Filter
Top Products
9 - 32 Rev D Dolphin® 7900 Series User’s Guide
Typical Message Exchange Using TTLS and PEAP
The above graphic shows a typical message flow for a TTLS transaction. TTLS authentication comprises two phases. In Phase
1, TLS is used to authenticate the TTLS server to the client. The TTLS server may optionally request authentication of the client's
certificate, but by default the client verifies only the server's certificate. The TLS handshake is negotiated between the client and
the TTLS server. Following the TLS handshake, Phase 2 may proceed using a secure channel (tunnel) provided by the TLS
record layer. The secure tunnel is then used to exchange information for the negotiation of the following legacy protocols: EAP-
MD5, PAP, CHAP, MS-CHAP, or MS-CHAPV2 (subject to support by the AAA server). A TTLS server may perform the
authentication, or the information may be de-tunneled and passed on to an AAA server. The AAA server is the server in the user's
home domain where authentication and authorization are administered.
PEAP works in the same manner as TTLS. However, supports different legacy protocols within the encrypted Phase 2 tunnel.
Currently the tunneled protocols are EAP-MSChapV2 and EAP-TLS/SmartCard. Like TTLS, the use of a client certificate is
optional, if one is used, the same certificate is used for Phase 1 and Phase 2. The client certificate is optional for both phases.
Benefits of 802.1X
Central User Administration
The Client allows network administrators to continue to use RADIUS or another AAA server as their centralized authentication
server. In 802.11b, where authentication took place between the AP and the station, there was no concept of passing credentials
from the AP to an authentication server. For LANs this was fine. However, as users began to use their devices in remote
locations, the security provided became inadequate. 802.1X solves this problem by allowing APs to pass client credentials to the
appropriate authentication server.
For example, the following graphic displays the authentication flow for a mobile user
who wishes to create a virtual private network with his home office.
By using the Client, the user can associate with a wireless network provided by a third
party, in this case the ISP. We assume that the company and the ISP have
established a service relationship beforehand. When the ISP receives the user's
credentials, the ISP proxies the credentials to the company's AAA server, which
returns a message telling the ISP to either accept or deny the user access. This
response is then propagated to the remote user.