| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008.
The flexible authentication via secure tunneling EAP method (EAP-FAST) enables secure communication between a client and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning.
1.
Introduction
1.1.
Specification Requirements
1.2.
Terminology
2.
EAP-FAST Provisioning Modes
3.
Dynamic Provisioning using EAP-FAST Conversation
3.1.
Phase 1 TLS tunnel
3.1.1.
Server-Authenticated Phase 1
3.1.2.
Server-Unauthenticated Phase 1
3.2.
Phase 2 - Tunneled Authentication and Provisioning
3.2.1.
Server-Authenticated Tunneled Authentication
3.2.2.
Server-Unauthenticated Tunneled Authentication
3.2.3.
Authenticating Using EAP-MSCHAPv2
3.2.4.
Use of other Inner EAP Methods for EAP-FAST Provisioning
3.3.
Key Derivations Used in the EAP-FAST Provisioning Exchange
3.4.
Peer-Id, Server-Id and Session-Id
3.5.
Network Access after EAP-FAST Provisioning
4.
Information Provisioned in EAP-FAST
4.1.
Protected Access Credential
4.2.
PAC TLV Format
4.2.1.
Formats for PAC Attributes
4.2.2.
PAC-Key
4.2.3.
PAC-Opaque
4.2.4.
PAC-Info
4.2.5.
PAC-Acknowledgement TLV
4.2.6.
PAC-Type TLV
4.3.
Trusted Server Root Certificate
4.3.1.
Server-Trusted-Root TLV
4.3.2.
PKCS#7 TLV
5.
IANA Considerations
6.
Security Considerations
6.1.
Provisioning Modes and Man-in-the-middle Attacks
6.1.1.
Server-Authenticated Provisioning Mode and Man-in-the-middle Attacks
6.1.2.
Server-Unauthenticated Provisioning Mode and Man-in-the-middle Attacks
6.2.
Dictionary Attacks
6.3.
Considerations in Selecting a Provisioning Mode
6.4.
Diffie-Hellman Groups
6.5.
Tunnel PAC Usage
6.6.
PAC Storage Considerations
6.7.
Security Claims
7.
Acknowledgements
8.
References
8.1.
Normative References
8.2.
Informative References
Appendix A.
Examples
A.1.
Example 1: Successful Tunnel PAC Provisioning
A.2.
Example 2: Failed Provisioning
A.3.
Example 3: Provisioning a Authentication Server's Trusted Root Certificate
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
EAP-FAST [RFC4851] (Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST),” May 2007.) is an EAP method that can be used to mutually authenticate peer and server. Credentials such as a pre-shared key, certificate trust anchor or a Protected Access Credential (PAC) must be provisioned to the peer before it can establish mutual authentication with the server. In many cases, the provisioning of such information presents deployment hurdles. Through the use of the protected TLS [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.) tunnel, EAP-FAST can enable dynamic in-band provisioning to address such deployment obstacles.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
Much of the terminology used in this document comes from [RFC3748] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.). The terms "peer" and "server" are used interchangeably with the terms "EAP peer" and "EAP server" respectively. Additional terms are defined below:
- Man in the Middle (MitM)
An adversary that can successfully inject itself between a peer and EAP server. The MitM succeeds by impersonating itself as a valid peer or server.- Provisioning
Providing peer with a trust anchor, shared secret or other appropriate information needed to establish a security association.- Protected Access Credential (PAC)
Credentials distributed to a peer for future optimized network authentication. The PAC consists of at most three components: a shared secret, an opaque element and optional information. The shared secret part contains the secret key shared between the peer and server. The opaque part contains the shared secret encrypted by a private key only known to the server. It is provided to the peer and is presented back to the server when the peer wishes to obtain access to network resources. Finally, a PAC may optionally include other information that may be useful to the peer.- Tunnel PAC
A set of credentials stored by the peer and consumed by both the peer and the server to establish a TLS tunnel.
| TOC |
EAP-FAST supports two modes for provisioning:
The EAP-FAST provisioning modes use EAP-DAST phase 2 inside a secure TLS tunnel established during phase 1. [RFC4851] (Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST),” May 2007.) describes the EAP-FAST phases in greater detail.
In the Server-Authenticated Provisioning Mode, the peer has successfully authenticated the EAP server as part of EAP-FAST Phase 1 (i.e. TLS tunnel establishment). Additional exchanges MAY occur inside the tunnel to allow the EAP Server to authenticate the EAP peer before provisioning any information.
In the Server-Unauthenticated Provisioning Mode, an unauthenticated TLS tunnel is established in the EAP-FAST Phase 1. The peer may negotiate a TLS anonymous Diffie-Hellman based cipher suite to signal that it wishes to use Server-Unauthenticateded Provisioning Mode. In addition, cases where the peer lacks the necessary trust anchors to validate the server certificate chain for an authenticated ciphersuite are also considered to be Server-Unauthenticated. This provisioning mode enables the bootstrapping of peers where the peer lacks strong credentials usable for mutual authentication with the server.
Since the server is not authenticated in the Server-Unauthenticated Provisioning Mode, it is possible that an attacker may intercept the TLS tunnel. When using this mode, an inner, phase 2, EAP method SHOULD be used to provide authentication and MitM detection as described in Section 6 (Security Considerations). If an anonymous tunnel is used then the peer and server MUST negotiate and successfully complete an EAP method supporting mutual authentication and key derivation. The peer then uses the Crypto-Binding TLV to validate the integrity of the TLS tunnel, thereby verifying that the exchange was not subject to a man-in-the-middle attack.
Assuming that an inner EAP method and Crypto-Binding TLV exchange is successful, the server will subsequently provide credential information, such as a shared key or the trusted root(s) of server certificate using a PAC TLV or a Server-Trusted-Root TLV respectively. Once the EAP-FAST Provisioning conversation completes, the peer is expected to use the provisioned credentials in subsequent EAP-FAST authentications.
| TOC |
| TOC |
| TOC |
The provisioning EAP-FAST exchange uses the same sequence as the EAP-FAST authentication phase 1 to establish a protected TLS tunnel. Implementations supporting this version of the Sever-Authenticated Provisioning Mode MUST support the following TLS ciphersuites defined in [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.):
Other TLS ciphersuites that provide server authentication and encryption MAY be supported. The server MAY authenticate the peer during the TLS handshake in Server-Authenticated Provisioning Mode.
| TOC |
Implementations supporting this version of the Sever-Unauthenticated Provisioning Mode MUST support the following TLS ciphersuites defined in [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.):
To adhere to best security practices, it is highly RECOMMENDED that the peer validate the server's certificate chain when performing server-side authentication to obtain the full security benefits of Server-Authenticated provisioning. However, as the provisioning of the root public key or trust anchor must also be secured, some deployments may be willing to trade off the security risks for ease of deployment and forgo trust root validation or use an anonymous ciphersuite. When Server-Unauthenticated Provisioning Mode is used in this way a ciphersuite that allows both peer and server to contribute to the TLS master secret, such as ciphersuites using ephemeral Diffie-Hellman based key agreement, MUST be used. Ciphersuites that are based on RSA key transport where only one side contributes the key material MUST NOT be used. Anonymous ciphersuites SHOULD NOT be allowed outside of EAP-FAST Server-Unauthenticated Provisioning Mode. Ciphersuites that are used for provisioning MUST provide encryption.
| TOC |
Once a protected tunnel is established, the peer and server may wish to execute additional authentication and perform checks on the integrity of the TLS tunnel. As defined in [RFC4851] (Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST),” May 2007.) the authentication exchange will be followed by an Intermediate-Result TLV and a Crypto-Binding TLV if the EAP method generates key material. the Crypto-Binding TLV provides a check on the integrity of the tunnel with respect to the endpoints of the EAP method. If the preceding is successful than a provisioning exchange may take place. The provisioning exchange will use a PAC TLV exchange if a PAC is being provisioned and a Server-Trusted-Root TLV if a trusted root certificate is being provisioned. The provisioning may be solicited by the client or it may be unsolicited. The PAC TLV exchange consists of the server distributing the PAC in a corresponding PAC TLV to the peer and the peer confirming its receipt in a final PAC TLV Acknowledgement message. The peer may also use the PAC TLV to request that the server send a PAC. The provision TLVs may be piggybacked on the Result TLV.
A fresh PAC may be distributed if the server detects that the PAC is expiring soon. A PAC TLV MUST NOT be accepted if it is not encapsulated in an encrypted TLS tunnel. In-band PAC refreshing is enforced by server policy. The server, based on the PAC-Opaque information, may determine not to refresh a peer's PAC through the PAC TLV mechanism even if the PAC- Key has expired.
| TOC |
If Server-Authenticated Mode is in use then any EAP method may be used within the TLS tunnel to authenticate the peer that is allowed by the peer's policy.
| TOC |
If Server-Unauthenticated Mode is in use then peer will want to authenticate the server and the server will want to authenticate the peer. The only method for performing authentication in this case makes use of MSCHAPv2 in a special way as described in the following section. It is possible for other methods to be defined to perform this authentication in the future.
| TOC |
Implementations of this version of the EAP-FAST Server-Unauthenticated Provisioning Mode MUST support EAP-MSCHAPv2 [EAP‑MSCHAPv2] (Microsoft Developer Network (MSDN), “[MS-CHAP]: Extensible Authentication Protocol Method for Microsoft Challenge Handshake Authentication Protocol (CHAP) Specification,” January 2008.) as the inner authentication method. While other authentication methods are allowed and exist to achieve mutual authentication, when using an anonymous or unauthenticated TLS tunnel, EAP-MSCHAPv2 was chosen for several reasons:
When using an anonymous DH key agreement and EAP-MSCHAPv2, a binding between the tunnel and the EAP-MSCHAPv2 exchanges is formed by using keying material generated during the EAP-FAST tunnel establishment as the EAP-MSCHAPv2 challenges instead of using the challenges exchanged within the protocol itself. A detailed description of the challenge generation is described in Section 3.3 (Key Derivations Used in the EAP-FAST Provisioning Exchange).
The MSCHAPv2 [RFC2759] (Zorn, G., “Microsoft PPP CHAP Extensions, Version 2,” January 2000.) exchange forces the server to provide a valid ServerChallengeResponse which must be a function of the server challenge, client challenge and password as part of its response. This reduces the window of vulnerability of a man-in-the-middle spoofing the server, by requiring the attacker to successfully break the password within the peer's challenge response time limit.
| TOC |
Once a protected tunnel is established, typically the peer authenticates itself to the server before the server can provision the peer. If the authentication mechanism does not support mutual authentication and protection from man-in-the-middle attacks then Server-Authenticated Provisioning Mode MUST be used. Within a server side authenticated tunnel authentication mechanisms such as EAP-GTC [I‑D.zhou‑emu‑fast‑gtc] (Cam-Winget, N. and H. Zhou, “Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST),” November 2008.) may be used. This will enable peers using other authentication mechanisms such as password database and one-time passwords to be provisioned in-band as well. This version of the EAP-FAST provisioning mode implementation MUST support both EAP-GTC and EAP-MSCHAPv2 within the tunnel in Server-Authenticated Provisioning Mode.
It should be noted that Server-Authenticated Provisioning Mode provides significant security advantages over Server-Unauthenticated Provisioning Mode even when EAP-MSCHAPv2 is being used as the inner method. It protects the EAP-MSCHAPv2 exchanges from potential MitM attacks by verifying server's authenticity before exchanging MSCHAPv2. Server-Authenticated Provisioning Mode is the recommended provisioning mode. The EAP-FAST peer MUST use the Server-Authenticated Provisioning Mode whenever it is configured with valid trust root for a particular server.
| TOC |
The TLS tunnel key is calculated according to the TLS [RFC4346] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.) with an extra 72 octets of key material. Portions of the extra 72 octets are used for the EAP-FAST provisioning exchange session key seed and as the random challenges in the EAP-MSCHAPv2 exchange.
- To generate the key material, compute
- key_block = PRF(master_secret,
- "key expansion",
server_random +
client_random);
until enough output has been generated.
- Then the key_block is partitioned as follows:
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
client_write_IV[IV_size]
server_write_IV[IV_size]
session_key_seed[40]
MSCHAPv2 ServerChallenge[16]
MSCHAPv2 ClientChallenge[16]
The extra key material, session_key_seed is used for the EAP-FAST Crypto-Binding TLV exchange while the ServerChallenge and ClientChallenge correspond to the authentication server's MSCHAPv2 challenge and the peer's MSCHAPv2 challenge respectively. The ServerChallenge and ClientChallenge are only used for the MSCHAPv2 exchange when DH anonymous key agreement is used in the EAP-FAST tunnel establishment.
| TOC |
The provisioning modes of EAP-FAST does not change the general EAP- FAST protocol and thus how the Peer-Id, Server-Id and Session-Id are determined is based on the [RFC4851] (Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST),” May 2007.) techniques.
[RFC4851] (Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST),” May 2007.) Section 3.4 describes how the Peer-Id and Server-Id are determined; Section 3.5 describes how the Session-Id is generated.
| TOC |
After successful provisioning, network access may be granted or denied depending upon server policy. For example, in the Server-Authenticated Provisioning Mode, access can be granted after the EAP server has authenticated the peer and provisioned the peer with a Tunnel PAC (i.e. a PAC used to mutually authenticate and establish the EAP-FAST tunnel). Additionally, peer policy may instruct the peer to disconnect the current provisioning connection and initiate a new EAP-FAST exchange for authentication utilizing the newly provisioned information. At the end of the Server-Unauthenticated Provisioning Mode, network access SHOULD NOT be granted as this conversation is intended for provisioning only and thus no network access is authorized. The server MAY grant access at the end of a successful Server-Authenticated provisioning exchange.
If after successful provisioning, access to the network is denied the EAP Server SHOULD conclude with an EAP Failure. The EAP Server SHALL NOT grant network access or distribute any session keys to the NAS as this exchange is not intended to provide network access. Even though provisioning mode completes with a successful inner termination (e.g. successful Result TLV), server policy defines whether the peer gains network access or not. Thus, it is feasible for the server, while providing a successful Result TLV may conclude that its authentication policy was not satisfied and terminate the conversation with an EAP Failure.
The EAP-FAST server, when denying network access after EAP-FAST Provisioning, may choose to instead, immediately invoke another EAP- FAST Start and thus initiate the EAP-FAST Phase 1 conversation. This server based implementation policy may be chosen to avoid applications such as wireless devices from being disrupted (e.g. in IEEE 802.11 devices, an EAP Failure may trigger a full 802.11 disassociation) and allow them to smoothly transition to the subsequent EAP-FAST authentications to enable network access. As an alternative, both the peer and server can initiate TLS renegotiation, where the newly provisioned credentials can be used to establish a server authenticated or mutually authenticated TLS tunnel for authentication. Upon completion of the TLS negotiation and subsequent authentication, normal network access policy on EAP-FAST authentication can be applied.
| TOC |
Multiple types of credentials may be provisioned within EAP-FAST. The most common credential is the Tunnel PAC that is used to establish the EAP-FAST phase 1 tunnel. In addition to the Tunnel PAC, other types of credentials and information can also be provisioned through EAP-FAST. They may include trusted root certificates, PACs for specific purposes, and user identities to name a few. Typically, provisioning is invoked after both peer and server authenticate each other and after a successful Crypto-Binding TLV exchange. However, depending on the information being provisioned, mutual authentication may not be needed.
At minimum, either the peer or server must prove authenticity before credentials are provisioned to ensure that information is not freely provisioned to or by adversaries. For example, the EAP server may not need to authenticate the peer to provision the peer with trusted root certificates. However, the peer should authenticate the server before it can accept a trusted server root certificate.
| TOC |
A Protected Access Credential (PAC) is a security credential generated by the server that holds information specific to a peer. The server distributes all PAC information through the use of a PAC TLV. Different types of PAC information are identified through the PAC Type and other PAC attributes defined in this section. The only type of PAC described in this document is a Tunnel PAC.
The server distributes the Tunnel PAC to the peer, which uses it in subsequent attempts to establish a secure EAP-FAST TLS tunnel with the server. Along with a secret key (PAC-Key), the tunnel PAC includes data that is opaque to the peer (PAC-Opaque) and other information (PAC-Info) which the peer can interpret. The opaque data is generated by the server and cryptographically protected so it cannot be modified or interpreted by the peer. The Tunnel PAC conveys the server policy of what must and can occur in the protected phase 2 tunnel. It is up to the server policy to include what is necessary in a PAC-Opaque to enforce the policy in subsequent TLS handshakes. For example, user identity, I-ID, can be included as the part of the server policy. This I-ID information limits the inner EAP methods to be carried only on the specified user identity. Other types of information can also be included, such as which EAP method(s) and which TLS ciphersuites are allowed. If the server policy is not included in a PAC-Opaque, then there is no limitation imposed by the PAC on the usage the inner EAP methods or user identities inside the tunnel established by the use of that PAC.
To request provisioning of a Tunnel PAC, a peer sends a PAC TLV containing a PAC attribute of PAC Type set to '1' (Tunnel PAC Type). The request may be issued after the peer has determined that it has successfully authenticated the EAP Server and validated the Crypto-Binding TLV to ensure that the TLS tunnel's integrity is intact. Since anonymous DH ciphersuites are only used for provisioning, if an anonymous ciphersuite is negotiated the Tunnel PAC is provisioned automatically by the server. A PAC-TLV containing PAC-Acknowledge Attribute MUST be sent by peer to acknowledge the receipt of the Tunnel PAC.
Please see Appendix A.1 (Example 1: Successful Tunnel PAC Provisioning) for an example of packet exchanges to provision a Tunnel PAC.
| TOC |
The PAC TLV provides support for provisioning the Protected Access Credential (PAC) defined within [RFC4851] (Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST),” May 2007.). The PAC TLV carries the PAC and related information within PAC attribute fields. Additionally, the PAC TLV MAY be used by the peer to request provisioning of a PAC of the type specified in the PAC Type PAC Attribute. The PAC TLV MUST only be used in a protected tunnel providing encryption and integrity protection. A general PAC TLV format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAC Attributes... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- M
0 - Non-mandatory TLV
1 - Mandatory TLV- R
Reserved, set to zero (0)- TLV Type
11 - PAC TLV- Length
Two octets containing length of the PAC Attributes field in octets- PAC Attributes
A list of PAC attributes in the TLV format
| TOC |
Each PAC Attribute in a PAC TLV is formatted as a TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type
The type field is two octets, denoting the attribute type Allocated Types include:
- 1 - PAC-Key
2 - PAC-Opaque
3 - PAC-Lifetime
4 - A-ID
5 - I-ID
6 - Reserved
7 - A-ID-Info
8 - PAC-Acknowledgement
9 - PAC-Info
10 - PAC-Type- Length
Two octets containing the length of the value field in octets.- Value
The value of the PAC Attribute
| TOC |
The PAC-Key is a secret key distributed in a PAC attribute of type PAC-Key. The PAC-Key field is included within the PAC TLV whenever the server wishes to issue or renew a PAC that is bound to a key such as a Tunnel PAC. The key is a randomly generated octet string 32 octets in length. The key is represented as an octet string. The generator of this key is the issuer of the credential, identified by the A-ID.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Key ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type
1 - PAC-Key- Length
2 octet length indicating a 32 octet long key- Key
The value of the PAC key
| TOC |
The PAC-Opaque field is included within the PAC TLV whenever the server wishes to issue or renew a PAC.
The PAC-Opaque is opaque to the peer and thus the peer MUST NOT attempt to interpret it. A peer that has been issued a PAC-Opaque by a server stores that data, and presents it back to the server according to its PAC Type. The Tunnel PAC is used in the ClientHello SessionTicket extension field defined in [RFC5077] (Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State,” January 2008.). If a client has opaque data issued to it by multiple servers, then it stores the data issued by each server separately according to A-ID. This requirement allows the client to maintain and use each opaque data as an independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque identified by the A-ID. As there is a one to one correspondence between PAC-Key and PAC-Opaque, the peer determines the PAC-Key and corresponding PAC-Opaque based on the A-ID provided in the EAP-FAST/Start message and the A-ID provided in the PAC-Info when it was provisioned with a PAC-Opaque.
The PAC-Opaque field format is summarized 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type
2 - PAC-Opaque- Length
The Length filed is two octets, which contains the length of the value field in octets- Value
The value field contains the actual data for PAC-Opaque. It is specific to the server implementation.
| TOC |
PAC-Info is comprised of a set of PAC attributes as defined in Section 4.2.1 (Formats for PAC Attributes). The PAC-Info attribute MUST contain the A-ID, A-ID-Info, and PAC-Type attributes. Other attributes MAY be included in the PAC-Info to provide more information to the peer. The PAC-Info attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, PAC-Info or PAC-Opaque attributes.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type
9 - PAC-Info- Length
Two octet length field containing the length of the Attributes field in octets- Attributes
The Attributes field contains a list of PAC Attributes Each mandatory and optional field type is defined as follows:
- 3 - PAC-LIFETIME
This is a 4 octet quantity representing the expiration time of the credential in UNIX UTC time. This attribute MAY be provided to the peer as part of PAC-Info.- 4 - A-ID
A-ID is the identity of the authority that issued the PAC. The A-ID is intended to be unique across all issuing servers to avoid namespace collisions. The A-ID is used by the peer to determine which PAC to employ. This attribute MUST be included in the PAC-Info attribute. The A-ID MUST match the A-ID the server used to establish the tunnel.- 5 - I-ID
Initiator identifier (I-ID) is the peer identity associated with the credential. The server employs the I-ID in the EAP-FAST Phase 2 conversation to validate that the same peer identity used to execute EAP-FAST Phase 1 is also used in at minimum one inner EAP method in EAP-FAST Phase 2. If the server is enforcing the I-ID validation on inner EAP method, then I-ID MUST be included in PAC-Info, to enable the peer to also enforce a unique PAC for each unique user. If I-ID is missing from the PAC-Info, it is assumed that the Tunnel PAC can be used for multiple users and peer will not enforce the unique Tunnel PAC per user policy.- 7 - A-ID-Info
Authority Identifier Information is a mandatory TLV intended to provide a user-friendly name for the A-ID. It may contain the enterprise name and server name in a human-readable format. This TLV serves as an aid to the peer to better inform the end-user about the A-ID. The name is encoded as UTF-8 [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) format. This attribute MUST be included in the PAC-Info.- 10 - PAC-type
PAC-Type is a mandatory TLV intended to provide the type of PAC. This field SHOULD be included in the PAC-Info. If PAC-Type is not present, then it defaults to a Tunnel PAC (Type 1).
| TOC |
The PAC-Acknowledgement is used to acknowledge the receipt of the PAC by the peer. The peer includes the PAC-Acknowledgement TLV in a PAC-TLV sent to the server to indicate the result of the processing and storing of a newly provisioned Tunnel PAC. This TLV is only used when Tunnel PAC is provisioned.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type
8 - PAC-Acknowledgement- Length
The length of this field is two octets containing a value of 2.- Result
The resulting value MUST be one of the following:
- 1 - Success 2 - Failure
| TOC |
The PAC-Type TLV is a TLV intended to specify the PAC type. It is included in a PAC-TLV sent by the peer to request PAC provisioning from the server. Its format is described 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAC Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type
10 - PAC-Type- Length
Two Octet length field with a value of 2- PAC Type
This two octet field defined the type of PAC being requested or provisioned. The following values are defined:
- 1 - Tunnel PAC
| TOC |
Server-Trusted-Root TLV facilitates the request and delivery of a trusted server root certificate. The Server-Trusted-Root TLV can be exchanged in regular EAP-FAST Authentication mode or Provisioning mode. The Server-Trusted-Root TLV is always marked as optional, and cannot be responded to with a NAK TLV. The Server-Trusted-Root TLV MUST only be sent as an inner TLV (inside the protection of the tunnel).
After the peer has determined that it has successfully authenticated the EAP server and validated the Crypto-Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked as optional) to request the trusted server root certificates from from the EAP server. The EAP server MAY send one or more root certificates with a PKCS#7 TLV inside Server-Trusted-Root TLV. The EAP server MAY also choose not to honor the request. Please see Section Appendix A.3 (Example 3: Provisioning a Authentication Server's Trusted Root Certificate) for an example of a server provisioning a server trusted root certificate.
| TOC |
The Server-Trusted-Root TLV allows the peer to send a request to the EAP server for a list of trusted roots. The server may respond with one or more root certificates in PKCS#7 [RFC2315] (Kaliski, B., “PKCS #7: Cryptographic Message Syntax Version 1.5,” March 1998.) format.
If the EAP server sets credential format to PKCS#7-Server- Certificate-Root, then the Server-Trusted-Root TLV should contain the root of the certificate chain of the certificate issued to the EAP server packaged in a PKCS#7 TLV. If the Server certificate is a self-signed certificate, then the root is the self-signed certificate.
If the Server-Trusted-Root TLV credential format contains a value unknown to the peer, then the EAP peer should ignore the TLV.
The Server-Trusted-Root 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Credential-Format | Cred TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- M
0 - Non-mandatory TLV- R
Reserved, set to zero (0)- TLV Type
18 - Server-Trusted-Root TLV [RFC4851]- Length
>=2 octets- Credential-Format
The Credential-Format field is two octets. Values include:
- 1 - PKCS#7-Server-Certificate-Root
- Cred TLVs
This field is of indefinite length. It contains TLVs associated with the credential format. The peer may leave this field empty when using this TLV to request server trust roots.
| TOC |
The PKCS#7 TLV is sent by the EAP server to the peer inside the Server-Trusted-Root TLV. It contains the PKCS #7 [RFC2315] (Kaliski, B., “PKCS #7: Cryptographic Message Syntax Version 1.5,” March 1998.) wrapped X.509 certificate. This field contains a certificate or certificate chain in PKCS#7 format requested by the peer as defined in [RFC2315] (Kaliski, B., “PKCS #7: Cryptographic Message Syntax Version 1.5,” March 1998.).
The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. EAP-FAST server implementations that claim to support the dynamic provisioning defined in this document SHOULD support this TLV. EAP-FAST peer implementations MAY support this TLV.
If the PKCS#7 TLV contains a certificate or certificate chain that is not acceptable to the peer, then peer MUST ignore the TLV.
The PKCS#7 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PKCS #7 Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- M
0 - Optional TLV- R
Reserved, set to zero (0)- TLV Type
20 - PKCS#7 TLV [RFC4851]- Length
The length of the PKCS #7 Data field- PKCS #7 Data
This field contains the PKCS #7 wrapped X.509 certificate or certificate chain in the PKCS #7 format.
| TOC |
This section explains the criteria to be used by the IANA for assignment of Type value in PAC attribute, PAC Type value in PAC- Type TLV, Credential-Format value in Server-Trusted-Root TLV. The "Specification Required" policy is used here with the meaning defined in BCP 26 [RFC2434] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.).
A registry of values is needed for the PAC Attribute types. The initial values to populate the registry are:
- 1 - PAC-Key
2 - PAC-Opaque
3 - PAC-Lifetime
4 - A-ID
5 - I-ID
6 - Reserved
7 - A-ID-Info
8 - PAC-Acknowledgement
9 - PAC-Info
10 - PAC-Type
Values from 11 to 63 are reserved. Values 64 to 255 are assigned with a "Specification Required" policy.
A registry of values is needed for PAC-Type values used in the PAC-Type TLV. The initial values to populate the registry are:
- 1 - Tunnel PAC
Values from 2 to 63 are reserved. Values 64 to 255 are assigned with a "Specification Required" policy.
A registry of values is needed for Credential-Format values used in Server-Trusted-Root TLV. The initial values to populate the registry are:
- 1 - PKCS#7-Server-Certificate-Root
Values from 2 to 63 are reserved. Values 64 to 255 are assigned with a "Specification Required" policy.
| TOC |
The Dynamic Provisioning EAP-FAST protocol shares the same security considerations outlined in [RFC4851] (Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST),” May 2007.). Additionally, it also has its unique security considerations described below:
| TOC |
EAP-FAST can be invoked in two different provisioning modes: Server-Authenticated Provisioning Mode and Server-Unauthenticated Provisioning Mode. Each mode provides different levels of resistance to man-in-the-middle attacks. The following list identifies some of the problems associated with a man-in-the-middle attack:
| TOC |
In Server-Authenticated Provisioning Mode the TLS handshake assures protected communications with the server because the peer must have been securely pre-provisioned with the trust roots and/or other authentication information necessary to authenticate the server during the handshake. This pre-provisioning step prevents an attacker from inserting themselves as a man-in-the-middle of the communications. Unfortunately, secure pre-provisioning can be difficult to achieve in many environments.
Cryptographic binding of inner authentication mechanisms to the TLS tunnel provides additional protection from man-in-the-middle attacks resulting from the tunneling of authentication mechanism.
Server-Authenticated Provisioning Mode provides a high degree of protection from man-in-the-middle attacks.
| TOC |
In Server-Unauthenticated Provisioning Mode the TLS handshake does not assure protected communications with the server because either an anonymous handshake is negotiated or the peer lacks the necessary information to complete the authentication of the server. This allows an attacker to insert themselves in the middle of the TLS communications.
EAP-FAST Server-Unauthenticated Provisioning Mode mitigates the man-in-the-middle attack through the following techniques:
While it would be sufficient to only support the cryptographic binding to mitigate the MitM; the binding of the MSCHAPv2 random challenge derivations to the TLS key agreement protocol enables early detection of a man-in-the-middle attack. This guards against adversaries who may otherwise relay the inner EAP authentication messages between the true peer and server and enforces that the adversary successfully respond with a valid challenge response.
This document specifies MSCHAPv2 as the inner authentication exchange, however it is possible that other inner authentications mechanisms to authenticate the tunnel may be developed in the future. Since the strength of the man-in-the-middle protection is directly dependent on the strength of the inner method it is RECOMMENDED that any inner method used provide at least as much resistance to attack as MSCHAPv2. Cleartext passwords MUST NOT be used in Server-Unauthenticated Provisioning Mode. Note that an active man-in-the-middle may observe phase 2 authentication method exchange until the point that the peer determines that authentication mechanism fails or is aborted. This allows for the disclosure of sensitive information such as identity or authentication protocol exchanges to the man-in-the-middle.The ciphersuite used to establish phase 1 of the Server-Unauthenticated provisioning mode MUST be one in which both the peer and server provide contribution to the derived TLS master key. The authenticated ephemeral Diffie-Hellman ciphersuites provide this type of key agreement.
| TOC |
It is often the case that phase 2 authentication mechanisms are based on password credentials. These exchanges may be vulnerable to both online and offline dictionary attacks. The two provisioning modes provide various degrees of protection from these attacks.
In online dictionary attacks the attacker attempts to discover the password by repeated attempts at authentication using a guessed password. Neither mode prevents this type of attack by itself. Implementations should provide controls that limit how often an attacker can execute authentication attempts.
In offline dictionary attacks the attacker captures information which can be processed offline to recover the password. Server-Authenticated provisioning mode provides effecting mitigation because the client will not engage in phase 2 authentication without first authenticating the server during phase 1. Server-Unauthenticated Provisioning Mode is vulnerable to this type of attack. If, during phase 2 authentication, a peer receives no response or an invalid response from the server then there is a possibility there is a man-in-the-middle attack in progress. Implementations SHOULD logs these events and , if possible, provide warnings to the user. Implementations are also encouraged to provide controls that limit how and where Server-Unauthenticated Provisioning Mode can be performed that are appropriate to their environment. For example, an implementation may limit this mode to be used only on certain interfaces or require user intervention before allowing this mode if provisioning has succeeded in the past.
Another mitigation technique that should not be overlooked is the choice of good passwords that have sufficient complexity and length and a password changing policy that requires regular password changes.
| TOC |
Since Server-Authenticated Provisioning Mode provides much better protection from attacks than Server-Unauthenticated Provisioning Mode, Server-Authenticated mode should be used whenever possible. The Server-Unauthenticated Provisioning Mode provides a viable option as there may be deployments that can physically confine devices during the provisioning or are willing to accept the risk of an active dictionary attack. Further, it is the only option that enables zero touch provisioning and facilitates simpler deployments requiring little to no peer configuration. The peer MAY choose to use alternative secure out-of-band mechanisms for PAC provisioning that afford better security than the Server Unauthenticated Provisioning Mode.
| TOC |
Implementations of EAP-FAST anonymous provisioning modes MUST support the Diffie-Hellman groups defined in [RFC3526] (Kivinen, T. and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” May 2003.).
The security of the DH key exchange is based on the difficulty of solving the Discrete Logarithm Problem (DLP). As algorithms and adversaries become more efficient in their abilities to pre-compute values for a given fixed group, it becomes more important for a server to generate new groups as a means to allay this threat. EAP-FAST servers in closed environments may make use of groups outside [RFC3526] (Kivinen, T. and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),” May 2003.). The server could, for instance, constantly compute new groups in the background. Clients in these environments need to employ proper parameter validation. Such an example is cited in [RFC4419] (Friedl, M., Provos, N., and W. Simpson, “Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol,” March 2006.).
The server can maintain a list of safe primes and corresponding generators to choose from. A prime p is safe, if:
p = 2q + 1 and q is prime
Initial implementations of the EAP-FAST provisioning exchange limit the generator to be 2 as it both improves the multiplication efficiency and still covers half of the space of possible residues.
Additionally, since the EAP-FAST provisioning exchange employs DH per [RFC3268] (Chown, P., “Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS),” June 2002.) to generate AES keys, the DH keys should provide enough entropy to ensure that a strong 128bit results from the DH key agreement.
| TOC |
The basic usage of the Tunnel PAC is to establish the TLS tunnel. In this operation it does not have to provide user authentication as it is expected for user authentication to be carried out in phase 2 of EAP-FAST. The EAP-FAST tunnel PAC may contain information about the identity of a peer to prevent a particular tunnel PAC from being used to establish a tunnel which can perform phase 2 authenticate other peers. While it is possible for the server to accept the tunnel PAC as authentication for the peer many current implementations do not do this. The ability to use PAC to authenticate peers and provide authorizations will be the subject of a future document. [RFC5077] (Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State,” January 2008.) gives an example PAC opaque format in the Recommended Ticket Construction section.
| TOC |
The main goal of EAP-FAST is to protect the authentication stream over the media link. However, host security is still an issue. Some care should be taken to protect the PAC on both the peer and server. The peer must store securely both the PAC-Key and PAC-Opaque, while the server must secure storage of its security association context used to consume the PAC-Opaque. Additionally, if alternate provisioning is employed, the transportation mechanism used to distribute the PAC must also be secured.
Most of the attacks described here would require some level of effort to execute; conceivably greater than their value. The main focus therefore, should be to ensure that proper protections are used on both the peer and server. There are a number of potential attacks which can be considered against secure key storage such as:
Another consideration is the use of secure mechanisms afforded by the particular device. For instance, some laptops enable secure key storage through a special chip. It would be worthwhile for implementations to explore the use of such a mechanism.
| TOC |
The [RFC3748] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.) security claims for EAP-FAST are given in Section 7.8 of [RFC4851] (Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST),” May 2007.). When using anonymous provisioning mode there is a greater risk of offline dictionary attack since it is possible for a man-in-the-middle to capture the beginning of the inner MSCHAPv2 conversation. However as noted previously it is possible to detect the man-in-the-middle.
| TOC |
The EAP-FAST design and protocol specification is based on the ideas and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith, Ilan Frenkel and Jeremy Steiglitz.
| TOC |
| TOC |
| TOC |
| [RFC2434] | Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 2434, October 1998 (TXT, HTML, XML). |
| [RFC4419] | Friedl, M., Provos, N., and W. Simpson, “Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol,” RFC 4419, March 2006 (TXT). |
| TOC |
| TOC |
The following exchanges show anonymous DH with a successful EAP- MSCHAPv2 exchange within Phase 2 to provision a Tunnel PAC, the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST,
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS Client Hello without
PAC-Opaque in SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS Server Hello,
TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange
TLS Change Cipher Spec
TLS Finished) ->
<- EAP-Request/EAP-FAST
( TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2
(Challenge))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Response)) ->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2)
(Success))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Success)) ->
<- Intermediate Result TLV(Success)
Crypto-Binding-TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC)
Intermediate Result TLV (Success)
Crypto-Binding-TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC)
PAC-TLV (Type=1)
<- Result TLV (Success)
PAC TLV
Result TLV (Success)
PAC Acknowledgment ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure| TOC |
The following exchanges show a failed EAP-MSCHAPV2 exchange within Phase 2, where the peer failed to authenticate the Server. The conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(s=1, A-ID)
EAP-Response/EAP-FAST
(TLS Client Hello without
SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS Server Hello
TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange
TLS Change Cipher Spec,
TLS Finished) ->
<- EAP-Request/EAP-FAST
( TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP Payload TLV
(EAP-Response/Identity)->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2
(Challenge))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Response)) ->
<- EAP Payload TLV
(EAP-Request EAP-MSCHAPV2
(Success))
// peer failed to verify server MSCHAPv2 response
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Failure)) ->
<- Result TLV (Failure)
Result TLV (Failure) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure| TOC |
The following exchanges show a successful provisioning of a server trusted root certificate using anonymous DH and EAP-MSCHAPV2 exchange within Phase 2, the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Requese/EAP-FAST
(s=1, A-ID)
EAP-Response/EAP-FAST
(TLS Client Hello without
SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS Server Hello,
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange
TLS Change Cipher Spec,
TLS Finished) ->
<- EAP-Request/EAP-FAST
(TLS Change Cipher Spec
TLS Finished)
(EAP-Payload-TLV(
EAP-Request/Identity))
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2
(Challenge))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Response)) ->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2
(success))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Success) ->
<- Intermediate Result TLV(Success)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Intermediate Result TLV(Success)
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC)
Server-Trusted-Root TLV
(Type = PKCS#7) ->
<- Result TLV (Success)
Server-Trusted-Root TLV
(PKCS#7 TLV)
Result TLV (Success) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure| TOC |
| Nancy Cam-Winget | |
| Cisco Systems | |
| 3625 Cisco Way | |
| San Jose, CA 95134 | |
| US | |
| Email: | ncamwing@cisco.com |
| David McGrew | |
| Cisco Systems | |
| San Jose, CA 95134 | |
| US | |
| Email: | mcgrew@cisco.com |
| Joseph Salowey | |
| Cisco Systems | |
| 2901 3rd Ave | |
| Seattle, WA 98121 | |
| US | |
| Email: | jsalowey@cisco.com |
| Hao Zhou | |
| Cisco Systems | |
| 4125 Highlander Parkway | |
| Richfield, OH 44286 | |
| US | |
| Email: | hzhou@cisco.com |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.