📄 draft-ietf-pppext-eap-ttls-05.txt
字号:
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 + -