eap Mailing List: Re: Comments on pasi.txt

[Mohan Parthasarathy (mohanp]

  > >
> > I had a few questions/comments on the pasi's notes.
> >
> > In the section, "client's point of view",
> >
> > >The proposed key derivation mechanisms (e.g. AAA server
> > >includes the BSSID when deriving the key to be sent to the AP)
> > >authenticates also the BSSID (MAC address) of the AP (if the
> > >AAA server can check that the BSSID is correct). However, it's
> > >not clear how much this actually helps the client in
> > >determining if it's talking to the correct AP or not. Since
> >
> > I am not sure i understood the meaning of correct AP here.
> > Is the correct AP the one that the client thinks that will provide
> > the expected service ?  AAA server "trusts" that this is the
> > "correct" AP and tells the client indirectly by including
> > the BSSID in key derivation. Why is this not sufficient ?
> > Could you elaborate ?
>
> By "correct AP", I meant any AP that provides the service
> expected by the user, and most likely the BSSID has nothing
> to do with the user's expectations...
>
> I think this is somewhat similar as DNS names and IP addresses.
> Suppose you want to connect to ExampleBank's on-line banking
> service. It wouldn't be very useful for the client to
> authenticate the server's IP address or MAC address (although
> these would uniquely identify the server). It's much more likely
> that the DNS name helps you in determining whether this is the
> expected service or not, although, just like SSID, it doesn't
> necessarily uniquely identify a single web server (most likely
> it's at least a cluster, and could be geographically
> distributed).
>
Ok, this helps understand better..

> > >"correct" here usually includes the intentions of the person
> > >operating the client, the identities that are authenticated
> > >should really be meaningful to that person. BSSID certainly
> > >is not; SSID probably is (although it doesn't uniquely
> > >identify the AP).
> >
> > What extra assurance the client gets by authenticating the "SSID" ?
> > What exactly does the AAA server do with the SSID ? Does it
> > verify that this AP is the right one for the SSID ?
>
> Authenticating the SSID helps if the same AAA server (and AAA
> server "identity") can provide different services. Suppose that
> you can use your USIM card and EAP-AKA to authenticate to both
> "Joe's_HotSpot" SSID and "Example_Inc_Intranet" SSID (this,
> of course, means that both Joe's HotSpot and Example Inc.
> have some sort of agreement with your 3G operator).
>
> If the client now selects the "Example_Inc_Intranet" SSID from a
> list and authenticates successfully, current specs (WPA1) don't
> guarantee that he's actually talking to Example Inc's AP at all.
> He could be talking to one of Joe's APs instead (if either Joe
> has turned bad, or his access points have been compromised).
>
> (Actually, it seems that the current situation is even worse:
> the SSID is not included in the four-way handshake, so can
> an attacker just change it on the radio link, without any
> help from Joe? I'm not 100% sure about this...)
>
> This certainly violates the user's expectations, and it
> would be prevented if the client authenticated the SSID.
> One way to implement this would be that when the AAA server
> receives a RADIUS Access-Request from Joe, it checks that the
> Called-Station-Id attribute has indeed SSID "Joe's HotSpot"
> (presumably this would be configured in the AAA server when
> an agreeement with Joe is made), and the SSID is also included
> in key derivation.
>
Ok. There are two parts to it. The first part is the authentication i.e
verification of
SSID in the called-station-id attribute. The second part is including the
SSID
in the key derivation.  I assume you meant that both the SSID and BSSID
and should be included in the key derivation.

> > Eventually the client wants to be able to send/receive packets.
> > BSSID seems important for this purpose. So, don't you really
> > want to verify whether this "BSSID" can be associated with this
> > "SSID",  and just include the BSSID in key derivation as that's
> > what is used eventually in sending and receiving packets.
>
> BSSID is certainly important for sending and received packets,
> but I'm not sure if it's necessary to authenticate it. It might
> be easier to just associate the SSID and the key (PMK) directly,
> skipping the BSSID (just like in SSL/TLS, the IP address is
> not authenticated)...
>
Did you mean skip the BSSID altogether from authentication and key
derivation ?

thanks
mohan
> Best regards,
> Pasi
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap