> 802.1X provides the framework for the authentication, but the actual > procedure (and whether or not the it supports mutual authentication) depends > on the EAP method chosen. The simplest method is EAP-MD5 challenge, which > authenticates the user to the authentication server, but not the > authentication server to the user. More advanced methods (e.g., EAP-TLS, > EAP-TTLS, EAP-SIM, etc.) provides for mutual authentication, and is fully > compatible with 802.1X. These methods will authenticate the authentication > server to the client, but will NOT authenticate the AP (i.e., authenticator) > to the client.
IEEE 802.11i includes a four-way key exchange handshake between the AP and the station, so that the AP and station DO mutually authenticate, as well as securely validate the capabilities, ciphersuite, etc. that had been insecurely obtained previously (such as via unsecured Beacon or Probe Request/Responses). As a result, the 4-way handshake is a significant security improvement, and SHOULD be implemented by APs along with the new 802.11i ciphers such as TKIP (with a 48-bit IV to lessen the need for rekey). > Therefore, if one of these methods is used, the following > relationships should result: > > Nodes are: > S = Supplicant (i.e., client, e.g., laptop) > A = Authenticator (e.g., AP) > AS = Authentication Server (e.g., RADIUS Server) > > o S has authenticated AS via EAP method > o AS has authenticated S via EAP method > o A has authenticated S via 802.11 authentication (e.g., Open Auth) Open Auth isn't the only 802.11 authentication mode in 802.11i -- it also supports 802.1X pre-authentication, and there is also the 4-way handshake. > o AS has "authenticated" A via RADIUS _RequestAuthenticator_ in RADIUS > request message Actually, I think you mean the Message-Authenticator attribute. The Request Authenticator is just a nonce in the Access Request message. > o A has "authenticated" AS via RADIUS _ResponseAuthenticator_ in RADIUS > response message The Message-Authenticator attribute is also required (see RFC 2869). > o S has NOT authenticated A explicitly In 802.11i, S DOES authenticate A explicitly, via the 4-way handshake. > Therefore, even though S has not authenticated A explicitly, S has > authenticated AS, who in turn has authenticated A, so their may be an > implied trust between S and A. To summarize, then, if the client can > authenticate the server (via an EAP method that supports mutual > authentication), it essentially can trust the Access Point in between. So effectively, you know that the AP has been authorized by the AS. -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless
