draft-funk-eap-ttls-v1-01.txt

来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,298 行 · 第 1/4 页

EAP                                                           Paul Funk 
Internet-Draft                                         Juniper Networks 
Category: Standards Track                            Simon Blake-Wilson 
<draft-funk-eap-ttls-v1-01.txt>                        Basic Commerce &  
                                                       Industries, Inc. 
                                                             March 2006 

                                     

          EAP Tunneled TLS Authentication Protocol Version 1 
                             (EAP-TTLSv1) 

                                     

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. 

Abstract 

   EAP-TTLS is an EAP type that utilizes TLS to establish a secure 
   connection between a client and server, through which additional 
   information may be exchanged. The initial TLS handshake may mutually 
   authenticate client and server; or it may perform a one-way 
   authentication, in which only the server is authenticated to the 
   client. The secure connection established by the initial handshake 
   may then be used to allow the server to authenticate the client 
   using existing, widely-deployed authentication infrastructures such 

Internet-Draft                                              March 2006         


   as RADIUS. The authentication of the client may itself be EAP, or it 
   may be another authentication protocol such as PAP, CHAP, MS-CHAP or 
   MS-CHAP-V2. 

   Thus, EAP-TTLS allows legacy password-based authentication protocols 
   to be used against existing authentication databases, while 
   protecting the security of these legacy protocols against 
   eavesdropping, man-in-the-middle and other cryptographic attacks. 

   EAP-TTLS also allows client and server to exchange other information 
   in addition to authentication-related information. 

   This document describes EAP-TTLSv1; that is, version 1 of the EAP-
   TTLS protocol. It represents a significant enhancement to the 
   original version 0 of the protocol. EAP-TTLSv1 utilizes an extended 
   version of TLS, called TLS/IA (TLS/InnerApplication) as its 
   underlying protocol [TLS/IA]. 

Table of Contents 

1.  Introduction......................................................3 
1.1    EAP-TTLSv1....................................................3 
1.2    Differences From Version 0....................................4 
2.  Motivation........................................................5 
3.  Terminology.......................................................6 
4.  Architectural Model...............................................9 
4.1    Carrier Protocols.............................................9 
4.2    Security Relationships.......................................10 
4.3    Messaging....................................................10 
4.4    Resulting Security...........................................11 
5.  Protocol Layering Model..........................................11 
6.  EAP-TTLSv1 Overview..............................................12 
6.1    Session Resumption...........................................13 
6.1.1      TTLS Server Guidelines for Session Resumption............14 
7.  Generating Keying Material.......................................15 
8.  EAP-TTLSv1 Protocol..............................................15 
8.1    Packet Format................................................15 
8.2    EAP-TTLS Start Packet........................................17 
8.2.1      Version Negotiation......................................17 
8.2.2      Fragmentation............................................17 
8.2.3      Acknowledgement Packets..................................18 
9.  Security Claims..................................................18 
10. Security Considerations..........................................19 
11. References.......................................................20 
11.1   Normative References.........................................20 
11.2   Informative References.......................................21 
12. Authors' Addresses...............................................22 
    






Paul Funk               expires September 2006                [Page 2] 

Internet-Draft                                              March 2006         


1. Introduction 

   EAP-TTLS is an EAP type that utilizes TLS to establish a secure 
   connection between a client and server, through which additional 
   information may be exchanged. The initial TLS handshake may mutually 
   authenticate client and server; or it may perform a one-way 
   authentication, in which only the server is authenticated to the 
   client. The secure connection established by the initial handshake 
   may then be used to allow the server to authenticate the client 
   using existing, widely-deployed authentication infrastructures such 
   as RADIUS. The authentication of the client may itself be EAP, or it 
   may be another authentication protocol such as PAP, CHAP, MS-CHAP or 
   MS-CHAP-V2. 

   Thus, EAP-TTLS allows legacy password-based authentication protocols 
   to be used against existing authentication databases, while 
   protecting the security of these legacy protocols against 
   eavesdropping, man-in-the-middle and other cryptographic attacks. 

   EAP-TTLS also allows client and server to establish keying material 
   for use in the data connection between the client and access point. 
   The keying material is established implicitly between client and 
   server based on the TLS handshake.  

   This document describes EAP-TTLSv1; that is, version 1 of the EAP-
   TTLS protocol. It represents a significant enhancement to the 
   original version 0 of the protocol. (EAP-TTLSv0). 

1.1 EAP-TTLSv1 

   EAP-TTLSv1 utilizes TLS with the Inner Application extension 
   (TLS/IA), as its underlying protocol. In TLS/IA, the TLS handshake 
   is followed by an exchange of messages with record type 
   InnerApplication, in which an arbirary exchange of messages between 
   client and server is conducted under the confidentiality and 
   integrity protection afforded by the TLS handshake. 

   The InnerApplication messages that are exchanged between client and 
   server are encoded as sequences of Attribute-Value-Pairs (AVPs) from 
   the RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace 
   provides natural compatibility between TLS/IA applications and 
   widely deployed AAA infrastructures. This namespace is extensible, 
   allowing new AVPs and, thus, new applications to be defined as 
   needed, either by standards bodies or by vendors wishing to define 
   proprietary applications. 

   The AVPs exchanged between client and server typically provide for 
   client authentication, or mutual client-server authentication. 
   However, the AVP exchange accommodates any type of client-server 
   exchange, not just authentication, though authentication may often 
   be the prerequisite that allows other exchanges to proceed. For 



Paul Funk               expires September 2006                [Page 3] 

Internet-Draft                                              March 2006         


   example, EAP-TTLSv1 may be used to verify endpoint integrity, 
   provision keying material for use in separate data channel 
   communications (e.g. IPsec), provide client credentials for single 
   sign-on, and so on. 

1.2 Differences From Version 0 

   Version 1 of EAP-TTLS is similar to version 0 in that a TLS 
   handshake is used to protect a subsequent AVP exchange. In version 
   0, the handshake portion of TLS is used to establish a tunnel and 
   the data portion is used to carry AVPs. This approach is similar to 
   that of other tunneled protocols, such as EAP-PEAP and EAP-FAST. 

   In version 1, an extension to TLS, called TLS/IA, is utilized; 
   TLS/IA already provides for a protected AVP exchange following the 
   TLS handshake, in effect producing an "extended" handshake. TLS/IA 
   was developed to allow authentication and other client-server 
   negotiations to occur within TLS itself. Thus, TLS/IA is suitable 
   both as the underlying protocol for EAP methods as well as a means 
   of introducing authentication and other client-server exchanges when 
   TLS is used to protect data communications such as an HTTP 
   conversation. 

   Use of TLS/IA in version 1 of EAP-TTLS provides several improvements 
   over verion 0: 

   -  Inner authentications are confirmed by mixing session keys 
      developed from those authentications with the master secret 
      developed during the TLS handshake. This guarantees that the TLS 
      handshake endpoint and the authentication endpoint are one and 
      the same, thus eliminating the Man-in-the-Middle (MitM) attack 
      against tunneled protocols for inner authentications that 
      generate session keys. See [MITM] for information about this 
      attack. 

   -  Session keys developed from inner authentications are mixed with 
      the TLS master secret to produce an "inner secret", which is 
      exported by TLS/IA. The inner secret is used to generate the MSK 
      (master session key) exported by EAP-TTLSv1 for use in the 
      subsequent data connection. Use of a session key that is bound to 
      inner session keys guarantees that the subsequent data connection 
      wll not operate except with the authentic client, even if the 
      original TLS master secret were compromised and available to an 
      eavesdropper. 

   -  TLS/IA's multi-phase operation allows a subsequent phase to 
      confirm the results of prior phases before proceeding.  

   -  A secure final exchange of the result of inner authentication is 
      exchanged between client and server to conclude the EAP-TTLSv1 
      exchange. This precludes any possibility of truncation attack 



Paul Funk               expires September 2006                [Page 4] 

Internet-Draft                                              March 2006         


      that could occur when the client relies solely on an unprotected 
      EAP-Success message to determine that the server has completed 
      its authentication. 

2. Motivation 

   Most password-based protocols in use today rely on a hash of the 
   password with a random challenge. Thus, the server issues a 
   challenge, the client hashes that challenge with the password and 
   forwards a response to the server, and the server validates that 
   response against the user's password retrieved from its database. 
   This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5-
   Challenge and EAP/One-Time Password. 

   An issue with such an approach is that an eavesdropper that observes 
   both challenge and response may be able to mount a dictionary 
   attack, in which random passwords are tested against the known 
   challenge to attempt to find one which results in the known 
   response. Because passwords typically have low entropy, such attacks 
   can in practice easily discover many passwords.  

   While this vulnerability has long been understood, it has not been 
   of great concern in environments where eavesdropping attacks are 
   unlikely in practice. For example, users with wired or dial-up 
   connections to their service providers have not been concerned that 
   such connections may be monitored. Users have also been willing to 
   entrust their passwords to their service providers, or at least to 
   allow their service providers to view challenges and hashed 
   responses which are then forwarded to their home authentication 
   servers using, for example, proxy RADIUS, without fear that the 
   service provider will mount dictionary attacks on the observed 
   credentials. Because a user typically has a relationship with a 
   single service provider, such trust is entirely manageable. 

   With the advent of wireless connectivity, however, the situation 
   changes dramatically: 

   -  Wireless connections are considerably more susceptible to 
      eavesdropping and man-in-the-middle attacks. These attacks may 
      enable dictionary attacks against low-entropy passwords. In 
      addition, they may enable channel hijacking, in which an attacker 
      gains fraudulent access by seizing control of the communications 
      channel after authentication is complete. 

   -  Existing authentication protocols often begin by exchanging the 
      client抯 username in the clear. In the context of eavesdropping 
      on the wireless channel, this can compromise the client抯 
      anonymity and locational privacy. 

   -  Often in wireless networks, the access point does not reside in 
      the administrative domain of the service provider with which the 



Paul Funk               expires September 2006                [Page 5] 

Internet-Draft                                              March 2006         


      user has a relationship. For example, the access point may reside 
      in an airport, coffee shop, or hotel in order to provide public 
      access via 802.11. Even if password authentications are protected 
      in the wireless leg, they may still be susceptible to 
      eavesdropping within the untrusted wired network of the access 
      point. 

   -  In the traditional wired world, the user typically intentionally 
      connects with a particular service provider by dialing an 
      associated phone number; that service provider may be required to 
      route an authentication to the user's home domain. In a wireless 
      network, however, the user does not get to choose an access 
      domain, and must connect with whichever access point is nearby; 
      providing for the routing of the authentication from an arbitrary 
      access point to the user's home domain may pose a challenge. 

   Thus, the authentication requirements for a wireless environment 
   that EAP-TTLS attempts to address can be summarized as follows: 

   -  Legacy password protocols must be supported, to allow easy 
      deployment against existing authentication databases. 

   -  Password-based information must not be observable in the 
      communications channel between the client node and a trusted 
      service provider, to protect the user against dictionary attacks. 

   -  The user's identity must not be observable in the communications 
      channel between the client node and a trusted service provider,