idnits 2.17.00 (12 Aug 2021) /tmp/idnits64299/draft-ietf-pppext-crtxchg-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-21) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 76: '... MUST specify the Certificate-Exchan...' RFC 2119 keyword, line 102: '... MUST This word, or the ad...' RFC 2119 keyword, line 106: '... MUST NOT This phrase means th...' RFC 2119 keyword, line 109: '... SHOULD This word, or the ad...' RFC 2119 keyword, line 115: '... MAY This word, or the ad...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 69 has weird spacing: '... not be manda...' == Line 92 has weird spacing: '...re that the i...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 703 looks like a reference -- Missing reference section? '2' on line 706 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group William A. Nace(NSA) 3 Internet Draft James E. Zmuda(SPYRUS) 4 expires in six months November 21st, 1997 6 PPP Certificate Exchange Protocol 7 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol 12 Extensions Working Group of the Internet Engineering Task Force 13 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 14 mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as 'work 27 in progress.' 29 To learn the current status of any Internet-Draft, please check 30 the '1id-abstracts.txt' listing contained in the Internet-Drafts 31 Shadow Directories on ds.internic.net (US East Coast), 32 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 33 munnari.oz.au (Pacific Rim). 35 Abstract 37 The Point-to-Point Protocol (PPP) [1] provides a standard method 38 for transporting multi-protocol datagrams over point-to-point 39 links 41 PPP also defines an extensible Link Control Protocol, which 42 allows negotiation of an Authentication Protocol for 43 authentication of its peer before allowing Network Layer 44 protocols to transmit over the link. 46 The Certificate exchange protocol is an extension to PPP that is 48 DRAFT PPP Certificate Exchange Protocol November 1997 50 in the form of an additional phase, called the certificate 51 exchange phase, that would allow for a PPP entity to request 52 certificates from a peer. If configured, this phase would be 53 negotiated during the LCP exchange. This exchange of 54 certificates is aimed at easing configuration issues by 55 providing for the exchange of certificate path information in a 56 standard manner across different strong, or public-key 57 certificate-based, authentication protocols. The certificate 58 exchange protocol accomodates arbitrary sized certificates. 60 1. Introduction 62 In order to establish communications over a point-to- point link, 63 each end of the PPP link must first send LCP packets to configure the 64 data link during Link Establishment phase. After the link has been 65 established, we are suggesting that the PPP provide for an optional 66 Certificate Exchange phase before proceeding to the Authentication 67 phase. 69 By default, this certificate exchange phase will not be mandatory. 70 If the certificate exchange phase is configured into a PPP entity, 71 and negotiation with the peer has concluded that it can be supported 72 by the peer, then the certificate exchange protocol will be performed 73 after the LCP phase and before the Authentication phase. 75 If the certificate exchange protocol is desired, an implementation 76 MUST specify the Certificate-Exchange-Protocol Configuration Option 77 during Link Establishment phase. 79 Of course, if no Authentication Protocol is negotiated during the 80 Link Establishment phase, or one that does not use strong authentica- 81 tion that requires the type of certificate that we have obtained, 82 then the product of the Certificate Exchange protocol will have been 83 wasted. However, this is to be avoided through proper configuration 84 and properly forming certificate exchange requests and responses. 85 This means primarily two things: First, the in the initial certifi- 86 cate exchange request, the requestor shall send the algorithm iden- 87 tifier for the certificate type in which he is interested, as well as 88 his distinguished name. Second, the responder shall include a certi- 89 ficate (if available) in his reply that supports the algorithm iden- 90 tified in the request, and that is within the naming hierarchy indi- 91 cated by the requestor's distinguished name. These procedures will 92 insure that the information retrieved by the certificate exchange 93 protocol is relevant. 95 DRAFT PPP Certificate Exchange Protocol November 1997 97 1.1. Specification of Requirements 99 In this document, several words are used to signify the requirements 100 of the specification. These words are often capitalized. 102 MUST This word, or the adjective required, means that the 103 definition is an absolute requirement of the specifi- 104 cation. 106 MUST NOT This phrase means that the definition is an absolute 107 prohibition of the specification. 109 SHOULD This word, or the adjective recommended, means that 110 there may exist valid reasons in particular cir- 111 cumstances to ignore this item, but the full implica- 112 tions must be understood and carefully weighed before 113 choosing a different course. 115 MAY This word, or the adjective optional, means that this 116 item is one of an allowed set of alternatives. An 117 implementation which does not include this option MUST 118 be prepared to interoperate with another implementa- 119 tion which does include the option. 121 1.2. Terminology 123 This document frequently uses the following terms: 125 certificate A certificate consists of the binding together of one 126 or more public key values and an identity. This bind- 127 ing is effected through a digital signature which is 128 applied to the data containing both the public key and 129 the identity. This signature is applied by a "certif- 130 ication authority" that is recognized as issuing this 131 certificate on behalf of the entity identified in the 132 certificate. In this manner a recipient of this certi- 133 ficate can determine the recognized public key of the 134 particular entity identified in the certificate. This 135 requires the recipient to, either directly or 136 indirectly, trust the authority that has issued this 137 certificate. 139 certificate validation 140 An individual certificate provides the recipient of a 141 certificate the assurance that the subject named in 142 the certificate is the holder of the public key con- 143 tained in the certificate. However, this assurance 145 DRAFT PPP Certificate Exchange Protocol November 1997 147 requires that the recipient trust the issuer of the 148 certificate. If the recipient doesn't directly trust 149 the certificate issuer, the recipient will attempt to 150 establish that trust by reviewing and validating the 151 certificate of the issuing authority itself. This 152 process continues until the recipient arrives at an 153 issuer whom it does trust. If this process is suc- 154 cessful, the certificate is validated. If this pro- 155 cess is unsuccessful within a certain number of steps 156 the certificate is not validated. This process of 157 validation of a chain of certificates is called certi- 158 ficate validation. 160 certificate pathThe chain of certificates examined during certificate 161 validation. 163 certification authority (CA) 164 An authority trusted by one or more users to create 165 and assign certificates. [2]. 167 distinguished name 168 A unique hierarchical name. Used in the certificate's 169 "subject" field to denote the entity associated with 170 the public key value(s) in the certificate[2]. Also 171 used in the certificate's "issuer" field to denote the 172 entity that issued this certificate. 174 peer The other end of the point-to-point link. 176 Requestor The end of the link initiating the Certificate 177 Exchange. It does this by sending the peer a Certifi- 178 cate Exchange Request packet. 180 2. PPP Certificate Exchange Protocol 182 The Certificate Exchange Protocol is a general protocol in support of 183 public-key based PPP authentication protocols. 185 The gating issue with respect to the deployment of public-key based 186 authentication protocols is the establishment of infrastructure. Two 187 types of infrastructure are needed. The first is the ability to issue 188 certificates. This relies upon the availability of certificate 189 authorities with the means to adequately verify legitimate users 190 before issuing them certificates. 192 The second type of infrastructure is a method to distribute these 193 certificates to the necessary parties, who are engaged in 195 DRAFT PPP Certificate Exchange Protocol November 1997 197 certificate-based strong authentication. There are a number of ways 198 that this can be accomplished in practice. The first, and obvious 199 method is to require that all parties who wish to employ 200 certificate/public-key based authentication have a complete database 201 of all the certificates required to authenticate any desired peer. 202 Another alternative would be to utilize one of the many access proto- 203 cols to retrieve a required certificate from a directory service. 204 Another method would be to require security protocols to transfer 205 certificates during the authentication exchange. None of these 206 options is particularly attractive or even applicable for the case of 207 PPP certificate-based authentication protocols. 209 The use of a pre-configured database is a possible but limited 210 approach. 212 The use of a directory service is not feasible due to the point in 213 time at which PPP authentication protocols are run, namely during the 214 authentication phase. At this point in time the connectivity needed 215 to reach a directory service has not yet been achieved. 217 The current approach used within certificate-based authentication in 218 PPP is to saddle the authentication protocol with the task of 219 exchanging the certificates required to authenticate a peer. This is 220 problematic. The reason is that more data than can be conveyed in a 221 single PPP packet may be required to be exchanged, and the PPP proto- 222 cols, running at the level they are and in the simple request 223 response fashion they do, do not immediately lend themselves to con- 224 veying large amounts of data. 226 The authors suggest that a better option is for the PPP authentica- 227 tion protocols to worry about authentication and another protocol to 228 perform the exchanges of certificates required to support certificate 229 validation. 231 The Certificate Exchange protocol is such a protocol. 233 The Certificate Exchange Protocol is a challenge- response protocol. 234 The initiator starts the protocol by sending the peer an initial 235 exchange packet. The peer is to respond to this request with an ini- 236 tial exchange response packet containing his own certificate. The 237 initiator then determines if he has the information required to vali- 238 date this certificate. [See the definition of certificate valida- 239 tion, above.] If the initiator does not possess such information, he 240 issues another certificate exchange request packet. This packet, 241 however is a "DName Specified" request packet. In this packet the 242 initiator puts the Distinguished name of the entity whose certificate 243 he requires to complete the next step in the certificate validation 244 process. The peer is to respond to this request with the certificate 246 DRAFT PPP Certificate Exchange Protocol November 1997 248 for the entity named in the request. If this certificate itself 249 requires another certificate in order to be validated, the initiator 250 issues yet another Certificate Exchange Request packet with DName of 251 the entity whose certificate is required to validate this certifi- 252 cate. This process continues until the complete certificate path for 253 the peer has been validated. 255 The protocol also has additional request/response types to handle the 256 case of a certificate that is itself too large for one PPP packet. 258 3. PPP Certificate Exchange Protocol Packet Format 260 The Certificate Exchange protocol is accomplished using two different 261 packet formats: a Request packet format and a Response packet format. 263 Both the Certificate Exchange Request and Response packets have the 264 following common format: 266 0 1 2 3 267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Code | Identifier | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type | Type Data ... 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 3.0-1 - The Certificate Exchange protocol packet format 275 Code 277 1 (Request) 278 2 (Response) 280 Identifier 282 The identifier field is one octet and aids in matching 283 responses with requests. The identifier field MUST be 284 changed on each Request packet containing a different 285 DName value. 287 Length 289 The Length field is two octets and indicates the length 290 of the Certificate Exchange Request and Response packets 291 including the Code, Identifier, Length, Type, and Type 292 Data fields. Octets in the packet outside the range of 293 the Length field should be treated as Data Link Layer 294 padding and should be ignored on reception. 296 DRAFT PPP Certificate Exchange Protocol November 1997 298 Type 300 1 (Initial Exchange) 301 2 (DName Specified Exchange) 302 3 (Certificate unavailable) 303 4 (Partial Certificate Request/Response) 305 Type Data 307 Depending upon the setting of the type field, the Request 308 packet will either use this field to carry the algorithm 309 ID and DName from its own certificate (in the case of 310 an Initial Exchange), or will use this field to specify 311 the DName of the certificate being requested (in the case 312 of a "DName Specified" Exchange). The Response packet 313 uses this field to hold the certificate value. The length 314 of this field is inferred from the length field for this 315 packet as a whole. 317 In the event the responder must reply to a request 318 (either Initial, or DName-specified) with a certificate 319 that is too big to fit within the current PPP MTU, the 320 certificate exchange protocol will respond with a "Par- 321 tial Certificate" response type packet. This format 322 allows the responder to return a partial certificate and 323 indicate the amount remaining. Subsequent "Partial Cer- 324 tificate" Requests and Responses will be used to transfer 325 the complete certificate. 327 The following sections define the format of the various 328 request and response packets used in the certificate exchange 329 protocol. The first to be dealt with are the PDUs exchanged 330 during the retrieval of complete certificates. Following this 331 are the PDUs required to support retrieval of certificates too 332 large to fit within the current PPP MTU. 334 3.1. Certificate Exchange Protocol Request Packet 336 The Certificate Exchange Protocol Request Packet is formatted as fol- 337 lows: 339 DRAFT PPP Certificate Exchange Protocol November 1997 341 0 1 2 3 342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Code | Identifier | Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | AlgIDLen | AlgorithmID... | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | ...AlgorithmID... | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 |...AlgorithmID | DName... 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 3.0-2 - Certificate Exchange Protocol Request Packet format 354 Code 356 1 (Request) 358 Identifier 360 The identifier field is one octet and aids in matching 361 responses with requests. The identifier field MUST be 362 changed on each Request packet containing a different 363 DName value. 365 Length 367 The Length field is two octets and indicates the length 368 of the Certificate Exchange Request packet including the 369 Code, Identifier, Length, and Type, Algorithm ID, and 370 DName fields. Octets in the packet outside the range of 371 the Length field should be treated as Data Link Layer 372 padding and should be ignored on reception. 374 Type 376 1 (Initial Exchange) 377 2 (DName Specified Exchange) 379 AlgIDLen 381 Indicates the length of the AlgorithmID field. 383 AlgorithmID 385 If the type field is set to a 1, indicating an "Initial 386 Exchange" then this field will contain the Algorithm 387 Identifier from the Certificate that the requestor will 389 DRAFT PPP Certificate Exchange Protocol November 1997 391 use during the authentication phase. This field is car- 392 ried in its raw ASN.1 form, right out of the certificate. 393 On the other hand, if the type field is set to a 2, 394 indicting this is a subsequent request, then this field 395 will not be present. This is indicating by a value of 0 396 in the AlgIDLen field. 398 DName 400 If the type field is set to a 1, indicating an "Initial 401 Exchange" then this field contains the DName from the 402 certificate that the requestor will use during the 403 authentication phase. On the other hand, if the type 404 field is set to a 2, indicting this is a subsequent 405 request, then this field will contain the DName of the 406 entity whose certificate is being requested. 408 3.2. Certificate Exchange Protocol Response Packet 410 The Certificate Exchange response packet is formatted as follows. 412 0 1 2 3 413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Code | Identifier | Length | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Certificate... 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 3.0-3 - Certificate Exchange Protocol Response Packet format 421 Code 423 2 (Response) 425 Identifier 427 The identifier field is one octet and MUST match the 428 Identifier field from the corresponding request. 430 Length 432 The Length field is two octets and indicates the length 433 of the Certificate Exchange Response packet including the 434 Code, Identifier, Length, and Type, and Certificate 435 fields. Octets in the packet outside the range of the 436 Length field should be treated as Data Link Layer padding 438 DRAFT PPP Certificate Exchange Protocol November 1997 440 and should be ignored on reception. 442 Type 444 The Type field in the Response can carry either the value 445 1 (signifying an initial certificate exchange request) or 446 the value 2 (signifying a subsequent certificate exchange 447 request), or the value 3 (signifying a retrieval 448 failure). 450 Certificate 452 The Certificate field contains the complete ASN.1 encoded 453 X.509 certificate for the entity named in the Certificate 454 Exchange request that this response corresponds to. In 455 the case there was no entity named in the Certificate 456 Exchange request (e.g. an Initial Certificate Exchange 457 Request) the responder will choose a certificate to use 458 to send to the requestor. The type of certificate 459 returned should correspond to the type of algorithm indi- 460 cated by the Requestor in the Initial Exchange Request. 461 The public key in this certificate should correspond to 462 the private key that will be used in any subsequent EAP 463 authentication operations. 465 A type value of 4 indicates a "Partial Certificate" 466 response. This format is described in section 3.3. 468 3.3. Certificate Exchange Protocol "Partial Certificate" Response 469 Packet 471 The Certificate Exchange "Partial Certificate" response packet is 472 formatted as follows. 474 DRAFT PPP Certificate Exchange Protocol November 1997 476 0 1 2 3 477 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Code | Identifier | Length | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type | CertOffset... | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | ...CertOffset | CertTotLen... | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |...CertTotLen | DName Length | DName... | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | ...DName | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Certificate Segment... 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 3.0-4 - Certificate Exchange Protocol "Partial Certificate" 492 Response Packet format 494 Code 496 2 (Response) 498 Identifier 500 The identifier field is one octet and MUST match the 501 Identifier field from the corresponding request. 503 Length 505 The Length field is two octets and indicates the length 506 of the Certificate Exchange Response packet including the 507 Code, Identifier, Length, and Type, and CertOffset, Cert- 508 TotLen, DName Length, DName, and Certificate fields. 509 Octets in the packet outside the range of the Length 510 field should be treated as Data Link Layer padding and 511 should be ignored on reception. 513 Type 515 The Type field in the "Partial Certificate" Response will 516 carry a value of 4, or the value 3 (signifying a 517 retrieval failure). 519 CertOffset 521 The CertOffset, or "Certificate Offset" field contains 522 the offset within the entire certificate of the segment 524 DRAFT PPP Certificate Exchange Protocol November 1997 526 carried within this partial response. 528 CertTotLen 530 The CertTotLen, or "Certificate Total Length" field con- 531 tains the length of the entire certificate, of which only 532 a portion is carried in this partial response. 534 DName Length 536 The Length of the DName field in bytes. 538 DName 540 This field contains the DName field from the Certificate, 541 whose segment is being carried in the Certificate Segment 542 field. This is present to facilitate the Requestors for- 543 mation of the subsequent "Partial Certificate" Requests 544 required to retrieve the complete Certificate. 546 Certificate Segment 548 The Certificate Segment field contains as much of the 549 complete ASN.1 encoded X.509 certificate that can be car- 550 ried within the current PPP MTU-sized packet. 552 3.4. Certificate Exchange Protocol "Partial Certificate" Request Packet 554 The Certificate Exchange "Partial Certificate" request packet is for- 555 matted as follows. 557 0 1 2 3 558 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Code | Identifier | Length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type | CertOffset... | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | ...CertOffset | CertTotLen... | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 |...CertTotLen | DName Length | DName... | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | ...DName 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Figure 3.0-5 - Certificate Exchange Protocol "Partial Certificate" 571 Request Packet format 573 DRAFT PPP Certificate Exchange Protocol November 1997 575 Code 577 1 (Request) 579 Identifier 581 The identifier field is one octet and aids in matching 582 responses with requests. The identifier field MUST be 583 changed on each Request packet containing a different 584 DName value. 586 Length 588 The Length field is two octets and indicates the length 589 of the Certificate Exchange Response packet including the 590 Code, Identifier, Length, and Type, and CertOffset, Cert- 591 TotLen, DName Length, and DName fields. Octets in the 592 packet outside the range of the Length field should be 593 treated as Data Link Layer padding and should be ignored 594 on reception. 596 Type 598 The Type field in the "Partial Certificate" Request will 599 carry a value of 4. 601 CertOffset 603 The CertOffset, or "Certificate Offset" field contains 604 the offset within the entire certificate of the certifi- 605 cate segment being requested. 607 CertTotLen 609 The CertTotLen, or "Certificate Total Length" field con- 610 tains the length of the entire certificate. 612 DName Length 614 The Length of the DName field in bytes. 616 DName 618 This field contains the DName field from the Certificate, 619 whose segment is being requested. 621 DRAFT PPP Certificate Exchange Protocol November 1997 623 4. Certificate Exchange Protocol Processing 625 During the certificate exchange phase, a PPP entity that is config- 626 ured to use the certificate exchange protocol will initiate the Cer- 627 tificate Exchange protocol. The Certificate Exchange protocol is a 628 series of REQUEST/RESPONSE exchanges. The PPP entity configured to 629 perform the Certificate Exchange protocol, or "initiator", will send 630 REQUEST packets requesting the peer send it a certificate. In the 631 initial exchange the initiator will send a initial Certificate 632 Exchange request asking the peer for its current certificate. The 633 Requestor will place its own certificate in this outgoing Initial 634 Exchange Request. The reason for this is so that the Responder will 635 know which, compatible type of certificate of the many it may have 636 available to send back in the Response. Next, the peer will reply 637 with a response packet containing its certificate of the appropriate 638 type, it available. If not, it will return a Response packet with a 639 type field indicating a retrieval failure. The initiator will then 640 determine if this certificate can be validated with the information 641 it currently has. (If it has the complete path to a common trust 642 point that this certificate requires.) If the initiator decides it 643 has sufficient information to validate this certificate, it finishes 644 the certificate exchange protocol phase and continues to the authen- 645 tication phase. If, on the other hand, the initiator does not have 646 enough information to validate this certificate, it sends another 647 Certificate Exchange protocol request packet to the peer requesting 648 the certificate (or the first certificate of a number of certifi- 649 cates) which it is missing in order to complete validation. This 650 process continues until the complete path has been obtained. The Cer- 651 tificate Exchange protocol is unilateral in that the requests are in 652 one direction only. If the peer PPP entity requires certificates to 653 accomplish authentication then that peer should also be configured to 654 perform the certificate exchange protocol. 656 In the event that the type field of a certificate response contains a 657 4 - indicating that the data field contains a partial response, the 658 requestor will use a partial certificate request type packet to 659 request the next segment in the certificate. The segment requested 660 is indicated in the partial certificate request by indicating the 661 byte offset within the total certificate of the next segment of the 662 certificate. The exchange of these request-response pairs continues 663 until the requestor is satisfied that it has retrieved the entire 664 certificate. Then processing continues, if necessary, to retrieve 665 the complete certificate path as in the normal case, above. 667 Figure 4.0-1 depicts the operation of the Certificate Exchange proto- 668 col. (For the purposes of this example, it is assumed that the cer- 669 tificates fit within a single PPP packet) In this figure depicting 670 protocol exchanges, the curly braces ({, }) denote items in ASN.1 672 DRAFT PPP Certificate Exchange Protocol November 1997 674 representation. 676 Side: B A 678 Authenticator Authenticatee 680 CRTXCHG Request (ID1, Initial Exchange, {certB}) => 682 <= CRTXCHG Response(ID1, Initial Exchange, {certA}) 684 CRTXCHG Request (ID2, DName Specified, {DName}) => 686 <= CRTXCHG Response(ID2, DName Specified, {Cert(DName)}) 688 Figure 4.0-1 Certificate Exchange protocol processing 690 Security Considerations 692 This memo defines a method for exchanging certificates to be used to 693 support public-key based authentication protocols, which rely upon 694 the validity of the public key used to verify signatures from the 695 peer. The validity of these public keys is vouched for by having the 696 certificates that bind them to an identity signed for by either a 697 directly or indirectly trusted third party. Obviously, the security 698 of such a system depends upon there being some common trust point 699 between the parties. 701 References: 703 [1] Simpson, W. A., 'The Point to Point Protocol 704 (PPP)', July 1994, RFC 1661. 706 [2] CCITT Recommendation X.509, 'The Directory - 707 Authentication Framework', 1988. 709 Acknowledgements: 711 Thanks to Peter Yee and Russ Housley who provided helpful comments on 712 earlier versions of this Memo. And thanks to Bill Simpson for the 713 standard PPP spec boilerplate from which I have borrowed heavily. 715 DRAFT PPP Certificate Exchange Protocol November 1997 717 Chair's Address: 719 The working group can be contacted via the current 720 chair: 722 Karl Fox 723 Ascend Communications, Inc. 725 Email: karl@ascend.com 727 Author's Address: 729 Questions about this memo can also be directed to: 731 DIRNSA 732 Attn: X22 (W. Nace) 733 9800 Savage Road 734 Fort Meade, MD 20755-6000 735 USA 737 Phone: +1 410 859-4464 738 Email: WANace@missi.ncsc.mil 740 James E. Zmuda 741 SPYRUS 742 2460 N. First Street 743 Suite 100 744 San Jose, CA 95131-1023 745 USA 747 Phone: +1 408 432-8180 748 Email: jzmuda@spyrus.com