idnits 2.17.00 (12 Aug 2021) /tmp/idnits20792/draft-walker-ieee802-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SIM' is mentioned on line 51, but not defined == Missing Reference: 'IEEE-802.1X' is mentioned on line 94, but not defined -- Looks like a reference, but probably isn't: '1' on line 140 -- Looks like a reference, but probably isn't: '2' on line 245 -- Looks like a reference, but probably isn't: '3' on line 255 -- Looks like a reference, but probably isn't: '4' on line 154 -- Looks like a reference, but probably isn't: '5' on line 166 -- Looks like a reference, but probably isn't: '6' on line 283 -- Looks like a reference, but probably isn't: '7' on line 274 -- Looks like a reference, but probably isn't: '8' on line 185 -- Looks like a reference, but probably isn't: '9' on line 258 -- Looks like a reference, but probably isn't: '10' on line 288 -- Looks like a reference, but probably isn't: '11' on line 204 == Unused Reference: 'EAPSIM' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 348, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021X-REV' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.11i' -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-08 == Outdated reference: A later version (-05) exists of draft-ietf-pppext-eap-ttls-03 == Outdated reference: draft-haverinen-pppext-eap-sim has been published as RFC 4186 == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dorothy Stanley 3 INTERNET-DRAFT Agere 4 Category: Best Current Practice Jesse Walker 5 Intel Corporation 6 11 May 2004 Bernard Aboba 7 Microsoft Corporation 9 EAP Method Requirements for Wireless LANs 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 The IEEE 802.11i MAC Security Enhancements Amendment makes use of 37 IEEE 802.1X which in turn relies on the Extensible Authentication 38 Protocol (EAP). This document defines requirements for EAP methods 39 used in IEEE 802.11 wireless LAN deployments. The material in this 40 document has been approved by IEEE 802.11 and it is being presented 41 as an IETF RFC for informational purposes. 43 1. Introduction 45 The IEEE 802.11i MAC Security Enhancements Amendment [IEEE802.11i] 46 makes use of IEEE 802.1X [IEEE8021X-REV] which in turn relies on the 47 Extensible Authentication Protocol (EAP), defined in [RFC3748]. 49 Deployments of IEEE 802.11 wireless LANs today are based on EAP, and 50 use several EAP methods, including EAP-TLS [RFC2716], EAP-TTLS 51 [TTLS], PEAP [PEAP] and EAP-SIM [SIM]. These methods support 52 authentication credentials that include digital certificates, user- 53 names and passwords, secure tokens, and SIM secrets. 55 This document defines requirements for EAP methods used in IEEE 56 802.11 wireless LAN deployments. EAP methods claiming conformance to 57 the IEEE 802.11 wireless LAN requirements for EAP methods must 58 complete IETF last call review. 60 1.1. Requirements specification 62 In this document, several words are used to signify the requirements 63 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 64 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 65 and "OPTIONAL" in this document are to be interpreted as described in 66 [RFC2119]. 68 An EAP authentication method is not compliant with this specification 69 if it fails to satisfy one or more of the MUST or MUST NOT 70 requirements. An EAP authentication method that satisfies all the 71 MUST, MUST NOT, SHOULD and SHOULD NOT requirements is said to be 72 "unconditionally compliant"; one that satisfies all the MUST and MUST 73 NOT requirements but not all the SHOULD or SHOULD NOT requirements is 74 said to be "conditionally compliant". 76 1.2. Terminology 78 authenticator 79 The end of the link initiating EAP authentication. The term 80 Authenticator is used in [IEEE-802.1X], and authenticator has the 81 same meaning in this document. 83 peer The end of the link that responds to the authenticator. In 84 [IEEE-802.1X], this end is known as the Supplicant. 86 Supplicant 87 The end of the link that responds to the authenticator in 88 [IEEE-802.1X]. 90 backend authentication server 91 A backend authentication server is an entity that provides an 92 authentication service to an authenticator. When used, this server 93 typically executes EAP methods for the authenticator. This 94 terminology is also used in [IEEE-802.1X]. 96 EAP server 97 The entity that terminates the EAP authentication method with the 98 peer. In the case where no backend authentication server is used, 99 the EAP server is part of the authenticator. In the case where the 100 authenticator operates in pass-through mode, the EAP server is 101 located on the backend authentication server. 103 Master Session Key (MSK) 104 Keying material that is derived between the EAP peer and server and 105 exported by the EAP method. The MSK is at least 64 octets in 106 length. In existing implementations a AAA server acting as an EAP 107 server transports the MSK to the authenticator. 109 Extended Master Session Key (EMSK) 110 Additional keying material derived between the EAP client and 111 server that is exported by the EAP method. The EMSK is at least 64 112 octets in length. The EMSK is not shared with the authenticator or 113 any other third party. The EMSK is reserved for future uses that 114 are not defined yet. 116 4-Way Handshake 117 A pairwise Authentication and Key Management Protocol (AKMP) 118 defined in [IEEE802.11i], which confirms mutual possession of a 119 Pairwise Master Key by two parties and distributes a Group Key. 121 2. Method requirements 123 2.1. Credential types 125 The IEEE 802.11i MAC Security Enhancements Amendment requires that 126 EAP authentication methods are available. Wireless LAN deployments 127 are expected to use different credentials types, including digital 128 certificates, user-names and passwords, existing secure tokens, and 129 mobile network credentials (GSM and UMTS secrets). Other credential 130 types that may be used include public/private key (without 131 necessarily requiring certificates), and asymmetric credential 132 support (such as password on one side, public/private key on the 133 other). 135 2.2. Mandatory requirements 137 EAP authentication methods suitable for use in wireless LAN 138 authentication MUST satisfy the following criteria: 140 [1] Generation of symmetric keying material. This corresponds to the 141 "Key derivation" security claim defined in [RFC3748], Section 142 7.2.1. 144 [2] Key strength. An EAP method suitable for use with IEEE 802.11 MUST 145 be capable of generating keying material with 128-bits of effective 146 key strength, as defined in [RFC3748] Section 7.2.1. As noted in 147 [RFC3748] Section 7.10, an EAP method supporting key derivation 148 MUST export a Master Session Key (MSK) of at least 64 octets, and 149 an Extended Master Session Key (EMSK) of at least 64 octets. 151 [3] Mutual authentication support. This corresponds to the "Mutual 152 authentication" security claim defined in [RFC3748], Section 7.2.1. 154 [4] Synchronization of state. This requirement applies when the EAP 155 method completes successfully. The exact state attributes that are 156 shared may vary from method to method but typically include the 157 protocol both executed, what credentials were presented and 158 accepted by both parties, what cryptographic keys are shared and 159 what EAP method specific attributes were negotiated, such as cipher 160 suites and limitations of usage on all protocol state. Both 161 parties must be able to distinguish this instance of the protocol 162 from all other instances of the protocol and they must share the 163 same view of which state attributes are public and which are 164 private to the two parties alone. 166 [5] Resistance to dictionary attacks. This corresponds to the 167 "Dictionary attack resistance" security claim defined in [RFC3748], 168 Section 7.2.1. 170 [6] Protection against man-in-the-middle attacks. This corresponds to 171 the "Cryptographic binding", "Integrity protection", "Replay 172 protection", and "Session independence" security claims defined in 173 [RFC3748], Section 7.2.1. 175 [7] Protected ciphersuite negotiation. If the method negotiates the 176 ciphersuite used to protect the EAP conversation, then it MUST 177 support the "Protected ciphersuite negotiation" security claim 178 defined in [RFC3748], Section 7.2.1. 180 2.3. Recommended requirements 182 EAP authentication methods used for wireless LAN authentication 183 SHOULD support the following features: 185 [8] Fragmentation. [RFC3748] Section 3.1 states: "EAP methods can 186 assume a minimum EAP MTU of 1020 octets, in the absence of other 187 information. EAP methods SHOULD include support for fragmentation 188 and reassembly if their payloads can be larger than this minimum 189 EAP MTU." This implies support for the "Fragmentation" claim 190 defined in [RFC3748], Section 7.2.1. 192 [9] End-user identity hiding. This corresponds to the 193 "Confidentiality" security claim defined in [RFC3748], Section 194 7.2.1. 196 2.4. Optional features 198 EAP authentication methods used for wireless LAN authentication MAY 199 support the following features: 201 [10] Channel binding. This corresponds to the "Channel binding" 202 security claim defined in [RFC3748], Section 7.2.1. 204 [11] Fast reconnect. This corresponds to the "Fast reconnect" security 205 claim defined in [RFC3748], Section 7.2.1. 207 2.5. Non-compliant EAP authentication methods 209 EAP-MD5-Challenge (the current mandatory-to-implement EAP 210 authentication method), is defined in [RFC3748] Section 5.4. EAP- 211 MD5-Challenge, One-Time Password (Section 5.5) and Generic Token Card 212 (Section 5.6), as defined in [RFC3748] are non-compliant with the 213 requirements specified in this document. As noted in [RFC3748], 214 these methods do not support any of the mandatory requirements 215 defined in Section 2.2 including key derivation, or mutual 216 authentication. In addition, these methods do not support any of the 217 recommended features defined in Section 2.3 or any of the optional 218 features defined in Section 2.4. 220 3. Security Considerations 222 Within [IEEE802.11i], EAP is used for both authentication and key 223 exchange between the EAP peer and server. Given that wireless local 224 area networks provide ready access to an attacker within range, EAP 225 usage within [IEEE802.11i] is subject to the threats outlined in 226 [RFC3748] Section 7.1. Security considerations relating to EAP are 227 discussed in [RFC3748] Sections 7; where an authentication server is 228 utilized, the security considerations described in [RFC3579], Section 229 4 will apply. 231 The system security properties required to address the threats 232 described in [RFC3748] Section 7.1 are noted in [Housley56]: 234 Algorithm independence 235 Wherever cryptographic algorithms are chosen, the algorithms must 236 be negotiable, in order to provide resilience against compromise of 237 a particular cryptographic algorithm. This is addressed by 238 mandatory requirement [7] in Section 2.2. Algorithm independence 239 is one of the EAP invariants described in [KEYFRAME]. 241 Strong, fresh session keys 242 Session keys must be demonstrated to be strong and fresh in all 243 circumstances, while at the same time retaining algorithm 244 independence. Key strength is addressed by mandatory requirement 245 [2] in Section 2.2. Recommendations for ensuring the Freshness of 246 keys derived by EAP methods are discussed in [RFC3748], Section 247 7.10. 249 Replay protection 250 All protocol exchanges must be replay protected. This is addressed 251 by mandatory requirement [6] in Section 2.2. 253 Authentication 254 All parties need to be authenticated. Mutual authentication is 255 required as part of mandatory requirement [3] in Section 2.2. The 256 confidentiality of the authenticator must be maintained. Identity 257 protection is a recommended capability, described in requirement 258 [9] in Section 2.3. No plaintext passwords are allowed. EAP does 259 not support plaintext passwords, as noted in [RFC3748] Section 260 7.14. 262 Authorization 263 EAP peer and authenticator authorization must be performed. Issues 264 relating to authorization are discussed in [RFC3748] Section 7.15, 265 and [RFC3579] Section 4.3.7. 267 Session keys 268 Confidentiality of session keys must be maintained. Issues 269 relating to Key Derivation are described in [RFC3748] Section 7.10, 270 as well as in [KEYFRAME]. 272 Ciphersuite negotiation 273 The selection of the "best" ciphersuite must be securely confirmed. 274 This is addressed in mandatory requirement [7] in Section 2.2. 276 Unique naming 277 Session keys must be uniquely named. Key naming issues are 278 addressed in [KEYFRAME]. 280 Domino effect 281 Compromise of a single authenticator cannot compromise any other 282 part of the system, including session keys and long-term secrets. 283 This issue is addressed by mandatory requirement [6] in Section 284 2.2. 286 Key binding 287 The key must be bound to the appropriate context. This issue is 288 addressed in optional requirement [10] in Section 2.4. Channel 289 binding is also discussed in Section 7.15 of [RFC3748]. 291 4. References 293 4.1. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", RFC 2119, March, 1997. 298 [RFC3748] Blunk, L. , et al., "Extensible Authentication Protocol 299 (EAP)", RFC 3748, May 2004. 301 [802.11] Information technology - Telecommunications and information 302 exchange between systems - Local and metropolitan area 303 networks - Specific Requirements Part 11: Wireless LAN Medium 304 Access Control (MAC) and Physical Layer (PHY) Specifications, 305 IEEE Std. 802.11-1999, 1999. 307 [IEEE8021X-REV] 308 IEEE Standards for Local and Metropolitan Area Networks: Port 309 based Network Access Control, IEEE Std 802.1X-REV, Draft 9, 310 March 2004. 312 [IEEE802.11i] 313 Institute of Electrical and Electronics Engineers, "Unapproved 314 Draft Supplement to Standard for Telecommunications and 315 Information Exchange Between Systems - LAN/MAN Specific 316 Requirements - Part 11: Wireless LAN Medium Access Control 317 (MAC) and Physical Layer (PHY) Specifications: Specification 318 for Enhanced Security", IEEE Draft 802.11i (work in progress), 319 2003. 321 4.2. Informative References 323 [Housley56] 324 Housley, R., "Key Management in AAA", Presentation to the AAA 325 WG at IETF 56, 326 http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, 327 March 2003. 329 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 330 RFC 2716, October 1999. 332 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 333 In User Service) Support For Extensible Authentication 334 Protocol (EAP)", RFC 3579, September 2003. 336 [PEAP] Palekar, A., et al., "Protected EAP Protocol (PEAP)", draft- 337 josefsson-pppext-eap-tls-eap-08.txt, Internet draft (work in 338 progress), May 2004. 340 [TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication 341 Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-03.txt, 342 August 2003. 344 [EAPSIM] Haverinen, H. and J. Salowey, "EAP SIM Authentication", draft- 345 haverinen-pppext-eap-sim-12.txt, Internet draft (work in 346 progress), October 2003. 348 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 349 Overview and Architecture, ANSI/IEEE Std 802, 1990. 351 [KEYFRAME] 352 Aboba, B., "EAP Key Management Framework", draft-ietf-eap- 353 keying-02 (work in progress), May 2004. 355 Acknowledgments 357 The authors would like to acknowledge contributions to this document 358 from members of the IEEE 802.11i Task Group, including Russ Housley 359 of Vigil Security, David Nelson of Enterasys Networks and Clint 360 Chaplin of Symbol Technologies, as well as members of the EAP WG 361 including Joe Salowey of Cisco Systems, Pasi Eronen of Nokia, Jari 362 Arkko of Ericsson, and Florent Bersani of France Telecom. 364 Authors' Addresses 366 Dorothy Stanley 367 Agere Systems 368 2000 North Naperville Rd. 370 Naperville, IL 60566 372 EMail: dstanley@agere.com 373 Phone: +1 630 979 1572 375 Jesse R. Walker 376 Intel Corporation 377 2111 N.E. 25th Avenue 378 Hillsboro, OR 97214 380 EMail: jesse.walker@intel.com 382 Bernard Aboba 383 Microsoft Corporation 384 One Microsoft Way 385 Redmond, WA 98052 387 EMail: bernarda@microsoft.com 388 Phone: +1 425 706 6605 389 Fax: +1 425 936 7329 391 Intellectual Property Statement 393 The IETF takes no position regarding the validity or scope of any 394 intellectual property or other rights that might be claimed to 395 pertain to the implementation or use of the technology described in 396 this document or the extent to which any license under such rights 397 might or might not be available; neither does it represent that it 398 has made any effort to identify any such rights. Information on the 399 IETF's procedures with respect to rights in standards-track and 400 standards-related documentation can be found in BCP-11. Copies of 401 claims of rights made available for publication and any assurances of 402 licenses to be made available, or the result of an attempt made to 403 obtain a general license or permission for the use of such 404 proprietary rights by implementors or users of this specification can 405 be obtained from the IETF Secretariat. 407 The IETF invites any interested party to bring to its attention any 408 copyrights, patents or patent applications, or other proprietary 409 rights which may cover technology that may be required to practice 410 this standard. Please address the information to the IETF Executive 411 Director. 413 Full Copyright Statement 415 Copyright (C) The Internet Society (2004). All Rights Reserved. 417 This document and translations of it may be copied and furnished to 418 others, and derivative works that comment on or otherwise explain it 419 or assist in its implementation may be prepared, copied, published 420 and distributed, in whole or in part, without restriction of any 421 kind, provided that the above copyright notice and this paragraph are 422 included on all such copies and derivative works. However, this 423 document itself may not be modified in any way, such as by removing 424 the copyright notice or references to the Internet Society or other 425 Internet organizations, except as needed for the purpose of 426 developing Internet standards in which case the procedures for 427 copyrights defined in the Internet Standards process must be 428 followed, or as required to translate it into languages other than 429 English. The limited permissions granted above are perpetual and 430 will not be revoked by the Internet Society or its successors or 431 assigns. This document and the information contained herein is 432 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 433 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 434 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 435 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 436 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 438 Open issues 440 Open issues relating to this specification are tracked on the 441 following web site: 443 http://www.drizzle.com/~aboba/EAP/eapissues.html 445 Expiration Date 447 This memo is filed as , and 448 expires November 22, 2004.