idnits 2.17.1 draft-ietf-eap-rfc2284bis-03.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 1241 has weird spacing: '...ed Type of 6 ...' == Line 1319 has weird spacing: '...pe-Data field...' == Line 1630 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 (May 16, 2003) is 7650 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 1623 -- Looks like a reference, but probably isn't: '2' on line 1626 -- Looks like a reference, but probably isn't: '3' on line 1628 -- Looks like a reference, but probably isn't: '4' on line 1633 -- Looks like a reference, but probably isn't: '5' on line 1636 -- Looks like a reference, but probably isn't: '6' on line 1639 -- Looks like a reference, but probably isn't: '7' on line 1642 -- Looks like a reference, but probably isn't: '8' on line 1645 -- Looks like a reference, but probably isn't: '9' on line 1648 == Unused Reference: 'RFC2401' is defined on line 2118, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.3' is defined on line 2166, but no explicit reference was found in the text ** 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: 6 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: November 14, 2003 Vollbrecht Consulting LLC 6 B. Aboba 7 Microsoft 8 J. Carlson 9 Sun 10 H. Levkowetz, Ed. 11 ipUnplugged 12 May 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 November 14, 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 . . . . . 5 62 2. Extensible Authentication Protocol (EAP) . . . . . . . . . . 9 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 5. Initial EAP Request/Response Types . . . . . . . . . . . . . 23 75 5.1 Identity . . . . . . . . . . . . . . . . . . . . . . . 23 76 5.2 Notification . . . . . . . . . . . . . . . . . . . . . 24 77 5.3 Nak . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 5.3.1 Legacy Nak . . . . . . . . . . . . . . . . . . . 25 79 5.3.2 Expanded Nak . . . . . . . . . . . . . . . . . . 26 80 5.4 MD5-Challenge . . . . . . . . . . . . . . . . . . . . 28 81 5.5 One-Time Password (OTP) . . . . . . . . . . . . . . . 30 82 5.6 Generic Token Card (GTC) . . . . . . . . . . . . . . . 31 83 5.7 Expanded Types . . . . . . . . . . . . . . . . . . . . 32 84 5.8 Experimental . . . . . . . . . . . . . . . . . . . . . 33 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 86 6.1 Packet Codes . . . . . . . . . . . . . . . . . . . . . 35 87 6.2 Method Types . . . . . . . . . . . . . . . . . . . . . 35 88 7. Security Considerations . . . . . . . . . . . . . . . . . . 35 89 7.1 Threat model . . . . . . . . . . . . . . . . . . . . . 36 90 7.2 Security claims . . . . . . . . . . . . . . . . . . . 37 91 7.3 Identity protection . . . . . . . . . . . . . . . . . 38 92 7.4 Man-in-the-middle attacks . . . . . . . . . . . . . . 38 93 7.5 Packet modification attacks . . . . . . . . . . . . . 39 94 7.6 Dictionary attacks . . . . . . . . . . . . . . . . . . 40 95 7.7 Connection to an untrusted network . . . . . . . . . . 40 96 7.8 Negotiation attacks . . . . . . . . . . . . . . . . . 41 97 7.9 Implementation idiosyncrasies . . . . . . . . . . . . 41 98 7.10 Key derivation . . . . . . . . . . . . . . . . . . . . 41 99 7.11 Weak ciphersuites . . . . . . . . . . . . . . . . . . 42 100 7.12 Link layer . . . . . . . . . . . . . . . . . . . . . . 43 101 7.13 Separation of authenticator and backend authentication 102 server . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 103 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 45 104 Normative References . . . . . . . . . . . . . . . . . . . . 45 105 Informative References . . . . . . . . . . . . . . . . . . . 46 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48 107 A. Method Specific Behavior . . . . . . . . . . . . . . . . . . 49 108 A.1 Message Integrity Checks . . . . . . . . . . . . . . . 49 109 B. Changes from RFC 2284 . . . . . . . . . . . . . . . . . . . 50 110 C. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 51 111 Intellectual Property and Copyright Statements . . . . . . . 53 113 1. Introduction 115 This document defines the Extensible Authentication Protocol (EAP), 116 an authentication framework which supports multiple authentication 117 methods. EAP typically runs directly over data link layers such as 118 PPP or IEEE 802, without requiring IP. EAP provides its own support 119 for duplicate elimination and retransmission, but is reliant on lower 120 layer ordering guarantees. Fragmentation is not supported within EAP 121 itself; however, individual EAP methods may support this. 123 EAP may be used on dedicated links as well as switched circuits, and 124 wired as well as wireless links. To date, EAP has been implemented 125 with hosts and routers that connect via switched circuits or dial-up 126 lines using PPP [RFC1661]. It has also been implemented with switches 127 and access points using IEEE 802 [IEEE-802]. EAP encapsulation on 128 IEEE 802 wired media is described in [IEEE-802.1X], and encapsulation 129 on IEEE wireless LANs in [IEEE-802.11i]. 131 One of the advantages of the EAP architecture is its flexibility. EAP 132 is used to select a specific authentication mechanism, typically 133 after the authenticator requests more information in order to 134 determine the specific authentication method to be used. Rather than 135 requiring the authenticator to be updated to support each new 136 authentication method, EAP permits the use of a backend 137 authentication server which may implement some or all authentication 138 methods, with the authenticator acting as a pass-through for some or 139 all methods and peers. 141 Within this document, authenticator requirements apply regardless of 142 whether the authenticator is operating as a pass-through or not. 143 Where the requirement is meant to apply to either the authenticator 144 or backend authentication server, depending on where the EAP 145 authentication is terminated, the term "EAP server" will be used. 147 1.1 Specification of Requirements 149 In this document, several words are used to signify the requirements 150 of the specification. These words are often capitalized. The key 151 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 152 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 153 are to be interpreted as described in [RFC2119]. 155 1.2 Terminology 157 This document frequently uses the following terms: 159 authenticator 160 The end of the EAP link initiating EAP authentication. The 161 term Authenticator is used in [IEEE-802.1X], and 162 authenticator has the same meaning in this document. 164 peer 165 The end of the EAP Link that responds to the authenticator. 166 In [IEEE-802.1X], this end is known as the Supplicant. 168 backend authentication server 169 A backend authentication server is an entity that provides 170 an authentication service to an authenticator. When used, 171 this server typically executes EAP methods for the 172 authenticator. This terminology is also used in 173 [IEEE-802.1X]. 175 Displayable Message 176 This is interpreted to be a human readable string of 177 characters. The message encoding MUST follow the UTF-8 178 transformation format [RFC2279]. 180 EAP server 181 The entity that terminates the EAP authentication method 182 with the peer. In the case where no backend authentication 183 server is used the EAP server is part of the authenticator. 184 In the case where the authenticator operates in 185 pass-through mode, the EAP server is located on the backend 186 authentication server. 188 Silently Discard 189 This means the implementation discards the packet without 190 further processing. The implementation SHOULD provide the 191 capability of logging the event, including the contents of 192 the silently discarded packet, and SHOULD record the event 193 in a statistics counter. 195 1.3 Security claims terminology for EAP methods 197 These terms are used to described the security properties of EAP 198 methods: 200 Mutual authentication 201 This refers to an EAP method in which, within an 202 interlocked exchange, the authenticator authenticates the 203 peer and the peer authenticates the authenticator. Two 204 independent one-way methods, running in opposite directions 205 do not provide mutual authentication as defined here. 207 Integrity protection 208 This refers to providing data origin authentication and 209 protection against unauthorized modification of information 210 for EAP packets (including EAP Requests and Responses). 211 When making this claim, a method specification MUST 212 describe the EAP packets and fields within the EAP packet 213 that are protected. 215 Replay protection 216 This refers to protection against replay of an EAP method 217 or its messages, including method-specific success and 218 failure indications. 220 Confidentiality 221 This refers to encryption of EAP messages, including EAP 222 Requests and Responses, and method-specific success and 223 failure indications. A method making this claim MUST 224 support identity protection (see Section 7.3). 226 Key derivation 227 This refers to the ability of the EAP method to derive 228 exportable keying material such as the Master Session Key 229 (MSK), and Extended Master Session Key (EMSK). The MSK is 230 used only for further key derivation, not directly for 231 protection of the EAP conversation or subsequent data. Use 232 of the EMSK is reserved. 234 Key strength 235 If the effective key strength is N bits, the best currently 236 known methods to recover the key (with non-negligible 237 probability) require an effort comparable to 2^N operations 238 of a typical block cipher. 240 Dictionary attack resistance 241 Where password authentication is used, users are 242 notoriously prone to select poor passwords. A method may 243 be said to be dictionary attack resistant if, when there is 244 a weak password in the secret, the method does not allow 245 an attack more efficient than brute force. 247 Fast reconnect 248 The ability, in the case where a security association has 249 been previously established, to create a new or refreshed 250 security association in a smaller number of round-trips. 252 Man-in-the-Middle resistance 253 This property applies only for the use of multiple methods 254 in a combination, such as in authentication sequences or 255 tunnels. It refers to the ability of the peer to 256 demonstrate to the authenticator that it has acted as the 257 peer for each authentication method within the 258 conversation. Similarly, the authenticator demonstrates to 259 the peer that it has acted as the authenticator for each 260 authentication method within the conversation. If this is 261 not possible, then there may be a vulnerability to a 262 man-in-the-middle attack. 264 Acknowledged result indications 265 The ability of the authenticator to provide the peer with 266 an indication of whether the peer has successfully 267 authenticated to it, and for the peer to acknowledge 268 receipt, as well as providing an indication of whether the 269 authenticator has successfully authenticated to the peer. 270 Since EAP Success and Failure packets are neither 271 acknowledged nor integrity protected, this claim requires 272 implementation of a method-specific result exchange that is 273 authenticated, integrity and replay protected on a 274 per-packet basis. 276 Message Integrity Check (MIC) 277 A keyed hash function used for authentication and integrity 278 protection of data. This is usually called a Message 279 Authentication Code (MAC), but IEEE 802 specifications (and 280 this document) use the acronym MIC to avoid confusion with 281 Medium Access Control. 283 Cryptographic binding 284 The demonstration of the EAP peer to the EAP server that a 285 single entity has acted as the EAP peer for all methods 286 executed within a sequence or tunnel. Binding MAY also 287 imply that the EAP server demonstrates to the peer that a 288 single entity has acted as the EAP server for all methods 289 executed within a sequence or tunnel. If executed 290 correctly, binding serves to mitigate man-in-the-middle 291 vulnerabilities. 293 Cryptographic separation 294 Two keys (x and y) are "cryptographically separate" if an 295 adversary that knows all messages exchanged in the protocol 296 cannot compute x from y or y from x without "breaking" some 297 cryptographic assumption. In particular, this definition 298 allows that the adversary has the knowledge of all nonces 299 sent in cleartext as well as all predictable counter values 300 used in the protocol. Breaking a cryptographic assumption 301 would typically require inverting a one- way function or 302 predicting the outcome of a cryptographic pseudo- random 303 number generator without knowledge of the secret state. In 304 other words, if the keys are cryptographically separate, 305 there is no shortcut to compute x from y or y from x, but 306 the work an adversary must do to perform this computation 307 is equivalent to performing exhaustive search for the 308 secret state value." 310 EAP Master key (MK) 311 A key derived between the EAP client and server during the 312 EAP authentication process that is purely local to the EAP 313 method. The MK MUST NOT be exported from the EAP method or 314 be made available to a third party. Since derivation of 315 the MK is a residue of the successful completion of the EAP 316 authentication exchange, proof of MK possession may be used 317 to shorten future EAP exchanges between the same EAP client 318 and server, a technique known as "fast resume". 320 Master Session Key (MSK) 321 Keying material that is derived between the EAP client and 322 server. The MSK is used in the derivation of Transient 323 Session Keys (TSKs) for the ciphersuite negotiated between 324 the EAP peer and authenticator. Where a backend 325 authentication server is present, acting as an EAP server, 326 it will typically transport the MSK to the authenticator. 328 The MSK differs from the MK in that it not assumed to 329 remain local to the EAP method, and is known by all parties 330 in the EAP exchange: the peer, authenticator and the 331 authentication server (if present). The MSK MAY be derived 332 from the MK via a one-way function, or it may be an 333 independent quantity. However possession of the MSK MUST 334 NOT provide any information useful in determining the MK. 336 Extended Master Session Key (EMSK) 337 Additional keying material derived between the EAP client 338 and server that is exported by the EAP method. However, 339 unlike the MSK, the EMSK is known only to the EAP peer and 340 EAP server and MUST NOT be provided to a third party. The 341 EMSK therefore MUST NOT be transported by the backend 342 authentication server to the authenticator. The EMSK is 343 reserved for future uses that are not defined yet. For 344 example, it could be used to derive additional keying 345 material for purposes such as fast handoff, 346 man-in-the-middle vulnerability protection, etc. 348 2. Extensible Authentication Protocol (EAP) 350 The EAP authentication exchange proceeds as follows: 352 [1] The authenticator sends a Request to authenticate the peer. The 353 Request has a Type field to indicate what is being requested. 354 Examples of Request Types include Identity, MD5-challenge, etc. 355 The MD5-challenge Type corresponds closely to the CHAP 356 authentication protocol [RFC1994]. Typically, the authenticator 357 will send an initial Identity Request; however, an initial 358 Identity Request is not required, and MAY be bypassed. For 359 example, the identity may not be required where it is determined 360 by the port to which the peer has connected (leased lines, 361 dedicated switch or dial-up ports); or where the identity is 362 obtained in another fashion (via calling station identity or MAC 363 address, in the Name field of the MD5-Challenge Response, etc.). 365 [2] The peer sends a Response packet in reply to a valid Request. As 366 with the Request packet the Response packet contains a Type 367 field, which corresponds to the Type field of the Request. 369 [3] The authenticator sends an additional Request packet, and the 370 peer replies with a Response. The sequence of Requests and 371 Responses continues as long as needed. EAP is a 'lock step' 372 protocol, so that other than the initial Request, a new Request 373 cannot be sent prior to receiving a valid Response. The 374 authenticator MUST NOT send a Success or Failure packet as a 375 result of a timeout. After a suitable number of timeouts have 376 elapsed, the authenticator SHOULD end the EAP conversation. 378 [4] The conversation continues until the authenticator cannot 379 authenticate the peer (unacceptable Responses to one or more 380 Requests), in which case the authenticator implementation MUST 381 transmit an EAP Failure (Code 4). Alternatively, the 382 authentication conversation can continue until the authenticator 383 determines that successful authentication has occurred, in which 384 case the authenticator MUST transmit an EAP Success (Code 3). 386 Since EAP is a peer-to-peer protocol, an independent and simultaneous 387 authentication may take place in the reverse direction. Both peers 388 may act as authenticators and authenticatees at the same time. For a 389 discussion of security issues in peer-to-peer operation, see Section 390 7.7. 392 Advantages: 394 o The EAP protocol can support multiple authentication mechanisms 395 without having to pre-negotiate a particular one. 397 o Network Access Server (NAS) devices (e.g., a switch or access 398 point) do not have to understand each authentication method and 399 MAY act as a pass-through agent for a backend authentication 400 server. Support for pass-through is optional. An authenticator 401 MAY authenticate local peers while at the same time acting as a 402 pass-through for non-local peers and authentication methods it 403 does not implement locally. 405 o Separation of the authenticator from the backend authentication 406 server simplifies credentials management and policy decision 407 making. 409 Disadvantages: 411 o For use in PPP, EAP does require the addition of a new 412 authentication Type to PPP LCP and thus PPP implementations will 413 need to be modified to use it. It also strays from the previous 414 PPP authentication model of negotiating a specific authentication 415 mechanism during LCP. Similarly, switch or access point 416 implementations need to support [IEEE-802.1X] in order to use EAP. 418 o Where the authenticator is separate from the backend 419 authentication server, this complicates the security analysis and, 420 if needed, key distribution. 422 2.1 Support for sequences 424 An EAP conversation MAY utilize a sequence of methods. A common 425 example of this is an Identity request followed by a single EAP 426 authentication method such as an MD5-Challenge. However the peer and 427 authenticator MUST utilize only one authentication method (Type 4 or 428 greater) within an EAP conversation, after which the authenticator 429 MUST send a Success or Failure packet. 431 Once a peer has sent a Response of the same Type as the initial 432 Request, an authenticator MUST NOT send a Request of a different Type 433 prior to completion of the final round of a given method (with the 434 exception of a Notification-Request) and MUST NOT send a Request for 435 an additional method of any Type after completion of the initial 436 authentication method; a peer receiving such Requests MUST treat them 437 as invalid, and silently discard them. As a result, Identity Requery 438 is not supported. 440 A peer MUST NOT send a Nak (legacy or expanded) in reply to a 441 Request, after an initial non-Nak Response has been sent. Since 442 spoofed EAP Request packets may be sent by an attacker, an 443 authenticator receiving an unexpected Nak SHOULD silently discard it 444 and log the event. 446 Multiple authentication methods within an EAP conversation are not 447 supported due to their vulnerability to man-in-the-middle attacks 448 (see Section 7.4) and incompatibility with existing implementations. 450 Where a single EAP authentication method is utilized, but other 451 methods are run within it (a "tunneled" method) the prohibition 452 against multiple authentication methods does not apply. Such 453 "tunneled" methods appear as a single authentication method to EAP. 454 Backward compatibility can be provided, since a peer not supporting a 455 "tunneled" method can reply to the initial EAP-Request with a Nak 456 (legacy or expanded). To address security vulnerabilities, 457 "tunneled" methods MUST support protection against man-in-the-middle 458 attacks. 460 2.2 EAP multiplexing model 462 Conceptually, EAP implementations consist of the following 463 components: 465 [a] Lower layer. The lower layer is responsible for transmitting and 466 receiving EAP frames between the peer and authenticator. EAP has 467 been run over a variety of lower layers including PPP; wired IEEE 468 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; 469 UDP (L2TP [RFC2661] and ISAKMP [PIC]); and TCP [PIC]. Lower layer 470 behavior is discussed in Section 3. 472 [b] EAP layer. The EAP layer receives and transmits EAP packets via 473 the lower layer, implements duplicate detection and 474 retransmission, and delivers and receives EAP messages to and 475 from EAP methods. 477 [c] EAP method. EAP methods implement the authentication algorithms 478 and receive and transmit EAP messages via the EAP layer. Since 479 fragmentation support is not provided by EAP itself, this is the 480 responsibility of EAP methods, which are discussed in Section 5. 482 The EAP multiplexing model is illustrated in Figure 1 below. Note 483 that there is no requirement that an implementation conform to this 484 model, as long as the on-the-wire behavior is consistent with it. 486 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 487 | | | | | | 488 | EAP method| EAP method| | EAP method| EAP method| 489 | Type = X | Type = Y | | Type = X | Type = Y | 490 | V | | | ^ | | 491 +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ 492 | ! | | ! | 493 | EAP ! Layer | | EAP ! Layer | 494 | ! | | ! | 495 +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ 496 | ! | | ! | 497 | Lower ! Layer | | Lower ! Layer | 498 | ! | | ! | 499 +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ 500 ! ! 501 ! Peer ! Authenticator 502 +------------>-------------+ 504 Figure 1: EAP Multiplexing Model 506 Within EAP, the Type field functions much like a port number in UDP 507 or TCP. It is assumed that the EAP layer multiplexes incoming EAP 508 packets according to their Type, and delivers them only to the EAP 509 method corresponding to that Type code. 511 Since EAP authentication methods may wish to access the Identity, the 512 Identity Request and Response can be assumed to be accessible to 513 authentication methods (Types 4 or greater) in addition to the 514 Identity method. The Identity Type is discussed in Section 5.1. 516 A Notification Response is only used as confirmation that the peer 517 received the Notification Request, not that it has processed it, or 518 displayed the message to the user. It cannot be assumed that the 519 contents of the Notification Request or Response is available to 520 another method. The Notification Type is discussed in Section 5.2. 522 Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes 523 of method negotiation. Peers respond to an initial EAP Request for 524 an unacceptable Type with a Nak Response (Type 3) or Expanded Nak 525 Response (Type 254). It cannot be assumed that the contents of the 526 Nak Response(s) are available to another method. The Nak Type(s) are 527 discussed in Section 5.3. 529 EAP packets with codes of Success or Failure do not include a Type, 530 and therefore are not delivered to an EAP method. Success and 531 Failure are discussed in Section 4.2. 533 Given these considerations, the Success, Failure, Nak Response(s) and 534 Notification Request/Response messages MUST NOT be used to carry data 535 destined for delivery to other EAP methods. 537 Where an authenticator operates as a pass-through, it forwards 538 packets back and forth between the peer and a backend authentication 539 server, based on the EAP layer header fields (Code, Identifier, 540 Length). This includes performing validity checks on the Code, 541 Identifer and Length fields, as described in Section 4.1. 543 Since pass-through authenticators rely on a backend authenticator 544 server to implement methods, the EAP method layer header fields 545 (Type, Type-Data) are not examined as part of the forwarding 546 decision. The forwarding model is illustrated in Figure 2. Compliant 547 pass-through authenticator implementations MUST by default be capable 548 of forwarding packets from any EAP method. The use of the RADIUS 549 protocol for encapsulation of EAP in pass-through operation is 550 described in [RFC2869bis]. 552 Peer Pass-through Authenticator Authentication 553 Server 555 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 556 | | | | 557 |EAP method | |EAP method | 558 | Layer | | Layer | 559 | V | | ^ | 560 +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ 561 | ! | | | | | ! | 562 |EAP !Layer| | EAP Layer | EAP Layer | |EAP !Layer| 563 | ! | | +-----+-----+ | | ! | 564 | ! | | ! | ! | | ! | 565 +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ 566 | ! | | ! | ! | | ! | 567 |Lower!Layer| |Lower!Layer| AAA ! /IP | | AAA ! /IP | 568 | ! | | ! | ! | | ! | 569 +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ 570 ! ! ! ! 571 ! ! ! ! 572 +-------->-----+ +------->------+ 574 Figure 2: Pass-through Authenticator 576 For sessions in which the authenticator acts as a pass-through, it 577 MUST determine the outcome of the authentication solely based on the 578 Accept/Reject indication sent by the backend authentication server; 579 the outcome MUST NOT be determined by the contents of an EAP packet 580 sent along with the Accept/Reject indication, or the absence of such 581 an encapsulated EAP packet. 583 3. Lower layer behavior 585 3.1 Lower layer requirements 587 EAP makes the following assumptions about lower layers: 589 [1] Unreliable transport. In EAP, the authenticator retransmits 590 Requests that have not yet received Responses, so that EAP does 591 not assume that lower layers are reliable. Since EAP defines it 592 own retransmission behavior, when run over a reliable lower 593 layer, it is possible (though undesirable) for retransmission to 594 occur both in the lower layer and the EAP layer. 596 Note that EAP Success and Failure packets are not retransmitted. 597 Without a reliable lower layer, and a non-negligible error rate, 598 these packets can be lost, resulting in timeouts. It is therefore 599 desirable for implementations to improve their resilience to loss 600 of EAP Success or Failure packets, as described in Section 4.2. 602 [2] Lower layer error detection. While EAP does not assume that the 603 lower layer is reliable, it does rely on lower layer error 604 detection (e.g., CRC, Checksum, MIC, etc.). EAP methods may not 605 include a MIC, or if they do, it may not be computed over all the 606 fields in the EAP packet, such as the Code, Identifier, Length or 607 Type fields. As a result, without lower layer error detection, 608 undetected errors could creep into the EAP layer or EAP method 609 layer header fields, resulting in authentication failures. 611 For example, EAP TLS [RFC2716], which computes its MIC over the 612 Type-Data field only, regards MIC validation failures as a fatal 613 error. Without lower layer error detection, this method and 614 others like it will not perform reliably. 616 [3] Lower layer security. EAP assumes that lower layers either 617 provide physical security (e.g., wired PPP or IEEE 802 links) or 618 support per-packet authentication, integrity and replay 619 protection. EAP SHOULD NOT be used on physically insecure links 620 (e.g., wireless or the Internet) where subsequent data is not 621 protected by per-packet authentication, integrity and replay 622 protection. 624 After EAP authentication is complete, the peer will typically 625 transmit data to the network via the authenticator. In order to 626 provide assurance that the peer transmitting data is the same 627 entity that successfully completed EAP authentication, the lower 628 layer needs to bind per-packet integrity, authentication and 629 replay protection to the original EAP authentication, using keys 630 derived during EAP authentication. Alternatively, the lower 631 layer needs to be physically secure. Otherwise it is possible 632 for subsequent data traffic to be hijacked, or replayed. 634 As a result of these considerations, EAP SHOULD be used only when 635 lower layers provide physical security for data (e.g., wired PPP 636 or IEEE 802 links), or for insecure links, where per-packet 637 authentication, integrity and replay protection is provided. 639 Where keying material for the lower layer ciphersuite is itself 640 provided by EAP, ciphersuite negotiation and key activation is 641 controlled by the lower layer. In PPP, ciphersuites are 642 negotiated within ECP so that it is not possible to use keys 643 derived from EAP authentication until the completion of ECP. 644 Therefore an initial EAP exchange cannot protected by a PPP 645 ciphersuite, although EAP re-authentication can be protected. 647 In IEEE 802 media, key activation also typically occurs after 648 completion of EAP authentication. Therefore an initial EAP 649 exchange typically cannot be protected by lower layer 650 ciphersuite, although an EAP re-authentication or 651 pre-authentication exchange can be protected. 653 [4] MTU known a-priori. The EAP layer does not support fragmentation 654 and reassembly. However, EAP methods SHOULD be capable of 655 handling fragmentation and reassembly. As a result, EAP is 656 capable of functioning across a range of MTU sizes, as long as 657 the MTU is known a-priori. EAP does not support path MTU 658 discovery. 660 [5] Possible duplication. Where the lower layer is reliable, it will 661 provide the EAP layer with a non-duplicated stream of packets. 662 However, while it is desirable that lower layers provide for 663 non-duplication, this is not a requirement. The Identifier field 664 provides both the peer and authenticator with the ability to 665 detect duplicates. 667 [6] Ordering guarantees. EAP does not require the Identifier to be 668 monotonically increasing, and so is reliant on lower layer 669 ordering guarantees for correct operation. EAP was originally 670 defined to run on PPP, and [RFC1661] Section 1 has an ordering 671 requirement: 673 "The Point-to-Point Protocol is designed for simple links which 674 transport packets between two peers. These links provide 675 full-duplex simultaneous bi-directional operation, and are 676 assumed to deliver packets in order." 677 Lower layer transports for EAP MUST preserve ordering between a 678 source and destination, at a given priority level (the ordering 679 guarantee provided by [IEEE-802]). 681 3.2 EAP usage within PPP 683 In order to establish communications over a point-to-point link, each 684 end of the PPP link must first send LCP packets to configure the data 685 link during Link Establishment phase. After the link has been 686 established, PPP provides for an optional Authentication phase before 687 proceeding to the Network-Layer Protocol phase. 689 By default, authentication is not mandatory. If authentication of 690 the link is desired, an implementation MUST specify the 691 Authentication Protocol Configuration Option during Link 692 Establishment phase. 694 If the identity of the peer has been established in the 695 Authentication phase, the server can use that identity in the 696 selection of options for the following network layer negotiations. 698 When implemented within PPP, EAP does not select a specific 699 authentication mechanism at PPP Link Control Phase, but rather 700 postpones this until the Authentication Phase. This allows the 701 authenticator to request more information before determining the 702 specific authentication mechanism. This also permits the use of a 703 "backend" server which actually implements the various mechanisms 704 while the PPP authenticator merely passes through the authentication 705 exchange. The PPP Link Establishment and Authentication phases, and 706 the Authentication Protocol Configuration Option, are defined in The 707 Point-to-Point Protocol (PPP) [RFC1661]. 709 3.2.1 PPP Configuration Option Format 711 A summary of the PPP Authentication Protocol Configuration Option 712 format to negotiate EAP is shown below. The fields are transmitted 713 from left to right. 715 Exactly one EAP packet is encapsulated in the Information field of a 716 PPP Data Link Layer frame where the protocol field indicates type hex 717 C227 (PPP EAP). 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Type | Length | Authentication Protocol | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Type 726 3 728 Length 730 4 732 Authentication Protocol 734 C227 (Hex) for Extensible Authentication Protocol (EAP) 736 3.3 EAP usage within IEEE 802 738 The encapsulation of EAP over IEEE 802 is defined in [IEEE-802.1X]. 739 The IEEE 802 encapsulation of EAP does not involve PPP, and IEEE 740 802.1X does not include support for link or network layer 741 negotiations. As a result, within IEEE 802.1X it is not possible to 742 negotiate non-EAP authentication mechanisms, such as PAP or CHAP 743 [RFC1994]. 745 3.4 Lower layer indications 747 The reliability and security of lower layer indications is dependent 748 on the lower layer. Since EAP is media independent, the presence or 749 absence of lower layer security is not taken into account in the 750 processing of EAP messages. 752 Lower layer failure indications provided to EAP by the lower layer 753 MUST be processed and will cause an EAP exchange in progress to be 754 aborted. However, lower layer success indications MUST NOT affect 755 EAP message processing; an EAP implementation cannot conclude that 756 authentication has succeeded based on those indications. This ensures 757 that an attacker spoofing lower layer indications can at best succeed 758 in a denial of service attack. 760 A discussion of some reliability and security issues with lower layer 761 indications in PPP, IEEE 802 wired networks and IEEE 802.11 wireless 762 LANs can be found in the Security Considerations, Section 7.12. 764 4. EAP Packet format 766 A summary of the EAP packet format is shown below. The fields are 767 transmitted from left to right. 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Code | Identifier | Length | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Data ... 775 +-+-+-+-+ 777 Code 779 The Code field is one octet and identifies the Type of EAP packet. 780 EAP Codes are assigned as follows: 782 1 Request 783 2 Response 784 3 Success 785 4 Failure 787 Since EAP only defines Codes 1-4, EAP packets with other codes 788 MUST be silently discarded by both authenticators and peers. 790 Identifier 792 The Identifier field is one octet and aids in matching Responses 793 with Requests. 795 Length 797 The Length field is two octets and indicates the length of the EAP 798 packet including the Code, Identifier, Length and Data fields. 799 Octets outside the range of the Length field should be treated as 800 Data Link Layer padding and should be ignored on reception. 802 Data 804 The Data field is zero or more octets. The format of the Data 805 field is determined by the Code field. 807 4.1 Request and Response 809 Description 811 The Request packet (Code field set to 1) is sent by the 812 authenticator to the peer. Each Request has a Type field which 813 serves to indicate what is being requested. Additional Request 814 packets MUST be sent until a valid Response packet is received, or 815 an optional retry counter expires. 817 Retransmitted Requests MUST be sent with the same Identifier value 818 in order to distinguish them from new Requests. The contents of 819 the data field are dependent on the Request Type. The peer MUST 820 send a Response packet in reply to a valid Request packet. 821 Responses MUST only be sent in reply to a valid Request and never 822 retransmitted on a timer. 824 The Identifier field of the Response MUST match that of the 825 currently outstanding Request. An authenticator receiving a 826 Response whose Identifier value does not match that of the 827 currently outstanding Request MUST silently discard the Response. 828 The Type field of a Response MUST either match that of the 829 Request, or correspond to a legacy or Expanded Nak (see Section 830 5.3). An EAP server receiving a Response not meeting this 831 requirement MUST silently discard it. 833 Implementation Note: The authenticator is responsible for 834 retransmitting Request messages. If the Request message is 835 obtained from elsewhere (such as from a backend authentication 836 server), then the authenticator will need to save a copy of the 837 Request in order to accomplish this. The peer is responsible 838 for detecting and handling duplicate Request messages before 839 processing them in any way, including passing them on to an 840 outside party. The authenticator is also responsible for 841 discarding Response messages with a non-matching Identifier 842 value before acting on them in any way, including passing them 843 on to the backend authentication server for verification. 844 Since the authenticator can retransmit before receiving a 845 Response from the peer, the authenticator can receive multiple 846 Responses, each with a matching Identifier. Until a new Request 847 is received by the authenticator, the Identifier value is not 848 updated, so that the authenticator forwards Responses to the 849 backend authentication server, one at a time. 851 Because the authentication process will often involve user 852 input, some care must be taken when deciding upon 853 retransmission strategies and authentication timeouts. By 854 default, where EAP is run over an unreliable lower layer, the 855 EAP retransmission timer SHOULD be computed as described in 856 [RFC2988]. This includes use of Karn's algorithm to filter RTT 857 estimates resulting from retransmissions. A maximum of 3-5 858 retransmissions is suggested. 860 When run over a reliable lower layer (e.g., EAP over ISAKMP/ 861 TCP, as within [PIC]), the authenticator retransmission timer 862 SHOULD be set to an infinite value, so that retransmissions do 863 not occur at the EAP layer. Note that in this case the peer 864 may still maintain a timeout value so as to avoid waiting 865 indefinitely for a Request. 867 Where the authentication process requires user input, the 868 measured round trip times are largely determined by user 869 responsiveness rather than network characteristics, so that RTO 870 estimation is not helpful. Instead, the retransmission timer 871 SHOULD be set so as to provide sufficient time for the user to 872 respond, with longer timeouts required in certain cases, such 873 as where Token Cards (see Section 5.6) are involved. 875 In order to provide the EAP authenticator with guidance as to 876 the appropriate timeout value, a hint can be communicated to 877 the authenticator by the backend authentication server (such as 878 via the RADIUS Session-Timeout attribute). 880 A summary of the Request and Response packet format is shown below. 881 The fields are transmitted from left to right. 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Code | Identifier | Length | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Type | Type-Data ... 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 891 Code 893 1 for Request 894 2 for Response 896 Identifier 898 The Identifier field is one octet. The Identifier field MUST be 899 the same if a Request packet is retransmitted due to a timeout 900 while waiting for a Response. Any new (non-retransmission) 901 Requests MUST modify the Identifier field. In order to avoid 902 confusion between new Requests and retransmissions, the Identifier 903 value chosen for each new Request need only be different from the 904 previous Request, but need not be unique within the conversation. 905 One way to achieve this is to start the Identifier at an initial 906 value and increment it for each new Request. Initializing the 907 first Identifier with a random number rather than starting from 908 zero is recommended, since it makes sequence attacks somewhat 909 harder. 911 Since the Identifier space is unique to each session, 912 authenticators are not restricted to only 256 simultaneous 913 authentication conversations. Similarly, with re-authentication, 914 an EAP conversation might continue over a long period of time, and 915 is not limited to only 256 roundtrips. 917 If a peer receives a valid duplicate Request for which it has 918 already sent a Response, it MUST resend its original Response. If 919 a peer receives a duplicate Request before it has sent a Response, 920 but after it has determined the initial Request to be valid (i.e., 921 it is waiting for user input), it MUST silently discard the 922 duplicate Request. An EAP message may be found invalid for a 923 variety of reasons: failed lower layer CRC or checksum, malformed 924 EAP packet, EAP method MIC failure, etc. 926 Length 928 The Length field is two octets and indicates the length of the EAP 929 packet including the Code, Identifier, Length, Type, and Type-Data 930 fields. Octets outside the range of the Length field should be 931 treated as Data Link Layer padding and should be ignored on 932 reception. 934 Type 936 The Type field is one octet. This field indicates the Type of 937 Request or Response. A single Type MUST be specified for each EAP 938 Request or Response. Normally, the Type field of the Response 939 will be the same as the Type of the Request. However, there are 940 also Nak Response Types for indicating that a Request Type is 941 unacceptable to the peer (see Section 5.3). An initial 942 specification of Types follows in Section 5 of this document. 944 Type-Data 946 The Type-Data field varies with the Type of Request and the 947 associated Response. 949 4.2 Success and Failure 951 The Success packet is sent by the authenticator to the peer after 952 completion of an EAP authentication method (Type 4 or greater), to 953 indicate that the peer has authenticated successfully to the 954 authenticator. The authenticator MUST transmit an EAP packet with 955 the Code field set to 3 (Success). If the authenticator cannot 956 authenticate the peer (unacceptable Responses to one or more 957 Requests) then after unsuccessful completion of the EAP method in 958 progress, the implementation MUST transmit an EAP packet with the 959 Code field set to 4 (Failure). An authenticator MAY wish to issue 960 multiple Requests before sending a Failure response in order to allow 961 for human typing mistakes. Success and Failure packets MUST NOT 962 contain additional data. 964 EAP Success or Failure packets MUST NOT be sent by an EAP server 965 prior to completion of the final round of a given method. A peer EAP 966 implementation receiving a Success or Failure packet prior to 967 completion of the method in progress MUST silently discard it. By 968 default, an EAP peer MUST silently discard a "canned" EAP Success 969 message (an EAP Success message sent immediately upon connection). 970 This ensures that a rogue authenticator will not be able to bypass 971 mutual authentication by sending an EAP Success prior to conclusion 972 of the EAP method conversation. 974 Implementation Note: Because the Success and Failure packets are 975 not acknowledged, the authenticator cannot know whether they have 976 been received. As a result, these packets are not retransmitted 977 by the authenticator. If acknowledged result indications are 978 desired, these MAY be implemented within individual EAP methods. 979 Since only a single EAP authentication method is supported within 980 an EAP conversation, a peer that successfully authenticates the 981 authenticator MAY, in the event that an EAP Success is not 982 received, conclude that the EAP Success packet was lost and enable 983 the link. 985 A summary of the Success and Failure packet format is shown below. 986 The fields are transmitted from left to right. 988 0 1 2 3 989 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 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Code | Identifier | Length | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 Code 996 3 for Success 997 4 for Failure 999 Identifier 1001 The Identifier field is one octet and aids in matching replies to 1002 Responses. The Identifier field MUST match the Identifier field 1003 of the Response packet that it is sent in response to. 1005 Length 1007 4 1009 5. Initial EAP Request/Response Types 1011 This section defines the initial set of EAP Types used in Request/ 1012 Response exchanges. More Types may be defined in follow-on 1013 documents. The Type field is one octet and identifies the structure 1014 of an EAP Request or Response packet. The first 3 Types are 1015 considered special case Types. 1017 The remaining Types define authentication exchanges. Nak (Type 3) or 1018 Expanded Nak (Type 254) are valid only for Response packets, they 1019 MUST NOT be sent in a Request. 1021 All EAP implementations MUST support Types 1-4, which are defined in 1022 this document, and SHOULD support Type 254. Implementations MAY 1023 support other Types defined here or in future RFCs. 1025 1 Identity 1026 2 Notification 1027 3 Nak (Response only) 1028 4 MD5-Challenge 1029 5 One Time Password (OTP) 1030 6 Generic Token Card (GTC) 1031 254 Expanded Types 1032 255 Experimental use 1034 EAP methods MAY support authentication based on shared secrets. If 1035 the shared secret is a passphrase entered by the user, 1036 implementations MAY support entering passphrases with non-ASCII 1037 characters. In this case, the input should be processed using an 1038 appropriate stringprep [RFC3454] profile, and encoded in octets using 1039 UTF-8 encoding [RFC2279]. A possible registered stringprep profile is 1040 specified in [SASLPREP]. 1042 5.1 Identity 1044 Description 1046 The Identity Type is used to query the identity of the peer. 1047 Generally, the authenticator will issue this as the initial 1048 Request. An optional displayable message MAY be included to 1049 prompt the peer in the case where there is an expectation of 1050 interaction with a user. A Response of Type 1 (Identity) SHOULD 1051 be sent in Response to a Request with a Type of 1 (Identity). 1053 Since Identity Requests and Responses are not protected, from a 1054 privacy perspective, it may be preferable for protected 1055 method-specific Identity exchanges to be used instead. Where the 1056 peer is configured to only accept authentication methods 1057 supporting protected identity exchanges, the peer MAY provide an 1058 abbreviated Identity Response (such as omitting the peer-name 1059 portion of the NAI [RFC2486]). For further discussion of identity 1060 protection, see Section 7.3. 1062 Implementation Note: The peer MAY obtain the Identity via user 1063 input. It is suggested that the authenticator retry the 1064 Identity Request in the case of an invalid Identity or 1065 authentication failure to allow for potential typos on the part 1066 of the user. It is suggested that the Identity Request be 1067 retried a minimum of 3 times before terminating the 1068 authentication phase with a Failure reply. The Notification 1069 Request MAY be used to indicate an invalid authentication 1070 attempt prior to transmitting a new Identity Request 1071 (optionally, the failure MAY be indicated within the message of 1072 the new Identity Request itself). 1074 Type 1076 1 1078 Type-Data 1080 This field MAY contain a displayable message in the Request, 1081 containing UTF-8 encoded ISO 10646 characters [RFC2279]. The 1082 Response uses this field to return the Identity. If the Identity 1083 is unknown, this field should be zero bytes in length. The field 1084 MUST NOT be null terminated. The length of this field is derived 1085 from the Length field of the Request/Response packet and hence a 1086 null is not required. 1088 5.2 Notification 1090 Description 1092 The Notification Type is optionally used to convey a displayable 1093 message from the authenticator to the peer. An authenticator MAY 1094 send a Notification Request to the peer at any time when there is 1095 no outstanding Request, prior to completion of an EAP 1096 authentication method. The peer MUST respond to a Notification 1097 Request with a Notification Response unless the EAP authentication 1098 method specification prohibits the use of Notification message. 1099 In any case, a Nak Response MUST NOT be sent in response to a 1100 Notification Request. 1102 An EAP method MAY indicate within its specification that 1103 Notification messages must not be sent during that method. In this 1104 case, the peer MUST silently discard Notification Requests from 1105 the point where an initial Request for that Type is answered with 1106 a Response of the same Type. 1108 The peer SHOULD display this message to the user or log it if it 1109 cannot be displayed. The Notification Type is intended to provide 1110 an acknowledged notification of some imperative nature, but it is 1111 not an error indication, and therefore does not change the state 1112 of the peer. Examples include a password with an expiration time 1113 that is about to expire, an OTP sequence integer which is nearing 1114 0, an authentication failure warning, etc. In most circumstances, 1115 Notification should not be required. 1117 Type 1119 2 1121 Type-Data 1123 The Type-Data field in the Request contains a displayable message 1124 greater than zero octets in length, containing UTF-8 encoded ISO 1125 10646 characters [RFC2279]. The length of the message is 1126 determined by Length field of the Request packet. The message 1127 MUST NOT be null terminated. A Response MUST be sent in reply to 1128 the Request with a Type field of 2 (Notification). The Type-Data 1129 field of the Response is zero octets in length. The Response 1130 should be sent immediately (independent of how the message is 1131 displayed or logged). 1133 5.3 Nak 1135 5.3.1 Legacy Nak 1137 Description 1139 The legacy Nak Type is valid only in Response messages. It is 1140 sent in reply to a Request where the desired authentication Type 1141 is unacceptable. Authentication Types are numbered 4 and above. 1142 The Response contains one or more authentication Types desired by 1143 the Peer. Type zero (0) is used to indicate that the sender has 1144 no viable alternatives. 1146 Since the legacy Nak Type is valid only in Responses and has very 1147 limited functionality, it MUST NOT be used as a general purpose 1148 error indication, such as for communication of error messages, or 1149 negotiation of parameters specific to a particular EAP method. 1151 Code 1153 2 for Response. 1155 Identifier 1157 The Identifier field is one octet and aids in matching Responses 1158 with Requests. The Identifier field of a legacy Nak Response MUST 1159 match the Identifier field of the Request packet that it is sent 1160 in response to. 1162 Length 1164 >=6 1166 Type 1168 3 1170 Type-Data 1172 Where a peer receives a Request for an unacceptable authentication 1173 Type (4-253,255), or a peer lacking support for Expanded Types 1174 receives a Request for Type 254, a Nak Response (Type 3) MUST be 1175 sent. The Type-Data field of the Nak Response (Type 3) MUST 1176 contain one or more octets indicating the desired authentication 1177 Type(s), one octet per Type, or the value zero (0) to indicate no 1178 proposed alternative. A peer supporting Expanded Types that 1179 receives a Request for an unacceptable authentication Type (4-253, 1180 255) MAY include the value 254 in the Nak Response (Type 3) in 1181 order to indicate the desire for an Expanded authentication Type. 1182 If the authenticator can accommodate this preference, it will 1183 respond with an Expanded Type Request (Type 254). 1185 5.3.2 Expanded Nak 1187 Description 1189 The Expanded Nak Type is valid only in Response messages. It MUST 1190 be sent only in reply to a Request of Type 254 (Expanded Type) 1191 where the authentication Type is unacceptable. The Expanded Nak 1192 Type uses the Expanded Type format itself, and the Response 1193 contains one or more authentication Types desired by the peer, all 1194 in Expanded Type format. Type zero (0) is used to indicate that 1195 the sender has no viable alternatives. The general format of the 1196 Expanded Type is described in Section 5.7. 1198 Since the Expanded Nak Type is valid only in Responses and has 1199 very limited functionality, it MUST NOT be used as a general 1200 purpose error indication, such as for communication of error 1201 messages, or negotiation of parameters specific to a particular 1202 EAP method. 1204 Code 1206 2 for Response. 1208 Identifier 1210 The Identifier field is one octet and aids in matching Responses 1211 with Requests. The Identifier field of an Expanded Nak Response 1212 MUST match the Identifier field of the Request packet that it is 1213 sent in response to. 1215 Length 1217 >=40 1219 Type 1221 254 1223 Vendor-Id 1225 0 (IETF) 1227 Vendor-Type 1229 3 (Nak) 1231 Vendor-Data 1233 The Expanded Nak Type is only sent when the Request contains an 1234 Expanded Type (254) as defined in Section 5.7. The Vendor-Data 1235 field of the Nak Response MUST contain one or more authentication 1236 Types (4 or greater), all in expanded format, 8 octets per Type, 1237 or the value zero (0), also in Expanded Type format, to indicate 1238 no proposed alternative. The desired authentication Types may 1239 include a mixture of Vendor-Specific and IETF Types. For example, 1240 an Expanded Nak Response indicating a preference for OTP (Type 5), 1241 and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as 1242 follows: 1244 0 1 2 3 1245 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 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | 2 | Identifier | Length | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Type=254 | 0 (IETF) | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | 3 (Nak) | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Type=254 | 0 (IETF) | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | 5 (OTP) | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Type=254 | 20 (MIT) | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | 6 | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 An Expanded Nak Response indicating a no desired alternative would 1263 appear as follows: 1265 0 1 2 3 1266 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 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | 2 | Identifier | Length | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Type=254 | 0 (IETF) | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | 3 (Nak) | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Type=254 | 0 (IETF) | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | 0 (No alternative) | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 5.4 MD5-Challenge 1281 Description 1283 The MD5-Challenge Type is analogous to the PPP CHAP protocol 1284 [RFC1994] (with MD5 as the specified algorithm). The Request 1285 contains a "challenge" message to the peer. A Response MUST be 1286 sent in reply to the Request. The Response MAY be either of Type 1287 4 (MD5-Challenge), Nak (Type 3) or Expanded Nak (Type 254). The 1288 Nak reply indicates the peer's desired authentication Type(s). 1289 EAP peer and EAP server implementations MUST support the 1290 MD5-Challenge mechanism. An authenticator that supports only 1291 pass-through MUST allow communication with a backend 1292 authentication server that is capable of supporting MD5-Challenge, 1293 although the EAP authenticator implementation need not support 1294 MD5-Challenge itself. However, if the EAP authenticator can be 1295 configured to authenticate peers locally (e.g., not operate in 1296 pass-through), then the requirement for support of the 1297 MD5-Challenge mechanism applies. 1299 Note that the use of the Identifier field in the MD5-Challenge 1300 Type is different from that described in [RFC1994]. EAP allows 1301 for retransmission of MD5-Challenge Request packets while 1302 [RFC1994] states that both the Identifier and Challenge fields 1303 MUST change each time a Challenge (the CHAP equivalent of the 1304 MD5-Challenge Request packet) is sent. 1306 Note: [RFC1994] treats the shared secret as an octet string, and 1307 does not specify how it is entered into the system (or if it is 1308 handled by the user at all). EAP MD5-Challenge implementations MAY 1309 support entering passphrases with non-ASCII characters. See 1310 Section 5 for instructions how the input should be processed and 1311 encoded into octets. 1313 Type 1315 4 1317 Type-Data 1319 The contents of the Type-Data field is summarized below. For 1320 reference on the use of these fields see the PPP Challenge 1321 Handshake Authentication Protocol [RFC1994]. 1323 0 1 2 3 1324 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 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Value-Size | Value ... 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | Name ... 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 Security Claims (see Section 7.2): 1333 Intended use: Wired networks, including PPP, PPPOE, and 1334 IEEE 802 wired media. Use over the 1335 Internet or with wireless media only when 1336 protected. 1337 Mechanism: Password or pre-shared key. 1338 Mutual authentication: No 1339 Integrity protection: No 1340 Replay protection: No 1341 Confidentiality: No 1342 Key Derivation: No 1343 Key strength: N/A 1344 Dictionary attack prot: No 1345 Key hierarchy: N/A 1346 Fast reconnect: No 1347 MiTM resistance: N/A 1348 Acknowledged S/F: No 1350 5.5 One-Time Password (OTP) 1352 Description 1354 The One-Time Password system is defined in "A One-Time Password 1355 System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The 1356 Request contains an OTP challenge in the format described in 1357 [RFC2289]. A Response MUST be sent in reply to the Request. The 1358 Response MUST be of Type 5 (OTP), Nak (Type 3) or Expanded Nak 1359 (Type 254). The Nak Response indicates the peer's desired 1360 authentication Type(s). 1362 Type 1364 5 1366 Type-Data 1368 The Type-Data field contains the OTP "challenge" as a displayable 1369 message in the Request. In the Response, this field is used for 1370 the 6 words from the OTP dictionary [RFC2289]. The messages MUST 1371 NOT be null terminated. The length of the field is derived from 1372 the Length field of the Request/Reply packet. 1374 Note: [RFC2289] does not specify how the secret pass-phrase is 1375 entered by the user, or how the pass-phrase is converted into 1376 octets. EAP OTP implementations MAY support entering passphrases 1377 with non-ASCII characters. See Section 5 for instructions how the 1378 input should be processed and encoded into octets. 1380 Security Claims (see Section 7.2): 1382 Intended use: Wired networks, including PPP, PPPOE, and 1383 IEEE 802 wired media. Use over the 1384 Internet or with wireless media only when 1385 protected. 1386 Mechanism: One-Time Password 1387 Mutual authentication: No 1388 Integrity protection: No 1389 Replay protection: No 1390 Confidentiality: No 1391 Key Derivation: No 1392 Key strength: N/A 1393 Dictionary attack prot: No 1394 Key hierarchy: N/A 1395 Fast reconnect: No 1396 MiTM resistance: N/A 1397 Acknowledged S/F: No 1399 5.6 Generic Token Card (GTC) 1401 Description 1403 The Generic Token Card Type is defined for use with various Token 1404 Card implementations which require user input. The Request 1405 contains a displayable message and the Response contains the Token 1406 Card information necessary for authentication. Typically, this 1407 would be information read by a user from the Token card device and 1408 entered as ASCII text. A Response MUST be sent in reply to the 1409 Request. The Response MUST be of Type 6 (GTC), Nak (Type 3) or 1410 Expanded Nak (Type 254). The Nak Response indicates the peer's 1411 desired authentication Type(s). 1413 Type 1415 6 1417 Type-Data 1419 The Type-Data field in the Request contains a displayable message 1420 greater than zero octets in length. The length of the message is 1421 determined by the Length field of the Request packet. The message 1422 MUST NOT be null terminated. A Response MUST be sent in reply to 1423 the Request with a Type field of 6 (Generic Token Card). The 1424 Response contains data from the Token Card required for 1425 authentication. The length of the data is determined by the 1426 Length field of the Response packet. 1428 EAP GTC implementations MAY support entering a response with 1429 non-ASCII characters. See Section 5 for instructions how the 1430 input should be processed and encoded into octets. 1432 Security Claims (see Section 7.2): 1434 Intended use: Wired networks, including PPP, PPPOE, and 1435 IEEE 802 wired media. Use over the 1436 Internet or with wireless media only when 1437 protected. 1438 Mechanism: Hardware token. 1439 Mutual authentication: No 1440 Integrity protection: No 1441 Replay protection: No 1442 Confidentiality: No 1443 Key Derivation: No 1444 Key strength: N/A 1445 Dictionary attack prot: No 1446 Key hierarchy: N/A 1447 Fast reconnect: No 1448 MiTM resistance: N/A 1449 Acknowledged S/F: No 1451 5.7 Expanded Types 1453 Description 1455 Since many of the existing uses of EAP are vendor-specific, the 1456 Expanded method Type is available to allow vendors to support 1457 their own Expanded Types not suitable for general usage. 1459 The Expanded Type is also used to expand the global Method Type 1460 space beyond the original 255 values. A Vendor-Id of 0 maps the 1461 original 255 possible Types onto a namespace of 2^32-1 possible 1462 Types, allowing for virtually unlimited expansion. (Type 0 is only 1463 used in a Nak Response, to indicate no acceptable alternative) 1465 An implementation that supports the Expanded attribute MUST treat 1466 EAP Types that are less than 256 equivalently whether they appear 1467 as a single octet or as the 32-bit Vendor-Type within a Expanded 1468 Type where Vendor-Id is 0. Peers not equipped to interpret the 1469 Expanded Type MUST send a Nak as described in Section 5.3.1, and 1470 negotiate a more suitable authentication method. 1472 A summary of the Expanded Type format is shown below. The fields 1473 are transmitted from left to right. 1475 0 1 2 3 1476 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 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | Type | Vendor-Id | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Vendor-Type | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Vendor data... 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 Type 1487 254 for Expanded Type 1489 Vendor-Id 1491 The Vendor-Id is 3 octets and represents the SMI Network 1492 Management Private Enterprise Code of the Vendor in network byte 1493 order, as allocated by IANA. A Vendor-Id of zero is reserved for 1494 use by the IETF in providing an expanded global EAP Type space. 1496 Vendor-Type 1498 The Vendor-Type field is four octets and represents the 1499 vendor-specific method Type. 1501 If the Vendor-Id is zero, the Vendor-Type field is an extension 1502 and superset of the existing namespace for EAP Types. The first 1503 256 Types are reserved for compatibility with single-octet EAP 1504 Types that have already been assigned or may be assigned in the 1505 future. Thus, EAP Types from 0 through 255 are semantically 1506 identical whether they appear as single octet EAP Types or as 1507 Vendor-Types when Vendor-Id is zero. 1509 Vendor-Data 1511 The Vendor-Data field is defined by the vendor. Where a Vendor-Id 1512 of zero is present, the Vendor-Data field will be used for 1513 transporting the contents of EAP methods of Types defined by the 1514 IETF. 1516 5.8 Experimental 1517 Description 1519 The Experimental Type has no fixed format or content. It is 1520 intended for use when experimenting with new EAP Types. This Type 1521 is intended for experimental and testing purposes. No guarantee 1522 is made for interoperability between peers using this Type, as 1523 outlined in [IANA-EXP]. 1525 Type 1527 255 1529 Type-Data 1531 Undefined 1533 6. IANA Considerations 1535 This section provides guidance to the Internet Assigned Numbers 1536 Authority (IANA) regarding registration of values related to the EAP 1537 protocol, in accordance with BCP 26, [RFC2434]. 1539 There are two name spaces in EAP that require registration: Packet 1540 Codes and method Types. 1542 EAP is not intended as a general-purpose protocol, and allocations 1543 SHOULD NOT be made for purposes unrelated to authentication. 1545 The following terms are used here with the meanings defined in BCP 1546 26: "name space", "assigned value", "registration". 1548 The following policies are used here with the meanings defined in BCP 1549 26: "Private Use", "First Come First Served", "Expert Review", 1550 "Specification Required", "IETF Consensus", "Standards Action". 1552 For registration requests where a Designated Expert should be 1553 consulted, the responsible IESG area director should appoint the 1554 Designated Expert. The intention is that any allocation will be 1555 accompanied by a published RFC. But in order to allow for the 1556 allocation of values prior to the RFC being approved for publication, 1557 the Designated Expert can approve allocations once it seems clear 1558 that an RFC will be published. The Designated expert will post a 1559 request to the EAP WG mailing list (or a successor designated by the 1560 Area Director) for comment and review, including an Internet-Draft. 1561 Before a period of 30 days has passed, the Designated Expert will 1562 either approve or deny the registration request and publish a notice 1563 of the decision to the EAP WG mailing list or its successor, as well 1564 as informing IANA. A denial notice must be justified by an 1565 explanation and, in the cases where it is possible, concrete 1566 suggestions on how the request can be modified so as to become 1567 acceptable. 1569 6.1 Packet Codes 1571 Packet Codes have a range from 1 to 255, of which 1-4 have been 1572 allocated. Because a new Packet Code has considerable impact on 1573 interoperability, a new Packet Code requires Standards Action, and 1574 should be allocated starting at 5. 1576 6.2 Method Types 1578 The original EAP method Type space has a range from 1 to 255, and is 1579 the scarcest resource in EAP, and thus must be allocated with care. 1580 Method Types 1-41 have been allocated, with 20 available for re-use. 1581 Method Types 42-191 may be allocated on the advice of a Designated 1582 Expert, with Specification Required. 1584 Allocation of blocks of method Types (more than one for a given 1585 purpose) should require IETF Consensus. EAP Type Values 192-253 are 1586 reserved and allocation requires Standards Action. 1588 Method Type 254 is allocated for the Expanded Type. Where the 1589 Vendor-Id field is non-zero, the Expanded Type is used for functions 1590 specific only to one vendor's implementation of EAP, where no 1591 interoperability is deemed useful. When used with a Vendor-Id of 1592 zero, method Type 254 can also be used to provide for an expanded 1593 IETF method Type space. Method Type values 256-4294967295 may be 1594 allocated after Type values 1-191 have been allocated. 1596 Method Type 255 is allocated for Experimental use, such as testing of 1597 new EAP methods before a permanent Type code is allocated. 1599 7. Security Considerations 1601 EAP was designed for use with dialup PPP [RFC1661] and was later 1602 adapted for use in wired IEEE 802 networks [IEEE-802] in 1603 [IEEE-802.1X]. On these networks, an attacker would need to gain 1604 physical access to the telephone or switch infrastructure in order to 1605 mount an attack. While such attacks have been documented, such as in 1606 [DECEPTION], they are assumed to be rare. 1608 However, subsequently EAP has been proposed for use on wireless 1609 networks, and over the Internet, where physical security cannot be 1610 assumed. On such networks, the security vulnerabilities are greater, 1611 as are the requirements for EAP security. 1613 This section defines the threat model and security terms and 1614 describes the security claims section required in EAP method 1615 specifications. We then discuss threat mitigation. 1617 7.1 Threat model 1619 On physically insecure networks, it is possible for an attacker to 1620 gain access to the physical medium. This enables a range of attacks, 1621 including the following: 1623 [1] An attacker may try to discover user identities by snooping 1624 authentication traffic. 1626 [2] An attacker may try to modify or spoof EAP packets. 1628 [3] An attacker may launch denial of service attacks by spoofing 1629 lower layer indications or Success/Failure packets; by replaying 1630 EAP packets; or by generating packets with overlapping 1631 Identifiers. 1633 [4] An attacker may attempt to recover the pass-phrase by mounting an 1634 offline dictionary attack. 1636 [5] An attacker may attempt to convince the peer to connect to an 1637 untrusted network, by mounting a man-in-the-middle attack. 1639 [6] An attacker may attempt to disrupt the EAP negotiation in order 1640 cause a weak authentication method to be selected. 1642 [7] An attacker may attempt to recover keys by taking advantage of 1643 weak key derivation techniques used within EAP methods. 1645 [8] An attacker may attempt to take advantage of weak ciphersuites 1646 subsequently used after the EAP conversation is complete. 1648 [9] An attacker may attempt to perform downgrading attacks on lower 1649 layer ciphersuite negotiation in order to ensure that a weaker 1650 ciphersuite is used subsequently to EAP authentication. 1652 Where EAP is used over wired networks, an attacker typically requires 1653 access to the physical infrastructure in order to carry out these 1654 attacks. However, where EAP is used over wireless networks, EAP 1655 packets may be forwarded by authenticators (e.g., pre-authentication) 1656 so that the attacker need not be within the coverage area of an 1657 authenticator in order to carry out an attack on it or its peers. 1658 Where EAP is used over the Internet, attacks may be carried out at an 1659 even greater distance. 1661 7.2 Security claims 1663 In order to clearly articulate the security provided by an EAP 1664 method, EAP method specifications MUST include a Security Claims 1665 section including the following declarations: 1667 [a] Intended use. This includes a statement of whether the method is 1668 intended for use over a physically secure or insecure network, as 1669 well as a statement of the applicable lower layers. 1671 [b] Mechanism. This is a statement of the authentication technology: 1672 certificates, pre-shared keys, passwords, token cards, etc. 1674 [c] Security claims. This is a statement of the claimed security 1675 properties of the method, using terms defined in Section 1.2: 1676 mutual authentication, integrity protection, replay protection, 1677 confidentiality, key derivation, dictionary attack resistance, 1678 fast reconnect, man-in-the-middle resistance, acknowledged result 1679 indications. The Security Claims section of an EAP method 1680 specification SHOULD provide justification for the claims that 1681 are made. This can be accomplished by including a proof in an 1682 Appendix, or including a reference to a proof. 1684 [d] Key strength. If the method derives keys, then the effective key 1685 strength MUST be estimated. This estimate is meant for potential 1686 users of the method to determine if the keys produced are strong 1687 enough for the intended application. 1689 The effective key strength SHOULD be stated as number of bits, 1690 defined as follows: If the effective key strength is N bits, the 1691 best currently known methods to recover the key (with 1692 non-negligible probability) require an effort comparable to 2^N 1693 operations of a typical block cipher. The statement SHOULD be 1694 accompanied by a short rationale, explaining how this number was 1695 arrived at. This explanation SHOULD include the parameters 1696 required to achieve the stated key strength based on current 1697 knowledge of the algorithms. 1699 (Note: Although it is difficult to define what "comparable 1700 effort" and "typical block cipher" exactly mean, reasonable 1701 approximations are sufficient here. Refer to e.g. [SILVERMAN] 1702 for more discussion.) 1704 The key strength depends on the methods used to derive the keys. 1705 For instance, if keys are derived from a shared secret (such as a 1706 password or a long-term secret), and possibly some public 1707 information such as nonces, the effective key strength is limited 1708 by the strength of the long-term secret (assuming that the 1709 derivation procedure is computationally simple). To take another 1710 example, when using public key algorithms, the strength of the 1711 symmetric key depends on the strength of the public keys used. 1713 [e] Description of key hierarchy. EAP methods deriving keys MUST 1714 either provide a reference to a key hierarchy specification, or 1715 describe how Master Session Keys (MSKs) and Extended Master 1716 Session Keys (EMSKs) are to be derived. 1718 [f] Indication of vulnerabilities. In addition to the security 1719 claims that are made, the specification MUST indicate which of 1720 the security claims detailed in Section 1.2 are NOT being made. 1722 7.3 Identity protection 1724 An Identity exchange is optional within the EAP conversation. 1725 Therefore, it is possible to omit the Identity exchange entirely, or 1726 to use a method-specific identity exchange once a protected channel 1727 has been established. 1729 However, where roaming is supported as described in [RFC2607], it may 1730 be necessary to locate the appropriate backend authentication server 1731 before the authentication conversation can proceed. The realm 1732 portion of the Network Access Identifier (NAI) [RFC2486] is typically 1733 included within the Identity-Response in order to enable the 1734 authentication exchange to be routed to the appropriate backend 1735 authentication server. Therefore while the peer-name portion of the 1736 NAI may be omitted in the Identity- Response, where proxies or relays 1737 are present, the realm portion may be required. 1739 7.4 Man-in-the-middle attacks 1741 Where EAP is tunneled within another protocol that omits peer 1742 authentication, there exists a potential vulnerability to 1743 man-in-the-middle attack. 1745 As noted in Section 2.1, EAP does not permit sequences of 1746 authentication methods. Were a sequence of EAP authentication 1747 methods to be permitted, the peer might not have proof that a single 1748 entity has acted as the authenticator for all EAP methods within the 1749 sequence. For example, an authenticator might terminate one EAP 1750 method, then forward the next method in the sequence to another party 1751 without the peer's knowledge or consent. Similarly, the 1752 authenticator might not have proof that a single entity has acted as 1753 the peer for all EAP methods within the sequence. 1755 This enables an attack by a rogue EAP authenticator tunneling EAP to 1756 a legitimate server. Where the tunneling protocol is used for key 1757 establishment but does not require peer authentication, an attacker 1758 convincing a legitimate peer to connect to it will be able to tunnel 1759 EAP packets to a legitimate server, successfully authenticating and 1760 obtaining the key. This allows the attacker to successfully 1761 establish itself as a man-in-the-middle, gaining access to the 1762 network, as well as the ability to decrypt data traffic between the 1763 legitimate peer and server. 1765 This attack may be mitigated by the following measures: 1767 [a] Requiring mutual authentication within EAP tunneling mechanisms. 1769 [b] Requiring cryptographic binding between the EAP tunneling 1770 protocol and the tunneled EAP methods. Where cryptographic 1771 binding is supported, a mechanism is also needed to protect 1772 against downgrade attacks that would bypass it. 1774 [c] Limiting the EAP methods authorized for use without protection, 1775 based on peer and authenticator policy. 1777 [d] Avoiding the use of tunnels when a single, strong method is 1778 available. 1780 7.5 Packet modification attacks 1782 While EAP methods may support per-packet data origin authentication, 1783 integrity and replay protection, support is not provided within the 1784 EAP layer. 1786 Since the Identifier is only a single octet, it is easy to guess, 1787 allowing an attacker to successfully inject or replay EAP packets. An 1788 attacker may also modify EAP headers within EAP packets where the 1789 header is unprotected. This could cause packets to be 1790 inappropriately discarded or misinterpreted. 1792 In the case of PPP and IEEE 802 wired links, it is assumed that such 1793 attacks are restricted to attackers who can gain access to the 1794 physical link. However, where EAP is run over physically insecure 1795 lower layers such as wireless (802.11 or cellular) or the Internet 1796 (such as within protocols supporting PPP, EAP or Ethernet Tunneling), 1797 this assumption is no longer valid and the vulnerability to attack is 1798 greater. 1800 To protect EAP messages sent over physically insecure lower layers, 1801 methods providing mutual authentication and key derivation, as well 1802 as per-packet origin authentication, integrity and replay protection 1803 SHOULD be used. Method-specific MICs may be used to provide 1804 protection. Since EAP messages of Types Identity, Notification, and 1805 Nak do not include their own MIC, it may be desirable for the EAP 1806 method MIC to cover information contained within these messages, as 1807 well as the header of each EAP message. For details, see Appendix A. 1809 To provide protection, EAP also may be encapsulated within a 1810 protected channel created by protocols such as ISAKMP [RFC2408] as is 1811 done in [PIC] or within TLS [RFC2246]. However, as noted in Section 1812 7.4, EAP tunneling may result in a man-in-the-middle vulnerability. 1814 7.6 Dictionary attacks 1816 Password authentication algorithms such as EAP-MD5, MS-CHAPv1 1817 [RFC2433] and Kerberos V [RFC1510] are known to be vulnerable to 1818 dictionary attacks. MS-CHAPv1 vulnerabilities are documented in 1819 [PPTPv1]; Kerberos vulnerabilities are described in [KRBATTACK], 1820 [KRBLIM], and [KERB4WEAK]. 1822 Where EAP runs over lower layers which are not physically secure, in 1823 order to protect against dictionary attacks, an authentication 1824 algorithm resistant to dictionary attack (as defined in Section 7.2) 1825 SHOULD be used. 1827 If an authentication algorithm is used that is known to be vulnerable 1828 to dictionary attack, then the conversation may be tunneled within a 1829 protected channel, in order to provide additional protection. 1830 However, as noted in Section 7.4, EAP tunneling may result in a 1831 man-in-the-middle vulnerability, and therefore dictionary attack 1832 resistant methods are preferred. 1834 7.7 Connection to an untrusted network 1836 With EAP methods supporting one-way authentication, such as EAP-MD5, 1837 the peer does not authenticate the authenticator. Where the lower 1838 layer is not physically secure (such as where EAP runs over wireless 1839 media or the Internet), the peer is vulnerable to a rogue 1840 authenticator. As a result, where the lower layer is not physically 1841 secure, a method supporting mutual authentication is RECOMMENDED. 1843 In EAP there is no requirement that authentication be full duplex or 1844 that the same protocol be used in both directions. It is perfectly 1845 acceptable for different protocols to be used in each direction. This 1846 will, of course, depend on the specific protocols negotiated. 1847 However, in general, completing a single unitary mutual 1848 authentication is preferable to two one-way authentications, one in 1849 each direction. This is because separate authentications that are 1850 not bound cryptographically so as to demonstrate they are part of the 1851 same session are subject to man-in-the-middle attacks, as discussed 1852 in Section 7.4. 1854 7.8 Negotiation attacks 1856 In a negotiation attack, the attacker attempts to convince the peer 1857 and authenticator to negotiate a less secure EAP method. EAP does 1858 not provide protection for Nak Response packets, although it is 1859 possible for a method to include coverage of Nak Responses within a 1860 method-specific MIC. 1862 Within or associated with each authenticator, it is not anticipated 1863 that a particular named peer will support a choice of methods. This 1864 would make the peer vulnerable to attacks that negotiate the least 1865 secure method from among a set. Instead, for each named peer there 1866 SHOULD be an indication of exactly one method used to authenticate 1867 that peer name. If a peer needs to make use of different 1868 authentication methods under different circumstances, then distinct 1869 identities SHOULD be employed, each of which identifies exactly one 1870 authentication method. 1872 7.9 Implementation idiosyncrasies 1874 The interaction of EAP with lower layers such as PPP and IEEE 802 are 1875 highly implementation dependent. 1877 For example, upon failure of authentication, some PPP implementations 1878 do not terminate the link, instead limiting traffic in Network-Layer 1879 Protocols to a filtered subset, which in turn allows the peer the 1880 opportunity to update secrets or send mail to the network 1881 administrator indicating a problem. Similarly, while in 1882 [IEEE-802.1X] an authentication failure will result in denied access 1883 to the controlled port, limited traffic may be permitted on the 1884 uncontrolled port. 1886 In EAP there is no provision for retries of failed authentication. 1887 However, in PPP the LCP state machine can renegotiate the 1888 authentication protocol at any time, thus allowing a new attempt. 1889 Similarly, in IEEE 802.1X the Supplicant or Authenticator can 1890 re-authenticate at any time. It is recommended that any counters 1891 used for authentication failure not be reset until after successful 1892 authentication, or subsequent termination of the failed link. 1894 7.10 Key derivation 1896 It is possible for the peer and EAP server to mutually authenticate, 1897 and derive keys. In order to provide keying material for use in a 1898 subsequently negotiated ciphersuite, an EAP method supporting key 1899 derivation MUST export a Master Session Key (MSK) of at least 64 1900 octets, and an Extended Master Session Key (EMSK) of at least 64 1901 octets. 1903 The MSK and EMSK are not used directly to protect data; however, they 1904 are of sufficient size to enable subsequent derivation of Transient 1905 Session Keys (TSKs) for use with the selected ciphersuite. Each 1906 ciphersuite is responsible for specifying how to derive the TSKs from 1907 the MSK. The EAP method is also responsible for the derivation of 1908 Transient EAP Keys (TEKs) used for protection of the EAP conversation 1909 itself. 1911 EAP methods provide Master Session Keys and not Transient Session 1912 Keys so as to allow EAP methods to be ciphersuite and media 1913 independent. Depending on the lower layer, EAP methods may run 1914 before or after ciphersuite negotiation, so that the selected 1915 ciphersuite may not be known to the EAP method. By providing keying 1916 material usable with any ciphersuite, EAP methods can used with a 1917 wide range of ciphersuites and media. 1919 Non-overlapping substrings of the MSK MUST be cryptographically 1920 separate from each other. This is required because some existing 1921 ciphersuites form TSKs by simply splitting the MSK to pieces of 1922 appropriate length. Likewise, non-overlapping substrings of EMSK 1923 MUST be cryptographically separate from each other, and from 1924 substrings of the MSK. 1926 The EMSK is reserved for future use and MUST remain on the EAP peer 1927 and EAP server where it is derived; it MUST NOT be transported to, or 1928 shared with, additional parties, or used to derive any other keys. 1929 (This restriction will be relaxed in a future document that specifies 1930 how the EMSK can be used.) 1932 This specification does not provide detailed guidance on how EAP 1933 methods are to derive the MSK, EMSK and TEKs, or how the TSKs are to 1934 be derived from the MSK. Key derivation is an art that is best 1935 practiced by professionals; rather than inventing new key derivation 1936 algorithms, reuse of existing algorithms such as those specified in 1937 IKE [RFC2409], or TLS [RFC2246] is recommended. 1939 Further details on EAP Key Derivation are provided within [KEYFRAME]. 1941 7.11 Weak ciphersuites 1943 If after the initial EAP authentication, data packets are sent 1944 without per-packet authentication, integrity and replay protection, 1945 an attacker with access to the media can inject packets, "flip bits" 1946 within existing packets, replay packets, or even hijack the session 1947 completely. Without per-packet confidentiality, it is possible to 1948 snoop data packets. 1950 As a result, as noted in Section 3.1, where EAP is used over a 1951 physically insecure lower layer, per-packet authentication, integrity 1952 and replay protection SHOULD be used, and per-packet confidentiality 1953 is also recommended. 1955 Additionally, if the lower layer performs ciphersuite negotiation, it 1956 should be understood that EAP does not provide by itself integrity 1957 protection of that negotiation. Therefore, in order to avoid 1958 downgrading attacks which would lead to weaker ciphersuites being 1959 used, clients implementing lower layer ciphersuite negotiation SHOULD 1960 protect against negotiation downgrading. 1962 This can be done by enabling users to configure which are the 1963 acceptable ciphersuites as a matter of security policy; or, the 1964 ciphersuite negotiation MAY be authenticated using keying material 1965 derived from the EAP authentication and a MIC algorithm agreed upon 1966 in advance by lower-layer peers. 1968 7.12 Link layer 1970 There exists a number of reliability and security issues with link 1971 layer indications in PPP, IEEE 802 wired networks and IEEE 802.11 1972 wireless LANs: 1974 [a] PPP. In PPP, link layer indications such as LCP-Terminate (a 1975 link failure indication) and NCP (a link success indication) are 1976 not authenticated or integrity protected. They can therefore be 1977 spoofed by an attacker with access to the physical medium. 1979 [b] IEEE 802 wired networks. On wired networks, IEEE 802.1X messages 1980 are sent to a non-forwardable multicast MAC address. As a 1981 result, while the IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames 1982 are not authenticated or integrity protected, only an attacker 1983 with access to the physical link can spoof these messages. 1985 [c] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer 1986 indications include Disassociate and Deauthenticate frames (link 1987 failure indications), and Association and Reassociation Response 1988 frames (link success indications). These messages are not 1989 authenticated or integrity protected, and although they are not 1990 forwardable, they are spoofable by an attacker within range. 1992 In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3 1993 unicast data frames, and are therefore forwardable. This implies 1994 that while EAPOL-Start and EAPOL-Logoff messages may be 1995 authenticated and integrity protected, they can be spoofed by an 1996 authenticated attacker far from the target when 1997 "pre-authentication" is enabled. 1999 In IEEE 802.11 a "link down" indication is an unreliable 2000 indication of link failure, since wireless signal strength can 2001 come and go and may be influenced by radio frequency interference 2002 generated by an attacker. To avoid unnecessary resets, it is 2003 advisable to damp these indications, rather than passing them 2004 directly to the EAP. Since EAP supports retransmission, it is 2005 robust against transient connectivity losses. 2007 7.13 Separation of authenticator and backend authentication server 2009 It is possible for the EAP peer and authenticator to mutually 2010 authenticate, and derive a Master Session Key (MSK) for a ciphersuite 2011 used to protect subsequent data traffic. This does not present an 2012 issue on the peer, since the peer and EAP client reside on the same 2013 machine; all that is required is for the EAP client module to derive 2014 and pass a Transient Session Key (TSK) to the ciphersuite module. 2016 However, in the case where the authenticator and authentication 2017 server reside on different machines, there are several implications 2018 for security. 2020 [a] Authentication will occur between the peer and the authentication 2021 server, not between the peer and the authenticator. This means 2022 that it is not possible for the peer to validate the identity of 2023 the authenticator that it is speaking to, using EAP alone. 2025 [b] As discussed in [RFC2869bis], the authenticator is dependent on 2026 the AAA protocol in order to know the outcome of an 2027 authentication conversation, and does not look at the 2028 encapsulated EAP packet (if one is present) to determine the 2029 outcome. In practice this means that the AAA protocol spoken 2030 between the authenticator and authentication server MUST support 2031 per-packet authentication, integrity and replay protection. 2033 [c] Where EAP is used over lower layers which are not physically 2034 secure, subsequent to completion of the EAP conversation, a 2035 subsequent protocol SHOULD be run between the peer and 2036 authentication in order to mutually authenticate the peer and 2037 authenticator; guarantee liveness of the TSKs; provide protected 2038 ciphersuite and capabilities negotiation; and provide for 2039 synchronized key usage. 2041 [d] An EAP Master Session Key (MSK) negotiated between the peer and 2042 authentication server MAY be transmitted to the authenticator. 2043 Therefore a mechanism needs to be provided to transmit the MSK 2044 from the authentication server to the authenticator that needs 2045 it. The specification of the key transport and wrapping 2046 mechanism is outside the scope of this document. 2048 8. Acknowledgments 2050 This protocol derives much of its inspiration from Dave Carrel's AHA 2051 draft as well as the PPP CHAP protocol [RFC1994]. Valuable feedback 2052 was provided by Yoshihiro Ohba of Toshiba America Research, Jari 2053 Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco 2054 Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan 2055 Payne of the University of Maryland, Steve Bellovin of AT&T Research, 2056 Paul Funk of Funk Software, Pasi Eronen of Nokia, Joseph Salowey of 2057 Cisco and Paul Congdon of HP and members of the EAP working group. 2059 Normative References 2061 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2062 RFC 1661, July 1994. 2064 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 2065 Protocol (CHAP)", RFC 1994, August 1996. 2067 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2068 Requirement Levels", BCP 14, RFC 2119, March 1997. 2070 [RFC2243] Metz, C., "OTP Extended Responses", RFC 2243, November 2071 1997. 2073 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 2074 10646", RFC 2279, January 1998. 2076 [RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time 2077 Password System", RFC 2289, February 1998. 2079 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2080 (IKE)", RFC 2409, November 1998. 2082 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2083 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2084 October 1998. 2086 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 2087 Timer", RFC 2988, November 2000. 2089 [IEEE-802] 2090 Institute of Electrical and Electronics Engineers, "Local 2091 and Metropolitan Area Networks: Overview and 2092 Architecture", IEEE Standard 802, 1990. 2094 [IEEE-802.1X] 2095 Institute of Electrical and Electronics Engineers, "Local 2096 and Metropolitan Area Networks: Port-Based Network Access 2097 Control", IEEE Standard 802.1X, September 2001. 2099 Informative References 2101 [DECEPTION] 2102 Slatalla, M. and J. Quittner, "Masters of Deception", 2103 HarperCollins , New York, 1995. 2105 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 2106 Authentication Service (V5)", RFC 1510, September 1993. 2108 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 2109 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 2110 January 1999. 2112 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 2113 Authentication Protocol (EAP)", RFC 2284, March 1998. 2115 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 2116 RFC 2486, January 1999. 2118 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2119 Internet Protocol", RFC 2401, November 1998. 2121 [RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet 2122 Security Association and Key Management Protocol 2123 (ISAKMP)", RFC 2408, November 1998. 2125 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2126 2433, October 1998. 2128 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2129 Implementation in Roaming", RFC 2607, June 1999. 2131 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. 2132 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2133 2661, August 1999. 2135 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 2136 Protocol", RFC 2716, October 1999. 2138 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 2139 Internationalized Strings ("stringprep")", RFC 3454, 2140 December 2002. 2142 [KRBATTACK] 2143 Wu, T., "A Real-World Analysis of Kerberos Password 2144 Security", Stanford University Computer Science 2145 Department, http://theory.stanford.edu/~tjw/krbpass.html. 2147 [KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos 2148 authentication system", Proceedings of the 1991 Winter 2149 USENIX Conference, pp. 253-267, 1991. 2151 [KERB4WEAK] 2152 Dole, B., Lodin, S. and E. Spafford, "Misplaced trust: 2153 Kerberos 4 session keys", Proceedings of the Internet 2154 Society Network and Distributed System Security Symposium, 2155 pp. 60-70, March 1997. 2157 [PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A Pre-IKE 2158 Credential Provisioning Protocol", draft-ietf-ipsra-pic-06 2159 (work in progress), October 2002. 2161 [PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's 2162 Point-to- Point Tunneling Protocol", Proceedings of the 2163 5th ACM Conference on Communications and Computer 2164 Security, ACM Press, November 1998. 2166 [IEEE-802.3] 2167 Institute of Electrical and Electronics Engineers, 2168 "Information technology - Telecommunications and 2169 Information Exchange between Systems - Local and 2170 Metropolitan Area Networks - Specific requirements - Part 2171 3: Carrier sense multiple access with collision detection 2172 (CSMA/CD) Access Method and Physical Layer 2173 Specifications", IEEE Standard 802.3, September 1998. 2175 [IEEE-802.11] 2176 Institute of Electrical and Electronics Engineers, 2177 "Information Technology - Telecommunications and 2178 Information Exchange between Systems - Local and 2179 Metropolitan Area Network - Specific Requirements - Part 2180 11: Wireless LAN Medium Access Control (MAC) and Physical 2181 Layer (PHY) Specifications", IEEE Standard 802.11, 1999. 2183 [SILVERMAN] 2184 Silverman, Robert D., "A Cost-Based Security Analysis of 2185 Symmetric and Asymmetric Key Lengths", RSA Laboratories 2186 Bulletin 13, April 2000 (Revised November 2001), http:// 2187 www.rsasecurity.com/rsalabs/bulletins/bulletin13.html. 2189 [RFC2869bis] 2190 Aboba, B. and P. Calhoun, "RADIUS Support For Extensible 2191 Authentication Protocol (EAP)", 2192 draft-aboba-radius-rfc2869bis-21 (work in progress), May 2193 2003. 2195 [IANA-EXP] 2196 Narten, T., "Assigning Experimental and Testing Numbers 2197 Considered Useful", 2198 draft-narten-iana-experimental-allocations-03 (work in 2199 progress), December 2002. 2201 [KEYFRAME] 2202 Aboba, B. and D. Simon, "EAP Keying Framework", 2203 draft-aboba-pppext-key-problem-06 (work in progress), 2204 March 2003. 2206 [SASLPREP] 2207 Zeilenga, K., "SASLprep: Stringprep profile for user names 2208 and passwords", draft-ietf-sasl-saslprep-01 (work in 2209 progress), May 2003. 2211 [IEEE-802.11i] 2212 Institute of Electrical and Electronics Engineers, 2213 "Unapproved Draft Supplement to Standard for 2214 Telecommunications and Information Exchange Between 2215 Systems - LAN/MAN Specific Requirements - Part 11: 2216 Wireless LAN Medium Access Control (MAC) and Physical 2217 Layer (PHY) Specifications: Specification for Enhanced 2218 Security", IEEE Draft 802.11i (work in progress), 2003. 2220 Authors' Addresses 2222 Larry J. Blunk 2223 Merit Network, Inc 2224 4251 Plymouth Rd., Suite 2000 2225 Ann Arbor, MI 48105-2785 2226 USA 2228 Phone: +1 734-647-9563 2229 Fax: +1 734-647-3185 2230 EMail: ljb@merit.edu 2231 John R. Vollbrecht 2232 Vollbrecht Consulting LLC 2233 9682 Alice Hill Drive 2234 Dexter, MI 48130 2235 USA 2237 Phone: 2238 EMail: jrv@umich.edu 2240 Bernard Aboba 2241 Microsoft Corporation 2242 One Microsoft Way 2243 Redmond, WA 98052 2244 USA 2246 Phone: +1 425 706 6605 2247 Fax: +1 425 936 6605 2248 EMail: bernarda@microsoft.com 2250 James Carlson 2251 Sun Microsystems, Inc 2252 1 Network Drive 2253 Burlington, MA 01803-2757 2254 USA 2256 Phone: +1 781 442 2084 2257 Fax: +1 781 442 1677 2258 EMail: james.d.carlson@sun.com 2260 Henrik Levkowetz 2261 ipUnplugged AB 2262 Arenavagen 33 2263 Stockholm S-121 28 2264 SWEDEN 2266 Phone: +46 8 725 9513 2267 EMail: henrik@levkowetz.com 2269 Appendix A. Method Specific Behavior 2271 A.1 Message Integrity Checks 2273 Today, EAP methods commonly define message integrity checks (MICs) 2274 that cover more than one EAP packet. For example, EAP-TLS [RFC2716] 2275 defines a MIC over a TLS record that could be split into multiple 2276 fragments; within the FINISHED message, the MIC is computed over 2277 previous messages. Where the MIC covers more than one EAP packet, a 2278 MIC validation failure is typically considered a fatal error. 2280 If a per-packet MIC is employed within an EAP method, then peers, 2281 authentication servers, and authenticators not operating in 2282 pass-through mode MUST validate the MIC. MIC validation failures 2283 SHOULD be logged. Whether a MIC validation failure is considered a 2284 fatal error or not is determined by the EAP method specification. 2286 Within EAP-TLS [RFC2716] a MIC validation failure is treated as a 2287 fatal error, since that is what is specified in TLS [RFC2246]. 2288 However, it is also possible to develop EAP methods that support 2289 per-packet MICs, and respond to verification failures by silently 2290 discarding the offending packet. 2292 In this document, descriptions of EAP message handling assume that 2293 per-packet MIC validation, where it occurs, is effectively performed 2294 as though it occurs before sending any responses or changing the 2295 state of the host which received the packet. 2297 Appendix B. Changes from RFC 2284 2299 This section lists the major changes between [RFC2284] and this 2300 document. Minor changes, including style, grammar, spelling and 2301 editorial changes are not mentioned here. 2303 o The Terminology section (Section 1.2) has been expanded, defining 2304 more concepts and giving more exact definitions. 2306 o In Section 2, it is explicitly specified that more than one 2307 exchange of Request and Response packets may occur as part of the 2308 EAP authentication exchange. How this may and may not be used is 2309 specified in detail in Section 2.1. 2311 o Also in Section 2, some requirements on the authenticator when 2312 acting in pass-through mode has been made explicit. 2314 o An EAP multiplexing model (Section 2.2) has been added, to 2315 illustrate a typical implementation of EAP. There is no 2316 requirement that an implementation conforms to this model, as long 2317 as the on-the-wire behavior is consistent with it. 2319 o As EAP is now in use with a variety of lower layers, not just PPP 2320 for which it was first designed, Section 3 on lower layer behavior 2321 has been added. 2323 o In the description of the EAP Request and Response interaction 2324 (Section 4.1), it has been more exactly specified when packets 2325 should be silently discarded, and also the behavior on receiving 2326 duplicate requests. The implementation notes in this section has 2327 been substantially expanded. 2329 o In Section 4.2, it has been clarified that Success and Failure 2330 packets must not contain additional data, and the implementation 2331 note has been expanded. A subsection giving requirements on 2332 processing of success and failure packets has been added. 2334 o Section 5 on EAP Request/Response Types lists two new Type values: 2335 the Expanded Type (Section 5.7), which is used to expand the Type 2336 value number space, and the Experimental Type. In the Expanded 2337 Type number space, the new Expanded Nak (Section 5.3.2) Type has 2338 been added. Clarifications have been made in the description of 2339 most of the existing Types. Security claims summaries have been 2340 added for authentication methods. 2342 o In Section 5.5, support for OTP Extended Responses [RFC2243] has 2343 been added to EAP OTP. 2345 o An IANA Considerations section (Section 6) has been added, giving 2346 registration policies for the numbering spaces defined for EAP. 2348 o The Security Considerations (Section 7) have been greatly 2349 expanded, aiming at giving a much more comprehensive coverage of 2350 possible threats and other security considerations. 2352 o Appendix A has been added on method-specific behavior, providing 2353 guidance on how EAP method-specific integrity checks should be 2354 processed. Where possible, it is desirable for a method-specific 2355 MIC to be computed over the entire EAP packet, including the EAP 2356 layer header (Code, Identifier, Length) and EAP method layer 2357 header (Type, Type-Data). 2359 Appendix C. Open issues 2361 (This section should be removed by the RFC editor before publication) 2363 Open issues relating to this specification are tracked on the 2364 following web site: 2366 http://www.drizzle.com/~aboba/EAP/eapissues.html 2368 The current working documents for this draft are available at this 2369 web site: 2371 http://www.levkowetz.com/pub/ietf/drafts/eap/ 2373 Intellectual Property Statement 2375 The IETF takes no position regarding the validity or scope of any 2376 intellectual property or other rights that might be claimed to 2377 pertain to the implementation or use of the technology described in 2378 this document or the extent to which any license under such rights 2379 might or might not be available; neither does it represent that it 2380 has made any effort to identify any such rights. Information on the 2381 IETF's procedures with respect to rights in standards-track and 2382 standards-related documentation can be found in BCP-11. Copies of 2383 claims of rights made available for publication and any assurances of 2384 licenses to be made available, or the result of an attempt made to 2385 obtain a general license or permission for the use of such 2386 proprietary rights by implementors or users of this specification can 2387 be obtained from the IETF Secretariat. 2389 The IETF invites any interested party to bring to its attention any 2390 copyrights, patents or patent applications, or other proprietary 2391 rights which may cover technology that may be required to practice 2392 this standard. Please address the information to the IETF Executive 2393 Director. 2395 Full Copyright Statement 2397 Copyright (C) The Internet Society (2003). All Rights Reserved. 2399 This document and translations of it may be copied and furnished to 2400 others, and derivative works that comment on or otherwise explain it 2401 or assist in its implementation may be prepared, copied, published 2402 and distributed, in whole or in part, without restriction of any 2403 kind, provided that the above copyright notice and this paragraph are 2404 included on all such copies and derivative works. However, this 2405 document itself may not be modified in any way, such as by removing 2406 the copyright notice or references to the Internet Society or other 2407 Internet organizations, except as needed for the purpose of 2408 developing Internet standards in which case the procedures for 2409 copyrights defined in the Internet Standards process must be 2410 followed, or as required to translate it into languages other than 2411 English. 2413 The limited permissions granted above are perpetual and will not be 2414 revoked by the Internet Society or its successors or assignees. 2416 This document and the information contained herein is provided on an 2417 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2418 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2419 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2420 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2421 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2423 Acknowledgement 2425 Funding for the RFC Editor function is currently provided by the 2426 Internet Society.