Hi, Not sure I understand exactly what you want to do, but if you want your station to authenticate an AP, you could actually use 802.1X with the roles reversed: the client would be the authenticator (also action as the auth server), and the AP would be the supplicant. Depending on the exact setup, this might be more or less easy to do (it will require having the code for the EAP method used on the boxes themselves).
Note that cisco APs can act as LEAP clients in some situations (when you have several APs, one of which is a repeater -acting as a supplicant- and the other being the root -acting as a regular authenticator- for instance). Standard 802.1X is not supported in this case, though (LEAP is limited to one single and pretty simple method). This is the normal setup: Station AP RADIUS server (supplicant) (authenticator) (auth server) EAP method(s) no EAP methods EAP method(s) (client side) (transparent passthrough) (server side) client credentials list of clients with verifiers for each This is, I believe, the setup you're looking for: Station AP (authenticator) (supplicant) EAP method(s) EAP method(s) (server side) (client side) list of APs with AP credentials verifiers for each Of course, that means that each station has to carry a copy of the verifiers (depending on the method these can be passwords, encrypted passwords, root certs, CRLs, etc.) for all APs, and get an update when the list changes. Alternatively, the station could actually contact a RADIUS server to verify the info, but that means using the link that has not been verified yet (unless of course you have another link somewhere else). Using IPsec to protect the RADIUS conversation might not be a bad idea in this case... Jacques. At 00:02 09/10/2002, David Rhodes wrote: >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 -- Jacques Caron, IP Sector Technologies Join the discussion on public WLAN open global roaming: http://lists.ipsector.com/listinfo/openroaming -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless
