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

From: "Pat R. Calhoun" <[email-masked]>
Date: Mon, 25 Oct 2004 10:19:47 -0700

While I understand Jesse's point, the IEEE is looking at alternatives in
its 802.11r task group. So while there is no standards based solution
today, I think it would be a mistake to break future interoperability.

Furthermore, I think the point that Dan was trying to make was that in
the CAPWAP architecture, the AC contain the authenticator, not the WTP.
Since the AC has access to the PMK, it is inherently a "shared" resource
- regardless of whether it is re-used across BSSIDs or not.

PatC 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Yang, Lily L
Sent: Monday, October 25, 2004 9:38 AM
To: [email-masked]
Cc: Walker, Jesse; [email-masked]
Subject: RE: [Capwap] Important: please provide input on comment
resolution for CAPWAP Taxonomy draft

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
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Mon, 25 Oct 2004 10:41:13 -0700

I agree. Obviously some of my contributions are being made in 802.11r,
but I'll be glad to help out in whatever way I can.

PatC 

-----Original Message-----
From: Walker, Jesse [mailto:[email-masked]] 
Sent: Monday, October 25, 2004 10:34 AM
To: Pat R. Calhoun; Yang, Lily L; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Important: please provide input on comment

Pat,

The issue is not whether the AC is the Authenticator, and we are not
talking about breaking future interoperability. The issue is the
contract the Authenticator makes with the mobile device concerning the
PMK.

Under 802.11i there is no way to specify that the Authenticator is
anything but the BSSID of the access point. If the key gets reused with
multiple BSSIDs, then the client must assume the key has been
compromised, because the Authenticator has broken its faith with the
client over the only relationship that is expressible within 802.11i.

My view is that no one wants to force people to necessarily use a
different PMK with different APs in switched architecture, because the
PMK and PTK remains within a single crypto boundary and so we know it
has not been compromised. What is needed instead is some way to express
the actual relationship, so that the client can distinguish the
situation from the case where its key has been compromised. We need a
way for the Authenticator to express its relationship with the client,
so that the client can determine that it is indeed living up to this
relationship.

Neither 802.11i nor EAP has attempted to address the binding problem,
and this is a deficiency that rules out the very natural usage model
CAPWAP wants to propose. We must either remove the deficiency, or else
we must live with the deployment restrictions it implies.

I am assembling a strawman list requirements to discuss in 802.11 for
the key binding problem. This sounds like one of them. If you have any
contributions, please let me know.

-- Jesse

-----Original Message-----
From: Pat R. Calhoun [mailto:[email-masked]]
Sent: Monday, October 25, 2004 10:20 AM
To: Yang, Lily L; [email-masked]
Cc: Walker, Jesse; [email-masked]
Subject: RE: [Capwap] Important: please provide input on comment

PatC 

-----Original Message-----

	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]

PatC
-----Original Message-----

hi all,

Regards
Rama Krishna Prasad

Ch. Rama Krishna Prasad

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Mon, 25 Oct 2004 11:17:21 -0700

When I refer to CAPWAP architecture, I refer to the various
architectures that are defined in the taxonomy document. The document
clearly states that certain architectures centralize the authenticator
function. 

So now you have a centralized place where the PMK is store. 802.11r can
help define a method of using the original PMK (in some way that I am
not defining here) to create new PMKs in a fast and efficient manner. I
know Jesse has other thoughts here too.

I am referring to CAPWAP here because the discussion is in the context
of the CAPWAP list. I am referring to 802.11r as external work. 802.11r
may work with other architectures as well.

PatC 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Clint Chaplin
Sent: Monday, October 25, 2004 10:58 AM
To: Pat R. Calhoun
Cc: Russ Housley; Walker, Jesse; Yang, Lily L; [email-masked]
Subject: Re: [Capwap] Important: please provide input on comment
resolution for CAPWAP Taxonomy draft

"The CAPWAP architecture "enables" 802.11r to function."  Say what?

Number one, I didn't think there was a CAPWAP "architecture"; well, at
least this group hasn't been able to define one.  CAPWAP is more a
protocol....

And, number two, the above seems to imply that without CAPWAP, IEEE
802.11r wouldn't be able to solve the problem at all.  I find that
limiting.

On Mon, 25 Oct 2004 10:40:09 -0700, Pat R. Calhoun
<[email-masked]> wrote:
> Correct, and 802.11r is looking at that problem. The CAPWAP 
> architecture "enables" 802.11r to function.
> 
> PatC
> 
> From: Russ Housley [mailto:[email-masked]]
> Sent: Monday, October 25, 2004 10:32 AM
> To: Pat R. Calhoun
> Cc: Walker, Jesse; Yang, Lily L; [email-masked]
> Pat:
> You are correct.  In the CAPWAP environment, the PMK is shared with 
> many WTPs.  However, the STA has no way to figure out which WTPs out 
> to have access to the PMK.  This needs to be solved before the PMK can

> be effectively shared.
> 
> Russ
> 
> 
> 
> At 01:19 PM 10/25/2004, Pat R. Calhoun wrote:
> >While I understand Jesse's point, the IEEE is looking at alternatives

> >in its 802.11r task group. So while there is no standards based 
> >solution today, I think it would be a mistake to break future
> interoperability.
> >
> >Furthermore, I think the point that Dan was trying to make was that 
> >in the CAPWAP architecture, the AC contain the authenticator, not the
WTP.

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

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

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

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

--
Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Lead
_______________________________________________
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: "Pat R. Calhoun" <[email-masked]>
Date: Mon, 25 Oct 2004 13:23:29 -0700

802.11r is out of scope and is a client-network protocol for speeding up
hand-offs. There is no document at this time to review.

This discussion is unfortunately really getting out of hand. My point,
below, is that PMKs are maintained in the AC today, and ACs can support
more than one WTP. If there is a mechanism that allows a station's PMKs
created on one WTP to be "used" in some fashion to derive other keying
material for other WTPs, then so be it.

CAPWAP is not the place to discuss the merits of such an approach. This
would be better served in other mailing lists (either AAA, RADIUS-EXT or
perhaps in 802.11r). That said, let some other group define the specific
mechanism but CAPWAP shouldn't explicitely prevent this behavior in its
charter. I am not stating that 802.11r is in some way replicating CAPWAP
or AAA work - it is completely orthogonal.

PatC 

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Monday, October 25, 2004 1:07 PM
To: Pat R. Calhoun; Walker, Jesse; Russ Housley
Cc: Yang, Lily L; [email-masked]
Subject: Re: [Capwap] Important: please provide input on comment

Pat,

From an architectural standpoint, the AAA server is the only functional
entity in the network that everybody trusts, so it has to be an
important part of the solution somehow. Since AAA is an IETF function,
the IETF has to be involved, and actually is probably the better body to
do the technical work, since the technical expertiese is in IETF.

Exactly how that plays out with 802.11r/CAPWAP, I am not sure, primarily
because I don't have a very good idea about what 802.11r does (and,
after spending a frustrating 10 minutes browsing around the confusing
802.11 Web site and failing to find the PAR, I've not been able to find
out by myself either). If .11r is primarily concerned with host to
network protocol, then I think CAPWAP might be a good place to do the
work in IETF, or the AAA WG (though I believe they are on the verge of
closing). If .11r is involved in network to network, then I am not so
sure, it would depend on what .11r is intending.

Perhaps the right time to discuss this is when .11r gets its
requirements together, but I do think it will need to be discussed in
IETF at some point.

            jak

----- Original Message -----
From: "Pat R. Calhoun" <[email-masked]>
To: "Walker, Jesse" <[email-masked]>; "Russ Housley"
<[email-masked]>
Cc: "Yang, Lily L" <[email-masked]>; <[email-masked]>
Sent: Monday, October 25, 2004 11:19 AM
Subject: RE: [Capwap] Important: please provide input on comment
resolution for CAPWAP Taxonomy draft

That's a topic that I will not bother polluting this specific list with.
However, regardless of the end solution, I do believe that what we are
both agreeing to is that the CAPWAP architecture makes this solution
possible once the actual problem has been addressed.

PatC

-----Original Message-----
From: Walker, Jesse [mailto:[email-masked]]
Sent: Monday, October 25, 2004 10:48 AM
To: Pat R. Calhoun; Russ Housley
Cc: Yang, Lily L; [email-masked]
Subject: RE: [Capwap] Important: please provide input on comment

Pat,

Your assertion that 802.11r is addressing the problem is not obviously
correct. Any solution that works will involve interaction between the
client, the AP or AC, and the AAA server. This is because the AAA server
is the only party available that the client trusts to make assertions
about its relationship with the Authenticator. This unfortunately means
that the solution is outside the scope of 802.11 and can only be dealt
with in IETF.

I think 802.11r can specify its requirements for solutions to this
problem, or it can draft the kind of solution it would like to see and
then request that the IETF accept its proposed solution as a work item.
I do not believe 802.11r can define the solution itself.

-- Jesse

-----Original Message-----
From: Pat R. Calhoun [mailto:[email-masked]]
Sent: Monday, October 25, 2004 10:40 AM
To: Russ Housley
Cc: Walker, Jesse; Yang, Lily L; [email-masked]
Subject: RE: [Capwap] Important: please provide input on comment

Correct, and 802.11r is looking at that problem. The CAPWAP architecture
"enables" 802.11r to function.

PatC

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Monday, October 25, 2004 10:32 AM
To: Pat R. Calhoun
Cc: Walker, Jesse; Yang, Lily L; [email-masked]
Subject: RE: [Capwap] Important: please provide input on comment

Pat:

You are correct.  In the CAPWAP environment, the PMK is shared with many
WTPs.  However, the STA has no way to figure out which WTPs out to have
access to the PMK.  This needs to be solved before the PMK can be
effectively shared.

Russ

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

>in that case only 4 way key handshake is requried to get the PTK. With

---

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

Jesse,

  Common courtesy dictates that one should not merely state "you are
wrong" but to explain exactly where one is wrong.

  Abstract language is getting in the way of my point so let me
just use common vernacular that is descriptive of what is deployed
today:

  If I can try to boil this down I think the residue we will be left
with is that you believe that there is a one-to-one relationship
between a RADIUS client and a BSSID that a supplicant speaks to and
that the identity of the RADIUS client and BSSID are interchangable.
It is that belief, I believe, that causes you to infer a binding of
PMK to BSSID when, strictly speaking, none exists.

  The RADIUS server has a trust relationship with a RADIUS client.
That RADIUS client is identified, to the RADIUS server, with an IP
address. You are assuming that that RADIUS client, identified by
its IP address, has one and only one BSSID. This is incorrect.
Furthermore you are assuming that this 3 way protocol between the
supplicant, the RADIUS server, and the RADIUS client is 1) secure;
and 2) extensible to a different identity of the RADIUS client, a
BSSID, without loss of security.

  Feel free to tell me I'm wrong again, but please tell me where
and how.

  Dan.

On Mon, 25 Oct 2004 13:03:24 PDT you wrote
> Dan,
> 
> You are wrong. The problem is there is no Needham-Shroeder-eseque
> protocol in the back end.
> 
> -- Jesse
> 
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Monday, October 25, 2004 12:58 PM
> To: Yang, Lily L
> Cc: [email-masked]; Walker, Jesse; [email-masked]
> Subject: Re: FW: [Capwap] Important: please provide input on comment
>   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
> > 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.
> > 
> > Sent: Saturday, October 23, 2004 7:05 PM
> > 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
> > 
> > Sent: Friday, October 22, 2004 12:03 PM
> > 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
> > 
> > Behalf Of Dan Harkins
> > Sent: Thursday, October 21, 2004 9:47 AM
> > To: Chunduru Rama Krishna Prasad
> > Cc: [email-masked]
> >   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,
> > > 
> > > 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

---

From: Dan Harkins <[email-masked]>
Date: Mon, 25 Oct 2004 15:05:15 -0700

Jesse,

  You are not addressing any of the issues I raised in response to
your previous demand for a deterministic algorithm, you're just
repeating yourself. I was trying to point out how the security of
the system is not lessened by the lack of such an algorithm. I
asked you to show me where in that email I was wrong and how I
was wrong. I even added some more analysis of what I think is the
crux of the matter. You ignored it all. 

  Sigh,

  Dan.

On Mon, 25 Oct 2004 14:28:16 PDT you wrote
> Dan,
> 
> I have already explained this, but will do so again out of common
> courtesy. Please provide a deterministic algorithm by which a client
> determines whether PMK sharing between AP1 and AP2 is acceptable or
> represents a compromise, using information available to it under
> 802.11i. If you produce such an algorithm, then I withdraw my claim and
> apologize. If you cannot, then my assertion stands.
> 
> -- Jesse
> 
> Sent: Monday, October 25, 2004 1:56 PM
> To: Walker, Jesse
> Cc: Yang, Lily L; [email-masked]; [email-masked]
> > > > I am not sure, I am right on this. My impression is that, PMK is
> on
> > > per

---

From: Dan Harkins <[email-masked]>
Date: Mon, 25 Oct 2004 16:53:32 -0700

Jesse,

  That same argument can be made against the existing 3 party exchange
between the supplicant, authentication server, and authenticator.
In fact, the existing 3 party exchange could be viewed as the degenerate
case of "PMK sharing".

  When the AP asserts possession of the PMK the supplicant has no
way of knowing whether that AP is a valid, trusted AP or is an attacker
that has compromised another AP (or the AP <--> AS connection) and
is playing man-in-the-middle.

  The reason this is so is because the supplicant never told the
authentication server to share the PMK with an entity identified by
a particular BSSID (and the authentication server does not maintain
a relationship with an entity identified by BSSID anyway), nor did
the AP provide some "ticket" to the supplicant proving that it is
trusted by the authentication server to know this secret. Either of
which would've made this exchange more secure.

  Can you show me some deterministic way for a supplicant to distinguish
between these two:

  1. the AAA client (entity trusted by the AS) and radio (that
     entity identified by a BSSID that the client is speaking to) are
     different parts of the same device and within the same security
     boundary.

  2. the AAA client is on an AP that has been compromised by an
     attacker and the radio with which the supplicant is communicating
     is on the attacker. The attacker relays the EAP exchange through
     the compromised AP and obtains the PMK.

If not then I maintain that there is no less security by doing "PMK
sharing". You're including two things in a cryptographic boundary--
the AAA client and radio-- that are not cryptographically bound
and are asking the supplicant to make a leap of faith. I can just
as easily draw a different cryptographic boundary and ask the
supplicant to make an _identical_ leap of faith. You can't have it
both ways, if it's OK for the existing 3 party exchange then it's
OK for "PMK sharing". 

  Dan.

On Mon, 25 Oct 2004 15:44:13 PDT you wrote
> Dan,
> 
> Let me go through this yet again.
> 
> In the 802.11i we discussion we said over and over and over and over
> again that the PMK must be kept within a single crypto boundary or it is
> compromised.
> 
> Now, if you have two classical APs, they represent separate crypto
> boundaries, because if you share a PMK between them and you compromise
> one AP, then the client's traffic is compromised at the other, while if
> you don't share PMKs between them then compromise of one does not lead
> to compromise of the client's traffic at the other.
> 
> It follows from the crypto boundaries argument, that different classical
> APs must be provisioned with independent PMKs. When this is not done,
> the client must treat its own PMK shared across different classical APs
> as a violation of its (the client's) security policy, because PMK
> sharing explicitly violates the crypto boundaries principle.
> 
> Under 802.11, 802.11i, 802.1X, and EAP the client does not learn whether
> an AP is a classical AP or a new switched AP such as what would be
> described by CAPWAP. The only thing 802.11 and 802.11i and 802.1X and
> EAP provide the client to distinguish one AP from another is the AP's
> BSSID. This means every AP looks like a classical AP to a client using
> the existing standardized 802.1, 802.11i, 802.1X, and EAP.
> 
> Since the client cannot tell a classical AP from a switched AP, it
> follows that a switched AP cannot share PMKs among its different
> light-weight APs, because doing so violates the client's security
> policy. That is, unless and until it receives evidence to the contrary,
> the client must assume that it is communicating with a classical AP, and
> PMK reuse between two classical APs violates its policy by violating the
> crypto boundary principle. The reason why it must assume this is that it
> does not and cannot know the contrary, and security says the client must
> make the most conservative assumption consistent with the facts known to
> it (performance, manageability, etc., might argue something else, but we
> are discussing security here).
> 
> I don't know what is not clear about this.
> 
> -- Jesse 
> 
> Sent: Monday, October 25, 2004 3:05 PM
> To: Walker, Jesse
> > > > technical editor of 11i, I think it would be good that we keep
> them
> > in
> > > > always assume its PMK has been compromised when it sees either
> case.
> > I
> > > > situation is even MORE secure than the traditional deployment
> where
> > a
> > > > STA

---

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 26 Oct 2004 09:39:32 -0700

Didn't work last time. One more try. Sorry if you receive duplicates of
this.

________________________________________
From: Yang, Lily L 
Sent: Tuesday, October 26, 2004 9:01 AM
To: Walker, Jesse; 'Dan Harkins'; [email-masked]'
Cc: [email-masked]'
Subject: RE: FW: [Capwap] Important: please provide input on comment
resolution for CAPWAP Taxonomy draft 

I tried to send this out last night but it never made it into the list
due to its size... here I truncated all the previous trailing postings
and hope it will make it to the list this time.
--------------

First of all, let me thank all of you, for the lively discussion we've
had on this important issue. It certainly helps me a lot personally to
understand the issue better.

IMHO, the debate and confusion here highlights one of the challenges
that Centralized Architecture brings to the current 802.11 standard:
while "WTP+AC"="Logical AP" seems like a logical assertion, it is not
always true that such functional split produces no ambiguity with
respect to the 802.11 standard. 

Most of time, when .11 standard talks about an AP, we can take it as a
logical AP, not a physical device, and the standard remains valid even
if the logical AP functions are implemented across two physical devices.
However, when 11i talks about AP as the "authenticator", I take it that
it means the AP in the physical sense, that is, a *single physical
device*. But when we split 11i functions into WTP and AC, unless one
device (that is, either AC or WTP, but not both) consistently plays the
role of "authenticator" in all the 11i functions, including 4-way
handshake, authenticator state machine, etc, we would be in trouble
because we are violating the basic architecture assumption that 11i
makes. Therefore it is important to acknowledge the potential security
risks associated with 11i functional split. 

On the other hand, it is not within the scope of CAPWAP taxonomy draft
to explicitly identify the potential solutions and where such solutions
should come from, etc. It is valuable discussion that we should have
sooner or later in some forum (either here or somewhere else), but it is
not yet critically important for us to resolve that within this draft.

But it *is* critically important for us to resolve how to fix the
taxonomy draft so that the additional security concerns due to the
functional split are properly documented so that we can close on this
draft and move on to the next steps.

Therefore, I would encourage that we focus our discussion on how to best
describe the additional security challenges for client data protection.
Remember that one of the motivations to use Centralized Architecture is
to enhance the security, not to lessen it, relatively to the traditional
"Autonomous Architecture".

The paragraph in question is 4.8.1:
"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."

The issue at hand is whether or not PMK can be reused across multiple
WTPs as defined in 11i today, without introducing additional security
risks.

I would like to take a step back, and go back to the original categories
that Inderpreet provided and refine on it and see if we can agree on the
following analysis:

Case 1: If AC handles all 11i functions (key mgmt, privacy & integrity
encryption, etc.) and functions fully as the "authenticator" without WTP
getting invovled, then there is no additional security issue from 11i's
point of view. (Note we are talking about client data security here only
in 4.8.1, not AC-WTP control message security which is covered in
4.8.2).

Case 2: If 11i is split between AC and WTP in the way that AC handles
all Authentication and Key Management (for PMK and PTK), but WTP handles
privacy and integrity encryption, then it is necessary for WTP to
possess PTK (but not PMK), therefore it is necessary to guarantee a
secure way to transfer PTK from AC to WTP. Provided that this additional
requirement is met, this functional split is still a relatively safe
usage model with respect to 11i, because only the AC (acting as the
authenticator) possesses PMK, similar to the case in Autonomous
Architecture where AP possesses PMK. But I would argue that this split
still maintain the security "advantage" argument of Centralized
Architecture because AC typically can assume better physical security
than AP, and there are typically significantly fewer ACs in Centralized
Architecture than the APs.

Case 3: If 11i is split between AC and WTP in the way that AC handles
.1X/EAP Authentication (as the authenticator, possesses PMK), but WTP
handles 4-way handshake and encryption, then it is necessary for WTP (in
addition to AC) to possess PMK as well. I would argue that such split
would weaken the network security, because now PMK is exposed to WTP,
and the physical security of a large number of WTPs is one of the
challenges that motivated the Centralized Architecture at the first
place. If PMK is shared among multiple WTPs (to support roaming or
whatever other functions), it would further weaken the security of the
network as explained by Jesse. Therefore, such a functional split seems
to present more security challenges than Case 1 and 2. It doesn't mean
that it can't be done; it just means that additional work on security
might be necessary to ensure that the security of the network is not in
any way reduced (similar to the goal in 11r as articulated by Clint). 

So it seems to me that the security considerations would vary depending
on how the 11i functions are split between AC and WTP. The CAPWAP
taxonomy draft should highlight the different security considerations
without getting into the solution space.

Lily

---

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 26 Oct 2004 09:00:34 -0700

--------------

 

Lily

---

From: "Walker, Jesse" <[email-masked]>
Date: Tue, 26 Oct 2004 10:43:24 -0700

Dan,

My arguments are not convincing to you, and yours are not to me. We will
just have to disagree. Best wishes on your position.

-- Jesse

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Tuesday, October 26, 2004 10:05 AM
To: Walker, Jesse
Cc: Yang, Lily L; [email-masked]; [email-masked]
Subject: Re: FW: [Capwap] Important: please provide input on comment

  Jesse,

  I know you didn't appeal to the 3 party protocol; I did. I was
pointing
out that it suffers from exactly what you claim "PMK sharing" suffers
from. 

  I cannot provide you with a deterministic algorithm to allow a
supplicant to know whether or not the PMK was compromised when doing
"PMK sharing" but you also cannot provide a deterministic algorithm
to allow a supplicant to know whether or not the PMK was compromised
in the 3 party protocol (i.e. even without "PMK sharing"). 

  It seems somewhat disingenuous for you to claim that "PMK sharing"
is bad and insist on someone providing you with a deterministic
algorithm while simultaneously ignoring exactly the same problems
with the 3 party protocol (and conveniently not demanding a
deterministic algorithm for that).

  Earlier in this thread you asked how a "properly implemented" 
supplicant would know, when PMKs are shared, whether AP2 was an
attacker that compromised AP1 or not. I said by exactly the same
method a "properly implemented" supplicant knows that the PMK
asserted by the AP in the 3 party protocol was compromised or not.
You seem to think there is a reason for the supplicant to believe
in the 3 party protocol. OK, great! Then by that same reasoning
it should believe in the integrity of a PMK that is shared.

  Let me close this increasingly tedious thread by noting:

	- "PMK sharing" is, indeed, allowed in the 11i draft
	  as Jesse alluded to earlier when he mentioned, as
	  option (c), that the text could be removed.

	- "PMK sharing" is not free of security considerations,
	  but then 11i is based on a protocol which, itself,
	  is not free of security considerations and suffers
	  from exactly the same issues that "PMK sharing" does.

	- The upside of "PMK sharing" is that a AAA server will
	  not be hammered by supplicants in problematic RF
	  environments, and handoffs can happen in sub 50ms.
	  The downside is that there are security considerations
	  to it, but then if those security considerations were
	  enough to make you not support "PMK sharing" then
	  you should not support 11i.

  Dan.

On Tue, 26 Oct 2004 06:46:17 PDT you wrote
> Dan,
> 
> Please reread my last message. Nowhere did I appeal to the use of a
> 3-party protocol. The argument was based solely on the configuration
of
> state, regardless of how it was delivered. The problem is the quite
> reasonable usage CAPWAP wants to make never took into account that the
> infrastructure has to recognize and accommodate the EAP Peer's
security
> policy as well as vice versa. There are at least two ways CAPWAP could
> accommodate the EAP Peer's security policy. One way is to not share
> keys. A second way is to rely on a key binding protocol. Either
approach
> can be made to work.
> 
> You are right in one way; the discussion isn't just about CAPWAP;
there
> is a problem with the basic EAP keying model, and that, not CAPWAP, is
> the prey in this hunt. The problem with the EAP keying model is that
it
> never establishes a contract governing the behavior of the EAP Peer's
> and NAS's use of what it calls the MSK.
> 
> -- Jesse
> 
> Sent: Monday, October 25, 2004 4:54 PM
> To: Walker, Jesse
> > again that the PMK must be kept within a single crypto boundary or
it
> > crypto boundary principle. The reason why it must assume this is
that
> > make the most conservative assumption consistent with the facts
known
> to
> > it (performance, manageability, etc., might argue something else,
but
> we
> > > 802.11i. If you produce such an algorithm, then I withdraw my
claim
> > and
> > > >   There is no way for a "properly implemented" client to know
that
> > the
> > > > 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
> > > > security issue </nudge></nudge></wink></wink> and believe we
have
> > > > tication server (or the link between the authentication server
and
> > > > > I solicited input from Jesse Walker and Russ Housley on the
> issue
> > of
> > > > PMK
> > > > > forward this to the CAPWAP list. I also cc Jesse and Russ
here.
> > > Since
> > > > > the loop with regard this discussion. So please cc them in
your
> > > email
> > > > > Dan's reasoning is invalid, unless he or someone else can
> produce
> > a
> > > > > 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
> > > > > 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
> > > > > authenticated identifier to the EAP Peer in an attestable
> fashion,
> > > and
> > > > > I believe possibilities (a) or (b) are the right way to
address
> > this
> > > > > 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
> > am
> > > > > From: [email-masked]
> [mailto:[email-masked]]
> > > On
> > > > > Behalf Of Dan Harkins
> > > > >   Strictly speaking the PMK is shared between the supplicant
and
> > the
> > > > >   As the person who got PMK caching and PMKIDs into the
802.11i
> > > draft
> > > > >     in an associate request. If the authenticator had a cached
> PMK
> > > for
> > > > >     request. That enabled the functionality you describe
below--
> > > "the
> > > > >     this idea). So the next motion was to name PMKs with a
PMKID
> > > > >   Addressing Russ's comment, the PMK is already leaked because
> it
> > is
> > > > > certain cryptographic properties associated with that state.
If
> 1
> > > > > but if more than 1 person knows your secret then it doesn't
> matter
> > > if
> > > > >   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
> > > > > OK, fine. The other AP is also "trusted" to have the PMK so
now
> 4
> > > > > PMK isn't shared among the APs, it resides on the switch.
There
> > > > > guess) in which the switch plays the role of the
authentication
> > > server
> > > > > establishes a PMK with a RADIUS server and that PMK is leaked
to
> > an
> > > > > > I am not sure, I am right on this. My impression is that,
PMK
> > > > > > 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

---

From: "Paul Lambert" <[email-masked]>
Date: Tue, 26 Oct 2004 14:33:20 -0700

Jesse,

I think I see your point ..., let me try to rephrase:

How does a client obtain the PMK and associated PMKID in a 'secure'
manner? 

This is an open 'problem' that allows vendors to field proprietary
mechanisms to establish the PMK and PMKID bindings.  Now, I thought this
was a planned feature ... that requires future work for
interoperability.

So, I think I see your point, more work is required, but we really
should allow multiple BSSIDs to share the same PMKID and PMK.  Future
work is required to provide the automated distribution if the BSSIDs are
not co-located.

Paul

> [mailto:[email-masked]] On Behalf Of Walker, Jesse
> Sent: Tuesday, October 26, 2004 10:43 AM
> To: Dan Harkins
> Subject: RE: FW: [Capwap] Important: please provide input on 
> comment resolution for CAPWAP Taxonomy draft 
> 
> Dan,
> 
> My arguments are not convincing to you, and yours are not to 
> me. We will just have to disagree. Best wishes on your position.
> 
> -- Jesse
> 
> Subject: Re: FW: [Capwap] Important: please provide input on 
> comment resolution for CAPWAP Taxonomy draft 
> 
>   Jesse,
> 
>   I know you didn't appeal to the 3 party protocol; I did. I 
> was pointing out that it suffers from exactly what you claim 
> "PMK sharing" suffers from. 
> 
>   I cannot provide you with a deterministic algorithm to 
> allow a supplicant to know whether or not the PMK was 
> compromised when doing "PMK sharing" but you also cannot 
> provide a deterministic algorithm to allow a supplicant to 
> know whether or not the PMK was compromised in the 3 party 
> protocol (i.e. even without "PMK sharing"). 
> 
> is bad and insist on someone providing you with a 
> deterministic algorithm while simultaneously ignoring exactly 
> the same problems with the 3 party protocol (and conveniently 
> not demanding a deterministic algorithm for that).
> 
> supplicant would know, when PMKs are shared, whether AP2 was 
> an attacker that compromised AP1 or not. I said by exactly 
> the same method a "properly implemented" supplicant knows 
> that the PMK asserted by the AP in the 3 party protocol was 
> compromised or not.
> You seem to think there is a reason for the supplicant to 
> believe in the 3 party protocol. OK, great! Then by that same 
> reasoning it should believe in the integrity of a PMK that is shared.
> 
> >   When the AP asserts possession of the PMK the supplicant 
> has no way 
> > of knowing whether that AP is a valid, trusted AP or is an
> attacker
> > that has compromised another AP (or the AP <--> AS 
> connection) and is 
> > playing man-in-the-middle.
> > 
> > authentication server to share the PMK with an entity 
> identified by a 
> > particular BSSID (and the authentication server does not maintain a 
> > relationship with an entity identified by BSSID anyway), 
> nor did the 
> > AP provide some "ticket" to the supplicant proving that it 
> is trusted 
> > by the authentication server to know this secret. Either of which 
> > would've made this exchange more secure.
> > 
> > the AAA client and radio-- that are not cryptographically bound and 
> > are asking the supplicant to make a leap of faith. I can just as 
> > easily draw a different cryptographic boundary and ask the 
> supplicant 
> > to make an _identical_ leap of faith. You can't have it 
> both ways, if 
> > it's OK for the existing 3 party exchange then it's OK for "PMK 
> > sharing".
> > 
> >   Dan.
> > 
> > > one AP, then the client's traffic is compromised at the 
> other, while
> > if
> > > the client must treat its own PMK shared across different 
> classical
> > APs
> > > the client must assume that it is communicating with a 
> classical AP,
> > and
> > > PMK reuse between two classical APs violates its policy 
> by violating
> > the
> > > does not and cannot know the contrary, and security says 
> the client
> > must
> > > the system is not lessened by the lack of such an 
> algorithm. I asked 
> > > you to show me where in that email I was wrong and how I 
> was wrong. 
> > > I even added some more analysis of what I think is the 
> crux of the 
> > > > >   If this was a Needham-Schroeder-esqe protocol Jesse 
> might have
> a
> > > > > point. But it's not.
> > > > > 
> > > > > 3-party authenticaiton system here so that we can 
> then condemn a
> > > > scheme
> > > > >   How does a "properly implemented" client know that 
> AP2 is not
> a
> > > > > legitimate authenticator). Since a "properly 
> implemented" client
> > can
> > > > >   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
> > > > > > sharing, and here is the response from Jesse. He 
> agrees to let
> > me
> > > > > > Russ posted the original comment in IESG review, 
> and Jesse is
> > the
> > > > > > deterministic algorithm that allows the client to 
> distinguish
> > the
> > > > > > following two cases:
> > > > > > 
> > > > > > server, so this implies a new binding protocol 
> between the AAA
> > > > server
> > > > > > and the EAP Peer.
> > > > > 
> > > > > > forwarding to you this and I would like to hear 
> what you think
> > > about
> > > > > > these responses. 
> > > > > > 
> > > > > > Lily
> > > > > > 
> > > > > >     from ping-ponging back and forth between APs 
> and hammering
> > an
> > > > > >     authentication server.
> > > > > > 
> > > > > >     for a particular STA in its cache. How? Via 
> something like
> a
> > > > > > pro-active
> > > > > > multiple APs. The statement "If PMK is shared 
> across multiple
> > > WTPs"
> > > > > is,
> > > > > > indeed, valid.
> > > > > > 
> > > > > > values: 0, 1 and infinity. If 0 other people know 
> your secret
> > > there
> > > > > are
> > > > > > so the PMK is known only by the switch and the STA. 
> This "PMK
> > > > sharing"
> > > > > > > already established PMK before, then station 
> sends PMKID and 
> > > > > > > in that case only 4 way key
> > > handshake
> > > > > is
> > > > > > > requried to get the PTK.
> > > > > > > '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
> > > > > > > Uma Plaza, Nagarjuna circle, Panjagutta. 
> Hyderabad, AP Tel 
> > > > > > > No:s  2335 8927/8928/8434
> > > > > > >