< draft-ietf-eap-rfc2284bis-08.txt   draft-ietf-eap-rfc2284bis-09.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: August 14, 2004 Vollbrecht Consulting LLC Expires: August 15, 2004 Vollbrecht Consulting LLC
B. Aboba B. Aboba
Microsoft Microsoft
J. Carlson J. Carlson
Sun Sun
H. Levkowetz, Ed. H. Levkowetz, Ed.
ipUnplugged ipUnplugged
February 14, 2004 February 15, 2004
Extensible Authentication Protocol (EAP) Extensible Authentication Protocol (EAP)
<draft-ietf-eap-rfc2284bis-08.txt> <draft-ietf-eap-rfc2284bis-09.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.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 August 14, 2004. This Internet-Draft will expire on August 15, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 26 skipping to change at page 2, line 26
2. Extensible Authentication Protocol (EAP) . . . . . . . . . . 8 2. Extensible Authentication Protocol (EAP) . . . . . . . . . . 8
2.1 Support for sequences . . . . . . . . . . . . . . . . 10 2.1 Support for sequences . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . 14 2.4 Peer-to-Peer Operation . . . . . . . . . . . . . . . . 14
3. Lower layer behavior . . . . . . . . . . . . . . . . . . . . 16 3. Lower layer behavior . . . . . . . . . . . . . . . . . . . . 16
3.1 Lower layer requirements . . . . . . . . . . . . . . . 16 3.1 Lower layer requirements . . . . . . . . . . . . . . . 16
3.2 EAP usage within PPP . . . . . . . . . . . . . . . . . 18 3.2 EAP usage within PPP . . . . . . . . . . . . . . . . . 18
3.2.1 PPP Configuration Option Format . . . . . . . . 19 3.2.1 PPP Configuration Option Format . . . . . . . . 19
3.3 EAP usage within IEEE 802 . . . . . . . . . . . . . . 19 3.3 EAP usage within IEEE 802 . . . . . . . . . . . . . . 19
3.4 Lower layer indications . . . . . . . . . . . . . . . 19 3.4 Lower layer indications . . . . . . . . . . . . . . . 20
4. EAP Packet format . . . . . . . . . . . . . . . . . . . . . 20 4. EAP Packet format . . . . . . . . . . . . . . . . . . . . . 20
4.1 Request and Response . . . . . . . . . . . . . . . . . 21 4.1 Request and Response . . . . . . . . . . . . . . . . . 21
4.2 Success and Failure . . . . . . . . . . . . . . . . . 24 4.2 Success and Failure . . . . . . . . . . . . . . . . . 24
4.3 Retransmission Behavior . . . . . . . . . . . . . . . 26 4.3 Retransmission Behavior . . . . . . . . . . . . . . . 26
5. Initial EAP Request/Response Types . . . . . . . . . . . . . 27 5. Initial EAP Request/Response Types . . . . . . . . . . . . . 27
5.1 Identity . . . . . . . . . . . . . . . . . . . . . . . 28 5.1 Identity . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Notification . . . . . . . . . . . . . . . . . . . . . 29 5.2 Notification . . . . . . . . . . . . . . . . . . . . . 29
5.3 Nak . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3 Nak . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1 Legacy Nak . . . . . . . . . . . . . . . . . . . 31 5.3.1 Legacy Nak . . . . . . . . . . . . . . . . . . . 31
5.3.2 Expanded Nak . . . . . . . . . . . . . . . . . . 32 5.3.2 Expanded Nak . . . . . . . . . . . . . . . . . . 32
5.4 MD5-Challenge . . . . . . . . . . . . . . . . . . . . 35 5.4 MD5-Challenge . . . . . . . . . . . . . . . . . . . . 35
5.5 One-Time Password (OTP) . . . . . . . . . . . . . . . 36 5.5 One-Time Password (OTP) . . . . . . . . . . . . . . . 36
5.6 Generic Token Card (GTC) . . . . . . . . . . . . . . . 38 5.6 Generic Token Card (GTC) . . . . . . . . . . . . . . . 37
5.7 Expanded Types . . . . . . . . . . . . . . . . . . . . 39 5.7 Expanded Types . . . . . . . . . . . . . . . . . . . . 39
5.8 Experimental . . . . . . . . . . . . . . . . . . . . . 40 5.8 Experimental . . . . . . . . . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40
6.1 Packet Codes . . . . . . . . . . . . . . . . . . . . . 42 6.1 Packet Codes . . . . . . . . . . . . . . . . . . . . . 41
6.2 Method Types . . . . . . . . . . . . . . . . . . . . . 42 6.2 Method Types . . . . . . . . . . . . . . . . . . . . . 41
7. Security Considerations . . . . . . . . . . . . . . . . . . 42 7. Security Considerations . . . . . . . . . . . . . . . . . . 42
7.1 Threat model . . . . . . . . . . . . . . . . . . . . . 42 7.1 Threat model . . . . . . . . . . . . . . . . . . . . . 42
7.2 Security claims . . . . . . . . . . . . . . . . . . . 44 7.2 Security claims . . . . . . . . . . . . . . . . . . . 43
7.2.1 Security claims terminology for EAP methods . . 45 7.2.1 Security claims terminology for EAP methods . . 44
7.3 Identity protection . . . . . . . . . . . . . . . . . 47 7.3 Identity protection . . . . . . . . . . . . . . . . . 46
7.4 Man-in-the-middle attacks . . . . . . . . . . . . . . 47 7.4 Man-in-the-middle attacks . . . . . . . . . . . . . . 47
7.5 Packet modification attacks . . . . . . . . . . . . . 48 7.5 Packet modification attacks . . . . . . . . . . . . . 48
7.6 Dictionary attacks . . . . . . . . . . . . . . . . . . 49 7.6 Dictionary attacks . . . . . . . . . . . . . . . . . . 49
7.7 Connection to an untrusted network . . . . . . . . . . 50 7.7 Connection to an untrusted network . . . . . . . . . . 49
7.8 Negotiation attacks . . . . . . . . . . . . . . . . . 50 7.8 Negotiation attacks . . . . . . . . . . . . . . . . . 50
7.9 Implementation idiosyncrasies . . . . . . . . . . . . 51 7.9 Implementation idiosyncrasies . . . . . . . . . . . . 50
7.10 Key derivation . . . . . . . . . . . . . . . . . . . . 51 7.10 Key derivation . . . . . . . . . . . . . . . . . . . . 51
7.11 Weak ciphersuites . . . . . . . . . . . . . . . . . . 53 7.11 Weak ciphersuites . . . . . . . . . . . . . . . . . . 53
7.12 Link layer . . . . . . . . . . . . . . . . . . . . . . 54 7.12 Link layer . . . . . . . . . . . . . . . . . . . . . . 53
7.13 Separation of authenticator and backend authentication 7.13 Separation of authenticator and backend authentication
server . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 server . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.14 Cleartext Passwords . . . . . . . . . . . . . . . . . 55 7.14 Cleartext Passwords . . . . . . . . . . . . . . . . . 55
7.15 Channel binding . . . . . . . . . . . . . . . . . . . 56 7.15 Channel binding . . . . . . . . . . . . . . . . . . . 55
7.16 Protected Result Indications . . . . . . . . . . . . . 57 7.16 Protected Result Indications . . . . . . . . . . . . . 56
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 59 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 58
Normative References . . . . . . . . . . . . . . . . . . . . 59 Normative References . . . . . . . . . . . . . . . . . . . . 59
Informative References . . . . . . . . . . . . . . . . . . . 60 Informative References . . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 63
A. Changes from RFC 2284 . . . . . . . . . . . . . . . . . . . 65 A. Changes from RFC 2284 . . . . . . . . . . . . . . . . . . . 64
B. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 66 B. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 66
Intellectual Property and Copyright Statements . . . . . . . 68 Intellectual Property and Copyright Statements . . . . . . . 67
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.
skipping to change at page 15, line 16 skipping to change at page 15, line 25
for each role. 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 "pass-through authenticator" operation. As [DIAM-EAP] only support "pass-through authenticator" operation. As
noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an
Access-Request encapsulating an EAP-Request, Success or Failure Access-Request encapsulating an EAP-Request, Success or Failure
packet with an Access-Reject. There is therefore no support for packet with an Access-Reject. There is therefore no support for
"pass-through peer" operation. "pass-through peer" operation.
Even where a method is used which supports mutual authentication and Even where a method is used which supports mutual authentication and
protected result indications, several considerations may dictate that result indications, several considerations may dictate that two EAP
two EAP authentications, (one in each direction) are required. These authentications, (one in each direction) are required. These
include: include:
[1] Support for bi-directional session key derivation in the lower [1] Support for bi-directional session key derivation in the lower
layer. Lower layers such as IEEE 802.11 may only support layer. Lower layers such as IEEE 802.11 may only support
uni-directional derivation and transport of transient session uni-directional derivation and transport of transient session
keys. For example, the group-key handshake defined in keys. For example, the group-key handshake defined in
[IEEE-802.11i] is uni-directional, since in IEEE 802.11 [IEEE-802.11i] is uni-directional, since in IEEE 802.11
infrastructure mode only the Access Point (AP) sends multicast/ infrastructure mode only the Access Point (AP) sends multicast/
broadcast traffic. In IEEE 802.11 ad hoc mode where either peer broadcast traffic. In IEEE 802.11 ad hoc mode where either peer
may send multicast/broadcast traffic, two uni-directional may send multicast/broadcast traffic, two uni-directional
skipping to change at page 15, line 39 skipping to change at page 15, line 48
design, this also implies the need for unicast key derivations design, this also implies the need for unicast key derivations
and EAP method exchanges to occur in each direction. and EAP method exchanges to occur in each direction.
[2] Support for tie-breaking in the lower layer. Lower layers such [2] Support for tie-breaking in the lower layer. Lower layers such
as IEEE 802.11 ad hoc do not support "tie breaking" wherein two as IEEE 802.11 ad hoc do not support "tie breaking" wherein two
hosts initiating authentication with each other will only go hosts initiating authentication with each other will only go
forward with a single authentication. This implies that even if forward with a single authentication. This implies that even if
802.11 were to support a bi-directional group-key handshake, then 802.11 were to support a bi-directional group-key handshake, then
two authentications, one in each direction, might still occur. two authentications, one in each direction, might still occur.
[3] Peer policy satisfaction. EAP methods may support protected [3] Peer policy satisfaction. EAP methods may support result
result indications, enabling the peer to indicate to the EAP indications, enabling the peer to indicate to the EAP server
server within the method that it successfully authenticated the within the method that it successfully authenticated the EAP
EAP server, as well as for the server to indicate that it has server, as well as for the server to indicate that it has
authenticated the peer. However, a pass-through authenticator authenticated the peer. However, a pass-through authenticator
will not be aware that the peer has accepted the credentials will not be aware that the peer has accepted the credentials
offered by the EAP server, unless this information is provided to offered by the EAP server, unless this information is provided to
the authenticator via the AAA protocol. The authenticator SHOULD the authenticator via the AAA protocol. The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet interpret the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated the as an indication that the peer has successfully authenticated the
server. server.
However, it is possible that the EAP peer's access policy was not However, it is possible that the EAP peer's access policy was not
satisfied during the initial EAP exchange, even though mutual satisfied during the initial EAP exchange, even though mutual
skipping to change at page 24, line 47 skipping to change at page 25, line 14
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 method-specific result indications. After the implement result indications. After the authenticator sends a
authenticator sends a method-specific failure indication to the failure result indication to the peer, regardless of the response
peer, regardless of the response from the peer, it MUST from the peer, it MUST subsequently send a Failure packet. After
subsequently send a Failure packet. After the authenticator sends the authenticator sends a success result indication to the peer,
a method-specific success indication to the peer, and receives a and receives a success result indication from the peer, it MUST
method-specific success indication from the peer, it MUST
subsequently send a Success packet. subsequently send a Success 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 failure result indication, or the
indication, or the peer decides that it does not want to continue peer decides that it does not want to continue the conversation,
the conversation, possibly after sending a method-specific failure possibly after sending a failure result indication), the peer MUST
indication), the peer MUST terminate the conversation and indicate terminate the conversation and indicate failure to the lower
failure to the lower layer. The peer MUST silently discard layer. The peer MUST silently discard Success packets and MAY
Success packets and MAY silently discard Failure packets. As a silently discard Failure packets. As a result, loss of a Failure
result, loss of a Failure packet need not result in a timeout. packet need not result in a timeout.
On the peer, after protected successful result indications have On the peer, after success result indications have been exchanged
been exchanged by both sides, a Failure packet MUST be silently by both sides, a Failure packet MUST be silently discarded. The
discarded. The peer MAY, in the event that an EAP Success is not peer MAY, in the event that an EAP Success is not received,
received, conclude that the EAP Success packet was lost and that conclude that the EAP Success packet was lost and that
authentication concluded successfully. authentication concluded successfully.
If the authenticator has not sent a method-specific result If the authenticator has not sent a result indication, and the
indication, and the peer is willing to continue the conversation, peer is willing to continue the conversation, once the method
once the method completes the peer waits for a Success or Failure completes the peer waits for a Success or Failure packet and MUST
packet and MUST NOT silently discard either of them. In the event NOT silently discard either of them. In the event that neither a
that neither a Success nor Failure packet is received, the peer Success nor Failure packet is received, the peer SHOULD terminate
SHOULD terminate the conversation to avoid lengthy timeouts in the conversation to avoid lengthy timeouts in case the lost packet
case the lost packet was an EAP Failure. was an EAP Failure.
If the peer attempts to authenticate to the authenticator and If the peer attempts to authenticate to the authenticator and
fails to do so, the authenticator MUST send a Failure packet and fails to do so, the authenticator MUST send a Failure packet and
MUST NOT grant access by sending a Success packet. However, an MUST NOT grant access by sending a Success packet. However, an
authenticator MAY omit having the peer authenticate to it in authenticator MAY omit having the peer authenticate to it in
situations where limited access is offered (e.g., guest access). situations where limited access is offered (e.g., guest access).
In this case the authenticator MUST send a Success packet. In this case the authenticator MUST send a Success packet.
Where the peer authenticates successfully to the authenticator, Where the peer authenticates successfully to the authenticator,
but the authenticator does not send a method-specific result but the authenticator does not send a result indication, the
indication the authenticator MAY deny access by sending a Failure authenticator MAY deny access by sending a Failure packet where
packet where the peer is not currently authorized for network the peer is not currently authorized for network access.
access.
A summary of the Success and Failure packet format is shown below. A summary of the Success and Failure 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 29, line 45 skipping to change at page 30, line 18
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
Protected result ind.: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: 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
skipping to change at page 31, line 18 skipping to change at page 31, line 34
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
Protected result ind.: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: No Channel binding: No
5.3 Nak 5.3 Nak
5.3.1 Legacy Nak 5.3.1 Legacy Nak
Description Description
skipping to change at page 32, line 42 skipping to change at page 33, line 18
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
Protected result ind.: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: 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
in Expanded Type format. Type zero (0) is used to indicate that in Expanded Type format. Type zero (0) is used to indicate that
the sender has no viable alternatives. The general format of the the sender has no viable alternatives. The general format of the
Expanded Type is described in Section 5.7. Expanded Type is described in Section 5.7.
skipping to change at page 35, line 18 skipping to change at page 35, line 34
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
Protected result ind.: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: 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
skipping to change at page 36, line 43 skipping to change at page 37, line 18
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
Protected result ind.: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: 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
(Type 254). The Nak Response indicates the peer's desired (Type 254). The Nak Response indicates the peer's desired
authentication Type(s). The EAP OTP method is intended for use authentication Type(s). The EAP OTP method is intended for use
with the One-Time Password system only, and MUST NOT be used to with the One-Time Password system only, and MUST NOT be used to
skipping to change at page 37, line 47 skipping to change at page 38, line 19
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
Protected result ind.: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: 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
skipping to change at page 39, line 18 skipping to change at page 39, line 26
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
Protected result ind.: No
Session independence: N/A Session independence: N/A
Fragmentation: No Fragmentation: No
Channel binding: 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
skipping to change at page 44, line 19 skipping to change at page 44, line 26
method, EAP method specifications MUST include a Security Claims method, EAP method specifications MUST include a Security Claims
section including the following declarations: section including the following declarations:
[a] Mechanism. This is a statement of the authentication technology: [a] Mechanism. This is a statement of the authentication technology:
certificates, pre-shared keys, passwords, token cards, etc. certificates, pre-shared keys, passwords, token cards, etc.
[b] Security claims. This is a statement of the claimed security [b] Security claims. This is a statement of the claimed security
properties of the method, using terms defined in Section 7.2.1: properties of the method, using terms defined in Section 7.2.1:
mutual authentication, integrity protection, replay protection, mutual authentication, integrity protection, replay protection,
confidentiality, key derivation, dictionary attack resistance, confidentiality, key derivation, dictionary attack resistance,
fast reconnect, cryptographic binding, protected result fast reconnect, cryptographic binding. The Security Claims
indications. The Security Claims section of an EAP method section of an EAP method specification SHOULD provide
specification SHOULD provide justification for the claims that justification for the claims that are made. This can be
are made. This can be accomplished by including a proof in an accomplished by including a proof in an Appendix, or including a
Appendix, or including a reference to a proof. reference to a proof.
[c] Key strength. If the method derives keys, then the effective key [c] Key strength. If the method derives keys, then the effective key
strength MUST be estimated. This estimate is meant for potential strength MUST be estimated. This estimate is meant for potential
users of the method to determine if the keys produced are strong users of the method to determine if the keys produced are strong
enough for the intended application. enough for the intended application.
The effective key strength SHOULD be stated as number of bits, The effective key strength SHOULD be stated as number of bits,
defined as follows: If the effective key strength is N bits, the defined as follows: If the effective key strength is N bits, the
best currently known methods to recover the key (with best currently known methods to recover the key (with
non-negligible probability) require on average an effort non-negligible probability) require on average an effort
skipping to change at page 45, line 44 skipping to change at page 45, line 51
Integrity protection Integrity protection
This refers to providing data origin authentication and This refers to providing data origin authentication and
protection against unauthorized modification of information protection against unauthorized modification of information
for EAP packets (including EAP Requests and Responses). for EAP packets (including EAP Requests and Responses).
When making this claim, a method specification MUST When making this claim, a method specification MUST
describe the EAP packets and fields within the EAP packet describe the EAP packets and fields within the EAP packet
that are protected. that are protected.
Replay protection Replay protection
This refers to protection against replay of an EAP method This refers to protection against replay of an EAP method
or its messages, including method-specific success and or its messages, including success and failure result
failure indications. indications.
Confidentiality Confidentiality
This refers to encryption of EAP messages, including EAP This refers to encryption of EAP messages, including EAP
Requests and Responses, and method-specific success and Requests and Responses, and success and failure result
failure indications. A method making this claim MUST indications. A method making this claim MUST support
support identity protection (see Section 7.3). identity protection (see Section 7.3).
Key derivation Key derivation
This refers to the ability of the EAP method to derive This refers to the ability of the EAP method to derive
exportable keying material such as the Master Session Key exportable keying material such as the Master Session Key
(MSK), and Extended Master Session Key (EMSK). The MSK is (MSK), and Extended Master Session Key (EMSK). The MSK is
used only for further key derivation, not directly for used only for further key derivation, not directly for
protection of the EAP conversation or subsequent data. Use protection of the EAP conversation or subsequent data. Use
of the EMSK is reserved. of the EMSK is reserved.
Key strength Key strength
skipping to change at page 65, line 22 skipping to change at page 65, line 22
Appendix A. Changes from RFC 2284 Appendix A. Changes from RFC 2284
This section lists the major changes between [RFC2284] and this This section lists the major changes between [RFC2284] and this
document. Minor changes, including style, grammar, spelling and document. Minor changes, including style, grammar, spelling and
editorial changes are not mentioned here. editorial changes are not mentioned here.
o The Terminology section (Section 1.2) has been expanded, defining o The Terminology section (Section 1.2) has been expanded, defining
more concepts and giving more exact definitions. more concepts and giving more exact definitions.
o The concepts of Mutual Authentication, Key Derivation and o The concepts of Mutual Authentication, Key Derivation and Result
Protected Result Indications are introduced and discussed Indications are introduced and discussed throughout the document
throughout the document where appropriate. where appropriate.
o In Section 2, it is explicitly specified that more than one o In Section 2, it is explicitly specified that more than one
exchange of Request and Response packets may occur as part of the exchange of Request and Response packets may occur as part of the
EAP authentication exchange. How this may and may not be used is EAP authentication exchange. How this may and may not be used is
specified in detail in Section 2.1. specified in detail in Section 2.1.
o Also in Section 2, some requirements on the authenticator when o Also in Section 2, some requirements on the authenticator when
acting in pass-through mode has been made explicit. acting in pass-through mode has been made explicit.
o An EAP multiplexing model (Section 2.2) has been added, to o An EAP multiplexing model (Section 2.2) has been added, to
 End of changes. 34 change blocks. 
76 lines changed or deleted 69 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/