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

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 9 Oct 2006 15:07:49 +0800

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

---

From: Scott G Kelly <[email-masked]>
Date: Mon, 09 Oct 2006 07:49:58 -0700

Hi Everyone,

I think I was careless in my wording, and that has led to some 
confusion. Charles already pointed out that splitting the authenticator 
role across the WTP and AC significantly changes the security model, and 
I thought our various posts on this made clear that the minimal security 
exposure resulting from KeyRSC imprecision does not warrant this level 
of change to the protocol.

However, what I meant to suggest in my Friday post was that rather than 
telling implementors they SHOULD set the value to zero right off the 
bat, we should hold off to see what sort of opportunities arise to 
derive a more accurate value from existing (or simply-added new) 
statistics. If it turns out that there are statistics from which an AC 
might unambiguously derive a "better" value, then (in my opinion) that's 
what implementors SHOULD use. However, we have yet to see if such a 
mechanism exists.

Scott

---

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

Hi Scott,

I am not sure the suggestion below affects any security model. As long as 
there is an established security framework between the AC and WTP, the 
suggested approach remains transparent.

Furthermore, given that the protocol is still in development, I think we 
should seriously consider all options.

Saravanan

----Original Message Follows----
From: Scott G Kelly <[email-masked]>
To: Saravanan Govindan <[email-masked]>
CC: Margaret Wasserman <[email-masked]>,capwap 
<[email-masked]>,Cheng Hong <[email-masked]>
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations
Date: Mon, 09 Oct 2006 07:49:58 -0700

Hi Everyone,

Scott

_________________________________________________________________
Find just what you are after with the more precise, more powerful new MSN 
Search. http://search.msn.com.sg/ Try it now.