idnits 2.17.1 draft-berrendo-chabanne-pppext-eapmake-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 309 has weird spacing: '...e field will ...' -- 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.) -- The document date (October 31, 2001) is 8212 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2284 (ref. '1') (Obsoleted by RFC 3748) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2459 (ref. '4') (Obsoleted by RFC 3280) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Contribution R. Berrendonner 3 Internet-Draft H. Chabanne 4 Expires: May 1, 2002 SAGEM S.A. 5 October 31, 2001 7 MAKE : Mutual Authentication with Key Exchange 8 draft-berrendo-chabanne-pppext-eapmake-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on May 1, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This memo describes EAP-MAKE protocol, an authentication protocol 40 based on EAP which emphasizes on simplicity and scalability. 41 Authentication is provided through a mechanism derived from the 42 Diffie-Hellman scheme, and it is possible to derive and check a 43 common symmetric key for the purpose of privacy. Scalability is 44 provided by the underlying support of legacy PKI systems. 46 Table of Contents 48 1. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 49 2. PPP EAP MAKE Mutual Authentication Protocol . . . . . . . . . 4 50 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.3 PPP EAP MAKE protocol in a nutshell . . . . . . . . . . . . . 5 53 3. MAKE key derivation scheme . . . . . . . . . . . . . . . . . . 8 54 4. EAP MAKE Packet Format . . . . . . . . . . . . . . . . . . . . 9 55 4.1 EAP MAKE1 Request Packet . . . . . . . . . . . . . . . . . . . 11 56 4.2 EAP MAKE1 Response Packet . . . . . . . . . . . . . . . . . . 12 57 4.3 MAKE2 Request Packet . . . . . . . . . . . . . . . . . . . . . 14 58 4.4 MAKE2 Response Packet . . . . . . . . . . . . . . . . . . . . 16 59 4.5 PPP EAP MAKE and MAKE-VALIDATE Protocol Processing . . . . . . 16 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 64 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 65 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22 67 1. Document Conventions 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119. 73 2. PPP EAP MAKE Mutual Authentication Protocol 75 2.1 Introduction 77 This document describes the PPP EAP MAKE protocol where MAKE stands 78 for Mutual Authentication protocol with Key Exchange. 80 PPP EAP MAKE protocol borrows a lot to "PPP EAP KEA Public Key 81 Authentication Protocol" (see Appendix A), namely : 83 o both protocols are aimed at defining an authentication mechanism 84 within PPP EAP [1] and both permits the creation of a session key 85 for encryption of data on the PPP link, 87 o PPP EAP MAKE protocol takes the two 2-pass EAP request-response of 88 PPP EAP KEA and their format for its own, in the sequel, the first 89 2-pass is called EAP MAKE1 and the second one EAP MAKE2, 91 o the underlying cryptographic property which allows mutual 92 authentication is essentially the same and consists in supplying 93 the prover and the verifier with a private/public Diffie-Hellman 94 key pair. 96 Nevertheless, EAP MAKE protocol has its own specificities which are : 98 o the flow of operations is asymmetric in the sense that there is a 99 prover and a verifier, that prover and verifier do not perform the 100 same computations ; most notably only partial "prover side" 101 forward secrecy is wanted, 103 o the general format of a message of the PPP EAP MAKE protocol is 104 "some data" followed by the HMAC [2] of these data under the 105 common prover/verifier Diffie-Hellman key. 107 2.2 Prerequisites 109 Before describing the PPP EAP MAKE protocol, some elements have to be 110 established. 112 The hypothesis is here made that both have exchanged some data before 113 the use of the PPP EAP MAKE protocol. In particular they MUST agree 114 on a way of identifying each other. For instance,this could be by 115 the ASCII representation of their distinguished name. But some other 116 ways can also be imagined. In the following, the verifier is 117 identified as "A" , the prover as "B" . 119 By certificate, X509 certificate as defined for instance in [4] are 120 here understood. Other choices are possible. In any case, it is 121 assumed that B SHOULD (resp. A MUST) be able to retrieve and check 122 the validity of the certificate of their correspondent. 124 They also agree on a Diffie-Hellman group. In this memo by Diffie- 125 Hellman we understand Diffie-Hellman computations made modulo a big 126 prime. Other choices are possible as working in finite fields of 127 characteristic 2 or over elliptic curves, as suggested in Appendix 6 128 of [6]. In any cases, A and B MUST share the knowledge of the 129 underlying group required for Diffie-Hellmann common key computation. 131 Then they MUST agree on an encryption algorithm, an hash algorithm 132 and an HMAC algorithm. 134 Finally, a counter which provides a basic but efficient anti-replay 135 mechanism is maintained. This counter is incremented at each attempt 136 of identification. The initial value of this counter is 0. In the 137 following, LID stands for the value of this counter. Both A and B 138 MUST store LID. In what follows, LID is 4 bytes long, but this can 139 be easily changed. This value should be sufficient for classical 140 dialin users as well as mobile-ip with periodic authentication 142 2.3 PPP EAP MAKE protocol in a nutshell 144 Let's call this Diffie-Hellman common key between A and B, KDH, p the 145 "big prime" which defines the group where Diffie-Hellman keys are 146 computed, privA (resp. privB)/ pubA (resp. pubB) the private / 147 public Diffie-Hellman key pair of A (resp. of B). 149 We note 151 ENCRYPT(D ; K) the encryption of data D under key K, 153 H(D) the computation of the hash of data D, 155 HMAC(D1, D2, ... , Dn ; K) the computation of the HMAC of 156 concatenated data D1, D2, ..., Dn under key K, 158 p is 128 bytes long. 160 For instance 162 o HMAC is performed using SHA-1 as an hash function. Its output is 163 truncated to 16 bytes [2], 165 o H is computed according to SHA-1 [5], 167 o ENCRYPT corresponds to 3DES E-D-E in CBC mode. 169 MAKE1 Request : 171 o A initiates the protocol by sending to B its identity. 173 MAKE1 Response : 175 o B checks A's certificate validity 177 o B computes KDH 179 o B increments LID and updates its database 181 o B chooses at random r, a private Diffie-Hellman key 183 o B computes R the public key corresponding to r 185 o B computes HMAC(B, LID, R, A ; KDH) 187 o B sends to A : B, LID, R, HMAC(B, LID, R, A ; KDH) 189 MAKE2 Request : 191 o A checks validity of LID, B's certificate 193 o A computes KDH 195 o A checks validity of HMAC(B, LID, R, A ; KDH) 197 o A computes Ks a session key following Section 3, with S = R**privA 198 mod p. 200 o A chooses at random K which is going to encrypt data on the PPP 201 link 203 o A chooses at random n a nonce 205 o A encrypts K under Ks, set 207 K' = ENCRYPT(K ; Ks) 209 o A encrypts n under K, set 211 n' = ENCRYPT(n ; K) 213 o A computes HMAC (B, LID, R, A, K', n' ; KDH) 215 o A sends to B : 217 K', n', HMAC (B, LID, R, A, K', n' ; KDH) 219 MAKE2 Response : 221 o B checks validity of HMAC (B, LID, R, A, K', n' ; KDH) 223 o B computes Ks the same way A does, using S = pubA**r mod p. 225 o B retrieves K and n 227 o B computes H(n) 229 o B sends to A : 231 H(n) 233 Finally : 235 o A checks validity of H(n) 237 o A updates LID (with the value sent by B) 239 3. MAKE key derivation scheme 241 This paragraph describes a method for getting a session key from a 242 given master key. Let's call S the master key, and Ks the session 243 key. The length of Ks depends on the keysize used with the symetric 244 cipher algorithm. For instance, if 3DES is chosen, Ks must be 245 168bits long. If AES is, it may be 128, 192 or 256 bits long. 247 The following computations are done in order to get Ks: 249 o S' = HMAC(LID, KDH ; S) 251 o Ks1 = HMAC(A, B, 1 ; S') 253 o Ks2 = HMAC(A, B, 2 ; Ks1) 255 o ... 257 o KsN = HMAC(A, B, N ; Ks(N-1) 259 o A computes enough KsI to meet the key length requirements for the 260 symetric cipher in use, by concatenating them: Ks = Ks1 | Ks2 | 261 ... | KsN. 263 4. EAP MAKE Packet Format 265 Four packets are exchanged in order to perform a complete 266 authentication, first from A to B, and then from B to A, then 267 repeating that sequence. 269 Both the EAP Response and Request packets for the MAKE1 and MAKE2 270 Subtypes have the format defined in Figure 1. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Code | Identifier | Length | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type | Subtype | Type Data ... 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 1:The PPP EAP packet format 282 Code: 284 1 - Request 286 2 - Response 288 Identifier: 290 The Identifier field is one octet and aids in matching responses 291 with requests. The Identifier MUST be changed for each new 292 Request message sent and MUST NOT be changed on retransmission of 293 a given message. The Identifier in the Response message MUST 294 match the corresponding Request. The verifier MUST discard non- 295 matching Response messages. 297 Length: 299 The Length field is two octets and indicates the length in bytes of 300 the EAP packet including the Code, Identifier, Length, Type, 301 Subtype, and Subtype-Data fields. Octets outside the range of the 302 Length field should be treated as Data Link Layer padding and 303 should be ignored on reception. Truncated packets (with Length 304 greater than the link layer reported length) MUST be silently 305 discarded. 307 Type: 309 The Type field will carry the value xxx (EAP MAKE). The Type field 310 in the Response SHOULD carry the corresponding value unless the 311 peer wishes to send a Nak Type to indicate that it is unable of 312 handling MAKE authentication. 314 Subtype: 316 1 - MAKE1 318 2 - MAKE2 320 The Subtype field is one octet and must contain the value 1 or 2. 321 If any other subtype value is encountered in an EAP MAKE Request 322 message, then the prover SHOULD return an EAP Response with the 323 Type field set to Nak. In EAP MAKE Response messages, the Subtype 324 value MUST be copied from the corresponding Request message. The 325 verifier SHOULD treat unknown Subtype values in Response messages 326 as malformed packets and silently discard. Values from 3 to 255 327 are reserved for futur use.(for instance, for a configuration 328 protocol or a rekeying scheme...). 330 Type Data: 332 The contents and formats of the remainder of the packet differ for 333 each of the four packet types: 335 1. MAKE1 Request, 337 2. MAKE1 Response, 339 3. MAKE2 Request, 341 4. MAKE2 Response. 343 The following sections define the format of the request and response 344 where the information is formatted in a length-value format. No 345 explicit type field is necessary because all fields are required and 346 are in a determinate order. The last element does not include a 347 length field because its length can be determined from the overall 348 length. When a packet is ill-formatted, an EAP failure packet MUST 349 be send. 351 4.1 EAP MAKE1 Request Packet 353 The EAP MAKE1 Request packet has the following overall format: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Code | Identifier | Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | Subtype | ...A's ID... | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 2: EAP MAKE1 Request Packet Format 365 Code: 1 (Request) 367 Identifier: ID1 (random value) 369 Length: length of 371 Code 373 Identifier 375 Length 377 Type 379 Subtype 381 A's Identity 383 Type: xxx (MAKE) 385 Subtype: 1 (MAKE1) 387 A's ID: The identity of the verifier. 389 When receiving a MAKE1 Request, B SHOULD check A's certificate 390 validity. If not valid, B SHOULD send an EAP Failure packet. 392 4.2 EAP MAKE1 Response Packet 394 The EAP MAKE1 Response packet has the following overall format : 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Code | Identifier | Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Subtype | LID length | LID... | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | ...LID... | R length | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | ...R... | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | ... | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | ...R... | B's ID length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | ...B's ID ... | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | ...B's ID ... | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | ... | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | ...HMAC... | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | ... | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | ...HMAC... | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 3: EAP MAKE1 Response Packet Format 426 Code: 2 (Response) 428 Identifier: ID1 (The identifier field MUST match the Identifier field 429 from the corresponding request, i.e. ID1) 431 Length: length of 433 Code 435 Identifier 437 Length 439 Type 440 Subtype 442 LID length 444 LID 446 R length 448 R 450 B's ID length 452 B's ID 454 HMAC 456 Type: xxx (MAKE) 458 Subtype: 1 (MAKE1) 460 LID length: 4 462 LID: actual value of LID (in network byte order). . 464 R length: length in bytes of R. 466 R: is the public key corresponding to r(a private Diffie-Hellman key 467 choosen at random) 469 B's ID length: length of B's ID will vary accordingly to B's ID 470 format. 472 B's ID: B's Identity. If not valid, A MUST send an EAP Failure 473 packet 475 HMAC: HMAC is computed as the HMAC of B, LID, R, A under KDH. 477 On reception of a MAKE1 Response packet, A MUST check that there is 478 an increment with regard to its stored value. A MUST check the 479 validity of B's certificate before computing KDH. If these values 480 are correct, A MUST check the validity of HMAC. In case one or more 481 of these checkings fail, A MUST send an EAP Failure packet. 482 Otherwise, it must send a MAKE2 request packet. 484 4.3 MAKE2 Request Packet 486 The EAP MAKE2 Request packet has the following overall format: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Code | Identifier | Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Type | Subtype | IV length | IVK... | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | ...IVK... | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | ...IVn... | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | ...IVn | K' length | ...K'... | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | ... | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | ...K'... | n' length | n'... | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | ...n'... | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | ... | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | ...n'... | ... HMAC | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | ...HMAC... | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | ... | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | ...HMAC... | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Figure 4: EAP MAKE2 Request Packet Format 520 Code: 1 (Request) 522 Identifier: ID2 (random value) 524 Length: length in bytes of 526 Code 528 Identifier 530 Length 531 Type 533 Subtype 535 IV length 537 IVK 539 IVn 541 K' length 543 K' 545 n' length 547 n' 549 HMAC 551 Type: xxx (MAKE) 553 Subtype: 2 (MAKE2) 555 IV length: we here consider that the encryption of K and n is 556 performed using the same algorithm in the same mode of operation. 557 IV length gives the length of the Initialization Vector for these 558 encryptions 560 IVK: Initialization Vector used to encrypt K choosen at random 562 IVn: Initialization Vector used to encrypt n choosen at random 564 HMAC: HMAC is computed as HMAC of B, LID, R, A, K', n' under KDH. 566 K': K' is the encryption of K under Ks where Ks is defined in Section 567 3, using S = R**privA mod p. 569 n': n' is the encryption of n under K where K is chosen at random. 571 On reception of a MAKE2 Request packet, B MUST check the HMAC. If 572 not valid, B MUST send an EAP Failure packet. Otherwise B computes 573 Ks, as defined in Section 3 with S = pubA**r mod p, retrieves K and 574 n, and computes the hash of n. Then B MUST send an MAKE2 response 575 packet. 577 4.4 MAKE2 Response Packet 579 The EAP MAKE2 Response packet has the following overall format: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Code | Identifier | Length | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Type | Subtype | H... | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | ... | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | ...H... | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Figure 5: EAP MAKE2 Response Packet Format 595 Code: 2 (Response) 597 Identifier: ID2 (The identifier field MUST match the Identifier field 598 from the corresponding request, i.e. ID2) 600 Length: length in bytes of 602 Code 604 Identifier 606 Length 608 Type 610 H 612 Type: xxx (MAKE) 614 Subtype: 2 (MAKE2) 616 H: H is the hash of n 618 On reception of MAKE2 Response, A MUST check this hash. If not 619 valid, A MUST send an EAP Failure packet. 621 4.5 PPP EAP MAKE and MAKE-VALIDATE Protocol Processing 623 Figure 6 depicts the operation of the EAP MAKE and MAKE-VALIDATE 624 protocol. In this figure depicting PDU exchanges, the curly braces 625 ({, }) denote items in Length-Value representation. 627 A B 629 => EAP Request (ID1, 630 MAKE, 631 MAKE1, 632 {A}) 634 <= EAP Response (ID1, 635 MAKE, 636 MAKE1, 637 {B, LID, R, HMAC}) 639 => EAP Request (ID2, 640 MAKE, 641 MAKE2, 642 {IVK, IVn, K', n', HMAC}) 644 <= EAP Response (ID2, 645 MAKE, 646 MAKE2 647 {H(n)}) 649 => EAP Success Packet(ID3) 651 Figure 6: PPP EAP MAKE and MAKE-VALIDATE Protocol processing 653 5. Security Considerations 655 When the verifier A is a server from which the prover B is the 656 client, A has some advantages to secure its database in 657 confidentiality too, allowing the storage of pre-computed KDH. Doing 658 so, some Denial of Service attacks should be more difficult to 659 achieve. Note also that besides its anti-replay role, the counter 660 LID may avoid to the verifier some extras computations against a 661 malevolent prover. 663 It should be noted that the HMAC computation is performed over data 664 in plaintext as well as in encrypted format (see [3] for a treatment 665 of this subject). 667 Finally, please note that most prover's computations might be carried 668 out off-line. This is especially true when the verifier is known. 670 6. IANA Considerations 672 In this memo, xxx should be substituted with whatever value IANA will 673 assign to MAKE. 675 References 677 [1] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 678 Protocol (EAP)", RFC 2284, March 1998. 680 [2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC : Keyed-Hashing 681 for Message Authentication", RFC 2104, February 1997. 683 [3] Bellare, M. and C. Mamprempre, "Authenticated encryption : 684 Relations among notions and analysis of the generic composition 685 paradigm", September 2000. 687 [4] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 688 Public Key Infrastructure Certificate and CRL Profile", RFC 689 2459, January 1999. 691 [5] NIST, "FIPS PUB 180-1: Secure Hash Standard", FIPS PUB 180-1, 692 April 1995. 694 [6] NIST, "FIPS PUB 186-2: Digital Signature Standard (DSS)", FIPS 695 PUB 186-2, January 2000. 697 Authors' Addresses 699 Romain Berrendonner 700 SAGEM S.A. 701 Avenue du Gros-Chene 702 Eragny-sur-Oise 95610 703 France 705 Phone: +33 1 34 30 37 15 706 EMail: romain.berrendonner@sagem.com 708 Herve Chabanne 709 SAGEM S.A. 710 Avenue du Gros-Chene 711 Eragny-sur-Oise 95610 712 France 714 Phone: +33 1 34 30 37 30 715 EMail: herve.chabanne@sagem.com 717 Appendix A. Acknowledgments 719 The authors wish to express their gratitude to W. Nace, P. Yee, J. 720 Zmuda for their stimulating work " PPP EAP KEA Public Key 721 Authentication Protocol " , which appears as an Internet Draft in 722 November 1997. This memo shares more than a simple resemblance with 723 their work. 725 They also want to thank warmly S. Tramoni for her fruitful 726 contributions to the subject and her implementation of MAKE. 728 Full Copyright Statement 730 Copyright (C) The Internet Society (2001). All Rights Reserved. 732 This document and translations of it may be copied and furnished to 733 others, and derivative works that comment on or otherwise explain it 734 or assist in its implementation may be prepared, copied, published 735 and distributed, in whole or in part, without restriction of any 736 kind, provided that the above copyright notice and this paragraph are 737 included on all such copies and derivative works. However, this 738 document itself may not be modified in any way, such as by removing 739 the copyright notice or references to the Internet Society or other 740 Internet organizations, except as needed for the purpose of 741 developing Internet standards in which case the procedures for 742 copyrights defined in the Internet Standards process must be 743 followed, or as required to translate it into languages other than 744 English. 746 The limited permissions granted above are perpetual and will not be 747 revoked by the Internet Society or its successors or assigns. 749 This document and the information contained herein is provided on an 750 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 751 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 752 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 753 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 754 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 756 Acknowledgement 758 Funding for the RFC Editor function is currently provided by the 759 Internet Society.