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

From: "Cheng Hong" <[email-masked]>
Date: Fri, 6 Oct 2006 11:45:37 +0800

Hi Charles and all,

To specify a "default" value means specifying it to "zero". Otherwise,
it would not work. Say, the "default" value is set to 100, but the
actual sequence number used could be 50 at the moment. It means the STA
is not able to receive the Broadcast/Multicast packets for the next 50
seqeunce count.

So, I think we need some clarification on what is the decision here. Is
the decision now:
- No change to the protocol design except some security disclaimers.
And, specify a default value (0) to be used by the AC always.

Or, We also allow:
- The WTP and AC can choose to implement info exchange methods (a simple
element to be specified in the draft). However, if some AC choose not to
support such mechanism, it will have to set the KeyRSC to zero. And a
security disclaimer to state what is the effect of setting the KeyRSC to
zero.

cheers

Cheng Hong

> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Friday, October 06, 2006 9:24 AM
> To: Dorothy Stanley
> Cc: capwap
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> 
> We'd definitely need to specify a value for keyRSC in the 
> appropriate section.  That would be in addition to the 
> changes to the security considerations.  Without specifying a 
> default value, we could have interoperability issues between 
> WTPs and ACs.
> 
> --
> t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
> 
> Dorothy Stanley wrote:
> > Behcet,
> > 
> > My understanding of Scott's recommendations is that  text be added 
> > into the security considerations section.
> > - no additional CAPWAP protocol exchange between the WTP and AC
> > - no specification of setting the keyRSC value to 0.
> > 
> > Without some specification in the protocol, how can the WTP provide 
> > the KeyRSC info to the AC in a way that the AC is sure to 
> understand?
> > The most we can say
> > with respect to the standard is that an AC implementation 
> is free to 
> > comes up with its own algorithm to set the keyRSC value.
> > 
> > Dorothy
> > 
> > On 10/5/06, *Behcet Sarikaya* <[email-masked] 
> > <mailto:[email-masked]>> wrote:
> > 
> >     I agree with this and suggest adding Peter's fix as a 
> possibility.
> >     As far as interoperability is concerned, value 0 is 
> interoperable
> >     but not correct. If we allow implementations to snif in 
> and modify
> >     then any value should be acceptable which may be a concern for
> >     interoperability?
> > 
> >     ----- Original Message ----
> >     From: Scott G. Kelly < [email-masked]
> >     <mailto:[email-masked]>>
> >     To: capwap <[email-masked] <mailto:[email-masked]>>
> >     Sent: Thursday, October 5, 2006 3:15:40 PM
> >     Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> > Considerations
> > 
> >     Following up once again - after careful review, I still 
> agree with
> >     Charles, and here's some suggested text for the 
> security considerations:
> > 
> >     13.5.  IEEE 802.11 Security
> > 
> >         When used with an IEEE 802.11 infrastructure with WEP
> >     encryption, the
> >        CAPWAP protocol does not add any new 
> vulnerabilities.  Derived
> >        session keys between the STA and WTP can be 
> compromised, resulting in
> >        many well-documented attacks.  Implementors SHOULD 
> discourage the use
> >        of WEP and encourage use of technically sound cryptographic
> >     solutions
> >        such as those in an IEEE 802.11 RSN.
> > 
> >        When used with IEEE 802.11 RSN security, the CAPWAP protocol
> >        may introduce new vulnerabilities, depending on 
> whether the link
> >     security
> >       (packet encryption and integrity verification) is 
> provided by the
> >     WTP or the AC.
> >        When the link security function is provided by the AC, no new
> >     security
> >        concerns are introduced.
> > 
> >        However, when the WTP provides link security, a new 
> vulnerability
> >     will
> >        exist when the following conditions are true:
> > 
> >         o the client is not the first to associate to the WTP/ESSID
> >             (i.e. other clients are associated), and a GTK already 
> > exists
> > 
> >             o traffic has been broadcast under the existing GTK
> > 
> >        Under these circumstances, the receive sequence 
> counter (KeyRSC)
> >        associated with the GTK is non-zero, but because the 
> AC anchors the
> >        4-way handshake with the client, the exact value of 
> the KeyRSC is not
> >        known when the AC constructs the message containing the GTK.
> >        The client will update its Key RSC value to the 
> current valid KeyRSC
> >        upon receipt of a valid multicast/broadcast message, 
> but prior to
> >     this,
> >        previous multicast/broadcast traffic which was 
> secured with the
> >     existing
> >        GTK may be replayed, and the client will accept this 
> traffic as
> >     valid.
> > 
> >        Typically, busy networks will produce numerous 
> multicast or broadcast
> >        frames per second, so the window of opportunity with 
> respect to such
> >        replay is expected to be very small. In most 
> conditions, it is
> >     expected that
> >        replayed frames could be detected (and logged) by the WTP.
> > 
> >        The only way to completely close this window is to 
> provide the
> >        exact KeyRSC value in message 3 of the 4-way handshake; any
> >        other approach simply narrows the window to varying 
> degrees. Given
> >        the low relative threat level this presents, the additional
> >     complexity
> >        introduced by providing the exact KeyRSC value is 
> not warranted.
> >     That
> >        is, this specification provides for a calculated 
> risk in this regard.
> >     ==>
> >     However, WTP implementations MAY provide the exact KeyRSC value
> >     before forwarding message 3 of the 4-way handshake.
> > 
> >     --behcet
> > 
> >     
> _________________________________________________________________
> >     To unsubscribe or modify your subscription options, 
> please visit:
> >     http://lists.frascone.com/mailman/listinfo/capwap
> > 
> >     Archives: http://lists.frascone.com/pipermail/capwap
> >     <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: Fri, 06 Oct 2006 08:33:24 -0400

You're suggesting the disclaimer and "static initialization value" 
(perhaps more accurate term than a "default value") would be mandatory 
to implement, and there would also be an optional information exchange 
to synchronize the KeyRSC to something else.  That certainly sounds like 
a good compromise, but I suspect a little more complicated to implement 
than it first appears.  For example, the WTP would need to communicate 
it's ability to be queried for the KeyRSC to the AC during initialization.

---

From: Scott G Kelly <[email-masked]>
Date: Fri, 06 Oct 2006 06:28:18 -0700

Hi Cheng,

I think we have to make the security disclaimer no matter what, as there 
is a small window of opportunity unless you precisely synchronize the 
KeyRSC (which I think most agree is more complex than the resulting 
exposure warrants).

As for setting the value, we could be rigid and require it to be set to 
zero, or we could be a little less precise, and leave some discretion 
here. The only requirement for interoperability is that the WTP *accept* 
any value, regardless of what its current KeyRSC value is (which is also 
true if we require "0"). Of course, if the AC sends the wrong value 
(i.e. a value greater than the actual KeyRSC), this will be a problem 
for the STA, and I think all would agree that this particular 
implementation is broken.

On the other hand, strictly requiring the AC to send zero precludes a 
vendor of a "compliant" implementation from implementing some heuristic 
or workaround which narrows the window. Frankly, I'm not certain that 
any such workaround exists (short of some yet to be defined WTP/AC 
exchange), but I guess the question is, should we firmly slam this door 
shut, or should we specify only the necessary and sufficient text for 
interoperability?

I think leaving the value unspecified might be a better approach.

Scott

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 6 Oct 2006 09:39:05 -0400

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

---