diff options
Diffstat (limited to 'doc/rfc/rfc4746.txt')
| -rw-r--r-- | doc/rfc/rfc4746.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc4746.txt b/doc/rfc/rfc4746.txt new file mode 100644 index 0000000..61a2c29 --- /dev/null +++ b/doc/rfc/rfc4746.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group T. Clancy +Request for Comments: 4746 LTS +Category: Informational W. Arbaugh + UMD + November 2006 + + + Extensible Authentication Protocol (EAP) + Password Authenticated Exchange + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2006). + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines an Extensible Authentication Protocol (EAP) + method called EAP-PAX (Password Authenticated eXchange). This method + is a lightweight shared-key authentication protocol with optional + support for key provisioning, key management, identity protection, + and authenticated data exchange. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Language Requirements ......................................3 + 1.2. Terminology ................................................3 + 2. Overview ........................................................5 + 2.1. PAX_STD Protocol ...........................................6 + 2.2. PAX_SEC Protocol ...........................................7 + 2.3. Authenticated Data Exchange ................................9 + 2.4. Key Derivation ............................................10 + 2.5. Verification Requirements .................................11 + 2.6. PAX Key Derivation Function ...............................12 + 3. Protocol Specification .........................................13 + 3.1. Header Specification ......................................13 + 3.1.1. Op-Code ............................................13 + 3.1.2. Flags ..............................................14 + + + +Clancy & Arbaugh Informational [Page 1] + +RFC 4746 EAP-PAX November 2006 + + + 3.1.3. MAC ID .............................................14 + 3.1.4. DH Group ID ........................................14 + 3.1.5. Public Key ID ......................................15 + 3.1.6. Mandatory to Implement .............................15 + 3.2. Payload Formatting ........................................16 + 3.3. Authenticated Data Exchange (ADE) .........................18 + 3.4. Integrity Check Value (ICV) ...............................19 + 4. Security Considerations ........................................19 + 4.1. Server Certificates .......................................20 + 4.2. Server Security ...........................................20 + 4.3. EAP Security Claims .......................................21 + 4.3.1. Protected Ciphersuite Negotiation ..................21 + 4.3.2. Mutual Authentication ..............................21 + 4.3.3. Integrity Protection ...............................21 + 4.3.4. Replay Protection ..................................21 + 4.3.5. Confidentiality ....................................21 + 4.3.6. Key Derivation .....................................21 + 4.3.7. Key Strength .......................................22 + 4.3.8. Dictionary Attack Resistance .......................22 + 4.3.9. Fast Reconnect .....................................22 + 4.3.10. Session Independence ..............................22 + 4.3.11. Fragmentation .....................................23 + 4.3.12. Channel Binding ...................................23 + 4.3.13. Cryptographic Binding .............................23 + 4.3.14. Negotiation Attack Prevention .....................23 + 5. IANA Considerations ............................................23 + 6. Acknowledgments ................................................24 + 7. References .....................................................24 + 7.1. Normative References ......................................24 + 7.2. Informative References ....................................25 + Appendix A. Key Generation from Passwords ........................ 27 + Appendix B. Implementation Suggestions ........................... 27 + B.1. WiFi Enterprise Network ................................... 27 + B.2. Mobile Phone Network ...................................... 28 + +1. Introduction + + EAP-PAX (Password Authenticated eXchange) is an Extensible + Authentication Protocol (EAP) method [RFC3748] designed for + authentication using a shared key. It makes use of two separate + subprotocols, PAX_STD and PAX_SEC. PAX_STD is a simple, lightweight + protocol for mutual authentication using a shared key, supporting + Authenticated Data Exchange (ADE). PAX_SEC complements PAX_STD by + providing support for shared-key provisioning and identity protection + using a server-side public key. + + + + + + +Clancy & Arbaugh Informational [Page 2] + +RFC 4746 EAP-PAX November 2006 + + + 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 elapsed, the + authentication server forces a key update. Rather than using a + symmetric key exchange, the client and server perform a Diffie- + Hellman key exchange, which provides forward secrecy. + + Since implementing a Public Key Infrastructure (PKI) can be + cumbersome, PAX_SEC defines multiple client security policies, + selectable based on one's threat model. In the weakest mode, PAX_SEC + allows the use of raw public keys completely eliminating the need for + a PKI. In the strongest mode, PAX_SEC requires that EAP servers use + certificates signed by a trusted Certification Authority (CA). In + the weaker modes, during provisioning PAX_SEC is vulnerable to a + man-in-the-middle dictionary attack. In the strongest mode, EAP-PAX + is provably secure under the Random Oracle model. + + EAP-PAX supports the generation of strong key material; mutual + authentication; resistance to desynchronization, dictionary, and + man-in-the-middle attacks; ciphersuite extensibility with protected + negotiation; identity protection; and the authenticated exchange of + data, useful for implementing channel binding. These features + satisfy the EAP method requirements for wireless LANs [RFC4017], + making EAP-PAX 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. 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 EAP-PAX protocol. They will be referenced frequently in later + sections. + + Variables: + + CID + User-supplied client ID, specified as a Network Access Identifier + (NAI) [RFC4282], restricted to 65535 octets + + g + public Diffie-Hellman generator, typically the integer 2 [RFC2631] + + + +Clancy & Arbaugh Informational [Page 3] + +RFC 4746 EAP-PAX November 2006 + + + M + 128-bit random integer generated by the server + + N + 128-bit random integer generated by the client + + X + 256-bit random integer generated by the server + + Y + 256-bit random integer generated by the client + + Keys: + + AK + authentication key shared between the client and EAP server + + AK' + new authentication key generated during a key update + + CertPK + EAP server's certificate containing public key PK + + CK + Confirmation Key generated from the MK and used during + authentication to prove knowledge of AK + + EMSK + Extended Master Session Key also generated from the MK and + containing additional keying material + + IV + Initialization Vector used to seed ciphers; exported to the + authenticator + + MID + Method ID used to construct the EAP Session ID and consequently + name all the exported keys [IETF.KEY] + + MK + Master Key between the client 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 + + + + + +Clancy & Arbaugh Informational [Page 4] + +RFC 4746 EAP-PAX November 2006 + + + PK + EAP server's public key + + 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 + + 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 + + || + 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 + link-layer protocol. The authentication phase is defined here. The + key distribution and secure association phases are handled + differently depending on the underlying protocol, and are not + discussed in this document. + + +--------+ +--------+ + | | EAP-Request/Identity | | + | CLIENT |<------------------------------------| SERVER | + | | | | + | | EAP-Response/Identity | | + | |------------------------------------>| | + | | | | + | | EAP-PAX (STD or SEC) | | + | |<----------------------------------->| | + | | ... ... | | + | |<----------------------------------->| | + | | | | + | | EAP-Success or EAP-Failure | | + | |<------------------------------------| | + +--------+ +--------+ + + Figure 1: EAP-PAX Packet Exchanges + + + + + +Clancy & Arbaugh Informational [Page 5] + +RFC 4746 EAP-PAX November 2006 + + + There are two distinct subprotocols that can be executed. The first, + PAX_STD, is used during typical authentications. The second, + PAX_SEC, provides more secure features such as key provisioning and + identity protection. + + PAX_STD and PAX_SEC have two modes of operation. When an AK update + is being performed, the client and server exchange Diffie-Hellman + exponents g^X and g^Y, which are computed modulo prime P or over an + elliptic curve multiplicative group. 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 deployment difference between PAX_STD and PAX_SEC is that + PAX_SEC requires a server-side public key. More specifically, that + means a private key known only to the server with corresponding + public key being transmitted to the client during each PAX_SEC + session. For every authentication, the client is required to compute + computationally intensive public-key operations. PAX_STD, on the + other hand, uses purely symmetric operations, other than a possible + Diffie-Hellman exchange. + + Each of the protocols is now defined. + +2.1. PAX_STD Protocol + + PAX_STD 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 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 + o B = Y + o E = X || Y + + Thus, A and B are 256-bit values and E is their 512-bit + concatenation. To provide forward secrecy and security, let the + following be true when a key update is being performed: + + o A = g^X + o B = g^Y + o E = g^(XY) + + Here A and B are Diffie-Hellman exponents whose length is determined + by the Diffie-Hellman group size. The value A is data transmitted + + + +Clancy & Arbaugh Informational [Page 6] + +RFC 4746 EAP-PAX November 2006 + + + from the server to the client, and B is data transmitted from the + client to the server. The value E is the entropy computed by each + that is used in Section 2.4 to perform key derivation. + + The full protocol is as follows: + + o PAX_STD-1 : client <- server : A + o PAX_STD-2 : client -> server : B, CID, MAC_CK(A, B, CID), + [optional ADE] + o PAX_STD-3 : client <- server : MAC_CK(B, CID), [optional ADE] + o PAX-ACK : client -> server : [optional ADE] + + See Section 2.3 for more information on the ADE component, and + Section 2.4 for the key derivation process, including derivation of + CK. + +2.2. PAX_SEC Protocol + + PAX_SEC is the high-security protocol designed to provide identity + protection and support for provisioning. PAX_SEC requires a server- + side public key, and public-key operations for every authentication. + + PAX_SEC can be performed with and without key update. Let A, B, and + E be defined as in the previous section. + + The exchanges for PAX_SEC are as follows: + + o PAX_SEC-1 : client <- server : M, PK or CertPK + o PAX_SEC-2 : client -> server : Enc_PK(M, N, CID) + o PAX_SEC-3 : client <- server : A, MAC_N(A, CID) + o PAX_SEC-4 : client -> server : B, MAC_CK(A, B, CID), [optional + ADE] + o PAX_SEC-5 : client <- server : MAC_CK(B, CID), [optional ADE] + o PAX-ACK : client -> server : [optional ADE] + + See Section 2.3 for more information on the ADE component, and + Section 2.4 for the key derivation process, including derivation of + CK. + + Use of CertPK is optional in PAX_SEC; however, careful consideration + should be given before omitting the CertPK. The following table + describes the risks involved when using PAX_SEC without a + certificate. + + + + + + + + +Clancy & Arbaugh Informational [Page 7] + +RFC 4746 EAP-PAX November 2006 + + + Certificate | Provisioning | Identity + Mode | | Protection + ==================+=====================+====================== + No Certificate | MiTM offline | ID reveal attack + | dictionary attack | + ------------------+---------------------+--------------------- + Self-Signed | MiTM offline | ID reveal attack + Certificate | dictionary attack | + ------------------+---------------------+--------------------- + Certificate/PK | MiTM offline | ID reveal attack + Caching | dictionary attack | during first auth + ------------------+---------------------+--------------------- + CA-Signed | secure mutual | secure mutual + Certificate | authentication | authentication + + Figure 2: Table of Different Security Modes + + When using PAX_SEC to support provisioning with a weak key, use of a + CA-signed certificate is RECOMMENDED. When not using a CA-signed + certificate, the initial authentication is vulnerable to an offline + man-in-the-middle (MiTM) dictionary attack. + + When using PAX_SEC to support identity protection, use of either a + CA-signed certificate or key caching is RECOMMENDED. Caching + involves a client recording the public key of the EAP server and + verifying its consistency between sessions, similar to Secure SHell + (SSH) Protocol [RFC4252]. Otherwise, an attacker can spoof an EAP + server during a session and gain knowledge of a client's identity. + + Whenever certificates are used, clients MUST validate that the + certificate's extended key usage, KeyPurposeID, is either + "eapOverPPP" or "eapOverLAN" [RFC3280][RFC4334]. If the underlying + EAP transport protocol is known, then the client MUST differentiate + between these values. For example, an IEEE 802.11 supplicant SHOULD + require KeyPurposeID == eapOverLAN. By not distinguishing, a client + could accept as valid an unauthorized server certificate. + + When using EAP-PAX with Wireless LAN, clients SHOULD validate that + the certificate's wlanSSID extension matches the SSID of the network + to which it is currently authenticating. + + In order to facilitate discussion of packet validations, three client + security policies for PAX_SEC are defined. + + open + Clients support both use of PK and CertPK. If CertPK is used, the + client MUST validate the KeyPurposeID. + + + + +Clancy & Arbaugh Informational [Page 8] + +RFC 4746 EAP-PAX November 2006 + + + caching + Clients save PK for each EAP server the first time it encounters + the server, and SHOULD NOT authenticate to EAP servers whose + public key has been changed. If CertPK is used, the client MUST + validate the KeyPurposeID. + + strict + In strict mode, clients require servers to present a valid + certificate signed by a trusted CA. As with the other modes, the + KeyPurposeID MUST be validated. + + Servers SHOULD support the PAX_SEC mode of operation, and SHOULD + support both the use of PK and CertPK with PAX_SEC. Clients MUST + support PAX_SEC, and MUST be capable of accepting both raw public + keys and certificates from the server. Local security policy will + define which forms of key or certificate authentications are + permissible. Default configurations SHOULD require a minimum of the + caching security policy, and MAY require strict. + + The ability to perform key management on the AK is built in to EAP- + PAX through the use of AK'. However, key management of the server + public key is beyond the scope of this document. If self-signed + certificates are used, the deployers should be aware that expired + certificates may be difficult to replace when the caching security + mode is used. + + See Section 4 for further discussion on security considerations. + +2.3. Authenticated Data Exchange + + Messages PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK + contain optional component ADE. This component is used to convey + authenticated data between the client and server during the + authentication. + + The Authenticated Data Exchanged (ADE) can be used in a variety of + ways, including the implementation of channel bindings. Channel + bindings allow link-layer network properties to be securely validated + by the EAP client and server during the authentication session. + + It is important to note that ADE is not encrypted, so any data + included will not be confidential. However, since these packets are + all protected by the Integrity Check Value (ICV), authenticity is + guaranteed. + + + + + + + +Clancy & Arbaugh Informational [Page 9] + +RFC 4746 EAP-PAX November 2006 + + + The ADE element consists of an arbitrary number of subelements, each + with length and type specified. If the number and size of + subelements is too large, packet fragmentation will be necessary. + Vendor-specific options are supported. See Section 3.3. + + Note that more than 1.5 round-trips may be necessary to execute a + particular authenticated protocol within EAP-PAX. In this case, + instead of sending an EAP-Success after receiving the PAX_ACK, the + server can continue sending PAX_ACK messages with attached elements. + The client responds to these PAX_ACK messages with PAX_ACK messages + possibly containing more ADE elements. Such an execution could look + something like the following: + + +--------+ +--------+ + | | PAX_STD-1 | | + | |<------------------------------------| | + | | PAX_STD-2(ADE[1]) | | + | |------------------------------------>| | + | | PAX_STD-3(ADE[2]) | | + | |<------------------------------------| | + | | PAX_ACK(ADE[3]) | | + | |------------------------------------>| | + | | PAX_ACK(ADE[4]) | | + | |<------------------------------------| | + | | | | + | | ... | | + | | | | + | | PAX_ACK(ADE[i]) | | + | |------------------------------------>| | + | | PAX_ACK(ADE[i+1]) | | + | |<------------------------------------| | + | | | | + | | ... | | + | | | | + | | EAP-Success or EAP-Failure | | + | |<------------------------------------| | + +--------+ +--------+ + + Figure 3: Extended Diagram of EAP-PAX Packet Exchanges + +2.4. 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) + + + +Clancy & Arbaugh Informational [Page 10] + +RFC 4746 EAP-PAX November 2006 + + + o CK = PAX-KDF-16(MK, "Confirmation Key", E) + o ICK = PAX-KDF-16(MK, "Integrity Check Key", E) + o MID = PAX-KDF-16(MK, "Method ID", 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. The EAP + Method ID is represented in ASCII as 32 hexadecimal characters + without any octet delimiters such as colons or dashes. + + The EAP Key Management Framework [IETF.KEY] recommends specification + of key names and scope. The EAP-PAX Method-ID is the MID value + computed as described above. The EAP peer name is the CID value + exchanged in PAX_STD-2 and PAX_SEC-2. The EAP server name is an + empty string. + +2.5. Verification Requirements + + In order for EAP-PAX to be secure, MACs must be properly verified + each step of the way. Any packet with an ICV (see Section 3.4) that + fails validation must be silently discarded. After ICV validation, + the following checks must be performed: + + PAX_STD-2 + The server MUST validate the included MAC, as it serves to + authenticate the client to the server. If this validation fails, + the server MUST send an EAP-Failure message. + + PAX_STD-3 + The client MUST validate the included MAC, as it serves to + authenticate the server to the client. If this validation fails, + the client MUST send an EAP-Failure message. + + PAX_SEC-1 + The client MUST validate PK or CertPK in a manner specified by its + local security policy (see Section 2.2). If this validation + fails, the client MUST send an EAP-Failure message. + + PAX_SEC-2 + The server MUST verify that the decrypted value of M matches the + value transmitted in PAX_SEC-1. If this validation fails, the + server MUST send an EAP-Failure message. + + + + + + + +Clancy & Arbaugh Informational [Page 11] + +RFC 4746 EAP-PAX November 2006 + + + PAX_SEC-3 + The client MUST validate the included MAC, as it serves to prevent + replay attacks. If this validation fails, the client MUST send an + EAP-Failure message. + + PAX_SEC-4 + The server MUST validate the included MAC, as it serves to + authenticate the client to the server. If this validation fails, + the server MUST send an EAP-Failure message. + + PAX_SEC-5 + The client MUST validate the included MAC, as it serves to + authenticate the server to the client. If this validation fails, + the client MUST send an EAP-Failure message. + + PAX-ACK + If PAX-ACK is received in response to a message fragment, the + receiver continues the protocol execution. If PAX-ACK is received + in response to PAX_STD-3 or PAX_SEC-5, then the server MUST send + an EAP-Success message. This indicates a successful execution of + PAX. + +2.6. 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 M_i = MAC_X(Y || Z || i), where i is an 8-bit unsigned integer + o L = ceiling(W/16) + 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). + + Consequently for the two values of W used in this document, 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) + + + + +Clancy & Arbaugh Informational [Page 12] + +RFC 4746 EAP-PAX November 2006 + + + The MAC used in the 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 EAP-PAX + messages are defined. + + 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 | MAC ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DH Group ID | Public Key ID | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ... Payload ... + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ... ICV ... + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: EAP-PAX Packet Structure + +3.1. Header Specification + + The Code, Identifier, Length, and Type fields are all part of the EAP + header, and defined in [RFC3748]. IANA has allocated EAP Method Type + 46 for EAP-PAX; thus, the Type field in the EAP header MUST be 46. + +3.1.1. Op-Code + + The OP-Code field is one of the following values: + + o 0x01 : PAX_STD-1 + o 0x02 : PAX_STD-2 + o 0x03 : PAX_STD-3 + o 0x11 : PAX_SEC-1 + o 0x12 : PAX_SEC-2 + o 0x13 : PAX_SEC-3 + o 0x14 : PAX_SEC-4 + + + +Clancy & Arbaugh Informational [Page 13] + +RFC 4746 EAP-PAX November 2006 + + + o 0x15 : PAX_SEC-5 + 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 + values: + + o 0x01 : more fragments (MF) + o 0x02 : certificate enabled (CE) + o 0x04 : ADE Included (AI) + o 0x08 - 0x80 : reserved + + 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. + + When using PAX_STD, the CE flag MUST be zero. When using PAX_SEC, + the CE flag MUST be set if PAX_SEC-1 includes CertPK. It MUST NOT be + set if PAX_SEC-1 includes PK. If CE is set in PAX_SEC-1, it MUST be + set in PAX_SEC-2, PAX_SEC-3, PAX_SEC-4, and PAX_SEC-5. If either + party detects an inconsistent value of the CE flag, he MUST send an + EAP-Failure message and discontinue the session. + + The AI flag indicates the presence of an ADE element. AI MUST only + be set on packets PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and + PAX_ACK if an ADE element is included. On packets of other types, + ADE elements MUST be silently discarded as they cannot be + authenticated. + +3.1.3. MAC ID + + The MAC field specifies the cryptographic hash used to generate the + keyed hash value. The following are currently supported: + + o 0x01 : HMAC_SHA1_128 [FIPS198] [FIPS180] + o 0x02 : HMAC_SHA256_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: + + + + +Clancy & Arbaugh Informational [Page 14] + +RFC 4746 EAP-PAX November 2006 + + + o 0x00 : NONE (iff not performing a key update) + o 0x01 : 2048-bit MODP Group (IANA DH Group 14) [RFC3526] + o 0x02 : 3072-bit MODP Group (IANA DH Group 15) [RFC3526] + o 0x03 : NIST ECC Group P-256 [FIPS186] + + 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_SEC-2. + + The following are currently supported: + + o 0x00 : NONE (if using PAX_STD) + o 0x01 : RSAES-OAEP [RFC3447] + o 0x02 : RSA-PKCS1-V1_5 [RFC3447] + o 0x03 : El-Gamal Over NIST ECC Group P-256 [FIPS186] + + If PAX_STD is being executed, the Public Key ID field MUST be zero. + If PAX_SEC is being executed, the Public Key ID field MUST NOT be + zero. + + When using RSAES-OAEP, the hash algorithm and mask generation + algorithm used SHALL be the MAC specified by the MAC ID, keyed using + an all-zero key. The label SHALL be null. + + The RSA-based schemes specified here do not dictate the length of the + public keys. DER encoding rules will specify the key size in the key + or certificate [X.690]. Key sizes SHOULD be used that reflect the + desired level of security. + +3.1.6. Mandatory to Implement + + The following ciphersuite is mandatory to implement and achieves + roughly 112 bits of security: + + o HMAC_SHA1_128 + o IANA DH Group 14 (2048 bits) + o RSA-PKCS1-V1_5 (RECOMMEND 2048-bit public key) + + The following ciphersuite is RECOMMENDED and achieves 128 bits of + security: + + o HMAC_SHA256_128 + o IANA DH Group 15 (3072 bits) + o RSAES-OAEP (RECOMMEND 3072-bit public key) + + + +Clancy & Arbaugh Informational [Page 15] + +RFC 4746 EAP-PAX November 2006 + + +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 2-octet length value + encoded as an integer as described below. This length field MUST + equal the length in octets of the subsequent value field. + + --- octet offset ---> + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +---+--------------------- + |len| value .... + +---+-------- + + Figure 5: Length Encoding for Data Elements + + All integer values are stored as octet arrays in network-byte order, + with the most significant octet first. Integers are padded on the + most significant end to reach octet boundaries. + + Public keys and certificates SHALL be in X.509 format [RFC3280] + 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. Note that for MACs, length fields are not included, + though the resulting MAC will itself have a length field. 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. 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 that no key update is being done and + HMAC_SHA1_128 is used such that the result will be a 16-octet value. + + + + + + + + + +Clancy & Arbaugh Informational [Page 16] + +RFC 4746 EAP-PAX November 2006 + + + --- octet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 32-octet integer A | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 32-octet integer B | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ... variable length CID ... + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + || + || + CK --> MAC + || + \/ + + --- octet offset ---> + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 16-octet MAC output | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Example Encoding of PAX_STD-2 MAC Data + + With this, we can now create the encoded payload: + + --- octet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |32 | 32-octet integer B + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | L | | + +-+-+-+-+ + + | | + ... L-octet CID ... + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |16 | MAC computed above | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Example Encoding of PAX_STD-2 Packet + + + + + +Clancy & Arbaugh Informational [Page 17] + +RFC 4746 EAP-PAX November 2006 + + + These 52+L octets are 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 (see Section 3.4). + +3.3. Authenticated Data Exchange (ADE) + + This section describes the formatting of the ADE elements. ADE + elements can only occur on packets of type PAX_STD-2, PAX_STD-3, + PAX_SEC-4, PAX_SEC-5, and PAX_ACK. Values included in other packets + MUST be silently ignored. + + The ADE element is preceded by its 2-octet length L. Each subelement + has first a 2-octet length Li followed by a 2-octet type Ti. The + entire ADE element looks as follows: + + --- octet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | L |L1 |T1 | | + +-+-+-+-+-+-+ + + | | + ... subADE-1, type T1, length L1 ... + | | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |L2 |T2 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ... subADE-2, type T2, length L2 ... + | | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | more subADE elements... ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: Encoding of ADE Components + + The following type values have been allocated: + + o 0x01 : Vendor Specific + o 0x02 : Client Channel Binding Data + o 0x03 : Server Channel Binding Data + + + + + + + + + + +Clancy & Arbaugh Informational [Page 18] + +RFC 4746 EAP-PAX November 2006 + + + The first three octets of a subADE utilizing type code 0x01 must be + the vendor's Enterprise Number [RFC3232] as registered with IANA. + The format for such a subADE is as follows: + + --- octet 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Li | 1 | ENi | | + +-+-+-+-+-+-+-+ + + | | + ... subADE-i, type Vendor Specific, length Li, vendor ENi ... + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: Encoding of Vendor-specific ADE + + Channel binding subADEs have yet to be defined. Future IETF + documents will specify the format for these subADE fields. + +3.4. Integrity Check Value (ICV) + + The ICV is computed as the MAC over the entire EAP packet, including + the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC + is keyed using the 16-octet ICK, using the MAC type specified by the + MAC ID in the EAP-PAX header. For packets of type PAX_STD-1, + PAX_SEC-1, PAX_SEC-2, and PAX_SEC-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 + + Any authentication protocol, especially one geared for wireless + environments, must assume that 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. Also note that the + security of PAX can be proved using under the Random Oracle model. + + + + + + + +Clancy & Arbaugh Informational [Page 19] + +RFC 4746 EAP-PAX November 2006 + + +4.1. Server Certificates + + PAX_SEC can be used in several configurations. It can be used with + or without a server-side certificate. Section 2.2 details the + possible modes and the resulting security risk. + + When using PAX_SEC for identity protection and not using a CA-signed + certificate, an attacker can convince a client to reveal his + username. To achieve this, an attacker can simply forge a PAX_SEC-1 + message and send it to the client. The client would respond with a + PAX_SEC-2 message containing his encrypted username. The attacker + can then use his associated private key to decrypt the client's + username. Use of key caching can reduce the risk of identity + revelation by allowing clients to detect when the EAP server to which + they are accustom has a different public key. + + When provisioning with PAX_SEC and not using a CA-signed certificate, + an attacker could first forge a PAX_SEC-1 message and send it to the + client. The client would respond with a PAX_SEC-2 message. Using + the decrypted value of N, an attacker could forge a PAX_SEC-3 + message. Once the client responds with a PAX_SEC-4 message, an + attacker can guess values of the weak AK and compute CK = PAX-KDF(AK, + "Confirmation Key", g^XY). Given enough time, the attacker can + obtain both the old AK and new AK' and forge a responding PAX_SEC-5. + +4.2. Server Security + + In order to maintain a reasonable security policy, the server should + manage five pieces of information concerning each user, most + obviously, the username and current key. In addition, 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. Last, 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 B 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. + + + + + + + +Clancy & Arbaugh Informational [Page 20] + +RFC 4746 EAP-PAX November 2006 + + +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. In addition, each + client's local security policy should specify secure ciphersuites the + client will accept. The ciphersuite specified in PAX_STD-1 and + PAX_SEC-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_SEC authenticate the client and the server, and + consequently achieve explicit mutual authentication. + +4.3.3. Integrity Protection + + The ICV described in Section 3.4 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 + + EAP-PAX is inherently designed to avoid replay attacks by + cryptographically binding each packet to the previous one. Also the + EAP sequence number is covered by the ICV to further strengthen + resistance to replay attacks. + +4.3.5. Confidentiality + + With identity protection enabled, PAX_SEC 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 password, only someone with knowledge of that + password or the capability of guessing it is capable of deriving the + + + +Clancy & Arbaugh Informational [Page 21] + +RFC 4746 EAP-PAX November 2006 + + + session keys. One of the main benefits of PAX_SEC is that it allows + you to bootstrap a strong shared secret using a weak password while + preventing offline dictionary attacks. + +4.3.7. Key Strength + + Authentication keys are 128 bits. The key generation is protected by + a 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. + + Future ciphersuites defined for EAP-PAX MUST contain a minimum of 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 + + Although a specific fast reconnection option is not included, + execution of PAX_STD requires very little computation time and is + therefore bound primarily by the latency of the Authentication, + Authorization, and Accounting (AAA) server. + +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, attackers + can discover neither 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 password updates will help mitigate such attacks. + + Session keys are independently generated using fresh nonces for each + session, and therefore the sessions are independent. + + + +Clancy & Arbaugh Informational [Page 22] + +RFC 4746 EAP-PAX November 2006 + + +4.3.11. Fragmentation + + Fragmentation and reassembly is supported through the fragmentation + flag in the header. + +4.3.12. Channel Binding + + EAP-PAX can be extended to support channel bindings through the use + of its subADE fields. + +4.3.13. Cryptographic Binding + + EAP-PAX does not include any cryptographic binding. This is relevant + only for tunneled methods. + +4.3.14. Negotiation Attack Prevention + + EAP is susceptible to an attack where an attacker uses NAKs to + convince an EAP client and server to use a less secure method, and + can be prevented using method-specific integrity protection on NAK + messages. Since EAP-PAX does not have suitable keys derived for this + integrity protection at the beginning of a PAX conversation, this is + not included. + +5. IANA Considerations + + This document requires IANA to maintain the namespace for the + following header fields: MAC ID, DH Group ID, Public Key ID, and ADE + type. The initial namespace populations are as follows. + + MAC ID Namespace: + + o 0x01 : HMAC_SHA1_128 + o 0x02 : HMAC_SHA256_128 + + DH Group ID Namespace: + + o 0x00 : NONE + o 0x01 : IANA DH Group 14 + o 0x02 : IANA DH Group 15 + o 0x03 : NIST ECC Group P-256 + + + + + + + + + + +Clancy & Arbaugh Informational [Page 23] + +RFC 4746 EAP-PAX November 2006 + + + Public Key ID Namespace: + + o 0x00 : NONE + o 0x01 : RSAES-OAEP + o 0x02 : RSA-PKCS1-V1_5 + o 0x03 : El-Gamal Over NIST ECC Group P-256 + + ADE Type Namespace: + + o 0x01 : Vendor Specific + o 0x02 : Client Channel Binding Data + o 0x03 : Server Channel Binding Data + + Allocation of values for these namespaces shall be reviewed by a + Designated Expert appointed by the IESG. The Designated Expert will + post a request to the EAP WG mailing list (or a successor designated + by the Designated Expert) for comment and review, including an + Internet-Draft. Before a period of 30 days has passed, the + Designated Expert will either approve or deny the registration + request and publish a notice of the decision to the EAP WG mailing + list or its successor, as well as informing IANA. A denial notice + must be justified by an explanation and, in the cases where it is + possible, concrete suggestions on how the request can be modified so + as to become acceptable. + +6. Acknowledgments + + The authors would like to thank Jonathan Katz for discussion with + respect to provable security, Bernard Aboba for technical guidance, + Jari Arkko for his expert review, and Florent Bersani for 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 + + [FIPS180] National Institute for Standards and Technology, "Secure + Hash Standard", Federal Information Processing Standard + 180-2, August 2002. + + [FIPS186] National Institute for Standards and Technology, + "Digital Signature Standard (DSS)", Federal Information + Processing Standard 186, May 1994. + + [FIPS198] National Institute for Standards and Technology, "The + Keyed-Hash Message Authentication Code (HMAC)", Federal + Information Processing Standard 198, March 2002. + + + +Clancy & Arbaugh Informational [Page 24] + +RFC 4746 EAP-PAX November 2006 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by + an On-line Database", RFC 3232, January 2002. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [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. + + [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The + Network Access Identifier", RFC 4282, December 2005. + + [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and + Attributes Supporting Authentication in Point-to-Point + Protocol (PPP) and Wireless Local Area Networks (WLAN)", + RFC 4334, February 2006. + + [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 + + [IETF.KEY] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. + Levkowetz, "Extensible Authentication Protocol (EAP) Key + Management Framework", Work in Progress. + + + + + + + + +Clancy & Arbaugh Informational [Page 25] + +RFC 4746 EAP-PAX November 2006 + + + [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. + + [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC + 2631, June 1999. + + [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For + Public Keys Used For Exchanging Symmetric Keys", BCP 86, + RFC 3766, April 2004. + + [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible + Authentication Protocol (EAP) Method Requirements for + Wireless LANs", RFC 4017, March 2005. + + [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) + Authentication Protocol", RFC 4252, January 2006. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clancy & Arbaugh Informational [Page 26] + +RFC 4746 EAP-PAX November 2006 + + +Appendix A. Key Generation from Passwords + + If a 128-bit key is not available to bootstrap the authentication + process, then one must be generated from some sort of weak preshared + key. Note that the security of the hashing process is unimportant, + as long as it does not significantly decrease the password's entropy. + Resistance to dictionary attacks is provided by PAX_SEC. + Consequently, computing the SHA-1 of the password and truncating the + output to 128 bits is RECOMMENDED as a means of converting a weak + password to a key for provisioning. + + When using other preshared credentials, such as a Kerberos Data + Encryption Standard (DES) key, or an MD4-hashed Microsoft Challenge + Handshake Authentication Protocol (MSCHAP) password, to provision + clients, these keys SHOULD still be put through SHA-1 before being + used. This serves to protect the credentials from possible + compromise, and also keeps things uniform. As an example, consider + provisioning using an existing Kerberos credential. The initial key + computation could be SHA1_128(string2key(password)). The KDC, + storing string2key(password), would also be able to compute this + initial key value. + +Appendix B. 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 IEEE 802.11i authentication. The second + describes how to use EAP-PAX for device authentication in a 3G-style + mobile phone network. + +B.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 IEEE 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 Network Access Identifier (NAI) have + + + + +Clancy & Arbaugh Informational [Page 27] + +RFC 4746 EAP-PAX November 2006 + + + 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 password. 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 to generate a key verifiable by the server. It is suggested + that this key then 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 keys. 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. + +B.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 B.1 could be + used. + + Provisioning could easily be accomplished by issuing customers a 6- + digit PIN they could type into their phone's keypad. + + + + + + + + + + + + + + + +Clancy & Arbaugh Informational [Page 28] + +RFC 4746 EAP-PAX November 2006 + + +Authors' Addresses + + T. Charles Clancy + DoD Laboratory for Telecommunications Sciences + 8080 Greenmeade Drive + College Park, MD 20740 + USA + + EMail: clancy@ltsnet.net + + + William A. Arbaugh + University of Maryland + Department of Computer Science + College Park, MD 20742 + USA + + EMail: waa@cs.umd.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clancy & Arbaugh Informational [Page 29] + +RFC 4746 EAP-PAX November 2006 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2006). + + 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. + + 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, THE IETF TRUST, + 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + +Clancy & Arbaugh Informational [Page 30] + |