< draft-josefsson-pppext-eap-tls-eap-06.txt   draft-josefsson-pppext-eap-tls-eap-07.txt >
PPPEXT Working Group Ashwin Palekar
INTERNET-DRAFT Dan Simon
Category: Standards Track Microsoft Corporation
<draft-josefsson-pppext-eap-tls-eap-07.txt> Glen Zorn
26 October 2003 Joe Salowey
Hao Zhou
Cisco Systems
S. Josefsson
Exundo
PPPEXT Working Group Ashwin Palekar Protected EAP Protocol (PEAP) Version 2
INTERNET-DRAFT Dan Simon
Category: Standards Track Microsoft
<draft-josefsson-pppext-eap-tls-eap-06.txt> Glen Zorn
22 March 2003 Cisco
S. Josefsson
Extundo
Protected EAP Protocol (PEAP)
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering This document is an Internet-Draft and is in full conformance with all
Task Force (IETF), its areas, and its working groups. Note that provisions of Section 10 of RFC 2026.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are working documents of the Internet Engineering Task
months and may be updated, replaced, or obsoleted by other documents Force (IETF), its areas, and its working groups. Note that other groups
at any time. It is inappropriate to use Internet-Drafts as may also distribute working documents as Internet- Drafts.
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/ietf/1id-abstracts.txt and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of Internet-Draft Shadow Directories can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/ietf/1id-abstracts.txt
Copyright Notice The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright Notice
Abstract Copyright (C) The Internet Society (2003). All Rights Reserved.
The Extensible Authentication Protocol (EAP), defined in RFC 2284, Abstract
provides for support of multiple authentication methods. While EAP
was originally created for use with PPP, it has since been adopted
for use with IEEE 802.1X "Network Port Authentication".
Since its deployment, a number of weaknesses in EAP or some EAP The Extensible Authentication Protocol (EAP) provides for support of
protocols have become apparent. These include no per packet multiple authentication methods. This document defines the Protected
confidentiality and integrity protection; which results in lack of Extensible Authentication Protocol (PEAP) Version 2, which provides
protection to user identity, notification messages or EAP an encrypted and authenticated tunnel based on transport layer
negotiation; and sequencing of EAP methods. In addition, there is no security (TLS) that encapsulates EAP authentication mechanisms.
standardized mechanism for key exchange; no built-in support for PEAPv2 uses TLS to protect against rogue authenticators, protect
fragmentation and reassembly; no support for acknowledged against various attacks on the confidentiality and integrity of the
success/failure indications; and no support for fast reconnect. inner EAP method exchange and provide EAP peer identity privacy.
PEAPv2 also provides support for chaining multiple EAP mechanisms,
cryptographic binding between authentications performed by inner EAP
mechanisms and the tunnel, exchange of arbitrary parameters (TLVs),
optimized session resumption, and fragmentation and reassembly.
In addition, some EAP protocols (e.g. like EAP-MD5) are susceptible Table of Contents
to dictionary and brute force attacks; do not provide
confidentiality; do not support server authentication required to
prevent spoofing by rogue servers (gateways), and do not support the
generation of key strength required for 802.11i.
By wrapping the EAP protocol within TLS, Protected EAP (PEAP) 1. Introduction .......................................... 4
addresses these deficiencies in EAP or EAP protocols. EAP method(s) 1.1 Requirements language ........................... 6
running within PEAP are provided with built-in support for 1.2 Terminology ..................................... 6
1.3 Operational model ............................... 8
2. Protocol overview ..................................... 11
2.1 PEAPv2 Part 1 .................................. 11
2.2 PEAPv2 Part 2 .................................. 16
2.3 Error handling ................................. 19
2.4 Fragmentation .................................. 21
2.5 Key derivation ................................. 22
2.6 Ciphersuite negotiation ........................ 24
3. Detailed description of the PEAPv2 protocol .......... 25
3.1 PEAPv2 Packet Format ........................... 25
3.2 PEAPv2 Request Packet .......................... 26
3.3 PEAPv2 Response Packet ......................... 28
3.4 PEAPv2 Part 2 Packet Format ................... 29
4. EAP TLV method ....................................... 30
4.1 EAP-TLV Request packet ......................... 30
4.2 EAP-TLV Response packet ......,,................ 31
4.3 TLV format ..................................... 32
4.4 Result TLV ..................................... 33
4.5 NAK TLV ........................................ 34
4.6 Crypto-Binding TLV ............................. 35
4.7 Connection-Binding TLV ......................... 37
4.8 Vendor-Specific TLV ............................ 38
4.9 URI TLV ........................................ 39
4.10 EAP Payload TLV ................................ 40
4.11 Intermediate Result TLV ........................ 41
4.12 TLV Rules ...................................... 42
5. Security considerations .............................. 43
5.1 Authentication and integrity protection ........ 43
5.2 Method negotiation ............................. 44
5.3 TLS session cache handling ..................... 44
5.4 Certificate revocation ......................... 45
5.5 Separation of EAP server and authenticator ..... 46
5.6 Separation of PEAPv2 Part 1 and Part 2 Servers . 47
5.7 Identity verification .......................... 48
5.8 Man-in-the-middle attack protection ............ 50
5.9 Cleartext forgeries ............................ 50
5.10 TLS Ciphersuites ............................... 51
5.11 Denial of service attacks ...................... 51
5.12 Security Claims ................................ 52
Privacy of user identity. 6. IANA Considerations ................................. 53
Protection to individual EAP methods. For example, protection can 6.1 Definition of Terms ............................ 53
provide dictionary attack resistance to protocols susceptible to 6.2 Recommended Registration Policies .............. 53
that attack. 7. References .......................................... 53
Protected EAP notification. 7.1 Normative references ........................... 53
Protected sequencing of EAP methods. 7.2 Informative references ......................... 54
Protected negotiation. Appendix A - Examples ........................................ 56
Protected EAP header. Acknowledgments .............................................. 70
Protected exchange of parameters (TLVs) between client and server. Author's Addresses ........................................... 70
Standardized mechanism for key exchange. Intellectual Property Statement .............................. 71
Proven key derivation and management. Full Copyright Statement ..................................... 72
Session resumption. 1. Introduction
Server authentication.
Protected Acknowledged and result exchange.
Fragmentation and reassembly.
Table of Contents The Extensible Authentication Protocol (EAP), defined in
[RFC2284bis], provides for support of multiple authentication
methods. EAP was developed for use on wired networks, where physical
security was presumed. EAP over PPP, defined in [RFC2284bis], is
typically deployed with leased lines or modem connections, requiring
an attacker to gain access to the telephone network in order to snoop
on the conversation or inject packets. [IEEE8021X] defines EAP over
IEEE 802 local area networks(EAPOL), presuming the existence of
switched media; in order to snoop or inject packets, an attacker
would need to gain administrative access to the switch. Due to the
presumption of physical security, facilities for protection of the
EAP conversation were not provided. Where an attacker can easily gain
access to the medium (such as on a wireless network or where EAP is
run over IP), the presumption of physical security is no longer
valid.
Protected EAP Protocol (PEAP)......................................1 Since its deployment, a number of weaknesses in EAP framework have
1. Introduction.................................................3 become apparent. These include lack of:
1.1. Requirements language.......................................5
1.2. Terminology.................................................5
1.3. Operational model...........................................6
2. Protocol overview............................................7
2.1. PEAP Part 1.................................................8
2.2. PEAP Part 2................................................11
2.3. Version negotiation........................................12
2.4. Termination................................................12
2.5. Error handling.............................................14
2.6. Retry behavior.............................................15
2.7. Session resumption.........................................15
2.8. Fragmentation..............................................16
2.9. Key derivation.............................................17
2.10. Ciphersuite negotiation....................................18
3. Detailed description of the PEAP protocol...................18
3.1. PEAP Packet Format.........................................18
3.2. PEAP Request Packet........................................20
4. EAP TLV method..............................................23
4.1. Protected success/failure..................................23
4.2. EAP-TLV Request Packet.....................................25
4.3. EAP-TLV Response Packet....................................25
4.4. EAP-TLV TLV format.........................................26
4.5. Result TLV.................................................27
4.6. NAK TLV....................................................28
5. Security Considerations.....................................28
5.1. Authentication and integrity protection....................28
5.2. Method negotiation.........................................29
5.3. TLS session cache handling.................................29
5.4. Certificate revocation.....................................30
5.5. Separation of the EAP server and the authenticator.........31
5.6. Separation of PEAP Part 1 and Part 2 Servers...............31
5.7. Identity verification......................................32
5.8. Man-in-the-middle protection...............................34
6. IANA Considerations.........................................35
6.1. Definition of Terms........................................35
6.2. Recommended Registration Policies..........................35
7. Normative references........................................35
8. Informative references......................................36
9. Appendix A - Examples.......................................37
10. and Contributions..........................................49
11. Intellectual Property Statement.............................50
12. Full Copyright Statement....................................51
1. Introduction identity protection
protected method negotiation
protected notification messages
protected termination messages
support for sequences of EAP methods
support for fragmentation and reassembly
support for a generic way to exchange arbitrary
parameters in a secure channel
support for generic optimized re-authentication
The Extensible Authentication Protocol (EAP), described in In addition many EAP methods lack the following features:
[RFC2284], provides a standard mechanism for support of multiple
authentication methods. Through the use of EAP, support for a
number of authentication schemes may be added, including smart
cards, Kerberos, Public Key, One Time Passwords, and others.
EAP was developed or use on wired networks, where physical security mutual authentication
was presumed. EAP over PPP, defined in [RFC2284], is typically resistance to dictionary attacks
deployed with leased lines or modem connections, requiring an adequate key generation
attacker to gain access to the telephone network in order to snoop
on the conversation or inject packets. [IEEE8021X] defines EAP over
IEEE 802 local area networks(EAPOL), presuming the existence of
switched media; in order to snoop or inject packets, an attacker
would need to gain administrative access to
the switch. Due to the presumption of physical security, facilities
for protection of the EAP conversation were not provided.
Where an attacker can easily gain access to the medium (such as on a By wrapping the EAP protocol within TLS, Protected EAP (PEAP) Version
wireless network or where EAP is run over IP), the presumption of 2 addresses these deficiencies in EAP or EAP methods. TLS provides
physical security is no longer valid. Since the EAP method per-packet encryption, authentication, integrity and replay
negotiation is unprotected, an attacker can inject packets in order protection of the EAP conversation. Benefits of PEAP Version 2
to cause the negotiation of a method with lesser security. Denial of include:
service attacks are also possible. Since the initial EAP Identity
Request/Response exchange is sent in the clear, an attacker snooping
on the conversation can collect user identities for use in
subsequent attacks.
By initially negotiating a TLS channel, and then conducting the EAP Identity protection
conversation within it, PEAP provides for per-packet encryption, By encrypting the identity exchange, and allowing client
authentication, integrity and replay protection of the EAP certificates to be provided after negotiation of the TLS channel,
conversation. PEAPv2 provides for identity protection.
Benefits include: Dictionary attack resistance
By conducting the EAP conversation within a TLS channel, PEAPv2
protects EAP methods that might be subject to an offline dictionary
attack were they to be conducted in the clear.
Identity protection Protected negotiation
By encrypting the identity exchange, and allowing client Since within PEAPv2, the EAP conversation is authenticated,
credentials to be provided after negotiation of the TLS channel, integrity and replay protected on a per-packet basis, the EAP
PEAP provides for identity protection. method negotiation that occurs within PEAPv2 is protected, as are
error messages sent within the TLS channel (TLS alerts or EAP
Notification packets). EAP negotiation outside of PEAPv2 is not
protected.
Dictionary attack resistance Header protection
By conducting the EAP conversation within a TLS channel, PEAP Within PEAPv2, the EAP conversation is conducted within a TLS
protects EAP methods that might be subject to an offline channel. As a result, the Type-Data field within PEAPv2 (including
dictionary attack were they to be conducted in the clear. the EAP header of the EAP method within PEAPv2) is protected
against modification. However, the EAP header of PEAPv2 itself is
not protected against modification, including the Code, Identifier
and Type fields.
Protected negotiation Protected termination
Since within PEAP, the EAP conversation is authenticated, By sending success/failure indications within the TLS channel,
integrity and replay protected on a per-packet basis, the EAP PEAPv2 provides support for protected termination of the EAP
method negotiation that occurs within PEAP is protected, as are conversation. This prevents an attacker from carrying out denial
error messages sent within the TLS channel (TLS alerts or EAP of service attacks by spoofing EAP Failure messages, or fooling the
Notification packets). EAP peer into accepting a rogue NAS, by spoofing EAP Success
messages.
Header protection Fragmentation and Reassembly
Within PEAP, the EAP conversation is conducted within a TLS Since EAP does not include support for fragmentation and
channel. As a result, the EAP header is protected against reassembly, individual methods need to include this capability. By
modification. including support for fragmentation and reassembly within PEAPv2,
methods leveraging PEAPv2 do not need to support this on their own.
Protected termination Fast reconnect
By sending success/failure indications within the TLS channel, Where EAP is used for authentication in wireless networks, the
PEAP provides support for protected termination of the EAP authentication latency is a concern. As a result, it is valuable
conversation. This prevents an attacker from carrying out denial to be able to do a quick re-authentication on roaming between
of service attacks by spoofing EAP Failure messages, or fooling access points. PEAPv2 supports this capability by leveraging the
the EAP peer into accepting a rogue NAS, by spoofing EAP Success TLS session resumption facility, and any EAP method running under
messages. PEAPv2 can take advantage of it.
Fragmentation and Reassembly Standard key establishment
Since EAP does not include support for fragmentation and In order to provide keying material for a wide range of link layer
reassembly, individual methods need to include this capability. ciphersuites, EAP methods need to provide keying material. Key
By including support for fragmentation and reassembly within derivation is complex. PEAPv2 provides for key establishment by
PEAP,methods leveraging PEAP do not need to support this on their relying on the widely implemented and well-reviewed TLS [RFC2246]
own. key derivation mechanism. PEAPv2 provides keying material for any
EAP method running within it. If EAP methods will also be deployed
without external protection (e.g PEAPv2 or IPSec), then the EAP
methods should follow the guidelines in section 6.8 to prevent the
man-in-the-middle attacks.
Fast reconnect Sequencing of multiple EAP methods
Where EAP is used for authentication in wireless networks, the In order to enhance security, PEAPv2 implementations may choose to
authentication latency is a concern. As a result, it is valuable provide multi-factor authentication that validates different
to be able to do a quick re-authentication on roaming between identities (for example user and machine identities) and/or uses
access points. PEAP supports this capability by leveraging the different credentials of the same or different identities of the
TLS session resumption facility, and any EAP method running under peer (e.g. user password and machine cert). PEAPv2 provides a
PEAP can take advantage of it. standard way to chain different types of authentication mechanisms
supporting different types of credentials.
Proven and Method independent key management Protected exchange of arbitrary parameters (TLVs)
In order to provide keying material for a wide range of link Type-Length-Value (TLV) tuples provide a way to exchange arbitrary
layer ciphersuites, EAP methods need to provide a key hierarchy information between peer and EAP server within a secure channel.
generating authentication and encryption keys, as well as This information can include signaling parameters for EAP protocol,
initialization vectors. Development of a secure key hierarchy is provisioning parameters, media specific and environment specific
complex, and not easy to generalize for all EAP methods. By data, and authorization parameters. The advantage of using PEAP
relying on the well-reviewed TLS [RFC2246] key derivation method, TLVs is that every EAP method does not have to be modified.
PEAP provides the required keying material for any EAP method
running within it. This frees EAP method developments from
creating keying material with key strength required for 802.11i
wireless LAN. If EAP methods will also be deployed without the
protection of PEAP or IPSEC, then the EAP methods should derive
key material of sufficient strength to prevent a Man-in-the-
middle attack described in the compound binding draft
[CompoundBinding].
1.1. Requirements language 1.1. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", In this document, the key words "MAY", "MUST, "MUST NOT",
"OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be
be interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
Access Point Access Point
A Network Access Server implementing 802.11. A Network Access Server implementing 802.11.
Authenticator Authenticator
The end of the link requiring the authentication. The end of the link initiating EAP authentication. This term is
also used in [IEEE8021X] and has the same meaning in this document.
Backend Authentication Server Backend Authentication Server
An Authentication Server is an entity that provides an A backend authentication server is an entity that provides an
Authentication Service to an NAS. This service verifies from authentication service to an Authenticator. When used, this server
the credentials provided by the peer, the claim of identity typically executes EAP methods for the Authenticator. This
made by the peer. terminology is also used in [IEEE8021X].
EAP server EAP server
The EAP server is the entity that terminates the EAP The entity that terminates the EAP authentication method with the
conversation with the peer. The EAP server may reside on the peer. In the case where no backend authentication server is used,
NAS, or alternatively within a backend authentication server. the EAP server is part of the Authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server.
Link layer ciphersuite Link layer ciphersuite
The ciphersuite negotiated for use at the link layer. The ciphersuite negotiated for use at the link layer.
Master key NAS Short for "Network Access Server".
The key derived between the EAP client and EAP server during
the EAP authentication process.
Master session key Peer The end of the link that responds to the authenticator. In
The keys derived from the master key are subsequently [IEEE8021X], this end is known as the Supplicant.
used in generation of the transient session keys for
authentication, encryption, binding exchange, and
IV-generation.
NAS Short for "Network Access Server". TLS Ciphersuite
The ciphersuite negotiated for protection of the PEAPv2 Part 2
conversation.
Peer EAP Master key (MK)
The other end of the point-to-point link (PPP), A key derived between the PEAPv2 client and server during the
point-to-point LAN segment (IEEE 802.1X) or 802.11 authentication conversation, and that is kept local to PEAPv2 and
wireless link, which is being authenticated by the NAS. not exported or made available to a third party.
In IEEE 802.1X, this end is known as the Supplicant.
TLS Ciphersuite Master Session Key (MSK)
The ciphersuite negotiated for protection of the PEAP Part 2 Keying material (64 octets) that is derived between the PEAPv2
conversation. client and server and exported by the PEAPv2 implementation.
Transient session keys AAA-Key
The transient session keys are derived from the master session Where a backend authentication server is present, acting as an EAP
keys, and are of the appropriate size and type for use with server, keying material known as the AAA-Key is transported from
the chosen link layer ciphersuite. the authentication server to the authenticator. The AAA-Key is
used by the EAP peer and authenticator in the derivation of
Transient Session Keys (TSKs) for the ciphersuite negotiated
between the EAP peer and authenticator. As a result, the AAA-Key
is typically known by all parties in the EAP exchange: the peer,
authenticator and the authentication server (if present).
1.3. Operational model Extended Master Session Key (EMSK)
Additional keying material (64 octets) derived between the EAP
client and server that is exported by the EAP method. The EMSK is
known only to the EAP peer and server and is not provided to a
third party.
Initialization Vector (IV)
A 64 octet quantity, suitable for use in an initialization vector
field, that is derived between the EAP client and server. Since
the IV is a known value in PEAPv2, it cannot be used by itself for
computation of any quantity that needs to remain secret. As a
result, PEAPv2 implementations are not required to generate it.
Pairwise Master Key (PMK)
The AAA-Key is divided into two halves, the "Peer to Authenticator
Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer
Encryption Key" (Enc-SEND-Key) (reception is defined from the point
of view of the authenticator). Within [IEEE80211i] Octets 0-31 of
the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
(PMK).
Transient EAP Keys (TEKs)
Session keys which are used to establish a protected channel
between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the
EAP conversation. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to subsequently
protect data sent between the EAP peer and Authenticator.
TLV TLV standards for objects of format Type-Length-Value. The TLV
format is defined in Section 4 of this document.
1.3. Operational model
In EAP, the EAP server may be implemented either within a Network In EAP, the EAP server may be implemented either within a Network
Access Server (NAS) or on a backend authentication server. Where the Access Server (NAS) or on a backend authentication server. Where the
EAP server resides on a NAS, the NAS is required to implement the EAP server resides on a NAS, the NAS is required to implement the
desired EAP methods, and therefore needs to be upgraded to support desired EAP methods, and therefore needs to be upgraded to support
each new EAP method. each new EAP method.
One of the goals of EAP is to enable development of new One of the goals of EAP is to enable development of new
authentication methods without requiring deployment of new code on authentication methods without requiring deployment of new code on
the Network Access Server (NAS). Where a backend authentication the Network Access Server (NAS). Where a backend authentication
server is deployed, the NAS acts as a "passthrough" and need not server is deployed, the NAS acts as a "passthrough" and need not
understand specific EAP methods. understand specific EAP methods.
This allows new EAP methods to be deployed on the EAP peer and This allows new EAP methods to be deployed on the EAP peer and
backend authentication server, without the need to upgrade code backend authentication server, without the need to upgrade code
residing on the NAS. residing on the NAS.
Figure 1 describes the relationship between the EAP peer, NAS and Figure 1 describes the relationship between the EAP peer, NAS and EAP
EAP server. As described in the figure, the EAP conversation occurs server. As described in the figure, the EAP conversation occurs
between the EAP peer and EAP server, "passing through" the NAS. In between the EAP peer and EAP server, "passing through" the NAS. In
order for the conversation to proceed in the case where the NAS and order for the conversation to proceed in the case where the NAS and
EAP server reside on separate machines, the NAS and EAP server need EAP server reside on separate machines, the NAS and EAP server need
to establish trust beforehand. to establish trust beforehand.
In PEAP, the conversation between the EAP peer and the EAP server is
encrypted, authenticated, integrity and replay protected within a
TLS channel, and mutual authentication is required between the EAP
peer and the EAP server.
As a result, where the NAS acts as a "passthrough" it does not have
knowledge of the TLS master secret derived between the EAP Peer and
the EAP server. In order to provide keying material for link-layer
ciphersuites, the NAS obtains the master session keys, which are
derived from the TLS master secret via a one-way function. This
enables the NAS and EAP peer to derive keys suitable for encrypting,
authenticating and integrity protecting session data. However, the
NAS cannot decrypt the PEAP conversation or spoof session
resumption, since this requires knowledge of the TLS master secret.
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | | | | | |
| Link | | Link | | Link | | Link |
| Layer | | Layer | | Layer | | Layer |
| Cipher- | | Cipher- | | Cipher- | | Cipher- |
| Suite | | Suite | | Suite | | Suite |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^ ^ ^
| | | |
skipping to change at page 7, line 47 skipping to change at page 10, line 5
| | | | | | | |
| | | | | | | |
| EAP | | EAP | | EAP | | EAP |
| Method | | Method | | Method | | Method |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 1 - Relationship between EAP client, backend authentication Figure 1 - Relationship between EAP client, backend authentication
server and NAS. server and NAS.
2. Protocol overview In PEAPv2, the conversation between the EAP peer and the EAP server
is encrypted, authenticated, integrity and replay protected within a
TLS channel.
Protected EAP (PEAP) is comprised of a two-part conversation: As a result, where the NAS acts as a "passthrough" it does not have
knowledge of the TLS master secret derived between the peer and the
EAP server. In order to provide keying material for link-layer
ciphersuites, the NAS obtains the master session key, which is
derived from a one-way function of the TLS master secret as well as
keying material provided by EAP methods protected within a TLS
channel. This enables the NAS and EAP peer to subsequently derive
transient session keys suitable for encrypting, authenticating and
integrity protecting session data. However, the NAS cannot decrypt
the PEAPv2 conversation or spoof session resumption, since this
requires knowledge of the TLS master secret.
[1] In Part 1, a TLS session is negotiated, with server 1.3.1. Sequences
authenticating to the client and optionally the client to the
server. The negotiated key is then used to encrypt the rest of
the conversation.
[2] In Part 2, within the TLS session, a complete EAP conversation EAP [RFC2284bis] prohibits use of multiple authentication methods
is carried out, unless part 1 provided client authentication. within a single EAP conversation, except when tunneled methods such
as PEAPv2 are used. This restriction was imposed in order to limit
vulnerabilities to man-in-the-middle attacks as well as to ensure
compatibility with existing EAP implementations.
In the next two sections, we provide an overview of each of the Within PEAP these concerns are addressed since PEAPv2 includes
parts of the PEAP conversation. support for cryptographic binding to address man-in-the-middle
attacks, as well as version negotiation so as to enable backward
compatibility with prior versions of PEAP.
2.1. PEAP Part 1 Within this document, the term "sequence" refers to a series of EAP
authentication methods run in sequence. The methods need not be
distinct - for example, EAP-TLS could be run initially with machine
credentials followed by the same protocol authenticating with user
credentials.
PEAPv2 supports two types of sequences:
[1] Serial authentication. Initiating additional EAP method(s) after a
first successful authentication. In this case the sequence is
successful if each of the EAP authentication methods completes
successfully. For example, successful authentication might require
a successful machine authentication followed by a successful user
authentication.
[2] Parallel authentication. Initiating an alternative EAP method after
failure of one or more initial methods. In this case the overall
authentication is successful if any of the methods is successful.
For example, if machine authentication fails, then user
authentication can be attempted.
2. Protocol overview
Protected EAP (PEAP) Version 2 is comprised of a two-part
conversation:
[1] In Part 1, a TLS session is negotiated, with server authenticating
to the client and optionally the client to the server. The
negotiated key is then used to encrypt the rest of the
conversation.
[2] In Part 2, within the TLS session, zero or more EAP methods are
carried out. Part 2 completes with a success/failure indication
protected by the TLS session or a protected error (TLS alert).
In the next two sections, we provide an overview of each of the parts
of the PEAPv2 conversation.
2.1. PEAPv2 Part 1
2.1.1. Initial identity exchange
The PEAP conversation typically begins with an optional identity The PEAP conversation typically begins with an optional identity
exchange. The authenticator will typically send an EAP- exchange. The authenticator will typically send an EAP-
Request/Identity packet to the peer, and the peer will respond with Request/Identity packet to the peer, and the peer will respond with
an EAP-Response/Identity packet to the authenticator, containing the an EAP-Response/Identity packet to the authenticator.
peer's EAP-ID. Since the initial identity exchange is used
primarily to route the EAP conversation to the EAP server, if the The initial identity exchange is used primarily to route the EAP
EAP server is known in advance (such as when all users authenticate conversation to the EAP server. Since the initial identity exchange
against the same backend server infrastructure and roaming is not is in the clear, the peer MAY decide to place a routing realm instead
supported), or if the identity is otherwise determined (such as from of its real name in the EAP-Response/Identity. The real identity of
the dialing phone number or client MAC address), then the identity the peer can be established later in PEAPv2 part 2.
exchange MAY be omitted.
If the EAP server is known in advance (such as when all users
authenticate against the same backend server infrastructure and
roaming is not supported), or if the identity is otherwise determined
(such as from the dialing phone number or client MAC address), then
the EAP-Request/Response-identity exchange MAY be omitted.
Once the optional initial Identity Request/Response exchange is Once the optional initial Identity Request/Response exchange is
completed, while nominally the EAP conversation occurs between the completed, while nominally the EAP conversation occurs between the
authenticator and the peer, the authenticator MAY act as a authenticator and the peer, the authenticator MAY act as a
passthrough device, with the EAP packets received from the peer passthrough device, with the EAP packets received from the peer being
being encapsulated for transmission to a backend authentication encapsulated for transmission to a backend authentication server.
server. However, PEAP does not require a backend authentication However, PEAP does not require a backend authentication server; if
server; if the authenticator implements PEAP and is provisioned with the authenticator implements PEAP, then it can authenticate local
the appropriate certificates, then it can authenticate local users. users.
In the discussion that follows, we will use the term "EAP server" to In the discussion that follows, we will use the term "EAP server" to
denote the ultimate endpoint conversing with the peer. denote the ultimate endpoint conversing with the peer.
2.1.2. TLS Session Establishment
In this section, the protocol is described assuming a certificate
based ciphersuite is negotiated in TLS. The conversation may
slightly differ if other TLS ciphersuites are used.
Once having received the peer's Identity, and determined that PEAP Once having received the peer's Identity, and determined that PEAP
authentication is to occur, the EAP server MUST respond with a authentication is to occur, the EAP server MUST respond with a
PEAP/Start packet, which is an EAP-Request packet with EAP- PEAP/Start packet, which is an EAP-Request packet with EAP-Type=PEAP,
Type=PEAP,the Start (S) bit set, and no data. Assuming that the the Start (S) bit set, the PEAP version as specified in Section
peer supports PEAP, the PEAP conversation will then begin, with the 2.1.5, and no data. Assuming that the peer supports PEAP, the PEAP
peer sending an EAP-Response packet with EAP-Type=PEAP. conversation will then begin, with the peer sending an EAP-Response
packet with EAP-Type=PEAP.
The data field of the EAP-Response packet will encapsulate one or The data field of the EAP-Response packet will encapsulate one or
more TLS records in TLS record layer format, containing a TLS more TLS records in TLS record layer format, containing a TLS
client_hello handshake message. The current cipher spec for the TLS client_hello handshake message. The current cipher spec for the TLS
records will be TLS_NULL_WITH_NULL_NULL and null compression. This records will be TLS_NULL_WITH_NULL_NULL and null compression. This
current cipher spec remains the same until the change_cipher_spec current cipher spec remains the same until the change_cipher_spec
message signals that subsequent records will have the negotiated message signals that subsequent records will have the negotiated
attributes for the remainder of the handshake. attributes for the remainder of the handshake.
The client_hello message contains the client's TLS version number, a The client_hello message contains the client's TLS version number, a
sessionId, a random number, and a set of TLS ciphersuites supported sessionId, a random number, and a set of TLS ciphersuites supported
by the client. The version offered by the client MUST correspond to by the client. The version offered by the client MUST correspond to
TLS v1.0 or later. TLS v1.0 or later.
The EAP server will then respond with an EAP-Request packet with The EAP server will then respond with an EAP-Request packet with EAP-
EAP-Type=PEAP. The data field of this packet will encapsulate one or Type=PEAP. The data field of this packet will encapsulate one or
more TLS records. These will contain a TLS server_hello handshake more TLS records. These will contain a TLS server_hello handshake
message, possibly followed by TLS certificate, server_key_exchange, message, possibly followed by TLS certificate, server_key_exchange,
certificate_request, server_hello_done and/or finished handshake certificate_request, server_hello_done and/or finished handshake
messages, and/or a TLS change_cipher_spec message. messages, and/or a TLS change_cipher_spec message.
Since after the TLS session is established, another complete EAP Since after the TLS session is established, another complete EAP
negotiation will occur and the peer will authenticate using a negotiation will occur and the peer will authenticate using a
secondary mechanism, with PEAP the client need not authenticate as secondary mechanism, with PEAPv2 the client need not authenticate as
part of TLS session establishment. As a result, although the EAP- part of TLS session establishment. As a result, although the EAP-
Request packet sent by the EAP Server MAY contain a Request packet sent by the EAP Server MAY contain a
certificate_request message, this is not required. certificate_request message, this is not required.
The certificate_request message indicates that the server desires The certificate_request message indicates that the server desires the
the client to authenticate itself via public key. Typically when the client to authenticate itself via public key. It is valid for the
EAP server sends a certificate_request message, the intent is to server to request a certificate in the server_hello and for the
complete the PEAP authentication without requiring negotiation of an client refuse to provide one.
additional EAP method. However, it is valid for the server to
request a certificate in the server_hello and for the client refuse
to provide one. In this case, the EAP server MUST require that PEAP
Part 2 be completed.
Note that since TLS client certificates are sent in the clear, if Note that since TLS client certificates are sent in the clear, if
identity protection is required, then it is possible for the TLS identity protection is required, then it is possible for the TLS
authentication to be re-negotiated after the first server authentication to be re-negotiated after the first server
authentication. To accomplish this, the server will typically not authentication. To accomplish this, the server will typically not
request a certificate in the server_hello, then after the request a certificate in the server_hello, then after the
server_finished message is sent, and before PEAP part 2, the server server_finished message is sent, and before PEAP part 2, the server
MAY send a TLS hello_request. This allows the client to perform MAY send a TLS hello_request. This allows the client to perform
client authentication by sending a client_hello if it wants to, or client authentication by sending a client_hello if it wants to, or
send a no_renegotiation alert to the server indicating that it wants send a no_renegotiation alert to the server indicating that it wants
to continue with PEAP part 2 instead. Assuming that the client to continue with PEAP part 2 instead. Assuming that the client
permits renegotiation by sending a client_hello, then the server permits renegotiation by sending a client_hello, then the server will
will respond with server_hello, a certificate and respond with server_hello, a certificate and certificate_request
certificate_request messages. The client replies with certificate, messages. The client replies with certificate, client_key_exchange
client_key_exchange and certificate_verify messages. Since this re- and certificate_verify messages. Since this re-negotiation occurs
negotiation occurs within the encrypted TLS channel, it does not within the encrypted TLS channel, it does not reveal client
reveal client certificate details. certificate details.
The server_hello handshake message contains a TLS version number, The server_hello handshake message contains a TLS version number,
another random number, a sessionId, and a TLS ciphersuite. The another random number, a sessionId, and a TLS ciphersuite. The
version offered by the server MUST correspond to TLS v1.0 or later. version offered by the server MUST correspond to TLS v1.0 or later.
In order to provide confidentiality, integrity and replay
protection, and authentication, the negotiated TLS ciphersuite MUST
provide all of these security services.
If the client's sessionId is null or unrecognized by the server, the If the client's sessionId is null or unrecognized by the server, the
server MUST choose the sessionId to establish a new session; server MUST choose the sessionId to establish a new session;
otherwise, the sessionId will match that offered by the client, otherwise, the sessionId will match that offered by the client,
indicating a resumption of the previously established session with indicating a resumption of the previously established session with
that sessionId. The server will also choose a TLS ciphersuite from that sessionId. The server will also choose a TLS ciphersuite from
those offered by the client; if the session matches the client's, those offered by the client; if the session matches the client's,
then the TLS ciphersuite MUST match the one negotiated during the then the TLS ciphersuite MUST match the one negotiated during the
handshake protocol execution that established the session. handshake protocol execution that established the session.
PEAP implementations need not necessarily support all TLS PEAP implementations need not necessarily support all TLS
ciphersuites listed in [RFC2246]. Not all TLS ciphersuites are ciphersuites listed in [RFC2246]. Not all TLS ciphersuites are
supported by available TLS tool kits and licenses may be required to supported by available TLS tool kits and licenses may be required to
support some TLS ciphersuites (e.g. TLS ciphersuites utilizing the support some TLS ciphersuites (e.g. TLS ciphersuites utilizing the
IDEA encryption algorithm). To ensure interoperability, PEAP peers IDEA encryption algorithm).
and Authenticators MUST support and be able to negotiate the
following TLS ciphersuites: To ensure interoperability, PEAP peers and EAP servers MUST support
and be able to negotiate the following TLS ciphersuites:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
In addition, PEAP peers and EAP servers SHOULD support and be able to
negotiate the following TLS ciphersuites.
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA (FIPS compliant)
TLS as described in [RFC2246] supports compression as well as TLS as described in [RFC2246] supports compression as well as
ciphersuite negotiation. Therefore during the PEAP Part 1 ciphersuite negotiation. Therefore during the PEAPv2 Part 1
conversation the EAP endpoints MAY request or negotiate TLS conversation the EAP endpoints MAY request or negotiate TLS
compression. compression.
2.1.3. Full handshake
If the EAP server is not resuming a previously established session, If the EAP server is not resuming a previously established session,
then it MUST include a TLS server_certificate handshake message, and and if a ciphersuite based on certificates is used, then it MUST
a server_hello_done handshake message MUST be the last handshake include a TLS server_certificate handshake message, and a
server_hello_done handshake message MUST be the last handshake
message encapsulated in this EAP-Request packet. message encapsulated in this EAP-Request packet.
The certificate message contains a public key certificate chain for The certificate message contains a public key certificate chain for
either a key exchange public key (such as an RSA or Diffie-Hellman either a key exchange public key (such as an RSA or Diffie-Hellman
key exchange public key) or a signature public key (such as an RSA key exchange public key) or a signature public key (such as an RSA or
or DSS signature public key). In the latter case, a TLS DSS signature public key). In the latter case, a TLS
server_key_exchange handshake message MUST also be included to allow server_key_exchange handshake message MUST also be included to allow
the key exchange to take place. the key exchange to take place.
The peer MUST respond to the EAP-Request with an EAP-Response packet
of EAP-Type=PEAP. The data field of this packet will encapsulate
one or more TLS records containing a TLS change_cipher_spec message
and finished handshake message, and possibly certificate,
certificate_verify and/or client_key_exchange handshake messages.
If the preceding server_hello message sent by the EAP server in the If the preceding server_hello message sent by the EAP server in the
preceding EAP-Request packet indicated the resumption of a previous preceding EAP-Request packet did not indicate the resumption of a
session, then the peer MUST send only the change_cipher_spec and previous session, then the peer MUST respond to the EAP-Request with
finished handshake messages. an EAP-Response packet of EAP-Type=PEAP. The data field of this
packet will encapsulate one or more TLS records containing a TLS
change_cipher_spec message and finished handshake message, and
possibly certificate, certificate_verify and/or client_key_exchange
handshake messages.
The finished message contains the peer's authentication response to The EAP server MUST then respond with an EAP-Request packet with EAP-
the EAP server. Type=PEAP, which includes, in the case of a new TLS session, one or
more TLS records containing TLS change_cipher_spec, finished
handshake messages; and the first payload of PEAPv2 part 2. The
first payload of PEAPv2 part 2 is sent along with finished handshake
message to reduce number of round trips.
If the preceding server_hello message sent by the EAP server in the 2.1.4. Session resumption
preceding EAP-Request packet did not indicate the resumption of a
previous session, then the peer MUST send, in addition to the
change_cipher_spec and finished messages, a client_key_exchange
message, which completes the exchange of a shared master secret
between the peer and the EAP server.
The EAP server MUST then respond with an EAP-Request packet with The purpose of the sessionId within the TLS protocol is to allow for
EAP-Type=PEAP, which includes, in the case of a new TLS session, one improved efficiency in the case where a client repeatedly attempts to
or more TLS records containing TLS change_cipher_spec and finished authenticate to an EAP server within a short period of time. This
handshake messages. The latter contains the EAP server's capability is particularly useful for support of wireless roaming.
authentication response to the peer. The peer will then verify the
hash in order to authenticate the EAP server.
If the EAP server authenticates unsuccessfully, the peer MAY send an It is left up to the peer whether to attempt to continue a previous
EAP-Response packet of EAP-Type=PEAP containing a TLS Alert message session, thus shortening the PEAP Part 1 conversation. Typically the
identifying the reason for the failed authentication. The peer MAY peer's decision will be made based on the time elapsed since the
send a TLS alert message rather than immediately terminating the previous authentication attempt to that EAP server.
conversation so as to allow the EAP server to log the cause of the
error for examination by the system administrator.
To ensure that the EAP Server receives the TLS alert message, the Based on the sessionId chosen by the peer, and the time elapsed since
peer MUST wait for the EAP-Server to reply before terminating the the previous authentication, the EAP server will decide whether to
conversation. The EAP Server MUST reply with an EAP-Failure packet allow the continuation, or whether to choose a new session.
since server authentication failure is a terminal condition.
If the EAP server authenticates successfully, the peer MUST send an In the case where the EAP server and the authenticator reside on the
EAP-Response packet of EAP-Type=PEAP, and no data. The EAP-Server same device, then the client will only be able to continue sessions
then continues with Part 2 of the PEAP conversation. when connecting to the same NAS or channel server. Should these
devices be set up in a rotary or round-robin then it may not be
possible for the peer to know in advance the authenticator it will be
connecting to, and therefore which sessionId to attempt to reuse. As
a result, it is likely that the continuation attempt will fail.
2.2. PEAP Part 2 In the case where the EAP authentication is remoted then continuation
is much more likely to be successful, since multiple NAS devices and
channel servers will remote their EAP authentications to the same
backend authentication server.
The second portion of the PEAP conversation consists of another If the EAP server is resuming a previously established session, then
complete EAP conversation occurring within the TLS session it MUST include only a TLS change_cipher_spec message and a TLS
negotiated in PEAP Part 1. It will therefore occur only if finished handshake message after the server_hello message. The
establishment of a new TLS session in Part 1 is successful or a TLS finished message contains the EAP server's authentication response to
session is successfully resumed in Part 1. the peer.
It MUST NOT occur if the EAP Server authenticates unsuccessfully or If the preceding server_hello message sent by the EAP server in the
if an EAP-Failure has been sent by the EAP Server to the peer, preceding EAP-Request packet indicated the resumption of a previous
terminating the conversation. Since all packets sent within the session, then the peer MUST send only the change_cipher_spec and
PEAP Part 2 conversation occur after TLS session establishment, they finished handshake messages. The finished message contains the
are protected using the negotiated TLS ciphersuite. All EAP packets peer's authentication response to the EAP server. The latter contains
of the EAP conversation in part 2 including the EAP header are the EAP server's authentication response to the peer. The peer will
protected using the negotiated TLS ciphersuite. verify the hash in order to authenticate the EAP server.
Part 2 of the PEAP conversation typically begins with the If authentication fails, then the peer and EAP-server MUST follow the
Authenticator sending an EAP-Request/Identity packet to the peer, error handling behavior specified in section 2.3.
protected by the TLS ciphersuite negotiated in PEAP Part 1. The peer
responds with an EAP-Response/Identity packet to the authenticator,
containing the peer's userId. Since this Identity Request/Response
exchange is protected by
the ciphersuite negotiated in TLS, it is protected against snooping
or packet modification attacks.
After the TLS session-protected Identity exchange, the EAP server Even if the session is successfully resumed with the same EAP server,
will then select authentication method(s) for the peer, and will the peer and EAP server MUST not assume that either will skip inner
send an EAP-Request with the EAP-Type set to the initial method. As EAP methods. The peer may have roamed to a network which may use the
described in [RFC2284], the peer can NAK the suggested EAP method, same EAP server, but may require conformance with a different
suggesting an alternative. Since the NAK will be sent within the TLS authentication policy.
channel, it is protected from snooping or packet modification. As a
result, an attacker snooping on the exchange will be unable to
inject NAKs in order to "negotiate down" the authentication method.
An attacker will also not be able to determine which EAP method was
negotiated.
2.3. Version negotiation 2.1.5. Version negotiation
PEAP packets contain a three bit version field, which enables PEAP PEAP packets contain a three bit version field, which enables PEAP
implementations to be backward compatible with previous versions of implementations to be backward compatible with previous versions of
the protocol. Implementations of this specification MUST use a the protocol. This specification documents the PEAP version 2
version field set to 2. This specification documents the protocol protocol; implementations of this specification MUST use a version
for version 2. field set to 2. Version negotiation proceeds as follows:
Version negotiation proceeds as follows: [1] In the first EAP-Request sent with EAP type=PEAP, the EAP server
MUST set the version field to the highest supported version number.
[1] In the first EAP-Request sent with EAP type=PEAP, the EAP [2] If the EAP peer supports this version of the protocol, it MUST
server MUST set the version field to the highest supported version respond with an EAP-Response of EAP type=PEAP, and the version
number. number proposed by the EAP server.
[2] If the EAP client supports this version of the protocol, it [3] If the EAP peer does not support this version, it responds with an
MUST respond with an EAP-Response of EAP type=PEAP, and the version EAP-Response of EAP type=PEAP and the highest supported version
number proposed by the EAP server. number.
[3] If the EAP client does not support this version, it responds [4] If the PEAP server does not support the version number proposed by
with an EAP-Response of EAP type=PEAP and the highest supported the PEAP peer, it terminates the conversation, as described in
version number. Section 2.2.2.
[4] If the EAP server supports the version proposed by the client, The version negotiation procedure guarantees that the EAP peer and
then all future EAP-Request packets of EAP type=PEAP MUST include server will agree to the latest version supported by both parties.
the version field set to the agreed upon version number. Similarly, If version negotiation fails, then use of PEAP will not be possible,
the EAP client MUST include the agreed upon version number in all and another mutually acceptable EAP method will need to be negotiated
EAP-Response packets of EAP type=PEAP. if authentication is to proceed.
[5] If the PEAP server does not support the version number proposed The PEAP version field is not protected by TLS and therefore can be
by the PEAP client, it terminates the conversation, as described in modified in transit. In order to detect modification of the PEAP
Section 2.4. version which could occur as part of a "downgrade" attack, the
PEAPv2 peer and server MUST exchange information on the highest
supported versions proposed by the peers using the crypto-binding-
TLV.
This version negotiation procedure guarantees that the EAP client 2.2. PEAPv2 Part 2
and server will agree to the latest version supported by both
parties. If version negotiation fails, then use of PEAP will not be
possible, and another mutually acceptable EAP method will need to be
negotiated if authentication is to proceed. In order to protect
against a downgrade version attack between PEAP versions support by
the peers, the peers MUST exchange information on the highest
version number supported during the binding exchange.
2.4. Termination The second portion of the PEAPv2 conversation typically consists of a
As described in [RFC2284], EAP Success and Failure packets are not complete EAP conversation occurring within the TLS session negotiated
authenticated, so that they may be forged by an attacker without in PEAPv2 Part 1; ending with protected termination using the Result-
fear of detection. Forged EAP Failure packets can be used to TLV. PEAPv2 part 2 will occur only if establishment of a new TLS
convince an EAP peer to disconnect. Forged EAP Success packets may session in Part 1 is successful or a TLS session is successfully
be used by a rogue NAS to convince a peer to let itself access the resumed in Part 1. In cases where a new TLS session is established
network, even though the NAS has not authenticated itself. in PEAPv2 part 1, the first payload of the part 2 conversation is
sent by the EAP server along with the finished message to save a
round-trip.
By requiring mutual authentication and by supporting encrypted, Part 2 MUST NOT occur if the EAP Server authenticates unsuccessfully
authenticated and integrity protected success/failure indications, or if an EAP-Failure has been sent by the EAP server to the peer,
(described below as "protected" indications) PEAP provides terminating the conversation. Since all packets sent within the
protection against these attacks. Within PEAP, protected PEAPv2 Part 2 conversation occur after TLS session establishment,
success/failure indications are supported by sending these they are protected using the negotiated TLS ciphersuite. All EAP
indications within the TLS channel. packets of the EAP conversation in part 2 including the EAP header of
the inner EAP method are protected using the negotiated TLS
ciphersuite.
PEAP support for protected success/failure indications is Part 2 MAY NOT always include a EAP conversation within the TLS
constrained by the [RFC2284] and [IEEE8021X] specifications. In session, referred to in this document as inner EAP methods. However,
[IEEE8021X], the authenticator "manufactures" cleartext EAP Success Part 2 MUST always end with either protected termination or protected
and Failure packets based on the result indicated by the backend error termination.
authentication server. As a result, were a PEAP server to send a
protected EAP Success or EAP Failure packet as the final packet
within the EAP exchange, authenticators compliant with [IEEE8021X]
would silently discard the packet, and replace it with a cleartext
EAP Success or Failure. Since the client will discard these
unprotected indications, where an authenticator compliant with
[IEEE8021X] is present, it is not be possible to conclude a
successful authentication. As a result, this approach does not
provide reliable authenticated success/failure indications on all
media.
In addition, [RFC2284] states that an EAP Success or EAP Failure Within Part 2, protected EAP conversation and protected termination
packet terminates the EAP conversation, so that no response is packets are always carried within an EAP-TLV packet. The EAP-TLV
possible. Since EAP Success and EAP Failure packets are not packet does not include an EAP header. There are TLVs defined for
retransmitted, if the final packet is lost, then authentication will specific purposes such as carrying EAP-authentication messages and
fail. As a result, where packet loss is expected to be non- carrying cryptographic binding. New TLVs may be developed for other
negligible, unacknowledged success/failure indications lack purposes.
robustness.
As a result, a PEAP server SHOULD NOT send a protected EAP Success 2.2.1. Protected conversation
or EAP Failure packet as the final packet within a PEAP
conversation. However, in the spirit of being "conservative in what
you send, liberal in what you receive", a PEAP client SHOULD accept
and process such a packet if it is received. This behavior makes it
possible for implementations to save a round-trip (improving the
performance of fast reconnect), assuming that the authentication
occurs within a low packet loss environment in which "manufacture"
of packets is guaranteed not to occur.
Instead, EAP servers MUST utilize the acknowledged and protected Part 2 of the PEAP conversation typically begins with the EAP server
success/failure indications defined in Section 4. In this approach, sending an optional EAP-Request/Identity packet to the peer,
the PEAP server sends the success/failure indication as an EAP- protected by the TLS ciphersuite negotiated in PEAP Part 1. The peer
Request with type=33 (EAP TLV), protected within the TLS channel. responds with an EAP-Response/Identity packet to the EAP server,
The PEAP client then replies with a protected success/failure containing the peer's userId. Since this Identity Request/Response
indication as an EAP-Response with type=33 (EAP TLV). The exchange is protected by the ciphersuite negotiated in TLS, it is not
conversation concludes with the PEAP server sending a cleartext vulnerable to snooping or packet modification attacks.
success/failure indication.
Since both sides have already concluded a protected termination After the TLS session-protected Identity exchange, the EAP server
conversation, this final packet is ceremonial. will then select authentication method(s) for the peer, and will send
an EAP-Request with the Type field set to the initial method. As
described in [RFC2284BIS], the peer can NAK the suggested EAP method,
suggesting an alternative. Since the NAK will be sent within the TLS
channel, it is protected from snooping or packet modification. As a
result, an attacker snooping on the exchange will be unable to inject
NAKs in order to "negotiate down" the authentication method. An
attacker will also not be able to determine which EAP method was
negotiated.
Use of a protected and acknowledged success/failure indication The EAP conversation within the TLS protected session may involve a
provides the PEAP protocol immunity against the "manufacture" of sequence of zero or more EAP authentication methods; it completes
cleartext success/failure indications mandated by [IEEE8021X]. It with the protected termination described in section 2.2.2. Several
also enables both sides of the conversation to communicate the EAP-TLVs may be included in each Request and Response. EAP-methods
outcome of PEAP mutual authentication, although the TLS alert (except if the type is EAP-TLV) are always encapsulated within EAP
mechanism already provides this capability to some extent. On the Payload-TLV.
other hand, this approach requires an extra round-trip, which
affects the performance of fast reconnect.
Once PEAP has been selected as the authentication method, compliant In a typical EAP conversation, the result of the conversation is
PEAP implementations MUST silently discard unprotected success communicated by sending EAP Success or EAP Failure packets after the
indications (e.g. cleartext EAP Success) unless both the PEAP peer EAP method is complete. The EAP Success or Failure packet is
and server have indicated a successful authentication exchange via considered the last packet of the EAP conversation; and therefore
the mechanism described in Section 4. cannot be used when sequences need to be supported. Hence, instead
of using the EAP-success or EAP-failure packet, both peer and EAP
server MUST use the Intermediate Result TLV to communicate the
result.
Similarly, once the TLS channel has been set up, compliant PEAP In a typical EAP conversation, the EAP Success or EAP Failure is
implementations MUST silently discard unprotected failure considered the last packet of the EAP conversation. Within PEAP, the
indications (e.g. cleartext EAP Failure) unless they are proceeded EAP server can start another EAP method after success or failure of
by a protected failure indication. Protected failure indications the previous EAP method inside the protected session.
include the TLS alert mechanism, as well the indication mechanism
described in Section 4. For example, if a PEAP peer has previously
received a protected EAP-Request of Type=33 (EAP TLV) with
Result=Failure, or if it has received a protected EAP-Request of
Type=33 (EAP-TLV) with Result=Success, and responded with a
protected EAP-Response of Type=33 (EAP-TLV) with Result=Failure,
then it will accept and process a cleartext EAP Failure.
However, if a PEAP peer has previously received a protected EAP-
Request of Type=33 (EAP-TLV) with Result=Success, and has responded
with a protected EAP-Request of Type=33 (EAP-TLV) with
Result=Success, then an unprotected failure indication MUST be
silently discarded.
Prior to establishment of the TLS channel, no keying material In a sequence of more than one EAP authentication method, to make
exists, so that protected success/failure indications are not sure the same parties are involved in tunnel establishment and
possible. However, within PEAP a failure to establish the TLS successful completion of previous inner EAP methods, before
channel (e.g. failure to verify the server certificate) is completing negotiation of the next EAP method, both peer and EAP
considered an unrecoverable error, so that where this failure has server MUST use crypto binding (Crypto-Binding TLV). If no EAP
occurred, an unprotected failure indication can be safely accepted. methods have been negotiated inside the tunnel or no EAP methods have
been successfully completed inside the tunnel, the crypto-binding TLV
MUST NOT be used.
2.5. Error handling The Crypto-Binding TLV and the Intermediate-Result TLV MUST be sent
after each successful EAP method (except for type EAP-TLV). If these
TLVs are not sent, it should be considered as tunnel compromise error
by peer and EAP server.
Other than supporting TLS alert messages, PEAP does not have its own Both TLVs can be sent in an EAP-TLV packet. Alternatively, if a
error message capabilities. This is unnecessary since errors in the subsequent EAP conversation is being attempted, then in order to
PEAP Part 1 conversation are communicated via TLS alert messages, reduce round trips, both TLVs SHOULD be sent in the EAP-Payload of
and errors in the PEAP Part 2 conversation are expected to be the first EAP packet of the next EAP conversation (for example, EAP-
handled by individual EAP methods. Identity or EAP-packet of the EAP method). Alternatively, if the
next packet is the PEAP termination packet, then in order to reduce
round trips, both TLVs SHOULD be sent with the termination packet.
If an error occurs at any point in the PEAP conversation, the EAP If the EAP server sends a valid Crypto-Binding-TLV to the peer, the
server SHOULD send an EAP-Request packet with EAP-Type=PEAP, peer MUST respond with a Crypto-Binding TLV. If the Crypto-Binding-
encapsulating a TLS record containing the appropriate TLS alert TLV is invalid, it should be considered a tunnel compromise error by
message. The EAP server SHOULD send a TLS alert message rather than the peer. If the peer does not respond with a EAP-TLV packet
immediately terminating the conversation so as to allow the peer to containing the crypto-binding TLV, it should be considered a tunnel
inform the user of the cause of the failure and possibly allow for a compromise error by the EAP server.
restart of the conversation. To ensure that the peer receives the
TLS alert message, the EAP server MUST wait for the peer to reply
with an EAP-Response packet.
2.6. Retry behavior 2.2.2. Protected Termination
As with other EAP protocols, the EAP server is responsible for retry The PEAPv2 part 2 conversation is completed by an exchange of
behavior. This means that if the EAP server does not receive a reply success/failure indications (Result-TLV) within a EAP-TLV packet
from the peer, it MUST resend the EAP-Request for which it has not protected by the TLS session.
yet received an EAP-Response. However, the peer MUST NOT resend EAP-
Response packets without first being prompted by the EAP server.
For example, if the initial PEAP start packet sent by the EAP server If the Crypto-Binding TLV and the Intermediate-Result TLV have NOT
were to be lost, then the peer would not receive this packet, and been exchanged in the previous conversation, then they MUST be
would not respond to it. As a result, the PEAP start packet would be present in the protected indication packet. Otherwise, it should be
resent by the EAP server. Once the peer received the PEAP start considered a tunnel compromise error by the peer and EAP server.
packet, it would send an EAP-Response encapsulating the client_hello
message. If the EAP-Response were to be lost, then the EAP server
would resend the initial PEAP start, and the peer would resend the
EAP-Response.
As a result, it is possible that a peer will receive duplicate EAP- The Result TLV is sent within the TLS channel. The PEAP client then
Request messages, and may send duplicate EAP-Responses. Both the replies with a Result-TLV. The conversation concludes with the PEAP
peer and the EAP Server should be engineered to handle this server sending a cleartext success/failure indication.
possibility.
2.7. Session resumption The only outcome which should be considered as successful
authentication is when an EAP Request of Type=EAP-TLVs with Result
TLV of Status=Success, is answered by an EAP Response of Type=EAP-
TLVs with Result TLV of Status=Success.
The purpose of the sessionId within the TLS protocol is to allow for All other combinations (EAP-TLVs Failure, EAP-TLVs Success), (EAP-
improved efficiency in the case where a client repeatedly attempts TLVs Failure, EAP-TLVs Failure), (no EAP-TLVs exchange or no
to authenticate to an EAP server within a short period of time. This protected EAP Success or Failure) should be considered failed
capability is particularly useful for support of wireless roaming. authentications, both by the PEAP peer and EAP server. Once the
PEAPv2 peer and PEAPv2 server considers them as failed
authentications, they are the last packets inside the protected
tunnel. These are considered failed authentications regardless of
whether a cleartext EAP Success or EAP Failure packet is subsequently
sent.
It is left up to the peer whether to attempt to continue a previous After the PEAPv2 server has sent the success indication, the peer is
session, thus shortening the PEAP Part 1 conversation. Typically the allowed to refuse to accept a Success message from the PEAPv2 server
peer's decision will be made based on the time elapsed since the since the client's policy may require completion of certain EAP
previous authentication attempt to that EAP server. methods. If the peer wants the server to negotiate EAP methods, it
MUST send the EAP-TLV packet with Result-TLV with Status=Failure. If
the success indication from the EAP server contains the crypto-
binding TLV, then the peer MUST include a crypto-binding TLV in the
EAP-TLV response. If the peer does not respond with a EAP-TLV packet
containing the crypto-binding TLV or if the crypto-binding TLV is
invalid, it should be considered as a tunnel compromise error by the
EAP server.
Based on the sessionId chosen by the peer, and the time elapsed If the EAP server has set Result-TLV with Status=Success; and the
since the previous authentication, the EAP server will decide response from the peer is Status=Failure, then the EAP server MUST
whether to allow the continuation, or whether to choose a new either start another EAP conversation inside the protected channel or
session. return Result=TLV with Status=Failure without a crypto-binding TLV
and Intermediate Result TLV.
In the case where the EAP server and the authenticator reside on the A PEAPv2 tunnel may be nested inside another tunnel, for example,
same device, then the client will only be able to continue sessions PEAPv2 may be negotiated as a EAP method inside a PEAPv2 tunnel. In
when connecting to the same NAS or channel server. Should these this case, each tunnel MUST use protected termination.
devices be set up in a rotary or round-robin then it may not be
possible for the peer to know in advance the authenticator it will
be connecting to, and therefore which sessionId to attempt to reuse.
As a result, it is likely that the continuation attempt will fail.
In the case where the EAP authentication is remoted then 2.3. Error handling
continuation is much more likely to be successful, since multiple
NAS devices and channel servers will remote their EAP
authentications to the same backend authentication server.
If the EAP server is resuming a previously established session, then Once the peer responds with the first PEAP packet and the EAP server
it MUST include only a TLS change_cipher_spec message and a TLS receives the first PEAP packet from the peer, both MUST silently
finished handshake message after the server_hello message. The discard all clear text EAP messages unless both the PEAP peer and
finished message contains the EAP server's authentication response server have indicated success or failure or an error using a
to the peer. protected error or protected termination mechanism. If the PEAPv2
tunnel is nested inside another tunnel, then the clear text EAP
messages should be accepted after protected termination of all the
tunnels. After a Fatal alert is received or after protected
termination is complete, the peer or EAP server should accept clear
text EAP messages.
After a session is successfully resumed, the EAP-Server starts with Other than supporting TLS alert messages, PEAPv2 does not have its
Part 2 of the PEAP conversation. The peer may have roamed to a own error message capabilities. This is unnecessary since errors in
different network and successfully resumed with same EAP server. The the PEAPv2 Part 1 conversation are communicated via TLS alert
peer and the EAP server MUST not assume that a session resume messages, and errors in the PEAPv2 Part 2 conversation are expected
implies either of them will skip inner EAP methods. to be handled by individual EAP methods.
2.8. Fragmentation If an error occurs at any point in the TLS layer, the EAP server
SHOULD send a TLS alert message instead of the next EAP-request
packet to the peer. The EAP server SHOULD send an EAP-Request packet
with EAP-Type=PEAP, encapsulating a TLS record containing the
appropriate TLS alert message. The EAP server SHOULD send a TLS
alert message rather than immediately terminating the conversation so
as to allow the peer to inform the user of the cause of the failure
and possibly allow for a restart of the conversation. To ensure that
the peer receives the TLS alert message, the EAP server MUST wait for
the peer to reply with an EAP-Response packet.
The EAP-Response packet sent by the peer MAY encapsulate a TLS
client_hello handshake message, in which case the EAP server MAY
allow the PEAPv2 conversation to be restarted, or it MAY contain an
EAP-Response packet with EAP-Type=PEAP and no data, in which case the
PEAPv2 server MUST send an EAP-Failure packet, and terminate the
conversation.
It is up to the EAP server whether to allow restarts, and if so, how
many times the conversation can be restarted. An EAP server
implementing restart capability SHOULD impose a limit on the number
of restarts, so as to protect against denial of service attacks.
If an error occurs at any point in the TLS layer, the peer SHOULD
send a TLS alert message instead of the next EAP-response packet to
the EAP server. The peer SHOULD send an EAP-Response packet with
EAP-Type=PEAP, encapsulating a TLS record containing the appropriate
TLS alert message. The EAP server may restart the conversation by
sending a EAP-Request packet encapsulating the TLS
hello_request_handshake message, in which case the peer MAY allow the
PEAPv2 conversation to be restarted; or the EAP server can response
with EAP Failure.
Any time the peer or the EAP server finds an error when processing
the sequence of exchanges, such a violation of TLV rules, it should
send a Result TLV of failure and terminate the tunnel. This is
usually due to an implementation problem and is considered an fatal
error.
If a tunnel compromise error (see Section 2.2) is detected by the
peer, the peer SHOULD send a TLS Internal Error alert (a Fatal error)
message instead of the next EAP-response packet to the EAP server.
Similarly, if a tunnel compromise error is detected by the EAP
server, the EAP server SHOULD send a TLS Internal error alert (a
Fatal error) message instead of the next EAP-response packet to the
peer.
2.4. Fragmentation
A single TLS record may be up to 16384 octets in length, but a TLS A single TLS record may be up to 16384 octets in length, but a TLS
message may span multiple TLS records, and a TLS certificate message message may span multiple TLS records, and a TLS certificate message
may in principle be as long as 16MB. The group of PEAP messages sent may in principle be as long as 16MB. The group of PEAP messages sent
in a single round may thus be larger than the PPP MTU size, the in a single round may thus be larger than the PPP MTU size, the
maximum RADIUS packet size of 4096 octets, or even the Multilink maximum RADIUS packet size of 4096 octets, or even the Multilink
Maximum Received Reconstructed Unit (MRRU). As described in [2], Maximum Received Reconstructed Unit (MRRU). As described in
the multilink MRRU is negotiated via the Multilink MRRU LCP option, [RFC1990], the multilink MRRU is negotiated via the Multilink MRRU
which includes an MRRU length field of two octets, and thus can LCP option, which includes an MRRU length field of two octets, and
support MRRUs as large as 64 KB. thus can support MRRUs as large as 64 KB.
However, note that in order to protect against reassembly lockup and However, note that in order to protect against reassembly lockup and
denial of service attacks, it may be desirable for an implementation denial of service attacks, it may be desirable for an implementation
to set a maximum size for one such group of TLS messages. Since a to set a maximum size for one such group of TLS messages. Since a
typical certificate chain is rarely longer than a few thousand typical certificate chain is rarely longer than a few thousand
octets, and no other field is likely to be anywhere near as long, a octets, and no other field is likely to be anywhere near as long, a
reasonable choice of maximum acceptable message length might be 64 reasonable choice of maximum acceptable message length might be 64
KB. KB.
If this value is chosen, then fragmentation can be handled via the If this value is chosen, then fragmentation can be handled via the
multilink PPP fragmentation mechanisms described in [RFC1990]. While multilink PPP fragmentation mechanisms described in [RFC1990]. While
this is desirable, EAP methods are used in other applications such this is desirable, EAP methods are used in other applications such as
as [IEEE80211] and there may be cases in which multilink or the MRRU [IEEE80211] and there may be cases in which multilink or the MRRU LCP
LCP option cannot be negotiated. As a result, a PEAP implementation option cannot be negotiated. As a result, a PEAPv2 implementation
MUST provide its own support for fragmentation and reassembly. MUST provide its own support for fragmentation and reassembly.
Since EAP is an ACK-NAK protocol, fragmentation support can be added Since EAP is an ACK-NAK protocol, fragmentation support can be added
in a simple manner. In EAP, fragments that are lost or damaged in in a simple manner. In EAP, fragments that are lost or damaged in
transit will be retransmitted, and since sequencing information is transit will be retransmitted, and since sequencing information is
provided by the Identifier field in EAP, there is no need for a provided by the Identifier field in EAP, there is no need for a
fragment offset field as is provided in IPv4. fragment offset field as is provided in IPv4.
PEAP fragmentation support is provided through addition of flag bits PEAPv2 fragmentation support is provided through addition of flag
within the EAP-Response and EAP-Request packets, as well as a TLS bits within the EAP-Response and EAP-Request packets, as well as a
Message Length field of four octets. Flags include the Length TLS Message Length field of four octets. Flags include the Length
included (L), More fragments (M), and PEAP Start (S) bits. The L included (L), More fragments (M), and PEAP Start (S) bits. The L
flag is set to indicate the presence of the four octet TLS Message flag is set to indicate the presence of the four octet TLS Message
Length field, and MUST be set for the first fragment of a fragmented Length field, and MUST be set only for the first fragment of a
TLS message or set of messages. The M flag is set on all but the fragmented TLS message or set of messages.
last fragment. The S flag is set only within the PEAP start message
sent from the EAP server to the peer. The TLS Message Length field
is four octets, and provides the total length of the TLS message or
set of messages that is being fragmented; this simplifies buffer
allocation.
When a PEAP peer receives an EAP-Request packet with the M bit set, The TLS Message Length field in the PEAPv2 header is not protected;
and hence can be modified by a attacker. The TLS record length in
the TLS data is protected. Hence, if TLS Message length received in
the first packet (with L bit set) is greater or less than the total
size of TLS data received including multiple fragments, then the TLS
message length should be ignored.
A single TLS record may be up to 16384 octets in length, but a TLS
message may span multiple TLS records, and a TLS certificate message
may in principle be as long as 16MB. However, note that in order to
protect against reassembly lockup and denial of service attacks, it
may be desirable for an implementation to set a maximum size for one
such group of TLS messages. Since a typical certificate chain is
rarely longer than a few thousand octets, and no other field is
likely to be anywhere near as long, a reasonable choice of maximum
acceptable message length might be 64 KB.
The M flag is set on all but the last fragment. The S flag is set
only within the PEAP start message sent from the EAP server to the
peer. The TLS Message Length field is four octets, and provides the
total length of the TLS message or set of messages that is being
fragmented; this simplifies buffer allocation.
When a PEAPv2 peer receives an EAP-Request packet with the M bit set,
it MUST respond with an EAP-Response with EAP-Type=PEAP and no data. it MUST respond with an EAP-Response with EAP-Type=PEAP and no data.
This serves as a fragment ACK. The EAP server MUST wait until it This serves as a fragment ACK. The EAP server MUST wait until it
receives the EAP-Response before sending another fragment. In order receives the EAP-Response before sending another fragment. In order
to prevent errors in processing of fragments, the EAP server MUST to prevent errors in processing of fragments, the EAP server MUST
increment the Identifier field for each fragment contained within an increment the Identifier field for each fragment contained within an
EAP-Request, and the peer MUST include this Identifier value in the EAP-Request, and the peer MUST include this Identifier value in the
fragment ACK contained within the EAP-Response. Retransmitted fragment ACK contained within the EAP-Response. Retransmitted
fragments will contain the same Identifier value. fragments will contain the same Identifier value.
Similarly, when the EAP server receives an EAP-Response with the M Similarly, when the EAP server receives an EAP-Response with the M
bit set, it MUST respond with an EAP-Request with EAP-Type=PEAP and bit set, it MUST respond with an EAP-Request with EAP-Type=PEAP and
no data. This serves as a fragment ACK. The EAP peer MUST wait until no data. This serves as a fragment ACK. The EAP peer MUST wait until
it receives the EAP-Request before sending another fragment. In it receives the EAP-Request before sending another fragment. In
order to prevent errors in the processing of fragments, the EAP order to prevent errors in the processing of fragments, the EAP
server MUST increment the Identifier value for each fragment ACK server MUST increment the Identifier value for each fragment ACK
contained within an EAP-Request, and the peer MUST include this contained within an EAP-Request, and the peer MUST include this
Identifier value in the subsequent fragment contained within an EAP- Identifier value in the subsequent fragment contained within an EAP-
Response. Response.
2.9. Key derivation 2.5. Key derivation
Since the normal TLS keys are used in the handshake, and therefore Since the normal TLS keys are used in the handshake, and therefore
should not be used in a different context, new keys must be derived should not be used in a different context, new keys must be derived
from the TLS master secret for use with the selected link layer from the TLS master secret for use with the selected link layer
ciphersuites. ciphersuites.
In the most general case, keying material must be provided for Instead of deriving keys specific to link layer ciphersuites EAP
authentication, encryption and initialization vectors (IVs) in each methods provides a Master Session Key (MSK) used to derive keys in a
direction. link layer specific manner. The method used to extract ciphering
keys from the MSK is beyond the scope of this document.
Since EAP methods may not know the link layer ciphersuite that has PEAPv2 also derives an Extended Master Session Key (EMSK) which is
been negotiated, it may not be possible for them to provide link reserved for use in deriving keys in other ciphering applications.
layer ciphersuite-specific keys. In addition, attempting to provide This draft also does not discuss the format of the attributes used to
such keys is undesirable, since it would require the EAP method to communicate the master session keys from the backend authentication
be revised each time a new link layer ciphersuite is developed. As a server to the NAS; examples of such attributes are provided in
result, PEAP derives master session keys which can subsequently be [RFC2548].
truncated for use with a particular link layer ciphersuite. Since
the truncation algorithms are ciphersuite-specific, they are not
discussed here; examples of such algorithms are provided in
[RFC3079]. This draft also does not discuss the format of the
attributes used to communicate the master session keys from the
backend authentication server to the NAS; examples of such
attributes are provided in [RFC2548].
Both the peer and EAP server MUST derive master session keys as PEAPv2 combines key material from the TLS exchange with key material
described in the compound Session Key derivation section (section from inner key generating EAP methods to provide stronger keys and to
4.2) of the draft Compound Authentication Binding Problem bind inner authentication mechanisms to the TLS tunnel. Both the
[compoundbinding]. peer and EAP server MUST derive compound MAC and compound session
keys using the procedure described below.
Algorithms for the truncation of these encryption and authentication The input for the cryptographic binding includes the following:
master session keys are specific to each link layer ciphersuite.
Link layer ciphersuites in use with PPP include DESEbis [RFC2419],
3DES [RFC2420] and MPPE [RFC3078]. IEEE 802.11 ciphersuites are
described in [IEEE80211]. An example of how encryption keys for use
with MPPE [RFC3078] are derived from the TLS master session keys is
given in [RFC3079].
2.10. Ciphersuite negotiation [a] The PEAPv2 tunnel key (TK) is calculated using the first 64 octets
of the (secret) key material generated as described in the EAP-TLS
algorithm (RFC2716 section 3.5)
[b] The MSK provided by each successful inner EAP method (should not
include the 64 octets of EMSK); for each successful EAP method
completed within the tunnel.
ISK1..ISKn are the MSK portion of the EAP keying material obtained
from methods 1 to n. In some cases (except in the case of the EAP-
TLV method), where the inner EAP method does not provide keys: ISKi,
for some i, may be the null string ("").
The algorithm uses P_SHA-1 PRF specified in the TLS specification
[RFC2246] ("|" denotes concatenation).
The intermediate combined key is generated after each successful EAP
method inside the tunnel.
Generating the intermediate combined key:
Take the second 32 octets of TK
IPMK0 = TK
for j = 1 to k do
IPMKj = P_SHA1(IPMK(j-1),"Intermediate PEAP MAC key" | ISKj);
k = the last successful EAP method inside the tunnel at the point
where the combined MAC key is derived.
Each IPMKj output is 32 octets. IPMKn is the intermediate combined
key used to derive combined session and combined MAC keys.
Compound MAC Key derivation:
The Compound MAC Key for the server (the B1_MAC) is derived CMK_B1
CMK_B1 = P_SHA1(IPMKn,"PEAP Server B1 MAC key" | S_NONCE)
The Compound MAC Key for the client (the B2_MAC) is derived from MAC
key called CMK B2.
CMK_B2 = P_SHA1(IPMKn,"PEAP Client B2 MAC key" | C_NONCE | S_NONCE)
The compound MAC keys (CMK_B1 and CMK_B2) are each 20 octets long.
Compound Session Key derivation:
The compound session key (CSK) is derived on both the peer and EAP
server after successful completion of protected termination.
CSK = P_SHA1 (IPMKn, "PEAP compound session key" | C_NONCE | S_NONCE
| OutputLength)
The output length of the CSK must be at least 128 bytes. The first
64 octets are taken and the MSK and the second 64 octets are taken as
the EMSK. The MSK and EMSK are described in [RFC2284bis].
2.6. Ciphersuite negotiation
Since TLS supports TLS ciphersuite negotiation, peers completing the Since TLS supports TLS ciphersuite negotiation, peers completing the
TLS negotiation will also have selected a TLS ciphersuite, which TLS negotiation will also have selected a TLS ciphersuite, which
includes key strength, encryption and hashing methods. However, includes key strength, encryption and hashing methods. However,
unlike in [RFC2716], within PEAP, the negotiated TLS ciphersuite unlike in [RFC2716], within PEAPv2, the negotiated TLS ciphersuite
relates only to the mechanism by which the PEAP Part 2 conversation relates only to the mechanism by which the PEAPv2 Part 2 conversation
will be protected, and has no relationship to link layer security will be protected, and has no relationship to link layer security
mechanisms negotiated within the PPP Encryption Control Protocol mechanisms negotiated within the PPP Encryption Control Protocol
(ECP) [RFC1968] or within IEEE 802.11 [IEEE80211]. (ECP) [RFC1968] or within IEEE 802.11 [IEEE80211].
As a result, this specification currently does not support secure As a result, this specification currently does not support secure
negotiation of link layer ciphersuites, although this capability may negotiation of link layer ciphersuites, although this capability may
be added in future by addition of TLVs to the EAP TLV method defined be added in future by addition of TLVs to the EAP TLV method defined
in Section 4. in Section 4.
3. Detailed description of the PEAP protocol 3. Detailed description of the PEAPv2 protocol
3.1. PEAP Packet Format 3.1. PEAPv2 Packet Format
A summary of the PEAP Request/Response packet format is shown below. A summary of the PEAPv2 Request/Response packet format is shown
The fields are transmitted from left to right. below. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Data... | Type | Flags | Ver | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code Code
1 - Request 1 - Request
2 - Response 2 - Response
Identifier Identifier
The Identifier field is one octet and aids in matching responses The Identifier field is one octet and aids in matching responses
with requests. with requests.
Length Length
The Length field is two octets and indicates the length of the The Length field is two octets and indicates the length of the EAP
EAP packet including the Code, Identifier, Length, Type, and Data packet including the Code, Identifier, Length, Type, and 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 should be ignored on treated as Data Link Layer padding and should be ignored on
reception. reception.
Type Type
25 - PEAP 25 - PEAP
Flags Flags
0 1 2 3 4 0 1 2 3 4
+-+-+-+-+-+ +-+-+-+-+-+
|L M S R R| |L M S R R|
+-+-+-+-+-+ +-+-+-+-+-+
L = Length included L = Length included
M = More fragments M = More fragments
S = PEAP start S = PEAP start
R = Reserved (must be zero) R = Reserved (must be zero)
The L bit (length included) is set to indicate the presence of the
The L bit (length included) is set to indicate the presence of four octet TLS Message Length field, and MUST be set for the first
the four octet TLS Message Length field, and MUST be set for the fragment of a fragmented TLS message or set of messages. The L
first fragment of a fragmented TLS message or set of messages. The M bit MUST NOT be set for other fragments of the same set of
bit(more fragments) is set on all but the last fragment. The S bit messages. The M bit(more fragments) is set on all but the last
(PEAP start) is set in a PEAP Start message. This differentiates the fragment. The S bit (PEAP start) is set in a PEAP Start message.
PEAP Start message from a fragment acknowledgment. This differentiates the PEAP Start message from a fragment
acknowledgment.
Version Version
0 1 2 0 1 2
+-+-+-+ +-+-+-+
|R|1|0| |R|1|0|
+-+-+-+ +-+-+-+
R = Reserved (must be zero) R = Reserved (must be zero)
Data Data
The format of the Data field is determined by the Code field. The format of the Data field is determined by the Code field.
3.2. PEAP Request Packet 3.2. PEAPv2 Request Packet
A summary of the PEAP Request packet format is shown below. The A summary of the PEAPv2 Request packet format is shown below. The
fields fields are transmitted from left to right.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | TLS Message Length | Type | Flags | Ver | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data... | TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code Code
1 1
Identifier Identifier
The Identifier field is one octet and aids in matching responses The Identifier field is one octet and aids in matching responses
with requests. The Identifier field MUST be changed on each Request with requests. The Identifier field MUST be changed on each
packet. Request packet.
Length Length
The Length field is two octets and indicates the length of the EAP
The Length field is two octets and indicates the length of the packet including the Code, Identifier, Length, Type, Flags, TLS
EAP packet including the Code, Identifier, Length, Type, and TLS message length and TLS data fields.
Response fields.
Type Type
25 - PEAP 25 - PEAP
Flags Flags
0 1 2 3 4 0 1 2 3 4
+-+-+-+-+-+ +-+-+-+-+-+
|L M S R R| |L M S R R|
skipping to change at page 21, line 4 skipping to change at page 27, line 18
Type Type
25 - PEAP 25 - PEAP
Flags Flags
0 1 2 3 4 0 1 2 3 4
+-+-+-+-+-+ +-+-+-+-+-+
|L M S R R| |L M S R R|
+-+-+-+-+-+ +-+-+-+-+-+
L = Length included L = Length included
M = More fragments M = More fragments
S = PEAP start S = PEAP start
R = Reserved (must be zero) R = Reserved (must be zero)
The L bit (length included) is set to indicate the presence of The L bit (length included) is set to indicate the presence of the
the four octet TLS Message Length field, and MUST be set for the four octet TLS Message Length field, and MUST be set for the first
first fragment of a fragmented TLS message or set of messages. The M fragment of a fragmented TLS message or set of messages. The M
bit(more fragments) is set on all but the last fragment. The S bit bit(more fragments) is set on all but the last fragment. The S
(PEAP start) is set in a PEAP Start message. This differentiates the bit (PEAP start) is set in a PEAP Start message. This
PEAP Start message from a fragment acknowledgment. differentiates the PEAP Start message from a fragment
acknowledgment.
Version Version
0 1 2 0 1 2
+-+-+-+ +-+-+-+
|R|1|0| |R|1|0|
+-+-+-+ +-+-+-+
R = Reserved (must be zero) R = Reserved (must be zero)
TLS Message Length TLS Message Length
The TLS Message Length field is four octets, and is present only The TLS Message Length field is four octets, and is present only
if the L bit is set. This field provides the total length of the if the L bit is set. This field provides the total length of the
TLS message or set of messages that is being fragmented. TLS message or set of messages that is being fragmented.
TLS data TLS data
The TLS data consists of the encapsulated packet in TLS record The TLS data consists of the encapsulated packet in TLS record
format. format.
3.3. PEAP Response Packet 3.3. PEAPv2 Response Packet
A summary of the PEAP Response packet format is shown below. The A summary of the PEAPv2 Response packet format is shown below. The
fields are transmitted from left to right. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags |Ver| TLS Message Length | Type | Flags |Ver| TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data... | TLS Message Length | TLS Data...
skipping to change at page 22, line 4 skipping to change at page 28, line 25
| Type | Flags |Ver| TLS Message Length | Type | Flags |Ver| TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data... | TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code Code
2 2
Identifier Identifier
The Identifier field is one octet and MUST match the Identifier The Identifier field is one octet and MUST match the Identifier
field from the corresponding request. field from the corresponding request.
Length Length
The Length field is two octets and indicates the length of the The Length field is two octets and indicates the length of the EAP
EAP packet including the Code, Identifier, Length, Type, and TLS packet including the Code, Identifier, Length, Type, Flags, Ver,
data fields. TLS message length, and TLS data fields.
Type Type
25 - PEAP 25 - PEAP
Flags Flags
0 1 2 3 4 0 1 2 3 4
+-+-+-+-+-+ +-+-+-+-+-+
|L M S R R| |L M S R R|
+-+-+-+-+-+ +-+-+-+-+-+
L = Length included L = Length included
M = More fragments M = More fragments
S = PEAP start S = PEAP start
R = Reserved (must be zero) R = Reserved (must be zero)
The L bit (length included) is set to indicate the presence of The L bit (length included) is set to indicate the presence of the
the four octet TLS Message Length field, and MUST be set for the four octet TLS Message Length field, and MUST be set for the first
first fragment of a fragmented TLS message or set of messages. The M fragment of a fragmented TLS message or set of messages. The M
bit (more fragments) is set on all but the last fragment. The S bit bit (more fragments) is set on all but the last fragment. The S
(PEAP start) is set in a PEAP Start message. This differentiates the bit (PEAP start) is set in a PEAP Start message. This
PEAP Start message from a fragment acknowledgment. differentiates the PEAP Start message from a fragment
acknowledgment.
Version Version
0 1 2 0 1 2
+-+-+-+ +-+-+-+
|R|1|0| |R|1|0|
+-+-+-+ +-+-+-+
R = Reserved (must be zero) R = Reserved (must be zero)
TLS Message Length TLS Message Length
The TLS Message Length field is four octets, and is present only The TLS Message Length field is four octets, and is present only
if the L bit is set. This field provides the total length of the TLS if the L bit is set. This field provides the total length of the
message or set of messages that is being fragmented. TLS message or set of messages that is being fragmented.
TLS data TLS data
The TLS data consists of the encapsulated TLS packet in TLS record The TLS data consists of the encapsulated TLS packet in TLS record
format. format.
4. EAP TLV method
The EAP-TLV method is a payload with standard Type-Length-Value
(TLV) objects. The TLV objects could be used to carry arbitrary
parameters between EAP peer and EAP server. Possible uses for TLV
objects include: language and character set for Notification
messages; cryptographic binding; IPv6 Binding Update.
The EAP peer may not necessarily implement all the TLVs supported by
the EAP server; and hence to allow for interoperability, the TLV
method allows a EAP server to discover if a TLV is supported by the
EAP peer, using the NAK TLV.
The mandatory bit in a TLV indicates that the peer MUST understand
the TLV. A peer can determine that a TLV is unknown when it does not
support the TLV; or when the TLV is corrupted. The mandatory bit
does not indicate that the peer successfully applied the value of
the TLV. The specification of a TLV could define additional
conditions under which the TLV can be determined to be unknown.
If an EAP peer finds an unknown TLV which is marked as mandatory; it
MUST indicate a failure to the EAP server using the NAK TLV; and all
the other TLVs in the message MUST be ignored.
If an EAP peer finds an unknown TLV which is marked as optional;
then it MUST ignore the TLV. The EAP peer is not required to inform
the EAP server of unknown TLVs which are marked as optional. If the
EAP peer finds that the packet has no TLVs, then it MUST send a
response with EAP-TLV Response Packet. The Response packet may
contain no TLVs.
If an EAP server finds an unknown TLV which is marked as mandatory; 3.4. PEAPv2 Part 2 Packet Format
the other TLVs in the message MUST be ignored. The EAP server can
drop the connection or send a EAP-TLV request packet with NAK-TLV to
the EAP client.
Compliant PEAP implementations MUST support the EAP TLV method, The PEAPv2 Part 2 packet format is the same as the PEAPv2 Request and
processing of mandatory/optional settings on the TLV, the NAK TLV. Response packet formats described in Sections 3.1 and 3.2, except
that the TLS Data field encapsulates TLS packets in TLS record
format, representing encrypted EAP-TLVs.
TLVs can be contained/nested in other TLVs. A EAP-TLV Request packet Although the EAP-TLV method has been allocated an EAP Type, use of
is a EAP method; and it can be sequenced before or after any other this method is prohibited outside of a tunnel by [RFC2284bis]. Since
EAP method. The packet does not have to contain any TLVs or does not EAP-TLVs are self-describing, when transmitted within PEAPv2, the EAP
have to contain any mandatory TLVs. header portion of the EAP-TLV packet is absent (including the Code,
Identifier, Length and Type fields), leaving only a list of TLVs as
the payload.
4.1. Protected success/failure Within PEAPv2, all inner EAP method packets are encapsulated in EAP-
TLV format. The EAP-Payload is an (optional) TLV which encapsulates
EAP packets (including all EAP header fields) and in addition carries
TLVs associated with them.
Compliant PEAP implementations MUST support acknowledged protected PEAP Part 2 packet format = EAP-TLV [EAP-Payload TLV [[EAP packet],
success/failure together with the Binding exchange. TLVs, ...], TLVs, ...] OR TLS Alert
The EAP-TLV packet is included without the EAP header fields (Code,
Identifier, Length, Type)
The Result TLV is used to indicate success or failure of the PEAP 4. EAP-TLV method
tunnel. The PEAP tunnel success/failure packet MUST contain a Result
TLV along with the Cryto-Binding TLV. Crypto-Binding TLV may be used
in other EAP-TLV packets. Result TLV MUST NOT be sent in packets
other than the protected success/failure indication.
If a CRYPTO BINDING TLV does not exist in a packet that contains The EAP-TLV method is a payload with standard Type-Length-Value (TLV)
Result TLV, then the EAP peer must disconnect the connection. objects. The TLV objects could be used to carry arbitrary parameters
between EAP peer and EAP server. Possible uses for TLV objects
include: language and character set for Notification messages;
cryptographic binding; MIPv6 Binding Update.
If a CRYPTO BINDING TLV fails validation, then peer must disconnect The EAP peer may not necessarily implement all the TLVs supported by
the connection. Implementations that can delete the TLS handle MUST the EAP server; and hence to allow for interoperability, the TLV
delete the TLS handle. Implementations that keep track of session method allows a EAP server to discover if a TLV is supported by the
state MUST ensure that the session handle cannot be used to skip EAP peer, using the NAK TLV.
stage2 authentication.
When using the Result-TLV, the only outcome which should be The mandatory bit in a TLV indicates that if the peer does not
considered as successful authentication is when an EAP Request of support the TLV, it MUST send a NAK TLV in response; and all the
Type=EAP-TLVs with Result TLV of Status=Success is answered by an other TLVs in the message MUST be ignored. If an EAP peer finds an
EAP Response of Type=EAP-TLVs with Result TLV of Status=Success. unsupported TLV which is marked as optional, it MUST NOT send an NAK
TLV.
If the EAP server has set Result-TLV with Status=Success; and the The mandatory bit does not imply that the peer is required to
response from the EAP peer is Status=Failure, then the server MUST understand the contents of the TLV. The appropriate response to a
either continue EAP conversation or return Result=TLV with supported TLV with content that is not understood is defined by the
Status=Failure. This allows EAP peer to indicate that it refuses to TLV specification.
accept the authentication without negotiating certain auth methods
as per its policy.
All other combinations (EAP-TLVs Failure, EAP-TLVs Success), (EAP- If the EAP peer finds that the packet has no TLVs, then it MUST send
TLVs Failure, EAP-TLVs Failure), (no EAP-TLVs exchange or no a response with EAP-TLV Response Packet.
protected EAP Success or Failure, no Crypto-Binding TLVs, crypto-
binding TLV validation is not successful) should be considered
failed authentications, both by the PEAP peer and authenticator.
Once the PEAP peer and authenticator considers them as failed
authentications, they are the last packets inside the protected
tunnel. These are considered failed authentications regardless of
whether a cleartext EAP Success or EAP Failure packet is
subsequently sent. Because the EAP-TLVs method is protected within
the TLS channel, these packets cannot be spoofed, whereas cleartext
EAP Success and EAP Failure messages can be sent by an attacker.
In order for the validation of crypto-binding TLV to be successful, The mandatory bit in a TLV indicates that if the EAP server does not
the EAP server and EAP peer should be in-sync on which EAP methods support the TLV, it MUST send a NAK TLV in response; otherwise it
inside the tunnel have been successful. If any or all EAP methods MUST send a protected termination message. If an EAP server finds an
inside the tunnels have failed as per EAP server or EAP peer, then unsupported TLV which is marked as mandatory; the other TLVs in the
that does not mean the Result will always be set to failure. message MUST be ignored.
In a successful authentication for a tunnel, the last packet An EAP-TLV packet is a EAP method and within a PEAPv2 tunnel, it can
exchange (both request and response) inside the tunnel MUST always be sequenced before or after any other EAP method. An EAP-TLV packet
contain a valid Crypto-Binding TLV and Result-TLV=Success. does not have to contain any TLVs nor need it contain any mandatory
TLVs.
Compliant PEAP implementations MUST support the EAP TLV method, PEAPv2 implementations MUST support the EAP TLV method, as well as
processing of mandatory/optional settings on the TLV, the NAK TLV, processing of mandatory/optional settings on the TLV.
Result-TLV, Method-Identity-TLV, Crypto-Binding-TLV.
4.2. EAP-TLV Request Packet 4.1. EAP-TLV Request Packet
A summary of the EAP EAP-TLVs Request packet format is shown below. A summary of the EAP-TLV Request packet format is shown below. The
The fields are transmitted from left to right. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Data.... | Type | Data....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code Code
1 1
Identifier Identifier
The Identifier field is one octet and aids in matching responses The Identifier field is one octet and aids in matching responses
with requests. The Identifier field MUST be changed on each Request with requests. The Identifier field MUST be changed on each
packet. Request packet.
Length Length
The Length field is two octets and indicates the length of the The Length field is two octets and indicates the length of the EAP
EAP packet including the Code, Identifier, Length, Type, and Data packet including the Code, Identifier, Length, Type, and Data
fields. fields.
Type Type
33 - EAP-TLV 33 - EAP-TLV
Data Data
The Data field is of variable length, and contains EAP-TLV TLVs. The Data field is of variable length, and contains Type-Length-
Value tuples (TLVs).
4.3. EAP-TLV Response Packet 4.2. EAP-TLV Response Packet
A summary of the EAP-TLV Response packet format is shown below. The A summary of the Extension Response packet format is shown below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Data.... | Type | Data....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
Code
2 2
Identifier Identifier
The Identifier field is one octet and aids in matching responses The Identifier field is one octet and aids in matching responses
with requests. The Identifier field MUST be changed on each Request with requests. The Identifier field MUST be changed on each
packet. Request packet.
Length Length
The Length field is two octets and indicates the length of the The Length field is two octets and indicates the length of the EAP
EAP packet including the Code, Identifier, Length, Type, and Data packet including the Code, Identifier, Length, Type, and Data
fields. fields.
Type Type
33 - EAP EAP-TLV 33 - EAP-TLV
Data Data
The Data field is of variable length, and contains Attribute- The Data field is of variable length, and contains Type-Length-
Value Pairs (TLVs). Value tuples (TLVs).
4.4. EAP-TLV TLV format 4.3. TLV format
EAP-TLV TLVs are defined as follows: EAP-TLV TLVs are defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M M
0 - Non-mandatory TLV 0 - Non-mandatory TLV
1 - Mandatory TLV 1 - Mandatory TLV
R R
Reserved, set to 0.
Reserved, set to zero (0)
TLV Type TLV Type
A 14-bit field, denoting the attribute type. Allocated TLV Types A 14-bit field, denoting the TLV type. Allocated Types include:
include:
0 - Reserved 0 - Reserved
1 - Reserved 1 - Reserved
2 - Reserved 2 - Reserved
3 - - RESULT_TLV - Acknowledged Result 3 - RESULT_TLV - Acknowledged Result
4 - NAK_TLV 4 - NAK_TLV
5 - CRYPTO_BINDING TLV 5 - Crypto-Binding TLV
6 - METHOD_IDENTITY TLV 6 - Connection-Binding TLV
7 - Vendor-Specific TLV
8 - URI TLV
9 - EAP Payload TLV
10 - Intermediate Result TLV
Length Length
The length of the Value field in octets. The length of the Value field in octets.
Value Value
The value of the attribute. The value of the TLV.
CRYPTO_BINDING_TLV and METHOD_IDENTITY_TLV are defined in the draft
Compound Authentication Binding Problem[CompoundBinding].
4.5. Result TLV 4.4. Result TLV
The Result TLV provides support for acknowledged Success and Failure The Result TLV provides support for acknowledged success and failure
messages within PEAP. It is defined as follows: messages within PEAPv2. PEAPv2 implementations MUST support this
TLV, which cannot be responded to with a NAK TLV. If the Status
field does not contain one of the known values, then the peer or EAP
server MUST drop the connection. The Result TLV is defined as
follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M M
1 - Mandatory TLV 1 - Mandatory TLV
R R
Reserved, set to zero (0) Reserved, set to zero (0)
TLV Type TLV Type
3 - Success/Failure 3
Length Length
2 2
Status Status
The status field is two octets. Values include: The Status field is two octets. Values include:
1 - Success 1 - Success
2 - - Failure 2 - Failure
4.6. NAK TLV 4.5. NAK TLV
The NAK TLV allows a peer to detect when TLVs that are not supported The NAK TLV allows a peer to detect TLVs that are not supported by
by the other peer. It is defined as follows: the other peer. An EAP-TLV packet can contain 0 or more NAK TLVs.
PEAPv2 implementations MUST support this TLV and this TLV cannot be
responded to with a NAK TLV. The NAK TLV is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type number | TLVsà | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M M
1 - Mandatory TLV 1 - Mandatory TLV
R R
Reserved, set to zero (0) Reserved, set to zero (0)
TLV Type TLV Type
4 - 4
Length Length
<tbd> >=6
TLV Type number. Vendor-Id
The field contains TLV type that is not supported. The Vendor-Id field is four octets, and contains the Vendor-Id of
the TLV that was not supported. The high-order octet is 0 and the
low-order 3 octets are the SMI Network Management Private
Enterprise Code of the Vendor in network byte order. The Vendor-
Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.
For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI
code.
TLVs.. NAK-Type
The field contains a list of optional TLVs. These could be used The NAK-Type field is two octets. The field contains the Type of
in future to send information on why the field was determined to the TLV that was not supported. A TLV of this Type MUST have been
be unknown. included in the previous packet.
5. Security Considerations TLVs
5.1. Authentication and integrity protection This field contains a list of TLVs, each of which MUST NOT have
the mandatory bit set. These optional TLVs can be used in the
future to communicate why the offending TLV was determined to be
unsupported.
The EAP-TLV method is presumed to run before or after an EAP 4.6. Crypto-binding TLV
method that supports mutual authentication and establishes a
protected channel. PEAP is such a method, and as a result the
acknowledged Success and Failure messages are always protected.
Note however, that [IEEE8021X] manufactures cleartext EAP Success The Crypto-Binding TLV is used prove that both peers participated in
and EAP Failure messages, so that even though the Result TLV will be the sequence of authentications (specifically the TLS session and
protected, this will be followed by a cleartext EAP Success or EAP inner EAP methods that generate keys).
Failure packet.
5.2. Method negotiation Both the Binding Request (B1) and Binding Response (B2) use the same
packet format. However the Sub-Type indicates whether it is B1 or
B2.
If the peer does not support PEAP, or does not wish to utilize PEAP The Crypto-Binding TLV MUST be used to perform Cryptographic Binding
authentication, it MUST respond to the initial EAP-Request/PEAP- after each successful EAP method (except EAP-TLV) in a sequence of
Start with a NAK, suggesting an alternate authentication method. EAP methods is complete in PEAPv2 part 2. The Crypto-Binding TLV can
Since the NAK is sent in cleartext with no integrity protection or also be used during Protected Termination.
authentication, it is subject to spoofing. Unauthentic NAK packets
can be used to trick the peer and Authenticator into "negotiating The crypto-binding TLV must have the version number received during
down" to a weaker form of authentication, such as EAP-MD5 (which the PEAP version negotiation. The receiver of the crypto binding TLV
only provides one way authentication and does not derive a key). must verify that the version in the crypto binding TLV matches the
version it sent during the PEAP version negotiation. If this check
fails then the TLV is invalid.
The receiver of the crypto binding TLV must verify that the subtype
is not set to any value other than the ones allowed. If this check
fails then the TLV is invalid.
This message format is used for the Binding Request (B1) and also the
Binding Response. This uses TLV type CRYPTO_BINDING_TLV. PEAPv2
implementations MUST support this TLV and this TLV cannot be
responded to with a NAK TLV. The format is as given below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |Received Ver. | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
5
Length
52
Version
The Version field is a single octet, which is set to the version
of crypto binding TLV. For the crypto-binding TLV defined in this
specification, It is set to zero (0).
Received Version
The Received Version field is a single octet and MUST be set to
the PEAP version number received during version negotiation. Note
that this field only provides protection against downgrade attacks
where a version of PEAP requiring support for this TLV is required
on both sides (such as PEAPv2 or a more recent version).
Sub-Type
The Sub-Type field is two octets. Possible values include:
0 - Binding Request
1 - Binding Response
Nonce
The Nonce field is 32 octets. It contains a 256 bit nonce that is
temporally unique, used for compound MAC key derivation at each
end. This is the S_NONCE for the B1 message and a C_NONCE for the
B2 message.
Compound MAC
The Compound MAC field is 16 octets. This can be the Server MAC
(B1_MAC) or the Client MAC (B2_MAC). It is computed over the
entire Crypto-Binding TLV attribute using the HMAC-SHA1-128 that
provides 128 bits of output using the CMK_B1 or CMK_B2 with the
MAC field zeroed out.
4.7. Connection-Binding TLV
The Connection-Binding TLV allows for connection specific information
to be sent by the peer to the AAA server. This TLV should be logged
by the EAP or AAA server. The AAA or EAP server should not deny
access if there i s a mismatch between the value sent through the AAA
protocol and this TLV.
The format of this TLV is defined for the layer that defines the
parameters. The format of the value sent by the peer to the EAP
server may be different from the format of the corresponding value
sent through the AAA protocol. For example, the connection binding
TLV may contain 802.11 MAC Address and SSID.
PEAP implementations MAY support this TLV and this TLV MUST NOT be
responded to with a NAK TLV. It is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
6
Length
>=0
TLVs...
The field contains a list of TLVs, each in the same format defined
in Section 4.3, with the optional bit set. These TLVs contain
information on the identity of the peer and authenticator (layer 2
or IP addresses); the media used to connect the peer and
authenticator (NAS-Port-Type); and/or the service the client is
trying to access on the gateway (SSID). The format of these TLVs
will be defined in a separate draft.
4.8. Vendor-Specific TLV
The Vendor-Specific TLV is available to allow vendors to support
their own extended attributes not suitable for general usage.
A Vendor-Specific-TLV attribute can contain one or more TLVs,
referred to as Vendor-TLVs. The TLV-type of the Vendor-TLV will be
defined by the vendor. All the Vendor-TLVs inside a single Vendor-
Specific TLV belong to the same vendor.
PEAPv2 implementations MUST support the Vendor-Specific TLV; and this
TLV cannot be responded to with a NAK TLV. PEAPv2 implementations
MAY NOT support the Vendor-TLVs included in the Vendor-Specific TLV
and can respond with a NAK TLV.
Vendor-TLVs may be optional or mandatory. Vendor-TLVs sent in the
protected success and failure packets MUST be marked as optional. If
Vendor-TLVs sent in protected success/failure packets are marked as
Mandatory, then the peer or EAP server MUST drop the connection.
A summary of the Vendor-Specific Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
7
Length
>=4
Vendor-Id
The Vendor-Id field is four octets. The high-order octet is 0 and
the low-order 3 octets are the SMI Network Management Private
Enterprise Code of the Vendor in network byte order. The Vendor-
Id MUST be zero for TLVs that are not Vendor-Specific TLVs. For
Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code.
Vendor-TLVs
This field is of indefinite length. It contains vendor-specific
TLVs, in a format defined by the vendor.
4.9. URI TLV
The URI TLV allows a server to send a URI to the client to refer it
to a resource. The TLV contains a URI in the format specified in
RFC2396 with UTF-8 encoding. If a packet contains multiple URI TLVs,
then the client SHOULD select the first TLV it can implement, and
ignore the others. If the client is unable to implement any of the
URI TLVs, then it MAY ignore the error. PEAP implementations MAY
support this TLV; and this TLV cannot be responded to with a NAK TLV.
A summary of this field is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
8
Length
>=0
URI
This field is of indefinite length, and conforms to the format
specified in [RFC2396].
4.10. EAP-Payload TLV
To allow piggybacking EAP request and response with other TLVs, the
EAP Payload TLV is defined, which includes an encapsulated EAP packet
and 0 or more TLVs. PEAPv2 implementations MUST support this TLV,
which cannot be responded to with a NAK TLV. The EAP-Payload TLV is
defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP packet...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
8
Length
>=0
EAP packet
This field contains a complete EAP packet, including the EAP
header (Code, Identifier, Length, Type) fields. The length of
this field is determined by the Length field of the encapsulated
EAP packet.
TLVs...
This (optional) field contains a list of TLVs associated with the
EAP packet field. The TLVs utilize the same format described
Section 4.3, and MUST NOT have the mandatory bit set. The total
length of this field is equal to the Length field of the EAP-
Payload-TLV, minus the Length field in the EAP header of the EAP
packet field.
4.11. Intermediate Result TLV
The Intermediate Result TLV provides support for acknowledged
intermediate Success and Failure messages within EAP. PEAPv2
implementations MUST support this TLV, which cannot be responded to
with a NAK TLV. This TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
10
Length
>=2
Status
The Status field is two octets. Values include:
1 - Success
2 - Failure
TLVs
This (optional) field is of indeterminate length, and contains the
TLVs associated with the Intermediate Result TLV, in the same
format as described in Section 4.3. The TLVs in this field MUST
NOT have the mandatory bit set.
4.12. TLV Rules
To save round trips, multiple TLVs can be sent in the single PEAPv2
packet. However, multiple EAP Payload TLVs within one single PEAPv2
packet is not supported in this version and MUST NOT be sent. If the
peer or EAP server receives multiple EAP Payload TLVs, then it MUST
drop the connection.
The following table provides a guide to which TLVs may be found in
which kind of packets, and in which quantity:
Request Response Success Failure TLV
0-1 0-1 0-1 0-1 Intermediate Result TLV
0-1 0-1 0 0 EAP Payload TLV
0-1 0-1 1 1 Result TLV
0-1 0-1 0-1 0-1 Crypto-Binding TLV
0+ 0+ 0 0 NAK TLV
0-1 0-1 0-1 0-1 Connection-Binding TLV
0+ 0+ 0+ 0+ Vendor-Specific TLV
0+ 0 0+ 0-1 URI TLV
The following table defines the meaning of the above table entries.
0 This TLV MUST NOT be present in the packet.
0+ Zero or more instances of this TLV MAY be present in packet.
0-1 Zero or one instance of this TLV MAY be present in packet.
1 Exactly one instance of this TLV MUST be present in packet.
Packet type Description
----------------------------
Request - EAP-TLV request packet sent by EAP server to peer.
Response - EAP-TLV response packet sent by peer to EAP server.
Success - EAP-TLV packet sent by Peer or EAP server as
protected success
Failure - EAP-TLV packet sent by Peer or EAP server as
protected failure.
The EAP-Payload TLV can contain other TLVs. The table below
defines which TLVs can be contained inside the EAP-Payload TLV
and how many such TLVs can be included.
EAP-Payload-TLV TLV
0 Intermediate Result TLV
0 EAP Payload TLV
0 Result TLV
0 Crypto-Binding TLV
0+ NAK TLV
0 Connection-Binding TLV
0+ Vendor-Specific TLV
0 URI TLV
5. Security Considerations
5.1. Authentication and integrity protection
PEAPv2 provides a server authenticated, encrypted and integrity
protected tunnel. All data within the tunnel has these properties.
Data outside the tunnel such as EAP Success and Failure,
authentication methods negotiated outside of PEAPv2 and the PEAPv2
headers themselves are not protected by this tunnel.
In addition, the crypto-binding TLV can reveal man-in-the-middle
attack described in section 6.8. Hence, the server should not reveal
any sensitive data to the client until after the Crypto-Binding TLV
has been properly verified.
5.2. Method negotiation
If the peer does not support PEAPv2, or does not wish to utilize
PEAPv2 authentication, it MUST respond to the initial EAP-
Request/PEAP-Start with a NAK, suggesting an alternate authentication
method. Since the NAK is sent in cleartext with no integrity
protection or authentication, it is subject to spoofing. Inauthentic
NAK packets can be used to trick the peer and authenticator into
"negotiating down" to a weaker form of authentication, such as EAP-
MD5 (which only provides one way authentication and does not derive a
key).
Since a subsequent protected EAP conversation can take place within Since a subsequent protected EAP conversation can take place within
the TLS session, selection of PEAP as an authentication method does the TLS session, selection of PEAPv2 as an authentication method does
not limit the potential secondary authentication methods. As a not limit the potential secondary authentication methods. As a
result, the only legitimate reason for a peer to NAK PEAP as an result, the only legitimate reason for a peer to NAK PEAPv2 as an
authentication method is that it does not support it. Where the authentication method is that it does not support it. Where the
additional security of PEAP is required, server implementations additional security of PEAPv2 is required, server implementations
SHOULD respond to a NAK with an EAP-Failure, terminating the SHOULD respond to a NAK with an EAP-Failure, terminating the
authentication conversation. authentication conversation.
5.3. TLS session cache handling Since method negotiation outside of PEAP is not protected, if the
peer is configured to allow PEAP and other EAP methods at the same
time, the negotiation is subject to downgrade attacks. Since method
negotiation outside of PEAP is not protected, if the peer is
configured to allow PEAP version 2; and previous PEAP versions at the
same time, the negotiation is subject to negotiation downgrade
attacks. However, peers configured to allow PEAPv2 and later PEAP
versions may not be subject to downgrade negotiation attack since the
highest version supported by both peers is checked within the
protected tunnel.
If peer implementations select incorrect methods or credentials with
EAP servers, then attacks are possible on the credentials. Hence, a
PEAPv2 peer implementation should preferably be configured with a set
of credentials and methods that may be used with a specific PEAPv2
Server. The peer implementation may be configured to use different
methods and/or credentials based on the PEAPv2 server.
5.3. TLS session cache handling
In cases where a TLS session has been successfully resumed, in some In cases where a TLS session has been successfully resumed, in some
circumstances, it is possible for the EAP server to skip the PEAP circumstances, it is possible for the EAP server to skip the PEAPv2
Part 2 conversation, and successfully conclude the conversation as Part 2 conversation, and successfully conclude the conversation with
described in Section 2.4. a protected termination.
PEAP "fast reconnect" is desirable in applications such as wireless PEAPv2 "fast reconnect" is desirable in applications such as wireless
roaming, since it minimizes interruptions in connectivity. It is roaming, since it minimizes interruptions in connectivity. It is
also desirable when the "inner" EAP mechanism used is such that it also desirable when the "inner" EAP mechanism used is such that it
requires user interaction. The user should not be required to re- requires user interaction. The user should not be required to re-
authenticate herself, using biometrics, token cards or similar, authenticate herself, using biometrics, token cards or similar, every
every time the radio connectivity is handed over between access time the radio connectivity is handed over between access points in
points in wireless environments. wireless environments.
However, there are issues that need to be understood in order to However, there are issues that need to be understood in order to
avoid introducing security vulnerabilities. avoid introducing security vulnerabilities.
Since PEAP Part 1 may not provide client authentication, Since PEAPv2 Part 1 may not provide client authentication,
establishment of a TLS session (and an entry in the TLS session establishment of a TLS session (and an entry in the TLS session
cache) does not by itself provide an indication of the peer's cache) does not by itself provide an indication of the peer's
authenticity. The peer's authenticity is only proven after authenticity.
successful completion of the protected acknowledge exchange in PEAP
part 2.
Some PEAP implementations may not be capable of removing TLS session Some PEAPv2 implementations may not be capable of removing TLS
cache entries established in PEAP Part 1 after an unsuccessful PEAP session cache entries established in PEAPv2 Part 1 after an
Part 2 authentication. In such implementations, the existence of a unsuccessful PEAPv2 Part 2 authentication. In such implementations,
TLS session cache entry provides no indication that the peer has the existence of a TLS session cache entry provides no indication
previously been authenticated. As a result, implementations that do that the peer has previously been authenticated. As a result,
not remove TLS session cache entries after a failed PEAP Part 2 implementations that do not remove TLS session cache entries after a
authentication or failed protected ack MUST use other means than failed PEAPv2 Part 2 authentication or failed protected termination
successful TLS resumption as the indicator of whether the client is MUST use other means than successful TLS resumption as the indicator
authenticated or not. The implementation MUST determine that the of whether the client is authenticated or not. The implementation
client is authenticated only after the protected acknowledge has MUST determine that the client is authenticated only after the
been successfully exchanged. Failing to do this would enable a completion of protected termination. Failing to do this would enable
peer to gain access by completing PEAP Part 1, tearing down the a peer to gain access by completing PEAPv2 Part 1, tearing down the
connection, re-connecting and resuming PEAP Part 1, thereby proving connection, re-connecting and resuming PEAPv2 Part 1, thereby proving
herself authenticated. Thus, TLS resumption MUST only be enabled if herself authenticated. Thus, TLS resumption MUST only be enabled if
the implementation supports TLS session cache removal. the implementation supports TLS session cache removal. If an EAP
If an EAP server implementing PEAP removes TLS session cache entries server implementing PEAPv2 removes TLS session cache entries of peers
of peers failing PEAP Part 2 authentication, then it MAY skip the failing PEAPv2 Part 2 authentication, then it MAY skip the PEAPv2
PEAP Part 2 conversation entirely after a successful session Part 2 conversation entirely after a successful session resumption,
resumption, successfully terminating the PEAP conversation as successfully terminating the PEAPv2 conversation as described in
described in Section 2.4. Section 2.4.
5.4. Certificate revocation 5.4. Certificate revocation
Since the EAP server is on the Internet during the EAP conversation, Since the EAP server is on the Internet during the EAP conversation,
the server is capable of following a certificate chain or verifying the server is capable of following a certificate chain or verifying
whether the peer's certificate has been revoked. In contrast, the whether the peer's certificate has been revoked. In contrast, the
peer may or may not have Internet connectivity, and thus while it peer may or may not have Internet connectivity, and thus while it can
can validate the EAP server's certificate based on a pre-configured validate the EAP server's certificate based on a pre-configured set
set of CAs, it may not be able to follow a certificate chain or of CAs, it may not be able to follow a certificate chain or verify
verify whether the EAP server's certificate has been revoked. whether the EAP server's certificate has been revoked.
In the case where the peer is initiating a voluntary Layer 2 channel In the case where the peer is initiating a voluntary Layer 2 channel
using PPTP or L2TP, the peer will typically already have Internet using PPTP or L2TP, the peer will typically already have Internet
connectivity established at the time of channel initiation. As a connectivity established at the time of channel initiation. As a
result, during the EAP conversation it is capable of checking for result, during the EAP conversation it is capable of checking for
certificate revocation. certificate revocation.
As part of the TLS negotiation, the server presents a certificate to As part of the TLS negotiation, the server presents a certificate to
the peer. The peer SHOULD verify the validity of the EAP server the peer. The peer SHOULD verify the validity of the EAP server
certificate, and SHOULD also examine the EAP server name presented certificate, and SHOULD also examine the EAP server name presented in
in the certificate, in order to determine whether the EAP server can the certificate, in order to determine whether the EAP server can be
be trusted. Please note that in the case where the EAP trusted. Please note that in the case where the EAP authentication is
authentication is remoted, the EAP server will not reside on the remoted, the EAP server will not reside on the same machine as the
same machine as the authenticator, and therefore the name in the EAP authenticator, and therefore the name in the EAP server's certificate
server's certificate cannot be expected to match that of the cannot be expected to match that of the intended destination. In
intended destination. In this case, a more appropriate test might be this case, a more appropriate test might be whether the EAP server's
whether the EAP server's certificate is signed by a CA controlling certificate is signed by a CA controlling the intended destination
the intended destination and whether the EAP server exists within a and whether the EAP server exists within a target sub-domain.
target sub-domain.
In the case where the peer is attempting to obtain network access, In the case where the peer is attempting to obtain network access, it
it will not have Internet connectivity. The TLS Extensions [TLSEXT] will not have Internet connectivity. The TLS Extensions [RFC3546]
support piggybacking of an Online Certificate Status Protocol (OCSP) support piggybacking of an Online Certificate Status Protocol (OCSP)
response within TLS, therefore can be utilized by the peer in order response within TLS, therefore can be utilized by the peer in order
to verify the validity of server certificate. However, since all TLS to verify the validity of server certificate. However, since not all
implementations do not implement the TLS extensions, it may be TLS implementations implement the TLS extensions, it may be necessary
necessary for the peer to wait to check for certificate revocation for the peer to wait to check for certificate revocation until after
until after Internet access has been obtained. In this case, the Internet access has been obtained. In this case, the peer SHOULD
peer SHOULD conduct the certificate status check immediately upon conduct the certificate status check immediately upon going online
going online and SHOULD NOT send data until it has received a and SHOULD NOT send data until it has received a positive response to
positive response to the status request. If the server certificate the status request. If the server certificate is found to be invalid
is found to be invalid, then the peer SHOULD disconnect. as per client policy, then the peer SHOULD disconnect.
5.5. Separation of the EAP server and the authenticator If the client has a policy to require checking certificate revocation
and it cannot obtain revocation information then it may need to
disallow the use of all or some of the inner methods since some
methods may reveal some sensitive information.
As a result of a complete PEAP Part 1 and Part 2 conversation, the 5.5. Separation of the EAP server and the authenticator
As a result of a complete PEAPv2 Part 1 and Part 2 conversation, the
EAP endpoints will mutually authenticate, and derive a session key EAP endpoints will mutually authenticate, and derive a session key
for subsequent use in link layer security. Since the peer and EAP for subsequent use in link layer security. Since the peer and EAP
client reside on the same machine, it is necessary for the EAP client reside on the same machine, it is necessary for the EAP client
client module to pass the session key to the link layer encryption module to pass the session key to the link layer encryption module.
module.
The situation may be more complex on the Authenticator, which may or The situation may be more complex on the Authenticator, which may or
may not reside on the same machine as the EAP server. In the case may not reside on the same machine as the EAP server. In the case
where the EAP server and the Authenticator reside on different where the EAP server and the Authenticator reside on different
machines, there are several implications for security. Firstly, the machines, there are several implications for security. Firstly, the
mutual authentication defined in PEAP will occur between the peer mutual authentication defined in PEAP will occur between the peer and
and the EAP server, not between the peer and the authenticator. This the EAP server, not between the peer and the authenticator. This
means that as a result of the PEAP conversation, it is not possible means that as a result of the PEAP conversation, it is not possible
for the peer to validate the identity of the NAS or channel server for the peer to validate the identity of the NAS or channel server
that it is speaking to. that it is speaking to.
The second issue is that the session key negotiated between the peer The second issue is that the session key negotiated between the peer
and EAP server will need to be transmitted to the authenticator. and EAP server will need to be transmitted to the authenticator.
Therefore a mechanism needs to be provided to transmit the session Therefore a secure mechanism needs to be provided to transmit the
key from the EAP server to the authenticator or channel server that session key from the EAP server to the authenticator or channel
needs to use the key. The specification of this transit mechanism is server that needs to use the key. The specification of this transit
outside the scope of this document. mechanism is outside the scope of this document.
5.6. Separation of PEAP Part 1 and Part 2 Servers 5.6. Separation of PEAPv2 Part 1 and Part 2 Servers
The EAP server involved in PEAP Part 2 need not necessarily be the The EAP server involved in PEAPv2 Part 2 need not necessarily be the
same as the EAP server involved in PEAP Part 1. For example, a local same as the EAP server involved in PEAPv2 Part 1. For example, a
authentication server or proxy might serve as the endpoint for the local authentication server or proxy might serve as the endpoint for
Part 1 conversation, establishing the TLS channel. Subsequently, the Part 1 conversation, establishing the TLS channel. Subsequently,
once the EAP-Response/Identity has been received within the TLS once the EAP-Response/Identity has been received within the TLS
channel, it can be decrypted and forwarded in cleartext to the channel, it can be decrypted and forwarded in cleartext to the
destination realm EAP server. The rest of the conversation will destination realm EAP server. The rest of the conversation will
therefore occur between the destination realm EAP server and the therefore occur between the destination realm EAP server and the
peer, with the local authentication server or proxy acting as an peer, with the local authentication server or proxy acting as an
encrypting/decrypting gateway. This permits a non-TLS capable EAP encrypting/decrypting gateway. This permits a non-TLS capable EAP
server to participate in the PEAP conversation. server to participate in the PEAPv2 conversation.
Note however that such an approach introduces security Note however that such an approach introduces security
vulnerabilities. Since the EAP Response/Identity is sent in the vulnerabilities. Since the EAP Response/Identity is sent in the
clear between the proxy and the EAP server, this enables an attacker clear between the proxy and the EAP server, this enables an attacker
to snoop the user's identity. It also enables a remote to snoop the user's identity. It also enables a remote environments,
environments, which may be public hot spots or Internet coffee which may be public hot spots or Internet coffee shops, to gain
shops, to gain knowledge of the identity of their users. Since one knowledge of the identity of their users. Since one of the potential
of the potential benefits of PEAP is identity protection, this is benefits of PEAP is identity protection, this is undesirable.
undesirable.
If the EAP method negotiated during PEAP Part 2 does not support If the EAP method negotiated during PEAPv2 Part 2 does not support
mutual authentication, then if the Part 2 conversation is proxied to mutual authentication, then if the Part 2 conversation is proxied to
another destination, the PEAP peer will not have the opportunity to another destination, the PEAP peer will not have the opportunity to
verify the secondary EAP server's identity. Only the initial EAP verify the secondary EAP server's identity. Only the initial EAP
server's identity will have been verified as Part of TLS session server's identity will have been verified as part of TLS session
establishment. establishment.
Similarly, if the EAP method negotiated during PEAP Part 2 is Similarly, if the EAP method negotiated during PEAPv2 Part 2 is
vulnerable to dictionary attack, then an attacker capturing the vulnerable to dictionary attack, then an attacker capturing the
cleartext exchange will be able to mount an offline dictionary cleartext exchange will be able to mount an offline dictionary attack
attack on the password. on the password.
Finally, when a Part 2 conversation is terminated at a different Finally, when a Part 2 conversation is terminated at a different
location than the Part 1 conversation, the Part 2 destination is location than the Part 1 conversation, the Part 2 destination is
unaware that the EAP client has negotiated PEAP. As a result, it is unaware that the EAP client has negotiated PEAPv2. As a result, it is
unable to enforce policies requiring PEAP. Since some EAP methods unable to enforce policies requiring PEAP. Since some EAP methods
require PEAP in order to generate keys or lessen security require PEAPv2 in order to generate keys or lessen security
vulnerabilities, where such methods are in use, such a configuration vulnerabilities, where such methods are in use, such a configuration
may be unacceptable. may be unacceptable.
In summary, PEAP encrypting/decrypting gateway configurations are In summary, PEAPv2 encrypting/decrypting gateway configurations are
vulnerable to attack and SHOULD NOT be used. Instead, the entire vulnerable to attack and SHOULD NOT be used. Instead, the entire
PEAP connection SHOULD be proxied to the final destination, and the PEAPv2 connection SHOULD be proxied to the final destination, and the
subsequently derived master session keys need to be transmitted subsequently derived master session keys need to be transmitted back.
back. This provides end to end protection of PEAP. The T his provides end to end protection of PEAPv2. The specification of
specification of this transit mechanism is outside the scope of this this transit mechanism is outside the scope of this document, but
document, but mechanisms similar to [RFC2548] can be used. These mechanisms similar to [RFC2548] can be used. These steps protect the
steps protects the client from revealing her identity to the remote client from revealing her identity to the remote environment.
environment.
In order to find the proper PEAP destination, the EAP client SHOULD In order to find the proper PEAP destination, the EAP client SHOULD
place a Network Access Identifier (NAI) conforming to [RFC2486] in place a Network Access Identifier (NAI) conforming to [RFC2486] in
the Identity Response. the Identity Response.
There may be cases where a natural trust relationship exists between There may be cases where a natural trust relationship exists between
the (foreign) authentication server and final EAP server, such as on the (foreign) authentication server and final EAP server, such as on
a campus or between two offices within the same company, where there a campus or between two offices within the same company, where there
is no danger in revealing the identity of the station to the is no danger in revealing the identity of the station to the
authentication server. In these cases, using a proxy solution authentication server. In these cases, a proxy solution without end
without end to end protection of PEAP MAY be used. The PEAP to end protection of PEAPv2 MAY be used. If RADIUS is used to
communicate between gateway and EAP server, then the PEAPv2
encrypting/decrypting gateway SHOULD provide support for IPsec encrypting/decrypting gateway SHOULD provide support for IPsec
protection of RADIUS in order to provide confidentiality for the protection of RADIUS in order to provide confidentiality for the
portion of the conversation between the gateway and the EAP server, portion of the conversation between the gateway and the EAP server,
as described in [RFC3162]. as described in [RFC3579].
5.7. Identity verification
5.7. Identity verification
Since the TLS session has not yet been negotiated, the initial Since the TLS session has not yet been negotiated, the initial
Identity request/response occurs in the clear without integrity Identity request/response occurs in the clear without integrity
protection or authentication. It is therefore subject to snooping protection or authentication. It is therefore subject to snooping and
and packet modification. packet modification.
In configurations where all users are required to authenticate with In configurations where all users are required to authenticate with
PEAP and the first portion of the PEAP conversation is terminated at PEAPv2 and the first portion of the PEAPv2 conversation is terminated
a local backend authentication server, without routing by proxies, at a local backend authentication server, without routing by proxies,
the initial cleartext Identity Request/Response exchange is not the initial cleartext Identity Request/Response exchange is not
needed in order to determine the required authentication method(s) needed in order to determine the required authentication method(s) or
or route the authentication conversation to its destination. As a route the authentication conversation to its destination. As a
result, the initial Identity and Request/Response exchange MAY NOT result, the initial Identity and Request/Response exchange MAY NOT
be present, and a subsequent Identity Request/Response exchange MAY be present, and a subsequent Identity Request/Response exchange MAY
occur after the TLS session is established. occur after the TLS session is established.
If the initial cleartext Identity Request/Response has been tampered If the initial cleartext Identity Request/Response has been tampered
with, after the TLS session is established, it is conceivable that with, after the TLS session is established, it is conceivable that
the EAP Server will discover that it cannot verify the peer's claim the EAP Server will discover that it cannot verify the peer's claim
of identity. For example, the peer's userID may not be valid or may of identity. For example, the peer's userID may not be valid or may
not be within a realm handled by the EAP server. Rather than not be within a realm handled by the EAP server. Rather than
attempting to proxy the authentication to the server within the attempting to proxy the authentication to the server within the
correct realm, the EAP server SHOULD terminate the conversation. correct realm, the EAP server SHOULD terminate the conversation.
The PEAP peer can present the server with multiple identities. This The PEAPv2 peer can present the server with multiple identities. This
includes the claim of identity within the initial EAP- includes the claim of identity within the initial EAP-
Response/Identity(MyID) packet, which is typically used to route the Response/Identity (MyID) packet, which is typically used to route the
EAP conversation to the appropriate home backend authentication EAP conversation to the appropriate home backend authentication
server. There may also be subsequent EAP-Response/Identity packets server. There may also be subsequent EAP-Response/Identity packets
sent by the peer once the TLS channel has been established. sent by the peer once the TLS channel has been established.
Note that since the PEAP peer may not present a certificate, it is Note that since the PEAPv2 peer may not present a certificate, it is
not always possible to check the initial EAP-Response/Identity not always possible to check the initial EAP-Response/Identity
against the identity presented in the certificate, as is done in against the identity presented in the certificate, as is done in
[RFC2716]. [RFC2716].
Moreover, it cannot be assumed that the peer identities presented Moreover, it cannot be assumed that the peer identities presented
within multiple EAP-Response/Identity packets will be the same. For within multiple EAP-Response/Identity packets will be the same. For
example, the initial EAP-Response/Identity might correspond to a example, the initial EAP-Response/Identity might correspond to a
machine identity, while subsequent identities might be those of the machine identity, while subsequent identities might be those of the
user. Thus, PEAP implementations SHOULD NOT abort the authentication user. Thus, PEAPv2 implementations SHOULD NOT abort the
just because the identities do not match. However, since the authentication just because the identities do not match. However,
initial EAP-Response/Identity will determine the EAP server handling since the initial EAP-Response/Identity will determine the EAP server
the authentication, if this or any other identity is inappropriate handling the authentication, if this or any other identity is
for use with the destination EAP server, there is no alternative but inappropriate for use with the destination EAP server, there is no
to terminate the PEAP conversation. alternative but to terminate the PEAPv2 conversation.
The protected identity or identities presented by the peer within The protected identity or identities presented by the peer within
PEAP Part 2 may not be identical to the cleartext identity presented PEAPv2 Part 2 may not be identical to the cleartext identity
in PEAP Part 1, for legitimate reasons. In order to shield the presented in PEAPv2 Part 1, for legitimate reasons. In order to
userID from snooping, the cleartext Identity may only provide enough shield the userID from snooping, the cleartext Identity may only
information to enable routing of the authentication request to the provide enough information to enable routing of the authentication
correct realm. For example, the peer may initially claim the request to the correct realm. For example, the peer may initially
identity of "nouser@bigco.com" in order to route the authentication claim the identity of "nouser@bigco.com" in order to route the
request to the bigco.com EAP server. Subsequently, once the TLS authentication request to the bigco.com EAP server. Subsequently,
session has been negotiated, in PEAP Part 2, the peer may claim the once the TLS session has been negotiated, in PEAPv2 Part 2, the peer
identity of "fred@bigco.com". Thus, PEAP can provide protection for may claim the identity of "fred@bigco.com". Thus, PEAPv2 can provide
the user's identity, though not necessarily the destination realm, protection for the user's identity, though not necessarily the
unless the PEAP Part 1 conversation terminates at the local destination realm, unless the PEAPv2 Part 1 conversation terminates
authentication server. at the local authentication server.
As a result, PEAP implementations SHOULD NOT attempt to compare the As a result, PEAPv2 implementations SHOULD NOT attempt to compare the
Identities claimed with Parts 1 and 2 of the PEAP conversation. Identities claimed with Parts 1 and 2 of the PEAPv2 conversation.
Similarly, if multiple Identities are claimed within PEAP Part 2, Similarly, if multiple Identities are claimed within PEAPv2 Part 2,
these SHOULD NOT be compared. An EAP conversation may involve more these SHOULD NOT be compared. An EAP conversation may involve more
than one EAP authentication method, and the identities claimed for than one EAP authentication method, and the identities claimed for
each of these authentications could be different (e.g. a machine each of these authentications could be different (e.g. a machine
authentication, followed by a user authentication). authentication, followed by a user authentication).
5.8. Man-in-the-middle protection 5.8. Man-in-the-middle attack protection
TLS protection can address a number of weaknesses in the EAP method;
as well as EAP protocol weaknesses listed in the abstract and
introduction sections in this document.
Hence, the recommended solution is to always deploy authentication
methods with protection of PEAPv2.
if a deployment chooses to allow a EAP method protected by PEAP
without protection of PEAP or IPsec at the same time, then this opens
up a possibility of a man-in-the-middle attack.
If an EAP method protected by PEAP is also deployed without
protection (from PEAP or IPSEC), and if the same credential is
allowed in both cases, then a man-in-the-middle attack is possible.
A man-in-the-middle can spoof the client to authenticate to it A man-in-the-middle can spoof the client to authenticate to it
instead of the real EAP server; and forward the authentication to instead of the real EAP server; and forward the authentication to the
the real server over a protected tunnel. Since the attacker has real server over a protected tunnel. Since the attacker has access to
access to the keys derived from the tunnel, it can gain access to the keys derived from the tunnel, it can gain access to the network.
the network.
The compound binding draft [CompoundBinding] identifies a number of PEAP version 2 prevents this attack by using the keys generated by
solutions to this attack. the inner EAP method in the crypto-binding exchange described in
protected termination section. This attack is not prevented if the
inner EAP method does not generate keys or if the keys generated by
the inner EAP method can be compromised.
The preferred solution is to deploy the authentication method with Alternatively, the attack can also be thwarted if the inner EAP
protection from PEAP or IPSEC. Protection can address the man-in- method can signal to the peer that the packets are being sent within
the-middle attack; and in addition can address EAP method and EAP the tunnel. In most cases this may require modification to the inner
protocol weaknesses listed in the abstract and introduction sections EAP method. In order to allow for these implementations, PEAPv2
in this document. implementations should inform inner EAP methods that the EAP method
is being protected by a PEAPv2 tunnel.
Another solution is to use knowledge known only to the real peers to Since all sequence negotiations and exchanges are protected by TLS
verify that there is no man-in-the-middle. A number of protocols channel, they are immune to snooping and MITM attacks with the use of
derive keys for encryption, and these keys are not known to the man- Crypto-Binding TLV. To make sure the same parties are involved tunnel
in-the-middle. These keys can be used in the binding phase exchange establishment and previous inner method, before engaging the next
described in compound binding [compoundbinding] draft to detect man- method to sent more sensitive information, both peer and server MUST
in-the-middle. PEAP implementations MUST support the binding phase use the Crypto-Binding TLV between methods to check the tunnel
exchange using compound MACs as described in the section 4.2 of the integrity. If the Crypto-Binding TLV failed validation, they SHOULD
compound binding draft[CompoundBinding]. stop the sequence and terminate the tunnel connection, to prevent
more sensitive information being sent in subsequent methods.
Another solution is for EAP methods to securely signal to peers that 5.9. Cleartext forgeries
they are inside the protected channel. This may require changes to
the EAP protocol. In order to allow EAP methods to implement secure
signaling, PEAP implementations SHOULD inform the EAP methods that
they are being protected by PEAP.
6. IANA Considerations As described in [RFC2284bis], EAP Success and Failure packets are not
authenticated, so that they may be forged by an attacker without fear
of detection. Forged EAP Failure packets can be used to convince an
EAP peer to disconnect. Forged EAP Success and Failure packets may be
used to convince a peer to disconnect; or convince a peer to access
the network even before authentication is complete, resulting in
denial of service for the peer.
By supporting encrypted, authenticated and integrity protected
success/failure indications, PEAPv2 provides protection against these
attacks.
When the peer responds with the first PEAP packet; and the EAP server
receives the first PEAPv2 packet from the peer, both MUST silently
discard all clear text EAP messages unless both the PEAPv2 peer and
server have indicated success or failure or error using a protected
error or protected termination mechanism. The success/failure
decisions sent by a protected mechanism indicate the final decision
of the EAP authentication conversation. After success/failure has
been indicated by a protected mechanism, the PEAPv2 client can
process unprotected EAP success and EAP failure message; however MUST
ignore any unprotected EAP success or failure messages where the
decision does not match the decision of the protected mechanism.
[RFC2284bis] states that an EAP Success or EAP Failure packet
terminates the EAP conversation, so that no response is possible.
Since EAP Success and EAP Failure packets are not retransmitted, if
the final packet is lost, then authentication will fail. As a
result, where packet loss is expected to be non-negligible,
unacknowledged success/failure indications lack robustness.
As a result, a EAP server SHOULD send a clear text EAP success or
EAP-failure packet after the protected success or failure packet or
TLS alert. The peer MUST NOT require the clear text EAP Success or
EAP Failure if it has received the protected success or failure or
TLS alert. For more details, refer to [RFC228bis], Section 4.2.
5.10. TLS Ciphersuites
Anonymous ciphersuites are vulnerable to man-in-the-middle attacks,
and SHOULD NOT be used with PEAPv2, unless the EAP methods inside
PEAPv2 can address the man-in-the-middle attack or unless the man-in-
the-middle attack can be addressed by mechanisms external to PEAPv2.
5.11. Denial of service attacks
Denial of service attacks are possible if the attacker can insert or
modify packets in the authentication channel. The attacker can
modify unprotected fields in the PEAP packet such as the EAP protocol
or PEAP version number. This can result in a denial of service
attack. It is also possible for the attacker to modify protected
fields in a packet to cause decode errors resulting in a denial of
service. In these ways the attacker can prevent access for peers
connecting to the network.
Denial of service attacks with multiplier impacts are more
interesting than the ones above. It is possible to multiply the
impact by creating a large number of TLS sessions with the EAP
server.
5.12. Security Claims
Intended use: Wireless or Wired networks, and over
the Internet, where physical security
cannot be assumed.
Auth. mechanism: Use arbitrary EAP and TLS authentication
mechanisms for authentication of the
client and server.
Ciphersuite negotiation: Yes.
Mutual authentication: Yes. Depends on the type of EAP method
used within the tunnel and the type of
authentication used within TLS.
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes
Key strength: Variable
Dictionary attack prot: Not susceptible.
Fast reconnect: Yes
Crypt. binding: Yes.
Acknowledged S/F: Yes
Session independence: Yes.
Fragmentation: Yes
PEAPv2 derives keys by combining keys from TLS and the inner EAP
methods. It should be noted that the use of TLS ciphersuites with a
particular key lengths does not guarantee that the key strength of
the keys will be equivalent to the length. The key exchange
mechanisms (eg. RSA or Diffie-Hellman) used must provide sufficient
security or they will be the weakest link. For example RSA key sizes
with a modulus of 1024 bits provides less than 128 bits of security,
this may provide sufficient key strength for some applications and
not for others. See [PKLENGTH] for a detailed analysis of
determining the public key strengths used to exchange symmetric keys.
6. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the EAP Authority (IANA) regarding registration of values related to the EAP
protocol, in accordance with BCP 26, [RFC2434]. protocol, in accordance with BCP 26, [RFC2434].
There is one name space in EAP-TLV that require registration: TLV- There is one name space in EAP-TLV that requires registration: PEAPv2
Types. TLV-Types.
6.1. Definition of Terms 6.1. Definition of Terms
The following terms are used here with the meanings defined in BCP The following terms are used here with the meanings defined in BCP
26: 26: "name space", "assigned value", "registration".
"name space", "assigned value", "registration".
The following policies are used here with the meanings defined in The following policies are used here with the meanings defined in BCP
BCP
26: "Private Use", "First Come First Served", "Expert Review", 26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IETF Consensus", "Standards Action". "Specification Required", "IETF Consensus", "Standards Action".
6.2. Recommended Registration Policies 6.2. Recommended Registration Policies
For registration requests where a Designated Expert should be For "Designated Expert with Specification Required", the request is
consulted, the responsible IESG area director should appoint the posted to the EAP WG mailing list (or, if it has been disbanded, a
Designated Expert. For Designated Expert with Specification successor designated by the Area Director) for comment and review,
Required, the request is posted to the EAP WG mailing list (or, if and MUST include a pointer to a public specification. Before a period
it has been disbanded, a successor designated by the Area Director) of 30 days has passed, the Designated Expert will either approve or
for comment and review, and MUST include a pointer to a public deny the registration request and publish a notice of the decision to
specification. Before a period of 30 days has passed, the Designated the EAP WG mailing list or its successor. A denial notice must be
Expert will either approve or deny the registration request and justified by an explanation and, in the cases where it is possible,
publish a notice of the decision to the EAP WG mailing list or its concrete suggestions on how the request can be modified so as to
successor. A denial notice must be justified by an explanation and, become acceptable.
in the cases where it is possible, concrete suggestions
on how the request can be modified so as to become acceptable.
For registration requests requiring Expert Review, the EAP mailing EAP-TLVs have a 14-bit field, of which 0-10 have been allocated.
list should be consulted. If the EAP mailing list is no longer
operational, an alternative mailing list may be designated by the
responsible IESG Area Director.
EAP-TLVs have a 14-bit field, of which 1-6 have been allocated. Additional EAP-TLV type codes may be allocated following Designated
Expert with Specification Required [RFC2434].
7. Normative references 7. References
[RFC1321] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", 7.1. Normative references
RFC
1321, April 1992.
[RFC1570] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm",
January RFC 1321, April 1992.
1994.
[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
STD Requirement Levels", BCP 14, RFC 2119, March 1997.
51, RFC 1661, July 1994.
[RFC1962] D. Rand. "The PPP Compression Control Protocol", RFC [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
1962, 2246, November 1998.
Novell, June 1996.
[RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
June 2486, January 1999.
1996.
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, Resource Identifiers (URI): Generic Syntax", RFC 2396, August
August 1998.
1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3546] Blake-Wilson, S., et al. "TLS Extensions", RFC 3546, June
Requirement Levels", BCP 14, RFC 2119, March 1997. 2003.
[RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC [RFC2284bis]
2246, November 1998. Blunk, L. et al., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-06.txt, Internet draft (work in
progress), October 2003.
[RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 7.2. Informative references
Protocol (EAP)", RFC 2284, March 1998.
[RFC2486] Aboba, B., Beadles, M., "The Network Access Identifier", [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June
RFC 2486, January 1999. 1996.
[TLSEXT] Blake-Wilson, S., et al. "TLS Extensions", Internet draft [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
(work in progress), draft-ietf-tls-extensions-06.txt, Feb Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August
2003. 1996.
[IEEE8021X] [RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
IEEE Standards for Local and Metropolitan Area Networks: Version 2 (DESE-bis)", RFC 2419, September 1998.
Port
based Network Access Control, IEEE Std 802.1X-2001, June
2001.
[CompoundBinding] [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)",
Puthenkulam, J., Lortz, V., Palekar, A., Simon, D., RFC 2420, September 1998.
"The Compound Authentication Binding Problem", March 2003;
draft-puthenkulam-eap-binding-02.txt.
8. Informative references [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
Version 2 (DESE-bis)", RFC 2419, September 1998. RFC2548, March 1999.
[RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
(3DESE)", RFC 2716, October 1999.
RFC 2420, September 1998.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption
RFC2548, March 1999. (MPPE) Protocol", RFC 3078, March 2001.
[RFC2716] Aboba, B., Simon, D., "PPP EAP TLS Authentication [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Protocol", Encryption (MPPE)", RFC 3079, March 2001.
RFC 2716, October 1999.
[RFC3078] Pall, G., Zorn, G., "Microsoft Point-to-Point Encryption [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS
(MPPE) Protocol", RFC 3078, March 2001. PUB 46 (January 1977).
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to- [IEEE80211]
Point Information technology - Telecommunications and information
Encryption (MPPE)", RFC 3079, March 2001. exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications,
IEEE Std. 802.11-1999, 1999.
[FIPSDES] National Bureau of Standards, "Data Encryption Standard", [MODES] National Bureau of Standards, "DES Modes of Operation", FIPS
FIPS PUB 81 (December 1980).
PUB 46 (January 1977).
[IEEE80211] [PEAPv0] Kamath, V., Palekar, A. and M. Wodrich, "Microsoft's PEAP
Information technology - Telecommunications and version 0 (Implementation in Windows XP SP1)", draft-kamath-
information pppext-peapv0-00.txt, Internet draft (work in progress), July
exchange between systems - Local and metropolitan area 2002.
networks - Specific Requirements Part 11: Wireless LAN
Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications,
IEEE Std. 802.11-1999, 1999.
[MODES] National Bureau of Standards, "DES Modes of Operation", [PKLENGTH]
FIPS H. Orman and P. Hoffman, "Determining Strengths For Public
PUB 81 (December 1980). Keys Used For Exchanging Symmetric Keys", draft-orman-public-
key-lengths-05.txt, Internet Draft (work in progress),
December 2002.
[PEAP version 0] [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for EAP", RFC 3579,
Kamath, V., Palekar, A., Wodrich, M., September 2003.
"Microsoft's PEAP version 0 (Implementation in Windows XP
SP1)",
draft-kamath-pppext-peapv0-00.txt.
9. Appendix A - Examples [CompoundBinding]
Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon, "The
Compound Authentication Binding Problem", draft-puthenkulam-
eap-binding-03.txt, Internet Draft (work in progress), May
2003.
In the case where an identity exchange occurs within PEAP Part 1, [IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEEE Std 802.1X-2001, June 2001.
Appendix A - Examples
A.1 Cleartext Identity Exchange
In the case where an identity exchange occurs within PEAPv2 Part 1,
the conversation will appear as follows: the conversation will appear as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route the
authentication request to EAP server, instead of the full user
identity.
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(PEAP Start, S bit set) (PEAP Start, S bit set)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=1 EAP-Type=PEAP, V=2
(TLS client_hello)-> (TLS client_hello)->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS server_hello, (TLS server_hello,
TLS certificate, TLS certificate,
[TLS server_key_exchange,] [TLS server_key_exchange,]
[TLS certificate_request,] [TLS certificate_request,]
TLS server_hello_done) TLS server_hello_done)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
([TLS certificate,] ([TLS certificate,]
TLS client_key_exchange, TLS client_key_exchange,
[TLS certificate_verify,] [TLS certificate_verify,]
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) -> TLS finished) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) TLS finished,
EAP-Response/ EAP-Request/EAP-Type=EAP-TLV
EAP-Type=PEAP -> [EAP-Payload-TLV[EAP-Request/
Identity]])
TLS channel established // identity protected by TLS. EAP-TLV packet does not include an EAP-
(messages sent within the TLS channel) header.
<- EAP-Request/ TLS channel established (EAP messages sent within TLS channel
Identity encapsulated in EAP-TLV packets without EAP header)
EAP-Response/
Identity (MyID2) ->
<- EAP-Request/
EAP-Type=X
EAP-Response/ EAP-TLV [EAP-Payload-TLV
EAP-Type=X or NAK -> [EAP-Response/Identity (MyID2)]]]->
<- EAP-Request/ <- EAP-TLV [EAP-Payload-TLV
EAP-Type=X [EAP-Request/EAP-Type=X]]
EAP-Response/
EAP-Type=X ->
<- EAP-Request/
EAP-Type=EAP-TLV
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP EAP-TLV [EAP-Payload-TLV
methods=1, Result TLV (Success), Method_Identity_TLV (EAP-Type=X, [EAP-Response/EAP-Type=X]] ->
EAP-Type-Version=0, keylengthusedforderivation,
ClientIdentityLength= sizeof(MyID2), MyID2, ServerIdentityLength=0,
Media-type=19), Method_Identity_TLV (EAP-Type=PEAP, EAP-Type-
Version=2, keylengthusedforderivation, ClientIdentityLength=
sizeof(MyID1), MyID1, ServerIdentityLength=0, Media-type=19),
CompoundMAC (over entire EAP TLV inside the tunnel including EAP-
header))
EAP-Response/
EAP-Type=EAP-TLV
Result=Success
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP
methods=1, Result TLV (Success), Method_Identity_TLV (EAP-Type=X,
EAP-Type-Version=0, keylengthusedforderivation,
ClientIdentityLength= sizeof(MyID2), MyID2, ServerIdentityLength=0,
Media-type=19), Method_Identity_TLV (EAP-Type=PEAP, EAP-Type-
Version=2, keylengthusedforderivation, ClientIdentityLength=
sizeof(MyID1), MyID1, ServerIdentityLength=0, Media-type=19),
CompoundMAC (over entire EAP TLV inside the tunnel including EAP-
header))
-> // Protected termination
<- EAP-TLV [Result TLV (Success),
Crypto-Binding-TLV (Version=0,
received-version=2, Nonce, B1_MAC),
Intermediate-Result-TLV (Success)]
EAP-TLV [Result-TLV (Success),
Intermediate-Result-TLV (Success),
Crypto-Binding-TLV (Version=0,
received-version=2,Nonce, B2_MAC)]->
TLS channel torn down TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success
Where all peers are known to support PEAP, a non-certificate A.2 No cleartext Identity Exchange
Where all peers are known to support PEAPv2, a non-certificate
authentication is desired for the client and the PEAP Part 1 authentication is desired for the client and the PEAP Part 1
conversation is carried out between the peer and a local EAP server, conversation is carried out between the peer and a local EAP server,
the cleartext identity exchange may be omitted and the conversation the cleartext identity exchange may be omitted and the conversation
appears as follows: appears as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=1 EAP-Type=PEAP, V=2
(PEAP Start, S bit set) (PEAP Start, S bit set)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=1 EAP-Type=PEAP, V=2
(TLS client_hello)-> (TLS client_hello)->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS server_hello, (TLS server_hello,
TLS certificate, TLS certificate,
[TLS server_key_exchange,] [TLS server_key_exchange,]
[TLS certificate_request,] [TLS certificate_request,]
TLS server_hello_done) TLS server_hello_done)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
([TLS certificate,] ([TLS certificate,]
TLS client_key_exchange, TLS client_key_exchange,
[TLS certificate_verify,] [TLS certificate_verify,]
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) -> TLS finished) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) TLS finished,
EAP-Response/ EAP-TLV [EAP-Payload-TLV
EAP-Type=PEAP, V=2 -> (EAP-Request/Identity)])
TLS channel established TLS channel established
(messages sent within the TLS channel) (messages sent within the TLS channel)
<- EAP-Request/ EAP-TLV [EAP-Payload-TLV
Identity [EAP-Response/Identity (MyID)]] ->
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=X
EAP-Response/
EAP-Type=X or NAK ->
<- EAP-Request/ <- EAP-TLV [EAP-Payload-TLV
EAP-Type=X [EAP-Type=EAP-Request/
EAP-Response/ EAP-Type=X]]
EAP-Type=X ->
<- EAP-Request/
EAP-Type=EAP-TLV
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP EAP-TLV [EAP-Payload-TLV
methods=<number>, Result TLV (Success), Method_Identity_TLV (for [EAP-Response/EAP-Type=X
each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), or NAK] ->
CompoundMAC (over entire EAP TLV packet inside the tunnel including <- EAP-TLV [EAP-Payload-TLV
EAP-header)) [EAP-Request/EAP-Type=X]]
EAP-Response/ EAP-TLV [EAP-Payload-TLV [EAP-Response/
EAP-Type=EAP-TLV EAP-Type=X]] ->
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP
methods=<number>, Result TLV (Success), Method_Identity_TLV (for // Protected success
each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), <- EAP-TLV [Crypto-Binding-TLV=
CompoundMAC (over entire EAP TLV packet inside the tunnel including (Version=0, Received-version=2,
EAP-header)) Nonce, B1_MAC),
Intermediate-Result-TLV(Success),
Result TLV (Success)]
EAP-TLV [Crypto-Binding-TLV=
(Version=0,Received-version=2,
Nonce, B2_MAC),
Intermediate-Result-TLV (Success),
Result TLV (Success)]->
TLS channel torn down TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success
Where all peers are known to support PEAP, where client certificate A.3 Client certificate authentication with identity privacy
authentication is desired and the PEAP Part 1 conversation is
Where all peers are known to support PEAPv2, where client certificate
authentication is desired and the PEAPv2 Part 1 conversation is
carried out between the peer and a local EAP server, the cleartext carried out between the peer and a local EAP server, the cleartext
identity exchange may be omitted and the conversation appears as identity exchange may be omitted and the conversation appears as
follows: follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(PEAP Start, S bit set) (PEAP Start, S bit set)
skipping to change at page 41, line 32 skipping to change at page 59, line 45
[TLS server_key_exchange,] [TLS server_key_exchange,]
TLS server_hello_done) TLS server_hello_done)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS client_key_exchange, (TLS client_key_exchange,
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) -> TLS finished) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) TLS finished,TLS Hello-Request)
EAP-Response/
EAP-Type=PEAP, V=2 ->
TLS channel established
(messages sent within the TLS channel)
<- EAP-Request/
EAP-Type=PEAP, V=2
(TLS hello_request)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS client_hello)-> (TLS client_hello)->
TLS channel established
(messages sent within the TLS channel)
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS server_hello, (TLS server_hello,
TLS certificate, TLS certificate,
[TLS server_key_exchange,] [TLS server_key_exchange,]
[TLS certificate_request,] [TLS certificate_request,]
TLS server_hello_done) TLS server_hello_done)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
([TLS certificate,] ([TLS certificate,]
skipping to change at page 42, line 8 skipping to change at page 60, line 18
[TLS server_key_exchange,] [TLS server_key_exchange,]
[TLS certificate_request,] [TLS certificate_request,]
TLS server_hello_done) TLS server_hello_done)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
([TLS certificate,] ([TLS certificate,]
TLS client_key_exchange, TLS client_key_exchange,
[TLS certificate_verify,] [TLS certificate_verify,]
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) -> TLS finished) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) TLS finished, EAP-TLV
EAP-Response/ [Crypto-binding-TLV (version=0,
Received-version=2, Nonce,
B1_MAC),
Result-TLV (Success)])
EAP-Type=PEAP, V=2 -> // packet format within the TLS channel
<- EAP-Request/
EAP-Type=EAP-TLV EAP-TLV [
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP Crypto-Binding-TLV=(Version=0,
methods=<number>, Result TLV (Success), Method_Identity_TLV (for Received-version=2,
each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), Nonce, B2_MAC),
CompoundMAC (over entire EAP TLV packet inside the tunnel including Result TLV (Success)]
EAP-header))
EAP-Response/
EAP-Type=EAP-TLV
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP
methods=<number>, Result TLV (Success), Method_Identity_TLV (for
each successful EAP-Type inside PEAP), Method_Identity_TLV (for
PEAP), CompoundMAC (over entire EAP TLV packet inside the tunnel
including EAP-header))
TLS channel torn down TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success
A.4 Fragmentation and Reassembly
In the case where the PEAP fragmentation is required, the In the case where the PEAP fragmentation is required, the
conversation will appear as follows: conversation will appear as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID) -> Identity (MyID) ->
<- EAP-Request/ <- EAP-Request/
skipping to change at page 43, line 32 skipping to change at page 61, line 44
TLS client_key_exchange, TLS client_key_exchange,
[TLS certificate_verify,] [TLS certificate_verify,]
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) TLS finished)
(Fragment 1: L, M bits set)-> (Fragment 1: L, M bits set)->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(Fragment 2)-> (Fragment 2)->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) TLS finished, EAP-TLV
[EAP-Payload-TLV[
EAP-Response/ EAP-Request/Identity]])
EAP-Type=PEAP, V=2 ->
TLS channel established TLS channel established
(messages sent within the TLS channel) (messages sent within the TLS channel)
<- EAP-Request/ EAP-TLV
Identity [EAP-Payload-TLV
EAP-Response/ [EAP-Response/Identity(myID)]] ->
Identity (MyID) ->
<- EAP-Request/
EAP-Type=X
EAP-Response/
EAP-Type=X or NAK ->
<- EAP-Request/ <- EAP-TLV [ EAP-Payload-TLV
EAP-Type=X [EAP-Request/EAP-Type=X]]
EAP-Response/
EAP-Type=X -> EAP-TLV [EAP-Payload-TLV
<- EAP-Request/ [EAP-Response/EAP-Type=X or NAK]]->
EAP-Type=EAP-TLV
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP <- EAP-TLV [ EAP-Payload-TLV
methods=<number>, Result TLV (Success), Method_Identity_TLV (for [EAP-Request/EAP-Type=X]]
each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP),
CompoundMAC (over entire EAP TLV packet inside the tunnel including EAP-TLV [EAP-Payload-TLV
EAP-header)) [EAP-Response/EAP-Type=X] ->
EAP-Response/
EAP-Type=EAP-TLV <- EAP-TLV [Crypto-Binding-TLV
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP =(Version=0, Received-Version=2,
methods=<number>, Result TLV (Success), Method_Identity_TLV (for Nonce, B1_MAC),
each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP), Intermediate-Result-TLV(Success),
CompoundMAC (over entire EAP TLV packet inside the tunnel including Result TLV (Success)]
EAP-header))
EAP-TLV [
Crypto-Binding-TLV=(Version=0,
Received-Version=2,Nonce, B2_MAC),
Result TLV (Success),
Intermediate-Result-TLV (Success)] ->
TLS channel torn down TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success
In the case where the server authenticates to the client A.5 Server authentication fails in Part 2
successfully in PEAP Part 1, but the client fails to authenticate to
the server in PEAP Part 2, the conversation will appear as follows: In the case where the server authenticates to the client successfully
in PEAPv2 Part 1, but the client fails to authenticate to the server
in PEAPv2 Part 2, the conversation will appear as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID) -> Identity (MyID) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(PEAP Start, S bit set) (PEAP Start, S bit set)
skipping to change at page 45, line 5 skipping to change at page 63, line 27
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
([TLS certificate,] ([TLS certificate,]
TLS client_key_exchange, TLS client_key_exchange,
[TLS certificate_verify,] [TLS certificate_verify,]
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) -> TLS finished) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) TLS finished, EAP-TLV
[EAP-Payload-TLV
EAP-Response/ [EAP-Request/Identity]])
EAP-Type=PEAP, V=2 ->
TLS channel established TLS channel established
(messages sent within the TLS channel) (messages sent within the TLS channel)
<- EAP-Request/ EAP-TLV [EAP-Payload-TLV
Identity [EAP-Response/Identity (MyID)]] ->
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=X
EAP-Response/
EAP-Type=X or NAK -> <- EAP-TLV [EAP-Payload-TLV
[EAP-Request/EAP-Type=X]]
<- EAP-Request/ EAP-TLV [EAP-Payload
EAP-Type=X [EAP-Response/EAP-Type=X
EAP-Response/ or NAK]] ->
EAP-Type=X -> <- EAP-TLV [EAP-Payload
<- EAP-Request/ [EAP-Request/EAP-Type=X]]
EAP-Type=EAP-TLV
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP
methods=<number>, Result TLV (Failure), Method_Identity_TLV (for
each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP),
CompoundMAC (over entire EAP TLV packet inside the tunnel including
EAP-header))
// Compound MAC calculated using TLS key material only.
EAP-Response/
EAP-Type=EAP-TLV
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP
methods=<number>, Result TLV (Failure), Method_Identity_TLV (for
each EAP-Type inside PEAP), Method_Identity_TLV (for PEAP),
CompoundMAC (over entire EAP TLV packet inside the tunnel including
EAP-header))
Result=Failure -> EAP-TLV [EAP-Payload
[EAP-Response/
EAP-Type=X]] ->
<- EAP-TLV [Crypto-Binding-TLV
(Version=0, Received-Version=2,
Nonce, B1_MAC),
Intermediate-Result-TLV (Failure),
Result TLV (Failure)]
EAP-TLV [Crypto-Binding-TLV
(Version=0, Received-version=2,
Nonce, B2_MAC),
Result TLV (Failure),
Intermediate-Result-TLV (Failure)]
(TLS session cache entry flushed) (TLS session cache entry flushed)
TLS channel torn down TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Failure <- EAP-Failure
A.6 Server authentication fails in Part 1
In the case where server authentication is unsuccessful in PEAP Part In the case where server authentication is unsuccessful in PEAP Part
1, the conversation will appear as follows: 1, the conversation will appear as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID) -> Identity (MyID) ->
<- EAP-Request/ <- EAP-Request/
skipping to change at page 46, line 29 skipping to change at page 65, line 4
TLS server_hello_done) TLS server_hello_done)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS client_key_exchange, (TLS client_key_exchange,
[TLS certificate_verify,] [TLS certificate_verify,]
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) -> TLS finished) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) TLS finished, EAP-TLV
EAP-Response/ [EAP-Payload-TLV [
EAP-Type=PEAP, V=2 EAP-Request/Identity]])
(TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=PEAP, V=2
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS Alert message) -> (TLS Alert message) ->
<- EAP-Failure <- EAP-Failure
(TLS session cache entry flushed) (TLS session cache entry flushed)
A.7 Session resume success
In the case where a previously established session is being resumed, In the case where a previously established session is being resumed,
the EAP server supports TLS session cache flushing for unsuccessful the EAP server supports TLS session cache flushing for unsuccessful
PEAP Part 2 authentications and both sides authenticate PEAPv2 Part 2 authentications and both sides authenticate
successfully, the conversation will appear as follows: successfully, the conversation will appear as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID) -> Identity (MyID) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP,V=2 EAP-Type=PEAP,V=2
skipping to change at page 47, line 19 skipping to change at page 65, line 43
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS server_hello, (TLS server_hello,
TLS change_cipher_spec TLS change_cipher_spec
TLS finished) TLS finished)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) -> TLS finished) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=EAP-TLV EAP-Type=EAP-TLV
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP Result TLV (Success)
methods=0, Result TLV (Success), Method_Identity_TLV (for PEAP),
CompoundMAC (over entire EAP TLV packet inside the tunnel including
EAP-header))
// Compound MAC calculated using TLS keys since there were no inner // Compound MAC calculated using TLS keys since there were no inner
EAP methods. EAP methods.
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLV EAP-Type=EAP-TLV
Crypto-Binding-TLV=(Version=0, Nounce, Number of inner EAP Crypto-Binding-TLV=(Version=0, Nonce, B2_MAC),
methods=0, Result TLV (Success), Method_Identity_TLV (for PEAP), Result TLV (Success)->
CompoundMAC (over entire EAP TLV packet inside the tunnel including
EAP-header)) .
->
TLS channel torn down TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success
A.8 Session resume failure
In the case where a previously established session is being resumed, In the case where a previously established session is being resumed,
and the server authenticates to the client successfully but the and the server authenticates to the client successfully but the
client fails to authenticate to the server, the conversation will client fails to authenticate to the server, the conversation will
appear as follows: appear as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID) -> Identity (MyID) ->
<- EAP-Request/ <- EAP-Request/
EAP-Request/ EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS Start) (PEAP Start)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS client_hello) -> (TLS client_hello) ->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS server_hello, (TLS server_hello,
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) TLS finished)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) -> TLS finished) ->
<- EAP-Request <- EAP-Request
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS Alert message) (TLS Alert message)
EAP-Response EAP-Response
EAP-Type=PEAP, V=2 -> EAP-Type=PEAP, V=2 ->
<- EAP-Failure <- EAP-Failure
(TLS session cache entry flushed) (TLS session cache entry flushed)
A.9 Session resume failure
In the case where a previously established session is being resumed, In the case where a previously established session is being resumed,
and the server authentication is unsuccessful, the conversation will and the server authentication is unsuccessful, the conversation will
appear as follows: appear as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID) -> Identity (MyID) ->
<- EAP-Request/ <- EAP-Request/
EAP-Request/ EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS Start) (PEAP Start)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS client_hello)-> (TLS client_hello)->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS server_hello, (TLS server_hello,
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) TLS finished)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS change_cipher_spec, (TLS change_cipher_spec,
TLS finished) TLS finished)
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS Alert message) -> (TLS Alert message) ->
(TLS session cache entry flushed)
(TLS session cache entry flushed)
<- EAP-Failure <- EAP-Failure
A.10 PEAP version negotiation
In the case where the peer and authenticator have mismatched PEAP In the case where the peer and authenticator have mismatched PEAP
versions (e.g. the peer has a pre-standard implementation with versions (e.g. the peer has a pre-standard implementation with
version 0, and the authenticator has an implementation compliant version 0, and the authenticator has an implementation compliant with
with this specification), the session is being resumed, but the this specification), the conversation will occur as follows:
authentication is unsuccessful, the conversation will occur as
follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID) -> Identity (MyID) ->
<- EAP-Request/ <- EAP-Request/
EAP-Request/ EAP-Request/
EAP-Type=PEAP, V=2 EAP-Type=PEAP, V=2
(TLS Start) (PEAP Start)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=0 EAP-Type=PEAP, V=0
(TLS client_hello)-> (TLS client_hello)->
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=0 EAP-Type=PEAP, V=0
(TLS server_hello, (TLS server_hello,
TLS change_cipher_spec, TLS change_cipher_spec,
TLS finished) TLS finished)
//conversation continued using pre-standard PEAP version 0
A.11 Sequences of EAP methods
Where PEAPv2 is negotiated, with a sequence of EAP method X followed
by method Y, the conversation will occur as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=0 Identity (MyID1) ->
(TLS change_cipher_spec,
TLS finished)
<- EAP-Request/ <- EAP-Request/
EAP-Type=PEAP, V=0 EAP-Type=PEAP, V=2
(PEAP Start, S bit set)
EAP-Response/ EAP-Response/
EAP-Type=PEAP, V=0 EAP-Type=PEAP, V=2
(TLS Alert message) -> (TLS client_hello)->
(TLS session cache entry flushed) <- EAP-Request/
EAP-Type=PEAP, V=2
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=PEAP, V=2
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=PEAP, V=2
(TLS change_cipher_spec,
TLS finished, EAP-TLV
<- EAP-Failure [EAP-Payload-TLV[
EAP-Request/Identity]])
10. Acknowledgments and Contributions TLS channel established
(messages sent within the TLS channel)
Thanks to Jan-Ove Larsson, Magnus Nystrom of RSA Security; Bernard EAP-TLV [EAP-Payload-TLV
Aboba, Vivek Kamath, Stephen Bensley, Narendra Gidwani of Microsoft; [EAP-Response/Identity]] ->
Joe Salowey, Hao Zhou, Ilan Frenkel, Nancy Cam-Winget of Cisco;
Hakan Andersson of RSA; Jose Puthenkulam of Intel for their <- EAP-TLV [EAP-Payload-TLV
contributions and critiques. [EAP-Request/EAP-Type=X]]]
EAP-TLV [EAP-Payload-TLV
[EAP-Response/EAP-Type=X]] ->
<- EAP-TLV [ EAP-Payload-TLV
[EAP-Request/EAP-Type=X]]
EAP-TLV [EAP-Payload-TLV
[EAP-Response/EAP-Type=X]]->
<- EAP-TLV [EAP Payload TLV [EAP-Type=Y],
(Intermediate Result TLV (Success),
Crypto-Binding-TLV
(Version=0, Received-version=2,
Nonce, B1_MAC))]
// Next EAP conversation started after successful completion of
previous method X. The intermediate-status and crypto-binding TLVs
are sent in next packet to minimize round-trips. In this example,
identity request is not sent before negotiating EAP-Type=Y.
EAP-TLV [EAP-Payload-TLV [EAP-Type=Y],
(Intermediate Result TLV (Success),
Crypto-Binding-TLV (Version=0,
Received-version=2, Nonce, B2_MAC))]->
// Compound MAC calculated using Keys generated from
EAP methods X and the TLS tunnel.
<- EAP-TLV [EAP Payload TLV [
EAP-Type=Y]]
EAP-TLV[EAP Payload TLV
[EAP-Type=Y]] ->
<- EAP-TLV [Result-TLV (Success),
Intermediate Result TLV (Success),
Crypto-Binding-TLV
(Version=0, Received-version=2,
Nonce, B1_MAC))]
EAP-TLV [(Result-TLV (Success),
Intermediate Result TLV (Success),
Crypto-Binding-TLV (Version=0,
Received-version=2, Nonce, B2_MAC))]->
// Compound MAC calculated using Keys generated from EAP methods X
and Y and the TLS tunnel. // Compound Keys generated using Keys
generated from EAP methods X and Y; and the TLS tunnel.
TLS channel torn down (messages sent in cleartext)
<- EAP-Success
Acknowledgments
Thanks to Hakan Andersson, Jan-Ove Larsson and Magnus Nystrom of RSA
Security; Bernard Aboba, Vivek Kamath, Stephen Bensley and Narendra
Gidwani of Microsoft; Ilan Frenkel and Nancy Cam-Winget of Cisco;
Jose Puthenkulam of Intel for their contributions and critiques.
The compound binding exchange to address man-in-the-middle attack is The compound binding exchange to address man-in-the-middle attack is
based on the draft "The Compound Authentication Binding based on the draft "The Compound Authentication Binding
Problem"[CompoundBinding]. Problem"[CompoundBinding].
The vast majority of the work by Simon Josefsson and Hakan Andersson The vast majority of the work by Simon Josefsson and Hakan Andersson
was done while he was employed at RSA Laboratories. was done while they were employed at RSA Laboratories.
Author Addresses Author Addresses
Ashwin Palekar Ashwin Palekar
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 882 8080 Phone: +1 425 882 8080
EMail: ashwinp@microsoft.com EMail: ashwinp@microsoft.com
Dan Simon Dan Simon
skipping to change at page 50, line 23 skipping to change at page 71, line 4
Phone: +1 425 882 8080 Phone: +1 425 882 8080
EMail: ashwinp@microsoft.com EMail: ashwinp@microsoft.com
Dan Simon Dan Simon
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 706 6711 Phone: +1 425 706 6711
EMail: dansimon@microsoft.com EMail: dansimon@microsoft.com
Glen Zorn Glen Zorn
Cisco Systems Cisco Systems
500 108th Avenue N.E. 500 108th Avenue N.E.
Suite 500 Suite 500
Bellevue, Washington 98004 Bellevue, Washington 98004
USA
Phone: + 1 425 438 8210 Phone: + 1 425 438 8210
Fax: + 1 425 438 1848 Fax: + 1 425 438 1848
EMail: gwz@cisco.com EMail: gwz@cisco.com
Simon Josefsson Simon Josefsson
Drottningholmsv„gen 70 Drottningholmsvagen 70
112 42 Stockholm 112 42 Stockholm
Sweden Sweden
Phone: +46 8 619 04 22 Phone: +46 8 619 04 22
EMail: jas@extundo.com EMail: jas@extundo.com
11. Intellectual Property Statement Hao Zhou
Cisco Systems, Inc.
4125 Highlander Parkway
Richfield, OH 44286
Phone: +1 330 523 2132
Fax: +1 330 523 2239
EMail: hzhou@cisco.com
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
Phone: +1 206 256 3380
EMail: jsalowey@cisco.com
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
standards-related documentation can be found in BCP-11. Copies of standards- related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances of
of licenses to be made available, or the result of an attempt made licenses to be made available, or the result of an attempt made to
to obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification proprietary rights by implementors or users of this specification can
can be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
12. Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expiration Date Expiration Date
This memo is filed as <draft-josefsson-pppext-eap-tls-eap-06.txt>, This memo is filed as <draft-josefsson-pppext-eap-tls-eap-07.txt>,
and expires after six months. and expires April 22, 2004.
 End of changes. 373 change blocks. 
1334 lines changed or deleted 2099 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/