Network Working Group N. Cam-Winget Internet Draft D. McGrew Category: Informational J. Salowey Expires: January 11, 2006 H. Zhou Cisco Sytems July 11, 2005 Dynamic Provisioning using EAP-FAST draft-cam-winget-eap-fast-provisioning-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract EAP-FAST is an extensible EAP method that enables secure communication between a client and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 1] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 information thru this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. Table of Contents 1. Introduction...................................................3 1.1. Specification Requirements.............................3 1.2. Terminology............................................3 2. EAP-FAST Provisioning Modes....................................5 3. Dynamic Provisioning using EAP-FAST Conversation...............6 3.1 Network Access after EAP-FAST Provisioning.................8 3.2 Key Derivations Used in the EAP-FAST Provisioning Exchange.9 3.3 Authenticating Using PeerÆs ..........10 3.4 Use of other Inner EAP Methods for EAP-FAST Provisioning..11 3.5 Provisioning or Refreshment of a PAC......................12 4. Types of Information Provisioned in EAP-FAST..................13 4.1 Provisioning through PAC TLV..............................13 4.1.1 Formats for PAC TLV Attributes .....................14 4.1.2 PAC-Key ............................................15 4.1.3 PAC-Opaque .........................................15 4.1.4 PAC-Info............................................17 4.1.5 PAC-Acknowledgement TLV ............................18 4.1.6 PAC-Type TLV........................................19 4.1.7 Server Trusted Root Certificate ....................20 4.2 PAC Types.................................................20 5. Security Considerations.......................................22 5.1 User Identity Protection and Validation...................23 5.2 Mitigation of Dictionary Attacks..........................23 5.3 Mitigation of Man-in-the-middle (MitM) attacks............24 5.4 PAC Validation and User Credentials.......................25 5.5 Generation of Diffie-Hellman Groups.......................26 6. IANA Considerations...........................................26 7. References....................................................26 7.1 Normative.................................................26 7.2 Informative...............................................27 8. Acknowledgments...............................................28 9. Author's Addresses............................................28 10. Appendix: Examples...........................................29 10.1 Example 1: Successful Provisioning.......................29 10.2 Example 2: Successful Provisioning with Password Change..31 10.3 Example 3: Failed Provisioning...........................32 10.4 Example 4: Provisioning a Authentication ServerÆs Trusted Root Certificate..............................................34 10.5 Example 5: Provisioning a User Authorization PAC.........36 11. Intellectual Property Statement..............................37 12. Disclaimer of Validity.......................................38 13. Copyright Statement..........................................38 14. Expiration Date..............................................38 Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 2] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 1. Introduction [EAP-FAST] is an extensible EAP method that can be used to mutually authenticate peer and server. However, to mutually authenticate with EAP-FAST, credentials such as a preshared key, trusted anchor or a Tunnel PAC MUST be provisioned to the peer before it can establish a secure association with the server. In some cases, the provisioning of such information present deployment hurdles. Through the use of the protected tunnel, EAP-FAST can also be used to enable the means for dynamic or in-band provisioning to address such deployment obstacles. 1.1. Specification Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology Some of the following terms are taken from EAP [RFC3748]: 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 Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 3] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 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) 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. 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 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 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. Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 4] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 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 EAP-FAST supports two modes for provisioning: 1) Server-Authenticated Mode: Provisioning inside a server authenticated (TLS) tunnel. 2) Server-Unauthenticated Mode: Provisioning inside an unauthenticated (TLS) tunnel In the Server-Authenticated Provisioning mode, the peer has successfully authenticated the EAP server as part of the TLS handshake of EAP-FAST Phase 1 (e.g. tunnel establishment). Additional exchanges MAY be needed inside the tunnel for the EAP Server to authenticate the peer before any information can be provisioned. In the Server-Unauthenticated Provisioning mode, an unauthenticated tunnel is established in the EAP-FAST Phase 1. This provisioning mode is defined to enable bootstrapping or initial configuration of peers where the peer lacks strong credentials (if any) to mutually authenticate with the server and configuration through out-of-band mechanisms are prohibitive. In the Server-Unauthenticated Provisioning mode, the peer and server do not achieve mutual authentication during EAP-FAST Phase 1. It is expected that the peer negotiates TLS_DH_anon_WITH_AES_128_CBC_SHA to signal that it can not provide proof of authenticity. While other cipher suites such as those requiring the use of server certificates may be used, the peer may lack the necessary trust anchors to validate the certificate and authenticate the server. Since the tunnel is not authenticated in the Server-Unauthenticated Provisioning mode, it is possible that the TLS channel may be terminated by an attacker. It is strongly recommended that an inner EAP method be used to provide some authenticity assurances and MitM detection and warning outlined in Section 5 MUST be applied. Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 5] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 The EAP-FAST Phase 2 conversation is unchanged in either Provisioning mode, except that the peer MUST accept an EAP method supporting mutual authentication and key derivation that is compatible with its initial or bootstrapping credentials (such as a password-based EAP method). The peer then uses the Crypto-Binding TLV to validate that the same server terminates both the TLS channel and to successfully complete the EAP method, thereby verifying that the exchange was not subject to a man-in-the-middle attack. Assuming that the Crypto- Binding TLV exchange is successful, the server will subsequently provide the information such as a shared key or the trusted root(s) of server certificate using a PAC TLV. Once the EAP-FAST Provisioning conversation completes, the peer is expected to use the provisioned credentials in subsequent EAP-FAST authentications. It is strongly recommended that Server- Unauthenticated Provisioning mode SHOULD NOT be used more than once. 3. Dynamic Provisioning using EAP-FAST Conversation The provisioning EAP-FAST exchange uses same sequence as the EAP-FAST Authentication Phase 1 to establish a protected tunnel by means of a Diffie-Hellman (DH) key agreement exchange. Once a tunnel is secured between the two parties, the client and server can then execute an EAP authentication method by which both parties can achieve mutual authentication. Provisioning in EAP-FAST is negotiated solely by the client as the first communication exchange when EAP-FAST is requested from the server. If the client does not have a Protected Access Credential (PAC) or requires provisioning of other information (such as the serverÆs Trusted Root certificate), it can request to initiate a provisioning EAP-FAST exchange and dynamically obtain one from the server. An EAP-FAST server distinguishes an EAP-FAST Provisioning 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 peer and an authentication server; more specifically, the server that can provision the peer with the requested information; typically, a unique PAC. With the EAP-FAST provisioning protocol, the EAP identity may be anonymous to further protect the clientÆs identity. The conversation between a peer and authentication server commences as a normal EAP-FAST exchange: with an anonymous Identity for a peer Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 6] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 and the server determining that EAP-FAST authentication is to occur, the EAP server MUST respond with an EAP-FAST/Start packet. Assuming that the peer supports EAP-FAST and the peer has no PAC provisioned on its device, the peer shall send an EAP-Response packet with EAP- Type=EAP-FAST. On receipt of the EAP-FAST Start message, the peer determines it must be provisioned with a fresh PAC. Further, the peer determines whether it must invoke a signed or anonymous DH exchange depending on whether it has the serverÆs public key or trust anchor. When an anonymous key exchange is negotiated, the signature in the KeyExchange algorithm shall contain the sha_hash of the records as 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 signed key exchange the server may also include a certificate to enable the peer to validate the signature. To provide best security practices, it is highly recommended that the peer obtain the serverÆs public key or trust anchor to enable server- side authentication by employing a signed Diffie-Hellman exchange (e.g. TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite specification). However, as the provisioning of the public key or trust anchor must also be secured to ensure the public key is to be trusted, some deployments may be willing to trade off the security risks for ease of deployment. The peer and server establish the EAP-FAST tunnel for provisioning in the same exchanges as that defined for EAP-FAST authentication [EAP- FAST]. With a successful EAP-FAST Phase 1 tunnel established, subsequent messages exchanged between peer and authentication server are protected using 128bit AES in CBC mode and HMAC-SHA1 as defined by both [RFC 2246] and [RFC 3268] to provide message confidentiality and integrity respectively. With a protected tunnel, the peer must now authenticate itself to the server before the server can provision it with a PAC. To ensure some means for authentication and to protect such authentication from exposure, the provisioning EAP-FAST exchange also employs EAP- MSCHAPv2 to achieve mutual authentication before any credentials or information can be provisioned. If an anonymous DH exchange ensued to establish the tunnel, the MSCHAPv2 exchange is susceptible to an active server-side dictionary attack. However, as it enables in-band provisioning at the cost of some loss in security strength, it is an option to afford a means for facilitating a deployment with minimal to no client (peer) configuration. It is recommended that when using the provisioning EAP-FAST exchange with anonymous DH, it be used no more than once by a client to provision itself with a PAC; further Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 7] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 provisioning or updates of the PAC should be done by means of the EAP-FAST PAC refreshing protocol or through some other (manual or out-of-band) mechanisms. Finally, it is also recommended that when 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 server engaging in an MSCHAPv2 conversation using invoking the same EAP-FAST Phase 2 MSCHAPv2 conversation. To further mitigate man-in- the-middle attacks, the challenges provided by the peer and authentication server are generated as part of the TLS establishment in the EAP-FAST provisioning exchange and conveyed as the Server and Client Challenges requested by MSCHAPv2. Further, the random challenges are not conveyed in the actual MSCHAPv2 messages, the messages shall replace the fields with zeroes to obscure the actual values used to generate the challenge responses. Following a successful MSCHAPv2 authentication exchange and successful Intermediate Result TLV and Crypto-Binding TLV exchange, the server can then provision the peer with a unique PAC. The provisioning is invoked through the same mechanism as in PAC refreshment: a PAC-TLV exchange is executed following the successful MSCHAPv2 exchange including the Intermediate Result TLV and Crypto- Binding TLV exchange, with the server distributing the PAC in a corresponding PAC TLV to the peer and the peer confirming its receipt in a final PAC TLV Acknowledgement message. 3.1 Network Access after EAP-FAST Provisioning Depending on server policy, network access can be granted or denied based on the EAP-FAST Provisioning mode, the credential(s) or other information that have been provisioned, and the inner EAP methods used. For example, in the Server-Authenticated Provisioning Mode, access can be granted after the EAP server has authenticated the peer and provisioned the peer with a Tunnel PAC (e.g. a PAC used to mutually authenticate the EAP-FAST tunnel). In the case where a peer lacks the trust anchors to validate the serverÆs certificate, the peer may choose proceed with the tunnel establishment by not authenticating the server. In the case where the server presents certificate(s) during the tunnel establishment, the server can not determine whether the peer actually validated the certificate and thus can not distinguish whether it has used the Server-Authenticated Provisioning mode or the Server-Unauthenticated Provisioning mode. Nonetheless, based on server policy, it may grant network access after it has succeeded authenticating the peer. In this instance, the peer may also have policy instilled by peer policy Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 8] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 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 access SHOULD NOT be granted. EAP server SHOULD conclude with an EAP Failure to acknowledge that this conversation was intended for provisioning only and thus no network access is authorized. Upon completion of the exchange, the EAP Server SHALL NOT grant network access or distribute any session keys to the NAS as this phase is not intended to provide network access. Even though provisioning mode completes with a successful inner termination (e.g. successful Result TLV), server policy defines whether the peer gains network access or not. Thus, it is feasible for the server, while providing a successful Result TLV may conclude with an EAP Failure. The EAP-FAST server, when denying network access after EAP-FAST Provisioning, may choose to instead, immediately invoke another EAP- FAST Start and thus initiate the EAP-FAST Phase 1 conversation. This server based implementation policy may be chosen to avoid applications such as wireless devices from being disrupted (e.g. in 802.11 devices, an EAP Failure may trigger a full 802.11 disassociation) and allow them to smoothly transit to the subsequent EAP-FAST authentications to enable network access. Similarly, if Server-Authenticated Provisioning Mode is used and the server policy is to disallow network access, the EAP Server SHALL NOT grant network access or distribute any session keys to the NAS as this phase is not intended to provide network access. Even though provisioning mode completes with a successful inner termination (e.g. successful Result TLV), the EAP-FAST Server-Authenticated Provisioning Mode MUST conclude with an EAP Failure to acknowledge that this conversation was intended for provisioning only and thus no network access is authorized. The EAP-FAST server may choose to instead, immediately invoke another EAP-FAST Start and thus initiate 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 Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 9] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 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 While other authentication methods exist to achieve mutual authentication, EAP-MSCHAPv2 was chosen for several reasons: * Afford the ability of slowing an active attack by obscuring the password through some hash Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 10] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 * Especially in the Server-Unauthenticated EAP-FAST Provisioning conversation MSCHAPv2 affords the ability to detect, based on the challenge responses, whether there is a possible attack. * It is understood that a large deployed base is already able to support MSCHAPv2 * MSCHAPv2 is picked in order to slow the active dictionary attack relative to MSCHAPv1. * Allow support for password change during the EAP-FAST Provisioning protocol. The MSCHAPv2 exchange forces the server to provide a valid ServerChallengeResponse which must be a function of the server challenge, client challenge and password as part of its response. This reduces the window of vulnerability in the EAP-FAST for in-band provisioning protocol to force the man-in-the-middle, acting as the server, to successfully break the password within the clientÆs challenge response time limit. Currently, EAP-FAST for provisioning only specifies MSCHAPV2 as the inner method. However, with support of signed DH key agreement, the provisioning protocol of EAP-FAST may support other methods such as EAP-GTC to enable peers (using other password databases such as LDAP and OTP) to be provisioned in-band as well. However, the replacement may only be achieved when used with the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite to ensure no loss in security. 3.4 Use of other Inner EAP Methods for EAP-FAST Provisioning Once a protected tunnel is established, the peer must authenticate itself to the server before the server can provision the peer. When using TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite in the EAP-FAST Phase 1 conversation, EAP-MSCHAPv2 is the only inner method allowed for Dynamic Provisioning in EAP-FAST. The MSCHAPv2 exchange forces the server to provide a valid ServerChallengeResponse which must be a function of the server challenge, client challenge and password as part of its response. This reduces the window of vulnerability in this provisioning mode to force the man-in-the-middle, acting as the server, to successfully break the password within the clientÆs challenge response time limit, or it raises the ability to detect if an MitM attacker is capturing the MSCHAPv2 exchange without responding for the purpose of affecting an off-line dictionary attack on the password. Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 11] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 As a result of not authenticating the server in Phase 1 and potential MITM attacks in the Server-Unauthenticated Provisioning Mode, an EAP method with equal or better protection than EAP-MSCHAPv2 MUST be used in Phase 2. With the use of additional TLS cipher suites, especially when serverauthenticity is verified as part of the TLS tunnel establishment, other inner EAP methods with weaker protection than EAP-MSCHAPv2 can be used safely inside tunnel. Hence, in addition to EAP-MSCHAPV2 as the inner method, EAP-GTC MAY be used in Server- Authenticated Provisioning Mode. This will enable peers using other user databases such as LDAP and OTP to be provisioned in-band as well. However, the replacement may only be achieved when used with the TLS cipher suites that ensure server authentication, such as TLS_DHE_RSA_WITH_AES_128_CBC_SHA, to ensure no loss in security. Dynamic Provisioning EAP-FAST MUST support both EAP-GTC and EAP-MS- CHAPv2 within the tunnel in Server-Authenticated Provisioning Mode. It should be noted that Server-Authenticated Provisioning Mode provides significant security advantages over Server-Unauthenticated Provisioning even when EAP-MSCHAPv2 is being used as inner method. It protects the EAP-MSCHAPv2 exchanges from potential MitM attacks by verifying 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 a certificate or (serverÆs) public key is available to authenticate the server, in order to ensure best security practices. 3.5 Provisioning or Refreshment of a PAC The server may provision or refresh information by use of the Protected Access Credential (PAC) after a successful user authentication. A PAC TLV is defined to facilitate the distribution and refreshing of information and is defined in Section 4.1. A fresh PAC may be distributed after a successful Intermediate Result TLV and Crypto-Binding TLV exchange, if the server detects that the PAC is expiring soon. A successful EAP-FAST inner method authentication, including a successful Crypto-Binding exchange must ensue before an EAP-FAST server can distribute a fresh PAC. A PAC TLV should not be accepted if it is not TLS tunnel-encapsulated. N.B. In-band PAC refreshing is enforced by server policy. The server, based on the PAC-Opaque information, may determine not to refresh a peerÆs PAC through the PAC TLV mechanism even if the PAC- Key has expired. Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 12] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 4. Types of Information Provisioned in EAP-FAST In addition to the Tunnel PAC (the one used to establish the EAP-FAST Phase 1 tunnel), other types of credentials and information can also be provisioned. They may include trusted root certificates for the server certificates, application specific PACs, and user identities to name a few. Typically, provisioning is invoked after both peer and server validate their authenticities and after a successful Crypto- Binding TLV exchange. However, depending on the information being provisioned, mutual authentication MAY not be needed. At minimum, at least one entity (peer or server) must prove authenticity before credentials are provisioned to ensure that information is not freely provisioned to or by adversaries. For example, the EAP server MAY not need to authenticate the peer to provision the peer with trusted root certificates. However, the peer MUST authenticate the server before it can accept a trusted server root certificate. The server distributes all PAC information through the use of a PAC TLV. Each type of PAC information is typed through a PAC Type and PAC TLV Attribute defined in this section. 4.1 Provisioning PACs through PAC TLV The PAC TLV is defined to enable the provisioning of PAC information. Additionally, the PAC-Type, PAC TLV MAY be used by the peer to request provisioning for specific types of information. Conversely, the PAC TLV is used by the server to provision the requested information to a peer. The PAC TLV provides support for Protected Access Credential (PAC) defined within [EAP-FAST]. A consistent PAC format will allow it to be used by multiple applications beyond EAP-FAST. A general PAC TLV format is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAC Attributes... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 13] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 M 0 - Non-mandatory TLV 1 - Mandatory TLV R Reserved, set to zero (0) TLV Type 11 Length The length of the PAC Attributes field in octets. PAC Attributes A list of PAC attributes in the TLV format. 4.1.1 Formats for PAC TLV Attributes A common encapsulating format is used to convey the different fields that comprise a PAC attribute. The common encapsulation is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The type field is two octets, denoting the attribute type. Allocated Types include: 1 - PAC-Key 2 - PAC-Opaque 3 - CRED_LIFETIME 4 - A-ID 5 - I-ID 6 - SERVER_PROTECTED_DATA 7 - A-ID-Info Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 14] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 8 - PAC-Acknowledgement 9 - PAC-Info 10 - PAC-Type Length The Length filed is two octets, which contains the length of the Value field in octets. Value The value of the PAC Attribute. 4.1.2 PAC-Key The PAC-Key is distributed as an attribute of type PAC-Key (Type=1). The key is a randomly generated octet string. The key is represented as an octet string whose length is determined by the length field. The generator of this key is the issuer of the credential, identified by the A-ID. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Key ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 - PAC-Key Length The Length filed is two octets. For this version of EAP-FAST, PAC-Key is 32 octets. Key The Key field contains the PAC-Key. 4.1.3 PAC-Opaque Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 15] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 The PAC-Opaque contains data that is opaque to the recipient, the peer is not the intended consumer of PAC-Opaque and thus should not attempt to interpret it. A peer that has been issued a PAC-Opaque by a server MUST store that data, and present it back to the server as is, in the ClientHello SessionTicket extension field [TICKET]. If a client has opaque data issued to it by multiple servers, then it MUST store the data issued by each server separately. This requirement allows the client to maintain and use each opaque data as an independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque identified by the A-ID. As there is a one to one correspondence between PAC-Key and PAC-Opaque, the peer must determine the PAC-Key and corresponding PAC-Opaque based on the A-ID provided in the EAP- FAST/Start message and the A-ID provided in the PAC-Info when it was provisioned with a PAC-Opaque. As the PAC-Opaque is server specific, its contents and definition are specific to the issuer of the PAC, e.g. the PAC server. The PAC-Opaque field is embedded as part of the PAC TLV when the server has determined that the PAC must be refreshed and sends a new PAC. The PAC-Opaque field format is summarized as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 - PAC-Opaque Length The Length filed is two octets, which contains the length of the value field in octets. Value The Value field contains the actual data for PAC-Opaque The PAC-Opaque field is also passed from the peer to the server during the EAP-FAST Authentication Phase 1 conversation to Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 16] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 enable the server to validate and recreate the PAC-Key. When it is passed from the peer, it is encapsulated as defined above in the ClientHello SessionTicket Extension [TICKET]. 4.1.4 PAC-Info PAC-Info is comprised of a set of PAC attributes. At minimum, the A-ID TLV is required to convey the issuing identity to the peer. Other optional fields may be included in the PAC to provide more information to the peer. It is a container attribute for various types of information each of which is encoded in conformance to the PAC TLV field format as defined in Section 4.1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 9 - PAC-Info Length The Length filed is two octets, which contains the length of the Attributes field in octets. Attributes The Attributes field contains a list of PAC Attributes. Each mandatory and optional field type is defined as follows: CRED_LIFETIME (type 3) This is a 4 octet quantity representing the expiration time of the credential in UNIX UTC time. This is a mandatory field contained in the PAC-Opaque field to enable the server to validate the PAC. This field may also be optionally provided to the peer as part of PAC-Info. A- ID (type 4) Authority identifier is the name of the authority that issued the token. The A-ID is intended to be unique across all issuing servers to avoid namespace collisions. Server implementations should use measures to ensure the A-ID used is globally unique to avoid name collisions. The A-ID is Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 17] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 used by the peer to determine which PAC to employ. Similarly, the server uses the A-ID to both authenticate the PAC-Opaque and determine which master key was used to issue the PAC. This field is mandatory and included in both the PAC-Opaque and as the first TLV comprising PAC-Info. I-ID (type 5) Initiator identifier (I-ID) is the peer identity associated with the credential. The server employs the I-ID in the EAP- FAST Phase 2 conversation to validate that the same peer identity used to execute EAP-FAST Phase 1 is also used in at minimum one inner EAP method in EAP-FAST Phase 2. This field is a mandatory field in PAC-Opaque and may optionally be included in the PAC-Info. If the AS is enforcing the I-ID validation on inner EAP method, then I-ID is mandatory in PAC-Info, to enable the client to also enforce a unique PAC for each unique user. If I-ID is missing from the PAC-Info, it is assumed that the Tunnel PAC can be used for multiple users and client will not enforce the unique Tunnel PAC per user policy. A-ID-Info (type 7) Authority Identifier Information is a mandatory TLV intended to provide a user-friendly name for the A-ID. It may contain the enterprise name and server name in a more human-readable format. This TLV serves as an aid to the peer to better inform the end-user about the A-ID. This field is a mandatory field in the PAC-Info. PAC-Type (type 10) PAC-Type is a mandatory TLV intended to provide the type of PAC. This field is a mandatory field in the PAC-Info. If PAC-Type is not present, then it defaults to a Tunnel PAC (Type 1). 4.1.5 PAC-Acknowledgement TLV The PAC-Acknowledgement TLV is used to acknowledge the receipt of the Tunnel PAC by the peer. Peer sends this TLV in response to the PAC TLV to indicate the result of the retrieving and storing of the new Tunnel PAC. This TLV is only used when provisioning Tunnel PAC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 18] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 | Result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 - PAC-Acknowledgement Length The length of this field is two octets and value must be 2. Result The resulting value must be one of the following: 1 - Success 2 - Failure 4.1.6 PAC-Type TLV The PAC-Type TLV is a mandatory TLV intended to specify the PAC type. Its format is described below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAC Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 10 - PAC-Type Length The length of this field is two octets and value must be 2. PAC Type This two octet field defined the type of PAC being requested or provisioned. Its value must be one of the following: 1 û Tunnel PAC 2 û Machine Authentication PAC 3 û User Authorization PAC Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 19] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 4.2 Server Trusted Root Certificate It is desirable to provision the peer with the serverÆs trusted root certificates (or CA certificates), which can later be used for enabling PKI based cipher suites. Server-Trusted-Root TLV [EAP-FAST] is introduced to facilitate the request for and delivery of server trusted root certificates. Within the EAP-FAST Phase 2 conversation, a peer MAY request for a serverÆs trusted root certificate using a Server-Trusted-Root TLV, and the EAP server MAY respond with a Server-Trusted-Root TLV containing the trusted root certificate in the PCKS#7 TLV [EAP-FAST] to the peer. The Server-Trusted-Root TLV can be exchanged in regular EAP-FAST Authentication mode or Provisioning modes. After the peer has determined that it has successfully authenticated the EAP server and determined that the tunnel and inner EAP methods were between the same peer and EAP Server by validating the Crypto- Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked as optional) to request for the certificate trust anchors of the server certificate from the EAP server. The EAP server will send the trusted root(s) of server certificate after its internal policy has been satisfied; or it may ignore the request or request additional authentications based on its policy. The peer may receive a trusted root of server certificate, but is not required to use it. Please see Section 10.4 for an example of a server provisioning a server trusted root certificate. 4.3 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 Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 20] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 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 Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 21] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 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. 5. Security Considerations The Dynamic Provisioning EAP-FAST protocol shares the same security considerations outlined in [EAP-FAST]. Additionally, it also has its unique security considerations described below: Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 22] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 5.1 User Identity Protection and Validation EAP-FAST for provisioning employs the DH key agreement (as defined in the TLS protocol) to establish a protected tunnel; the initial Identity request/response may be omitted as it must be transmitted in the clear and thus subject to snooping and forgery. Alternately, an anonymous identity may be used in the Identity response to prevent disclosure of the peerÆs true identity. As the provisioning EAP-FAST exchange is used for provisioning a PAC to a specific identity, e.g. I-ID, it is expected that the server will assign the I-ID based on the identity provided in the protected inner EAP authentication method. Thus, the protected identity may not be identical to the cleartext identity presented in the initial tunnel establishment messages. In order to shield the user identity from snooping, the cleartext Identity may only provide enough information to enable routing of the authentication request to the correct realm. For example, the peer may initially claim the identity of "nouser@bigco.com" in order to route the authentication request to the bigco.com EAP server. Subsequently, once the EAP-FAST session has been negotiated, in the inner authentication method, the peer may claim the identity of "fred@bigco.com". Thus, the EAP-FAST protocol for provisioning can provide protection for the user's identity, though not necessarily the destination realm, unless the provisioning EAP-FAST conversation terminates at the local authentication server. 5.2 Mitigation of Dictionary Attacks When EAP-FAST is invoked for provisioning, the peer specifies the means for securing the communications for the provisioning. As such, it can invoke the DH key agreement in one of two ways: anonymously or server-authenticated. With a server-authenticated DH key agreement, the server must provide its certificate and an RSA signature with the ephemeral DH parameters, whereas no signature is provided for an anonymous DH key agreement. In a server authenticated DH key agreement, the protected communications is assured that the AS is authentic as the peer must have been pre-provisioned with the ASÆs certificate or public (RSA) key prior to the negotiation. As it is the peer that must first provide proof of identity through an identity and (password) credential, an adversary may only pose as an AS to successfully mount a dictionary attack. An EAP-FAST compliant implementation must assure that provisioning of the AS public key, certificate or root certificate to the peer must be achieved through a secure mechanism. Only through a secure mechanism can server-authenticated DH key agreement provide resistance to dictionary attacks. While this Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 23] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 option affords best security practices, it presents deployment issues as, especially for wireless clients where there is little means to provide secure configuration, peers must be configured with a means to validate the 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 gain the 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. 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 the tunnel establishment. With MSCHAPv2, a peer may detect it is under attack when the AS that has provided an acceptable Authority ID (A-ID) fails to provide a successful MSCHAPv2 server challenge response. By employing the ServerChallenge and ClientChallenge derived during tunnel establishment; detection of a MitM is feasible during the MSCHAPv2 exchange. The peer may choose to use a more secure out-of-band mechanism for PAC provisioning that affords better security than the anonymous DH key agreement. Similarly, the peer may find a means of pre- provisioning the serverÆs public key securely to invoke the server- authenticated DH key agreement. The anonymous DH key agreement is presented as a viable option as there may be deployments that can physically confine devices during the provisioning or are willing to accept the risk of an active dictionary attack. Further, it is the only option that enables zero out-of-band provisioning and facilitates simpler deployments requiring little to no peer configuration. 5.3 Mitigation of Man-in-the-middle (MitM) attacks EAP-FAST invocation of provisioning addresses MitM attacks in the following way: * Generating MSCHAPv2 server and client challenges as a function of the DH key agreement: in enforcing the dependence of the Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 24] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 MSCHAP challenges on the DH exchange, a MitM is prevented from successfully establishing a secure tunnel with both the peer and legitimate server and succeed in obtaining the PAC credential. * Cryptographic binding of EAP-FAST Phase 1 and the Phase 2 authentication method: by cryptographically binding key material generated in all methods, both peer and AS are assured that they were the sole participants of all transpired methods. The binding of the MSCHAPv2 random challenge derivations to the DH key agreement protocol enables early detection of a MitM attack. This is required to guard from adversaries who may otherwise reflect the inner EAP authentication messages between the true peer and AS 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 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.4 PAC Validation and User Credentials In provisioning, the AS presents the peer with information such as a PAC-Key, PAC-Opaque and PAC-Info attributes. The peer must securely Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 25] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 cache the PAC-Key and the PAC-Opaque which is bound to the A-ID provided as a PAC-Info attribute. 5.5 Generation of Diffie-Hellman Groups The security of the DH key exchange is based on the difficulty of solving the Discrete Logarithm Problem (DLP). As algorithms and adversaries become more efficient in their abilities to precompute values for a given fixed group, it becomes more important for a server to generate new groups as a means to allay this threat. The server could, for instance, constantly compute new groups in the background. Such an example is cited in [SECSH-DH]. Thus, the server can maintain a list of safe primes and corresponding generators to choose from. A prime p is safe, if: p = 2q + 1 and q is prime New primes may be generated in the background. Initial implementations of the EAP-FAST provisioning exchange limit the generator to be 2 as it both improves the multiplication efficiency and still covers half of the space of possible residues. Furthermore, as the server defines the group used for the DH exchange, it may restrict the prime size to be 1024 bits. Additionally, since the EAP-FAST provisioning exchange employs DH per [RFC 3268] to generate AES keys, the DH keys must provide enough entropy to ensure that a strong 128bit results from the DH key agreement. EAP-FAST employs the 2048 bit DH groups defined in [RFC 3526]. 6. IANA Considerations PAC TLV attribute value and PAC-Type value should be assigned by IANA. 7. References 7.1 Normative [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 26] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 [EAP] Blunk, L., et. al., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", RFC 2119, March 1997. [RFC3546] Blake-Wilson, S., et al., "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [EAP-FAST] Cam-Winget, N., et al., "EAP Flexible Authentication via Secure Tunneling (EAP-FAST) ", draft-cam-winget-eap-fast- 02 (work in progress), April 2005 [TICKET] Salowey, J., et al, "TLS Session Resumption without Server-Side State", draft-salowey-tls-ticket-02.txt, February 2005 7.2 Informative [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 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 2631, January 1999. [RFC2716] Aboba, B. and Simon, D, "PPP EAP TLS Authentication 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 Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 27] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 [RFC3526] Kivinen, T., "More Modular Exponential (MODP) DIffie- Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003 [MITM] Puthenkulam, J., "The Compound Authentication Binding Problem", draft-puthenkulam-eap-binding-04 (expired), October 2003. [RFC2486BIS]Aboba, et. al., "The Network Access Identifier", draft- ietf-radext-rfc2486bis-06.txt (work in progress), 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 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 of Cisco Systems, Inc. 9. Author's Addresses Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US Phone: +1 408 853 0532 E-mail: ncamwing@cisco.com David McGrew Cisco Systems San Jose, CA 95134 US E-mail: mcgrew@cisco.com Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 28] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US Phone: +1 206 256 3380 E-mail: jsalowey@cisco.com Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US Phone : +1 330 523 2132 E-mail: hzhou@cisco.com 10. Appendix: Examples 10.1 Example 1: Successful Tunnel PAC Provisioning The following exchanges show anonymous DH with a successful EAP- MSCHAPv2 exchange within Phase 2 to provision a Tunnel PAC, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID1) -> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (EAP-FAST Start, S bit set, A-ID) EAP-Response/ EAP-Type=EAP-FAST, V=1 (TLS client_hello without PAC-Opaque extension)-> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS server_hello, TLS Server Key Exchange TLS Server Hello Done) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (TLS Client Key Exchange TLS change_cipher_spec, TLS finished) Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 29] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS change_cipher_spec TLS finished) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (Acknowledgement) TLS channel established (messages sent within the TLS channel) <- EAP Payload TLV, EAP-Request/ EAP Identity Request EAP Payload TLV, EAP-Response/ EAP Identity Response -> <- EAP Payload TLV, EAP-Request, EAP-MSCHAPV2, Challenge EAP Payload TLV, EAP-Response, EAP-MSCHAPV2, Response) -> <- EAP Payload TLV, EAP-Request, MSCHAPV2, Success) EAP Payload TLV, EAP-Response, MSCHAPV2, Success) -> <- Intermediate Result TLV (Success) Binding-TLV=(Version=1,SNonce, CompoundMAC) Intermediate Result TLV (Success) Binging-TLV=(Version=1, CNonce, CompoundMAC) <- Result TLV (Success) PAC TLV Result TLV (Success) PAC Acknowledgment -> TLS channel torn down (messages sent in cleartext) <- EAP-Success Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 30] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 10.2 Example 2: Successful Tunnel PAC Provisioning with Password Change The following exchanges show where EAP-MSCHAPv2 with password change within Phase 2 to provision a Tunnel PAC, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID1) -> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (EAP-FAST Start, S bit set, A-ID) EAP-Response/ EAP-Type=EAP-FAST, V=1 (TLS client_hello without PAC-Opaque extension)-> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS Server Key Exchange TLS Server Hello Done) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (TLS Client Key Exchange TLS change_cipher_spec, TLS finished) <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS change_cipher_spec TLS finished) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (Acknowledgement) TLS channel established (messages sent within the TLS channel) <- EAP Payload TLV EAP-Request/ EAP Identity Request EAP Payload TLV EAP-Response/ Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 31] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 EAP Identity Response -> <- EAP-Payload TLV EAP-Request/ EAP-MSCHAPV2, Challenge EAP Payload TLV, EAP-Response, EAP-MSCHAPV2, Response) -> <- EAP Payload TLV, EAP-Request, MSCHAPV2, Failure, Error Code = ERROR_PASSWD_EXPIRED (E=648)) EAP Payload TLV, EAP-Response, MSCHAPV2, Change Password Response) -> <- EAP Payload TLV, EAP-Request, MSCHAPV2, Success) EAP Payload TLV, EAP-Response, MSCHAPV2, Success) -> <- Intermediate Result TLV (Success) Binding-TLV=(Version=1,SNonce, CompoundMAC) Intermediate Result TLV (Success) Binging-TLV=(Version=1, CNonce, CompoundMAC) <- Result TLV (Success) PAC TLV Result TLV (Success) PAC Acknowledgement -> TLS channel torn down (messages sent in cleartext) <- EAP-Success 10.3 Example 3: Failed Provisioning The following exchanges show a failed EAP-MSCHAPV2 exchange within Phase 2, where the peer failed to authenticate the Server. The conversation will appear as follows: Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 32] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID1) -> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (EAP-FAST Start, S bit set, A-ID) EAP-Response/ EAP-Type=EAP-FAST, V=1 (TLS client_hello without PAC-Opaque extension)-> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS Server Key Exchange TLS Server Hello Done) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (TLS Client Key Exchange TLS change_cipher_spec, TLS finished) <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS change_cipher_spec TLS finished) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (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 -> Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 33] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 <- EAP Payload TLV, EAP-Request, EAP-MSCHAPV2, Success) EAP Payload TLV, EAP-Response, EAP-MSCHAPV2, Failure) -> <- Result TLV (Failure) Result TLV (Failure) -> TLS channel torn down (messages sent in cleartext) <- EAP-Failure 10.4 Example 4: Provisioning a Authentication 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 PAC-Opaque extension)-> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS server_hello, (TLS Server Key Exchange TLS Server Hello Done) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (TLS Client Key Exchange TLS change_cipher_spec, Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 34] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 TLS finished) <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS change_cipher_spec TLS finished) EAP-Payload-TLV[ EAP-Request/Identity]) // TLS channel established (messages sent within the TLS channel) // First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel EAP-Payload TLV/ [EAP Identity Response] -> <- EAP Payload TLV, EAP-Request, [EAP-MSCHAPV2, Challenge] 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) Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 35] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 <- EAP-Failure 10.5 Example 5: Provisioning a User Authorization PAC The following exchanges demonstrate how a User Authorization PAC is provisioned in Phase 2. The conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID1) -> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (EAP-FAST Start, S bit set, A-ID) EAP-Response/ EAP-Type=EAP-FAST, V=1 (TLS client_hello with PAC-Opaque extension)-> <- EAP-Request/ EAP-Type=EAP-FAST, V=1 (TLS server_hello, (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-FAST, V=1 -> (TLS change_cipher_spec, TLS finished) TLS channel established (messages sent within the TLS channel) <- EAP-Payload TLV, EAP-Request, EAP-GTC, Challenge EAP-Payload TLV, EAP-Response, EAP-GTC, Response with both user name and password) -> optional additional exchanges (new pin mode, password change etc.) ... <- Crypto-Binding TLV=(Version=1, EAP-FAST Version =1, Nonce, CompoundMAC) Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 36] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 Result TLV (Success) Crypto-Binding TLV=(Version=1, EAP-FAST Version=1, Nonce, CompoundMAC) Result TLV (Success) Request-Action TLV (Action=1-Process TLV) PAC TLV with PAC-Type=User Authorization PAC)-> <- Result TLV (Success) PAC TLV with User Authorization PAC Result TLV (Success) -> TLS channel torn down (messages sent in cleartext) <- EAP-Success 11. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 37] Internet-Draft Dynamic Provisioning using EAP-FAST July 2005 12. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 14. Expiration Date This memo is filed as , and expires January 11, 2006. Cam-Winget, et al. Expires ûJanuary 11, 2006 [Page 38]