idnits 2.17.1 draft-ietf-eap-rfc2284bis-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1321 has weird spacing: '...ed Type of 6 ...' == Line 1399 has weird spacing: '...pe-Data field...' == Line 1710 has weird spacing: '...; or by gener...' -- 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 (June 16, 2003) is 7613 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 1703 -- Looks like a reference, but probably isn't: '2' on line 1706 -- Looks like a reference, but probably isn't: '3' on line 1708 -- Looks like a reference, but probably isn't: '4' on line 1713 -- Looks like a reference, but probably isn't: '5' on line 1716 -- Looks like a reference, but probably isn't: '6' on line 1719 -- Looks like a reference, but probably isn't: '7' on line 1722 -- Looks like a reference, but probably isn't: '8' on line 1725 -- Looks like a reference, but probably isn't: '9' on line 1728 == Unused Reference: 'RFC2401' is defined on line 2203, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.3' is defined on line 2251, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1X' -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) == Outdated reference: A later version (-07) exists of draft-ietf-ipsra-pic-06 == Outdated reference: A later version (-22) exists of draft-aboba-radius-rfc2869bis-21 == Outdated reference: A later version (-05) exists of draft-narten-iana-experimental-allocations-03 == Outdated reference: A later version (-07) exists of draft-aboba-pppext-key-problem-06 == Outdated reference: A later version (-10) exists of draft-ietf-sasl-saslprep-01 Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group L. Blunk 3 Internet-Draft Merit Network, Inc 4 Obsoletes: 2284 (if approved) J. Vollbrecht 5 Expires: December 15, 2003 Vollbrecht Consulting LLC 6 B. Aboba 7 Microsoft 8 J. Carlson 9 Sun 10 H. Levkowetz, Ed. 11 ipUnplugged 12 June 16, 2003 14 Extensible Authentication Protocol (EAP) 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 15, 2003. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 This document defines the Extensible Authentication Protocol (EAP), 46 an authentication framework which supports multiple authentication 47 methods. EAP typically runs directly over data link layers such as 48 PPP or IEEE 802, without requiring IP. EAP provides its own support 49 for duplicate elimination and retransmission, but is reliant on lower 50 layer ordering guarantees. Fragmentation is not supported within EAP 51 itself; however, individual EAP methods may support this. 53 This document obsoletes RFC 2284. A summary of the changes between 54 this document and RFC 2284 is available in Appendix B. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Specification of Requirements . . . . . . . . . . . . 4 60 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . 4 61 1.3 Security claims terminology for EAP methods . . . . . 6 62 2. Extensible Authentication Protocol (EAP) . . . . . . . . . . 8 63 2.1 Support for sequences . . . . . . . . . . . . . . . . 10 64 2.2 EAP multiplexing model . . . . . . . . . . . . . . . . 11 65 3. Lower layer behavior . . . . . . . . . . . . . . . . . . . . 14 66 3.1 Lower layer requirements . . . . . . . . . . . . . . . 14 67 3.2 EAP usage within PPP . . . . . . . . . . . . . . . . . 16 68 3.2.1 PPP Configuration Option Format . . . . . . . . 16 69 3.3 EAP usage within IEEE 802 . . . . . . . . . . . . . . 17 70 3.4 Lower layer indications . . . . . . . . . . . . . . . 17 71 4. EAP Packet format . . . . . . . . . . . . . . . . . . . . . 17 72 4.1 Request and Response . . . . . . . . . . . . . . . . . 18 73 4.2 Success and Failure . . . . . . . . . . . . . . . . . 21 74 4.3 Retransmission Behavior . . . . . . . . . . . . . . . 23 75 5. Initial EAP Request/Response Types . . . . . . . . . . . . . 24 76 5.1 Identity . . . . . . . . . . . . . . . . . . . . . . . 25 77 5.2 Notification . . . . . . . . . . . . . . . . . . . . . 26 78 5.3 Nak . . . . . . . . . . . . . . . . . . . . . . . . . 27 79 5.3.1 Legacy Nak . . . . . . . . . . . . . . . . . . . 27 80 5.3.2 Expanded Nak . . . . . . . . . . . . . . . . . . 28 81 5.4 MD5-Challenge . . . . . . . . . . . . . . . . . . . . 30 82 5.5 One-Time Password (OTP) . . . . . . . . . . . . . . . 32 83 5.6 Generic Token Card (GTC) . . . . . . . . . . . . . . . 33 84 5.7 Expanded Types . . . . . . . . . . . . . . . . . . . . 34 85 5.8 Experimental . . . . . . . . . . . . . . . . . . . . . 35 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36 87 6.1 Packet Codes . . . . . . . . . . . . . . . . . . . . . 37 88 6.2 Method Types . . . . . . . . . . . . . . . . . . . . . 37 89 7. Security Considerations . . . . . . . . . . . . . . . . . . 37 90 7.1 Threat model . . . . . . . . . . . . . . . . . . . . . 38 91 7.2 Security claims . . . . . . . . . . . . . . . . . . . 39 92 7.3 Identity protection . . . . . . . . . . . . . . . . . 40 93 7.4 Man-in-the-middle attacks . . . . . . . . . . . . . . 40 94 7.5 Packet modification attacks . . . . . . . . . . . . . 41 95 7.6 Dictionary attacks . . . . . . . . . . . . . . . . . . 42 96 7.7 Connection to an untrusted network . . . . . . . . . . 42 97 7.8 Negotiation attacks . . . . . . . . . . . . . . . . . 43 98 7.9 Implementation idiosyncrasies . . . . . . . . . . . . 43 99 7.10 Key derivation . . . . . . . . . . . . . . . . . . . . 43 100 7.11 Weak ciphersuites . . . . . . . . . . . . . . . . . . 44 101 7.12 Link layer . . . . . . . . . . . . . . . . . . . . . . 45 102 7.13 Separation of authenticator and backend authentication 103 server . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 104 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 47 105 Normative References . . . . . . . . . . . . . . . . . . . . 47 106 Informative References . . . . . . . . . . . . . . . . . . . 48 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 50 108 A. Method Specific Behavior . . . . . . . . . . . . . . . . . . 52 109 A.1 Message Integrity Checks . . . . . . . . . . . . . . . 52 110 B. Changes from RFC 2284 . . . . . . . . . . . . . . . . . . . 52 111 C. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 54 112 Intellectual Property and Copyright Statements . . . . . . . 55 114 1. Introduction 116 This document defines the Extensible Authentication Protocol (EAP), 117 an authentication framework which supports multiple authentication 118 methods. EAP typically runs directly over data link layers such as 119 PPP or IEEE 802, without requiring IP. EAP provides its own support 120 for duplicate elimination and retransmission, but is reliant on lower 121 layer ordering guarantees. Fragmentation is not supported within EAP 122 itself; however, individual EAP methods may support this. 124 EAP may be used on dedicated links as well as switched circuits, and 125 wired as well as wireless links. To date, EAP has been implemented 126 with hosts and routers that connect via switched circuits or dial-up 127 lines using PPP [RFC1661]. It has also been implemented with switches 128 and access points using IEEE 802 [IEEE-802]. EAP encapsulation on 129 IEEE 802 wired media is described in [IEEE-802.1X], and encapsulation 130 on IEEE wireless LANs in [IEEE-802.11i]. 132 One of the advantages of the EAP architecture is its flexibility. EAP 133 is used to select a specific authentication mechanism, typically 134 after the authenticator requests more information in order to 135 determine the specific authentication method to be used. Rather than 136 requiring the authenticator to be updated to support each new 137 authentication method, EAP permits the use of a backend 138 authentication server which may implement some or all authentication 139 methods, with the authenticator acting as a pass-through for some or 140 all methods and peers. 142 Within this document, authenticator requirements apply regardless of 143 whether the authenticator is operating as a pass-through or not. 144 Where the requirement is meant to apply to either the authenticator 145 or backend authentication server, depending on where the EAP 146 authentication is terminated, the term "EAP server" will be used. 148 1.1 Specification of Requirements 150 In this document, several words are used to signify the requirements 151 of the specification. These words are often capitalized. The key 152 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 153 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 154 are to be interpreted as described in [RFC2119]. 156 1.2 Terminology 158 This document frequently uses the following terms: 160 authenticator 161 The end of the EAP link initiating EAP authentication. The 162 term Authenticator is used in [IEEE-802.1X], and 163 authenticator has the same meaning in this document. 165 peer 166 The end of the EAP Link that responds to the authenticator. 167 In [IEEE-802.1X], this end is known as the Supplicant. 169 backend authentication server 170 A backend authentication server is an entity that provides 171 an authentication service to an authenticator. When used, 172 this server typically executes EAP methods for the 173 authenticator. This terminology is also used in 174 [IEEE-802.1X]. 176 Displayable Message 177 This is interpreted to be a human readable string of 178 characters. The message encoding MUST follow the UTF-8 179 transformation format [RFC2279]. 181 EAP server 182 The entity that terminates the EAP authentication method 183 with the peer. In the case where no backend authentication 184 server is used the EAP server is part of the authenticator. 185 In the case where the authenticator operates in 186 pass-through mode, the EAP server is located on the backend 187 authentication server. 189 Silently Discard 190 This means the implementation discards the packet without 191 further processing. The implementation SHOULD provide the 192 capability of logging the event, including the contents of 193 the silently discarded packet, and SHOULD record the event 194 in a statistics counter. 196 Successful authentication 197 In the context of this document, "successful 198 authentication" is an exchange of EAP messages, as a result 199 of which the authenticator decides to allow access by the 200 peer, and the peer decides to use this access. The 201 authenticator's decision typically involves both 202 authentication and authorization aspects; the peer may 203 successfully authenticate to the authenticator but access 204 may be denied by the authenticator due to policy reasons. 206 1.3 Security claims terminology for EAP methods 208 These terms are used to described the security properties of EAP 209 methods: 211 Mutual authentication 212 This refers to an EAP method in which, within an 213 interlocked exchange, the authenticator authenticates the 214 peer and the peer authenticates the authenticator. Two 215 independent one-way methods, running in opposite directions 216 do not provide mutual authentication as defined here. 218 Integrity protection 219 This refers to providing data origin authentication and 220 protection against unauthorized modification of information 221 for EAP packets (including EAP Requests and Responses). 222 When making this claim, a method specification MUST 223 describe the EAP packets and fields within the EAP packet 224 that are protected. 226 Replay protection 227 This refers to protection against replay of an EAP method 228 or its messages, including method-specific success and 229 failure indications. 231 Confidentiality 232 This refers to encryption of EAP messages, including EAP 233 Requests and Responses, and method-specific success and 234 failure indications. A method making this claim MUST 235 support identity protection (see Section 7.3). 237 Key derivation 238 This refers to the ability of the EAP method to derive 239 exportable keying material such as the Master Session Key 240 (MSK), and Extended Master Session Key (EMSK). The MSK is 241 used only for further key derivation, not directly for 242 protection of the EAP conversation or subsequent data. Use 243 of the EMSK is reserved. 245 Key strength 246 If the effective key strength is N bits, the best currently 247 known methods to recover the key (with non-negligible 248 probability) require an effort comparable to 2^N operations 249 of a typical block cipher. 251 Dictionary attack resistance 252 Where password authentication is used, users are 253 notoriously prone to select poor passwords. A method may 254 be said to be dictionary attack resistant if, when there is 255 a weak password in the secret, the method does not allow 256 an attack more efficient than brute force. 258 Fast reconnect 259 The ability, in the case where a security association has 260 been previously established, to create a new or refreshed 261 security association in a smaller number of round-trips. 263 Man-in-the-Middle resistance 264 This property applies only for the use of multiple methods 265 in a combination, such as in authentication sequences or 266 tunnels. It refers to the ability of the peer to 267 demonstrate to the authenticator that it has acted as the 268 peer for each authentication method within the 269 conversation. Similarly, the authenticator demonstrates to 270 the peer that it has acted as the authenticator for each 271 authentication method within the conversation. If this is 272 not possible, then there may be a vulnerability to a 273 man-in-the-middle attack. 275 Acknowledged result indications 276 The ability of the authenticator to provide the peer with 277 an indication of whether the peer has successfully 278 authenticated to it, and for the peer to acknowledge 279 receipt, as well as providing an indication of whether the 280 authenticator has successfully authenticated to the peer. 281 Since EAP Success and Failure packets are neither 282 acknowledged nor integrity protected, this claim requires 283 implementation of a method-specific result exchange that is 284 authenticated, integrity and replay protected on a 285 per-packet basis. 287 Message Integrity Check (MIC) 288 A keyed hash function used for authentication and integrity 289 protection of data. This is usually called a Message 290 Authentication Code (MAC), but IEEE 802 specifications (and 291 this document) use the acronym MIC to avoid confusion with 292 Medium Access Control. 294 Cryptographic binding 295 The demonstration of the EAP peer to the EAP server that a 296 single entity has acted as the EAP peer for all methods 297 executed within a sequence or tunnel. Binding MAY also 298 imply that the EAP server demonstrates to the peer that a 299 single entity has acted as the EAP server for all methods 300 executed within a sequence or tunnel. If executed 301 correctly, binding serves to mitigate man-in-the-middle 302 vulnerabilities. 304 Cryptographic separation 305 Two keys (x and y) are "cryptographically separate" if an 306 adversary that knows all messages exchanged in the protocol 307 cannot compute x from y or y from x without "breaking" some 308 cryptographic assumption. In particular, this definition 309 allows that the adversary has the knowledge of all nonces 310 sent in cleartext as well as all predictable counter values 311 used in the protocol. Breaking a cryptographic assumption 312 would typically require inverting a one- way function or 313 predicting the outcome of a cryptographic pseudo- random 314 number generator without knowledge of the secret state. In 315 other words, if the keys are cryptographically separate, 316 there is no shortcut to compute x from y or y from x, but 317 the work an adversary must do to perform this computation 318 is equivalent to performing exhaustive search for the 319 secret state value. 321 Master Session Key (MSK) 322 Keying material that is derived between the EAP client and 323 server. The MSK is used in the derivation of Transient 324 Session Keys (TSKs) for the ciphersuite negotiated between 325 the EAP peer and authenticator. Where a backend 326 authentication server is present, acting as an EAP server, 327 it will typically transport the MSK to the authenticator, 328 so that in this case, the MSK is available to the peer, 329 authenticator and authentication server. 331 Extended Master Session Key (EMSK) 332 Additional keying material derived between the EAP client 333 and server that is exported by the EAP method. Unlike the 334 MSK, the EMSK is known only to the EAP peer and EAP server 335 and is not provided to a third party. The EMSK is reserved 336 for future uses that are not defined yet. For example, it 337 could be used to derive additional keying material for 338 purposes such as fast handoff, man-in-the-middle 339 vulnerability protection, etc. 341 2. Extensible Authentication Protocol (EAP) 343 The EAP authentication exchange proceeds as follows: 345 [1] The authenticator sends a Request to authenticate the peer. The 346 Request has a Type field to indicate what is being requested. 347 Examples of Request Types include Identity, MD5-challenge, etc. 348 The MD5-challenge Type corresponds closely to the CHAP 349 authentication protocol [RFC1994]. Typically, the authenticator 350 will send an initial Identity Request; however, an initial 351 Identity Request is not required, and MAY be bypassed. For 352 example, the identity may not be required where it is determined 353 by the port to which the peer has connected (leased lines, 354 dedicated switch or dial-up ports); or where the identity is 355 obtained in another fashion (via calling station identity or MAC 356 address, in the Name field of the MD5-Challenge Response, etc.). 358 [2] The peer sends a Response packet in reply to a valid Request. As 359 with the Request packet the Response packet contains a Type 360 field, which corresponds to the Type field of the Request. 362 [3] The authenticator sends an additional Request packet, and the 363 peer replies with a Response. The sequence of Requests and 364 Responses continues as long as needed. EAP is a 'lock step' 365 protocol, so that other than the initial Request, a new Request 366 cannot be sent prior to receiving a valid Response. The 367 authenticator is responsible for retransmitting requests as 368 described in Section 4.1. After a suitable number of 369 retransmissions, the authenticator SHOULD end the EAP 370 conversation. The authenticator MUST NOT send a Success or 371 Failure packet when retransmitting or when it fails to get a 372 response from the peer. 374 [4] The conversation continues until the authenticator cannot 375 authenticate the peer (unacceptable Responses to one or more 376 Requests), in which case the authenticator implementation MUST 377 transmit an EAP Failure (Code 4). Alternatively, the 378 authentication conversation can continue until the authenticator 379 determines that successful authentication has occurred, in which 380 case the authenticator MUST transmit an EAP Success (Code 3). 382 Since EAP is a peer-to-peer protocol, an independent and simultaneous 383 authentication may take place in the reverse direction. Both peers 384 may act as authenticators and authenticatees at the same time. For a 385 discussion of security issues in peer-to-peer operation, see Section 386 7.7. 388 Advantages: 390 o The EAP protocol can support multiple authentication mechanisms 391 without having to pre-negotiate a particular one. 393 o Network Access Server (NAS) devices (e.g., a switch or access 394 point) do not have to understand each authentication method and 395 MAY act as a pass-through agent for a backend authentication 396 server. Support for pass-through is optional. An authenticator 397 MAY authenticate local peers while at the same time acting as a 398 pass-through for non-local peers and authentication methods it 399 does not implement locally. 401 o Separation of the authenticator from the backend authentication 402 server simplifies credentials management and policy decision 403 making. 405 Disadvantages: 407 o For use in PPP, EAP does require the addition of a new 408 authentication Type to PPP LCP and thus PPP implementations will 409 need to be modified to use it. It also strays from the previous 410 PPP authentication model of negotiating a specific authentication 411 mechanism during LCP. Similarly, switch or access point 412 implementations need to support [IEEE-802.1X] in order to use EAP. 414 o Where the authenticator is separate from the backend 415 authentication server, this complicates the security analysis and, 416 if needed, key distribution. 418 2.1 Support for sequences 420 An EAP conversation MAY utilize a sequence of methods. A common 421 example of this is an Identity request followed by a single EAP 422 authentication method such as an MD5-Challenge. However the peer and 423 authenticator MUST utilize only one authentication method (Type 4 or 424 greater) within an EAP conversation, after which the authenticator 425 MUST send a Success or Failure packet. 427 Once a peer has sent a Response of the same Type as the initial 428 Request, an authenticator MUST NOT send a Request of a different Type 429 prior to completion of the final round of a given method (with the 430 exception of a Notification-Request) and MUST NOT send a Request for 431 an additional method of any Type after completion of the initial 432 authentication method; a peer receiving such Requests MUST treat them 433 as invalid, and silently discard them. As a result, Identity Requery 434 is not supported. 436 A peer MUST NOT send a Nak (legacy or expanded) in reply to a 437 Request, after an initial non-Nak Response has been sent. Since 438 spoofed EAP Request packets may be sent by an attacker, an 439 authenticator receiving an unexpected Nak SHOULD silently discard it 440 and log the event. 442 Multiple authentication methods within an EAP conversation are not 443 supported due to their vulnerability to man-in-the-middle attacks 444 (see Section 7.4) and incompatibility with existing implementations. 446 Where a single EAP authentication method is utilized, but other 447 methods are run within it (a "tunneled" method) the prohibition 448 against multiple authentication methods does not apply. Such 449 "tunneled" methods appear as a single authentication method to EAP. 450 Backward compatibility can be provided, since a peer not supporting a 451 "tunneled" method can reply to the initial EAP-Request with a Nak 452 (legacy or expanded). To address security vulnerabilities, 453 "tunneled" methods MUST support protection against man-in-the-middle 454 attacks. 456 2.2 EAP multiplexing model 458 Conceptually, EAP implementations consist of the following 459 components: 461 [a] Lower layer. The lower layer is responsible for transmitting and 462 receiving EAP frames between the peer and authenticator. EAP has 463 been run over a variety of lower layers including PPP; wired IEEE 464 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; 465 UDP (L2TP [RFC2661] and ISAKMP [PIC]); and TCP [PIC]. Lower layer 466 behavior is discussed in Section 3. 468 [b] EAP layer. The EAP layer receives and transmits EAP packets via 469 the lower layer, implements duplicate detection and 470 retransmission, and delivers and receives EAP messages to and 471 from EAP methods. 473 [c] EAP method. EAP methods implement the authentication algorithms 474 and receive and transmit EAP messages via the EAP layer. Since 475 fragmentation support is not provided by EAP itself, this is the 476 responsibility of EAP methods, which are discussed in Section 5. 478 The EAP multiplexing model is illustrated in Figure 1 below. Note 479 that there is no requirement that an implementation conform to this 480 model, as long as the on-the-wire behavior is consistent with it. 482 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | | | | | 484 | EAP method| EAP method| | EAP method| EAP method| 485 | Type = X | Type = Y | | Type = X | Type = Y | 486 | V | | | ^ | | 487 +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ 488 | ! | | ! | 489 | EAP ! Layer | | EAP ! Layer | 490 | ! | | ! | 491 +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ 492 | ! | | ! | 493 | Lower ! Layer | | Lower ! Layer | 494 | ! | | ! | 495 +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ 496 ! ! 497 ! Peer ! Authenticator 498 +------------>-------------+ 500 Figure 1: EAP Multiplexing Model 502 Within EAP, the Type field functions much like a port number in UDP 503 or TCP. It is assumed that the EAP layer multiplexes incoming EAP 504 packets according to their Type, and delivers them only to the EAP 505 method corresponding to that Type code. 507 Since EAP authentication methods may wish to access the Identity, the 508 Identity Request and Response can be assumed to be accessible to 509 authentication methods (Types 4 or greater) in addition to the 510 Identity method. The Identity Type is discussed in Section 5.1. 512 A Notification Response is only used as confirmation that the peer 513 received the Notification Request, not that it has processed it, or 514 displayed the message to the user. It cannot be assumed that the 515 contents of the Notification Request or Response is available to 516 another method. The Notification Type is discussed in Section 5.2. 518 Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes 519 of method negotiation. Peers respond to an initial EAP Request for 520 an unacceptable Type with a Nak Response (Type 3) or Expanded Nak 521 Response (Type 254). It cannot be assumed that the contents of the 522 Nak Response(s) are available to another method. The Nak Type(s) are 523 discussed in Section 5.3. 525 EAP packets with codes of Success or Failure do not include a Type, 526 and therefore are not delivered to an EAP method. Success and 527 Failure are discussed in Section 4.2. 529 Given these considerations, the Success, Failure, Nak Response(s) and 530 Notification Request/Response messages MUST NOT be used to carry data 531 destined for delivery to other EAP methods. 533 Where an authenticator operates as a pass-through, it forwards 534 packets back and forth between the peer and a backend authentication 535 server, based on the EAP layer header fields (Code, Identifier, 536 Length). This includes performing validity checks on the Code, 537 Identifer and Length fields, as described in Section 4.1. 539 Since pass-through authenticators rely on a backend authenticator 540 server to implement methods, the EAP method layer header fields 541 (Type, Type-Data) are not examined as part of the forwarding 542 decision. The forwarding model is illustrated in Figure 2. Compliant 543 pass-through authenticator implementations MUST by default be capable 544 of forwarding packets from any EAP method. The use of the RADIUS 545 protocol for encapsulation of EAP in pass-through operation is 546 described in [RFC2869bis]. 548 Peer Pass-through Authenticator Authentication 549 Server 551 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 552 | | | | 553 |EAP method | |EAP method | 554 | Layer | | Layer | 555 | V | | ^ | 556 +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ 557 | ! | | | | | ! | 558 |EAP !Layer| | EAP Layer | EAP Layer | |EAP !Layer| 559 | ! | | +-----+-----+ | | ! | 560 | ! | | ! | ! | | ! | 561 +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ 562 | ! | | ! | ! | | ! | 563 |Lower!Layer| |Lower!Layer| AAA ! /IP | | AAA ! /IP | 564 | ! | | ! | ! | | ! | 565 +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ 566 ! ! ! ! 567 ! ! ! ! 568 +-------->-----+ +------->------+ 570 Figure 2: Pass-through Authenticator 572 For sessions in which the authenticator acts as a pass-through, it 573 MUST determine the outcome of the authentication solely based on the 574 Accept/Reject indication sent by the backend authentication server; 575 the outcome MUST NOT be determined by the contents of an EAP packet 576 sent along with the Accept/Reject indication, or the absence of such 577 an encapsulated EAP packet. 579 3. Lower layer behavior 581 3.1 Lower layer requirements 583 EAP makes the following assumptions about lower layers: 585 [1] Unreliable transport. In EAP, the authenticator retransmits 586 Requests that have not yet received Responses, so that EAP does 587 not assume that lower layers are reliable. Since EAP defines it 588 own retransmission behavior, when run over a reliable lower 589 layer, it is possible (though undesirable) for retransmission to 590 occur both in the lower layer and the EAP layer. 592 Note that EAP Success and Failure packets are not retransmitted. 593 Without a reliable lower layer, and a non-negligible error rate, 594 these packets can be lost, resulting in timeouts. It is therefore 595 desirable for implementations to improve their resilience to loss 596 of EAP Success or Failure packets, as described in Section 4.2. 598 [2] Lower layer error detection. While EAP does not assume that the 599 lower layer is reliable, it does rely on lower layer error 600 detection (e.g., CRC, Checksum, MIC, etc.). EAP methods may not 601 include a MIC, or if they do, it may not be computed over all the 602 fields in the EAP packet, such as the Code, Identifier, Length or 603 Type fields. As a result, without lower layer error detection, 604 undetected errors could creep into the EAP layer or EAP method 605 layer header fields, resulting in authentication failures. 607 For example, EAP TLS [RFC2716], which computes its MIC over the 608 Type-Data field only, regards MIC validation failures as a fatal 609 error. Without lower layer error detection, this method and 610 others like it will not perform reliably. 612 [3] Lower layer security. EAP assumes that lower layers either 613 provide physical security (e.g., wired PPP or IEEE 802 links) or 614 support per-packet authentication, integrity and replay 615 protection. EAP SHOULD NOT be used on physically insecure links 616 (e.g., wireless or the Internet) where subsequent data is not 617 protected by per-packet authentication, integrity and replay 618 protection. 620 After EAP authentication is complete, the peer will typically 621 transmit data to the network via the authenticator. In order to 622 provide assurance that the peer transmitting data is the same 623 entity that successfully completed EAP authentication, the lower 624 layer needs to bind per-packet integrity, authentication and 625 replay protection to the original EAP authentication, using keys 626 derived during EAP authentication. Alternatively, the lower 627 layer needs to be physically secure. Otherwise it is possible 628 for subsequent data traffic to be hijacked, or replayed. 630 As a result of these considerations, EAP SHOULD be used only when 631 lower layers provide physical security for data (e.g., wired PPP 632 or IEEE 802 links), or for insecure links, where per-packet 633 authentication, integrity and replay protection is provided. 635 Where keying material for the lower layer ciphersuite is itself 636 provided by EAP, ciphersuite negotiation and key activation is 637 controlled by the lower layer. In PPP, ciphersuites are 638 negotiated within ECP so that it is not possible to use keys 639 derived from EAP authentication until the completion of ECP. 640 Therefore an initial EAP exchange cannot protected by a PPP 641 ciphersuite, although EAP re-authentication can be protected. 643 In IEEE 802 media, key activation also typically occurs after 644 completion of EAP authentication. Therefore an initial EAP 645 exchange typically cannot be protected by lower layer 646 ciphersuite, although an EAP re-authentication or 647 pre-authentication exchange can be protected. 649 [4] MTU known a-priori. The EAP layer does not support fragmentation 650 and reassembly. However, EAP methods SHOULD be capable of 651 handling fragmentation and reassembly. As a result, EAP is 652 capable of functioning across a range of MTU sizes, as long as 653 the MTU is known a-priori. EAP does not support path MTU 654 discovery. 656 [5] Possible duplication. Where the lower layer is reliable, it will 657 provide the EAP layer with a non-duplicated stream of packets. 658 However, while it is desirable that lower layers provide for 659 non-duplication, this is not a requirement. The Identifier field 660 provides both the peer and authenticator with the ability to 661 detect duplicates. 663 [6] Ordering guarantees. EAP does not require the Identifier to be 664 monotonically increasing, and so is reliant on lower layer 665 ordering guarantees for correct operation. EAP was originally 666 defined to run on PPP, and [RFC1661] Section 1 has an ordering 667 requirement: 669 "The Point-to-Point Protocol is designed for simple links which 670 transport packets between two peers. These links provide 671 full-duplex simultaneous bi-directional operation, and are 672 assumed to deliver packets in order." 673 Lower layer transports for EAP MUST preserve ordering between a 674 source and destination, at a given priority level (the ordering 675 guarantee provided by [IEEE-802]). 677 3.2 EAP usage within PPP 679 In order to establish communications over a point-to-point link, each 680 end of the PPP link must first send LCP packets to configure the data 681 link during Link Establishment phase. After the link has been 682 established, PPP provides for an optional Authentication phase before 683 proceeding to the Network-Layer Protocol phase. 685 By default, authentication is not mandatory. If authentication of 686 the link is desired, an implementation MUST specify the 687 Authentication Protocol Configuration Option during Link 688 Establishment phase. 690 If the identity of the peer has been established in the 691 Authentication phase, the server can use that identity in the 692 selection of options for the following network layer negotiations. 694 When implemented within PPP, EAP does not select a specific 695 authentication mechanism at PPP Link Control Phase, but rather 696 postpones this until the Authentication Phase. This allows the 697 authenticator to request more information before determining the 698 specific authentication mechanism. This also permits the use of a 699 "backend" server which actually implements the various mechanisms 700 while the PPP authenticator merely passes through the authentication 701 exchange. The PPP Link Establishment and Authentication phases, and 702 the Authentication Protocol Configuration Option, are defined in The 703 Point-to-Point Protocol (PPP) [RFC1661]. 705 3.2.1 PPP Configuration Option Format 707 A summary of the PPP Authentication Protocol Configuration Option 708 format to negotiate EAP is shown below. The fields are transmitted 709 from left to right. 711 Exactly one EAP packet is encapsulated in the Information field of a 712 PPP Data Link Layer frame where the protocol field indicates type hex 713 C227 (PPP EAP). 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Type | Length | Authentication Protocol | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Type 722 3 724 Length 726 4 728 Authentication Protocol 730 C227 (Hex) for Extensible Authentication Protocol (EAP) 732 3.3 EAP usage within IEEE 802 734 The encapsulation of EAP over IEEE 802 is defined in [IEEE-802.1X]. 735 The IEEE 802 encapsulation of EAP does not involve PPP, and IEEE 736 802.1X does not include support for link or network layer 737 negotiations. As a result, within IEEE 802.1X it is not possible to 738 negotiate non-EAP authentication mechanisms, such as PAP or CHAP 739 [RFC1994]. 741 3.4 Lower layer indications 743 The reliability and security of lower layer indications is dependent 744 on the lower layer. Since EAP is media independent, the presence or 745 absence of lower layer security is not taken into account in the 746 processing of EAP messages. 748 Section 4.2 defines the circumstances in which a peer, having 749 concluded an EAP method with successful acknowledged result 750 indications, may conclude that a Success packet has been lost after 751 expiration of a timeout. In those same circumstances, if a peer 752 receives a lower layer success indication as defined in Section 7.2, 753 it MAY conclude that a Success packet has been lost without waiting 754 for a timeout. This ensures that an attacker spoofing lower layer 755 indications can at best succeed in a denial of service attack. 757 A discussion of some reliability and security issues with lower layer 758 indications in PPP, IEEE 802 wired networks and IEEE 802.11 wireless 759 LANs can be found in the Security Considerations, Section 7.12. 761 4. EAP Packet format 763 A summary of the EAP packet format is shown below. The fields are 764 transmitted from left to right. 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Code | Identifier | Length | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Data ... 772 +-+-+-+-+ 774 Code 776 The Code field is one octet and identifies the Type of EAP packet. 777 EAP Codes are assigned as follows: 779 1 Request 780 2 Response 781 3 Success 782 4 Failure 784 Since EAP only defines Codes 1-4, EAP packets with other codes 785 MUST be silently discarded by both authenticators and peers. 787 Identifier 789 The Identifier field is one octet and aids in matching Responses 790 with Requests. 792 Length 794 The Length field is two octets and indicates the length of the EAP 795 packet including the Code, Identifier, Length and Data fields. 796 Octets outside the range of the Length field should be treated as 797 Data Link Layer padding and MUST be ignored on reception. A 798 message with the Length field set to a value larger than the 799 number of received octets MUST be silently discarded. 801 Data 803 The Data field is zero or more octets. The format of the Data 804 field is determined by the Code field. 806 4.1 Request and Response 808 Description 810 The Request packet (Code field set to 1) is sent by the 811 authenticator to the peer. Each Request has a Type field which 812 serves to indicate what is being requested. Additional Request 813 packets MUST be sent until a valid Response packet is received, or 814 an optional retry counter expires. 816 Retransmitted Requests MUST be sent with the same Identifier value 817 in order to distinguish them from new Requests. The contents of 818 the data field are dependent on the Request Type. The peer MUST 819 send a Response packet in reply to a valid Request packet. 820 Responses MUST only be sent in reply to a valid Request and never 821 retransmitted on a timer. 823 The Identifier field of the Response MUST match that of the 824 currently outstanding Request. An authenticator receiving a 825 Response whose Identifier value does not match that of the 826 currently outstanding Request MUST silently discard the Response. 827 The Type field of a Response MUST either match that of the 828 Request, or correspond to a legacy or Expanded Nak (see Section 829 5.3). An EAP server receiving a Response not meeting this 830 requirement MUST silently discard it. 832 Implementation Note: The authenticator is responsible for 833 retransmitting Request messages. If the Request message is 834 obtained from elsewhere (such as from a backend authentication 835 server), then the authenticator will need to save a copy of the 836 Request in order to accomplish this. The peer is responsible 837 for detecting and handling duplicate Request messages before 838 processing them in any way, including passing them on to an 839 outside party. The authenticator is also responsible for 840 discarding Response messages with a non-matching Identifier 841 value before acting on them in any way, including passing them 842 on to the backend authentication server for verification. 843 Since the authenticator can retransmit before receiving a 844 Response from the peer, the authenticator can receive multiple 845 Responses, each with a matching Identifier. Until a new Request 846 is received by the authenticator, the Identifier value is not 847 updated, so that the authenticator forwards Responses to the 848 backend authentication server, one at a time. 850 A summary of the Request and Response packet format is shown below. 851 The fields are transmitted from left to right. 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Code | Identifier | Length | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Type | Type-Data ... 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 860 Code 862 1 for Request 863 2 for Response 865 Identifier 867 The Identifier field is one octet. The Identifier field MUST be 868 the same if a Request packet is retransmitted due to a timeout 869 while waiting for a Response. Any new (non-retransmission) 870 Requests MUST modify the Identifier field. In order to avoid 871 confusion between new Requests and retransmissions, the Identifier 872 value chosen for each new Request need only be different from the 873 previous Request, but need not be unique within the conversation. 874 One way to achieve this is to start the Identifier at an initial 875 value and increment it for each new Request. Initializing the 876 first Identifier with a random number rather than starting from 877 zero is recommended, since it makes sequence attacks somewhat 878 harder. 880 Since the Identifier space is unique to each session, 881 authenticators are not restricted to only 256 simultaneous 882 authentication conversations. Similarly, with re-authentication, 883 an EAP conversation might continue over a long period of time, and 884 is not limited to only 256 roundtrips. 886 If a peer receives a valid duplicate Request for which it has 887 already sent a Response, it MUST resend its original Response 888 without reprocessing the Request. Requests MUST be processed in 889 the order that they are received, and MUST be processed to their 890 completion before inspecting the next Request. 892 Length 894 The Length field is two octets and indicates the length of the EAP 895 packet including the Code, Identifier, Length, Type, and Type-Data 896 fields. Octets outside the range of the Length field should be 897 treated as Data Link Layer padding and MUST be ignored on 898 reception. A message with the Length field set to a value larger 899 than the number of received octets MUST be silently discarded. 901 Type 903 The Type field is one octet. This field indicates the Type of 904 Request or Response. A single Type MUST be specified for each EAP 905 Request or Response. Normally, the Type field of the Response 906 will be the same as the Type of the Request. However, there are 907 also Nak Response Types for indicating that a Request Type is 908 unacceptable to the peer (see Section 5.3). An initial 909 specification of Types follows in Section 5 of this document. 911 Type-Data 913 The Type-Data field varies with the Type of Request and the 914 associated Response. 916 4.2 Success and Failure 918 The Success packet is sent by the authenticator to the peer after 919 completion of an EAP authentication method (Type 4 or greater), to 920 indicate that the peer has authenticated successfully to the 921 authenticator. The authenticator MUST transmit an EAP packet with 922 the Code field set to 3 (Success). If the authenticator cannot 923 authenticate the peer (unacceptable Responses to one or more 924 Requests) then after unsuccessful completion of the EAP method in 925 progress, the implementation MUST transmit an EAP packet with the 926 Code field set to 4 (Failure). An authenticator MAY wish to issue 927 multiple Requests before sending a Failure response in order to allow 928 for human typing mistakes. Success and Failure packets MUST NOT 929 contain additional data. 931 Success or Failure packets MUST NOT be sent by an EAP authenticator 932 prior to completion of the final round of a given method. A peer EAP 933 implementation receiving a Success or Failure packet prior to 934 completion of the method in progress MUST silently discard it. By 935 default, an EAP peer MUST silently discard a "canned" Success packet 936 (a Success packet sent immediately upon connection). This ensures 937 that a rogue authenticator will not be able to bypass mutual 938 authentication by sending a Success packet prior to conclusion of the 939 EAP method conversation. 941 Implementation Note: Because the Success and Failure packets are 942 not acknowledged, they are not retransmitted by the authenticator, 943 and may be potentially lost. A peer MUST allow for this 944 circumstance as described in this note. See also Section 3.4 for 945 guidance on the processing of lower layer success and failure 946 indications. 948 As described in Section 2.1, only a single EAP authentication 949 method is allowed within an EAP conversation. EAP methods MAY 950 implement acknowledged result indications. After the authenticator 951 sends a method-specific failure indication to the peer, regardless 952 of the response from the peer, it MUST subsequently send a Failure 953 packet. After the authenticator sends a method-specific success 954 indication to the peer, and receives a method-specific success 955 indication from the peer, it MUST subsequently send a Success 956 packet. 958 On the peer, once the method completes unsuccessfully (that is, 959 either the authenticator sends a method-specific failure 960 indication, or the peer decides that it does want to continue the 961 conversation, possibly after sending a method-specific failure 962 indication), the peer MUST terminate the conversation and avoid 963 sending data on the link. The peer MUST silently discard Success 964 packets and MAY silently discard Failure packets. As a result, 965 loss of a Failure packet need not result in a timeout. 967 On the peer, after acknowledged successful result indications have 968 been exchanged by both sides, a Failure packet MUST be silently 969 discarded. The peer MAY, in the event that an EAP Success is not 970 received, conclude that the EAP Success packet was lost and that 971 authentication concluded successfully. 973 A mutually authenticating method (such as EAP-TLS [RFC2716]) that 974 provides authorization error messages provides acknowledged result 975 indications for the purpose of this specification. Within 976 EAP-TLS, the peer always authenticates the authenticator, and may 977 send a TLS-alert message in the event of an authentication 978 failure. An authenticator may use the "access denied" TLS alert 979 after successfully authenticating the peer to indicate that a 980 valid certificate was received from the peer, but when access 981 control was applied, the authenticator decided not to proceed. If 982 a method provides authorization error messages, the authenticator 983 SHOULD use them so as to ensure consistency with the final access 984 decision and avoid lengthy timeouts. 986 If the authenticator has not sent a method-specific result 987 indication, and the peer is willing to continue the conversation, 988 once the method completes the peer waits for a Success or Failure 989 packet and MUST NOT silently discard either of them. In the event 990 that neither a Success nor Failure packet is received, the peer 991 SHOULD terminate the conversation to avoid lengthy timeouts in 992 case the lost packet was an EAP Failure. 994 If the peer attempts to authenticate to the authenticator and 995 fails to do so, the authenticator MUST send a Failure packet and 996 MUST NOT grant access by sending a Success packet. However, an 997 authenticator MAY omit having the peer authenticate to it in 998 situations where limited access is offered (e.g., guest access). 999 In this case the authenticator MUST send a Success packet. 1001 Where the peer authenticates successfully to the authenticator, 1002 but the authenticator does not send a method-specific result 1003 indication the authenticator MAY deny access by sending a Failure 1004 packet where the peer is not currently authorized for network 1005 access. 1007 A summary of the Success and Failure packet format is shown below. 1008 The fields are transmitted from left to right. 1010 0 1 2 3 1011 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 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Code | Identifier | Length | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 Code 1018 3 for Success 1019 4 for Failure 1021 Identifier 1023 The Identifier field is one octet and aids in matching replies to 1024 Responses. The Identifier field MUST match the Identifier field 1025 of the Response packet that it is sent in response to. 1027 Length 1029 4 1031 4.3 Retransmission Behavior 1033 Because the authentication process will often involve user input, 1034 some care must be taken when deciding upon retransmission strategies 1035 and authentication timeouts. By default, where EAP is run over an 1036 unreliable lower layer, the EAP retransmission timer SHOULD be 1037 dynamically estimated. A maximum of 3-5 retransmissions is 1038 suggested. 1040 When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as 1041 within [PIC]), the authenticator retransmission timer SHOULD be set 1042 to an infinite value, so that retransmissions do not occur at the EAP 1043 layer. The peer may still maintain a timeout value so as to avoid 1044 waiting indefinitely for a Request. 1046 Where the authentication process requires user input, the measured 1047 round trip times may be determined by user responsiveness rather than 1048 network characteristics, so that dynamic RTO estimation may not be 1049 helpful. Instead, the retransmission timer SHOULD be set so as to 1050 provide sufficient time for the user to respond, with longer timeouts 1051 required in certain cases, such as where Token Cards (see Section 1052 5.6) are involved. 1054 In order to provide the EAP authenticator with guidance as to the 1055 appropriate timeout value, a hint can be communicated to the 1056 authenticator by the backend authentication server (such as via the 1057 RADIUS Session-Timeout attribute). 1059 In order to dynamically estimate the EAP retransmission timer, the 1060 algorithms for estimation of SRTT, RTTVAR and RTO described in 1061 [RFC2988] are RECOMMENDED, including use of Karn's algorithm, with 1062 the following potential modifications: 1064 [a] In order to avoid synchronization behaviors that can occur with 1065 fixed timers among distributed systems, the retransmission timer 1066 is calculated with a jitter by using the RTO value and randomly 1067 adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative 1068 calculations to create jitter MAY be used. These MUST be 1069 pseudo-random, generated by a PRNG seeded as per [RFC1750]. 1071 [b] When EAP is transported over a single link (as opposed to over 1072 the Internet), smaller values of RTOinitial, RTOmin and RTOmax 1073 MAY be used. Recommended values are RTOinitial=1 second, 1074 RTOmin=200ms, RTOmax=20 seconds. 1076 [c] When EAP is transported over a single link (as opposed to over 1077 the Internet), estimates MAY be done on a per-authenticator 1078 basis, rather than a per-session basis. This enables the 1079 retransmission estimate to make the most use of information on 1080 link-layer behavior. 1082 [d] An EAP implementation MAY clear SRTT and RTTVAR after backing off 1083 the timer multiple times as it is likely that the current SRTT 1084 and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are 1085 cleared they should be initialized with the next RTT sample taken 1086 as described in [RFC2988] equation 2.2. 1088 5. Initial EAP Request/Response Types 1090 This section defines the initial set of EAP Types used in Request/ 1091 Response exchanges. More Types may be defined in follow-on 1092 documents. The Type field is one octet and identifies the structure 1093 of an EAP Request or Response packet. The first 3 Types are 1094 considered special case Types. 1096 The remaining Types define authentication exchanges. Nak (Type 3) or 1097 Expanded Nak (Type 254) are valid only for Response packets, they 1098 MUST NOT be sent in a Request. 1100 All EAP implementations MUST support Types 1-4, which are defined in 1101 this document, and SHOULD support Type 254. Implementations MAY 1102 support other Types defined here or in future RFCs. 1104 1 Identity 1105 2 Notification 1106 3 Nak (Response only) 1107 4 MD5-Challenge 1108 5 One Time Password (OTP) 1109 6 Generic Token Card (GTC) 1110 254 Expanded Types 1111 255 Experimental use 1113 EAP methods MAY support authentication based on shared secrets. If 1114 the shared secret is a passphrase entered by the user, 1115 implementations MAY support entering passphrases with non-ASCII 1116 characters. In this case, the input should be processed using an 1117 appropriate stringprep [RFC3454] profile, and encoded in octets using 1118 UTF-8 encoding [RFC2279]. A preliminary version of a possible 1119 stringprep profile is described in [SASLPREP]. 1121 5.1 Identity 1123 Description 1125 The Identity Type is used to query the identity of the peer. 1126 Generally, the authenticator will issue this as the initial 1127 Request. An optional displayable message MAY be included to 1128 prompt the peer in the case where there is an expectation of 1129 interaction with a user. A Response of Type 1 (Identity) SHOULD 1130 be sent in Response to a Request with a Type of 1 (Identity). 1132 Since Identity Requests and Responses are not protected, from a 1133 privacy perspective, it may be preferable for protected 1134 method-specific Identity exchanges to be used instead. Where the 1135 peer is configured to only accept authentication methods 1136 supporting protected identity exchanges, the peer MAY provide an 1137 abbreviated Identity Response (such as omitting the peer-name 1138 portion of the NAI [RFC2486]). For further discussion of identity 1139 protection, see Section 7.3. 1141 Implementation Note: The peer MAY obtain the Identity via user 1142 input. It is suggested that the authenticator retry the 1143 Identity Request in the case of an invalid Identity or 1144 authentication failure to allow for potential typos on the part 1145 of the user. It is suggested that the Identity Request be 1146 retried a minimum of 3 times before terminating the 1147 authentication phase with a Failure reply. The Notification 1148 Request MAY be used to indicate an invalid authentication 1149 attempt prior to transmitting a new Identity Request 1150 (optionally, the failure MAY be indicated within the message of 1151 the new Identity Request itself). 1153 Type 1155 1 1157 Type-Data 1159 This field MAY contain a displayable message in the Request, 1160 containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where 1161 the Request contains a null, only the portion of the field prior 1162 to the null is displayed. If the Identity is unknown, the 1163 Identity Response field should be zero bytes in length. The 1164 Identity Response field MUST NOT be null terminated. In all 1165 cases, the length of the Type-Data field is derived from the 1166 Length field of the Request/Response packet. 1168 5.2 Notification 1170 Description 1172 The Notification Type is optionally used to convey a displayable 1173 message from the authenticator to the peer. An authenticator MAY 1174 send a Notification Request to the peer at any time when there is 1175 no outstanding Request, prior to completion of an EAP 1176 authentication method. The peer MUST respond to a Notification 1177 Request with a Notification Response unless the EAP authentication 1178 method specification prohibits the use of Notification message. 1179 In any case, a Nak Response MUST NOT be sent in response to a 1180 Notification Request. 1182 An EAP method MAY indicate within its specification that 1183 Notification messages must not be sent during that method. In this 1184 case, the peer MUST silently discard Notification Requests from 1185 the point where an initial Request for that Type is answered with 1186 a Response of the same Type. 1188 The peer SHOULD display this message to the user or log it if it 1189 cannot be displayed. The Notification Type is intended to provide 1190 an acknowledged notification of some imperative nature, but it is 1191 not an error indication, and therefore does not change the state 1192 of the peer. Examples include a password with an expiration time 1193 that is about to expire, an OTP sequence integer which is nearing 1194 0, an authentication failure warning, etc. In most circumstances, 1195 Notification should not be required. 1197 Type 1199 2 1201 Type-Data 1203 The Type-Data field in the Request contains a displayable message 1204 greater than zero octets in length, containing UTF-8 encoded ISO 1205 10646 characters [RFC2279]. The length of the message is 1206 determined by Length field of the Request packet. The message 1207 MUST NOT be null terminated. A Response MUST be sent in reply to 1208 the Request with a Type field of 2 (Notification). The Type-Data 1209 field of the Response is zero octets in length. The Response 1210 should be sent immediately (independent of how the message is 1211 displayed or logged). 1213 5.3 Nak 1215 5.3.1 Legacy Nak 1217 Description 1219 The legacy Nak Type is valid only in Response messages. It is 1220 sent in reply to a Request where the desired authentication Type 1221 is unacceptable. Authentication Types are numbered 4 and above. 1222 The Response contains one or more authentication Types desired by 1223 the Peer. Type zero (0) is used to indicate that the sender has 1224 no viable alternatives. 1226 Since the legacy Nak Type is valid only in Responses and has very 1227 limited functionality, it MUST NOT be used as a general purpose 1228 error indication, such as for communication of error messages, or 1229 negotiation of parameters specific to a particular EAP method. 1231 Code 1233 2 for Response. 1235 Identifier 1237 The Identifier field is one octet and aids in matching Responses 1238 with Requests. The Identifier field of a legacy Nak Response MUST 1239 match the Identifier field of the Request packet that it is sent 1240 in response to. 1242 Length 1244 >=6 1246 Type 1248 3 1250 Type-Data 1252 Where a peer receives a Request for an unacceptable authentication 1253 Type (4-253,255), or a peer lacking support for Expanded Types 1254 receives a Request for Type 254, a Nak Response (Type 3) MUST be 1255 sent. The Type-Data field of the Nak Response (Type 3) MUST 1256 contain one or more octets indicating the desired authentication 1257 Type(s), one octet per Type, or the value zero (0) to indicate no 1258 proposed alternative. A peer supporting Expanded Types that 1259 receives a Request for an unacceptable authentication Type (4-253, 1260 255) MAY include the value 254 in the Nak Response (Type 3) in 1261 order to indicate the desire for an Expanded authentication Type. 1262 If the authenticator can accommodate this preference, it will 1263 respond with an Expanded Type Request (Type 254). 1265 5.3.2 Expanded Nak 1267 Description 1269 The Expanded Nak Type is valid only in Response messages. It MUST 1270 be sent only in reply to a Request of Type 254 (Expanded Type) 1271 where the authentication Type is unacceptable. The Expanded Nak 1272 Type uses the Expanded Type format itself, and the Response 1273 contains one or more authentication Types desired by the peer, all 1274 in Expanded Type format. Type zero (0) is used to indicate that 1275 the sender has no viable alternatives. The general format of the 1276 Expanded Type is described in Section 5.7. 1278 Since the Expanded Nak Type is valid only in Responses and has 1279 very limited functionality, it MUST NOT be used as a general 1280 purpose error indication, such as for communication of error 1281 messages, or negotiation of parameters specific to a particular 1282 EAP method. 1284 Code 1286 2 for Response. 1288 Identifier 1290 The Identifier field is one octet and aids in matching Responses 1291 with Requests. The Identifier field of an Expanded Nak Response 1292 MUST match the Identifier field of the Request packet that it is 1293 sent in response to. 1295 Length 1297 >=40 1299 Type 1301 254 1303 Vendor-Id 1305 0 (IETF) 1307 Vendor-Type 1309 3 (Nak) 1311 Vendor-Data 1313 The Expanded Nak Type is only sent when the Request contains an 1314 Expanded Type (254) as defined in Section 5.7. The Vendor-Data 1315 field of the Nak Response MUST contain one or more authentication 1316 Types (4 or greater), all in expanded format, 8 octets per Type, 1317 or the value zero (0), also in Expanded Type format, to indicate 1318 no proposed alternative. The desired authentication Types may 1319 include a mixture of Vendor-Specific and IETF Types. For example, 1320 an Expanded Nak Response indicating a preference for OTP (Type 5), 1321 and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as 1322 follows: 1324 0 1 2 3 1325 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 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | 2 | Identifier | Length | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Type=254 | 0 (IETF) | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | 3 (Nak) | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Type=254 | 0 (IETF) | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | 5 (OTP) | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Type=254 | 20 (MIT) | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | 6 | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 An Expanded Nak Response indicating a no desired alternative would 1343 appear as follows: 1345 0 1 2 3 1346 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 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | 2 | Identifier | Length | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Type=254 | 0 (IETF) | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | 3 (Nak) | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Type=254 | 0 (IETF) | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | 0 (No alternative) | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 5.4 MD5-Challenge 1361 Description 1363 The MD5-Challenge Type is analogous to the PPP CHAP protocol 1364 [RFC1994] (with MD5 as the specified algorithm). The Request 1365 contains a "challenge" message to the peer. A Response MUST be 1366 sent in reply to the Request. The Response MAY be either of Type 1367 4 (MD5-Challenge), Nak (Type 3) or Expanded Nak (Type 254). The 1368 Nak reply indicates the peer's desired authentication Type(s). 1369 EAP peer and EAP server implementations MUST support the 1370 MD5-Challenge mechanism. An authenticator that supports only 1371 pass-through MUST allow communication with a backend 1372 authentication server that is capable of supporting MD5-Challenge, 1373 although the EAP authenticator implementation need not support 1374 MD5-Challenge itself. However, if the EAP authenticator can be 1375 configured to authenticate peers locally (e.g., not operate in 1376 pass-through), then the requirement for support of the 1377 MD5-Challenge mechanism applies. 1379 Note that the use of the Identifier field in the MD5-Challenge 1380 Type is different from that described in [RFC1994]. EAP allows 1381 for retransmission of MD5-Challenge Request packets while 1382 [RFC1994] states that both the Identifier and Challenge fields 1383 MUST change each time a Challenge (the CHAP equivalent of the 1384 MD5-Challenge Request packet) is sent. 1386 Note: [RFC1994] treats the shared secret as an octet string, and 1387 does not specify how it is entered into the system (or if it is 1388 handled by the user at all). EAP MD5-Challenge implementations MAY 1389 support entering passphrases with non-ASCII characters. See 1390 Section 5 for instructions how the input should be processed and 1391 encoded into octets. 1393 Type 1395 4 1397 Type-Data 1399 The contents of the Type-Data field is summarized below. For 1400 reference on the use of these fields see the PPP Challenge 1401 Handshake Authentication Protocol [RFC1994]. 1403 0 1 2 3 1404 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 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Value-Size | Value ... 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Name ... 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 Security Claims (see Section 7.2): 1413 Intended use: Wired networks, including PPP, PPPOE, and 1414 IEEE 802 wired media. Use over the 1415 Internet or with wireless media only when 1416 protected. 1417 Mechanism: Password or pre-shared key. 1418 Mutual authentication: No 1419 Integrity protection: No 1420 Replay protection: No 1421 Confidentiality: No 1422 Key Derivation: No 1423 Key strength: N/A 1424 Dictionary attack prot: No 1425 Key hierarchy: N/A 1426 Fast reconnect: No 1427 MiTM resistance: N/A 1428 Acknowledged S/F: No 1430 5.5 One-Time Password (OTP) 1432 Description 1434 The One-Time Password system is defined in "A One-Time Password 1435 System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The 1436 Request contains an OTP challenge in the format described in 1437 [RFC2289]. A Response MUST be sent in reply to the Request. The 1438 Response MUST be of Type 5 (OTP), Nak (Type 3) or Expanded Nak 1439 (Type 254). The Nak Response indicates the peer's desired 1440 authentication Type(s). 1442 Type 1444 5 1446 Type-Data 1448 The Type-Data field contains the OTP "challenge" as a displayable 1449 message in the Request. In the Response, this field is used for 1450 the 6 words from the OTP dictionary [RFC2289]. The messages MUST 1451 NOT be null terminated. The length of the field is derived from 1452 the Length field of the Request/Reply packet. 1454 Note: [RFC2289] does not specify how the secret pass-phrase is 1455 entered by the user, or how the pass-phrase is converted into 1456 octets. EAP OTP implementations MAY support entering passphrases 1457 with non-ASCII characters. See Section 5 for instructions how the 1458 input should be processed and encoded into octets. 1460 Security Claims (see Section 7.2): 1462 Intended use: Wired networks, including PPP, PPPOE, and 1463 IEEE 802 wired media. Use over the 1464 Internet or with wireless media only when 1465 protected. 1466 Mechanism: One-Time Password 1467 Mutual authentication: No 1468 Integrity protection: No 1469 Replay protection: No 1470 Confidentiality: No 1471 Key Derivation: No 1472 Key strength: N/A 1473 Dictionary attack prot: No 1474 Key hierarchy: N/A 1475 Fast reconnect: No 1476 MiTM resistance: N/A 1477 Acknowledged S/F: No 1479 5.6 Generic Token Card (GTC) 1481 Description 1483 The Generic Token Card Type is defined for use with various Token 1484 Card implementations which require user input. The Request 1485 contains a displayable message and the Response contains the Token 1486 Card information necessary for authentication. Typically, this 1487 would be information read by a user from the Token card device and 1488 entered as ASCII text. A Response MUST be sent in reply to the 1489 Request. The Response MUST be of Type 6 (GTC), Nak (Type 3) or 1490 Expanded Nak (Type 254). The Nak Response indicates the peer's 1491 desired authentication Type(s). 1493 Type 1495 6 1497 Type-Data 1499 The Type-Data field in the Request contains a displayable message 1500 greater than zero octets in length. The length of the message is 1501 determined by the Length field of the Request packet. The message 1502 MUST NOT be null terminated. A Response MUST be sent in reply to 1503 the Request with a Type field of 6 (Generic Token Card). The 1504 Response contains data from the Token Card required for 1505 authentication. The length of the data is determined by the 1506 Length field of the Response packet. 1508 EAP GTC implementations MAY support entering a response with 1509 non-ASCII characters. See Section 5 for instructions how the 1510 input should be processed and encoded into octets. 1512 Security Claims (see Section 7.2): 1514 Intended use: Wired networks, including PPP, PPPOE, and 1515 IEEE 802 wired media. Use over the 1516 Internet or with wireless media only when 1517 protected. 1518 Mechanism: Hardware token. 1519 Mutual authentication: No 1520 Integrity protection: No 1521 Replay protection: No 1522 Confidentiality: No 1523 Key Derivation: No 1524 Key strength: N/A 1525 Dictionary attack prot: No 1526 Key hierarchy: N/A 1527 Fast reconnect: No 1528 MiTM resistance: N/A 1529 Acknowledged S/F: No 1531 5.7 Expanded Types 1533 Description 1535 Since many of the existing uses of EAP are vendor-specific, the 1536 Expanded method Type is available to allow vendors to support 1537 their own Expanded Types not suitable for general usage. 1539 The Expanded Type is also used to expand the global Method Type 1540 space beyond the original 255 values. A Vendor-Id of 0 maps the 1541 original 255 possible Types onto a namespace of 2^32-1 possible 1542 Types, allowing for virtually unlimited expansion. (Type 0 is only 1543 used in a Nak Response, to indicate no acceptable alternative) 1545 An implementation that supports the Expanded attribute MUST treat 1546 EAP Types that are less than 256 equivalently whether they appear 1547 as a single octet or as the 32-bit Vendor-Type within a Expanded 1548 Type where Vendor-Id is 0. Peers not equipped to interpret the 1549 Expanded Type MUST send a Nak as described in Section 5.3.1, and 1550 negotiate a more suitable authentication method. 1552 A summary of the Expanded Type format is shown below. The fields 1553 are transmitted from left to right. 1555 0 1 2 3 1556 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 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Type | Vendor-Id | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | Vendor-Type | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Vendor data... 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 Type 1567 254 for Expanded Type 1569 Vendor-Id 1571 The Vendor-Id is 3 octets and represents the SMI Network 1572 Management Private Enterprise Code of the Vendor in network byte 1573 order, as allocated by IANA. A Vendor-Id of zero is reserved for 1574 use by the IETF in providing an expanded global EAP Type space. 1576 Vendor-Type 1578 The Vendor-Type field is four octets and represents the 1579 vendor-specific method Type. 1581 If the Vendor-Id is zero, the Vendor-Type field is an extension 1582 and superset of the existing namespace for EAP Types. The first 1583 256 Types are reserved for compatibility with single-octet EAP 1584 Types that have already been assigned or may be assigned in the 1585 future. Thus, EAP Types from 0 through 255 are semantically 1586 identical whether they appear as single octet EAP Types or as 1587 Vendor-Types when Vendor-Id is zero. 1589 Vendor-Data 1591 The Vendor-Data field is defined by the vendor. Where a Vendor-Id 1592 of zero is present, the Vendor-Data field will be used for 1593 transporting the contents of EAP methods of Types defined by the 1594 IETF. 1596 5.8 Experimental 1597 Description 1599 The Experimental Type has no fixed format or content. It is 1600 intended for use when experimenting with new EAP Types. This Type 1601 is intended for experimental and testing purposes. No guarantee 1602 is made for interoperability between peers using this Type, as 1603 outlined in [IANA-EXP]. 1605 Type 1607 255 1609 Type-Data 1611 Undefined 1613 6. IANA Considerations 1615 This section provides guidance to the Internet Assigned Numbers 1616 Authority (IANA) regarding registration of values related to the EAP 1617 protocol, in accordance with BCP 26, [RFC2434]. 1619 There are two name spaces in EAP that require registration: Packet 1620 Codes and method Types. 1622 EAP is not intended as a general-purpose protocol, and allocations 1623 SHOULD NOT be made for purposes unrelated to authentication. 1625 The following terms are used here with the meanings defined in BCP 1626 26: "name space", "assigned value", "registration". 1628 The following policies are used here with the meanings defined in BCP 1629 26: "Private Use", "First Come First Served", "Expert Review", 1630 "Specification Required", "IETF Consensus", "Standards Action". 1632 For registration requests where a Designated Expert should be 1633 consulted, the responsible IESG area director should appoint the 1634 Designated Expert. The intention is that any allocation will be 1635 accompanied by a published RFC. But in order to allow for the 1636 allocation of values prior to the RFC being approved for publication, 1637 the Designated Expert can approve allocations once it seems clear 1638 that an RFC will be published. The Designated expert will post a 1639 request to the EAP WG mailing list (or a successor designated by the 1640 Area Director) for comment and review, including an Internet-Draft. 1641 Before a period of 30 days has passed, the Designated Expert will 1642 either approve or deny the registration request and publish a notice 1643 of the decision to the EAP WG mailing list or its successor, as well 1644 as informing IANA. A denial notice must be justified by an 1645 explanation and, in the cases where it is possible, concrete 1646 suggestions on how the request can be modified so as to become 1647 acceptable. 1649 6.1 Packet Codes 1651 Packet Codes have a range from 1 to 255, of which 1-4 have been 1652 allocated. Because a new Packet Code has considerable impact on 1653 interoperability, a new Packet Code requires Standards Action, and 1654 should be allocated starting at 5. 1656 6.2 Method Types 1658 The original EAP method Type space has a range from 1 to 255, and is 1659 the scarcest resource in EAP, and thus must be allocated with care. 1660 Method Types 1-41 have been allocated, with 20 available for re-use. 1661 Method Types 42-191 may be allocated on the advice of a Designated 1662 Expert, with Specification Required. 1664 Allocation of blocks of method Types (more than one for a given 1665 purpose) should require IETF Consensus. EAP Type Values 192-253 are 1666 reserved and allocation requires Standards Action. 1668 Method Type 254 is allocated for the Expanded Type. Where the 1669 Vendor-Id field is non-zero, the Expanded Type is used for functions 1670 specific only to one vendor's implementation of EAP, where no 1671 interoperability is deemed useful. When used with a Vendor-Id of 1672 zero, method Type 254 can also be used to provide for an expanded 1673 IETF method Type space. Method Type values 256-4294967295 may be 1674 allocated after Type values 1-191 have been allocated. 1676 Method Type 255 is allocated for Experimental use, such as testing of 1677 new EAP methods before a permanent Type code is allocated. 1679 7. Security Considerations 1681 EAP was designed for use with dialup PPP [RFC1661] and was later 1682 adapted for use in wired IEEE 802 networks [IEEE-802] in 1683 [IEEE-802.1X]. On these networks, an attacker would need to gain 1684 physical access to the telephone or switch infrastructure in order to 1685 mount an attack. While such attacks have been documented, such as in 1686 [DECEPTION], they are assumed to be rare. 1688 However, subsequently EAP has been proposed for use on wireless 1689 networks, and over the Internet, where physical security cannot be 1690 assumed. On such networks, the security vulnerabilities are greater, 1691 as are the requirements for EAP security. 1693 This section defines the threat model and security terms and 1694 describes the security claims section required in EAP method 1695 specifications. We then discuss threat mitigation. 1697 7.1 Threat model 1699 On physically insecure networks, it is possible for an attacker to 1700 gain access to the physical medium. This enables a range of attacks, 1701 including the following: 1703 [1] An attacker may try to discover user identities by snooping 1704 authentication traffic. 1706 [2] An attacker may try to modify or spoof EAP packets. 1708 [3] An attacker may launch denial of service attacks by spoofing 1709 lower layer indications or Success/Failure packets; by replaying 1710 EAP packets; or by generating packets with overlapping 1711 Identifiers. 1713 [4] An attacker may attempt to recover the pass-phrase by mounting an 1714 offline dictionary attack. 1716 [5] An attacker may attempt to convince the peer to connect to an 1717 untrusted network, by mounting a man-in-the-middle attack. 1719 [6] An attacker may attempt to disrupt the EAP negotiation in order 1720 cause a weak authentication method to be selected. 1722 [7] An attacker may attempt to recover keys by taking advantage of 1723 weak key derivation techniques used within EAP methods. 1725 [8] An attacker may attempt to take advantage of weak ciphersuites 1726 subsequently used after the EAP conversation is complete. 1728 [9] An attacker may attempt to perform downgrading attacks on lower 1729 layer ciphersuite negotiation in order to ensure that a weaker 1730 ciphersuite is used subsequently to EAP authentication. 1732 Where EAP is used over wired networks, an attacker typically requires 1733 access to the physical infrastructure in order to carry out these 1734 attacks. However, where EAP is used over wireless networks, EAP 1735 packets may be forwarded by authenticators (e.g., pre-authentication) 1736 so that the attacker need not be within the coverage area of an 1737 authenticator in order to carry out an attack on it or its peers. 1738 Where EAP is used over the Internet, attacks may be carried out at an 1739 even greater distance. 1741 7.2 Security claims 1743 In order to clearly articulate the security provided by an EAP 1744 method, EAP method specifications MUST include a Security Claims 1745 section including the following declarations: 1747 [a] Intended use. This includes a statement of whether the method is 1748 intended for use over a physically secure or insecure network, as 1749 well as a statement of the applicable lower layers. 1751 [b] Mechanism. This is a statement of the authentication technology: 1752 certificates, pre-shared keys, passwords, token cards, etc. 1754 [c] Security claims. This is a statement of the claimed security 1755 properties of the method, using terms defined in Section 1.2: 1756 mutual authentication, integrity protection, replay protection, 1757 confidentiality, key derivation, dictionary attack resistance, 1758 fast reconnect, man-in-the-middle resistance, acknowledged result 1759 indications. The Security Claims section of an EAP method 1760 specification SHOULD provide justification for the claims that 1761 are made. This can be accomplished by including a proof in an 1762 Appendix, or including a reference to a proof. 1764 [d] Key strength. If the method derives keys, then the effective key 1765 strength MUST be estimated. This estimate is meant for potential 1766 users of the method to determine if the keys produced are strong 1767 enough for the intended application. 1769 The effective key strength SHOULD be stated as number of bits, 1770 defined as follows: If the effective key strength is N bits, the 1771 best currently known methods to recover the key (with 1772 non-negligible probability) require an effort comparable to 2^N 1773 operations of a typical block cipher. The statement SHOULD be 1774 accompanied by a short rationale, explaining how this number was 1775 arrived at. This explanation SHOULD include the parameters 1776 required to achieve the stated key strength based on current 1777 knowledge of the algorithms. 1779 (Note: Although it is difficult to define what "comparable 1780 effort" and "typical block cipher" exactly mean, reasonable 1781 approximations are sufficient here. Refer to e.g. [SILVERMAN] 1782 for more discussion.) 1784 The key strength depends on the methods used to derive the keys. 1785 For instance, if keys are derived from a shared secret (such as a 1786 password or a long-term secret), and possibly some public 1787 information such as nonces, the effective key strength is limited 1788 by the strength of the long-term secret (assuming that the 1789 derivation procedure is computationally simple). To take another 1790 example, when using public key algorithms, the strength of the 1791 symmetric key depends on the strength of the public keys used. 1793 [e] Description of key hierarchy. EAP methods deriving keys MUST 1794 either provide a reference to a key hierarchy specification, or 1795 describe how Master Session Keys (MSKs) and Extended Master 1796 Session Keys (EMSKs) are to be derived. 1798 [f] Indication of vulnerabilities. In addition to the security 1799 claims that are made, the specification MUST indicate which of 1800 the security claims detailed in Section 1.2 are NOT being made. 1802 7.3 Identity protection 1804 An Identity exchange is optional within the EAP conversation. 1805 Therefore, it is possible to omit the Identity exchange entirely, or 1806 to use a method-specific identity exchange once a protected channel 1807 has been established. 1809 However, where roaming is supported as described in [RFC2607], it may 1810 be necessary to locate the appropriate backend authentication server 1811 before the authentication conversation can proceed. The realm 1812 portion of the Network Access Identifier (NAI) [RFC2486] is typically 1813 included within the Identity-Response in order to enable the 1814 authentication exchange to be routed to the appropriate backend 1815 authentication server. Therefore while the peer-name portion of the 1816 NAI may be omitted in the Identity- Response, where proxies or relays 1817 are present, the realm portion may be required. 1819 7.4 Man-in-the-middle attacks 1821 Where EAP is tunneled within another protocol that omits peer 1822 authentication, there exists a potential vulnerability to 1823 man-in-the-middle attack. 1825 As noted in Section 2.1, EAP does not permit sequences of 1826 authentication methods. Were a sequence of EAP authentication 1827 methods to be permitted, the peer might not have proof that a single 1828 entity has acted as the authenticator for all EAP methods within the 1829 sequence. For example, an authenticator might terminate one EAP 1830 method, then forward the next method in the sequence to another party 1831 without the peer's knowledge or consent. Similarly, the 1832 authenticator might not have proof that a single entity has acted as 1833 the peer for all EAP methods within the sequence. 1835 This enables an attack by a rogue EAP authenticator tunneling EAP to 1836 a legitimate server. Where the tunneling protocol is used for key 1837 establishment but does not require peer authentication, an attacker 1838 convincing a legitimate peer to connect to it will be able to tunnel 1839 EAP packets to a legitimate server, successfully authenticating and 1840 obtaining the key. This allows the attacker to successfully 1841 establish itself as a man-in-the-middle, gaining access to the 1842 network, as well as the ability to decrypt data traffic between the 1843 legitimate peer and server. 1845 This attack may be mitigated by the following measures: 1847 [a] Requiring mutual authentication within EAP tunneling mechanisms. 1849 [b] Requiring cryptographic binding between the EAP tunneling 1850 protocol and the tunneled EAP methods. Where cryptographic 1851 binding is supported, a mechanism is also needed to protect 1852 against downgrade attacks that would bypass it. 1854 [c] Limiting the EAP methods authorized for use without protection, 1855 based on peer and authenticator policy. 1857 [d] Avoiding the use of tunnels when a single, strong method is 1858 available. 1860 7.5 Packet modification attacks 1862 While EAP methods may support per-packet data origin authentication, 1863 integrity and replay protection, support is not provided within the 1864 EAP layer. 1866 Since the Identifier is only a single octet, it is easy to guess, 1867 allowing an attacker to successfully inject or replay EAP packets. An 1868 attacker may also modify EAP headers within EAP packets where the 1869 header is unprotected. This could cause packets to be 1870 inappropriately discarded or misinterpreted. 1872 In the case of PPP and IEEE 802 wired links, it is assumed that such 1873 attacks are restricted to attackers who can gain access to the 1874 physical link. However, where EAP is run over physically insecure 1875 lower layers such as wireless (802.11 or cellular) or the Internet 1876 (such as within protocols supporting PPP, EAP or Ethernet Tunneling), 1877 this assumption is no longer valid and the vulnerability to attack is 1878 greater. 1880 To protect EAP messages sent over physically insecure lower layers, 1881 methods providing mutual authentication and key derivation, as well 1882 as per-packet origin authentication, integrity and replay protection 1883 SHOULD be used. Method-specific MICs may be used to provide 1884 protection. Since EAP messages of Types Identity, Notification, and 1885 Nak do not include their own MIC, it may be desirable for the EAP 1886 method MIC to cover information contained within these messages, as 1887 well as the header of each EAP message. For details, see Appendix A. 1889 To provide protection, EAP also may be encapsulated within a 1890 protected channel created by protocols such as ISAKMP [RFC2408] as is 1891 done in [PIC] or within TLS [RFC2246]. However, as noted in Section 1892 7.4, EAP tunneling may result in a man-in-the-middle vulnerability. 1894 7.6 Dictionary attacks 1896 Password authentication algorithms such as EAP-MD5, MS-CHAPv1 1897 [RFC2433] and Kerberos V [RFC1510] are known to be vulnerable to 1898 dictionary attacks. MS-CHAPv1 vulnerabilities are documented in 1899 [PPTPv1]; Kerberos vulnerabilities are described in [KRBATTACK], 1900 [KRBLIM], and [KERB4WEAK]. 1902 Where EAP runs over lower layers which are not physically secure, in 1903 order to protect against dictionary attacks, an authentication 1904 algorithm resistant to dictionary attack (as defined in Section 7.2) 1905 SHOULD be used. 1907 If an authentication algorithm is used that is known to be vulnerable 1908 to dictionary attack, then the conversation may be tunneled within a 1909 protected channel, in order to provide additional protection. 1910 However, as noted in Section 7.4, EAP tunneling may result in a 1911 man-in-the-middle vulnerability, and therefore dictionary attack 1912 resistant methods are preferred. 1914 7.7 Connection to an untrusted network 1916 With EAP methods supporting one-way authentication, such as EAP-MD5, 1917 the peer does not authenticate the authenticator. Where the lower 1918 layer is not physically secure (such as where EAP runs over wireless 1919 media or the Internet), the peer is vulnerable to a rogue 1920 authenticator. As a result, where the lower layer is not physically 1921 secure, a method supporting mutual authentication is RECOMMENDED. 1923 In EAP there is no requirement that authentication be full duplex or 1924 that the same protocol be used in both directions. It is perfectly 1925 acceptable for different protocols to be used in each direction. This 1926 will, of course, depend on the specific protocols negotiated. 1927 However, in general, completing a single unitary mutual 1928 authentication is preferable to two one-way authentications, one in 1929 each direction. This is because separate authentications that are 1930 not bound cryptographically so as to demonstrate they are part of the 1931 same session are subject to man-in-the-middle attacks, as discussed 1932 in Section 7.4. 1934 7.8 Negotiation attacks 1936 In a negotiation attack, the attacker attempts to convince the peer 1937 and authenticator to negotiate a less secure EAP method. EAP does 1938 not provide protection for Nak Response packets, although it is 1939 possible for a method to include coverage of Nak Responses within a 1940 method-specific MIC. 1942 Within or associated with each authenticator, it is not anticipated 1943 that a particular named peer will support a choice of methods. This 1944 would make the peer vulnerable to attacks that negotiate the least 1945 secure method from among a set. Instead, for each named peer there 1946 SHOULD be an indication of exactly one method used to authenticate 1947 that peer name. If a peer needs to make use of different 1948 authentication methods under different circumstances, then distinct 1949 identities SHOULD be employed, each of which identifies exactly one 1950 authentication method. 1952 7.9 Implementation idiosyncrasies 1954 The interaction of EAP with lower layers such as PPP and IEEE 802 are 1955 highly implementation dependent. 1957 For example, upon failure of authentication, some PPP implementations 1958 do not terminate the link, instead limiting traffic in Network-Layer 1959 Protocols to a filtered subset, which in turn allows the peer the 1960 opportunity to update secrets or send mail to the network 1961 administrator indicating a problem. Similarly, while in 1962 [IEEE-802.1X] an authentication failure will result in denied access 1963 to the controlled port, limited traffic may be permitted on the 1964 uncontrolled port. 1966 In EAP there is no provision for retries of failed authentication. 1967 However, in PPP the LCP state machine can renegotiate the 1968 authentication protocol at any time, thus allowing a new attempt. 1969 Similarly, in IEEE 802.1X the Supplicant or Authenticator can 1970 re-authenticate at any time. It is recommended that any counters 1971 used for authentication failure not be reset until after successful 1972 authentication, or subsequent termination of the failed link. 1974 7.10 Key derivation 1976 It is possible for the peer and EAP server to mutually authenticate, 1977 and derive keys. In order to provide keying material for use in a 1978 subsequently negotiated ciphersuite, an EAP method supporting key 1979 derivation MUST export a Master Session Key (MSK) of at least 64 1980 octets, and an Extended Master Session Key (EMSK) of at least 64 1981 octets. 1983 The MSK and EMSK are not used directly to protect data; however, they 1984 are of sufficient size to enable subsequent derivation of Transient 1985 Session Keys (TSKs) for use with the selected ciphersuite. Each 1986 ciphersuite is responsible for specifying how to derive the TSKs from 1987 the MSK. The EAP method is also responsible for the derivation of 1988 Transient EAP Keys (TEKs) used for protection of the EAP conversation 1989 itself. 1991 EAP methods provide Master Session Keys and not Transient Session 1992 Keys so as to allow EAP methods to be ciphersuite and media 1993 independent. Depending on the lower layer, EAP methods may run 1994 before or after ciphersuite negotiation, so that the selected 1995 ciphersuite may not be known to the EAP method. By providing keying 1996 material usable with any ciphersuite, EAP methods can used with a 1997 wide range of ciphersuites and media. 1999 Non-overlapping substrings of the MSK MUST be cryptographically 2000 separate from each other, as defined in Section 1.3. That is, 2001 knowledge of one substring MUST NOT help in recovering some other 2002 substring without breaking some hard cryptographic assumption. This 2003 is required because some existing ciphersuites form TSKs by simply 2004 splitting the MSK to pieces of appropriate length. Likewise, 2005 non-overlapping substrings of the EMSK MUST be cryptographically 2006 separate from each other, and from substrings of the MSK. 2008 The EMSK is reserved for future use and MUST remain on the EAP peer 2009 and EAP server where it is derived; it MUST NOT be transported to, or 2010 shared with, additional parties, or used to derive any other keys. 2011 (This restriction will be relaxed in a future document that specifies 2012 how the EMSK can be used.) 2014 This specification does not provide detailed guidance on how EAP 2015 methods are to derive the MSK, EMSK and TEKs, or how the TSKs are to 2016 be derived from the MSK. Key derivation is an art that is best 2017 practiced by professionals; rather than inventing new key derivation 2018 algorithms, reuse of existing algorithms such as those specified in 2019 IKE [RFC2409], or TLS [RFC2246] is recommended. 2021 Further details on EAP Key Derivation are provided within [KEYFRAME]. 2023 7.11 Weak ciphersuites 2025 If after the initial EAP authentication, data packets are sent 2026 without per-packet authentication, integrity and replay protection, 2027 an attacker with access to the media can inject packets, "flip bits" 2028 within existing packets, replay packets, or even hijack the session 2029 completely. Without per-packet confidentiality, it is possible to 2030 snoop data packets. 2032 As a result, as noted in Section 3.1, where EAP is used over a 2033 physically insecure lower layer, per-packet authentication, integrity 2034 and replay protection SHOULD be used, and per-packet confidentiality 2035 is also recommended. 2037 Additionally, if the lower layer performs ciphersuite negotiation, it 2038 should be understood that EAP does not provide by itself integrity 2039 protection of that negotiation. Therefore, in order to avoid 2040 downgrading attacks which would lead to weaker ciphersuites being 2041 used, clients implementing lower layer ciphersuite negotiation SHOULD 2042 protect against negotiation downgrading. 2044 This can be done by enabling users to configure which are the 2045 acceptable ciphersuites as a matter of security policy; or, the 2046 ciphersuite negotiation MAY be authenticated using keying material 2047 derived from the EAP authentication and a MIC algorithm agreed upon 2048 in advance by lower-layer peers. 2050 7.12 Link layer 2052 There exists a number of reliability and security issues with link 2053 layer indications in PPP, IEEE 802 wired networks and IEEE 802.11 2054 wireless LANs: 2056 [a] PPP. In PPP, link layer indications such as LCP-Terminate (a 2057 link failure indication) and NCP (a link success indication) are 2058 not authenticated or integrity protected. They can therefore be 2059 spoofed by an attacker with access to the physical medium. 2061 [b] IEEE 802 wired networks. On wired networks, IEEE 802.1X messages 2062 are sent to a non-forwardable multicast MAC address. As a 2063 result, while the IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames 2064 are not authenticated or integrity protected, only an attacker 2065 with access to the physical link can spoof these messages. 2067 [c] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer 2068 indications include Disassociate and Deauthenticate frames (link 2069 failure indications), and the first message of the 4-way 2070 handshake (link success indication). These messages are not 2071 authenticated or integrity protected, and although they are not 2072 forwardable, they are spoofable by an attacker within range. 2074 In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3 2075 unicast data frames, and are therefore forwardable. This implies 2076 that while EAPOL-Start and EAPOL-Logoff messages may be 2077 authenticated and integrity protected, they can be spoofed by an 2078 authenticated attacker far from the target when 2079 "pre-authentication" is enabled. 2081 In IEEE 802.11 a "link down" indication is an unreliable 2082 indication of link failure, since wireless signal strength can 2083 come and go and may be influenced by radio frequency interference 2084 generated by an attacker. To avoid unnecessary resets, it is 2085 advisable to damp these indications, rather than passing them 2086 directly to the EAP. Since EAP supports retransmission, it is 2087 robust against transient connectivity losses. 2089 7.13 Separation of authenticator and backend authentication server 2091 It is possible for the EAP peer and authenticator to mutually 2092 authenticate, and derive a Master Session Key (MSK) for a ciphersuite 2093 used to protect subsequent data traffic. This does not present an 2094 issue on the peer, since the peer and EAP client reside on the same 2095 machine; all that is required is for the EAP client module to derive 2096 and pass a Transient Session Key (TSK) to the ciphersuite module. 2098 However, in the case where the authenticator and authentication 2099 server reside on different machines, there are several implications 2100 for security. 2102 [a] Authentication will occur between the peer and the authentication 2103 server, not between the peer and the authenticator. This means 2104 that it is not possible for the peer to validate the identity of 2105 the authenticator that it is speaking to, using EAP alone. 2107 [b] As discussed in [RFC2869bis], the authenticator is dependent on 2108 the AAA protocol in order to know the outcome of an 2109 authentication conversation, and does not look at the 2110 encapsulated EAP packet (if one is present) to determine the 2111 outcome. In practice this means that the AAA protocol spoken 2112 between the authenticator and authentication server MUST support 2113 per-packet authentication, integrity and replay protection. 2115 [c] Where EAP is used over lower layers which are not physically 2116 secure, subsequent to completion of the EAP conversation, a 2117 subsequent protocol SHOULD be run between the peer and 2118 authentication in order to mutually authenticate the peer and 2119 authenticator; guarantee liveness of the TSKs; provide protected 2120 ciphersuite and capabilities negotiation; and provide for 2121 synchronized key usage. 2123 [d] An EAP Master Session Key (MSK) negotiated between the peer and 2124 authentication server MAY be transmitted to the authenticator. 2125 Therefore a mechanism needs to be provided to transmit the MSK 2126 from the authentication server to the authenticator that needs 2127 it. The specification of the key transport and wrapping 2128 mechanism is outside the scope of this document. 2130 8. Acknowledgments 2132 This protocol derives much of its inspiration from Dave Carrel's AHA 2133 draft as well as the PPP CHAP protocol [RFC1994]. Valuable feedback 2134 was provided by Yoshihiro Ohba of Toshiba America Research, Jari 2135 Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco 2136 Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan 2137 Payne of the University of Maryland, Steve Bellovin of AT&T Research, 2138 Paul Funk of Funk Software, Pasi Eronen of Nokia, Joseph Salowey of 2139 Cisco and Paul Congdon of HP and members of the EAP working group. 2141 Normative References 2143 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2144 RFC 1661, July 1994. 2146 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 2147 Recommendations for Security", RFC 1750, December 1994. 2149 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 2150 Protocol (CHAP)", RFC 1994, August 1996. 2152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2153 Requirement Levels", BCP 14, RFC 2119, March 1997. 2155 [RFC2243] Metz, C., "OTP Extended Responses", RFC 2243, November 2156 1997. 2158 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 2159 10646", RFC 2279, January 1998. 2161 [RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time 2162 Password System", RFC 2289, February 1998. 2164 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2165 (IKE)", RFC 2409, November 1998. 2167 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2168 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2169 October 1998. 2171 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 2172 Timer", RFC 2988, November 2000. 2174 [IEEE-802] 2175 Institute of Electrical and Electronics Engineers, "Local 2176 and Metropolitan Area Networks: Overview and 2177 Architecture", IEEE Standard 802, 1990. 2179 [IEEE-802.1X] 2180 Institute of Electrical and Electronics Engineers, "Local 2181 and Metropolitan Area Networks: Port-Based Network Access 2182 Control", IEEE Standard 802.1X, September 2001. 2184 Informative References 2186 [DECEPTION] 2187 Slatalla, M. and J. Quittner, "Masters of Deception", 2188 HarperCollins , New York, 1995. 2190 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 2191 Authentication Service (V5)", RFC 1510, September 1993. 2193 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 2194 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 2195 January 1999. 2197 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 2198 Authentication Protocol (EAP)", RFC 2284, March 1998. 2200 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 2201 RFC 2486, January 1999. 2203 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2204 Internet Protocol", RFC 2401, November 1998. 2206 [RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet 2207 Security Association and Key Management Protocol 2208 (ISAKMP)", RFC 2408, November 1998. 2210 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2211 2433, October 1998. 2213 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2214 Implementation in Roaming", RFC 2607, June 1999. 2216 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. 2217 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2218 2661, August 1999. 2220 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 2221 Protocol", RFC 2716, October 1999. 2223 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 2224 Internationalized Strings ("stringprep")", RFC 3454, 2225 December 2002. 2227 [KRBATTACK] 2228 Wu, T., "A Real-World Analysis of Kerberos Password 2229 Security", Stanford University Computer Science 2230 Department, http://theory.stanford.edu/~tjw/krbpass.html. 2232 [KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos 2233 authentication system", Proceedings of the 1991 Winter 2234 USENIX Conference, pp. 253-267, 1991. 2236 [KERB4WEAK] 2237 Dole, B., Lodin, S. and E. Spafford, "Misplaced trust: 2238 Kerberos 4 session keys", Proceedings of the Internet 2239 Society Network and Distributed System Security Symposium, 2240 pp. 60-70, March 1997. 2242 [PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A Pre-IKE 2243 Credential Provisioning Protocol", draft-ietf-ipsra-pic-06 2244 (work in progress), October 2002. 2246 [PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's 2247 Point-to- Point Tunneling Protocol", Proceedings of the 2248 5th ACM Conference on Communications and Computer 2249 Security, ACM Press, November 1998. 2251 [IEEE-802.3] 2252 Institute of Electrical and Electronics Engineers, 2253 "Information technology - Telecommunications and 2254 Information Exchange between Systems - Local and 2255 Metropolitan Area Networks - Specific requirements - Part 2256 3: Carrier sense multiple access with collision detection 2257 (CSMA/CD) Access Method and Physical Layer 2258 Specifications", IEEE Standard 802.3, September 1998. 2260 [IEEE-802.11] 2261 Institute of Electrical and Electronics Engineers, 2262 "Information Technology - Telecommunications and 2263 Information Exchange between Systems - Local and 2264 Metropolitan Area Network - Specific Requirements - Part 2265 11: Wireless LAN Medium Access Control (MAC) and Physical 2266 Layer (PHY) Specifications", IEEE Standard 802.11, 1999. 2268 [SILVERMAN] 2269 Silverman, Robert D., "A Cost-Based Security Analysis of 2270 Symmetric and Asymmetric Key Lengths", RSA Laboratories 2271 Bulletin 13, April 2000 (Revised November 2001), http:// 2272 www.rsasecurity.com/rsalabs/bulletins/bulletin13.html. 2274 [RFC2869bis] 2275 Aboba, B. and P. Calhoun, "RADIUS Support For Extensible 2276 Authentication Protocol (EAP)", 2277 draft-aboba-radius-rfc2869bis-21 (work in progress), May 2278 2003. 2280 [IANA-EXP] 2281 Narten, T., "Assigning Experimental and Testing Numbers 2282 Considered Useful", 2283 draft-narten-iana-experimental-allocations-03 (work in 2284 progress), December 2002. 2286 [KEYFRAME] 2287 Aboba, B. and D. Simon, "EAP Keying Framework", 2288 draft-aboba-pppext-key-problem-06 (work in progress), 2289 March 2003. 2291 [SASLPREP] 2292 Zeilenga, K., "SASLprep: Stringprep profile for user names 2293 and passwords", draft-ietf-sasl-saslprep-01 (work in 2294 progress), May 2003. 2296 [IEEE-802.11i] 2297 Institute of Electrical and Electronics Engineers, 2298 "Unapproved Draft Supplement to Standard for 2299 Telecommunications and Information Exchange Between 2300 Systems - LAN/MAN Specific Requirements - Part 11: 2301 Wireless LAN Medium Access Control (MAC) and Physical 2302 Layer (PHY) Specifications: Specification for Enhanced 2303 Security", IEEE Draft 802.11i (work in progress), 2003. 2305 Authors' Addresses 2307 Larry J. Blunk 2308 Merit Network, Inc 2309 4251 Plymouth Rd., Suite 2000 2310 Ann Arbor, MI 48105-2785 2311 USA 2313 Phone: +1 734-647-9563 2314 Fax: +1 734-647-3185 2315 EMail: ljb@merit.edu 2317 John R. Vollbrecht 2318 Vollbrecht Consulting LLC 2319 9682 Alice Hill Drive 2320 Dexter, MI 48130 2321 USA 2323 Phone: 2324 EMail: jrv@umich.edu 2326 Bernard Aboba 2327 Microsoft Corporation 2328 One Microsoft Way 2329 Redmond, WA 98052 2330 USA 2332 Phone: +1 425 706 6605 2333 Fax: +1 425 936 6605 2334 EMail: bernarda@microsoft.com 2336 James Carlson 2337 Sun Microsystems, Inc 2338 1 Network Drive 2339 Burlington, MA 01803-2757 2340 USA 2342 Phone: +1 781 442 2084 2343 Fax: +1 781 442 1677 2344 EMail: james.d.carlson@sun.com 2345 Henrik Levkowetz 2346 ipUnplugged AB 2347 Arenavagen 33 2348 Stockholm S-121 28 2349 SWEDEN 2351 Phone: +46 8 725 9513 2352 EMail: henrik@levkowetz.com 2354 Appendix A. Method Specific Behavior 2356 A.1 Message Integrity Checks 2358 Today, EAP methods commonly define message integrity checks (MICs) 2359 that cover more than one EAP packet. For example, EAP-TLS [RFC2716] 2360 defines a MIC over a TLS record that could be split into multiple 2361 fragments; within the FINISHED message, the MIC is computed over 2362 previous messages. Where the MIC covers more than one EAP packet, a 2363 MIC validation failure is typically considered a fatal error. 2365 If a per-packet MIC is employed within an EAP method, then peers, 2366 authentication servers, and authenticators not operating in 2367 pass-through mode MUST validate the MIC. MIC validation failures 2368 SHOULD be logged. Whether a MIC validation failure is considered a 2369 fatal error or not is determined by the EAP method specification. 2371 Within EAP-TLS [RFC2716] a MIC validation failure is treated as a 2372 fatal error, since that is what is specified in TLS [RFC2246]. 2373 However, it is also possible to develop EAP methods that support 2374 per-packet MICs, and respond to verification failures by silently 2375 discarding the offending packet. 2377 In this document, descriptions of EAP message handling assume that 2378 per-packet MIC validation, where it occurs, is effectively performed 2379 as though it occurs before sending any responses or changing the 2380 state of the host which received the packet. 2382 Appendix B. Changes from RFC 2284 2384 This section lists the major changes between [RFC2284] and this 2385 document. Minor changes, including style, grammar, spelling and 2386 editorial changes are not mentioned here. 2388 o The Terminology section (Section 1.2) has been expanded, defining 2389 more concepts and giving more exact definitions. 2391 o In Section 2, it is explicitly specified that more than one 2392 exchange of Request and Response packets may occur as part of the 2393 EAP authentication exchange. How this may and may not be used is 2394 specified in detail in Section 2.1. 2396 o Also in Section 2, some requirements on the authenticator when 2397 acting in pass-through mode has been made explicit. 2399 o An EAP multiplexing model (Section 2.2) has been added, to 2400 illustrate a typical implementation of EAP. There is no 2401 requirement that an implementation conforms to this model, as long 2402 as the on-the-wire behavior is consistent with it. 2404 o As EAP is now in use with a variety of lower layers, not just PPP 2405 for which it was first designed, Section 3 on lower layer behavior 2406 has been added. 2408 o In the description of the EAP Request and Response interaction 2409 (Section 4.1), it has been more exactly specified when packets 2410 should be silently discarded, and also the behavior on receiving 2411 duplicate requests. The implementation notes in this section has 2412 been substantially expanded. 2414 o In Section 4.2, it has been clarified that Success and Failure 2415 packets must not contain additional data, and the implementation 2416 note has been expanded. A subsection giving requirements on 2417 processing of success and failure packets has been added. 2419 o Section 5 on EAP Request/Response Types lists two new Type values: 2420 the Expanded Type (Section 5.7), which is used to expand the Type 2421 value number space, and the Experimental Type. In the Expanded 2422 Type number space, the new Expanded Nak (Section 5.3.2) Type has 2423 been added. Clarifications have been made in the description of 2424 most of the existing Types. Security claims summaries have been 2425 added for authentication methods. 2427 o In Section 5.5, support for OTP Extended Responses [RFC2243] has 2428 been added to EAP OTP. 2430 o An IANA Considerations section (Section 6) has been added, giving 2431 registration policies for the numbering spaces defined for EAP. 2433 o The Security Considerations (Section 7) have been greatly 2434 expanded, aiming at giving a much more comprehensive coverage of 2435 possible threats and other security considerations. 2437 o Appendix A has been added on method-specific behavior, providing 2438 guidance on how EAP method-specific integrity checks should be 2439 processed. Where possible, it is desirable for a method-specific 2440 MIC to be computed over the entire EAP packet, including the EAP 2441 layer header (Code, Identifier, Length) and EAP method layer 2442 header (Type, Type-Data). 2444 Appendix C. Open issues 2446 (This section should be removed by the RFC editor before publication) 2448 Open issues relating to this specification are tracked on the 2449 following web site: 2451 http://www.drizzle.com/~aboba/EAP/eapissues.html 2453 The current working documents for this draft are available at this 2454 web site: 2456 http://www.levkowetz.com/pub/ietf/drafts/eap/ 2458 Intellectual Property Statement 2460 The IETF takes no position regarding the validity or scope of any 2461 intellectual property or other rights that might be claimed to 2462 pertain to the implementation or use of the technology described in 2463 this document or the extent to which any license under such rights 2464 might or might not be available; neither does it represent that it 2465 has made any effort to identify any such rights. Information on the 2466 IETF's procedures with respect to rights in standards-track and 2467 standards-related documentation can be found in BCP-11. Copies of 2468 claims of rights made available for publication and any assurances of 2469 licenses to be made available, or the result of an attempt made to 2470 obtain a general license or permission for the use of such 2471 proprietary rights by implementors or users of this specification can 2472 be obtained from the IETF Secretariat. 2474 The IETF invites any interested party to bring to its attention any 2475 copyrights, patents or patent applications, or other proprietary 2476 rights which may cover technology that may be required to practice 2477 this standard. Please address the information to the IETF Executive 2478 Director. 2480 Full Copyright Statement 2482 Copyright (C) The Internet Society (2003). All Rights Reserved. 2484 This document and translations of it may be copied and furnished to 2485 others, and derivative works that comment on or otherwise explain it 2486 or assist in its implementation may be prepared, copied, published 2487 and distributed, in whole or in part, without restriction of any 2488 kind, provided that the above copyright notice and this paragraph are 2489 included on all such copies and derivative works. However, this 2490 document itself may not be modified in any way, such as by removing 2491 the copyright notice or references to the Internet Society or other 2492 Internet organizations, except as needed for the purpose of 2493 developing Internet standards in which case the procedures for 2494 copyrights defined in the Internet Standards process must be 2495 followed, or as required to translate it into languages other than 2496 English. 2498 The limited permissions granted above are perpetual and will not be 2499 revoked by the Internet Society or its successors or assignees. 2501 This document and the information contained herein is provided on an 2502 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2503 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2504 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2505 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2506 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2508 Acknowledgement 2510 Funding for the RFC Editor function is currently provided by the 2511 Internet Society.