Internet Draft Romain Berrendonner (SAGEM SA) expires in six months Herve Chabanne (SAGEM SA) September 17, 2001 Expires March 2002 PPP EAP MAKE Mutual Authentication Protocol Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the authors do not provide the IETF with any right other than to publish as an Internet-Draft. 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. 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. 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. 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 Acknowledgments), namely : - both protocols are aimed to define an authentication mechanism within PPP EAP [1] and both permits the creation of a session key for encryption of data on the PPP link, - 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, - 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 : - 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, - 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 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 here understood. Other choices are possible. In any cases, 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. 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. 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 write - ENCRYPT(D ; K) for the encryption of data D under key K, - H(D) for the computation of the hash of data D, - HMAC(D1, D2, ... , Dn ; K) for the computation of the HMAC of concatenated data D1, D2, ..., Dn under key K. To make things completely clear, let say that - p is 128 bytes long, - HMAC is performed using SHA-1 as an hash function. Its output is truncated to 16 bytes [2], - H is computed according to SHA-1. [5], - ENCRYPT corresponds to 3DES E-D-E in CBC mode. MAKE1 Request : - A initiates the protocol by sending to B its identity. MAKE1 Response : - B checks A's certificate validity - B computes KDH - B increments LID - B chooses at random r, a private Diffie-Hellman key - B computes R the public key corresponding to r - B computes HMAC(B, LID, R, A ; KDH) - B sends to A : B, LID, R, HMAC(B, LID, R, A ; KDH) MAKE2 Request : - A checks validity of LID, B's certificate - A computes KDH - A checks validity of HMAC(B, LID, R, A ; KDH) - A computes KS a session key as Ks = HMAC(A, B, LID, KDH ; R**privA mod p) - A chooses at random K which is going to encrypt data on the PPP link - A chooses at random n a nonce - A encrypts K under Ks, set K' = ENCRYPT(K ; Ks) - A encrypts n under K, set n' = ENCRYPT(n ; K) - A computes HMAC (A, B, LID, K', n' ; KDH) - A sends to B : K', n', HMAC (B, LID, R, A, K', n' ; KDH) MAKE2 Response : - B checks validity of HMAC (B, LID, R, A, K', n' ; KDH) - B computes Ks = HMAC(A, B, LID, KDH ; pubA**r mod p) - B retrieves K and n - B computes H(n) - B sends to A : H(n) Finally : - A checks validity of H(n) - A updates LID Figure 1 : General description of EAP MAKE Protocol 3. EAP MAKE Packet Format Four packets are exchanged in order to perform the 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 Subtype have the following 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 | Type Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 : 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 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 21 (EAP MAKE). The Type field in the Response SHOULD carry the corresponding value unless the peer wishes to send a Nak Type to indicate that it is incapable of handling MAKE authentication. Subtype 1 - MAKE1 2 - MAKE2 The Subtype field is one octet and must contain the value 1, 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. Subtype 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. 3.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 3 : EAP MAKE1 Request Packet Format Code : 1 (Request) Identifier : ID1 (random value) Length : length of Code Identifier Length Type Subtype A's Identity Type : 21 (MAKE) Subtype : 1 (MAKE1) A's ID : B SHOULD check A's certificate validity. If not valid, B SHOULD send an EAP Failure packet. 3.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 4 : 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 in bytes of Code Identifier Length Type Subtype LID length LID R length R B's ID length B's ID HMAC Type : 21 (MAKE) Subtype : 1 (MAKE1) LID length : 4 LID : actual value of LID, A MUST check that there is an increment with regard to its stored value. If not if MUST send an EAP Failure packet. B's ID length : length of B's ID will vary accordingly to B's ID format. B's ID : A MUST check B's certificate validity. If not valid, A MUST send an EAP Failure packet. HMAC : A MUST check HMAC. If not valid, A MUST send an EAP Failure packet. 3.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IVn | K' length | ...K'... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...K'... | n' length | n'... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...n'... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...n'... | ... HMAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...HMAC... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...HMAC... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 : EAP MAKE2 Request Packet Format Code : 1 (Request) Identifier : ID2 (random value) Length : length in bytes of Code Identifier Length Type Subtype IV length IVK IVn K' length K' n' length n' HMAC Type : 21 (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 IVn : Initialization Vector used to encrypt n HMAC : B MUST check HMAC. If not valid, B MUST send an EAP Failure packet. 3.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 6 : 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 : 25 length in bytes of Code Identifier Length Type H Type : 21 (MAKE) Subtype : 2 (MAKE2) H : A MUST check HMAC. If not valid, A MUST send an EAP Failure packet. 3.5. PPP EAP MAKE and MAKE-VALIDATE Protocol Processing Figure 7 depicts the operation of the EAP MAKE and MAKE-VALIDATE protocol. In this figure depicting PDU exchanges, the curly braces ({, }) denote items in Length-Value representation. A B => EAP Request (ID1, MAKE, MAKE1, {A}) <= EAP Response (ID1, MAKE, MAKE1, {LID, R, B, HMAC}) => EAP Request (ID2, MAKE, MAKE2, {IVK, IVn, K', n', HMAC}) <= EAP Response (ID2, MAKE, MAKE2 {H(n)}) => EAP Success Packet(ID3) Figure 7 : PPP EAP MAKE and MAKE-VALIDATE Protocol processing 4. 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. References: [1] " PPP Extensible Authentication Protocol (EAP) " L. Blunk, J.Vollbrecht, RFC 2284, March 1998 [2] " HMAC : Keyed-Hashing for Message Authentication " H. Krawczyk, M. Bellare, R. Canetti, RFC 2401, February 1997 [3] " Authenticated encryption : Relations among notions and analysis of the generic composition paradigm " (full version) M. Bellare, C. Mamprempre, September 2000 [4] "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", R. Housley, W. Ford, W. Polk, D. Solo, RFC 2459, January 1999 [5] "FIPS PUB 180-1: Secure Hash Standard" NIST, April 1995 Acknowledgments: 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. Author's Address: Romain Berrendonner SAGEM SA Centre de recherches d'Eragny Avenue du Gros-Chene F-95610 ERAGNY Romain.Berrendonner@SAGEM.com Herve Chabanne SAGEM SA Centre de recherches d'Eragny Avenue du Gros-Chene F-95610 ERAGNY Herve.Chabanne@SAGEM.com