One document matched: draft-cam-winget-eap-fast-provisioning-04.txt
Differences from draft-cam-winget-eap-fast-provisioning-03.txt
Network Working Group N. Cam-Winget
Internet-Draft D. McGrew
Intended status: Informational J. Salowey
Expires: September 5, 2007 H. Zhou
Cisco Systems
March 4, 2007
Dynamic Provisioning using Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol (EAP-FAST)
draft-cam-winget-eap-fast-provisioning-04
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.
This Internet-Draft will expire on September 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Cam-Winget, et al. Expires September 5, 2007 [Page 1]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
Abstract
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.
Cam-Winget, et al. Expires September 5, 2007 [Page 2]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Specification Requirements . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. EAP-FAST Provisioning Modes . . . . . . . . . . . . . . . . . 7
3. Dynamic Provisioning using EAP-FAST Conversation . . . . . . . 8
3.1. Network Access after EAP-FAST Provisioning . . . . . . . . 8
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
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Peer-Id, Server-Id and Session-Id . . . . . . . . . . . . 11
3.6. Provisioning or Refreshment of a PAC . . . . . . . . . . . 11
4. Information Provisioned in EAP-FAST . . . . . . . . . . . . . 13
4.1. Protected Access Credential . . . . . . . . . . . . . . . 13
4.2. PAC TLV Format . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Formats for PAC Attributes . . . . . . . . . . . . . . 15
4.2.2. PAC-Key . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. PAC-Opaque . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4. PAC-Info . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.5. PAC-Acknowledgement TLV . . . . . . . . . . . . . . . 19
4.2.6. PAC-Type TLV . . . . . . . . . . . . . . . . . . . . . 20
4.3. Trusted Server Root Certificate . . . . . . . . . . . . . 20
4.3.1. Server-Trusted-Root TLV . . . . . . . . . . . . . . . 21
4.3.2. PKCS #7 TLV . . . . . . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5.1. Mitigation of Dictionary Attacks . . . . . . . . . . . . . 24
5.2. Mitigation of Man-in-the-middle (MitM) attacks in
server- unauthenticated provisioning mode . . . . . . . . 25
5.3. Mitigation of Man-in-the-middle (MitM) attacks in
server- authenticated provisioning mode . . . . . . . . . 26
5.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 26
5.5. PAC Storage Considerations . . . . . . . . . . . . . . . . 27
5.6. Security Claims . . . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Cam-Winget, et al. Expires September 5, 2007 [Page 3]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
Appendix A. Appendix: Examples . . . . . . . . . . . . . . . . . 33
A.1. Example 1: Successful Tunnel PAC Provisioning . . . . . . 33
A.2. Example 2: Failed Provisioning . . . . . . . . . . . . . . 34
A.3. Example 3: Provisioning a Authentication Server's
Trusted Root Certificate . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39
Cam-Winget, et al. Expires September 5, 2007 [Page 4]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
1. Introduction
EAP-FAST [I-D.cam-winget-eap-fast] is an EAP method that can be used
to mutually authenticate peer and server. However, to mutually
authenticate with EAP-FAST, credentials such as a pre-shared key,
trusted anchor or a Protected Access Credential (PAC) must be
provisioned to the peer before it can establish a secure
communication channel with the server. In many cases, the
provisioning of such information presents deployment hurdles.
Through the use of the protected tunnel, EAP-FAST can also be used to
enable the means for dynamic 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:
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.
Cam-Winget, et al. Expires September 5, 2007 [Page 5]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
Tunnel PAC
A set of credentials stored by the peer and consumed by both the
peer and the server to establish a TLS tunnel.
Cam-Winget, et al. Expires September 5, 2007 [Page 6]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
2. EAP-FAST Provisioning Modes
EAP-FAST supports two modes for provisioning:
1. Server-Authenticated Mode - Provisioning inside a TLS tunnel that
provides server-side authentication.
2. Server-Unauthenticated Mode Mode - Provisioning inside a TLS
tunnel without server-side authentication.
The EAP-FAST provisioning modes use the secure TLS tunnel of phase 2
that is established during phase 1. [I-D.cam-winget-eap-fast]
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 peer
before provisioning any information.
In the Server-Unauthenticated Provisioning mode, an unauthenticated
TLS tunnel is established in the EAP-FAST Phase 1. This provisioning
mode enables the bootstrapping of peers where the peer lacks strong
credentials usable for mutual authentication with the server. The
peer may negotiate a TLS_DH_anon based cipher suites to signal that
it wishes to use Server-Unauthenticateded provisioning mode. Other
cipher suites requiring the use of server certificates may be used
and are considered unauthenticated if the peer may lacks the
necessary trust anchors to validate the server certificate chain.
Since the server is not authenticated in the Server-Unauthenticated
Provisioning mode, it is possible that an attacker may intercept the
TLS tunnel. When it is possible an inner EAP method should be used
to provide some authentication and MitM detection as outlined in
Section 5. 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 any inner EAP method and 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.
Cam-Winget, et al. Expires September 5, 2007 [Page 7]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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 TLS tunnel. This
version of the EAP-FAST provisioning mode implementation MUST support
the following TLS ciphersuites defined in [RFC2246], [RFC4346] and
[RFC3268]:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Other TLS ciphersuites MAY be supported. To adhere to best security
practices, it is highly RECOMMENDED that the peer validate the
server's certificate chain when performing server-side
authentication. 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. Anonymous
ciphersuites SHOULD NOT be allowed outside of EAP-FAST provisioning
mode. Ciphersuites that are used for provisioning MUST provide
encryption.
Once a protected tunnel is established, the peer and server can then
execute an EAP method and provision credential information. The
internal EAP method can be used to authenticate the peer to the
server if this was not accomplished in EAP-FAST phase 1.
Additionally the internal EAP method can provide an additional check
on the integrity of the TLS tunnel if server side authentication was
not performed in phase 1. Following a successful 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 a PAC-TLV exchange that
is executed following a successful authentication exchange including
the Intermediate Result TLV and Crypto-Binding TLV. 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.
3.1. Network Access after EAP-FAST Provisioning
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
Cam-Winget, et al. Expires September 5, 2007 [Page 8]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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 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 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.
3.2. Authenticating Using EAP-MSCHAPv2
This version of the EAP-FAST provisioning mode implementation MUST
support EAP-MSCHAPv2 as the inner authentication method for enabling
Server-Unauthenticated Provisioning Mode using an anonymous Diffie-
Hellman key agreement. 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:
o Provide the ability of slowing an active attack by using a hash
based challeng-response protocol.
o The use of a challenge response protocol such as MSCHAPv2 provides
some ability to detect a man-in-the-middle attack during server-
unauthenticated provisioning.
Cam-Winget, et al. Expires September 5, 2007 [Page 9]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
o A large deployed base is already able to support MSCHAPv2
o It allows support for password change during the EAP-FAST
Provisioning mode.
The MSCHAPv2 [RFC2759] 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 mode to force the man-in-the-middle, acting as the
server, to successfully break the password within the client's
challenge response time limit.
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. 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 authenticates itself
to the server before the server can provision the peer. If the
authentication mechanism is not EAP-MSCHAPv2 a ciphersuite that
provides server side authentication, such as
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, MUST be used. Within a server side
authenticated tunnel authentication mechanisms such as EAP-GTC 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. Thus Server-Authenticated Provisioning Mode is the
preferred provisioning mode. The EAP-FAST peer MUST use the Server-
Authenticated Provisioning Mode whenever it is configured with a
trust root for the purpose of validating the EAP server's
certificate.
3.4. Key Derivations Used in the EAP-FAST Provisioning Exchange
The TLS tunnel key is calculated according to the TLS [RFC2246] with
an extra 72 octets of key material. Portions of the extra 72 octets
Cam-Winget, et al. Expires September 5, 2007 [Page 10]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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[seed_size= 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.
3.5. Peer-Id, Server-Id and Session-Id
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 [I-D.cam-winget-eap-fast] techniques.
[I-D.cam-winget-eap-fast] Section 3.4 describes how the Peer-Id and
Server-Id are determined; Section 3.5 describes how the Session-Id is
generated.
3.6. Provisioning or Refreshment of a PAC
The server may provision or refresh information by use of the
Protected Access Credential (PAC) anytime after a successful peer
authentication followed by a successful Intermediate Result TLV and
Cam-Winget, et al. Expires September 5, 2007 [Page 11]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
Crypto-Binding TLV exchange. 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 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.
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 peer's PAC through the PAC TLV mechanism even if the PAC-
Key has expired.
Cam-Winget, et al. Expires September 5, 2007 [Page 12]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
4. Information Provisioned in EAP-FAST
In addition to the Tunnel PAC (used to establish the EAP-FAST Phase 1
TLS tunnel), 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
validate their authenticity 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.
4.1. Protected Access Credential
A Protected Access Credential (PAC) is a security credential provided
by the Authentication Server (AS) 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 a PAC Type and PAC attributes defined in this section. The
type of PAC described in this document is a Tunnel PAC which is used
to establish the EAP-FAST TLS tunnel.
The server distributes the Tunnel PAC to the peer which uses it when
it attempts to establish a secure EAP-FAST TLS tunnel with the
server. The Tunnel PAC conveys the server policy of what must and
can occur in the tunnel. The server policy can include EAP methods,
TLV exchanges and identities allowed in the tunnel. It is up to the
server policy to include what's 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 TLS ciphersuites are allowed. If the server policy is not
included in a PAC, then there is no limitation imposed by the PAC
usage on 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-
Cam-Winget, et al. Expires September 5, 2007 [Page 13]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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 for an example of packet exchanges to
provision a Tunnel PAC.
4.2. PAC TLV Format
The PAC TLV provides support for provisioning the Protected Access
Credential (PAC) defined within [I-D.cam-winget-eap-fast]. 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. 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
Two octets containing length of the PAC Attributes field in
octets
Cam-Winget, et al. Expires September 5, 2007 [Page 14]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
PAC Attributes
A list of PAC attributes in the TLV format
4.2.1. Formats for PAC Attributes
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
Cam-Winget, et al. Expires September 5, 2007 [Page 15]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
4.2.2. PAC-Key
The PAC-Key is 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 representing a 32 octet long key
Key
The value of the PAC key
4.2.3. PAC-Opaque
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 [RFC4507]. 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
Cam-Winget, et al. Expires September 5, 2007 [Page 16]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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.
4.2.4. PAC-Info
PAC-Info is comprised of a set of PAC attributes as defined in
Section 4.2.1. 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cam-Winget, et al. Expires September 5, 2007 [Page 17]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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:
PAC-LIFETIME (type 3)
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.
A-ID (type 4)
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.
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. If the AS
is enforcing the I-ID validation on inner EAP method, then
I-ID MUST be included 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
Cam-Winget, et al. Expires September 5, 2007 [Page 18]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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] format. This attribute MUST be
included in the PAC-Info.
PAC-type (type 10)
PAC-Type is a mandatory TLV intended to provide the type of
PAC. This field SHOULD be included in the PAC-Info. For
legacy implementations, if PAC-Type is not present, then it
defaults to a Tunnel PAC (Type 1).
4.2.5. PAC-Acknowledgement TLV
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 new 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
Cam-Winget, et al. Expires September 5, 2007 [Page 19]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
4.2.6. PAC-Type TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
4.3. Trusted Server Root Certificate
Server-Trusted-Root TLV facilitates the request and delivery of a
trusted server root certificates. 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
can 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 of from the EAP server. **** why
would it send more than one *** 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
Cam-Winget, et al. Expires September 5, 2007 [Page 20]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
Section Appendix A.3 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 list of trusted roots. The server may respond with
one or more root certificates in PKCS#7 [RFC2315] 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
Length
>=2 octets
Cam-Winget, et al. Expires September 5, 2007 [Page 21]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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. In the case of the
provision request from the peer it is empty.
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 [RFC2315] 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 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)
Cam-Winget, et al. Expires September 5, 2007 [Page 22]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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.
Cam-Winget, et al. Expires September 5, 2007 [Page 23]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
5. Security Considerations
The Dynamic Provisioning EAP-FAST protocol shares the same security
considerations outlined in [I-D.cam-winget-eap-fast]. Additionally,
it also has its unique security considerations described below:
5.1. 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 TLS key agreement in one of two ways: anonymously
or server-authenticated. With a server-authenticated TLS key
agreement, the server provides its certificate and be authenticated
by the peer, whereas in an anonymous TLS key agreement, the server is
not authenticated as part of the TLS tunnel establishment.
In a server authenticated TLS key agreement, the protected
communications is assured that the AS is authentic as the peer must
have been pre-provisioned with the AS's trusted root certificate or
public key prior to the negotiation. In this instance, the AS
provides proof of identity through an identity and (certificate)
credential, preventing an adversary from posing as an AS to mount a
dictionary attack. An EAP-FAST implementation must assure secure
provisioning of the AS public key, certificate or root certificate to
the peer. While this follows 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 server's 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 peer's
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. With MSCHAPv2, a peer may detect it is under attack when the
AS 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. For this reason, an EAP-FAST compliant
implementation MUST support an MSCHAPv2 or stronger EAP method for
peer authentication when an anonymous DH key agreement is used for
Cam-Winget, et al. Expires September 5, 2007 [Page 24]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
the tunnel establishment. Cleartext passwords MUST NOT be used in
anonymous provisioning mode.
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 server's public key or trust root certificate
securely to invoke the Server-Authenticated provisioning.
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.2. Mitigation of Man-in-the-middle (MitM) attacks in server-
unauthenticated provisioning mode
EAP-FAST invocation of provisioning addresses MitM attacks in server-
unauthenticated provisioning mode in the following way:
o 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.
o Cryptographic binding of EAP-FAST Phase 1 and the Phase 2
authentication method: by cryptographically binding key material
generated in all phases, both peer and AS are assured that they
were the sole participants of all transpired phases.
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
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 adversary's attempt to
Cam-Winget, et al. Expires September 5, 2007 [Page 25]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
respond with a challenge response (e.g. indication of whether the
adversary succeeded in breaking the peer's 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.3. Mitigation of Man-in-the-middle (MitM) attacks in server-
authenticated provisioning mode
EAP-FAST provisioning in server-authenticated mode addresses MitM
attacks by enforcing the server to present a valid certificate as
part of the TLS negotiation. To ensure the authenticity of the
server and address MitM attacks, the peer MUST verify the validity of
the EAP server certificate to guarantee it is not subject to a MitM
attack.
The cryptographic binding is another reassurance that indeed the true
peer and AS were the two parties communicating in both the tunnel
establishment and inner EAP authentication conversations.
5.4. Diffie-Hellman Groups
Implementations of EAP-FAST anonymous provisioning modes MUST support
the Diffie-Hellman groups defined in [RFC3526].
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]. 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].
Cam-Winget, et al. Expires September 5, 2007 [Page 26]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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] to generate AES keys, the DH keys should provide enough
entropy to ensure that a strong 128bit results from the DH key
agreement.
5.5. PAC Storage Considerations
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 client and server. There are a number of potential attacks
which can be considered against secure key storage such as:
o Weak Passphrases
On the peer 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 email 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.
o Key Finding Attacks
Key finding attacks are usually mentioned in reference to web
Cam-Winget, et al. Expires September 5, 2007 [Page 27]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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.
o 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 peer or
server to force a PAC re-key, and take advantage of the potential
MitM/dictionary attack vulnerability of the EAP-FAST Server-
Unauthenticated Provisioning Mode.
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.
5.6. Security Claims
The [RFC3748] security claims for EAP-FAST are given in Section 7.8
of [I-D.cam-winget-eap-fast]. 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.
Cam-Winget, et al. Expires September 5, 2007 [Page 28]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
6. IANA Considerations
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].
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 10 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 10 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 10 to 63 are reserved. Values 64 to 255 are assigned
with a specification required policy.
Cam-Winget, et al. Expires September 5, 2007 [Page 29]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
7. Acknowledgements
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.
Cam-Winget, et al. Expires September 5, 2007 [Page 30]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
8. References
8.1. Normative References
[I-D.cam-winget-eap-fast]
Salowey, J., "The Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol Method (EAP-
FAST)", draft-cam-winget-eap-fast-06 (work in progress),
January 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March 1998.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
RFC 2759, January 2000.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 4507, May 2006.
8.2. Informative References
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
Cam-Winget, et al. Expires September 5, 2007 [Page 31]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
October 1998.
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman
Group Exchange for the Secure Shell (SSH) Transport Layer
Protocol", RFC 4419, March 2006.
Cam-Winget, et al. Expires September 5, 2007 [Page 32]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
Appendix A. Appendix: Examples
A.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 Finished TLS Server Hello Done)
EAP-Response/
EAP-Type=EAP-FAST, V=1 ->
(TLS Client Key Exchange
TLS Change Cipher Spec,
)
<- 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
Cam-Winget, et al. Expires September 5, 2007 [Page 33]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
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, 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)
<- Result TLV (Success)
PAC TLV
Result TLV (Success)
PAC Acknowledgment ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
A.2. Example 2: 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
Cam-Winget, et al. Expires September 5, 2007 [Page 34]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
(EAP-FAST Start, S bit set, A-ID)
EAP-Response/
EAP-Type=EAP-FAST, V=1
(TLS Client Hello without
Ticket 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-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,
EAP-MSCHAPV2, Success)
// peer failed to verify server MSCHAPv2 response
EAP Payload TLV, EAP-Response,
EAP-MSCHAPV2, Failure) ->
Cam-Winget, et al. Expires September 5, 2007 [Page 35]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
<- Result TLV (Failure)
Result TLV (Failure) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
A.3. Example 3: Provisioning a Authentication Server's 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
------------------- -------------
<- 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
Ticket 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])
Cam-Winget, et al. Expires September 5, 2007 [Page 36]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
// 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]
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
Cam-Winget, et al. Expires September 5, 2007 [Page 37]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
Authors' Addresses
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.co
Cam-Winget, et al. Expires September 5, 2007 [Page 38]
Internet-Draft Dynamic Provisioning using EAP-FAST March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Cam-Winget, et al. Expires September 5, 2007 [Page 39]
| PAFTECH AB 2003-2026 | 2026-04-23 02:06:06 |