diff options
Diffstat (limited to 'doc/rfc/rfc3748.txt')
| -rw-r--r-- | doc/rfc/rfc3748.txt | 3755 |
1 files changed, 3755 insertions, 0 deletions
diff --git a/doc/rfc/rfc3748.txt b/doc/rfc/rfc3748.txt new file mode 100644 index 0000000..75600c1 --- /dev/null +++ b/doc/rfc/rfc3748.txt @@ -0,0 +1,3755 @@ + + + + + + +Network Working Group B. Aboba +Request for Comments: 3748 Microsoft +Obsoletes: 2284 L. Blunk +Category: Standards Track Merit Network, Inc + J. Vollbrecht + Vollbrecht Consulting LLC + J. Carlson + Sun + H. Levkowetz, Ed. + ipUnplugged + June 2004 + + + Extensible Authentication Protocol (EAP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document defines the Extensible Authentication Protocol (EAP), + an authentication framework which supports multiple authentication + methods. EAP typically runs directly over data link layers such as + Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP + provides its own support for duplicate elimination and + retransmission, but is reliant on lower layer ordering guarantees. + Fragmentation is not supported within EAP itself; however, individual + EAP methods may support this. + + This document obsoletes RFC 2284. A summary of the changes between + this document and RFC 2284 is available in Appendix A. + + + + + + + + + + + +Aboba, et al. Standards Track [Page 1] + +RFC 3748 EAP June 2004 + + +Table of Contents + + 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Specification of Requirements . . . . . . . . . . . . . 4 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 6 + 2. Extensible Authentication Protocol (EAP). . . . . . . . . . . 7 + 2.1. Support for Sequences . . . . . . . . . . . . . . . . . 9 + 2.2. EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10 + 2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . 12 + 2.4. Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14 + 3. Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15 + 3.1. Lower Layer Requirements. . . . . . . . . . . . . . . . 15 + 3.2. EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18 + 3.2.1. PPP Configuration Option Format. . . . . . . . . 18 + 3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19 + 3.4. Lower Layer Indications . . . . . . . . . . . . . . . . 19 + 4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1. Request and Response. . . . . . . . . . . . . . . . . . 21 + 4.2. Success and Failure . . . . . . . . . . . . . . . . . . 23 + 4.3. Retransmission Behavior . . . . . . . . . . . . . . . . 26 + 5. Initial EAP Request/Response Types. . . . . . . . . . . . . . 27 + 5.1. Identity. . . . . . . . . . . . . . . . . . . . . . . . 28 + 5.2. Notification. . . . . . . . . . . . . . . . . . . . . . 29 + 5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31 + 5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32 + 5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35 + 5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . 36 + 5.6. Generic Token Card (GTC). . . . . . . . . . . . . . . . 37 + 5.7. Expanded Types. . . . . . . . . . . . . . . . . . . . . 38 + 5.8. Experimental. . . . . . . . . . . . . . . . . . . . . . 40 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 + 6.1. Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41 + 6.2. Method Types. . . . . . . . . . . . . . . . . . . . . . 41 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 + 7.1. Threat Model. . . . . . . . . . . . . . . . . . . . . . 42 + 7.2. Security Claims . . . . . . . . . . . . . . . . . . . . 43 + 7.2.1. Security Claims Terminology for EAP Methods. . . 44 + 7.3. Identity Protection . . . . . . . . . . . . . . . . . . 46 + 7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47 + 7.5. Packet Modification Attacks . . . . . . . . . . . . . . 48 + 7.6. Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49 + 7.7. Connection to an Untrusted Network. . . . . . . . . . . 49 + 7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . 50 + 7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . 50 + 7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51 + 7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53 + + + +Aboba, et al. Standards Track [Page 2] + +RFC 3748 EAP June 2004 + + + 7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53 + 7.13. Separation of Authenticator and Backend Authentication + Server. . . . . . . . . . . . . . . . . . . . . . . . . 54 + 7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55 + 7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55 + 7.16. Protected Result Indications. . . . . . . . . . . . . . 56 + 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58 + 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 59 + 9.1. Normative References. . . . . . . . . . . . . . . . . . 59 + 9.2. Informative References. . . . . . . . . . . . . . . . . 60 + Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67 + +1. Introduction + + This document defines the Extensible Authentication Protocol (EAP), + an authentication framework which supports multiple authentication + methods. EAP typically runs directly over data link layers such as + Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP + provides its own support for duplicate elimination and + retransmission, but is reliant on lower layer ordering guarantees. + Fragmentation is not supported within EAP itself; however, individual + EAP methods may support this. + + EAP may be used on dedicated links, as well as switched circuits, and + wired as well as wireless links. To date, EAP has been implemented + with hosts and routers that connect via switched circuits or dial-up + lines using PPP [RFC1661]. It has also been implemented with + switches and access points using IEEE 802 [IEEE-802]. EAP + encapsulation on IEEE 802 wired media is described in [IEEE-802.1X], + and encapsulation on IEEE wireless LANs in [IEEE-802.11i]. + + One of the advantages of the EAP architecture is its flexibility. + EAP is used to select a specific authentication mechanism, typically + after the authenticator requests more information in order to + determine the specific authentication method to be used. Rather than + requiring the authenticator to be updated to support each new + authentication method, EAP permits the use of a backend + authentication server, which may implement some or all authentication + methods, with the authenticator acting as a pass-through for some or + all methods and peers. + + Within this document, authenticator requirements apply regardless of + whether the authenticator is operating as a pass-through or not. + Where the requirement is meant to apply to either the authenticator + or backend authentication server, depending on where the EAP + authentication is terminated, the term "EAP server" will be used. + + + +Aboba, et al. Standards Track [Page 3] + +RFC 3748 EAP June 2004 + + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. The key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +1.2. Terminology + + This document frequently uses the following terms: + + authenticator + The end of the link initiating EAP authentication. The term + authenticator is used in [IEEE-802.1X], and has the same meaning + in this document. + + peer + The end of the link that responds to the authenticator. In + [IEEE-802.1X], this end is known as the Supplicant. + + Supplicant + The end of the link that responds to the authenticator in [IEEE- + 802.1X]. In this document, this end of the link is called the + peer. + + backend authentication server + A backend authentication server is an entity that provides an + authentication service to an authenticator. When used, this + server typically executes EAP methods for the authenticator. This + terminology is also used in [IEEE-802.1X]. + + AAA + Authentication, Authorization, and Accounting. AAA protocols with + EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP]. In + this document, the terms "AAA server" and "backend authentication + server" are used interchangeably. + + Displayable Message + This is interpreted to be a human readable string of characters. + The message encoding MUST follow the UTF-8 transformation format + [RFC2279]. + + + + + + + + + +Aboba, et al. Standards Track [Page 4] + +RFC 3748 EAP June 2004 + + + EAP server + The entity that terminates the EAP authentication method with the + peer. In the case where no backend authentication server is used, + the EAP server is part of the authenticator. In the case where + the authenticator operates in pass-through mode, the EAP server is + located on the backend authentication server. + + Silently Discard + This means the implementation discards the packet without further + processing. The implementation SHOULD provide the capability of + logging the event, including the contents of the silently + discarded packet, and SHOULD record the event in a statistics + counter. + + Successful Authentication + In the context of this document, "successful authentication" is an + exchange of EAP messages, as a result of which the authenticator + decides to allow access by the peer, and the peer decides to use + this access. The authenticator's decision typically involves both + authentication and authorization aspects; the peer may + successfully authenticate to the authenticator, but access may be + denied by the authenticator due to policy reasons. + + Message Integrity Check (MIC) + A keyed hash function used for authentication and integrity + protection of data. This is usually called a Message + Authentication Code (MAC), but IEEE 802 specifications (and this + document) use the acronym MIC to avoid confusion with Medium + Access Control. + + Cryptographic Separation + Two keys (x and y) are "cryptographically separate" if an + adversary that knows all messages exchanged in the protocol cannot + compute x from y or y from x without "breaking" some cryptographic + assumption. In particular, this definition allows that the + adversary has the knowledge of all nonces sent in cleartext, as + well as all predictable counter values used in the protocol. + Breaking a cryptographic assumption would typically require + inverting a one-way function or predicting the outcome of a + cryptographic pseudo-random number generator without knowledge of + the secret state. In other words, if the keys are + cryptographically separate, there is no shortcut to compute x from + y or y from x, but the work an adversary must do to perform this + computation is equivalent to performing an exhaustive search for + the secret state value. + + + + + + +Aboba, et al. Standards Track [Page 5] + +RFC 3748 EAP June 2004 + + + Master Session Key (MSK) + Keying material that is derived between the EAP peer and server + and exported by the EAP method. The MSK is at least 64 octets in + length. In existing implementations, a AAA server acting as an + EAP server transports the MSK to the authenticator. + + Extended Master Session Key (EMSK) + Additional keying material derived between the EAP client and + server that is exported by the EAP method. The EMSK is at least + 64 octets in length. The EMSK is not shared with the + authenticator or any other third party. The EMSK is reserved for + future uses that are not defined yet. + + Result indications + A method provides result indications if after the method's last + message is sent and received: + + 1) The peer is aware of whether it has authenticated the server, + as well as whether the server has authenticated it. + + 2) The server is aware of whether it has authenticated the peer, + as well as whether the peer has authenticated it. + + In the case where successful authentication is sufficient to + authorize access, then the peer and authenticator will also know if + the other party is willing to provide or accept access. This may not + always be the case. An authenticated peer may be denied access due + to lack of authorization (e.g., session limit) or other reasons. + Since the EAP exchange is run between the peer and the server, other + nodes (such as AAA proxies) may also affect the authorization + decision. This is discussed in more detail in Section 7.16. + +1.3. Applicability + + EAP was designed for use in network access authentication, where IP + layer connectivity may not be available. Use of EAP for other + purposes, such as bulk data transport, is NOT RECOMMENDED. + + Since EAP does not require IP connectivity, it provides just enough + support for the reliable transport of authentication protocols, and + no more. + + EAP is a lock-step protocol which only supports a single packet in + flight. As a result, EAP cannot efficiently transport bulk data, + unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960]. + + + + + + +Aboba, et al. Standards Track [Page 6] + +RFC 3748 EAP June 2004 + + + While EAP provides support for retransmission, it assumes ordering + guarantees provided by the lower layer, so out of order reception is + not supported. + + Since EAP does not support fragmentation and reassembly, EAP + authentication methods generating payloads larger than the minimum + EAP MTU need to provide fragmentation support. + + While authentication methods such as EAP-TLS [RFC2716] provide + support for fragmentation and reassembly, the EAP methods defined in + this document do not. As a result, if the EAP packet size exceeds + the EAP MTU of the link, these methods will encounter difficulties. + + EAP authentication is initiated by the server (authenticator), + whereas many authentication protocols are initiated by the client + (peer). As a result, it may be necessary for an authentication + algorithm to add one or two additional messages (at most one + roundtrip) in order to run over EAP. + + Where certificate-based authentication is supported, the number of + additional roundtrips may be much larger due to fragmentation of + certificate chains. In general, a fragmented EAP packet will require + as many round-trips to send as there are fragments. For example, a + certificate chain 14960 octets in size would require ten round-trips + to send with a 1496 octet EAP MTU. + + Where EAP runs over a lower layer in which significant packet loss is + experienced, or where the connection between the authenticator and + authentication server experiences significant packet loss, EAP + methods requiring many round-trips can experience difficulties. In + these situations, use of EAP methods with fewer roundtrips is + advisable. + +2. Extensible Authentication Protocol (EAP) + + The EAP authentication exchange proceeds as follows: + + [1] The authenticator sends a Request to authenticate the peer. The + Request has a Type field to indicate what is being requested. + Examples of Request Types include Identity, MD5-challenge, etc. + The MD5-challenge Type corresponds closely to the CHAP + authentication protocol [RFC1994]. Typically, the authenticator + will send an initial Identity Request; however, an initial + Identity Request is not required, and MAY be bypassed. For + example, the identity may not be required where it is determined + by the port to which the peer has connected (leased lines, + + + + + +Aboba, et al. Standards Track [Page 7] + +RFC 3748 EAP June 2004 + + + dedicated switch or dial-up ports), or where the identity is + obtained in another fashion (via calling station identity or MAC + address, in the Name field of the MD5-Challenge Response, etc.). + + [2] The peer sends a Response packet in reply to a valid Request. As + with the Request packet, the Response packet contains a Type + field, which corresponds to the Type field of the Request. + + [3] The authenticator sends an additional Request packet, and the + peer replies with a Response. The sequence of Requests and + Responses continues as long as needed. EAP is a 'lock step' + protocol, so that other than the initial Request, a new Request + cannot be sent prior to receiving a valid Response. The + authenticator is responsible for retransmitting requests as + described in Section 4.1. After a suitable number of + retransmissions, the authenticator SHOULD end the EAP + conversation. The authenticator MUST NOT send a Success or + Failure packet when retransmitting or when it fails to get a + response from the peer. + + [4] The conversation continues until the authenticator cannot + authenticate the peer (unacceptable Responses to one or more + Requests), in which case the authenticator implementation MUST + transmit an EAP Failure (Code 4). Alternatively, the + authentication conversation can continue until the authenticator + determines that successful authentication has occurred, in which + case the authenticator MUST transmit an EAP Success (Code 3). + + Advantages: + + o The EAP protocol can support multiple authentication mechanisms + without having to pre-negotiate a particular one. + + o Network Access Server (NAS) devices (e.g., a switch or access + point) do not have to understand each authentication method and + MAY act as a pass-through agent for a backend authentication + server. Support for pass-through is optional. An authenticator + MAY authenticate local peers, while at the same time acting as a + pass-through for non-local peers and authentication methods it + does not implement locally. + + o Separation of the authenticator from the backend authentication + server simplifies credentials management and policy decision + making. + + + + + + + +Aboba, et al. Standards Track [Page 8] + +RFC 3748 EAP June 2004 + + + Disadvantages: + + o For use in PPP, EAP requires the addition of a new authentication + Type to PPP LCP and thus PPP implementations will need to be + modified to use it. It also strays from the previous PPP + authentication model of negotiating a specific authentication + mechanism during LCP. Similarly, switch or access point + implementations need to support [IEEE-802.1X] in order to use EAP. + + o Where the authenticator is separate from the backend + authentication server, this complicates the security analysis and, + if needed, key distribution. + +2.1. Support for Sequences + + An EAP conversation MAY utilize a sequence of methods. A common + example of this is an Identity request followed by a single EAP + authentication method such as an MD5-Challenge. However, the peer + and authenticator MUST utilize only one authentication method (Type 4 + or greater) within an EAP conversation, after which the authenticator + MUST send a Success or Failure packet. + + Once a peer has sent a Response of the same Type as the initial + Request, an authenticator MUST NOT send a Request of a different Type + prior to completion of the final round of a given method (with the + exception of a Notification-Request) and MUST NOT send a Request for + an additional method of any Type after completion of the initial + authentication method; a peer receiving such Requests MUST treat them + as invalid, and silently discard them. As a result, Identity Requery + is not supported. + + A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request + after an initial non-Nak Response has been sent. Since spoofed EAP + Request packets may be sent by an attacker, an authenticator + receiving an unexpected Nak SHOULD discard it and log the event. + + Multiple authentication methods within an EAP conversation are not + supported due to their vulnerability to man-in-the-middle attacks + (see Section 7.4) and incompatibility with existing implementations. + + Where a single EAP authentication method is utilized, but other + methods are run within it (a "tunneled" method), the prohibition + against multiple authentication methods does not apply. Such + "tunneled" methods appear as a single authentication method to EAP. + Backward compatibility can be provided, since a peer not supporting a + "tunneled" method can reply to the initial EAP-Request with a Nak + + + + + +Aboba, et al. Standards Track [Page 9] + +RFC 3748 EAP June 2004 + + + (legacy or expanded). To address security vulnerabilities, + "tunneled" methods MUST support protection against man-in-the-middle + attacks. + +2.2. EAP Multiplexing Model + + Conceptually, EAP implementations consist of the following + components: + + [a] Lower layer. The lower layer is responsible for transmitting and + receiving EAP frames between the peer and authenticator. EAP has + been run over a variety of lower layers including PPP, wired IEEE + 802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], + UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP [PIC]. Lower + layer behavior is discussed in Section 3. + + [b] EAP layer. The EAP layer receives and transmits EAP packets via + the lower layer, implements duplicate detection and + retransmission, and delivers and receives EAP messages to and + from the EAP peer and authenticator layers. + + [c] EAP peer and authenticator layers. Based on the Code field, the + EAP layer demultiplexes incoming EAP packets to the EAP peer and + authenticator layers. Typically, an EAP implementation on a + given host will support either peer or authenticator + functionality, but it is possible for a host to act as both an + EAP peer and authenticator. In such an implementation both EAP + peer and authenticator layers will be present. + + [d] EAP method layers. EAP methods implement the authentication + algorithms and receive and transmit EAP messages via the EAP peer + and authenticator layers. Since fragmentation support is not + provided by EAP itself, this is the responsibility of EAP + methods, which are discussed in Section 5. + + The EAP multiplexing model is illustrated in Figure 1 below. Note + that there is no requirement that an implementation conform to this + model, as long as the on-the-wire behavior is consistent with it. + + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 10] + +RFC 3748 EAP June 2004 + + + +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ + | | | | | | + | EAP method| EAP method| | EAP method| EAP method| + | Type = X | Type = Y | | Type = X | Type = Y | + | V | | | ^ | | + +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ + | ! | | ! | + | EAP ! Peer layer | | EAP ! Auth. layer | + | ! | | ! | + +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ + | ! | | ! | + | EAP ! layer | | EAP ! layer | + | ! | | ! | + +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ + | ! | | ! | + | Lower ! layer | | Lower ! layer | + | ! | | ! | + +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ + ! ! + ! Peer ! Authenticator + +------------>-------------+ + + Figure 1: EAP Multiplexing Model + + Within EAP, the Code field functions much like a protocol number in + IP. It is assumed that the EAP layer demultiplexes incoming EAP + packets according to the Code field. Received EAP packets with + Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the + EAP layer to the EAP peer layer, if implemented. EAP packets with + Code=2 (Response) are delivered to the EAP authenticator layer, if + implemented. + + Within EAP, the Type field functions much like a port number in UDP + or TCP. It is assumed that the EAP peer and authenticator layers + demultiplex incoming EAP packets according to their Type, and deliver + them only to the EAP method corresponding to that Type. An EAP + method implementation on a host may register to receive packets from + the peer or authenticator layers, or both, depending on which role(s) + it supports. + + Since EAP authentication methods may wish to access the Identity, + implementations SHOULD make the Identity Request and Response + accessible to authentication methods (Types 4 or greater), in + addition to the Identity method. The Identity Type is discussed in + Section 5.1. + + + + + + +Aboba, et al. Standards Track [Page 11] + +RFC 3748 EAP June 2004 + + + A Notification Response is only used as confirmation that the peer + received the Notification Request, not that it has processed it, or + displayed the message to the user. It cannot be assumed that the + contents of the Notification Request or Response are available to + another method. The Notification Type is discussed in Section 5.2. + + Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes + of method negotiation. Peers respond to an initial EAP Request for + an unacceptable Type with a Nak Response (Type 3) or Expanded Nak + Response (Type 254). It cannot be assumed that the contents of the + Nak Response(s) are available to another method. The Nak Type(s) are + discussed in Section 5.3. + + EAP packets with Codes of Success or Failure do not include a Type + field, and are not delivered to an EAP method. Success and Failure + are discussed in Section 4.2. + + Given these considerations, the Success, Failure, Nak Response(s), + and Notification Request/Response messages MUST NOT be used to carry + data destined for delivery to other EAP methods. + +2.3. Pass-Through Behavior + + When operating as a "pass-through authenticator", an authenticator + performs checks on the Code, Identifier, and Length fields as + described in Section 4.1. It forwards EAP packets received from the + peer and destined to its authenticator layer to the backend + authentication server; packets received from the backend + authentication server destined to the peer are forwarded to it. + + A host receiving an EAP packet may only do one of three things with + it: act on it, drop it, or forward it. The forwarding decision is + typically based only on examination of the Code, Identifier, and + Length fields. A pass-through authenticator implementation MUST be + capable of forwarding EAP packets received from the peer with Code=2 + (Response) to the backend authentication server. It also MUST be + capable of receiving EAP packets from the backend authentication + server and forwarding EAP packets of Code=1 (Request), Code=3 + (Success), and Code=4 (Failure) to the peer. + + Unless the authenticator implements one or more authentication + methods locally which support the authenticator role, the EAP method + layer header fields (Type, Type-Data) are not examined as part of the + forwarding decision. Where the authenticator supports local + authentication methods, it MAY examine the Type field to determine + whether to act on the packet itself or forward it. Compliant pass- + through authenticator implementations MUST by default forward EAP + packets of any Type. + + + +Aboba, et al. Standards Track [Page 12] + +RFC 3748 EAP June 2004 + + + EAP packets received with Code=1 (Request), Code=3 (Success), and + Code=4 (Failure) are demultiplexed by the EAP layer and delivered to + the peer layer. Therefore, unless a host implements an EAP peer + layer, these packets will be silently discarded. Similarly, EAP + packets received with Code=2 (Response) are demultiplexed by the EAP + layer and delivered to the authenticator layer. Therefore, unless a + host implements an EAP authenticator layer, these packets will be + silently discarded. The behavior of a "pass-through peer" is + undefined within this specification, and is unsupported by AAA + protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP]. + + The forwarding model is illustrated in Figure 2. + + Peer Pass-through Authenticator Authentication + Server + + +-+-+-+-+-+-+ +-+-+-+-+-+-+ + | | | | + |EAP method | |EAP method | + | V | | ^ | + +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ + | ! | |EAP | EAP | | | ! | + | ! | |Peer | Auth.| EAP Auth. | | ! | + |EAP ! peer| | | +-----------+ | |EAP !Auth.| + | ! | | | ! | ! | | ! | + +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ + | ! | | ! | ! | | ! | + |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| + | ! | | ! | ! | | ! | + +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ + | ! | | ! | ! | | ! | + |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | + | ! | | ! | ! | | ! | + +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ + ! ! ! ! + ! ! ! ! + +-------->--------+ +--------->-------+ + + + Figure 2: Pass-through Authenticator + + For sessions in which the authenticator acts as a pass-through, it + MUST determine the outcome of the authentication solely based on the + Accept/Reject indication sent by the backend authentication server; + the outcome MUST NOT be determined by the contents of an EAP packet + sent along with the Accept/Reject indication, or the absence of such + an encapsulated EAP packet. + + + + +Aboba, et al. Standards Track [Page 13] + +RFC 3748 EAP June 2004 + + +2.4. Peer-to-Peer Operation + + Since EAP is a peer-to-peer protocol, an independent and simultaneous + authentication may take place in the reverse direction (depending on + the capabilities of the lower layer). Both ends of the link may act + as authenticators and peers at the same time. In this case, it is + necessary for both ends to implement EAP authenticator and peer + layers. In addition, the EAP method implementations on both peers + must support both authenticator and peer functionality. + + Although EAP supports peer-to-peer operation, some EAP + implementations, methods, AAA protocols, and link layers may not + support this. Some EAP methods may support asymmetric + authentication, with one type of credential being required for the + peer and another type for the authenticator. Hosts supporting peer- + to-peer operation with such a method would need to be provisioned + with both types of credentials. + + For example, EAP-TLS [RFC2716] is a client-server protocol in which + distinct certificate profiles are typically utilized for the client + and server. This implies that a host supporting peer-to-peer + authentication with EAP-TLS would need to implement both the EAP peer + and authenticator layers, support both peer and authenticator roles + in the EAP-TLS implementation, and provision certificates appropriate + for each role. + + AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM- + EAP] only support "pass-through authenticator" operation. As noted + in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access- + Request encapsulating an EAP-Request, Success, or Failure packet with + an Access-Reject. There is therefore no support for "pass-through + peer" operation. + + Even where a method is used which supports mutual authentication and + result indications, several considerations may dictate that two EAP + authentications (one in each direction) are required. These include: + + [1] Support for bi-directional session key derivation in the lower + layer. Lower layers such as IEEE 802.11 may only support uni- + directional derivation and transport of transient session keys. + For example, the group-key handshake defined in [IEEE-802.11i] is + uni-directional, since in IEEE 802.11 infrastructure mode, only + the Access Point (AP) sends multicast/broadcast traffic. In IEEE + 802.11 ad hoc mode, where either peer may send + multicast/broadcast traffic, two uni-directional group-key + + + + + + +Aboba, et al. Standards Track [Page 14] + +RFC 3748 EAP June 2004 + + + exchanges are required. Due to limitations of the design, this + also implies the need for unicast key derivations and EAP method + exchanges to occur in each direction. + + [2] Support for tie-breaking in the lower layer. Lower layers such + as IEEE 802.11 ad hoc do not support "tie breaking" wherein two + hosts initiating authentication with each other will only go + forward with a single authentication. This implies that even if + 802.11 were to support a bi-directional group-key handshake, then + two authentications, one in each direction, might still occur. + + [3] Peer policy satisfaction. EAP methods may support result + indications, enabling the peer to indicate to the EAP server + within the method that it successfully authenticated the EAP + server, as well as for the server to indicate that it has + authenticated the peer. However, a pass-through authenticator + will not be aware that the peer has accepted the credentials + offered by the EAP server, unless this information is provided to + the authenticator via the AAA protocol. The authenticator SHOULD + interpret the receipt of a key attribute within an Accept packet + as an indication that the peer has successfully authenticated the + server. + + However, it is possible that the EAP peer's access policy was not + satisfied during the initial EAP exchange, even though mutual + authentication occurred. For example, the EAP authenticator may not + have demonstrated authorization to act in both peer and authenticator + roles. As a result, the peer may require an additional + authentication in the reverse direction, even if the peer provided an + indication that the EAP server had successfully authenticated to it. + +3. Lower Layer Behavior + +3.1. Lower Layer Requirements + + EAP makes the following assumptions about lower layers: + + [1] Unreliable transport. In EAP, the authenticator retransmits + Requests that have not yet received Responses so that EAP does + not assume that lower layers are reliable. Since EAP defines its + own retransmission behavior, it is possible (though undesirable) + for retransmission to occur both in the lower layer and the EAP + layer when EAP is run over a reliable lower layer. + + + + + + + + +Aboba, et al. Standards Track [Page 15] + +RFC 3748 EAP June 2004 + + + Note that EAP Success and Failure packets are not retransmitted. + Without a reliable lower layer, and with a non-negligible error rate, + these packets can be lost, resulting in timeouts. It is therefore + desirable for implementations to improve their resilience to loss of + EAP Success or Failure packets, as described in Section 4.2. + + [2] Lower layer error detection. While EAP does not assume that the + lower layer is reliable, it does rely on lower layer error + detection (e.g., CRC, Checksum, MIC, etc.). EAP methods may not + include a MIC, or if they do, it may not be computed over all the + fields in the EAP packet, such as the Code, Identifier, Length, + or Type fields. As a result, without lower layer error + detection, undetected errors could creep into the EAP layer or + EAP method layer header fields, resulting in authentication + failures. + + For example, EAP TLS [RFC2716], which computes its MIC over the + Type-Data field only, regards MIC validation failures as a fatal + error. Without lower layer error detection, this method, and + others like it, will not perform reliably. + + [3] Lower layer security. EAP does not require lower layers to + provide security services such as per-packet confidentiality, + authentication, integrity, and replay protection. However, where + these security services are available, EAP methods supporting Key + Derivation (see Section 7.2.1) can be used to provide dynamic + keying material. This makes it possible to bind the EAP + authentication to subsequent data and protect against data + modification, spoofing, or replay. See Section 7.1 for details. + + [4] Minimum MTU. EAP is capable of functioning on lower layers that + provide an EAP MTU size of 1020 octets or greater. + + EAP does not support path MTU discovery, and fragmentation and + reassembly is not supported by EAP, nor by the methods defined in + this specification: Identity (1), Notification (2), Nak Response + (3), MD5-Challenge (4), One Time Password (5), Generic Token Card + (6), and expanded Nak Response (254) Types. + + Typically, the EAP peer obtains information on the EAP MTU from + the lower layers and sets the EAP frame size to an appropriate + value. Where the authenticator operates in pass-through mode, + the authentication server does not have a direct way of + determining the EAP MTU, and therefore relies on the + authenticator to provide it with this information, such as via + the Framed-MTU attribute, as described in [RFC3579], Section 2.4. + + + + + +Aboba, et al. Standards Track [Page 16] + +RFC 3748 EAP June 2004 + + + While methods such as EAP-TLS [RFC2716] support fragmentation and + reassembly, EAP methods originally designed for use within PPP + where a 1500 octet MTU is guaranteed for control frames (see + [RFC1661], Section 6.1) may lack fragmentation and reassembly + features. + + EAP methods can assume a minimum EAP MTU of 1020 octets in the + absence of other information. EAP methods SHOULD include support + for fragmentation and reassembly if their payloads can be larger + than this minimum EAP MTU. + + EAP is a lock-step protocol, which implies a certain inefficiency + when handling fragmentation and reassembly. Therefore, if the + lower layer supports fragmentation and reassembly (such as where + EAP is transported over IP), it may be preferable for + fragmentation and reassembly to occur in the lower layer rather + than in EAP. This can be accomplished by providing an + artificially large EAP MTU to EAP, causing fragmentation and + reassembly to be handled within the lower layer. + + [5] Possible duplication. Where the lower layer is reliable, it will + provide the EAP layer with a non-duplicated stream of packets. + However, while it is desirable that lower layers provide for + non-duplication, this is not a requirement. The Identifier field + provides both the peer and authenticator with the ability to + detect duplicates. + + [6] Ordering guarantees. EAP does not require the Identifier to be + monotonically increasing, and so is reliant on lower layer + ordering guarantees for correct operation. EAP was originally + defined to run on PPP, and [RFC1661] Section 1 has an ordering + requirement: + + "The Point-to-Point Protocol is designed for simple links + which transport packets between two peers. These links + provide full-duplex simultaneous bi-directional operation, + and are assumed to deliver packets in order." + + Lower layer transports for EAP MUST preserve ordering between a + source and destination at a given priority level (the ordering + guarantee provided by [IEEE-802]). + + Reordering, if it occurs, will typically result in an EAP + authentication failure, causing EAP authentication to be re-run. + In an environment in which reordering is likely, it is therefore + expected that EAP authentication failures will be common. It is + RECOMMENDED that EAP only be run over lower layers that provide + ordering guarantees; running EAP over raw IP or UDP transport is + + + +Aboba, et al. Standards Track [Page 17] + +RFC 3748 EAP June 2004 + + + NOT RECOMMENDED. Encapsulation of EAP within RADIUS [RFC3579] + satisfies ordering requirements, since RADIUS is a "lockstep" + protocol that delivers packets in order. + +3.2. EAP Usage Within PPP + + In order to establish communications over a point-to-point link, each + end of the PPP link first sends LCP packets to configure the data + link during the Link Establishment phase. After the link has been + established, PPP provides for an optional Authentication phase before + proceeding to the Network-Layer Protocol phase. + + By default, authentication is not mandatory. If authentication of + the link is desired, an implementation MUST specify the + Authentication Protocol Configuration Option during the Link + Establishment phase. + + If the identity of the peer has been established in the + Authentication phase, the server can use that identity in the + selection of options for the following network layer negotiations. + + When implemented within PPP, EAP does not select a specific + authentication mechanism at the PPP Link Control Phase, but rather + postpones this until the Authentication Phase. This allows the + authenticator to request more information before determining the + specific authentication mechanism. This also permits the use of a + "backend" server which actually implements the various mechanisms + while the PPP authenticator merely passes through the authentication + exchange. The PPP Link Establishment and Authentication phases, and + the Authentication Protocol Configuration Option, are defined in The + Point-to-Point Protocol (PPP) [RFC1661]. + +3.2.1. PPP Configuration Option Format + + A summary of the PPP Authentication Protocol Configuration Option + format to negotiate EAP follows. The fields are transmitted from + left to right. + + Exactly one EAP packet is encapsulated in the Information field of a + PPP Data Link Layer frame where the protocol field indicates type hex + C227 (PPP EAP). + + + + + + + + + + +Aboba, et al. Standards Track [Page 18] + +RFC 3748 EAP June 2004 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Authentication Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 4 + + Authentication Protocol + + C227 (Hex) for Extensible Authentication Protocol (EAP) + +3.3. EAP Usage Within IEEE 802 + + The encapsulation of EAP over IEEE 802 is defined in [IEEE-802.1X]. + The IEEE 802 encapsulation of EAP does not involve PPP, and IEEE + 802.1X does not include support for link or network layer + negotiations. As a result, within IEEE 802.1X, it is not possible to + negotiate non-EAP authentication mechanisms, such as PAP or CHAP + [RFC1994]. + +3.4. Lower Layer Indications + + The reliability and security of lower layer indications is dependent + on the lower layer. Since EAP is media independent, the presence or + absence of lower layer security is not taken into account in the + processing of EAP messages. + + To improve reliability, if a peer receives a lower layer success + indication as defined in Section 7.2, it MAY conclude that a Success + packet has been lost, and behave as if it had actually received a + Success packet. This includes choosing to ignore the Success in some + circumstances as described in Section 4.2. + + A discussion of some reliability and security issues with lower layer + indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless + LANs can be found in the Security Considerations, Section 7.12. + + After EAP authentication is complete, the peer will typically + transmit and receive data via the authenticator. It is desirable to + provide assurance that the entities transmitting data are the same + ones that successfully completed EAP authentication. To accomplish + + + +Aboba, et al. Standards Track [Page 19] + +RFC 3748 EAP June 2004 + + + this, it is necessary for the lower layer to provide per-packet + integrity, authentication and replay protection, and to bind these + per-packet services to the keys derived during EAP authentication. + Otherwise, it is possible for subsequent data traffic to be modified, + spoofed, or replayed. + + Where keying material for the lower layer ciphersuite is itself + provided by EAP, ciphersuite negotiation and key activation are + controlled by the lower layer. In PPP, ciphersuites are negotiated + within ECP so that it is not possible to use keys derived from EAP + authentication until the completion of ECP. Therefore, an initial + EAP exchange cannot be protected by a PPP ciphersuite, although EAP + re-authentication can be protected. + + In IEEE 802 media, initial key activation also typically occurs after + completion of EAP authentication. Therefore an initial EAP exchange + typically cannot be protected by the lower layer ciphersuite, + although an EAP re-authentication or pre-authentication exchange can + be protected. + +4. EAP Packet Format + + A summary of the EAP packet format is shown below. The fields are + transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + The Code field is one octet and identifies the Type of EAP packet. + EAP Codes are assigned as follows: + + 1 Request + 2 Response + 3 Success + 4 Failure + + Since EAP only defines Codes 1-4, EAP packets with other codes + MUST be silently discarded by both authenticators and peers. + + + + + + +Aboba, et al. Standards Track [Page 20] + +RFC 3748 EAP June 2004 + + + Identifier + + The Identifier field is one octet and aids in matching Responses + with Requests. + + Length + + The Length field is two octets and indicates the length, in + octets, of the EAP packet including the Code, Identifier, Length, + and Data fields. Octets outside the range of the Length field + should be treated as Data Link Layer padding and MUST be ignored + upon reception. A message with the Length field set to a value + larger than the number of received octets MUST be silently + discarded. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + +4.1. Request and Response + + Description + + The Request packet (Code field set to 1) is sent by the + authenticator to the peer. Each Request has a Type field which + serves to indicate what is being requested. Additional Request + packets MUST be sent until a valid Response packet is received, an + optional retry counter expires, or a lower layer failure + indication is received. + + Retransmitted Requests MUST be sent with the same Identifier value + in order to distinguish them from new Requests. The content of + the data field is dependent on the Request Type. The peer MUST + send a Response packet in reply to a valid Request packet. + Responses MUST only be sent in reply to a valid Request and never + be retransmitted on a timer. + + If a peer receives a valid duplicate Request for which it has + already sent a Response, it MUST resend its original Response + without reprocessing the Request. Requests MUST be processed in + the order that they are received, and MUST be processed to their + completion before inspecting the next Request. + + A summary of the Request and Response packet format follows. The + fields are transmitted from left to right. + + + + + +Aboba, et al. Standards Track [Page 21] + +RFC 3748 EAP June 2004 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Type-Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 1 for Request + 2 for Response + + Identifier + + The Identifier field is one octet. The Identifier field MUST be + the same if a Request packet is retransmitted due to a timeout + while waiting for a Response. Any new (non-retransmission) + Requests MUST modify the Identifier field. + + The Identifier field of the Response MUST match that of the + currently outstanding Request. An authenticator receiving a + Response whose Identifier value does not match that of the + currently outstanding Request MUST silently discard the Response. + + In order to avoid confusion between new Requests and + retransmissions, the Identifier value chosen for each new Request + need only be different from the previous Request, but need not be + unique within the conversation. One way to achieve this is to + start the Identifier at an initial value and increment it for each + new Request. Initializing the first Identifier with a random + number rather than starting from zero is recommended, since it + makes sequence attacks somewhat more difficult. + + Since the Identifier space is unique to each session, + authenticators are not restricted to only 256 simultaneous + authentication conversations. Similarly, with re-authentication, + an EAP conversation might continue over a long period of time, and + is not limited to only 256 roundtrips. + + Implementation Note: The authenticator is responsible for + retransmitting Request messages. If the Request message is obtained + from elsewhere (such as from a backend authentication server), then + the authenticator will need to save a copy of the Request in order to + accomplish this. The peer is responsible for detecting and handling + duplicate Request messages before processing them in any way, + including passing them on to an outside party. The authenticator is + also responsible for discarding Response messages with a non-matching + + + +Aboba, et al. Standards Track [Page 22] + +RFC 3748 EAP June 2004 + + + Identifier value before acting on them in any way, including passing + them on to the backend authentication server for verification. Since + the authenticator can retransmit before receiving a Response from the + peer, the authenticator can receive multiple Responses, each with a + matching Identifier. Until a new Request is received by the + authenticator, the Identifier value is not updated, so that the + authenticator forwards Responses to the backend authentication + server, one at a time. + + Length + + The Length field is two octets and indicates the length of the EAP + packet including the Code, Identifier, Length, Type, and Type-Data + fields. Octets outside the range of the Length field should be + treated as Data Link Layer padding and MUST be ignored upon + reception. A message with the Length field set to a value larger + than the number of received octets MUST be silently discarded. + + Type + + The Type field is one octet. This field indicates the Type of + Request or Response. A single Type MUST be specified for each EAP + Request or Response. An initial specification of Types follows in + Section 5 of this document. + + The Type field of a Response MUST either match that of the + Request, or correspond to a legacy or Expanded Nak (see Section + 5.3) indicating that a Request Type is unacceptable to the peer. + A peer MUST NOT send a Nak (legacy or expanded) in response to a + Request, after an initial non-Nak Response has been sent. An EAP + server receiving a Response not meeting these requirements MUST + silently discard it. + + Type-Data + + The Type-Data field varies with the Type of Request and the + associated Response. + +4.2. Success and Failure + + The Success packet is sent by the authenticator to the peer after + completion of an EAP authentication method (Type 4 or greater) to + indicate that the peer has authenticated successfully to the + authenticator. The authenticator MUST transmit an EAP packet with + the Code field set to 3 (Success). If the authenticator cannot + authenticate the peer (unacceptable Responses to one or more + Requests), then after unsuccessful completion of the EAP method in + progress, the implementation MUST transmit an EAP packet with the + + + +Aboba, et al. Standards Track [Page 23] + +RFC 3748 EAP June 2004 + + + Code field set to 4 (Failure). An authenticator MAY wish to issue + multiple Requests before sending a Failure response in order to allow + for human typing mistakes. Success and Failure packets MUST NOT + contain additional data. + + Success and Failure packets MUST NOT be sent by an EAP authenticator + if the specification of the given method does not explicitly permit + the method to finish at that point. A peer EAP implementation + receiving a Success or Failure packet where sending one is not + explicitly permitted MUST silently discard it. By default, an EAP + peer MUST silently discard a "canned" Success packet (a Success + packet sent immediately upon connection). This ensures that a rogue + authenticator will not be able to bypass mutual authentication by + sending a Success packet prior to conclusion of the EAP method + conversation. + + Implementation Note: Because the Success and Failure packets are not + acknowledged, they are not retransmitted by the authenticator, and + may be potentially lost. A peer MUST allow for this circumstance as + described in this note. See also Section 3.4 for guidance on the + processing of lower layer success and failure indications. + + As described in Section 2.1, only a single EAP authentication method + is allowed within an EAP conversation. EAP methods may implement + result indications. After the authenticator sends a failure result + indication to the peer, regardless of the response from the peer, it + MUST subsequently send a Failure packet. After the authenticator + sends a success result indication to the peer and receives a success + result indication from the peer, it MUST subsequently send a Success + packet. + + On the peer, once the method completes unsuccessfully (that is, + either the authenticator sends a failure result indication, or the + peer decides that it does not want to continue the conversation, + possibly after sending a failure result indication), the peer MUST + terminate the conversation and indicate failure to the lower layer. + The peer MUST silently discard Success packets and MAY silently + discard Failure packets. As a result, loss of a Failure packet need + not result in a timeout. + + On the peer, after success result indications have been exchanged by + both sides, a Failure packet MUST be silently discarded. The peer + MAY, in the event that an EAP Success is not received, conclude that + the EAP Success packet was lost and that authentication concluded + successfully. + + + + + + +Aboba, et al. Standards Track [Page 24] + +RFC 3748 EAP June 2004 + + + If the authenticator has not sent a result indication, and the peer + is willing to continue the conversation, the peer waits for a Success + or Failure packet once the method completes, and MUST NOT silently + discard either of them. In the event that neither a Success nor + Failure packet is received, the peer SHOULD terminate the + conversation to avoid lengthy timeouts in case the lost packet was an + EAP Failure. + + If the peer attempts to authenticate to the authenticator and fails + to do so, the authenticator MUST send a Failure packet and MUST NOT + grant access by sending a Success packet. However, an authenticator + MAY omit having the peer authenticate to it in situations where + limited access is offered (e.g., guest access). In this case, the + authenticator MUST send a Success packet. + + Where the peer authenticates successfully to the authenticator, but + the authenticator does not send a result indication, the + authenticator MAY deny access by sending a Failure packet where the + peer is not currently authorized for network access. + + A summary of the Success and Failure packet format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 3 for Success + 4 for Failure + + Identifier + + The Identifier field is one octet and aids in matching replies to + Responses. The Identifier field MUST match the Identifier field + of the Response packet that it is sent in response to. + + Length + + 4 + + + + + + + + +Aboba, et al. Standards Track [Page 25] + +RFC 3748 EAP June 2004 + + +4.3. Retransmission Behavior + + Because the authentication process will often involve user input, + some care must be taken when deciding upon retransmission strategies + and authentication timeouts. By default, where EAP is run over an + unreliable lower layer, the EAP retransmission timer SHOULD be + dynamically estimated. A maximum of 3-5 retransmissions is + suggested. + + When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as + within [PIC]), the authenticator retransmission timer SHOULD be set + to an infinite value, so that retransmissions do not occur at the EAP + layer. The peer may still maintain a timeout value so as to avoid + waiting indefinitely for a Request. + + Where the authentication process requires user input, the measured + round trip times may be determined by user responsiveness rather than + network characteristics, so that dynamic RTO estimation may not be + helpful. Instead, the retransmission timer SHOULD be set so as to + provide sufficient time for the user to respond, with longer timeouts + required in certain cases, such as where Token Cards (see Section + 5.6) are involved. + + In order to provide the EAP authenticator with guidance as to the + appropriate timeout value, a hint can be communicated to the + authenticator by the backend authentication server (such as via the + RADIUS Session-Timeout attribute). + + In order to dynamically estimate the EAP retransmission timer, the + algorithms for the estimation of SRTT, RTTVAR, and RTO described in + [RFC2988] are RECOMMENDED, including use of Karn's algorithm, with + the following potential modifications: + + [a] In order to avoid synchronization behaviors that can occur with + fixed timers among distributed systems, the retransmission timer + is calculated with a jitter by using the RTO value and randomly + adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative + calculations to create jitter MAY be used. These MUST be + pseudo-random. For a discussion of pseudo-random number + generation, see [RFC1750]. + + [b] When EAP is transported over a single link (as opposed to over + the Internet), smaller values of RTOinitial, RTOmin, and RTOmax + MAY be used. Recommended values are RTOinitial=1 second, + RTOmin=200ms, and RTOmax=20 seconds. + + + + + + +Aboba, et al. Standards Track [Page 26] + +RFC 3748 EAP June 2004 + + + [c] When EAP is transported over a single link (as opposed to over + the Internet), estimates MAY be done on a per-authenticator + basis, rather than a per-session basis. This enables the + retransmission estimate to make the most use of information on + link-layer behavior. + + [d] An EAP implementation MAY clear SRTT and RTTVAR after backing off + the timer multiple times, as it is likely that the current SRTT + and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are + cleared, they should be initialized with the next RTT sample + taken as described in [RFC2988] equation 2.2. + +5. Initial EAP Request/Response Types + + This section defines the initial set of EAP Types used in Request/ + Response exchanges. More Types may be defined in future documents. + The Type field is one octet and identifies the structure of an EAP + Request or Response packet. The first 3 Types are considered special + case Types. + + The remaining Types define authentication exchanges. Nak (Type 3) or + Expanded Nak (Type 254) are valid only for Response packets, they + MUST NOT be sent in a Request. + + All EAP implementations MUST support Types 1-4, which are defined in + this document, and SHOULD support Type 254. Implementations MAY + support other Types defined here or in future RFCs. + + 1 Identity + 2 Notification + 3 Nak (Response only) + 4 MD5-Challenge + 5 One Time Password (OTP) + 6 Generic Token Card (GTC) + 254 Expanded Types + 255 Experimental use + + EAP methods MAY support authentication based on shared secrets. If + the shared secret is a passphrase entered by the user, + implementations MAY support entering passphrases with non-ASCII + characters. In this case, the input should be processed using an + appropriate stringprep [RFC3454] profile, and encoded in octets using + UTF-8 encoding [RFC2279]. A preliminary version of a possible + stringprep profile is described in [SASLPREP]. + + + + + + + +Aboba, et al. Standards Track [Page 27] + +RFC 3748 EAP June 2004 + + +5.1. Identity + + Description + + The Identity Type is used to query the identity of the peer. + Generally, the authenticator will issue this as the initial + Request. An optional displayable message MAY be included to + prompt the peer in the case where there is an expectation of + interaction with a user. A Response of Type 1 (Identity) SHOULD + be sent in Response to a Request with a Type of 1 (Identity). + + Some EAP implementations piggy-back various options into the + Identity Request after a NUL-character. By default, an EAP + implementation SHOULD NOT assume that an Identity Request or + Response can be larger than 1020 octets. + + It is RECOMMENDED that the Identity Response be used primarily for + routing purposes and selecting which EAP method to use. EAP + Methods SHOULD include a method-specific mechanism for obtaining + the identity, so that they do not have to rely on the Identity + Response. Identity Requests and Responses are sent in cleartext, + so an attacker may snoop on the identity, or even modify or spoof + identity exchanges. To address these threats, it is preferable + for an EAP method to include an identity exchange that supports + per-packet authentication, integrity and replay protection, and + confidentiality. The Identity Response may not be the appropriate + identity for the method; it may have been truncated or obfuscated + so as to provide privacy, or it may have been decorated for + routing purposes. Where the peer is configured to only accept + authentication methods supporting protected identity exchanges, + the peer MAY provide an abbreviated Identity Response (such as + omitting the peer-name portion of the NAI [RFC2486]). For further + discussion of identity protection, see Section 7.3. + + Implementation Note: The peer MAY obtain the Identity via user input. + It is suggested that the authenticator retry the Identity Request in + the case of an invalid Identity or authentication failure to allow + for potential typos on the part of the user. It is suggested that + the Identity Request be retried a minimum of 3 times before + terminating the authentication. The Notification Request MAY be used + to indicate an invalid authentication attempt prior to transmitting a + new Identity Request (optionally, the failure MAY be indicated within + the message of the new Identity Request itself). + + + + + + + + +Aboba, et al. Standards Track [Page 28] + +RFC 3748 EAP June 2004 + + + Type + + 1 + + Type-Data + + This field MAY contain a displayable message in the Request, + containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where + the Request contains a null, only the portion of the field prior + to the null is displayed. If the Identity is unknown, the + Identity Response field should be zero bytes in length. The + Identity Response field MUST NOT be null terminated. In all + cases, the length of the Type-Data field is derived from the + Length field of the Request/Response packet. + + Security Claims (see Section 7.2): + + Auth. mechanism: None + Ciphersuite negotiation: No + Mutual authentication: No + Integrity protection: No + Replay protection: No + Confidentiality: No + Key derivation: No + Key strength: N/A + Dictionary attack prot.: N/A + Fast reconnect: No + Crypt. binding: N/A + Session independence: N/A + Fragmentation: No + Channel binding: No + +5.2. Notification + + Description + + The Notification Type is optionally used to convey a displayable + message from the authenticator to the peer. An authenticator MAY + send a Notification Request to the peer at any time when there is + no outstanding Request, prior to completion of an EAP + authentication method. The peer MUST respond to a Notification + Request with a Notification Response unless the EAP authentication + method specification prohibits the use of Notification messages. + In any case, a Nak Response MUST NOT be sent in response to a + Notification Request. Note that the default maximum length of a + Notification Request is 1020 octets. By default, this leaves at + most 1015 octets for the human readable message. + + + + +Aboba, et al. Standards Track [Page 29] + +RFC 3748 EAP June 2004 + + + An EAP method MAY indicate within its specification that + Notification messages must not be sent during that method. In + this case, the peer MUST silently discard Notification Requests + from the point where an initial Request for that Type is answered + with a Response of the same Type. + + The peer SHOULD display this message to the user or log it if it + cannot be displayed. The Notification Type is intended to provide + an acknowledged notification of some imperative nature, but it is + not an error indication, and therefore does not change the state + of the peer. Examples include a password with an expiration time + that is about to expire, an OTP sequence integer which is nearing + 0, an authentication failure warning, etc. In most circumstances, + Notification should not be required. + + Type + + 2 + + Type-Data + + The Type-Data field in the Request contains a displayable message + greater than zero octets in length, containing UTF-8 encoded ISO + 10646 characters [RFC2279]. The length of the message is + determined by the Length field of the Request packet. The message + MUST NOT be null terminated. A Response MUST be sent in reply to + the Request with a Type field of 2 (Notification). The Type-Data + field of the Response is zero octets in length. The Response + should be sent immediately (independent of how the message is + displayed or logged). + + Security Claims (see Section 7.2): + + Auth. mechanism: None + Ciphersuite negotiation: No + Mutual authentication: No + Integrity protection: No + Replay protection: No + Confidentiality: No + Key derivation: No + Key strength: N/A + Dictionary attack prot.: N/A + Fast reconnect: No + Crypt. binding: N/A + Session independence: N/A + Fragmentation: No + Channel binding: No + + + + +Aboba, et al. Standards Track [Page 30] + +RFC 3748 EAP June 2004 + + +5.3. Nak + +5.3.1. Legacy Nak + + Description + + The legacy Nak Type is valid only in Response messages. It is + sent in reply to a Request where the desired authentication Type + is unacceptable. Authentication Types are numbered 4 and above. + The Response contains one or more authentication Types desired by + the Peer. Type zero (0) is used to indicate that the sender has + no viable alternatives, and therefore the authenticator SHOULD NOT + send another Request after receiving a Nak Response containing a + zero value. + + Since the legacy Nak Type is valid only in Responses and has very + limited functionality, it MUST NOT be used as a general purpose + error indication, such as for communication of error messages, or + negotiation of parameters specific to a particular EAP method. + + Code + + 2 for Response. + + Identifier + + The Identifier field is one octet and aids in matching Responses + with Requests. The Identifier field of a legacy Nak Response MUST + match the Identifier field of the Request packet that it is sent + in response to. + + Length + + >=6 + + Type + + 3 + + Type-Data + + Where a peer receives a Request for an unacceptable authentication + Type (4-253,255), or a peer lacking support for Expanded Types + receives a Request for Type 254, a Nak Response (Type 3) MUST be + sent. The Type-Data field of the Nak Response (Type 3) MUST + contain one or more octets indicating the desired authentication + Type(s), one octet per Type, or the value zero (0) to indicate no + proposed alternative. A peer supporting Expanded Types that + + + +Aboba, et al. Standards Track [Page 31] + +RFC 3748 EAP June 2004 + + + receives a Request for an unacceptable authentication Type (4-253, + 255) MAY include the value 254 in the Nak Response (Type 3) to + indicate the desire for an Expanded authentication Type. If the + authenticator can accommodate this preference, it will respond + with an Expanded Type Request (Type 254). + + Security Claims (see Section 7.2): + + Auth. mechanism: None + Ciphersuite negotiation: No + Mutual authentication: No + Integrity protection: No + Replay protection: No + Confidentiality: No + Key derivation: No + Key strength: N/A + Dictionary attack prot.: N/A + Fast reconnect: No + Crypt. binding: N/A + Session independence: N/A + Fragmentation: No + Channel binding: No + + +5.3.2. Expanded Nak + + Description + + The Expanded Nak Type is valid only in Response messages. It MUST + be sent only in reply to a Request of Type 254 (Expanded Type) + where the authentication Type is unacceptable. The Expanded Nak + Type uses the Expanded Type format itself, and the Response + contains one or more authentication Types desired by the peer, all + in Expanded Type format. Type zero (0) is used to indicate that + the sender has no viable alternatives. The general format of the + Expanded Type is described in Section 5.7. + + Since the Expanded Nak Type is valid only in Responses and has + very limited functionality, it MUST NOT be used as a general + purpose error indication, such as for communication of error + messages, or negotiation of parameters specific to a particular + EAP method. + + Code + + 2 for Response. + + + + + +Aboba, et al. Standards Track [Page 32] + +RFC 3748 EAP June 2004 + + + Identifier + + The Identifier field is one octet and aids in matching Responses + with Requests. The Identifier field of an Expanded Nak Response + MUST match the Identifier field of the Request packet that it is + sent in response to. + + Length + + >=20 + + Type + + 254 + + Vendor-Id + + 0 (IETF) + + Vendor-Type + + 3 (Nak) + + Vendor-Data + + The Expanded Nak Type is only sent when the Request contains an + Expanded Type (254) as defined in Section 5.7. The Vendor-Data + field of the Nak Response MUST contain one or more authentication + Types (4 or greater), all in expanded format, 8 octets per Type, + or the value zero (0), also in Expanded Type format, to indicate + no proposed alternative. The desired authentication Types may + include a mixture of Vendor-Specific and IETF Types. For example, + an Expanded Nak Response indicating a preference for OTP (Type 5), + and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as + follows: + + + + + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 33] + +RFC 3748 EAP June 2004 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | Identifier | Length=28 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=254 | 0 (IETF) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 3 (Nak) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=254 | 0 (IETF) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 5 (OTP) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=254 | 20 (MIT) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 6 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + An Expanded Nak Response indicating a no desired alternative would + appear as follows: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | Identifier | Length=20 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=254 | 0 (IETF) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 3 (Nak) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type=254 | 0 (IETF) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 (No alternative) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Security Claims (see Section 7.2): + + Auth. mechanism: None + Ciphersuite negotiation: No + Mutual authentication: No + Integrity protection: No + Replay protection: No + Confidentiality: No + Key derivation: No + Key strength: N/A + Dictionary attack prot.: N/A + Fast reconnect: No + Crypt. binding: N/A + + + +Aboba, et al. Standards Track [Page 34] + +RFC 3748 EAP June 2004 + + + Session independence: N/A + Fragmentation: No + Channel binding: No + + +5.4. MD5-Challenge + + Description + + The MD5-Challenge Type is analogous to the PPP CHAP protocol + [RFC1994] (with MD5 as the specified algorithm). The Request + contains a "challenge" message to the peer. A Response MUST be + sent in reply to the Request. The Response MAY be either of Type + 4 (MD5-Challenge), Nak (Type 3), or Expanded Nak (Type 254). The + Nak reply indicates the peer's desired authentication Type(s). + EAP peer and EAP server implementations MUST support the MD5- + Challenge mechanism. An authenticator that supports only pass- + through MUST allow communication with a backend authentication + server that is capable of supporting MD5-Challenge, although the + EAP authenticator implementation need not support MD5-Challenge + itself. However, if the EAP authenticator can be configured to + authenticate peers locally (e.g., not operate in pass-through), + then the requirement for support of the MD5-Challenge mechanism + applies. + + Note that the use of the Identifier field in the MD5-Challenge + Type is different from that described in [RFC1994]. EAP allows + for retransmission of MD5-Challenge Request packets, while + [RFC1994] states that both the Identifier and Challenge fields + MUST change each time a Challenge (the CHAP equivalent of the + MD5-Challenge Request packet) is sent. + + Note: [RFC1994] treats the shared secret as an octet string, and + does not specify how it is entered into the system (or if it is + handled by the user at all). EAP MD5-Challenge implementations + MAY support entering passphrases with non-ASCII characters. See + Section 5 for instructions how the input should be processed and + encoded into octets. + + Type + + 4 + + Type-Data + + The contents of the Type-Data field is summarized below. For + reference on the use of these fields, see the PPP Challenge + Handshake Authentication Protocol [RFC1994]. + + + +Aboba, et al. Standards Track [Page 35] + +RFC 3748 EAP June 2004 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value-Size | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Name ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Security Claims (see Section 7.2): + + Auth. mechanism: Password or pre-shared key. + Ciphersuite negotiation: No + Mutual authentication: No + Integrity protection: No + Replay protection: No + Confidentiality: No + Key derivation: No + Key strength: N/A + Dictionary attack prot.: No + Fast reconnect: No + Crypt. binding: N/A + Session independence: N/A + Fragmentation: No + Channel binding: No + +5.5. One-Time Password (OTP) + + Description + + The One-Time Password system is defined in "A One-Time Password + System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The + Request contains an OTP challenge in the format described in + [RFC2289]. A Response MUST be sent in reply to the Request. The + Response MUST be of Type 5 (OTP), Nak (Type 3), or Expanded Nak + (Type 254). The Nak Response indicates the peer's desired + authentication Type(s). The EAP OTP method is intended for use + with the One-Time Password system only, and MUST NOT be used to + provide support for cleartext passwords. + + Type + + 5 + + + + + + + + + +Aboba, et al. Standards Track [Page 36] + +RFC 3748 EAP June 2004 + + + Type-Data + + The Type-Data field contains the OTP "challenge" as a displayable + message in the Request. In the Response, this field is used for + the 6 words from the OTP dictionary [RFC2289]. The messages MUST + NOT be null terminated. The length of the field is derived from + the Length field of the Request/Reply packet. + + Note: [RFC2289] does not specify how the secret pass-phrase is + entered by the user, or how the pass-phrase is converted into + octets. EAP OTP implementations MAY support entering passphrases + with non-ASCII characters. See Section 5 for instructions on how + the input should be processed and encoded into octets. + + Security Claims (see Section 7.2): + + Auth. mechanism: One-Time Password + Ciphersuite negotiation: No + Mutual authentication: No + Integrity protection: No + Replay protection: Yes + Confidentiality: No + Key derivation: No + Key strength: N/A + Dictionary attack prot.: No + Fast reconnect: No + Crypt. binding: N/A + Session independence: N/A + Fragmentation: No + Channel binding: No + + +5.6. Generic Token Card (GTC) + + Description + + The Generic Token Card Type is defined for use with various Token + Card implementations which require user input. The Request + contains a displayable message and the Response contains the Token + Card information necessary for authentication. Typically, this + would be information read by a user from the Token card device and + entered as ASCII text. A Response MUST be sent in reply to the + Request. The Response MUST be of Type 6 (GTC), Nak (Type 3), or + Expanded Nak (Type 254). The Nak Response indicates the peer's + desired authentication Type(s). The EAP GTC method is intended + for use with the Token Cards supporting challenge/response + + + + + +Aboba, et al. Standards Track [Page 37] + +RFC 3748 EAP June 2004 + + + authentication and MUST NOT be used to provide support for + cleartext passwords in the absence of a protected tunnel with + server authentication. + + Type + + 6 + + Type-Data + + The Type-Data field in the Request contains a displayable message + greater than zero octets in length. The length of the message is + determined by the Length field of the Request packet. The message + MUST NOT be null terminated. A Response MUST be sent in reply to + the Request with a Type field of 6 (Generic Token Card). The + Response contains data from the Token Card required for + authentication. The length of the data is determined by the + Length field of the Response packet. + + EAP GTC implementations MAY support entering a response with non- + ASCII characters. See Section 5 for instructions how the input + should be processed and encoded into octets. + + Security Claims (see Section 7.2): + + Auth. mechanism: Hardware token. + Ciphersuite negotiation: No + Mutual authentication: No + Integrity protection: No + Replay protection: No + Confidentiality: No + Key derivation: No + Key strength: N/A + Dictionary attack prot.: No + Fast reconnect: No + Crypt. binding: N/A + Session independence: N/A + Fragmentation: No + Channel binding: No + + +5.7. Expanded Types + + Description + + Since many of the existing uses of EAP are vendor-specific, the + Expanded method Type is available to allow vendors to support + their own Expanded Types not suitable for general usage. + + + +Aboba, et al. Standards Track [Page 38] + +RFC 3748 EAP June 2004 + + + The Expanded Type is also used to expand the global Method Type + space beyond the original 255 values. A Vendor-Id of 0 maps the + original 255 possible Types onto a space of 2^32-1 possible Types. + (Type 0 is only used in a Nak Response to indicate no acceptable + alternative). + + An implementation that supports the Expanded attribute MUST treat + EAP Types that are less than 256 equivalently, whether they appear + as a single octet or as the 32-bit Vendor-Type within an Expanded + Type where Vendor-Id is 0. Peers not equipped to interpret the + Expanded Type MUST send a Nak as described in Section 5.3.1, and + negotiate a more suitable authentication method. + + A summary of the Expanded Type format is shown below. The fields + are transmitted from left to right. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Vendor-Id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 254 for Expanded Type + + Vendor-Id + + The Vendor-Id is 3 octets and represents the SMI Network + Management Private Enterprise Code of the Vendor in network byte + order, as allocated by IANA. A Vendor-Id of zero is reserved for + use by the IETF in providing an expanded global EAP Type space. + + Vendor-Type + + The Vendor-Type field is four octets and represents the vendor- + specific method Type. + + If the Vendor-Id is zero, the Vendor-Type field is an extension + and superset of the existing namespace for EAP Types. The first + 256 Types are reserved for compatibility with single-octet EAP + Types that have already been assigned or may be assigned in the + future. Thus, EAP Types from 0 through 255 are semantically + identical, whether they appear as single octet EAP Types or as + + + +Aboba, et al. Standards Track [Page 39] + +RFC 3748 EAP June 2004 + + + Vendor-Types when Vendor-Id is zero. There is one exception to + this rule: Expanded Nak and Legacy Nak packets share the same + Type, but must be treated differently because they have a + different format. + + Vendor-Data + + The Vendor-Data field is defined by the vendor. Where a Vendor-Id + of zero is present, the Vendor-Data field will be used for + transporting the contents of EAP methods of Types defined by the + IETF. + +5.8. Experimental + + Description + + The Experimental Type has no fixed format or content. It is + intended for use when experimenting with new EAP Types. This Type + is intended for experimental and testing purposes. No guarantee + is made for interoperability between peers using this Type, as + outlined in [RFC3692]. + + Type + + 255 + + Type-Data + + Undefined + +6. IANA Considerations + + This section provides guidance to the Internet Assigned Numbers + Authority (IANA) regarding registration of values related to the EAP + protocol, in accordance with BCP 26, [RFC2434]. + + There are two name spaces in EAP that require registration: Packet + Codes and method Types. + + EAP is not intended as a general-purpose protocol, and allocations + SHOULD NOT be made for purposes unrelated to authentication. + + The following terms are used here with the meanings defined in BCP + 26: "name space", "assigned value", "registration". + + The following policies are used here with the meanings defined in BCP + 26: "Private Use", "First Come First Served", "Expert Review", + "Specification Required", "IETF Consensus", "Standards Action". + + + +Aboba, et al. Standards Track [Page 40] + +RFC 3748 EAP June 2004 + + + For registration requests where a Designated Expert should be + consulted, the responsible IESG area director should appoint the + Designated Expert. The intention is that any allocation will be + accompanied by a published RFC. But in order to allow for the + allocation of values prior to the RFC being approved for publication, + the Designated Expert can approve allocations once it seems clear + that an RFC will be published. The Designated expert will post a + request to the EAP WG mailing list (or a successor designated by the + Area Director) for comment and review, including an Internet-Draft. + Before a period of 30 days has passed, the Designated Expert will + either approve or deny the registration request and publish a notice + of the decision to the EAP WG mailing list or its successor, as well + as informing IANA. A denial notice must be justified by an + explanation, and in the cases where it is possible, concrete + suggestions on how the request can be modified so as to become + acceptable should be provided. + +6.1. Packet Codes + + Packet Codes have a range from 1 to 255, of which 1-4 have been + allocated. Because a new Packet Code has considerable impact on + interoperability, a new Packet Code requires Standards Action, and + should be allocated starting at 5. + +6.2. Method Types + + The original EAP method Type space has a range from 1 to 255, and is + the scarcest resource in EAP, and thus must be allocated with care. + Method Types 1-45 have been allocated, with 20 available for re-use. + Method Types 20 and 46-191 may be allocated on the advice of a + Designated Expert, with Specification Required. + + Allocation of blocks of method Types (more than one for a given + purpose) should require IETF Consensus. EAP Type Values 192-253 are + reserved and allocation requires Standards Action. + + Method Type 254 is allocated for the Expanded Type. Where the + Vendor-Id field is non-zero, the Expanded Type is used for functions + specific only to one vendor's implementation of EAP, where no + interoperability is deemed useful. When used with a Vendor-Id of + zero, method Type 254 can also be used to provide for an expanded + IETF method Type space. Method Type values 256-4294967295 may be + allocated after Type values 1-191 have been allocated, on the advice + of a Designated Expert, with Specification Required. + + Method Type 255 is allocated for Experimental use, such as testing of + new EAP methods before a permanent Type is allocated. + + + + +Aboba, et al. Standards Track [Page 41] + +RFC 3748 EAP June 2004 + + +7. Security Considerations + + This section defines a generic threat model as well as the EAP method + security claims mitigating those threats. + + It is expected that the generic threat model and corresponding + security claims will used to define EAP method requirements for use + in specific environments. An example of such a requirements analysis + is provided in [IEEE-802.11i-req]. A security claims section is + required in EAP method specifications, so that EAP methods can be + evaluated against the requirements. + +7.1. Threat Model + + EAP was developed for use with PPP [RFC1661] and was later adapted + for use in wired IEEE 802 networks [IEEE-802] in [IEEE-802.1X]. + Subsequently, EAP has been proposed for use on wireless LAN networks + and over the Internet. In all these situations, it is possible for + an attacker to gain access to links over which EAP packets are + transmitted. For example, attacks on telephone infrastructure are + documented in [DECEPTION]. + + An attacker with access to the link may carry out a number of + attacks, including: + + [1] An attacker may try to discover user identities by snooping + authentication traffic. + + [2] An attacker may try to modify or spoof EAP packets. + + [3] An attacker may launch denial of service attacks by spoofing + lower layer indications or Success/Failure packets, by replaying + EAP packets, or by generating packets with overlapping + Identifiers. + + [4] An attacker may attempt to recover the pass-phrase by mounting + an offline dictionary attack. + + [5] An attacker may attempt to convince the peer to connect to an + untrusted network by mounting a man-in-the-middle attack. + + [6] An attacker may attempt to disrupt the EAP negotiation in order + cause a weak authentication method to be selected. + + [7] An attacker may attempt to recover keys by taking advantage of + weak key derivation techniques used within EAP methods. + + + + + +Aboba, et al. Standards Track [Page 42] + +RFC 3748 EAP June 2004 + + + [8] An attacker may attempt to take advantage of weak ciphersuites + subsequently used after the EAP conversation is complete. + + [9] An attacker may attempt to perform downgrading attacks on lower + layer ciphersuite negotiation in order to ensure that a weaker + ciphersuite is used subsequently to EAP authentication. + + [10] An attacker acting as an authenticator may provide incorrect + information to the EAP peer and/or server via out-of-band + mechanisms (such as via a AAA or lower layer protocol). This + includes impersonating another authenticator, or providing + inconsistent information to the peer and EAP server. + + Depending on the lower layer, these attacks may be carried out + without requiring physical proximity. Where EAP is used over + wireless networks, EAP packets may be forwarded by authenticators + (e.g., pre-authentication) so that the attacker need not be within + the coverage area of an authenticator in order to carry out an attack + on it or its peers. Where EAP is used over the Internet, attacks may + be carried out at an even greater distance. + +7.2. Security Claims + + In order to clearly articulate the security provided by an EAP + method, EAP method specifications MUST include a Security Claims + section, including the following declarations: + + [a] Mechanism. This is a statement of the authentication technology: + certificates, pre-shared keys, passwords, token cards, etc. + + [b] Security claims. This is a statement of the claimed security + properties of the method, using terms defined in Section 7.2.1: + mutual authentication, integrity protection, replay protection, + confidentiality, key derivation, dictionary attack resistance, + fast reconnect, cryptographic binding. The Security Claims + section of an EAP method specification SHOULD provide + justification for the claims that are made. This can be + accomplished by including a proof in an Appendix, or including a + reference to a proof. + + [c] Key strength. If the method derives keys, then the effective key + strength MUST be estimated. This estimate is meant for potential + users of the method to determine if the keys produced are strong + enough for the intended application. + + + + + + + +Aboba, et al. Standards Track [Page 43] + +RFC 3748 EAP June 2004 + + + The effective key strength SHOULD be stated as a number of bits, + defined as follows: If the effective key strength is N bits, the + best currently known methods to recover the key (with non- + negligible probability) require, on average, an effort comparable + to 2^(N-1) operations of a typical block cipher. The statement + SHOULD be accompanied by a short rationale, explaining how this + number was derived. This explanation SHOULD include the + parameters required to achieve the stated key strength based on + current knowledge of the algorithms. + + (Note: Although it is difficult to define what "comparable + effort" and "typical block cipher" exactly mean, reasonable + approximations are sufficient here. Refer to e.g. [SILVERMAN] + for more discussion.) + + The key strength depends on the methods used to derive the keys. + For instance, if keys are derived from a shared secret (such as a + password or a long-term secret), and possibly some public + information such as nonces, the effective key strength is limited + by the strength of the long-term secret (assuming that the + derivation procedure is computationally simple). To take another + example, when using public key algorithms, the strength of the + symmetric key depends on the strength of the public keys used. + + [d] Description of key hierarchy. EAP methods deriving keys MUST + either provide a reference to a key hierarchy specification, or + describe how Master Session Keys (MSKs) and Extended Master + Session Keys (EMSKs) are to be derived. + + [e] Indication of vulnerabilities. In addition to the security + claims that are made, the specification MUST indicate which of + the security claims detailed in Section 7.2.1 are NOT being made. + +7.2.1. Security Claims Terminology for EAP Methods + + These terms are used to describe the security properties of EAP + methods: + + Protected ciphersuite negotiation + This refers to the ability of an EAP method to negotiate the + ciphersuite used to protect the EAP conversation, as well as to + integrity protect the negotiation. It does not refer to the + ability to negotiate the ciphersuite used to protect data. + + + + + + + + +Aboba, et al. Standards Track [Page 44] + +RFC 3748 EAP June 2004 + + + Mutual authentication + This refers to an EAP method in which, within an interlocked + exchange, the authenticator authenticates the peer and the peer + authenticates the authenticator. Two independent one-way methods, + running in opposite directions do not provide mutual + authentication as defined here. + + Integrity protection + This refers to providing data origin authentication and protection + against unauthorized modification of information for EAP packets + (including EAP Requests and Responses). When making this claim, a + method specification MUST describe the EAP packets and fields + within the EAP packet that are protected. + + Replay protection + This refers to protection against replay of an EAP method or its + messages, including success and failure result indications. + + Confidentiality + This refers to encryption of EAP messages, including EAP Requests + and Responses, and success and failure result indications. A + method making this claim MUST support identity protection (see + Section 7.3). + + Key derivation + This refers to the ability of the EAP method to derive exportable + keying material, such as the Master Session Key (MSK), and + Extended Master Session Key (EMSK). The MSK is used only for + further key derivation, not directly for protection of the EAP + conversation or subsequent data. Use of the EMSK is reserved. + + Key strength + If the effective key strength is N bits, the best currently known + methods to recover the key (with non-negligible probability) + require, on average, an effort comparable to 2^(N-1) operations of + a typical block cipher. + + Dictionary attack resistance + Where password authentication is used, passwords are commonly + selected from a small set (as compared to a set of N-bit keys), + which raises a concern about dictionary attacks. A method may be + said to provide protection against dictionary attacks if, when it + uses a password as a secret, the method does not allow an offline + attack that has a work factor based on the number of passwords in + an attacker's dictionary. + + + + + + +Aboba, et al. Standards Track [Page 45] + +RFC 3748 EAP June 2004 + + + Fast reconnect + The ability, in the case where a security association has been + previously established, to create a new or refreshed security + association more efficiently or in a smaller number of round- + trips. + + Cryptographic binding + The demonstration of the EAP peer to the EAP server that a single + entity has acted as the EAP peer for all methods executed within a + tunnel method. Binding MAY also imply that the EAP server + demonstrates to the peer that a single entity has acted as the EAP + server for all methods executed within a tunnel method. If + executed correctly, binding serves to mitigate man-in-the-middle + vulnerabilities. + + Session independence + The demonstration that passive attacks (such as capture of the EAP + conversation) or active attacks (including compromise of the MSK + or EMSK) does not enable compromise of subsequent or prior MSKs or + EMSKs. + + Fragmentation + This refers to whether an EAP method supports fragmentation and + reassembly. As noted in Section 3.1, EAP methods should support + fragmentation and reassembly if EAP packets can exceed the minimum + MTU of 1020 octets. + + Channel binding + The communication within an EAP method of integrity-protected + channel properties such as endpoint identifiers which can be + compared to values communicated via out of band mechanisms (such + as via a AAA or lower layer protocol). + + Note: This list of security claims is not exhaustive. Additional + properties, such as additional denial-of-service protection, may be + relevant as well. + +7.3. Identity Protection + + An Identity exchange is optional within the EAP conversation. + Therefore, it is possible to omit the Identity exchange entirely, or + to use a method-specific identity exchange once a protected channel + has been established. + + However, where roaming is supported as described in [RFC2607], it may + be necessary to locate the appropriate backend authentication server + before the authentication conversation can proceed. The realm + portion of the Network Access Identifier (NAI) [RFC2486] is typically + + + +Aboba, et al. Standards Track [Page 46] + +RFC 3748 EAP June 2004 + + + included within the EAP-Response/Identity in order to enable the + authentication exchange to be routed to the appropriate backend + authentication server. Therefore, while the peer-name portion of the + NAI may be omitted in the EAP-Response/Identity where proxies or + relays are present, the realm portion may be required. + + It is possible for the identity in the identity response to be + different from the identity authenticated by the EAP method. This + may be intentional in the case of identity privacy. An EAP method + SHOULD use the authenticated identity when making access control + decisions. + +7.4. Man-in-the-Middle Attacks + + Where EAP is tunneled within another protocol that omits peer + authentication, there exists a potential vulnerability to a man-in- + the-middle attack. For details, see [BINDING] and [MITM]. + + As noted in Section 2.1, EAP does not permit untunneled sequences of + authentication methods. Were a sequence of EAP authentication + methods to be permitted, the peer might not have proof that a single + entity has acted as the authenticator for all EAP methods within the + sequence. For example, an authenticator might terminate one EAP + method, then forward the next method in the sequence to another party + without the peer's knowledge or consent. Similarly, the + authenticator might not have proof that a single entity has acted as + the peer for all EAP methods within the sequence. + + Tunneling EAP within another protocol enables an attack by a rogue + EAP authenticator tunneling EAP to a legitimate server. Where the + tunneling protocol is used for key establishment but does not require + peer authentication, an attacker convincing a legitimate peer to + connect to it will be able to tunnel EAP packets to a legitimate + server, successfully authenticating and obtaining the key. This + allows the attacker to successfully establish itself as a man-in- + the-middle, gaining access to the network, as well as the ability to + decrypt data traffic between the legitimate peer and server. + + This attack may be mitigated by the following measures: + + [a] Requiring mutual authentication within EAP tunneling mechanisms. + + [b] Requiring cryptographic binding between the EAP tunneling + protocol and the tunneled EAP methods. Where cryptographic + binding is supported, a mechanism is also needed to protect + against downgrade attacks that would bypass it. For further + details on cryptographic binding, see [BINDING]. + + + + +Aboba, et al. Standards Track [Page 47] + +RFC 3748 EAP June 2004 + + + [c] Limiting the EAP methods authorized for use without protection, + based on peer and authenticator policy. + + [d] Avoiding the use of tunnels when a single, strong method is + available. + +7.5. Packet Modification Attacks + + While EAP methods may support per-packet data origin authentication, + integrity, and replay protection, support is not provided within the + EAP layer. + + Since the Identifier is only a single octet, it is easy to guess, + allowing an attacker to successfully inject or replay EAP packets. + An attacker may also modify EAP headers (Code, Identifier, Length, + Type) within EAP packets where the header is unprotected. This could + cause packets to be inappropriately discarded or misinterpreted. + + To protect EAP packets against modification, spoofing, or replay, + methods supporting protected ciphersuite negotiation, mutual + authentication, and key derivation, as well as integrity and replay + protection, are recommended. See Section 7.2.1 for definitions of + these security claims. + + Method-specific MICs may be used to provide protection. If a per- + packet MIC is employed within an EAP method, then peers, + authentication servers, and authenticators not operating in pass- + through mode MUST validate the MIC. MIC validation failures SHOULD + be logged. Whether a MIC validation failure is considered a fatal + error or not is determined by the EAP method specification. + + It is RECOMMENDED that methods providing integrity protection of EAP + packets include coverage of all the EAP header fields, including the + Code, Identifier, Length, Type, and Type-Data fields. + + Since EAP messages of Types Identity, Notification, and Nak do not + include their own MIC, it may be desirable for the EAP method MIC to + cover information contained within these messages, as well as the + header of each EAP message. + + To provide protection, EAP also may be encapsulated within a + protected channel created by protocols such as ISAKMP [RFC2408], as + is done in [IKEv2] or within TLS [RFC2246]. However, as noted in + Section 7.4, EAP tunneling may result in a man-in-the-middle + vulnerability. + + + + + + +Aboba, et al. Standards Track [Page 48] + +RFC 3748 EAP June 2004 + + + Existing EAP methods define message integrity checks (MICs) that + cover more than one EAP packet. For example, EAP-TLS [RFC2716] + defines a MIC over a TLS record that could be split into multiple + fragments; within the FINISHED message, the MIC is computed over + previous messages. Where the MIC covers more than one EAP packet, a + MIC validation failure is typically considered a fatal error. + + Within EAP-TLS [RFC2716], a MIC validation failure is treated as a + fatal error, since that is what is specified in TLS [RFC2246]. + However, it is also possible to develop EAP methods that support + per-packet MICs, and respond to verification failures by silently + discarding the offending packet. + + In this document, descriptions of EAP message handling assume that + per-packet MIC validation, where it occurs, is effectively performed + as though it occurs before sending any responses or changing the + state of the host which received the packet. + +7.6. Dictionary Attacks + + Password authentication algorithms such as EAP-MD5, MS-CHAPv1 + [RFC2433], and Kerberos V [RFC1510] are known to be vulnerable to + dictionary attacks. MS-CHAPv1 vulnerabilities are documented in + [PPTPv1]; MS-CHAPv2 vulnerabilities are documented in [PPTPv2]; + Kerberos vulnerabilities are described in [KRBATTACK], [KRBLIM], and + [KERB4WEAK]. + + In order to protect against dictionary attacks, authentication + methods resistant to dictionary attacks (as defined in Section 7.2.1) + are recommended. + + If an authentication algorithm is used that is known to be vulnerable + to dictionary attacks, then the conversation may be tunneled within a + protected channel in order to provide additional protection. + However, as noted in Section 7.4, EAP tunneling may result in a man- + in-the-middle vulnerability, and therefore dictionary attack + resistant methods are preferred. + +7.7. Connection to an Untrusted Network + + With EAP methods supporting one-way authentication, such as EAP-MD5, + the peer does not authenticate the authenticator, making the peer + vulnerable to attack by a rogue authenticator. Methods supporting + mutual authentication (as defined in Section 7.2.1) address this + vulnerability. + + In EAP there is no requirement that authentication be full duplex or + that the same protocol be used in both directions. It is perfectly + + + +Aboba, et al. Standards Track [Page 49] + +RFC 3748 EAP June 2004 + + + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + However, in general, completing a single unitary mutual + authentication is preferable to two one-way authentications, one in + each direction. This is because separate authentications that are + not bound cryptographically so as to demonstrate they are part of the + same session are subject to man-in-the-middle attacks, as discussed + in Section 7.4. + +7.8. Negotiation Attacks + + In a negotiation attack, the attacker attempts to convince the peer + and authenticator to negotiate a less secure EAP method. EAP does + not provide protection for Nak Response packets, although it is + possible for a method to include coverage of Nak Responses within a + method-specific MIC. + + Within or associated with each authenticator, it is not anticipated + that a particular named peer will support a choice of methods. This + would make the peer vulnerable to attacks that negotiate the least + secure method from among a set. Instead, for each named peer, there + SHOULD be an indication of exactly one method used to authenticate + that peer name. If a peer needs to make use of different + authentication methods under different circumstances, then distinct + identities SHOULD be employed, each of which identifies exactly one + authentication method. + +7.9. Implementation Idiosyncrasies + + The interaction of EAP with lower layers such as PPP and IEEE 802 are + highly implementation dependent. + + For example, upon failure of authentication, some PPP implementations + do not terminate the link, instead limiting traffic in Network-Layer + Protocols to a filtered subset, which in turn allows the peer the + opportunity to update secrets or send mail to the network + administrator indicating a problem. Similarly, while an + authentication failure will result in denied access to the controlled + port in [IEEE-802.1X], limited traffic may be permitted on the + uncontrolled port. + + In EAP there is no provision for retries of failed authentication. + However, in PPP the LCP state machine can renegotiate the + authentication protocol at any time, thus allowing a new attempt. + Similarly, in IEEE 802.1X the Supplicant or Authenticator can re- + authenticate at any time. It is recommended that any counters used + for authentication failure not be reset until after successful + authentication, or subsequent termination of the failed link. + + + +Aboba, et al. Standards Track [Page 50] + +RFC 3748 EAP June 2004 + + +7.10. Key Derivation + + It is possible for the peer and EAP server to mutually authenticate + and derive keys. In order to provide keying material for use in a + subsequently negotiated ciphersuite, an EAP method supporting key + derivation MUST export a Master Session Key (MSK) of at least 64 + octets, and an Extended Master Session Key (EMSK) of at least 64 + octets. EAP Methods deriving keys MUST provide for mutual + authentication between the EAP peer and the EAP Server. + + The MSK and EMSK MUST NOT be used directly to protect data; however, + they are of sufficient size to enable derivation of a AAA-Key + subsequently used to derive Transient Session Keys (TSKs) for use + with the selected ciphersuite. Each ciphersuite is responsible for + specifying how to derive the TSKs from the AAA-Key. + + The AAA-Key is derived from the keying material exported by the EAP + method (MSK and EMSK). This derivation occurs on the AAA server. In + many existing protocols that use EAP, the AAA-Key and MSK are + equivalent, but more complicated mechanisms are possible (see + [KEYFRAME] for details). + + EAP methods SHOULD ensure the freshness of the MSK and EMSK, even in + cases where one party may not have a high quality random number + generator. A RECOMMENDED method is for each party to provide a nonce + of at least 128 bits, used in the derivation of the MSK and EMSK. + + EAP methods export the MSK and EMSK, but not Transient Session Keys + so as to allow EAP methods to be ciphersuite and media independent. + Keying material exported by EAP methods MUST be independent of the + ciphersuite negotiated to protect data. + + Depending on the lower layer, EAP methods may run before or after + ciphersuite negotiation, so that the selected ciphersuite may not be + known to the EAP method. By providing keying material usable with + any ciphersuite, EAP methods can used with a wide range of + ciphersuites and media. + + In order to preserve algorithm independence, EAP methods deriving + keys SHOULD support (and document) the protected negotiation of the + ciphersuite used to protect the EAP conversation between the peer and + server. This is distinct from the ciphersuite negotiated between the + peer and authenticator, used to protect data. + + The strength of Transient Session Keys (TSKs) used to protect data is + ultimately dependent on the strength of keys generated by the EAP + method. If an EAP method cannot produce keying material of + sufficient strength, then the TSKs may be subject to a brute force + + + +Aboba, et al. Standards Track [Page 51] + +RFC 3748 EAP June 2004 + + + attack. In order to enable deployments requiring strong keys, EAP + methods supporting key derivation SHOULD be capable of generating an + MSK and EMSK, each with an effective key strength of at least 128 + bits. + + Methods supporting key derivation MUST demonstrate cryptographic + separation between the MSK and EMSK branches of the EAP key + hierarchy. Without violating a fundamental cryptographic assumption + (such as the non-invertibility of a one-way function), an attacker + recovering the MSK or EMSK MUST NOT be able to recover the other + quantity with a level of effort less than brute force. + + Non-overlapping substrings of the MSK MUST be cryptographically + separate from each other, as defined in Section 7.2.1. That is, + knowledge of one substring MUST NOT help in recovering some other + substring without breaking some hard cryptographic assumption. This + is required because some existing ciphersuites form TSKs by simply + splitting the AAA-Key to pieces of appropriate length. Likewise, + non-overlapping substrings of the EMSK MUST be cryptographically + separate from each other, and from substrings of the MSK. + + The EMSK is reserved for future use and MUST remain on the EAP peer + and EAP server where it is derived; it MUST NOT be transported to, or + shared with, additional parties, or used to derive any other keys. + (This restriction will be relaxed in a future document that specifies + how the EMSK can be used.) + + Since EAP does not provide for explicit key lifetime negotiation, EAP + peers, authenticators, and authentication servers MUST be prepared + for situations in which one of the parties discards the key state, + which remains valid on another party. + + This specification does not provide detailed guidance on how EAP + methods derive the MSK and EMSK, how the AAA-Key is derived from the + MSK and/or EMSK, or how the TSKs are derived from the AAA-Key. + + The development and validation of key derivation algorithms is + difficult, and as a result, EAP methods SHOULD re-use well + established and analyzed mechanisms for key derivation (such as those + specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing + new ones. EAP methods SHOULD also utilize well established and + analyzed mechanisms for MSK and EMSK derivation. Further details on + EAP Key Derivation are provided within [KEYFRAME]. + + + + + + + + +Aboba, et al. Standards Track [Page 52] + +RFC 3748 EAP June 2004 + + +7.11. Weak Ciphersuites + + If after the initial EAP authentication, data packets are sent + without per-packet authentication, integrity, and replay protection, + an attacker with access to the media can inject packets, "flip bits" + within existing packets, replay packets, or even hijack the session + completely. Without per-packet confidentiality, it is possible to + snoop data packets. + + To protect against data modification, spoofing, or snooping, it is + recommended that EAP methods supporting mutual authentication and key + derivation (as defined by Section 7.2.1) be used, along with lower + layers providing per-packet confidentiality, authentication, + integrity, and replay protection. + + Additionally, if the lower layer performs ciphersuite negotiation, it + should be understood that EAP does not provide by itself integrity + protection of that negotiation. Therefore, in order to avoid + downgrading attacks which would lead to weaker ciphersuites being + used, clients implementing lower layer ciphersuite negotiation SHOULD + protect against negotiation downgrading. + + This can be done by enabling users to configure which ciphersuites + are acceptable as a matter of security policy, or the ciphersuite + negotiation MAY be authenticated using keying material derived from + the EAP authentication and a MIC algorithm agreed upon in advance by + lower-layer peers. + +7.12. Link Layer + + There are reliability and security issues with link layer indications + in PPP, IEEE 802 LANs, and IEEE 802.11 wireless LANs: + + [a] PPP. In PPP, link layer indications such as LCP-Terminate (a + link failure indication) and NCP (a link success indication) are + not authenticated or integrity protected. They can therefore be + spoofed by an attacker with access to the link. + + [b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are + not authenticated or integrity protected. They can therefore be + spoofed by an attacker with access to the link. + + [c] IEEE 802.11. In IEEE 802.11, link layer indications include + Disassociate and Deauthenticate frames (link failure + indications), and the first message of the 4-way handshake (link + success indication). These messages are not authenticated or + integrity protected, and although they are not forwardable, they + are spoofable by an attacker within range. + + + +Aboba, et al. Standards Track [Page 53] + +RFC 3748 EAP June 2004 + + + In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3 + unicast data frames, and are therefore forwardable. This implies + that while EAPOL-Start and EAPOL-Logoff messages may be authenticated + and integrity protected, they can be spoofed by an authenticated + attacker far from the target when "pre-authentication" is enabled. + + In IEEE 802.11, a "link down" indication is an unreliable indication + of link failure, since wireless signal strength can come and go and + may be influenced by radio frequency interference generated by an + attacker. To avoid unnecessary resets, it is advisable to damp these + indications, rather than passing them directly to the EAP. Since EAP + supports retransmission, it is robust against transient connectivity + losses. + +7.13. Separation of Authenticator and Backend Authentication Server + + It is possible for the EAP peer and EAP server to mutually + authenticate and derive a AAA-Key for a ciphersuite used to protect + subsequent data traffic. This does not present an issue on the peer, + since the peer and EAP client reside on the same machine; all that is + required is for the client to derive the AAA-Key from the MSK and + EMSK exported by the EAP method, and to subsequently pass a Transient + Session Key (TSK) to the ciphersuite module. + + However, in the case where the authenticator and authentication + server reside on different machines, there are several implications + for security. + + [a] Authentication will occur between the peer and the authentication + server, not between the peer and the authenticator. This means + that it is not possible for the peer to validate the identity of + the authenticator that it is speaking to, using EAP alone. + + [b] As discussed in [RFC3579], the authenticator is dependent on the + AAA protocol in order to know the outcome of an authentication + conversation, and does not look at the encapsulated EAP packet + (if one is present) to determine the outcome. In practice, this + implies that the AAA protocol spoken between the authenticator + and authentication server MUST support per-packet authentication, + integrity, and replay protection. + + [c] After completion of the EAP conversation, where lower layer + security services such as per-packet confidentiality, + authentication, integrity, and replay protection will be enabled, + a secure association protocol SHOULD be run between the peer and + authenticator in order to provide mutual authentication between + + + + + +Aboba, et al. Standards Track [Page 54] + +RFC 3748 EAP June 2004 + + + the peer and authenticator, guarantee liveness of transient + session keys, provide protected ciphersuite and capabilities + negotiation for subsequent data, and synchronize key usage. + + [d] A AAA-Key derived from the MSK and/or EMSK negotiated between the + peer and authentication server MAY be transmitted to the + authenticator. Therefore, a mechanism needs to be provided to + transmit the AAA-Key from the authentication server to the + authenticator that needs it. The specification of the AAA-key + derivation, transport, and wrapping mechanisms is outside the + scope of this document. Further details on AAA-Key Derivation + are provided within [KEYFRAME]. + +7.14. Cleartext Passwords + + This specification does not define a mechanism for cleartext password + authentication. The omission is intentional. Use of cleartext + passwords would allow the password to be captured by an attacker with + access to a link over which EAP packets are transmitted. + + Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not + provide confidentiality, EAP packets may be subsequently encapsulated + for transport over the Internet where they may be captured by an + attacker. + + As a result, cleartext passwords cannot be securely used within EAP, + except where encapsulated within a protected tunnel with server + authentication. Some of the same risks apply to EAP methods without + dictionary attack resistance, as defined in Section 7.2.1. For + details, see Section 7.6. + +7.15. Channel Binding + + It is possible for a compromised or poorly implemented EAP + authenticator to communicate incorrect information to the EAP peer + and/or server. This may enable an authenticator to impersonate + another authenticator or communicate incorrect information via out- + of-band mechanisms (such as via a AAA or lower layer protocol). + + Where EAP is used in pass-through mode, the EAP peer typically does + not verify the identity of the pass-through authenticator, it only + verifies that the pass-through authenticator is trusted by the EAP + server. This creates a potential security vulnerability. + + Section 4.3.7 of [RFC3579] describes how an EAP pass-through + authenticator acting as a AAA client can be detected if it attempts + to impersonate another authenticator (such by sending incorrect NAS- + Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address + + + +Aboba, et al. Standards Track [Page 55] + +RFC 3748 EAP June 2004 + + + [RFC3162] attributes via the AAA protocol). However, it is possible + for a pass-through authenticator acting as a AAA client to provide + correct information to the AAA server while communicating misleading + information to the EAP peer via a lower layer protocol. + + For example, it is possible for a compromised authenticator to + utilize another authenticator's Called-Station-Id or NAS-Identifier + in communicating with the EAP peer via a lower layer protocol, or for + a pass-through authenticator acting as a AAA client to provide an + incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA + server via the AAA protocol. + + In order to address this vulnerability, EAP methods may support a + protected exchange of channel properties such as endpoint + identifiers, including (but not limited to): Called-Station-Id + [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS- + Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address + [RFC3162]. + + Using such a protected exchange, it is possible to match the channel + properties provided by the authenticator via out-of-band mechanisms + against those exchanged within the EAP method. Where discrepancies + are found, these SHOULD be logged; additional actions MAY also be + taken, such as denying access. + +7.16. Protected Result Indications + + Within EAP, Success and Failure packets are neither acknowledged nor + integrity protected. Result indications improve resilience to loss + of Success and Failure packets when EAP is run over lower layers + which do not support retransmission or synchronization of the + authentication state. In media such as IEEE 802.11, which provides + for retransmission, as well as synchronization of authentication + state via the 4-way handshake defined in [IEEE-802.11i], additional + resilience is typically of marginal benefit. + + Depending on the method and circumstances, result indications can be + spoofable by an attacker. A method is said to provide protected + result indications if it supports result indications, as well as the + "integrity protection" and "replay protection" claims. A method + supporting protected result indications MUST indicate which result + indications are protected, and which are not. + + Protected result indications are not required to protect against + rogue authenticators. Within a mutually authenticating method, + requiring that the server authenticate to the peer before the peer + will accept a Success packet prevents an attacker from acting as a + rogue authenticator. + + + +Aboba, et al. Standards Track [Page 56] + +RFC 3748 EAP June 2004 + + + However, it is possible for an attacker to forge a Success packet + after the server has authenticated to the peer, but before the peer + has authenticated to the server. If the peer were to accept the + forged Success packet and attempt to access the network when it had + not yet successfully authenticated to the server, a denial of service + attack could be mounted against the peer. After such an attack, if + the lower layer supports failure indications, the authenticator can + synchronize state with the peer by providing a lower layer failure + indication. See Section 7.12 for details. + + If a server were to authenticate the peer and send a Success packet + prior to determining whether the peer has authenticated the + authenticator, an idle timeout can occur if the authenticator is not + authenticated by the peer. Where supported by the lower layer, an + authenticator sensing the absence of the peer can free resources. + + In a method supporting result indications, a peer that has + authenticated the server does not consider the authentication + successful until it receives an indication that the server + successfully authenticated it. Similarly, a server that has + successfully authenticated the peer does not consider the + authentication successful until it receives an indication that the + peer has authenticated the server. + + In order to avoid synchronization problems, prior to sending a + success result indication, it is desirable for the sender to verify + that sufficient authorization exists for granting access, though, as + discussed below, this is not always possible. + + While result indications may enable synchronization of the + authentication result between the peer and server, this does not + guarantee that the peer and authenticator will be synchronized in + terms of their authorization or that timeouts will not occur. For + example, the EAP server may not be aware of an authorization decision + made by a AAA proxy; the AAA server may check authorization only + after authentication has completed successfully, to discover that + authorization cannot be granted, or the AAA server may grant access + but the authenticator may be unable to provide it due to a temporary + lack of resources. In these situations, synchronization may only be + achieved via lower layer result indications. + + Success indications may be explicit or implicit. For example, where + a method supports error messages, an implicit success indication may + be defined as the reception of a specific message without a preceding + error message. Failures are typically indicated explicitly. As + described in Section 4.2, a peer silently discards a Failure packet + received at a point where the method does not explicitly permit this + + + + +Aboba, et al. Standards Track [Page 57] + +RFC 3748 EAP June 2004 + + + to be sent. For example, a method providing its own error messages + might require the peer to receive an error message prior to accepting + a Failure packet. + + Per-packet authentication, integrity, and replay protection of result + indications protects against spoofing. Since protected result + indications require use of a key for per-packet authentication and + integrity protection, methods supporting protected result indications + MUST also support the "key derivation", "mutual authentication", + "integrity protection", and "replay protection" claims. + + Protected result indications address some denial-of-service + vulnerabilities due to spoofing of Success and Failure packets, + though not all. EAP methods can typically provide protected result + indications only in some circumstances. For example, errors can + occur prior to key derivation, and so it may not be possible to + protect all failure indications. It is also possible that result + indications may not be supported in both directions or that + synchronization may not be achieved in all modes of operation. + + For example, within EAP-TLS [RFC2716], in the client authentication + handshake, the server authenticates the peer, but does not receive a + protected indication of whether the peer has authenticated it. In + contrast, the peer authenticates the server and is aware of whether + the server has authenticated it. In the session resumption + handshake, the peer authenticates the server, but does not receive a + protected indication of whether the server has authenticated it. In + this mode, the server authenticates the peer and is aware of whether + the peer has authenticated it. + +8. Acknowledgements + + This protocol derives much of its inspiration from Dave Carrel's AHA + document, as well as the PPP CHAP protocol [RFC1994]. Valuable + feedback was provided by Yoshihiro Ohba of Toshiba America Research, + Jari Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco + Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan + Payne of the University of Maryland, Steve Bellovin of AT&T Research, + Paul Funk of Funk Software, Pasi Eronen of Nokia, Joseph Salowey of + Cisco, Paul Congdon of HP, and members of the EAP working group. + + The use of Security Claims sections for EAP methods, as required by + Section 7.2 and specified for each EAP method described in this + document, was inspired by Glen Zorn through [EAP-EVAL]. + + + + + + + +Aboba, et al. Standards Track [Page 58] + +RFC 3748 EAP June 2004 + + +9. References + +9.1. Normative References + + [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", + STD 51, RFC 1661, July 1994. + + [RFC1994] Simpson, W., "PPP Challenge Handshake + Authentication Protocol (CHAP)", RFC 1994, August + 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC2243] Metz, C., "OTP Extended Responses", RFC 2243, + November 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of + ISO 10646", RFC 2279, January 1998. + + [RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A + One-Time Password System", RFC 2289, February + 1998. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", + BCP 26, RFC 2434, October 1998. + + [RFC2988] Paxson, V. and M. Allman, "Computing TCP's + Retransmission Timer", RFC 2988, November 2000. + + [IEEE-802] Institute of Electrical and Electronics Engineers, + "Local and Metropolitan Area Networks: Overview + and Architecture", IEEE Standard 802, 1990. + + [IEEE-802.1X] Institute of Electrical and Electronics Engineers, + "Local and Metropolitan Area Networks: Port-Based + Network Access Control", IEEE Standard 802.1X, + September 2001. + + + + + + + + + + + +Aboba, et al. Standards Track [Page 59] + +RFC 3748 EAP June 2004 + + +9.2. Informative References + + [RFC793] Postel, J., "Transmission Control Protocol", STD + 7, RFC 793, September 1981. + + [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network + Authentication Service (V5)", RFC 1510, September + 1993. + + [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, + "Randomness Recommendations for Security", RFC + 1750, December 1994. + + [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., + Freier, A. and P. Kocher, "The TLS Protocol + Version 1.0", RFC 2246, January 1999. + + [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible + Authentication Protocol (EAP)", RFC 2284, March + 1998. + + [RFC2486] Aboba, B. and M. Beadles, "The Network Access + Identifier", RFC 2486, January 1999. + + [RFC2408] Maughan, D., Schneider, M. and M. Schertler, + "Internet Security Association and Key Management + Protocol (ISAKMP)", RFC 2408, November 1998. + + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key + Exchange (IKE)", RFC 2409, November 1998. + + [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP + Extensions", RFC 2433, October 1998. + + [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and + Policy Implementation in Roaming", RFC 2607, June + 1999. + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., + Zorn, G. and B. Palter, "Layer Two Tunneling + Protocol "L2TP"", RFC 2661, August 1999. + + [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS + Authentication Protocol", RFC 2716, October 1999. + + [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. + Simpson, "Remote Authentication Dial In User + Service (RADIUS)", RFC 2865, June 2000. + + + +Aboba, et al. Standards Track [Page 60] + +RFC 3748 EAP June 2004 + + + [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., + Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, + M., Zhang, L. and V. Paxson, "Stream Control + Transmission Protocol", RFC 2960, October 2000. + + [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and + IPv6", RFC 3162, August 2001. + + [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", RFC + 3454, December 2002. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote + Authentication Dial In User Service) Support For + Extensible Authentication Protocol (EAP)", RFC + 3579, September 2003. + + [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. + Roese, "IEEE 802.1X Remote Authentication Dial In + User Service (RADIUS) Usage Guidelines", RFC 3580, + September 2003. + + [RFC3692] Narten, T., "Assigning Experimental and Testing + Numbers Considered Useful", BCP 82, RFC 3692, + January 2004. + + [DECEPTION] Slatalla, M. and J. Quittner, "Masters of + Deception", Harper-Collins, New York, 1995. + + [KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos + Password Security", Proceedings of the 1999 ISOC + Network and Distributed System Security Symposium, + http://www.isoc.org/isoc/conferences/ndss/99/ + proceedings/papers/wu.pdf. + + [KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the + Kerberos authentication system", Proceedings of + the 1991 Winter USENIX Conference, pp. 253-267, + 1991. + + [KERB4WEAK] Dole, B., Lodin, S. and E. Spafford, "Misplaced + trust: Kerberos 4 session keys", Proceedings of + the Internet Society Network and Distributed + System Security Symposium, pp. 60-70, March 1997. + + + + + + + +Aboba, et al. Standards Track [Page 61] + +RFC 3748 EAP June 2004 + + + [PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A + Pre-IKE Credential Provisioning Protocol", Work in + Progress, October 2002. + + [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) + Protocol", Work in Progress, January 2004. + + [PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of + Microsoft's Point-to- Point Tunneling Protocol", + Proceedings of the 5th ACM Conference on + Communications and Computer Security, ACM Press, + November 1998. + + [IEEE-802.11] Institute of Electrical and Electronics Engineers, + "Wireless LAN Medium Access Control (MAC) and + Physical Layer (PHY) Specifications", IEEE + Standard 802.11, 1999. + + [SILVERMAN] Silverman, Robert D., "A Cost-Based Security + Analysis of Symmetric and Asymmetric Key Lengths", + RSA Laboratories Bulletin 13, April 2000 (Revised + November 2001), + http://www.rsasecurity.com/rsalabs/bulletins/ + bulletin13.html. + + [KEYFRAME] Aboba, B., "EAP Key Management Framework", Work in + Progress, October 2003. + + [SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for + user names and passwords", Work in Progress, March + 2004. + + [IEEE-802.11i] Institute of Electrical and Electronics Engineers, + "Unapproved Draft Supplement to Standard for + Telecommunications and Information Exchange + Between Systems - LAN/MAN Specific Requirements - + Part 11: Wireless LAN Medium Access Control (MAC) + and Physical Layer (PHY) Specifications: + Specification for Enhanced Security", IEEE Draft + 802.11i (work in progress), 2003. + + [DIAM-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter + Extensible Authentication Protocol (EAP) + Application", Work in Progress, February 2004. + + [EAP-EVAL] Zorn, G., "Specifying Security Claims for EAP + Authentication Types", Work in Progress, October + 2002. + + + +Aboba, et al. Standards Track [Page 62] + +RFC 3748 EAP June 2004 + + + [BINDING] Puthenkulam, J., "The Compound Authentication + Binding Problem", Work in Progress, October 2003. + + [MITM] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the- + Middle in Tunneled Authentication Protocols", IACR + ePrint Archive Report 2002/163, October 2002, + <http://eprint.iacr.org/2002/163>. + + [IEEE-802.11i-req] Stanley, D., "EAP Method Requirements for Wireless + LANs", Work in Progress, February 2004. + + [PPTPv2] Schneier, B. and Mudge, "Cryptanalysis of + Microsoft's PPTP Authentication Extensions (MS- + CHAPv2)", CQRE 99, Springer-Verlag, 1999, pp. + 192-203. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 63] + +RFC 3748 EAP June 2004 + + +Appendix A. Changes from RFC 2284 + + This section lists the major changes between [RFC2284] and this + document. Minor changes, including style, grammar, spelling, and + editorial changes are not mentioned here. + + o The Terminology section (Section 1.2) has been expanded, defining + more concepts and giving more exact definitions. + + o The concepts of Mutual Authentication, Key Derivation, and Result + Indications are introduced and discussed throughout the document + where appropriate. + + o In Section 2, it is explicitly specified that more than one + exchange of Request and Response packets may occur as part of the + EAP authentication exchange. How this may be used and how it may + not be used is specified in detail in Section 2.1. + + o Also in Section 2, some requirements have been made explicit for + the authenticator when acting in pass-through mode. + + o An EAP multiplexing model (Section 2.2) has been added to + illustrate a typical implementation of EAP. There is no + requirement that an implementation conform to this model, as long + as the on-the-wire behavior is consistent with it. + + o As EAP is now in use with a variety of lower layers, not just PPP + for which it was first designed, Section 3 on lower layer behavior + has been added. + + o In the description of the EAP Request and Response interaction + (Section 4.1), both the behavior on receiving duplicate requests, + and when packets should be silently discarded has been more + exactly specified. The implementation notes in this section have + been substantially expanded. + + o In Section 4.2, it has been clarified that Success and Failure + packets must not contain additional data, and the implementation + note has been expanded. A subsection giving requirements on + processing of success and failure packets has been added. + + o Section 5 on EAP Request/Response Types lists two new Type values: + the Expanded Type (Section 5.7), which is used to expand the Type + value number space, and the Experimental Type. In the Expanded + Type number space, the new Expanded Nak (Section 5.3.2) Type has + been added. Clarifications have been made in the description of + most of the existing Types. Security claims summaries have been + added for authentication methods. + + + +Aboba, et al. Standards Track [Page 64] + +RFC 3748 EAP June 2004 + + + o In Sections 5, 5.1, and 5.2, a requirement has been added such + that fields with displayable messages should contain UTF-8 encoded + ISO 10646 characters. + + o It is now required in Section 5.1 that if the Type-Data field of + an Identity Request contains a NUL-character, only the part before + the null is displayed. RFC 2284 prohibits the null termination of + the Type-Data field of Identity messages. This rule has been + relaxed for Identity Request messages and the Identity Request + Type-Data field may now be null terminated. + + o In Section 5.5, support for OTP Extended Responses [RFC2243] has + been added to EAP OTP. + + o An IANA Considerations section (Section 6) has been added, giving + registration policies for the numbering spaces defined for EAP. + + o The Security Considerations (Section 7) have been greatly + expanded, giving a much more comprehensive coverage of possible + threats and other security considerations. + + o In Section 7.5, text has been added on method-specific behavior, + providing guidance on how EAP method-specific integrity checks + should be processed. Where possible, it is desirable for a + method-specific MIC to be computed over the entire EAP packet, + including the EAP layer header (Code, Identifier, Length) and EAP + method layer header (Type, Type-Data). + + o In Section 7.14 the security risks involved in use of cleartext + passwords with EAP are described. + + o In Section 7.15 text has been added relating to detection of rogue + NAS behavior. + + + + + + + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 65] + +RFC 3748 EAP June 2004 + + +Authors' Addresses + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + + Phone: +1 425 706 6605 + Fax: +1 425 936 6605 + EMail: bernarda@microsoft.com + + Larry J. Blunk + Merit Network, Inc + 4251 Plymouth Rd., Suite 2000 + Ann Arbor, MI 48105-2785 + USA + + Phone: +1 734-647-9563 + Fax: +1 734-647-3185 + EMail: ljb@merit.edu + + John R. Vollbrecht + Vollbrecht Consulting LLC + 9682 Alice Hill Drive + Dexter, MI 48130 + USA + + EMail: jrv@umich.edu + + James Carlson + Sun Microsystems, Inc + 1 Network Drive + Burlington, MA 01803-2757 + USA + + Phone: +1 781 442 2084 + Fax: +1 781 442 1677 + EMail: james.d.carlson@sun.com + + Henrik Levkowetz + ipUnplugged AB + Arenavagen 33 + Stockholm S-121 28 + SWEDEN + + Phone: +46 708 32 16 08 + EMail: henrik@levkowetz.com + + + +Aboba, et al. Standards Track [Page 66] + +RFC 3748 EAP June 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Aboba, et al. Standards Track [Page 67] + |