draft-ietf-pppext-eap-ttls-05.txt

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

TXT
1,413
字号
      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. 





Paul Funk                expires January 2005                 [Page 5] 

Internet-Draft                                              April 2004         


   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, 
      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 

      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. 



Paul Funk                expires January 2005                 [Page 6] 

Internet-Draft                                              April 2004         


   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 

      A Network Access Identifier [7], 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 



Paul Funk                expires January 2005                 [Page 7] 

Internet-Draft                                              April 2004         


      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 is 
      possessed of 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. 

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 ----> 





Paul Funk                expires January 2005                 [Page 8] 

Internet-Draft                                              April 2004         


   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.  

   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. 






Paul Funk                expires January 2005                 [Page 9] 

Internet-Draft                                              April 2004         


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, 

⌨️ 快捷键说明

复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?