Network Working Group N. Cam-Winget Request for Comments: 5422 D. McGrew Category: Informational J. Salowey H. Zhou Cisco Systems March 2009 Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. IESG Note EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this specification is intended to promote interoperability by documenting current use of existing EAP methods within EAP-FAST.
The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code assigned to EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel. In order to minimize the risk associated with an anonymous tunnel, changes to the method were made that are not interoperable with EAP- MSCHAPv2. Since EAP-MSCHAPv2 does not support method-specific version negotiation, the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous EAP-FAST tunnel. This behavior may cause problems in implementations where the use of unaltered EAP-MSCHAPv2 is needed inside an anonymous EAP-FAST tunnel. Since such support requires special case execution of a method within a tunnel, it also complicates implementations that use the same method code both within and outside of the tunnel method. If EAP-FAST were to be designed today, these difficulties could be avoided by utilization of unique EAP Type codes. Given these issues, assigned method types must not be re-used with different meaning inside tunneled methods in the future.
AbstractThe Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP- FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. 1. Introduction ....................................................4 1.1. Specification Requirements .................................4 1.2. Terminology ................................................4 2. EAP-FAST Provisioning Modes .....................................5 3. Dynamic Provisioning Using EAP-FAST Conversation ................6 3.1. Phase 1 TLS Tunnel .........................................7 3.1.1. Server-Authenticated Tunnel .........................7 3.1.2. Server-Unauthenticated Tunnel .......................7 3.2. Phase 2 - Tunneled Authentication and Provisioning .........7 3.2.1. Server-Authenticated Tunneled Authentication ........8 3.2.2. Server-Unauthenticated Tunneled Authentication ......8 3.2.3. Authenticating Using EAP-FAST-MSCHAPv2 ..............8 3.2.4. Use of Other Inner EAP Methods for EAP-FAST Provisioning ........................................9 3.3. Key Derivations Used in the EAP-FAST Provisioning Exchange ..................................................10 3.4. Peer-Id, Server-Id, and Session-Id ........................11 3.5. Network Access after EAP-FAST Provisioning ................11 4. Information Provisioned in EAP-FAST ............................12
4.1. Protected Access Credential ...............................12 4.1.1. Tunnel PAC .........................................13 4.1.2. Machine Authentication PAC .........................13 4.1.3. User Authorization PAC .............................13 4.1.4. PAC Provisioning ...................................14 4.2. PAC TLV Format ............................................15 4.2.1. Formats for PAC Attributes .........................16 4.2.2. PAC-Key ............................................16 4.2.3. PAC-Opaque .........................................17 4.2.4. PAC-Info ...........................................18 4.2.5. PAC-Acknowledgement TLV ............................20 4.2.6. PAC-Type TLV .......................................21 4.3. Trusted Server Root Certificate ...........................21 4.3.1. Server-Trusted-Root TLV ............................22 4.3.2. PKCS#7 TLV .........................................23 5. IANA Considerations ............................................24 6. Security Considerations ........................................25 6.1. Provisioning Modes and Man-in-the-Middle Attacks ..........25 6.1.1. Server-Authenticated Provisioning Mode and Man-in-the-Middle Attacks ..........................26 6.1.2. Server-Unauthenticated Provisioning Mode and Man-in-the-Middle Attacks ......................26 6.2. Dictionary Attacks ........................................27 6.3. Considerations in Selecting a Provisioning Mode ...........28 6.4. Diffie-Hellman Groups .....................................28 6.5. Tunnel PAC Usage ..........................................28 6.6. Machine Authentication PAC Usage ..........................29 6.7. User Authorization PAC Usage ..............................29 6.8. PAC Storage Considerations ................................29 6.9. Security Claims ...........................................31 7. Acknowledgements ...............................................31 8. References .....................................................31 8.1. Normative References ......................................31 8.2. Informative References ....................................32 Appendix A. Examples .............................................33 A.1. Example 1: Successful Tunnel PAC Provisioning .............33 A.2. Example 2: Failed Provisioning ............................35 A.3. Example 3: Provisioning an Authentication Server's Trusted Root Certificate ..................................37
RFC4851] is an EAP method that can be used to mutually authenticate the peer and server. Credentials such as a pre-shared key, certificate trust anchor, or a Protected Access Credential (PAC) must be provisioned to the peer before it can establish mutual authentication with the server. In many cases, the provisioning of such information presents deployment hurdles. Through the use of the protected TLS [RFC5246] tunnel, EAP-FAST can enable dynamic in-band provisioning to address such deployment obstacles. RFC2119]. RFC3748]. The terms "peer" and "server" are used interchangeably with the terms "EAP peer" and "EAP server", respectively. Additional terms are defined below: Man in the Middle (MITM) An adversary that can successfully inject itself between a peer and EAP server. The MITM succeeds by impersonating a valid peer or server. Provisioning Providing a peer with a trust anchor, shared secret, or other appropriate information needed to establish a security association. Protected Access Credential (PAC) Credentials distributed to a peer for future optimized network authentication. The PAC consists of at most three components: a shared secret, an opaque element, and optional information. The shared secret part contains the secret key shared between the peer and server. The opaque part contains the shared secret encrypted by a private key only known to the server. It is provided to the peer and is presented back to the server when the peer wishes to obtain access to network resources. Finally, a PAC may optionally include other information that may be useful to the peer.
Tunnel PAC A set of credentials stored by the peer and consumed by both the peer and the server to establish a TLS tunnel. User Authorization PAC A User Authorization PAC is server-encrypted data containing authorization information associated with a previously authenticated user. The User Authorization PAC does not contain a key, but rather it is generally bound to a Tunnel PAC, which is used with the User Authorization PAC. Machine Authentication PAC A Machine Authentication PAC contains server-encrypted data containing authorization information associated with a device. A Machine Authentication PAC may be used instead of a Tunnel PAC to establish the TLS tunnel to provide machine authentication and authorization information. The Machine Authentication PAC is useful in cases where the machine needs to be authenticated and authorized to access a network before a user has logged in. RFC4851] describes the EAP- FAST phases in greater detail. In the Server-Authenticated Provisioning Mode, the peer has successfully authenticated the EAP server as part of EAP-FAST phase 1 (i.e., TLS tunnel establishment). Additional exchanges MAY occur inside the tunnel to allow the EAP server to authenticate the EAP peer before provisioning any information. In the Server-Unauthenticated Provisioning Mode, an unauthenticated TLS tunnel is established in the EAP-FAST phase 1. The peer MUST negotiate a TLS anonymous Diffie-Hellman-based ciphersuite to signal
that it wishes to use Server-Unauthenticateded Provisioning Mode. This provisioning mode enables the bootstrapping of peers where the peer lacks strong credentials usable for mutual authentication with the server. Since the server is not authenticated in the Server-Unauthenticated Provisioning Mode, it is possible that an attacker may intercept the TLS tunnel. If an anonymous tunnel is used, then the peer and server MUST negotiate and successfully complete an EAP method supporting mutual authentication and key derivation as described in Section 6. The peer then uses the Crypto-Binding TLV to validate the integrity of the TLS tunnel, thereby verifying that the exchange was not subject to a man-in-the-middle attack. Server-Authenticated Provisioning Mode protects against the man-in- the-middle attack; however, it requires provisioning the peer with the credentials necessary to authenticate the server. Environments willing to trade off the security risk of a man-in-the-middle attack for ease of deployment can choose to use the Server-Unauthenticated Provisioning Mode. Assuming that an inner EAP method and Crypto-Binding TLV exchange is successful, the server will subsequently provide credential information, such as a shared key using a PAC TLV or the trusted certificate root(s) of the server using a Server-Trusted-Root TLV. Once the EAP-FAST Provisioning conversation completes, the peer is expected to use the provisioned credentials in subsequent EAP-FAST authentications. RFC 4851. First, the EAP-FAST phase 1 TLS tunnel is established. During this process, extra material is extracted from the TLS key derivation for use as challenges in the subsequent authentication exchange. Next, an inner EAP method, such as EAP-FAST-MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2), is executed within the EAP-FAST phase 2 TLS tunnel to authenticate the client using the challenges derived from the phase 1 TLS exchange. Following successful authentication and Crypto-Binding TLV exchange, the server provisions the peer with PAC information including the secret PAC-Key and the PAC-Opaque. Finally, the EAP-FAST conversation completes with Result TLV exchanges defined in RFC 4851. The exported EAP Master Session Key (MSK) and Extended MSK (EMSK) are derived from a combination of the tunnel key material and key material from the inner EAP method exchange.
RFC5246]: TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA Other TLS ciphersuites that provide server authentication and encryption MAY be supported. The server MAY authenticate the peer during the TLS handshake in Server-Authenticated Provisioning Mode. To adhere to best security practices, the peer MUST validate the server's certificate chain when performing server-side authentication to obtain the full security benefits of Server-Authenticated provisioning. RFC5246]: TLS_DH_anon_WITH_AES_128_CBC_SHA Anonymous ciphersuites SHOULD NOT be allowed outside of EAP-FAST Server-Unauthenticated Provisioning Mode. Any ciphersuites that are used for Server-Unauthenticated Provisioning Mode MUST provide a key agreement contributed by both parties. Therefore, ciphersuites based on RSA key transport MUST NOT be used for this mode. Ciphersuites that are used for provisioning MUST provide encryption. RFC4851], the authentication exchange will be followed by an Intermediate-Result TLV and a Crypto- Binding TLV, if the EAP method succeeded. The Crypto-Binding TLV
provides a check on the integrity of the tunnel with respect to the endpoints of the EAP method. If the preceding is successful, then a provisioning exchange MAY take place. The provisioning exchange will use a PAC TLV exchange if a PAC is being provisioned and a Server- Trusted-Root TLV if a trusted root certificate is being provisioned. The provisioning MAY be solicited by the peer or it MAY be unsolicited. The PAC TLV exchange consists of the server distributing the PAC in a corresponding PAC TLV to the peer and the peer confirming its receipt in a final PAC TLV Acknowledgement message. The peer may also use the PAC TLV to request that the server send a PAC. The provisioning TLVs MAY be piggybacked onto the Result TLV. Many implementations process TLVs in the order they are received; thus, for proper provisioning to occur, the Result TLV MUST precede the TLVs to be provisioned (e.g., Tunnel PAC, Machine Authentication PAC, and User Authorization PAC). A PAC TLV MUST NOT be accepted if it is not encapsulated in an encrypted TLS tunnel. A fresh PAC MAY be distributed if the server detects that the PAC is expiring soon. In-band PAC refreshing is through the PAC TLV mechanism. The decision of whether or not to refresh the PAC is determined by the server. Based on the PAC-Opaque information, the server MAY determine not to refresh a peer's PAC, even if the PAC-Key has expired. EAP-MSCHAPv2] defined for use within EAP-FAST. The 256-bit inner session key (ISK) is generated from EAP-FAST-MSCHAPv2 by combining the 128-bit master keys derived according to RFC 3079 [RFC3079], with the MasterSendKey taking the first 16 octets and MasterReceiveKey taking the last 16 octets.
Implementations of this version of the EAP-FAST Server- Unauthenticated Provisioning Mode MUST support EAP-FAST-MSCHAPv2 as the inner authentication method. While other authentication methods exist, EAP-FAST-MSCHAPv2 was chosen for several reasons: o It provides the ability to slow an active attack by using a hash- based challenge-response protocol. o Its use of a challenge-response protocol, such as MSCHAPv2, provides some ability to detect a man-in-the-middle attack during Server-Unauthenticated Provisioning Mode. o It is already supported by a large deployed base. o It allows support for password change during the EAP-FAST provisioning modes. When using an anonymous Diffie-Hellman (DH) key agreement, the challenges MUST be generated as defined in Section 3.3. This forms a binding between the tunnel and the EAP-FAST-MSCHAPv2 exchanges by using keying material generated during the EAP-FAST tunnel establishment as the EAP-FAST-MSCHAPv2 challenges instead of using the challenges exchanged within the protocol itself. The exchanged challenges are zeroed upon transmission, ignored upon reception, and the challenges derived from the TLS key exchange are used in the calculations. When EAP-FAST-MSCHAPv2 is used within a tunnel established using a ciphersuite other than one that provides anonymous key agreement, the randomly generated EAP-FAST-MSCHAPv2 challenges MUST be exchanged and used. The EAP-FAST-MSCHAPv2 exchange forces the server to provide a valid ServerChallengeResponse, which must be a function of the server challenge, peer challenge, and password as part of its response. This reduces the window of vulnerability of a man-in-the-middle attack spoofing the server by requiring the attacker to successfully break the password within the peer's challenge-response time limit. RFC5421] MAY be used. This will enable peers using other authentication mechanisms such as password database and one-time passwords to be provisioned in-band as well.
This version of the EAP-FAST provisioning mode implementation MUST support both EAP-FAST-GTC and EAP-FAST-MSCHAPv2 within the tunnel in Server-Authenticated Provisioning Mode. It should be noted that Server-Authenticated Provisioning Mode provides significant security advantages over Server-Unauthenticated Provisioning Mode even when EAP-FAST-MSCHAPv2 is being used as the inner method. It protects the EAP-FAST-MSCHAPv2 exchanges from potential active MITM attacks by verifying the server's authenticity before executing EAP-FAST-MSCHAPv2. Server-Authenticated Provisioning Mode is the recommended provisioning mode. The EAP-FAST peer MUST use the Server- Authenticated Provisioning Mode whenever it is configured with a valid trust root for a particular server. RFC2246] 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 ServerChallenge ClientChallenge
and the key_block for subsequent versions 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] session_key_seed ServerChallenge ClientChallenge In the extra key material, session_key_seed is used for the EAP-FAST Crypto-Binding TLV exchange while the ServerChallenge and ClientChallenge correspond to the authentication server's EAP-FAST- MSCHAPv2 challenge and the peer's EAP-FAST-MSCHAPv2 challenge, respectively. The ServerChallenge and ClientChallenge are only used for the EAP-FAST-MSCHAPv2 exchange when Diffie-Hellman anonymous key agreement is used in the EAP-FAST tunnel establishment. RFC4851] techniques. Section 3.4 of [RFC4851] describes how the Peer-Id and Server-Id are determined; Section 3.5 describes how the Session-Id is generated.
with a successful inner termination (e.g., a successful Result TLV), the server policy defines whether or not the peer gains network access. Thus, it is feasible that the server, while providing a successful Result TLV, may conclude that its authentication policy was not satisfied and terminate the conversation with an EAP Failure. Denying network access after EAP-FAST Provisioning may cause disruption in scenarios such as wireless devices (e.g., in IEEE 802.11 devices, an EAP Failure may trigger a full 802.11 disassociation). While a full EAP restart can be performed, a smooth transition to the subsequent EAP-FAST authentications to enable network access can be achieved by the peer or server initiating TLS renegotiation, where the newly provisioned credentials can be used to establish a server-authenticated or mutually authenticated TLS tunnel for authentication. Either the peer or server may reject the request for TLS renegotiation. Upon completion of the TLS negotiation and subsequent authentication, normal network access policy on EAP-FAST authentication can be applied.
resume so user authentication MAY be skipped. The User Authorization PAC MAY be provisioned after user authentication. It is meant to be short lived and not persisted across logon sessions. The User Authorization PAC SHOULD only be available to the user for which it is provisioned. The User Authorization PAC SHOULD be deleted from the peer when the local authorization state of a user's session changes, such as upon the user logs out. Once the EAP-FAST phase 1 TLS tunnel is established, the peer MAY present a User Authorization PAC to the server in a PAC TLV. This is sent as TLS application data, but it MAY be included in the same message as the Finished Handshake message sent by the peer. The User Authorization PAC MUST only be sent within the protection of an encrypted tunnel to an authenticated entity. The server will decrypt the PAC and evaluate the contents. If the contents are valid and the server policy allows the session to be resumed based on this information, then the server will complete the session resumption and grant access to the peer without requiring an inner authentication method. This is called stateless session resume in EAP-FAST. In this case, the server sends the Result TLV indicating success without the Crypto-Binding TLV and the peer sends back a Result TLV indicating success. If the User Authorization PAC fails the server validation or the server policy, the server MAY either reject the request or continue with performing full user authentication within the tunnel.
A PAC-TLV containing PAC-Acknowledge attribute MUST be sent by the peer to acknowledge the receipt of the Tunnel PAC. A PAC-Acknowledge TLV MUST NOT be used by the peer to acknowledge the receipt of other types of PACs. Please see Appendix A.1 for an example of packet exchanges to provision a Tunnel PAC. RFC4851]. The PAC TLV carries the PAC and related information within PAC attribute fields. Additionally, the PAC TLV MAY be used by the peer to request provisioning of a PAC of the type specified in the PAC Type PAC attribute. The PAC TLV MUST only be used in a protected tunnel providing encryption and integrity protection. A general PAC TLV format is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAC Attributes... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 0 - Non-mandatory TLV 1 - Mandatory TLV R Reserved, set to zero (0) TLV Type 11 - PAC TLV Length Two octets containing the length of the PAC attributes field in octets. PAC Attributes A list of PAC attributes in the TLV format.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Key ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 - PAC-Key Length 2-octet length indicating a 32-octet key Key The value of the PAC-Key. RFC5077]. If a peer has opaque data issued to it by multiple servers, then it stores the data issued by each server separately according to the A-ID. This requirement allows the peer to maintain and use each opaque datum 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 the PAC-Key and PAC-Opaque, the peer determines the PAC-Key and corresponding PAC-Opaque based on the A-ID provided in the EAP- FAST/Start message and the A-ID provided in the PAC-Info when it was provisioned with a PAC-Opaque. The PAC-Opaque attribute 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 the PAC-Opaque. It is specific to the server implementation. Section 4.2.1. The PAC-Info attribute MUST contain the A-ID, A-ID- Info, and PAC-Type attributes. Other attributes MAY be included in the PAC-Info to provide more information to the peer. The PAC-Info attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, PAC- Info, or PAC-Opaque attributes. The PAC-Info attribute is included within the PAC TLV whenever the server wishes to issue or renew a 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 9 - PAC-Info
Length 2-octet Length field containing the length of the attributes field in octets. Attributes The attributes field contains a list of PAC attributes. Each mandatory and optional field type is defined as follows: 3 - PAC-LIFETIME This is a 4-octet quantity representing the expiration time of the credential expressed as the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970. This attribute MAY be provided to the peer as part of the PAC-Info. 4 - A-ID The A-ID is the identity of the authority that issued the PAC. The A-ID is intended to be unique across all issuing servers to avoid namespace collisions. The A-ID is used by the peer to determine which PAC to employ. The A-ID is treated as an opaque octet string. This attribute MUST be included in the PAC-Info attribute. The A-ID MUST match the A-ID the server used to establish the tunnel. Since many existing implementations expect the A-ID to be 16 octets in length, it is RECOMMENDED that the length of an A-ID be 16 octets for maximum interoperability. One method for generating the A-ID is to use a high-quality random number generator to generate a 16-octet random number. An alternate method would be to take the hash of the public key or public key certificate belonging a server represented by the A-ID. 5 - I-ID Initiator identifier (I-ID) is the peer identity associated with the credential. This identity is derived from the inner EAP exchange or from the client-side authentication during tunnel establishment if inner EAP method authentication is not used. The server employs the I-ID in the EAP-FAST phase 2 conversation to validate that the same peer identity used to execute EAP-FAST phase 1 is also used in at minimum one inner EAP method in EAP-FAST phase 2. If the server is enforcing the I-ID validation on the inner EAP method, then the I-ID MUST be included in the PAC-Info, to
enable the peer to also enforce a unique PAC for each unique user. If the I-ID is missing from the PAC-Info, it is assumed that the Tunnel PAC can be used for multiple users and the peer will not enforce the unique-Tunnel-PAC-per-user policy. 7 - A-ID-Info Authority Identifier Information is intended to provide a user-friendly name for the A-ID. It may contain the enterprise name and server name in a human-readable format. This TLV serves as an aid to the peer to better inform the end-user about the A-ID. The name is encoded in UTF-8 [RFC3629] format. This attribute MUST be included in the PAC-Info. 10 - PAC-type The PAC-Type is intended to provide the type of PAC. This attribute SHOULD be included in the PAC-Info. If the PAC- Type is not present, then it defaults to a Tunnel PAC (Type 1).
Result The resulting value MUST be one of the following: 1 - Success 2 - Failure
cannot be responded to with a Negative Acknowledgement (NAK) TLV. The Server-Trusted-Root TLV MUST only be sent as an inner TLV (inside the protection of the tunnel). After the peer has determined that it has successfully authenticated the EAP server and validated the Crypto-Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked as optional) to request the trusted server root certificates from the EAP server. The EAP server MAY send one or more root certificates with a Public Key Cryptographic System #7 (PKCS#7) TLV inside Server-Trusted-Root TLV. The EAP server MAY also choose not to honor the request. Please see Appendix A.3 for an example of a server provisioning a server trusted root certificate. RFC2315] format. If the EAP server sets the credential format to PKCS#7-Server- Certificate-Root, then the Server-Trusted-Root TLV should contain the root of the certificate chain of the certificate issued to the EAP server packaged in a PKCS#7 TLV. If the Server certificate is a self-signed certificate, then the root is the self-signed certificate. If the Server-Trusted-Root TLV credential format contains a value unknown to the peer, then the EAP peer should ignore the TLV. The Server-Trusted-Root TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Credential-Format | Cred TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- M 0 - Non-mandatory TLV R Reserved, set to zero (0)
TLV Type 18 - Server-Trusted-Root TLV [RFC4851] Length >=2 octets Credential-Format The Credential-Format field is two octets. Values include: 1 - PKCS#7-Server-Certificate-Root Cred TLVs This field is of indefinite length. It contains TLVs associated with the credential format. The peer may leave this field empty when using this TLV to request server trust roots. RFC2315] X.509 certificates. The format consists of a certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message as defined in [RFC2311]. The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. EAP-FAST server implementations that claim to support the dynamic provisioning defined in this document SHOULD support this TLV. EAP-FAST peer implementations MAY support this TLV. If the PKCS#7 TLV contains a certificate or certificate chain that is not acceptable to the peer, then the peer MUST ignore the TLV. The PKCS#7 TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PKCS #7 Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M 0 - Optional TLV R Reserved, set to zero (0) TLV Type 20 - PKCS#7 TLV [RFC4851] Length The length of the PKCS #7 Data field. PKCS #7 Data This field contains the X.509 certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message. RFC5226]. A registry of values, named "EAP-FAST PAC Attribute Types", has been created for the PAC attribute types. The initial values that populate the registry are: 1 - PAC-Key 2 - PAC-Opaque 3 - PAC-Lifetime 4 - A-ID 5 - I-ID 6 - Reserved 7 - A-ID-Info 8 - PAC-Acknowledgement 9 - PAC-Info 10 - PAC-Type Values from 11 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy.
A registry of values, named "EAP-FAST PAC Types", has been created for PAC-Type values used in the PAC-Type TLV. The initial values that populate the registry are: 1 - Tunnel PAC 2 - Machine Authentication PAC 3 - User Authorization PAC Values from 4 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy. A registry of values, named "EAP-FAST Server-Trusted-Root Credential Format Types", has been created for Credential-Format values used in the Server-Trusted-Root TLV. The initial values that populate the registry are: 1 - PKCS#7-Server-Certificate-Root Values from 2 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy. RFC4851]. Additionally, it also has its unique security considerations described below:
This makes use of the cryptographic binding exchange defined within EAP-FAST to discover the presence of a man-in-the-middle attack by binding secret information obtained from the phase 2 EAP-FAST-MSCHAPv2 exchange with secret information from the phase 1 TLS exchange. While it would be sufficient to only support the cryptographic binding to mitigate the MITM, the binding of the EAP-FAST-MSCHAPv2 random challenge derivations to the TLS key agreement protocol enables early detection of a man-in-the-middle attack. This guards against adversaries who may otherwise relay the inner EAP authentication messages between the true peer and server, and it enforces that the adversary successfully respond with a valid challenge response. The ciphersuite used to establish phase 1 of the Server- Unauthenticated Provisioning Mode MUST be one in which both the peer and server provide contribution to the derived TLS master key. Ciphersuites that use RSA key transport do not meet this requirement. The authenticated and anonymous ephemeral Diffie-Hellman ciphersuites provide this type of key agreement. This document specifies EAP-FAST-MSCHAPv2 as the inner authentication exchange; however, it is possible that other inner authentication mechanisms to authenticate the tunnel may be developed in the future. Since the strength of the man-in-the-middle protection is directly dependent on the strength of the inner method, it is RECOMMENDED that any inner method used provide at least as much resistance to attack as EAP-FAST-MSCHAPv2. Cleartext passwords MUST NOT be used in Server-Unauthenticated Provisioning Mode. Note that an active man- in-the-middle attack may observe phase 2 authentication method exchange until the point that the peer determines that authentication mechanism fails or is aborted. This allows for the disclosure of sensitive information such as identity or authentication protocol exchanges to the man-in-the-middle attack.
In off-line dictionary attacks, the attacker captures information that can be processed off-line to recover the password. Server- Authenticated Provisioning Mode provides effecting mitigation because the peer will not engage in phase 2 authentication without first authenticating the server during phase 1. Server-Unauthenticated Provisioning Mode is vulnerable to this type of attack. If, during phase 2 authentication, a peer receives no response or an invalid response from the server, then there is a possibility there is a man- in-the-middle attack in progress. Implementations SHOULD log these events and, if possible, provide warnings to the user. Implementations are also encouraged to provide controls, which are appropriate to their environment, that limit how and where Server- Unauthenticated Provisioning Mode can be performed. For example, an implementation may limit this mode to be used only on certain interfaces or require user intervention before allowing this mode if provisioning has succeeded in the past. Another mitigation technique that should not be overlooked is the choice of good passwords that have sufficient complexity and length and a password-changing policy that requires regular password changes. RFC3526].
identity of a peer to prevent a particular Tunnel PAC from being used to establish a tunnel that can perform phase 2 authentication other peers. While it is possible for the server to accept the Tunnel PAC as authentication for the peer, many current implementations do not do this. The ability to use PAC to authenticate peers and provide authorizations will be the subject of a future document. [RFC5077] gives an example PAC-Opaque format in the Recommended Ticket Construction section.
Most of the attacks described here would require some level of effort to execute: conceivably greater than their value. The main focus therefore, should be to ensure that proper protections are used on both the peer and server. There are a number of potential attacks that can be considered against secure key storage such as: o Weak Passphrases On the peer side, keys are usually protected by a passphrase. In 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 enable an attacker to easily attack all users in an enterprise environment through the use of email viruses and other techniques. o Key Finding Attacks Key finding attacks are usually mentioned in reference to web servers where the private Secure Socket Layer (SSL) key may be stored securely, but at some point, it must be decrypted and stored in system memory. An attacker with access to system memory can actually find the key by identifying their mathematical properties. To date, this attack appears to be purely theoretical and primarily acts to argue strongly for secure access controls on the server itself to prevent such unauthorized code from executing. o Key duplication, Key substitution, Key modification Once keys are accessible to an attacker on either the peer or server, they fall under three forms of attack: key duplication, key substitution, and key modification. The first option would be the most common, allowing the attacker to masquerade as the user in question. The second option could have some use if an attacker could implement it on the server. Alternatively, an attacker could use one of the latter two attacks on either the peer or server to force a PAC re-key, and take advantage of the potential MITM/dictionary attack vulnerability of the EAP-FAST Server- Unauthenticated Provisioning Mode. Another consideration is the use of secure mechanisms afforded by the particular device. For instance, some laptops enable secure key storage through a special chip. It would be worthwhile for implementations to explore the use of such a mechanism.
RFC3748] security claims for EAP-FAST are given in Section 7.8 of [RFC4851]. When using anonymous provisioning mode, there is a greater risk of off-line dictionary attack since it is possible for a man-in-the-middle attack to capture the beginning of the inner EAP- FAST-MSCHAPv2 conversation. However, as noted previously, it is possible to detect the man-in-the-middle attack. [EAP-MSCHAPv2] Microsoft Corporation, "MS-CHAP: Extensible Authentication Protocol Method for Microsoft Challenge Handshake Authentication Protocol (CHAP) Specification", January 2009. http://msdn2.microsoft.com/ en-us/library/cc224612.aspx [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998. [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998. [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP- FAST)", RFC 4851, May 2007. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP- FAST)", RFC 5421, March 2009. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
EAP Payload TLV (EAP-Response/Identity) -> <- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (Challenge)) EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) -> <- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2) (Success)) EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Success)) -> <- Intermediate Result TLV(Success) Crypto-Binding-TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC) Intermediate Result TLV (Success) Crypto-Binding-TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC) PAC-TLV (Type=1) <- Result TLV (Success) PAC TLV Result TLV (Success) PAC Acknowledgment -> TLS channel torn down (messages sent in cleartext) <- EAP-Failure
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) -> <- EAP Payload TLV (EAP-Request EAP-FAST-MSCHAPv2 (Success)) // peer failed to verify server MSCHAPv2 response EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Failure)) -> <- Result TLV (Failure) Result TLV (Failure) -> TLS channel torn down (messages sent in cleartext) <- EAP-Failure
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) -> <- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (success)) EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Success) -> <- Intermediate Result TLV(Success) Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC), Intermediate Result TLV(Success) Crypto-Binding TLV (Version=1 EAP-FAST Version=1, Nonce, CompoundMAC) Server-Trusted-Root TLV (Type = PKCS#7) -> <- Result TLV (Success) Server-Trusted-Root TLV (PKCS#7 TLV) Result TLV (Success) -> // TLS channel torn down (messages sent in cleartext) <- EAP-Failure