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 + -
显示快捷键?