< draft-ietf-eap-rfc2284bis-06.txt   draft-ietf-eap-rfc2284bis-07.txt >
EAP Working Group L. Blunk EAP Working Group L. Blunk
Internet-Draft Merit Network, Inc Internet-Draft Merit Network, Inc
Obsoletes: 2284 (if approved) J. Vollbrecht Obsoletes: 2284 (if approved) J. Vollbrecht
Expires: March 29, 2004 Vollbrecht Consulting LLC Expires: May 27, 2004 Vollbrecht Consulting LLC
B. Aboba B. Aboba
Microsoft Microsoft
J. Carlson J. Carlson
Sun Sun
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
September 29, 2003 November 27, 2003
Extensible Authentication Protocol (EAP) Extensible Authentication Protocol (EAP)
<draft-ietf-eap-rfc2284bis-06.txt> <draft-ietf-eap-rfc2284bis-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 29, 2004. This Internet-Draft will expire on May 27, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification of Requirements . . . . . . . . . . . . 4 1.1 Specification of Requirements . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . 4
1.3 Applicability . . . . . . . . . . . . . . . . . . . . 6 1.3 Applicability . . . . . . . . . . . . . . . . . . . . 6
2. Extensible Authentication Protocol (EAP) . . . . . . . . . . 7 2. Extensible Authentication Protocol (EAP) . . . . . . . . . . 7
2.1 Support for sequences . . . . . . . . . . . . . . . . 9 2.1 Support for sequences . . . . . . . . . . . . . . . . 9
2.2 EAP multiplexing model . . . . . . . . . . . . . . . . 10 2.2 EAP multiplexing model . . . . . . . . . . . . . . . . 10
2.3 Pass-through behavior . . . . . . . . . . . . . . . . 12 2.3 Pass-through behavior . . . . . . . . . . . . . . . . 12
2.4 Peer-to-Peer Operation . . . . . . . . . . . . . . . . 13 2.4 Peer-to-Peer Operation . . . . . . . . . . . . . . . . 14
3. Lower layer behavior . . . . . . . . . . . . . . . . . . . . 14 3. Lower layer behavior . . . . . . . . . . . . . . . . . . . . 15
3.1 Lower layer requirements . . . . . . . . . . . . . . . 14 3.1 Lower layer requirements . . . . . . . . . . . . . . . 15
3.2 EAP usage within PPP . . . . . . . . . . . . . . . . . 16 3.2 EAP usage within PPP . . . . . . . . . . . . . . . . . 17
3.2.1 PPP Configuration Option Format . . . . . . . . 17 3.2.1 PPP Configuration Option Format . . . . . . . . 18
3.3 EAP usage within IEEE 802 . . . . . . . . . . . . . . 17 3.3 EAP usage within IEEE 802 . . . . . . . . . . . . . . 19
3.4 Lower layer indications . . . . . . . . . . . . . . . 17 3.4 Lower layer indications . . . . . . . . . . . . . . . 19
4. EAP Packet format . . . . . . . . . . . . . . . . . . . . . 18 4. EAP Packet format . . . . . . . . . . . . . . . . . . . . . 20
4.1 Request and Response . . . . . . . . . . . . . . . . . 19 4.1 Request and Response . . . . . . . . . . . . . . . . . 21
4.2 Success and Failure . . . . . . . . . . . . . . . . . 22 4.2 Success and Failure . . . . . . . . . . . . . . . . . 23
4.3 Retransmission Behavior . . . . . . . . . . . . . . . 24 4.3 Retransmission Behavior . . . . . . . . . . . . . . . 26
5. Initial EAP Request/Response Types . . . . . . . . . . . . . 25 5. Initial EAP Request/Response Types . . . . . . . . . . . . . 27
5.1 Identity . . . . . . . . . . . . . . . . . . . . . . . 26 5.1 Identity . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Notification . . . . . . . . . . . . . . . . . . . . . 28 5.2 Notification . . . . . . . . . . . . . . . . . . . . . 29
5.3 Nak . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3 Nak . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1 Legacy Nak . . . . . . . . . . . . . . . . . . . 29 5.3.1 Legacy Nak . . . . . . . . . . . . . . . . . . . 31
5.3.2 Expanded Nak . . . . . . . . . . . . . . . . . . 31 5.3.2 Expanded Nak . . . . . . . . . . . . . . . . . . 32
5.4 MD5-Challenge . . . . . . . . . . . . . . . . . . . . 33 5.4 MD5-Challenge . . . . . . . . . . . . . . . . . . . . 35
5.5 One-Time Password (OTP) . . . . . . . . . . . . . . . 35 5.5 One-Time Password (OTP) . . . . . . . . . . . . . . . 37
5.6 Generic Token Card (GTC) . . . . . . . . . . . . . . . 36 5.6 Generic Token Card (GTC) . . . . . . . . . . . . . . . 38
5.7 Expanded Types . . . . . . . . . . . . . . . . . . . . 37 5.7 Expanded Types . . . . . . . . . . . . . . . . . . . . 39
5.8 Experimental . . . . . . . . . . . . . . . . . . . . . 39 5.8 Experimental . . . . . . . . . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
6.1 Packet Codes . . . . . . . . . . . . . . . . . . . . . 40 6.1 Packet Codes . . . . . . . . . . . . . . . . . . . . . 42
6.2 Method Types . . . . . . . . . . . . . . . . . . . . . 40 6.2 Method Types . . . . . . . . . . . . . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . 42
7.1 Threat model . . . . . . . . . . . . . . . . . . . . . 41 7.1 Threat model . . . . . . . . . . . . . . . . . . . . . 43
7.2 Security claims . . . . . . . . . . . . . . . . . . . 42 7.2 Security claims . . . . . . . . . . . . . . . . . . . 44
7.2.1 Security claims terminology for EAP methods . . 43 7.2.1 Security claims terminology for EAP methods . . 45
7.3 Identity protection . . . . . . . . . . . . . . . . . 45 7.3 Identity protection . . . . . . . . . . . . . . . . . 47
7.4 Man-in-the-middle attacks . . . . . . . . . . . . . . 46 7.4 Man-in-the-middle attacks . . . . . . . . . . . . . . 48
7.5 Packet modification attacks . . . . . . . . . . . . . 47 7.5 Packet modification attacks . . . . . . . . . . . . . 49
7.6 Dictionary attacks . . . . . . . . . . . . . . . . . . 48 7.6 Dictionary attacks . . . . . . . . . . . . . . . . . . 50
7.7 Connection to an untrusted network . . . . . . . . . . 48 7.7 Connection to an untrusted network . . . . . . . . . . 50
7.8 Negotiation attacks . . . . . . . . . . . . . . . . . 49 7.8 Negotiation attacks . . . . . . . . . . . . . . . . . 51
7.9 Implementation idiosyncrasies . . . . . . . . . . . . 49 7.9 Implementation idiosyncrasies . . . . . . . . . . . . 51
7.10 Key derivation . . . . . . . . . . . . . . . . . . . . 50 7.10 Key derivation . . . . . . . . . . . . . . . . . . . . 51
7.11 Weak ciphersuites . . . . . . . . . . . . . . . . . . 52 7.11 Weak ciphersuites . . . . . . . . . . . . . . . . . . 53
7.12 Link layer . . . . . . . . . . . . . . . . . . . . . . 52 7.12 Link layer . . . . . . . . . . . . . . . . . . . . . . 54
7.13 Separation of authenticator and backend authentication 7.13 Separation of authenticator and backend authentication
server . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 server . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.14 Cleartext Passwords . . . . . . . . . . . . . . . . . 54 7.14 Cleartext Passwords . . . . . . . . . . . . . . . . . 56
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54 7.15 Channel binding . . . . . . . . . . . . . . . . . . . 56
Normative References . . . . . . . . . . . . . . . . . . . . 55 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 57
Informative References . . . . . . . . . . . . . . . . . . . 55 Normative References . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 58 Informative References . . . . . . . . . . . . . . . . . . . 58
A. Changes from RFC 2284 . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 62
B. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 61 A. Changes from RFC 2284 . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . 62 B. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 64
Intellectual Property and Copyright Statements . . . . . . . 66
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
PPP or IEEE 802, without requiring IP. EAP provides its own support PPP or IEEE 802, without requiring IP. EAP provides its own support
for duplicate elimination and retransmission, but is reliant on lower for duplicate elimination and retransmission, but is reliant on lower
layer ordering guarantees. Fragmentation is not supported within EAP layer ordering guarantees. Fragmentation is not supported within EAP
itself; however, individual EAP methods may support this. itself; however, individual 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 switches lines using PPP [RFC1661]. It has also been implemented with
and access points using IEEE 802 [IEEE-802]. EAP encapsulation on switches and access points using IEEE 802 [IEEE-802]. EAP
IEEE 802 wired media is described in [IEEE-802.1X], and encapsulation encapsulation on IEEE 802 wired media is described in [IEEE-802.1X],
on IEEE wireless LANs in [IEEE-802.11i]. and encapsulation on IEEE wireless LANs in [IEEE-802.11i].
One of the advantages of the EAP architecture is its flexibility. EAP One of the advantages of the EAP architecture is its flexibility. EAP
is used to select a specific authentication mechanism, typically 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.
skipping to change at page 5, line 22 skipping to change at page 5, line 22
[IEEE-802.1X], this end is known as the Supplicant. [IEEE-802.1X], this end is known as the Supplicant.
backend authentication server backend authentication server
A backend authentication server is an entity that provides A backend authentication server is an entity that provides
an authentication service to an authenticator. When used, an authentication service to an authenticator. When used,
this server typically executes EAP methods for the this server typically executes EAP methods for the
authenticator. This terminology is also used in authenticator. This terminology is also used in
[IEEE-802.1X]. [IEEE-802.1X].
AAA AAA
Authentication, Authorization and Accounting. AAA protocols Authentication, Authorization and Accounting. AAA
with EAP support include RADIUS [RFC3579] and Diameter protocols with EAP support include RADIUS [RFC3579] and
[DIAM-EAP]. In this document, the terms "AAA server" and Diameter [DIAM-EAP]. In this document, the terms "AAA
"backend authentication server" are used interchangeably. server" and "backend authentication server" are used
interchangeably.
Displayable Message Displayable Message
This is interpreted to be a human readable string of This is interpreted to be a human readable string of
characters. The message encoding MUST follow the UTF-8 characters. The message encoding MUST follow the UTF-8
transformation format [RFC2279]. transformation format [RFC2279].
EAP server EAP server
The entity that terminates the EAP authentication method The entity that terminates the EAP authentication method
with the peer. In the case where no backend authentication with the peer. In the case where no backend authentication
server is used, the EAP server is part of the server is used, the EAP server is part of the
skipping to change at page 5, line 51 skipping to change at page 5, line 52
This means the implementation discards the packet without This means the implementation discards the packet without
further processing. The implementation SHOULD provide the further processing. The implementation SHOULD provide the
capability of logging the event, including the contents of capability of logging the event, including the contents of
the silently discarded packet, and SHOULD record the event the silently discarded packet, and SHOULD record the event
in a statistics counter. in a statistics counter.
Successful authentication Successful authentication
In the context of this document, "successful In the context of this document, "successful
authentication" is an exchange of EAP messages, as a result authentication" is an exchange of EAP messages, as a result
of which the authenticator decides to allow access by the of which the authenticator decides to allow access by the
peer, and the peer decides to use this access. The peer, and the peer decides to use this access. The
authenticator's decision typically involves both 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 successfully authenticate to the authenticator but access
may be denied by the authenticator due to policy reasons. may be 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 Authentication Code (MAC), but IEEE 802 specifications (and
this document) use the acronym MIC to avoid confusion with this document) use the acronym MIC to avoid confusion with
skipping to change at page 10, line 19 skipping to change at page 10, line 23
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 [a] 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 [IKEv2]); and TCP [PIC]. Lower
layer behavior is discussed in Section 3. layer behavior is discussed in Section 3.
[b] EAP layer. The EAP layer receives and transmits EAP packets via [b] 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 EAP methods. from the EAP peer and authenticator layers.
[c] EAP method. EAP methods implement the authentication algorithms [c] EAP peer and authenticator layers. Based on the Code field, the
and receive and transmit EAP messages via the EAP layer. Since EAP layer demultiplexes incoming EAP packets to the EAP peer and
fragmentation support is not provided by EAP itself, this is the authenticator layers. Typically an EAP implementation on a given
responsibility of EAP methods, which are discussed in Section 5. host will support either peer or authenticator functionality, but
it is possible for a host to act as both an EAP peer and
authenticator. In such an implementation both EAP peer and
authenticator layers will be present.
[d] EAP method layers. EAP methods implement the authentication
algorithms and receive and transmit EAP messages via the EAP peer
and authenticator layers. Since fragmentation support is not
provided by EAP itself, this is the responsibility of EAP
methods, which are discussed in Section 5.
The EAP multiplexing model is illustrated in Figure 1 below. Note 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.
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | |
| EAP method| EAP method| | EAP method| EAP method| | EAP method| EAP method| | EAP method| EAP method|
| Type = X | Type = Y | | Type = X | Type = Y | | Type = X | Type = Y | | Type = X | Type = Y |
| V | | | ^ | | | V | | | ^ | |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! | | ! | | ! |
| EAP ! Peer layer | | EAP ! Auth. layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! layer | | EAP ! layer | | EAP ! layer | | EAP ! layer |
| ! | | ! | | ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! | | ! | | ! |
| 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
IP. It is assumed that the EAP layer demultiplexes incoming EAP
packets according to the Code field. Received EAP packets with
Code=1 (Request), 3 (Success) and 4 (Failure) are delivered by the
EAP layer to the EAP peer layer, if implemented. EAP packets with
Code=2 (Response) are delivered to the EAP authenticator layer, if
implemented.
Within EAP, the Type field functions much like a port number in UDP Within EAP, the Type field functions much like a port number in UDP
or TCP. It is assumed that the EAP layer multiplexes incoming EAP or TCP. It is assumed that the EAP peer and authenticator layers
packets according to their Type, and delivers them only to the EAP demultiplex incoming EAP packets according to their Type, and deliver
method corresponding to that Type code. them only to the EAP method corresponding to that Type. An EAP
method implementation on a host may register to receive packets from
the peer or authenticator layers, or both, depending on which role(s)
it supports.
Since EAP authentication methods may wish to access the Identity, Since EAP authentication methods may wish to access the Identity,
implementations SHOULD make the Identity Request and Response implementations SHOULD make the Identity Request and Response
accessible to authentication methods (Types 4 or greater) in addition accessible to authentication methods (Types 4 or greater) in addition
to the Identity method. The Identity Type is discussed in Section to the Identity method. The Identity Type is discussed in Section
5.1. 5.1.
A Notification Response is only used as confirmation that the peer A Notification Response is only used as confirmation that the peer
received the Notification Request, not that it has processed it, or received the Notification Request, not that it has processed it, or
displayed the message to the user. It cannot be assumed that the displayed the message to the user. It cannot be assumed that the
contents of the Notification Request or Response is available to contents of the Notification Request or Response is available to
another method. The Notification Type is discussed in Section 5.2. another method. The Notification Type is discussed in Section 5.2.
Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes
of method negotiation. Peers respond to an initial EAP Request for of method negotiation. Peers respond to an initial EAP Request for
an unacceptable Type with a Nak Response (Type 3) or Expanded Nak an unacceptable Type with a Nak Response (Type 3) or Expanded Nak
Response (Type 254). It cannot be assumed that the contents of the Response (Type 254). It cannot be assumed that the contents of the
Nak Response(s) are available to another method. The Nak Type(s) are Nak Response(s) are available to another method. The Nak Type(s) are
discussed in Section 5.3. discussed in Section 5.3.
EAP packets with codes of Success or Failure do not include a Type, EAP packets with Codes of Success or Failure do not include a Type
and are not delivered to an EAP method. Success and Failure are field, and are not delivered to an EAP method. Success and Failure
discussed in Section 4.2. are discussed in Section 4.2.
Given these considerations, the Success, Failure, Nak Response(s) and Given these considerations, the Success, Failure, Nak Response(s) and
Notification Request/Response messages MUST NOT be used to carry data Notification Request/Response messages MUST NOT be used to carry data
destined for delivery to other EAP methods. destined for delivery to other EAP methods.
2.3 Pass-through behavior 2.3 Pass-through behavior
Where an authenticator operates as a pass-through, it forwards When operating as a "pass-through authenticator", an authenticator
packets back and forth between the peer and a backend authentication performs checks on the Code, Identifier and Length fields as
server, based on the EAP layer header fields (Code, Identifier, described in Section 4.1. It forwards EAP packets received from the
Length). This includes performing validity checks on the Code, peer and destined to its authenticator layer to the backend
Identifier and Length fields, as described in Section 4.1. authentication server; packets received from the backend
authentication server destined to the peer are forwarded to it.
Since pass-through authenticators rely on a backend authenticator A host receiving an EAP packet may only do one of three things with
server to implement methods, the EAP method layer header fields it: act on it, drop it, or forward it. The forwarding decision is
(Type, Type-Data) are not examined as part of the forwarding typically based only on examination of the Code, Identifier and
decision. The forwarding model is illustrated in Figure 2. Compliant Length fields. A pass-through authenticator implementation MUST be
pass-through authenticator implementations MUST by default be capable capable of forwarding to the backend authentication server EAP
of forwarding packets from any EAP method. The use of the RADIUS packets received from the peer with Code=2 (Response). It also MUST
protocol for encapsulation of EAP in pass-through operation is be capable of receiving EAP packets from the backend authentication
described in [RFC3579]. server and forwarding EAP packets of Code=1 (Request), Code=3
(Success), and Code=4 (Failure) to the peer.
Peer Pass-through Authenticator Authentication Unless the authenticator implements one or more authentication
Server methods locally which support the authenticator role, the EAP method
layer header fields (Type, Type-Data) are not examined as part of the
forwarding decision. Where the authenticator supports local
authentication methods, it MAY examine the Type field to determine
whether to act on the packet itself or forward it. Compliant
pass-through authenticator implementations MUST by default forward
EAP packets of any Type.
+-+-+-+-+-+-+ +-+-+-+-+-+-+ EAP packets received with Code=1 (Request), Code=3 (Success), and
| | | | Code=4 (Failure) are demultiplexed by the EAP layer and delivered to
|EAP method | |EAP method | the peer layer. Therefore unless a host implements an EAP peer layer,
| V | | ^ | these packets will be silently discarded. Similarly, EAP packets
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ received with Code=2 (Response) are demultiplexed by the EAP layer
| ! | | | | | ! | and delivered to the authenticator layer. Therefore unless a host
|EAP !layer| | EAP layer | EAP layer | |EAP !layer| implements an EAP authenticator layer, these packets will be silently
| ! | | +-----+-----+ | | ! | discarded. The behavior of a "pass-through peer" is undefined within
| ! | | ! | ! | | ! | this specification, and is unsupported by AAA protocols such as
+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ RADIUS [RFC3579] and Diameter [DIAM-EAP].
| ! | | ! | ! | | ! |
|Lower!layer| |Lower!layer| AAA ! /IP | | AAA ! /IP | The forwarding model is illustrated in Figure 2.
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ Peer Pass-through Authenticator Authentication
! ! ! ! Server
! ! ! !
+-------->-----+ +------->------+ +-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | ^ |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP |
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! ! ! !
! ! ! !
+-------->--------+ +--------->-------+
Figure 2: Pass-through Authenticator Figure 2: Pass-through Authenticator
For sessions in which the authenticator acts as a pass-through, it For sessions in which the authenticator acts as a pass-through, it
MUST determine the outcome of the authentication solely based on the MUST determine the outcome of the authentication solely based on the
Accept/Reject indication sent by the backend authentication server; Accept/Reject indication sent by the backend authentication server;
the outcome MUST NOT be determined by the contents of an EAP packet the outcome MUST NOT be determined by the contents of an EAP packet
sent along with the Accept/Reject indication, or the absence of such sent along with the Accept/Reject indication, or the absence of such
an encapsulated EAP packet. an encapsulated EAP packet.
2.4 Peer-to-Peer Operation 2.4 Peer-to-Peer Operation
Since EAP is a peer-to-peer protocol, an independent and simultaneous Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction (depending on authentication may take place in the reverse direction (depending on
the capabilities of the lower layer). Both peers may act as the capabilities of the lower layer). Both peers may act as
authenticators and authenticatees at the same time. authenticators and authenticatees at the same time, in which case it
is necessary for both peers to implement EAP authenticator and peer
layers. In addition, the EAP method implementations on both peers
must support both authenticator and peer functionality.
Although EAP supports peer-to-peer operation, selected EAP methods, Although EAP supports peer-to-peer operation, some EAP
AAA protocols and link layers may not support this. For example, implementations, methods, AAA protocols and link layers may not
EAP-TLS [RFC2716] is a client-server protocol requiring a different support this. Some EAP methods may support asymmetric
certificate profile for the client and server. This implies that a authentication, with one type of credential being required for the
host supporting both the EAP-TLS peer and authenticator roles would peer and another type for the authenticator. Hosts supporting
need to be provisioned with two distinct certificates, one peer-to-peer operation with such a method would need to be
appropriate for each role. provisioned with both types of credentials.
Some EAP methods may support asymmetric authentication, with one type For example, EAP-TLS [RFC2716] is a client-server protocol with a
of credential being required for the peer and another type for the different certificate profile for the client and server. This
authenticator. Hosts supporting peer-to-peer operation with such a implies that a host supporting peer-to-peer authentication with
method would need to be provisioned with both types of credentials. EAP-TLS would need to implement both the EAP peer and authenticator
layers; support both peer and authenticator roles in the EAP-TLS
implementation; and provision two distinct certificates, one
appropriate for each role.
AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP
[DIAM-EAP] only support "passthrough" operation on behalf of an [DIAM-EAP] only support "passthrough authenticator" operation. As
authenticator, not a peer. For example, as noted in [RFC3579] Section noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an
2.6.2, a RADIUS server responds to an Access-Request encapsulating an Access-Request encapsulating an EAP-Request, Success or Failure
EAP-Request with an Access-Reject. packet with an Access-Reject. There is therefore no support for
"passthrough peer" operation.
Link layers such as IEEE 802.11 may only support uni-directional Even where a method is used which supports mutual authentication and
derivation and transport of transient session keys. For example, the protected result indications, several considerations may dictate that
group-key handshake defined in [IEEE-802.11i] is uni-directional, two EAP authentications, (one in each direction) are required. These
since in IEEE 802.11 only the Access Point (AP) sends multicast include:
traffic. This means that in ad-hoc operation where either peer may
send multicast traffic, two uni-directional group-key exchanges are
required. Due to constraints imposed by the 4-way unicast key
handshake state machine, this also implies two 4-way handshake and
EAP method exchanges.
Link layers such as IEEE 802.11 adhoc also do not support "tie [1] Support for bi-directional session key derivation in the lower
breaking" wherein two hosts initiating authentication with each other layer. Lower layers such as IEEE 802.11 may only support
will only go forward with a single authentication. This implies that uni-directional derivation and transport of transient session
even if 802.11 were to support a bi-directional group-key handshake, keys. For example, the group-key handshake defined in
then two authentications, one in each direction, might still occur. [IEEE-802.11i] is uni-directional, since in IEEE 802.11
infrastructure mode only the Access Point (AP) sends multicast/
broadcast traffic. In IEEE 802.11 ad-hoc mode where either peer
may send multicast/broadcast traffic, two uni-directional
group-key exchanges are required. Due to limitations of the
design, this also implies the need for unicast key derivations
and EAP method exchanges to occur in each direction.
[2] Support for tie-breaking in the lower layer. Lower layers such
as IEEE 802.11 adhoc do not support "tie breaking" wherein two
hosts initiating authentication with each other will only go
forward with a single authentication. This implies that even if
802.11 were to support a bi-directional group-key handshake, then
two authentications, one in each direction, might still occur.
[3] Peer policy satisfaction. EAP methods may support protected
result indications, enabling the peer to indicate to the EAP
server that it successfully authenticated the EAP server.
However, a pass-through authenticator will not be aware that the
peer has accepted the credentials offered by the EAP server,
unless this information is provided to the authenticator via the
AAA protocol. As a result, two authentications, one in each
direction, may still be needed.
It is also possible that the EAP peer's access policy was not
satisfied during the EAP method exchange. For example, the
authenticator may not have successfully authenticated to the
peer, or may not have demonstrated authorization to act in both
peer and server roles. For example, in EAP-TLS [RFC2716], the
authenticator may have authenticated using a valid TLS server
certificate, but not using a valid TLS client certificate. As a
result, the peer may require an additional authentication in the
reverse direction, even if the peer provided a protected result
indication to the EAP server indicating that the 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
skipping to change at page 14, line 49 skipping to change at page 16, line 8
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 a non-negligible error rate, Without a reliable lower layer, and a non-negligible error rate,
these packets can be lost, resulting in timeouts. It is therefore these packets can be lost, resulting in timeouts. It is therefore
desirable for implementations to improve their resilience to loss desirable for implementations to improve their resilience to loss
of EAP Success or Failure packets, as described in Section 4.2. 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 or fields in the EAP packet, such as the Code, Identifier, Length or
Type fields. As a result, without lower layer error detection, Type fields. As a result, without lower layer error detection,
undetected errors could creep into the EAP layer or EAP method undetected errors could creep into the EAP layer or EAP method
layer header fields, resulting in authentication failures. layer header fields, resulting in authentication failures.
For example, EAP TLS [RFC2716], which computes its MIC over the For example, EAP TLS [RFC2716], which computes its MIC over the
Type-Data field only, regards MIC validation failures as a fatal Type-Data field only, regards MIC validation failures as a fatal
error. Without lower layer error detection, this method and error. Without lower layer error detection, this method and
others like it will not perform reliably. others like it will not perform reliably.
[3] Lower layer security. EAP assumes that lower layers either [3] Lower layer security. EAP assumes that lower layers either
provide physical security (e.g., wired PPP or IEEE 802 links) or provide physical security (e.g., wired PPP or IEEE 802 links) or
support per-packet authentication, integrity and replay support per-packet authentication, integrity and replay
protection. EAP SHOULD NOT be used on physically insecure links protection. EAP SHOULD NOT be used on physically insecure links
(e.g., wireless or the Internet) where subsequent data is not (e.g., wireless or the Internet) where subsequent data is not
protected by per-packet authentication, integrity and replay protected by per-packet authentication, integrity and replay
protection. protection.
[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: the Identity (1), Notification (2), Nak this specification: the Identity (1), Notification (2), Nak
Response (3), MD5-Challenge (4), One Time Password (5), Generic Response (3), MD5-Challenge (4), One Time Password (5), Generic
Token Card (6) and expanded Nak Response (254) Types. Token Card (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
skipping to change at page 15, line 45 skipping to change at page 17, line 4
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 [RFC2716] support fragmentation and
reassembly, EAP methods originally designed for use within PPP reassembly, EAP methods originally designed for use within PPP
where a 1500 octet MTU is guaranteed for control frames (see where a 1500 octet MTU is guaranteed for control frames (see
[RFC1661], Section 6.1) may lack fragmentation and reassembly [RFC1661], Section 6.1) may lack fragmentation and reassembly
features. 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
skipping to change at page 16, line 32 skipping to change at page 17, line 39
"The Point-to-Point Protocol is designed for simple links "The Point-to-Point Protocol is designed for simple links
which transport packets between two peers. These links which transport packets between two peers. These links
provide full-duplex simultaneous bi-directional operation, and provide full-duplex simultaneous bi-directional operation, and
are assumed to deliver packets in order." are assumed to 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
authentication failure, causing EAP authentication to be rerun.
In an environment in which reordering is likely, it is therefore
expected that EAP authentication failures will be common. It is
RECOMMENDED that EAP only be run over lower layers that provide
ordering guarantees; running EAP over raw IP or UDP transport is
NOT RECOMMENDED. Encapsulation of EAP within RADIUS [RFC3579]
satisfies ordering requirements, since RADIUS is a "lockstep"
protocol that delivers packets in order.
3.2 EAP usage within PPP 3.2 EAP usage within PPP
In order to establish communications over a point-to-point link, each In order to establish communications over a point-to-point link, each
end of the PPP link must first send LCP packets to configure the data end of the PPP link must first send LCP packets to configure the data
link during Link Establishment phase. After the link has been link during Link Establishment phase. After the link has been
established, PPP provides for an optional Authentication phase before established, PPP provides for an optional Authentication phase before
proceeding to the Network-Layer Protocol phase. proceeding to the Network-Layer Protocol phase.
By default, authentication is not mandatory. If authentication of By default, authentication is not mandatory. If authentication of
the link is desired, an implementation MUST specify the the link is desired, an implementation MUST specify the
skipping to change at page 20, line 4 skipping to change at page 21, line 25
Data Link Layer padding and MUST be ignored on reception. A Data Link Layer padding and MUST be ignored on reception. A
message with the Length field set to a value larger than the message with the Length field set to a value larger than the
number of received octets MUST be silently discarded. number of received octets MUST be silently discarded.
Data Data
The Data field is zero or more octets. The format of the Data The Data field is zero or more octets. The format of the Data
field is determined by the Code field. field is determined by the Code field.
4.1 Request and Response 4.1 Request and Response
Description Description
The Request packet (Code field set to 1) is sent by the The Request packet (Code field set to 1) is sent by the
authenticator to the peer. Each Request has a Type field which authenticator to the peer. Each Request has a Type field which
serves to indicate what is being requested. Additional Request serves to indicate what is being requested. Additional Request
packets MUST be sent until a valid Response packet is received, or packets MUST be sent until a valid Response packet is received, or
an optional retry counter expires. an optional retry counter expires.
Retransmitted Requests MUST be sent with the same Identifier value Retransmitted Requests MUST be sent with the same Identifier value
in order to distinguish them from new Requests. The content of the in order to distinguish them from new Requests. The content of the
data field is dependent on the Request Type. The peer MUST send a data field is dependent on the Request Type. The peer MUST send a
Response packet in reply to a valid Request packet. Responses Response packet in reply to a valid Request packet. Responses
MUST only be sent in reply to a valid Request and never MUST only be sent in reply to a valid Request and never
retransmitted on a timer. retransmitted on a timer.
If a peer receives a valid duplicate Request for which it has If a peer receives a valid duplicate Request for which it has
already sent a Response, it MUST resend its original Response already sent a Response, it MUST resend its original Response
without reprocessing the Request. Requests MUST be processed in without reprocessing the Request. Requests MUST be processed in
the order that they are received, and MUST be processed to their the order that they are received, and MUST be processed to their
completion before inspecting the next Request. completion before inspecting the next Request.
A summary of the Request and Response packet format is shown below. A summary of the Request and Response packet format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
skipping to change at page 22, line 4 skipping to change at page 23, line 26
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 on treated as Data Link Layer padding and MUST be ignored on
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 Section
5.3) indicating that a Request Type is unacceptable to the peer. 5.3) indicating that a Request Type is unacceptable to the peer.
A peer MUST NOT send a Nak (legacy or expanded) in response to a A peer MUST NOT send a Nak (legacy or expanded) in response to a
Request, after an initial non-Nak Response has been sent. An EAP Request, after an initial non-Nak Response has been sent. An EAP
server receiving a Response not meeting these requirements MUST server receiving a Response not meeting these requirements MUST
silently discard it. silently discard it.
skipping to change at page 22, line 26 skipping to change at page 23, line 48
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
indicate that the peer has authenticated successfully to the indicate that the peer has authenticated successfully to the
authenticator. The authenticator MUST transmit an EAP packet with authenticator. The authenticator MUST transmit an EAP packet with
the Code field set to 3 (Success). If the authenticator cannot the Code field set to 3 (Success). If the authenticator cannot
authenticate the peer (unacceptable Responses to one or more authenticate the peer (unacceptable Responses to one or more
Requests) then after unsuccessful completion of the EAP method in Requests) then after unsuccessful completion of the EAP method in
progress, the implementation MUST transmit an EAP packet with the progress, the implementation MUST transmit an EAP packet with the
Code field set to 4 (Failure). An authenticator MAY wish to issue Code field set to 4 (Failure). An authenticator MAY wish to issue
multiple Requests before sending a Failure response in order to allow multiple Requests before sending a Failure response in order to allow
for human typing mistakes. Success and Failure packets MUST NOT for human typing mistakes. Success and Failure packets MUST NOT
contain additional data. contain additional data.
Success and Failure packets MUST NOT be sent by an EAP authenticator Success and Failure packets MUST NOT be sent by an EAP authenticator
if the specification of the given method does not explicitly permit if the specification of the given method does not explicitly permit
the method to finish at that point. A peer EAP implementation the method to finish at that point. A peer EAP implementation
receiving a Success or Failure packet where sending one is not receiving a Success or Failure packet where sending one is not
explicitly permitted MUST silently discard it. By default, an EAP explicitly permitted MUST silently discard it. By default, an EAP
peer MUST silently discard a "canned" Success packet (a Success peer MUST silently discard a "canned" Success packet (a Success
packet sent immediately upon connection). This ensures that a rogue packet sent immediately upon connection). This ensures that a rogue
authenticator will not be able to bypass mutual authentication by authenticator will not be able to bypass mutual authentication by
sending a Success packet prior to conclusion of the EAP method sending a Success packet prior to conclusion of the EAP method
conversation. conversation.
Implementation Note: Because the Success and Failure packets are Implementation Note: Because the Success and Failure packets are
not acknowledged, they are not retransmitted by the authenticator, not acknowledged, they are not retransmitted by the authenticator,
and may be potentially lost. A peer MUST allow for this and may be potentially lost. A peer MUST allow for this
circumstance as described in this note. See also Section 3.4 for circumstance as described in this note. See also Section 3.4 for
guidance on the processing of lower layer success and failure guidance on the processing of lower layer success and failure
indications. indications.
As described in Section 2.1, only a single EAP authentication As described in Section 2.1, only a single EAP authentication
method is allowed within an EAP conversation. EAP methods MAY method is allowed within an EAP conversation. EAP methods MAY
implement acknowledged result indications. After the authenticator implement protected result indications. After the authenticator
sends a method-specific failure indication to the peer, regardless sends a method-specific failure indication to the peer, regardless
of the response from the peer, it MUST subsequently send a Failure of the response from the peer, it MUST subsequently send a Failure
packet. After the authenticator sends a method-specific success packet. After the authenticator sends a method-specific success
indication to the peer, and receives a method-specific success indication to the peer, and receives a method-specific success
indication from the peer, it MUST subsequently send a Success indication from the peer, it MUST subsequently send a Success
packet. packet.
On the peer, once the method completes unsuccessfully (that is, On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a method-specific failure either the authenticator sends a method-specific failure
indication, or the peer decides that it does want to continue the indication, or the peer decides that it does want to continue the
conversation, possibly after sending a method-specific failure conversation, possibly after sending a method-specific failure
indication), the peer MUST terminate the conversation and indicate indication), the peer MUST terminate the conversation and indicate
failure to the lower layer. The peer MUST silently discard failure to the lower layer. The peer MUST silently discard
Success packets and MAY silently discard Failure packets. As a Success packets and MAY silently discard Failure packets. As a
result, loss of a Failure packet need not result in a timeout. result, loss of a Failure packet need not result in a timeout.
On the peer, after acknowledged successful result indications have On the peer, after protected successful result indications have
been exchanged by both sides, a Failure packet MUST be silently been exchanged by both sides, a Failure packet MUST be silently
discarded. The peer MAY, in the event that an EAP Success is not discarded. The peer MAY, in the event that an EAP Success is not
received, conclude that the EAP Success packet was lost and that received, conclude that the EAP Success packet was lost and that
authentication concluded successfully. authentication concluded successfully.
A mutually authenticating method (such as EAP-TLS [RFC2716]) that A mutually authenticating method (such as EAP-TLS [RFC2716]) that
provides authorization error messages provides acknowledged result provides authorization error messages provides protected result
indications for the purpose of this specification. Within indications for the purpose of this specification. Within
EAP-TLS, the peer always authenticates the authenticator, and may EAP-TLS, the peer always authenticates the authenticator, and may
send a TLS-alert message in the event of an authentication send a TLS-alert message in the event of an authentication
failure. An authenticator may use the "access denied" TLS alert failure. An authenticator may use the "access denied" TLS alert
after successfully authenticating the peer to indicate that a after successfully authenticating the peer to indicate that a
valid certificate was received from the peer, but when access valid certificate was received from the peer, but when access
control was applied, the authenticator decided not to proceed. If control was applied, the authenticator decided not to proceed. If
a method provides authorization error messages, the authenticator a method provides authorization error messages, the authenticator
SHOULD use them so as to ensure consistency with the final access SHOULD use them so as to ensure consistency with the final access
decision and avoid lengthy timeouts. decision and avoid lengthy timeouts.
skipping to change at page 25, line 32 skipping to change at page 26, line 51
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 estimation of SRTT, RTTVAR and RTO described in algorithms for estimation of SRTT, RTTVAR and RTO described in
[RFC2988] are RECOMMENDED, including use of Karn's algorithm, with [RFC2988] 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 [a] 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-random, generated by a PRNG seeded as per [RFC1750]. pseudo-random, generated by a PRNG seeded as per [RFC1750].
[b] When EAP is transported over a single link (as opposed to over [b] When EAP is transported over a single link (as opposed to over
the Internet), smaller values of RTOinitial, RTOmin and RTOmax the Internet), smaller values of RTOinitial, RTOmin and RTOmax
MAY be used. Recommended values are RTOinitial=1 second, MAY be used. Recommended values are RTOinitial=1 second,
RTOmin=200ms, RTOmax=20 seconds. RTOmin=200ms, RTOmax=20 seconds.
[c] When EAP is transported over a single link (as opposed to over [c] When EAP is transported over a single link (as opposed to over
the Internet), estimates MAY be done on a per-authenticator the Internet), estimates MAY be done on a per-authenticator
skipping to change at page 27, line 6 skipping to change at page 28, line 27
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
be sent in Response to a Request with a Type of 1 (Identity). be sent in Response to a Request with a Type of 1 (Identity).
Some EAP implementations piggy-back various options into the Some EAP implementations piggy-back various options into the
Identity Request after a NUL-character. By default an EAP Identity Request after a NUL-character. By default an EAP
implementation SHOULD NOT assume that an Identity Request or implementation SHOULD NOT assume that an Identity Request or
Response can be larger than 1020 octets. Response can be larger than 1020 octets.
Since Identity Requests and Responses are not protected, from a It is RECOMMENDED that the Identity Response be used primarily for
privacy perspective, it may be preferable for protected routing purposes and selecting which EAP method to use. EAP
method-specific Identity exchanges to be used instead. Where the Methods SHOULD include a method-specific mechanism for obtaining
peer is configured to only accept authentication methods the identity, so that they do not have to rely on the Identity
supporting protected identity exchanges, the peer MAY provide an Response. Identity Requests and Responses are not protected, so
abbreviated Identity Response (such as omitting the peer-name from a privacy perspective it is preferable for an EAP method to
portion of the NAI [RFC2486]). For further discussion of identity include its own protected identity exchange. The Identity
protection, see Section 7.3. Response may not be the appropriate identity for the method; it
may have been truncated or obfuscated so as to provide privacy; or
it may have been decorated for routing purposes. Where the peer
is configured to only accept authentication methods supporting
protected identity exchanges, the peer MAY provide an abbreviated
Identity Response (such as omitting the peer-name portion of the
NAI [RFC2486]). For further discussion of identity protection,
see Section 7.3.
Implementation Note: The peer MAY obtain the Identity via user Implementation Note: The peer MAY obtain the Identity via user
input. It is suggested that the authenticator retry the input. It is suggested that the authenticator retry the
Identity Request in the case of an invalid Identity or Identity Request in the case of an invalid Identity or
authentication failure to allow for potential typos on the part authentication failure to allow for potential typos on the part
of the user. It is suggested that the Identity Request be of the user. It is suggested that the Identity Request be
retried a minimum of 3 times before terminating the retried a minimum of 3 times before terminating the
authentication. The Notification Request MAY be used to authentication. The Notification Request MAY be used to
indicate an invalid authentication attempt prior to indicate an invalid authentication attempt prior to
transmitting a new Identity Request (optionally, the failure transmitting a new Identity Request (optionally, the failure
skipping to change at page 28, line 7 skipping to change at page 29, line 24
containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where containing UTF-8 encoded ISO 10646 characters [RFC2279]. 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):
Intended use: Physically secure lower layers; Intended use: Physically secure lower layers;
vulnerable to attack when used with vulnerable to attack when used with
wireless or over the Internet. wireless or over the Internet.
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
Acknowledged S/F: No Protected success/failure: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No
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 29, line 26 skipping to change at page 31, line 7
10646 characters [RFC2279]. The length of the message is 10646 characters [RFC2279]. The length of the message is
determined by Length field of the Request packet. The message determined by 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):
Intended use: Physically secure lower layers; Intended use: Physically secure lower layers;
vulnerable to attack when used with vulnerable to attack when used with
wireless or over the Internet. wireless or over the Internet.
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
Acknowledged S/F: No Protected success/failure: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No
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.
The Response contains one or more authentication Types desired by The Response contains one or more authentication Types desired by
the Peer. Type zero (0) is used to indicate that the sender has the Peer. Type zero (0) is used to indicate that the sender has
no viable alternatives, and therefore the authenticator SHOULD NOT no viable alternatives, and therefore the authenticator SHOULD NOT
send another Request after receiving a Nak Response containing a send another Request after receiving a Nak Response containing a
zero value. zero value.
skipping to change at page 31, line 8 skipping to change at page 32, line 37
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) in 255) MAY include the value 254 in the Nak Response (Type 3) in
order to indicate the desire for an Expanded authentication Type. order to indicate the desire for an Expanded authentication Type.
If the authenticator can accommodate this preference, it will If the authenticator can accommodate this preference, it will
respond with an Expanded Type Request (Type 254). respond with an Expanded Type Request (Type 254).
Security Claims (see Section 7.2): Security Claims (see Section 7.2):
Intended use: Physically secure lower layers; Intended use: Physically secure lower layers;
vulnerable to attack when used with vulnerable to attack when used with
wireless or over the Internet. wireless or over the Internet.
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
Acknowledged S/F: No Protected success/failure: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No
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 32, line 31 skipping to change at page 34, line 12
0 (IETF) 0 (IETF)
Vendor-Type Vendor-Type
3 (Nak) 3 (Nak)
Vendor-Data Vendor-Data
The Expanded Nak Type is only sent when the Request contains an The Expanded Nak Type is only sent when the Request contains an
Expanded Type (254) as defined in Section 5.7. The Vendor-Data Expanded Type (254) as defined in Section 5.7. The Vendor-Data
field of the Nak Response MUST contain one or more authentication field of the Nak Response MUST contain one or more authentication
Types (4 or greater), all in expanded format, 8 octets per Type, Types (4 or greater), all in expanded format, 8 octets per Type,
or the value zero (0), also in Expanded Type format, to indicate or the value zero (0), also in Expanded Type format, to indicate
no proposed alternative. The desired authentication Types may no proposed alternative. The desired authentication Types may
include a mixture of Vendor-Specific and IETF Types. For example, include a mixture of Vendor-Specific and IETF Types. For example,
an Expanded Nak Response indicating a preference for OTP (Type 5), an Expanded Nak Response indicating a preference for OTP (Type 5),
and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as
follows: follows:
0 1 2 3 0 1 2 3
skipping to change at page 34, line 7 skipping to change at page 35, line 10
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) | | 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) | | Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (No alternative) | | 0 (No alternative) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Claims (see Section 7.2): Security Claims (see Section 7.2):
Intended use: Physically secure lower layers; Intended use: Physically secure lower layers;
vulnerable to attack when used with vulnerable to attack when used with
wireless or over the Internet. wireless or over the Internet.
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
Acknowledged S/F: No Protected success/failure: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No
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
Nak reply indicates the peer's desired authentication Type(s). Nak reply indicates the peer's desired authentication Type(s).
EAP peer and EAP server implementations MUST support the EAP peer and EAP server implementations MUST support the
MD5-Challenge mechanism. An authenticator that supports only MD5-Challenge mechanism. An authenticator that supports only
pass-through MUST allow communication with a backend pass-through MUST allow communication with a backend
authentication server that is capable of supporting MD5-Challenge, authentication server that is capable of supporting MD5-Challenge,
although the EAP authenticator implementation need not support although the EAP authenticator implementation need not support
MD5-Challenge itself. However, if the EAP authenticator can be MD5-Challenge itself. However, if the EAP authenticator can be
configured to authenticate peers locally (e.g., not operate in configured to authenticate peers locally (e.g., not operate in
pass-through), then the requirement for support of the pass-through), then the requirement for support of the
MD5-Challenge mechanism applies. MD5-Challenge mechanism applies.
skipping to change at page 35, line 32 skipping to change at page 37, line 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ... | Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... | Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Claims (see Section 7.2): Security Claims (see Section 7.2):
Intended use: Wired networks, including PPP, PPPOE, and Intended use: Wired networks, including PPP, PPPOE,
IEEE 802 wired media. Use over the and IEEE 802 wired media. Use over the
Internet or with wireless media only when Internet or with wireless media only
protected. when protected.
Auth. mechanism: Password or pre-shared key. Auth. mechanism: Password or pre-shared key.
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: No Dictionary attack prot.: No
Fast reconnect: No Fast reconnect: No
Crypt. binding: N/A Crypt. binding: N/A
Acknowledged S/F: No Protected success/failure: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No
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 5 skipping to change at page 38, line 13
the Length field of the Request/Reply packet. the Length field of the Request/Reply packet.
Note: [RFC2289] does not specify how the secret pass-phrase is Note: [RFC2289] does not specify how the secret pass-phrase is
entered by the user, or how the pass-phrase is converted into entered by the user, or how the pass-phrase is converted into
octets. EAP OTP implementations MAY support entering passphrases octets. EAP OTP implementations MAY support entering passphrases
with non-ASCII characters. See Section 5 for instructions how the with non-ASCII characters. See Section 5 for instructions how the
input should be processed and encoded into octets. input should be processed and encoded into octets.
Security Claims (see Section 7.2): Security Claims (see Section 7.2):
Intended use: Wired networks, including PPP, PPPOE, and Intended use: Wired networks, including PPP, PPPOE,
IEEE 802 wired media. Use over the and IEEE 802 wired media. Use over the
Internet or with wireless media only when Internet or with wireless media only
protected. when protected.
Auth. mechanism: One-Time Password Auth. mechanism: One-Time Password
Ciphersuite negotiation: No Ciphersuite negotiation: No
Mutual authentication: No Mutual authentication: No
Integrity protection: No Integrity protection: No
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
Acknowledged S/F: No Protected success/failure: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No
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 15 skipping to change at page 39, line 26
Response contains data from the Token Card required for Response contains data from the Token Card required for
authentication. The length of the data is determined by the authentication. The length of the data is determined by the
Length field of the Response packet. Length field of the Response packet.
EAP GTC implementations MAY support entering a response with EAP GTC implementations MAY support entering a response with
non-ASCII characters. See Section 5 for instructions how the non-ASCII characters. See Section 5 for instructions how the
input should be processed and encoded into octets. input should be processed and encoded into octets.
Security Claims (see Section 7.2): Security Claims (see Section 7.2):
Intended use: Wired networks, including PPP, PPPOE, and Intended use: Wired networks, including PPP, PPPOE,
IEEE 802 wired media. Use over the and IEEE 802 wired media. Use over the
Internet or with wireless media only when Internet or with wireless media only
protected. when protected.
Auth. mechanism: Hardware token. Auth. mechanism: Hardware token.
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: No Dictionary attack prot.: No
Fast reconnect: No Fast reconnect: No
Crypt. binding: N/A Crypt. binding: N/A
Acknowledged S/F: No Protected success/failure: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No
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 39, line 45 skipping to change at page 41, line 8
vendor-specific method Type. vendor-specific method Type.
If the Vendor-Id is zero, the Vendor-Type field is an extension If the Vendor-Id is zero, the Vendor-Type field is an extension
and superset of the existing namespace for EAP Types. The first and superset of the existing namespace for EAP Types. The first
256 Types are reserved for compatibility with single-octet EAP 256 Types are reserved for compatibility with single-octet EAP
Types that have already been assigned or may be assigned in the Types that have already been assigned or may be assigned in the
future. Thus, EAP Types from 0 through 255 are semantically future. Thus, EAP Types from 0 through 255 are semantically
identical whether they appear as single octet EAP Types or as identical whether they appear as single octet EAP Types or as
Vendor-Types when Vendor-Id is zero. There is one exception to Vendor-Types when Vendor-Id is zero. There is one exception to
this rule: Expanded Nak and Legacy Nak packets share the same this rule: Expanded Nak and Legacy Nak packets share the same
code, but must be treated differently because they have a Type, but must be treated differently because they have a
different format. different format.
Vendor-Data Vendor-Data
The Vendor-Data field is defined by the vendor. Where a Vendor-Id The Vendor-Data field is defined by the vendor. Where a Vendor-Id
of zero is present, the Vendor-Data field will be used for of zero is present, the Vendor-Data field will be used for
transporting the contents of EAP methods of Types defined by the transporting the contents of EAP methods of Types defined by the
IETF. IETF.
5.8 Experimental 5.8 Experimental
skipping to change at page 41, line 43 skipping to change at page 43, line 6
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. allocated after Type values 1-191 have been allocated.
Method Type 255 is allocated for Experimental use, such as testing of Method Type 255 is allocated for Experimental use, such as testing of
new EAP methods before a permanent Type code is allocated. new EAP methods before a permanent Type is allocated.
7. Security Considerations 7. Security Considerations
EAP was designed for use with dialup PPP [RFC1661] and was later EAP was designed for use with dialup PPP [RFC1661] and was later
adapted for use in wired IEEE 802 networks [IEEE-802] in adapted for use in wired IEEE 802 networks [IEEE-802] in
[IEEE-802.1X]. On these networks, an attacker would need to gain [IEEE-802.1X]. On these networks, an attacker would need to gain
physical access to the telephone or switch infrastructure in order to physical access to the telephone or switch infrastructure in order to
mount an attack. While such attacks have been documented, such as in mount an attack. While such attacks have been documented, such as in
[DECEPTION], they are assumed to be rare. [DECEPTION], they are assumed to be rare.
However, subsequently EAP has been proposed for use on wireless However, subsequently EAP has been proposed for use on wireless
networks, and over the Internet, where physical security cannot be networks, and over the Internet, where physical security cannot be
assumed. On such networks, the security vulnerabilities are greater, assumed. On such networks, the security vulnerabilities are greater,
as are the requirements for EAP security. as are the requirements for EAP security.
This section defines the threat model and security terms and This section defines the threat model and security terms and
describes the security claims section required in EAP method describes the security claims section required in EAP method
specifications. We then discuss threat mitigation. specifications. We then discuss threat mitigation.
7.1 Threat model 7.1 Threat model
On physically insecure networks, it is possible for an attacker to On physically insecure networks, it is possible for an attacker to
gain access to the physical medium. This enables a range of attacks, gain access to the physical medium. This enables a range of attacks,
including the following: including the following:
[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 an [4] An attacker may attempt to recover the pass-phrase by mounting
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
information to the EAP peer and/or server via out-of-band
mechanisms (such as via a AAA or lower layer protocol). This
includes impersonating another authenticator, or providing
inconsistent information to the peer and EAP server.
Where EAP is used over wired networks, an attacker typically requires Where EAP is used over wired networks, an attacker typically requires
access to the physical infrastructure in order to carry out these access to the physical infrastructure in order to carry out these
attacks. However, where EAP is used over wireless networks, EAP attacks. However, where EAP is used over wireless networks, EAP
packets may be forwarded by authenticators (e.g., pre-authentication) packets may be forwarded by authenticators (e.g., pre-authentication)
so that the attacker need not be within the coverage area of an so that the attacker need not be within the coverage area of an
authenticator in order to carry out an attack on it or its peers. authenticator in order to carry out an attack on it or its peers.
Where EAP is used over the Internet, attacks may be carried out at an Where EAP is used over the Internet, attacks may be carried out at an
even greater distance. even greater distance.
skipping to change at page 43, line 28 skipping to change at page 44, line 47
intended for use over a physically secure or insecure network, as intended for use over a physically secure or insecure network, as
well as a statement of the applicable lower layers. well as a statement of the applicable lower layers.
[b] Mechanism. This is a statement of the authentication technology: [b] 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.
[c] Security claims. This is a statement of the claimed security [c] Security claims. This is a statement of the claimed security
properties of the method, using terms defined in Section 1.2: properties of the method, using terms defined in Section 1.2:
mutual authentication, integrity protection, replay protection, mutual authentication, integrity protection, replay protection,
confidentiality, key derivation, dictionary attack resistance, confidentiality, key derivation, dictionary attack resistance,
fast reconnect, cryptographic binding, acknowledged result fast reconnect, cryptographic binding, protected result
indications. The Security Claims section of an EAP method indications. The Security Claims section of an EAP method
specification SHOULD provide justification for the claims that specification SHOULD provide justification for the claims that
are made. This can be accomplished by including a proof in an are made. This can be accomplished by including a proof in an
Appendix, or including a reference to a proof. Appendix, or including a reference to a proof.
[d] Key strength. If the method derives keys, then the effective key [d] 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.
skipping to change at page 44, line 11 skipping to change at page 45, line 30
(Note: Although it is difficult to define what "comparable (Note: Although it is difficult to define what "comparable
effort" and "typical block cipher" exactly mean, reasonable effort" and "typical block cipher" exactly mean, reasonable
approximations are sufficient here. Refer to e.g. [SILVERMAN] approximations are sufficient here. Refer to e.g. [SILVERMAN]
for more discussion.) for more 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.
[e] Description of key hierarchy. EAP methods deriving keys MUST [e] 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.
[f] Indication of vulnerabilities. In addition to the security [f] Indication of vulnerabilities. In addition to the security
claims that are made, the specification MUST indicate which of claims that are made, the specification MUST indicate which of
the security claims detailed in Section 7.2.1 are NOT being made. the 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 described the security properties of EAP These terms are used to described the security properties of EAP
methods: methods:
Protected ciphersuite negotiation Protected ciphersuite negotiation
This refers to the ability of an EAP method to negotiate This refers to the ability of an EAP method to negotiate
the ciphersuite used to protect the EAP conversation, as the ciphersuite used to protect the EAP conversation, as
well as to integrity protect the negotiation. It does not well as to integrity protect the negotiation. It does not
refer to the ability to negotiate the ciphersuite used to refer to the ability to negotiate the ciphersuite used to
protect data. protect data.
Mutual authentication Mutual authentication
This refers to an EAP method in which, within an This refers to an EAP method in which, within an
interlocked exchange, the authenticator authenticates the interlocked exchange, the authenticator authenticates the
peer and the peer authenticates the authenticator. Two peer and the peer authenticates the authenticator. Two
independent one-way methods, running in opposite directions independent one-way methods, running in opposite directions
do not provide mutual authentication as defined here. do not provide mutual authentication as defined here.
skipping to change at page 46, line 5 skipping to change at page 47, line 23
Cryptographic binding Cryptographic binding
The demonstration of the EAP peer to the EAP server that a The demonstration of the EAP peer to the EAP server that a
single entity has acted as the EAP peer for all methods single entity has acted as the EAP peer for all methods
executed within a tunnel method. Binding MAY also imply executed within a tunnel method. Binding MAY also imply
that the EAP server demonstrates to the peer that a single that the EAP server demonstrates to the peer that a single
entity has acted as the EAP server for all methods executed entity has acted as the EAP server for all methods executed
within a tunnel method. If executed correctly, binding within a tunnel method. If executed correctly, binding
serves to mitigate man-in-the-middle vulnerabilities. serves to mitigate man-in-the-middle vulnerabilities.
Acknowledged result indications Protected result indications
The ability within a method for the authenticator to The ability within a method for the authenticator to
indicate to the peer whether it has successfully indicate to the peer whether it has successfully
authenticated to it, and for the peer to acknowledge authenticated to it, and for the peer to acknowledge
receipt of that indication as well as indicating to the receipt of that indication as well as indicating to the
authenticator whether it has successfully authenticated to authenticator whether it has successfully authenticated to
the peer. Since EAP Success and Failure packets are neither the peer. Since EAP Success and Failure packets are
acknowledged nor integrity protected, this claim requires neither acknowledged nor integrity protected, this claim
implementation of a method-specific result exchange that is requires implementation of a method-specific result
authenticated, integrity and replay protected on a exchange that is authenticated, integrity and replay
per-packet basis. protected on a per-packet basis.
Session independence Session independence
The demonstration that passive attacks (such as capture of The demonstration that passive attacks (such as capture of
the EAP conversation) or active attacks (including the EAP conversation) or active attacks (including
compromise of the MSK or EMSK) does not enable compromise compromise of the MSK or EMSK) does not enable compromise
of subsequent or prior MSKs or EMSKs. of subsequent or prior MSKs or EMSKs.
Fragmentation Fragmentation
This refers to whether an EAP method supports fragmentation This refers to whether an EAP method supports fragmentation
and reassembly. As noted in Section 3.1, EAP methods should and reassembly. As noted in Section 3.1, EAP methods
support fragmentation and reassembly if EAP packets can should support fragmentation and reassembly if EAP packets
exceed the minimum MTU of 1020 octets. can exceed the minimum MTU of 1020 octets.
Channel binding
The communication within an EAP method of
integrity-protected channel properties such as endpoint
identifiers which can be compared to values communicated
via out of band mechanisms (such as via a AAA or lower
layer protocol).
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 may 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 may different from the identity authenticated by the EAP method. This may
be intentional in the case of identity privacy. An EAP method SHOULD be intentional in the case of identity privacy. An EAP method SHOULD
use the authenticated identity when making access control decisions. use the authenticated identity when making access control 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 authentication, there exists a potential vulnerability to
man-in-the-middle attack. man-in-the-middle attack. For details, see [BINDING] and [MITM].
As noted in Section 2.1, EAP does not permit untunnelled sequences of As noted in Section 2.1, EAP does not permit untunnelled 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 39 skipping to change at page 49, line 15
ability to decrypt data traffic between the legitimate peer and ability to decrypt data traffic between the legitimate peer and
server. 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. [a] Requiring mutual authentication within EAP tunneling mechanisms.
[b] Requiring cryptographic binding between the EAP tunneling [b] 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. against downgrade attacks that would bypass it. For further
details on cryptographic binding, see [BINDING].
[c] Limiting the EAP methods authorized for use without protection, [c] 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 [d] 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,
skipping to change at page 48, line 24 skipping to change at page 49, line 49
lower layers such as wireless (802.11 or cellular) or the Internet lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling), (such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is this assumption is no longer valid and the vulnerability to attack is
greater. greater.
To protect EAP messages sent over physically insecure lower layers, To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection as per-packet origin authentication, integrity and replay protection
SHOULD be used. SHOULD be used.
Method-specific MICs may be used to provide protection. If a Method-specific MICs may be used to provide protection. If a
per-packet MIC is employed within an EAP method, then peers, per-packet MIC is employed within an EAP method, then peers,
authentication servers, and authenticators not operating in authentication servers, and authenticators not operating in
pass-through mode MUST validate the MIC. MIC validation failures pass-through mode MUST validate the MIC. MIC validation failures
SHOULD be logged. Whether a MIC validation failure is considered a SHOULD be logged. Whether a MIC validation failure is considered a
fatal error or not is determined by the EAP method specification. fatal error or not is determined by the EAP method specification.
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 is protected channel created by protocols such as ISAKMP [RFC2408] as is
done in [IKEv2] or within TLS [RFC2246]. However, as noted in Section done in [IKEv2] or within TLS [RFC2246]. However, as noted in
7.4, EAP tunneling may result in a man-in-the-middle vulnerability. Section 7.4, EAP tunneling may result in a man-in-the-middle
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 [RFC2716]
defines a MIC over a TLS record that could be split into multiple defines a MIC over a TLS record that could be split into multiple
fragments; within the FINISHED message, the MIC is computed over fragments; within the FINISHED message, the MIC is computed over
previous messages. Where the MIC covers more than one EAP packet, a previous messages. Where the MIC covers more than one EAP packet, a
MIC validation failure is typically considered a fatal error. MIC validation failure is typically considered a fatal error.
Within EAP-TLS [RFC2716] a MIC validation failure is treated as a Within EAP-TLS [RFC2716] a MIC validation failure is treated as a
fatal error, since that is what is specified in TLS [RFC2246]. fatal error, since that is what is specified in TLS [RFC2246].
However, it is also possible to develop EAP methods that support However, it is also possible to develop EAP methods that support
per-packet MICs, and respond to verification failures by silently per-packet MICs, and respond to verification failures by silently
discarding the offending packet. 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
skipping to change at page 50, line 44 skipping to change at page 52, line 25
However, in PPP the LCP state machine can renegotiate the However, in PPP the LCP state machine can renegotiate the
authentication protocol at any time, thus allowing a new attempt. authentication protocol at any time, thus allowing a new attempt.
Similarly, in IEEE 802.1X the Supplicant or Authenticator can Similarly, in IEEE 802.1X the Supplicant or Authenticator can
re-authenticate at any time. It is recommended that any counters re-authenticate at any time. It is recommended that any counters
used for authentication failure not be reset until after successful used for authentication failure not be reset until after successful
authentication, or subsequent termination of the failed link. authentication, or subsequent termination of the failed link.
7.10 Key derivation 7.10 Key derivation
It is possible for the peer and EAP server to mutually authenticate It is possible for the peer and EAP server to mutually authenticate
and derive keys. In order to provide keying material for use in a and derive keys. In order to provide keying material for use in a
subsequently negotiated ciphersuite, an EAP method supporting key subsequently negotiated ciphersuite, an EAP method supporting key
derivation MUST export a Master Session Key (MSK) of at least 64 derivation MUST export a Master Session Key (MSK) of at least 64
octets, and an Extended Master Session Key (EMSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64
octets. EAP Methods deriving keys MUST provide for mutual octets. EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server. authentication between the EAP peer and the EAP Server.
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). [KEYFRAME] 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 and not Transient Session Keys so EAP methods export the MSK and EMSK and not Transient Session Keys so
as to allow EAP methods to be ciphersuite and media independent. 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.
Depending on the lower layer, EAP methods may run before or after Depending on the lower layer, EAP methods may run before or after
ciphersuite negotiation, so that the selected ciphersuite may not be ciphersuite negotiation, so that the selected ciphersuite may not be
known to the EAP method. By providing keying material usable with known to the EAP method. By providing keying material usable with
any ciphersuite, EAP methods can used with a wide range of any ciphersuite, EAP methods can used with a wide range of
ciphersuites and media. ciphersuites and media.
It is RECOMMENDED that methods providing integrity protection of EAP It is RECOMMENDED that methods providing integrity protection of EAP
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.
In order to preserve algorithm independence, EAP methods deriving In order to preserve algorithm independence, EAP methods deriving
keys SHOULD support (and document) the protected negotiation of the keys SHOULD support (and document) the protected negotiation of the
ciphersuite used to protect the EAP conversation between the peer and ciphersuite used to protect the EAP conversation between the peer and
server. This is distinct from the ciphersuite negotiated between the server. This is distinct from the ciphersuite negotiated between the
peer and authenticator, used to protect data. peer and authenticator, used to protect data.
The strength of Transient Session Keys (TSKs) used to protect data is The strength of Transient Session Keys (TSKs) used to protect data is
ultimately dependent on the strength of keys generated by the EAP ultimately dependent on the strength of keys generated by the EAP
method. If an EAP method cannot produce keying material of sufficient method. If an EAP method cannot produce keying material of
strength, then the TSKs may be subject to brute force attack. In sufficient strength, then the TSKs may be subject to brute force
order to enable deployments requiring strong keys, EAP methods attack. In order to enable deployments requiring strong keys, EAP
supporting key derivation SHOULD be capable of generating an MSK and methods supporting key derivation SHOULD be capable of generating an
EMSK, each with an effective key strength of at least 128 bits. MSK and EMSK, each with an effective key strength of at least 128
bits.
Methods supporting key derivation MUST demonstrate cryptographic Methods supporting key derivation MUST demonstrate cryptographic
separation between the MSK and EMSK branches of the EAP key separation between the MSK and EMSK branches of the EAP key
hierarchy. Without violating a fundamental cryptographic assumption hierarchy. Without violating a fundamental cryptographic assumption
(such as the non-invertibility of a one-way function) an attacker (such as the non-invertibility of a one-way function) an attacker
recovering the MSK or EMSK MUST NOT be able to recover the other recovering the MSK or EMSK MUST NOT be able to recover the other
quantity with a level of effort less than brute force. quantity with a level of effort less than brute force.
Non-overlapping substrings of the MSK MUST be cryptographically Non-overlapping substrings of the MSK MUST be cryptographically
separate from each other, as defined in Section 7.2.1. That is, separate from each other, as defined in Section 7.2.1. That is,
knowledge of one substring MUST NOT help in recovering some other knowledge of one substring MUST NOT help in recovering some other
substring without breaking some hard cryptographic assumption. This substring without breaking some hard cryptographic assumption. This
is required because some existing ciphersuites form TSKs by simply is required because some existing ciphersuites form TSKs by simply
splitting the AAA-Key to pieces of appropriate length. Likewise, splitting the AAA-Key to pieces of appropriate length. Likewise,
non-overlapping substrings of the EMSK MUST be cryptographically non-overlapping substrings of the EMSK MUST be cryptographically
separate from each other, and from substrings of the MSK. separate from each other, and from substrings of the MSK.
The EMSK is reserved for future use and MUST remain on the EAP peer The EMSK is reserved for future use and MUST remain on the EAP peer
and EAP server where it is derived; it MUST NOT be transported to, or and EAP server where it is derived; it MUST NOT be transported to, or
shared with, additional parties, or used to derive any other keys. shared with, additional parties, or used to derive any other keys.
(This restriction will be relaxed in a future document that specifies (This restriction will be relaxed in a future document that specifies
how the EMSK can be used.) how the EMSK can be used.)
skipping to change at page 54, line 14 skipping to change at page 55, line 42
come and go and may be influenced by radio frequency interference come and go and may be influenced by radio frequency interference
generated by an attacker. To avoid unnecessary resets, it is generated by an attacker. To avoid unnecessary resets, it is
advisable to damp these indications, rather than passing them advisable to damp these indications, rather than passing them
directly to the EAP. Since EAP supports retransmission, it is directly to the EAP. Since EAP supports retransmission, it is
robust against transient connectivity losses. robust against transient connectivity losses.
7.13 Separation of authenticator and backend authentication server 7.13 Separation of authenticator and backend authentication server
It is possible for the EAP peer and EAP server to mutually It is possible for the EAP peer and EAP server to mutually
authenticate and derive a AAA-Key for a ciphersuite used to protect authenticate and derive a AAA-Key for a ciphersuite used to protect
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 [a] Authentication will occur between the peer and the authentication
skipping to change at page 54, line 48 skipping to change at page 56, line 29
secure, after completion of the EAP conversation, a secure secure, after completion of the EAP conversation, a secure
association protocol SHOULD be run between the peer and association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication; authenticator in order to provide mutual authentication;
guarantee liveness of the TSKs; provide protected ciphersuite and guarantee liveness of the TSKs; provide protected ciphersuite and
capabilities negotiation; synchronize key usage. capabilities negotiation; synchronize key usage.
[d] A AAA-Key derived from the MSK and/or EMSK negotiated between the [d] 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 are scope of this document. Further details on AAA-Key Derivation
provided within [KEYFRAME]. are provided within [KEYFRAME].
7.14 Cleartext Passwords 7.14 Cleartext Passwords
EAP does not support cleartext password authentication. This EAP does not support cleartext password authentication. This
omission is intentional. Where EAP is carried over physically omission is intentional. Where EAP is carried over physically
insecure lower layers, including wireless LANs [IEEE-802.11] or the insecure lower layers, including wireless LANs [IEEE-802.11] or the
Internet, use of cleartext passwords would allow the password to be Internet, use of cleartext passwords would allow the password to be
captured by an attacker with access to the lower layer. captured by an attacker with access to the lower layer.
Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
provide confidentiality, even where the lower layer is physically provide confidentiality, even where the lower layer is physically
secure, EAP frames may be subsequently encapsulated for transport secure, EAP frames may be subsequently encapsulated for transport
over the Internet where they may be captured by an attacker. over the Internet where they may be captured by an attacker.
As a result, cleartext passwords cannot be securely used within EAP, As a result, cleartext passwords cannot be securely used within EAP,
except where encapsulated within a protected tunnel with server except where encapsulated within a protected tunnel with server
authentication. Some of the same risks apply to EAP methods without authentication. Some of the same risks apply to EAP methods without
dictionary attack resistance, as defined in Section 7.2.1. For dictionary attack resistance, as defined in Section 7.2.1. For
details, see Section 7.6. details, see Section 7.6.
7.15 Channel binding
It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer
and/or server. This may enable an authenticator to impersonate
another authenticator or communicate incorrect information via
out-of-band mechanisms (such as via a AAA or lower layer protocol).
Where EAP is used in pass-through mode, the EAP peer typically does
not verify the identity of the pass-through authenticator, it only
verifies that the pass-through authenticator is trusted by the EAP
server. This creates a potential security vulnerability.
Section 4.3.7 of [RFC3579] describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect
NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or
NAS-IPv6-Address [RFC3162] attributes via the AAA protocol).
However, it is possible for a pass-through authenticator acting as a
AAA client to provide correct information to the AAA server while
communicating misleading information to the EAP peer via a lower
layer protocol.
For example, it is possible for a compromised authenticator to
utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the EAP peer via a lower layer protocol, or for
a pass-through authenticator acting as a AAA client to provide an
incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
server via the AAA protocol.
In order to address this vulnerability, EAP methods may support a
protected exchange of channel properties such as endpoint
identifiers, including (but not limited to): Called-Station-Id
[RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580],
NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and
NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. Where discrepancies
are found, these SHOULD be logged; additional actions MAY also be
taken, such as denying access.
8. Acknowledgments 8. Acknowledgments
This protocol derives much of its inspiration from Dave Carrel's AHA This protocol derives much of its inspiration from Dave Carrel's AHA
draft as well as the PPP CHAP protocol [RFC1994]. Valuable feedback draft as well as the PPP CHAP protocol [RFC1994]. Valuable feedback
was provided by Yoshihiro Ohba of Toshiba America Research, Jari was provided by Yoshihiro Ohba of Toshiba America Research, Jari
Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco
Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan
Payne of the University of Maryland, Steve Bellovin of AT&T Research, Payne of the University of Maryland, Steve Bellovin of AT&T Research,
Paul Funk of Funk Software, Pasi Eronen of Nokia, Joseph Salowey of Paul Funk of Funk Software, Pasi Eronen of Nokia, Joseph Salowey of
Cisco and Paul Congdon of HP and members of the EAP working group. Cisco and Paul Congdon of HP and members of the EAP working group.
The use of Security Claims sections for EAP methods, as required by
Section 7.2 and specified for each EAP method described in this
document, was inspired by Glen Zorn through [EAP-EVAL].
Normative References Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996. Protocol (CHAP)", RFC 1994, August 1996.
skipping to change at page 57, line 28 skipping to change at page 60, line 5
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC
2661, August 1999. 2661, August 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999. Protocol", RFC 2716, October 1999.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission Zhang, L. and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, Internationalized Strings ("stringprep")", RFC 3454,
December 2002. December 2002.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.
[DECEPTION] [DECEPTION]
Slatalla, M. and J. Quittner, "Masters of Deception", Slatalla, M. and J. Quittner, "Masters of Deception",
Harper-Collins , New York, 1995. Harper-Collins , New York, 1995.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support For Extensible
Authentication Protocol (EAP)", RFC 3579, May 2003.
[KRBATTACK] [KRBATTACK]
Wu, T., "A Real-World Analysis of Kerberos Password Wu, T., "A Real-World Analysis of Kerberos Password
Security", Proceedings of the 1999 ISOC Network and Security", Proceedings of the 1999 ISOC Network and
Distributed System Security Symposium, http:// Distributed System Security Symposium, http://
www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/ www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/
wu.pdf. wu.pdf.
[KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos [KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos
authentication system", Proceedings of the 1991 Winter authentication system", Proceedings of the 1991 Winter
USENIX Conference, pp. 253-267, 1991. USENIX Conference, pp. 253-267, 1991.
skipping to change at page 58, line 17 skipping to change at page 61, line 6
Dole, B., Lodin, S. and E. Spafford, "Misplaced trust: Dole, B., Lodin, S. and E. Spafford, "Misplaced trust:
Kerberos 4 session keys", Proceedings of the Internet Kerberos 4 session keys", Proceedings of the Internet
Society Network and Distributed System Security Symposium, Society Network and Distributed System Security Symposium,
pp. 60-70, March 1997. pp. 60-70, March 1997.
[PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A Pre-IKE [PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A Pre-IKE
Credential Provisioning Protocol", draft-ietf-ipsra-pic-06 Credential Provisioning Protocol", draft-ietf-ipsra-pic-06
(work in progress), October 2002. (work in progress), October 2002.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-10 (work in progress), May 2003. draft-ietf-ipsec-ikev2-11 (work in progress), October
2003.
[PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's [PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's
Point-to- Point Tunneling Protocol", Proceedings of the Point-to- Point Tunneling Protocol", Proceedings of the
5th ACM Conference on Communications and Computer 5th ACM Conference on Communications and Computer
Security, ACM Press, November 1998. Security, ACM Press, November 1998.
[IEEE-802.3] [IEEE-802.3]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and "Information technology - Telecommunications and
Information Exchange between Systems - Local and information exchange between systems - Local and
Metropolitan Area Networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
3: Carrier sense multiple access with collision detection 3: Carrier sense multiple access with collision detection
(CSMA/CD) Access Method and Physical Layer (CSMA/CD) access method and physical layer
Specifications", IEEE Standard 802.3, September 1998. specifications"", IEEE Standard 802.3, September 1998.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information Technology - Telecommunications and "Wireless LAN Medium Access Control (MAC) and Physical
Information Exchange between Systems - Local and
Metropolitan Area Network - Specific Requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, 1999. Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
[SILVERMAN] [SILVERMAN]
Silverman, Robert D., "A Cost-Based Security Analysis of Silverman, Robert D., "A Cost-Based Security Analysis of
Symmetric and Asymmetric Key Lengths", RSA Laboratories Symmetric and Asymmetric Key Lengths", RSA Laboratories
Bulletin 13, April 2000 (Revised November 2001), http:// Bulletin 13, April 2000 (Revised November 2001), http://
www.rsasecurity.com/rsalabs/bulletins/bulletin13.html. www.rsasecurity.com/rsalabs/bulletins/bulletin13.html.
[IANA-EXP] [IANA-EXP]
Narten, T., "Assigning Experimental and Testing Numbers Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", Considered Useful",
draft-narten-iana-experimental-allocations-03 (work in draft-narten-iana-experimental-allocations-05 (work in
progress), December 2002. progress), November 2003.
[KEYFRAME] [KEYFRAME]
Aboba, B. and D. Simon, "EAP Keying Framework", Aboba, B., "EAP Key Management Framework",
draft-aboba-pppext-key-problem-07 (work in progress), draft-ietf-eap-keying-01 (work in progress), October 2003.
March 2003.
[SASLPREP] [SASLPREP]
Zeilenga, K., "SASLprep: Stringprep profile for user names Zeilenga, K., "SASLprep: Stringprep profile for user names
and passwords", draft-ietf-sasl-saslprep-03 (work in and passwords", draft-ietf-sasl-saslprep-04 (work in
progress), May 2003. progress), October 2003.
[IEEE-802.11i] [IEEE-802.11i]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Unapproved Draft Supplement to Standard for "Unapproved Draft Supplement to Standard for
Telecommunications and Information Exchange Between Telecommunications and Information Exchange Between
Systems - LAN/MAN Specific Requirements - Part 11: Systems - LAN/MAN Specific Requirements - Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications: Specification for Enhanced Layer (PHY) Specifications: Specification for Enhanced
Security", IEEE Draft 802.11i (work in progress), 2003. Security", IEEE Draft 802.11i (work in progress), 2003.
[DIAM-EAP] [DIAM-EAP]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-02 (work in progress), June 2003. draft-ietf-aaa-eap-03 (work in progress), October 2003.
[EAP-EVAL]
Zorn, G., "Specifying Security Claims for EAP
Authentication Types", draft-zorn-eap-eval-00 (work in
progress), October 2002.
[BINDING] Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (work in
progress), October 2003.
[MITM] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-Middle in
Tunnelled Authentication Protocols", IACR ePrint Archive
Report 2002/163, October 2002, <http://eprint.iacr.org/
2002/163>.
Authors' Addresses Authors' Addresses
Larry J. Blunk Larry J. Blunk
Merit Network, Inc Merit Network, Inc
4251 Plymouth Rd., Suite 2000 4251 Plymouth Rd., Suite 2000
Ann Arbor, MI 48105-2785 Ann Arbor, MI 48105-2785
USA USA
Phone: +1 734-647-9563 Phone: +1 734-647-9563
skipping to change at page 62, line 20 skipping to change at page 65, line 20
(This section should be removed by the RFC editor before publication) (This section should be removed by the RFC editor before publication)
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
http://www.drizzle.com/~aboba/EAP/eapissues.html http://www.drizzle.com/~aboba/EAP/eapissues.html
The current working documents for this draft are available at this The current working documents for this draft are available at this
web site: web site:
http://www.levkowetz.com/pub/ietf/drafts/eap/ http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 64, line 7 skipping to change at page 67, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Attachment Converted: "c:\program files\qualcomm\eudora\imap\dominant\ids\attach\Untitled3"
 End of changes. 112 change blocks. 
372 lines changed or deleted 573 lines changed or added

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