Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 10 Oct 2006 09:27:08 +0800

Pat,

The WTP does not need any additional key information since the issue at
hand considers the WTP to perform crypto functions. I do not think the
proposal introduces threats.

Also, given CAPWAP development is still in progress, I think we should
not preclude any item because it involves change - the protocol is not
yet complete. 

Saravanan

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Tuesday, October 10, 2006 1:39 AM
To: Saravanan Govindan; Cheng Hong; Scott G. Kelly; Margaret Wasserman
Cc: capwap
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

This would require the AC to send additional keying information to the
WTP, since message three needs to be authenticated. So I disagree with
this proposal. The change is much more sinificant than simply leaving
the field zero.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Monday, October 09, 2006 12:08 AM
> To: Cheng Hong; Scott G. Kelly; Margaret Wasserman
> Cc: capwap
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> 
> Hi Cheng Hong, Scott,
> 
> I share your concerns for setting the KeyRSC to 0. 
> 
> In my opinion, it is clear that the protocol is "broken" in 
> this case and needs to be fixed. 
> 
> My suggestion is to have the KeyRSC field be updated by the 
> WTP. So the AC could send Message-3 of the 4-way handshake to 
> the WTP with an empty KeyRSC field. The WTP could then 
> correctly update the field, compute the KeyMIC, update 
> Message-3 and then forward it to the STA. 
> 
> Of course, this requires a CAPWAP message from the AC and WTP 
> to exchange the incomplete Message-3. I think this is an 
> acceptable addition because it maintains the integrity of 
> 802.11i exchanges and provides a complete fix to the problem. 
> 
> Saravanan
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Cheng Hong [mailto:[email-masked]]
> Sent: Monday, October 09, 2006 1:21 PM
> To: Scott G. Kelly; Margaret Wasserman
> Cc: capwap
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> 
> Hi Scott,
> 
> Some comments below:
> 
> > After thinking long and hard about this, I can't bring 
> myself to agree 
> > with the suggested text. Quite frankly, I think always using an RSC 
> > value of 0 is a lazy hack, and given that we've acknowledged we are 
> > introducing a vulnerability here (however slight), telling 
> > implementors they SHOULD do this just doesn't sit right with me.
> > 
> > An enlightened implementation could almost certainly do better than 
> > always setting this to zero, and explicitly recommending 
> that people 
> > nail this window open just rubs me the wrong way. At least, 
> let's hold 
> > off on this decision until we've clearly defined what statistics we 
> > expect to be available. Seems like if we're going to tell 
> implementors 
> > what they SHOULD do, we SHOULD give them sound, well considered 
> > advice.
> 
> I absolutely agree with you on this point. 
> 
> What I was trying to state in my previous emails was:
> - I would against setting a static value for the KeyRSC as a 
> solution to this issue. 
> - However if the WG decided to go for a static value, the 
> draft should clearly point out that NOT all static value 
> could work (value other than zero may be a problem for 
> interoperability).
> - And the draft needs to clearly point out what is the danger 
> of setting a static KeyRSC value in the security 
> consideration section.
> - Also, the draft should not prohibit other implementation 
> for sync the KeyRSC value between WTP and AC (the CAPWAP 
> standard should not dictate such implementation incompatible). 
> 
> If there is a alternative solution than setting a static 
> KeyRSC value to narrow the window, I would vote for it.
> 
> cheers
> 
> Cheng Hong
> 
> 
> 
> > -----Original Message-----
> > From: Scott G. Kelly [mailto:[email-masked]]
> > Sent: Saturday, October 07, 2006 8:26 AM
> > To: Margaret Wasserman
> > Cc: capwap
> > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> > Considerations
> > 
> > Hi Margaret,
> > 
> > Comments inline below...
> > 
> > -----Original Message-----
> > >From: Margaret Wasserman <[email-masked]>
> > >Sent: Oct 6, 2006 9:39 AM
> > >To: Scott G Kelly <[email-masked]>
> > >Cc: Cheng Hong <[email-masked]>, capwap 
> > ><[email-masked]>
> > >Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> > >
> > >
> > >While I am not against leaving things open to more optimal 
> > >implementations, I do think that we need to add some text to the 
> > >protocol portion of the document (as well as the security
> > >considerations) to explain how this is handled.  How about 
> something
> > >like:
> > >
> > >The AC SHOULD use an RSC of 0 when computing message-3 of 
> the 4-way 
> > >802.11i handshake, unless the AC has knowledge of a more 
> optimal RSC 
> > >value to use.  Mechanisms for determining a more optimal RSC
> > value are
> > >outside the scope of this specification.
> > >
> > >I do not think that we should simply say nothing and hope that 
> > >implementors figure this out.
> > >
> > >Margaret
> > 
> > After thinking long and hard about this, I can't bring 
> myself to agree 
> > with the suggested text. Quite frankly, I think always using an RSC 
> > value of 0 is a lazy hack, and given that we've acknowledged we are 
> > introducing a vulnerability here (however slight), telling 
> > implementors they SHOULD do this just doesn't sit right with me.
> > 
> > An enlightened implementation could almost certainly do better than 
> > always setting this to zero, and explicitly recommending 
> that people 
> > nail this window open just rubs me the wrong way. At least, 
> let's hold 
> > off on this decision until we've clearly defined what statistics we 
> > expect to be available. Seems like if we're going to tell 
> implementors 
> > what they SHOULD do, we SHOULD give them sound, well considered 
> > advice.
> > 
> > Scott
> > 
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> > 
> > Archives: http://lists.frascone.com/pipermail/capwap
> > 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Charles Clancy <[email-masked]>
Date: Mon, 09 Oct 2006 22:18:25 -0400

Saravanan,

Your proposal requires the WTP to know the KCK to compute the MIC.

In both Split MAC and Local MAC, the 4-way handshake is executed between 
the AC and STA (hence the whole problem we're talking about).  After the 
handshake is complete, the PTK is transmitted to the WTP.  Currently 
there is no way for the WTP to know the KCK in any of the possible usage 
scenarios.

Key derivation process:

EAP MSK = 11i PMK  (transported from AAA server to AC after successful 
EAP authentication)

First two messages of 4-way handshake occurs between AC and STA and both 
the AC and STA now know SNonce, ANonce, SAddr, AAddr.

(KEK, KCK, PTK) = TK = KDF(PMK, SNonce, ANonce, SAddr, AAddr)

AC and STA now know KEK, KCK, PTK.

AC and STA use KCK to properly MIC messages 3 and 4 of handshake

If 11i is terminated at the WTP, the AC then transports the PTK to WTP.

At no point, and in no scenario, does the KCK currently get transported 
to the WTP.  An additional message would have to be inserted between 
messages 2 and 3 of the 4-way handshake to inform the WTP of the KCK.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy