Individual Contribution R. Berrendonner Internet-Draft H. Chabanne Expires: May 1, 2002 SAGEM S.A. October 31, 2001 MAKE : Mutual Authentication with Key Exchange draft-berrendo-chabanne-pppext-eapmake-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 1, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes EAP-MAKE protocol, an authentication protocol based on EAP which emphasizes on simplicity and scalability. Authentication is provided through a mechanism derived from the Diffie-Hellman scheme, and it is possible to derive and check a common symmetric key for the purpose of privacy. Scalability is provided by the underlying support of legacy PKI systems. Berrendonner & Chabanne Expires May 1, 2002 [Page 1] Internet-Draft MAKE October 2001 Table of Contents 1. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 2. PPP EAP MAKE Mutual Authentication Protocol . . . . . . . . . 4 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 PPP EAP MAKE protocol in a nutshell . . . . . . . . . . . . . 5 3. MAKE key derivation scheme . . . . . . . . . . . . . . . . . . 8 4. EAP MAKE Packet Format . . . . . . . . . . . . . . . . . . . . 9 4.1 EAP MAKE1 Request Packet . . . . . . . . . . . . . . . . . . . 11 4.2 EAP MAKE1 Response Packet . . . . . . . . . . . . . . . . . . 12 4.3 MAKE2 Request Packet . . . . . . . . . . . . . . . . . . . . . 14 4.4 MAKE2 Response Packet . . . . . . . . . . . . . . . . . . . . 16 4.5 PPP EAP MAKE and MAKE-VALIDATE Protocol Processing . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22 Berrendonner & Chabanne Expires May 1, 2002 [Page 2] Internet-Draft MAKE October 2001 1. Document Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Berrendonner & Chabanne Expires May 1, 2002 [Page 3] Internet-Draft MAKE October 2001 2. PPP EAP MAKE Mutual Authentication Protocol 2.1 Introduction This document describes the PPP EAP MAKE protocol where MAKE stands for Mutual Authentication protocol with Key Exchange. PPP EAP MAKE protocol borrows a lot to "PPP EAP KEA Public Key Authentication Protocol" (see Appendix A), namely : o both protocols are aimed at defining an authentication mechanism within PPP EAP [1] and both permits the creation of a session key for encryption of data on the PPP link, o PPP EAP MAKE protocol takes the two 2-pass EAP request-response of PPP EAP KEA and their format for its own, in the sequel, the first 2-pass is called EAP MAKE1 and the second one EAP MAKE2, o the underlying cryptographic property which allows mutual authentication is essentially the same and consists in supplying the prover and the verifier with a private/public Diffie-Hellman key pair. Nevertheless, EAP MAKE protocol has its own specificities which are : o the flow of operations is asymmetric in the sense that there is a prover and a verifier, that prover and verifier do not perform the same computations ; most notably only partial "prover side" forward secrecy is wanted, o the general format of a message of the PPP EAP MAKE protocol is "some data" followed by the HMAC [2] of these data under the common prover/verifier Diffie-Hellman key. 2.2 Prerequisites Before describing the PPP EAP MAKE protocol, some elements have to be established. The hypothesis is here made that both have exchanged some data before the use of the PPP EAP MAKE protocol. In particular they MUST agree on a way of identifying each other. For instance,this could be by the ASCII representation of their distinguished name. But some other ways can also be imagined. In the following, the verifier is identified as "A" , the prover as "B" . By certificate, X509 certificate as defined for instance in [4] are Berrendonner & Chabanne Expires May 1, 2002 [Page 4] Internet-Draft MAKE October 2001 here understood. Other choices are possible. In any case, it is assumed that B SHOULD (resp. A MUST) be able to retrieve and check the validity of the certificate of their correspondent. They also agree on a Diffie-Hellman group. In this memo by Diffie- Hellman we understand Diffie-Hellman computations made modulo a big prime. Other choices are possible as working in finite fields of characteristic 2 or over elliptic curves, as suggested in Appendix 6 of [6]. In any cases, A and B MUST share the knowledge of the underlying group required for Diffie-Hellmann common key computation. Then they MUST agree on an encryption algorithm, an hash algorithm and an HMAC algorithm. Finally, a counter which provides a basic but efficient anti-replay mechanism is maintained. This counter is incremented at each attempt of identification. The initial value of this counter is 0. In the following, LID stands for the value of this counter. Both A and B MUST store LID. In what follows, LID is 4 bytes long, but this can be easily changed. This value should be sufficient for classical dialin users as well as mobile-ip with periodic authentication 2.3 PPP EAP MAKE protocol in a nutshell Let's call this Diffie-Hellman common key between A and B, KDH, p the "big prime" which defines the group where Diffie-Hellman keys are computed, privA (resp. privB)/ pubA (resp. pubB) the private / public Diffie-Hellman key pair of A (resp. of B). We note ENCRYPT(D ; K) the encryption of data D under key K, H(D) the computation of the hash of data D, HMAC(D1, D2, ... , Dn ; K) the computation of the HMAC of concatenated data D1, D2, ..., Dn under key K, p is 128 bytes long. For instance o HMAC is performed using SHA-1 as an hash function. Its output is truncated to 16 bytes [2], o H is computed according to SHA-1 [5], o ENCRYPT corresponds to 3DES E-D-E in CBC mode. Berrendonner & Chabanne Expires May 1, 2002 [Page 5] Internet-Draft MAKE October 2001 MAKE1 Request : o A initiates the protocol by sending to B its identity. MAKE1 Response : o B checks A's certificate validity o B computes KDH o B increments LID and updates its database o B chooses at random r, a private Diffie-Hellman key o B computes R the public key corresponding to r o B computes HMAC(B, LID, R, A ; KDH) o B sends to A : B, LID, R, HMAC(B, LID, R, A ; KDH) MAKE2 Request : o A checks validity of LID, B's certificate o A computes KDH o A checks validity of HMAC(B, LID, R, A ; KDH) o A computes Ks a session key following Section 3, with S = R**privA mod p. o A chooses at random K which is going to encrypt data on the PPP link o A chooses at random n a nonce o A encrypts K under Ks, set K' = ENCRYPT(K ; Ks) o A encrypts n under K, set n' = ENCRYPT(n ; K) o A computes HMAC (B, LID, R, A, K', n' ; KDH) o A sends to B : Berrendonner & Chabanne Expires May 1, 2002 [Page 6] Internet-Draft MAKE October 2001 K', n', HMAC (B, LID, R, A, K', n' ; KDH) MAKE2 Response : o B checks validity of HMAC (B, LID, R, A, K', n' ; KDH) o B computes Ks the same way A does, using S = pubA**r mod p. o B retrieves K and n o B computes H(n) o B sends to A : H(n) Finally : o A checks validity of H(n) o A updates LID (with the value sent by B) Berrendonner & Chabanne Expires May 1, 2002 [Page 7] Internet-Draft MAKE October 2001 3. MAKE key derivation scheme This paragraph describes a method for getting a session key from a given master key. Let's call S the master key, and Ks the session key. The length of Ks depends on the keysize used with the symetric cipher algorithm. For instance, if 3DES is chosen, Ks must be 168bits long. If AES is, it may be 128, 192 or 256 bits long. The following computations are done in order to get Ks: o S' = HMAC(LID, KDH ; S) o Ks1 = HMAC(A, B, 1 ; S') o Ks2 = HMAC(A, B, 2 ; Ks1) o ... o KsN = HMAC(A, B, N ; Ks(N-1) o A computes enough KsI to meet the key length requirements for the symetric cipher in use, by concatenating them: Ks = Ks1 | Ks2 | ... | KsN. Berrendonner & Chabanne Expires May 1, 2002 [Page 8] Internet-Draft MAKE October 2001 4. EAP MAKE Packet Format Four packets are exchanged in order to perform a complete authentication, first from A to B, and then from B to A, then repeating that sequence. Both the EAP Response and Request packets for the MAKE1 and MAKE2 Subtypes have the format defined in Figure 1. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Type Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1:The PPP EAP packet format Code: 1 - Request 2 - Response Identifier: The Identifier field is one octet and aids in matching responses with requests. The Identifier MUST be changed for each new Request message sent and MUST NOT be changed on retransmission of a given message. The Identifier in the Response message MUST match the corresponding Request. The verifier MUST discard non- matching Response messages. Length: The Length field is two octets and indicates the length in bytes of the EAP packet including the Code, Identifier, Length, Type, Subtype, and Subtype-Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Truncated packets (with Length greater than the link layer reported length) MUST be silently discarded. Type: The Type field will carry the value xxx (EAP MAKE). The Type field in the Response SHOULD carry the corresponding value unless the Berrendonner & Chabanne Expires May 1, 2002 [Page 9] Internet-Draft MAKE October 2001 peer wishes to send a Nak Type to indicate that it is unable of handling MAKE authentication. Subtype: 1 - MAKE1 2 - MAKE2 The Subtype field is one octet and must contain the value 1 or 2. If any other subtype value is encountered in an EAP MAKE Request message, then the prover SHOULD return an EAP Response with the Type field set to Nak. In EAP MAKE Response messages, the Subtype value MUST be copied from the corresponding Request message. The verifier SHOULD treat unknown Subtype values in Response messages as malformed packets and silently discard. Values from 3 to 255 are reserved for futur use.(for instance, for a configuration protocol or a rekeying scheme...). Type Data: The contents and formats of the remainder of the packet differ for each of the four packet types: 1. MAKE1 Request, 2. MAKE1 Response, 3. MAKE2 Request, 4. MAKE2 Response. The following sections define the format of the request and response where the information is formatted in a length-value format. No explicit type field is necessary because all fields are required and are in a determinate order. The last element does not include a length field because its length can be determined from the overall length. When a packet is ill-formatted, an EAP failure packet MUST be send. Berrendonner & Chabanne Expires May 1, 2002 [Page 10] Internet-Draft MAKE October 2001 4.1 EAP MAKE1 Request Packet The EAP MAKE1 Request packet has the following overall format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | ...A's ID... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: EAP MAKE1 Request Packet Format Code: 1 (Request) Identifier: ID1 (random value) Length: length of Code Identifier Length Type Subtype A's Identity Type: xxx (MAKE) Subtype: 1 (MAKE1) A's ID: The identity of the verifier. When receiving a MAKE1 Request, B SHOULD check A's certificate validity. If not valid, B SHOULD send an EAP Failure packet. Berrendonner & Chabanne Expires May 1, 2002 [Page 11] Internet-Draft MAKE October 2001 4.2 EAP MAKE1 Response Packet The EAP MAKE1 Response packet has the following overall format : 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | LID length | LID... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...LID... | R length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...R... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...R... | B's ID length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...B's ID ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...B's ID ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...HMAC... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...HMAC... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: EAP MAKE1 Response Packet Format Code: 2 (Response) Identifier: ID1 (The identifier field MUST match the Identifier field from the corresponding request, i.e. ID1) Length: length of Code Identifier Length Type Berrendonner & Chabanne Expires May 1, 2002 [Page 12] Internet-Draft MAKE October 2001 Subtype LID length LID R length R B's ID length B's ID HMAC Type: xxx (MAKE) Subtype: 1 (MAKE1) LID length: 4 LID: actual value of LID (in network byte order). . R length: length in bytes of R. R: is the public key corresponding to r(a private Diffie-Hellman key choosen at random) B's ID length: length of B's ID will vary accordingly to B's ID format. B's ID: B's Identity. If not valid, A MUST send an EAP Failure packet HMAC: HMAC is computed as the HMAC of B, LID, R, A under KDH. On reception of a MAKE1 Response packet, A MUST check that there is an increment with regard to its stored value. A MUST check the validity of B's certificate before computing KDH. If these values are correct, A MUST check the validity of HMAC. In case one or more of these checkings fail, A MUST send an EAP Failure packet. Otherwise, it must send a MAKE2 request packet. Berrendonner & Chabanne Expires May 1, 2002 [Page 13] Internet-Draft MAKE October 2001 4.3 MAKE2 Request Packet The EAP MAKE2 Request packet has the following overall format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | IV length | IVK... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...IVK... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...IVn... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...IVn | K' length | ...K'... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...K'... | n' length | n'... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...n'... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...n'... | ... HMAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...HMAC... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...HMAC... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: EAP MAKE2 Request Packet Format Code: 1 (Request) Identifier: ID2 (random value) Length: length in bytes of Code Identifier Length Berrendonner & Chabanne Expires May 1, 2002 [Page 14] Internet-Draft MAKE October 2001 Type Subtype IV length IVK IVn K' length K' n' length n' HMAC Type: xxx (MAKE) Subtype: 2 (MAKE2) IV length: we here consider that the encryption of K and n is performed using the same algorithm in the same mode of operation. IV length gives the length of the Initialization Vector for these encryptions IVK: Initialization Vector used to encrypt K choosen at random IVn: Initialization Vector used to encrypt n choosen at random HMAC: HMAC is computed as HMAC of B, LID, R, A, K', n' under KDH. K': K' is the encryption of K under Ks where Ks is defined in Section 3, using S = R**privA mod p. n': n' is the encryption of n under K where K is chosen at random. On reception of a MAKE2 Request packet, B MUST check the HMAC. If not valid, B MUST send an EAP Failure packet. Otherwise B computes Ks, as defined in Section 3 with S = pubA**r mod p, retrieves K and n, and computes the hash of n. Then B MUST send an MAKE2 response packet. Berrendonner & Chabanne Expires May 1, 2002 [Page 15] Internet-Draft MAKE October 2001 4.4 MAKE2 Response Packet The EAP MAKE2 Response packet has the following overall format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | H... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...H... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: EAP MAKE2 Response Packet Format Code: 2 (Response) Identifier: ID2 (The identifier field MUST match the Identifier field from the corresponding request, i.e. ID2) Length: length in bytes of Code Identifier Length Type H Type: xxx (MAKE) Subtype: 2 (MAKE2) H: H is the hash of n On reception of MAKE2 Response, A MUST check this hash. If not valid, A MUST send an EAP Failure packet. 4.5 PPP EAP MAKE and MAKE-VALIDATE Protocol Processing Figure 6 depicts the operation of the EAP MAKE and MAKE-VALIDATE protocol. In this figure depicting PDU exchanges, the curly braces Berrendonner & Chabanne Expires May 1, 2002 [Page 16] Internet-Draft MAKE October 2001 ({, }) denote items in Length-Value representation. A B => EAP Request (ID1, MAKE, MAKE1, {A}) <= EAP Response (ID1, MAKE, MAKE1, {B, LID, R, HMAC}) => EAP Request (ID2, MAKE, MAKE2, {IVK, IVn, K', n', HMAC}) <= EAP Response (ID2, MAKE, MAKE2 {H(n)}) => EAP Success Packet(ID3) Figure 6: PPP EAP MAKE and MAKE-VALIDATE Protocol processing Berrendonner & Chabanne Expires May 1, 2002 [Page 17] Internet-Draft MAKE October 2001 5. Security Considerations When the verifier A is a server from which the prover B is the client, A has some advantages to secure its database in confidentiality too, allowing the storage of pre-computed KDH. Doing so, some Denial of Service attacks should be more difficult to achieve. Note also that besides its anti-replay role, the counter LID may avoid to the verifier some extras computations against a malevolent prover. It should be noted that the HMAC computation is performed over data in plaintext as well as in encrypted format (see [3] for a treatment of this subject). Finally, please note that most prover's computations might be carried out off-line. This is especially true when the verifier is known. Berrendonner & Chabanne Expires May 1, 2002 [Page 18] Internet-Draft MAKE October 2001 6. IANA Considerations In this memo, xxx should be substituted with whatever value IANA will assign to MAKE. Berrendonner & Chabanne Expires May 1, 2002 [Page 19] Internet-Draft MAKE October 2001 References [1] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC : Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [3] Bellare, M. and C. Mamprempre, "Authenticated encryption : Relations among notions and analysis of the generic composition paradigm", September 2000. [4] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. [5] NIST, "FIPS PUB 180-1: Secure Hash Standard", FIPS PUB 180-1, April 1995. [6] NIST, "FIPS PUB 186-2: Digital Signature Standard (DSS)", FIPS PUB 186-2, January 2000. Authors' Addresses Romain Berrendonner SAGEM S.A. Avenue du Gros-Chene Eragny-sur-Oise 95610 France Phone: +33 1 34 30 37 15 EMail: romain.berrendonner@sagem.com Herve Chabanne SAGEM S.A. Avenue du Gros-Chene Eragny-sur-Oise 95610 France Phone: +33 1 34 30 37 30 EMail: herve.chabanne@sagem.com Berrendonner & Chabanne Expires May 1, 2002 [Page 20] Internet-Draft MAKE October 2001 Appendix A. Acknowledgments The authors wish to express their gratitude to W. Nace, P. Yee, J. Zmuda for their stimulating work " PPP EAP KEA Public Key Authentication Protocol " , which appears as an Internet Draft in November 1997. This memo shares more than a simple resemblance with their work. They also want to thank warmly S. Tramoni for her fruitful contributions to the subject and her implementation of MAKE. Berrendonner & Chabanne Expires May 1, 2002 [Page 21] Internet-Draft MAKE October 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Berrendonner & Chabanne Expires May 1, 2002 [Page 22]