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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 9 Oct 2006 10:39:26 -0700

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 17:14:25 -0400

Slight clarification... my previous posts indicated that transporting 
the PMK to the WTP would break the security model.  To accomplish what 
Saravanan is talking about only requires transporting the KCK after 
message 2 of the 4-way handshake.

In the 11i keying hierarchy, the TK (made up of the KCK, KEK, and PTK) 
is derived from the PMK based on the 4-way-handshake.  We're already 
transporting the PTK from the AC to the WTP in this scenario for CCMP 
and TKIP to use.  Transporting the KCK too and allowing the WTP to 
perform the MAC doesn't break the current security model.

Now, as to whether or not it makes sense from an implementation 
standpoint, I'll leave to those with strong opinions than I.

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