idnits 2.17.1 draft-walker-ieee802-req-04.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 471. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 10 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 11 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SIM' is mentioned on line 75, but not defined == Missing Reference: 'IEEE-802.1X' is mentioned on line 104, but not defined -- Looks like a reference, but probably isn't: '1' on line 164 -- Looks like a reference, but probably isn't: '2' on line 278 -- Looks like a reference, but probably isn't: '3' on line 293 -- Looks like a reference, but probably isn't: '4' on line 178 -- Looks like a reference, but probably isn't: '5' on line 194 -- Looks like a reference, but probably isn't: '6' on line 331 -- Looks like a reference, but probably isn't: '7' on line 319 -- Looks like a reference, but probably isn't: '8' on line 213 -- Looks like a reference, but probably isn't: '9' on line 294 -- Looks like a reference, but probably isn't: '10' on line 337 -- Looks like a reference, but probably isn't: '11' on line 232 == Unused Reference: 'EAPSIM' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 401, but no explicit reference was found in the text -- 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 (-16) exists of draft-haverinen-pppext-eap-sim-13 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-03 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 19 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: Informational Jesse Walker 5 Intel Corporation 6 10 August 2004 Bernard Aboba 7 Microsoft Corporation 9 EAP Method Requirements for Wireless LANs 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 2, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society 2004. All rights reserved. 38 Abstract 40 The IEEE 802.11i MAC Security Enhancements Amendment makes use of 41 IEEE 802.1X which in turn relies on the Extensible Authentication 42 Protocol (EAP). This document defines requirements for EAP methods 43 used in IEEE 802.11 wireless LAN deployments. The material in this 44 document has been approved by IEEE 802.11 and it is being presented 45 as an IETF RFC for informational purposes. 47 Table of Contents 49 1. Introduction .......................................... 3 50 1.1 Requirements Specification ...................... 3 51 1.2 Terminology ..................................... 3 52 2. Method Requirements ................................... 4 53 2.1 Credential Types ................................ 4 54 2.2 Mandatory Requirements .......................... 5 55 2.3 Recommended Requirements ........................ 6 56 2.4 Optional Features ............................... 6 57 2.5 Non-compliant EAP Authentication Methods ........ 6 58 3. Security Considerations ............................... 6 59 4. References ............................................ 8 60 4.1 Normative References ............................ 8 61 4.2 Informative References .......................... 9 62 Acknowledgments .............................................. 10 63 Authors' Addresses ........................................... 10 64 Intellectual Property Statement .............................. 10 65 Disclaimer of Validity ....................................... 11 66 Copyright Statement .......................................... 11 67 1. Introduction 69 The IEEE 802.11i MAC Security Enhancements Amendment [IEEE802.11i] 70 makes use of IEEE 802.1X [IEEE802.1X] which in turn relies on the 71 Extensible Authentication Protocol (EAP), defined in [RFC3748]. 73 Deployments of IEEE 802.11 wireless LANs today are based on EAP, and 74 use several EAP methods, including EAP-TLS [RFC2716], EAP-TTLS 75 [TTLS], PEAP [PEAP] and EAP-SIM [SIM]. These methods support 76 authentication credentials that include digital certificates, user- 77 names and passwords, secure tokens, and SIM secrets. 79 This document defines requirements for EAP methods used in IEEE 80 802.11 wireless LAN deployments. EAP methods claiming conformance to 81 the IEEE 802.11 EAP method requirements for wireless LANs must 82 complete IETF last call review. 84 1.1. Requirements Specification 86 In this document, several words are used to signify the requirements 87 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 88 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 89 and "OPTIONAL" in this document are to be interpreted as described in 90 [RFC2119]. 92 An EAP authentication method is not compliant with this specification 93 if it fails to satisfy one or more of the MUST or MUST NOT 94 requirements. An EAP authentication method that satisfies all the 95 MUST, MUST NOT, SHOULD and SHOULD NOT requirements is said to be 96 "unconditionally compliant"; one that satisfies all the MUST and MUST 97 NOT requirements but not all the SHOULD or SHOULD NOT requirements is 98 said to be "conditionally compliant". 100 1.2. Terminology 102 authenticator 103 The end of the link initiating EAP authentication. The term 104 authenticator is used in [IEEE-802.1X], and authenticator has the 105 same meaning in this document. 107 peer The end of the link that responds to the authenticator. In 108 [IEEE802.1X], this end is known as the supplicant. 110 Supplicant 111 The end of the link that responds to the authenticator in 112 [IEEE802.1X]. 114 backend authentication server 115 A backend authentication server is an entity that provides an 116 authentication service to an authenticator. When used, this server 117 typically executes EAP methods for the authenticator. This 118 terminology is also used in [IEEE802.1X]. 120 EAP server 121 The entity that terminates the EAP authentication method with the 122 peer. In the case where no backend authentication server is used, 123 the EAP server is part of the authenticator. In the case where the 124 authenticator operates in pass-through mode, the EAP server is 125 located on the backend authentication server. 127 Master Session Key (MSK) 128 Keying material that is derived between the EAP peer and server and 129 exported by the EAP method. The MSK is at least 64 octets in 130 length. In existing implementations a AAA server acting as an EAP 131 server transports the MSK to the authenticator. 133 Extended Master Session Key (EMSK) 134 Additional keying material derived between the EAP client and 135 server that is exported by the EAP method. The EMSK is at least 64 136 octets in length. The EMSK is not shared with the authenticator or 137 any other third party. The EMSK is reserved for future uses that 138 are not defined yet. 140 4-Way Handshake 141 A pairwise Authentication and Key Management Protocol (AKMP) 142 defined in [IEEE802.11i], which confirms mutual possession of a 143 Pairwise Master Key by two parties and distributes a Group Key. 145 2. Method Requirements 147 2.1. Credential Types 149 The IEEE 802.11i MAC Security Enhancements Amendment requires that 150 EAP authentication methods are available. Wireless LAN deployments 151 are expected to use different credentials types, including digital 152 certificates, user-names and passwords, existing secure tokens, and 153 mobile network credentials (GSM and UMTS secrets). Other credential 154 types that may be used include public/private key (without 155 necessarily requiring certificates), and asymmetric credential 156 support (such as password on one side, public/private key on the 157 other). 159 2.2. Mandatory Requirements 161 EAP authentication methods suitable for use in wireless LAN 162 authentication MUST satisfy the following criteria: 164 [1] Generation of symmetric keying material. This corresponds to the 165 "Key derivation" security claim defined in [RFC3748], Section 166 7.2.1. 168 [2] Key strength. An EAP method suitable for use with IEEE 802.11 MUST 169 be capable of generating keying material with 128-bits of effective 170 key strength, as defined in [RFC3748] Section 7.2.1. As noted in 171 [RFC3748] Section 7.10, an EAP method supporting key derivation 172 MUST export a Master Session Key (MSK) of at least 64 octets, and 173 an Extended Master Session Key (EMSK) of at least 64 octets. 175 [3] Mutual authentication support. This corresponds to the "Mutual 176 authentication" security claim defined in [RFC3748], Section 7.2.1. 178 [4] Shared state equivalence. The shared EAP method state of the EAP 179 peer and server must be equivalent when the EAP method completes 180 successfully on both sides. This includes the internal state of 181 the authentication protocol but not the state external to the EAP 182 method, such as the negotiation occurring prior to initiation of 183 the EAP method. The exact state attributes that are shared may 184 vary from method to method but typically include the method version 185 number, what credentials were presented and accepted by both 186 parties, what cryptographic keys are shared and what EAP method 187 specific attributes were negotiated, such as ciphersuites and 188 limitations of usage on all protocol state. Both parties must be 189 able to distinguish this instance of the protocol from all other 190 instances of the protocol and they must share the same view of 191 which state attributes are public and which are private to the two 192 parties alone. 194 [5] Resistance to dictionary attacks. This corresponds to the 195 "Dictionary attack resistance" security claim defined in [RFC3748], 196 Section 7.2.1. 198 [6] Protection against man-in-the-middle attacks. This corresponds to 199 the "Cryptographic binding", "Integrity protection", "Replay 200 protection", and "Session independence" security claims defined in 201 [RFC3748], Section 7.2.1. 203 [7] Protected ciphersuite negotiation. If the method negotiates the 204 ciphersuite used to protect the EAP conversation, then it MUST 205 support the "Protected ciphersuite negotiation" security claim 206 defined in [RFC3748], Section 7.2.1. 208 2.3. Recommended Requirements 210 EAP authentication methods used for wireless LAN authentication 211 SHOULD support the following features: 213 [8] Fragmentation. This implies support for the "Fragmentation" claim 214 defined in [RFC3748], Section 7.2.1. [RFC3748] Section 3.1 states: 215 "EAP methods can assume a minimum EAP MTU of 1020 octets, in the 216 absence of other information. EAP methods SHOULD include support 217 for fragmentation and reassembly if their payloads can be larger 218 than this minimum EAP MTU." 220 [9] End-user identity hiding. This corresponds to the 221 "Confidentiality" security claim defined in [RFC3748], Section 222 7.2.1. 224 2.4. Optional Features 226 EAP authentication methods used for wireless LAN authentication MAY 227 support the following features: 229 [10] Channel binding. This corresponds to the "Channel binding" 230 security claim defined in [RFC3748], Section 7.2.1. 232 [11] Fast reconnect. This corresponds to the "Fast reconnect" security 233 claim defined in [RFC3748], Section 7.2.1. 235 2.5. Non-compliant EAP Authentication Methods 237 EAP-MD5-Challenge (the current mandatory-to-implement EAP 238 authentication method), is defined in [RFC3748] Section 5.4. As 239 defined in [RFC3748], EAP-MD5-Challenge, One-Time Password (Section 240 5.5) and Generic Token Card (Section 5.6) are non-compliant with the 241 requirements specified in this document. As noted in [RFC3748], 242 these methods do not support any of the mandatory requirements 243 defined in Section 2.2 including key derivation, or mutual 244 authentication. In addition, these methods do not support any of the 245 recommended features defined in Section 2.3 or any of the optional 246 features defined in Section 2.4. 248 3. Security Considerations 250 Within [IEEE802.11i], EAP is used for both authentication and key 251 exchange between the EAP peer and server. Given that wireless local 252 area networks provide ready access to an attacker within range, EAP 253 usage within [IEEE802.11i] is subject to the threats outlined in 254 [RFC3748] Section 7.1. Security considerations relating to EAP are 255 discussed in [RFC3748] Sections 7; where an authentication server is 256 utilized, the security considerations described in [RFC3579], Section 257 4 will apply. 259 The system security properties required to address the threats 260 described in [RFC3748] Section 7.1 are noted in [Housley56]. In the 261 material below, the requirements articulated in [Housley56] are 262 listed, along with the corresponding recommendations. 264 Algorithm independence 265 Requirement: "Wherever cryptographic algorithms are chosen, the 266 algorithms must be negotiable, in order to provide resilience 267 against compromise of a particular cryptographic algorithm." 269 This issue is addressed by mandatory requirement [7] in Section 270 2.2. Algorithm independence is one of the EAP invariants described 271 in [KEYFRAME]. 273 Strong, fresh session keys 274 Requirement: "Session keys must be demonstrated to be strong and 275 fresh in all circumstances, while at the same time retaining 276 algorithm independence." 278 Key strength is addressed by mandatory requirement [2] in Section 279 2.2. Recommendations for ensuring the Freshness of keys derived by 280 EAP methods are discussed in [RFC3748], Section 7.10. 282 Replay protection 283 Requirement: "All protocol exchanges must be replay protected." 285 This is addressed by mandatory requirement [6] in Section 2.2. 287 Authentication 288 Requirements: "All parties need to be authenticated. The 289 confidentiality of the authenticator must be maintained. No 290 plaintext passwords are allowed." 292 Mutual authentication is required as part of mandatory requirement 293 [3] in Section 2.2. Identity protection is a recommended 294 capability, described in requirement [9] in Section 2.3. EAP does 295 not support plaintext passwords, as noted in [RFC3748] Section 296 7.14. 298 Authorization 299 Requirement: "EAP peer and authenticator authorization must be 300 performed." 302 Authorization issues are discussed in [RFC3748] Section 1.2, and 303 Section 7.16. Authentication, Authorization and Accounting (AAA) 304 protocols such as RADIUS [RFC2865][RFC3579] may be used to enable 305 authorization of EAP peers by a central authority. AAA 306 authorization issues are discussed in [RFC3579] Section 2.6.3 as 307 well as in Section 4.3.7. 309 Session keys 310 Requirement: "Confidentiality of session keys must be maintained." 312 Issues relating to Key Derivation are described in [RFC3748] 313 Section 7.10, as well as in [KEYFRAME]. 315 Ciphersuite negotiation 316 Requirement: "The selection of the "best" ciphersuite must be 317 securely confirmed." 319 This is addressed in mandatory requirement [7] in Section 2.2. 321 Unique naming 322 Requirement: "Session keys must be uniquely named." 324 Key naming issues are addressed in [KEYFRAME]. 326 Domino effect 327 Requirement: "Compromise of a single authenticator cannot 328 compromise any other part of the system, including session keys and 329 long-term secrets." 331 This issue is addressed by mandatory requirement [6] in Section 332 2.2. 334 Key binding 335 Requirement: "The key must be bound to the appropriate context." 337 This issue is addressed in optional requirement [10] in Section 338 2.4. Channel binding is also discussed in Section 7.15 of 339 [RFC3748], and Section 4.3.7 of [RFC3579]. 341 4. References 343 4.1. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", RFC 2119, March, 1997. 348 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 349 Authentication Dial In User Service (RADIUS)", RFC 2865, June 350 2000. 352 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 353 In User Service) Support For Extensible Authentication 354 Protocol (EAP)", RFC 3579, September 2003. 356 [RFC3748] Aboba, B., et al., "Extensible Authentication Protocol (EAP)", 357 RFC 3748, June 2004. 359 [802.11] Information technology - Telecommunications and information 360 exchange between systems - Local and metropolitan area 361 networks - Specific Requirements Part 11: Wireless LAN Medium 362 Access Control (MAC) and Physical Layer (PHY) Specifications, 363 IEEE Std. 802.11-2003, 2003. 365 [IEEE802.1X] 366 IEEE Standards for Local and Metropolitan Area Networks: Port 367 based Network Access Control, IEEE Std 802.1X-2004, August 368 2004. 370 [IEEE802.11i] 371 Institute of Electrical and Electronics Engineers, "Supplement 372 to Standard for Telecommunications and Information Exchange 373 Between Systems - LAN/MAN Specific Requirements - Part 11: 374 Wireless LAN Medium Access Control (MAC) and Physical Layer 375 (PHY) Specifications: Specification for Enhanced Security", 376 IEEE 802.11i, July 2004. 378 4.2. Informative References 380 [Housley56] 381 Housley, R., "Key Management in AAA", Presentation to the AAA 382 WG at IETF 56, 383 http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, 384 March 2003. 386 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 387 RFC 2716, October 1999. 389 [PEAP] Palekar, A., et al., "Protected EAP Protocol (PEAP)", draft- 390 josefsson-pppext-eap-tls-eap-08.txt, Internet draft (work in 391 progress), July 2004. 393 [TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication 394 Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-05.txt, July 395 2004. 397 [EAPSIM] Haverinen, H. and J. Salowey, "EAP SIM Authentication", draft- 398 haverinen-pppext-eap-sim-13.txt, Internet draft (work in 399 progress), April 2004. 401 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 402 Overview and Architecture, ANSI/IEEE Std 802, 1990. 404 [KEYFRAME] 405 Aboba, B., et al., "EAP Key Management Framework", draft-ietf- 406 eap-keying-03.txt, Internet draft (work in progress), July 407 2004. 409 Acknowledgments 411 The authors would like to acknowledge contributions to this document 412 from members of the IEEE 802.11i Task Group, including Russ Housley 413 of Vigil Security, David Nelson of Enterasys Networks and Clint 414 Chaplin of Symbol Technologies, as well as members of the EAP WG 415 including Joe Salowey of Cisco Systems, Pasi Eronen of Nokia, Jari 416 Arkko of Ericsson, and Florent Bersani of France Telecom. 418 Authors' Addresses 420 Dorothy Stanley 421 Agere Systems 422 2000 North Naperville Rd. 423 Naperville, IL 60566 425 EMail: dstanley@agere.com 426 Phone: +1 630 979 1572 428 Jesse R. Walker 429 Intel Corporation 430 2111 N.E. 25th Avenue 431 Hillsboro, OR 97214 433 EMail: jesse.walker@intel.com 435 Bernard Aboba 436 Microsoft Corporation 437 One Microsoft Way 438 Redmond, WA 98052 440 EMail: bernarda@microsoft.com 441 Phone: +1 425 706 6605 442 Fax: +1 425 936 7329 444 Intellectual Property Statement 446 The IETF has been notified of intellectual property rights claimed in 447 regard to some or all of the specification contained in this 448 document. For more information consult the online list of claimed 449 rights. 451 The IETF takes no position regarding the validity or scope of any 452 Intellectual Property Rights or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; nor does it represent that it has 456 made any independent effort to identify any such rights. Information 457 on the procedures with respect to rights in RFC documents can be 458 found in BCP 78 and BCP 79. 460 Copies of IPR disclosures made to the IETF Secretariat and any 461 assurances of licenses to be made available, or the result of an 462 attempt made to obtain a general license or permission for the use of 463 such proprietary rights by implementers or users of this 464 specification can be obtained from the IETF on-line IPR repository at 465 http://www.ietf.org/ipr. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary 469 rights that may cover technology that may be required to implement 470 this standard. Please address the information to the IETF at ietf- 471 ipr@ietf.org. 473 Disclaimer of Validity 475 This document and the information contained herein are provided on an 476 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 477 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 478 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 479 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 480 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 481 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 483 Copyright Statement 485 Copyright (C) The Internet Society (2004). This document is subject 486 to the rights, licenses and restrictions contained in BCP 78, and 487 except as set forth therein, the authors retain all their rights. 489 Open issues 491 Open issues relating to this specification are tracked on the 492 following web site: 494 http://www.drizzle.com/~aboba/EAP/eapissues.html