summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5422.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5422.txt')
-rw-r--r--doc/rfc/rfc5422.txt2187
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc5422.txt b/doc/rfc/rfc5422.txt
new file mode 100644
index 0000000..2163633
--- /dev/null
+++ b/doc/rfc/rfc5422.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 1]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+Abstract
+
+ The 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.
+
+Table of Contents
+
+ 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
+
+
+
+Cam-Winget, et al. Informational [Page 2]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 3]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+1. Introduction
+
+ EAP-FAST [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.
+
+1.1. Specification Requirements
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+1.2. Terminology
+
+ Much of the terminology used in this document comes from [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.
+
+
+
+
+Cam-Winget, et al. Informational [Page 4]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+2. EAP-FAST Provisioning Modes
+
+ EAP-FAST supports two modes for provisioning:
+
+ 1. Server-Authenticated Provisioning Mode - Provisioning inside a
+ TLS tunnel that provides server-side authentication.
+
+ 2. Server-Unauthenticated Provisioning Mode - Provisioning inside an
+ anonymous TLS tunnel.
+
+ The EAP-FAST provisioning modes use EAP-FAST phase 2 inside a secure
+ TLS tunnel established during phase 1. [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
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 5]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+3. Dynamic Provisioning Using EAP-FAST Conversation
+
+ The provisioning occurs in the following steps, which are detailed in
+ the subsequent sections and in 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.
+
+
+
+
+Cam-Winget, et al. Informational [Page 6]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+3.1. Phase 1 TLS Tunnel
+
+3.1.1. Server-Authenticated Tunnel
+
+ The provisioning EAP-FAST exchange uses the same sequence as the EAP-
+ FAST authentication phase 1 to establish a protected TLS tunnel.
+ Implementations supporting this version of the Sever-Authenticated
+ Provisioning Mode MUST support the following TLS ciphersuites defined
+ in [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.
+
+3.1.2. Server-Unauthenticated Tunnel
+
+ Implementations supporting this version of the Sever-Unauthenticated
+ Provisioning Mode MUST support the following TLS ciphersuite defined
+ in [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.
+
+3.2. Phase 2 - Tunneled Authentication and Provisioning
+
+ Once a protected tunnel is established and the server is
+ unauthenticated, the peer and server MUST execute additional
+ authentication and perform integrity checks of the TLS tunnel. Even
+ if both parties are authenticated during TLS tunnel establishment,
+ the peer and server MAY wish to perform additional authentication
+ within the tunnel. As defined in [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
+
+
+
+
+Cam-Winget, et al. Informational [Page 7]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+3.2.1. Server-Authenticated Tunneled Authentication
+
+ If Server-Authenticated Provisioning Mode is in use, then any EAP
+ method may be used within the TLS tunnel to authenticate the peer
+ that is allowed by the peer's policy.
+
+3.2.2. Server-Unauthenticated Tunneled Authentication
+
+ If Server-Unauthenticated Provisioning Mode is in use, then peer
+ authenticates the server and the server authenticates the peer within
+ the tunnel. The only method for performing authentication defined in
+ this version of EAP-FAST is EAP-FAST-MSCHAPv2 (in a special way as
+ described in the following section). It is possible for other
+ methods to be defined to perform this authentication in the future.
+
+3.2.3. Authenticating Using EAP-FAST-MSCHAPv2
+
+ EAP-FAST-MSCHAPv2 is a specific instantiation of EAP-MSCHAPv2
+ [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.
+
+
+
+
+Cam-Winget, et al. Informational [Page 8]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+3.2.4. Use of Other Inner EAP Methods for EAP-FAST Provisioning
+
+ Once a protected tunnel is established, typically the peer
+ authenticates itself to the server before the server can provision
+ the peer. If the authentication mechanism does not support mutual
+ authentication and protection from man-in-the-middle attacks, then
+ Server-Authenticated Provisioning Mode MUST be used. Within a server
+ side, authenticated tunnel authentication mechanisms such as EAP-
+ FAST-GTC (Generic Token Card) [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.
+
+
+
+Cam-Winget, et al. Informational [Page 9]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+3.3. Key Derivations Used in the EAP-FAST Provisioning Exchange
+
+ The TLS tunnel key is calculated according to the TLS version with an
+ extra 72 octets of key material derived from the end of the
+ key_block. Portions of the extra 72 octets are used for the EAP-FAST
+ provisioning exchange session key seed and as the random challenges
+ in the EAP-FAST-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.
+
+ For example, the key_block for TLS 1.0 [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[40]
+ ServerChallenge[16]
+ ClientChallenge[16]
+
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 10]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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[40]
+ ServerChallenge[16]
+ ClientChallenge[16]
+
+ 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.
+
+3.4. Peer-Id, Server-Id, and Session-Id
+
+ The provisioning modes of EAP-FAST do not change the general EAP-
+ FAST protocol and thus how the Peer-Id, Server-Id, and Session-Id are
+ determined is based on the [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.
+
+3.5. Network Access after EAP-FAST Provisioning
+
+ After successful provisioning, network access MAY be granted or
+ denied depending upon the server policy. For example, in the Server-
+ Authenticated Provisioning Mode, access can be granted after the EAP
+ server has authenticated the peer and provisioned it with a Tunnel
+ PAC (i.e., a PAC used to mutually authenticate and establish the EAP-
+ FAST tunnel). Additionally, peer policy MAY instruct the peer to
+ disconnect the current provisioning connection and initiate a new
+ EAP-FAST exchange for authentication utilizing the newly provisioned
+ information. At the end of the Server-Unauthenticated Provisioning
+ Mode, network access SHOULD NOT be granted as this conversation is
+ intended for provisioning only and thus no network access is
+ authorized. The server MAY grant access at the end of a successful
+ Server-Authenticated provisioning exchange.
+
+ If after successful provisioning access to the network is denied, the
+ EAP Server SHOULD conclude with an EAP Failure. The EAP server SHALL
+ NOT grant network access or distribute any session keys to the
+ Network Access Server (NAS) if this exchange is not intended to
+ provide network access. Even though the provisioning mode completes
+
+
+
+Cam-Winget, et al. Informational [Page 11]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+4. Information Provisioned in EAP-FAST
+
+ Multiple types of credentials MAY be provisioned within EAP-FAST.
+ The most common credential is the Tunnel PAC that is used to
+ establish the EAP-FAST phase 1 tunnel. In addition to the Tunnel
+ PAC, other types of credentials and information can also be
+ provisioned through EAP-FAST. They may include trusted root
+ certificates, PACs for specific purposes, and user identities, to
+ name a few. Typically, provisioning is invoked after both the peer
+ and server authenticate each other and after a successful Crypto-
+ Binding TLV exchange. However, depending on the information being
+ provisioned, mutual authentication MAY not be needed.
+
+ At a minimum, either the peer or server must prove authenticity
+ before credentials are provisioned to ensure that information is not
+ freely provisioned to or by adversaries. For example, the EAP server
+ may not need to authenticate the peer to provision it with trusted
+ root certificates. However, the peer SHOULD authenticate the server
+ before it can accept a trusted server root certificate.
+
+4.1. Protected Access Credential
+
+ A Protected Access Credential (PAC) is a security credential
+ generated by the server that holds information specific to a peer.
+ The server distributes all PAC information through the use of a PAC
+ TLV. Different types of PAC information are identified through the
+ PAC Type and other PAC attributes defined in this section. This
+ document defines three types of PACs: a Tunnel PAC, a Machine
+ Authentication PAC, and a User Authorization PAC.
+
+
+
+Cam-Winget, et al. Informational [Page 12]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+4.1.1. Tunnel PAC
+
+ The server distributes the Tunnel PAC to the peer, which uses it in
+ subsequent attempts to establish a secure EAP-FAST TLS tunnel with
+ the server. The Tunnel PAC includes a secret key (PAC-Key), data
+ that is opaque to the peer (PAC-Opaque), and other information (PAC-
+ Info) that the peer can interpret. The opaque data is generated by
+ the server and cryptographically protected so it cannot be modified
+ or interpreted by the peer. The Tunnel PAC conveys the server policy
+ of what must and can occur in the protected phase 2 tunnel. It is up
+ to the server policy to include what is necessary in a PAC-Opaque to
+ enforce the policy in subsequent TLS handshakes. For example, user
+ identity, I-ID, can be included as the part of the server policy.
+ This I-ID information limits the inner EAP methods to be carried only
+ on the specified user identity. Other types of information can also
+ be included, such as which EAP method(s) and which TLS ciphersuites
+ are allowed. If the server policy is not included in a PAC-Opaque,
+ then there is no limitation imposed by the PAC on the usage of the
+ inner EAP methods or user identities inside the tunnel established by
+ the use of that PAC.
+
+4.1.2. Machine Authentication PAC
+
+ The Machine Authentication PAC contains information in the PAC-Opaque
+ that identifies the machine. It is meant to be used by a machine
+ when network access is required and no user is logged in. Typically,
+ a server will only grant the minimal amount of access required for a
+ machine without a user present based on the Machine Authentication
+ PAC. The Machine Authentication PAC MAY be provisioned during the
+ authentication of a user. It SHOULD be stored by the peer in a
+ location that is only accessible to the machine. This type of PAC
+ typically persists across sessions.
+
+ The peer can use the Machine Authentication PAC as the Tunnel PAC to
+ establish the TLS tunnel. The EAP server MAY have a policy to bypass
+ additional inner EAP method and grant limited network access based on
+ information in the Machine Authentication PAC. The server MAY
+ request additional exchanges to validate machine's other
+ authorization criteria, such as posture information etc., before
+ granting network access.
+
+4.1.3. User Authorization PAC
+
+ The User Authorization PAC contains information in the PAC-Opaque
+ that identifies a user and provides authorization information. This
+ type of PAC does not contain a PAC-Key. The PAC-Opaque portion of
+ the User Authorization PAC is presented within the protected EAP-FAST
+ TLS tunnel to provide user information during stateless session
+
+
+
+Cam-Winget, et al. Informational [Page 13]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+4.1.4. PAC Provisioning
+
+ To request provisioning of a PAC, a peer sends a PAC TLV containing a
+ PAC attribute of PAC Type set to the appropriate value. For a Tunnel
+ PAC, the value is '1'; for a Machine Authentication PAC, the value is
+ '2'; and for a User Authorization PAC, the value is '3'. The request
+ MAY be issued after the peer has determined that it has successfully
+ authenticated the EAP server and validated the Crypto-Binding TLV to
+ ensure that the TLS tunnel's integrity is intact. Since anonymous DH
+ ciphersuites are only allowed for provisioning a Tunnel PAC, if an
+ anonymous ciphersuite is negotiated, the Tunnel PAC MAY be
+ provisioned automatically by the server. The peer MUST send separate
+ PAC TLVs for each type of PAC it wants to provision. Multiple PAC
+ TLVs can be sent in the same packet or different packets. When
+ requesting the Machine Authentication PAC, the peer SHOULD include an
+ I-ID TLV containing the machine name prefixed by "host/". 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 an unknown type, it MUST ignore it.
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 14]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+4.2. PAC TLV Format
+
+ The PAC TLV provides support for provisioning the Protected Access
+ Credential (PAC) defined within [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.
+
+
+
+Cam-Winget, et al. Informational [Page 15]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+4.2.1. Formats for PAC Attributes
+
+ Each PAC attribute in a PAC TLV is formatted as a TLV defined as
+ follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ The Type field is two octets, denoting the attribute type.
+ Allocated Types include:
+
+ 1 - PAC-Key
+ 2 - PAC-Opaque
+ 3 - PAC-Lifetime
+ 4 - A-ID
+ 5 - I-ID
+ 6 - Reserved
+ 7 - A-ID-Info
+ 8 - PAC-Acknowledgement
+ 9 - PAC-Info
+ 10 - PAC-Type
+
+ Length
+
+ Two octets containing the length of the Value field in
+ octets.
+
+ Value
+
+ The value of the PAC attribute.
+
+4.2.2. PAC-Key
+
+ The PAC-Key is a secret key distributed in a PAC attribute of type
+ PAC-Key. The PAC-Key attribute is included within the PAC TLV
+ whenever the server wishes to issue or renew a PAC that is bound to a
+ key such as a Tunnel PAC. The key is a randomly generated octet
+ string, which is 32 octets in length. The generator of this key is
+ the issuer of the credential, which is identified by the Authority
+ Identifier (A-ID).
+
+
+
+
+Cam-Winget, et al. Informational [Page 16]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+4.2.3. PAC-Opaque
+
+ The PAC-Opaque attribute is included within the PAC TLV whenever the
+ server wishes to issue or renew a PAC or the client wishes to present
+ a User Authorization PAC to the server.
+
+ The PAC-Opaque is opaque to the peer and thus the peer MUST NOT
+ attempt to interpret it. A peer that has been issued a PAC-Opaque by
+ a server stores that data and presents it back to the server
+ according to its PAC Type. The Tunnel PAC is used in the ClientHello
+ SessionTicket extension field defined in [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:
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 17]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+4.2.4. PAC-Info
+
+ The PAC-Info is comprised of a set of PAC attributes as defined in
+ Section 4.2.1. The PAC-Info attribute MUST contain the A-ID, A-ID-
+ Info, and PAC-Type attributes. Other attributes MAY be included in
+ the PAC-Info to provide more information to the peer. The PAC-Info
+ attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, PAC-
+ Info, or PAC-Opaque attributes. 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
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 18]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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
+
+
+
+Cam-Winget, et al. Informational [Page 19]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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).
+
+4.2.5. PAC-Acknowledgement TLV
+
+ The PAC-Acknowledgement is used to acknowledge the receipt of the
+ Tunnel PAC by the peer. The peer includes the PAC-Acknowledgement
+ TLV in a PAC-TLV sent to the server to indicate the result of the
+ processing and storing of a newly provisioned Tunnel PAC. This TLV
+ is only used when Tunnel PAC is provisioned.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 8 - PAC-Acknowledgement
+
+ Length
+
+ The length of this field is two octets containing a value of 2.
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 20]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ Result
+
+ The resulting value MUST be one of the following:
+
+ 1 - Success
+ 2 - Failure
+
+4.2.6. PAC-Type TLV
+
+ The PAC-Type TLV is a TLV intended to specify the PAC type. It is
+ included in a PAC-TLV sent by the peer to request PAC provisioning
+ from the server. Its format is described below:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PAC Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 10 - PAC-Type
+
+ Length
+
+ 2-octet Length field with a value of 2
+
+ PAC Type
+
+ This 2-octet field defines the type of PAC being requested or
+ provisioned. The following values are defined:
+
+ 1 - Tunnel PAC
+ 2 - Machine Authentication PAC
+ 3 - User Authorization PAC
+
+4.3. Trusted Server Root Certificate
+
+ Server-Trusted-Root TLV facilitates the request and delivery of a
+ trusted server root certificate. The Server-Trusted-Root TLV can be
+ exchanged in regular EAP-FAST authentication mode or provisioning
+ mode. The Server-Trusted-Root TLV is always marked as optional, and
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 21]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+4.3.1. Server-Trusted-Root TLV
+
+ The Server-Trusted-Root TLV allows the peer to send a request to the
+ EAP server for a list of trusted roots. The server may respond with
+ one or more root certificates in PKCS#7 [RFC2315] format.
+
+ If the EAP server sets 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)
+
+
+
+
+Cam-Winget, et al. Informational [Page 22]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+4.3.2. PKCS#7 TLV
+
+ The PKCS#7 TLV is sent by the EAP server to the peer inside the
+ Server-Trusted-Root TLV. It contains PKCS#7-wrapped [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...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+Cam-Winget, et al. Informational [Page 23]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+5. IANA Considerations
+
+ This section explains the criteria to be used by the IANA for
+ assignment of Type value in the PAC attribute, the PAC Type value in
+ the PAC- Type TLV, and the Credential-Format value in the Server-
+ Trusted-Root TLV. The "Specification Required" policy is used here
+ with the meaning defined in BCP 26 [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.
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 24]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+6. Security Considerations
+
+ The Dynamic Provisioning EAP-FAST protocol shares the same security
+ considerations outlined in [RFC4851]. Additionally, it also has its
+ unique security considerations described below:
+
+6.1. Provisioning Modes and Man-in-the-Middle Attacks
+
+ EAP-FAST can be invoked in two different provisioning modes: Server-
+ Authenticated Provisioning Mode and Server-Unauthenticated
+ Provisioning Mode. Each mode provides different levels of resistance
+ to man-in-the-middle attacks. The following list identifies some of
+ the problems associated with a man-in-the-middle attack:
+
+ o Disclosure of secret information such as keys, identities, and
+ credentials to an attacker
+
+ o Spoofing of a valid server to a peer and the distribution of false
+ credentials
+
+ o Spoofing of a valid peer and receiving credentials generated for
+ that peer
+
+ o Denial of service
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 25]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+6.1.1. Server-Authenticated Provisioning Mode and Man-in-the-Middle
+ Attacks
+
+ In Server-Authenticated Provisioning Mode, the TLS handshake assures
+ protected communications with the server because the peer must have
+ been securely pre-provisioned with the trust roots and/or other
+ authentication information necessary to authenticate the server
+ during the handshake. This pre-provisioning step prevents an
+ attacker from inserting themselves as a man-in-the-middle of the
+ communications. Unfortunately, secure pre-provisioning can be
+ difficult to achieve in many environments.
+
+ Cryptographic binding of inner authentication mechanisms to the TLS
+ tunnel provides additional protection from man-in-the-middle attacks
+ resulting from the tunneling of authentication mechanisms.
+
+ Server-Authenticated Provisioning Mode provides a high degree of
+ protection from man-in-the-middle attacks.
+
+6.1.2. Server-Unauthenticated Provisioning Mode and Man-in-the-Middle
+ Attacks
+
+ In Server-Unauthenticated Provisioning Mode, the TLS handshake does
+ not assure protected communications with the server because either an
+ anonymous handshake is negotiated or the peer lacks the necessary
+ information to complete the authentication of the server. This
+ allows an attacker to insert itself in the middle of the TLS
+ communications.
+
+ EAP-FAST Server-Unauthenticated Provisioning Mode mitigates the man-
+ in-the-middle attack through the following techniques:
+
+ o Binding the phase 2 authentication method to secret values derived
+ from the phase 1 TLS exchange:
+
+ In the case of EAP-FAST-MSCHAPv2 used with an anonymous Diffie-
+ Hellman ciphersuite, the challenges for the EAP-FAST-MSCHAPv2
+ exchange are derived from the TLS handshake and are not
+ transmitted within the EAP-FAST-MSCHAPv2 exchange. Since the man-
+ in-the-middle attack does not know these challenges, it cannot
+ successfully impersonate the server without cracking the EAP-FAST-
+ MSCHAPv2 message from the peer before the peer times out.
+
+ o Cryptographic binding of secret values derived from the phase 2
+ authentication exchange with secret values derived from the phase
+ 1 TLS exchange:
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 26]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+6.2. Dictionary Attacks
+
+ It is often the case that phase 2 authentication mechanisms are based
+ on password credentials. These exchanges may be vulnerable to both
+ online and off-line dictionary attacks. The two provisioning modes
+ provide various degrees of protection from these attacks.
+
+ In online dictionary attacks, the attacker attempts to discover the
+ password by repeated attempts at authentication using a guessed
+ password. Neither mode prevents this type of attack by itself.
+ Implementations should provide controls that limit how often an
+ attacker can execute authentication attempts.
+
+
+
+Cam-Winget, et al. Informational [Page 27]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+6.3. Considerations in Selecting a Provisioning Mode
+
+ Since Server-Authenticated Provisioning Mode provides much better
+ protection from attacks than Server-Unauthenticated Provisioning
+ Mode, Server-Authenticated Provisioning Mode SHOULD be used whenever
+ possible. The Server-Unauthenticated Provisioning Mode provides 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-touch provisioning and facilitates simpler deployments
+ requiring little to no peer configuration. The peer MAY choose to
+ use alternative secure out-of-band mechanisms for PAC provisioning
+ that afford better security than the Server Unauthenticated
+ Provisioning Mode.
+
+6.4. Diffie-Hellman Groups
+
+ To encourage interoperability implementations of EAP-FAST, anonymous
+ provisioning modes MUST support the 2048-bit group "14" in [RFC3526].
+
+6.5. Tunnel PAC Usage
+
+ The basic usage of the Tunnel PAC is to establish the TLS tunnel. In
+ this operation, it does not have to provide user authentication as
+ user authentication is expected to be carried out in phase 2 of EAP-
+ FAST. The EAP-FAST Tunnel PAC MAY contain information about the
+
+
+
+Cam-Winget, et al. Informational [Page 28]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+6.6. Machine Authentication PAC Usage
+
+ In general, the Machine Authorization PAC is expected to provide the
+ minimum access required by a machine without a user. This will
+ typically be a subset of the privilege a registered user has. The
+ server provisioning the PAC should include information necessary to
+ validate it at a later point in time. This would include expiration
+ information. The Machine Authentication PAC includes a key so it can
+ be used as a Tunnel PAC. The PAC-Key MUST be kept secret by the
+ peer.
+
+6.7. User Authorization PAC Usage
+
+ The User Authorization PAC provides the privilege associated with a
+ user. The server provisioning the PAC should include the information
+ necessary to validate it at a later point in time. This includes
+ expiration and other information associated with the PAC. The User
+ Authorization PAC is a bearer credential such that it does not have a
+ key that used to authenticate its ownership. For this reason, this
+ type of PAC MUST NOT be sent in the clear. For additional
+ protection, the PAC MAY be bound to a Tunnel PAC used to establish
+ the TLS tunnel. On the peer, the User Authorization PAC SHOULD only
+ be accessible by the user for which it is provisioned.
+
+6.8. PAC Storage Considerations
+
+ The main goal of EAP-FAST is to protect the authentication stream
+ over the media link. However, host security is still an issue. Some
+ care should be taken to protect the PAC on both the peer and server.
+ The peer must securely store both the PAC-Key and PAC-Opaque, while
+ the server must secure storage of its security association context
+ used to consume the PAC-Opaque. Additionally, if alternate
+ provisioning is employed, the transportation mechanism used to
+ distribute the PAC must also be secured.
+
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 29]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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.
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 30]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+6.9. Security Claims
+
+ The [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.
+
+7. Acknowledgements
+
+ The EAP-FAST design and protocol specification is based on the ideas
+ and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith,
+ Ilan Frenkel, Max Pritikin, Jan Vilhuber, and Jeremy Steiglitz. The
+ authors would also like to thank Jouni Malinen, Pasi Eronen, Jari
+ Arkko, Chris Newman, Ran Canetti, and Vijay Gurbani for reviewing
+ this document.
+
+8. References
+
+8.1. Normative References
+
+ [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.
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 31]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ [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.
+
+8.2. Informative References
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", BCP 26,
+ RFC 5226, May 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 32]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+Appendix A. Examples
+
+A.1. Example 1: Successful Tunnel PAC Provisioning
+
+ The following exchanges show anonymous DH with a successful EAP-FAST-
+ 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-FAST,
+ (S=1, A-ID)
+
+ EAP-Response/EAP-FAST
+ (TLS Client Hello without
+ PAC-Opaque in SessionTicket extension)->
+
+ <- EAP-Request/EAP-FAST
+ (TLS Server Hello,
+ TLS Server Key Exchange
+ TLS Server Hello Done)
+
+ EAP-Response/EAP-FAST
+ (TLS Client Key Exchange
+ TLS Change Cipher Spec
+ TLS Finished) ->
+
+ <- EAP-Request/EAP-FAST
+ ( TLS change_cipher_spec,
+ TLS finished,
+ EAP-Payload-TLV
+ (EAP-Request/Identity))
+
+ // TLS channel established
+ (Subsequent messages sent within the TLS channel,
+ encapsulated within EAP-FAST)
+
+ // First EAP Payload TLV is piggybacked on the TLS Finished as
+ Application Data and protected by the TLS tunnel
+
+
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 33]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 34]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+A.2. Example 2: Failed Provisioning
+
+ The following exchanges show a failed EAP-FAST-MSCHAPv2 exchange
+ within phase 2, where the peer failed to authenticate the server.
+ The conversation will appear as follows:
+
+ Authenticating Peer Authenticator
+ ------------------- -------------
+ <- EAP-Request/Identity
+ EAP-Response/
+ Identity (MyID1) ->
+ <- EAP-Request/EAP-FAST
+ (s=1, A-ID)
+
+ EAP-Response/EAP-FAST
+ (TLS Client Hello without
+ SessionTicket extension)->
+
+ <- EAP-Request/EAP-FAST
+ (TLS Server Hello
+ TLS Server Key Exchange
+ TLS Server Hello Done)
+ EAP-Response/EAP-FAST
+ (TLS Client Key Exchange
+ TLS Change Cipher Spec,
+ TLS Finished) ->
+
+ <- EAP-Request/EAP-FAST
+ ( TLS change_cipher_spec,
+ TLS finished,
+ EAP-Payload-TLV
+ (EAP-Request/Identity))
+
+ // TLS channel established
+ (Subsequent messages sent within the TLS channel,
+ encapsulated within EAP-FAST)
+
+ // First EAP Payload TLV is piggybacked on the TLS Finished as
+ Application Data and protected by the TLS tunnel
+
+
+ EAP Payload TLV
+ (EAP-Response/Identity)->
+
+ <- EAP Payload TLV
+ (EAP-Request/EAP-FAST-MSCHAPv2
+ (Challenge))
+
+
+
+
+Cam-Winget, et al. Informational [Page 35]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 36]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+A.3. Example 3: Provisioning an Authentication Server's Trusted Root
+ Certificate
+
+ The following exchanges show a successful provisioning of a server
+ trusted root certificate using anonymous DH and EAP-FAST-MSCHAPv2
+ exchange within phase 2. The conversation will appear as follows:
+
+ Authenticating Peer Authenticator
+ ------------------- -------------
+ <- EAP-Request/
+ Identity
+ EAP-Response/
+ Identity (MyID1) ->
+ <- EAP-Requese/EAP-FAST
+ (s=1, A-ID)
+
+ EAP-Response/EAP-FAST
+ (TLS Client Hello without
+ SessionTicket extension)->
+ <- EAP-Request/EAP-FAST
+ (TLS Server Hello,
+ (TLS Server Key Exchange
+ TLS Server Hello Done)
+
+ EAP-Response/EAP-FAST
+ (TLS Client Key Exchange
+ TLS Change Cipher Spec,
+ TLS Finished) ->
+
+ <- EAP-Request/EAP-FAST
+ (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 on the TLS Finished as
+ Application Data and protected by the TLS tunnel
+
+ EAP-Payload TLV
+ (EAP-Response/Identity) ->
+
+ <- EAP Payload TLV
+ (EAP-Request/EAP-FAST-MSCHAPv2
+ (Challenge))
+
+
+
+
+Cam-Winget, et al. Informational [Page 37]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 38]
+
+RFC 5422 Dynamic Provisioning Using EAP-FAST March 2009
+
+
+Authors' Addresses
+
+ Nancy Cam-Winget
+ Cisco Systems
+ 3625 Cisco Way
+ San Jose, CA 95134
+ US
+
+ EMail: ncamwing@cisco.com
+
+
+ David McGrew
+ Cisco Systems
+ 3625 Cisco Way
+ San Jose, CA 95134
+ US
+
+ EMail: mcgrew@cisco.com
+
+
+ Joseph Salowey
+ Cisco Systems
+ 2901 3rd Ave
+ Seattle, WA 98121
+ US
+
+ EMail: jsalowey@cisco.com
+
+
+ Hao Zhou
+ Cisco Systems
+ 4125 Highlander Parkway
+ Richfield, OH 44286
+ US
+
+ EMail: hzhou@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cam-Winget, et al. Informational [Page 39]
+