idnits 2.17.1 draft-ietf-pppext-eapkea-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-19) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [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 66: '...ed, an implementation MUST specify the...' RFC 2119 keyword, line 86: '... MUST This word, or the ad...' RFC 2119 keyword, line 90: '... MUST NOT This phrase means th...' RFC 2119 keyword, line 93: '... SHOULD This word, or the ad...' RFC 2119 keyword, line 102: '... MAY This word, or the ad...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 776 looks like a reference -- Missing reference section? '2' on line 779 looks like a reference -- Missing reference section? '3' on line 783 looks like a reference -- Missing reference section? '5' on line 790 looks like a reference -- Missing reference section? '4' on line 786 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 7 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 Peter Yee(SPYRUS) 4 expires in six months James E. Zmuda(SPYRUS) 5 November 16th, 1997 7 PPP EAP KEA Public Key Authentication Protocol 8 10 Status of this Memo 12 This document is a submission to the Point-to-Point Protocol 13 Extensions Working Group of the Internet Engineering Task Force 14 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 15 mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is not appropriate to use Internet- 27 Drafts as reference material or to cite them other than as 'work 28 in progress.' 30 To learn the current status of any Internet-Draft, please check 31 the '1id-abstracts.txt' listing contained in the Internet-Drafts 32 Shadow Directories on ds.internic.net (US East Coast), 33 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 34 munnari.oz.au (Pacific Rim). 36 Abstract 38 The Point-to-Point Protocol (PPP) [1] provides a standard method 39 for transporting multi-protocol datagrams over point-to-point 40 links 42 PPP also defines an extensible Link Control Protocol, which 43 allows negotiation of an Authentication Protocol for 44 authentication of its peer before allowing Network Layer 45 protocols to transmit over the link. 47 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 49 PPP Extensible Authentication Protocol (EAP) [2] provides for a 50 number of authentication mechanisms. This document specifies 51 yet another authentication mechanism that may be used within the 52 EAP framework. This document defines the KEA Public Key 53 Authentication Protocol within PPP EAP. A side effect of KEA 54 public key authentication is the creation of a session key for 55 encryption of data on the PPP link. 57 1. Introduction 59 In order to establish communications over a point-to- point link, 60 each end of the PPP link must first send LCP packets to configure the 61 data link during Link Establishment phase. After the link has been 62 established, PPP provides for an optional Authentication phase before 63 proceeding to the Network- Layer Protocol phase. 65 By default, authentication is not mandatory. If authentication of 66 the link is desired, an implementation MUST specify the 67 Authentication-Protocol Configuration Option during Link Establish- 68 ment phase. 70 PPP Extensible Authentication Protocol (EAP) [2] allows for a number 71 of authentication protocols including KEA Public Key Authentication 72 Protocol. 74 This document defines the PPP EAP KEA Public Key Authentication Pro- 75 tocol. The Link Establishment and Authentication phases, and the 76 Authentication-Protocol Configuration Option are defined in The 77 Point-to-Point Protocol (PPP) [1]. The Extensible Authentication 78 protocol is defined in PPP Extensible Authentication Protocol (EAP) 79 [2]. 81 1.1. Specification of Requirements 83 In this document, several words are used to signify the requirements 84 of the specification. These words are often capitalized. 86 MUST This word, or the adjective required, means that the 87 definition is an absolute requirement of the specifi- 88 cation. 90 MUST NOT This phrase means that the definition is an absolute 91 prohibition of the specification. 93 SHOULD This word, or the adjective recommended, means that 94 there may exist valid reasons in particular 96 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 98 circumstances to ignore this item, but the full impli- 99 cations must be understood and carefully weighed 100 before choosing a different course. 102 MAY This word, or the adjective optional, means that this 103 item is one of an allowed set of alternatives. An 104 implementation which does not include this option MUST 105 be prepared to interoperate with another implementa- 106 tion which does include the option. 108 1.2. Terminology 110 This document frequently uses the following terms: 112 authenticator The end of the link requiring the authentication. The 113 authenticator specifies use of DSS Authentication in 114 the EAP-Request during Authentication phase. 116 certificate A certificate consists of the binding together of one 117 or more public key values and an identity. This bind- 118 ing is effected through a digital signature which is 119 computed over the data containing both the public key 120 and the identity. This signature is applied by a 121 "certification authority" who is recognized as issuing 122 this certificate on behalf of the entity identified in 123 the certificate. In this manner a recipient of this 124 certificate can determine the recognized public key of 125 the particular entity identified in the certificate. 126 This requires the recipient to, either directly or 127 indirectly, trust the authority who has issued this 128 certificate. 130 certification authority (CA) 131 An authority trusted by one or more users to create 132 and assign certificates. [3]. 134 digital signature 135 In the DSS, a digital signature is produced by per- 136 forming the DSA signing operation with a private key 137 on the SHA-1 Hash value computed over the original 138 data to be signed. The verification of this digital 139 signature requires the verifier to obtain the original 140 message, and the signature value, and the proper pub- 141 lic key value that is associated with the signer (see 142 certificates below). The verifier then also computes 143 the SHA-1 Hash of the message data, and then perform a 144 computation whose inputs include this hash value, the 146 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 148 public key, and the signature value. If the output of 149 this computation matches a particular part of the sig- 150 nature value produced by the signer, then the signa- 151 ture is verified. 153 distinguished name 154 A unique heirarchical name. Used in the certificate's 155 "subject" field to denote the entity associated with 156 the public key value(s) in the certificate[2]. Also 157 used in the certificate's "issuer" field to denote the 158 entity that issued this certificate. 160 KEA key pair A pair of related keys, used in the agreement of ses- 161 sion encryption key. The two keys in the pair are 162 known as the public and private keys. Knowledge of 163 the public key does not necessarily imply knowledge of 164 the private key of the pair. This document frequently 165 uses the following terms: 167 peer The other end of the point-to-point link; the end 168 which is being authenticated by the authenticator. 170 private key That key of a key pair which is known only by that 171 user [3]. 173 public key That key of a key pair which is publicly known [3]. 175 2. PPP EAP KEA Public Key Authentication 177 The PPP Extensible Authentication Protocol is a general protocol for 178 PPP authentication which supports multiple authentication mechanisms. 179 EAP MAY be negotiated at Link Control Phase. EAP MAY then be used to 180 select the KEA Public Key Authentication mechanisms at the Authenti- 181 cation Phase. 183 The KEA Public Key Authentication Protocol is a four pass request- 184 response protocol involving both authentication and key derivation. 185 Since a side effect of KEA authentication is the derivation of a ses- 186 sion encryption key, only one party need initiate the KEA Public Key 187 Authentication Protocol. Liveness testing of the derived key indi- 188 cates proper completion of the protocol. 190 In order to ensure that the authentication protocol is performed only 191 once, rules are introduced to handle the case where both parties ini- 192 tiate the protocol. 194 If one party transmits a KEA Request and the other a DSS Unilateral 196 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 198 Request (or any other Request for that matter), then the second party 199 may refuse the KEA Request by transmitting an LCP Terminate-Request. 200 Should it be willing to honor the KEA Request, it will not terminate 201 the link. Rather it shall no longer expect a Response to its DSS 202 Unilateral Request and shall transmit a KEA Response. 204 If both parties transmit KEA Requests, the party transmitting the 205 lesser value for the KEA Ra value shall no longer expect a Response 206 to its Request, but shall instead generate a Response to the KEA 207 Request containing the higher Ra value. 209 The initiating party starts the protocol with a EAP KEA Request 210 packet. The peer MUST formulate a Response packet based on informa- 211 tion in the Request packet as well as information only the peer knows 212 (the peer's private key). The peer MUST also provide in its response 213 a reference (i.e. the Distinguished Name in the Certificate) to its 214 own certificate (the certificate containing the peer's public key), 215 as well as proof that it knows the corresponding private key. The 216 peer's certificate is assumed to have been obtained through other 217 means. One such means is the use of the Certificate Exchange Proto- 218 col. The Certificate Exchange Protocol is defined as an extension to 219 the PPP protocol suite. It is suggested as occurring during a new 220 phase in between Link Control and Authentication. The Certificate 221 Exchange Protocol is defined in [5]. 223 After the initial request and response, a second request/response 224 exchange is used to test the liveness of the derived key. Successful 225 completion of this exchange is signaled to the peer by the sending of 226 the EAP Success Packet. 228 In detail, the steps in EAP KEA are: 230 After the Link Establishment phase is complete and Extensible Authen- 231 tication Protocol is negotiated, the authenticator sends a Request 232 packet to authenticate the peer. The Request packet has a type field 233 specifying KEA Public Key Authentication plus the requester's certi- 234 ficate reference and Ra value. 236 2. The peer sends a Response packet in reply to the 237 Request. The Response packet contains the peer's cer- 238 tificate reference, Rb value, a wrapped Message 239 Encryption Key, an initialization vector, and a nonce, 240 The nonce is encrypted using the MEK. Underlying the 241 transmission of this Response is the calculation by 242 the peer of a Token Encryption Key, generation and 243 wrapping of a Message Encryption Key, and encryption 244 of a random nonce using the Message Encryption Key. 246 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 248 3. The initiator then begins the KEA-Validate EAP 249 exchange by sending a Request containing another ini- 250 tialization vector, and, encrypted in the MEK, the 251 original nonce, incremented by one, and a new, random 252 nonce. Again, underlying the transmission of this 253 Request is the calculation by the initiator of the 254 Token Encryption Key, the successful unwrapping of the 255 Message Encryption Key, and its use to decrypt the 256 peer's nonce. 258 4. The peer checks the KEA-Validate Request by decrypting 259 both nonces. The original is checked to see that it 260 has been incremented, while the initiator's nonce is 261 incremented and encrypted and sent back in the KEA- 262 Validate Response. 264 5. The initiator checks the KEA Validate Response by 265 decrypting the nonce. This returned nonce should 266 equal the nonce sent by the originator plus one. If 267 the nonce matches as expected the initiator ends the 268 authentication phase by sending the peer a Success 269 packet. Otherwise the peer is sent a Failure packet. 270 These packets are defined in PPP Extensible Authenti- 271 cation Protocol (EAP) [2]. 273 3. PPP KEA DSS Public Key Authentication Packet Format 275 KEA authentication is performed using a derivative of the mechanism 276 introduced in draft-ietf-cat-ftpkeasj-00.txt. 278 The initiating party is identified as "A"; its peer as "B". Four 279 packets are exchanged in order to perform the authentication, first 280 from A to B, and then from B to A, then repeating that sequence. 282 Both the EAP Response and Request packets for the KEA and KEA- 283 Validate Type have the following format: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Code | Identifier | Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Type Data ... 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 3.0-1 - The PPP EAP packet format 294 Code 296 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 298 1 (Request) 299 2 (Response) 301 Identifier 303 The identifier field is one octet and aids in matching 304 responses with requests. The identifier field MUST be 305 changed on each Request packet containing a different 306 ChallengeVal. 308 Length 310 The Length field is two octets and indicates the length 311 of the EAP Request and Response packets including the 312 Code, Identifier, Length, Type, and Type Data fields. 313 Octets in the packet outside the range of the Length 314 field should be treated as Data Link Layer padding and 315 should be ignored on reception. 317 Type 319 The Type field in the Request will carry the value 11 320 (KEA) or 12 (KEA-VALIDATE). The Type field in the 321 Response SHOULD carry the corresponding value unless the 322 peer wishes to send a Nak Type to indicate that it is 323 incapable of handling KEA authentication. 325 Type Data 327 The contents and formats of the remainder of the packet 328 differ for each of the four packet types: 1) KEA Request; 329 2) KEA Response; 3) KEA-VALIDATE Request; and 4) 330 KEA VALIDATE Response. 332 The following sections define the format of the request and response. 334 3.1. EAP KEA Request Packet 336 The KEA Request packet is formatted as follows: 338 This information is formatted in a length-value format. No explicit 339 type field is necessary because all fields are required and are in a 340 determinate order. The last element does not include a length field 341 because its length can be determined from the overall length. The 342 EAP KEA Request packet has the following overall format: 344 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Code | Identifier | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type | ranA Length | ranA... | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | ...ranA... | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | ...ranA... | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | . | 358 . 359 . 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | ...ranA... | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | ...ranA | DName... 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 3.0-2 - EAP KEA Request Packet format 367 Code 369 1 (Request) 371 Identifier 373 The identifier field is one octet and aids in matching 374 responses with requests. The identifier field MUST be 375 changed on each Request packet containing a different 376 RanA value. 378 Length 380 The Length field is two octets and indicates the length 381 of the EAP Request and Response packets including the 382 Code, Identifier, Length, Type, RanA length field, RanA 383 field, and DName field. Octets in the packet outside the 384 range of the Length field should be treated as Data Link 385 Layer padding and should be ignored on reception. 387 Type 389 The Type field in the Request will carry the value 11 390 (KEA). 392 ranA Length 394 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 396 The Length of the ranA field in bytes is specified here. 397 A single byte is used to represent this length. For KEA 398 this value is 128. 400 ranA 402 The value of the random number from the initiator to the 403 responder. For KEA this field is 128 bytes in length. 405 DName 407 The DER-encoded form of the subject field in the X.509 408 certificate whose public key corresponds to the private 409 key used in the KEA operation. 411 3.2. EAP KEA Response Packet 413 The KEA Response packet is formatted as follows: 415 This information is formatted in a length-value format. No explicit 416 type field is necessary because all fields are required and are in a 417 determinate order. The last element does not include a length field 418 because its length can be determined from the overall length. The 419 EAP KEA Response packet has the following overall format: 421 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Code | Identifier | Length | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | ranB Length | ranB... | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | ...ranB... | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | . | 433 . 434 . 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | ...ranB | wMEK Length | wMEK... | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | ...wMEK... | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | ...wMEK... | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | ...wMEK | IV Length | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | IV... | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | . | 447 . 448 . 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | ...IV | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | EncNonce Len | EncNonce... | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | . | 455 . 456 . 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | ...EncNonce | DName... 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 3.0-2 - EAP KEA Response Packet format 463 Code 465 2 (Response) 467 Identifier 469 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 471 The identifier field is one octet and MUST match the 472 Identifier field from the corresponding request. 474 Length 476 The Length field is two octets and indicates the length 477 of the EAP Request and Response packets including the 478 Code, Identifier, Length, Type, RanB length field, RanB 479 field, wMEK Length field, wMEK field, IV Length field, IV 480 field, Encrypted Nonce Length field, Encrypted Nonce 481 field, and DName field. Octets in the packet outside the 482 range of the Length field should be treated as Data Link 483 Layer padding and should be ignored on reception. 485 Type 487 The Type field in the Response will carry the value 11 488 (KEA) unless the peer wishes to send a Nak Type to indi- 489 cate that it is incapable of handling KEA authentication. 491 ranB Length 493 The Length of the ranB field in bytes is specified here. 494 A single byte is used to represent this length. For KEA 495 this value is 128. 497 ranB 499 The value of the random number from the responder to the 500 initiator. For KEA this field is 128 bytes in length. 502 wMEK Length 504 The Length of the wMEK field in bytes is specified here. 505 A single byte is used to represent this length. For KEA 506 and the default encryption algorithm this value is 12. 508 wMEK 510 The value of the TEK-wrapped MEK. This MEK is a truly 511 random key generated by the responder. It is wrapped in 512 the TEK created during the KEA computation on the 513 responder's side. This means this MEK can only be 514 unwrapped by the entity that initiated this KEA exchange. 515 For KEA and the default encryption algorithm this field 516 is 12 bytes in length. 518 IV Length 520 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 522 The Length of the IV field in bytes is specified here. A 523 single byte is used to represent this length. For KEA 524 and the default encryption algorithm this value is 24. 526 IV 528 The value of the IV. This value is required to support 529 the subsequent use of encryption algorithms that will use 530 the MEK generated during this exchange. This is the IV 531 value to be fed into the decryptor on the Requestor's 532 side. For KEA and the default encryption algorithm this 533 field is 24 bytes in length. 535 Encrypted Nonce Length 537 The Length of the Encrypted Nonce field in bytes is 538 specified here. A single byte is used to represent this 539 length. For KEA and the default encryption algorithm 540 this value is 24. 542 Encrypted Nonce 544 The value of the Encrypted Nonce. This value is used in 545 the first of two liveness checks that are performed in 546 each direction on the link. To support this liveness 547 check the KEA Responder chooses a Nonce, encrypts it 548 using the MEK (the one whose wrapped value is in the 549 field wMEK) with the default encryption algorithm, and 550 places this value here in this field. Upon receiving this 551 value the KEA Requestor sends back in a KEA-VALIDATE 552 Request the encrypted value of this Nonce value plus one. 553 The liveness check for Responder is then performed by 554 decrypting this last value and checking if it equals the 555 original Nonce plus one. 557 DName 559 The value of the subject field in the X.509 certificate 560 whose public key corresponds with the private key used in 561 the KEA computation by the peer. 563 3.3. EAP KEA-VALIDATE Request Packet 565 The KEA-VALIDATE Request packet is formatted as follows: 567 This information is formatted in a length-value format. No explicit 568 type field is necessary because all fields are required and are in a 569 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 571 determinate order. The last element does not include a length field 572 because its length can be determined from the overall length. The EAP 573 KEA-VALIDATE Request packet has the following overall format: 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Code | Identifier | Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type | IVPrime Len | IVPrime... | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | ...IVPrime... | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | . | 585 . 586 . 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | ...IVPrime | Encrypted Nonces... | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | . | 591 . 592 . 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | ...Encrypted Nonces... | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Figure 3.0-3 - EAP KEA-VALIDATE Request Packet format 598 Code 600 1 (Request) 602 Identifier 604 The identifier field is one octet and aids in matching 605 responses with requests. The identifier field MUST be 606 changed on each Request packet containing a different 607 EncryptedNonces value. 609 Length 611 The Length field is two octets and indicates the length 612 of the EAP KEA-VALIDATE Request packet including the 613 Code, Identifier, Length, Type, IVPrime length field, 614 IVPrime field, and Encrypted Nonce fields. Octets in the 615 packet outside the range of the Length field should be 616 treated as Data Link Layer padding and should be ignored 617 on reception. 619 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 621 Type 623 The Type field in the Request will carry the value 12 624 (KEA-VALIDATE). 626 IVPrime Length 628 The Length of the IVPrime field in bytes is specified 629 here. A single byte is used to represent this length. 630 For KEA and the default encryption algorithm this value 631 is 24. 633 IVPrime 635 The value of the IV from the Initiator to the peer. This 636 value is required to support the subsequent use of 637 encryption algorithms that will use the MEK generated 638 during this exchange. This is the IV value to be fed 639 into the decryptor on the Responder's side. For KEA and 640 the default encryption algorithm this field is 24 bytes 641 in length. 643 Encrypted Nonces Length 645 The Length of the Encrypted Nonces field in bytes is 646 specified here. A single byte is used to represent this 647 length. For KEA and the default encryption algorithm 648 this value is 40. 650 Encrypted Nonces 652 The value of the Encrypted Nonces. There are two values 653 which are concatenated together and encrypted (with the 654 current MEK) here. The first is the number the Requestor 655 forms when he takes the Nonce value that the Responder 656 sent over in the previous KEA Response and adds one to 657 it. The second value in this field is the NoncePrime 658 value, or the random value chosen by the Requestor. The 659 Requestor expects the Responder to increment this value 660 by one and send this new value of NoncePrime+1 back 661 (encrypted in the MEK) in the KEA-VALIDATE Response. For 662 KEA and the default encryption algorithm these two values 663 together are 40 bytes in length. 665 3.4. EAP KEA-VALIDATE Response Packet 667 The KEA-VALIDATE Response packet is formatted as follows: 669 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 671 This information is formatted in a length-value format. No explicit 672 type field is necessary because all fields are required and are in a 673 determinate order. The last element does not include a length field 674 because its length can be determined from the overall length. The EAP 675 KEA-VALIDATE Response packet has the following overall format: 677 0 1 2 3 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Code | Identifier | Length | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type | Encrypted NoncePrime | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | ...Encrypted NoncePrime... | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | . | 687 . 688 . 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | ...Encrypted NoncePrime... | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | ... | 693 +-+-+-+-+-+-+-+-+ 694 Figure 3.0-3 - EAP KEA-VALIDATE Response Packet format 696 Code 698 2 (Response) 700 Identifier 702 The identifier field is one octet and MUST match the 703 Identifier field from the corresponding request. 705 Length 707 The Length field is two octets and indicates the length 708 of the EAP KEA-VALIDATE Request packet including the 709 Code, Identifier, Length, Type, and Encrypted NoncePrime 710 fields. Octets in the packet outside the range of the 711 Length field should be treated as Data Link Layer padding 712 and should be ignored on reception. 714 Type 716 The Type field in the Response will carry the value 12 717 (KEA-VALIDATE). 719 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 721 Encrypted NoncePrime 723 The value of the Encrypted NoncePrime. This value is 724 formed by the Responder by taking the NoncePrime value 725 which he received in the KEA-VALIDATE request and sending 726 it back encrypted in the same MEK, after being incre- 727 mented by one. This completes the two-way key liveness 728 checks and the Requestor will upon checking this value, 729 proceed to a successful authentication state and sending 730 over a EAP success packet to the peer. 732 4. PPP EAP KEA and KEA-VALIDATE Protocol Processing 734 The operation of the complete PPP KEA protocol, including the two 735 steps of Authentication/Key Generation and Liveness Checking are both 736 show. The first is performed by the PPP KEA protocol and the second 737 by the EAP KEA-VALIDATE protocol. 739 Figure 4.0-1 depicts the operation of the EAP KEA and KEA-VALIDATE 740 protocol. In this and the following figures depicting PDU exchanges, 741 the curly braces ({, }) denote items in Length-Value representation. 743 Side: A B 745 Initiator Recipient 747 =>EAP Request (ID1, KEA, {certA, ra}) 749 <= EAP Response (ID1, 750 KEA, 751 {certB, rb, wMEK, iv, 752 ENCRYPTMEK(eNonce)})) 754 =>EAP Request (ID2, 755 KEA-Validate, 756 { ivPrime,ENCRYPTMEK(eNonce+1,eNoncePrime)}) 758 <= EAP Response (ID2, 759 KEA-Validate, 760 {ENCRYPTMEK(eNoncePrime+1)})) 762 => EAP Success Packet(ID3) 764 Figure 4.0-1 PPP EAP KEA and KEA-VALIDATE Protocol processing 766 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 768 Security Considerations 770 This memo defines a method for using EAP to perform Strong authenti- 771 cation and key generation of/with a peer using the KEA Key Exchange 772 and authentication algorithm. 774 References: 776 [1] Simpson, W. A., 'The Point to Point Protocol 777 (PPP)', July 1994, RFC 1661. 779 [2] Blunk, L. J. & Vollbrecht, J. R., 'PPP Extensible 780 Authentication Protocol (EAP)', June 1996, work in 781 progress. 783 [3] CCITT Recommendation X.509, 'The Directory - 784 Authentication Framework', 1988. 786 [4] Federal Information Processing Standards Publication, FIPS Pub 196, 787 'Entity Authentication using Public Key Cryptography', 788 February 18, 1997. 790 [5] Zmuda, J., 'The PPP Certificate Exchange Protocol', 791 July 1997, work in progress. 793 Acknowledgements: 795 This work is based largely on EAP. The authors would like to thank 796 John Vollbrecht of Merit specifically for his help in understanding 797 the intention of the EAP Internet Draft. The authors would also like 798 to thank Paul Amaranth of Oakland University for his EAP implementa- 799 tion. Thanks also are due to Bill Whelan of Network Express for his 800 Internet Draft showing a worked example of the use of EAP for public 801 key based authentication. And thanks go to Russ Housley for his 802 helpful comments on earlier versions of this memo. And thanks 803 finally to Bill Simpson for the standard PPP spec boilerplate from 804 which we have borrowed heavily. 806 Chair's Address: 808 The working group can be contacted via the current 809 chair: 811 Karl Fox 812 Ascend Communications, Inc. 814 Email: karl@ascend.com 816 DRAFT PPP EAP KEA Public Key Authentication ProtocolNovember 1997 818 Author's Address: 820 Questions about this memo can also be directed to: 822 DIRNSA 823 Attn: X22 (W. Nace) 824 9800 Savage Road 825 Fort Meade, MD 20755-6000 826 USA 828 Phone: +1 410 859-4464 829 Email: WANace@missi.ncsc.mil 831 Peter Yee 832 SPYRUS 833 2460 N. First Street 834 Suite 100 835 San Jose, CA 95131-1023 836 USA 838 Phone: +1 408 432-8180 839 Email: pyee@spyrus.com 841 James E. Zmuda 842 SPYRUS 843 2460 N. First Street 844 Suite 100 845 San Jose, CA 95131-1023 846 USA 848 Phone: +1 408 432-8180 849 Email: jzmuda@spyrus.com