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

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

I solicited input from Jesse Walker and Russ Housley on the issue of PMK
sharing, and here is the response from Jesse. He agrees to let me
forward this to the CAPWAP list. I also cc Jesse and Russ here. Since
Russ posted the original comment in IESG review, and Jesse is the
technical editor of 11i, I think it would be good that we keep them in
the loop with regard this discussion. So please cc them in your email
posting on this issue as they are not in the CAPWAP list.

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

Lily,

Dan's reasoning is invalid, unless he or someone else can produce a
deterministic algorithm that allows the client to distinguish the
following two cases:

Case 1: AP1 and AP2 are classical access points. An attacker compromises
AP1 and AP2 and moves the client's PMK from AP1 and AP2.

Case 2: AP1 and AP2 are two light-weight access points that are part of
the same switch S. The switch S uses the same PMK with both AP1 and AP2.

If no one can demonstrate a deterministic algorithm the client can use
to distinguish the two cases, then a properly implemented client will
always assume its PMK has been compromised when it sees either case. I
suspect no one can, because the client lacks the necessary state.

It appears to me there are three possible solutions:

a. The first is the necessary state is somehow delivered to the client
in an attestable fashion. The only party that client trusts is the AAA
server, so this implies a new binding protocol between the AAA server
and the EAP Peer.

b. The second is to define a new protocol that delivers the AP's
authenticated identifier to the EAP Peer in an attestable fashion, and
to change the 802.11i key confirmation handshake to use this identifier
instead of the BSSID of the APs.

c. The text that permits this usage should be removed.

I believe possibilities (a) or (b) are the right way to address this
issue.

-- Jesse

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

Jesse and Russ --

CAPWAP WG has had some email discussion regarding the comment from you
on PMK sharing. I don't think either of you are on the list, so I am
forwarding to you this and I would like to hear what you think about
these responses. 

Lily

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

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

---

From: Dan Harkins <[email-masked]>
Date: Mon, 25 Oct 2004 12:57:34 -0700

I beg to differ.

  If this was a Needham-Schroeder-esqe protocol Jesse might have a
point. But it's not.

  There is no way for a "properly implemented" client to know that the
AP it is speaking to is trusted by the authentication server since
nothing in the exchange that derives the PMK includes anything about
the AP. It's merely a man-in-the-middle. The AP proves knowledge of the
PMK so the client is just supposed to assume it's trusted! What is being
asked here is <nudge><nudge><wink><wink> just ignore that unpleasant
security issue </nudge></nudge></wink></wink> and believe we have a secure
3-party authenticaiton system here so that we can then condemn a scheme
that suffers from that same unpleasant security issue.

  How does a "properly implemented" client know that AP2 is not a
attacker which compromised AP1? By the same technique that it used
to know that AP1 was not an attacker which compromised the authen-
tication server (or the link between the authentication server and a
legitimate authenticator). Since a "properly implemented" client can
do the latter it can take the same steps to do the former.

  If mere proof of possession of the PMK is enough to legitimize AP1
to the client then mere proof of possession of the PMK is enough to
legitimize AP2 to the client. You cannot reasonably claim otherwise.

  This is not to say that Jesse's suggestions of (a) or (b) below
are not needed, I would welcome either of those. I would also like
to note that Jesse's mention of (c) is an explicit acknowledgment
that "PMK sharing" is permitted by the existing specification.

  Dan.

On Mon, 25 Oct 2004 09:33:05 PDT you wrote