idnits 2.17.1 draft-ietf-pppext-crtxchg-00.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 (2024-04-20) 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) 2024 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.) ** There are 2 instances of too long lines in the document, the longest one being 60 characters in excess of 72. ** 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 688 looks like a reference -- Missing reference section? '2' on line 691 looks like a reference Summary: 10 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 16th, 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 Exchange" then this field will contain the Algorithm Identifi 387 DName 389 DRAFT PPP Certificate Exchange Protocol November 1997 391 If the type field is set to a 1, indicating an "Initial Exchange" then this field contains the DName from the certifi 393 3.2. Certificate Exchange Protocol Response Packet 395 The Certificate Exchange response packet is formatted as follows. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Code | Identifier | Length | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Certificate... 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 3.0-3 - Certificate Exchange Protocol Response Packet format 406 Code 408 2 (Response) 410 Identifier 412 The identifier field is one octet and MUST match the 413 Identifier field from the corresponding request. 415 Length 417 The Length field is two octets and indicates the length 418 of the Certificate Exchange Response packet including the 419 Code, Identifier, Length, and Type, and Certificate 420 fields. Octets in the packet outside the range of the 421 Length field should be treated as Data Link Layer padding 422 and should be ignored on reception. 424 Type 426 The Type field in the Response can carry either the value 427 1 (signifying an initial certificate exchange request) or 428 the value 2 (signifying a subsequent certificate exchange 429 request), or the value 3 (signifying a retrieval 430 failure). 432 Certificate 434 The Certificate field contains the complete ASN.1 encoded 435 X.509 certificate for the entity named in the Certificate 436 Exchange request that this response corresponds to. In 438 DRAFT PPP Certificate Exchange Protocol November 1997 440 the case there was no entity named in the Certificate 441 Exchange request (e.g. an Initial Certificate Exchange 442 Request) the responder will choose a certificate to use 443 to send to the requestor. The type of certificate 444 returned should correspond to the type of algorithm indi- 445 cated by the Requestor in the Initial Exchange Request. 446 The public key in this certificate should correspond to 447 the private key that will be used in any subsequent EAP 448 authentication operations. 450 A type value of 4 indicates a "Partial Certificate" 451 response. This format is described in section 3.3. 453 3.3. Certificate Exchange Protocol "Partial Certificate" Response 454 Packet 456 The Certificate Exchange "Partial Certificate" response packet is 457 formatted as follows. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Code | Identifier | Length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type | CertOffset... | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | ...CertOffset | CertTotLen... | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 |...CertTotLen | DName Length | DName... | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | ...DName | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Certificate Segment... 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Figure 3.0-4 - Certificate Exchange Protocol "Partial Certificate" 475 Response Packet format 477 Code 479 2 (Response) 481 Identifier 483 The identifier field is one octet and MUST match the 484 Identifier field from the corresponding request. 486 DRAFT PPP Certificate Exchange Protocol November 1997 488 Length 490 The Length field is two octets and indicates the length 491 of the Certificate Exchange Response packet including the 492 Code, Identifier, Length, and Type, and CertOffset, Cert- 493 TotLen, DName Length, DName, and Certificate fields. 494 Octets in the packet outside the range of the Length 495 field should be treated as Data Link Layer padding and 496 should be ignored on reception. 498 Type 500 The Type field in the "Partial Certificate" Response will 501 carry a value of 4, or the value 3 (signifying a 502 retrieval failure). 504 CertOffset 506 The CertOffset, or "Certificate Offset" field contains 507 the offset within the entire certificate of the segment 508 carried within this partial response. 510 CertTotLen 512 The CertTotLen, or "Certificate Total Length" field con- 513 tains the length of the entire certificate, of which only 514 a portion is carried in this partial response. 516 DName Length 518 The Length of the DName field in bytes. 520 DName 522 This field contains the DName field from the Certificate, 523 whose segment is being carried in the Certificate Segment 524 field. This is present to facilitate the Requestors for- 525 mation of the subsequent "Partial Certificate" Requests 526 required to retrieve the complete Certificate. 528 Certificate Segment 530 The Certificate Segment field contains as much of the 531 complete ASN.1 encoded X.509 certificate that can be car- 532 ried within the current PPP MTU-sized packet. 534 DRAFT PPP Certificate Exchange Protocol November 1997 536 3.4. Certificate Exchange Protocol "Partial Certificate" Request Packet 538 The Certificate Exchange "Partial Certificate" request packet is for- 539 matted as follows. 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Code | Identifier | Length | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | CertOffset... | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | ...CertOffset | CertTotLen... | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |...CertTotLen | DName Length | DName... | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | ...DName 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Figure 3.0-5 - Certificate Exchange Protocol "Partial Certificate" 555 Request Packet format 557 Code 559 1 (Request) 561 Identifier 563 The identifier field is one octet and aids in matching 564 responses with requests. The identifier field MUST be 565 changed on each Request packet containing a different 566 DName value. 568 Length 570 The Length field is two octets and indicates the length 571 of the Certificate Exchange Response packet including the 572 Code, Identifier, Length, and Type, and CertOffset, Cert- 573 TotLen, DName Length, and DName fields. Octets in the 574 packet outside the range of the Length field should be 575 treated as Data Link Layer padding and should be ignored 576 on reception. 578 Type 580 The Type field in the "Partial Certificate" Request will 581 carry a value of 4. 583 DRAFT PPP Certificate Exchange Protocol November 1997 585 CertOffset 587 The CertOffset, or "Certificate Offset" field contains 588 the offset within the entire certificate of the certifi- 589 cate segment being requested. 591 CertTotLen 593 The CertTotLen, or "Certificate Total Length" field con- 594 tains the length of the entire certificate. 596 DName Length 598 The Length of the DName field in bytes. 600 DName 602 This field contains the DName field from the Certificate, 603 whose segment is being requested. 605 4. Certificate Exchange Protocol Processing 607 During the certificate exchange phase, a PPP entity that is config- 608 ured to use the certificate exchange protocol will initiate the Cer- 609 tificate Exchange protocol. The Certificate Exchange protocol is a 610 series of REQUEST/RESPONSE exchanges. The PPP entity configured to 611 perform the Certificate Exchange protocol, or "initiator", will send 612 REQUEST packets requesting the peer send it a certificate. In the 613 initial exchange the initiator will send a initial Certificate 614 Exchange request asking the peer for its current certificate. The 615 Requestor will place its own certificate in this outgoing Initial 616 Exchange Request. The reason for this is so that the Responder will 617 know which, compatible type of certificate of the many it may have 618 available to send back in the Response. Next, the peer will reply 619 with a response packet containing its certificate of the appropriate 620 type, it available. If not, it will return a Response packet with a 621 type field indicating a retrieval failure. The initiator will then 622 determine if this certificate can be validated with the information 623 it currently has. (If it has the complete path to a common trust 624 point that this certificate requires.) If the initiator decides it 625 has sufficient information to validate this certificate, it finishes 626 the certificate exchange protocol phase and continues to the authen- 627 tication phase. If, on the other hand, the initiator does not have 628 enough information to validate this certificate, it sends another 629 Certificate Exchange protocol request packet to the peer requesting 630 the certificate (or the first certificate of a number of 632 DRAFT PPP Certificate Exchange Protocol November 1997 634 certificates) which it is missing in order to complete validation. 635 This process continues until the complete path has been obtained. The 636 Certificate Exchange protocol is unilateral in that the requests are 637 in one direction only. If the peer PPP entity requires certificates 638 to accomplish authentication then that peer should also be configured 639 to perform the certificate exchange protocol. 641 In the event that the type field of a certificate response contains a 642 4 - indicating that the data field contains a partial response, the 643 requestor will use a partial certificate request type packet to 644 request the next segment in the certificate. The segment requested 645 is indicated in the partial certificate request by indicating the 646 byte offset within the total certificate of the next segment of the 647 certificate. The exchange of these request-response pairs continues 648 until the requestor is satisfied that it has retrieved the entire 649 certificate. Then processing continues, if necessary, to retrieve 650 the complete certificate path as in the normal case, above. 652 Figure 4.0-1 depicts the operation of the Certificate Exchange proto- 653 col. (For the purposes of this example, it is assumed that the cer- 654 tificates fit within a single PPP packet) In this figure depicting 655 protocol exchanges, the curly braces ({, }) denote items in ASN.1 656 representation. 658 Side: B A 660 Authenticator Authenticatee 662 CRTXCHG Request (ID1, Initial Exchange, {certB}) => 664 <= CRTXCHG Response(ID1, Initial Exchange, {certA}) 666 CRTXCHG Request (ID2, DName Specified, {DName}) => 668 <= CRTXCHG Response(ID2, DName Specified, {Cert(DName)}) 670 Figure 4.0-1 Certificate Exchange protocol processing 672 Security Considerations 674 This memo defines a method for exchanging certificates to be used to 675 support public-key based authentication protocols, which rely upon 676 the validity of the public key used to verify signatures from the 677 peer. The validity of these public keys is vouched for by having the 678 certificates that bind them to an identity signed for by either a 680 DRAFT PPP Certificate Exchange Protocol November 1997 682 directly or indirectly trusted third party. Obviously, the security 683 of such a system depends upon there being some common trust point 684 between the parties. 686 References: 688 [1] Simpson, W. A., 'The Point to Point Protocol 689 (PPP)', July 1994, RFC 1661. 691 [2] CCITT Recommendation X.509, 'The Directory - 692 Authentication Framework', 1988. 694 Acknowledgements: 696 Thanks to Peter Yee and Russ Housley who provided helpful comments on 697 earlier versions of this Memo. And thanks to Bill Simpson for the 698 standard PPP spec boilerplate from which I have borrowed heavily. 700 Chair's Address: 702 The working group can be contacted via the current 703 chair: 705 Karl Fox 706 Ascend Communications, Inc. 708 Email: karl@ascend.com 710 Author's Address: 712 Questions about this memo can also be directed to: 714 DIRNSA 715 Attn: X22 (W. Nace) 716 9800 Savage Road 717 Fort Meade, MD 20755-6000 718 USA 720 Phone: +1 410 859-4464 721 Email: WANace@missi.ncsc.mil 723 James E. Zmuda 724 SPYRUS 725 2460 N. First Street 726 Suite 100 728 DRAFT PPP Certificate Exchange Protocol November 1997 730 San Jose, CA 95131-1023 731 USA 733 Phone: +1 408 432-8180 734 Email: jzmuda@spyrus.com