[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5422

Network Working Group                                      N. Cam-Winget
Internet-Draft                                                 D. McGrew
Intended status: Informational                                J. Salowey
Expires: May 4, 2009                                             H. Zhou
                                                           Cisco Systems
                                                        October 31, 2008


Dynamic Provisioning using Flexible Authentication via Secure Tunneling
             Extensible Authentication Protocol (EAP-FAST)
               draft-cam-winget-eap-fast-provisioning-10

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 4, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).











Cam-Winget, et al.         Expires May 4, 2009                  [Page 1]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


Abstract

   The flexible authentication via secure tunneling EAP method (EAP-
   FAST) 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  . . . . . . . . . . . . . . . . .  6

   3.  Dynamic Provisioning using EAP-FAST Conversation . . . . . . .  8
     3.1.  Phase 1 TLS tunnel . . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  Server-Authenticated Phase 1 . . . . . . . . . . . . .  8
       3.1.2.  Server-Unauthenticated Phase 1 . . . . . . . . . . . .  8
     3.2.  Phase 2 - Tunneled Authentication and Provisioning . . . .  9
       3.2.1.  Server-Authenticated Tunneled Authentication . . . . .  9
       3.2.2.  Server-Unauthenticated Tunneled Authentication . . . . 10
       3.2.3.  Authenticating Using EAP-MSCHAPv2  . . . . . . . . . . 10
       3.2.4.  Use of other Inner EAP Methods for EAP-FAST
               Provisioning . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  Key Derivations Used in the EAP-FAST Provisioning
           Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.4.  Peer-Id, Server-Id and Session-Id  . . . . . . . . . . . . 12
     3.5.  Network Access after EAP-FAST Provisioning . . . . . . . . 12

   4.  Information Provisioned in EAP-FAST  . . . . . . . . . . . . . 14
     4.1.  Protected Access Credential  . . . . . . . . . . . . . . . 14
       4.1.1.  Tunnel PAC . . . . . . . . . . . . . . . . . . . . . . 14
       4.1.2.  Machine Authentication PAC . . . . . . . . . . . . . . 15
       4.1.3.  User Authorization PAC . . . . . . . . . . . . . . . . 15
       4.1.4.  PAC Provisioning . . . . . . . . . . . . . . . . . . . 16
     4.2.  PAC TLV Format . . . . . . . . . . . . . . . . . . . . . . 16
       4.2.1.  Formats for PAC Attributes . . . . . . . . . . . . . . 17
       4.2.2.  PAC-Key  . . . . . . . . . . . . . . . . . . . . . . . 18
       4.2.3.  PAC-Opaque . . . . . . . . . . . . . . . . . . . . . . 19
       4.2.4.  PAC-Info . . . . . . . . . . . . . . . . . . . . . . . 20
       4.2.5.  PAC-Acknowledgement TLV  . . . . . . . . . . . . . . . 22
       4.2.6.  PAC-Type TLV . . . . . . . . . . . . . . . . . . . . . 22
     4.3.  Trusted Server Root Certificate  . . . . . . . . . . . . . 23
       4.3.1.  Server-Trusted-Root TLV  . . . . . . . . . . . . . . . 24



Cam-Winget, et al.         Expires May 4, 2009                  [Page 2]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


       4.3.2.  PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . . 25

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
     6.1.  Provisioning Modes and Man-in-the-middle Attacks . . . . . 28
       6.1.1.  Server-Authenticated Provisioning Mode and
               Man-in-the-middle Attacks  . . . . . . . . . . . . . . 28
       6.1.2.  Server-Unauthenticated Provisioning Mode and
               Man-in-the-middle Attacks  . . . . . . . . . . . . . . 28
     6.2.  Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 30
     6.3.  Considerations in Selecting a Provisioning Mode  . . . . . 31
     6.4.  Diffie-Hellman Groups  . . . . . . . . . . . . . . . . . . 31
     6.5.  Tunnel PAC Usage . . . . . . . . . . . . . . . . . . . . . 31
     6.6.  Machine Authentication PAC Usage . . . . . . . . . . . . . 31
     6.7.  User Authorization PAC Usage . . . . . . . . . . . . . . . 32
     6.8.  PAC Storage Considerations . . . . . . . . . . . . . . . . 32
     6.9.  Security Claims  . . . . . . . . . . . . . . . . . . . . . 33

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 35
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 36

   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . . 37
     A.1.  Example 1: Successful Tunnel PAC Provisioning  . . . . . . 37
     A.2.  Example 2: Failed Provisioning . . . . . . . . . . . . . . 38
     A.3.  Example 3: Provisioning a Authentication Server's
           Trusted Root Certificate . . . . . . . . . . . . . . . . . 40

   Appendix B.  Recent Changes  . . . . . . . . . . . . . . . . . . . 42

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
   Intellectual Property and Copyright Statements . . . . . . . . . . 45
















Cam-Winget, et al.         Expires May 4, 2009                  [Page 3]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


1.  Introduction

   EAP-FAST [RFC4851] is an EAP method that can be used to mutually
   authenticate 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 [RFC4346] 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 itself as a
      valid peer or server.

   Provisioning

      Providing 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.         Expires May 4, 2009                  [Page 4]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   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.





























Cam-Winget, et al.         Expires May 4, 2009                  [Page 5]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


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 cipher suite 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, however it requires provisioning the peer with
   credentials necessary to authenticate the server.  Environments
   willing to trade off the security risk of a man-in-the-middle 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.



Cam-Winget, et al.         Expires May 4, 2009                  [Page 6]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   Once the EAP-FAST Provisioning conversation completes, the peer is
   expected to use the provisioned credentials in subsequent EAP-FAST
   authentications.
















































Cam-Winget, et al.         Expires May 4, 2009                  [Page 7]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


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-MSCHAPv2, 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 MSK and EMSK are
   derived from a combination of the tunnel key material and key
   material from the inner EAP method exchange.

3.1.  Phase 1 TLS tunnel

3.1.1.  Server-Authenticated Phase 1

   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 [RFC4346]:

      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 Phase 1

   Implementations supporting this version of the Sever-Unauthenticated
   Provisioning Mode MUST support the following TLS ciphersuites defined
   in [RFC4346]:

      TLS_DH_anon_WITH_AES_128_CBC_SHA

   Anonymous cipher suites SHOULD NOT be allowed outside of EAP-FAST



Cam-Winget, et al.         Expires May 4, 2009                  [Page 8]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   Server-Unauthenticated Provisioning Mode.  Any cipher suites that are
   used for Server-Unauthenticated Provisioning Mode MUST provide key
   agreement contributed by both parties.  Therefore, cipher suites
   based on RSA key transport MUST NOT be used for this mode.  Cipher
   suites 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 provides a check on
   the integrity of the tunnel with respect to the endpoints of the EAP
   method.  If the preceding is successful than 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 provision
   TLVs MAY be piggybacked on the Result TLV, following 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 to refresh 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.






Cam-Winget, et al.         Expires May 4, 2009                  [Page 9]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


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-MSCHAPv2 [EAP-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-MSCHAPv2

   Implementations of this version of the EAP-FAST Server-
   Unauthenticated Provisioning Mode MUST support EAP-MSCHAPv2
   [EAP-MSCHAPv2] as the inner authentication method.  While other
   authentication methods exist, EAP-MSCHAPv2 was chosen for several
   reasons:

   o  Provide the ability of slowing an active attack by using a hash
      based challenge-response protocol.

   o  The use of a challenge response protocol such as MSCHAPv2 provides
      some ability to detect a man-in-the-middle attack during Server-
      Unauthenticated Provisioning Mode.

   o  A large deployed base is already able to support MSCHAPv2.

   o  It allows support for password change during the EAP-FAST
      provisioning modes.

   When using an anonymous Diffie-Hellman key agreement and EAP-
   MSCHAPv2, the challenges MUST be generated as defined in Section 3.3.
   This forms a binding between the tunnel and the EAP-MSCHAPv2
   exchanges by using keying material generated during the EAP-FAST
   tunnel establishment as the EAP-MSCHAPv2 challenges instead of using
   the challenges exchanged within the protocol itself.  When EAP-
   MSCHAPv2 is used within tunnel established using a cipher suite other
   than one that provides anonymous key agreement the randomly generated
   MSCHAPv2 challenges MUST be used.

   The MSCHAPv2 [RFC2759] 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 spoofing
   the server, by requiring the attacker to successfully break the
   password within the peer's challenge response time limit.






Cam-Winget, et al.         Expires May 4, 2009                 [Page 10]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


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-GTC
   [I-D.zhou-emu-fast-gtc] MAY be used.  This will enable peers using
   other authentication mechanisms such as password database and one-
   time passwords to be provisioned in-band as well.  This version of
   the EAP-FAST provisioning mode implementation MUST support both EAP-
   GTC and EAP-MSCHAPv2 within the tunnel in Server-Authenticated
   Provisioning Mode.

   It should be noted that Server-Authenticated Provisioning Mode
   provides significant security advantages over Server-Unauthenticated
   Provisioning Mode even when EAP-MSCHAPv2 is being used as the inner
   method.  It protects the EAP-MSCHAPv2 exchanges from potential active
   MitM attacks by verifying server's authenticity before exchanging
   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 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-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]



Cam-Winget, et al.         Expires May 4, 2009                 [Page 11]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


             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]

   and the key_block for TLS 1.1 [RFC4346] 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]

   The extra key material, session_key_seed is used for the EAP-FAST
   Crypto-Binding TLV exchange while the ServerChallenge and
   ClientChallenge correspond to the authentication server's MSCHAPv2
   challenge and the peer's MSCHAPv2 challenge respectively.  The
   ServerChallenge and ClientChallenge are only used for the MSCHAPv2
   exchange when 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 does not change the general EAP-
   FAST protocol and thus how the Peer-Id, Server-Id and Session-Id are
   determined is based on the [RFC4851] techniques.

   [RFC4851] Section 3.4 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 server policy.  For example, in the Server-
   Authenticated Provisioning Mode, access can be granted after the EAP
   server has authenticated the peer and provisioned the peer with a
   Tunnel PAC (i.e. a PAC used to mutually authenticate and establish
   the EAP-FAST tunnel).  Additionally, peer policy MAY instruct the
   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



Cam-Winget, et al.         Expires May 4, 2009                 [Page 12]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   access is authorized.  The server MAY grant access at the end of a
   successful Server-Authenticated provisioning exchange.

   If after successful provisioning access to the network is denied, the
   EAP Server SHOULD conclude with an EAP Failure.  The EAP Server SHALL
   NOT grant network access or distribute any session keys to the NAS if
   this exchange is not intended to provide network access.  Even though
   provisioning mode completes with a successful inner termination (e.g.
   successful Result TLV), server policy defines whether the peer gains
   network access or not.  Thus, it is feasible for the server, while
   providing a successful Result TLV may conclude 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.

























Cam-Winget, et al.         Expires May 4, 2009                 [Page 13]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


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 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 minimum, either the peer or server must prove authenticity before
   credentials are provisioned to ensure that information is not freely
   provisioned to or by adversaries.  For example, the EAP server may
   not need to authenticate the peer to provision the peer with trusted
   root certificates.  However, the peer SHOULD authenticate the server
   before it can accept a trusted server root certificate.

4.1.  Protected Access Credential

   A Protected Access Credential (PAC) is a security credential
   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.

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) which 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



Cam-Winget, et al.         Expires May 4, 2009                 [Page 14]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   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.  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.  It is presented within the
   protected EAP-FAST TLS tunnel to provide user information during
   stateless session 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



Cam-Winget, et al.         Expires May 4, 2009                 [Page 15]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   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 they want 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 unknown type, it MUST
   ignore it.

   A PAC-TLV containing PAC-Acknowledge Attribute MUST be sent by peer
   to acknowledge the receipt of the Tunnel PAC.  PAC-Acknowledge TLV
   MUST NOT be used from 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:





Cam-Winget, et al.         Expires May 4, 2009                 [Page 16]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   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 length of the PAC Attributes field in
             octets

        PAC Attributes

             A list of PAC attributes in the TLV format

4.2.1.  Formats for PAC Attributes

   Each PAC Attribute in a PAC TLV is formatted as a TLV defined as
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Cam-Winget, et al.         Expires May 4, 2009                 [Page 17]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


        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 32 octets in length.  The key is represented as an octet
   string.  The generator of this key is the issuer of the credential,
   identified by the A-ID.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                              Key                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Cam-Winget, et al.         Expires May 4, 2009                 [Page 18]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008




      Type

         1 - PAC-Key

      Length

         2 octet length indicating a 32 octet long 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.

   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 A-ID.  This requirement
   allows the peer to maintain and use each opaque data as an
   independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque
   identified by the A-ID.  As there is a one to one correspondence
   between PAC-Key and PAC-Opaque, the peer 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 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Cam-Winget, et al.         Expires May 4, 2009                 [Page 19]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


      Type

         2 - PAC-Opaque

      Length

         The Length filed is two octets, which contains the length of
         the value field in octets

      Value

         The value field contains the actual data for PAC-Opaque.  It is
         specific to the server implementation.

4.2.4.  PAC-Info

   PAC-Info is comprised of a set of PAC attributes as defined in
   Section 4.2.1.  The PAC-Info attribute MUST contain the A-ID, A-ID-
   Info, and PAC-Type attributes.  Other attributes MAY be included in
   the PAC-Info to provide more information to the peer.  The PAC-Info
   attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, PAC-Info
   or PAC-Opaque attributes.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Attributes...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Type

         9 - PAC-Info

      Length

         Two octet length field containing the length of the Attributes
         field in octets

      Attributes

         The Attributes field contains a list of PAC Attributes Each
         mandatory and optional field type is defined as follows:





Cam-Winget, et al.         Expires May 4, 2009                 [Page 20]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


         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 PAC-
            Info.

         4 - A-ID

            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 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 inner EAP
            method, then I-ID MUST be included in PAC-Info, to enable
            the peer to also enforce a unique PAC for each unique user.
            If I-ID is missing from the PAC-Info, it is assumed that the
            Tunnel PAC can be used for multiple users and 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



Cam-Winget, et al.         Expires May 4, 2009                 [Page 21]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


            end-user about the A-ID.  The name is encoded as UTF-8
            [RFC3629] format.  This attribute MUST be included in the
            PAC-Info.

         10 - PAC-type

            PAC-Type is intended to provide the type of PAC.  This
            attribute SHOULD be included in the PAC-Info.  If PAC-Type
            is not present, then it defaults to a Tunnel PAC (Type 1).

4.2.5.  PAC-Acknowledgement TLV

   The PAC-Acknowledgement is used to acknowledge the receipt of the
   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.

      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.



Cam-Winget, et al.         Expires May 4, 2009                 [Page 22]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


    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

         Two Octet length field with a value of 2

      PAC Type

         This two octet field defined the type of PAC being requested or
         provisioned.  The following values are defined:

            1 - Tunnel PAC
            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
   cannot be responded to with a 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 from the EAP server.  The EAP
   server MAY send one or more root certificates with a PKCS#7 TLV
   inside Server-Trusted-Root TLV.  The EAP server MAY also choose not
   to honor the request.  Please see Section Appendix A.3 for an example
   of a server provisioning a server trusted root certificate.






Cam-Winget, et al.         Expires May 4, 2009                 [Page 23]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


4.3.1.  Server-Trusted-Root TLV

   The Server-Trusted-Root TLV allows the peer to send a request to the
   EAP server for a list of trusted roots.  The server may respond with
   one or more root certificates in PKCS#7 [RFC2315] format.

   If the EAP server sets credential format to PKCS#7-Server-
   Certificate-Root, then the Server-Trusted-Root TLV should contain the
   root of the certificate chain of the certificate issued to the EAP
   server packaged in a PKCS#7 TLV.  If the Server certificate is a
   self-signed certificate, then the root is the self-signed
   certificate.

   If the Server-Trusted-Root TLV credential format contains a value
   unknown to the peer, then the EAP peer should ignore the TLV.

   The Server-Trusted-Root TLV is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Credential-Format   |     Cred TLVs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



        M

             0 - Non-mandatory TLV

        R

             Reserved, set to zero (0)

        TLV Type

             18 - Server-Trusted-Root TLV [RFC4851]

        Length

             >=2 octets

        Credential-Format

             The Credential-Format field is two octets.  Values include:




Cam-Winget, et al.         Expires May 4, 2009                 [Page 24]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


                  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 [RFC2315] wrapped 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 peer MUST ignore the TLV.

   The PKCS#7 TLV is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PKCS #7 Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



      M

         0 - Optional TLV

      R

         Reserved, set to zero (0)






Cam-Winget, et al.         Expires May 4, 2009                 [Page 25]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


      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.







































Cam-Winget, et al.         Expires May 4, 2009                 [Page 26]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


5.  IANA Considerations

   This section explains the criteria to be used by the IANA for
   assignment of Type value in PAC attribute, PAC Type value in PAC-
   Type TLV, Credential-Format value in Server-Trusted-Root TLV.  The
   "Specification Required" policy is used here with the meaning defined
   in BCP 26 [RFC5226].

   A registry of values, named "EAP-FAST PAC Attribute Types", is needed
   for the PAC Attribute types.  The initial values to populate the
   registry are:


      1 - PAC-Key
      2 - PAC-Opaque
      3 - PAC-Lifetime
      4 - A-ID
      5 - I-ID
      6 - Reserved
      7 - A-ID-Info
      8 - PAC-Acknowledgement
      9 - PAC-Info
      10 - PAC-Type

   Values from 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", is needed for PAC-
   Type values used in the PAC-Type TLV.  The initial values to 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", is needed for Credential-Format values used in Server-
   Trusted-Root TLV.  The initial values to populate the registry are:

      1 - PKCS#7-Server-Certificate-Root

   Values from 2 to 63 are allocated for management by Cisco.  Values 64
   to 255 are assigned with a "Specification Required" policy.




Cam-Winget, et al.         Expires May 4, 2009                 [Page 27]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


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

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



Cam-Winget, et al.         Expires May 4, 2009                 [Page 28]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   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 themselves 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 MSCHAPv2 used with an anonymous Diffie-Hellman
      ciphersuite the challenges for the MSCHAPv2 exchange are derived
      from the TLS handshake and are not transmitted within the MSCHAPv2
      exchange.  Since the man-in-the-middle does not know these
      challenges it cannot successfully impersonate the server without
      cracking the 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:

      This makes use of the cryptographic binding exchange defined
      within EAP-FAST to discover the presence of a man-in-the-middle by
      binding secret information obtained from the phase 2 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 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 enforces that the
   adversary successfully respond with a valid challenge response.

   The cipher suite 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.
   Cipher suites that use RSA key transport do not meet this
   requirement.  The authenticated and anonymous ephemeral Diffie-
   Hellman cipher suites provide this type of key agreement.

   This document specifies MSCHAPv2 as the inner authentication
   exchange, however it is possible that other inner authentications
   mechanisms to authenticate the tunnel may be developed in the future.
   Since the strength of the man-in-the-middle protection is directly



Cam-Winget, et al.         Expires May 4, 2009                 [Page 29]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   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 MSCHAPv2.  Cleartext passwords MUST NOT be used in Server-
   Unauthenticated Provisioning Mode.  Note that an active man-in-the-
   middle 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.

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 offline 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.

   In offline dictionary attacks the attacker captures information which
   can be processed offline 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 logs these
   events and, if possible, provide warnings to the user.
   Implementations are also encouraged to provide controls that limit
   how and where Server-Unauthenticated Provisioning Mode can be
   performed that are appropriate to their environment.  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.







Cam-Winget, et al.         Expires May 4, 2009                 [Page 30]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


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 it
   is expected for user authentication to be carried out in phase 2 of
   EAP-FAST.  The EAP-FAST Tunnel PAC MAY contain information about the
   identity of a peer to prevent a particular Tunnel PAC from being used
   to establish a tunnel which can perform phase 2 authenticate 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.






Cam-Winget, et al.         Expires May 4, 2009                 [Page 31]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


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 store securely both the PAC-Key and PAC-Opaque, while
   the server must secure storage of its security association context
   used to consume the PAC-Opaque.  Additionally, if alternate
   provisioning is employed, the transportation mechanism used to
   distribute the PAC must also be secured.

   Most of the attacks described here would require some level of effort
   to execute; conceivably greater than their value.  The main focus
   therefore, should be to ensure that proper protections are used on
   both the peer and server.  There are a number of potential attacks
   which can be considered against secure key storage such as:

   o  Weak Passphrases

      On the peer side, keys are usually protected by a passphrase.  On
      some environments, this passphrase may be associated with the
      user's password.  In either case, if an attacker can obtain the
      encrypted key for a range of users, he may be able to successfully
      attack a weak passphrase.  The tools are already in place today to
      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 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



Cam-Winget, et al.         Expires May 4, 2009                 [Page 32]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


      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.

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 offline dictionary attack since it is possible for a
   man-in-the-middle to capture the beginning of the inner MSCHAPv2
   conversation.  However as noted previously it is possible to detect
   the man-in-the-middle.






















Cam-Winget, et al.         Expires May 4, 2009                 [Page 33]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


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.











































Cam-Winget, et al.         Expires May 4, 2009                 [Page 34]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


8.  References

8.1.  Normative References

   [EAP-MSCHAPv2]
              Microsoft Developer Network (MSDN), "[MS-CHAP]: Extensible
              Authentication Protocol Method for Microsoft Challenge
              Handshake Authentication Protocol (CHAP) Specification",
              January 2008.

              http://msdn2.microsoft.com/en-us/library/cc224612.aspx

   [I-D.zhou-emu-fast-gtc]
              Cam-Winget, N. and H. Zhou, "Basic Password Exchange
              within the Flexible Authentication via Secure  Tunneling
              Extensible Authentication Protocol (EAP-FAST)",
              draft-zhou-emu-fast-gtc-04 (work in progress), July 2008.

   [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.

   [RFC2759]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
              RFC 2759, January 2000.

   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, May 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.




Cam-Winget, et al.         Expires May 4, 2009                 [Page 35]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   [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.

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.         Expires May 4, 2009                 [Page 36]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


Appendix A.  Examples

A.1.  Example 1: Successful Tunnel PAC Provisioning

   The following exchanges show anonymous DH with a successful EAP-
   MSCHAPv2 exchange within Phase 2 to provision a Tunnel PAC, the
   conversation will appear as follows:

          Authenticating Peer     Authenticator
          -------------------     -------------
                                  <- EAP-Request/Identity
          EAP-Response/
          Identity (MyID1) ->
                                  <- EAP-Request/EAP-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 to the TLS Finished as
            Application Data and protected by the TLS tunnel

          EAP Payload TLV
          (EAP-Response/Identity) ->

                                 <-  EAP Payload TLV
                                     (EAP-Request/EAP-MSCHAPV2



Cam-Winget, et al.         Expires May 4, 2009                 [Page 37]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


                                      (Challenge))

          EAP Payload TLV
          (EAP-Response/EAP-MSCHAPV2
           (Response)) ->

                                 <-  EAP Payload TLV
                                     (EAP-Request/EAP-MSCHAPV2)
                                     (Success))
          EAP Payload TLV
          (EAP-Response/EAP-MSCHAPV2
           (Success)) ->
                                  <- Intermediate Result TLV(Success)
                                     Crypto-Binding-TLV (Version=1,
                                     EAP-FAST Version=1, Nonce,
                                     CompoundMAC)

          Intermediate Result TLV (Success)
          Crypto-Binding-TLV (Version=1,
          EAP-FAST Version=1, Nonce,
          CompoundMAC)
          PAC-TLV (Type=1)
                                  <- Result TLV (Success)
                                     PAC TLV

          Result TLV (Success)
          PAC Acknowledgment ->

          TLS channel torn down
          (messages sent in cleartext)

                                  <- EAP-Failure

A.2.  Example 2: Failed Provisioning

   The following exchanges show a failed EAP-MSCHAPV2 exchange within
   Phase 2, where the peer failed to authenticate the Server.  The
   conversation will appear as follows:

        Authenticating Peer     Authenticator
        -------------------     -------------
                                <- EAP-Request/Identity
        EAP-Response/
        Identity (MyID1) ->
                                <- EAP-Request/EAP-FAST
                                   (s=1, A-ID)

        EAP-Response/EAP-FAST



Cam-Winget, et al.         Expires May 4, 2009                 [Page 38]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


        (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 to the TLS Finished as
          Application Data and protected by the TLS tunnel


        EAP Payload TLV
        (EAP-Response/Identity)->

                               <-  EAP Payload TLV
                                  (EAP-Request/EAP-MSCHAPV2
                                    (Challenge))

        EAP Payload TLV
        (EAP-Response/EAP-MSCHAPV2
         (Response)) ->

                               <-  EAP Payload TLV
                                   (EAP-Request EAP-MSCHAPV2
                                    (Success))

        // peer failed to verify server MSCHAPv2 response
        EAP Payload TLV
        (EAP-Response/EAP-MSCHAPV2
         (Failure)) ->

                               <-  Result TLV (Failure)




Cam-Winget, et al.         Expires May 4, 2009                 [Page 39]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


        Result TLV (Failure) ->
        TLS channel torn down
        (messages sent in cleartext)

                                <- EAP-Failure

A.3.  Example 3: Provisioning a Authentication Server's Trusted Root
      Certificate

   The following exchanges show a successful provisioning of a server
   trusted root certificate using anonymous DH and EAP-MSCHAPV2 exchange
   within Phase 2, the conversation will appear as follows:

      Authenticating Peer     Authenticator
      -------------------     -------------
                              <- EAP-Request/
                              Identity
      EAP-Response/
      Identity (MyID1) ->
                              <- EAP-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 to the TLS Finished as
         Application Data and protected by the TLS tunnel

      EAP-Payload TLV



Cam-Winget, et al.         Expires May 4, 2009                 [Page 40]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


      (EAP-Response/Identity) ->

                              <- EAP Payload TLV
                                 (EAP-Request/EAP-MSCHAPV2
                                 (Challenge))

      EAP Payload TLV
      (EAP-Response/EAP-MSCHAPV2
       (Response)) ->

                             <-  EAP Payload TLV
                                 (EAP-Request/EAP-MSCHAPV2
                                  (success))

      EAP Payload TLV
      (EAP-Response/EAP-MSCHAPV2
       (Success) ->

                              <- Intermediate Result TLV(Success)
                                 Crypto-Binding TLV (Version=1,
                                 EAP-FAST Version=1, Nonce,
                                 CompoundMAC),

      Intermediate Result TLV(Success)
      Crypto-Binding TLV (Version=1
      EAP-FAST Version=1, Nonce,
      CompoundMAC)
      Server-Trusted-Root TLV
      (Type = PKCS#7) ->
                              <- Result TLV (Success)
                                 Server-Trusted-Root TLV
                                 (PKCS#7 TLV)

      Result TLV (Success) ->

      // TLS channel torn down
         (messages sent in cleartext)

                              <- EAP-Failure












Cam-Winget, et al.         Expires May 4, 2009                 [Page 41]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


Appendix B.  Recent Changes

   changes in -07

   o  Added definition for User Authorization PAC and Machine
      Authentication PAC

   o  Added sections for User Authorization PAC (4.1.3) and Machine
      Authentication PAC (4.1.2).

   o  Added security considerations for new types of PACs

   o  Added recommendation for 16 octet A-ID

   changes in -08

   o  Clarified that Server-Unauthenticated provisioning mode uses
      anonymous TLS ciphersuites

   o  Editorial corrections

   changes in -09

   o  Added text to section 3 to provide an overview of the provisioning
      process

   changes in -10

   o  Clarified that user authorization PAC is not associated with a
      key.

   o  Removed conflicting SHOULD requirement for inner method
      authentication.

   o  In section 3.1.1 change cert validation to MUST.

   o  Clarified that RSA ciphersuites MUST NOT be used with anonymous
      mode.

   o  In section 3.2 added requirement for TLV order.

   o  Clarified that the modified MSCHAPv2 is only used for
      provisioning.

   o  Fixed TLS key block derivation

   o  In section 3.5, made TLS renegotiation the optional method for
      continuing authentication after provisioning



Cam-Winget, et al.         Expires May 4, 2009                 [Page 42]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


   o  define A-ID as opaque and included recommendations for generation

   o  defined I-ID as derived from the inner EAP method

   o  added details to PKCS encoding of certs

   o  updated IANA considerations section

   o  tightened specification to require 2048 DH group










































Cam-Winget, et al.         Expires May 4, 2009                 [Page 43]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


Authors' Addresses

   Nancy Cam-Winget
   Cisco Systems
   3625 Cisco Way
   San Jose, CA  95134
   US

   Email: ncamwing@cisco.com


   David McGrew
   Cisco Systems
   San Jose, CA  95134
   US

   Email: mcgrew@cisco.com


   Joseph Salowey
   Cisco Systems
   2901 3rd Ave
   Seattle, WA  98121
   US

   Email: jsalowey@cisco.com


   Hao Zhou
   Cisco Systems
   4125 Highlander Parkway
   Richfield, OH  44286
   US

   Email: hzhou@cisco.com
















Cam-Winget, et al.         Expires May 4, 2009                 [Page 44]

Internet-Draft     Dynamic Provisioning using EAP-FAST      October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Cam-Winget, et al.         Expires May 4, 2009                 [Page 45]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/