rfc3748.txt   draft-arkko-emu-rfc3748bis.txt 
Network Working Group B. Aboba Network Working Group B. Aboba
Request for Comments: 3748 Microsoft Internet-Draft Microsoft Corporation
Obsoletes: 2284 L. Blunk Obsoletes: 3748 (if approved) L. Blunk
Category: Standards Track Merit Network, Inc Intended status: Standards Track Merit Network, Inc
J. Vollbrecht Expires: August 26, 2021 J. Vollbrecht
Vollbrecht Consulting LLC Vollbrecht Consulting LLC
J. Carlson J. Carlson
Sun Sun Microsystems, Inc
H. Levkowetz, Ed. H. Levkowetz
ipUnplugged ipUnplugged AB
June 2004 J. Arkko (Ed.)
J. Mattsson (Ed.)
Ericsson
February 22, 2021
Extensible Authentication Protocol (EAP) Extensible Authentication Protocol (EAP)
draft-arkko-emu-rfc3748bis-00
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 Abstract
This document defines the Extensible Authentication Protocol (EAP), This document defines the Extensible Authentication Protocol (EAP),
an authentication framework which supports multiple authentication an authentication framework which supports multiple authentication
methods. EAP typically runs directly over data link layers such as methods. EAP typically runs directly over data link layers such as
Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP Point-to-Point Protocol (PPP), IEEE 802, or 3GPP 5G without requiring
provides its own support for duplicate elimination and IP. EAP provides its own support for duplicate elimination and
retransmission, but is reliant on lower layer ordering guarantees. retransmission, but is reliant on lower layer ordering guarantees.
Fragmentation is not supported within EAP itself; however, individual Fragmentation is not supported within EAP itself; however, individual
EAP methods may support this. EAP methods may support this.
This document obsoletes RFC 2284. A summary of the changes between This document obsoletes RFC 3748, which in turn obsoleted RFC 2284.
this document and RFC 2284 is available in Appendix A. This document updates some of the security considerations, terms,
references, the IANA considerations, and few other minor updates. A
summary of the changes between this document and RFC 3748 is in
Appendix A, and the changes from RFC 2284 were listed in RFC 3748.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . 4 1.1. Specification of Requirements . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 6 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
2. Extensible Authentication Protocol (EAP). . . . . . . . . . . 7 2. Extensible Authentication Protocol (EAP) . . . . . . . . . . 8
2.1. Support for Sequences . . . . . . . . . . . . . . . . . 9 2.1. Support for Sequences . . . . . . . . . . . . . . . . . . 10
2.2. EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10 2.2. EAP Multiplexing Model . . . . . . . . . . . . . . . . . 11
2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . 12 2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . . 13
2.4. Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14 2.4. Peer-to-Peer Operation . . . . . . . . . . . . . . . . . 15
3. Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15 3. Lower Layer Behavior . . . . . . . . . . . . . . . . . . . . 16
3.1. Lower Layer Requirements. . . . . . . . . . . . . . . . 15 3.1. Lower Layer Requirements . . . . . . . . . . . . . . . . 16
3.2. EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18 3.2. EAP Usage Within PPP . . . . . . . . . . . . . . . . . . 19
3.2.1. PPP Configuration Option Format. . . . . . . . . 18 3.2.1. PPP Configuration Option Format . . . . . . . . . . . 19
3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19 3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . . 20
3.4. Lower Layer Indications . . . . . . . . . . . . . . . . 19 3.4. Lower Layer Indications . . . . . . . . . . . . . . . . . 20
4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20 4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Request and Response. . . . . . . . . . . . . . . . . . 21 4.1. Request and Response . . . . . . . . . . . . . . . . . . 22
4.2. Success and Failure . . . . . . . . . . . . . . . . . . 23 4.2. Success and Failure . . . . . . . . . . . . . . . . . . . 24
4.3. Retransmission Behavior . . . . . . . . . . . . . . . . 26 4.3. Retransmission Behavior . . . . . . . . . . . . . . . . . 27
5. Initial EAP Request/Response Types. . . . . . . . . . . . . . 27 5. Initial EAP Request/Response Types . . . . . . . . . . . . . 28
5.1. Identity. . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. Notification. . . . . . . . . . . . . . . . . . . . . . 29 5.2. Notification . . . . . . . . . . . . . . . . . . . . . . 30
5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31 5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . . . 32
5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32 5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . . . 33
5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35 5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . . 36
5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . 36 5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . . 38
5.6. Generic Token Card (GTC). . . . . . . . . . . . . . . . 37 5.6. Generic Token Card (GTC) . . . . . . . . . . . . . . . . 39
5.7. Expanded Types. . . . . . . . . . . . . . . . . . . . . 38 5.7. Expanded Types . . . . . . . . . . . . . . . . . . . . . 40
5.8. Experimental. . . . . . . . . . . . . . . . . . . . . . 40 5.8. Experimental . . . . . . . . . . . . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
6.1. Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41 6.1. Packet Codes . . . . . . . . . . . . . . . . . . . . . . 43
6.2. Method Types. . . . . . . . . . . . . . . . . . . . . . 41 6.2. Method Types . . . . . . . . . . . . . . . . . . . . . . 43
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43
7.1. Threat Model. . . . . . . . . . . . . . . . . . . . . . 42 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 44
7.2. Security Claims . . . . . . . . . . . . . . . . . . . . 43 7.2. Security Claims . . . . . . . . . . . . . . . . . . . . . 45
7.2.1. Security Claims Terminology for EAP Methods. . . 44 7.2.1. Security Claims Terminology for EAP Methods . . . . . 46
7.3. Identity Protection . . . . . . . . . . . . . . . . . . 46 7.3. Identity Protection . . . . . . . . . . . . . . . . . . . 48
7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47 7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 49
7.5. Packet Modification Attacks . . . . . . . . . . . . . . 48 7.5. Packet Modification Attacks . . . . . . . . . . . . . . . 50
7.6. Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49 7.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 51
7.7. Connection to an Untrusted Network. . . . . . . . . . . 49 7.7. Connection to an Untrusted Network . . . . . . . . . . . 51
7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . 50 7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . . 52
7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . 50 7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . . 52
7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51 7.10. Key Derivation . . . . . . . . . . . . . . . . . . . . . 53
7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53 7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . . 55
7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53 7.11.1. Legacy Authentication Methods . . . . . . . . . . . 55
7.13. Separation of Authenticator and Backend Authentication 7.12. Link Layer . . . . . . . . . . . . . . . . . . . . . . . 56
Server. . . . . . . . . . . . . . . . . . . . . . . . . 54 7.13. Separation of Authenticator and Backend Authentication
7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55 Server . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55 7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . . 57
7.16. Protected Result Indications. . . . . . . . . . . . . . 56 7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . . 58
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58 7.16. Protected Result Indications . . . . . . . . . . . . . . 58
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.1. Normative References. . . . . . . . . . . . . . . . . . 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 61
9.2. Informative References. . . . . . . . . . . . . . . . . 60 8.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64 Appendix A. Changes from RFC 3748 . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 69
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction 1. Introduction
This document defines the Extensible Authentication Protocol (EAP), This document defines the Extensible Authentication Protocol (EAP),
an authentication framework which supports multiple authentication an authentication framework which supports multiple authentication
methods. EAP typically runs directly over data link layers such as methods. EAP typically runs directly over data link layers such as
Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP Point-to-Point Protocol (PPP),IEEE 802, or 3GPP 5G without requiring
provides its own support for duplicate elimination and IP. EAP provides its own support for duplicate elimination and
retransmission, but is reliant on lower layer ordering guarantees. retransmission, but is reliant on lower layer ordering guarantees.
Fragmentation is not supported within EAP itself; however, individual Fragmentation is not supported within EAP itself; however, individual
EAP methods may support this. EAP methods may support this.
EAP may be used on dedicated links, as well as switched circuits, and 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 wired as well as wireless links. To date, EAP has been implemented
with hosts and routers that connect via switched circuits or dial-up with hosts and routers that connect via switched circuits or dial-up
lines using PPP [RFC1661]. It has also been implemented with lines using PPP [RFC1661]. It has also been implemented with
switches and access points using IEEE 802 [IEEE-802]. EAP switches and access points using IEEE 802 [IEEE-802]. EAP
encapsulation on IEEE 802 wired media is described in [IEEE-802.1X], encapsulation on IEEE 802 wired media is described in [IEEE-802.1X],
and encapsulation on IEEE wireless LANs in [IEEE-802.11i]. and encapsulation on IEEE wireless LANs in [IEEE-802.11i]. EAP can
be used for authentication in all types of accesses in 3GPP 5G
[TS.33.501].
One of the advantages of the EAP architecture is its flexibility. One of the advantages of the EAP architecture is its flexibility.
EAP is used to select a specific authentication mechanism, typically EAP is used to select a specific authentication mechanism, typically
after the authenticator requests more information in order to after the authenticator requests more information in order to
determine the specific authentication method to be used. Rather than determine the specific authentication method to be used. Rather than
requiring the authenticator to be updated to support each new requiring the authenticator to be updated to support each new
authentication method, EAP permits the use of a backend authentication method, EAP permits the use of a backend
authentication server, which may implement some or all authentication authentication server, which may implement some or all authentication
methods, with the authenticator acting as a pass-through for some or methods, with the authenticator acting as a pass-through for some or
all methods and peers. all methods and peers.
Within this document, authenticator requirements apply regardless of Within this document, authenticator requirements apply regardless of
whether the authenticator is operating as a pass-through or not. whether the authenticator is operating as a pass-through or not.
Where the requirement is meant to apply to either the authenticator Where the requirement is meant to apply to either the authenticator
or backend authentication server, depending on where the EAP or backend authentication server, depending on where the EAP
authentication is terminated, the term "EAP server" will be used. authentication is terminated, the term "EAP server" will be used.
Other aspects of the EAP framework are discussed in companion
documents, [RFC4137] discusses a possible state machine, [RFC5113]
defines the network discovery and selection problem, [RFC5247]
specifies the EAP key hierarchy, [RFC6677] and [RFC7029] explores
man-in-the-middle attacks as well as defining how to implement
channel bindings.
While the authors believe that the update from RFC 3748 is useful, it
is by no means something that absolute has to be done, but has been
provided for the community's consideration as part of an overall
interest in maintaining the technology and its documentation. If we
care about a technology we should keep it up to date. The authors
believe that it is preferable to have ongoing maintenance that
addresses issues when they are identified, rather than waiting for a
larger but more infrequent update. The specific changes are
discussed in Appendix A, and the rationale for the terminology-
related parts of the change is discussed in more detail in
Appendix B.
This update proposal is brought forward for discussion. Discussion
may find that the update is considered useful or unnecessary, or
perhaps even a distracton or flawed in some of its definitions. All
feedback is welcome!
1.1. Specification of Requirements 1.1. Specification of Requirements
In this document, several words are used to signify the requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" in this document are to be interpreted as described in BCP
and "OPTIONAL" in this document are to be interpreted as described in 14 [RFC2119] [RFC8174] when, and only when, they appear in all
[RFC2119]. capitals, as shown here.
1.2. Terminology 1.2. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
authenticator authenticator
The end of the link initiating EAP authentication. The term The end of the link initiating EAP authentication. The term
authenticator is used in [IEEE-802.1X], and has the same meaning authenticator is used in [IEEE-802.1X], and has the same meaning
in this document. in this document.
peer peer
The end of the link that responds to the authenticator. In The end of the link that responds to the authenticator. In
[IEEE-802.1X], this end is known as the Supplicant. [IEEE-802.1X], this end is known as the Supplicant.
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 The end of the link that responds to the authenticator in
peer. [IEEE-802.1X]. In this document, this end of the link is called
the peer.
backend authentication server backend authentication server
A backend authentication server is an entity that provides an A backend authentication server is an entity that provides an
authentication service to an authenticator. When used, this authentication service to an authenticator. When used, this
server typically executes EAP methods for the authenticator. This server typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1X]. terminology is also used in [IEEE-802.1X].
AAA AAA
Authentication, Authorization, and Accounting. AAA protocols with Authentication, Authorization, and Accounting. AAA protocols with
EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP]. In EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. In
this document, the terms "AAA server" and "backend authentication this document, the terms "AAA server" and "backend authentication
server" are used interchangeably. server" are used interchangeably.
Displayable Message Displayable Message
This is interpreted to be a human readable string of characters. This is interpreted to be a human readable string of characters.
The message encoding MUST follow the UTF-8 transformation format The message encoding MUST follow the UTF-8 transformation format
[RFC2279]. [RFC3629].
EAP server EAP server
The entity that terminates the EAP authentication method with the The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used, peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where the EAP server is part of the authenticator. In the case where
the authenticator operates in pass-through mode, the EAP server is the authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server. located on the backend authentication server.
Silently Discard Silently Discard
This means the implementation discards the packet without further This means the implementation discards the packet without further
processing. The implementation SHOULD provide the capability of processing. The implementation SHOULD provide the capability of
logging the event, including the contents of the silently logging the event, including the contents of the silently
discarded packet, and SHOULD record the event in a statistics discarded packet, and SHOULD record the event in a statistics
counter. counter.
Successful Authentication Successful Authentication
In the context of this document, "successful authentication" is an In the context of this document, "successful authentication" is an
exchange of EAP messages, as a result of which the authenticator exchange of EAP messages, as a result of which the authenticator
decides to allow access by the peer, and the peer decides to use decides to allow access by the peer, and the peer decides to use
this access. The authenticator's decision typically involves both this access. The authenticator's decision typically involves both
authentication and authorization aspects; the peer may authentication and authorization aspects; the peer may
successfully authenticate to the authenticator, but access may be successfully authenticate to the authenticator, but access may be
denied by the authenticator due to policy reasons. denied by the authenticator due to policy reasons.
Message Integrity Check (MIC) Message Integrity Check (MIC)
A keyed hash function used for authentication and integrity A keyed hash function used for authentication and integrity
protection of data. This is usually called a Message protection of data. This is usually called a Message
Authentication Code (MAC), but IEEE 802 specifications (and this Authentication Code (MAC), but IEEE 802 specifications (and this
document) use the acronym MIC to avoid confusion with Medium document) use the acronym MIC to avoid confusion with Medium
Access Control. Access Control.
Cryptographic Separation Cryptographic Separation
Two keys (x and y) are "cryptographically separate" if an Two keys (x and y) are "cryptographically separate" if an
adversary that knows all messages exchanged in the protocol cannot adversary that knows all messages exchanged in the protocol cannot
compute x from y or y from x without "breaking" some cryptographic compute x from y or y from x without "breaking" some cryptographic
assumption. In particular, this definition allows that the assumption. In particular, this definition allows that the
adversary has the knowledge of all nonces sent in cleartext, as adversary has the knowledge of all nonces sent in cleartext, as
well as all predictable counter values used in the protocol. well as all predictable counter values used in the protocol.
Breaking a cryptographic assumption would typically require Breaking a cryptographic assumption would typically require
inverting a one-way function or predicting the outcome of a inverting a one-way function or predicting the outcome of a
cryptographic pseudo-random number generator without knowledge of cryptographic pseudo-random number generator without knowledge of
the secret state. In other words, if the keys are the secret state. In other words, if the keys are
skipping to change at page 6, line 5 skipping to change at page 7, line 7
well as all predictable counter values used in the protocol. well as all predictable counter values used in the protocol.
Breaking a cryptographic assumption would typically require Breaking a cryptographic assumption would typically require
inverting a one-way function or predicting the outcome of a inverting a one-way function or predicting the outcome of a
cryptographic pseudo-random number generator without knowledge of cryptographic pseudo-random number generator without knowledge of
the secret state. In other words, if the keys are the secret state. In other words, if the keys are
cryptographically separate, there is no shortcut to compute x from 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 y or y from x, but the work an adversary must do to perform this
computation is equivalent to performing an exhaustive search for computation is equivalent to performing an exhaustive search for
the secret state value. the secret state value.
Master Session Key (MSK) Main Session Key (MSK)
Keying material that is derived between the EAP peer and server 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 and exported by the EAP method. The MSK is at least 64 octets in
length. In existing implementations, a AAA server acting as an length. In existing implementations, a AAA server acting as an
EAP server transports the MSK to the authenticator. EAP server transports the MSK to the authenticator.
Extended Master Session Key (EMSK) Extended Main Session Key (EMSK)
Additional keying material derived between the EAP client and Additional keying material derived between the EAP client and
server that is exported by the EAP method. The EMSK is at least server that is exported by the EAP method. The EMSK is at least
64 octets in length. The EMSK is not shared with the 64 octets in length. The EMSK is not shared with the
authenticator or any other third party. The EMSK is reserved for authenticator or any other third party. The EMSK is reserved for
future uses that are not defined yet. future uses that are not defined yet.
Result indications Result indications
A method provides result indications if after the method's last A method provides result indications if after the method's last
message is sent and received: message is sent and received:
1) The peer is aware of whether it has authenticated the server, 1. The peer is aware of whether it has authenticated the server,
as well as whether the server has authenticated it. as well as whether the server has authenticated it.
2) The server is aware of whether it has authenticated the peer, 2. The server is aware of whether it has authenticated the peer,
as well as whether the peer has authenticated it. as well as whether the peer has authenticated it.
In the case where successful authentication is sufficient to In the case where successful authentication is sufficient to
authorize access, then the peer and authenticator will also know if authorize access, then the peer and authenticator will also know if
the other party is willing to provide or accept access. This may not 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 always be the case. An authenticated peer may be denied access due
to lack of authorization (e.g., session limit) or other reasons. to lack of authorization (e.g., session limit) or other reasons.
Since the EAP exchange is run between the peer and the server, other Since the EAP exchange is run between the peer and the server, other
nodes (such as AAA proxies) may also affect the authorization nodes (such as AAA proxies) may also affect the authorization
decision. This is discussed in more detail in Section 7.16. decision. This is discussed in more detail in Section 7.16.
skipping to change at page 6, line 49 skipping to change at page 8, line 7
EAP was designed for use in network access authentication, where IP EAP was designed for use in network access authentication, where IP
layer connectivity may not be available. Use of EAP for other layer connectivity may not be available. Use of EAP for other
purposes, such as bulk data transport, is NOT RECOMMENDED. purposes, such as bulk data transport, is NOT RECOMMENDED.
Since EAP does not require IP connectivity, it provides just enough Since EAP does not require IP connectivity, it provides just enough
support for the reliable transport of authentication protocols, and support for the reliable transport of authentication protocols, and
no more. no more.
EAP is a lock-step protocol which only supports a single packet in EAP is a lock-step protocol which only supports a single packet in
flight. As a result, EAP cannot efficiently transport bulk data, flight. As a result, EAP cannot efficiently transport bulk data,
unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960]. unlike transport protocols such as TCP [RFC0793] or SCTP [RFC4960].
While EAP provides support for retransmission, it assumes ordering While EAP provides support for retransmission, it assumes ordering
guarantees provided by the lower layer, so out of order reception is guarantees provided by the lower layer, so out of order reception is
not supported. not supported.
Since EAP does not support fragmentation and reassembly, EAP Since EAP does not support fragmentation and reassembly, EAP
authentication methods generating payloads larger than the minimum authentication methods generating payloads larger than the minimum
EAP MTU need to provide fragmentation support. EAP MTU need to provide fragmentation support.
While authentication methods such as EAP-TLS [RFC2716] provide While authentication methods such as EAP-TLS
support for fragmentation and reassembly, the EAP methods defined in [RFC5216][I-D.ietf-emu-eap-tls13] provide support for fragmentation
this document do not. As a result, if the EAP packet size exceeds and reassembly, the EAP methods defined in this document do not. As
the EAP MTU of the link, these methods will encounter difficulties. 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), EAP authentication is initiated by the server (authenticator),
whereas many authentication protocols are initiated by the client whereas many authentication protocols are initiated by the client
(peer). As a result, it may be necessary for an authentication (peer). As a result, it may be necessary for an authentication
algorithm to add one or two additional messages (at most one algorithm to add one or two additional messages (at most one
roundtrip) in order to run over EAP. roundtrip) in order to run over EAP.
Where certificate-based authentication is supported, the number of Where certificate-based authentication is supported, the number of
additional roundtrips may be much larger due to fragmentation of additional roundtrips may be much larger due to fragmentation of
certificate chains. In general, a fragmented EAP packet will require certificate chains. In general, a fragmented EAP packet will require
skipping to change at page 7, line 42 skipping to change at page 8, line 47
experienced, or where the connection between the authenticator and experienced, or where the connection between the authenticator and
authentication server experiences significant packet loss, EAP authentication server experiences significant packet loss, EAP
methods requiring many round-trips can experience difficulties. In methods requiring many round-trips can experience difficulties. In
these situations, use of EAP methods with fewer roundtrips is these situations, use of EAP methods with fewer roundtrips is
advisable. advisable.
2. Extensible Authentication Protocol (EAP) 2. Extensible Authentication Protocol (EAP)
The EAP authentication exchange proceeds as follows: The EAP authentication exchange proceeds as follows:
[1] The authenticator sends a Request to authenticate the peer. The 1. The authenticator sends a Request to authenticate the peer. The
Request has a Type field to indicate what is being requested. Request has a Type field to indicate what is being requested.
Examples of Request Types include Identity, MD5-challenge, etc. Examples of Request Types include Identity, MD5-challenge, etc.
The MD5-challenge Type corresponds closely to the CHAP The MD5-challenge Type corresponds closely to the CHAP
authentication protocol [RFC1994]. Typically, the authenticator authentication protocol [RFC1994]. Typically, the authenticator
will send an initial Identity Request; however, an initial will send an initial Identity Request; however, an initial
Identity Request is not required, and MAY be bypassed. For Identity Request is not required, and MAY be bypassed. For
example, the identity may not be required where it is determined example, the identity may not be required where it is determined
by the port to which the peer has connected (leased lines, by the port to which the peer has connected (leased lines,
dedicated switch or dial-up ports), or where the identity is dedicated switch or dial-up ports), or where the identity is
obtained in another fashion (via calling station identity or MAC obtained in another fashion (via calling station identity or MAC
address, in the Name field of the MD5-Challenge Response, etc.). 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 2. The peer sends a Response packet in reply to a valid Request. As
with the Request packet, the Response packet contains a Type with the Request packet, the Response packet contains a Type
field, which corresponds to the Type field of the Request. field, which corresponds to the Type field of the Request.
[3] The authenticator sends an additional Request packet, and the 3. The authenticator sends an additional Request packet, and the
peer replies with a Response. The sequence of Requests and peer replies with a Response. The sequence of Requests and
Responses continues as long as needed. EAP is a 'lock step' Responses continues as long as needed. EAP is a 'lock step'
protocol, so that other than the initial Request, a new Request protocol, so that other than the initial Request, a new Request
cannot be sent prior to receiving a valid Response. The cannot be sent prior to receiving a valid Response. The
authenticator is responsible for retransmitting requests as authenticator is responsible for retransmitting requests as
described in Section 4.1. After a suitable number of described in Section 4.1. After a suitable number of
retransmissions, the authenticator SHOULD end the EAP retransmissions, the authenticator SHOULD end the EAP
conversation. The authenticator MUST NOT send a Success or conversation. The authenticator MUST NOT send a Success or
Failure packet when retransmitting or when it fails to get a Failure packet when retransmitting or when it fails to get a
response from the peer. response from the peer.
[4] The conversation continues until the authenticator cannot 4. The conversation continues until the authenticator cannot
authenticate the peer (unacceptable Responses to one or more authenticate the peer (unacceptable Responses to one or more
Requests), in which case the authenticator implementation MUST Requests), in which case the authenticator implementation MUST
transmit an EAP Failure (Code 4). Alternatively, the transmit an EAP Failure (Code 4). Alternatively, the
authentication conversation can continue until the authenticator authentication conversation can continue until the authenticator
determines that successful authentication has occurred, in which determines that successful authentication has occurred, in which
case the authenticator MUST transmit an EAP Success (Code 3). case the authenticator MUST transmit an EAP Success (Code 3).
Advantages: Advantages:
o The EAP protocol can support multiple authentication mechanisms o The EAP protocol can support multiple authentication mechanisms
skipping to change at page 10, line 13 skipping to change at page 11, line 12
"tunneled" method can reply to the initial EAP-Request with a Nak "tunneled" method can reply to the initial EAP-Request with a Nak
(legacy or expanded). To address security vulnerabilities, (legacy or expanded). To address security vulnerabilities,
"tunneled" methods MUST support protection against man-in-the-middle "tunneled" methods MUST support protection against man-in-the-middle
attacks. attacks.
2.2. EAP Multiplexing Model 2.2. EAP Multiplexing Model
Conceptually, EAP implementations consist of the following Conceptually, EAP implementations consist of the following
components: components:
[a] Lower layer. The lower layer is responsible for transmitting and 1. Lower layer. The lower layer is responsible for transmitting and
receiving EAP frames between the peer and authenticator. EAP has receiving EAP frames between the peer and authenticator. EAP has
been run over a variety of lower layers including PPP, wired IEEE 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], 802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11],
UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP [PIC]. Lower UDP (L2TP [RFC2661] and IKEv2 [RFC7296]), TCP
layer behavior is discussed in Section 3. [I-D.ietf-ipsra-pic], and 3GPP 5G [TS.33.501]. Lower layer
behavior is discussed in Section 3.
[b] EAP layer. The EAP layer receives and transmits EAP packets via 2. EAP layer. The EAP layer receives and transmits EAP packets via
the lower layer, implements duplicate detection and the lower layer, implements duplicate detection and
retransmission, and delivers and receives EAP messages to and retransmission, and delivers and receives EAP messages to and
from the EAP peer and authenticator layers. from the EAP peer and authenticator layers.
[c] EAP peer and authenticator layers. Based on the Code field, the 3. EAP peer and authenticator layers. Based on the Code field, the
EAP layer demultiplexes incoming EAP packets to the EAP peer and EAP layer demultiplexes incoming EAP packets to the EAP peer and
authenticator layers. Typically, an EAP implementation on a authenticator layers. Typically, an EAP implementation on a
given host will support either peer or authenticator given host will support either peer or authenticator
functionality, but it is possible for a host to act as both an functionality, but it is possible for a host to act as both an
EAP peer and authenticator. In such an implementation both EAP EAP peer and authenticator. In such an implementation both EAP
peer and authenticator layers will be present. peer and authenticator layers will be present.
[d] EAP method layers. EAP methods implement the authentication 4. EAP method layers. EAP methods implement the authentication
algorithms and receive and transmit EAP messages via the EAP peer algorithms and receive and transmit EAP messages via the EAP peer
and authenticator layers. Since fragmentation support is not and authenticator layers. Since fragmentation support is not
provided by EAP itself, this is the responsibility of EAP provided by EAP itself, this is the responsibility of EAP
methods, which are discussed in Section 5. methods, which are discussed in Section 5.
The EAP multiplexing model is illustrated in Figure 1 below. Note The EAP multiplexing model is illustrated in Figure 1 below. Note
that there is no requirement that an implementation conform to this that there is no requirement that an implementation conform to this
model, as long as the on-the-wire behavior is consistent with it. model, as long as the on-the-wire behavior is consistent with it.
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 27 skipping to change at page 12, line 27
| ! | | ! | | ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! | | ! | | ! |
| Lower ! layer | | Lower ! layer | | Lower ! layer | | Lower ! layer |
| ! | | ! | | ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
! ! ! !
! Peer ! Authenticator ! Peer ! Authenticator
+------------>-------------+ +------------>-------------+
Figure 1: EAP Multiplexing Model Figure 1: EAP Multiplexing Model
Within EAP, the Code field functions much like a protocol number in Within EAP, the Code field functions much like a protocol number in
IP. It is assumed that the EAP layer demultiplexes incoming EAP IP. It is assumed that the EAP layer demultiplexes incoming EAP
packets according to the Code field. Received EAP packets with packets according to the Code field. Received EAP packets with
Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the
EAP layer to the EAP peer layer, if implemented. EAP packets with EAP layer to the EAP peer layer, if implemented. EAP packets with
Code=2 (Response) are delivered to the EAP authenticator layer, if Code=2 (Response) are delivered to the EAP authenticator layer, if
implemented. implemented.
Within EAP, the Type field functions much like a port number in UDP Within EAP, the Type field functions much like a port number in UDP
skipping to change at page 12, line 40 skipping to change at page 13, line 37
described in Section 4.1. It forwards EAP packets received from the described in Section 4.1. It forwards EAP packets received from the
peer and destined to its authenticator layer to the backend peer and destined to its authenticator layer to the backend
authentication server; packets received from the backend authentication server; packets received from the backend
authentication server destined to the peer are forwarded to it. authentication server destined to the peer are forwarded to it.
A host receiving an EAP packet may only do one of three things with 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 it: act on it, drop it, or forward it. The forwarding decision is
typically based only on examination of the Code, Identifier, and typically based only on examination of the Code, Identifier, and
Length fields. A pass-through authenticator implementation MUST be Length fields. A pass-through authenticator implementation MUST be
capable of forwarding EAP packets received from the peer with Code=2 capable of forwarding EAP packets received from the peer with Code=2
(Response) to the backend authentication server. It also MUST be (Response) to the backend authentication server. It also MUST be
capable of receiving EAP packets from the backend authentication capable of receiving EAP packets from the backend authentication
server and forwarding EAP packets of Code=1 (Request), Code=3 server and forwarding EAP packets of Code=1 (Request), Code=3
(Success), and Code=4 (Failure) to the peer. (Success), and Code=4 (Failure) to the peer.
Unless the authenticator implements one or more authentication Unless the authenticator implements one or more authentication
methods locally which support the authenticator role, the EAP method methods locally which support the authenticator role, the EAP method
layer header fields (Type, Type-Data) are not examined as part of the layer header fields (Type, Type-Data) are not examined as part of the
forwarding decision. Where the authenticator supports local forwarding decision. Where the authenticator supports local
authentication methods, it MAY examine the Type field to determine authentication methods, it MAY examine the Type field to determine
whether to act on the packet itself or forward it. Compliant pass- whether to act on the packet itself or forward it. Compliant pass-
skipping to change at page 13, line 14 skipping to change at page 14, line 14
EAP packets received with Code=1 (Request), Code=3 (Success), and EAP packets received with Code=1 (Request), Code=3 (Success), and
Code=4 (Failure) are demultiplexed by the EAP layer and delivered to Code=4 (Failure) are demultiplexed by the EAP layer and delivered to
the peer layer. Therefore, unless a host implements an EAP peer the peer layer. Therefore, unless a host implements an EAP peer
layer, these packets will be silently discarded. Similarly, EAP layer, these packets will be silently discarded. Similarly, EAP
packets received with Code=2 (Response) are demultiplexed by the EAP packets received with Code=2 (Response) are demultiplexed by the EAP
layer and delivered to the authenticator layer. Therefore, unless a layer and delivered to the authenticator layer. Therefore, unless a
host implements an EAP authenticator layer, these packets will be host implements an EAP authenticator layer, these packets will be
silently discarded. The behavior of a "pass-through peer" is silently discarded. The behavior of a "pass-through peer" is
undefined within this specification, and is unsupported by AAA undefined within this specification, and is unsupported by AAA
protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP]. protocols such as RADIUS [RFC3579] and Diameter [RFC4072].
The forwarding model is illustrated in Figure 2. The forwarding model is illustrated in Figure 2.
Peer Pass-through Authenticator Authentication Peer Pass-through Authenticator Authentication
Server Server
+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | | | | | |
|EAP method | |EAP method | |EAP method | |EAP method |
| V | | ^ | | V | | ^ |
skipping to change at page 14, line 23 skipping to change at page 15, line 23
must support both authenticator and peer functionality. must support both authenticator and peer functionality.
Although EAP supports peer-to-peer operation, some EAP Although EAP supports peer-to-peer operation, some EAP
implementations, methods, AAA protocols, and link layers may not implementations, methods, AAA protocols, and link layers may not
support this. Some EAP methods may support asymmetric support this. Some EAP methods may support asymmetric
authentication, with one type of credential being required for the authentication, with one type of credential being required for the
peer and another type for the authenticator. Hosts supporting peer- peer and another type for the authenticator. Hosts supporting peer-
to-peer operation with such a method would need to be provisioned to-peer operation with such a method would need to be provisioned
with both types of credentials. with both types of credentials.
For example, EAP-TLS [RFC2716] is a client-server protocol in which For example, EAP-TLS [RFC5216][I-D.ietf-emu-eap-tls13] is a client-
distinct certificate profiles are typically utilized for the client server protocol in which distinct certificate profiles are typically
and server. This implies that a host supporting peer-to-peer utilized for the client and server. This implies that a host
authentication with EAP-TLS would need to implement both the EAP peer supporting peer-to-peer authentication with EAP-TLS would need to
and authenticator layers, support both peer and authenticator roles implement both the EAP peer and authenticator layers, support both
in the EAP-TLS implementation, and provision certificates appropriate peer and authenticator roles in the EAP-TLS implementation, and
for each role. provision certificates appropriate for each role.
AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM- AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [RFC4072]
EAP] only support "pass-through authenticator" operation. As noted only support "pass-through authenticator" operation. As noted in
in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access- [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-
Request encapsulating an EAP-Request, Success, or Failure packet with Request encapsulating an EAP-Request, Success, or Failure packet with
an Access-Reject. There is therefore no support for "pass-through an Access-Reject. There is therefore no support for "pass-through
peer" operation. peer" operation.
Even where a method is used which supports mutual authentication and Even where a method is used which supports mutual authentication and
result indications, several considerations may dictate that two EAP result indications, several considerations may dictate that two EAP
authentications (one in each direction) are required. These include: authentications (one in each direction) are required. These include:
[1] Support for bi-directional session key derivation in the lower 1. Support for bi-directional session key derivation in the lower
layer. Lower layers such as IEEE 802.11 may only support uni- layer. Lower layers such as IEEE 802.11 may only support uni-
directional derivation and transport of transient session keys. directional derivation and transport of transient session keys.
For example, the group-key handshake defined in [IEEE-802.11i] is For example, the group-key handshake defined in [IEEE-802.11i] is
uni-directional, since in IEEE 802.11 infrastructure mode, only uni-directional, since in IEEE 802.11 infrastructure mode, only
the Access Point (AP) sends multicast/broadcast traffic. In IEEE the Access Point (AP) sends multicast/broadcast traffic. In IEEE
802.11 ad hoc mode, where either peer may send 802.11 ad hoc mode, where either peer may send multicast/
multicast/broadcast traffic, two uni-directional group-key broadcast traffic, two uni-directional group-key exchanges are
exchanges are required. Due to limitations of the design, this required. Due to limitations of the design, this also implies
also implies the need for unicast key derivations and EAP method the need for unicast key derivations and EAP method exchanges to
exchanges to occur in each direction. occur in each direction.
[2] Support for tie-breaking in the lower layer. Lower layers such 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 as IEEE 802.11 ad hoc do not support "tie breaking" wherein two
hosts initiating authentication with each other will only go hosts initiating authentication with each other will only go
forward with a single authentication. This implies that even if forward with a single authentication. This implies that even if
802.11 were to support a bi-directional group-key handshake, then 802.11 were to support a bi-directional group-key handshake, then
two authentications, one in each direction, might still occur. two authentications, one in each direction, might still occur.
[3] Peer policy satisfaction. EAP methods may support result 3. Peer policy satisfaction. EAP methods may support result
indications, enabling the peer to indicate to the EAP server indications, enabling the peer to indicate to the EAP server
within the method that it successfully authenticated the EAP within the method that it successfully authenticated the EAP
server, as well as for the server to indicate that it has server, as well as for the server to indicate that it has
authenticated the peer. However, a pass-through authenticator authenticated the peer. However, a pass-through authenticator
will not be aware that the peer has accepted the credentials will not be aware that the peer has accepted the credentials
offered by the EAP server, unless this information is provided to offered by the EAP server, unless this information is provided to
the authenticator via the AAA protocol. The authenticator SHOULD the authenticator via the AAA protocol. The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet interpret the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated the as an indication that the peer has successfully authenticated the
server. server.
skipping to change at page 15, line 41 skipping to change at page 16, line 38
roles. As a result, the peer may require an additional roles. As a result, the peer may require an additional
authentication in the reverse direction, even if the peer provided an authentication in the reverse direction, even if the peer provided an
indication that the EAP server had successfully authenticated to it. indication that the EAP server had successfully authenticated to it.
3. Lower Layer Behavior 3. Lower Layer Behavior
3.1. Lower Layer Requirements 3.1. Lower Layer Requirements
EAP makes the following assumptions about lower layers: EAP makes the following assumptions about lower layers:
[1] Unreliable transport. In EAP, the authenticator retransmits 1. Unreliable transport. In EAP, the authenticator retransmits
Requests that have not yet received Responses so that EAP does Requests that have not yet received Responses so that EAP does
not assume that lower layers are reliable. Since EAP defines its not assume that lower layers are reliable. Since EAP defines its
own retransmission behavior, it is possible (though undesirable) own retransmission behavior, it is possible (though undesirable)
for retransmission to occur both in the lower layer and the EAP for retransmission to occur both in the lower layer and the EAP
layer when EAP is run over a reliable lower layer. layer when EAP is run over a reliable lower layer.
Note that EAP Success and Failure packets are not retransmitted. Note that EAP Success and Failure packets are not retransmitted.
Without a reliable lower layer, and with a non-negligible error rate, Without a reliable lower layer, and with a non-negligible error
these packets can be lost, resulting in timeouts. It is therefore rate, these packets can be lost, resulting in timeouts. It is
desirable for implementations to improve their resilience to loss of therefore desirable for implementations to improve their
EAP Success or Failure packets, as described in Section 4.2. 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 2. Lower layer error detection. While EAP does not assume that the
lower layer is reliable, it does rely on lower layer error lower layer is reliable, it does rely on lower layer error
detection (e.g., CRC, Checksum, MIC, etc.). EAP methods may not 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 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, fields in the EAP packet, such as the Code, Identifier, Length,
or Type fields. As a result, without lower layer error or Type fields. As a result, without lower layer error
detection, undetected errors could creep into the EAP layer or detection, undetected errors could creep into the EAP layer or
EAP method layer header fields, resulting in authentication EAP method layer header fields, resulting in authentication
failures. failures.
For example, EAP TLS [RFC2716], which computes its MIC over the For example, EAP TLS [RFC5216][I-D.ietf-emu-eap-tls13], which
Type-Data field only, regards MIC validation failures as a fatal computes its MIC over the Type-Data field only, regards MIC
error. Without lower layer error detection, this method, and validation failures as a fatal error. Without lower layer error
others like it, will not perform reliably. detection, this method, and others like it, will not perform
reliably.
[3] Lower layer security. EAP does not require lower layers to 3. Lower layer security. EAP does not require lower layers to
provide security services such as per-packet confidentiality, provide security services such as per-packet confidentiality,
authentication, integrity, and replay protection. However, where authentication, integrity, and replay protection. However, where
these security services are available, EAP methods supporting Key these security services are available, EAP methods supporting Key
Derivation (see Section 7.2.1) can be used to provide dynamic Derivation (see Section 7.2.1) can be used to provide dynamic
keying material. This makes it possible to bind the EAP keying material. This makes it possible to bind the EAP
authentication to subsequent data and protect against data authentication to subsequent data and protect against data
modification, spoofing, or replay. See Section 7.1 for details. modification, spoofing, or replay. See Section 7.1 for details.
[4] Minimum MTU. EAP is capable of functioning on lower layers that 4. Minimum MTU. EAP is capable of functioning on lower layers that
provide an EAP MTU size of 1020 octets or greater. provide an EAP MTU size of 1020 octets or greater.
EAP does not support path MTU discovery, and fragmentation and EAP does not support path MTU discovery, and fragmentation and
reassembly is not supported by EAP, nor by the methods defined in reassembly is not supported by EAP, nor by the methods defined in
this specification: Identity (1), Notification (2), Nak Response this specification: Identity (1), Notification (2), Nak Response
(3), MD5-Challenge (4), One Time Password (5), Generic Token Card (3), MD5-Challenge (4), One Time Password (5), Generic Token Card
(6), and expanded Nak Response (254) Types. (6), and expanded Nak Response (254) Types.
Typically, the EAP peer obtains information on the EAP MTU from Typically, the EAP peer obtains information on the EAP MTU from
the lower layers and sets the EAP frame size to an appropriate the lower layers and sets the EAP frame size to an appropriate
value. Where the authenticator operates in pass-through mode, value. Where the authenticator operates in pass-through mode,
the authentication server does not have a direct way of the authentication server does not have a direct way of
determining the EAP MTU, and therefore relies on the determining the EAP MTU, and therefore relies on the
authenticator to provide it with this information, such as via authenticator to provide it with this information, such as via
the Framed-MTU attribute, as described in [RFC3579], Section 2.4. the Framed-MTU attribute, as described in [RFC3579], Section 2.4.
While methods such as EAP-TLS [RFC2716] support fragmentation and While methods such as EAP-TLS [RFC5216][I-D.ietf-emu-eap-tls13]
reassembly, EAP methods originally designed for use within PPP support fragmentation and reassembly, EAP methods originally
where a 1500 octet MTU is guaranteed for control frames (see designed for use within PPP where a 1500 octet MTU is guaranteed
[RFC1661], Section 6.1) may lack fragmentation and reassembly for control frames (see [RFC1661], Section 6.1) may lack
features. fragmentation and reassembly features.
EAP methods can assume a minimum EAP MTU of 1020 octets in the EAP methods can assume a minimum EAP MTU of 1020 octets in the
absence of other information. EAP methods SHOULD include support absence of other information. EAP methods SHOULD include support
for fragmentation and reassembly if their payloads can be larger for fragmentation and reassembly if their payloads can be larger
than this minimum EAP MTU. than this minimum EAP MTU.
EAP is a lock-step protocol, which implies a certain inefficiency EAP is a lock-step protocol, which implies a certain inefficiency
when handling fragmentation and reassembly. Therefore, if the when handling fragmentation and reassembly. Therefore, if the
lower layer supports fragmentation and reassembly (such as where lower layer supports fragmentation and reassembly (such as where
EAP is transported over IP), it may be preferable for EAP is transported over IP), it may be preferable for
fragmentation and reassembly to occur in the lower layer rather fragmentation and reassembly to occur in the lower layer rather
than in EAP. This can be accomplished by providing an than in EAP. This can be accomplished by providing an
artificially large EAP MTU to EAP, causing fragmentation and artificially large EAP MTU to EAP, causing fragmentation and
reassembly to be handled within the lower layer. reassembly to be handled within the lower layer.
[5] Possible duplication. Where the lower layer is reliable, it will 5. Possible duplication. Where the lower layer is reliable, it will
provide the EAP layer with a non-duplicated stream of packets. provide the EAP layer with a non-duplicated stream of packets.
However, while it is desirable that lower layers provide for However, while it is desirable that lower layers provide for non-
non-duplication, this is not a requirement. The Identifier field duplication, this is not a requirement. The Identifier field
provides both the peer and authenticator with the ability to provides both the peer and authenticator with the ability to
detect duplicates. detect duplicates.
[6] Ordering guarantees. EAP does not require the Identifier to be 6. Ordering guarantees. EAP does not require the Identifier to be
monotonically increasing, and so is reliant on lower layer monotonically increasing, and so is reliant on lower layer
ordering guarantees for correct operation. EAP was originally ordering guarantees for correct operation. EAP was originally
defined to run on PPP, and [RFC1661] Section 1 has an ordering defined to run on PPP, and [RFC1661] Section 1 has an ordering
requirement: requirement:
"The Point-to-Point Protocol is designed for simple links "The Point-to-Point Protocol is designed for simple links which
which transport packets between two peers. These links transport packets between two peers. These links provide full-
provide full-duplex simultaneous bi-directional operation, duplex simultaneous bi-directional operation, and are assumed to
and are assumed to deliver packets in order." deliver packets in order."
Lower layer transports for EAP MUST preserve ordering between a Lower layer transports for EAP MUST preserve ordering between a
source and destination at a given priority level (the ordering source and destination at a given priority level (the ordering
guarantee provided by [IEEE-802]). guarantee provided by [IEEE-802]).
Reordering, if it occurs, will typically result in an EAP Reordering, if it occurs, will typically result in an EAP
authentication failure, causing EAP authentication to be re-run. authentication failure, causing EAP authentication to be re-run.
In an environment in which reordering is likely, it is therefore In an environment in which reordering is likely, it is therefore
expected that EAP authentication failures will be common. It is expected that EAP authentication failures will be common. It is
RECOMMENDED that EAP only be run over lower layers that provide RECOMMENDED that EAP only be run over lower layers that provide
skipping to change at page 19, line 40 skipping to change at page 20, line 30
[RFC1994]. [RFC1994].
3.4. Lower Layer Indications 3.4. Lower Layer Indications
The reliability and security of lower layer indications is dependent The reliability and security of lower layer indications is dependent
on the lower layer. Since EAP is media independent, the presence or on the lower layer. Since EAP is media independent, the presence or
absence of lower layer security is not taken into account in the absence of lower layer security is not taken into account in the
processing of EAP messages. processing of EAP messages.
To improve reliability, if a peer receives a lower layer success To improve reliability, if a peer receives a lower layer success
indication as defined in Section 7.2, it MAY conclude that a Success indication as defined in Section 7.12, it MAY conclude that a Success
packet has been lost, and behave as if it had actually received a packet has been lost, and behave as if it had actually received a
Success packet. This includes choosing to ignore the Success in some Success packet. This includes choosing to ignore the Success in some
circumstances as described in Section 4.2. circumstances as described in Section 4.2. See also protected result
indications in Section 7.16.
A discussion of some reliability and security issues with lower layer A discussion of some reliability and security issues with lower layer
indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless
LANs can be found in the Security Considerations, Section 7.12. LANs can be found in the Security Considerations, Section 7.12.
After EAP authentication is complete, the peer will typically After EAP authentication is complete, the peer will typically
transmit and receive data via the authenticator. It is desirable to transmit and receive data via the authenticator. It is desirable to
provide assurance that the entities transmitting data are the same provide assurance that the entities transmitting data are the same
ones that successfully completed EAP authentication. To accomplish ones that successfully completed EAP authentication. To accomplish
this, it is necessary for the lower layer to provide per-packet this, it is necessary for the lower layer to provide per-packet
skipping to change at page 22, line 45 skipping to change at page 23, line 45
new Request. Initializing the first Identifier with a random new Request. Initializing the first Identifier with a random
number rather than starting from zero is recommended, since it number rather than starting from zero is recommended, since it
makes sequence attacks somewhat more difficult. makes sequence attacks somewhat more difficult.
Since the Identifier space is unique to each session, Since the Identifier space is unique to each session,
authenticators are not restricted to only 256 simultaneous authenticators are not restricted to only 256 simultaneous
authentication conversations. Similarly, with re-authentication, authentication conversations. Similarly, with re-authentication,
an EAP conversation might continue over a long period of time, and an EAP conversation might continue over a long period of time, and
is not limited to only 256 roundtrips. is not limited to only 256 roundtrips.
Implementation Note: The authenticator is responsible for Implementation Note: The authenticator is responsible for
retransmitting Request messages. If the Request message is obtained retransmitting Request messages. If the Request message is
from elsewhere (such as from a backend authentication server), then obtained from elsewhere (such as from a backend authentication
the authenticator will need to save a copy of the Request in order to server), then the authenticator will need to save a copy of the
accomplish this. The peer is responsible for detecting and handling Request in order to accomplish this. The peer is responsible for
duplicate Request messages before processing them in any way, detecting and handling duplicate Request messages before
including passing them on to an outside party. The authenticator is processing them in any way, including passing them on to an
also responsible for discarding Response messages with a non-matching outside party. The authenticator is also responsible for
Identifier value before acting on them in any way, including passing discarding Response messages with a non-matching Identifier value
them on to the backend authentication server for verification. Since before acting on them in any way, including passing them on to the
the authenticator can retransmit before receiving a Response from the backend authentication server for verification. Since the
peer, the authenticator can receive multiple Responses, each with a authenticator can retransmit before receiving a Response from the
matching Identifier. Until a new Request is received by the peer, the authenticator can receive multiple Responses, each with
authenticator, the Identifier value is not updated, so that the a matching Identifier. Until a new Request is received by the
authenticator forwards Responses to the backend authentication authenticator, the Identifier value is not updated, so that the
server, one at a time. authenticator forwards Responses to the backend authentication
server, one at a time.
Length Length
The Length field is two octets and indicates the length of the EAP The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, and Type-Data packet including the Code, Identifier, Length, Type, and Type-Data
fields. Octets outside the range of the Length field should be fields. Octets outside the range of the Length field should be
treated as Data Link Layer padding and MUST be ignored upon treated as Data Link Layer padding and MUST be ignored upon
reception. A message with the Length field set to a value larger reception. A message with the Length field set to a value larger
than the number of received octets MUST be silently discarded. than the number of received octets MUST be silently discarded.
Type Type
The Type field is one octet. This field indicates the Type of 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. A single Type MUST be specified for each EAP
Request or Response. An initial specification of Types follows in Request or Response. An initial specification of Types follows in
Section 5 of this document. Section 5 of this document.
The Type field of a Response MUST either match that of the The Type field of a Response MUST either match that of the
Request, or correspond to a legacy or Expanded Nak (see Section Request, or correspond to a legacy or Expanded Nak (see
5.3) indicating that a Request Type is unacceptable to the peer. Section 5.3) indicating that a Request Type is unacceptable to the
A peer MUST NOT send a Nak (legacy or expanded) in response to a peer. A peer MUST NOT send a Nak (legacy or expanded) in response
Request, after an initial non-Nak Response has been sent. An EAP to a Request, after an initial non-Nak Response has been sent. An
server receiving a Response not meeting these requirements MUST EAP server receiving a Response not meeting these requirements
silently discard it. MUST silently discard it.
Type-Data Type-Data
The Type-Data field varies with the Type of Request and the The Type-Data field varies with the Type of Request and the
associated Response. associated Response.
4.2. Success and Failure 4.2. Success and Failure
The Success packet is sent by the authenticator to the peer after The Success packet is sent by the authenticator to the peer after
completion of an EAP authentication method (Type 4 or greater) to completion of an EAP authentication method (Type 4 or greater) to
skipping to change at page 26, line 15 skipping to change at page 27, line 16
4.3. Retransmission Behavior 4.3. Retransmission Behavior
Because the authentication process will often involve user input, Because the authentication process will often involve user input,
some care must be taken when deciding upon retransmission strategies some care must be taken when deciding upon retransmission strategies
and authentication timeouts. By default, where EAP is run over an and authentication timeouts. By default, where EAP is run over an
unreliable lower layer, the EAP retransmission timer SHOULD be unreliable lower layer, the EAP retransmission timer SHOULD be
dynamically estimated. A maximum of 3-5 retransmissions is dynamically estimated. A maximum of 3-5 retransmissions is
suggested. suggested.
When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as
within [PIC]), the authenticator retransmission timer SHOULD be set within [I-D.ietf-ipsra-pic]), the authenticator retransmission timer
to an infinite value, so that retransmissions do not occur at the EAP SHOULD be set to an infinite value, so that retransmissions do not
layer. The peer may still maintain a timeout value so as to avoid occur at the EAP layer. The peer may still maintain a timeout value
waiting indefinitely for a Request. so as to avoid waiting indefinitely for a Request.
Where the authentication process requires user input, the measured Where the authentication process requires user input, the measured
round trip times may be determined by user responsiveness rather than round trip times may be determined by user responsiveness rather than
network characteristics, so that dynamic RTO estimation may not be network characteristics, so that dynamic RTO estimation may not be
helpful. Instead, the retransmission timer SHOULD be set so as to helpful. Instead, the retransmission timer SHOULD be set so as to
provide sufficient time for the user to respond, with longer timeouts provide sufficient time for the user to respond, with longer timeouts
required in certain cases, such as where Token Cards (see Section required in certain cases, such as where Token Cards (see
5.6) are involved. Section 5.6) are involved.
In order to provide the EAP authenticator with guidance as to the In order to provide the EAP authenticator with guidance as to the
appropriate timeout value, a hint can be communicated to the appropriate timeout value, a hint can be communicated to the
authenticator by the backend authentication server (such as via the authenticator by the backend authentication server (such as via the
RADIUS Session-Timeout attribute). RADIUS Session-Timeout attribute).
In order to dynamically estimate the EAP retransmission timer, the In order to dynamically estimate the EAP retransmission timer, the
algorithms for the estimation of SRTT, RTTVAR, and RTO described in algorithms for the estimation of SRTT, RTTVAR, and RTO described in
[RFC2988] are RECOMMENDED, including use of Karn's algorithm, with [RFC6298] are RECOMMENDED, including use of Karn's algorithm, with
the following potential modifications: the following potential modifications:
[a] In order to avoid synchronization behaviors that can occur with o In order to avoid synchronization behaviors that can occur with
fixed timers among distributed systems, the retransmission timer fixed timers among distributed systems, the retransmission timer
is calculated with a jitter by using the RTO value and randomly is calculated with a jitter by using the RTO value and randomly
adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative
calculations to create jitter MAY be used. These MUST be calculations to create jitter MAY be used. These MUST be pseudo-
pseudo-random. For a discussion of pseudo-random number random. For a discussion of pseudo-random number generation, see
generation, see [RFC1750]. [RFC1750].
[b] When EAP is transported over a single link (as opposed to over o When EAP is transported over a single link (as opposed to over the
the Internet), smaller values of RTOinitial, RTOmin, and RTOmax Internet), smaller values of RTOinitial, RTOmin, and RTOmax MAY be
MAY be used. Recommended values are RTOinitial=1 second, used. Recommended values are RTOinitial=1 second, RTOmin=200ms,
RTOmin=200ms, and RTOmax=20 seconds. and RTOmax=20 seconds.
[c] When EAP is transported over a single link (as opposed to over o When EAP is transported over a single link (as opposed to over the
the Internet), estimates MAY be done on a per-authenticator Internet), estimates MAY be done on a per-authenticator basis,
basis, rather than a per-session basis. This enables the rather than a per-session basis. This enables the retransmission
retransmission estimate to make the most use of information on estimate to make the most use of information on link-layer
link-layer behavior. behavior.
[d] An EAP implementation MAY clear SRTT and RTTVAR after backing off o An EAP implementation MAY clear SRTT and RTTVAR after backing off
the timer multiple times, as it is likely that the current SRTT the timer multiple times, as it is likely that the current SRTT
and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are
cleared, they should be initialized with the next RTT sample cleared, they should be initialized with the next RTT sample taken
taken as described in [RFC2988] equation 2.2. as described in [RFC6298] equation 2.2.
5. Initial EAP Request/Response Types 5. Initial EAP Request/Response Types
This section defines the initial set of EAP Types used in Request/ This section defines the initial set of EAP Types used in Request/
Response exchanges. More Types may be defined in future documents. Response exchanges. More Types may be defined in future documents.
The Type field is one octet and identifies the structure of an EAP The Type field is one octet and identifies the structure of an EAP
Request or Response packet. The first 3 Types are considered special Request or Response packet. The first 3 Types are considered special
case Types. case Types.
The remaining Types define authentication exchanges. Nak (Type 3) or The remaining Types define authentication exchanges. Nak (Type 3) or
skipping to change at page 27, line 47 skipping to change at page 28, line 47
5 One Time Password (OTP) 5 One Time Password (OTP)
6 Generic Token Card (GTC) 6 Generic Token Card (GTC)
254 Expanded Types 254 Expanded Types
255 Experimental use 255 Experimental use
EAP methods MAY support authentication based on shared secrets. If EAP methods MAY support authentication based on shared secrets. If
the shared secret is a passphrase entered by the user, the shared secret is a passphrase entered by the user,
implementations MAY support entering passphrases with non-ASCII implementations MAY support entering passphrases with non-ASCII
characters. In this case, the input should be processed using an characters. In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in octets using appropriate stringprep [RFC3454] profile, and encoded in octets using
UTF-8 encoding [RFC2279]. A preliminary version of a possible UTF-8 encoding [RFC3629]. A preliminary version of a possible
stringprep profile is described in [SASLPREP]. stringprep profile is described in [RFC8265].
5.1. Identity 5.1. Identity
Description Description
The Identity Type is used to query the identity of the peer. The Identity Type is used to query the identity of the peer.
Generally, the authenticator will issue this as the initial Generally, the authenticator will issue this as the initial
Request. An optional displayable message MAY be included to Request. An optional displayable message MAY be included to
prompt the peer in the case where there is an expectation of prompt the peer in the case where there is an expectation of
interaction with a user. A Response of Type 1 (Identity) SHOULD interaction with a user. A Response of Type 1 (Identity) SHOULD
skipping to change at page 28, line 39 skipping to change at page 29, line 39
per-packet authentication, integrity and replay protection, and per-packet authentication, integrity and replay protection, and
confidentiality. The Identity Response may not be the appropriate confidentiality. The Identity Response may not be the appropriate
identity for the method; it may have been truncated or obfuscated identity for the method; it may have been truncated or obfuscated
so as to provide privacy, or it may have been decorated for so as to provide privacy, or it may have been decorated for
routing purposes. Where the peer is configured to only accept routing purposes. Where the peer is configured to only accept
authentication methods supporting protected identity exchanges, authentication methods supporting protected identity exchanges,
the peer MAY provide an abbreviated Identity Response (such as the peer MAY provide an abbreviated Identity Response (such as
omitting the peer-name portion of the NAI [RFC2486]). For further omitting the peer-name portion of the NAI [RFC2486]). For further
discussion of identity protection, see Section 7.3. discussion of identity protection, see Section 7.3.
Implementation Note: The peer MAY obtain the Identity via user input. Implementation Note: The peer MAY obtain the Identity via user
It is suggested that the authenticator retry the Identity Request in input. It is suggested that the authenticator retry the Identity
the case of an invalid Identity or authentication failure to allow Request in the case of an invalid Identity or authentication
for potential typos on the part of the user. It is suggested that failure to allow for potential typos on the part of the user. It
the Identity Request be retried a minimum of 3 times before is suggested that the Identity Request be retried a minimum of 3
terminating the authentication. The Notification Request MAY be used times before terminating the authentication. The Notification
to indicate an invalid authentication attempt prior to transmitting a Request MAY be used to indicate an invalid authentication attempt
new Identity Request (optionally, the failure MAY be indicated within prior to transmitting a new Identity Request (optionally, the
the message of the new Identity Request itself). failure MAY be indicated within the message of the new Identity
Request itself).
Type Type
1 1
Type-Data Type-Data
This field MAY contain a displayable message in the Request, This field MAY contain a displayable message in the Request,
containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where containing UTF-8 encoded ISO 10646 characters [RFC3629]. Where
the Request contains a null, only the portion of the field prior the Request contains a null, only the portion of the field prior
to the null is displayed. If the Identity is unknown, the to the null is displayed. If the Identity is unknown, the
Identity Response field should be zero bytes in length. The Identity Response field should be zero bytes in length. The
Identity Response field MUST NOT be null terminated. In all Identity Response field MUST NOT be null terminated. In all
cases, the length of the Type-Data field is derived from the cases, the length of the Type-Data field is derived from the
Length field of the Request/Response packet. Length field of the Request/Response packet.
Security Claims (see Section 7.2): Security Claims (see Section 7.2):
Auth. mechanism: None Auth. mechanism: None
skipping to change at page 29, line 36 skipping to change at page 30, line 33
Replay protection: No Replay protection: No
Confidentiality: No Confidentiality: No
Key derivation: No Key derivation: No
Key strength: N/A Key strength: N/A
Dictionary attack prot.: N/A Dictionary attack prot.: N/A
Fast reconnect: No Fast reconnect: No
Crypt. binding: N/A Crypt. binding: N/A
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No Channel binding: No
Perfect Forward Secrecy: N/A
5.2. Notification 5.2. Notification
Description Description
The Notification Type is optionally used to convey a displayable The Notification Type is optionally used to convey a displayable
message from the authenticator to the peer. An authenticator MAY message from the authenticator to the peer. An authenticator MAY
send a Notification Request to the peer at any time when there is send a Notification Request to the peer at any time when there is
no outstanding Request, prior to completion of an EAP no outstanding Request, prior to completion of an EAP
authentication method. The peer MUST respond to a Notification authentication method. The peer MUST respond to a Notification
skipping to change at page 30, line 28 skipping to change at page 31, line 28
Notification should not be required. Notification should not be required.
Type Type
2 2
Type-Data Type-Data
The Type-Data field in the Request contains a displayable message The Type-Data field in the Request contains a displayable message
greater than zero octets in length, containing UTF-8 encoded ISO greater than zero octets in length, containing UTF-8 encoded ISO
10646 characters [RFC2279]. The length of the message is 10646 characters [RFC3629]. The length of the message is
determined by the Length field of the Request packet. The message determined by the Length field of the Request packet. The message
MUST NOT be null terminated. A Response MUST be sent in reply to 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 the Request with a Type field of 2 (Notification). The Type-Data
field of the Response is zero octets in length. The Response field of the Response is zero octets in length. The Response
should be sent immediately (independent of how the message is should be sent immediately (independent of how the message is
displayed or logged). displayed or logged).
Security Claims (see Section 7.2): Security Claims (see Section 7.2):
Auth. mechanism: None Auth. mechanism: None
skipping to change at page 31, line 4 skipping to change at page 32, line 19
Replay protection: No Replay protection: No
Confidentiality: No Confidentiality: No
Key derivation: No Key derivation: No
Key strength: N/A Key strength: N/A
Dictionary attack prot.: N/A Dictionary attack prot.: N/A
Fast reconnect: No Fast reconnect: No
Crypt. binding: N/A Crypt. binding: N/A
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No Channel binding: No
Perfect Forward Secrecy: N/A
5.3. Nak 5.3. Nak
5.3.1. Legacy Nak 5.3.1. Legacy Nak
Description Description
The legacy Nak Type is valid only in Response messages. It is The legacy Nak Type is valid only in Response messages. It is
sent in reply to a Request where the desired authentication Type sent in reply to a Request where the desired authentication Type
is unacceptable. Authentication Types are numbered 4 and above. is unacceptable. Authentication Types are numbered 4 and above.
skipping to change at page 32, line 6 skipping to change at page 33, line 21
Where a peer receives a Request for an unacceptable authentication Where a peer receives a Request for an unacceptable authentication
Type (4-253,255), or a peer lacking support for Expanded Types 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 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 sent. The Type-Data field of the Nak Response (Type 3) MUST
contain one or more octets indicating the desired authentication contain one or more octets indicating the desired authentication
Type(s), one octet per Type, or the value zero (0) to indicate no Type(s), one octet per Type, or the value zero (0) to indicate no
proposed alternative. A peer supporting Expanded Types that proposed alternative. A peer supporting Expanded Types that
receives a Request for an unacceptable authentication Type (4-253, receives a Request for an unacceptable authentication Type (4-253,
255) MAY include the value 254 in the Nak Response (Type 3) to 255) MAY include the value 254 in the Nak Response (Type 3) to
indicate the desire for an Expanded authentication Type. If the indicate the desire for an Expanded authentication Type. If the
authenticator can accommodate this preference, it will respond authenticator can accommodate this preference, it will respond
with an Expanded Type Request (Type 254). with an Expanded Type Request (Type 254).
Security Claims (see Section 7.2): Security Claims (see Section 7.2):
Auth. mechanism: None Auth. mechanism: None
Ciphersuite negotiation: No Ciphersuite negotiation: No
Mutual authentication: No Mutual authentication: No
Integrity protection: No Integrity protection: No
Replay protection: No Replay protection: No
Confidentiality: No Confidentiality: No
Key derivation: No Key derivation: No
Key strength: N/A Key strength: N/A
Dictionary attack prot.: N/A Dictionary attack prot.: N/A
Fast reconnect: No Fast reconnect: No
Crypt. binding: N/A Crypt. binding: N/A
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No Channel binding: No
Perfect Forward Secrecy: N/A
5.3.2. Expanded Nak 5.3.2. Expanded Nak
Description Description
The Expanded Nak Type is valid only in Response messages. It MUST 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) be sent only in reply to a Request of Type 254 (Expanded Type)
where the authentication Type is unacceptable. The Expanded Nak where the authentication Type is unacceptable. The Expanded Nak
Type uses the Expanded Type format itself, and the Response Type uses the Expanded Type format itself, and the Response
contains one or more authentication Types desired by the peer, all contains one or more authentication Types desired by the peer, all
skipping to change at page 34, line 23 skipping to change at page 35, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) | | Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (OTP) | | 5 (OTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 20 (MIT) | | Type=254 | 20 (MIT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An Expanded Nak Response indicating a no desired alternative would An Expanded Nak Response indicating a no desired alternative would
appear as follows: appear as follows:
0 1 2 3 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 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 | | 2 | Identifier | Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) | | Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) | | 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 7 skipping to change at page 36, line 19
Replay protection: No Replay protection: No
Confidentiality: No Confidentiality: No
Key derivation: No Key derivation: No
Key strength: N/A Key strength: N/A
Dictionary attack prot.: N/A Dictionary attack prot.: N/A
Fast reconnect: No Fast reconnect: No
Crypt. binding: N/A Crypt. binding: N/A
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No Channel binding: No
Perfect Forward Secrecy: N/A
5.4. MD5-Challenge 5.4. MD5-Challenge
Description Description
The MD5-Challenge Type is analogous to the PPP CHAP protocol The MD5-Challenge Type is analogous to the PPP CHAP protocol
[RFC1994] (with MD5 as the specified algorithm). The Request [RFC1994] (with MD5 as the specified algorithm). The Request
contains a "challenge" message to the peer. A Response MUST be contains a "challenge" message to the peer. A Response MUST be
sent in reply to the Request. The Response MAY be either of Type 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 4 (MD5-Challenge), Nak (Type 3), or Expanded Nak (Type 254). The
skipping to change at page 35, line 35 skipping to change at page 36, line 48
then the requirement for support of the MD5-Challenge mechanism then the requirement for support of the MD5-Challenge mechanism
applies. applies.
Note that the use of the Identifier field in the MD5-Challenge Note that the use of the Identifier field in the MD5-Challenge
Type is different from that described in [RFC1994]. EAP allows Type is different from that described in [RFC1994]. EAP allows
for retransmission of MD5-Challenge Request packets, while for retransmission of MD5-Challenge Request packets, while
[RFC1994] states that both the Identifier and Challenge fields [RFC1994] states that both the Identifier and Challenge fields
MUST change each time a Challenge (the CHAP equivalent of the MUST change each time a Challenge (the CHAP equivalent of the
MD5-Challenge Request packet) is sent. MD5-Challenge Request packet) is sent.
Note: [RFC1994] treats the shared secret as an octet string, and Note 1. MD5 algorithm has severe issues, particularly when used
without HMAC (which is not used by CHAP or EAP-MD5). For more
information, refer to Section 7.11.1.
Note 2: [RFC1994] treats the shared secret as an octet string, and
does not specify how it is entered into the system (or if it is does not specify how it is entered into the system (or if it is
handled by the user at all). EAP MD5-Challenge implementations handled by the user at all). EAP MD5-Challenge implementations
MAY support entering passphrases with non-ASCII characters. See MAY support entering passphrases with non-ASCII characters. See
Section 5 for instructions how the input should be processed and Section 5 for instructions how the input should be processed and
encoded into octets. encoded into octets.
Type Type
4 4
skipping to change at page 36, line 29 skipping to change at page 37, line 46
Replay protection: No Replay protection: No
Confidentiality: No Confidentiality: No
Key derivation: No Key derivation: No
Key strength: N/A Key strength: N/A
Dictionary attack prot.: No Dictionary attack prot.: No
Fast reconnect: No Fast reconnect: No
Crypt. binding: N/A Crypt. binding: N/A
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No Channel binding: No
Perfect Forward Secrecy: N/A
5.5. One-Time Password (OTP) 5.5. One-Time Password (OTP)
Description Description
The One-Time Password system is defined in "A One-Time Password The One-Time Password system is defined in "A One-Time Password
System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The
Request contains an OTP challenge in the format described in Request contains an OTP challenge in the format described in
[RFC2289]. A Response MUST be sent in reply to the Request. The [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 Response MUST be of Type 5 (OTP), Nak (Type 3), or Expanded Nak
skipping to change at page 37, line 35 skipping to change at page 39, line 19
Replay protection: Yes Replay protection: Yes
Confidentiality: No Confidentiality: No
Key derivation: No Key derivation: No
Key strength: N/A Key strength: N/A
Dictionary attack prot.: No Dictionary attack prot.: No
Fast reconnect: No Fast reconnect: No
Crypt. binding: N/A Crypt. binding: N/A
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No Channel binding: No
Perfect Forward Secrecy: N/A
5.6. Generic Token Card (GTC) 5.6. Generic Token Card (GTC)
Description Description
The Generic Token Card Type is defined for use with various Token The Generic Token Card Type is defined for use with various Token
Card implementations which require user input. The Request Card implementations which require user input. The Request
contains a displayable message and the Response contains the Token contains a displayable message and the Response contains the Token
Card information necessary for authentication. Typically, this Card information necessary for authentication. Typically, this
would be information read by a user from the Token card device and would be information read by a user from the Token card device and
skipping to change at page 38, line 43 skipping to change at page 40, line 27
Replay protection: No Replay protection: No
Confidentiality: No Confidentiality: No
Key derivation: No Key derivation: No
Key strength: N/A Key strength: N/A
Dictionary attack prot.: No Dictionary attack prot.: No
Fast reconnect: No Fast reconnect: No
Crypt. binding: N/A Crypt. binding: N/A
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No Channel binding: No
Perfect Forward Secrecy: N/A
5.7. Expanded Types 5.7. Expanded Types
Description Description
Since many of the existing uses of EAP are vendor-specific, the Since many of the existing uses of EAP are vendor-specific, the
Expanded method Type is available to allow vendors to support Expanded method Type is available to allow vendors to support
their own Expanded Types not suitable for general usage. their own Expanded Types not suitable for general usage.
The Expanded Type is also used to expand the global Method Type The Expanded Type is also used to expand the global Method Type
skipping to change at page 40, line 38 skipping to change at page 42, line 27
255 255
Type-Data Type-Data
Undefined Undefined
6. IANA Considerations 6. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the EAP Authority (IANA) regarding registration of values related to the EAP
protocol, in accordance with BCP 26, [RFC2434]. protocol, in accordance with BCP 26, [RFC8126].
There are two name spaces in EAP that require registration: Packet There are two name spaces in EAP that require registration: Packet
Codes and method Types. Codes and method Types.
EAP is not intended as a general-purpose protocol, and allocations EAP is not intended as a general-purpose protocol, and allocations
SHOULD NOT be made for purposes unrelated to authentication. SHOULD NOT be made for purposes unrelated to authentication.
The following terms are used here with the meanings defined in BCP The following terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration". 26: "name space", "assigned value", "registration".
The following policies are used here with the meanings defined in BCP The following policies are used here with the meanings defined in BCP
26: "Private Use", "First Come First Served", "Expert Review", 26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IETF Consensus", "Standards Action". "Specification Required", "IETF Review", "Standards Action".
For registration requests where a Designated Expert should be For registration requests where a Designated Expert should be
consulted, the responsible IESG area director should appoint the consulted, the responsible IESG area director should appoint the
Designated Expert. The intention is that any allocation will be Designated Expert. The intention is that any allocation will be
accompanied by a published RFC. But in order to allow for the accompanied by a published RFC. But in order to allow for the
allocation of values prior to the RFC being approved for publication, allocation of values prior to the RFC being approved for publication,
the Designated Expert can approve allocations once it seems clear the Designated Expert can approve allocations once it seems clear
that an RFC will be published. The Designated expert will post a 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 request to the EAP WG mailing list (or a successor designated by the
Area Director) for comment and review, including an Internet-Draft. Area Director) for comment and review, including an Internet-Draft.
skipping to change at page 41, line 25 skipping to change at page 43, line 17
either approve or deny the registration request and publish a notice 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 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 as informing IANA. A denial notice must be justified by an
explanation, and in the cases where it is possible, concrete explanation, and in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become suggestions on how the request can be modified so as to become
acceptable should be provided. acceptable should be provided.
6.1. Packet Codes 6.1. Packet Codes
Packet Codes have a range from 1 to 255, of which 1-4 have been 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 allocated by this document and 5-6 by [RFC6696]. Because a new
interoperability, a new Packet Code requires Standards Action, and Packet Code has considerable impact on interoperability, a new Packet
should be allocated starting at 5. Code requires Standards Action, and should be allocated starting at
5.
6.2. Method Types 6.2. Method Types
The original EAP method Type space has a range from 1 to 255, and is 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. 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 Type 0 is reserved. Method Types 1-55 have been allocated,
Method Types 20 and 46-191 may be allocated on the advice of a with 20 available for re-use. Method Types 20 and 56-191 may be
Designated Expert, with Specification Required. allocated through Expert Review, on the advice of a Designated
Expert, with Specification Required.
Allocation of blocks of method Types (more than one for a given Allocation of blocks of method Types (more than one for a given
purpose) should require IETF Consensus. EAP Type Values 192-253 are purpose) should require IETF Review. EAP Type Values 192-253 are
reserved and allocation requires Standards Action. reserved and allocation requires Standards Action.
Method Type 254 is allocated for the Expanded Type. Where the Method Type 254 is allocated for the Expanded Type. Where the
Vendor-Id field is non-zero, the Expanded Type is used for functions Vendor-Id field is non-zero, the Expanded Type is used for functions
specific only to one vendor's implementation of EAP, where no specific only to one vendor's implementation of EAP, where no
interoperability is deemed useful. When used with a Vendor-Id of interoperability is deemed useful. When used with a Vendor-Id of
zero, method Type 254 can also be used to provide for an expanded zero, method Type 254 can also be used to provide for an expanded
IETF method Type space. Method Type values 256-4294967295 may be IETF method Type space. Method Type values 256-4294967295 may be
allocated after Type values 1-191 have been allocated, on the advice allocated after Type values 1-191 have been allocated, on the advice
of a Designated Expert, with Specification Required. of a Designated Expert, with Specification Required.
skipping to change at page 42, line 20 skipping to change at page 44, line 15
It is expected that the generic threat model and corresponding It is expected that the generic threat model and corresponding
security claims will used to define EAP method requirements for use security claims will used to define EAP method requirements for use
in specific environments. An example of such a requirements analysis in specific environments. An example of such a requirements analysis
is provided in [IEEE-802.11i-req]. A security claims section is is provided in [IEEE-802.11i-req]. A security claims section is
required in EAP method specifications, so that EAP methods can be required in EAP method specifications, so that EAP methods can be
evaluated against the requirements. evaluated against the requirements.
7.1. Threat Model 7.1. Threat Model
EAP was developed for use with PPP [RFC1661] and was later adapted 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]. for use in wired IEEE 802 networks [IEEE-802] in [IEEE-802.1X] and
Subsequently, EAP has been proposed for use on wireless LAN networks 3GPP 5G [TS.33.501]. Subsequently, EAP has been proposed for use on
and over the Internet. In all these situations, it is possible for wireless LAN networks and over the Internet. In all these
an attacker to gain access to links over which EAP packets are situations, it is possible for an attacker to gain access to links
transmitted. For example, attacks on telephone infrastructure are over which EAP packets are transmitted. For example, attacks on
documented in [DECEPTION]. telephone infrastructure are documented in [DECEPTION].
An attacker with access to the link may carry out a number of An attacker with access to the link may carry out a number of
attacks, including: attacks, including:
[1] An attacker may try to discover user identities by snooping 1. An attacker may try to discover user identities by snooping
authentication traffic. authentication traffic.
[2] An attacker may try to modify or spoof EAP packets. 2. An attacker may try to modify or spoof EAP packets.
[3] An attacker may launch denial of service attacks by spoofing 3. An attacker may launch denial of service attacks by spoofing
lower layer indications or Success/Failure packets, by replaying lower layer indications or Success/Failure packets, by replaying
EAP packets, or by generating packets with overlapping EAP packets, or by generating packets with overlapping
Identifiers. Identifiers.
[4] An attacker may attempt to recover the pass-phrase by mounting 4. An attacker may attempt to recover the pass-phrase by mounting
an offline dictionary attack. an offline dictionary attack.
[5] An attacker may attempt to convince the peer to connect to an 5. An attacker may attempt to convince the peer to connect to an
untrusted network by mounting a man-in-the-middle attack. untrusted network by mounting a man-in-the-middle attack.
[6] An attacker may attempt to disrupt the EAP negotiation in order 6. An attacker may attempt to disrupt the EAP negotiation in order
cause a weak authentication method to be selected. cause a weak authentication method to be selected.
[7] An attacker may attempt to recover keys by taking advantage of 7. An attacker may attempt to recover keys by taking advantage of
weak key derivation techniques used within EAP methods. weak key derivation techniques used within EAP methods.
[8] An attacker may attempt to take advantage of weak ciphersuites 8. An attacker may attempt to take advantage of weak ciphersuites
subsequently used after the EAP conversation is complete. subsequently used after the EAP conversation is complete.
[9] An attacker may attempt to perform downgrading attacks on lower 9. An attacker may attempt to perform downgrading attacks on lower
layer ciphersuite negotiation in order to ensure that a weaker layer ciphersuite negotiation in order to ensure that a weaker
ciphersuite is used subsequently to EAP authentication. ciphersuite is used subsequently to EAP authentication.
[10] An attacker acting as an authenticator may provide incorrect 10. An attacker acting as an authenticator may provide incorrect
information to the EAP peer and/or server via out-of-band information to the EAP peer and/or server via out-of-band
mechanisms (such as via a AAA or lower layer protocol). This mechanisms (such as via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server. inconsistent information to the peer and EAP server.
Depending on the lower layer, these attacks may be carried out Depending on the lower layer, these attacks may be carried out
without requiring physical proximity. Where EAP is used over without requiring physical proximity. Where EAP is used over
wireless networks, EAP packets may be forwarded by authenticators wireless networks, EAP packets may be forwarded by authenticators
(e.g., pre-authentication) so that the attacker need not be within (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 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 on it or its peers. Where EAP is used over the Internet, attacks may
be carried out at an even greater distance. be carried out at an even greater distance.
7.2. Security Claims 7.2. Security Claims
In order to clearly articulate the security provided by an EAP In order to clearly articulate the security provided by an EAP
method, EAP method specifications MUST include a Security Claims method, EAP method specifications MUST include a Security Claims
section, including the following declarations: section, including the following declarations:
[a] Mechanism. This is a statement of the authentication technology: o Mechanism. This is a statement of the authentication technology:
certificates, pre-shared keys, passwords, token cards, etc. certificates, pre-shared keys, passwords, token cards, etc.
[b] Security claims. This is a statement of the claimed security o Security claims. This is a statement of the claimed security
properties of the method, using terms defined in Section 7.2.1: properties of the method, using terms defined in Section 7.2.1:
mutual authentication, integrity protection, replay protection, mutual authentication, integrity protection, replay protection,
confidentiality, key derivation, dictionary attack resistance, confidentiality, key derivation, key strength, dictionary attack
fast reconnect, cryptographic binding. The Security Claims resistance, fast reconnect, cryptographic binding, session
section of an EAP method specification SHOULD provide independance, fragmentation, channel binding, perfect forward
justification for the claims that are made. This can be secrecy. The Security Claims section of an EAP method
accomplished by including a proof in an Appendix, or including a specification SHOULD provide justification for the claims that are
reference to a proof. 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 o Key strength. If the method derives keys, then the effective key
strength MUST be estimated. This estimate is meant for potential strength MUST be estimated. This estimate is meant for potential
users of the method to determine if the keys produced are strong users of the method to determine if the keys produced are strong
enough for the intended application. enough for the intended application.
The effective key strength SHOULD be stated as a number of bits, The effective key strength SHOULD be stated as a number of bits,
defined as follows: If the effective key strength is N bits, the defined as follows: If the effective key strength is N bits, the
best currently known methods to recover the key (with non- best currently known methods to recover the key (with non-
negligible probability) require, on average, an effort comparable negligible probability) require, on average, an effort comparable
to 2^(N-1) operations of a typical block cipher. The statement to 2^(N-1) operations of a typical block cipher. The statement
SHOULD be accompanied by a short rationale, explaining how this SHOULD be accompanied by a short rationale, explaining how this
number was derived. This explanation SHOULD include the number was derived. This explanation SHOULD include the
parameters required to achieve the stated key strength based on parameters required to achieve the stated key strength based on
current knowledge of the algorithms. current knowledge of the algorithms.
(Note: Although it is difficult to define what "comparable (Note: Although it is difficult to define what "comparable effort"
effort" and "typical block cipher" exactly mean, reasonable and "typical block cipher" exactly mean, reasonable approximations
approximations are sufficient here. Refer to e.g. [SILVERMAN] are sufficient here. Refer to e.g. [SILVERMAN] for more
for more discussion.) discussion.)
The key strength depends on the methods used to derive the keys. 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 For instance, if keys are derived from a shared secret (such as a
password or a long-term secret), and possibly some public password or a long-term secret), and possibly some public
information such as nonces, the effective key strength is limited information such as nonces, the effective key strength is limited
by the strength of the long-term secret (assuming that the by the strength of the long-term secret (assuming that the
derivation procedure is computationally simple). To take another derivation procedure is computationally simple). To take another
example, when using public key algorithms, the strength of the example, when using public key algorithms, the strength of the
symmetric key depends on the strength of the public keys used. symmetric key depends on the strength of the public keys used.
[d] Description of key hierarchy. EAP methods deriving keys MUST o Description of key hierarchy. EAP methods deriving keys MUST
either provide a reference to a key hierarchy specification, or either provide a reference to a key hierarchy specification, or
describe how Master Session Keys (MSKs) and Extended Master describe how Master Session Keys (MSKs) and Extended Master
Session Keys (EMSKs) are to be derived. Session Keys (EMSKs) are to be derived.
[e] Indication of vulnerabilities. In addition to the security o Indication of vulnerabilities. In addition to the security claims
claims that are made, the specification MUST indicate which of that are made, the specification MUST indicate which of the
the security claims detailed in Section 7.2.1 are NOT being made. security claims detailed in Section 7.2.1 are NOT being made.
7.2.1. Security Claims Terminology for EAP Methods 7.2.1. Security Claims Terminology for EAP Methods
These terms are used to describe the security properties of EAP These terms are used to describe the security properties of EAP
methods: methods:
Protected ciphersuite negotiation Protected ciphersuite negotiation
This refers to the ability of an EAP method to negotiate the This refers to the ability of an EAP method to negotiate the
ciphersuite used to protect the EAP conversation, as well as to ciphersuite used to protect the EAP conversation, as well as to
integrity protect the negotiation. It does not refer to the integrity protect the negotiation. It does not refer to the
ability to negotiate the ciphersuite used to protect data. ability to negotiate the ciphersuite used to protect data.
Mutual authentication Mutual authentication
This refers to an EAP method in which, within an interlocked This refers to an EAP method in which, within an interlocked
exchange, the authenticator authenticates the peer and the peer exchange, the authenticator authenticates the peer and the peer
authenticates the authenticator. Two independent one-way methods, authenticates the authenticator. Two independent one-way methods,
running in opposite directions do not provide mutual running in opposite directions do not provide mutual
authentication as defined here. authentication as defined here.
Integrity protection Integrity protection
This refers to providing data origin authentication and protection This refers to providing data origin authentication and protection
against unauthorized modification of information for EAP packets against unauthorized modification of information for EAP packets
(including EAP Requests and Responses). When making this claim, a (including EAP Requests and Responses). When making this claim, a
method specification MUST describe the EAP packets and fields method specification MUST describe the EAP packets and fields
within the EAP packet that are protected. within the EAP packet that are protected.
Replay protection Replay protection
This refers to protection against replay of an EAP method or its This refers to protection against replay of an EAP method or its
messages, including success and failure result indications. messages, including success and failure result indications.
Confidentiality Confidentiality
This refers to encryption of EAP messages, including EAP Requests This refers to encryption of EAP messages, including EAP Requests
and Responses, and success and failure result indications. A and Responses, and success and failure result indications. A
method making this claim MUST support identity protection (see method making this claim MUST support identity protection (see
Section 7.3). Section 7.3).
Key derivation Key derivation
This refers to the ability of the EAP method to derive exportable This refers to the ability of the EAP method to derive exportable
keying material, such as the Master Session Key (MSK), and keying material, such as the Master Session Key (MSK), and
Extended Master Session Key (EMSK). The MSK is used only for Extended Master Session Key (EMSK). The MSK is used only for
further key derivation, not directly for protection of the EAP further key derivation, not directly for protection of the EAP
conversation or subsequent data. Use of the EMSK is reserved. conversation or subsequent data. Use of the EMSK is reserved.
Key strength Key strength
If the effective key strength is N bits, the best currently known If the effective key strength is N bits, the best currently known
methods to recover the key (with non-negligible probability) methods to recover the key (with non-negligible probability)
require, on average, an effort comparable to 2^(N-1) operations of require, on average, an effort comparable to 2^(N-1) operations of
a typical block cipher. a typical block cipher.
Dictionary attack resistance Dictionary attack resistance
Where password authentication is used, passwords are commonly Where password authentication is used, passwords are commonly
selected from a small set (as compared to a set of N-bit keys), 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 which raises a concern about dictionary attacks. A method may be
said to provide protection against dictionary attacks if, when it said to provide protection against dictionary attacks if, when it
uses a password as a secret, the method does not allow an offline 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 attack that has a work factor based on the number of passwords in
an attacker's dictionary. an attacker's dictionary.
Fast reconnect Fast reconnect
The ability, in the case where a security association has been The ability, in the case where a security association has been
previously established, to create a new or refreshed security previously established, to create a new or refreshed security
association more efficiently or in a smaller number of round- association more efficiently or in a smaller number of round-
trips. trips.
Cryptographic binding Cryptographic binding
The demonstration of the EAP peer to the EAP server that a single 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 entity has acted as the EAP peer for all methods executed within a
tunnel method. Binding MAY also imply that the EAP server tunnel method. Binding MAY also imply that the EAP server
demonstrates to the peer that a single entity has acted as the EAP demonstrates to the peer that a single entity has acted as the EAP
skipping to change at page 46, line 21 skipping to change at page 48, line 13
Cryptographic binding Cryptographic binding
The demonstration of the EAP peer to the EAP server that a single 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 entity has acted as the EAP peer for all methods executed within a
tunnel method. Binding MAY also imply that the EAP server tunnel method. Binding MAY also imply that the EAP server
demonstrates to the peer that a single entity has acted as the EAP demonstrates to the peer that a single entity has acted as the EAP
server for all methods executed within a tunnel method. If server for all methods executed within a tunnel method. If
executed correctly, binding serves to mitigate man-in-the-middle executed correctly, binding serves to mitigate man-in-the-middle
vulnerabilities. vulnerabilities.
Session independence Session independence
The demonstration that passive attacks (such as capture of the EAP The demonstration that passive attacks (such as capture of the EAP
conversation) or active attacks (including compromise of the MSK conversation) or active attacks (including compromise of the MSK
or EMSK) does not enable compromise of subsequent or prior MSKs or or EMSK) does not enable compromise of subsequent or prior MSKs or
EMSKs. EMSKs.
Fragmentation Fragmentation
This refers to whether an EAP method supports fragmentation and This refers to whether an EAP method supports fragmentation and
reassembly. As noted in Section 3.1, EAP methods should support reassembly. As noted in Section 3.1, EAP methods should support
fragmentation and reassembly if EAP packets can exceed the minimum fragmentation and reassembly if EAP packets can exceed the minimum
MTU of 1020 octets. MTU of 1020 octets.
Channel binding Channel binding
The communication within an EAP method of integrity-protected The communication within an EAP method of integrity-protected
channel properties such as endpoint identifiers which can be channel properties such as endpoint identifiers which can be
compared to values communicated via out of band mechanisms (such compared to values communicated via out of band mechanisms (such
as via a AAA or lower layer protocol). as via a AAA or lower layer protocol).
Perfect Forward Secrecy
The demonstration that the derived keying material, such as the
MSK and EMSK will not be compromised even if long-term secrets
used in EAP conversation are compromised.
Note: This list of security claims is not exhaustive. Additional Note: This list of security claims is not exhaustive. Additional
properties, such as additional denial-of-service protection, may be properties, such as additional denial-of-service protection, may be
relevant as well. relevant as well.
7.3. Identity Protection 7.3. Identity Protection
An Identity exchange is optional within the EAP conversation. An Identity exchange is optional within the EAP conversation.
Therefore, it is possible to omit the Identity exchange entirely, or Therefore, it is possible to omit the Identity exchange entirely, or
to use a method-specific identity exchange once a protected channel to use a method-specific identity exchange once a protected channel
has been established. has been established.
However, where roaming is supported as described in [RFC2607], it may However, where roaming is supported as described in [RFC2607], it may
be necessary to locate the appropriate backend authentication server be necessary to locate the appropriate backend authentication server
before the authentication conversation can proceed. The realm before the authentication conversation can proceed. The realm
portion of the Network Access Identifier (NAI) [RFC2486] is typically portion of the Network Access Identifier (NAI) [RFC2486] is typically
included within the EAP-Response/Identity in order to enable the included within the EAP-Response/Identity in order to enable the
authentication exchange to be routed to the appropriate backend authentication exchange to be routed to the appropriate backend
authentication server. Therefore, while the peer-name portion of the authentication server. Therefore, while the peer-name portion of the
NAI may be omitted in the EAP-Response/Identity where proxies or NAI SHOULD be omitted in the EAP-Response/Identity where proxies or
relays are present, the realm portion may be required. relays are present, the realm portion may be required.
It is possible for the identity in the identity response to be It is possible for the identity in the identity response to be
different from the identity authenticated by the EAP method. This different from the identity authenticated by the EAP method. This
may be intentional in the case of identity privacy. An EAP method may be intentional in the case of identity privacy. An EAP method
SHOULD use the authenticated identity when making access control SHOULD use the authenticated identity when making access control
decisions. decisions.
7.4. Man-in-the-Middle Attacks 7.4. Man-in-the-Middle Attacks
Where EAP is tunneled within another protocol that omits peer Where EAP is tunneled within another protocol that omits peer
authentication, there exists a potential vulnerability to a man-in- authentication, there exists a potential vulnerability to a man-in-
the-middle attack. For details, see [BINDING] and [MITM]. the-middle attack. For details, see [I-D.puthenkulam-eap-binding]
and [MITM].
As noted in Section 2.1, EAP does not permit untunneled sequences of As noted in Section 2.1, EAP does not permit untunneled sequences of
authentication methods. Were a sequence of EAP authentication authentication methods. Were a sequence of EAP authentication
methods to be permitted, the peer might not have proof that a single 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 entity has acted as the authenticator for all EAP methods within the
sequence. For example, an authenticator might terminate one EAP sequence. For example, an authenticator might terminate one EAP
method, then forward the next method in the sequence to another party method, then forward the next method in the sequence to another party
without the peer's knowledge or consent. Similarly, the without the peer's knowledge or consent. Similarly, the
authenticator might not have proof that a single entity has acted as authenticator might not have proof that a single entity has acted as
the peer for all EAP methods within the sequence. the peer for all EAP methods within the sequence.
skipping to change at page 47, line 44 skipping to change at page 49, line 47
tunneling protocol is used for key establishment but does not require tunneling protocol is used for key establishment but does not require
peer authentication, an attacker convincing a legitimate peer to peer authentication, an attacker convincing a legitimate peer to
connect to it will be able to tunnel EAP packets to a legitimate connect to it will be able to tunnel EAP packets to a legitimate
server, successfully authenticating and obtaining the key. This server, successfully authenticating and obtaining the key. This
allows the attacker to successfully establish itself as a man-in- allows the attacker to successfully establish itself as a man-in-
the-middle, gaining access to the network, as well as the ability to the-middle, gaining access to the network, as well as the ability to
decrypt data traffic between the legitimate peer and server. decrypt data traffic between the legitimate peer and server.
This attack may be mitigated by the following measures: This attack may be mitigated by the following measures:
[a] Requiring mutual authentication within EAP tunneling mechanisms. 1. Requiring mutual authentication within EAP tunneling mechanisms.
[b] Requiring cryptographic binding between the EAP tunneling 2. Requiring cryptographic binding between the EAP tunneling
protocol and the tunneled EAP methods. Where cryptographic protocol and the tunneled EAP methods. Where cryptographic
binding is supported, a mechanism is also needed to protect binding is supported, a mechanism is also needed to protect
against downgrade attacks that would bypass it. For further against downgrade attacks that would bypass it. For further
details on cryptographic binding, see [BINDING]. details on cryptographic binding, see
[I-D.puthenkulam-eap-binding].
[c] Limiting the EAP methods authorized for use without protection, 3. Limiting the EAP methods authorized for use without protection,
based on peer and authenticator policy. based on peer and authenticator policy.
[d] Avoiding the use of tunnels when a single, strong method is 4. Avoiding the use of tunnels when a single, strong method is
available. available.
7.5. Packet Modification Attacks 7.5. Packet Modification Attacks
While EAP methods may support per-packet data origin authentication, While EAP methods may support per-packet data origin authentication,
integrity, and replay protection, support is not provided within the integrity, and replay protection, support is not provided within the
EAP layer. EAP layer.
Since the Identifier is only a single octet, it is easy to guess, Since the Identifier is only a single octet, it is easy to guess,
allowing an attacker to successfully inject or replay EAP packets. allowing an attacker to successfully inject or replay EAP packets.
skipping to change at page 48, line 47 skipping to change at page 50, line 50
packets include coverage of all the EAP header fields, including the packets include coverage of all the EAP header fields, including the
Code, Identifier, Length, Type, and Type-Data fields. Code, Identifier, Length, Type, and Type-Data fields.
Since EAP messages of Types Identity, Notification, and Nak do not 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 include their own MIC, it may be desirable for the EAP method MIC to
cover information contained within these messages, as well as the cover information contained within these messages, as well as the
header of each EAP message. header of each EAP message.
To provide protection, EAP also may be encapsulated within a To provide protection, EAP also may be encapsulated within a
protected channel created by protocols such as ISAKMP [RFC2408], as protected channel created by protocols such as ISAKMP [RFC2408], as
is done in [IKEv2] or within TLS [RFC2246]. However, as noted in is done in [RFC7296] or within TLS [RFC2246]. However, as noted in
Section 7.4, EAP tunneling may result in a man-in-the-middle Section 7.4, EAP tunneling may result in a man-in-the-middle
vulnerability. vulnerability.
Existing EAP methods define message integrity checks (MICs) that Existing EAP methods define message integrity checks (MICs) that
cover more than one EAP packet. For example, EAP-TLS [RFC2716] cover more than one EAP packet. For example, EAP-TLS
defines a MIC over a TLS record that could be split into multiple [RFC5216][I-D.ietf-emu-eap-tls13] defines a MIC over a TLS record
fragments; within the FINISHED message, the MIC is computed over that could be split into multiple fragments; within the FINISHED
previous messages. Where the MIC covers more than one EAP packet, a message, the MIC is computed over previous messages. Where the MIC
MIC validation failure is typically considered a fatal error. 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 Within EAP-TLS [RFC5216][I-D.ietf-emu-eap-tls13], a MIC validation
fatal error, since that is what is specified in TLS [RFC2246]. failure is treated as a fatal error, since that is what is specified
However, it is also possible to develop EAP methods that support in TLS [RFC2246]. However, it is also possible to develop EAP
per-packet MICs, and respond to verification failures by silently methods that support per-packet MICs, and respond to verification
discarding the offending packet. failures by silently discarding the offending packet.
In this document, descriptions of EAP message handling assume that In this document, descriptions of EAP message handling assume that
per-packet MIC validation, where it occurs, is effectively performed per-packet MIC validation, where it occurs, is effectively performed
as though it occurs before sending any responses or changing the as though it occurs before sending any responses or changing the
state of the host which received the packet. state of the host which received the packet.
7.6. Dictionary Attacks 7.6. Dictionary Attacks
Password authentication algorithms such as EAP-MD5, MS-CHAPv1 Password authentication algorithms such as EAP-MD5, MS-CHAPv1
[RFC2433], and Kerberos V [RFC1510] are known to be vulnerable to [RFC2433], and Kerberos V [RFC1510] are known to be vulnerable to
skipping to change at page 51, line 25 skipping to change at page 53, line 30
The MSK and EMSK MUST NOT be used directly to protect data; however, 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 they are of sufficient size to enable derivation of a AAA-Key
subsequently used to derive Transient Session Keys (TSKs) for use subsequently used to derive Transient Session Keys (TSKs) for use
with the selected ciphersuite. Each ciphersuite is responsible for with the selected ciphersuite. Each ciphersuite is responsible for
specifying how to derive the TSKs from the AAA-Key. specifying how to derive the TSKs from the AAA-Key.
The AAA-Key is derived from the keying material exported by the EAP 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 method (MSK and EMSK). This derivation occurs on the AAA server. In
many existing protocols that use EAP, the AAA-Key and MSK are many existing protocols that use EAP, the AAA-Key and MSK are
equivalent, but more complicated mechanisms are possible (see equivalent, but more complicated mechanisms are possible (see
[KEYFRAME] for details). [RFC5247] for details).
EAP methods SHOULD ensure the freshness of the MSK and EMSK, even in 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 cases where one party may not have a high quality random number
generator. A RECOMMENDED method is for each party to provide a nonce 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. 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 EAP methods export the MSK and EMSK, but not Transient Session Keys
so as to allow EAP methods to be ciphersuite and media independent. so as to allow EAP methods to be ciphersuite and media independent.
Keying material exported by EAP methods MUST be independent of the Keying material exported by EAP methods MUST be independent of the
ciphersuite negotiated to protect data. ciphersuite negotiated to protect data.
skipping to change at page 52, line 44 skipping to change at page 54, line 51
which remains valid on another party. which remains valid on another party.
This specification does not provide detailed guidance on how EAP This specification does not provide detailed guidance on how EAP
methods derive the MSK and EMSK, how the AAA-Key is derived from the 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. MSK and/or EMSK, or how the TSKs are derived from the AAA-Key.
The development and validation of key derivation algorithms is The development and validation of key derivation algorithms is
difficult, and as a result, EAP methods SHOULD re-use well difficult, and as a result, EAP methods SHOULD re-use well
established and analyzed mechanisms for key derivation (such as those established and analyzed mechanisms for key derivation (such as those
specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing
new ones. EAP methods SHOULD also utilize well established and new ones. EAP methods SHOULD also utilize well established and
analyzed mechanisms for MSK and EMSK derivation. Further details on analyzed mechanisms for MSK and EMSK derivation. Further details on
EAP Key Derivation are provided within [KEYFRAME]. EAP Key Derivation are provided within [RFC5247].
7.11. Weak Ciphersuites 7.11. Weak Ciphersuites
If after the initial EAP authentication, data packets are sent If after the initial EAP authentication, data packets are sent
without per-packet authentication, integrity, and replay protection, without per-packet authentication, integrity, and replay protection,
an attacker with access to the media can inject packets, "flip bits" an attacker with access to the media can inject packets, "flip bits"
within existing packets, replay packets, or even hijack the session within existing packets, replay packets, or even hijack the session
completely. Without per-packet confidentiality, it is possible to completely. Without per-packet confidentiality, it is possible to
snoop data packets. snoop data packets.
skipping to change at page 53, line 33 skipping to change at page 55, line 35
downgrading attacks which would lead to weaker ciphersuites being downgrading attacks which would lead to weaker ciphersuites being
used, clients implementing lower layer ciphersuite negotiation SHOULD used, clients implementing lower layer ciphersuite negotiation SHOULD
protect against negotiation downgrading. protect against negotiation downgrading.
This can be done by enabling users to configure which ciphersuites This can be done by enabling users to configure which ciphersuites
are acceptable as a matter of security policy, or the ciphersuite are acceptable as a matter of security policy, or the ciphersuite
negotiation MAY be authenticated using keying material derived from negotiation MAY be authenticated using keying material derived from
the EAP authentication and a MIC algorithm agreed upon in advance by the EAP authentication and a MIC algorithm agreed upon in advance by
lower-layer peers. lower-layer peers.
7.11.1. Legacy Authentication Methods
EAP has a long history, and the early authentication methods have
severe issues. For instance, the MD5-Challenge method uses an
algorithm that has problems described in [RFC6151]. These problems
are particularly pressing, given that MD5-Challenge does not employ a
HMAC construction. The use of MD5-Challenge is NOT RECOMMENDED, at
least not outside an external, tunneled authentication method.
Users and network administrators must be aware of the security issues
in the authentication methods they choose to allow and use. Modern
use of EAP employes typically newer authentication methods such as
Transport Layer Security (EAP-TLS) [I-D.ietf-emu-eap-tls13], Tunnel
Extensible Authentication Protocol (TEAP) [RFC7170], or 3rd
Generation Authentication and Key Agreement (EAP-AKA')
[I-D.ietf-emu-rfc5448bis].
7.12. Link Layer 7.12. Link Layer
There are reliability and security issues with link layer indications There are reliability and security issues with link layer indications
in PPP, IEEE 802 LANs, and IEEE 802.11 wireless LANs: in PPP, IEEE 802 LANs, and IEEE 802.11 wireless LANs:
[a] PPP. In PPP, link layer indications such as LCP-Terminate (a 1. PPP. In PPP, link layer indications such as LCP-Terminate (a
link failure indication) and NCP (a link success indication) are link failure indication) and NCP (a link success indication) are
not authenticated or integrity protected. They can therefore be not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the link. spoofed by an attacker with access to the link.
[b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are 2. IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are
not authenticated or integrity protected. They can therefore be not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the link. spoofed by an attacker with access to the link.
[c] IEEE 802.11. In IEEE 802.11, link layer indications include 3. IEEE 802.11. In IEEE 802.11, link layer indications include
Disassociate and Deauthenticate frames (link failure Disassociate and Deauthenticate frames (link failure
indications), and the first message of the 4-way handshake (link indications), and the first message of the 4-way handshake (link
success indication). These messages are not authenticated or success indication). These messages are not authenticated or
integrity protected, and although they are not forwardable, they integrity protected, and although they are not forwardable, they
are spoofable by an attacker within range. are spoofable by an attacker within range.
In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3 In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3
unicast data frames, and are therefore forwardable. This implies unicast data frames, and are therefore forwardable. This implies
that while EAPOL-Start and EAPOL-Logoff messages may be authenticated that while EAPOL-Start and EAPOL-Logoff messages may be authenticated
and integrity protected, they can be spoofed by an authenticated and integrity protected, they can be spoofed by an authenticated
skipping to change at page 54, line 33 skipping to change at page 57, line 5
subsequent data traffic. This does not present an issue on the peer, 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 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 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 EMSK exported by the EAP method, and to subsequently pass a Transient
Session Key (TSK) to the ciphersuite module. Session Key (TSK) to the ciphersuite module.
However, in the case where the authenticator and authentication However, in the case where the authenticator and authentication
server reside on different machines, there are several implications server reside on different machines, there are several implications
for security. for security.
[a] Authentication will occur between the peer and the authentication 1. Authentication will occur between the peer and the authentication
server, not between the peer and the authenticator. This means server, not between the peer and the authenticator. This means
that it is not possible for the peer to validate the identity of that it is not possible for the peer to validate the identity of
the authenticator that it is speaking to, using EAP alone. the authenticator that it is speaking to, using EAP alone.
[b] As discussed in [RFC3579], the authenticator is dependent on the 2. As discussed in [RFC3579], the authenticator is dependent on the
AAA protocol in order to know the outcome of an authentication AAA protocol in order to know the outcome of an authentication
conversation, and does not look at the encapsulated EAP packet conversation, and does not look at the encapsulated EAP packet
(if one is present) to determine the outcome. In practice, this (if one is present) to determine the outcome. In practice, this
implies that the AAA protocol spoken between the authenticator implies that the AAA protocol spoken between the authenticator
and authentication server MUST support per-packet authentication, and authentication server MUST support per-packet authentication,
integrity, and replay protection. integrity, and replay protection.
[c] After completion of the EAP conversation, where lower layer 3. After completion of the EAP conversation, where lower layer
security services such as per-packet confidentiality, security services such as per-packet confidentiality,
authentication, integrity, and replay protection will be enabled, authentication, integrity, and replay protection will be enabled,
a secure association protocol SHOULD be run between the peer and a secure association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication between authenticator in order to provide mutual authentication between
the peer and authenticator, guarantee liveness of transient the peer and authenticator, guarantee liveness of transient
session keys, provide protected ciphersuite and capabilities session keys, provide protected ciphersuite and capabilities
negotiation for subsequent data, and synchronize key usage. negotiation for subsequent data, and synchronize key usage.
[d] A AAA-Key derived from the MSK and/or EMSK negotiated between the 4. A AAA-Key derived from the MSK and/or EMSK negotiated between the
peer and authentication server MAY be transmitted to the peer and authentication server MAY be transmitted to the
authenticator. Therefore, a mechanism needs to be provided to authenticator. Therefore, a mechanism needs to be provided to
transmit the AAA-Key from the authentication server to the transmit the AAA-Key from the authentication server to the
authenticator that needs it. The specification of the AAA-key authenticator that needs it. The specification of the AAA-key
derivation, transport, and wrapping mechanisms is outside the derivation, transport, and wrapping mechanisms is outside the
scope of this document. Further details on AAA-Key Derivation scope of this document. Further details on AAA-Key Derivation
are provided within [KEYFRAME]. are provided within [RFC5247].
7.14. Cleartext Passwords 7.14. Cleartext Passwords
This specification does not define a mechanism for cleartext password This specification does not define a mechanism for cleartext password
authentication. The omission is intentional. Use of cleartext authentication. The omission is intentional. Use of cleartext
passwords would allow the password to be captured by an attacker with passwords would allow the password to be captured by an attacker with
access to a link over which EAP packets are transmitted. access to a link over which EAP packets are transmitted.
Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
provide confidentiality, EAP packets may be subsequently encapsulated provide confidentiality, EAP packets may be subsequently encapsulated
skipping to change at page 58, line 24 skipping to change at page 60, line 43
Protected result indications address some denial-of-service Protected result indications address some denial-of-service
vulnerabilities due to spoofing of Success and Failure packets, vulnerabilities due to spoofing of Success and Failure packets,
though not all. EAP methods can typically provide protected result though not all. EAP methods can typically provide protected result
indications only in some circumstances. For example, errors can indications only in some circumstances. For example, errors can
occur prior to key derivation, and so it may not be possible to occur prior to key derivation, and so it may not be possible to
protect all failure indications. It is also possible that result protect all failure indications. It is also possible that result
indications may not be supported in both directions or that indications may not be supported in both directions or that
synchronization may not be achieved in all modes of operation. synchronization may not be achieved in all modes of operation.
For example, within EAP-TLS [RFC2716], in the client authentication For example, within EAP-TLS [RFC5216][I-D.ietf-emu-eap-tls13], in the
handshake, the server authenticates the peer, but does not receive a client authentication handshake, the server authenticates the peer,
protected indication of whether the peer has authenticated it. In but does not receive a protected indication of whether the peer has
contrast, the peer authenticates the server and is aware of whether authenticated it. In contrast, the peer authenticates the server and
the server has authenticated it. In the session resumption is aware of whether the server has authenticated it. In the session
handshake, the peer authenticates the server, but does not receive a resumption handshake, the peer authenticates the server, but does not
protected indication of whether the server has authenticated it. In receive a protected indication of whether the server has
this mode, the server authenticates the peer and is aware of whether authenticated it. In this mode, the server authenticates the peer
the peer has authenticated it. and is aware of whether the peer has authenticated it.
8. Acknowledgements 8. References
This protocol derives much of its inspiration from Dave Carrel's AHA 8.1. Normative References
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 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
Section 7.2 and specified for each EAP method described in this STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
document, was inspired by Glen Zorn through [EAP-EVAL]. <https://www.rfc-editor.org/info/rfc1661>.
9. References [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, DOI 10.17487/RFC1994, August
1996, <https://www.rfc-editor.org/info/rfc1994>.
9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", [RFC2243] Metz, C., "OTP Extended Responses", RFC 2243,
STD 51, RFC 1661, July 1994. DOI 10.17487/RFC2243, November 1997, <https://www.rfc-
editor.org/info/rfc2243>.
[RFC1994] Simpson, W., "PPP Challenge Handshake [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-
Authentication Protocol (CHAP)", RFC 1994, August Time Password System", STD 61, RFC 2289,
1996. DOI 10.17487/RFC2289, February 1998, <https://www.rfc-
editor.org/info/rfc2289>.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
Indicate Requirement Levels", BCP 14, RFC 2119, 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
March 1997. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC2243] Metz, C., "OTP Extended Responses", RFC 2243, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
November 1997. "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, <https://www.rfc-
editor.org/info/rfc6298>.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
ISO 10646", RFC 2279, January 1998. Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
One-Time Password System", RFC 2289, February 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1998. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for [IEEE-802]
Writing an IANA Considerations Section in RFCs", Institute of Electrical and Electronics Engineers, "Local
BCP 26, RFC 2434, October 1998. and Metropolitan Area Networks: Overview and
Architecture", IEEE Standard 802, 1990.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's [IEEE-802.1X]
Retransmission Timer", RFC 2988, November 2000. Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X, January 2020.
[IEEE-802] Institute of Electrical and Electronics Engineers, [TS.33.501]
"Local and Metropolitan Area Networks: Overview 3GPP, "Security architecture and procedures for 5G
and Architecture", IEEE Standard 802, 1990. System", 3GPP TS 33.501 17.0.0, December 2020.
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, 8.2. Informative References
"Local and Metropolitan Area Networks: Port-Based
Network Access Control", IEEE Standard 802.1X,
September 2001.
9.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel, J., "Transmission Control Protocol", STD [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
7, RFC 793, September 1981. Authentication Service (V5)", RFC 1510,
DOI 10.17487/RFC1510, September 1993, <https://www.rfc-
editor.org/info/rfc1510>.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller,
Authentication Service (V5)", RFC 1510, September "Randomness Recommendations for Security", RFC 1750,
1993. DOI 10.17487/RFC1750, December 1994, <https://www.rfc-
editor.org/info/rfc1750>.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
"Randomness Recommendations for Security", RFC RFC 2246, DOI 10.17487/RFC2246, January 1999,
1750, December 1994. <https://www.rfc-editor.org/info/rfc2246>.
[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Freier, A. and P. Kocher, "The TLS Protocol Authentication Protocol (EAP)", RFC 2284,
Version 1.0", RFC 2246, January 1999. DOI 10.17487/RFC2284, March 1998, <https://www.rfc-
editor.org/info/rfc2284>.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
Authentication Protocol (EAP)", RFC 2284, March "Internet Security Association and Key Management Protocol
1998. (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998,
<https://www.rfc-editor.org/info/rfc2408>.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
Identifier", RFC 2486, January 1999. (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>.
[RFC2408] Maughan, D., Schneider, M. and M. Schertler, [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
"Internet Security Association and Key Management RFC 2433, DOI 10.17487/RFC2433, October 1998,
Protocol (ISAKMP)", RFC 2408, November 1998. <https://www.rfc-editor.org/info/rfc2433>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
Exchange (IKE)", RFC 2409, November 1998. RFC 2486, DOI 10.17487/RFC2486, January 1999,
<https://www.rfc-editor.org/info/rfc2486>.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Extensions", RFC 2433, October 1998. Implementation in Roaming", RFC 2607,
DOI 10.17487/RFC2607, June 1999, <https://www.rfc-
editor.org/info/rfc2607>.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
Policy Implementation in Roaming", RFC 2607, June G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
1999. RFC 2661, DOI 10.17487/RFC2661, August 1999,
<https://www.rfc-editor.org/info/rfc2661>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
Zorn, G. and B. Palter, "Layer Two Tunneling "Remote Authentication Dial In User Service (RADIUS)",
Protocol "L2TP"", RFC 2661, August 1999. RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
Authentication Protocol", RFC 2716, October 1999. RFC 3162, DOI 10.17487/RFC3162, August 2001,
<https://www.rfc-editor.org/info/rfc3162>.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Simpson, "Remote Authentication Dial In User Internationalized Strings ("stringprep")", RFC 3454,
Service (RADIUS)", RFC 2865, June 2000. DOI 10.17487/RFC3454, December 2002, <https://www.rfc-
editor.org/info/rfc3454>.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, Dial In User Service) Support For Extensible
M., Zhang, L. and V. Paxson, "Stream Control Authentication Protocol (EAP)", RFC 3579,
Transmission Protocol", RFC 2960, October 2000. DOI 10.17487/RFC3579, September 2003, <https://www.rfc-
editor.org/info/rfc3579>.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
IPv6", RFC 3162, August 2001. "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580,
DOI 10.17487/RFC3580, September 2003, <https://www.rfc-
editor.org/info/rfc3580>.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Internationalized Strings ("stringprep")", RFC Considered Useful", BCP 82, RFC 3692,
3454, December 2002. DOI 10.17487/RFC3692, January 2004, <https://www.rfc-
editor.org/info/rfc3692>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Authentication Dial In User Service) Support For Levkowetz, Ed., "Extensible Authentication Protocol
Extensible Authentication Protocol (EAP)", RFC (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
3579, September 2003. <https://www.rfc-editor.org/info/rfc3748>.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
Roese, "IEEE 802.1X Remote Authentication Dial In Extensible Authentication Protocol (EAP) Application",
User Service (RADIUS) Usage Guidelines", RFC 3580, RFC 4072, DOI 10.17487/RFC4072, August 2005,
September 2003. <https://www.rfc-editor.org/info/rfc4072>.
[RFC3692] Narten, T., "Assigning Experimental and Testing [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
Numbers Considered Useful", BCP 82, RFC 3692, "State Machines for Extensible Authentication Protocol
January 2004. (EAP) Peer and Authenticator", RFC 4137,
DOI 10.17487/RFC4137, August 2005, <https://www.rfc-
editor.org/info/rfc4137>.
[DECEPTION] Slatalla, M. and J. Quittner, "Masters of [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
Deception", Harper-Collins, New York, 1995. RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari,
Password Security", Proceedings of the 1999 ISOC "Network Discovery and Selection Problem", RFC 5113,
Network and Distributed System Security Symposium, DOI 10.17487/RFC5113, January 2008, <https://www.rfc-
http://www.isoc.org/isoc/conferences/ndss/99/ editor.org/info/rfc5113>.
proceedings/papers/wu.pdf.
[KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Kerberos authentication system", Proceedings of Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
the 1991 Winter USENIX Conference, pp. 253-267, March 2008, <https://www.rfc-editor.org/info/rfc5216>.
1991.
[KERB4WEAK] Dole, B., Lodin, S. and E. Spafford, "Misplaced [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
trust: Kerberos 4 session keys", Proceedings of Authentication Protocol (EAP) Key Management Framework",
the Internet Society Network and Distributed RFC 5247, DOI 10.17487/RFC5247, August 2008,
System Security Symposium, pp. 60-70, March 1997. <https://www.rfc-editor.org/info/rfc5247>.
[PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
Pre-IKE Credential Provisioning Protocol", Work in and Passwords", RFC 4013, DOI 10.17487/RFC4013, February
Progress, October 2002. 2005, <https://www.rfc-editor.org/info/rfc4013>.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
Protocol", Work in Progress, January 2004. for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of [RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-
Microsoft's Point-to- Point Tunneling Protocol", Binding Support for Extensible Authentication Protocol
Proceedings of the 5th ACM Conference on (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012,
Communications and Computer Security, ACM Press, <https://www.rfc-editor.org/info/rfc6677>.
November 1998.
[IEEE-802.11] Institute of Electrical and Electronics Engineers, [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed.,
"Wireless LAN Medium Access Control (MAC) and "EAP Extensions for the EAP Re-authentication Protocol
Physical Layer (PHY) Specifications", IEEE (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012,
Standard 802.11, 1999. <https://www.rfc-editor.org/info/rfc6696>.
[SILVERMAN] Silverman, Robert D., "A Cost-Based Security [RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible
Analysis of Symmetric and Asymmetric Key Lengths", Authentication Protocol (EAP) Mutual Cryptographic
RSA Laboratories Bulletin 13, April 2000 (Revised Binding", RFC 7029, DOI 10.17487/RFC7029, October 2013,
November 2001), <https://www.rfc-editor.org/info/rfc7029>.
http://www.rsasecurity.com/rsalabs/bulletins/
bulletin13.html.
[KEYFRAME] Aboba, B., "EAP Key Management Framework", Work in [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
Progress, October 2003. "Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
user names and passwords", Work in Progress, March Kivinen, "Internet Key Exchange Protocol Version 2
2004. (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
"Unapproved Draft Supplement to Standard for Enforcement, and Comparison of Internationalized Strings
Telecommunications and Information Exchange Representing Usernames and Passwords", RFC 7613,
Between Systems - LAN/MAN Specific Requirements - DOI 10.17487/RFC7613, August 2015, <https://www.rfc-
Part 11: Wireless LAN Medium Access Control (MAC) editor.org/info/rfc7613>.
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 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
Extensible Authentication Protocol (EAP) Enforcement, and Comparison of Internationalized Strings
Application", Work in Progress, February 2004. Representing Usernames and Passwords", RFC 8265,
DOI 10.17487/RFC8265, October 2017, <https://www.rfc-
editor.org/info/rfc8265>.
[EAP-EVAL] Zorn, G., "Specifying Security Claims for EAP [DECEPTION]
Authentication Types", Work in Progress, October Slatalla, M. and J. Quittner, "Masters of Deception",
2002. Harper-Collins New York, 1995.
[BINDING] Puthenkulam, J., "The Compound Authentication [KRBATTACK]
Binding Problem", Work in Progress, October 2003. 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.
[MITM] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the- [KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos
Middle in Tunneled Authentication Protocols", IACR authentication system", Proceedings of the 1991 Winter
ePrint Archive Report 2002/163, October 2002, USENIX Conference pp. 253-267, 1991.
<http://eprint.iacr.org/2002/163>.
[IEEE-802.11i-req] Stanley, D., "EAP Method Requirements for Wireless [KERB4WEAK]
LANs", Work in Progress, February 2004. 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.
[PPTPv2] Schneier, B. and Mudge, "Cryptanalysis of [I-D.ietf-ipsra-pic]
Microsoft's PPTP Authentication Extensions (MS- Sheffer, Y., Krawczyk, H., and B. Aboba, "PIC, A Pre-IKE
CHAPv2)", CQRE 99, Springer-Verlag, 1999, pp. Credential Provisioning Protocol", draft-ietf-ipsra-pic-05
192-203. (work in progress), February 2002.
Appendix A. Changes from RFC 2284 [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.
This section lists the major changes between [RFC2284] and this [IEEE-802.11]
document. Minor changes, including style, grammar, spelling, and Institute of Electrical and Electronics Engineers,
editorial changes are not mentioned here. "Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
o The Terminology section (Section 1.2) has been expanded, defining [SILVERMAN]
more concepts and giving more exact definitions. Silverman, R., "A Cost-Based Security Analysis of
Symmetric and Asymmetric Key Lengths", RSA Laboratories
Bulletin 13 (Revised November 2001)
http://www.rsasecurity.com/rsalabs/bulletins/
bulletin13.html, April 2000.
o The concepts of Mutual Authentication, Key Derivation, and Result [IEEE-802.11i]
Indications are introduced and discussed throughout the document Institute of Electrical and Electronics Engineers,
where appropriate. "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.
o In Section 2, it is explicitly specified that more than one [I-D.zorn-eap-eval]
exchange of Request and Response packets may occur as part of the Zorn, G., "Specifying Security Claims for EAP
EAP authentication exchange. How this may be used and how it may Authentication Types", draft-zorn-eap-eval-00 (work in
not be used is specified in detail in Section 2.1. progress), October 2002.
o Also in Section 2, some requirements have been made explicit for [I-D.puthenkulam-eap-binding]
the authenticator when acting in pass-through mode. Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in
progress), October 2003.
o An EAP multiplexing model (Section 2.2) has been added to [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
illustrate a typical implementation of EAP. There is no in Tunneled Authentication Protocols", IACR ePrint Archive
requirement that an implementation conform to this model, as long Report 2002/163 http://eprint.iacr.org/2002/163, October
as the on-the-wire behavior is consistent with it. 2002.
o As EAP is now in use with a variety of lower layers, not just PPP [IEEE-802.11i-req]
for which it was first designed, Section 3 on lower layer behavior Stanley, D., "EAP Method Requirements for Wireless LANs",
has been added. February 2004.
o In the description of the EAP Request and Response interaction [PPTPv2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP
(Section 4.1), both the behavior on receiving duplicate requests, Authentication Extensions (MS-CHAPv2)", CQRE 99, Springer-
and when packets should be silently discarded has been more Verlag pp. 192-203, 1999.
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 [Terminology]
packets must not contain additional data, and the implementation Alissa Cooper et al., , "Inclusive terminology in IETF
note has been expanded. A subsection giving requirements on Documents", Contribution under the IETF
processing of success and failure packets has been added. GitHub https://github.com/ietf/terminology, October 2020.
o Section 5 on EAP Request/Response Types lists two new Type values: [W3C] Le Hegaret, P. and C. Mercier, "W3C Manual of Style", W3C
the Expanded Type (Section 5.7), which is used to expand the Type Document https://w3c.github.io/manual-of-style/, January
value number space, and the Experimental Type. In the Expanded 2021.
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.
o In Sections 5, 5.1, and 5.2, a requirement has been added such [RedHat] Wright, C., "Making open source more inclusive by
that fields with displayable messages should contain UTF-8 encoded eradicating problematic language", RedHat Blog
ISO 10646 characters. https://www.redhat.com/en/blog/making-open-source-more-
inclusive-eradicating-problematic-language, January 2021.
o It is now required in Section 5.1 that if the Type-Data field of [GitLab] Ramsay, J., "Change the default initial branch name for
an Identity Request contains a NUL-character, only the part before new projects on GitLab", GitLab issue 221164
the null is displayed. RFC 2284 prohibits the null termination of https://gitlab.com/gitlab-org/gitlab/-/issues/221164, June
the Type-Data field of Identity messages. This rule has been 2020.
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 [Mozilla] Davidson, J., "Replace all user-facing instances that
been added to EAP OTP. refer to "master" password", Mozilla Bug 1644807
https://bugzilla.mozilla.org/show_bug.cgi?id=1644807,
November 2016.
o An IANA Considerations section (Section 6) has been added, giving [IESG] IESG, , "IESG Statement On Oppressive or Exclusionary
registration policies for the numbering spaces defined for EAP. Language", IESG Statement
https://www.ietf.org/about/groups/iesg/statements/
statement-on-oppressive-exclusionary-language/, July 2020.
o The Security Considerations (Section 7) have been greatly [I-D.ietf-emu-eap-tls13]
expanded, giving a much more comprehensive coverage of possible Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
threats and other security considerations. draft-ietf-emu-eap-tls13-13 (work in progress), November
2020.
o In Section 7.5, text has been added on method-specific behavior, [I-D.ietf-emu-rfc5448bis]
providing guidance on how EAP method-specific integrity checks Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
should be processed. Where possible, it is desirable for a "Improved Extensible Authentication Protocol Method for
method-specific MIC to be computed over the entire EAP packet, 3GPP Mobile Network Authentication and Key Agreement (EAP-
including the EAP layer header (Code, Identifier, Length) and EAP AKA')", draft-ietf-emu-rfc5448bis-09 (work in progress),
method layer header (Type, Type-Data). January 2021.
o In Section 7.14 the security risks involved in use of cleartext Appendix A. Changes from RFC 3748
passwords with EAP are described.
o In Section 7.15 text has been added relating to detection of rogue There are no changes with related to interoperability. Minor
NAS behavior. changes, including style, grammar, spelling, and editorial changes
are not mentioned here. The only changes are the following:
o The names of the MSK and EMSK terms used to discuss and specify
the protocol have been changed.
o The security considerations note the deficiencies in legacy EAP
methods such as MD5-Challenge in Section 7.11.1, and recommend the
use of more modern authentication methods.
o Ivo Sedlacek's errata on a reference to Section 7.12 rather than
Section 7.2 from Section 3.4 has been adopted.
o IANA rules have been updated to comply with RFC 8126 and current
allocations.
o References have been updated to their most recent versions.
o The security claim perfect forward secrecy has been added.
o References to 3GPP 5G has been added.
o The peer-name portion of the NAI SHOULD be omitted in the EAP-
Response/Identity.
o Since the publication of RFC3748, several documents related to the
core EAP document have been published: [RFC4137] offers a proposed
state machine [RFC5113] defines the network discovery and
selection problem, [RFC5247] specifies the EAP key hierarchy,
[RFC6677] [RFC7029] explores man-in-the-middle attacks and defines
how to implement channel bindings. References to RFC 4137, RFC
5113, RFC 5247, RFC 6677, and RFC 7029 3GPP have been added.
There are still some open questions, however:
o RFC 3748 referred to an early version of the SASLPREP document,
which turned into [RFC4013], then [RFC7613], and is currently
[RFC8265]. Does this still apply? Has something been learned in
the meanwhile about internationalization and passwords?
o Is there a need to update security considerations beyond what was
done already? The is likly more to say about privacy, identity
protection, pervasive monitoring and perfect forward secrecy.
o IEEE references need to be updated to newer ones. Some aspects of
IEEE have changed since 2004
o IEEE links are discussed a lot in the document, and some of 3GPP
link technologies and related EAP methods. Should the document
say something more about 3GPP and 5G?
o Could some sections be replaced by links to RFC 4137, RFC 5113,
RFC 5247, RFC 6677, and RFC 7029? Should the document say more
about RFC 4137, RFC 5113, RFC 5247, RFC 6677, and RFC 7029?
o What other issues have been discussed since since 2004, but not
recorded in errata?
A summary of the changes between RFC 3748 and RFC 2284 were listed in
Appendix A of RFC 3748 [RFC3748] [RFC2284].
Appendix B. Rationale
In 2020, the Internet Engineering Steering Group (IESG) noted that
terminology used in IETF documents is important [IESG]. When the
objective of an organization is to be inclusive and respectful,
terminology can also have an effect. There are obvious challenges
for creating good terminology for the parts of Internet technology
currently under development, both in a technical sense and in our
ability to agree what terms are inclusive. There are also difficult
tradeoffs related to changing terminology for existing technology, or
for spending valuable effort on terminology vs. other things.
This update is both a refresh of the RFC in general, bringing in the
noted errata, updates to referred documents, but also an update of
the terminology.
With regards to terminology, the authors have worked for a long time
with EAP technology, and continue to make contributions in this
space. In the authors' view, while there is no need for a change,
some of the terms that are used when referring to various parts of
the overall EAP technology could be improved. As a result, the
authors wanted to make a modest proposal for a change that would
improve the terms without changing the associated acronyms, and
enable better use of the terms in future documents.
It should be noted that the issues with EAP terms are minor, compared
many other terminology or other problems with Internet technology.
The authors do not wish to start a big debate; if the WG finds this
useful, we can perhaps make an update and move on. If not, we can
simply move on without making a change.
The specific change that is suggested in this document relates to the
use of the word "master" in various EAP terms. This word is rather
benign when compared to the use of master/slave or black/whitelists,
and other similar terms. Indeed, "master" is commonly used in a
large number of everyday terms. Given this, some authors and
organizations have chosen to make updates only with the most
egregious terms, such as master/slave.
Nevertheless, at least the authors of this document feel that he
would use another word if a different word or term was available. It
should be noted that:
o The slavery-related meaning comes up in any dictionary search for
the word "master".
o The word "master" and some suggested alternatives (such as "main")
are listed in [Terminology].
o Several organisations have recommended changing the word "master"
in various aspects of their documentation or software. Others are
considering changes. See, for instance, [W3C] [RedHat] [GitLab]
[Mozilla].
In any case, as noted, this proposal is for the working group to
discuss. Discussion may find that the proposal is considered useful,
unnecessary, or flawed in some fashion.
Appendix C. Acknowledgements
This version of the document is a minor update with respect to RFC
3748. The acknowledgements from RFC 3748 apply:
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 [I-D.zorn-eap-eval].
The authors of the most recent version of this document would like to
thank Stephen Hayes, Lars Eggert, Mohit Sethi, Alissa Cooper, and Ivo
Sedlacek for englightening discussions and general contributions in
this area.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA USA
Phone: +1 425 706 6605 Email: bernarda@microsoft.com
Fax: +1 425 936 6605
EMail: bernarda@microsoft.com
Larry J. Blunk Larry J. Blunk
Merit Network, Inc Merit Network, Inc
4251 Plymouth Rd., Suite 2000
Ann Arbor, MI 48105-2785
USA USA
Phone: +1 734-647-9563 Email: ljb@merit.edu
Fax: +1 734-647-3185
EMail: ljb@merit.edu
John R. Vollbrecht John R. Vollbrecht
Vollbrecht Consulting LLC Vollbrecht Consulting LLC
9682 Alice Hill Drive
Dexter, MI 48130
USA USA
EMail: jrv@umich.edu Email: jrv@umich.edu
James Carlson James Carlson
Sun Microsystems, Inc Sun Microsystems, Inc
1 Network Drive
Burlington, MA 01803-2757
USA USA
Phone: +1 781 442 2084 Email: james.d.carlson@sun.com
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Henrik Levkowetz Henrik Levkowetz
ipUnplugged AB ipUnplugged AB
Arenavagen 33 Sweden
Stockholm S-121 28
SWEDEN
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
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 Email: henrik@levkowetz.com
assurances of licenses to be made available, or the result of an Jari Arkko (Editor)
attempt made to obtain a general license or permission for the use of Ericsson
such proprietary rights by implementers or users of this Jorvas 02420
specification can be obtained from the IETF on-line IPR repository at Finland
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Email: jari.arkko@piuha.net
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 John Mattsson (Editor)
Ericsson
Stockholm
Sweden
Funding for the RFC Editor function is currently provided by the Email: john.mattsson@ericsson.com
Internet Society.
 End of changes. 230 change blocks. 
627 lines changed or deleted 893 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/