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

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

      to protect the user's locational privacy against surveillance, 
      undesired acquisition of marketing information, and the like. 

   -  The authentication process must result in the distribution of 
      shared keying information to the client and access point to 
      permit encryption and validation of the wireless data connection 
      subsequent to authentication, to secure it against eavesdroppers 
      and prevent channel hijacking. 

   -  The authentication mechanism must support roaming among small 
      access domains with which the user has no relationship and which 
      will have limited capabilities for routing authentication 
      requests. 

3. Terminology 

   AAA 

      Authentication, Authorization and Accounting - functions that are 
      generally required to control access to a network and support 
      billing and auditing. 

   AAA protocol 



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


      A network protocol used to communicate with AAA servers; examples 
      include RADIUS and Diameter. 

   AAA server 

      A server which performs one or more AAA functions: authenticating 
      a user prior to granting network service, providing authorization 
      (policy) information governing the type of network service the 
      user is to be granted, and accumulating accounting information 
      about actual usage. 

   AAA/H 

      A AAA server in the user's home domain, where authentication and 
      authorization for that user are administered. 

   access point 

      A network device providing users with a point of entry into the 
      network, and which may enforce access control and policy based on 
      information returned by a AAA server. For the purposes of this 
      document, "access point" and "NAS" are architecturally 
      equivalent. "Access point" is used throughout because it is 
      suggestive of devices used for wireless access; "NAS" is used 
      when more traditional forms of access, such as dial-up, are 
      discussed. 

   access domain 

      The domain, including access points and other devices, that 
      provides users with an initial point of entry into the network; 
      for example, a wireless hot spot. 

   client 

      A host or device that connects to a network through an access 
      point.  

   domain 

      A network and associated devices that are under the 
      administrative control of an entity such as a service provider or 
      the user's home organization. 

   link layer protocol 

      A protocol used to carry data between hosts that are connected 
      within a single network segment; examples include PPP and 
      Ethernet. 

   NAI 



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


      A Network Access Identifier [RFC2486], normally consisting of the 
      name of the user and, optionally, the user's home realm. 

   NAS 

      A network device providing users with a point of entry into the 
      network, and which may enforce access control and policy based on 
      information returned by a AAA server. For the purposes of this 
      document, "access point" and "NAS" are architecturally 
      equivalent. "Access point" is used throughout because it is 
      suggestive of devices used for wireless access; "NAS" is used 
      when more traditional forms of access, such as dial-up, are 
      discussed. 

   proxy 

      A server that is able to route AAA transactions to the 
      appropriate AAA server, possibly in another domain, typically 
      based on the realm portion of an NAI. 

   realm 

      The optional part of an NAI indicating the domain to which a AAA 
      transaction is to be routed, normally the user's home domain. 

   service provider 

      An organization with which a user has a business relationship, 
      that provides network or other services. The service provider may 
      provide the access equipment with which the user connects, may 
      perform authentication or other AAA functions, may proxy AAA 
      transactions to the user's home domain, etc. 

   TTLS server 

      A AAA server which implements EAP-TTLS. This server may also be 
      capable of performing user authentication, or it may proxy the 
      user authentication to a AAA/H. 

   user 

      The person operating the client device. Though the line is often 
      blurred, "user" is intended to refer to the human being who 
      possesses an identity (username), password or other 
      authenticating information, and "client" is intended to refer to 
      the device which makes use of this information to negotiate 
      network access. There may also be clients with no human 
      operators; in this case the term "user" is a convenient 
      abstraction. 





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


4. Architectural Model 

   The network architectural model for EAP-TTLS usage and the type of 
   security it provides is shown below. 

   +----------+      +----------+      +----------+      +----------+ 
   |          |      |          |      |          |      |          | 
   |  client  |<---->|  access  |<---->| TTLS AAA |<---->|  AAA/H   | 
   |          |      |  point   |      |  server  |      |  server  | 
   |          |      |          |      |          |      |          | 
   +----------+      +----------+      +----------+      +----------+ 
    
   <---- secure password authentication tunnel ---> 
    
   <---- secure data tunnel ----> 

   The entities depicted above are logical entities and may or may not 
   correspond to separate network components. For example, the TTLS 
   server and AAA/H server might be a single entity; the access point 
   and TTLS server might be a single entity; or, indeed, the functions 
   of the access point, TTLS server and AAA/H server might be combined 
   into a single physical device. The above diagram illustrates the 
   division of labor among entities in a general manner and shows how a 
   distributed system might be constructed; however, actual systems 
   might be realized more simply. 

   Note also that one or more AAA proxy servers might be deployed 
   between access point and TTLS server, or between TTLS server and 
   AAA/H server. Such proxies typically perform aggregation or are 
   required for realm-based message routing. However, such servers play 
   no direct role in EAP-TTLS and are therefore not shown. 

4.1 Carrier Protocols 

   The entities shown above communicate with each other using carrier 
   protocols capable of encapsulating EAP. The client and access point 
   communicate using a link layer carrier protocol such as PPP or 
   EAPOL. The access point, TTLS server and AAA/H server communicate 
   using a AAA carrier protocol such as RADIUS or Diameter.  

   EAP, and therefore EAP-TTLS, must be initiated via the link layer 
   protocol. In PPP or EAPOL, for example, EAP is initiated when the 
   access point sends an EAP-Request/Identity packet to the client. 

   The keying material used to encrypt and authenticate the data 
   connection between the client and access point is developed 
   implicitly between the client and TTLS server as a result of EAP-
   TTLS negotiation. This keying material must be communicated to the 
   access point by the TTLS server using the AAA carrier protocol.  





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


   The client and access point must also agree on an 
   encryption/validation algorithm to be used based on the keying 
   material. In some systems, both these devices may be preconfigured 
   with this information, and distribution of the keying material alone 
   is sufficient. Or, the link layer protocol may provide a mechanism 
   for client and access point to negotiate an algorithm. 

   In the most general case, however, it may be necessary for both 
   client and access point to communicate their algorithm preferences 
   to the TTLS server, and for the TTLS server to select one and 
   communicate its choice to both parties. This information would be 
   transported between access point and TTLS server via the AAA 
   protocol, and between client and TTLS server via EAP-TTLS in 
   encrypted form. 

4.2 Security Relationships 

   The client and access point have no pre-existing security 
   relationship. 

   The access point, TTLS server and AAA/H server are each assumed to 
   have a pre-existing security association with the adjacent entity 
   with which it communicates. With RADIUS, for example, this is 
   achieved using shared secrets. It is essential for such security 
   relationships to permit secure key distribution. 

   The client and AAA/H server have a security relationship based on 
   the user's credentials such as a password.  

   The client and TTLS server may have a one-way security relationship 
   based on the TTLS server's possession of a private key guaranteed by 
   a CA certificate which the user trusts, or may have a mutual 
   security relationship based on certificates for both parties. 

4.3 Messaging 

   The client and access point initiate an EAP conversation to 
   negotiate the client's access to the network. Typically, the access 
   point issues an EAP-Request/Identity to the client, which responds 
   with an EAP-Response/Identity. Note that the client does not include 
   the user's actual identity in this EAP-Response/Identity packet; the 
   user's identity will not be transmitted until an encrypted channel 
   has been established. 

   The access point now acts as a passthrough device, allowing the TTLS 
   server to negotiate EAP-TTLS with the client directly.  

   During the first phase of the negotiation, the TLS handshake 
   protocol is used to authenticate the TTLS server to the client and, 
   optionally, to authenticate the client to the TTLS server, based on 
   public/private key certificates. As a result of the handshake, 



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


   client and TTLS server now have shared keying material and an agreed 
   upon TLS record layer cipher suite with which to secure subsequent 
   EAP-TTLS communication. 

   During the second phase of negotiation, client and TTLS server use 
   the secure TLS record layer channel established by the TLS handshake 
   as a tunnel to exchange information encapsulated in attribute-value 
   pairs, to perform additional functions such as client authentication 
   and key distribution for the subsequent data connection. 

   If a tunneled client authentication is performed, the TTLS server 
   de-tunnels and forwards the authentication information to the AAA/H. 
   If the AAA/H performs a challenge, the TTLS server tunnels the 
   challenge information to the client. The AAA/H server may be a 
   legacy device and needs to know nothing about EAP-TTLS; it only 
   needs to be able to authenticate the client based on commonly used 
   authentication protocols. 

   Keying material for the subsequent data connection between client 
   and access point may be generated based on secret information 
   developed during the TLS handshake and subsequent tunneled 
   authentications between client and TTLS server. At the conclusion of 
   a successful authentication, the TTLS server may transmit this 
   keying material to the access point, encrypted based on the existing 
   security associations between those devices (e.g., RADIUS).  

   The client and access point now share keying material which they can 
   use to encrypt data traffic between them. 

   In EAP-TTLSv1, the AVP exchange during the second phase is performed 
   using InnerApplication records via the TLS/IA protocol. This AVP 
   exchange itself may be be multi-phase, with each phase proceeding 
   only if the prior phase resulted in success.  

4.4 Resulting Security 

   As the diagram above indicates, EAP-TTLS allows user identity and 
   password information to be securely transmitted between client and 
   TTLS server, and performs key distribution to allow network data 
   subsequent to authentication to be securely transmitted between 
   client and access point.  

5. Protocol Layering Model 

   EAP-TTLSv1 packets are encapsulated within EAP, and EAP in turn 
   requires a carrier protocol to transport it. EAP-TTLSv1 packets 
   themselves encapsulate TLS/IA, which is then used to encapsulate 
   user authentication information. TLS/IA, as an extension to TLS, can 
   be considered encapsulated by TLS. Thus, EAP-TTLSv1 messaging can be 
   described using a layered model, where each layer is encapsulated by 




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