idnits 2.17.00 (12 Aug 2021) /tmp/idnits64349/draft-aboba-pppext-eap-iana-02.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 document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC2284, but the header doesn't have an 'Updates:' line to match this. 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 (12 October 2002) is 7154 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) == Missing Reference: 'RFC1661' is mentioned on line 193, but not defined == Missing Reference: 'IEEE802' is mentioned on line 193, but not defined == Missing Reference: 'IEEE8023' is mentioned on line 194, but not defined == Missing Reference: 'DECEPTION' is mentioned on line 197, but not defined -- Looks like a reference, but probably isn't: '1' on line 251 -- Looks like a reference, but probably isn't: '2' on line 255 -- Looks like a reference, but probably isn't: '3' on line 265 -- Looks like a reference, but probably isn't: '4' on line 275 -- Looks like a reference, but probably isn't: '5' on line 286 -- Looks like a reference, but probably isn't: '6' on line 293 -- Looks like a reference, but probably isn't: '7' on line 232 -- Looks like a reference, but probably isn't: '8' on line 235 -- Looks like a reference, but probably isn't: '9' on line 238 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group B. Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Standards Track 5 6 12 October 2002 7 Updates: RFC 2284 9 EAP IANA Considerations 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet- Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2002). All Rights Reserved. 33 Abstract 35 This document describes the IANA considerations for Extensible 36 Authentication Protocol (EAP). 38 This document updates RFC 2284. 40 1. Introduction 42 This document provides guidance to the Internet Assigned Numbers 43 Authority (IANA) regarding registration of values related to the 44 Extensible Authentication Protocol (EAP),defined in [RFC2284], in 45 accordance with BCP 26, [RFC2434]. 47 1.1. Specification of Requirements 49 In this document, several words are used to signify the requirements of 50 the specification. These words are often capitalized. The key words 51 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 52 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 53 interpreted as described in [RFC2119]. 55 1.2. Terminology 57 The following terms are used here with the meanings defined in BCP 26: 58 "name space", "assigned value", "registration". 60 The following policies are used here with the meanings defined in BCP 61 26: "Private Use", "First Come First Served", "Expert Review", 62 "Specification Required", "IETF Consensus", "Standards Action". 64 2. IANA Considerations 66 There are two name spaces in EAP that require registration: Packet Codes 67 and Method Types. 69 EAP is not intended as a general-purpose protocol, and allocations 70 SHOULD NOT be made for purposes unrelated to authentication. 72 2.1. Recommended Registration Policies 74 For registration requests where a Designated Expert should be consulted, 75 the responsible IESG area director should appoint the Designated Expert. 76 For Designated Expert with Specification Required, the request is posted 77 to the EAP WG mailing list (or, if it has been disbanded, a successor 78 designated by the Area Director) for comment and review, and MUST 79 include a pointer to a public specification. Before a period of 30 days 80 has passed, the Designated Expert will either approve or deny the 81 registration request and publish a notice of the decision to the EAP WG 82 mailing list or its sucessor. In making the decision, the Designated 83 Expert will take into account the security guidelines described in 84 Section 4. A denial notice must be justified by an explanation and, in 85 the cases where it is possible, concrete suggestions on how the request 86 can be modified so as to become acceptable. 88 Packet Codes have a range from 1 to 255, of which 1-4 have been 89 allocated. Because a new Packet Code has considerable impact on 90 interoperability, a new Packet Code requires Standards Action, and 91 should be allocated starting at 5. 93 The original EAP Method Type space has a range from 1 to 255, and is the 94 scarcest resource in EAP, and thus must be allocated with care. Method 95 Types 1-36 have been allocated, with 20 available for re-use. Method 96 Types 37-191 may be allocated following Designated Expert, with 97 Specification Required. Release of blocks of Method Types (more than 1 98 at a time for a given purpose) should require IETF Consensus. EAP Type 99 Values 192-254 are reserved and allocation requires Standards Action. 101 Method Type 255 is allocated for Vendor-Specific extensions as described 102 in Section 3, and the use of that should be encouraged instead of 103 allocation from the original global Method Type space, for functions 104 specific only to one vendor's implementation of EAP, where no 105 interoperability is deemed useful. 107 When used with a Vendor-Id of zero, Method Type 255 can also be used to 108 provide for an expanded Method Type space. Expanded Method Type values 109 256-4294967295 may be allocated after Type values 1-191 have been 110 allocated, using Designated Expert with Specification Required. 112 3. Vendor-specific 114 Description 116 Due to EAP's popularity, the original Method Type space, which only 117 provides for 255 values, is being allocated at a pace, which if 118 continued, would result in exhaustion within a few years. Since many 119 of the existing uses of EAP are vendor-specific, the Vendor-Specific 120 Method Type is available to allow vendors to support their own 121 extended Types not suitable for general usage. The Vendor-specific 122 Type may also be used to expand the global Method Type space beyond 123 the original 255 values. 125 Peers not equipped to interpret the Vendor-specific Type, or who 126 support the Vendor-Specific Type, but find the proposed Vendor-Id to 127 be unacceptable, MUST send a Nak, and negotiate a more suitable 128 authentication method. 130 A summary of the Vendor-specific Type format is shown below. The 131 fields are transmitted from left to right. 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Type | Vendor-Id | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | String... 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Type 143 255 for Vendor-specific 145 Vendor-Id 147 The Vendor-Id is 3 octets and represents the SMI Network Management 148 Private Enterprise Code of the Vendor in network byte order, as 149 allocated by IANA. A Vendor-Id of zero is reserved for use by the 150 IETF in providing an expanded global EAP Type space. 152 String 154 The String field is one or more octets. The actual format of the 155 information is site or application specific, and a robust 156 implementation SHOULD support the field as undistinguished octets. 158 The codification of the range of allowed usage of this field is 159 outside the scope of this specification. 161 It SHOULD be encoded as follows. The Vendor-Specific field is 162 dependent on the vendor's definition of that attribute. An example 163 encoding of the Vendor-Specific attribute using this method follows. 165 Example Implementation 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type | Vendor-Id | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Vendor-Type | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Vendor-Specific... 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Vendor-Type 179 The Vendor-Type field is four octets and represents the vendor- 180 specific Method Type. Where a Vendor-Id of zero is present, the 181 Vendor-Type field provides an expanded global EAP Type space, 182 beginning with EAP Type values of 256. 184 Vendor-Specific 186 The Vendor-Specific field is dependent on the vendor's definition of 187 that attribute. Where a Vendor-Id of zero is present, the Vendor- 188 Specific field will be used for transporting the contents of EAP 189 Methods of Types 256 or greater. 191 4. Security Considerations 193 EAP was designed for use with dialup PPP [RFC1661] and wired [IEEE802] 194 networks such as Ethernet [IEEE8023]. On these networks, an attacker 195 would need to gain physical access to the telephone or switch 196 infrastructure in order to mount an attack. While such attacks have been 197 documented, such as in [DECEPTION], they are assumed to be rare. 199 However, subsequently EAP has been proposed for use on wireless 200 networks, and over the Internet, where physical security cannot be 201 assumed. On such networks, the security vulnerabilities are greater, as 202 are the requirements for EAP security. 204 This section documents the threats that exist on physically insecure 205 networks carrying EAP, as well as laying out the security analysis 206 required of an EAP method requesting a Type allocation. 208 4.1. Threat model 210 On physically insecure networks, it is possible for an attacker to gain 211 access to the physical medium. This enables a range of attacks, 212 including the following: 214 [1] An adversary may try to discover user identities by snooping data 215 packets. 217 [2] An adversary may try to modify or spoof EAP packets. 219 [3] An adversary may launch denial of service attacks by terminating 220 EAP conversations. 222 [4] An adversary might attempt to recover the passphrase by mounting an 223 offline dictionary attack. 225 [5] An adversary may attempt to convince the Peer to connect to an 226 untrusted network. 228 [6] An adversary may attempt to disrupt the EAP negotiation in order to 229 weaken the authentication, gain access to user passwords or remove 230 confidentiality protection. 232 [7] An adversary may attempt to mount a denial of service attack by 233 modify 235 [8] An attacker may attempt to take advantage of weak key derivation 236 techniques used within EAP methods. 238 [9] An attacker may attempt to take advantage of weak ciphersuites 239 subsequently used after the EAP conversation is complete. 241 Where EAP is used over wireless networks, an attacker needs to be within 242 the coverage area of the wireless medium in order to carry out these 243 attacks. However, where EAP is used over the Internet, no such 244 restrictions apply. 246 4.2. Security requirements 248 In order to address the threats that exist where EAP is used on a 249 physically insecure medium, the following requirements are imposed: 251 [1] Mutual authentication. Mutual authentication of the communication 252 endpoints MUST be provided in order to protect against rogue 253 Authenticators. 255 [2] Protected conversation. On a physically insecure network, EAP 256 messages SHOULD be integrity and replay protected, authenticated 257 and confidential so as to protect against downgrade attacks, 258 snooping of identities, and spoofing of packets. This includes 259 protection of packets of types Identity, Nak and Notification, as 260 well as packets sent within the EAP method itself, and success and 261 failure indications. Where EAP is used for ciphersuite or 262 capabilities negotiation, these messages SHOULD be integrity and 263 replay protected, authenticated and confidential. 265 [3] Key derivation. EAP methods used on physically insecure networks 266 MAY derive keys in order to enable per-packet authentication, 267 integrity and replay protection as well as confidentiality. Where 268 EAP methods derive keys, the distributed keys SHOULD be master 269 session keys, used only for further key derivation, independent of 270 the ciphersuite. This eliminates the need for an EAP method to 271 understand how to derive keys for every ciphersuite. Rather than 272 inventing new key derivation techniques, well analyzed algorithms 273 SHOULD be used. 275 [4] Dictionary attack resistance. Where EAP is used on physically 276 insecure networks resistance against dictionary attack SHOULD be 277 provided. Where password authentication is used, users are 278 notoriously prone to selection of poor passwords. Without 279 dictionary attack protection, it is easy for an attacker snooping 280 authentication traffic to gather a large number of authentication 281 exchanges, and successfully obtain a substantial fraction of the 282 passwords used in those exchanges via a dictionary attack. Given 283 the steadily declining prices of computing power, successful 284 dictionary attacks can now be mounted at minimal expense. 286 [5] Support for fast reconnect. On physically insecure media such as 287 wireless, it is often desirable to improve scalability and minimize 288 connectivity interruptions due to authentication. Where this is 289 desired, EAP methods MAY support "fast reconnect". After an initial 290 authentication conversation, this enables subsequent authentication 291 conversations to take place in shortened form. 293 [6] Acknowledged success and failure indications. Where EAP is used 294 over an unreliable medium, it is possible for packets to be lost. 295 This can result in the Peer and Authenticator having a different 296 interpretation of the state of the authentication conversation. As 297 a result, where EAP is used over an unreliable medium, EAP methods 298 SHOULD support acknowledged success and failure indications. 300 Since proposed EAP methods may be used on physically insecure methods, 301 it is necessary to be able to evaluate methods against the above 302 requirements in order to determine their suitability. In order to be 303 suitable for allocation of a Type code, EAP method specifications MUST 304 include the following: 306 [a] Statement of intended use. This includes a statement of whether the 307 method is intended for use over a physically secure or insecure 308 network, as well as a statement of the applicable media. 310 [b] Indication of security claims. This includes a statement of the 311 claimed security properties of the method. In particular, the 312 specification MUST include a vulnerability analysis and an 313 indication of whether the method claims to satisfy the requirements 314 for use on physically insecure media. 316 [c] Description of key hierarchy. EAP methods deriving keys MUST 317 describe how keys for authentication/integrity, encryption and IVs 318 are to be derived from the provided keying material, or a reference 319 to other documents providing such a description. 321 [d] Indication of vulnerabilities. If the method is intended for use on 322 a physically insecure network, yet does not satisfy the above 323 requirements, the specification MUST indicate which requirements 324 are not satisfied, and discuss the security implications. 326 5. Normative references 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", RFC 2119, March 1997. 331 [RFC2434] Alvestrand, H. and Narten, T., "Guidelines for Writing an 332 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 333 October 1998. 335 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 336 Protocol (EAP)", RFC 2284, March 1998. 338 Acknowledgments 340 Thanks to Glen Zorn of Cisco, and Ashwin Palekar of Microsoft for 341 discussions relating to this document. 343 Authors' Addresses 345 Bernard Aboba 346 Microsoft Corporation 347 One Microsoft Way 348 Redmond, WA 98052 350 EMail: bernarda@microsoft.com 351 Phone: +1 425 706 6605 352 Fax: +1 425 936 7329 353 Intellectual Property Statement 355 The IETF takes no position regarding the validity or scope of any 356 intellectual property or other rights that might be claimed to pertain 357 to the implementation or use of the technology described in this 358 document or the extent to which any license under such rights might or 359 might not be available; neither does it represent that it has made any 360 effort to identify any such rights. Information on the IETF's 361 procedures with respect to rights in standards-track and standards- 362 related documentation can be found in BCP-11. Copies of claims of 363 rights made available for publication and any assurances of licenses to 364 be made available, or the result of an attempt made to obtain a general 365 license or permission for the use of such proprietary rights by 366 implementers or users of this specification can be obtained from the 367 IETF Secretariat. 369 The IETF invites any interested party to bring to its attention any 370 copyrights, patents or patent applications, or other proprietary rights 371 which may cover technology that may be required to practice this 372 standard. Please address the information to the IETF Executive 373 Director. 375 Full Copyright Statement 377 Copyright (C) The Internet Society (2002). All Rights Reserved. 378 This document and translations of it may be copied and furnished to 379 others, and derivative works that comment on or otherwise explain it or 380 assist in its implementation may be prepared, copied, published and 381 distributed, in whole or in part, without restriction of any kind, 382 provided that the above copyright notice and this paragraph are included 383 on all such copies and derivative works. However, this document itself 384 may not be modified in any way, such as by removing the copyright notice 385 or references to the Internet Society or other Internet organizations, 386 except as needed for the purpose of developing Internet standards in 387 which case the procedures for copyrights defined in the Internet 388 Standards process must be followed, or as required to translate it into 389 languages other than English. The limited permissions granted above are 390 perpetual and will not be revoked by the Internet Society or its 391 successors or assigns. This document and the information contained 392 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 393 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 394 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 395 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 396 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 397 Expiration Date 399 This memo is filed as , and 400 expires April 19, 2003.