Thanks to all for the replies on this one, especially the outline below. A bit of additional info - I do use VPN's for connection security, so I'm not really worried about MITM attacks via rogue AP's. I have a different application I'm working on related to mesh networking where I need to identify the AP for QOS reasons. A standard smart card empowered protocol/API would indeed do the trick, yet it seems fairly obscure in actual implementation at this point. Is there maybe a hack that could be done to extract the EAP (or equiv.) identifier of the authenticator over the wireless link? (by a client posing as an auth server) Or does 1X/EAP-TTLS forbid auth traffic over the air - i.e. backhaul only? Very curious.
Thanks again.. David -----Original Message----- From: Fors Chad-QA3336 [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 12:29 To: 'David Rhodes'; [EMAIL PROTECTED] Subject: RE: [BAWUG] AP spoof detection 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. 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) o AS has "authenticated" A via RADIUS _RequestAuthenticator_ in RADIUS request message o A has "authenticated" AS via RADIUS _ResponseAuthenticator_ in RADIUS response message o S has NOT authenticated A explicitly 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. Let me know if I confused the issue even more, and I will attempt to clarify :o) -Chad Fors He does not believe, that does not live according to his belief. ... Thomas Fuller (1608-1661) -----Original Message----- From: David Rhodes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 11:29 AM To: [EMAIL PROTECTED] Subject: [BAWUG] AP spoof detection ..another thought related to recent EAP/LEAP threads - Does anyone know if any of the related 1x mechanisms will provide AP authentication to the client? It seems like all the effort has gone into authenticating the client, not the access point. I realize that most 802.11 equip. was built for corporate and home environments where the network provider is trusted, but this is not true in the public space. I haven't used the 1x solutions to any serious degree yet but it appears the AP only passes the supplicant info to the RADIUS server. I know the RADIUS server essentially auth's the AP via the optional SSL/shared key connection but that doesn't provide the user any first hand information. Seems like we need some way to put public certs on the AP's similar to what is done with webservers. With all these stories of pimping starbucks wifi customers from the street, etc..not to mention AP storms... or am I missing something? thanks, david -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless
