Network Working Group T. Clancy Internet-Draft W. Arbaugh Expires: December 30, 2004 University of Maryland July 2004 EAP Password Authenticated Exchange draft-clancy-eap-pax-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This Internet Draft defines a provably secure Extensible Authentication Protocol method called EAP-PAX. This method is designed for bootstrapping a shared key-based authentication protocol with a weak preshared password or PIN. It includes key management features, is secure against dictionary attacks, includes optional support for identity protection, and avoids intellectual property rights associated with competing EAP methods. EAP-PAX consists of two different authentication protocols: PAX_STD Clancy & Arbaugh Expires December 30, 2004 [Page 1] Internet-Draft EAP-PAX July 2004 and PAX_IDP. PAX_STD is a simple mutual authentication and key derivation protocol capable of deriving session keys and new authentication keys. PAX_IDP is a variant that additionally provides identity protection, and requires a server-side certificate. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Language Requirements . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 PAX_STD Protocol . . . . . . . . . . . . . . . . . . . . . 7 2.2 PAX_IDP Protocol . . . . . . . . . . . . . . . . . . . . . 7 2.3 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Verification Requirements . . . . . . . . . . . . . . . . 8 2.5 PAX Key Derivation Function . . . . . . . . . . . . . . . 9 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 9 3.1 Header Specification . . . . . . . . . . . . . . . . . . . 10 3.1.1 Op-Code . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3 MAC ID . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.4 DH Group ID . . . . . . . . . . . . . . . . . . . . . 12 3.1.5 Public Key ID . . . . . . . . . . . . . . . . . . . . 12 3.1.6 Sequence Number . . . . . . . . . . . . . . . . . . . 12 3.2 Payload Formatting . . . . . . . . . . . . . . . . . . . . 12 3.3 Integrity Check Value (ICV) . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . 15 4.1 Server Certificates . . . . . . . . . . . . . . . . . . . 15 4.2 Server Security . . . . . . . . . . . . . . . . . . . . . 17 4.3 EAP Security Claims . . . . . . . . . . . . . . . . . . . 17 4.3.1 Protected Ciphersuite Negotiation . . . . . . . . . . 17 4.3.2 Mutual Authentication . . . . . . . . . . . . . . . . 17 4.3.3 Integrity Protection . . . . . . . . . . . . . . . . . 18 4.3.4 Replay Protection . . . . . . . . . . . . . . . . . . 18 4.3.5 Confidentiality . . . . . . . . . . . . . . . . . . . 18 4.3.6 Key Derivation . . . . . . . . . . . . . . . . . . . . 18 4.3.7 Key Strength . . . . . . . . . . . . . . . . . . . . . 18 4.3.8 Dictionary Attack Resistance . . . . . . . . . . . . . 18 4.3.9 Fast Reconnect . . . . . . . . . . . . . . . . . . . . 18 4.3.10 Session Independence . . . . . . . . . . . . . . . . 19 4.3.11 Fragmentation . . . . . . . . . . . . . . . . . . . 19 4.3.12 Channel Binding . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 7.2 Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 Clancy & Arbaugh Expires December 30, 2004 [Page 2] Internet-Draft EAP-PAX July 2004 A. Implementation Suggestions . . . . . . . . . . . . . . . . . 22 A.1 WiFi Enterprise Network . . . . . . . . . . . . . . . . . 23 A.2 Mobile Phone Network . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . 25 Clancy & Arbaugh Expires December 30, 2004 [Page 3] Internet-Draft EAP-PAX July 2004 1. Introduction EAP-PAX, or Extensible Authentication Protocol, Password Authenticated eXchange, is a secure EAP method designed for authentication using a shared key. It provides a provisioning mechanism suitable for deriving a strong authentication key from a weak preshared key. Two separate protocols, PAX_STD and PAX_IDP, are defined, with the distinguishing characteristic being that PAX_IDP supports identity protection and requires a server-side certificate. Both techniques have been optimized for minimal client-side complexity. The idea motivating EAP-PAX is a desire for device authentication bootstrapped by a simple personal identification number (PIN). If a weak key is used or a expiration period has lapsed, the authentication server forces a key update. During a key update, rather than using a hash-based key exchange, the client and server perform a Diffie-Hellman key exchange which provides forward secrecy. While the preferred mode of operation is for the server to have a certificate it can supply to the client when a weak key is being used, the protocol supports a purely symmetric-key mode of operation when identity protection is not required. However, in this mode the protocol is vulnerable to an active man-in-the-middle off-line dictionary attack during the initial key update, if a weak key generated from a provisioned password or PIN is being used. When all the suggested security options are enabled, EAP-PAX is provably secure under the Random Oracle model. EAP-PAX includes built-in key management features, resistance to dictionary attacks, and avoids intellectual property issues associated with protocols such as EKE [BM92], SPEKE [Jab96], and SRP [RFC2945]. EAP-PAX is ideal for wireless environments such as IEEE 802.11 [IEEE.80211]. 1.1 Language Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119]. 1.2 Terminology This section describes the various variables and functions used in the PAX protocol. They will be referenced frequently in later sections. Clancy & Arbaugh Expires December 30, 2004 [Page 4] Internet-Draft EAP-PAX July 2004 Variables: g public Diffie-Hellman generator, typically 2 X, M 256-bit random integer generated by the server Y, N 256-bit random integer generated by the client CID EAP client NAI [RFC2486] SID EAP server NAI [RFC2486] Keys: PK EAP server's public key CertPK EAP server's certificate for public key PK AK authentication key shared between the client and EAP server AK' new authentication key generated during a key update MK Master Key shared between the client and EAP server from which all other EAP method session keys are derived CK Confirmation Key generated from the MK and used during authentication to prove knowledge of AK MSK Master Session Key generated from the MK and exported by the EAP method to the authenticator EMSK Extended Master Session Key also generated from the MK and contains additional keying material IV Initialization Vector used to seed ciphers; exported to the authenticator Operations: enc_X(Y) encryption of message Y with public key X MAC_X(Y) keyed message authentication code computed over message Y with symmetric key X Clancy & Arbaugh Expires December 30, 2004 [Page 5] Internet-Draft EAP-PAX July 2004 PAX-KDF-W(X, Y, Z) PAX Key Derivation Function computed using secret X, identifier Y, and seed Z, and producing W octets of output; defined in section 2.5 || string or binary data concatenation 2. Overview The EAP framework [RFC3748] defines four basic steps that occur during the execution of an EAP conversation between client and server. The first phase, discovery, is handled by the underlying MAC protocol. The authentication phase is defined here. The key distribution and secure association are handled differently depending on the link layer protocol, and are not discussed in this document. +--------+ +---------+ | | EAP-Request/Identity | | | CLIENT |<------------------------------------| SERVER | | | | | | | EAP-Response/Identity | | | |------------------------------------>| | | | | | | | PAX_STD or PAX_IDP | | | |<------------------------------------| | | |------------------------------------>| | | |<------------------------------------| | | |------------------------------------>| | | | | | | | EAP Success | | | |<------------------------------------| | | | | | +--------+ +---------+ As mentioned earlier, there are two distinct protocols that can be executed. The first, PAX_STD, is used when identity protection is not required. The second, PAX_IDP provides this protection. Each protocol has two modes of operation. When an AK update is being performed, the client and server exchange g^X and g^Y. When no update is being performed, and only session keys are being derived, X and Y are exchanged. Using Diffie-Hellman during the key update provides forward secrecy, and secure key derivation when a weak provisioned key is used. The main difference between the protocols is that PAX_IDP requires a server-side certificate. For every authentication, the client is required to compute a public-key encryption. PAX_STD on the other Clancy & Arbaugh Expires December 30, 2004 [Page 6] Internet-Draft EAP-PAX July 2004 hand can be accomplished using purely symmetric operations, provided a key update is not being performed. Each of the protocols are now defined. 2.1 PAX_STD Protocol In the PAX_STD protocol, is a simple nonce-based authentication. The client and server each exchange 256 bits of random data which is used to seed the PAX-KDF for generation of session keys. The randomly exchanged data in the protocol differs depending on whether a key update is being performed. If no key update is being performed, then let: o A = X (256-bit random value) o B = Y (256-bit random value) o E = X || Y (512-bit concatenation) To provide forward secrecy and security when a weak key is used, let the following be true when a key update is being performed: o A = g^X o B = g^Y o E = g^(XY) The full protocol, when server-side certificates are used is as follows: o PAX_STD-1 : client <- server : A, SID, PK, CertPK o PAX_STD-2 : client -> server : Enc_PK( B, MAC_CK( A, B, CID, SID )) o PAX_STD-3 : client <- server : MAC_CK( B, CID, SID ) o PAX-ACK : client -> server When not performing an initial key update, where server-side certificates can be omitted, the protocol reduces to: o PAX_STD-1 : client <- server : A, SID o PAX_STD-2 : client -> server : B, MAC_CK( A, B, CID, SID ) o PAX_STD-3 : client <- server : MAC_CK( B, CID, SID ) o PAX-ACK : client -> server 2.2 PAX_IDP Protocol PAX_IDP is an alternate protocol designed to provide identity protection. The main disadvantage of PAX_IDP is that it requires a server-side certificate, and public key operations for every Clancy & Arbaugh Expires December 30, 2004 [Page 7] Internet-Draft EAP-PAX July 2004 authentication. PAX_IDP can be performed with and without key update. Let A, B, and E be defined as in the previous section. The exchanges for PAX_IDP are as follows: o PAX_IDP-1 : client <- server : M, SID, PK, CertPK o PAX_IDP-2 : client -> server : Enc_PK( M, N, CID ) o PAX_IDP-3 : client <- server : A, MAC_N( A, CID, SID ) o PAX_IDP-4 : client -> server : B, MAC_CK( A, B, CID, SID ) 2.3 Key Derivation Keys are derived independently of which authentication mechanism was used. The process uses the entropy value E computed as described above. Session and authentication keys are computed as follows: o AK' = PAX-KDF-16( AK, "Authentication Key", E ) o MK = PAX-KDF-16( AK, "Master Key", E ) o CK = PAX-KDF-16( MK, "Confirmation Key", E ) o ICK = PAX-KDF-16( MK, "Integrity Check Key", E ) o MSK = PAX-KDF-64( MK, "Master Session Key", E ) o EMSK = PAX-KDF-64( MK, "Extended Master Session Key", E ) o IV = PAX-KDF-64( 0x00^16, "Initialization Vector", E ) The IV is computed using a 16-octet NULL key. The value of AK' is only used to replace AK if a key update is being performed. If a key update is not performed, AK' need not be computed. 2.4 Verification Requirements In order for EAP-PAX to be secure, certificates and MACs must be properly verified each step of the way. PAX_STD-1/PAX_IDP-1 -> Client : If a public key and certificate are included, the client SHOULD either compare the public key to a locally cached copy or use the certificate authority's public key to validate the server's public key and certificate. If this validation fails, and the client's security policy prohibits the use of a non-verifiable certificate, then the client MUST send an EAP-Failure message. PAX_STD-2 -> Server : After possibly decrypting the packet, the server MUST validate the included MAC. This MAC serves to authenticate the client to the server. If this validation fails, the server MUST send an EAP-Failure message. Clancy & Arbaugh Expires December 30, 2004 [Page 8] Internet-Draft EAP-PAX July 2004 PAX_IDP-2 -> Server : The server MUST verify that the decrypted value of M matches the value transmitted in PAX_IDP-1. If this validation fails, the server MUST send an EAP-Failure message. PAX_STD-3/PAX_IDP-3 -> Client : The client MUST validate the transmitted MAC, as it serves to authenticate the server to the client. If this validation fails, the client MUST send an EAP-Failure message. PAX_IDP-4 -> Server : The server MUST validate the transmitted MAC, as it serves to authenticate the client to the server. If this validation fails, the server MUST send an EAP-Failure message. 2.5 PAX Key Derivation Function The PAX-KDF is a secure key derivation function used to generate various keys from the provided entropy and shared key. PAX-KDF-W(X, Y, Z) W length, in octets, of the desired output X secret key used to protect the computation Y public identifier for the key being derived Z exchanged entropy used to seed the KDF Let's define some variables and functions: o S = length in octets of the output of the MAC function o M_i = MAC_X(Y || Z || i), where i is an 8-bit unsigned integer o L = ceiling(W/S) o F(A, B) = first A octets of binary data B We define PAX-KDF-W(X, Y, Z) = F(W, M_1 || M_2 || ... || M_L). For example when using a 128-bit MAC function, for the two values of W used in this draft, we have: o PAX-KDF-16(X, Y, Z) = MAC_X(Y || Z || 0x01) o PAX-KDF-64(X, Y, Z) = MAC_X(Y || Z || 0x01) || MAC_X(Y || Z || 0x02) || MAC_X(Y || Z || 0x03) || MAC_X(Y || Z || 0x04) The MAC used in this PRF is extensible, and is the same MAC used in the rest of the protocol. It is specified in the EAP-PAX header. 3. Protocol Specification In this section, the packet format and content for the challenge and response messages are defined. EAP-PAX packets have the following Clancy & Arbaugh Expires December 30, 2004 [Page 9] Internet-Draft EAP-PAX July 2004 structure: --- bit offset ---> 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 | OP-Code | Flags | MAC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DH Group ID | Public Key ID | Sequence No | Payload... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... Payload ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ICV ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 3.1 Header Specification The Code, Identifier, Length, and Type fields are all part of the EAP header, and defined in [RFC3748]. See the "IANA Considerations" section for more information on the type field. 3.1.1 Op-Code The OP-Code field is one of eight possible values: o 0x01 : PAX_STD-1 o 0x02 : PAX_STD-2 o 0x03 : PAX_STD-3 o 0x11 : PAX_IDP-1 o 0x12 : PAX_IDP-2 o 0x13 : PAX_IDP-3 o 0x14 : PAX_IDP-4 o 0x21 : PAX-ACK 3.1.2 Flags The flags field is broken up into 8 bits each representing a binary flag. The field is defined as the Logical OR of the following Clancy & Arbaugh Expires December 30, 2004 [Page 10] Internet-Draft EAP-PAX July 2004 values: o 0x01 : server-side certificate available (SSCA) o 0x02 : public-key encryption required (PKER) o 0x04 : public-key encryption used (PKEU) o 0x08 : more fragments (MF) o 0x10 - 0x80 : reserved The SSCA flag is set in packets of type PAX_STD-1 if and only if those packets include the server's public key and certificate. For PAX_STD packets of any other type, the SSCA flag MUST equal the value of SSCA in the original PAX_STD-1 packet. When the PAX_IDP protocol is used, SSCA MUST be set. The PKER flag SHOULD be set in packets of type PAX_STD-1 if the current authentication key is weak. PKER MUST be set in all packets if PAX_IDP is used. For PAX_STD packets of any other type, the PKER flag MUST equal the value of PKER in the original PAX_STD-1 packet. PKER can only be set if SSCA is set. The PKEU flag MUST equal zero in packets of type PAX_STD-1 and PAX_IDP-1. In packets of type PAX_STD-2, PKEU should be set if and only if the client has encrypted the packet payload using the server's public key. In packets of type PAX_IDP-2, PKEU MUST be set, since encryption is required. If in PAX_STD-1, PKER was set, PKEU MUST be set in PAX_STD-2. If in PAX_STD-1, SSCA was set and PKER was not set, PKEU MAY be set in PAX_STD-2. In general, for PAX_STD, the server is responsible for setting SSCA and PKER in packet PAX_STD-1, while the client is responsible for setting PKEU in packet PAX_STD-2. SSCA and PKER must remain constant in all packets. PKEU must be zero in PAX_STD-1, and constant in all successive packets. For PAX_IDP, SSCA and PKER MUST be set in all packets. PKEU MUST NOT be set in packet PAX_IDP-1, and MUST be set in all other PAX_IDP packets. The MF flag is set if the current packet required fragmentation, and further fragments need to be transmitted. If a packet does not require fragmentation, the MF flag is not set. When a payload requires fragmentation, each fragment is transmitted, and the receiving party responds with a PAX-ACK packet for each received fragment. 3.1.3 MAC ID The MAC field specifies the cryptographic hash used to generate the Clancy & Arbaugh Expires December 30, 2004 [Page 11] Internet-Draft EAP-PAX July 2004 keyed hash value. The following are currently supported: o 0x01 : HMAC_SHA1_128 [FIPS180] o 0x02 : AES_CBC_MAC_128 [FIPS113] 3.1.4 DH Group ID The Diffie-Hellman group field specifies the group used in the Diffie-Hellman computations. The following are currently supported: o 0x00 : NONE (iff not performing a key update) o 0x01 : 3072-bit MODP Group (IANA DH Group 15) [RFC3526] If no key update is being performed, the DH Group ID field MUST be zero. Otherwise, the DH Group ID field MUST NOT be zero. 3.1.5 Public Key ID The public key ID field specifies the cipher used to encrypt the client's EAP-Response in PAX_STD-2 and PAX_IDP-2. The following are currently supported: o 0x00 : NONE (iff SSCA is not set) o 0x01 : RSA_OAEP_2048 If the SSCA flag is not set, the Public Key ID field MUST be zero. Otherwise, the Public Key ID field MUST NOT be zero. 3.1.6 Sequence Number Sequence numbers are used to prevent replay attacks, in particular with respect to ACKs. The server initializes the sequence number to 0 for each transaction, and increments it for each packet. For every EAP-Request/PAX packet fragment transmitted the associated EAP-Response/PAX packet MUST contain a matching sequence number. Packets with invalid sequence numbers MUST be silently discarded. 3.2 Payload Formatting This section describes how to format the payload field. Depending on the packet type, different values are transmitted. Sections 2.1 and 2.2 define the fields, and in what order they are to be concatenated. For simplicity and since many field lengths can vary with the ciphersuite, each value is prepended with a two-octet length value. Clancy & Arbaugh Expires December 30, 2004 [Page 12] Internet-Draft EAP-PAX July 2004 --- byte offset ---> 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+- |len| value .... +-+-+-+-+-+-+- All integer values are stored as octet arrays in network-byte order, with the most significant byte first. Integers are padded on the most significant end to reach byte boundaries. Public keys and certificates SHALL be in X.509 format [X.509] encoded using the Distinguished Encoding Rules (DER) format [X.690]. Strings are not null-terminated and are encoded using UTF-8. Binary data, such as message authentication codes, are transmitted as-is. MACs are computed by concatenating the specified values in the specified order. Values are encoded as described above, except that no length field is specified. To illustrate this process, an example is presented. What follows is the encoding of the payload for PAX_STD-2 with encryption. The three basic steps will be computing the MAC, forming the payload, and encrypting the payload. To create the MAC, we first need to form the buffer that will be MACed. For this example, assume no key update is being done and HMAC_SHA1_128 is used such that the result will be a 16-octet value. Clancy & Arbaugh Expires December 30, 2004 [Page 13] Internet-Draft EAP-PAX July 2004 --- byte offset ---> 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16-octet integer A | 16-octet integer B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... variable length CID ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... variable length SID ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || || CK --> MAC || \/ --- byte offset ---> 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16-octet MAC output | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ With this, we can now create the encoded payload: --- byte offset ---> 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |16 | 16-octet integer B |16 | MAC computed above +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+ These 36 octets are then encrypted using the server's public key. The output of the encryption algorithm is then attached to the packet as the payload. The ICV is then computed by MACing the packet headers and payload, and appended after the payload. 3.3 Integrity Check Value (ICV) The ICV is computed as the MAC over the entire EAP packet, including Clancy & Arbaugh Expires December 30, 2004 [Page 14] Internet-Draft EAP-PAX July 2004 the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC is keyed using the 16-octet MK. For packets of type PAX_STD-1, PAX_IDP-1, PAX_IDP-2, and PAX_IDP-3, where the MK has not yet been derived, the MAC is keyed using a zero-octet NULL key. If the ICV field is incorrect, the receiver MUST silently discard the packet. 4. Security Considerations For any authentication protocol, especially one geared for wireless environments, one must assume adversaries have many capabilities. In general, all messages between the client and server are delivered via the adversary. This allows passive attackers to eavesdrop on all traffic, while active attackers can modify data in any way before delivery. In this section, we discuss the security properties and requirements of EAP-PAX with respect to this threat model. The security of PAX can be proved using under the Random Oracle model. Key updates using a certificate is a slight variation on Halevi and Krawczyk's proved mutually authenticated Diffie-Hellman scheme [HK99]. 4.1 Server Certificates Since many vendors are leery of establishing a public key infrastructure (PKI), or the client-side computation power needed to implement them, some discussion is required with respect to the PKI requirements of this protocol. First of all, realize that only the server needs a public key. The client is authenticated based on the shared secret, not a key pair. This should make deployment significantly easier. Secondly, this protocol is only guaranteed to be secure if when using a weak key (i.e. during provisioning), the client has a means of verifying the authenticity of the server's public key. This can be easily achieved by establishing a certificate authority (CA), signing the server's public key with the CA's private key, and then distributing the CA's public key. The CA's public key can be easily loaded onto the client during the initial software installation. If a CA is not used, then the public key of all servers can be preloaded onto the client, so the client can match the received certificate with the one cached locally. Lastly, if identity protection is required, and PAX_IDP is being executed, the server-side certificate is required. Without using Clancy & Arbaugh Expires December 30, 2004 [Page 15] Internet-Draft EAP-PAX July 2004 some form of authenticated public-key cryptography, identity protection with forward secrecy is theoretically impossible. The only other possibility is to use an aliasing scheme where users are given new usernames after every successful authentication--generally considered a fragile approach, prone to synchronization problems. Use of self-signed certificates with client-side SSH-style caching is only suggested if identity protection is required and a PKI is infeasible. When identity protection is not used, self-signed certificates provide no additional security over no signatures at all. When using cached self-signed certificates in PAX_IDP, realize that clients have no way to authenticate the authenticator before sending them their identity. An attacker could impersonate an authenticator and gain knowledge of the client's identity. In a roaming wireless environment, this attack becomes much easier since the client could possibly interact with multiple authentication servers. Provided a client positively knows they will only interact with one backend authentication server, even when roaming a self-signed, cached certificate approach may be sufficient, depending on one's threat model. When a PKI is not used, realize that a active man-in-the-middle dictionary attack is possible during PAX_STD-1 if the client is authenticating with a weak key and does not have the server's public key locally cached for verification. The effects of this can be mitigated by performing provisioning in a controlled environment. Specifically, in a certificateless environment, an attacker could first forge a PAX_STD-1 message and send it to the client. The client would respond with a PAX_STD-2 packet containing g^X and MAC_CK( g^X || g^Y || CID || SID ). The attacker can now guess values of the weak AK and compute CK = PAX-KDF-16(AK, "Confirmation Key", g^XY). Given enough time, the attacker can obtain both the old AK and new AK', and would then be capable of forging PAX_STD-3 and falsely authenticating himself to the client. In short, in identity protection mode, certificates are required, and use of cached self-signed certificates can lead to man-in-the-middle attacks the first time a client interacts with a particular authenticator. When identity protection is not used, certificates are optional, but clients are vulnerable to an active off-line dictionary attack during provisioning. Implementors should assess these risks with respect to their threat model before deciding not to use the PKI features of EAP-PAX. Clancy & Arbaugh Expires December 30, 2004 [Page 16] Internet-Draft EAP-PAX July 2004 4.2 Server Security In order to maintain a reasonable security policy, the server must manage four pieces of information concerning each user. Most obviously, their username and current key. Additionally, the server must keep a bit that indicates whether the current key is weak. Weak keys must be updated prior to key derivation. Also, the server should track the date of last key update. To implement the coarse-grained forward secrecy, the authentication key must be updated on a regular basis, and this field can be used to expire keys. Lastly, the server should track the previous key, to prevent attacks where an adversary desynchronizes the key state by interfering with PAX-ACK packets. See Appendix A for more suggested implementation strategies that prevent key desynchronization attacks. Since the client keys are stored in plaintext on the server, special care should be given to the overall security of the authentication server. An operating system-level attack yielding root access to an intruder would result in the compromise of all client credentials. 4.3 EAP Security Claims This section describes EAP-PAX in terms of specific security terminology as required by [RFC3748]. 4.3.1 Protected Ciphersuite Negotiation In the initial packet from the server, the server specifies the ciphersuite in the packet header. The server is in total control of the ciphersuite, thus a client not supporting the specified ciphersuite will not be able to authenticate. Additionally, each clients' local security policy should specify secure ciphersuites the client will accept. The ciphersuite specified in PAX_STD-1 and PAX_IDP-1 MUST remain the same in successive packets within the same authentication session. Since later packets are covered by an ICV keyed with the ICK, the server can verify that the originally transmitted ciphersuite was not altered by an adversary. 4.3.2 Mutual Authentication Both PAX_STD and PAX_IDP authenticate the client and the server, and consequently achieve explicit mutual authentication. Notice however that if PAX_STD is used with a weak key and no server-side certificate, the server to client authentication is weak, as the server may have cracked the client's key in order to forge a valid authentication packet. Clancy & Arbaugh Expires December 30, 2004 [Page 17] Internet-Draft EAP-PAX July 2004 4.3.3 Integrity Protection The ICV described in Section 3.3 provides integrity protection once the integrity check key has been derived. The header values in the unprotected packets can be verified when an ICV is received later in the session. 4.3.4 Replay Protection The sequence number in the header prevents replay attacks. 4.3.5 Confidentiality With identity protection enabled, PAX_IDP provides full confidentiality. 4.3.6 Key Derivation Session keys are derived using the PAX-KDF and fresh entropy supplied by both the client and the server. Since the key hierarchy is derived from the shared key, only someone with knowledge of that key is capable of deriving the session keys. 4.3.7 Key Strength Authentication keys are 128 bits. The key generation is protected by a public-key signature and Diffie-Hellman key exchange. It is believed that a 3000-bit MODP public-key scheme is roughly equivalent [RFC3766] to a 128-bit symmetric-key scheme. Consequently, EAP-PAX requires the use of a Diffie-Hellman group with modulus larger than 3000. Also, the exponent used as the private DH parameter must be at least twice as large as the key eventually generated. Consequently, EAP-PAX uses 256-bit DH exponents. Thus, the authentication keys contain the full 128 bits of security. 4.3.8 Dictionary Attack Resistance EAP-PAX is resistant to dictionary attacks, except for the case where a weak key is initially used and the server is not using a certificate for authentication. See section 4.1 for more information on resistance to dictionary attacks. 4.3.9 Fast Reconnect While a specific fast reconnection option is not included, execution of EAP-PAX requires such minimal effort that the time required to perform a full reauthentication is not prohibitive. Clancy & Arbaugh Expires December 30, 2004 [Page 18] Internet-Draft EAP-PAX July 2004 4.3.10 Session Independence This protocol easily achieves backward secrecy through, among other things, use of the PAX-KDF. Given a current session key, they can neither discover the entropy used to generate it, nor the key used to encrypt that entropy as it was transmitted across the network. This protocol has coarse-grained forward secrecy. Compromised session keys are only useful on data for that session, and one cannot derive AK from them. If an attacker can discover AK, that value can only be used to compromise session keys derived using that AK. Reasonably frequent key updates will help mitigate such attacks. Session keys are independently generated using fresh nonces for each session, and therefore the sessions are independent. 4.3.11 Fragmentation Fragmentation and reassembly is supported through the fragmentation flag in the header. 4.3.12 Channel Binding EAP-PAX does not explicitly include any channel binding. 5. IANA Considerations This document introduces one new IANA consideration. It requires IANA to allocate a new EAP Type for EAP-PAX. 6. Acknowledgment The authors would like to thank Jonathan Katz for discussion with respect to provable security, Bernard Aboba for technical guidance, and Florent Bersani for extensive feedback and suggestions. Finally, the authors would like to thank the Defense Information Systems Agency for initially funding this work. 7. References 7.1 Normative References [FIPS113] National Institute for Standards and Technology, "Standard on Computer Data Authentication", Federal Information Processing Standard 113, May 1985. [FIPS180] National Institute for Standards and Technology, Clancy & Arbaugh Expires December 30, 2004 [Page 19] Internet-Draft EAP-PAX July 2004 "Announcing the Secure Hash Standard", Federal Information Processing Standard 180, April 1995. [FIPS197] National Institute for Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", Federal Information Processing Standard 197, November 2001. [FIPS198] National Institute for Standards and Technology, "The Keyed-Hash Message Authentication Code", Federal Information Processing Standard 198, March 2002. [IEEE.80211] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-1997, 1997. [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Clancy & Arbaugh Expires December 30, 2004 [Page 20] Internet-Draft EAP-PAX July 2004 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2004. [X.509] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", Data Networks and Open System Communication Recommendation X.509, March 2000. [X.690] International Telecommunications Union, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", Data Networks and Open System Communication Recommendation X.690, July 2002. 7.2 Informative References [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-based Protocols Secure Against Dictionary Attack", IEEE Symposium on Research in Security and Privacy, May 1992. [DH76] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, 1976. [Gut04] Gutmann, P., "Simplifying Public Key Management", IEEE Computer, February 2004. [HK99] Halevi, S. and H. Krawczyk, "Public-key Cryptography and Password Protocols", ACM Conference on Computer and Communication Security, February 1999. [Jab96] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM Computer Communications Review, October 1996. [I-D.bersani-eap-psk] Bersani, F., "The EAP PSK Protocol", draft-bersani-eap-psk (work in progress), March 2004. [I-D.bersani-eap-synthesis-sharedkeymethods] Bersani, F., "EAP shared key methods: a tentative synthesis of those proposed so far", Clancy & Arbaugh Expires December 30, 2004 [Page 21] Internet-Draft EAP-PAX July 2004 draft-bersani-eap-synthesis-sharedkeymethods (work in progress), April 2004. [I-D.ietf-eap-keying] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. Levkowetz, Ed., "EAP Key Management Framework", draft-ietf-eap-keying-02b (work in progress), November 2003. [I-D.ietf-secsh-architecture] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-architecture-15 (work in progress), October 2003. [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000. Authors' Addresses T. Charles Clancy University of Maryland 4122 A.V. Williams Building College Park, MD 20742 USA EMail: clancy@cs.umd.edu William A. Arbaugh University of Maryland 4137 A.V. Williams Building College Park, MD 20742 USA EMail: waa@cs.umd.edu Appendix A. Implementation Suggestions In this section, two implementation strategies are discussed. The first describes how best to implement and deploy EAP-PAX in an enterprise network for 802.11i authentication. The second describes how to use EAP-PAX for device authentication in a 3G-style mobile phone network. Clancy & Arbaugh Expires December 30, 2004 [Page 22] Internet-Draft EAP-PAX July 2004 A.1 WiFi Enterprise Network For the purposes of this section, a wireless enterprise network is defined to have the following characteristics: o Users wish to obtain network access through 802.11 access points. o Users can possibly have multiple devices (laptops, PDAs, etc) they wish to authenticate. o A preexisting authentication framework already exists, for example a Microsoft Active Directory domain or a Kerberos realm. Two of the biggest challenges in an enterprise WiFi network is key provisioning and support for multiple devices. Consequently, it is recommended that the client's NAI have the format username/KID@realm, where KID is a key ID that can be used to distinguish between different devices. The client's supplicant can use a variety of sources to automatically generate the KID. Two of the better choices would likely be the computer's NETBIOS name, or local Ethernet adapter's MAC address. The wireless adapter's address may be a suboptimal choice, as the user may only have one PCCARD adapter for multiple systems. With an authentication system already in place, there is a natural choice for the provisioned key. Clients can authenticate using their preexisting key. When the server is presented with a new KID, it can create a new key record on the server, and use the user's current password as the provisioned key. For example, for Active Directory, the supplicant could use Microsoft's NtPasswordHash function [RFC2759] to generate a key verifiable by the server. For security, it is suggested that this key be fed through SHA1_128 before being used in a non-Microsoft authentication protocol. After a key update, the server SHOULD keep track of both the old and new authentication key. When two keys exist, the server SHOULD attempt to use both to validate the MACs on transmitted packets. Once a client successfully authenticates using the new key, the server SHOULD discard the old key. This prevents desynchronization attacks. A.2 Mobile Phone Network In a mobile phone system, we no longer need to worry about supporting multiple keys per identity. Presumably each mobile device has a unique identity. However, if multiple devices per identity are desired, a method similar to that presented in section A.1 could be used. Clancy & Arbaugh Expires December 30, 2004 [Page 23] Internet-Draft EAP-PAX July 2004 Provisioning could easily be accomplished by issuing a customer a 4-digit PIN they could type into their phone's keypad. Clancy & Arbaugh Expires December 30, 2004 [Page 24] Internet-Draft EAP-PAX July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Clancy & Arbaugh Expires December 30, 2004 [Page 25]