idnits 2.17.1 draft-ietf-eap-rfc2284bis-00.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 33 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 1114 has weird spacing: '...pe-Data field...' -- 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 (January 2003) is 7744 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 1673 -- Looks like a reference, but probably isn't: '2' on line 1676 -- Looks like a reference, but probably isn't: '3' on line 1680 -- Looks like a reference, but probably isn't: '4' on line 1683 -- Looks like a reference, but probably isn't: '5' on line 1687 -- Looks like a reference, but probably isn't: '6' on line 1690 -- Looks like a reference, but probably isn't: '7' on line 1403 -- Looks like a reference, but probably isn't: '8' on line 1406 == Unused Reference: 'RFC2401' is defined on line 1775, but no explicit reference was found in the text == Unused Reference: 'IEEE.802-3.1996' is defined on line 1819, 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.1990' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1X.2001' -- 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) == Outdated reference: A later version (-07) exists of draft-ietf-ipsra-pic-06 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 19 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: July 2, 2003 Vollbrecht Consulting LLC 6 B. Aboba 7 Microsoft 8 J. Carlson 9 Sun 10 January 2003 12 Extensible Authentication Protocol (EAP) 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 2, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This document defines the Extensible Authentication Protocol (EAP), 44 an authentication framework which supports multiple authentication 45 mechanisms. EAP typically runs directly over the link layer without 46 requiring IP, but is reliant on lower layer ordering guarantees as in 47 PPP and IEEE 802. EAP does provide its own support for duplicate 48 elimination and retransmission. Fragmentation is not supported 49 within EAP itself; however, individual EAP methods may support this. 51 While EAP was originally developed for use with PPP, it is also now 52 in use with IEEE 802. 54 This document obsoletes RFC 2284. A summary of the changes between 55 this document and RFC 2284 is available in the "Change Log" Appendix. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1 Specification of Requirements . . . . . . . . . . . . . . . 4 61 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Extensible Authentication Protocol (EAP) . . . . . . . . . . 7 63 2.1 Support for sequences . . . . . . . . . . . . . . . . . . . 8 64 2.2 EAP multiplexing model . . . . . . . . . . . . . . . . . . . 9 65 3. Lower layer behavior . . . . . . . . . . . . . . . . . . . . 12 66 3.1 Lower layer requirements . . . . . . . . . . . . . . . . . . 12 67 3.2 EAP usage within PPP . . . . . . . . . . . . . . . . . . . . 13 68 3.3 EAP usage within IEEE 802 . . . . . . . . . . . . . . . . . 14 69 3.4 Link layer indications . . . . . . . . . . . . . . . . . . . 14 70 4. EAP Packet format . . . . . . . . . . . . . . . . . . . . . 15 71 4.1 Request and Response . . . . . . . . . . . . . . . . . . . . 16 72 4.2 Success and Failure . . . . . . . . . . . . . . . . . . . . 19 73 5. Initial EAP Request/Response Types . . . . . . . . . . . . . 21 74 5.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 5.2 Notification . . . . . . . . . . . . . . . . . . . . . . . . 23 76 5.3 Nak . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 5.4 MD5-Challenge . . . . . . . . . . . . . . . . . . . . . . . 25 78 5.5 One-Time Password (OTP) . . . . . . . . . . . . . . . . . . 26 79 5.6 Generic Token Card (GTC) . . . . . . . . . . . . . . . . . . 27 80 5.7 Vendor-specific . . . . . . . . . . . . . . . . . . . . . . 28 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 82 6.1 Definition of Terms . . . . . . . . . . . . . . . . . . . . 30 83 6.2 Recommended Registration Policies . . . . . . . . . . . . . 30 84 7. Security Considerations . . . . . . . . . . . . . . . . . . 31 85 7.1 Threat model . . . . . . . . . . . . . . . . . . . . . . . . 31 86 7.2 Security claims . . . . . . . . . . . . . . . . . . . . . . 32 87 7.3 Identity protection . . . . . . . . . . . . . . . . . . . . 33 88 7.4 Man-in-the-middle attacks . . . . . . . . . . . . . . . . . 33 89 7.5 Packet modification attacks . . . . . . . . . . . . . . . . 34 90 7.6 Dictionary attacks . . . . . . . . . . . . . . . . . . . . . 35 91 7.7 Connection to an untrusted network . . . . . . . . . . . . . 35 92 7.8 Negotiation attacks . . . . . . . . . . . . . . . . . . . . 35 93 7.9 Implementation idiosyncrasies . . . . . . . . . . . . . . . 36 94 7.10 Key derivation . . . . . . . . . . . . . . . . . . . . . . . 36 95 7.11 Weak ciphersuites . . . . . . . . . . . . . . . . . . . . . 38 96 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 38 97 Normative References . . . . . . . . . . . . . . . . . . . . 38 98 Informative References . . . . . . . . . . . . . . . . . . . 39 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 100 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 42 101 B. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 42 102 Intellectual Property and Copyright Statements . . . . . . . 43 104 1. Introduction 106 This document defines the Extensible Authentication Protocol (EAP), 107 an authentication framework which supports multiple authentication 108 mechanisms. EAP typically runs directly over the link layer without 109 requiring IP, but is reliant on lower layer ordering guarantees as in 110 PPP and IEEE 802. EAP does provide its own support for duplicate 111 elimination and retransmission. Fragmentation is not supported 112 within EAP itself; however, individual EAP methods may support this. 114 EAP may be used on dedicated links as well as switched circuits, and 115 wired as well as wireless links. To date, EAP has been implemented 116 with hosts and routers that connect via switched circuits or dial-up 117 lines using PPP [RFC1661]. It has also been implemented with switches 118 and access points using IEEE 802 [IEEE.802.1990]. EAP encapsulation 119 on IEEE 802 wired media is described in [IEEE.802-1X.2001]. 121 One of the advantages of the EAP architecture is its flexibility. 122 EAP is used to select a specific authentication mechanism, typically 123 after the authenticator requests more information in order to 124 determine the specific authentication mechanism(s) to be used. 125 Rather than requiring the authenticator to be updated to support each 126 new authentication method, EAP permits the use of a backend 127 authentication server which may implement some or all authentication 128 methods, with the authenticator acting as a pass-through for some or 129 all methods and users. 131 Within this document, authenticator requirements apply regardless of 132 whether the authenticator is operating as a pass-through or not. 133 Where the requirement is meant to apply to either the authenticator 134 or backend authentication server, depending on where the EAP 135 authentication is terminated, the term "EAP server" will be used. 137 1.1 Specification of Requirements 139 In this document, several words are used to signify the requirements 140 of the specification. These words are often capitalized. The key 141 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 142 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 143 are to be interpreted as described in [RFC2119]. 145 1.2 Terminology 147 This document frequently uses the following terms: 149 authenticator 150 The end of the link requiring the authentication. This 151 terminology is also used in [IEEE.802-1X.2001], and has the 152 same meaning in this document. 154 peer The other end of the point-to-point link (PPP), 155 point-to-point LAN segment (IEEE 802 wired media) or 802.11 156 wireless link, which is being authenticated by the 157 authenticator. In [IEEE.802-1X.2001], this end is known as 158 the Supplicant. 160 backend authentication server 161 A backend authentication server is an entity that provides 162 an authentication service to an authenticator. This service 163 verifies the claim of identity made by the peer from the 164 credentials provided by the peer. This terminology is also 165 used in [IEEE.802-1X.2001]. 167 Displayable Message 168 This is interpreted to be a human readable string of 169 characters, and MUST NOT affect operation of the protocol. 170 The message encoding MUST follow the UTF-8 transformation 171 format [RFC2279]. 173 EAP server 174 The entity that terminates the EAP authentication with the 175 peer. In the case where there is no backend authentication 176 server, this term refers to the authenticator. Where the 177 authenticator operates in pass-through, it refers to the 178 backend authentication server. 180 Silently Discard 181 This means the implementation discards the packet without 182 further processing. The implementation SHOULD provide the 183 capability of logging the event, including the contents of 184 the silently discarded packet, and SHOULD record the event 185 in a statistics counter. 187 Security claims terminology (see Section 7.2): 189 Mutual authentication 190 This refers to an EAP method in which, within an 191 interlocked exchange, the authenticator authenticates the 192 peer and the peer authenticates the authenticator. Two 193 one-way conversations, running in opposite directions do 194 not provide mutual authentication as defined here. 196 Integrity protection 197 This refers to per-packet authentication and integrity 198 protection of EAP packets, including EAP Requests and 199 Responses, and method-specific success and failure 200 indications. When making this claim, a method specification 201 MUST describe the fields within the EAP packet that are 202 protected. 204 Replay protection 205 This refers to protection against replay of EAP messages, 206 including EAP Requests and Responses, and method-specific 207 success and failure indications. 209 Confidentiality 210 This refers to encryption of EAP messages, including EAP 211 Requests and Responses, and method-specific success and 212 failure indications. A method making this claim MUST 213 support identity protection. 215 Key derivation 216 This refers to the ability of the EAP method to derive a 217 Master Key which is not exported, as well as a ciphersuite- 218 independent Master Session Keys. Both the Master Key and 219 Master Session Keys are used only for further key 220 derivation, not directly for protection of the EAP 221 conversation or subsequent data. 223 Key strength 224 This refers to the effective entropy of the derived Master 225 Session Keys, independent of their physical length. For 226 example, a 128-bit key derived from a password might have 227 an effective entropy much less than 128 bits. 229 Dictionary attack resistance 230 Where password authentication is used, users are 231 notoriously prone to select poor passwords. A method may be 232 said to be dictionary attack resistant if, when there is a 233 weak password in the secret, the method does not allow an 234 attack more efficient than brute force. 236 Fast reconnect 237 The ability, in the case where a security association has 238 been previously established, to create a new or refreshed 239 security association in a smaller number of round-trips. 241 Man-in-the-Middle resistance 242 The ability for the peer to demonstrate to the 243 authenticator that it has acted as the peer for each method 244 within the conversation. Similarly, the authenticator 245 demonstrates to the peer that it has acted as the 246 authenticator for each method within the conversation. If 247 this is not possible, then the authentication sequence or 248 tunnel may be vulnerable to a man-in-the-middle attack. 250 Acknowledged result indications 251 The ability of the authenticator to provide the peer with 252 an indication of whether the peer has successfully 253 authenticated to it, and for the peer to acknowledge 254 receipt, as well as providing an indication of whether the 255 authenticator has successfully authenticated to the peer. 256 Since EAP Success and Failure packets are neither 257 acknowledged nor integrity protected, this claim requires 258 implementation of a method- specific result exchange that 259 is integrity protected. 261 2. Extensible Authentication Protocol (EAP) 263 The EAP authentication exchange proceeds as follows: 265 [1] The authenticator sends a Request to authenticate the peer. The 266 Request has a type field to indicate what is being requested. 267 Examples of Request types include Identity, MD5-challenge, etc. 268 The MD5-challenge type corresponds closely to the CHAP 269 authentication protocol [RFC1994]. Typically, the authenticator 270 will send an initial Identity Request; however, an initial 271 Identity Request is not required, and MAY be bypassed. For 272 example, the identity may not be required where it is determined 273 by the port to which the peer has connected (leased lines, 274 dedicated switch or dial-up ports); or where the identity is 275 obtained in another fashion (via calling station identity or MAC 276 address, in the Name field of the MD5-Challenge Response, etc.). 278 [2] The peer sends a Response packet in reply to a valid Request. As 279 with the Request packet the Response packet contains a Type 280 field, which corresponds to the Type field of the Request. 282 [3] The authenticator sends an additional Request packet, and the 283 peer replies with a Response. The sequence of Requests and 284 Responses continues as long as needed. 286 [4] The conversation continues until the authenticator cannot 287 authenticate the peer (unacceptable Responses to one or more 288 Requests), in which case the authenticator implementation MUST 289 transmit an EAP Failure (Code 4). Alternatively, the 290 authentication conversation can continue until the authenticator 291 determines that successful authentication has occurred, in which 292 case the authenticator MUST transmit an EAP Success (Code 3). 294 Since EAP is a peer-to-peer protocol, an independent and simultaneous 295 authentication may take place in the reverse direction. Both peers 296 may act as authenticators and authenticatees at the same time. 298 Advantages 300 The EAP protocol can support multiple authentication mechanisms 301 without having to pre-negotiate a particular one. 303 Devices (e.g. a NAS, switch or access point) do not have to 304 understand each authentication method and MAY act as a 305 pass-through agent for a backend authentication server. Support 306 for pass-through is optional. An authenticator MAY authenticate 307 local users while at the same time acting as a pass-through for 308 non-local users and authentication methods it does not implement 309 locally. 311 For sessions in which the authenticator acts as a pass-through, it 312 MUST determine the outcome of the authentication solely based on 313 the Accept/Reject indication sent by the backend authentication 314 server; the outcome MUST NOT be determined by the contents of an 315 EAP packet sent along with the Accept/Reject indication, or the 316 absence of such an encapsulated EAP packet. 318 Separation of the authenticator from the backend authentication 319 server simplifies credentials management and policy decision 320 making. 322 Disadvantages 324 For use in PPP, EAP does require the addition of a new 325 authentication type to PPP LCP and thus PPP implementations will 326 need to be modified to use it. It also strays from the previous 327 PPP authentication model of negotiating a specific authentication 328 mechanism during LCP. Similarly, switch or access point 329 implementations need to support [IEEE.802-1X.2001] in order to use 330 EAP. 332 Where the authenticator is separate from the backend 333 authentication server, this complicates the security analysis and, 334 if needed, key distribution. 336 2.1 Support for sequences 338 An EAP conversation MAY utilize a sequence of methods. A common 339 example of this is an Identity request followed by a single EAP 340 authentication method such as an MD5-Challenge. However, within or 341 associated with each EAP server, it is not anticipated that a 342 particular named peer will utilize multiple authentication methods 343 (Type 4 or greater), either by supporting a choice of methods or by 344 using multiple methods in sequence. This would make the peer 345 vulnerable to attacks that negotiate the least secure method from 346 among a set (negotiation attacks, described in Section 7.8) or 347 man-in-the-middle attacks (described in Section 7.4). Instead, for 348 each named peer there SHOULD be an indication of exactly one method 349 used to authenticate that peer name. If a peer needs to make use of 350 different authentication methods under different circumstances, then 351 distinct identities SHOULD be employed, each of which identifies 352 exactly one authentication method. If additional authentication 353 methods are required beyond the initial one, the authenticator MAY 354 send a Request packet for a subsequent authentication method, or it 355 MAY send another Identity request. If the peer does not support 356 additional methods, it SHOULD respond with a Nak, indicating no 357 acceptable alternative, as described in Section 5.3. However, peer 358 implementations MAY not respond at all, in which case a timeout will 359 result and authentication will fail. Since the authenticator 360 presumably requires successful completion of the sequence in order to 361 grant access, authentication failure is the correct result. 362 Therefore, it is not necessary for the authenticator to determine 363 that the peer supports sequences prior to sending a Request for a 364 subsequent authentication method. 366 The above prescription also applies in the situation where an 367 authenticator sends a message of a different Type prior to completion 368 of the final round of a given method. If the peer wishes to continue 369 authenticating with the method in progress, it SHOULD send a Nak in 370 response to such a Request, indicating the Type in progress as the 371 alternative. Otherwise it MAY send a Response with the same Type as 372 the Request. Since an EAP packet with a different Type may be sent 373 by an attacker, an authenticator receiving a Nak including a 374 preference for the Type in progress SHOULD log the event, but 375 otherwise not take any action. 377 Once a peer has sent a Response of the same Type as a Request, some 378 existing peer implementations might expect the method to run to 379 completion. As a result, these implementations silently discard EAP 380 Requests of a Type different from the method in progress, despite the 381 requirement for a Response in Section 4.1. For this reason, EAP 382 authenticators that must interoperate with these peers are 383 discouraged from switching methods before the final round of a given 384 method has completed. 386 2.2 EAP multiplexing model 388 Conceptually, EAP implementations consist of the following 389 components: 391 [a] Lower layer. The lower layer is responsible for transmitting and 392 receiving EAP frames between the peer and authenticator. EAP has 393 been run over a variety of lower layers including PPP; wired IEEE 394 802 LANs [IEEE.802-1X.2001]; IEEE 802.11 wireless LANs 395 [IEEE.802-11.1999]; UDP (L2TP [RFC2661] and ISAKMP 396 [I-D.ietf-ipsra-pic]); and TCP [I-D.ietf-ipsra-pic]. Lower layer 397 behavior is discussed in Section 3. 399 [b] EAP layer. The EAP layer receives and transmits EAP packets via 400 the lower layer, implements the EAP state machine, and delivers 401 and receives EAP messages to and from EAP methods. 403 [c] EAP method. EAP methods implement the authentication algorithms 404 and receive and transmit EAP messages via the EAP layer. Since 405 fragmentation support is not provided by EAP itself, this is the 406 responsibility of EAP methods, which are discussed in Section 5. 408 The EAP multiplexing model is illustrated in figure 1 below. Note 409 that there is no requirement that an implementation conform to this 410 model, as long as the on-the-wire behavior is consistent with it. 412 Within EAP, the Type field functions much like a port number in UDP 413 or TCP. With the exception of Types handled by the EAP layer, it is 414 assumed that the EAP layer multiplexes incoming EAP packets according 415 to their Type, and delivers them only to the EAP method corresponding 416 to that Type code, with one exception. 418 Since EAP methods may wish to access the Identity, the Identity 419 Response can be assumed to be stored within the EAP layer so as to be 420 available to methods of Types other than 1 (Identity). The Identity 421 Type is discussed in Section 5.1. 423 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 424 | | | | | | 425 | EAP method| EAP method| | EAP method| EAP method| 426 | Type = X | Type = Y | | Type = X | Type = Y | 427 | ! | | | ^ | | 428 +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ 429 | ! | | ! | 430 | EAP ! Layer | | EAP ! Layer | 431 | ! | | ! | 432 | (Nak, ! Success, | | (Nak, ! Success, | 433 | ! Failure, | | ! Failure, | 434 | ! Notification, | | ! Notification, | 435 | ! Identity) | | ! Identity) | 436 | ! | | ! | 437 +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ 438 | ! | | ! | 439 | Lower ! Layer | | Lower ! Layer | 440 | ! | | ! | 441 +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ 442 ! ! 443 +------------>-------------+ 445 Figure 1: EAP Multiplexing Model 447 A Notification Response is only used as confirmation that the peer 448 received the Notification Request, not that it has processed it, or 449 displayed the message to the user. It cannot be assumed that the 450 contents of the Notification Request or Response is available to 451 another method. The Notification Type is discussed in Section 5.2. 453 The Nak method is utilized for the purposes of method negotiation. 454 Peers MUST respond to an EAP Request for an unacceptable Type with a 455 Nak Response. It cannot be assumed that the contents of the Nak 456 Response is available to another method. The Nak Type is discussed 457 in Section 5.3. 459 EAP packets with codes of Success or Failure do not include a Type, 460 and therefore are not delivered to an EAP method. Success and Failure 461 are discussed in Section 4.2. 463 Given these considerations, the Success, Failure, Nak Response and 464 Notification Request/Response messages MUST NOT used to carry data 465 destined for delivery to EAP authentication Types (4 or greater). 467 3. Lower layer behavior 469 3.1 Lower layer requirements 471 EAP makes the following assumptions about lower layers: 473 [1] Lower layer CRC or checksum is not necessary. In EAP, the 474 authenticator retransmits Requests that have not yet received 475 Responses, so that EAP does not assume that lower layers are 476 reliable. Since EAP defines its own retransmission behavior, 477 when run over a reliable lower layer, it is possible (though 478 undesirable) for retransmission to occur both in the lower layer 479 and the EAP layer. 481 If lower layers exhibit a high loss rate, then retransmissions 482 are likely, and since EAP Success and Failure are not 483 retransmitted, timeouts are also likely to result. EAP methods 484 such as EAP TLS [RFC2716] include a message integrity check (MIC) 485 and regard MIC errors as fatal. Therefore if a checksum or CRC is 486 not provided by the lower layer, then some methods may not behave 487 well. 489 [2] Lower layer data security. After EAP authentication is complete, 490 the peer will typically transmit data to the network, through the 491 authenticator. In order to provide assurance that the peer 492 transmitting data is the one that successfully completed EAP 493 authentication, it is necessary for the lower layer to provide 494 per- packet integrity, authentication and replay protection that 495 is bound to the original EAP authentication, or for the lower 496 layer to be physically secure. Otherwise it is possible for 497 subsequent data traffic to be hijacked, or replayed. 499 As a result of these considerations, EAP SHOULD be used only when 500 lower layers provide physical security for data (e.g. wired PPP 501 or IEEE 802 links), or for insecure links, where per-packet 502 authentication, integrity and replay protection is provided. 503 Where keying material for the lower layer ciphersuite is itself 504 provided by EAP, typically the lower layer ciphersuite cannot be 505 enabled until late in the EAP conversation, after key derivation 506 has completed. Thus it may only be possible to use the lower 507 layer ciphersuite to protect a portion of the EAP conversation, 508 such as the EAP Success or Failure packet. 510 [3] Known MTU. The EAP layer does not support fragmentation and 511 reassembly. However, EAP methods SHOULD be capable of handling 512 fragmentation and reassembly. As a result, EAP is capable of 513 functioning across a range of MTU sizes, as long as the MTU is 514 known. 516 [4] Possible duplication. Where the lower layer is reliable, it will 517 provide the EAP layer with a non-duplicated stream of packets. 518 However, while it is desirable that lower layers provide for non- 519 duplication, this is not a requirement. The Identifier field 520 provides both the peer and authenticator with the ability to 521 detect duplicates. 523 [5] Ordering guarantees. EAP does not require the Identifier to be 524 monotonically increasing, and so is reliant on lower layer 525 ordering guarantees for correct operation. Also, EAP was 526 originally defined to run on PPP, and [RFC1661] Section 1 has an 527 ordering requirement: 529 "The Point-to-Point Protocol is designed for simple links which 530 transport packets between two peers. These links provide full- 531 duplex simultaneous bi-directional operation, and are assumed to 532 deliver packets in order." 534 Lower lower transports for EAP MUST preserve ordering between a 535 source and destination, at a given priority level (the level of 536 ordering guarantee provided by [IEEE.802.1990]). 538 3.2 EAP usage within PPP 540 In order to establish communications over a point-to-point link, each 541 end of the PPP link must first send LCP packets to configure the data 542 link during Link Establishment phase. After the link has been 543 established, PPP provides for an optional Authentication phase before 544 proceeding to the Network-Layer Protocol phase. 546 By default, authentication is not mandatory. If authentication of the 547 link is desired, an implementation MUST specify the Authentication- 548 Protocol Configuration Option during Link Establishment phase. 550 If the identity of the peer has been established in the 551 Authentication phase, the server can use that identity in the 552 selection of options for the following network layer negotiations. 554 When implemented within PPP, EAP does not select a specific 555 authentication mechanism at PPP Link Control Phase, but rather 556 postpones this until the Authentication Phase. This allows the 557 authenticator to request more information before determining the 558 specific authentication mechanism. This also permits the use of a 559 "back-end" server which actually implements the various mechanisms 560 while the PPP authenticator merely passes through the authentication 561 exchange. The PPP Link Establishment and Authentication phases, and 562 the Authentication-Protocol Configuration Option, are defined in The 563 Point-to-Point Protocol (PPP) [RFC1661]. 565 3.2.1 PPP Configuration Option Format 567 A summary of the PPP Authentication-Protocol Configuration Option 568 format to negotiate the EAP Authentication Protocol is shown below. 569 The fields are transmitted from left to right. 571 Exactly one EAP packet is encapsulated in the Information field of a 572 PPP Data Link Layer frame where the protocol field indicates type hex 573 C227 (PPP EAP). 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type | Length | Authentication-Protocol | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Type 582 3 584 Length 585 4 587 Authentication-Protocol 588 C227 (Hex) for PPP Extensible Authentication Protocol (EAP) 590 3.3 EAP usage within IEEE 802 592 The encapsulation of EAP over IEEE 802 is defined in 593 [IEEE.802-1X.2001]. The IEEE 802 encapsulation of EAP does not 594 involve PPP, and IEEE 802.1X does not include support for link or 595 network layer negotiations. As a result, within IEEE 802.1X it is not 596 possible to negotiate non-EAP authentication mechanisms, such as PAP 597 or CHAP [RFC1994]. 599 3.4 Link layer indications 601 The reliability and security of link layer indications is dependent 602 on the medium. Link layer failure indications accepted by the link 603 layer and provided to EAP MUST be processed. However, link layer 604 success indications MUST NOT result in an EAP implementation 605 concluding that authentication has succeeded, since these indications 606 are typically unauthenticated. 608 In PPP, link layer indications are not authenticated and are 609 therefore subject to spoofing, provided that the attacker can gain 610 access to the physical medium. This includes LCP-Terminate (a link 611 failure indication), NCP (a link success indication), and "link down" 612 (a link failure indication). 614 In IEEE 802 wired networks, the IEEE 802.1X EAPOL-Start and 615 EAPOL-Logoff frames are not authenticated or integrity protected, 616 whereas within 802.11, authentication and integrity protection is 617 possible depending on when they are sent and the ciphersuite that has 618 been negotiated. Therefore, depending on the circumstances, 619 EAPOL-Start and EAPOL-Logoff frames may or may not be authenticated 620 and integrity protected. 622 In 802.11 a "link down" indication is an unreliable indication of 623 link failure, since wireless signal strength can come and go and may 624 be influenced by radio frequency interference generated by an 625 attacker. In 802.11, control and management frames are not 626 authenticated and an attacker within range can gain access to the 627 physical medium. Link layer indications include Disassociate and 628 Deauthenticate frames (link failure indications), and Association and 629 Reassociation Response frames (link success indications). 631 4. EAP Packet format 633 A summary of the EAP packet format is shown below. The fields are 634 transmitted from left to right. 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Code | Identifier | Length | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Data ... 642 +-+-+-+-+ 644 Code 645 The Code field is one octet and identifies the type of EAP packet. 646 EAP Codes are assigned as follows: 648 1 Request 649 2 Response 650 3 Success 651 4 Failure 652 Since EAP only defines Codes 1-4, EAP packets with other codes 653 MUST be silently discarded by both authenticators and peers. 655 Identifier 656 The Identifier field is one octet and aids in matching Responses 657 with Requests. 659 Length 660 The Length field is two octets and indicates the length of the EAP 661 packet including the Code, Identifier, Length and Data fields. 662 Octets outside the range of the Length field should be treated as 663 Data Link Layer padding and should be ignored on reception. 665 Data 666 The Data field is zero or more octets. The format of the Data 667 field is determined by the Code field. 669 4.1 Request and Response 671 Description 672 The Request packet (Code field set to 1) MUST be sent by the 673 authenticator to the peer; the peer MUST NOT send Request packets 674 to the authenticator. Each Request has a Type field which serves 675 to indicate what is being requested. Additional Request packets 676 MUST be sent until a valid Response packet is received, or an 677 optional retry counter expires. In [IEEE.802-1X.2001], the retry 678 counter is effectively set to zero, so that retransmission never 679 occurs, and instead the peer times out and authentication is 680 restarted. 682 Retransmitted Requests MUST be sent with the same Identifier value 683 in order to distinguish them from new Requests. The contents of 684 the data field is dependent on the Request type. The peer MUST 685 send a Response packet in reply to a valid Request packet. 686 Responses MUST only be sent in reply to a valid Request and never 687 retransmitted on a timer. 689 The Identifier field of the Response MUST match that of the 690 Request; if it does not match, then the Response MUST be silently 691 discarded. Authenticators receiving a Response for which the 692 authenticator has no outstanding Request MUST silently discard the 693 Response. 695 The authenticator MUST NOT send a new Request until a valid 696 Response is received to an outstanding Request. Since the 697 authenticator can retransmit before receiving a valid Response 698 from the peer, the authenticator can receive duplicate Responses. 700 The authenticator MUST silently discard these duplicate Responses. 702 If a Message Integrity Check (MIC) is employed within an EAP 703 method, then implementations MUST silently discard any message 704 that fails this check. In this document, the descriptions of EAP 705 message handling assume that MIC validation is effectively 706 performed as though it occurs before examining any of the EAP 707 message fields (such as 'Code'). 709 Implementation Note: These obligations apply regardless of 710 whether or not pass-through is implemented. The authenticator 711 is responsible for retransmitting Request messages. If the 712 Request message is obtained from elsewhere (such as from a 713 backend authentication server), then the authenticator will 714 need to save a copy of the Request in order to accomplish this. 715 The authenticator is also responsible for discarding Response 716 messages with the wrong Identifier value before acting on them 717 in any way, including passing them on to the backend 718 authentication server for verification. Similarly, the peer is 719 responsible for detecting and handling duplicate Request 720 messages before processing them in any way, including passing 721 them on to an outside party. 723 Because the authentication process will often involve user 724 input, some care must be taken when deciding upon 725 retransmission strategies and authentication timeouts. By 726 default, where EAP is run over an unreliable lower layer, the 727 EAP retransmission timer SHOULD be computed as described in 728 [RFC2988]. This includes use of Karn's algorithm to filter RTT 729 estimates resulting from retransmissions. A maximum of 3-5 730 retransmissions is suggested. 732 When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, 733 as within [I-D.ietf-ipsra-pic]), the EAP retransmission timer 734 SHOULD be set to an infinite value, so that retransmissions do 735 not occur at the EAP layer. 737 Where the authentication process requires user input, the 738 measured round trip times are largely determined by user 739 responsiveness rather than network characteristics, so that RTO 740 estimation is not helpful. Instead, the retransmission timer 741 SHOULD be set so as to provide sufficient time for the user to 742 respond, with longer timeouts required in certain cases, such 743 as where Token Cards (see Section 5.6) are involved. 745 In order to provide the EAP authenticator with guidance as to 746 the appropriate timeout value, a hint can be communicated to 747 the authenticator by the backend authentication server (such as 748 via the RADIUS Session-Timeout attribute). 750 A summary of the Request and Response packet format is shown below. 751 The fields are transmitted from left to right. 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Code | Identifier | Length | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Type | Type-Data ... 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 761 Code 763 1 for Request 764 2 for Response 766 Identifier 767 The Identifier field is one octet. The Identifier field MUST be 768 the same if a Request packet is retransmitted due to a timeout 769 while waiting for a Response. Any new (non-retransmission) 770 Requests MUST modify the Identifier field. In order to avoid 771 confusion between new Requests and retransmissions, the Identifier 772 value chosen for each new Request need only be different from the 773 previous Request, but need not be unique within the conversation. 774 One way to achieve this is to start the Identifier at an initial 775 value and increment it for each new Request. Initializing the 776 first Identifier with a random number rather than starting from 777 zero is recommended, since it makes sequence attacks somewhat 778 harder. 780 Since the Identifier space is unique to each session, 781 authenticators are not restricted to only 256 simultaneous 782 authentication conversations. Similarly, with re-authentication, 783 an EAP conversation might continue over a long period of time, and 784 is not limited to only 256 roundtrips. 786 If a peer receives a valid duplicate Request for which it has 787 already sent a Response, it MUST resend its original Response. If 788 a peer receives a duplicate Request before it has sent a Response, 789 but after it has determined the initial Request to be valid (i.e. 790 it is waiting for user input), it MUST silently discard the 791 duplicate Request. An EAP message may be found invalid for a 792 variety of reasons: failed lower layer CRC or checksum, malformed 793 EAP packet, EAP method MIC failure, etc. 795 Length 796 The Length field is two octets and indicates the length of the EAP 797 packet including the Code, Identifier, Length, Type, and Type-Data 798 fields. Octets outside the range of the Length field should be 799 treated as Data Link Layer padding and should be ignored on 800 reception. 802 Type 803 The Type field is one octet. This field indicates the Type of 804 Request or Response. A single Type MUST be specified for each EAP 805 Request or Response. Normally, the Type field of the Response 806 will be the same as the Type of the Request. However, there is 807 also a Nak Response Type for indicating that a Request type is 808 unacceptable to the peer. An initial specification of Types 809 follows in a later section of this document. 811 Type-Data 812 The Type-Data field varies with the Type of Request and the 813 associated Response. 815 4.2 Success and Failure 817 The Success packet is sent by the authenticator to the peer to 818 acknowledge successful authentication. The authenticator MUST 819 transmit an EAP packet with the Code field set to 3 (Success). If 820 the authenticator cannot authenticate the peer (unacceptable 821 Responses to one or more Requests) then the implementation MUST 822 transmit an EAP packet with the Code field set to 4 (Failure). An 823 authenticator MAY wish to issue multiple Requests before sending a 824 Failure response in order to allow for human typing mistakes. Success 825 and Failure packets MUST NOT contain additional data. 827 Implementation Note: Because the Success and Failure packets are 828 not acknowledged, the authenticator cannot know whether they have 829 been received. As a result, these packets are not retransmitted by 830 the authenticator, and if they are lost, the peer will timeout. If 831 acknowledged success and failure indications are desired, these 832 MAY be implemented within individual EAP methods. 834 A summary of the Success and Failure packet format is shown below. 835 The fields are transmitted from left to right. 837 0 1 2 3 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Code | Identifier | Length | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 Code 845 3 for Success 846 4 for Failure 848 Identifier 849 The Identifier field is one octet and aids in matching replies to 850 Responses. The Identifier field MUST match the Identifier field 851 of the Response packet that it is sent in response to. 853 Length 854 4 856 4.2.1 Processing of success and failure 858 Within EAP, success and failure indications consist of the EAP 859 Success and Failure messages, as well as method-specific indications. 860 Within EAP, these indications may be protected or unprotected. 862 EAP Success and Failure packets are considered unprotected 863 indications which may be spoofed, since as described in Section 4.2, 864 they contain no message integrity check (MIC). 866 In order to provide additional protection against tampering, EAP 867 methods MAY support a MIC that covers some or all of the EAP packet, 868 including headers. In addition, such a MIC MAY include coverage of 869 previous Request and Response messages, so as to enable protection of 870 other packets to that do not contain MICs, such as Identity Request/ 871 Response, Notification Request/Response and Nak Response. 873 EAP methods also MAY include support for method-specific acknowledged 874 success and failure indications. This enables the authenticator to 875 indicate whether the peer has successfully authenticated, as well as 876 for the peer to acknowledge receipt of that indication, and respond 877 with an indication of whether the authenticator has successfully 878 authenticated to the peer. If a key has previously been derived, the 879 result exchange MAY be protected by a Message Integrity Check (MIC), 880 and if so, then this success/failure indication is considered 881 protected. 883 In order to decrease vulnerability to spoofing of success and failure 884 indications, the following processing rules are recommended: 886 [a] Processing of protected success and failure indications. Where a 887 method-specific protected success/failure indication has been 888 received, the implementation MUST validate the EAP method MIC, 889 with a MIC failure handled via silent discard, as specified in 890 Section 4.1. 892 [b] Receipt of EAP Success and Failure packets prior to method 893 completion. A peer EAP implementation receiving an EAP Success 894 packet prior to completion of the method in progress MUST 895 silently discard it. This ensures that a rogue authenticator will 896 not be able to bypass mutual authentication by sending an EAP 897 Success prior to conclusion of the EAP method conversation. A 898 peer EAP implementation receiving an EAP Failure packet prior to 899 completion of the method in progress MAY silently discard it. 900 When using EAP methods that provide their own (protected) error 901 indications, premature EAP Failure packets are unexpected, so 902 that this technique may be more readily employed. 904 [c] Authentication requirement. An EAP peer implementation that has 905 been configured to require authentication MUST silently discard a 906 "canned" EAP Success message (an EAP Success message sent 907 immediately upon connection). 909 [d] Contradictory indications. Where protected and unprotected result 910 indications are both available, protected indications take 911 precedence. For example, where an EAP method provides a 912 protected indication that authentication failure has occurred in 913 either direction, the implementation MUST silently discard 914 subsequent EAP Success packets. Similarly, where an EAP method 915 provides a protected indication that authentication has succeeded 916 in both directions, the EAP implementation MAY silently discard 917 EAP Failure packets. 919 [e] Processing of EAP Success and Failure in the absence of protected 920 indications. Subsequent to the completion of the EAP 921 authentication method (Types 4 and greater), and in the absence 922 of protected result indications, EAP Success and Failure packets 923 MUST be accepted and processed by the EAP implementation. 925 5. Initial EAP Request/Response Types 927 This section defines the initial set of EAP Types used in Request/ 928 Response exchanges. More Types may be defined in follow-on 929 documents. The Type field is one octet and identifies the structure 930 of an EAP Request or Response packet. The first 3 Types are 931 considered special case Types. 933 The remaining Types define authentication exchanges. The Nak Type is 934 valid only for Response packets, it MUST NOT be sent in a Request. 935 The Nak Type MUST only be sent in response to a Request which uses an 936 authentication Type code (i.e., Type of 4 or greater). 938 All EAP implementations MUST support Types 1-4, which are defined in 939 this document, and SHOULD support Type 254. Follow-on RFCs MAY define 940 additional EAP Types. 942 1 Identity 943 2 Notification 944 3 Nak (Response only) 945 4 MD5-Challenge 946 5 One Time Password (OTP) 947 6 Generic Token Card (GTC) 948 254 Vendor-specific 949 255 Experimental use 951 5.1 Identity 953 Description 954 The Identity Type is used to query the identity of the peer. 955 Generally, the authenticator will issue this as the initial 956 Request. An optional displayable message MAY be included to prompt 957 the peer in the case where there expectation of interaction with a 958 user. A Response of Type 1 (Identity) SHOULD be sent in Response 959 to a Request with a Type of 1 (Identity). 961 Since Identity Requests and Responses are not protected, from a 962 security perspective, it may be preferable for protected method- 963 specific Identity exchanges to be used instead. 965 Implementation Note: The peer MAY obtain the Identity via user 966 input. It is suggested that the authenticator retry the 967 Identity Request in the case of an invalid Identity or 968 authentication failure to allow for potential typos on the part 969 of the user. It is suggested that the Identity Request be 970 retried a minimum of 3 times before terminating the 971 authentication phase with a Failure reply. The Notification 972 Request MAY be used to indicate an invalid authentication 973 attempt prior to transmitting a new Identity Request 974 (optionally, the failure MAY be indicated within the message of 975 the new Identity Request itself). 977 Type 978 1 980 Type-Data 981 This field MAY contain a displayable message in the Request, 982 containing UTF-8 encoded ISO 10646 characters [RFC2279]. The 983 Response uses this field to return the Identity. If the Identity 984 is unknown, this field should be zero bytes in length. The field 985 MUST NOT be null terminated. The length of this field is derived 986 from the Length field of the Request/Response packet and hence a 987 null is not required. 989 5.2 Notification 991 Description 992 The Notification Type is optionally used to convey a displayable 993 message from the authenticator to the peer. An authenticator MAY 994 send a Notification Request to the peer at any time. The peer MUST 995 respond to a Notification Request with a Notification Response; a 996 Nak Response MUST NOT be sent. 998 The peer SHOULD display this message to the user or log it if it 999 cannot be displayed. The Notification Type is intended to provide 1000 an acknowledged notification of some imperative nature, but it is 1001 not an error indication, and therefore does not change the state 1002 of the peer. Examples include a password with an expiration time 1003 that is about to expire, an OTP sequence integer which is nearing 1004 0, an authentication failure warning, etc. In most circumstances, 1005 Notification should not be required. 1007 Type 1008 2 1010 Type-Data 1011 The Type-Data field in the Request contains a displayable message 1012 greater than zero octets in length, containing UTF-8 encoded ISO 1013 10646 characters [RFC2279]. The length of the message is 1014 determined by Length field of the Request packet. The message 1015 MUST NOT be null terminated. A Response MUST be sent in reply to 1016 the Request with a Type field of 2 (Notification). The Type-Data 1017 field of the Response is zero octets in length. The Response 1018 should be sent immediately (independent of how the message is 1019 displayed or logged). 1021 5.3 Nak 1023 Description 1024 The Nak Type is valid only in Response messages. It is sent in 1025 reply to a Request where the desired authentication Type is 1026 unacceptable. Authentication Types are numbered 4 and above. The 1027 Response contains one or more authentication Types desired by the 1028 Peer. Type zero (0) is used to indicate that the sender has no 1029 viable alternatives. 1031 Since the Nak Type is only valid in Responses and has very limited 1032 functionality, it MUST NOT be used as a general purpose error 1033 indication, such as for communication of error messages, or 1034 negotiation of parameters specific to a particular EAP method. 1036 Code 1037 2 for Response. 1039 Identifier 1040 The Identifier field is one octet and aids in matching Responses 1041 with Requests. The Identifier field of a Nak Response MUST match 1042 the Identifier field of the Request packet that it is sent in 1043 response to. 1045 Length 1046 >=6 1048 Type 1049 3 1051 Type-Data 1052 Where the Request contains a Type within the original EAP Type 1053 space (1-253, 255), or the Request contains an expanded Type as 1054 defined in Section 5.7, but the peer does not support expanded 1055 Types, then the Type-Data field of the Nak Response MUST contain 1056 one or more octets indicating the desired authentication Type(s), 1057 one octet per Type, or the value zero (0) to indicate no proposed 1058 alternative. When the Nak Response includes as one of the Type(s) 1059 the value 254, this indicates an expanded Type of preference 1060 indicated by the relative order. If the authenticator can 1061 accomodate this preference, it will respond with a an expanded 1062 Type Request. 1064 If a peer supporting expanded Types receives an expanded Type 1065 Request, then the Type-Data field of the Nak Response, if sent, 1066 MUST contain one or more authentication Types, all of which MUST 1067 be in the format below (8 octets per Type). This includes the 1068 encoding of zero (0) in the Vendor-Type field, to indicate no 1069 proposed alternative. See Section 5.7 for details on the Vendor-Id 1070 and Vendor-Type fields. If the peer does not support expanded 1071 Types, then the Type-Data field of the Nak Response MUST contain 1072 one or more authentication Type(s), one octet per Type, or the 1073 value zero (0) to indicate no proposed alternative. However, the 1074 value 254 MUST NOT be included as one of the preferred 1075 authentication Types. 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Type=254 | Vendor-Id | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Vendor-Type | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 5.4 MD5-Challenge 1087 Description 1088 The MD5-Challenge Type is analogous to the PPP CHAP protocol 1089 [RFC1994] (with MD5 as the specified algorithm). The Request 1090 contains a "challenge" message to the peer. A Response MUST be 1091 sent in reply to the Request. The Response MAY be either of Type 1092 4 (MD5-Challenge) or Type 3 (Nak). The Nak reply indicates the 1093 peer's desired authentication Type(s). EAP peer and EAP server 1094 implementations MUST support the MD5-Challenge mechanism. An 1095 authenticator that supports only pass-through MUST allow 1096 communication with a backend authentication server that is capable 1097 of supporting MD5-Challenge, although the EAP authenticator 1098 implementation need not support MD5-Challenge itself. However, if 1099 the EAP authenticator can be configured to authenticate peers 1100 locally (e.g. not operate in pass-through), then the requirement 1101 for support of the MD5-Challenge mechanism applies. 1103 Note that the use of the Identifier field in the MD5-Challenge 1104 Type is different from that described in [RFC1994]. EAP allows 1105 for retransmission of MD5-Challenge Request packets while 1106 [RFC1994] states that both the Identifier and Challenge fields 1107 MUST change each time a Challenge (the CHAP equivalent of the 1108 MD5-Challenge Request packet) is sent. 1110 Type 1111 4 1113 Type-Data 1114 The contents of the Type-Data field is summarized below. For 1115 reference on the use of these fields see the PPP Challenge 1116 Handshake Authentication Protocol [RFC1994]. 1118 0 1 2 3 1119 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 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Value-Size | Value ... 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Name ... 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 Security Claims ) (see Section 7.2): 1128 Intended use: Wired networks, including PPP, PPPOE, and 1129 IEEE 802 wired media. Use over the 1130 Internet or with wireless media only when 1131 protected. 1132 Mechanism: Password or pre-shared key. 1133 Mutual authentication: No 1134 Integrity protection: No 1135 Replay protection: No 1136 Confidentiality: No 1137 Key Derivation: No 1138 Key strength: N/A 1139 Dictionary attack prot: No 1140 Key hierarchy: N/A 1141 Fast reconnect: No 1142 MiTM resistance: No 1143 Acknowledged S/F: No 1145 5.5 One-Time Password (OTP) 1147 Description 1148 The One-Time Password system is defined in "A One-Time Password 1149 System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The 1150 Request contains a displayable message containing an OTP 1151 challenge. A Response MUST be sent in reply to the Request. The 1152 Response MUST be of Type 5 (OTP) or Type 3 (Nak). The Nak 1153 Response indicates the peer's desired authentication Type(s). 1155 Type 1156 5 1158 Type-Data 1159 The Type-Data field contains the OTP "challenge" as a displayable 1160 message in the Request. In the Response, this field is used for 1161 the 6 words from the OTP dictionary [RFC2289]. The messages MUST 1162 NOT be null terminated. The length of the field is derived from 1163 the Length field of the Request/Reply packet. 1165 Security Claims (see Section 7.2): 1167 Intended use: Wired networks, including PPP, PPPOE, and 1168 IEEE 802 wired media. Use over the 1169 Internet or with wireless media only when 1170 protected. 1171 Mechanism: One-Time Password 1172 Mutual authentication: No 1173 Integrity protection: No 1174 Replay protection: No 1175 Confidentiality: No 1176 Key Derivation: No 1177 Key strength: N/A 1178 Dictionary attack prot: No 1179 Key hierarchy: N/A 1180 Fast reconnect: No 1181 MiTM resistance: No 1182 Acknowledged S/F: No 1184 5.6 Generic Token Card (GTC) 1186 Description 1187 The Generic Token Card Type is defined for use with various Token 1188 Card implementations which require user input. The Request 1189 contains a displayable message and the Response contains the Token 1190 Card information necessary for authentication. Typically, this 1191 would be information read by a user from the Token card device and 1192 entered as ASCII text. A Response MUST be sent in reply to the 1193 Request. The Response MUST be of Type 6 (GTC) or Type 3 (Nak). 1194 The Nak Response indicates the peer's desired authentication 1195 Type(s). 1197 Type 1198 6 1200 Type-Data 1201 The Type-Data field in the Request contains a displayable message 1202 greater than zero octets in length. The length of the message is 1203 determined by the Length field of the Request packet. The message 1204 MUST NOT be null terminated. A Response MUST be sent in reply to 1205 the Request with a Type field of 6 (Generic Token Card). The 1206 Response contains data from the Token Card required for 1207 authentication. The length of the data is determined by the 1208 Length field of the Response packet. 1210 Security Claims (see Section 7.2): 1212 Intended use: Wired networks, including PPP, PPPOE, and 1213 IEEE 802 wired media. Use over the 1214 Internet or with wireless media only when 1215 protected. 1216 Mechanism: Hardware token. 1217 Mutual authentication: No 1218 Integrity protection: No 1219 Replay protection: No 1220 Confidentiality: No 1221 Key Derivation: No 1222 Key strength: N/A 1223 Dictionary attack prot: No 1224 Key hierarchy: N/A 1225 Fast reconnect: No 1226 MiTM resistance: No 1227 Acknowledged S/F: No 1229 5.7 Vendor-specific 1231 Description 1232 Due to EAP's popularity, the original Method Type space, which 1233 only provides for 255 values, is being allocated at a pace, which 1234 if continued, would result in exhaustion within a few years. Since 1235 many of the existing uses of EAP are vendor-specific, the 1236 Vendor-Specific Method Type is available to allow vendors to 1237 support their own extended Types not suitable for general usage. 1239 The Vendor-specific type is also used to expand the global Method 1240 Type space beyond the original 255 values. A Vendor-Id of 0 maps 1241 the original 255 possible types onto a namespace of 2^32-1 1242 possible types, allowing for virtually unlimited expansion. (Type 1243 0 is only used in a Nak Response, to indicate no acceptable 1244 alternative) 1246 An implementation that supports the Vendor-specific attribute MUST 1247 treat EAP types that are less than 256 equivalently whether they 1248 appear as a single octet or as the 32-bit Vendor-Type within a 1249 Vendor-specific type where Vendor-Id is 0. Peers not equipped to 1250 interpret the Vendor-specific Type MUST send a Nak as described in 1251 Section 5.3, and negotiate a more suitable authentication method. 1253 A summary of the Vendor-specific Type format is shown below. The 1254 fields are transmitted from left to right. 1256 0 1 2 3 1257 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 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Type | Vendor-Id | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Vendor-Type | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Vendor data... 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 Type 1267 254 for Vendor-specific 1269 Vendor-Id 1270 The Vendor-Id is 3 octets and represents the SMI Network 1271 Management Private Enterprise Code of the Vendor in network byte 1272 order, as allocated by IANA. A Vendor-Id of zero is reserved for 1273 use by the IETF in providing an expanded global EAP Type space. 1275 Vendor-Type 1276 The Vendor-Type field is four octets and represents the vendor- 1277 specific Method Type. 1279 If Vendor-Id is zero, the Vendor-Type field is an extension and 1280 superset of the existing namespace for EAP types. The first 256 1281 types are reserved for compatibility with single-octet EAP types 1282 that have already been assigned or may be assigned in the future. 1283 Thus, EAP types from 0 through 255 are semantically identical 1284 whether they appear as single octet EAP types or as Vendor-Types 1285 when Vendor-Id is zero. 1287 Vendor-Data 1288 The Vendor-Data field is defined by the vendor. Where a Vendor-Id 1289 of zero is present, the Vendor-Data field will be used for 1290 transporting the contents of EAP methods of Types defined by the 1291 IETF. 1293 6. IANA Considerations 1295 This section provides guidance to the Internet Assigned Numbers 1296 Authority (IANA) regarding registration of values related to the EAP 1297 protocol, in accordance with BCP 26, [RFC2434]. 1299 There are two name spaces in EAP that require registration: Packet 1300 Codes and Method Types. 1302 EAP is not intended as a general-purpose protocol, and allocations 1303 SHOULD NOT be made for purposes unrelated to authentication. 1305 6.1 Definition of Terms 1307 The following terms are used here with the meanings defined in BCP 1308 26: "name space", "assigned value", "registration". 1310 The following policies are used here with the meanings defined in BCP 1311 26: "Private Use", "First Come First Served", "Expert Review", 1312 "Specification Required", "IETF Consensus", "Standards Action". 1314 6.2 Recommended Registration Policies 1316 For registration requests where a Designated Expert should be 1317 consulted, the responsible IESG area director should appoint the 1318 Designated Expert. For Designated Expert with Specification Required, 1319 the request is posted to the EAP WG mailing list (or, if it has been 1320 disbanded, a successor designated by the Area Director) for comment 1321 and review, and MUST include a pointer to a public specification. 1322 Before a period of 30 days has passed, the Designated Expert will 1323 either approve or deny the registration request and publish a notice 1324 of the decision to the EAP WG mailing list or its successor. A denial 1325 notice must be justified by an explanation and, in the cases where it 1326 is possible, concrete suggestions on how the request can be modified 1327 so as to become acceptable. 1329 For registration requests requiring Expert Review, the EAP mailing 1330 list should be consulted. If the EAP mailing list is no longer 1331 operational, an alternative mailing list may be designated by the 1332 responsible IESG Area Director. 1334 Packet Codes have a range from 1 to 255, of which 1-4 have been 1335 allocated. Because a new Packet Code has considerable impact on 1336 interoperability, a new Packet Code requires Standards Action, and 1337 should be allocated starting at 5. 1339 The original EAP Method Type space has a range from 1 to 255, and is 1340 the scarcest resource in EAP, and thus must be allocated with care. 1341 Method Types 1-36 have been allocated, with 20 available for re-use. 1342 Method Types 37-191 may be allocated on the advice of a Designated 1343 Expert, with Specification Required. 1345 Allocation of blocks of Method Types (more than one for a given 1346 purpose) should require IETF Consensus. EAP Type Values 192-253 are 1347 reserved and allocation requires Standards Action. 1349 Method Type 254 is allocated for the Vendor-Specific Type. Where the 1350 Vendor-Id field is non-zero, the Vendor-Specific Type is used for 1351 functions specific only to one vendor's implementation of EAP, where 1352 no interoperability is deemed useful. When used with a Vendor-Id of 1353 zero, Method Type 254 can also be used to provide for an expanded 1354 Method Type space. Method Type values 256-4294967295 may be 1355 allocated after Type values 1-191 have been allocated. 1357 Method Type 255 is allocated for Experimental use, such as testing of 1358 new EAP methods before a permanent Type code is allocated. 1360 7. Security Considerations 1362 EAP was designed for use with dialup PPP [RFC1661] and was later 1363 adapted for use in wired IEEE 802 networks [IEEE.802.1990] in 1364 [IEEE.802-1X.2001]. On these networks, an attacker would need to 1365 gain physical access to the telephone or switch infrastructure in 1366 order to mount an attack. While such attacks have been documented, 1367 such as in [DECEPTION], they are assumed to be rare. 1369 However, subsequently EAP has been proposed for use on wireless 1370 networks, and over the Internet, where physical security cannot be 1371 assumed. On such networks, the security vulnerabilities are greater, 1372 as are the requirements for EAP security. 1374 This section defines the threat model and security terms and 1375 describes the security claims section required in EAP method 1376 specifications. We then discuss threat mitigation. 1378 7.1 Threat model 1380 On physically insecure networks, it is possible for an attacker to 1381 gain access to the physical medium. This enables a range of attacks, 1382 including the following: 1384 [1] An adversary may try to discover user identities by snooping 1385 authentication traffic. 1387 [2] An adversary may try to modify or spoof EAP packets. 1389 [3] An adversary may launch denial of service attacks by spoofing 1390 layer 2 indications or EAP layer success/failure indications, 1391 replaying EAP packets, or generating packets with overlapping 1392 Identifiers. 1394 [4] An adversary might attempt to recover the pass-phrase by mounting 1395 an offline dictionary attack. 1397 [5] An adversary may attempt to convince the peer to connect to an 1398 untrusted network, by mounting a man-in-the-middle attack. 1400 [6] An adversary may attempt to disrupt the EAP negotiation in order 1401 to weaken the authentication. 1403 [7] An attacker may attempt to recover the key by taking advantage of 1404 weak key derivation techniques used within EAP methods. 1406 [8] An attacker may attempt to take advantage of weak ciphersuites 1407 subsequently used after the EAP conversation is complete. 1409 Where EAP is used over wireless networks, an attacker needs to be 1410 within the coverage area of the wireless medium in order to carry out 1411 these attacks. However, where EAP is used over the Internet, no such 1412 restrictions apply. 1414 7.2 Security claims 1416 In order to clearly articulate the security provided by an EAP 1417 method, EAP method specifications MUST include a Security Claims 1418 section including the following declarations: 1420 [a] Intended use. This includes a statement of whether the method is 1421 intended for use over a physically secure or insecure network, as 1422 well as a statement of the applicable media. 1424 [b] Mechanism. This is a statement of the authentication technology: 1425 certificates, pre-shared keys, passwords, token cards, etc. 1427 [c] Security claims. This is a statement of the claimed security 1428 properties of the method, using terms defined in Section 1.2: 1429 mutual authentication, integrity protection, replay protection, 1430 confidentiality, key derivation, key strength, dictionary attack 1431 resistance, fast reconnect, man-in-the-middle resistance, 1432 acknowledged result indications. The Security Claims section of 1433 an EAP method specification SHOULD provide justification for the 1434 claims that are made. This can be accomplished by including a 1435 proof in an Appendix, or including a reference to a proof. 1437 [d] Key strength. If the method derives keys, then the effective key 1438 strength MUST be estimated. 1440 [e] Description of key hierarchy. EAP methods deriving keys MUST 1441 either provide a reference to a key hierarchy specification, or 1442 describe how keys used for authentication/integrity, encryption 1443 and IVs are to be derived from the provided keying material, and 1444 how cryptographic separation is maintained between keys used for 1445 different purposes. 1447 [f] Indication of vulnerabilities. In addition to the security claims 1448 that are made, the specification MUST indicate which of the 1449 security claims detailed in Section 1.2 are NOT being made. 1451 7.3 Identity protection 1453 An Identity exchange is optional within the EAP conversation. 1454 Therefore, it is possible to omit the Identity exchange entirely, or 1455 to postpone it until later in the conversation once a protected 1456 channel has been established. 1458 However, where roaming is supported as described in [RFC2607], it may 1459 be necessary to locate the appropriate backend authentication server 1460 before the authentication conversation can proceed. The realm 1461 portion of the Network Access Identifier (NAI) [RFC2486] is typically 1462 included within the Identity-Response in order to enable the 1463 authentication exchange to be routed to the appropriate backend 1464 authentication server. Therefore while the peer-name portion of the 1465 NAI may be omitted in the Identity- Response, where proxies or relays 1466 are present, the realm portion may be required. 1468 7.4 Man-in-the-middle attacks 1470 Where a sequence of methods is utilized for authentication or EAP is 1471 tunneled within another protocol that omits peer authentication, 1472 there exists a potential vulnerability to man-in-the-middle attack. 1474 Where a sequence of EAP methods is utilized for authentication, the 1475 peer might not have proof that a single entity has acted as the 1476 authenticator for all EAP methods within the sequence. For example, 1477 an authenticator might terminate one EAP method, then forward the 1478 next method in the sequence to another party without the peer's 1479 knowledge or consent. Similarly, the authenticator might not have 1480 proof that a single entity has acted as the peer for all EAP methods 1481 within the sequence. 1483 This enables an attack by a rogue EAP authenticator tunneling EAP to 1484 a legitimate server. Where the tunneling protocol is used for key 1485 establishment but does not require peer authentication, an attacker 1486 convincing a legitimate peer to connect to it will be able to tunnel 1487 EAP packets to a legitimate server, successfully authenticating and 1488 obtaining the key. This allows the attacker to successfully establish 1489 itself as a man-in-the-middle, gaining access to the network, as well 1490 as the ability to decrypt data traffic between the legitimate peer 1491 and server. 1493 This attack may be mitigated by the following measures: 1495 [a] Requiring mutual authentication within EAP tunneling mechanisms. 1497 [b] Requiring cryptographic binding between EAP methods executed 1498 within a sequence or between the EAP tunneling protocol and the 1499 tunneled EAP methods. Where cryptographic binding is supported, a 1500 mechanism is also needed to protect against downgrade attacks 1501 that would bypass it. 1503 [c] Limiting the EAP methods authorized for use without protection, 1504 based on peer and authenticator policy. 1506 [d] Avoiding the use of sequences or tunnels when a single, strong 1507 method is available. 1509 7.5 Packet modification attacks 1511 While individual EAP methods may support per-packet data origin 1512 authentication, integrity and replay protection, EAP itself does not 1513 provide built-in support for this. 1515 Since the Identifier is only a single octet, it is easy to guess, 1516 allowing an attacker to successfully inject or replay EAP packets. 1517 An attacker may also modify EAP headers within EAP packets where the 1518 header is unprotected. This could cause packets to be inappropriately 1519 discarded or misinterpreted. 1521 In the case of PPP and IEEE 802 wired links, it is assumed that such 1522 attacks are restricted to attackers who can gain access to the 1523 physical link. However, where EAP is run over physically insecure 1524 lower layers such as IEEE 802.11 or the Internet (such as within 1525 protocols supporting PPP, EAP or Ethernet Tunneling), this assumption 1526 is no longer valid and the vulnerability to attack is greater. 1528 To protect EAP messages sent over physically insecure lower layers, 1529 methods providing mutual authentication and key derivation, as well 1530 as per-packet origin authentication, integrity and replay protection 1531 SHOULD be used. Method-specific MICs may be used to provide 1532 protection. Since EAP messages of Types Identity, Notification, and 1533 Nak do not include their own MIC, it may be desirable for the EAP 1534 method MIC to cover information contained within these messages, as 1535 well as the header of each EAP message. To provide protection, EAP 1536 also may be encapsulated within a protected channel created by 1537 protocols such as ISAKMP [RFC2408] as is done in [I-D.ietf-ipsra-pic] 1538 or within TLS [RFC2246]. However, as noted in Section 7.4, EAP 1539 tunneling may result in a man-in-the-middle vulnerability. 1541 7.6 Dictionary attacks 1543 Password authentication algorithms such as EAP-MD5, MS-CHAPv1 1544 [RFC2433] and Kerberos V [RFC1510] are known to be vulnerable to 1545 dictionary attacks. MS-CHAPv1 vulnerabilities are documented in 1546 [PPTPv1]; Kerberos vulnerabilities are described in [KRBATTACK], 1547 [KRBLIM], and [KERB4WEAK]. 1549 In order to protect against dictionary attacks, an authentication 1550 algorithm resistant to dictionary attack (as defined in Section 7.2) 1551 may be used. This is particularly important when EAP runs over media 1552 which are not physically secure. 1554 If an authentication algorithm is used that is known to be vulnerable 1555 to dictionary attack, then the conversation may be tunneled within a 1556 protected channel, in order to provide additional protection. 1557 However, as noted in Section 7.4, EAP tunneling may result in a 1558 man-in-the-middle vulnerability, and therefore dictionary attack 1559 resistant methods are preferred. 1561 7.7 Connection to an untrusted network 1563 With EAP methods supporting one-way authentication, such as EAP-MD5, 1564 the authenticator's identity is not verified. Where the lower layer 1565 is not physically secure (such as where EAP runs over wireless media 1566 or IP), this enables the peer to connect to a rogue authenticator. As 1567 a result, where the lower layer is not physically secure, a method 1568 supporting mutual authentication is recommended. 1570 In EAP there is no requirement that authentication be full duplex or 1571 that the same protocol be used in both directions. It is perfectly 1572 acceptable for different protocols to be used in each direction. 1573 This will, of course, depend on the specific protocols negotiated. 1574 However, in general, completing a single unitary mutual 1575 authentication is preferable to two one-way authentications, one in 1576 each direction. This is because separate authentications that are 1577 not bound cryptographically so as to demonstrate they are part of the 1578 same session are subject to man-in-the-middle attacks, as discussed 1579 in Section 7.4. 1581 7.8 Negotiation attacks 1583 In a negotiation attack, the attacker attempts to convince the peer 1584 and authenticator to negotiate a less secure EAP method. EAP does not 1585 provide protection for the Nak packet, although it is possible for a 1586 method to include coverage of Nak Responses within a method-specific 1587 MIC. 1589 To avoid negotiation attacks in situations where EAP runs over 1590 physically insecure media, for each named peer there SHOULD be an 1591 indication of exactly one method used to authenticate that peer name, 1592 as described in Section 2.1. 1594 7.9 Implementation idiosyncrasies 1596 The interaction of EAP with lower layer transports such as PPP and 1597 IEEE 802 are highly implementation dependent. 1599 For example, upon failure of authentication, some PPP implementations 1600 do not terminate the link, instead limiting traffic in Network-Layer 1601 Protocols to a filtered subset, which in turn allows the peer the 1602 opportunity to update secrets or send mail to the network 1603 administrator indicating a problem. Similarly, while in IEEE 802.1X 1604 an authentication failure will result in denied access to the 1605 controlled port, limited traffic may be permitted on the uncontrolled 1606 port. 1608 In EAP there is no provision for retries of failed authentication. 1609 However, in PPP the LCP state machine can renegotiate the 1610 authentication protocol at any time, thus allowing a new attempt. 1611 Similarly, in IEEE 802.1X the Supplicant or Authenticator can 1612 re-authenticate at any time. It is recommended that any counters used 1613 for authentication failure not be reset until after successful 1614 authentication, or subsequent termination of the failed link. 1616 7.10 Key derivation 1618 It is possible for the peer and EAP server to mutually authenticate, 1619 and derive a Master Key (MK). The MK is unique to the peer and EAP 1620 server and MUST NOT be exported by the EAP method, or used directly 1621 to protect the EAP conversation or subsequent data. As a result, 1622 possession of the MK represents proof of a successful authentication, 1623 and this is potentially useful in enabling features such as fast 1624 reconnect, or fast handoff. 1626 In order to provide keying material for use in a subsequently 1627 negotiated ciphersuite, the EAP method exports a Master Session Key 1628 (MSK). Like the EAP Master Key, EAP Master Session Keys are also not 1629 used directly to protect data; however, they are of sufficient size 1630 to enable subsequent derivation of Transient Session Keys (TSKs) for 1631 use with the selected ciphersuite. 1633 EAP methods provide Master Session Keys and not Transient Session 1634 Keys so as to allow EAP methods to be ciphersuite and media 1635 independent. Depending on the lower layer, EAP methods may run before 1636 or after ciphersuite negotiation, so that the selected ciphersuite 1637 may not be known to the EAP method. By providing keying material 1638 usable with any ciphersuite, EAP methods can used with a wide range 1639 of ciphersuites and media. Since the peer and EAP client reside on 1640 the same machine, TSKs can be provided to the lower layer security 1641 module without needing to leave the machine. 1643 In the case where the backend authentication server and authenticator 1644 reside on different machines, there are several implications for 1645 security: 1647 [a] Mutual authentication may occur between the peer and the backend 1648 authentication server, if the negotiated EAP method supports 1649 this. However, where the authenticator and backend authentication 1650 server are separate, the peer and authenticator do not mutually 1651 authenticate within EAP. However, subsequent to completion of 1652 the EAP conversation, the lower layer may support mutual 1653 authentication between the peer and authenticator. For example, 1654 IEEE 802.11i includes a Transient Session Key derivation protocol 1655 known as the 4-way handshake, which guarantees liveness of the 1656 TSKs, provides for mutual authentication between the peer and 1657 authenticator, replay protection, and protected ciphersuite 1658 negotiation. 1660 [b] The MSK negotiated between the peer and backend authentication 1661 server will need to be transmitted to the authenticator. The 1662 specification of this transit mechanism is outside the scope of 1663 this document. 1665 This specification does not provide detailed guidance on how EAP 1666 methods are to derive the MK and MSK. Key derivation is an art that 1667 is best practiced by professionals; rather than inventing new key 1668 derivation algorithms, reuse of existing algorithms such as those 1669 specified in IKE [RFC2409], or TLS [RFC2246] is recommended. 1671 However, some general guidelines can be provided: 1673 [1] The MK is for use only by the EAP authenticator and peer and MUST 1674 NOT be exported by the EAP method or provided to a third party. 1676 [2] Since the MSK is exported by the EAP method, while the MK is not, 1677 possession of the MSK MUST NOT provide information useful in 1678 determining the MK. 1680 [3] The MSK and TSKs MUST be fresh. Otherwise it is infeasible to 1681 detect messages replayed from prior sessions. 1683 [4] TSKs MUST be cryptographically independent from each other so 1684 that if an attacker obtains one of them, he will not have gained 1685 information useful in determining the other ones. 1687 [5] There MUST be a way to determine whether TSKs belong to this or 1688 to some other session. 1690 [6] The MSK derived by EAP methods MUST be bound to the peers as well 1691 as to the authentication method, so as to avoid a 1692 man-in-the-middle attack (see Section 7.4). 1694 7.11 Weak ciphersuites 1696 If after the initial EAP authentication, data packets are sent 1697 without per-packet authentication, integrity and replay protection, 1698 an attacker with access to the media can inject packets, "flip bits" 1699 within existing packets, replay packets, or even hijack the session 1700 completely. Without per-packet confidentiality, it is possible to 1701 snoop data packets. 1703 As a result, as noted in Section 3.1, where EAP is used over a 1704 physically insecure lower layer, per-packet authentication, integrity 1705 and replay protection SHOULD be used, and per-packet confidentiality 1706 is also recommended. 1708 8. Acknowledgments 1710 This protocol derives much of its inspiration from Dave Carrel's AHA 1711 draft as well as the PPP CHAP protocol [RFC1994]. Valuable feedback 1712 was provided by Yoshihiro Ohba of Toshiba America Research, Jari 1713 Arkko of Ericsson, Sachin Seth of Microsoft, and Glen Zorn of Cisco 1714 Systems. 1716 Normative References 1718 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1719 RFC 1661, July 1994. 1721 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1722 Protocol (CHAP)", RFC 1994, August 1996. 1724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1725 Requirement Levels", BCP 14, RFC 2119, March 1997. 1727 [RFC2243] Metz, C., "OTP Extended Responses", RFC 2243, November 1728 1997. 1730 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 1731 10646", RFC 2279, January 1998. 1733 [RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time 1734 Password System", RFC 2289, February 1998. 1736 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1737 (IKE)", RFC 2409, November 1998. 1739 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1740 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1741 October 1998. 1743 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 1744 Timer", RFC 2988, November 2000. 1746 [IEEE.802.1990] 1747 Institute of Electrical and Electronics Engineers, "Local 1748 and Metropolitan Area Networks: Overview and 1749 Architecture", IEEE Standard 802, 1990. 1751 [IEEE.802-1X.2001] 1752 Institute of Electrical and Electronics Engineers, "Local 1753 and Metropolitan Area Networks: Port-Based Network Access 1754 Control", IEEE Standard 802.1X, September 2001. 1756 Informative References 1758 [DECEPTION] 1759 Slatalla, M. and J. Quittner, "Masters of Deception", 1760 HarperCollins , New York, 1995. 1762 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 1763 Authentication Service (V5)", RFC 1510, September 1993. 1765 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 1766 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 1767 January 1999. 1769 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 1770 Authentication Protocol (EAP)", RFC 2284, March 1998. 1772 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 1773 RFC 2486, January 1999. 1775 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1776 Internet Protocol", RFC 2401, November 1998. 1778 [RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet 1779 Security Association and Key Management Protocol 1780 (ISAKMP)", RFC 2408, November 1998. 1782 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 1783 2433, October 1998. 1785 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1786 Implementation in Roaming", RFC 2607, June 1999. 1788 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. 1789 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 1790 2661, August 1999. 1792 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 1793 Protocol", RFC 2716, October 1999. 1795 [KRBATTACK] 1796 Wu, T., "A Real-World Analysis of Kerberos Password 1797 Security". 1799 [KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos 1800 authentication system, Proceedings of the 1991 Winter 1801 USENIX Conference, pp. 253-267", , 1991. 1803 [KERB4WEAK] 1804 Dole, B., Lodin, S. and E. Spafford, "Misplaced trust: 1805 Kerberos 4 session keys, Proceedings of the Internet 1806 Society Network and Distributed System Security Symposium, 1807 pp. 60-70", , March 1997. 1809 [I-D.ietf-ipsra-pic] 1810 Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A Pre-IKE 1811 Credential Provisioning Protocol", draft-ietf-ipsra-pic-06 1812 (work in progress), October 2002. 1814 [PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's 1815 Point-to- Point Tunneling Protocol, Proceedings of the 5th 1816 ACM Conference on Communications and Computer Security, 1817 ACM Press", , November 1998. 1819 [IEEE.802-3.1996] 1820 Institute of Electrical and Electronics Engineers, 1821 "Information technology - Telecommunications and 1822 Information Exchange between Systems - Local and 1823 Metropolitan Area Networks - Specific requirements - Part 1824 3: Carrier sense multiple access with collision detection 1825 (CSMA/CD) Access Method and Physical Layer 1826 Specifications", IEEE Standard 802.3, 1996. 1828 [IEEE.802-11.1999] 1829 Institute of Electrical and Electronics Engineers, 1830 "Information Technology - Telecommunications and 1831 Information Exchange between Systems - Local and 1832 Metropolitan Area Network - Specific Requirements - Part 1833 11: Wireless LAN Medium Access Control (MAC) and Physical 1834 Layer (PHY) Specifications", IEEE Standard 802.11, 1999. 1836 Authors' Addresses 1838 Larry J. Blunk 1839 Merit Network, Inc 1840 4251 Plymouth Rd., Suite 2000 1841 Ann Arbor, MI 48105-2785 1842 USA 1844 Phone: +1 734-647-9563 1845 EMail: ljb@merit.edu 1847 John R. Vollbrecht 1848 Vollbrecht Consulting LLC 1849 9682 Alice Hill Drive 1850 Dexter, MI 48130 1851 USA 1853 Phone: 1854 EMail: jrv@umich.edu 1856 Bernard Aboba 1857 Microsoft Corporation 1858 One Microsoft Way 1859 Redmond, WA 98052 1860 USA 1862 Phone: +1 425 706 6605 1863 EMail: bernarda@microsoft.com 1864 James Carlson 1865 Sun Microsystems, Inc 1866 1 Network Drive 1867 Burlington, MA 01803-2757 1868 USA 1870 Phone: +1 781 442 2084 1871 EMail: james.d.carlson@sun.com 1873 Appendix A. Change Log 1875 This section lists the major changes between [RFC2284] and this 1876 document. Minor changes, including style, grammar, spelling and 1877 editorial changes are not mentioned here. 1879 [To be written] 1881 Appendix B. Open issues 1883 Open issues relating to this specification are tracked on the 1884 following web site: 1886 http://www.drizzle.com/~aboba/EAP/eapissues.html 1888 The current working documents for this draft are available at this 1889 web site: 1891 http://www.levkowetz.com/pub/ietf/drafts/eap/ 1893 Intellectual Property Statement 1895 The IETF takes no position regarding the validity or scope of any 1896 intellectual property or other rights that might be claimed to 1897 pertain to the implementation or use of the technology described in 1898 this document or the extent to which any license under such rights 1899 might or might not be available; neither does it represent that it 1900 has made any effort to identify any such rights. Information on the 1901 IETF's procedures with respect to rights in standards-track and 1902 standards-related documentation can be found in BCP-11. Copies of 1903 claims of rights made available for publication and any assurances of 1904 licenses to be made available, or the result of an attempt made to 1905 obtain a general license or permission for the use of such 1906 proprietary rights by implementors or users of this specification can 1907 be obtained from the IETF Secretariat. 1909 The IETF invites any interested party to bring to its attention any 1910 copyrights, patents or patent applications, or other proprietary 1911 rights which may cover technology that may be required to practice 1912 this standard. Please address the information to the IETF Executive 1913 Director. 1915 Full Copyright Statement 1917 Copyright (C) The Internet Society (2003). All Rights Reserved. 1919 This document and translations of it may be copied and furnished to 1920 others, and derivative works that comment on or otherwise explain it 1921 or assist in its implementation may be prepared, copied, published 1922 and distributed, in whole or in part, without restriction of any 1923 kind, provided that the above copyright notice and this paragraph are 1924 included on all such copies and derivative works. However, this 1925 document itself may not be modified in any way, such as by removing 1926 the copyright notice or references to the Internet Society or other 1927 Internet organizations, except as needed for the purpose of 1928 developing Internet standards in which case the procedures for 1929 copyrights defined in the Internet Standards process must be 1930 followed, or as required to translate it into languages other than 1931 English. 1933 The limited permissions granted above are perpetual and will not be 1934 revoked by the Internet Society or its successors or assignees. 1936 This document and the information contained herein is provided on an 1937 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1938 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1939 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1940 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1941 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1943 Acknowledgement 1945 Funding for the RFC Editor function is currently provided by the 1946 Internet Society.