⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

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

📁 Linux上的802.1x 的supplicant的实现。很多supplicant程序都是基于它开发的
💻 TXT
📖 第 1 页 / 共 5 页
字号:
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,    optionally, to authenticate the client to the TTLS server, based on    public/private key certificates. As a result of the handshake,    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 

⌨️ 快捷键说明

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