idnits 2.17.1 draft-clancy-eap-pax-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1299. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1, 2006) is 6446 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 436 -- Looks like a reference, but probably isn't: '2' on line 438 -- Looks like a reference, but probably isn't: '3' on line 440 -- Looks like a reference, but probably isn't: '4' on line 442 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS198' ** Downref: Normative reference to an Informational RFC: RFC 3232 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-14 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clancy 3 Internet-Draft LTS 4 Expires: March 5, 2007 W. Arbaugh 5 UMD 6 September 1, 2006 8 EAP Password Authenticated Exchange 9 draft-clancy-eap-pax-11 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 5, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines an Extensible Authentication Protocol method 43 called EAP-PAX (Password Authenticated eXchange). This method is a 44 lightweight shared-key authentication protocol with optional support 45 for key provisioning, key management, identity protection, and 46 authenticated data exchange. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Language Requirements . . . . . . . . . . . . . . . . . . 4 52 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.1. PAX_STD Protocol . . . . . . . . . . . . . . . . . . . . . 7 55 2.2. PAX_SEC Protocol . . . . . . . . . . . . . . . . . . . . . 8 56 2.3. Authenticated Data Exchange . . . . . . . . . . . . . . . 10 57 2.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 11 58 2.5. Verification Requirements . . . . . . . . . . . . . . . . 12 59 2.6. PAX Key Derivation Function . . . . . . . . . . . . . . . 13 60 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 13 61 3.1. Header Specification . . . . . . . . . . . . . . . . . . . 14 62 3.1.1. Op-Code . . . . . . . . . . . . . . . . . . . . . . . 14 63 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 64 3.1.3. MAC ID . . . . . . . . . . . . . . . . . . . . . . . . 15 65 3.1.4. DH Group ID . . . . . . . . . . . . . . . . . . . . . 15 66 3.1.5. Public Key ID . . . . . . . . . . . . . . . . . . . . 16 67 3.1.6. Mandatory to Implement . . . . . . . . . . . . . . . . 16 68 3.2. Payload Formatting . . . . . . . . . . . . . . . . . . . . 17 69 3.3. Authenticated Data Exchange (ADE) . . . . . . . . . . . . 19 70 3.4. Integrity Check Value (ICV) . . . . . . . . . . . . . . . 20 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 72 4.1. Server Certificates . . . . . . . . . . . . . . . . . . . 20 73 4.2. Server Security . . . . . . . . . . . . . . . . . . . . . 21 74 4.3. EAP Security Claims . . . . . . . . . . . . . . . . . . . 21 75 4.3.1. Protected Ciphersuite Negotiation . . . . . . . . . . 21 76 4.3.2. Mutual Authentication . . . . . . . . . . . . . . . . 22 77 4.3.3. Integrity Protection . . . . . . . . . . . . . . . . . 22 78 4.3.4. Replay Protection . . . . . . . . . . . . . . . . . . 22 79 4.3.5. Confidentiality . . . . . . . . . . . . . . . . . . . 22 80 4.3.6. Key Derivation . . . . . . . . . . . . . . . . . . . . 22 81 4.3.7. Key Strength . . . . . . . . . . . . . . . . . . . . . 22 82 4.3.8. Dictionary Attack Resistance . . . . . . . . . . . . . 23 83 4.3.9. Fast Reconnect . . . . . . . . . . . . . . . . . . . . 23 84 4.3.10. Session Independence . . . . . . . . . . . . . . . . . 23 85 4.3.11. Fragmentation . . . . . . . . . . . . . . . . . . . . 23 86 4.3.12. Channel Binding . . . . . . . . . . . . . . . . . . . 23 87 4.3.13. Cryptographic Binding . . . . . . . . . . . . . . . . 24 88 4.3.14. Negotiation Attack Prevention . . . . . . . . . . . . 24 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 25 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 93 7.2. Informative References . . . . . . . . . . . . . . . . . . 26 94 Appendix A. Key Generation from Passwords . . . . . . . . . . . . 27 95 Appendix B. Implementation Suggestions . . . . . . . . . . . . . 27 96 B.1. WiFi Enterprise Network . . . . . . . . . . . . . . . . . 27 97 B.2. Mobile Phone Network . . . . . . . . . . . . . . . . . . . 28 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 99 Intellectual Property and Copyright Statements . . . . . . . . . . 30 101 1. Introduction 103 EAP-PAX (Password Authenticated eXchange) is an EAP method [RFC3748] 104 designed for authentication using a shared key. It makes use of two 105 separate subprotocols, PAX_STD and PAX_SEC. PAX_STD is a simple, 106 lightweight protocol for mutual authentication using a shared key, 107 supporting Authenticated Data Exchange (ADE). PAX_SEC complements 108 PAX_STD by providing support for shared key provisioning and identity 109 protection using a server-side public key. 111 The idea motivating EAP-PAX is a desire for device authentication 112 bootstrapped by a simple Personal Identification Number (PIN). If a 113 weak key is used or a expiration period has elapsed, the 114 authentication server forces a key update. Rather than using a 115 symmetric key exchange, the client and server perform a Diffie- 116 Hellman key exchange which provides forward secrecy. 118 Since implementing a Public Key Infrastructure (PKI) can be 119 cumbersome, PAX_SEC defines multiple client security policies, 120 selectable based on one's threat model. In the weakest mode, PAX_SEC 121 allows the use of raw public keys completely eliminating the need for 122 a PKI. In the strongest mode, PAX_SEC requires that EAP servers use 123 certificates signed by a trusted Certification Authority (CA). In 124 the weaker modes, during provisioning PAX_SEC is vulnerable to a man- 125 in-the-middle dictionary attack. In the strongest mode, EAP-PAX is 126 provably secure under the Random Oracle model. 128 EAP-PAX supports the generation of strong key material; mutual 129 authentication; resistance to desynchronization, dictionary, and man- 130 in-the-middle attacks; ciphersuite extensibility with protected 131 negotiation; identity protection; and the authenticated exchange of 132 data, useful for implementing channel binding. These features 133 satisfy the EAP method requirements for wireless LANs [RFC4017], 134 making EAP-PAX ideal for wireless environments such as IEEE 802.11 135 [IEEE.80211]. 137 1.1. Language Requirements 139 In this document, several words are used to signify the requirements 140 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 141 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 142 and "OPTIONAL" in this document are to be interpreted as described in 143 [RFC2119]. 145 1.2. Terminology 147 This section describes the various variables and functions used in 148 the EAP-PAX protocol. They will be referenced frequently in later 149 sections. 151 Variables: 153 CID 154 User-supplied client ID, specified as a Network Access Identifier 155 (NAI) [RFC4282], restricted to 65535 octets 156 g 157 public Diffie-Hellman generator, typically the integer 2 [RFC2631] 158 M 159 128-bit random integer generated by the server 160 N 161 128-bit random integer generated by the client 162 X 163 256-bit random integer generated by the server 164 Y 165 256-bit random integer generated by the client 167 Keys: 169 AK 170 authentication key shared between the client and EAP server 171 AK' 172 new authentication key generated during a key update 173 CertPK 174 EAP server's certificate containing public key PK 175 CK 176 Confirmation Key generated from the MK and used during 177 authentication to prove knowledge of AK 178 EMSK 179 Extended Master Session Key also generated from the MK and 180 contains additional keying material 181 IV 182 Initialization Vector used to seed ciphers; exported to the 183 authenticator 184 MID 185 Method ID used to construct the EAP Session ID and consequently 186 name all the exported keys [I-D.ietf-eap-keying] 187 MK 188 Master Key between the client and EAP server from which all other 189 EAP method session keys are derived 190 MSK 191 Master Session Key generated from the MK and exported by the EAP 192 method to the authenticator 194 PK 195 EAP server's public key 197 Operations: 199 enc_X(Y) 200 encryption of message Y with public key X 201 MAC_X(Y) 202 keyed message authentication code computed over message Y with 203 symmetric key X 204 PAX-KDF-W(X, Y, Z) 205 PAX Key Derivation Function computed using secret X, identifier Y, 206 and seed Z, and producing W octets of output. 207 || 208 string or binary data concatenation 210 2. Overview 212 The EAP framework [RFC3748] defines four basic steps that occur 213 during the execution of an EAP conversation between client and 214 server. The first phase, discovery, is handled by the underlying 215 link-layer protocol. The authentication phase is defined here. The 216 key distribution and secure association phases are handled 217 differently depending on the underlying protocol, and are not 218 discussed in this document. 220 +--------+ +--------+ 221 | | EAP-Request/Identity | | 222 | CLIENT |<------------------------------------| SERVER | 223 | | | | 224 | | EAP-Response/Identity | | 225 | |------------------------------------>| | 226 | | | | 227 | | EAP-PAX (STD or SEC) | | 228 | |<----------------------------------->| | 229 | | ... ... | | 230 | |<----------------------------------->| | 231 | | | | 232 | | EAP-Success or EAP-Failure | | 233 | |<------------------------------------| | 234 +--------+ +--------+ 236 Figure 1: EAP-PAX Packet Exchanges 238 There are two distinct subprotocols that can be executed. The first, 239 PAX_STD, is used during typical authentications. The second, PAX_SEC 240 provides more secure features such as key provisioning and identity 241 protection. 243 PAX_STD and PAX_SEC have two modes of operation. When an AK update 244 is being performed, the client and server exchange Diffie-Hellman 245 exponents g^X and g^Y which are computed modulo prime P or over an 246 elliptic curve multiplicative group. When no update is being 247 performed, and only session keys are being derived, X and Y are 248 exchanged. Using Diffie-Hellman during the key update provides 249 forward secrecy, and secure key derivation when a weak provisioned 250 key is used. 252 The main deployment difference between PAX_STD and PAX_SEC is that 253 PAX_SEC requires a server-side public key. More specifically, that 254 means a private key known only to the server with corresponding 255 public key being transmitted to the client during each PAX_SEC 256 session. For every authentication, the client is required to compute 257 computationally intensive public-key operations. PAX_STD on the 258 other hand uses purely symmetric operations, other than a possible 259 Diffie-Hellman exchange. 261 Each of the protocols are now defined. 263 2.1. PAX_STD Protocol 265 PAX_STD is a simple nonce-based authentication using the strong long- 266 term key. The client and server each exchange 256 bits of random 267 data which is used to seed the PAX-KDF for generation of session 268 keys. The randomly exchanged data in the protocol differs depending 269 on whether a key update is being performed. If no key update is 270 being performed, then let: 272 o A = X 273 o B = Y 274 o E = X || Y 276 Thus A and B are 256-bit values and E is their 512-bit concatenation. 277 To provide forward secrecy and security, let the following be true 278 when a key update is being performed: 280 o A = g^X 281 o B = g^Y 282 o E = g^(XY) 284 Here A and B are Diffie-Hellman exponents whose length is determined 285 by the Diffie-Hellman group size. The value A is data transmitted 286 from the server to the client, and B is data transmitted from the 287 client to the server. The value E is the entropy computed by each 288 that is used in section 2.4 to perform key derivation. 290 The full protocol is as follows: 292 o PAX_STD-1 : client <- server : A 293 o PAX_STD-2 : client -> server : B, CID, MAC_CK(A, B, CID), 294 [optional ADE] 295 o PAX_STD-3 : client <- server : MAC_CK(B, CID), [optional ADE] 296 o PAX-ACK : client -> server : [optional ADE] 298 See Section 2.3 for more information on the ADE component, and 299 Section 2.4 for the key derivation process, including derivation of 300 CK. 302 2.2. PAX_SEC Protocol 304 PAX_SEC is the high-security protocol designed to provide identity 305 protection and support for provisioning. PAX_SEC requires a server- 306 side public key, and public key operations for every authentication. 308 PAX_SEC can be performed with and without key update. Let A, B, and 309 E be defined as in the previous section. 311 The exchanges for PAX_SEC are as follows: 313 o PAX_SEC-1 : client <- server : M, PK or CertPK 314 o PAX_SEC-2 : client -> server : Enc_PK(M, N, CID) 315 o PAX_SEC-3 : client <- server : A, MAC_N(A, CID) 316 o PAX_SEC-4 : client -> server : B, MAC_CK(A, B, CID), [optional 317 ADE] 318 o PAX_SEC-5 : client <- server : MAC_CK(B, CID), [optional ADE] 319 o PAX-ACK : client -> server : [optional ADE] 321 See Section 2.3 for more information on the ADE component, and 322 Section 2.4 for the key derivation process, including derivation of 323 CK. 325 Use of CertPK is optional in PAX_SEC, however careful consideration 326 should be given before omitting the CertPK. The following table 327 describes the risks involved when using PAX_SEC without a 328 certificate. 330 Certificate | Provisioning | Identity 331 Mode | | Protection 332 ==================+=====================+====================== 333 No Certificate | MiTM offline | ID reveal attack 334 | dictionary attack | 335 ------------------+---------------------+--------------------- 336 Self-Signed | MiTM offline | ID reveal attack 337 Certificate | dictionary attack | 338 ------------------+---------------------+--------------------- 339 Certificate/PK | MiTM offline | ID reveal attack 340 Caching | dictionary attack | during first auth 341 ------------------+---------------------+--------------------- 342 CA-Signed | secure mutual | secure mutual 343 Certificate | authentication | authentication 345 Figure 2: Table of different security modes 347 When using PAX_SEC to support provisioning with a weak key, use of a 348 CA-signed certificate is RECOMMENDED. When not using a CA-signed 349 certificate, the initial authentication is vulnerable to an offline 350 man-in-the-middle dictionary attack. 352 When using PAX_SEC to support identity protection, use of either a 353 CA-signed certificate or key caching is RECOMMENDED. Caching 354 involves a client recording the public key of the EAP server and 355 verifying its consistency between sessions, similar to SSH [RFC4252]. 356 Otherwise, an attacker can spoof an EAP server during a session and 357 gain knowledge of a client's identity. 359 Whenever certificates are used, clients MUST validate that the 360 certificate's extended key usage, KeyPurposeID, is either 361 "eapOverPPP" or "eapOverLAN" [RFC3280][RFC4334]. If the underlying 362 EAP transport protocol is known, then the client MUST differentiate 363 between these values. For example, an IEEE 802.11 supplicant SHOULD 364 require KeyPurposeID == eapOverLAN. By not distinguishing, a client 365 could accept as valid an unauthorized server certificate. 367 When using EAP-PAX with Wireless LAN, clients SHOULD validate that 368 the certificate's wlanSSID extension matches the SSID of the network 369 to which it is currently authenticating. 371 In order to facilitate discussion of packet validations, three client 372 security policies for PAX_SEC are defined. 374 open 375 Clients support both use of PK and CertPK. If CertPK is used, the 376 client MUST validate the KeyPurposeID. 377 caching 378 Clients save PK for each EAP server the first time it encounters 379 the server, and SHOULD NOT authenticate to EAP servers whose 380 public key has been changed. If CertPK is used, the client MUST 381 validate the KeyPurposeID. 382 strict 383 In strict mode, clients require servers to present a valid 384 certificate signed by a trusted CA. As with the other modes, the 385 KeyPurposeID MUST be validated. 387 Servers SHOULD support the PAX_SEC mode of operation, and SHOULD 388 support both the use of PK and CertPK with PAX_SEC. Clients MUST 389 support PAX_SEC, and MUST be capable of accepting both raw public 390 keys and certificates from the server. Local security policy will 391 define which forms of key or certificate authentications are 392 permissible. Default configurations SHOULD require a minimum of the 393 caching security policy, and MAY require strict. 395 The ability to perform key management on the AK is built in to EAP- 396 PAX through the use of AK'. However, key management of the server 397 public key is beyond the scope of this document. If self-signed 398 certificates are used, the deployers should be aware that expired 399 certificates may be difficult to replace when the caching security 400 mode is used. 402 See Section 4 for further discussion on security considerations. 404 2.3. Authenticated Data Exchange 406 Messages PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK 407 contain optional component ADE. This component is used to convey 408 authenticated data between the client and server during the 409 authentication. 411 The Authenticated Data Exchanged can be used in a variety of ways, 412 including the implementation of channel bindings. Channel bindings 413 allow link-layer network properties to be securely validated by the 414 EAP client and server during the authentication session. 416 It is important to note that ADE is not encrypted, so any data 417 included will not be confidential. However, since these packets are 418 all protected by the ICV, authenticity is guaranteed. 420 The ADE element consists of an arbitrary number of subelements, each 421 with length and type specified. If the number and size of 422 subelements is too large, packet fragmentation will be necessary. 423 Vendor-specific options are supported. See section 3.3. 425 Note that more than 1.5 round trips may be necessary to execute a 426 particular authenticated protocol within EAP-PAX. In this case, 427 instead of sending an EAP-Success after receiving the PAX_ACK, the 428 server can continue sending PAX_ACK messages with attached elements. 429 The client responds to these PAX_ACK messages with PAX_ACK messages 430 possibly containing more ADE elements. Such an execution could look 431 something like the following: 433 +--------+ +--------+ 434 | | PAX_STD-1 | | 435 | |<------------------------------------| | 436 | | PAX_STD-2(ADE[1]) | | 437 | |------------------------------------>| | 438 | | PAX_STD-3(ADE[2]) | | 439 | |<------------------------------------| | 440 | | PAX_ACK(ADE[3]) | | 441 | |------------------------------------>| | 442 | | PAX_ACK(ADE[4]) | | 443 | |<------------------------------------| | 444 | | | | 445 | | ... | | 446 | | | | 447 | | PAX_ACK(ADE[i]) | | 448 | |------------------------------------>| | 449 | | PAX_ACK(ADE[i+1]) | | 450 | |<------------------------------------| | 451 | | | | 452 | | ... | | 453 | | | | 454 | | EAP-Success or EAP-Failure | | 455 | |<------------------------------------| | 456 +--------+ +--------+ 458 Figure 3: Extended diagram of EAP-PAX packet exchanges 460 2.4. Key Derivation 462 Keys are derived independently of which authentication mechanism was 463 used. The process uses the entropy value E computed as described 464 above. Session and authentication keys are computed as follows: 466 o AK' = PAX-KDF-16(AK, "Authentication Key", E) 467 o MK = PAX-KDF-16(AK, "Master Key", E) 468 o CK = PAX-KDF-16(MK, "Confirmation Key", E) 469 o ICK = PAX-KDF-16(MK, "Integrity Check Key", E) 470 o MID = PAX-KDF-16(MK, "Method ID", E) 471 o MSK = PAX-KDF-64(MK, "Master Session Key", E) 472 o EMSK = PAX-KDF-64(MK, "Extended Master Session Key", E) 473 o IV = PAX-KDF-64(0x00^16, "Initialization Vector", E) 475 The IV is computed using a 16-octet NULL key. The value of AK' is 476 only used to replace AK if a key update is being performed. The EAP 477 Method ID is represented in ASCII as 32 hexadecimal characters 478 without any octet delimiters such as colons or dashes. 480 The EAP Key Management Framework [I-D.ietf-eap-keying] recommends 481 specification of key names and scope. The EAP-PAX Method-ID is the 482 MID value computed as described above. The EAP peer name is the CID 483 value exchanged in PAX_STD-2 and PAX_SEC-2. The EAP server name is 484 an empty string. 486 2.5. Verification Requirements 488 In order for EAP-PAX to be secure, MACs must be properly verified 489 each step of the way. Any packet with an ICV (see section 3.3) that 490 fails validation must be silently discarded. After ICV validation, 491 the following checks must be performed: 493 PAX_STD-2 494 The server MUST validate the included MAC, as it serves to 495 authenticate the client to the server. If this validation fails, 496 the server MUST send an EAP-Failure message. 497 PAX_STD-3 498 The client MUST validate the included MAC, as it serves to 499 authenticate the server to the client. If this validation fails, 500 the client MUST send an EAP-Failure message. 501 PAX_SEC-1 502 The client MUST validate PK or CertPK in a manner specified by its 503 local security policy (see section 2.2). If this validation 504 fails, the client MUST send an EAP-Failure message. 505 PAX_SEC-2 506 The server MUST verify that the decrypted value of M matches the 507 value transmitted in PAX_SEC-1. If this validation fails, the 508 server MUST send an EAP-Failure message. 509 PAX_SEC-3 510 The client MUST validate the included MAC, as it serves to prevent 511 replay attacks. If this validation fails, the client MUST send an 512 EAP-Failure message. 514 PAX_SEC-4 515 The server MUST validate the included MAC, as it serves to 516 authenticate the client to the server. If this validation fails, 517 the server MUST send an EAP-Failure message. 518 PAX_SEC-5 519 The client MUST validate the included MAC, as it serves to 520 authenticate the server to the client. If this validation fails, 521 the client MUST send an EAP-Failure message. 522 PAX-ACK 523 If PAX-ACK is received in response to a message fragment, the 524 receiver continues the protocol execution. If PAX-ACK is received 525 in response to PAX_STD-3 or PAX_SEC-5, then the server MUST send 526 an EAP-Success message. This indicates a successful execution of 527 PAX. 529 2.6. PAX Key Derivation Function 531 The PAX-KDF is a secure key derivation function used to generate 532 various keys from the provided entropy and shared key. 534 PAX-KDF-W(X, Y, Z) 536 W length, in octets, of the desired output 537 X secret key used to protect the computation 538 Y public identifier for the key being derived 539 Z exchanged entropy used to seed the KDF 541 Let's define some variables and functions: 543 o M_i = MAC_X(Y || Z || i), where i is an 8-bit unsigned integer 544 o L = ceiling(W/16) 545 o F(A, B) = first A octets of binary data B 547 We define PAX-KDF-W(X, Y, Z) = F(W, M_1 || M_2 || ... || M_L). 549 Consequently for the two values of W used in this draft, we have: 551 o PAX-KDF-16(X, Y, Z) = MAC_X(Y || Z || 0x01) 552 o PAX-KDF-64(X, Y, Z) = MAC_X(Y || Z || 0x01) || MAC_X(Y || Z || 553 0x02) || MAC_X(Y || Z || 0x03) || MAC_X(Y || Z || 0x04) 555 The MAC used in the PRF is extensible, and is the same MAC used in 556 the rest of the protocol. It is specified in the EAP-PAX header. 558 3. Protocol Specification 560 In this section, the packet format and content for the EAP-PAX 561 messages are defined. 563 EAP-PAX packets have the following structure: 565 --- bit offset ---> 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Code | Identifier | Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type | OP-Code | Flags | MAC ID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | DH Group ID | Public Key ID | | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 575 | | 576 ... Payload ... 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 ... ICV ... 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Figure 4: EAP-PAX packet structure 586 3.1. Header Specification 588 The Code, Identifier, Length, and Type fields are all part of the EAP 589 header, and defined in [RFC3748]. IANA has allocated EAP Method Type 590 46 for EAP-PAX, thus the Type field in the EAP header MUST be 46. 592 3.1.1. Op-Code 594 The OP-Code field is one of the following values: 596 o 0x01 : PAX_STD-1 597 o 0x02 : PAX_STD-2 598 o 0x03 : PAX_STD-3 599 o 0x11 : PAX_SEC-1 600 o 0x12 : PAX_SEC-2 601 o 0x13 : PAX_SEC-3 602 o 0x14 : PAX_SEC-4 603 o 0x15 : PAX_SEC-5 604 o 0x21 : PAX-ACK 606 3.1.2. Flags 608 The flags field is broken up into 8 bits each representing a binary 609 flag. The field is defined as the Logical OR of the following 610 values: 612 o 0x01 : more fragments (MF) 613 o 0x02 : certificate enabled (CE) 614 o 0x04 : ADE Included (AI) 615 o 0x08 - 0x80 : reserved 617 The MF flag is set if the current packet required fragmentation, and 618 further fragments need to be transmitted. If a packet does not 619 require fragmentation, the MF flag is not set. 621 When a payload requires fragmentation, each fragment is transmitted, 622 and the receiving party responds with a PAX-ACK packet for each 623 received fragment. 625 When using PAX_STD, the CE flag MUST be zero. When using PAX_SEC, 626 the CE flag MUST be set if PAX_SEC-1 includes CertPK. It MUST NOT be 627 set if PAX_SEC-1 includes PK. If CE is set in PAX_SEC-1, it MUST be 628 set in PAX_SEC-2, PAX_SEC-3, PAX_SEC-4, and PAX_SEC-5. If either 629 party detects an inconsistent value of the CE flag, he MUST send an 630 EAP-Failure message and discontinue the session. 632 The AI flag indicates the presence of an ADE element. AI MUST only 633 be set on packets on packets PAX_STD-2, PAX_STD-3, PAX_SEC-4, 634 PAX_SEC-5, and PAX_ACK if an ADE element is included. On packets of 635 other types, ADE elements MUST be silently discarded as they cannot 636 be authenticated. 638 3.1.3. MAC ID 640 The MAC field specifies the cryptographic hash used to generate the 641 keyed hash value. The following are currently supported: 643 o 0x01 : HMAC_SHA1_128 [FIPS198] [FIPS180] 644 o 0x02 : HMAC_SHA256_128 [FIPS180] 646 3.1.4. DH Group ID 648 The Diffie-Hellman group field specifies the group used in the 649 Diffie-Hellman computations. The following are currently supported: 651 o 0x00 : NONE (iff not performing a key update) 652 o 0x01 : 2048-bit MODP Group (IANA DH Group 14) [RFC3526] 653 o 0x02 : 3072-bit MODP Group (IANA DH Group 15) [RFC3526] 654 o 0x03 : NIST ECC Group P-256 [FIPS186] 656 If no key update is being performed, the DH Group ID field MUST be 657 zero. Otherwise, the DH Group ID field MUST NOT be zero. 659 3.1.5. Public Key ID 661 The public key ID field specifies the cipher used to encrypt the 662 client's EAP-Response in PAX_SEC-2. 664 The following are currently supported: 666 o 0x00 : NONE (iff using PAX_STD) 667 o 0x01 : RSAES-OAEP [RFC3447] 668 o 0x02 : RSA-PKCS1-V1_5 [RFC3447] 669 o 0x03 : El-Gamal Over NIST ECC Group P-256 [FIPS186] 671 If PAX_STD is being executed, the Public Key ID field MUST be zero. 672 If PAX_SEC is being executed, the Public Key ID field MUST NOT be 673 zero. 675 When using RSAES-OAEP, the hash algorithm and mask generation 676 algorithm used SHALL be the MAC specified by the MAC ID, keyed using 677 an all-zero key. The label SHALL be null. 679 The RSA-based schemes specified here do not dictate the length of the 680 public keys. DER encoding rules will specify the key size in the key 681 or certificate [X.690]. Key sizes SHOULD be used that reflect the 682 desired level of security. 684 3.1.6. Mandatory to Implement 686 The following ciphersuite is mandatory to implement, achieves roughly 687 112 bits of security: 689 o HMAC_SHA1_128 690 o IANA DH Group 14 (2048 bits) 691 o RSA-PKCS1-V1_5 (RECOMMEND 2048-bit public key) 693 The following ciphersuite is RECOMMENDED and achieves 128 bits of 694 security: 696 o HMAC_SHA256_128 697 o IANA DH Group 15 (3072 bits) 698 o RSAES-OAEP (RECOMMEND 3072-bit public key) 700 3.2. Payload Formatting 702 This section describes how to format the payload field. Depending on 703 the packet type, different values are transmitted. Sections 2.1 and 704 2.2 define the fields, and in what order they are to be concatenated. 705 For simplicity and since many field lengths can vary with the 706 ciphersuite, each value is prepended with a two-octet length value 707 encoded as an integer as described below. This length field MUST 708 equal the length in octets of the subsequent value field. 710 --- octet offset ---> 711 0 1 712 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 713 +---+--------------------- 714 |len| value .... 715 +---+-------- 717 Figure 5: Length encoding for data elements 719 All integer values are stored as octet arrays in network-byte order, 720 with the most significant octet first. Integers are padded on the 721 most significant end to reach octet boundaries. 723 Public keys and certificates SHALL be in X.509 format [RFC3280] 724 encoded using the Distinguished Encoding Rules (DER) format [X.690]. 726 Strings are not null-terminated and are encoded using UTF-8. Binary 727 data, such as message authentication codes, are transmitted as-is. 729 MACs are computed by concatenating the specified values in the 730 specified order. Note that for MACs, length fields are not included, 731 though the resulting MAC will itself have a length field. Values are 732 encoded as described above, except that no length field is specified. 734 To illustrate this process, an example is presented. What follows is 735 the encoding of the payload for PAX_STD-2. The three basic steps 736 will be computing the MAC, forming the payload, and encrypting the 737 payload. 739 To create the MAC, we first need to form the buffer that will be 740 MACed. For this example, assume no key update is being done and 741 HMAC_SHA1_128 is used such that the result will be a 16-octet value. 743 --- octet offset ---> 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | 32-octet integer A | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | 32-octet integer B | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | | 752 ... variable length CID ... 753 | | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 || 757 || 758 CK --> MAC 759 || 760 \/ 762 --- octet offset ---> 763 0 1 764 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | 16-octet MAC output | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Figure 6: Example encoding of PAX_STD-2 MAC data 771 With this, we can now create the encoded payload: 773 --- octet offset ---> 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 |32 | 32-octet integer B 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | L | | 780 +-+-+-+-+ + 781 | | 782 ... L-octet CID ... 783 | | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 |16 | MAC computed above | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 Figure 7: Example encoding of PAX_STD-2 packet 790 These 52+L octets are then attached to the packet as the payload. 792 The ICV is then computed by MACing the packet headers and payload, 793 and appended after the payload (see Section 3.4). 795 3.3. Authenticated Data Exchange (ADE) 797 This section describes the formatting of the ADE elements. ADE 798 elements can only occur on packets of type PAX_STD-2, PAX_STD-3, 799 PAX_SEC-4, PAX_SEC-5, and PAX_ACK. Values included in other packets 800 MUST be silently ignored. 802 The ADE element is preceded by its two-octet length L. Each 803 subelement has first a two-octet length Li followed by a two-octet 804 type Ti. The entire ADE element looks as follows: 806 --- octet offset ---> 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | L |L1 |T1 | | 811 +-+-+-+-+-+-+ + 812 | | 813 ... subADE-1, type T1, length L1 ... 814 | | 815 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | |L2 |T2 | | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 818 | | 819 ... subADE-2, type T2, length L2 ... 820 | | 821 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | | more subADE elements... ... 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 Figure 8: Encoding of ADE components 827 The following type values have been allocated: 829 o 0x01 : Vendor Specific 830 o 0x02 : Client Channel Binding Data 831 o 0x03 : Server Channel Binding Data 833 The first three octets of a subADE utilizing type code 0x01 must be 834 the vendor's Enterprise Number [RFC3232] as registered with IANA. 835 The format for such a subADE is as follows: 837 --- octet offset ---> 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 |Li | 1 | ENi | | 842 +-+-+-+-+-+-+-+ + 843 | | 844 ... subADE-i, type Vendor Specific , length Li, vendor ENi ... 845 | | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Figure 9: Encoding of vendor-specific ADE 850 Channel binding subADEs have yet to be defined. Future IETF 851 documents will specify the format for these subADE fields. 853 3.4. Integrity Check Value (ICV) 855 The ICV is computed as the MAC over the entire EAP packet, including 856 the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC 857 is keyed using the 16-octet ICK, using the MAC type specified by the 858 MAC ID in the EAP-PAX header. For packets of type PAX_STD-1, 859 PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3, where the MK has not yet been 860 derived, the MAC is keyed using a zero-octet NULL key. 862 If the ICV field is incorrect, the receiver MUST silently discard the 863 packet. 865 4. Security Considerations 867 Any authentication protocol, especially one geared for wireless 868 environments, must assume adversaries have many capabilities. In 869 general, one must assume that all messages between the client and 870 server are delivered via the adversary. This allows passive 871 attackers to eavesdrop on all traffic, while active attackers can 872 modify data in any way before delivery. 874 In this section, we discuss the security properties and requirements 875 of EAP-PAX with respect to this threat model. Also note that the 876 security of PAX can be proved using under the Random Oracle model. 878 4.1. Server Certificates 880 PAX_SEC can be used in several configurations. It can be used with 881 or without a server-side certificate. Section 2.2 details the 882 possible modes and the resulting security risk. 884 When using PAX_SEC for identity protection and not using a CA-signed 885 certificate, an attacker can convince a client to reveal his 886 username. To achieve this, an attacker can simply forge a PAX_SEC-1 887 message and send it to the client. The client would respond with a 888 PAX_SEC-2 message containing his encrypted username. The attacker 889 can then use his associated private key to decrypt the client's 890 username. Use of key caching can reduce the risk of identity 891 revelation by allowing clients to detect when the EAP server to which 892 they are accustom has a different public key. 894 When provisioning with PAX_SEC and not using a CA-signed certificate, 895 an attacker could first forge a PAX_SEC-1 message and send it to the 896 client. The client would respond with a PAX_SEC-2 message. Using 897 the decrypted value of N, an attacker could forge a PAX_SEC-3 898 message. Once the client responds with a PAX_SEC-4 message, an 899 attacker can guess values of the weak AK and compute CK = PAX-KDF(AK, 900 "Confirmation Key", g^XY). Given enough time, the attacker can 901 obtain both the old AK and new AK' and forge a responding PAX_SEC-5. 903 4.2. Server Security 905 In order to maintain a reasonable security policy, the server should 906 manage five pieces of information concerning each user. Most 907 obviously, their username and current key. Additionally, the server 908 must keep a bit that indicates whether the current key is weak. Weak 909 keys must be updated prior to key derivation. Also, the server 910 should track the date of last key update. To implement the coarse- 911 grained forward secrecy, the authentication key must be updated on a 912 regular basis, and this field can be used to expire keys. Lastly, 913 the server should track the previous key, to prevent attacks where an 914 adversary desynchronizes the key state by interfering with PAX-ACK 915 packets. See Appendix B for more suggested implementation strategies 916 that prevent key desynchronization attacks. 918 Since the client keys are stored in plaintext on the server, special 919 care should be given to the overall security of the authentication 920 server. An operating system-level attack yielding root access to an 921 intruder would result in the compromise of all client credentials. 923 4.3. EAP Security Claims 925 This section describes EAP-PAX in terms of specific security 926 terminology as required by [RFC3748]. 928 4.3.1. Protected Ciphersuite Negotiation 930 In the initial packet from the server, the server specifies the 931 ciphersuite in the packet header. The server is in total control of 932 the ciphersuite, thus a client not supporting the specified 933 ciphersuite will not be able to authenticate. Additionally, each 934 clients' local security policy should specify secure ciphersuites the 935 client will accept. The ciphersuite specified in PAX_STD-1 and 936 PAX_SEC-1 MUST remain the same in successive packets within the same 937 authentication session. Since later packets are covered by an ICV 938 keyed with the ICK, the server can verify that the originally 939 transmitted ciphersuite was not altered by an adversary. 941 4.3.2. Mutual Authentication 943 Both PAX_STD and PAX_SEC authenticate the client and the server, and 944 consequently achieve explicit mutual authentication. 946 4.3.3. Integrity Protection 948 The ICV described in Section 3.3 provides integrity protection once 949 the integrity check key has been derived. The header values in the 950 unprotected packets can be verified when an ICV is received later in 951 the session. 953 4.3.4. Replay Protection 955 EAP-PAX is inherently designed to avoid replay attacks by 956 cryptographically binding each packet to the previous one. Also the 957 EAP sequence number is covered by the ICV to further strengthen 958 resistance to replay attacks. 960 4.3.5. Confidentiality 962 With identity protection enabled, PAX_SEC provides full 963 confidentiality. 965 4.3.6. Key Derivation 967 Session keys are derived using the PAX-KDF and fresh entropy supplied 968 by both the client and the server. Since the key hierarchy is 969 derived from the shared password, only someone with knowledge of that 970 password or the capability of guessing it is capable of deriving the 971 session keys. One of the main benefits of PAX_SEC is it allows you 972 to bootstrap a strong shared secret using a weak password while 973 preventing offline dictionary attacks. 975 4.3.7. Key Strength 977 Authentication keys are 128 bits. The key generation is protected by 978 a Diffie-Hellman key exchange. It is believed that a 3000-bit MODP 979 public-key scheme is roughly equivalent [RFC3766] to a 128-bit 980 symmetric-key scheme. Consequently, EAP-PAX requires the use of a 981 Diffie-Hellman group with modulus larger than 3000. Also, the 982 exponent used as the private DH parameter must be at least twice as 983 large as the key eventually generated. Consequently, EAP-PAX uses 984 256-bit DH exponents. Thus, the authentication keys contain the full 985 128 bits of security. 987 Future ciphersuites defined for EAP-PAX MUST contain a minimum of 128 988 bits of security. 990 4.3.8. Dictionary Attack Resistance 992 EAP-PAX is resistant to dictionary attacks, except for the case where 993 a weak password is initially used and the server is not using a 994 certificate for authentication. See section 4.1 for more information 995 on resistance to dictionary attacks. 997 4.3.9. Fast Reconnect 999 While a specific fast reconnection option is not included, execution 1000 of PAX_STD requires very little computation time and is therefore 1001 bound primarily by the latency of the AAA server. 1003 4.3.10. Session Independence 1005 This protocol easily achieves backward secrecy through, among other 1006 things, use of the PAX-KDF. Given a current session key, attackers 1007 can neither discover the entropy used to generate it, nor the key 1008 used to encrypt that entropy as it was transmitted across the 1009 network. 1011 This protocol has coarse-grained forward secrecy. Compromised 1012 session keys are only useful on data for that session, and one cannot 1013 derive AK from them. If an attacker can discover AK, that value can 1014 only be used to compromise session keys derived using that AK. 1015 Reasonably frequent password updates will help mitigate such attacks. 1017 Session keys are independently generated using fresh nonces for each 1018 session, and therefore the sessions are independent. 1020 4.3.11. Fragmentation 1022 Fragmentation and reassembly is supported through the fragmentation 1023 flag in the header. 1025 4.3.12. Channel Binding 1027 EAP-PAX can be extended to support channel bindings through the use 1028 of its subADE fields. 1030 4.3.13. Cryptographic Binding 1032 EAP-PAX does not include any cryptographic binding. This is relevant 1033 only for tunneled methods. 1035 4.3.14. Negotiation Attack Prevention 1037 EAP is susceptible to an attack where an attacker uses NAKs to 1038 convince an EAP client and server to use a less secure method, and 1039 can be prevented using method-specific integrity protection on NAK 1040 messages. Since EAP-PAX does not have suitable keys derived for this 1041 integrity protection at the beginning of a PAX conversation, this is 1042 not included. 1044 5. IANA Considerations 1046 This document requires IANA to maintain the namespace for the 1047 following header fields: MAC ID, DH Group ID, Public Key ID, and ADE 1048 type. The initial namespace populations are as follows. 1050 MAC ID Namespace: 1052 o 0x01 : HMAC_SHA1_128 1053 o 0x02 : HMAC_SHA256_128 1055 DH Group ID Namespace: 1057 o 0x00 : NONE 1058 o 0x01 : IANA DH Group 14 1059 o 0x02 : IANA DH Group 15 1060 o 0x03 : NIST ECC Group P-256 1062 Public Key ID Namespace: 1064 o 0x00 : NONE 1065 o 0x01 : RSAES-OAEP 1066 o 0x02 : RSA-PKCS1-V1_5 1067 o 0x03 : El-Gamal Over NIST ECC Group P-256 1069 ADE Type Namespace: 1071 o 0x01 : Vendor Specific 1072 o 0x02 : Client Channel Binding Data 1073 o 0x03 : Server Channel Binding Data 1075 Allocation of values for these namespaces shall be reviewed by a 1076 Designated Expert appointed by the IESG. The Designated expert will 1077 post a request to the EAP WG mailing list (or a successor designated 1078 by the Designated Expert) for comment and review, including an 1079 Internet-Draft. Before a period of 30 days has passed, the 1080 Designated Expert will either approve or deny the registration 1081 request and publish a notice of the decision to the EAP WG mailing 1082 list or its successor, as well as informing IANA. A denial notice 1083 must be justified by an explanation and, in the cases where it is 1084 possible, concrete suggestions on how the request can be modified so 1085 as to become acceptable. 1087 6. Acknowledgment 1089 The authors would like to thank Jonathan Katz for discussion with 1090 respect to provable security, Bernard Aboba for technical guidance, 1091 Jari Arkko for his expert review, and Florent Bersani for feedback 1092 and suggestions. Finally, the authors would like to thank the 1093 Defense Information Systems Agency for initially funding this work. 1095 7. References 1097 7.1. Normative References 1099 [FIPS180] National Institute for Standards and Technology, "Secure 1100 Hash Standard", Federal Information Processing 1101 Standard 180-2, August 2002. 1103 [FIPS186] National Institute for Standards and Technology, "Digital 1104 Signature Standard (DSS)", Federal Information Processing 1105 Standard 186, May 1994. 1107 [FIPS198] National Institute for Standards and Technology, "The 1108 Keyed-Hash Message Authentication Code (HMAC)", Federal 1109 Information Processing Standard 198, March 2002. 1111 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1112 Requirement Levels", BCP 14, RFC 2119, March 1997. 1114 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1115 an On-line Database", RFC 3232, January 2002. 1117 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1118 X.509 Public Key Infrastructure Certificate and 1119 Certificate Revocation List (CRL) Profile", RFC 3280, 1120 April 2002. 1122 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1123 Standards (PKCS) #1: RSA Cryptography Specifications 1124 Version 2.1", RFC 3447, February 2003. 1126 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1127 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1128 RFC 3526, May 2003. 1130 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1131 Levkowetz, "Extensible Authentication Protocol (EAP)", 1132 RFC 3748, June 2004. 1134 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1135 Network Access Identifier", RFC 4282, December 2005. 1137 [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and 1138 Attributes Supporting Authentication in Point-to-Point 1139 Protocol (PPP) and Wireless Local Area Networks (WLAN)", 1140 RFC 4334, April 2005. 1142 [X.690] International Telecommunications Union, "Information 1143 technology - ASN.1 encoding rules: Specification of Basic 1144 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1145 Distinguished Encoding Rules (DER)", Data Networks and 1146 Open System Communication Recommendation X.690, July 2002. 1148 7.2. Informative References 1150 [I-D.ietf-eap-keying] 1151 Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. 1152 Levkowetz, "Extensible Authentication Protocol (EAP) Key 1153 Management Framework", draft-ietf-eap-keying-14 (work in 1154 progress), June 2006. 1156 [IEEE.80211] 1157 Institute of Electrical and Electronics Engineers, 1158 "Information technology - Telecommunications and 1159 information exchange between systems - Local and 1160 metropolitan area networks - Specific Requirements Part 1161 11: Wireless LAN Medium Access Control (MAC) and Physical 1162 Layer (PHY) Specifications", IEEE Standard 802.11-1997, 1163 1997. 1165 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1166 RFC 2631, June 1999. 1168 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1169 Public Keys Used For Exchanging Symmetric Keys", RFC 3766, 1170 April 2004. 1172 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "EAP Method 1173 Requirements for Wireless LANs", RFC 4017, March 2005. 1175 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1176 Authentication Protocol", RFC 4252, January 2006. 1178 Appendix A. Key Generation from Passwords 1180 If a 128-bit key is not available to bootstrap the authentication 1181 process, then one must be generated from some sort of weak preshared 1182 key. Note that the security of the hashing process is unimportant, 1183 as long as it does not significantly decrease the password's entropy. 1184 Resistance to dictionary attacks is provided by PAX_SEC. 1185 Consequently, computing the SHA-1 of the password and truncating the 1186 output to 128 bits is RECOMMENDED as a means of converting a weak 1187 password to a key for provisioning. 1189 When using other preshared credentials, such as a Kerberos DES key, 1190 or an MD4-hashed MSCHAP password, to provision clients, these keys 1191 SHOULD still be put through SHA-1 before being used. This serves to 1192 protect the credentials from possible compromise, and also keeps 1193 things uniform. As an example, consider provisioning using an 1194 existing Kerberos credential. The initial key computation could be 1195 SHA1_128(string2key(password)). The KDC, storing 1196 string2key(password), would also be able to compute this initial key 1197 value. 1199 Appendix B. Implementation Suggestions 1201 In this section, two implementation strategies are discussed. The 1202 first describes how best to implement and deploy EAP-PAX in an 1203 enterprise network for IEEE 802.11i authentication. The second 1204 describes how to use EAP-PAX for device authentication in a 3G-style 1205 mobile phone network. 1207 B.1. WiFi Enterprise Network 1209 For the purposes of this section, a wireless enterprise network is 1210 defined to have the following characteristics: 1212 o Users wish to obtain network access through IEEE 802.11 access 1213 points. 1214 o Users can possibly have multiple devices (laptops, PDAs, etc) they 1215 wish to authenticate. 1216 o A preexisting authentication framework already exists, for example 1217 a Microsoft Active Directory domain or a Kerberos realm. 1219 Two of the biggest challenges in an enterprise WiFi network is key 1220 provisioning and support for multiple devices. Consequently, it is 1221 recommended that the client's NAI have the format username/KID@realm, 1222 where KID is a key ID that can be used to distinguish between 1223 different devices. 1225 The client's supplicant can use a variety of sources to automatically 1226 generate the KID. Two of the better choices would likely be the 1227 computer's NETBIOS name, or local Ethernet adapter's MAC address. 1228 The wireless adapter's address may be a suboptimal choice, as the 1229 user may only have one PCCARD adapter for multiple systems. 1231 With an authentication system already in place, there is a natural 1232 choice for the provisioned key. Clients can authenticate using their 1233 preexisting password. When the server is presented with a new KID, 1234 it can create a new key record on the server, and use the user's 1235 current password as the provisioned key. For example, for Active 1236 Directory, the supplicant could use Microsoft's NtPasswordHash 1237 function to generate a key verifiable by the server. It is suggested 1238 that this key then be fed through SHA1_128 before being used in a 1239 non-Microsoft authentication protocol (see Appendix B). 1241 After a key update, the server should keep track of both the old and 1242 new authentication key. When two keys exist, the server should 1243 attempt to use both to validate the MACs on transmitted packets. 1244 Once a client successfully authenticates using the new key, the 1245 server should discard the old key. This prevents desynchronization 1246 attacks. 1248 B.2. Mobile Phone Network 1250 In a mobile phone system, we no longer need to worry about supporting 1251 multiple keys per identity. Presumably each mobile device has a 1252 unique identity. However, if multiple devices per identity are 1253 desired, a method similar to that presented in section A.1 could be 1254 used. 1256 Provisioning could easily be accomplished by issuing a customer a 1257 6-digit PIN they could type into their phone's keypad. 1259 Authors' Addresses 1261 T. Charles Clancy 1262 DoD Laboratory for Telecommunications Sciences 1263 8080 Greenmeade Drive 1264 College Park, MD 20740 1265 USA 1267 Email: clancy@ltsnet.net 1269 William A. Arbaugh 1270 University of Maryland 1271 Department of Computer Science 1272 College Park, MD 20742 1273 USA 1275 Email: waa@cs.umd.edu 1277 Intellectual Property Statement 1279 The IETF takes no position regarding the validity or scope of any 1280 Intellectual Property Rights or other rights that might be claimed to 1281 pertain to the implementation or use of the technology described in 1282 this document or the extent to which any license under such rights 1283 might or might not be available; nor does it represent that it has 1284 made any independent effort to identify any such rights. Information 1285 on the procedures with respect to rights in RFC documents can be 1286 found in BCP 78 and BCP 79. 1288 Copies of IPR disclosures made to the IETF Secretariat and any 1289 assurances of licenses to be made available, or the result of an 1290 attempt made to obtain a general license or permission for the use of 1291 such proprietary rights by implementers or users of this 1292 specification can be obtained from the IETF on-line IPR repository at 1293 http://www.ietf.org/ipr. 1295 The IETF invites any interested party to bring to its attention any 1296 copyrights, patents or patent applications, or other proprietary 1297 rights that may cover technology that may be required to implement 1298 this standard. Please address the information to the IETF at 1299 ietf-ipr@ietf.org. 1301 Disclaimer of Validity 1303 This document and the information contained herein are provided on an 1304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1311 Copyright Statement 1313 Copyright (C) The Internet Society (2006). This document is subject 1314 to the rights, licenses and restrictions contained in BCP 78, and 1315 except as set forth therein, the authors retain all their rights. 1317 Acknowledgment 1319 Funding for the RFC Editor function is currently provided by the 1320 Internet Society.