+----------+      +----------+      +----------+      +----------+
    |          |      |          |      |          |      |  Inner   |
    |   Peer   |<---->|  Authen- |<---->| EAP-FAST |<---->|  Method  |
    |          |      |  ticator |      |  server  |      |  server  |
    |          |      |          |      |          |      |          |
    +----------+      +----------+      +----------+      +----------+


   The entities depicted above are logical entities and may or may not
   correspond to separate network components.  For example, the EAP-
   FAST server and Inner Method server might be a single entity; the
   authenticator and EAP-FAST server might be a single entity; or, the
   functions of the authenticator, EAP-FAST server and Inner Method
   server might be combined into a single physical device.  For example,
   typical 802.11 deployments place the Authenticator in an access point
   (AP) while a Radius Server may provide the EAP-FAST and Inner Method
   server components.  The above diagram illustrates the division of
   labor among entities in a general manner and shows how a distributed



Cam-Winget, et al.       Expires April 22, 2006                 [Page 6]

Internet-Draft                  EAP-FAST                    October 2005


   system might be constructed; however, actual systems might be
   realized more simply.  The security considerations Section 7.4
   provides an additional discussion of the implications of separating
   EAP-FAST server from the inner method server.

2.2  Protocol Layering Model

   EAP-FAST packets are encapsulated within EAP, and EAP in turn,
   requires a carrier protocol for transport.  EAP-FAST packets
   encapsulate TLS, which is then used to encapsulate user
   authentication information.  Thus, EAP-FAST messaging can be
   described using a layered model, where each layer encapsulates the
   layer beneath it.  The following diagram clarifies the relationship
   between protocols:


    +---------------------------------------------------------------+
    |       Inner EAP Method     |     Other TLV information        |
    |---------------------------------------------------------------|
    |                 TLV Encapsulation (TLVs)                      |
    |---------------------------------------------------------------|
    |                         TLS                                   |
    |---------------------------------------------------------------|
    |                       EAP-FAST                                |
    |---------------------------------------------------------------|
    |                         EAP                                   |
    |---------------------------------------------------------------|
    |        Carrier Protocol (EAPOL, RADIUS, Diameter, etc.)       |
    +---------------------------------------------------------------+


   The TLV layer is a payload with standard Type-Length-Value (TLV)
   Objects defined in Section 4.2.  The TLV objects are used to carry
   arbitrary parameters between an EAP peer and an EAP server.  All
   conversations in the EAP-FAST protected tunnel must be encapsulated
   in a TLV layer.

   Methods for encapsulating EAP within carrier protocols are already
   defined.  For example, IEEE 802.1x EAPOL may be used to transport EAP
   between the peer and the authenticator; RADIUS or Diameter are used
   to transport EAP between the authenticator and the EAP-FAST server.

3.  EAP-FAST Protocol

   EAP-FAST authentication occurs in two phases.  For the first phase
   EAP-FAST employs the TLS handshake to invoke an authenticated key
   agreement exchange to establish a protected tunnel.  Once the tunnel
   is established phase 2 begins in which the peer and server can engage



Cam-Winget, et al.       Expires April 22, 2006                 [Page 7]

Internet-Draft                  EAP-FAST                    October 2005


   in further conversations to establish the required authentication and
   authorization policies.  The operation of the protocol including
   phase 1 and phase 2 are the topic of this section.  The format of
   EAP-FAST messages is given in Section 4 and the cryptographic
   calculations are given in Section 5.

3.1  Version Negotiation

   EAP-FAST packets contain a three bit version field, following the TLS
   Flags field, which enables EAP-FAST implementations to be backward
   compatible with previous versions of the protocol.  This
   specification documents the EAP-FAST version 1 protocol;
   implementations of this specification MUST use a version field set to
   1.

   Version negotiation proceeds as follows:

      In the first EAP-Request sent with EAP type=EAP-FAST, the EAP
      server must set the version field to the highest supported version
      number.

      If the EAP peer supports this version of the protocol, it MUST
      respond with an EAP-Response of EAP type=EAP-FAST, and the version
      number proposed by the EAP-FAST server.

      If the EAP-FAST peer does not support this version, it responds
      with an EAP-Response of EAP type=EAP-FAST and the highest
      supported version number.

      If the EAP-FAST server does not support the version number
      proposed by the EAP-FAST peer, it terminates the conversation.
      Otherwise the EAP-FAST conversation continues.

   The version negotiation procedure guarantees that the EAP-FAST peer
   and server will agree to the latest version supported by both
   parties.  If version negotiation fails, then use of EAP-FAST will not
   be possible, and another mutually acceptable EAP method will need to
   be negotiated if authentication is to proceed.

   The EAP-FAST version is not protected by TLS; and hence can be
   modified in transit.  In order to detect modification of EAP-FAST
   version and specifically downgrade of an EAP-FAST version negotiated,
   the peers MUST exchange information on the EAP-FAST version number
   received during version negotiation using the Crypto-Binding TLV
   described in Section 3.3.2.  The receiver of the Crypto-Binding TLV
   MUST verify that the version in the Crypto-Binding TLV matches the
   version sent in the EAP-FAST version negotiation.




Cam-Winget, et al.       Expires April 22, 2006                 [Page 8]

Internet-Draft                  EAP-FAST                    October 2005


3.2  EAP-FAST Authentication Phase 1: Tunnel Establishment

   EAP-FAST is based on TLS handshake [RFC2246] to establish an
   authenticated and protected tunnel.  The TLS version offered by the
   peer and server MUST be TLS v1.0 or later.  This version of the EAP-
   FAST implementation MUST support the following TLS ciphersuites:

      TLS_RSA_WITH_RC4_128_SHA
      TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268]
      TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC3268]

   Other ciphersuites MAY be supported.  It is RECOMMENDED that
   anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only
   be used in the context of the provisioning described in [I-D.cam-
   winget-eap-fast-provisioning].  During the EAP-FAST Phase 1
   conversation the EAP-FAST endpoints MAY negotiate TLS compression.

   The EAP server initiates the EAP-FAST conversation with an EAP
   request containing an EAP-FAST/Start packet.  This packet includes a
   set Start (S) bit, the EAP-FAST version as specified in Section 3.1,
   and an authority identity.  The TLS payload in the initial packet is
   empty.  The authority identity (A-ID) is used to provide the peer a
   hint of the server's identity which may be useful in helping the peer
   select the appropriate credential to use.  Assuming that the peer
   supports EAP-FAST the conversation continues with the peer sending an
   EAP-Response packet with EAP type of EAP-FAST with the start (s) bit
   clear and the version as specified in Section 3.1.  This message
   encapsulates one or more TLS records containing the TLS handshake
   messages.  If the EAP-FAST version negotiation is successful then the
   EAP-FAST conversation continues until the EAP server and EAP peer are
   ready to enter phase 2.  When the full TLS handshake is performed,
   then the first payload of EAP-FAST Phase 2 MAY be sent along with
   finished handshake message to reduce the number of round trips.

   After the TLS session is established, another EAP exchange may occur
   within the tunnel to authenticate the EAP peer.  EAP-FAST
   implementations MUST support client authentication during tunnel
   establishment using the specified TLS ciphersuites specified in
   Section 3.2.  EAP-FAST implementations MUST also support the
   immediate re-negotiation of a TLS session to initiate a new handshake
   message exchange under the protection of the current ciphersuite.
   This allows support for protection of the peer's identity.  Note that
   the EAP peer does not need to authenticate as part of the TLS
   exchange, but can alternatively be authenticate through additional
   EAP exchanges carried out in phase 2.

   The EAP-FAST tunnel protects peer identity information from
   disclosure outside the tunnel.  Implementations that wish to provide



Cam-Winget, et al.       Expires April 22, 2006                 [Page 9]

Internet-Draft                  EAP-FAST                    October 2005


   identity privacy for the peer identity must carefully consider what
   information is disclosed outside the tunnel.

   The following sections describe resuming a TLS session based on
   server side or client side state.

3.2.1  TLS Session Resume using Server State

   EAP-FAST session resumption is achieved in the same manner TLS
   achieves session resume.  To support session resumption, the server
   and peer must minimally cache the Session ID, master secret and
   ciphersuite.  The peer attempts to resume a session by including a
   valid Session ID from a previous handshake in its ClientHello
   message.  If the server finds a match for the Session ID and is
   willing to establish a new connection using the specified session
   state, the server will respond with the same session ID and proceed
   with the EAP-FAST Authentication Phase 1 tunnel establishment based
   on a TLS abbreviated handshake.  After a successful conclusion of the
   EAP-FAST Authentication Phase 1 conversation, the conversation then
   continues on to phase 2.

3.2.2  TLS Session Resume Using a PAC

   EAP-FAST supports the resumption of sessions based on client side
   state using techniques described in [I-D.salowey-tls-ticket].  This
   version of EAP-FAST does not support the provisioning of a ticket
   through the use of the SessionTicket handshake message.  Instead it
   supports the provisioning of a ticket called a Protected Access
   Credential (PAC) as described in [I-D.cam-winget-eap-fast-
   provisioning].  Since the PAC mentioned here is used for establishing
   the TLS Tunnel, it is more specifically referred to as the Tunnel
   PAC.  The Tunnel PAC is a security credential provided by the EAP
   server to a peer and comprised of:

   1.  PAC-Key: this is a 32-octet key used by the peer to establish the
       EAP-FAST Phase 1 tunnel.  This key is used to derive the TLS
       premaster secret as described in Section 5.1.  The PAC-Key is
       randomly generated by the EAP Server to produce a strong entropy
       32-octet key.  The PAC-Key is a secret and MUST be treated
       accordingly.  For example a PAC-Key MUST be delivered in a secure
       channel and stored securely.

   2.  PAC-Opaque: this is a variable length field that is sent to the
       EAP Server during the EAP-FAST Phase 1 tunnel establishment.  The
       PAC-Opaque can only be interpreted by the EAP Server to recover
       the required information for the server to validate the peer's
       identity and authentication.  For example, the PAC-Opaque may
       include the PAC-Key and the PAC's peer identity.  The PAC-Opaque



Cam-Winget, et al.       Expires April 22, 2006                [Page 10]

Internet-Draft                  EAP-FAST                    October 2005


       format and contents are specific to the PAC issuing server.  The
       PAC-Opaque is a public credential and MAY be presented in the
       clear, so an attacker MUST NOT be able to gain useful information
       from the PAC-Opaque itself.

   3.  PAC-Info: this is a variable length field used to provide at
       minimum, the authority identity of PAC issuer.  Other useful but
       not mandatory information, such as the PAC-Key lifetime, may also
       be conveyed by the EAP Server to the peer during PAC provisioning
       or refreshment.

   The use of the PAC is based on the SessionTicket extension defined in
   [I-D.salowey-tls-ticket].  The EAP Server initiates the TLS
   conversation as in the previous section.  Upon receiving the A-ID
   from the server the Peer checks to see if it has an existing valid
   PAC-Key and PAC-Opaque for the server.  If it does then it obtains
   the PAC-Opaque and puts it in the SessionTicket extension in the
   ClientHello.  It is RECOMMENDED in EAP-FAST that the peer include an
   empty session ID in a ClientHello containing a PAC-Opaque.  EAP-FAST
   does not currently support the SessionTicket Handshake message so an
   empty SessionTicket extension MUST NOT be included in the
   ClientHello.  If the PAC-Opaque included in SessionTicket extension
   is valid and EAP server permits the abbreviated TLS handshake, it
   will select the ciphersuite allowed to be used from information
   within the PAC and finish with the abbreviated TLS handshake.  If the
   server receives a Session ID and a PAC-Opaque in the SessionTicket
   extension in a ClientHello it should place the same Session ID in the
   ServerHello if it is resuming a session based on the PAC-Opaque.  The
   conversation then proceeds as described in [I-D.salowey-tls-ticket]
   until the handshake completes or a fatal error occurs.  After the
   abbreviated handshake completes the peer and server are ready to
   enter phase 2.  Note that when a PAC is used the TLS master secret is
   calculated from the PAC-Key, client random and server random as
   described in Section 5.1.


3.2.3  Transition between Abbreviated and Full TLS Handshake

   If session resumption based on server side or client side state fails
   the server can gracefully fall back to a full TLS handshake.  If the
   ServerHello received by the peer contains a empty Session ID or a
   Session ID that is different than in the ClientHello the server may
   be falling back to a full handshake.  The peer can distinguish
   Server's intent of negotiating full or abbreviated TLS handshake by
   checking the next TLS handshake messages in the server response to
   ClientHello.  If ChangeCipherSpec follows the ServerHello in response
   to the ClientHello, then the Server has accepted the session
   resumption and intends to negotiate the abbreviated handshake.



Cam-Winget, et al.       Expires April 22, 2006                [Page 11]

Internet-Draft                  EAP-FAST                    October 2005


   Otherwise, the Server intends to negotiate the full TLS handshake.  A
   peer can request for a new PAC to be provisioned after the full TLS
   handshake and mutual authentication of the peer and the server.  In