Network Working Group                             N. Cam-Winget 
  Internet Draft                                        D. McGrew 
  Category: Informational                              J. Salowey 
  Expires: September 5, 2006                              H. Zhou 
                                                     Cisco Sytems 
                                                    March 5, 2006 
   
   
                 Dynamic Provisioning using EAP-FAST 
          draft-cam-winget-eap-fast-provisioning-02.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 (2006). All Rights Reserved.  
      
    
 
 
 
 
Cam-Winget, et al.   Expires September 5, 2006            [Page 1] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
 
  
Abstract  
      
  EAP-FAST is an extensible 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..........................9 
     3.3 Use of other Inner EAP Methods for EAP-FAST Provisioning..10 
     3.4 Key Derivations Used in the EAP-FAST Provisioning Exchange11 
     3.5 Provisioning or Refreshment of a PAC......................12 
  4. Types of Information Provisioned in EAP-FAST..................13 
     4.1 PAC Types.................................................13 
     4.2 Provisioning PACs through PAC TLV.........................16 
4.2.1 Formats for PAC TLV Attributes...............................17 
4.2.2 PAC-Key......................................................17 
4.2.3 PAC-Opaque...................................................18 
4.2.4 PAC-Info.....................................................19 
4.2.5 PAC-Acknowledgement TLV......................................21 
4.2.6 PAC-Type TLV.................................................22 
     4.3 Server Trusted Root Certificate...........................23 
4.3.1 Server-Trusted-Root TLV......................................23 
4.3.2 PKCS #7 TLV..................................................25 
  5. Security Considerations.......................................26 
     5.1 User Identity Protection and Validation...................26 
     5.2 Mitigation of Dictionary Attacks..........................27 
     5.3 Mitigation of Man-in-the-middle (MitM) attacks............28 
     5.4 PAC Validation and User Credentials.......................29 
     5.5 Generation of Diffie-Hellman Groups.......................29 
     5.6 PAC Storage Considerations................................30 
  6. IANA Considerations...........................................31 
 
 
Cam-Winget, et al.   Expires September 5, 2006            [Page 2] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
  7. References...................................................32 
     7.1 Normative................................................32 
     7.2 Informative..............................................32 
  8. Acknowledgments..............................................33 
  9. Author's Addresses...........................................33 
  10. Appendix: Examples..........................................34 
     10.1 Example 1: Successful Tunnel PAC Provisioning...........34 
     10.2 Example 2: Successful Tunnel PAC Provisioning with Password 
     Change.......................................................36 
     10.3 Example 3: Failed Provisioning..........................38 
     10.4 Example 4: Provisioning a Authentication Server抯 Trusted 
     Root Certificate.............................................39 
     10.5 Example 5: Provisioning a User Authorization PAC........41 
  11. Intellectual Property Statement.............................43 
  12. Disclaimer of Validity......................................43
  13. Copyright Statement.........................................44 
  14. Expiration Date.............................................44 
    
1. Introduction 
   
  [EAP-FAST] is an extensible 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 
  Tunnel PAC MUST be provisioned to the peer before it can establish a 
  secure association 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 or 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 September 5, 2006            [Page 3] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
  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.  
 
      
   
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 an 
      unauthenticated (TLS) tunnel 
 
  In the Server-Authenticated Provisioning mode, the peer has 
  successfully authenticated the EAP server as part of the TLS 
  handshake of EAP-FAST Phase 1 (e.g. tunnel establishment).  
  Additional exchanges MAY be needed inside the tunnel for the EAP 
  Server to authenticate the peer before any information can be 
  provisioned.    
   
  In the Server-Unauthenticated Provisioning mode, an unauthenticated 
  tunnel is established in the EAP-FAST Phase 1.  This provisioning 
  mode is defined to enable bootstrapping or initial configuration of 
 
 
Cam-Winget, et al.   Expires September 5, 2006            [Page 4] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
  peers where the peer lacks strong credentials (if any) to mutually 
  authenticate with the server and configuration 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_WITH_AES_128_CBC_SHA 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 accept 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 to successfully complete the 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 
   
  The provisioning EAP-FAST exchange uses same sequence as the EAP-FAST 
  Authentication Phase 1 to establish a protected tunnel.  Once a 
  tunnel is secured between the two parties, the client and server can 
  then execute an EAP authentication method by which both parties can 
  achieve mutual authentication. 
 
 
Cam-Winget, et al.   Expires September 5, 2006            [Page 5] 
 
 
 
 
 
Internet-Draft   Dynamic Provisioning using EAP-FAST      March 2006 
 
 
   
  Provisioning in EAP-FAST is negotiated solely by the client as 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抯 Trusted Root certificate), it can request to initiate a 
  provisioning EAP-FAST exchange and dynamically obtain one 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; typically, 
  a unique PAC.   
 
  The conversation between a peer and authentication server commences