Network Working Group T. Clancy Internet-Draft W. Arbaugh Expires: January 10, 2005 University of Maryland July 12, 2004 EAP Password Authenticated Exchange draft-clancy-eap-pax-00 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 January 10, 2005. 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-Auth and PAX-Update. PAX-Auth is an extremely lightweight protocol in which a preexisting strong authentication key is used to explicitly authenticate the client to the server, and derive session keys. Clancy & Arbaugh Expires January 10, 2005 [Page 1] Internet-Draft EAP-PAX July 2004 PAX-Update is a more complex protocol that mutually authenticates the client and server, derives a new long-lived authentication key from a weak preshared secret, and finally derives session keys. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Language Requirements . . . . . . . . . . . . . . . . . . 3 1.2 EAP Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.3 PAX Terminology . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 PAX-Auth Protocol . . . . . . . . . . . . . . . . . . . . 6 2.2 PAX-Update Protocol . . . . . . . . . . . . . . . . . . . 6 2.3 Verification Requirements . . . . . . . . . . . . . . . . 8 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 8 3.1 Header Specification . . . . . . . . . . . . . . . . . . . 8 3.2 Payload Formatting . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.1 Server Certificates . . . . . . . . . . . . . . . . . . . 12 4.2 Server Security . . . . . . . . . . . . . . . . . . . . . 13 4.3 EAP Security Claims . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 7.2 Informative References . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Clancy & Arbaugh Expires January 10, 2005 [Page 2] 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 simple, short-term, shared secret. It provides a key update mechanism suitable for deriving a strong authentication key from a weak preshared password or PIN. Then using the strong authentication key, it can derive session keys. The password update mechanism is a Diffie-Hellman key exchange [RFC2631] authenticated with the preshared password and optional server certificate. The session key derivation is a simple nonce-based authentication scheme and MUST only be used with a strong shared secret. 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 timeout period has occurred, the authentication server forces a key update, and the systems defaults to PAX-Update. Otherwise, the simpler PAX-Auth protocol is executed. While the preferred mode of operation is for the server to have a certificate, 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, when a weak password 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][I-D.ietf-pppext-eap-srp]. 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 EAP Terminology The following terminology is defined in the EAP Key Management Framework [I-D.ietf-eap-keying], and will be referenced frequently in later sections. Clancy & Arbaugh Expires January 10, 2005 [Page 3] Internet-Draft EAP-PAX July 2004 peer end client wishing to authenticate authenticator device initiating and enforcing authentication, often passing the authentication through to a backend EAP server through an AAA server; in 802.11, this is the Access Point (AP). AAA server Authentication, Authorization, and Accounting server responsible for passing EAP requests from the authenticator to the local EAP server methods EAP server backend of the EAP methods, responsible for performing authentication and key generation EAP protocol protocol between the peer and authenticator AAA protocol protocol between the authenticator and the AAA server MK Master Key between the peer and EAP server from which all other EAP method session keys are derived 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 for future use IV Initialization vector used to seed stream ciphers; exported to the authenticator 1.3 PAX Terminology This section describes the various variables and functions used in the PAX protocol. They will be referenced frequently in later sections. G public Diffie-Hellman group g public generator of group G, typically 2 X 256-bit random integer generated by the client Y 256-bit random integer generated by the server K Clancy & Arbaugh Expires January 10, 2005 [Page 4] Internet-Draft EAP-PAX July 2004 EAP server's public key CertK EAP server's certificate for public key K P secret (weak password or strong key) shared between the client and EAP server P' new strong shared key generated as a result of PAX-Update IDc client identity contained in the EAP Identity Response if not using identity protection, and packets PAX-A2 and PAX-U2. sign_X(Y) digital signature of message Y with private key X enc_X(Y) encryption of message Y with symmetric key X HMAC_X(Y) keyed message authentication code [RFC2104][FIPS198] computed over message Y with symmetric key X TLS-PRF(X, Y, Z) TLS Pseudorandom Function [RFC2246] computed using secret X, identifier Y, and seed Z. || string or binary data concatination 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. +--------+ +---------+ | | Discovery | | | CLIENT |<----------------------------------->| AUTHEN- | | | | TICATOR | | | EAP Identity Request | | | |<----------------------------------->| | | | | | | | EAP Identity Response | | | |------------------------------------>| | | | | | | | PAX-Auth or PAX-Update | | | |<----------------------------------->| | | | | | | | EAP Success | | | |<------------------------------------| | Clancy & Arbaugh Expires January 10, 2005 [Page 5] Internet-Draft EAP-PAX July 2004 +--------+ +---------+ As mentioned above, there are two distinct protocols that can be executed. The first, and simpler, is PAX-Auth. This is used when an unexpired, strong key is being used to authenticate and generate session keys. When used with an optional server certificate, this protocol supports client identity protection. The second protocol, PAX-Update, is used when an update of the long-term key is required. It uses Diffie-Hellman to ensure the forward secrecy of the new key, and then uses new credentials to generate the required session keys. When used with a server-side certificate, PAX-Update provides client identity protection and security against off-line dictionary attacks. PAX-Update without a certificate is only secure when a strong key is being used. Each of the protocols are now defined. 2.1 PAX-Auth Protocol The PAX-Auth protocol is a simple nonce-based authentication using the strong long-term key. The client and server each exchange 256 bits of random data which is used to seed the TLS-PRF for generation of session keys. The full protocol, when server-side certificates are being used, is as follows: o PAX-A1 : client <- server : X, K, CertK o PAX-A2 : client -> server : Enc_K( Y, IDc, HMAC_P( X, Y, IDc )) When identity protection is not required, and server-side certificates are omitted, the protocol reduces to: o PAX-A1 : client <- server : X o PAX-A2 : client -> server : Y, IDc, HMAC_P( X, Y, IDc ) Session keys are computed as follows: o MK = TLS-PRF( P, "Master Key", X || Y ) o MSK = TLS-PRF( MK, "Master Session Key", X || Y ) o EMSK = TLS-PRF( MK, "Extended Master Session Key", X || Y ) o IV = TLS-PRF( MK, "Initialization Vector", X || Y ) 2.2 PAX-Update Protocol PAX-Update need only be performed if the current authentication key has expired or is weak. If the current key is weak the server MUST Clancy & Arbaugh Expires January 10, 2005 [Page 6] Internet-Draft EAP-PAX July 2004 perform PAX-Update instead of PAX-Auth. The client MUST also refuse to perform PAX-Auth if it has a weak or expired authentication key. PAX-Update consists of three meaningful packets which establish mutual authentication and provide the appropriate material for key derivation. A fourth NULL packet is sent from the client to the server in the end to satisfy the challenge/response nature of the EAP state machine. The optional certificate and signature are used to authenticate the server when a weak password is being used or to provide identity protection if it is required. See Section 4.1 for more information on the risks associated with omitting the server-side certificate. The exchanges for PAX-Update: o PAX-U1 : client <- server : g^X, K, CertK o PAX-U2 : client -> server : Enc_K( g^Y, IDc, HMAC_P'( g^X, IDc )) o PAX-U3 : client <- server : H_P'( g^X, g^Y, IDc ) o PAX-U4 : client -> server : NULL o P <- P' When server-side certificates are omitted, PAX-Update reduces to the following: o PAX-U1 : client <- server : g^X o PAX-U2 : client -> server : g^Y, IDc, HMAC_P'( g^X, IDc ) o PAX-U3 : client <- server : H_P'( g^X, g^Y, IDc ) o PAX-U4 : client -> server : NULL o P <- P' As with PAX-Auth, the only difference in the protocol when the certificate is omitted, is that the public key information is left out from the first packet and the second packet is not encrypted by the client using the server's public key. Session and authentication keys are computed as follows: o P' = TLS-PRF( P, "Authentication Key", g^XY ) o MK = TLS-PRF( P', "Master Key", g^XY ) o MSK = TLS-PRF( MK, "Master Session Key", g^XY ) o EMSK = TLS-PRF( MK, "Extended Master Session Key", g^XY ) o IV = TLS-PRF( MK, "Initialization Vector", g^XY ) Once the DH value g^XY has been computed, it is used to seed the TLS-PRF and compute a new authentication key. This P' then replaces P as the current password on both the client and server. Regardless of the strength of P, P' is a strong shared key immune to dictionary attacks. Clancy & Arbaugh Expires January 10, 2005 [Page 7] Internet-Draft EAP-PAX July 2004 2.3 Verification Requirements In order for EAP-PAX to be secure, HMACs must be properly verified each step of the way. [PAX-A1 and PAX-U1] -> Client : If a public key and certificate are included, the client MUST 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, the client MUST send an EAP-Failure message and disconnect. [PAX-A2 and PAX-U2] -> Server : After possibly decrypting the packet, the server MUST validate the included HMAC. This HMAC serves to authenticate the client to the server. If this validation fails, the client MUST send an EAP-Failure message and disconnect. PAX-U3 -> Client : The client must validate the HMAC transmitted in PAX-U3, as it serves to authenticate the server to the client. If this validation fails, the client MUST send an EAP-Failure message and disconnect. PAX-U4 -> Server : No validation is required. 3. Protocol Specification In this section, the packet format and content for the challenge and response messages are defined. 3.1 Header Specification EAP-PAX packets have the following 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 | HMAC ID | +---------------+---------------+---------------+---------------+ | DH Group ID | Public Key ID | Payload ... +---------------+---------------+----------- Figure 2 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. Clancy & Arbaugh Expires January 10, 2005 [Page 8] Internet-Draft EAP-PAX July 2004 3.1.1 Op-Code The OP-Code field is one of six values: o 0x01 : PAX-Auth : PAX-A1 o 0x02 : PAX-Auth : PAX-A2 o 0x03 : PAX-Update : PAX-U1 o 0x04 : PAX-Update : PAX-U2 o 0x05 : PAX-Update : PAX-U3 o 0x06 : PAX-Update : PAX-U4 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 values: o 0x01 : Server-Side Certificate Enabled o 0x02 : Last Fragment o 0x04 - 0x80 : Reserved The certificate flag is enabled if and only if server side certificates are being used in this particular transaction, and either packet PAX-A2 or PAX-U2 will be encrypted. The fragment flag is enabled if this particular packet represents packet in a series of fragmented packets making up a single EAP-PAX message. If a message only contains one fragment, this flag is enabled. 3.1.3 HMAC ID The HMAC field specifies the cryptographic hash used to generate the keyed hash value. The following are currently supported: o 0x01 : HMAC_SHA1_128 [FIPS180] 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 0x01 : 3072-bit MODP Group (IANA DH Group 15) [RFC3526] 3.1.5 Public Key ID The signature field specifies the signature cipher used to authenticate the server's DH exponent in PAX-U1, and provide client identity protection. Clancy & Arbaugh Expires January 10, 2005 [Page 9] Internet-Draft EAP-PAX July 2004 The following are currently supported: o 0x00 : NONE (iff certificate flag = 0) o 0x01 : RSA-OAEP-2048 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-byte length. --- 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 byte arrays in network-byte order, with the most significant byte first. Integers are padded on the most significant end to reach byte boundaries. For example, a 128-bit integer I is saved in the 16-byte array b as follows: I = b[0]*256^15 + b[1]*256^14 + ... + b[15] 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-terminanted and are encoded using 8-bit ASCII characters. Binary data, such as message authentication codes, are transmitted as-is. HMACs are computed by concatenating the specified values in the specified order. Strings are encoded as 8-bit ASCII characters, and NOT null-terminated. Integers are encoded as specified above. Packets of type PAX-U4 have a payload of length zero. To illustrate this process, an example is presented. What follows is the encoding of the payload for PAX-A2 with encryption. The three basic steps will be computing the HMAC, forming the payload, and encrypting the payload. To create the HMAC, we first need to form the buffer that will be HMAC'd. Assuming HMAC_SHA1_128 is used, the result will be a 16-byte value. Clancy & Arbaugh Expires January 10, 2005 [Page 10] 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-byte integer X | 16-byte integer Y | +-------------------------------+-------------------------------+ | variable length IDc ... +------------------ || || P --> HMAC || \/ --- byte offset ---> 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-------------------------------+ | 16-byte HMAC 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-byte integer Y | L | length L IDc ... +---+-------------------------------+---+---------------- |16 | HMAC computed above | +---+-------------------------------+ These 32+L bytes are then encrypted using the server's public key. The output of the encryption algorithm is then attached to the packet as the payload. 4. Security Considerations For any authentication protocol, especially one geared for wireless environments, must assume adversaries have many capabilities. In general, one must assume that 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. Clancy & Arbaugh Expires January 10, 2005 [Page 11] Internet-Draft EAP-PAX July 2004 The security of PAX-Auth can be easily proven using under the Random Oracle model. In fact, the authentication portion can be proven under the Standard Model, while the Random Oracle (RO) model is only required to ensure secure session key generation. Assuming the difficulty of the Decision Diffie Hellman problem, PAX-Update with a strong key and without a certificate can be proven under the RO model. PAX-Update with a weak key and with a certificate is a slight variation on Halevi and Krawczyk's proven mutually authenticated Diffie-Hellman scheme [HK99]. 4.1 Server Certificates Since many vendors are leary of establishing a public key infrastructure (PKI), or the client-side computation power required 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 password (i.e. during registration), 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. Use of self-signed certificates with client-side SSH-style caching is only suggested if integrity protection is required and a PKI is infeasible. When integrity protection is not used, self-signed certificates provide no additional security over no signatures at all. When using cached self-signed certificates in integrity protection mode, 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 many different authentication servers. When the PKI is not used, realize that a active man-in-the-middle dictionary attack is possible during PAX-Update if the client is authenticating with a weak password and does not have the server's Clancy & Arbaugh Expires January 10, 2005 [Page 12] Internet-Draft EAP-PAX July 2004 public key locally cached for verification. The effects of this can be mitigated by performing registration in a controlled environment. Specifically, in a certificateless environment, an attacker could first forge a PAX-U1 message and send it to the client. The client would respond with a PAX-U2 packet containing g^X and HMAC_P'( g^X || g^Y || IDc ). The attacker can now guess values of the weak P and compute P' = TLS-PRF(P, "Authentication Key", g^XY). Given enough time, the attacker can obtain both the old P and new P', and would then be capable of forging PAX-U3 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 registration. Implementors should assess these risks with respect to their threat model before deciding not to use the PKI features of EAP-PAX. 4.2 Server Security In order to maintain a reasonable security policy, the server must maintain 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 or not. 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 perfect forward secrecy described earlier, the authentication key must be updated on a regular basis, and this field can be used to expire keys. 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 Clancy & Arbaugh Expires January 10, 2005 [Page 13] Internet-Draft EAP-PAX July 2004 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-A1 and PAX-U1 MUST remain the same in successive packets within the same authentication session. 4.3.2 Mutual Authentication When PAX-Auth is used, only the client is explicitly authenticated. The server is implicitly authenticated to the client because only a valid server would be able to generate the required session keys. Thus with PAX-Auth, mutual authentication is achieved only implicitly. The client can only verify the server's authenticity after receiving the first packet encrypted with the derived session key. On the other hand, PAX-Update authenticates both the client and the server, and consequently achieves explicit mutual authentication. Notice however that if PAX-Update is used with a weak password and no server-side certificiate, the server to client authentication is weak, as the server may have cracked the client's password in order to forge a valid authentication packet. 4.3.3 Integrity Protection The fields of the EAP and EAP-PAX headers are not explicitly covered by an integrity protection field. Since neither the identity nor a strong key may yet exist, there is no guarantee that a key will be available to perform an HMAC. However, the security of the scheme is not compromised by the lack of an integrity check field. The options are validated and must agree with the client's security policy. Altered payloads will only create a denial of service condition. 4.3.4 Replay Protection Replays are avoided because replies include values from previous requests. The only packets capable of being replayed are PAX-A1 and PAX-U1. However, replaying these packets provides an attacker with only a negligible advantage. 4.3.5 Confidentiality With identity protection enabled, EAP-PAX provides full confidentiality. 4.3.6 Key Derivation Session keys are derived using the TLS-PRF and fresh entropy supplied Clancy & Arbaugh Expires January 10, 2005 [Page 14] Internet-Draft EAP-PAX July 2004 by both the client and the server. Since the key hierarchy is derived from the shared password, only someone with knowledge of that password 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. Since the public-key is solely used to authenticate the server, its compromise will not affect previously generated keys. Thus, provided proper certificate management policies a smaller key size may be used without affecting the derived authentication key strength. While the session keys are each generated from 512 bits of entropy, the entropy is exchanged using the 128-bit authentication key. Therefore, they have at most 128 bits of security. 4.3.8 Dictionary Attack Resistance EAP-PAX is resistant to dictionary attacks, except for the case where a weak password 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 PAX-Auth requires such minimal effort that the time required to perform a full reauthentication is not prohibitive. 4.3.10 Session Independence This protocol easily achieves backward secrecy through, among other things, use of the TLS-PRF. 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 perfect forward secrecy. Compromised session keys are only useful on data for that session, and one cannot derive P from them. If an attacker can discover P, that value can Clancy & Arbaugh Expires January 10, 2005 [Page 15] Internet-Draft EAP-PAX July 2004 only be used to compromise session keys derived using that P. Reasonably frequent password updates will help mitigate such attacks. Session keys are independently generated 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 [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. [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. [FIPS180] National Institute for Standards and Technology, "Announcing the Secure Hash Standard", Federal Information Clancy & Arbaugh Expires January 10, 2005 [Page 16] Internet-Draft EAP-PAX July 2004 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. [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-pppext-eap-srp] Carlson, J., Aboba, B. and H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", draft-ietf-pppext-eap-srp-03 (work in progress), July 2001. [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. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", Clancy & Arbaugh Expires January 10, 2005 [Page 17] Internet-Draft EAP-PAX July 2004 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. 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 [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. [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", draft-bersani-eap-synthesis-sharedkeymethods (work in progress), April 2004. [I-D.ietf-secsh-architecture] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Protocol Architecture", Clancy & Arbaugh Expires January 10, 2005 [Page 18] Internet-Draft EAP-PAX July 2004 draft-ietf-secsh-architecture-15 (work in progress), October 2003. Authors' Addresses T. Charles Clancy III University of Maryland A.V. Williams Building College Park, MD 20742 USA EMail: clancy@cs.umd.edu William A. Arbaugh University of Maryland A.V. Williams Building College Park, MD 20742 USA EMail: waa@cs.umd.edu Clancy & Arbaugh Expires January 10, 2005 [Page 19] Internet-Draft EAP-PAX July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 assignees. 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 Clancy & Arbaugh Expires January 10, 2005 [Page 20] Internet-Draft EAP-PAX July 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.