Network Working Group                                      N. Cam-Winget
Internet-Draft                                                 D. McGrew
Expires: April 22, 2006                                       J. Salowey
                                                                 H. Zhou
                                                           Cisco Systems
                                                        October 19, 2005


      The Flexible Authentication via Secure Tunneling Extensible
               Authentication Protocol Method (EAP-FAST)
                    draft-cam-winget-eap-fast-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.

   This Internet-Draft will expire on April 22, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines the Extensible Authentication Protocol (EAP)
   based Flexible Authentication via Secure Tunneling (EAP-FAST)
   protocol.  EAP-FAST is an EAP method that enables secure
   communication between a peer and a server by using the Transport
   Layer Security (TLS) to establish a mutually authenticated tunnel.



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


   Within the tunnel, Type-Length-Value (TLV) objects are used to convey
   authentication related data between the peer and the EAP server.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Specification Requirements . . . . . . . . . . . . . . . .  5
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   Architectural Model  . . . . . . . . . . . . . . . . . . .  6
     2.2   Protocol Layering Model  . . . . . . . . . . . . . . . . .  7
   3.  EAP-FAST Protocol  . . . . . . . . . . . . . . . . . . . . . .  7
     3.1   Version Negotiation  . . . . . . . . . . . . . . . . . . .  8
     3.2   EAP-FAST Authentication Phase 1: Tunnel Establishment  . .  9
       3.2.1   TLS Session Resume using Server State  . . . . . . . . 10
       3.2.2   TLS Session Resume Using a PAC . . . . . . . . . . . . 10
       3.2.3   Transition between Abbreviated and Full TLS
               Handshake  . . . . . . . . . . . . . . . . . . . . . . 11
     3.3   EAP-FAST Authentication Phase 2: Tunneled
           Authentication . . . . . . . . . . . . . . . . . . . . . . 12
       3.3.1   EAP Sequences  . . . . . . . . . . . . . . . . . . . . 12
       3.3.2   Protected Termination and Acknowledged Result
               Indication . . . . . . . . . . . . . . . . . . . . . . 13
     3.4   Error Handling . . . . . . . . . . . . . . . . . . . . . . 14
       3.4.1   TLS Layer Errors . . . . . . . . . . . . . . . . . . . 14
       3.4.2   Phase 2 Errors . . . . . . . . . . . . . . . . . . . . 14
     3.5   Fragmentation  . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 16
     4.1   EAP-FAST Message Format  . . . . . . . . . . . . . . . . . 16
       4.1.1   Authority ID Data  . . . . . . . . . . . . . . . . . . 18
     4.2   EAP-FAST TLV Format and Support  . . . . . . . . . . . . . 19
       4.2.1   General TLV Format . . . . . . . . . . . . . . . . . . 19
       4.2.2   Result TLV . . . . . . . . . . . . . . . . . . . . . . 20
       4.2.3   NAK TLV  . . . . . . . . . . . . . . . . . . . . . . . 21
       4.2.4   Error TLV  . . . . . . . . . . . . . . . . . . . . . . 23
       4.2.5   Vendor-Specific TLV  . . . . . . . . . . . . . . . . . 24
       4.2.6   EAP-Payload TLV  . . . . . . . . . . . . . . . . . . . 25
       4.2.7   Intermediate-Result TLV  . . . . . . . . . . . . . . . 26
       4.2.8   Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 27
       4.2.9   Request-Action TLV . . . . . . . . . . . . . . . . . . 29
     4.3   Table of TLVs  . . . . . . . . . . . . . . . . . . . . . . 30
   5.  Cryptographic Calculations . . . . . . . . . . . . . . . . . . 31
     5.1   EAP-FAST Authentication Phase 1: Key Derivations . . . . . 31
     5.2   Intermediate Compound Key Derivations  . . . . . . . . . . 32
     5.3   Computing the Compound MAC . . . . . . . . . . . . . . . . 32
     5.4   EAP Master Session Key Generation  . . . . . . . . . . . . 33
     5.5   T-PRF  . . . . . . . . . . . . . . . . . . . . . . . . . . 33
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34



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


   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
     7.1   Mutual Authentication and Integrity Protection . . . . . . 35
     7.2   Method Negotiation . . . . . . . . . . . . . . . . . . . . 35
     7.3   Separation of the EAP Server and the Authenticator . . . . 36
     7.4   Separation of Phase 1 and Phase 2 Servers  . . . . . . . . 36
     7.5   Mitigation of Known Vulnerabilities and Protocol
           Deficiencies . . . . . . . . . . . . . . . . . . . . . . . 37
       7.5.1   User Identity Protection and Verification  . . . . . . 38
       7.5.2   Dictionary Attack Resistance . . . . . . . . . . . . . 39
       7.5.3   Protection against MitM Attacks  . . . . . . . . . . . 39
       7.5.4   PAC Validation with User Credentials . . . . . . . . . 40
     7.6   Protecting against Forged Clear Text EAP Packets . . . . . 41
     7.7   Implementation . . . . . . . . . . . . . . . . . . . . . . 42
     7.8   Server Certificate Validation  . . . . . . . . . . . . . . 42
     7.9   Security Claims  . . . . . . . . . . . . . . . . . . . . . 42
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 43
     9.2   Informative References . . . . . . . . . . . . . . . . . . 44
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 44
   A.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
     A.1   Successful Authentication  . . . . . . . . . . . . . . . . 45
     A.2   Failed Authentication  . . . . . . . . . . . . . . . . . . 46
     A.3   Full TLS Handshake using Certificate-based Cipher Suite  . 48
     A.4   Client authentication during Phase 1 with identity
           privacy  . . . . . . . . . . . . . . . . . . . . . . . . . 49
     A.5   Fragmentation and Reassembly . . . . . . . . . . . . . . . 51
     A.6   Sequence of EAP Methods  . . . . . . . . . . . . . . . . . 53
     A.7   Failed Crypto-binding  . . . . . . . . . . . . . . . . . . 55
     A.8   Stateless Session Resume Using Authorization PAC . . . . . 57
     A.9   Sequence of EAP Method with Vendor-Specific TLV
           Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 58
   B.  Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 60
     B.1   Key Derivation . . . . . . . . . . . . . . . . . . . . . . 60
     B.2   Crypto-Binding MIC . . . . . . . . . . . . . . . . . . . . 62
       Intellectual Property and Copyright Statements . . . . . . . . 63















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


1.  Introduction

   The need to provide user friendly and easily deployable network
   access solutions has heightened the need for strong mutual
   authentication protocols that internally use weak user credentials.
   This document defines the base protocol which consists of
   establishing a Transport Layer Security (TLS) tunnel as defined in
   [RFC2246] and then exchanging data in the form of type, length, value
   objects (TLV) to perform further authentication.  [I-D.cam-winget-
   eap-fast-provisioning] defines extensions to provision an additional
   credential called a protected access credential (PAC) to optimize the
   EAP-FAST exchange.  In addition to regular TLS ciphersuites and
   handshakes, EAP-FAST supports using a PAC with the TLS extension
   defined in [I-D.salowey-tls-ticket] in order to support fast re-
   establishment of the secure tunnel without having to maintain per-
   session state on the server as described in Section 3.2.2.

   EAP-FAST's design motivations included:

   o  Mutual Authentication: an EAP Server must be able to verify the
      identity and authenticity of the peer, and the peer must be able
      to verify the authenticity of the EAP server.

   o  Immunity to passive dictionary attacks: as many authentication
      protocols require the password to be explicitly provided (either
      in the clear or hashed) by the peer to the EAP server; at minimum,
      the communication of the weak credential (e.g. password) must be
      immune from eavesdropping.

   o  Immunity to man-in-the-middle (MitM) attacks: in establishing a
      mutually authenticated protected tunnel, the protocol must prevent
      adversaries from successfully interjecting information into the
      conversation between the peer and the EAP server.

   o  Flexibility to enable support for most password authentication
      interfaces: as many different password interfaces (e.g.  MSCHAP,
      LDAP, OTP, etc) exist to authenticate a peer, the protocol must
      provide this support seamlessly.

   o  Efficiency: specifically when using wireless media, peers will be
      limited in computational and power resources.  The protocol must
      enable the network access communication to be computationally
      lightweight.

   With these motivational goals defined, further secondary design
   criteria are imposed:





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


   o  Flexibility to extend the communications inside the tunnel: with
      the growing complexity in network infrastructures the need to gain
      authentication, authorization and accounting is also evolving.
      For instance, there may be instances in which multiple (already
      existent) authentication protocols are required to achieve mutual
      authentication.  Similarly, different protected conversations may
      be required to achieve the proper authorization once a peer has
      successfully authenticated.

   o  Minimize the authentication server's per user authentication state
      requirements: with large deployments, it is typical to have many
      servers acting as the authentication servers for many peers.  It
      is also highly desirable for a peer to use the same shared secret
      to secure a tunnel much the same way it uses the username and
      password to gain access to the network.  The protocol must
      facilitate the use of a single strong shared secret by the peer
      while enabling the servers to minimize the per user and device
      state it must cache and manage.

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:

   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 the 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.  The opaque part of the PAC is the same type of data as the
      ticket in [I-D.salowey-tls-ticket].

2.  Protocol Overview

   EAP-FAST is an authentication protocol similar to EAP-TLS [RFC2716]
   that enables mutual authentication and cryptographic context
   establishment by using the TLS handshake protocol.  EAP-FAST allows



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


   for the established TLS tunnel to be used for further authentication
   exchanges.  EAP-FAST makes use of TLVs to carry out the inner
   authentication exchanges.  The tunnel is then used to protect weaker
   inner authentication methods, which may be based on passwords, and to
   communicate the results of the authentication.

   EAP-FAST makes use of the TLS enhancements in [I-D.salowey-tls-
   ticket] to enable an optimized TLS tunnel session resume while
   minimizing server state.  In EAP-FAST the key and ticket used to
   establish the tunnel may be provisioned through mechanisms that do
   not involve the TLS handshake.  It is RECOMMENDED that
   implementations support the capability to distribute the ticket and
   secret key within the EAP-FAST tunnel as specified in [I-D.cam-
   winget-eap-fast-provisioning].  The pre-shared secret used in EAP-
   FAST is referred to as the protected access credential key (or PAC-
   Key); the PAC-Key is used to mutually authenticate the peer and the
   server when securing a tunnel.  The ticket is referred to as the
   protected access credential opaque data (or PAC-Opaque).

   The EAP-FAST conversation is used to establish or resume an existing
   session to typically establish network connectivity between a peer
   and the network.  Upon successful execution of EAP-FAST both EAP Peer
   and EAP Server derive strong session keys which can then communicated
   to the network access server (NAS).

2.1  Architectural Model

   The network architectural model for EAP-FAST usage is shown below: