The RADIUS server can then act as a central repository of user profile information. Such use of a centralized authentication
server allows the user to access wireless LANs at many different points, but still be authenticated against the same server. In
response to the Access-Request, the RADIUS server sends an Access-Challenge to the AP, which is then relayed in the form of
an EAP-Request to the device. The device sends its credentials to the AP, which in turn relays them to the RADIUS server. The
RADIUS server determines whether access to the network is accepted or denied based on the Client's credentials.
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.
Dolphin® 9500 Series Mobile Computer User's Guide
7 - 45