< draft-cam-winget-eap-fast-provisioning-00.txt   draft-cam-winget-eap-fast-provisioning-01.txt >
Internet-Draft Dynamic Provisioning using EAP-FAST July 2005
Network Working Group N. Cam-Winget Network Working Group N. Cam-Winget
Internet Draft D. McGrew Internet Draft D. McGrew
Category: Informational J. Salowey Category: Informational J. Salowey
Expires: January 11, 2006 H. Zhou Expires: January 17, 2006 H. Zhou
Cisco Sytems Cisco Sytems
July 11, 2005 July 17, 2005
Dynamic Provisioning using EAP-FAST Dynamic Provisioning using EAP-FAST
draft-cam-winget-eap-fast-provisioning-00.txt draft-cam-winget-eap-fast-provisioning-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 9 skipping to change at page 2, line 16
EAP-FAST is an extensible EAP method that enables secure EAP-FAST is an extensible EAP method that enables secure
communication between a client and a server by using the Transport communication between a client and a server by using the Transport
Layer Security (TLS) to establish a mutually authenticated tunnel. Layer Security (TLS) to establish a mutually authenticated tunnel.
EAP-FAST also enables the provisioning credentials or other EAP-FAST also enables the provisioning credentials or other
information thru this protected tunnel. This document describes the information thru this protected tunnel. This document describes the
use of EAP-FAST for dynamic provisioning. use of EAP-FAST for dynamic provisioning.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction........................................... 3
1.1. Specification Requirements.............................3 1.1. Specification Requirements........................ 3
1.2. Terminology............................................3 1.2. Terminology..................................... 3
2. EAP-FAST Provisioning Modes....................................5 2. EAP-FAST Provisioning Modes.............................. 4
3. Dynamic Provisioning using EAP-FAST Conversation...............6 3. Dynamic Provisioning using EAP-FAST Conversation............ 5
3.1 Network Access after EAP-FAST Provisioning.................8 3.1 Network Access after EAP-FAST Provisioning............. 8
3.2 Key Derivations Used in the EAP-FAST Provisioning Exchange.9 3.2 Authenticating Using MSCHAPv2......................... 9
3.3 Authenticating Using PeerÆs <username, password>..........10 3.3 Use of other Inner EAP Methods for EAP-FAST Provisioning.10
3.4 Use of other Inner EAP Methods for EAP-FAST Provisioning..11 3.4 Key Derivations Used in the EAP-FAST Provisioning Exchange11
3.5 Provisioning or Refreshment of a PAC......................12 3.5 Provisioning or Refreshment of a PAC...................12
4. Types of Information Provisioned in EAP-FAST..................13 4. Types of Information Provisioned in EAP-FAST...............13
4.1 Provisioning through PAC TLV..............................13 4.1 PAC Types..........................................13
4.1.1 Formats for PAC TLV Attributes .....................14 4.2 Provisioning PACs through PAC TLV.....................16
4.1.2 PAC-Key ............................................15 4.2.1 Formats for PAC TLV Attributes ..................17
4.1.3 PAC-Opaque .........................................15 4.2.2 PAC-Key ........................................18
4.1.4 PAC-Info............................................17 4.2.3 PAC-Opaque .....................................18
4.1.5 PAC-Acknowledgement TLV ............................18 4.2.4 PAC-Info ........................................20
4.1.6 PAC-Type TLV........................................19 4.2.5 PAC-Acknowledgement TLV .........................21
4.1.7 Server Trusted Root Certificate ....................20 4.2.6 PAC-Type TLV.....................................22
4.2 PAC Types.................................................20 4.3 Server Trusted Root Certificate.......................23
5. Security Considerations.......................................22 4.3.1 Server-Trusted-Root TLV .........................23
5.1 User Identity Protection and Validation...................23 4.3.2 PKCS #7 TLV .....................................25
5.2 Mitigation of Dictionary Attacks..........................23 5. Security Considerations.................................26
5.3 Mitigation of Man-in-the-middle (MitM) attacks............24 5.1 User Identity Protection and Validation................26
5.4 PAC Validation and User Credentials.......................25 5.2 Mitigation of Dictionary Attacks......................27
5.5 Generation of Diffie-Hellman Groups.......................26 5.3 Mitigation of Man-in-the-middle (MitM) attacks..........28
6. IANA Considerations...........................................26 5.4 PAC Validation and User Credentials ...................29
7. References....................................................26 5.5 Generation of Diffie-Hellman Groups ...................29
7.1 Normative.................................................26 5.6 PAC Storage Considerations...........................30
7.2 Informative...............................................27 6. IANA Considerations.....................................31
8. Acknowledgments...............................................28 7. References.............................................32
9. Author's Addresses............................................28 7.1 Normative..........................................32
10. Appendix: Examples...........................................29 7.2 Informative........................................32
10.1 Example 1: Successful Provisioning.......................29 8. Acknowledgments........................................33
10.2 Example 2: Successful Provisioning with Password Change..31 9. Author's Addresses......................................33
10.3 Example 3: Failed Provisioning...........................32 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 ServerÆs Trusted 10.4 Example 4: Provisioning a Authentication ServerÆs Trusted
Root Certificate..............................................34 Root Certificate .......................................39
10.5 Example 5: Provisioning a User Authorization PAC.........36 10.5 Example 5: Provisioning a User Authorization PAC.......41
11. Intellectual Property Statement..............................37 11. Intellectual Property Statement .........................43
12. Disclaimer of Validity.......................................38 12. Disclaimer of Validity.................................43
13. Copyright Statement..........................................38 13. Copyright Statement....................................44
14. Expiration Date..............................................38 14. Expiration Date .......................................44
1. Introduction 1. Introduction
[EAP-FAST] is an extensible EAP method that can be used to mutually [EAP-FAST] is an extensible EAP method that can be used to mutually
authenticate peer and server. However, to mutually authenticate with authenticate peer and server. However, to mutually authenticate with
EAP-FAST, credentials such as a preshared key, trusted anchor or a 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 Tunnel PAC MUST be provisioned to the peer before it can establish a
secure association with the server. In some cases, the provisioning secure association with the server. In some cases, the provisioning
of such information present deployment hurdles. Through the use of of such information present deployment hurdles. Through the use of
the protected tunnel, EAP-FAST can also be used to enable the means the protected tunnel, EAP-FAST can also be used to enable the means
skipping to change at page 3, line 25 skipping to change at page 3, line 42
obstacles. obstacles.
1.1. Specification Requirements 1.1. Specification Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
Some of the following terms are taken from EAP [RFC3748]: Much of the terminology in this document comes from [RFC3748].
Additional terms are defined below:
EAP Server
The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used,
the EAP server is part of the authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server.
Authenticator
The end of the link initiating EAP authentication. The term
Authenticator is used in [IEEE-802.1x], and has the same meaning in
this document.
Peer
The end of the link that responds to the authenticator. In
[IEEE-802.1x], this end is known as the Supplicant.
Supplicant
The end of the link that responds to the authenticator in [IEEE-
802.1x]. In this document, this end of the link is called the
peer.
Back End Authentication Server
A back end authentication server is an entity that provides an
authentication service to an authenticator. When used, this server
typically executes EAP methods for the authenticator. This
terminology is also used in [IEEE-802.1x].
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in
length. In existing implementations, an AAA server acting as an
EAP server transports the MSK to the authenticator.
Man in the Middle (MitM) Man in the Middle (MitM)
An adversary that can successfully inject itself between a peer and An adversary that can successfully inject itself between a peer and
EAP server. The MitM succeeds by impersonating itself as a valid EAP server. The MitM succeeds by impersonating itself as a valid
peer, authenticator or authentication server. peer, authenticator or authentication server.
Message Authentication Code (MAC)
A MAC is a function that takes a variable length input and a key to
produce a fixed-length output to carry authentication and integrity
protection of data.
Message Integrity Check (MIC)
A keyed hash function used for authentication and integrity
protection of data. This is usually called a Message
Authentication Code (MAC), but IEEE 802 specifications (and this
document) use the acronym MIC to avoid confusion with Medium Access
Control.
Provisioning Provisioning
Providing peer with a trust anchor, shared secret or other Providing peer with a trust anchor, shared secret or other
appropriate information based on which a security association can appropriate information based on which a security association can
be established. be established.
Protected Access Credential (PAC) Protected Access Credential (PAC)
Credentials distributed to a peer for future optimized network Credentials distributed to a peer for future optimized network
authentication. The PAC consists of at most three components: a authentication. The PAC consists of at most three components: a
shared secret, an opaque element and optionally other information. shared secret, an opaque element and optionally other information.
The shared secret part contains the pre-shared key between the peer The shared secret part contains the pre-shared key between the peer
and authentication server. The opaque part is provided to the peer and authentication server. The opaque part is provided to the peer
and is presented to the authentication server when the peer wishes and is presented to the authentication server when the peer wishes
to obtain access to network resources. Finally, a PAC may to obtain access to network resources. Finally, a PAC may
optionally include other information that may be useful to the optionally include other information that may be useful to the
client. client.
Silently Discard
This means the implementation discards the packet without further
processing. The implementation SHOULD provide the capability of
logging the event, including the contents of the silently discarded
packet, and SHOULD record the event in a statistics counter.
Successful Authentication
In the context of this document, "successful authentication" is an
exchange of EAP messages, as a result of which the authenticator
decides to allow access by the peer, and the peer decides to use
this access. The authenticator's decision typically involves both
authentication and authorization aspects; the peer may successfully
authenticate to the authenticator but access may be denied by the
authenticator due to policy reasons.
2. EAP-FAST Provisioning Modes 2. EAP-FAST Provisioning Modes
EAP-FAST supports two modes for provisioning: EAP-FAST supports two modes for provisioning:
1) Server-Authenticated Mode: Provisioning inside a server 1) Server-Authenticated Mode: Provisioning inside a server
authenticated (TLS) tunnel. authenticated (TLS) tunnel.
2) Server-Unauthenticated Mode: Provisioning inside an 2) Server-Unauthenticated Mode: Provisioning inside an
unauthenticated (TLS) tunnel unauthenticated (TLS) tunnel
skipping to change at page 6, line 15 skipping to change at page 5, line 32
The EAP-FAST Phase 2 conversation is unchanged in either Provisioning The EAP-FAST Phase 2 conversation is unchanged in either Provisioning
mode, except that the peer MUST accept an EAP method supporting mode, except that the peer MUST accept an EAP method supporting
mutual authentication and key derivation that is compatible with its mutual authentication and key derivation that is compatible with its
initial or bootstrapping credentials (such as a password-based EAP initial or bootstrapping credentials (such as a password-based EAP
method). The peer then uses the Crypto-Binding TLV to validate that method). The peer then uses the Crypto-Binding TLV to validate that
the same server terminates both the TLS channel and to successfully the same server terminates both the TLS channel and to successfully
complete the EAP method, thereby verifying that the exchange was not complete the EAP method, thereby verifying that the exchange was not
subject to a man-in-the-middle attack. Assuming that the Crypto- subject to a man-in-the-middle attack. Assuming that the Crypto-
Binding TLV exchange is successful, the server will subsequently Binding TLV exchange is successful, the server will subsequently
provide the information such as a shared key or the trusted root(s) provide the information such as a shared key or the trusted root(s)
of server certificate using a PAC TLV. of server certificate using a PAC TLV or a Server Trusted Root TLV
respectively.
Once the EAP-FAST Provisioning conversation completes, the peer is Once the EAP-FAST Provisioning conversation completes, the peer is
expected to use the provisioned credentials in subsequent EAP-FAST expected to use the provisioned credentials in subsequent EAP-FAST
authentications. It is strongly recommended that Server- authentications. It is strongly recommended that either or both peer
Unauthenticated Provisioning mode SHOULD NOT be used more than once. and EAP Server policy enforce Server-Unauthenticated Provisioning
mode to be used no more than once as a means to minimize exposure to
potential MitM attacks.
3. Dynamic Provisioning using EAP-FAST Conversation 3. Dynamic Provisioning using EAP-FAST Conversation
The provisioning EAP-FAST exchange uses same sequence as the EAP-FAST The provisioning EAP-FAST exchange uses same sequence as the EAP-FAST
Authentication Phase 1 to establish a protected tunnel by means of a Authentication Phase 1 to establish a protected tunnel by means of a
Diffie-Hellman (DH) key agreement exchange. Once a tunnel is secured TLS based Diffie-Hellman (DH) key agreement exchange. Once a tunnel
between the two parties, the client and server can then execute an is secured between the two parties, the client and server can then
EAP authentication method by which both parties can achieve mutual execute an EAP authentication method by which both parties can
authentication. achieve mutual authentication.
Provisioning in EAP-FAST is negotiated solely by the client as the Provisioning in EAP-FAST is negotiated solely by the client as the
first communication exchange when EAP-FAST is requested from the first communication exchange when EAP-FAST is requested from the
server. If the client does not have a Protected Access Credential server. If the client does not have a Protected Access Credential
(PAC) or requires provisioning of other information (such as the (PAC) or requires provisioning of other information (such as the
serverÆs Trusted Root certificate), it can request to initiate a serverÆs Trusted Root certificate), it can request to initiate a
provisioning EAP-FAST exchange and dynamically obtain one from the provisioning EAP-FAST exchange and dynamically obtain one from the
server. An EAP-FAST server distinguishes an EAP-FAST Provisioning server.
conversation from an EAP-FAST Authentication Phase 1 by both the
absence of a ClientHello extension and the negotiation of a
TLS_DH_anon_WITH_AES_128_CBC_SHA or TLS_DHE_RSA_WITH_AES_128_CBC_SHA
cipher suite.
The EAP-FAST provisioning conversation will typically occur between The EAP-FAST provisioning conversation will typically occur between
the peer and an authentication server; more specifically, the server the peer and an authentication server; more specifically, the server
that can provision the peer with the requested information; typically, that can provision the peer with the requested information; typically,
a unique PAC. With the EAP-FAST provisioning protocol, the EAP a unique PAC.
identity may be anonymous to further protect the clientÆs identity.
The conversation between a peer and authentication server commences The conversation between a peer and authentication server commences
as a normal EAP-FAST exchange: with an anonymous Identity for a peer as a normal EAP-FAST exchange: with an anonymous Identity for a peer
and the server determining that EAP-FAST authentication is to occur, and the server determining that EAP-FAST authentication is to occur,
the EAP server MUST respond with an EAP-FAST/Start packet. Assuming 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 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- on its device, the peer shall send an EAP-Response packet with EAP-
Type=EAP-FAST. Type=EAP-FAST.
On receipt of the EAP-FAST Start message, the peer determines it must On receipt of the EAP-FAST Start message, the peer determines it must
be provisioned with a fresh PAC. Further, the peer determines be provisioned with a fresh PAC. Further, the peer determines
whether it must invoke a signed or anonymous DH exchange depending on whether it must invoke a signed or anonymous DH exchange.
whether it has the serverÆs public key or trust anchor.
When an anonymous key exchange is negotiated, the signature in the When an anonymous key exchange is negotiated, the signature in the
KeyExchange algorithm shall contain the sha_hash of the records as KeyExchange algorithm shall contain the sha_hash of the records as
defined in [RFC 2246]. If a signed key exchange is negotiated, then defined in [RFC 2246]. If a signed key exchange is negotiated, then
the DH parameters are signed using the serverÆs private key; with a the DH parameters are signed using the serverÆs private key; with a
signed key exchange the server may also include a certificate to signed key exchange the server may also include a certificate to
enable the peer to validate the signature. enable the peer to validate the signature.
To provide best security practices, it is highly recommended that the To provide best security practices, it is highly recommended that the
peer obtain the serverÆs public key or trust anchor to enable server- peer obtain the serverÆs public key or trust anchor to enable server-
skipping to change at page 7, line 42 skipping to change at page 7, line 16
the same exchanges as that defined for EAP-FAST authentication [EAP- the same exchanges as that defined for EAP-FAST authentication [EAP-
FAST]. With a successful EAP-FAST Phase 1 tunnel established, FAST]. With a successful EAP-FAST Phase 1 tunnel established,
subsequent messages exchanged between peer and authentication server subsequent messages exchanged between peer and authentication server
are protected using 128bit AES in CBC mode and HMAC-SHA1 as defined are protected using 128bit AES in CBC mode and HMAC-SHA1 as defined
by both [RFC 2246] and [RFC 3268] to provide message confidentiality by both [RFC 2246] and [RFC 3268] to provide message confidentiality
and integrity respectively. and integrity respectively.
With a protected tunnel, the peer must now authenticate itself to the 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 server before the server can provision it with a PAC. To ensure some
means for authentication and to protect such authentication from means for authentication and to protect such authentication from
exposure, the provisioning EAP-FAST exchange also employs EAP- exposure, the provisioning EAP-FAST exchange also employs [MSCHAPv2]
MSCHAPv2 to achieve mutual authentication before any credentials or to achieve mutual authentication before any credentials or
information can be provisioned. If an anonymous DH exchange ensued information can be provisioned. If an anonymous DH exchange ensued
to establish the tunnel, the MSCHAPv2 exchange is susceptible to an 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 active server-side dictionary attack. However, as it enables in-band
provisioning at the cost of some loss in security strength, it is an provisioning at the cost of some loss in security strength, it is an
option to afford a means for facilitating a deployment with minimal option to afford a means for facilitating a deployment with minimal
to no client (peer) configuration. It is recommended that when using to no client (peer) configuration. To minimize exposure of the
the provisioning EAP-FAST exchange with anonymous DH, it be used no active dictionary attack, it is recommended that the anonymous DH
more than once by a client to provision itself with a PAC; further provisioning EAP-FAST conversation be used only once; further
provisioning or updates of the PAC should be done by means of the provisioning or updates of the PAC should be done by means of the
EAP-FAST PAC refreshing protocol or through some other (manual or EAP-FAST PAC refreshing protocol or through some other (manual or
out-of-band) mechanisms. Finally, it is also recommended that when out-of-band) mechanisms.
using Server-Unauthenticated Provisioning Mode, the server restrict
the use of this mode to a limited time.
The client authentication proceeds by the peer and authentication The client authentication proceeds by the peer and authentication
server engaging in an MSCHAPv2 conversation using invoking the same server engaging in an MSCHAPv2 conversation using invoking the same
EAP-FAST Phase 2 MSCHAPv2 conversation. To further mitigate man-in- EAP-FAST Phase 2 MSCHAPv2 conversation. To further mitigate man-in-
the-middle attacks, the challenges provided by the peer and the-middle attacks in the Server-Unauthenticated Provisioning Mode,
authentication server are generated as part of the TLS establishment the challenges provided by the peer and authentication server are
in the EAP-FAST provisioning exchange and conveyed as the Server and generated as part of the TLS establishment in the EAP-FAST
Client Challenges requested by MSCHAPv2. Further, the random provisioning exchange and conveyed as the Server and Client
challenges are not conveyed in the actual MSCHAPv2 messages, the Challenges requested by MSCHAPv2. Further, the random challenges are
messages shall replace the fields with zeroes to obscure the actual not conveyed in the actual MSCHAPv2 messages, the messages shall
values used to generate the challenge responses. replace the fields with zeroes to obscure the actual values used to
generate the challenge responses.
Following a successful MSCHAPv2 authentication exchange and Following a successful MSCHAPv2 authentication exchange and
successful Intermediate Result TLV and Crypto-Binding TLV exchange, successful Intermediate Result TLV and Crypto-Binding TLV exchange,
the server can then provision the peer with a unique PAC. The the server can then provision the peer with a unique PAC. The
provisioning is invoked through the same mechanism as in PAC provisioning is invoked through the same mechanism as in PAC
refreshment: a PAC-TLV exchange is executed following the successful refreshment: a PAC-TLV exchange is executed following the successful
MSCHAPv2 exchange including the Intermediate Result TLV and Crypto- MSCHAPv2 exchange including the Intermediate Result TLV and Crypto-
Binding TLV exchange, with the server distributing the PAC in a Binding TLV exchange, with the server distributing the PAC in a
corresponding PAC TLV to the peer and the peer confirming its receipt corresponding PAC TLV to the peer and the peer confirming its receipt
in a final PAC TLV Acknowledgement message. in a final PAC TLV Acknowledgement message.
skipping to change at page 8, line 41 skipping to change at page 8, line 19
3.1 Network Access after EAP-FAST Provisioning 3.1 Network Access after EAP-FAST Provisioning
Depending on server policy, network access can be granted or denied Depending on server policy, network access can be granted or denied
based on the EAP-FAST Provisioning mode, the credential(s) or other based on the EAP-FAST Provisioning mode, the credential(s) or other
information that have been provisioned, and the inner EAP methods information that have been provisioned, and the inner EAP methods
used. For example, in the Server-Authenticated Provisioning Mode, used. For example, in the Server-Authenticated Provisioning Mode,
access can be granted after the EAP server has authenticated the peer 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 and provisioned the peer with a Tunnel PAC (e.g. a PAC used to
mutually authenticate the EAP-FAST tunnel). mutually authenticate the EAP-FAST tunnel).
In the case where a peer lacks the trust anchors to validate the Additionally, peer policy may also be used to disconnect the current
serverÆs certificate, the peer may choose proceed with the tunnel provisioning connection and initiate a new EAP-FAST exchange for
establishment by not authenticating the server. In the case where authentication utilizing the newly provisioned information and ensure
the server presents certificate(s) during the tunnel establishment, the inner methods are conducted with the trusted server. The peer
the server can not determine whether the peer actually validated the policy may be required as the peer determines whether it can
certificate and thus can not distinguish whether it has used the authenticate the EAP Server. In the case where a peer lacks the
Server-Authenticated Provisioning mode or the Server-Unauthenticated trust anchors to validate the serverÆs certificate, the peer SHOULD
Provisioning mode. Nonetheless, based on server policy, it may grant negotiate the TLS_DH_anon_WITH_AES_128_CBC_SHA to signal the EAP
network access after it has succeeded authenticating the peer. In server that it lacks the trust anchors to authenticate the server.
this instance, the peer may also have policy instilled by peer policy
to disconnect the current (provisioning) connection and initiate a
new EAP-FAST exchange for authentication utilizing the credentials
newly provisioned information and ensure the inner methods are
conducted with the trusted server.
At the end of the Server-Unauthenticated Provisioning Mode, network At the end of the Server-Unauthenticated Provisioning Mode, network
access SHOULD NOT be granted. EAP server SHOULD conclude with an EAP access SHOULD NOT be granted. EAP server SHOULD conclude with an EAP
Failure to acknowledge that this conversation was intended for Failure to acknowledge that this conversation was intended for
provisioning only and thus no network access is authorized. Upon provisioning only and thus no network access is authorized. Upon
completion of the exchange, the EAP Server SHALL NOT grant network 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 access or distribute any session keys to the NAS as this phase is not
intended to provide network access. Even though provisioning mode intended to provide network access. Even though provisioning mode
completes with a successful inner termination (e.g. successful Result completes with a successful inner termination (e.g. successful Result
TLV), server policy defines whether the peer gains network access or TLV), server policy defines whether the peer gains network access or
skipping to change at page 9, line 39 skipping to change at page 9, line 17
Similarly, if Server-Authenticated Provisioning Mode is used and the Similarly, if Server-Authenticated Provisioning Mode is used and the
server policy is to disallow network access, the EAP Server SHALL NOT server policy is to disallow network access, the EAP Server SHALL NOT
grant network access or distribute any session keys to the NAS as grant network access or distribute any session keys to the NAS as
this phase is not intended to provide network access. Even though this phase is not intended to provide network access. Even though
provisioning mode completes with a successful inner termination (e.g. provisioning mode completes with a successful inner termination (e.g.
successful Result TLV), the EAP-FAST Server-Authenticated successful Result TLV), the EAP-FAST Server-Authenticated
Provisioning Mode MUST conclude with an EAP Failure to acknowledge Provisioning Mode MUST conclude with an EAP Failure to acknowledge
that this conversation was intended for provisioning only and thus no that this conversation was intended for provisioning only and thus no
network access is authorized. The EAP-FAST server may choose to network access is authorized. The EAP-FAST server may choose to
instead, immediately invoke another EAP-FAST Start and thus initiate instead, immediately invoke another EAP authentication transaction.
the EAP-FAST Phase 1 conversation.
3.2 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 +
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 serverÆs MSCHAPv2 challenge and the peerÆs
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.3 Authenticating Using PeerÆs <username, password> 3.2 Authenticating Using MSCHAPv2
While other authentication methods exist to achieve mutual While other authentication methods exist to achieve mutual
authentication, EAP-MSCHAPv2 was chosen for several reasons: 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 * Afford the ability of slowing an active attack by obscuring the
password through some hash password through some hash
* Especially in the Server-Unauthenticated EAP-FAST Provisioning * Especially in the Server-Unauthenticated EAP-FAST Provisioning
conversation MSCHAPv2 affords the ability to detect, based on conversation MSCHAPv2 affords the ability to detect, based on
the challenge responses, whether there is a possible attack. the challenge responses, whether there is a possible attack.
* It is understood that a large deployed base is already able to * It is understood that a large deployed base is already able to
support MSCHAPv2 support MSCHAPv2
skipping to change at page 11, line 26 skipping to change at page 10, line 7
Provisioning protocol. Provisioning protocol.
The MSCHAPv2 exchange forces the server to provide a valid The MSCHAPv2 exchange forces the server to provide a valid
ServerChallengeResponse which must be a function of the server ServerChallengeResponse which must be a function of the server
challenge, client challenge and password as part of its response. challenge, client challenge and password as part of its response.
This reduces the window of vulnerability in the EAP-FAST for in-band 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 provisioning protocol to force the man-in-the-middle, acting as the
server, to successfully break the password within the clientÆs server, to successfully break the password within the clientÆs
challenge response time limit. challenge response time limit.
Currently, EAP-FAST for provisioning only specifies MSCHAPV2 as the EAP-FAST for provisioning only specifies MSCHAPV2 as the inner method
inner method. However, with support of signed DH key agreement, the when using an anonymous DH key agreement. However, with support of
provisioning protocol of EAP-FAST may support other methods such as signed DH key agreement, the provisioning protocol of EAP-FAST may
EAP-GTC to enable peers (using other password databases such as LDAP support other methods such as EAP-GTC to enable peers (using other
and OTP) to be provisioned in-band as well. However, the replacement password databases such as LDAP and OTP) to be provisioned in-band as
may only be achieved when used with the well. However, the replacement may only be achieved when used with
TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite to ensure no loss in the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite to ensure no loss
security. in security.
3.4 Use of other Inner EAP Methods for EAP-FAST Provisioning 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 Once a protected tunnel is established, the peer must authenticate
itself to the server before the server can provision the peer. When 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 using TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite in the EAP-FAST
Phase 1 conversation, EAP-MSCHAPv2 is the only inner method allowed Phase 1 conversation, EAP-MSCHAPv2 is the only inner method allowed
for Dynamic Provisioning in EAP-FAST. for Dynamic Provisioning in EAP-FAST.
The MSCHAPv2 exchange forces the server to provide a valid The MSCHAPv2 exchange forces the server to provide a valid
ServerChallengeResponse which must be a function of the server ServerChallengeResponse which must be a function of the server
challenge, client challenge and password as part of its response. challenge, client challenge and password as part of its response.
skipping to change at page 12, line 35 skipping to change at page 11, line 27
provides significant security advantages over Server-Unauthenticated provides significant security advantages over Server-Unauthenticated
Provisioning even when EAP-MSCHAPv2 is being used as inner method. It Provisioning even when EAP-MSCHAPv2 is being used as inner method. It
protects the EAP-MSCHAPv2 exchanges from potential MitM attacks by protects the EAP-MSCHAPv2 exchanges from potential MitM attacks by
verifying serverÆs authenticity before exchanging MSCHAPv2. Thus verifying serverÆs authenticity before exchanging MSCHAPv2. Thus
Server-Authenticated Provisioning Mode is the preferred provisioning Server-Authenticated Provisioning Mode is the preferred provisioning
mode. The EAP-FAST peer MUST use the Server-Authenticated mode. The EAP-FAST peer MUST use the Server-Authenticated
Provisioning Mode whenever a certificate or (serverÆs) public key is Provisioning Mode whenever a certificate or (serverÆs) public key is
available to authenticate the server, in order to ensure best available to authenticate the server, in order to ensure best
security practices. 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 +
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 serverÆs MSCHAPv2 challenge and the peerÆs
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 3.5 Provisioning or Refreshment of a PAC
The server may provision or refresh information by use of the The server may provision or refresh information by use of the
Protected Access Credential (PAC) after a successful user Protected Access Credential (PAC) after a successful user
authentication. A PAC TLV is defined to facilitate the distribution authentication. A PAC TLV is defined to facilitate the distribution
and refreshing of information and is defined in Section 4.1. A fresh and refreshing of information and is defined in Section 4.2. A fresh
PAC may be distributed after a successful Intermediate Result TLV and PAC may be distributed after a successful Intermediate Result TLV and
Crypto-Binding TLV exchange, if the server detects that the PAC is Crypto-Binding TLV exchange, if the server detects that the PAC is
expiring soon. A successful EAP-FAST inner method authentication, expiring soon. A successful EAP-FAST inner method authentication,
including a successful Crypto-Binding exchange must ensue before an including a successful Crypto-Binding exchange must ensue before an
EAP-FAST server can distribute a fresh PAC. A PAC TLV should not be EAP-FAST server can distribute a fresh PAC. A PAC TLV should not be
accepted if it is not TLS tunnel-encapsulated. accepted if it is not TLS tunnel-encapsulated.
N.B. In-band PAC refreshing is enforced by server policy. The N.B. In-band PAC refreshing is enforced by server policy. The
server, based on the PAC-Opaque information, may determine not to 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- refresh a peerÆs PAC through the PAC TLV mechanism even if the PAC-
skipping to change at page 13, line 28 skipping to change at page 13, line 33
information is not freely provisioned to or by adversaries. For information is not freely provisioned to or by adversaries. For
example, the EAP server MAY not need to authenticate the peer to example, the EAP server MAY not need to authenticate the peer to
provision the peer with trusted root certificates. However, the peer provision the peer with trusted root certificates. However, the peer
MUST authenticate the server before it can accept a trusted server MUST authenticate the server before it can accept a trusted server
root certificate. root certificate.
The server distributes all PAC information through the use of a PAC 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 TLV. Each type of PAC information is typed through a PAC Type and
PAC TLV Attribute defined in this section. PAC TLV Attribute defined in this section.
4.1 Provisioning PACs through PAC TLV 4.1 PAC Types
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
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 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
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 serverÆs
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 peerÆs 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.
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. 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 Additionally, the PAC-Type, PAC TLV MAY be used by the peer to
request provisioning for specific types of information. Conversely, request provisioning for specific types of information. Conversely,
the PAC TLV is used by the server to provision the requested the PAC TLV is used by the server to provision the requested
information to a peer. information to a peer.
The PAC TLV provides support for Protected Access Credential (PAC) The PAC TLV provides support for Protected Access Credential (PAC)
defined within [EAP-FAST]. A consistent PAC format will allow it to defined within [EAP-FAST]. A consistent PAC format will allow it to
be used by multiple applications beyond EAP-FAST. A general PAC TLV be used by multiple applications beyond EAP-FAST. A general PAC TLV
skipping to change at page 14, line 4 skipping to change at page 16, line 33
be used by multiple applications beyond EAP-FAST. A general PAC TLV be used by multiple applications beyond EAP-FAST. A general PAC TLV
format is defined as follows: format is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Attributes... | PAC Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M M
0 - Non-mandatory TLV 0 - Non-mandatory TLV
1 - Mandatory TLV 1 - Mandatory TLV
R R
Reserved, set to zero (0) Reserved, set to zero (0)
TLV Type TLV Type
11 11
Length Length
The length of the PAC Attributes field in octets.
The length of the PAC Attributes field in octets.
PAC Attributes PAC Attributes
A list of PAC attributes in the TLV format.
A list of PAC attributes in the TLV format. 4.2.1 Formats for PAC TLV Attributes
4.1.1 Formats for PAC TLV Attributes
A common encapsulating format is used to convey the different fields A common encapsulating format is used to convey the different fields
that comprise a PAC attribute. The common encapsulation is defined that comprise a PAC attribute. The common encapsulation is defined
as follows: as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 15 skipping to change at page 18, line 5
9 - PAC-Info 9 - PAC-Info
10 - PAC-Type 10 - PAC-Type
Length Length
The Length filed is two octets, which contains the length of The Length filed is two octets, which contains the length of
the Value field in octets. the Value field in octets.
Value Value
The value of the PAC Attribute. The value of the PAC Attribute.
4.1.2 PAC-Key 4.2.2 PAC-Key
The PAC-Key is distributed as an attribute of type PAC-Key (Type=1). 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 The key is a randomly generated octet string. The key is represented
as an octet string whose length is determined by the length field. as an octet string whose length is determined by the length field.
The generator of this key is the issuer of the credential, identified The generator of this key is the issuer of the credential, identified
by the A-ID. by the A-ID.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 44 skipping to change at page 18, line 34
1 - PAC-Key 1 - PAC-Key
Length Length
The Length filed is two octets. For this version of EAP-FAST, The Length filed is two octets. For this version of EAP-FAST,
PAC-Key is 32 octets. PAC-Key is 32 octets.
Key Key
The Key field contains the PAC-Key. The Key field contains the PAC-Key.
4.1.3 PAC-Opaque 4.2.3 PAC-Opaque
The PAC-Opaque contains data that is opaque to the recipient, the 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 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 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 a server MUST store that data, and present it back to the server as
is, in the ClientHello SessionTicket extension field [TICKET]. If a is, in the ClientHello SessionTicket extension field [TICKET]. If a
client has opaque data issued to it by multiple servers, then it MUST client has opaque data issued to it by multiple servers, then it MUST
store the data issued by each server separately. This requirement store the data issued by each server separately. This requirement
allows the client to maintain and use each opaque data as an allows the client to maintain and use each opaque data as an
independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque 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 identified by the A-ID. As there is a one to one correspondence
skipping to change at page 17, line 8 skipping to change at page 20, line 5
Value Value
The Value field contains the actual data for PAC-Opaque The Value field contains the actual data for PAC-Opaque
The PAC-Opaque field is also passed from the peer to the server The PAC-Opaque field is also passed from the peer to the server
during the EAP-FAST Authentication Phase 1 conversation to during the EAP-FAST Authentication Phase 1 conversation to
enable the server to validate and recreate the PAC-Key. When enable the server to validate and recreate the PAC-Key. When
it is passed from the peer, it is encapsulated as defined above it is passed from the peer, it is encapsulated as defined above
in the ClientHello SessionTicket Extension [TICKET]. in the ClientHello SessionTicket Extension [TICKET].
4.1.4 PAC-Info 4.2.4 PAC-Info
PAC-Info is comprised of a set of PAC attributes. At minimum, the 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. 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 Other optional fields may be included in the PAC to provide more
information to the peer. It is a container attribute for various information to the peer. It is a container attribute for various
types of information each of which is encoded in conformance to the types of information each of which is encoded in conformance to the
PAC TLV field format as defined in Section 4.1. PAC TLV field format as defined in Section 4.2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes... | Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
skipping to change at page 18, line 39 skipping to change at page 21, line 40
format. This TLV serves as an aid to the peer to better format. This TLV serves as an aid to the peer to better
inform the end-user about the A-ID. This field is a inform the end-user about the A-ID. This field is a
mandatory field in the PAC-Info. mandatory field in the PAC-Info.
PAC-Type (type 10) PAC-Type (type 10)
PAC-Type is a mandatory TLV intended to provide the type of 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. This field is a mandatory field in the PAC-Info. If
PAC-Type is not present, then it defaults to a Tunnel PAC PAC-Type is not present, then it defaults to a Tunnel PAC
(Type 1). (Type 1).
4.1.5 PAC-Acknowledgement TLV 4.2.5 PAC-Acknowledgement TLV
The PAC-Acknowledgement TLV is used to acknowledge the receipt of the 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 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 TLV to indicate the result of the retrieving and storing of the new
Tunnel PAC. This TLV is only used when provisioning Tunnel PAC. Tunnel PAC. This TLV is only used when provisioning Tunnel PAC.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
skipping to change at page 19, line 20 skipping to change at page 22, line 26
Length Length
The length of this field is two octets and value must be 2. The length of this field is two octets and value must be 2.
Result Result
The resulting value must be one of the following: The resulting value must be one of the following:
1 - Success 1 - Success
2 - Failure 2 - Failure
4.1.6 PAC-Type TLV 4.2.6 PAC-Type TLV
The PAC-Type TLV is a mandatory TLV intended to specify the PAC type. The PAC-Type TLV is a mandatory TLV intended to specify the PAC type.
Its format is described below. Its format is described below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Type | | PAC Type |
skipping to change at page 20, line 5 skipping to change at page 23, line 13
The length of this field is two octets and value must be 2. The length of this field is two octets and value must be 2.
PAC Type PAC Type
This two octet field defined the type of PAC being requested or This two octet field defined the type of PAC being requested or
provisioned. Its value must be one of the following: provisioned. Its value must be one of the following:
1 û Tunnel PAC 1 û Tunnel PAC
2 û Machine Authentication PAC 2 û Machine Authentication PAC
3 û User Authorization PAC 3 û User Authorization PAC
4.2 Server Trusted Root Certificate 4.3 Server Trusted Root Certificate
It is desirable to provision the peer with the serverÆs trusted root It is desirable to provision the peer with the serverÆs trusted root
certificates (or CA certificates), which can later be used for certificates (or CA certificates), which can later be used for
enabling PKI based cipher suites. Server-Trusted-Root TLV [EAP-FAST] enabling PKI based cipher suites. Server-Trusted-Root TLV [EAP-FAST]
is introduced to facilitate the request for and delivery of server is introduced to facilitate the request for and delivery of server
trusted root certificates. Within the EAP-FAST Phase 2 conversation, trusted root certificates. Within the EAP-FAST Phase 2 conversation,
a peer MAY request for a serverÆs trusted root certificate using a a peer MAY request for a serverÆs trusted root certificate using a
Server-Trusted-Root TLV, and the EAP server MAY respond with a Server-Trusted-Root TLV, and the EAP server MAY respond with a
Server-Trusted-Root TLV containing the trusted root certificate in Server-Trusted-Root TLV containing the trusted root certificate in
the PCKS#7 TLV [EAP-FAST] to the peer. The Server-Trusted-Root TLV the PCKS#7 TLV to the peer. The Server-Trusted-Root TLV can be
can be exchanged in regular EAP-FAST Authentication mode or exchanged in regular EAP-FAST Authentication mode or Provisioning
Provisioning modes. modes.
After the peer has determined that it has successfully authenticated After the peer has determined that it has successfully authenticated
the EAP server and determined that the tunnel and inner EAP methods the EAP server and determined that the tunnel and inner EAP methods
were between the same peer and EAP Server by validating the Crypto- were between the same peer and EAP Server by validating the Crypto-
Binding TLV, it MAY send one or more Server-Trusted-Root TLVs Binding TLV, it MAY send one or more Server-Trusted-Root TLVs
(marked as optional) to request for the certificate trust anchors of (marked as optional) to request for the certificate trust anchors of
the server certificate from the EAP server. The EAP server will send the server certificate from the EAP server. The EAP server will send
the trusted root(s) of server certificate after its internal policy the trusted root(s) of server certificate after its internal policy
has been satisfied; or it may ignore the request or request has been satisfied; or it may ignore the request or request
additional authentications based on its policy. The peer may receive additional authentications based on its policy. The peer may receive
a trusted root of server certificate, but is not required to use it. 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 Please see Section 10.4 for an example of a server provisioning a
server trusted root certificate. server trusted root certificate.
4.3 PAC Types 4.3.1 Server-Trusted-Root TLV
A Protected Access Credential (PAC) is a security credential provided The Server-Trusted-Root TLV allows the peer to send a request to the
by the Authentication Server (AS) that holds application specific EAP server for a trusted root in PKCS#7 format.
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 The Server-Trusted-Root TLV is always marked as optional, and cannot
establishing the EAP-FAST tunnel in Phase 1 is referred to as the be responded to with a NAK TLV.
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 The Server-Trusted-Root TLV can only be sent as an inner TLV (inside
AS used to establish a secure the EAP-FAST tunnel and convey the protection of the tunnel).
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 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 The peer MUST NOT request, or accept the trusted root sent inside the
authorization information that is bound to a specific user or Server-Root credential TLV by EAP-server until it has completed
device identity. They are intended to be short-lived, with an authentication of EAP server, and validated the Crypto-Binding TLV.
expiry time usually in the range of normal session resume The peer may receive a trusted root, but is not required to use the
timeouts (i.e., minutes or hours, versus days or months). Since trusted root received from the EAP server.
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 If the EAP server sets credential-format to PKCS#7-Server-
authorization result based on a previous authentication. It Certificate-Root, then the Server-Trusted-Root TLV MUST contain the
can be used in combination with the Tunnel PAC to bypass root of the certificate chain of the certificate issued to the EAP
subsequent user authentication(s). It is intended to be short- server packages in a PKCS#7 TLV. If the Server certificate is a
lived and also controlled by the peer. If any state of the self-signed certificate, then the root is the self-signed
user has changed to the extent that will affect the user certificate. In this case, the EAP server does not have to sign the
authentication result (i.e., user has logged on/off), the peer certificate inside the PCKS#7 TLV since it does not necessarily have
MUST discard it and not use it again. The User Authorization to private key for it.
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 If the Server-Trusted-Root TLV credential format does not contain one
long lived PACs are each issued a key that can be used to prove of the known values, then the EAP-server MUST ignore the value.
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
authenticate each other. One application of this type of PAC is
defined in this specification:
Machine Authentication PAC û A distributed device The Server-Trusted-Root TLV is defined as follows:
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 serverÆs
policy.
To request provisioning of a Tunnel PAC, a peer MUST send a PAC TLV 0 1 2 3
with a PAC-Type PAC TLV with its TLVs field and set to ô1ö (Tunnel 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
PAC Type). The request may be issued after the peer has determined +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
that it has successfully authenticated the EAP Server and the tunnel |M|R| TLV Type | Length |
and inner EAP methods were between the same peer and EAP Server by +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
validating the Crypto-Binding TLV. This would differentiate the | Credential-Format | TLVs...
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 M
MUST send a PAC TLV with a PAC-Type PAC TLV in its TLVs field and set 0 - Optional TLV
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 peerÆs 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 R
receipt of other types of PACs. Reserved, set to zero (0)
Please see Section 10.5 for an example of packet exchanges to TLV Type
provision a User Authorization PAC. 18
Length
>=2
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)
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 5. Security Considerations
The Dynamic Provisioning EAP-FAST protocol shares the same security The Dynamic Provisioning EAP-FAST protocol shares the same security
considerations outlined in [EAP-FAST]. Additionally, it also has its considerations outlined in [EAP-FAST]. Additionally, it also has its
unique security considerations described below: unique security considerations described below:
5.1 User Identity Protection and Validation 5.1 User Identity Protection and Validation
EAP-FAST for provisioning employs the DH key agreement (as defined in EAP-FAST for provisioning employs the DH key agreement (as defined in
skipping to change at page 24, line 50 skipping to change at page 28, line 33
dictionary attack. Further, it is the only option that enables zero dictionary attack. Further, it is the only option that enables zero
out-of-band provisioning and facilitates simpler deployments out-of-band provisioning and facilitates simpler deployments
requiring little to no peer configuration. requiring little to no peer configuration.
5.3 Mitigation of Man-in-the-middle (MitM) attacks 5.3 Mitigation of Man-in-the-middle (MitM) attacks
EAP-FAST invocation of provisioning addresses MitM attacks in the EAP-FAST invocation of provisioning addresses MitM attacks in the
following way: following way:
* Generating MSCHAPv2 server and client challenges as a function * Generating MSCHAPv2 server and client challenges as a function
of the DH key agreement: in enforcing the dependence of the of the DH key agreement: in enforcing the dependence of the MSCHAP
MSCHAP challenges on the DH exchange, a MitM is prevented from challenges on the DH exchange, a MitM is prevented from
successfully establishing a secure tunnel with both the peer and successfully establishing a secure tunnel with both the peer and
legitimate server and succeed in obtaining the PAC credential. legitimate server and succeed in obtaining the PAC credential.
* Cryptographic binding of EAP-FAST Phase 1 and the Phase 2 * Cryptographic binding of EAP-FAST Phase 1 and the Phase 2
authentication method: by cryptographically binding key authentication method: by cryptographically binding key material
material generated in all methods, both peer and AS are assured generated in all methods, both peer and AS are assured that they
that they were the sole participants of all transpired methods. were the sole participants of all transpired methods.
The binding of the MSCHAPv2 random challenge derivations to the DH The binding of the MSCHAPv2 random challenge derivations to the DH
key agreement protocol enables early detection of a MitM attack. key agreement protocol enables early detection of a MitM attack.
This is required to guard from adversaries who may otherwise reflect This is required to guard from adversaries who may otherwise reflect
the inner EAP authentication messages between the true peer and AS the inner EAP authentication messages between the true peer and AS
and enforces that the adversary successfully respond with a valid and enforces that the adversary successfully respond with a valid
challenge response. challenge response.
The cryptographic binding is another reassurance that indeed the true The cryptographic binding is another reassurance that indeed the true
peer and AS were the two parties ensuing both the tunnel peer and AS were the two parties ensuing both the tunnel
skipping to change at page 26, line 36 skipping to change at page 30, line 27
Furthermore, as the server defines the group used for the DH exchange, Furthermore, as the server defines the group used for the DH exchange,
it may restrict the prime size to be 1024 bits. it may restrict the prime size to be 1024 bits.
Additionally, since the EAP-FAST provisioning exchange employs DH per Additionally, since the EAP-FAST provisioning exchange employs DH per
[RFC 3268] to generate AES keys, the DH keys must provide enough [RFC 3268] to generate AES keys, the DH keys must provide enough
entropy to ensure that a strong 128bit results from the DH key entropy to ensure that a strong 128bit results from the DH key
agreement. agreement.
EAP-FAST employs the 2048 bit DH groups defined in [RFC 3526]. 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:
* 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 6. IANA Considerations
PAC TLV attribute value and PAC-Type value should be assigned by This section explains the criteria to be used by the IANA for
IANA. assignment of PAC TLV attribute and PAC-Type values. The
"Specification Required" policy is used here with the meaning defined
in BCP 26 [RFC2434].
7. References 7. References
7.1 Normative 7.1 Normative
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[EAP] Blunk, L., et. al., "Extensible Authentication Protocol [EAP] Blunk, L., et. al., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004. (EAP)", RFC 3748, June 2004.
skipping to change at page 27, line 20 skipping to change at page 32, line 29
3268, June 2002. 3268, June 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC3546] Blake-Wilson, S., et al., "Transport Layer Security (TLS) [RFC3546] Blake-Wilson, S., et al., "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003. Extensions", RFC 3546, June 2003.
[EAP-FAST] Cam-Winget, N., et al., "EAP Flexible Authentication via [EAP-FAST] Cam-Winget, N., et al., "EAP Flexible Authentication via
Secure Tunneling (EAP-FAST) ", draft-cam-winget-eap-fast- Secure Tunneling (EAP-FAST) ", draft-cam-winget-eap-fast-
02 (work in progress), April 2005 02 (work in progress), April 2005.
[TICKET] Salowey, J., et al, "TLS Session Resumption without [TICKET] Salowey, J., et al, "TLS Session Resumption without
Server-Side State", draft-salowey-tls-ticket-02.txt, Server-Side State", draft-salowey-tls-ticket-02.txt,
February 2005 February 2005
[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 7.2 Informative
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October IANA Considerations Section in RFCs", RFC 2434, October
1998. 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, January 1999. 2631, January 1999.
[RFC2716] Aboba, B. and Simon, D, "PPP EAP TLS Authentication [RFC3526] Kivinen, T., "More Modular Exponential (MODP) Diffie-
Protocol", RFC 2716, October 1999.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), September
2004.
[PEAP] Palekar, et. al., "Protected EAP Protocol (PEAP) Version
2", draft-josefsson-pppext-eap-tls-eap-10 (work in
progress), October 2004
[RFC3526] Kivinen, T., "More Modular Exponential (MODP) DIffie-
Hellman groups for Internet Key Exchange (IKE)", RFC Hellman groups for Internet Key Exchange (IKE)", RFC
3526, May 2003 3526, May 2003
[MITM] [MITM]
Puthenkulam, J., "The Compound Authentication Binding Puthenkulam, J., "The Compound Authentication Binding
Problem", draft-puthenkulam-eap-binding-04 (expired), Problem", draft-puthenkulam-eap-binding-04 (expired),
October 2003. October 2003.
[RFC2486BIS]Aboba, et. al., "The Network Access Identifier", draft- [RFC2486BIS]Aboba, et. al., "The Network Access Identifier", draft-
ietf-radext-rfc2486bis-06.txt (work in progress), ietf-radext-rfc2486bis-06.txt (work in progress),
February, 2005. February, 2005.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[EAP-TTLS] Funk & Blake-Wilson, "EAP Tunneled TLS Authentication
Protocol", draft-funk-eap-ttls-v0-00.txt (work in
progress), February 2005
[TLS-PSK] Eronen, P. and Tschofenig, H., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", draft-
ietf-tls-psk-09, June 2005
8. Acknowledgments 8. Acknowledgments
The EAP-FAST design and protocol specification is based on the ideas The EAP-FAST design and protocol specification is based on the ideas
and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith, and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith,
Ilan Frenkel and Jeremy Steiglitz of Cisco Systems, Inc. Ilan Frenkel and Jeremy Steiglitz of Cisco Systems, Inc.
9. Author's Addresses 9. Author's Addresses
Nancy Cam-Winget Nancy Cam-Winget
Cisco Systems Cisco Systems
skipping to change at page 38, line 24 skipping to change at page 44, line 16
13. Copyright Statement 13. Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
14. Expiration Date 14. Expiration Date
This memo is filed as <draft-cam-winget-eap-fast-provisioning- This memo is filed as <draft-cam-winget-eap-fast-provisioning-
00.txt>, and expires January 11, 2006. 00.txt>, and expires January 17, 2006.
 End of changes. 63 change blocks. 
364 lines changed or deleted 449 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/