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

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 20 Oct 2004 16:01:17 -0700

Inderpreet sent this out to the list earlier but it has not shown up
yet, so I am trying to resend here.
Please provide input ASAP as we want to resolve this so we can submit
v06 by Monday morning. Thanks!
Lily
----------the following is from Inderpreet -----

Hi all,
We have received the following comment on the security section of v05
--------------------begin Russ's comment:------------------------- 
Section 4.8.1 says:
:
: If the PMK (Pairwise Master Key) is reused across multiple
: WTPs, then requiring a 4-way handshake for each WTP that the station
: associates to, followed by the transfer of that PTK from the AC to
: the WTP, would ensure that a different PTK is used at each WTP.
:
I believe that each WTP has its own MAC address. So, each WTP looks
like a full-blown AP to the STA. The STA is sheltered from the WTP/AC
separation, and it cannot tell that PMK is not being reused across
truly different APs. To the STA, the share PMK looks like a
compromised PMK.

In order for the PMK to be shared, there needs some way for the STA to
securely learn the MAC addresses of the different WTPs that are
legitimately sharing the PMK. 
------------------------end of Russ's comment --------------------- 
In response I wanted to make the following clarifications and solicit
input on how to resolve this paragraph.
I understand there to be three different kinds of implementations:
1. 802.11i is fully implemented in the AC
2. 802.11i is distributed between AC and WTP
a. WTP is solely involved in the 4 way handshake and generation of PTK
(EAPoL messages are "proxied" to the RADIUS server via the AC). The PMK
is unique per WTP.
b. AC is involved in the 4 way handshake and the generation of the PTK.
EAP state machine is terminated on the AC, and AC is involved in PMK is
the same for all WTPs. This is where I think Russ is questioning the
security and or feasibility of this implementation given the current
802.11i standard's requirement for unique MAC per 
In my opinion - #1 and #2a is what was intended in this section. #2b is
problematic because of the non-uniqueness of the WTP's MAC addresses and
I don't recall which vendor has that kind of implementation?
Thanks, looking forward to people's input on this. There are other
comments that I think Lily has taken care of.
---
Inderpreet Singh
Chantry Networks
[email-masked]
Cell: 416-831-3705

---

From: Chunduru Rama Krishna Prasad <[email-masked]>
Date: Thu, 21 Oct 2004 14:56:37 +0530

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

---

From: "Michael Montemurro" <[email-masked]>
Date: Thu, 21 Oct 2004 10:16:25 -0400

Rama, 

You are correct. The PMK is derived from an 802.1x authentication
between the STA and the Authenticator. It is defined as being unique per
Authenticator/STA pair, which implies that is a unique value for each
WTP MAC/STA MAC pair. 

Cheers,

Mike

Michael Montemurro
Director, Advanced Technology and Standards
Chantry Networks Inc.
Mississauga, ON, CANADA.
T: 905-567-6900 x237
F: 905-567-9900
E: [email-masked] 

-----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,

If the station is re-associated with new WTP (different MAC address),
then 

Regards
Rama Krishna Prasad

Ch. Rama Krishna Prasad

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

---

From: Dan Harkins <[email-masked]>
Date: Thu, 21 Oct 2004 09:47:18 -0700

Strictly speaking the PMK is shared between the supplicant and the
authentication server, not the authenticator. There are no MAC addresses
bound to the PMK or used in the derivation of the PMK.

  As the person who got PMK caching and PMKIDs into the 802.11i draft
let me explain the steps we went through:

  - first motion was to indicate the ability of a STA to do "PMK caching"
    in an associate request. If the authenticator had a cached PMK for
    the STA it would respond with the 1st message of the 4way handshake,
    otherwise it would respond with an 802.1x encapsulated EAP Identity
    request. That enabled the functionality you describe below-- "the
    station is reassociating with an AP to with it already established
    the PMK before..." It prevented a STA in a difficult RF environment
    from ping-ponging back and forth between APs and hammering an 
    authentication server.

  - it soon became apparent that an authenticator may have multiple PMKs
    for a particular STA in its cache. How? Via something like a pro-active
    key pushing mechanism using neighbor graphs (Bill Arbaugh presented
    this idea). So the next motion was to name PMKs with a PMKID to
    indicate which PMK a STA is asserting in its associate request.
    This eliminated the ambiguity.

So the very reason that we have PMKIDs, and not just blind assertions of
a cached PMK, is because the PMK may be used to derive a PTK for 
multiple APs. The statement "If PMK is shared across multiple WTPs" is,
indeed, valid.

  Addressing Russ's comment, the PMK is already leaked because it is
given to the authenticator by the authentication server. When discussing
"the number of other people who know my secret" there are 3 possible
values: 0, 1 and infinity. If 0 other people know your secret there are
certain cryptographic properties associated with that state. If 1 other
person knows your secret there are other cryptographic properties
associated with that state (message source authentication for instance),
but if more than 1 person knows your secret then it doesn't matter if
it's 2 or 22, the cryptographic properties are the same (it is possible
for someone to impersonate you, forge your messages, read your
messages, etc).

  Of course you can say that in the 802.11i case the authenticator is
"trusted" and therefore it's OK for the authentication server to leak
the secret to the authenticator (and have 3 people know the secret).
OK, fine. The other AP is also "trusted" to have the PMK so now 4 people
know the secret (or 5 "trusted" people or 10 "trusted" people). Nothing
changed.

  In the case of a switch hosting multiple APs the switch is the
authenticator and the APs are merely tentacles of the same octopus. The
PMK isn't shared among the APs, it resides on the switch. There is even
one company I know of (I won't name it but it shouldn't be difficult to
guess) in which the switch plays the role of the authentication server
so the PMK is known only by the switch and the STA. This "PMK sharing"
situation is even MORE secure than the traditional deployment where a STA
establishes a PMK with a RADIUS server and that PMK is leaked to an AP.

  Dan.

On Thu, 21 Oct 2004 14:56:37 +0530 you wrote

---

From: Chunduru Rama Krishna Prasad <[email-masked]>
Date: Mon, 25 Oct 2004 09:16:18 +0530

Hi,
Does it mean that, 802.11i supplicants reuse the same PMK, even though they 
talk to new BSSID (WTP)?
If it is true in majority of supplicant implemenations, then it reduces one 
configuration element in our WTP/AC implementation :-).
If that is the case, it also helps in voice quality (as it does not require 
full EAP authentication), when the station moves from one
WTP to another new WTP belonging to same ESS, controlled by AC.
Thanks
Rama Krishna Prasad

Ch. Rama Krishna Prasad

---

From: Dan Harkins <[email-masked]>
Date: Sun, 24 Oct 2004 23:40:29 -0700

What it means is that when a supplicant associates to an AP that it
has never been associated to before it is permissible for a it to 
indicate a possession of a PMK (through a PMKID in an associate
request) that was derived from associating to a different AP. 

  What a majority of supplicant implementations do is a completely
different story because it is also permissible for a supplicant to
be 802.11i compliant and have a PMK cache of size zero-- that is,
never cache a PMK and require a full 802.1X/EAP authentication every
time it associates. 

  I cannot speak to a majority of supplicant implementations. All I
can say is that they can take advantaged of a cached PMK between
multiple APs. If a supplicant indicates possession of a PMK and 
the authenticator has the PMK it wins, if the authenticator 
doesn't then it's just as if the supplicant didn't identify the PMK.
It would seem to make sense that given such a situation a supplicant
would aggressively assert possession of PMKs when handing off. 

  You're right. It will help in voice applications when the client
hands off from AP to AP. That's the whole idea.

  Dan.

On Mon, 25 Oct 2004 09:16:18 +0530 you wrote