Subject: [eap] Key Design discussions

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Sep 2003 16:23:09 -0700 (PDT)

I've created a web site holding the position papers and minutes of the Key
Framework Design Team:

http://www.drizzle.com/~aboba/key-design/
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 20 Sep 2003 22:04:39 -0700

Hi, 

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 ?

>"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 ? 
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. 

-mohan