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

From: Dan Harkins <[email-masked]>
Date: Tue, 26 Oct 2004 10:04:57 -0700

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
> 
> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Monday, October 25, 2004 4:54 PM
> To: Walker, Jesse
> Cc: Yang, Lily L; [email-masked]; [email-masked]
> Subject: Re: FW: [Capwap] Important: please provide input on comment
> resolution for CAPWAP Taxonomy draft 
> 
>   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 
> > 
> > -----Original Message-----
> > From: Dan Harkins [mailto:[email-masked]] 
> > Sent: Monday, October 25, 2004 3:05 PM
> > To: Walker, Jesse
> > Cc: Yang, Lily L; [email-masked]; [email-masked]
> > Subject: Re: FW: [Capwap] Important: please provide input on comment
> > resolution for CAPWAP Taxonomy draft 
> > 
> >   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
> > > 
> > > -----Original Message-----
> > > From: Dan Harkins [mailto:[email-masked]] 
> > > Sent: Monday, October 25, 2004 1:56 PM
> > > To: Walker, Jesse
> > > Cc: Yang, Lily L; [email-masked]; [email-masked]
> > > Subject: Re: FW: [Capwap] Important: please provide input on comment
> > > resolution for CAPWAP Taxonomy draft 
> > > 
> > >   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
> > > > 
> > > > -----Original Message-----
> > > > 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
> > > > resolution for CAPWAP Taxonomy draft 
> > > > 
> > > >   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.
> > > > > 
> > > > > -----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
> > > > > 
> > > > 
> > > 
> > 
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Walker, Jesse" <[email-masked]>
Date: Tue, 26 Oct 2004 06:46:17 -0700

Dan,

-- Jesse

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Monday, October 25, 2004 4:54 PM
To: Walker, Jesse
Cc: Yang, Lily L; [email-masked]; [email-masked]
Subject: Re: FW: [Capwap] Important: please provide input on comment

  Jesse,

  Dan.

is
if
classical
APs
whether
contrary,
and
the
it
must
to
we
comment
about
of
unpleasant
a
a
can
AP1
to
otherwise.
issue
me
the
produce
the
can
state.
the
fashion,
from
I
PMK
an 

it
possible
1
properties
matter
authenticator
4
is
is
AC