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

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 5 Oct 2006 13:56:29 -0700 (PDT)

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]>
To: capwap <[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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 5 Oct 2006 14:53:58 -0700

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]> 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?
>
> Following up once again - after careful review, I still agree with
> Charles, and here's some suggested text for the security considerations:
>
> However, WTP implementations MAY provide the exact KeyRSC value before
> forwarding message 3 of the 4-way handshake.
>
> --behcet
>

---

From: Charles Clancy <[email-masked]>
Date: Thu, 05 Oct 2006 21:23:39 -0400

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:
> 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?
> 
>     From: Scott G. Kelly < [email-masked]
>     <mailto:[email-masked]>>
>     To: capwap <[email-masked] <mailto:[email-masked]>>
>     However, WTP implementations MAY provide the exact KeyRSC value
>     before forwarding message 3 of the 4-way handshake.
> 
>     --behcet
> 
>     <http://lists.frascone.com/pipermail/capwap>
> 
> 
> 
> ------------------------------------------------------------------------
>