Network Working Group N. Cam-Winget
Internet Draft D. McGrew
Category: Informational J. Salowey
Expires: September 5, 2006 H. Zhou
Cisco Sytems
March 5, 2006
Dynamic Provisioning using EAP-FAST
draft-cam-winget-eap-fast-provisioning-02.txt
Status of this Memo
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.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Cam-Winget, et al. Expires September 5, 2006 [Page 1]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
Abstract
EAP-FAST is an extensible EAP method that enables secure
communication between a client and a server by using the Transport
Layer Security (TLS) to establish a mutually authenticated tunnel.
EAP-FAST also enables the provisioning credentials or other
information thru this protected tunnel. This document describes the
use of EAP-FAST for dynamic provisioning.
Table of Contents
1. Introduction...................................................3
1.1. Specification Requirements...............................3
1.2. Terminology..............................................3
2. EAP-FAST Provisioning Modes....................................4
3. Dynamic Provisioning using EAP-FAST Conversation...............5
3.1 Network Access after EAP-FAST Provisioning.................7
3.2 Authenticating Using EAP-MSCHAPv2..........................9
3.3 Use of other Inner EAP Methods for EAP-FAST Provisioning..10
3.4 Key Derivations Used in the EAP-FAST Provisioning Exchange11
3.5 Provisioning or Refreshment of a PAC......................12
4. Types of Information Provisioned in EAP-FAST..................13
4.1 PAC Types.................................................13
4.2 Provisioning PACs through PAC TLV.........................16
4.2.1 Formats for PAC TLV Attributes...............................17
4.2.2 PAC-Key......................................................17
4.2.3 PAC-Opaque...................................................18
4.2.4 PAC-Info.....................................................19
4.2.5 PAC-Acknowledgement TLV......................................21
4.2.6 PAC-Type TLV.................................................22
4.3 Server Trusted Root Certificate...........................23
4.3.1 Server-Trusted-Root TLV......................................23
4.3.2 PKCS #7 TLV..................................................25
5. Security Considerations.......................................26
5.1 User Identity Protection and Validation...................26
5.2 Mitigation of Dictionary Attacks..........................27
5.3 Mitigation of Man-in-the-middle (MitM) attacks............28
5.4 PAC Validation and User Credentials.......................29
5.5 Generation of Diffie-Hellman Groups.......................29
5.6 PAC Storage Considerations................................30
6. IANA Considerations...........................................31
Cam-Winget, et al. Expires September 5, 2006 [Page 2]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
7. References...................................................32
7.1 Normative................................................32
7.2 Informative..............................................32
8. Acknowledgments..............................................33
9. Author's Addresses...........................................33
10. Appendix: Examples..........................................34
10.1 Example 1: Successful Tunnel PAC Provisioning...........34
10.2 Example 2: Successful Tunnel PAC Provisioning with Password
Change.......................................................36
10.3 Example 3: Failed Provisioning..........................38
10.4 Example 4: Provisioning a Authentication Servers Trusted
Root Certificate.............................................39
10.5 Example 5: Provisioning a User Authorization PAC........41
11. Intellectual Property Statement.............................43
12. Disclaimer of Validity......................................43
13. Copyright Statement.........................................44
14. Expiration Date.............................................44
1. Introduction
[EAP-FAST] is an extensible EAP method that can be used to mutually
authenticate peer and server. However, to mutually authenticate with
EAP-FAST, credentials such as a preshared key, trusted anchor or a
Tunnel PAC MUST be provisioned to the peer before it can establish a
secure association with the server. In some cases, the provisioning
of such information present deployment hurdles. Through the use of
the protected tunnel, EAP-FAST can also be used to enable the means
for dynamic or in-band provisioning to address such deployment
obstacles.
1.1. Specification Requirements
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].
1.2. Terminology
Much of the terminology in this document comes from [RFC3748].
Additional terms are defined below:
Cam-Winget, et al. Expires September 5, 2006 [Page 3]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
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, authenticator or authentication server.
Provisioning
Providing peer with a trust anchor, shared secret or other
appropriate information based on which a security association can
be established.
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 optionally other information.
The shared secret part contains the pre-shared key between the peer
and authentication server. The opaque part is provided to the peer
and is presented to the authentication 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.
2. EAP-FAST Provisioning Modes
EAP-FAST supports two modes for provisioning:
1) Server-Authenticated Mode: Provisioning inside a server
authenticated (TLS) tunnel.
2) Server-Unauthenticated Mode: Provisioning inside an
unauthenticated (TLS) tunnel
In the Server-Authenticated Provisioning mode, the peer has
successfully authenticated the EAP server as part of the TLS
handshake of EAP-FAST Phase 1 (e.g. tunnel establishment).
Additional exchanges MAY be needed inside the tunnel for the EAP
Server to authenticate the peer before any information can be
provisioned.
In the Server-Unauthenticated Provisioning mode, an unauthenticated
tunnel is established in the EAP-FAST Phase 1. This provisioning
mode is defined to enable bootstrapping or initial configuration of
Cam-Winget, et al. Expires September 5, 2006 [Page 4]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
peers where the peer lacks strong credentials (if any) to mutually
authenticate with the server and configuration through out-of-band
mechanisms are prohibitive.
In the Server-Unauthenticated Provisioning mode, the peer and server
do not achieve mutual authentication during EAP-FAST Phase 1. It is
expected that the peer negotiates TLS_DH_anon_WITH_AES_128_CBC_SHA to
signal that it can not provide proof of authenticity. While other
cipher suites such as those requiring the use of server certificates
may be used, the peer may lack the necessary trust anchors to
validate the certificate and authenticate the server.
Since the server is not authenticated in the Server-Unauthenticated
Provisioning mode, it is possible that the TLS tunnel may be
terminated by an attacker. It is strongly recommended that an inner
EAP method be used to provide some authenticity assurances and MitM
detection and warning outlined in Section 5 MUST be applied.
The EAP-FAST Phase 2 conversation is unchanged in either Provisioning
mode. However, if the server is not authenticated in Phase 1 the
peer MUST accept an EAP method supporting mutual authentication and
key derivation that is compatible with its initial or bootstrapping
credentials (such as a password-based EAP method). The peer then uses
the Crypto-Binding TLV to validate that the same server terminates
both the TLS tunnel and to successfully complete the EAP method,
thereby verifying that the exchange was not subject to a man-in-the-
middle attack. Assuming that the Crypto-Binding TLV exchange is
successful, the server will subsequently provide the 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.
3. Dynamic Provisioning using EAP-FAST Conversation
The provisioning EAP-FAST exchange uses same sequence as the EAP-FAST
Authentication Phase 1 to establish a protected tunnel. Once a
tunnel is secured between the two parties, the client and server can
then execute an EAP authentication method by which both parties can
achieve mutual authentication.
Cam-Winget, et al. Expires September 5, 2006 [Page 5]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
Provisioning in EAP-FAST is negotiated solely by the client as the
first communication exchange when EAP-FAST is requested from the
server. If the client does not have a Protected Access Credential
(PAC) or requires provisioning of other information (such as the
servers Trusted Root certificate), it can request to initiate a
provisioning EAP-FAST exchange and dynamically obtain one from the
server.
The EAP-FAST provisioning conversation will typically occur between
the peer and an authentication server; more specifically, the server
that can provision the peer with the requested information; typically,
a unique PAC.
The conversation between a peer and authentication server commences
as a normal EAP-FAST exchange: with an anonymous Identity for a peer
and the server determining that EAP-FAST authentication is to occur,
the EAP server MUST respond with an EAP-FAST/Start packet. Assuming
that the peer supports EAP-FAST and the peer has no PAC provisioned
on its device, the peer shall send an EAP-Response packet with EAP-
Type=EAP-FAST.
On receipt of the EAP-FAST Start message, the peer determines it must
be provisioned with a fresh PAC. Further, the peer determines
whether it must invoke a signed or anonymous DH exchange.
To provide best security practices, it is highly recommended that the
peer obtain the servers public key or trust anchor to enable server-
side authentication. However, as the provisioning of the public key
or trust anchor must also be secured to ensure the public key is to
be trusted, some deployments may be willing to trade off the security
risks for ease of deployment.
The peer and server establish the EAP-FAST tunnel for provisioning in
the same exchanges as that defined for EAP-FAST authentication [EAP-
FAST]. With a successful EAP-FAST Phase 1 tunnel established,
subsequent messages exchanged between peer and authentication server
are protected using TLS cipher suites as defined by both [RFC 2246]
and [RFC 3268] to provide message confidentiality and integrity
respectively.
With a protected tunnel, the peer must now authenticate itself to the
server before the server can provision it with a PAC. To ensure some
means for authentication and to protect such authentication from
Cam-Winget, et al. Expires September 5, 2006 [Page 6]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
exposure, the provisioning EAP-FAST exchange requires mutual
authentication. For instance, [MSCHAPv2] may be used to achieve
mutual authentication before any credentials or information can be
provisioned. If an anonymous DH exchange ensued to establish the
tunnel or if the peer was unable to validate the authenticated DH
exchange, the MSCHAPv2 exchange is susceptible to an active server-
side dictionary attack. However, as it enables in-band provisioning
at the cost of some loss in security strength, it is an option to
afford a means for facilitating a deployment with minimal to no
client (peer) configuration. To minimize exposure of the active
dictionary attack, it is recommended that the anonymous DH
provisioning EAP-FAST conversation be used only once; further
provisioning or updates of the PAC should be done by means of the
EAP-FAST PAC refreshing protocol or through some other (manual or
out-of-band) mechanisms.
The client authentication proceeds by the peer and authentication
server engaging in an MSCHAPv2 conversation using invoking the same
EAP-FAST Phase 2 MSCHAPv2 conversation. To further mitigate man-in-
the-middle attacks in the Server-Unauthenticated Provisioning Mode,
the challenges provided by the peer and authentication server are
generated as part of the TLS establishment in the EAP-FAST
provisioning exchange and conveyed as the Server and Client
Challenges requested by MSCHAPv2. Further, the random challenges are
not conveyed in the actual MSCHAPv2 messages, the messages shall
replace the fields with zeroes to obscure the actual values used to
generate the challenge responses.
Following a successful MSCHAPv2 authentication exchange and
successful Intermediate Result TLV and Crypto-Binding TLV exchange,
the server can then provision the peer with a unique PAC. The
provisioning is invoked through the same mechanism as in PAC
refreshment: a PAC-TLV exchange is executed following the successful
MSCHAPv2 exchange including the Intermediate Result TLV and Crypto-
Binding TLV exchange, with 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.
3.1 Network Access after EAP-FAST Provisioning
Depending on server policy, network access can be granted or denied
based on the EAP-FAST Provisioning mode, the credential(s) or other
information that have been provisioned, and the inner EAP methods
Cam-Winget, et al. Expires September 5, 2006 [Page 7]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
used. 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 (e.g. a PAC used to
mutually authenticate the EAP-FAST tunnel).
Additionally, peer policy may also be used to disconnect the current
provisioning connection and initiate a new EAP-FAST exchange for
authentication utilizing the newly provisioned information and ensure
the inner methods are conducted with the trusted server. The peer
policy may be required as the peer determines whether it can
authenticate the EAP Server. In the case where a peer lacks the
trust anchors to validate the servers certificate, the peer SHOULD
negotiate the TLS_DH_anon_WITH_AES_128_CBC_SHA to signal the EAP
server that it lacks the trust anchors to authenticate the server.
At the end of the Server-Unauthenticated Provisioning Mode, network
access SHOULD NOT be granted. EAP server SHOULD conclude with an EAP
Failure to acknowledge that this conversation was intended for
provisioning only and thus no network access is authorized. Upon
completion of the exchange, the EAP Server SHALL NOT grant network
access or distribute any session keys to the NAS as this phase 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 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
802.11 devices, an EAP Failure may trigger a full 802.11
disassociation) and allow them to smoothly transit to the subsequent
EAP-FAST authentications to enable network access.
Similarly, if Server-Authenticated Provisioning Mode is used and the
server policy is to disallow network access, the EAP Server SHALL NOT
grant network access or distribute any session keys to the NAS as
this phase is not intended to provide network access. Even though
provisioning mode completes with a successful inner termination (e.g.
successful Result TLV), the EAP-FAST Server-Authenticated
Provisioning Mode MUST conclude with an EAP Failure to acknowledge
Cam-Winget, et al. Expires September 5, 2006 [Page 8]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
that this conversation was intended for provisioning only and thus no
network access is authorized. The EAP-FAST server may choose to
instead, immediately invoke another EAP authentication transaction.
3.2 Authenticating Using EAP-MSCHAPv2
While other authentication methods exist to achieve mutual
authentication, when using an anonymous or unauthenticated TLS tunnel,
MSCHAPv2 was chosen for several reasons:
. Afford the ability of slowing an active attack by obscuring the
password through some hash
. Especially in the Server-Unauthenticated EAP-FAST Provisioning
conversation MSCHAPv2 affords the ability to detect, based on
the challenge responses, whether there is a possible attack.
. It is understood that a large deployed base is already able to
support MSCHAPv2
. MSCHAPv2 is picked in order to slow the active dictionary attack
relative to MSCHAPv1.
. Allow support for password change during the EAP-FAST
Provisioning protocol.
The MSCHAPv2 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 in the EAP-FAST for in-band
provisioning protocol to force the man-in-the-middle, acting as the
server, to successfully break the password within the clients
challenge response time limit.
EAP-FAST for provisioning MUST support MSCHAPV2 as the inner method
when using an anonymous DH key agreement. However, with support of
signed DH key agreement, the provisioning protocol of EAP-FAST may
support other methods such as EAP-GTC to enable peers (using other
password databases such as LDAP and OTP) to be provisioned in-band as
well. However, the replacement may only be achieved when used with
the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite to ensure no loss
in security.
Cam-Winget, et al. Expires September 5, 2006 [Page 9]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
When using an anonymous DH key agreement and MSCHAPv2, a binding
between the tunnel and the MSCHAPv2 exchanges is formed by using
keying material generated during the EAP-FAST tunnel establishment as
the MSCHAPv2 challenges. A detailed description of the challenge
generation is described in Section 3.4.
3.3 Use of other Inner EAP Methods for EAP-FAST Provisioning
Once a protected tunnel is established, the peer must authenticate
itself to the server before the server can provision the peer. When
using TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite in the EAP-FAST
Phase 1 conversation, an EAP method providing both mutual
authentication and keying material MUST be employed.
EAP-MSCHAPv2 is an inner method that MUST be supported for Dynamic
Provisioning in EAP-FAST. The MSCHAPv2 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 in this
provisioning mode to force the man-in-the-middle, acting as the
server, to successfully break the password within the clients
challenge response time limit, or it raises the ability to detect if
an MitM attacker is capturing the MSCHAPv2 exchange without
responding for the purpose of affecting an off-line dictionary attack
on the password.
As a result of not authenticating the server in Phase 1 and potential
MITM attacks in the Server-Unauthenticated Provisioning Mode, an EAP
method with equal or better protection than EAP-MSCHAPv2 MUST be used
in Phase 2.
With the use of additional TLS cipher suites, especially when server
authenticity is verified as part of the TLS tunnel establishment,
other inner EAP methods with weaker protection than EAP-MSCHAPv2 can
be used safely inside tunnel. Hence, in addition to EAP-MSCHAPV2 as
the inner method, EAP-GTC MAY be used in Server-Authenticated
Provisioning Mode. This will enable peers using other user databases
such as LDAP and OTP to be provisioned in-band as well. However, the
replacement may only be achieved when used with the TLS cipher suites
that ensure server authentication, such as
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, to ensure no loss in security.
Cam-Winget, et al. Expires September 5, 2006 [Page 10]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
Dynamic Provisioning EAP-FAST MUST support both EAP-GTC and EAP-MS-
CHAPv2 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 even when EAP-MSCHAPv2 is being used as inner method. It
protects the EAP-MSCHAPv2 exchanges from potential MitM attacks by
verifying servers authenticity before exchanging MSCHAPv2. Thus
Server-Authenticated Provisioning Mode is the preferred provisioning
mode. The EAP-FAST peer MUST use the Server-Authenticated
Provisioning Mode whenever a certificate or (servers) public key is
available to authenticate the server, in order to ensure best
security practices.
3.4 Key Derivations Used in the EAP-FAST Provisioning Exchange
When generating keys in the EAP-FAST Provisioning conversation, the
DH computation is used as the pre_master_secret and is converted into
the master_secret as specified by [RFC 2246]:
For the client:
pre_master_secret = (DH_Ys)^peer-private-DH-key mod DH_p
For the server:
pre_master_secret = (DH_Yc)^server-private-DH-key mod DH_
master_secret = PRF(pre_master_secret, master secret, client_random
+ server_random)
The TLS tunnel key is calculated similar to the TLS key calculation
with an extra 72 octets generated. Portions of the extra 72 octets
are used for the EAP-FAST provisioning exchange session key seed and
as the random challenges in the MSCHAPv2 exchange.
To generate the key material, compute
key_block = PRF(master_secret,
key expansion,
server_random +
Cam-Winget, et al. Expires September 5, 2006 [Page 11]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
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[seed_size= 40]
MSCHAPv2 ServerChallenge[16]
MSCHAPv2 ClientChallenge[16]
The extra key material, session_key_seed is used for the Crypto-
Binding while the ServerChallenge and ClientChallenge correspond to
the authentication servers MSCHAPv2 challenge and the peers
MSCHAPv2 challenge respectively. The ServerChallenge and
ClientChallenge are only used for the MSCHAPv2 exchange when
TLS_DH_anon_WITH_AES_128_CBC_SHA is used in the EAP-FAST tunnel
establishment.
3.5 Provisioning or Refreshment of a PAC
The server may provision or refresh information by use of the
Protected Access Credential (PAC) after a successful user
authentication. A PAC TLV is defined to facilitate the distribution
and refreshing of information and is defined in Section 4.2. A fresh
PAC may be distributed after a successful Intermediate Result TLV and
Crypto-Binding TLV exchange, if the server detects that the PAC is
expiring soon. A successful EAP-FAST inner method authentication,
including a successful Crypto-Binding exchange must ensue before an
EAP-FAST server can distribute a fresh PAC. A PAC TLV should not be
accepted if it is not TLS tunnel-encapsulated.
N.B. In-band PAC refreshing is enforced by server policy. The
server, based on the PAC-Opaque information, may determine not to
refresh a peers PAC through the PAC TLV mechanism even if the PAC-
Key has expired.
Cam-Winget, et al. Expires September 5, 2006 [Page 12]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
4. Types of Information Provisioned in EAP-FAST
In addition to the Tunnel PAC (the one used to establish the EAP-FAST
Phase 1 tunnel), other types of credentials and information can also
be provisioned. They may include trusted root certificates for the
server certificates, application specific PACs, and user identities
to name a few. Typically, provisioning is invoked after both peer and
server validate their authenticities and after a successful Crypto-
Binding TLV exchange. However, depending on the information being
provisioned, mutual authentication MAY not be needed.
At minimum, at least one entity (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
MUST authenticate the server before it can accept a trusted server
root certificate.
4.1 PAC Types
The server distributes all PAC information through the use of a PAC
TLV. Each type of PAC information is typed through a PAC Type and
PAC TLV Attribute defined in this section.
A Protected Access Credential (PAC) is a security credential provided
by the Authentication Server (AS) that holds application specific
information. For instance, a Tunnel PAC holds a shared secret
mutually and uniquely shared between the peer and AS and is used to
secure an EAP-FAST (TLS) tunnel. EAP-FAST uses the PAC to facilitate
the storage of secure information between a peer and a server on the
peer and minimize the per user state management on the AS.
However, as PACs have wider contextual use, the PAC used for
establishing the EAP-FAST tunnel in Phase 1 is referred to as the
Tunnel PAC throughout this document. A summary of three major types
of PACs that MUST be supported in this version of the Dynamic
Provisioning EAP-FAST include:
1) Tunnel PAC A distributed shared secret between the peer and
AS used to establish a secure the EAP-FAST tunnel and convey
the server policy of what must and can occur in the tunnel. The
Cam-Winget, et al. Expires September 5, 2006 [Page 13]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
server policy can include EAP methods, TLV exchanges and
identities allowed in the tunnel. It is up to the server policy
to include whats necessary in a PAC to enforce the policy in
subsequent authentications that use the PAC. 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 cipher suite is allowed. If the server policy is not
included in a PAC, then there is no validation or limitation on
the inner EAP methods or user identities inside the tunnel
established by use of that PAC.
2) Application Specific Short Lived PACs - these PACs carry
authorization information that is bound to a specific user or
device identity. They are intended to be short-lived, with an
expiry time usually in the range of normal session resume
timeouts (i.e., minutes or hours, versus days or months). Since
they are usually bound to a particular session or state, they
MUST be kept in volatile memory only and MUST not be persistent
cross system reboots. They MAY be bound to the Tunnel PAC to
enforce the two being used together. Currently there is only
one application specific short lived PAC defined as:
User Authorization PAC A distributed user authentication and
authorization result based on a previous authentication. It
can be used in combination with the Tunnel PAC to bypass
subsequent user authentication(s). It is intended to be short-
lived and also controlled by the peer. If any state of the
user has changed to the extent that will affect the user
authentication result (i.e., user has logged on/off), the peer
MUST discard it and not use it again. The User Authorization
PACs can be used in combination with the Tunnel PAC to allow a
stateless server session resume as defined [EAP-FAST].
3) Application Specific Long Lived PACs - Application specific
long lived PACs are each issued a key that can be used to prove
ownership of the PACs and credentials. They can be considered
another form of credentials, independent of the Tunnel PAC and
can be used alone to prove authenticity. In this case they may
not be bound to the Tunnel PAC. They are usually allowed a
longer expiry time and stored in persistent storage. Peer and
EAP Server can use them either inside or outside EAP-FAST
(mostly likely in some shared key EAP methods) to manually
Cam-Winget, et al. Expires September 5, 2006 [Page 14]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
authenticate each other. One application of this type of PAC is
defined in this specification:
Machine Authentication PAC A distributed device
authentication and authorization policy based on a previous
user authentication. It can be used by itself to prove
ownership of the PAC and gain authorization. It is often
used as the credentials to obtain network access in lieu of
the user credentials whenever user credentials are not
available, i.e., during boot up time. After successful
validation of the Machine Authentication PAC, limited or
full network access MAY be granted based on the servers
policy.
To request provisioning of a Tunnel PAC, a peer MUST send a PAC TLV
with a PAC-Type PAC TLV with its TLVs field and 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 the tunnel
and inner EAP methods were between the same peer and EAP Server by
validating the Crypto-Binding TLV. This would differentiate the
Tunnel PAC request from other types of PAC provisioning requests. If
anonymous DH is negotiated and the peer does not send any PAC-TLV to
request provisioning, then Tunnel PAC is provisioned automatically
by the server. PAC-Acknowledge TLV MUST be used for peer to
acknowledge the receipt of the Tunnel PAC.
To request provisioning of PACs other than the Tunnel PAC, a peer
MUST send a PAC TLV with a PAC-Type PAC TLV in its TLVs field and set
to the appropriate PAC-Type, after the peer has determined that it
has successfully authenticated the EAP Server and determined that the
tunnel and inner EAP methods were between the same peer and EAP
Server by validating the Crypto-Binding TLV. This can also be used to
indicate a peers support for other types of PACs. Peer MUST send
each individual corresponding PAC TLV to request different types of
PACs. Multiple PAC TLVs can be sent in the same packet or different
packets to request provisioning of different type of PACs. The EAP
server will send the PACs after its internal policy has been
satisfied; or it may ignore the request or request additional
authentications if its policy dictates. If a peer receives a PAC with
unknown type, it MUST ignore it.
PAC-Acknowledge TLV MUST NOT be used from peer to acknowledge the
receipt of other types of PACs.
Cam-Winget, et al. Expires September 5, 2006 [Page 15]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
Please see Section 10.5 for an example of packet exchanges to
provision a User Authorization PAC.
4.2 Provisioning PACs through PAC TLV
The PAC TLV is defined to enable the provisioning of PAC information.
Additionally, the PAC-Type, PAC TLV MAY be used by the peer to
request provisioning for specific types of information. Conversely,
the PAC TLV is used by the server to provision the requested
information to a peer.
The PAC TLV provides support for Protected Access Credential (PAC)
defined within [EAP-FAST]. A consistent PAC format will allow it to
be used by multiple applications beyond EAP-FAST. 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
Length
The length of the PAC Attributes field in octets.
PAC Attributes
A list of PAC attributes in the TLV format.
Cam-Winget, et al. Expires September 5, 2006 [Page 16]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
4.2.1 Formats for PAC TLV Attributes
A common encapsulating format is used to convey the different fields
that comprise a PAC attribute. The common encapsulation 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
The type field is two octets, denoting the attribute type.
Allocated Types include:
1 - PAC-Key
2 - PAC-Opaque
3 - CRED_LIFETIME
4 - A-ID
5 - I-ID
6 - Reserved
7 - A-ID-Info
8 - PAC-Acknowledgement
9 - PAC-Info
10 - PAC-Type
Length
The Length filed is two octets, which contains the length of
the Value field in octets.
Value
The value of the PAC Attribute.
4.2.2 PAC-Key
The PAC-Key is distributed as an attribute of type PAC-Key (Type=1).
The key is a randomly generated octet string. The key is represented
as an octet string whose length is determined by the length field.
Cam-Winget, et al. Expires September 5, 2006 [Page 17]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
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
The Length filed is two octets. For this version of EAP-FAST,
PAC-Key is 32 octets.
Key
The Key field contains the PAC-Key.
4.2.3 PAC-Opaque
The PAC-Opaque contains data that is opaque to the recipient, the
peer is not the intended consumer of PAC-Opaque and thus should not
attempt to interpret it. A peer that has been issued a PAC-Opaque by
a server MUST store that data, and present it back to the server as
is, in the ClientHello SessionTicket extension field [TICKET]. If a
client has opaque data issued to it by multiple servers, then it MUST
store the data issued by each server separately. 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 must determine the PAC-Key
and corresponding PAC-Opaque based on the A-ID provided in the EAP-
Cam-Winget, et al. Expires September 5, 2006 [Page 18]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
FAST/Start message and the A-ID provided in the PAC-Info when it was
provisioned with a PAC-Opaque.
As the PAC-Opaque is server specific, its contents and definition are
specific to the issuer of the PAC, e.g. the PAC server.
The PAC-Opaque field is embedded as part of the PAC TLV when the
server has determined that the PAC must be refreshed and sends a new
PAC.
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
The PAC-Opaque field is also passed from the peer to the server
during the EAP-FAST Authentication Phase 1 conversation to
enable the server to validate and recreate the PAC-Key. When
it is passed from the peer, it is encapsulated as defined above
in the ClientHello SessionTicket Extension [TICKET].
4.2.4 PAC-Info
Cam-Winget, et al. Expires September 5, 2006 [Page 19]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
PAC-Info is comprised of a set of PAC attributes. At minimum, the
A-ID TLV is required to convey the issuing identity to the peer.
Other optional fields may be included in the PAC to provide more
information to the peer. It is a container attribute for various
types of information each of which is encoded in conformance to the
PAC TLV field format as defined in Section 4.2.
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
The Length filed is two octets, which contains 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:
CRED_LIFETIME (type 3)
This is a 4 octet quantity representing the expiration time
of the credential in UNIX UTC time. This is a mandatory
field contained in the PAC-Opaque field to enable the server
to validate the PAC. This field may also be optionally
provided to the peer as part of PAC-Info.
A-ID (type 4)
Authority identifier is the name of the authority that
issued the token. The A-ID is intended to be unique across
all issuing servers to avoid namespace collisions. Server
implementations should use measures to ensure the A-ID used
is globally unique to avoid name collisions. The A-ID is
used by the peer to determine which PAC to employ.
Similarly, the server uses the A-ID to both authenticate the
PAC-Opaque and determine which master key was used to issue
Cam-Winget, et al. Expires September 5, 2006 [Page 20]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
the PAC. This field is mandatory and included in both the
PAC-Opaque and as the first TLV comprising PAC-Info.
I-ID (type 5)
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. This
field is a mandatory field in PAC-Opaque and may optionally
be included in the PAC-Info. If the AS is enforcing the I-ID
validation on inner EAP method, then I-ID is mandatory in
PAC-Info, to enable the client 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 client will not enforce the unique Tunnel PAC per
user policy.
A-ID-Info (type 7)
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 more human-readable
format. This TLV serves as an aid to the peer to better
inform the end-user about the A-ID. This field is a
mandatory field in the PAC-Info.
PAC-Type (type 10)
PAC-Type is a mandatory TLV intended to provide the type of
PAC. This field is a mandatory field in the PAC-Info. If
PAC-Type is not present, then it defaults to a Tunnel PAC
(Type 1).
4.2.5 PAC-Acknowledgement TLV
The PAC-Acknowledgement TLV is used to acknowledge the receipt of the
Tunnel PAC by the peer. Peer sends this TLV in response to the PAC
TLV to indicate the result of the retrieving and storing of the new
Tunnel PAC. This TLV is only used when provisioning Tunnel PAC.
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 |
Cam-Winget, et al. Expires September 5, 2006 [Page 21]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8 - PAC-Acknowledgement
Length
The length of this field is two octets and value must be 2.
Result
The resulting value must be one of the following:
1 - Success
2 - Failure
4.2.6 PAC-Type TLV
The PAC-Type TLV is a TLV intended to specify the PAC type. 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
The length of this field is two octets and value must be 2.
PAC Type
This two octet field defined the type of PAC being requested or
provisioned. Its value must be one of the following:
Cam-Winget, et al. Expires September 5, 2006 [Page 22]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
1 Tunnel PAC
2 Machine Authentication PAC
3 User Authorization PAC
4.3 Server Trusted Root Certificate
It is desirable to provision the peer with the servers trusted root
certificates (or CA certificates), which can later be used for
enabling PKI based cipher suites. Server-Trusted-Root TLV is
introduced to facilitate the request for and delivery of server
trusted root certificates. Within the EAP-FAST Phase 2 conversation,
a peer MAY request for a servers trusted root certificate using a
Server-Trusted-Root TLV, and the EAP server MAY respond with a
Server-Trusted-Root TLV containing the trusted root certificate in
the PCKS#7 TLV to the peer. The Server-Trusted-Root TLV can be
exchanged in regular EAP-FAST Authentication mode or Provisioning
modes.
After the peer has determined that it has successfully authenticated
the EAP server and determined that the tunnel and inner EAP methods
were between the same peer and EAP Server by validating the Crypto-
Binding TLV, it MAY send one or more Server-Trusted-Root TLVs
(marked as optional) to request for the certificate trust anchors of
the server certificate from the EAP server. The EAP server will send
the trusted root(s) of server certificate after its internal policy
has been satisfied; or it may ignore the request or request
additional authentications based on its policy. The peer may receive
a trusted root of server certificate, but is not required to use it.
Please see Section 10.4 for an example of a server provisioning a
server trusted root certificate.
4.3.1 Server-Trusted-Root TLV
The Server-Trusted-Root TLV allows the peer to send a request to the
EAP server for a trusted root in PKCS#7 format.
The Server-Trusted-Root TLV is always marked as optional, and cannot
be responded to with a NAK TLV.
The Server-Trusted-Root TLV can only be sent as an inner TLV (inside
the protection of the tunnel).
Cam-Winget, et al. Expires September 5, 2006 [Page 23]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
The peer MUST NOT request, or accept the trusted root sent inside the
Server-Root credential TLV by EAP-server until it has completed
authentication of EAP server, and validated the Crypto-Binding TLV.
The peer may receive a trusted root, but is not required to use the
trusted root received from the EAP server.
If the EAP server sets credential-format to PKCS#7-Server-
Certificate-Root, then the Server-Trusted-Root TLV MUST contain the
root of the certificate chain of the certificate issued to the EAP
server packages in a PKCS#7 TLV. If the Server certificate is a
self-signed certificate, then the root is the self-signed
certificate. In this case, the EAP server does not have to sign the
certificate inside the PCKS#7 TLV since it does not necessarily have
to private key for it.
If the Server-Trusted-Root TLV credential format does not contain one
of the known values, then the EAP-server MUST ignore the value.
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 | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
18
Length
>=2
Cam-Winget, et al. Expires September 5, 2006 [Page 24]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
Credential-Format
The Credential-Format field is two octets. Values include:
1 - PKCS#7-Server-Certificate-Root.
TLVs
This field is of indefinite length. It contains TLVs
associated with the certificate-request.
4.3.2 PKCS #7 TLV
The PKCS#7 TLV is sent by the EAP server to the peer inside the
Server-Trusted-Root TLV. It contains the PKCS #7 wrapped X.509
certificate. This field contains a certificate or certificate chain
in PKCS#7 format requested by the peer as defined in [RFC2315].
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 provisioning MUST support this TLV. EAP-FAST peer
implementations MAY not 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 value.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Optional TLV
R
Reserved, set to zero (0)
Cam-Winget, et al. Expires September 5, 2006 [Page 25]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
TLV Type
20 (for PKCS #7 TLV)
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.
5. Security Considerations
The Dynamic Provisioning EAP-FAST protocol shares the same security
considerations outlined in [EAP-FAST]. Additionally, it also has its
unique security considerations described below:
5.1 User Identity Protection and Validation
EAP-FAST for provisioning employs the DH key agreement (as defined in
the TLS protocol) to establish a protected tunnel; the initial
Identity request/response may be omitted as it must be transmitted in
the clear and thus subject to snooping and forgery. Alternately, an
anonymous identity may be used in the Identity response to prevent
disclosure of the peers true identity.
As the provisioning EAP-FAST exchange is used for provisioning a PAC
to a specific identity, e.g. I-ID, it is expected that the server
will assign the I-ID based on the identity provided in the protected
inner EAP authentication method. Thus, the protected identity may
not be identical to the cleartext identity presented in the initial
tunnel establishment messages. In order to shield the user identity
from snooping, the cleartext Identity may only provide enough
information to enable routing of the authentication request to the
correct realm. For example, the peer may initially claim the identity
of "nouser@bigco.com" in order to route the authentication request to
the bigco.com EAP server. Subsequently, once the EAP-FAST session has
been negotiated, in the inner authentication method, the peer may
claim the identity of "fred@bigco.com". Thus, the EAP-FAST protocol
for provisioning can provide protection for the user's identity,
Cam-Winget, et al. Expires September 5, 2006 [Page 26]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
though not necessarily the destination realm, unless the provisioning
EAP-FAST conversation terminates at the local authentication server.
5.2 Mitigation of Dictionary Attacks
When EAP-FAST is invoked for provisioning, the peer specifies the
means for securing the communications for the provisioning. As such,
it can invoke the DH or RSA key agreement. When invoking DH key
agreement in one of two ways: anonymously or server-authenticated.
With a server-authenticated DH key agreement, the server must provide
its certificate and an RSA signature with the ephemeral DH
parameters, whereas no signature is provided for an anonymous DH key
agreement.
In a server authenticated DH key agreement, the protected
communications is assured that the AS is authentic as the peer must
have been pre-provisioned with the ASs certificate or public (RSA)
key prior to the negotiation. In this instance, the AS provides
proof of identity through an identity and (certificate) credential,
an adversary may only pose as an AS to successfully mount a
dictionary attack. An EAP-FAST compliant implementation must assure
that provisioning of the AS public key, certificate or root
certificate to the peer must be achieved through a secure mechanism.
Only through a secure mechanism can server-authenticated DH key
agreement provide resistance to dictionary attacks. While this
option affords best security practices, it presents deployment issues
as, especially for wireless clients where there is little means to
provide secure configuration, peers must be configured with a means
to validate the servers credential (e.g. public key).
In an anonymous DH key agreement, an adversary may attempt to
impersonate a client and enable EAP-FAST for provisioning. However,
it must successfully authenticate inside the DH tunnel to succeed and
gain a PAC credential from a server. Thus, peer impersonation is
mitigated through the enabling of peer authentication inside a
protected tunnel. However, an adversary may impersonate as a valid
AS and obtains the MSCHAPv2 exchanges in order to gain peers
identity and credentials. While the adversary must successfully
gain contact with a peer that is willing to negotiate EAP-FAST for
provisioning and provide a valid A-ID that a client accepts, this
occurrence is feasible and enables an adversary to mount a dictionary
attack. For this reason, an EAP-FAST compliant implementation must
support an MSCHAPv2 or stronger EAP method for peer authentication
Cam-Winget, et al. Expires September 5, 2006 [Page 27]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
when an anonymous DH key agreement is used for the tunnel
establishment.
With MSCHAPv2, a peer may detect it is under attack when the AS that
has provided an acceptable Authority ID (A-ID) fails to provide a
successful MSCHAPv2 server challenge response. By employing the
ServerChallenge and ClientChallenge derived during tunnel
establishment; detection of a MitM is feasible during the MSCHAPv2
exchange.
The peer may choose to use a more secure out-of-band mechanism for
PAC provisioning that affords better security than the anonymous DH
key agreement. Similarly, the peer may find a means of pre-
provisioning the servers public key securely to invoke the server-
authenticated DH key agreement.
The anonymous DH key agreement is presented as 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
out-of-band provisioning and facilitates simpler deployments
requiring little to no peer configuration.
5.3 Mitigation of Man-in-the-middle (MitM) attacks
EAP-FAST invocation of provisioning addresses MitM attacks in server-
unauthenticated provisioning mode in the following way:
* Generating MSCHAPv2 server and client challenges as a function
of the DH key agreement: in enforcing the dependence of the MSCHAP
challenges on the DH exchange, a MitM is prevented from
successfully establishing a secure tunnel with both the peer and
legitimate server and succeed in obtaining the PAC credential.
* Cryptographic binding of EAP-FAST Phase 1 and the Phase 2
authentication method: by cryptographically binding key material
generated in all methods, both peer and AS are assured that they
were the sole participants of all transpired methods.
The binding of the MSCHAPv2 random challenge derivations to the DH
key agreement protocol enables early detection of a MitM attack.
This is required to guard from adversaries who may otherwise reflect
the inner EAP authentication messages between the true peer and AS
Cam-Winget, et al. Expires September 5, 2006 [Page 28]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
and enforces that the adversary successfully respond with a valid
challenge response.
The cryptographic binding is another reassurance that indeed the true
peer and AS were the two parties ensuing both the tunnel
establishment and inner EAP authentication conversations. While it
would be sufficient to only support the cryptographic binding to
mitigate the MitM; the extra precaution of binding the MSCHAP
challenge to the DH key agreement affords the client earlier
detection of a MitM and further guards the peer from having to
respond to the success or failure of the adversarys attempt to
respond with a challenge response (e.g. indication of whether the
adversary succeeded in breaking the peers identity and password).
A failure in either step, results in no PAC provisioning.
EAP-FAST invocation of provisioning using an unauthenticated tunnel
can invoke certain procedures to guard implementations for potential
MitM attacks. Detectors can be devised to warn the user when the
peer encounters error conditions that warrant the likelihood of a
MitM. For example, when the MSCHAPv2 server challenge response is
never received or fails, the peer implementation can impose policy
decisions to warn the user and respond to the likelihood that the
failure was due to a MitM attack.
Similarly, to guard against attacks in the EAP-FAST Authentication
that may force a peer to invoke in-band provisioning, guards and
detectors can and should be implemented as part of the EAP-FAST
Authentication protocols.
5.4 PAC Validation and User Credentials
In provisioning, the AS presents the peer with information such as a
PAC-Key, PAC-Opaque and PAC-Info attributes. The peer must securely
cache the PAC-Key and the PAC-Opaque which is bound to the A-ID
provided as a PAC-Info attribute.
5.5 Generation of Diffie-Hellman Groups
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 precompute
values for a given fixed group, it becomes more important for a
Cam-Winget, et al. Expires September 5, 2006 [Page 29]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
server to generate new groups as a means to allay this threat. The
server could, for instance, constantly compute new groups in the
background. Such an example is cited in [SECSH-DH].
Thus, 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
New primes may be generated in the background.
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.
Furthermore, as the server defines the group used for the DH exchange,
it may restrict the prime size to be 1024 bits.
Additionally, since the EAP-FAST provisioning exchange employs DH per
[RFC 3268] to generate AES keys, the DH keys must provide enough
entropy to ensure that a strong 128bit results from the DH key
agreement.
EAP-FAST employs the 2048 bit DH groups defined in [RFC 3526].
5.6 PAC Storage Considerations
The main premise behind EAP-FAST is to protect the authentication
stream over the media link. However, physical 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
manual 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 client and server. There are a number of potential attacks
which can be considered against secure key storage such as:
Cam-Winget, et al. Expires September 5, 2006 [Page 30]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
* weak passphrases
On the client side, keys are usually protected by a passphrase. On
some environments, this passphrase may be associated with the
user's password. In either case, if an attacker can obtain the
encrypted key for a range of users, he may be able to successfully
attack a weak passphrase. The tools are already in place today to
allow an attacker to easily attack all Outlook or Outlook Express
users in an enterprise environment. Most viruses or worms of this
sort attract attention to themselves by their action, but that need
not be the case. A simple, genuine appearing email could
surreptitiously access keys from known locations and email them
directly to the attacker, attracting little notice.
* key finding attacks
Key finding attacks are usually mentioned in reference to web
servers, where the private SSL key may be stored securely, but at
some point it must be decrypted and stored in system memory. An
attacker with access to system memory can actually find the key by
identifying their mathematical properties. To date, this attack
appears to be purely theoretical and primarily acts to argue
strongly for secure access controls on the server itself to prevent
such unauthorized code from executing.
* key duplication , key substitution, key modification
Once keys are accessible to an attacker on either the client or
server, they fall under three forms of attack: key duplication, key
substitution and key modification. The first option would be the
most common, allowing the attacker to masquerade as the user in
question. The second option could have some use if an attacker
could implement it on the server. Alternatively, an attacker could
use one of the latter two attacks on either the client or server to
force a PAC re-key, and take advantage of the MitM/dictionary
attack weakness of the EAP-FAST provisioning protocol.
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.
6. IANA Considerations
This section explains the criteria to be used by the IANA for
assignment of PAC TLV attribute and PAC-Type values. The
Cam-Winget, et al. Expires September 5, 2006 [Page 31]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
"Specification Required" policy is used here with the meaning defined
in BCP 26 [RFC2434].
7. References
7.1 Normative
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[EAP] Blunk, L., et. al., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3546] Blake-Wilson, S., et al., "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[EAP-FAST] Cam-Winget, N., et al., "EAP Flexible Authentication via
Secure Tunneling (EAP-FAST) ", draft-cam-winget-eap-fast-
03 (work in progress), April 2006.
[TICKET] Salowey, J., et al, "TLS Session Resumption without
Server-Side State", draft-salowey-tls-ticket-07.txt,
January 2006
[MSCHAPv2] Zorn, G., Microsoft PPP CHAP Extensions, Version 2, RFC
2759, January 2000.
[RFC2315] Kaliski, B., PKCS #7: Cryptographic Message Syntax
Version 1.5, RFC 2315, March 1998.
7.2 Informative
Cam-Winget, et al. Expires September 5, 2006 [Page 32]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October
1998.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, January 1999.
[RFC3526] Kivinen, T., "More Modular Exponential (MODP) Diffie-
Hellman groups for Internet Key Exchange (IKE)", RFC
3526, May 2003
[MITM]
Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (expired),
October 2003.
8. Acknowledgments
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.
9. Author's Addresses
Nancy Cam-Winget
Cisco Systems
3625 Cisco Way
San Jose, CA 95134
US
Phone: +1 408 853 0532
E-mail: ncamwing@cisco.com
David McGrew
Cisco Systems
San Jose, CA 95134
US
E-mail: mcgrew@cisco.com
Joseph Salowey
Cam-Winget, et al. Expires September 5, 2006 [Page 33]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
US
Phone: +1 206 256 3380
E-mail: jsalowey@cisco.com
Hao Zhou
Cisco Systems
4125 Highlander Parkway
Richfield, OH 44286
US
Phone : +1 330 523 2132
E-mail: hzhou@cisco.com
10. Appendix: Examples
10.1 Example 1: Successful Tunnel PAC Provisioning
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-Type=EAP-FAST, V=1
(EAP-FAST Start, S bit set, A-ID)
EAP-Response/
EAP-Type=EAP-FAST, V=1
(TLS client_hello without
PAC-Opaque extension)->
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(TLS server_hello,
TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/
EAP-Type=EAP-FAST, V=1 ->
Cam-Winget, et al. Expires September 5, 2006 [Page 34]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
(TLS Client Key Exchange
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(TLS change_cipher_spec
TLS finished)
EAP-Response/
EAP-Type=EAP-FAST, V=1 ->
(Acknowledgement)
TLS channel established
(messages sent within the TLS channel)
<- EAP Payload TLV,
EAP-Request/
EAP Identity Request
EAP Payload TLV, EAP-Response/
EAP Identity Response ->
<- EAP Payload TLV,
EAP-Request,
EAP-MSCHAPV2, Challenge
EAP Payload TLV, EAP-Response,
EAP-MSCHAPV2, Response) ->
<- EAP Payload TLV,
EAP-Request, MSCHAPV2, Success)
EAP Payload TLV, EAP-Response,
MSCHAPV2, Success) ->
<- Intermediate Result TLV (Success)
Binding-TLV=(Version=1,SNonce,
CompoundMAC)
Intermediate Result TLV (Success)
Binging-TLV=(Version=1,
CNonce, CompoundMAC)
<- Result TLV (Success)
PAC TLV
Result TLV (Success)
Cam-Winget, et al. Expires September 5, 2006 [Page 35]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
PAC Acknowledgment ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
10.2 Example 2: Successful Tunnel PAC Provisioning with Password Change
The following exchanges show where EAP-MSCHAPv2 with password
change 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-Type=EAP-FAST, V=1
(EAP-FAST Start, S bit set, A-ID)
EAP-Response/
EAP-Type=EAP-FAST, V=1
(TLS client_hello without
PAC-Opaque extension)->
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/
EAP-Type=EAP-FAST, V=1 ->
(TLS Client Key Exchange
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(TLS change_cipher_spec
TLS finished)
EAP-Response/
EAP-Type=EAP-FAST, V=1 ->
Cam-Winget, et al. Expires September 5, 2006 [Page 36]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
(Acknowledgement)
TLS channel established
(messages sent within the TLS channel)
<- EAP Payload TLV
EAP-Request/
EAP Identity Request
EAP Payload TLV
EAP-Response/
EAP Identity Response ->
<- EAP-Payload TLV
EAP-Request/
EAP-MSCHAPV2, Challenge
EAP Payload TLV, EAP-Response,
EAP-MSCHAPV2, Response) ->
<- EAP Payload TLV,
EAP-Request, MSCHAPV2, Failure,
Error Code =
ERROR_PASSWD_EXPIRED (E=648))
EAP Payload TLV, EAP-Response,
MSCHAPV2, Change Password Response) ->
<- EAP Payload TLV, EAP-Request,
MSCHAPV2, Success)
EAP Payload TLV, EAP-Response,
MSCHAPV2, Success) ->
<- Intermediate Result TLV (Success)
Binding-TLV=(Version=1,SNonce,
CompoundMAC)
Intermediate Result TLV (Success)
Binging-TLV=(Version=1,
CNonce, CompoundMAC)
<- Result TLV (Success)
PAC TLV
Cam-Winget, et al. Expires September 5, 2006 [Page 37]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
Result TLV (Success)
PAC Acknowledgement ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
10.3 Example 3: Failed Provisioning
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-Type=EAP-FAST, V=1
(EAP-FAST Start, S bit set, A-ID)
EAP-Response/
EAP-Type=EAP-FAST, V=1
(TLS client_hello without
PAC-Opaque extension)->
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/
EAP-Type=EAP-FAST, V=1 ->
(TLS Client Key Exchange
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(TLS change_cipher_spec
TLS finished)
EAP-Response/
Cam-Winget, et al. Expires September 5, 2006 [Page 38]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
EAP-Type=EAP-FAST, V=1 ->
(Acknowledgement)
TLS channel established
(messages sent within the TLS channel)
<- EAP Payload TLV
EAP-Request/EAP Identity Request
Eap Payload TLV
EAP-Response/
EAP Identity Response ->
<- 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, Failure) ->
<- Result TLV (Failure)
Result TLV (Failure) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
10.4 Example 4: Provisioning a Authentication Servers Trusted Root
Certificate
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
Cam-Winget, et al. Expires September 5, 2006 [Page 39]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(EAP-FAST Start, S bit set, A-ID)
EAP-Response/
EAP-Type=EAP-FAST, V=1
(TLS client_hello without
PAC-Opaque extension)->
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(TLS server_hello,
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/
EAP-Type=EAP-FAST, V=1 ->
(TLS Client Key Exchange
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(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 Identity Response] ->
<- EAP Payload TLV, EAP-Request,
[EAP-MSCHAPV2, Challenge]
Cam-Winget, et al. Expires September 5, 2006 [Page 40]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
EAP Payload TLV, EAP-Response,
[EAP-MSCHAPV2, Response] ->
<- EAP Payload TLV, EAP-Request,
[EAP-MSCHAPV2, Success Request]
EAP Payload TLV, EAP-Response,
[EAP-MSCHAPV2, Success Response] ->
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
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
10.5 Example 5: Provisioning a User Authorization PAC
The following exchanges demonstrate how a User Authorization PAC is
provisioned in Phase 2. The conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(EAP-FAST Start, S bit set, A-ID)
Cam-Winget, et al. Expires September 5, 2006 [Page 41]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
EAP-Response/
EAP-Type=EAP-FAST, V=1
(TLS client_hello with
PAC-Opaque extension)->
<- EAP-Request/
EAP-Type=EAP-FAST, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-FAST, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- EAP-Payload TLV, EAP-Request,
EAP-GTC, Challenge
EAP-Payload TLV, EAP-Response,
EAP-GTC, Response with both
user name and password) ->
optional additional exchanges (new pin mode,
password change etc.) ...
<- Crypto-Binding TLV=(Version=1,
EAP-FAST Version =1, Nonce,
CompoundMAC)
Result TLV (Success)
Crypto-Binding TLV=(Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC)
Result TLV (Success)
Request-Action TLV
(Action=1-Process TLV)
PAC TLV with PAC-Type=User Authorization PAC)->
<- Result TLV (Success)
PAC TLV with User Authorization
PAC
Cam-Winget, et al. Expires September 5, 2006 [Page 42]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
Result TLV (Success) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
11. Intellectual Property Statement
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.
12. Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Cam-Winget, et al. Expires September 5, 2006 [Page 43]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2006
13. Copyright Statement
Copyright (C) The Internet Society (2006). 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.
14. Expiration Date
This memo is filed as <draft-cam-winget-eap-fast-provisioning-
02.txt>, and expires September 5, 2006.
Cam-Winget, et al. Expires September 5, 2006 [Page 44]
