Subject: RE: [Capwap] Important: please provide input on comment resolution for CAPWAP Taxonomy draft

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 25 Oct 2004 09:37:30 -0700

Another response from Jesse on this ...

-----Original Message-----
From: Walker, Jesse 
Sent: Saturday, October 23, 2004 7:06 PM
To: Yang, Lily L; [email-masked]'
Subject: RE: [Capwap] Important: please provide input on comment
resolution for CAPWAP Taxonomy draft

Whether vendors want to believe it or not, the BSSID of the AP
identifies the PMK the STA should use, while the PMKID was an
after-thought to 802.11i, and was not properly integrated to perform the
function required of it. In particular, the binding of BSSIDs and STA
MAC addresses to the PMKID was never undertaken. Therefore, if the BSSID
changes, the STA has to assume that the PMK has been compromised, unless
the AAA server gives it some reason to believe the new BSSID is also
bound to the same PMK.

-----Original Message-----
From: Yang, Lily L 
Sent: Friday, October 22, 2004 12:59 PM
To: Walker, Jesse; [email-masked]
Subject: FW: [Capwap] Important: please provide input on comment
resolution for CAPWAP Taxonomy draft

Here is some other responds to the comment.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Montemurro
Sent: Thursday, October 21, 2004 8:12 AM
To: 'Pat R. Calhoun'; 'Chunduru Rama Krishna Prasad';
[email-masked]
Subject: RE: [Capwap] Important: please provide input on comment
resolution for CAPWAP Taxonomy draft

I'd agree that the text should likely remain. However, there should be
work done (likely in both IEEE and IETF) to modify the key hierarchy to
address this case.

	Mike

-----Original Message-----
From: Pat R. Calhoun [mailto:[email-masked]] 
Sent: Thursday, October 21, 2004 10:47 AM
To: Michael Montemurro; Chunduru Rama Krishna Prasad;
[email-masked]
Subject: RE: [Capwap] Important: please provide input on comment
resolution for CAPWAP Taxonomy draft

The comment may be valid in light of 802.11r. I'd argue that the text
remains since we need to be cognizant of not only current IEEE
standards, but also the ones in progress.

PatC 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chunduru Rama Krishna Prasad
Sent: Thursday, October 21, 2004 5:27 AM
To: [email-masked]
Subject: Re: [Capwap] Important: please provide input on comment
resolution for CAPWAP Taxonomy draft

hi all,

I am not sure, I am right on this. My impression is that, PMK is on per
Authenticator MAC address. If the station is re-associated with new WTP
(different MAC address), then it would not even send PMKID of old AP. If
there is no PMKID found in reassoc event, AC would start with full
802.1x authentication. If the station is reassociating with an AP, to
which it already established PMK before, then station sends PMKID and in
that case only 4 way key handshake is requried to get the PTK. With
respect to this, I am not sure whether the statement 'If PMK is shared
across multiple WTP' is valid. If not, the whole statement can be
removed from the draft

Regards
Rama Krishna Prasad

Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434

_______________________________________________
Capwap mailing list
[email-masked] http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked] http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Dan Harkins <[email-masked]>
Date: Mon, 25 Oct 2004 13:27:35 -0700

This is not an issue of what vendors want to believe.

  If the supplicant informed the authentication server of the BSSID
of the AP while it was deriving the PMK (and it should also properly
identify itself in a manner that the AP will identify it, i.e. 
it's MAC address and not some meta-identity like a "username"), and
if the authentication server had its trusted relationship with an
entity identified by the BSSID and not something completely different
(like an IP address of a different interface) we could have a PMK
bound to BSSID and the supplicant's MAC address. But that is not what
we have.

  What we have is a PMK derived by the supplicant and authentication
server with no binding of MAC addresses or BSSIDs. The two peers
identify themselves by meta-identities (like the DN of a certificate,
or a username) and the supplicant never indicates its desire to
use this secret for communication with a different entity, much
less identify that entity.

  Since the authentication server doesn't know the BSSID of the AP
(and the supplicant never told it that the PMK was to be shared with
that BSSID) there is no way that the PMK can be bound to it. 

  Dan.

On Mon, 25 Oct 2004 09:37:30 PDT you wrote