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

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

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   Network Working Group                                  N. Cam-Winget
   Internet Draft                                             D. McGrew
   Category: Informational                                   J. Salowey
   Expires: July 11, 2007                                       H. Zhou
                                                          Cisco Systems
                                                       January 11, 2007


                    Dynamic Provisioning using EAP-FAST
              draft-cam-winget-eap-fast-provisioning-03.txt



Status of this Memo

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

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

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

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

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


Copyright Notice

   Copyright (C) The Internet Society (2007). All Rights Reserved.






Cam-Winget, et al.      Expires July 11, 2007                [Page 1]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007




Abstract

   EAP-FAST is an flexible EAP method that enables secure
   communication between a client and a server by using the Transport
   Layer Security (TLS) to establish a mutually authenticated tunnel.
   EAP-FAST also enables the provisioning credentials or other
   information thru this protected tunnel. This document describes the
   use of EAP-FAST for dynamic provisioning.


Table of Contents

   1. Introduction...................................................3
      1.1.   Specification Requirements.............................3
      1.2.   Terminology............................................3
   2. EAP-FAST Provisioning Modes....................................4
   3. Dynamic Provisioning using EAP-FAST Conversation...............5
      3.1 Network Access after EAP-FAST Provisioning.................7
      3.2 Authenticating Using EAP-MSCHAPv2..........................8
      3.3 Use of other Inner EAP Methods for EAP-FAST Provisioning...9
      3.4 Key Derivations Used in the EAP-FAST Provisioning Exchange10
      3.5 Peer-Id, Server-Id and Session-Id.........................11
      3.6 Provisioning or Refreshment of a PAC......................11
   4. Information Provisioned in EAP-FAST...........................12
      4.1 Protected Access Credential...............................12
      4.2 Provisioning PACs through PAC TLV.........................13
         4.2.1 Formats for PAC TLV Attributes ......................14
         4.2.2 PAC-Key .............................................15
         4.2.3 PAC-Opaque ..........................................16
         4.2.4 PAC-Info ............................................17
         4.2.5 PAC-Acknowledgement TLV..............................19
         4.2.6 PAC-Type TLV.........................................20
      4.3 Server Trusted Root Certificate...........................20
         4.3.1 Server-Trusted-Root TLV .............................21
         4.3.2 PKCS #7 TLV .........................................22
   5. Security Considerations.......................................24
      5.1 User Identity Protection and Validation...................24
      5.2 Mitigation of Dictionary Attacks..........................24
      5.3 Mitigation of Man-in-the-middle (MitM) attacks in server-
      unauthenticated provisioning mode.............................26
      5.4 Mitigation of Man-in-the-middle (MitM) attacks in server-
      authenticated provisioning mode...............................27


Cam-Winget, et al.      Expires July 11, 2007                [Page 2]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


      5.5 Generation of Diffie-Hellman Groups.......................27
      5.6 PAC Storage Considerations................................28
      5.7 Security Claims...........................................29
   6. IANA Considerations...........................................31
   7. References....................................................31
      7.1 Normative.................................................31
      7.2 Informative...............................................32
   8. Acknowledgments...............................................32
   9. Author's Addresses............................................32
   10. Appendix: Examples...........................................33
      10.1 Example 1: Successful Tunnel PAC Provisioning............33
      10.2 Example 2: Failed Provisioning...........................35
      10.3 Example 3: Provisioning a Authentication Server's Trusted
      Root Certificate..............................................37
   11. Intellectual Property Statement..............................39
   12. Disclaimer of Validity.......................................39
   13. Copyright Statement..........................................39
   14. Expiration Date..............................................40

1.
  Introduction

   [EAP-FAST] is an EAP method that can be used to mutually authenticate
   peer and server. However, to mutually authenticate with EAP-FAST,
   credentials such as a preshared key, trusted anchor or a Protected
   Access Credential (PAC) MUST be provisioned to the peer before it can
   establish a secure communication channel with the server. In some
   cases, the provisioning of such information present deployment
   hurdles.  Through the use of the protected tunnel, EAP-FAST can also
   be used to enable the means for dynamic 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 in this document comes from [RFC3748].
   Additional terms are defined below:



Cam-Winget, et al.      Expires July 11, 2007                [Page 3]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007



   Man in the Middle (MitM)
     An adversary that can successfully inject itself between a peer and
     EAP server. The MitM succeeds by impersonating itself as a valid
     peer, authenticator or authentication server.


   Provisioning
     Providing peer with a trust anchor, shared secret or other
     appropriate information based on which a security association can
     be established.

   Protected Access Credential (PAC)
     Credentials distributed to a peer for future optimized network
     authentication.  The PAC consists of at most three components:  a
     shared secret, an opaque element and optionally other information.
     The shared secret part contains the pre-shared key between the peer
     and authentication server.  The opaque part is provided to the peer
     and is presented to the authentication server when the peer wishes
     to obtain access to network resources.  Finally, a PAC may
     optionally include other information that may be useful to the
     peer.

   Tunnel PAC
     A set of credentials stored by the peer and consumed by both the
     peer and the server to establish a TLS tunnel.



2.
   EAP-FAST Provisioning Modes

   EAP-FAST supports two modes for provisioning:

     1) Server-Authenticated Mode: Provisioning inside a server-
        authenticated TLS tunnel.

     2) Server-Unauthenticated Mode: Provisioning inside a server-
        unauthenticated TLS tunnel.

   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 be needed
   inside the tunnel for the EAP Server to authenticate the peer before
   any information can be provisioned.


Cam-Winget, et al.      Expires July 11, 2007                [Page 4]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007



   In the Server-Unauthenticated Provisioning mode, an unauthenticated
   TLS tunnel is established in the EAP-FAST Phase 1 where the server is
   not authenticated.  This provisioning mode is defined to enable
   bootstrapping or initial configuration of peers where the peer lacks
   strong credentials (if any) to mutually authenticate with the server
   and configuration of such credentials through out-of-band mechanisms
   are prohibitive.

   In the Server-Unauthenticated Provisioning mode, the peer and server
   do not achieve mutual authentication during EAP-FAST Phase 1.  It is
   expected that the peer negotiates TLS_DH_anon based cipher suites to
   signal that it can not provide proof of authenticity.  While other
   cipher suites such as those requiring the use of server certificates
   may be used, the peer may lack the necessary trust anchors to
   validate the certificate and authenticate the server.

   Since the server is not authenticated in the Server-Unauthenticated
   Provisioning mode, it is possible that the TLS tunnel may be
   terminated by an attacker. It is strongly recommended that an inner
   EAP method be used to provide some authenticity assurances and MitM
   detection and warning outlined in Section 5 MUST be applied.

   The EAP-FAST Phase 2 conversation is unchanged in either Provisioning
   mode.  However, if the server is not authenticated in Phase 1 the
   peer MUST negotiate an EAP method supporting mutual authentication
   and key derivation that is compatible with its initial or
   bootstrapping credentials (such as a password-based EAP method). The
   peer then uses the Crypto-Binding TLV to validate that the same
   server terminates both the TLS tunnel and the inner EAP method,
   thereby verifying that the exchange was not subject to a man-in-the-
   middle attack. Assuming that the Crypto-Binding TLV exchange is
   successful, the server will subsequently provide the information such
   as a shared key or the trusted root(s) of server
   certificate using a PAC TLV or a Server-Trusted-Root TLV
   respectively.

   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



Cam-Winget, et al.      Expires July 11, 2007                [Page 5]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   The provisioning EAP-FAST exchange uses same sequence as the EAP-FAST
   Authentication Phase 1 to establish a protected TLS tunnel.  Once a
   tunnel is secured between the two parties, the client and server can
   then negotiate and execute an EAP authentication method by which both
   parties can achieve mutual authentication.

   Provisioning in EAP-FAST is negotiated by the client in the first
   communication exchange when EAP-FAST is requested from the server.
   If the client does not have a Protected Access Credential (PAC) or
   requires provisioning of other information (such as the server's
   Trusted Root certificate), it can request to initiate a provisioning
   EAP-FAST exchange and dynamically obtain a PAC or other information
   from the server.

   The EAP-FAST provisioning conversation will typically occur between
   the peer and an authentication server; more specifically, the server
   that can provision the peer with the requested information.

   The conversation between a peer and authentication server commences
   as a normal EAP-FAST exchange as defined in [EAP-FAST]. On receipt of
   the EAP-FAST Start message, the peer determines it must be
   provisioned with a new PAC or server's trusted root certificate.
   This version of the EAP-FAST provisioning mode implementation MUST
   support the following TLS ciphersuites:

         TLS_RSA_WITH_RC4_128_SHA
         TLS_RSA_WITH_AES_128_CBC_SHA
         TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC 3268]
         TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC 3268]

   Other TLS ciphersuites MAY be supported. To provide best security
   practices, it is highly recommended that the peer obtain the server's
   public key or trust anchor to enable server-side authentication.
   However, as the provisioning of the public key or trust anchor must
   also be secured to ensure the public key is to be trusted, some
   deployments may be willing to trade off the security risks for ease
   of deployment and thus use TLS_DH_anon_WITH_AES_128_CBC_SHA that is
   allowed for EAP-FAST provisioning mode only.

   With a successful EAP-FAST Phase 1 tunnel established, subsequent
   messages exchanged between peer and authentication server are
   protected using the negotiated TLS cipher suites as defined by both



Cam-Winget, et al.      Expires July 11, 2007                [Page 6]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   [RFC 2246], [RFC4346] and [RFC 3268] to provide message
   confidentiality and integrity respectively.

   With a protected tunnel, the peer must authenticate itself to the
   server before the server can provision it with information such as a
   PAC.

   Following a successful authentication exchange and successful
   Intermediate Result TLV and Crypto-Binding TLV exchange, the server
   can then provision the peer with a unique PAC.  The provisioning is
   invoked through the a PAC-TLV exchange that is executed following the
   successful authentication exchange including the Intermediate Result
   TLV and Crypto-Binding TLV exchange, with the server distributing the
   information such as a PAC in a corresponding PAC TLV to the peer and
   the peer confirming its receipt in a final PAC TLV Acknowledgement
   message.


3.1
    Network Access after EAP-FAST Provisioning

   Depending on server policy, network access can be granted or denied
   based on the EAP-FAST Provisioning mode, the credential(s) or other
   information that have been provisioned, and the inner EAP methods
   used. For example, in the Server-Authenticated Provisioning Mode,
   access can be granted after the EAP server has authenticated the peer
   and provisioned the peer with a Tunnel PAC (e.g. a PAC used to
   mutually authenticate and establish the EAP-FAST tunnel).


   Additionally, peer policy may also be used to disconnect the current
   provisioning connection and initiate a new EAP-FAST exchange for
   authentication utilizing the newly provisioned information and ensure
   the inner methods are conducted with the trusted server.  The peer
   policy may be required as the peer determines whether it can
   authenticate the EAP Server.  In the case where a peer lacks the
   trust anchors to validate the server's certificate, the peer SHOULD
   negotiate using one of the TLS_DH_anon based cipher suites to signal
   the EAP server that it lacks the trust anchors to authenticate the
   server.

   At the end of the Server-Unauthenticated Provisioning Mode, network
   access SHOULD NOT be granted. EAP server SHOULD conclude with an EAP
   Failure to acknowledge that this conversation was intended for
   provisioning only and thus no network access is authorized. Upon


Cam-Winget, et al.      Expires July 11, 2007                [Page 7]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   completion of the exchange, the EAP Server SHALL NOT grant network
   access or distribute any session keys to the NAS as this phase is not
   intended to provide network access.  Even though provisioning mode
   completes with a successful inner termination (e.g. successful Result
   TLV), server policy defines whether the peer gains network access or
   not.  Thus, it is feasible for the server, while providing a
   successful Result TLV may conclude with an EAP Failure.

   The EAP-FAST server, when denying network access after EAP-FAST
   Provisioning, may choose to instead, immediately invoke another EAP-
   FAST Start and thus initiate the EAP-FAST Phase 1 conversation.  This
   server based implementation policy may be chosen to avoid
   applications such as wireless devices from being disrupted (e.g. in
   802.11 devices, an EAP Failure may trigger a full 802.11
   disassociation) and allow them to smoothly transition to the
   subsequent EAP-FAST authentications to enable network access. As an
   alternative, both the peer and server can initiate TLS renegotiation,
   where the newly provisioned credentials can be used to establish a
   server authenticated or mutually authenticated TLS tunnel for
   authentication. Upon completion of the TLS negotiation and subsequent
   authentication, normal network access policy on EAP-FAST
   authentication can be applied.

   Similarly, if Server-Authenticated Provisioning Mode is used and the
   server policy is to disallow network access, the EAP Server SHALL NOT
   grant network access or distribute any session keys to the NAS as
   this phase is not intended to provide network access.  Even though
   provisioning mode completes with a successful inner termination (e.g.
   successful Result TLV), the EAP-FAST Server-Authenticated
   Provisioning Mode MUST conclude with an EAP Failure to acknowledge
   that this conversation was intended for provisioning only and thus no
   network access is authorized.  The EAP-FAST server may choose to
   instead, immediately invoke another EAP authentication transaction.


3.2
    Authenticating Using EAP-MSCHAPv2

   This version of the EAP-FAST provisioning mode implementation MUST
   support EAP-MSCHAPv2 as the inner authentication method for enabling
   Server-Unauthenticated Provisioning Mode. While other authentication
   methods are allowed and exist to achieve mutual authentication, when
   using an anonymous or unauthenticated TLS tunnel, MSCHAPv2 was chosen
   for several reasons:



Cam-Winget, et al.      Expires July 11, 2007                [Page 8]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


     * Provide the ability of slowing an active attack by obscuring the
     password through some hash

     * Especially in the Server-Unauthenticated EAP-FAST Provisioning
     conversation, MSCHAPv2 provides the ability to detect, based on the
     challenge responses, whether there is a possible attack.

     * It is understood that a large deployed base is already able to
     support MSCHAPv2

     * Allow support for password change during the EAP-FAST
     Provisioning mode.

   The MSCHAPv2 exchange forces the server to provide a valid
   ServerChallengeResponse which must be a function of the server
   challenge, client challenge and password as part of its response.
   This reduces the window of vulnerability in the EAP-FAST for in-band
   provisioning mode to force the man-in-the-middle, acting as the
   server, to successfully break the password within the client's
   challenge response time limit.

   EAP-FAST for provisioning MUST support EAP-MSCHAPv2 as the inner
   method when using an anonymous DH key agreement.  However, with
   support of signed DH key agreement, the provisioning protocol of EAP-
   FAST may support other methods such as EAP-GTC to enable peers (using
   other password databases such as LDAP and OTP) to be provisioned in-
   band as well.  However, the replacement may only be achieved when
   used with cipher suites that enable server side authentication (for
   example, using TLS_DHE_RSA_WITH_AES_128_CBC_SHA) to ensure no loss in
   security.

   When using an anonymous DH key agreement and MSCHAPv2, a binding
   between the tunnel and the MSCHAPv2 exchanges is formed by using
   keying material generated during the EAP-FAST tunnel establishment as
   the MSCHAPv2 challenges.  A detailed description of the challenge
   generation is described in Section 3.4.


3.3
    Use of other Inner EAP Methods for EAP-FAST Provisioning

   Once a protected tunnel is established, the peer must authenticate
   itself to the server before the server can provision the peer. When
   using TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite in the EAP-FAST



Cam-Winget, et al.      Expires July 11, 2007                [Page 9]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   Phase 1 conversation, an EAP method providing both mutual
   authentication and keying material MUST be employed.

   With the use of additional TLS cipher suites, especially when server
   authenticity is verified as part of the TLS tunnel establishment,
   other inner EAP methods with weaker protection than EAP-MSCHAPv2 can
   be used safely inside tunnel. Hence, in addition to EAP-MSCHAPV2 as
   the inner method, EAP-GTC MAY be used in Server-Authenticated
   Provisioning Mode. This will enable peers using other user databases
   such as LDAP and OTP to be provisioned in-band as well.  However, the
   replacement may only be achieved when used with the TLS cipher suites
   that ensure server authentication, such as
   TLS_DHE_RSA_WITH_AES_128_CBC_SHA, to ensure no loss in security.

   This version of the EAP-FAST provisioning mode implementation MUST
   support both EAP-GTC and EAP-MS-CHAPv2 within the tunnel in Server-
   Authenticated Provisioning Mode.

   It should be noted that Server-Authenticated Provisioning Mode
   provides significant security advantages over Server-Unauthenticated
   Provisioning even when EAP-MSCHAPv2 is being used as inner method. It
   protects the EAP-MSCHAPv2 exchanges from potential MitM attacks by
   verifying server's authenticity before exchanging MSCHAPv2. Thus
   Server-Authenticated Provisioning Mode is the preferred provisioning
   mode. The EAP-FAST peer MUST use the Server-Authenticated
   Provisioning Mode whenever a certificate or (server's) public key is
   available to authenticate the server, in order to ensure best
   security practices.






3.4
    Key Derivations Used in the EAP-FAST Provisioning Exchange

   When generating keys in the EAP-FAST Provisioning conversation, the
   DH computation is used as the pre_master_secret and is converted into
   the master_secret as specified by [RFC 2246].

   The TLS tunnel key is calculated similar to the TLS key calculation
   with an extra 72 octets generated. Portions of the extra 72 octets
   are used for the EAP-FAST provisioning exchange session key seed and
   as the random challenges in the MSCHAPv2 exchange.


Cam-Winget, et al.      Expires July 11, 2007               [Page 10]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007



   To generate the key material, compute

          key_block = PRF(master_secret,
                             "key expansion",
                             server_random +
                             client_random);

      until enough output has been generated. Then the key_block is
      partitioned as follows:

          client_write_MAC_secret[hash_size]
          server_write_MAC_secret[hash_size]
          client_write_key[Key_material_length]
          server_write_key[key_material_length]
          client_write_IV[IV_size]
          server_write_IV[IV_size]
          session_key_seed[seed_size= 40]
          MSCHAPv2 ServerChallenge[16]
          MSCHAPv2 ClientChallenge[16]

   The extra key material, session_key_seed is used for the Crypto-
   Binding while the ServerChallenge and ClientChallenge correspond to
   the authentication server's MSCHAPv2 challenge and the peer's
   MSCHAPv2 challenge respectively.  The ServerChallenge and
   ClientChallenge are only used for the MSCHAPv2 exchange when DH
   anonymous key agreement is used in the EAP-FAST tunnel establishment.


3.5
   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 [EAP-FAST] techniques.

   [EAP-FAST] Section 3.4 describes how the Peer-Id and Server-Id are
   determined; Section 3.5 describes how the Session-Id is generated.



3.6
   Provisioning or Refreshment of a PAC

   The server may provision or refresh information by use of the
   Protected Access Credential (PAC) after a successful user


Cam-Winget, et al.      Expires July 11, 2007               [Page 11]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   authentication. A PAC TLV is defined to facilitate the distribution
   and refreshing of information and is defined in Section 4.2.  A fresh
   PAC may be distributed after a successful Intermediate Result TLV and
   Crypto-Binding TLV exchange, if the server detects that the PAC is
   expiring soon.   A successful EAP-FAST inner method authentication,
   including a successful Crypto-Binding exchange must ensue before an
   EAP-FAST server can distribute a fresh PAC.  A PAC TLV should not be
   accepted if it is not TLS tunnel-encapsulated.

   N.B. In-band PAC refreshing is enforced by server policy.  The
   server, based on the PAC-Opaque information, may determine not to
   refresh a peer's PAC through the PAC TLV mechanism even if the PAC-
   Key has expired.


4.
   Information Provisioned in EAP-FAST

   In addition to the Tunnel PAC (the one used to establish the EAP-FAST
   Phase 1 TLS tunnel), other types of credentials and information can
   also be provisioned in EAP-FAST. They may include trusted root
   certificates for the server certificates, application specific PACs,
   and user identities to name a few. Typically, provisioning is invoked
   after both peer and server validate their authenticities and after a
   successful Crypto-Binding TLV exchange. However, depending on the
   information being provisioned, mutual authentication MAY not be
   needed.

   At minimum, at least one entity (peer or server) must prove
   authenticity before credentials are provisioned to ensure that
   information is not freely provisioned to or by adversaries.  For
   example, the EAP server MAY not need to authenticate the peer to
   provision the peer with trusted root certificates. However, the peer
   MUST authenticate the server before it can accept a trusted server
   root certificate.


4.1
    Protected Access Credential

   A Protected Access Credential (PAC) is a security credential provided
   by the Authentication Server (AS) that holds application specific
   information. The server distributes all PAC information through the
   use of a PAC TLV.  Each type of PAC information is typed through a
   PAC Type and PAC TLV Attribute defined in this section.



Cam-Winget, et al.      Expires July 11, 2007               [Page 12]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007




   For instance, a Tunnel PAC holds a shared secret mutually and
   uniquely shared between the peer and AS and is used to secure an EAP-
   FAST (TLS) tunnel.  EAP-FAST uses the Tunnel PAC to facilitate the
   storage of secure information between a peer and a server on the peer
   and minimize the per user state management on the AS.

   The Tunnel PAC is distributed by the server to the peer and used to
   establish a secure EAP-FAST TLS tunnel and convey the server policy
   of what must and can occur in the tunnel. The server policy can
   include EAP methods, TLV exchanges and identities allowed in the
   tunnel. It is up to the server policy to include what's necessary in
   a PAC to enforce the policy in subsequent authentications that use
   the PAC. For example, user identity, I-ID, can be included as the
   part of the server policy. This I-ID information limits the inner
   EAP methods to be carried only on the specified user identity. Other
   types of information can also be included, such as which EAP
   method(s) and which cipher suite is allowed. If the server policy is
   not included in a PAC, then there is no validation or limitation on
   the inner EAP methods or user identities inside the tunnel
   established by the use of that PAC.


   To request provisioning of a Tunnel PAC, a peer MUST send a PAC TLV
   with a PAC-Type PAC TLV with its TLVs field and '1' (Tunnel PAC
   Type).  The request may be issued after the peer has determined that
   it has successfully authenticated the EAP Server and the tunnel and
   inner EAP methods were between the same peer and EAP Server by
   validating the Crypto-Binding TLV. This would differentiate the
   Tunnel PAC request from other types of PAC provisioning requests. If
   anonymous DH is negotiated and the peer does not send any PAC-TLV to
   request provisioning, then Tunnel PAC is provisioned automatically
   by the server. PAC-Acknowledge TLV MUST be used for peer to
   acknowledge the receipt of the Tunnel PAC.


   Please see Section 10.1 for an example of packet exchanges to
   provision a Tunnel PAC.


4.2
   Provisioning PACs through PAC TLV

   The PAC TLV is defined to enable the provisioning of PAC information.


Cam-Winget, et al.      Expires July 11, 2007               [Page 13]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   Additionally, the PAC-Type in PAC TLV MAY be used by the peer to
   request provisioning for specific types of information. Conversely,
   the PAC TLV is used by the server to provision the requested
   information to a peer.

   The PAC TLV provides support for Protected Access Credential (PAC)
   defined within [EAP-FAST].  A consistent PAC format will allow it to
   be used by multiple applications beyond EAP-FAST.  A general PAC TLV
   format is defined as follows:

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

       M

          0 - Non-mandatory TLV
          1 - Mandatory TLV


       R

          Reserved, set to zero (0)

       TLV Type

          11

       Length
            The length of the PAC Attributes field in octets.

       PAC Attributes
            A list of PAC attributes in the TLV format.


4.2.1 Formats for PAC TLV Attributes

   A common encapsulating format is used to convey the different fields
   that comprise a PAC attribute.  The common encapsulation is defined
   as follows:


Cam-Winget, et al.      Expires July 11, 2007               [Page 14]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007



        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
         The Length filed is two octets, which contains the length of
         the Value field in octets.

       Value
         The value of the PAC Attribute.


4.2.2 PAC-Key

   The PAC-Key is distributed as an attribute of type PAC-Key (Type=1).
   The key is a randomly generated octet string.  The key is represented
   as an octet string whose length is determined by the length field.
   The generator of this key is the issuer of the credential, identified
   by the A-ID.




        0                   1                   2                   3


Cam-Winget, et al.      Expires July 11, 2007               [Page 15]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


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

       Type

         1 - PAC-Key

       Length
         The Length filed is two octets. For this version of EAP-FAST,
         PAC-Key is 32 octets.

       Key
         The Key field contains the key used to establish the TLS
         tunnel.



4.2.3  PAC-Opaque

   The PAC-Opaque contains data that is opaque to the recipient, the
   peer is not the intended consumer of PAC-Opaque and thus should not
   attempt to interpret it.  A peer that has been issued a PAC-Opaque by
   a server MUST store that data, and present it back to the server as
   is, in the ClientHello SessionTicket extension field [RFC4507]. If a
   client has opaque data issued to it by multiple servers, then it MUST
   store the data issued by each server separately according to A-ID.
   This requirement allows the client to maintain and use each opaque
   data as an independent PAC pairing, with a PAC-Key mapping to a PAC-
   Opaque identified by the A-ID. As there is a one to one
   correspondence between PAC-Key and PAC-Opaque, the peer must
   determine the PAC-Key and corresponding PAC-Opaque based on the A-ID
   provided in the EAP-FAST/Start message and the A-ID provided in the
   PAC-Info when it was provisioned with a PAC-Opaque.

   As the PAC-Opaque is server specific, its contents and definition are
   specific to the issuer of the PAC, e.g. the PAC server.

   The PAC-Opaque field is embedded as part of the PAC TLV when the


Cam-Winget, et al.      Expires July 11, 2007               [Page 16]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   server has determined that the PAC must be provisioned or refreshed.



   The PAC-Opaque field format is summarized as follows:

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


       Type

         2 - PAC-Opaque

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

       Value
         The Value field contains the actual data for PAC-Opaque.

   The PAC-Opaque field is also passed from the peer to the server
   during the EAP-FAST Authentication Phase 1 conversation to enable
   the server to validate and recreate the PAC-Key.  When it is passed
   from the peer, it is encapsulated as defined above in the
   ClientHello SessionTicket Extension [RFC4507].


4.2.4 PAC-Info

   PAC-Info is comprised of a set of PAC attributes.  At minimum, the
   A-ID, A-ID-Info,  and PAC-Type attribute is required to convey the
   issuing identity to the peer.  Other optional fields may be included
   in the PAC to provide more information to the peer. It is a container
   attribute for various types of information each of which is encoded
   in conformance to the PAC TLV attribute field format as defined in
   Section 4.2.

        0                   1                   2                   3


Cam-Winget, et al.      Expires July 11, 2007               [Page 17]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


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

       Type

         9 - PAC-Info

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

       Attributes
         The Attributes field contains a list of PAC Attributes.

         Each mandatory and optional field type is defined as follows:

         PAC-LIFETIME (type 3)
            This is a 4 octet quantity representing the expiration time
            of the credential in UNIX UTC time.  This is a mandatory
            field contained in the PAC-Opaque field to enable the server
            to validate the PAC.  This field may also be optionally
            provided to the peer as part of PAC-Info.

         A- ID (type 4)
           Authority identifier is the name of the authority that
           issued the PAC.  The A-ID is intended to be unique across
           all issuing servers to avoid namespace collisions.  Server
           implementations should use measures to ensure the A-ID used
           is globally unique to avoid name collisions. The A-ID is
           used by the peer to determine which PAC to employ.
           Similarly, the server uses the A-ID to both authenticate the
           PAC-Opaque and determine which master key was used to issue
           the PAC.  This field is mandatory and included in both the
           PAC-Opaque and PAC-Info.

         I-ID (type 5)
            Initiator identifier (I-ID) is the peer identity associated
            with the credential. The server employs the I-ID in the EAP-
            FAST Phase 2 conversation to validate that the same peer
            identity used to execute EAP-FAST Phase 1 is also used in at


Cam-Winget, et al.      Expires July 11, 2007               [Page 18]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


            minimum one inner EAP method in EAP-FAST Phase 2.  This
            field is a mandatory field in PAC-Opaque and may optionally
            be included in the PAC-Info. If the AS is enforcing the I-ID
            validation on inner EAP method, then I-ID is mandatory in
            PAC-Info, to enable the client to also enforce a unique PAC
            for each unique user. If I-ID is missing from the PAC-Info,
            it is assumed that the Tunnel PAC can be used for multiple
            users and client will not enforce the unique Tunnel PAC per
            user policy.

          A-ID-Info (type 7)
            Authority Identifier Information is a mandatory TLV intended
            to provide a user-friendly name for the A-ID. It may contain
            the enterprise name and server name in a more human-readable
            format. This TLV serves as an aid to the peer to better
            inform the end-user about the A-ID.  This field is a
            mandatory field in the PAC-Info.

         PAC-Type (type 10)
            PAC-Type is a mandatory TLV intended to provide the type of
            PAC. This field is a mandatory field in the PAC-Info. For
            legacy implementations, if PAC-Type is not present, then it
            defaults to a Tunnel PAC (Type 1).


4.2.5  PAC-Acknowledgement TLV

   The PAC-Acknowledgement TLV is used to acknowledge the receipt of the
   Tunnel PAC by the peer. Peer sends this TLV in response to the PAC
   TLV to indicate the result of the retrieving and storing of the new
   Tunnel PAC. This TLV is only used when 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



Cam-Winget, et al.      Expires July 11, 2007               [Page 19]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


       Length
         The length of this field is two octets and value must be 2.

       Result
         The resulting value must be one of the following:

            1 - Success
            2 - Failure


4.2.6 PAC-Type TLV

   The PAC-Type TLV is a TLV intended to specify the PAC type. Its
   format is described below.


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

       Type

         10 - PAC-Type

       Length
         The length of this field is two octets and value must be 2.


       PAC Type
         This two octet field defined the type of PAC being requested or
         provisioned.  Its value must be one of the following:

           1 - Tunnel PAC

4.3
    Server Trusted Root Certificate

   It is desirable to provision the peer with the server's trusted root
   certificates (or CA certificates), which can later be used for
   enabling PKI based cipher suites. Server-Trusted-Root TLV is
   introduced to facilitate the request for and delivery of server


Cam-Winget, et al.      Expires July 11, 2007               [Page 20]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   trusted root certificates. Within the EAP-FAST Phase 2 conversation,
   a peer MAY request for a server's trusted root certificate using a
   Server-Trusted-Root TLV, and the EAP server MAY respond with a
   Server-Trusted-Root TLV containing the trusted root certificate in
   the PCKS#7 TLV to the peer.  The Server-Trusted-Root TLV can be
   exchanged in regular EAP-FAST Authentication mode or Provisioning
   mode.

   After the peer has determined that it has successfully authenticated
   the EAP server and determined that the tunnel and inner EAP methods
   were between the same peer and EAP Server by validating the Crypto-
   Binding TLV, it MAY send one or more Server-Trusted-Root TLVs
   (marked as optional) to request for the certificate trust anchors of
   the server certificate from the EAP server. The EAP server will send
   the trusted root(s) of server certificate after its internal policy
   has been satisfied; or it may ignore the request or request
   additional authentications based on its policy. The peer may receive
   a trusted root of server certificate, but is not required to use it.
   Please see Section 10.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 trusted root in PKCS#7 [RFC2315]format.

   The Server-Trusted-Root TLV is always marked as optional, and cannot
   be responded to with a NAK TLV.

   The Server-Trusted-Root TLV can only be sent as an inner TLV (inside
   the protection of the tunnel).

   The peer MUST NOT request, or accept the trusted root sent inside the
   Server-Trusted-Root-TLV by the EAP server until it has completed
   authentication of the EAP server, and validated the Crypto-Binding
   TLV. The peer may receive a trusted root, but is not required to use
   the trusted root sent from the EAP server.

   If the EAP server sets credential-format to PKCS#7-Server-
   Certificate-Root, then the Server-Trusted-Root TLV MUST 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



Cam-Winget, et al.      Expires July 11, 2007               [Page 21]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   self-signed certificate, then the root is the self-signed
   certificate.

   If the Server-Trusted-Root TLV credential format does not contain one
   of the known values, then the EAP-server MUST 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   |     TLVs...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      M
         0 - Optional TLV

      R
         Reserved, set to zero (0)

      TLV Type
         18

      Length
          >=2

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

         1 - PKCS#7-Server-Certificate-Root.

      TLVs
         This field is of indefinite length.  It contains TLVs
         associated with the certificate request and response.


4.3.2 PKCS #7 TLV



Cam-Winget, et al.      Expires July 11, 2007               [Page 22]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   The PKCS#7 TLV is sent by the EAP server to the peer inside the
   Server-Trusted-Root TLV. It contains the PKCS #7 [RFC2315] wrapped
   X.509 certificate.  This field contains a certificate or certificate
   chain in PKCS#7 format requested by the peer as defined in [RFC2315].

   The PKCS#7 TLV is always marked as optional, which cannot be
   responded to with a NAK TLV.  EAP-FAST server implementations that
   claim to support dynamic provisioning MUST support this TLV.  EAP-
   FAST peer implementations MAY not support this TLV.

   If the PKCS#7 TLV contains a certificate or certificate chain that is
   not acceptable to the peer, then peer MUST ignore the TLV.

   The PKCS#7 TLV is defined as follows:


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

      M
         0 - Optional TLV


      R
         Reserved, set to zero (0)

      TLV Type
         20 (for PKCS #7 TLV)

      Length
         The length of the PKCS #7 Data field

      PKCS #7 Data
         This field contains the PKCS #7 wrapped X.509 certificate or
         certificate chain in the PKCS #7 format.





Cam-Winget, et al.      Expires July 11, 2007               [Page 23]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007




5.
  Security Considerations

   The Dynamic Provisioning EAP-FAST protocol shares the same security
   considerations outlined in [EAP-FAST]. Additionally, it also has its
   unique security considerations described below:

5.1
    User Identity Protection and Validation

   EAP-FAST for provisioning employs the TLS key agreement (as defined
   in the TLS protocol) to establish a protected tunnel; the initial
   EAP-Identity request/response may be omitted as it must be
   transmitted in the clear and thus subject to snooping and forgery.
   Alternately, an
   anonymous identity may be used in the EAP-Identity response to
   prevent disclosure of the peer's true identity.

   As the provisioning EAP-FAST exchange is used for provisioning a PAC
   to a specific identity, e.g. I-ID, it is expected that the server
   will assign the I-ID based on the identity provided in the protected
   inner EAP authentication method.  Thus, the protected identity may
   not be identical to the cleartext identity presented in the initial
   EAP identity exchange messages. In order to shield the user identity
   from snooping, the cleartext Identity may only provide enough
   information to enable routing of the authentication request to the
   correct realm. For example, the peer may initially claim the identity
   of "anonymous@example.com" in order to route the authentication
   request to the example.com EAP server. Subsequently, once the EAP-
   FAST session has been negotiated, in the inner authentication method,
   the peer may claim the identity of "user1@example.com".  Thus, the
   EAP-FAST protocol for provisioning can provide protection for the
   user's identity, though not necessarily the destination realm, unless
   the provisioning EAP-FAST conversation terminates at the local
   authentication server.

5.2
     Mitigation of Dictionary Attacks

   When EAP-FAST is invoked for provisioning, the peer specifies the
   means for securing the communications for the provisioning.  As such,
   it can invoke the TLS key agreement in one of two ways: anonymously
   or server-authenticated.  With a server-authenticated TLS key
   agreement, the server must provide its certificate and be validated



Cam-Winget, et al.      Expires July 11, 2007               [Page 24]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   by the peer, whereas in an anonymous TLS key agreement, there is no
   ability to authenticate the server.

   In a server authenticated TLS key agreement, the protected
   communications is assured that the AS is authentic as the peer must
   have been pre-provisioned with the AS's certificate or public (RSA)
   key prior to the negotiation.  In this instance, the AS provides
   proof of identity through an identity and (certificate) credential,
   preventing an adversary from posing as an AS to mount a dictionary
   attack.   An EAP-FAST compliant implementation must assure that
   provisioning of the AS public key, certificate or root certificate to
   the peer must be achieved through a secure mechanism. Only through a
   secure mechanism can server-authenticated DH key agreement provide
   resistance to dictionary attacks.   While this option affords best
   security practices, it presents deployment issues as, especially for
   wireless clients where there is little means to provide secure
   configuration, peers must be configured with a means to validate the
   server's credential (e.g. public key).

   In an anonymous DH key agreement, an adversary may attempt to
   impersonate a client and enable EAP-FAST for provisioning.  However,
   it must successfully authenticate inside the DH tunnel to succeed and
   gain a PAC credential from a server.  Thus, peer impersonation is
   mitigated through the enabling of peer authentication inside a
   protected tunnel.  However, an adversary may impersonate as a valid
   AS and obtains the MSCHAPv2 exchanges in order to gain peer's
   identity and credentials.   While the adversary must successfully
   gain contact with a peer that is willing to negotiate EAP-FAST for
   provisioning and provide a valid A-ID that a client accepts, this
   occurrence is feasible and enables an adversary to mount a dictionary
   attack. For this reason, an EAP-FAST compliant implementation must
   support an MSCHAPv2 or stronger EAP method for peer authentication
   when an anonymous DH key agreement is used for the tunnel
   establishment.

   With MSCHAPv2, a peer may detect it is under attack when the AS that
   has provided an acceptable Authority ID (A-ID) fails to provide a
   successful MSCHAPv2 server challenge response.  By employing the
   ServerChallenge and ClientChallenge derived during tunnel
   establishment; detection of a MitM is feasible during the MSCHAPv2
   exchange.

   The peer MAY choose to use a more secure out-of-band mechanism for
   PAC provisioning that affords better security than the anonymous DH


Cam-Winget, et al.      Expires July 11, 2007               [Page 25]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   key agreement.  Similarly, the peer MAY find a means of pre-
   provisioning the server's public key securely to invoke the server-
   authenticated DH key agreement.

   The anonymous DH key agreement is presented as a viable option as
   there may be deployments that can physically confine devices during
   the provisioning or are willing to accept the risk of an active
   dictionary attack.   Further, it is the only option that enables zero
   out-of-band provisioning and facilitates simpler deployments
   requiring little to no peer configuration.


5.3
   Mitigation of Man-in-the-middle (MitM) attacks in server-
    unauthenticated provisioning mode

   EAP-FAST invocation of provisioning addresses MitM attacks in server-
   unauthenticated provisioning mode in the following way:

     * Generating MSCHAPv2 server and client challenges as a function
     of the DH key agreement: in enforcing the dependence of the MSCHAP
     challenges on the DH exchange, a MitM is prevented from
     successfully establishing a secure tunnel with both the peer and
     legitimate server and succeed in obtaining the PAC credential.

     * Cryptographic binding of EAP-FAST Phase 1 and the Phase 2
     authentication method:  by cryptographically binding key material
     generated in all phases, both peer and AS are assured that they
     were the sole participants of all transpired phases.

   The binding of the MSCHAPv2 random challenge derivations to the DH
   key agreement protocol enables early detection of a MitM attack.
   This is required to guard from adversaries who may otherwise reflect
   the inner EAP authentication messages between the true peer and AS
   and enforces that the adversary successfully respond with a valid
   challenge response.

   The cryptographic binding is another reassurance that indeed the true
   peer and AS were the two parties ensuing both the tunnel
   establishment and inner EAP authentication conversations.  While it
   would be sufficient to only support the cryptographic binding to
   mitigate the MitM; the extra precaution of binding the MSCHAP
   challenge to the DH key agreement affords the client earlier
   detection of a MitM and further guards the peer from having to
   respond to the success or failure of the adversary's attempt to


Cam-Winget, et al.      Expires July 11, 2007               [Page 26]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   respond with a challenge response (e.g. indication of whether the
   adversary succeeded in breaking the peer's identity and password).

   A failure in either step, results in no PAC provisioning.
   EAP-FAST invocation of provisioning using an unauthenticated tunnel
   can invoke certain procedures to guard implementations for potential
   MitM attacks.  Detectors can be devised to warn the user when the
   peer encounters error conditions that warrant the likelihood of a
   MitM.  For example, when the MSCHAPv2 server challenge response is
   never received or fails, the peer implementation can impose policy
   decisions to warn the user and respond to the likelihood that the
   failure was due to a MitM attack.

   Similarly, to guard against attacks in the EAP-FAST Authentication
   that may force a peer to invoke in-band provisioning, guards and
   detectors can and should be implemented as part of the EAP-FAST
   Authentication protocols.

5.4
   Mitigation of Man-in-the-middle (MitM) attacks in server-
    authenticated provisioning mode


   EAP-FAST provisioning in server-authenticated mode addresses MitM
   attacks by enforcing the server to present a valid certificate as
   part of the TLS negotiation.  To ensure the authenticity of the
   server and address MitM attacks, the peer MUST verify the validity of
   the EAP server certificate to guarantee it is not subject to a MitM
   attack.

   The cryptographic binding is another reassurance that indeed the true
   peer and AS were the two parties communicating in both the tunnel
   establishment and inner EAP authentication conversations.



5.5
    Generation of Diffie-Hellman Groups

   The security of the DH key exchange is based on the difficulty of
   solving the Discrete Logarithm Problem (DLP). As algorithms and
   adversaries become more efficient in their abilities to precompute
   values for a given fixed group, it becomes more important for a
   server to generate new groups as a means to allay this threat.  The
   server could, for instance, constantly compute new groups in the
   background.  Such an example is cited in [SECSH-DH].


Cam-Winget, et al.      Expires July 11, 2007               [Page 27]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007



   Thus, the server can maintain a list of safe primes and corresponding
   generators to choose from.  A prime p is safe, if:
   p = 2q + 1 and q is prime

   New primes may be generated in the background.

   Initial implementations of the EAP-FAST provisioning exchange limit
   the generator to be 2 as it both improves the multiplication
   efficiency and still covers half of the space of possible residues.
   Furthermore, as the server defines the group used for the DH exchange,
   it may restrict the prime size to be 1024 bits.

   Additionally, since the EAP-FAST provisioning exchange employs DH per
   [RFC 3268] to generate AES keys, the DH keys must provide enough
   entropy to ensure that a strong 128bit results from the DH key
   agreement.

   EAP-FAST employs the 2048 bit DH groups defined in [RFC 3526].


5.6
    PAC Storage Considerations

   The main premise behind EAP-FAST is to protect the authentication
   stream over the media link.  However, physical security is still an
   issue.  Some care should be taken to protect the PAC on both the peer
   and server.  The peer must store securely both the PAC-Key and PAC-
   Opaque, while the server must secure storage of its security
   association context used to consume the PAC-Opaque.  Additionally, if
   manual provisioning is employed, the transportation mechanism used to
   distribute the PAC must also be secured.

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


   * weak passphrases
     On the 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


Cam-Winget, et al.      Expires July 11, 2007               [Page 28]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


     encrypted key for a range of users, he may be able to successfully
     attack a weak passphrase.  The tools are already in place today to
     allow an attacker to easily attack all email users in an enterprise
     environment.  Most viruses or worms of this sort attract attention
     to themselves by their action, but that need not be the case.  A
     simple, genuine appearing email could surreptitiously access keys
     from known locations and email them directly to the attacker,
     attracting little notice.

   * key finding attacks
     Key finding attacks are usually mentioned in reference to web
     servers, where the private SSL key may be stored securely, but at
     some point it must be decrypted and stored in system memory.  An
     attacker with access to system memory can actually find the key by
     identifying their mathematical properties.  To date, this attack
     appears to be purely theoretical and primarily acts to argue
     strongly for secure access controls on the server itself to prevent
     such unauthorized code from executing.

   * key duplication , key substitution, key modification
     Once keys are accessible to an attacker on either the client or
     server, they fall under three forms of attack: key duplication, key
     substitution and key modification.  The first option would be the
     most common, allowing the attacker to masquerade as the user in
     question.  The second option could have some use if an attacker
     could implement it on the server.  Alternatively, an attacker could
     use one of the latter two attacks on either the peer or server to
     force a PAC re-key, and take advantage of the MitM/dictionary
     attack weakness of  the EAP-FAST provisioning protocol.

   Another consideration is the use of secure mechanisms afforded by the
   particular device.  For instance, some laptops enable secure key
   storage through a special chip.  It would be worthwhile for
   implementations to explore the use of such a mechanism.

5.7
   Security Claims

   This section provides needed security claim requirement for EAP
   [RFC3748].

   Auth. mechanism:            Certificate based, shared secret based
                               and various tunneled authentication
   mechanisms.
      Ciphersuite negotiation: Yes


Cam-Winget, et al.      Expires July 11, 2007               [Page 29]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


      Mutual authentication:   Yes
      Integrity protection:    Yes, Any method executed within the EAP-
                               FAST tunnel is integrity protected.  The
                               cleartext EAP headers outside the tunnel
                               are not integrity protected.
      Replay protection:       Yes
      Confidentiality:         Yes
      Key derivation:          Yes
      Key strength:            [1]
      Dictionary attack prot.: Yes
      Fast reconnect:          Yes
      Cryptographic binding:   Yes
      Session independence:    Yes
      Fragmentation:           Yes
      Key Hierarchy:           Yes
      Channel binding:         No, but TLVs could be defined for this.

   Notes

      1.  BCP 86 [RFC3766] offers advice on appropriate key sizes.  The
          National Institute for Standards and Technology (NIST) also
          offers advice on appropriate key sizes in [SP800-57].
   [RFC3766]
          Section 5 advises use of the following required RSA or DH
   module
          and DSA subgroup size in bits, for a given level of attack


          resistance in bits.  Based on the table below, a 2048-bit RSA
   key
          is required to provide 128-bit equivalent key strength:

         Attack Resistance     RSA or DH Modulus            DSA subgroup
          (bits)                  size (bits)                size (bits)
         -----------------     -----------------            ------------
           70                         947                        129
           80                        1228                        148
           90                        1553                        167
           100                       1926                        186
           150                       4575                        284
           200                       8719                        383
           250                      14596                        482


Cam-Winget, et al.      Expires July 11, 2007               [Page 30]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007



6.
  IANA Considerations

   This section explains the criteria to be used by the IANA for
   assignment of Type value in PAC TLV 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 [RFC2434].



7.
   References

7.1
    Normative

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

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


   [EAP]      Blunk, L., et. al., "Extensible Authentication Protocol
              (EAP)", RFC 3748, June 2004.

   [RFC3268]  Chown, P., "Advanced Encryption Standard (AES)
              Ciphersuites for Transport Layer Security (TLS)", RFC
              3268, June 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC3546]  Blake-Wilson, S., et al., "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

   [EAP-FAST] Cam-Winget, N., et al., "EAP Flexible Authentication via
              Secure Tunneling (EAP-FAST) ", draft-cam-winget-eap-fast-
              07  (work in progress), January 2007.

   [RFC4507]   Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
                 "Transport Layer Security (TLS) Session Resumption
              without Server-Side State", RFC 4507, May 2006.




Cam-Winget, et al.      Expires July 11, 2007               [Page 31]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


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

   [RFC2315]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax
              Version 1.5", RFC 2315, March 1998.



7.2
    Informative

   [RFC2434]  Narten, T., and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 2434, October
              1998.

   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
              2631, January 1999.

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

   [RFC3766]   Orman, H. and P. Hoffman, "Determining Strengths For
               Public Keys Used For Exchanging Symmetric Keys", BCP 86,
               RFC 3766, April 2004.

   [MITM]      Puthenkulam, J., "The Compound Authentication Binding
              Problem", draft-puthenkulam-eap-binding-04 (expired),
              October 2003.




8.
  Acknowledgments

   The EAP-FAST design and protocol specification is based on the ideas
   and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith,
   Ilan Frenkel and Jeremy Steiglitz.



9.
  Author's Addresses

   Nancy Cam-Winget
   Cisco Systems


Cam-Winget, et al.      Expires July 11, 2007               [Page 32]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


   190 W Tasman Drive
   San Jose, CA 95134
   US
   Phone: +1 408 853 0532
   E-mail: ncamwing@cisco.com

   David McGrew
   Cisco Systems
   San Jose, CA 95134
   US
   E-mail: mcgrew@cisco.com

   Joseph Salowey
   Cisco Systems
   2901 3rd Ave
   Seattle, WA 98121
   US
   Phone: +1 206 256 3380
   E-mail: jsalowey@cisco.com

   Hao Zhou
   Cisco Systems
   4125 Highlander Parkway
   Richfield, OH 44286
   US
   Phone : +1 330 523 2132
   E-mail: hzhou@cisco.com

10.
   Appendix: Examples

10.1
    Example 1: Successful Tunnel PAC Provisioning

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

       Authenticating Peer     Authenticator
       -------------------     -------------
                               <- EAP-Request/
                               Identity
       EAP-Response/
       Identity (MyID1) ->
                               <- EAP-Request/
                               EAP-Type=EAP-FAST, V=1


Cam-Winget, et al.      Expires July 11, 2007               [Page 33]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


                               (EAP-FAST Start, S bit set, A-ID)

       EAP-Response/
       EAP-Type=EAP-FAST, V=1
       (TLS client_hello without
       PAC-Opaque extension)->
                               <- EAP-Request/
                               EAP-Type=EAP-FAST, V=1
                               (TLS server_hello,
                                TLS Server Key Exchange
                                TLS Server Hello Done)
       EAP-Response/
       EAP-Type=EAP-FAST, V=1 ->
       (TLS Client Key Exchange
        TLS change_cipher_spec,
        TLS finished)

                               <- EAP-Request/
                               EAP-Type=EAP-FAST, V=1
                               (TLS change_cipher_spec
                                TLS finished)
       EAP-Response/
       EAP-Type=EAP-FAST, V=1 ->
       (Acknowledgement)

       TLS channel established
       (messages sent within the TLS channel)

                              <-  EAP Payload TLV,
                                  EAP-Request/
                                  EAP Identity Request

       EAP Payload TLV, EAP-Response/
       EAP Identity Response ->

                              <-  EAP Payload TLV,
                                  EAP-Request,
                                  EAP-MSCHAPV2, Challenge

       EAP Payload TLV, EAP-Response,
       EAP-MSCHAPV2, Response) ->

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


Cam-Winget, et al.      Expires July 11, 2007               [Page 34]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


       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)
                               <- Result TLV (Success)
                                  PAC TLV

       Result TLV (Success)
       PAC Acknowledgment ->

       TLS channel torn down
       (messages sent in cleartext)

                               <- EAP-Failure



10.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-Type=EAP-FAST, V=1
                               (EAP-FAST Start, S bit set, A-ID)

       EAP-Response/
       EAP-Type=EAP-FAST, V=1
       (TLS client_hello without
       Ticket extension)->


Cam-Winget, et al.      Expires July 11, 2007               [Page 35]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


                               <- EAP-Request/
                               EAP-Type=EAP-FAST, V=1
                               (TLS Server Key Exchange
                                TLS Server Hello Done)
       EAP-Response/
       EAP-Type=EAP-FAST, V=1 ->
       (TLS Client Key Exchange
        TLS change_cipher_spec,
        TLS finished)

                               <- EAP-Request/
                               EAP-Type=EAP-FAST, V=1
                               (TLS change_cipher_spec
                                TLS finished)
       EAP-Response/
       EAP-Type=EAP-FAST, V=1 ->
       (Acknowledgement)

       TLS channel established
       (messages sent within the TLS channel)

                              <- EAP Payload TLV
                                 EAP-Request/EAP Identity Request

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

                              <-  EAP Payload TLV, EAP-Request,
                                  EAP-MSCHAPV2, Challenge

       EAP Payload TLV, EAP-Response,
       EAP-MSCHAPV2, Response ->

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

       Result TLV (Failure) ->


Cam-Winget, et al.      Expires July 11, 2007               [Page 36]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007



       TLS channel torn down
       (messages sent in cleartext)

                               <- EAP-Failure


10.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-Request/
                           EAP-Type=EAP-FAST, V=1
                           (EAP-FAST Start, S bit set, A-ID)

   EAP-Response/
   EAP-Type=EAP-FAST, V=1
   (TLS client_hello without
   Ticket extension)->
                           <- EAP-Request/
                           EAP-Type=EAP-FAST, V=1
                           (TLS server_hello,
                           (TLS Server Key Exchange
                            TLS Server Hello Done)

   EAP-Response/
   EAP-Type=EAP-FAST, V=1 ->
   (TLS Client Key Exchange
    TLS change_cipher_spec,
    TLS finished)

                           <- EAP-Request/
                           EAP-Type=EAP-FAST, V=1
                           (TLS change_cipher_spec



Cam-Winget, et al.      Expires July 11, 2007               [Page 37]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007


                            TLS finished)
                            EAP-Payload-TLV[
                            EAP-Request/Identity])

   // TLS channel established
      (messages sent within the TLS channel)

   // First EAP Payload TLV is piggybacked to the TLS Finished as
      Application Data and protected by the TLS tunnel

   EAP-Payload TLV/
   [EAP Identity Response] ->

                          <-  EAP Payload TLV, EAP-Request,
                              [EAP-MSCHAPV2, Challenge]

   EAP Payload TLV, EAP-Response,
   [EAP-MSCHAPV2, Response] ->

                          <-  EAP Payload TLV, EAP-Request,
                              [EAP-MSCHAPV2, Success Request]

   EAP Payload TLV, EAP-Response,
   [EAP-MSCHAPV2, Success Response] ->

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

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

   Result TLV (Success) ->

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

                           <- EAP-Failure


Cam-Winget, et al.      Expires July 11, 2007               [Page 38]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007





11.
   Intellectual Property Statement

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

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

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

12.
   Disclaimer of Validity

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


13.
   Copyright Statement

   Copyright (C) The Internet Society (2007).  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.



Cam-Winget, et al.      Expires July 11, 2007               [Page 39]

Internet-Draft   Dynamic Provisioning using EAP-FAST     January 2007



14.
   Expiration Date

   This memo is filed as <draft-cam-winget-eap-fast-provisioning-
   03.txt>, and expires July 11, 2007.









































Cam-Winget, et al.      Expires July 11, 2007               [Page 40]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/