Subject: [Capwap] Proposed resolution to Isse 43/ wasRe: Security Considerations

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 28 Nov 2006 14:05:17 -0800

All,

In San Diego, we reviewed the 4 different options for dealing with the
KeyRSC value issue:

1. Extend the IEEE 802.11 Binding to deliver the KCK to the WTP
2. Extend the IEEE 802.11 Binding to deliver the GTK KeyRSC from the WTP to
the AC
3. Document the issue in the IEEE 802.11 binding document security
considerations section,
do not extend the protocol, and provide no implementation advice
4.Document the issue in the IEEE 802.11 binding document security
considerations section,
do not extend the protocol, and add text to indicate that the "AC shoule set
the KeyRSC value to zero
or other value".

 1.

2.
3.
–
4
–
 There seemed to be agreement on proceeding with option #4. Below is
proposed text, taken
from previous postings (Scott, Margaret) to implement option 4.

Comments welcome,

Thanks,

Dorothy
---------------------------------------------------------------------------------------------------------------------------------

Proposed Resolution:

In draft-ietf-capwap-protocol-binding-ieee80211-00, change section 9.1 from

9.1 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.

   STA authentication is performed using IEEE 802.lX, and consequently
   EAP.  Implementors SHOULD use EAP methods meeting the requirements
   specified [6].

to

9.1.  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.

   STA authentication is performed using IEEE 802.lX, and consequently
   EAP.  Implementors SHOULD use EAP methods meeting the requirements
   specified [6].

  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.

  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.

On 11/28/06, Saravanan Govindan <[email-masked]> wrote:
>
>  Hello All,
>
>
>
> Going back to Cheng Hong's earlier post, I think the Security
> Considerations section should include Scott Kelly's analysis on running
> 802.11i in the CAPWAP architecture.
>
>
>
> As to the recommendation involved, I continue to prefer the approach of
> assigning the KeyRSC at the WTP. In the interest of moving forward, I will
> support the WG's consensus decision on this.
>
>
>
> Cheers,
>
>
>
> Saravanan
>
>
>
> _________________________________________________________________
> 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: Margaret Wasserman <[email-masked]>
Date: Wed, 29 Nov 2006 10:28:48 -0500

Hi All,

Per standard IETF procedure, all consensus decisions reached at a WG  
meeting must be checked on the IETF mailing list.

In San Diego, we reached strong consensus of those present to close  
the KeyRSC issue (Issue #43) by including text about the tradeoffs in  
the IEEE 802.11 binding document security considerations section and  
stating that the AC should set the KeyRSC value to zero or a more  
optimal value.  Dorothy Stanley has proposed specific text below.

If you have tuning suggestions for Dorothy's text, please respond to  
Dorothy's e-mail from November 28th.

If anyone who was not present at the San Diego meeting has a strong  
objection to this course of action, please respond to this message by  
Wednesday, December 6th.  Please state why you object to this course  
of action and what course of action you would prefer.

Thanks,
Margaret

Begin forwarded message:

> From: "Dorothy Stanley" <[email-masked]>
> Date: November 28, 2006 5:05:17 PM EST
> To: "Saravanan Govindan" <[email-masked]>
> Cc: [email-masked]
> Subject: [Capwap] Proposed resolution to Isse 43/ wasRe: Security  
> Considerations
>
[snip]
>
> ---------------------------------------------------------------------- 
> -----------------------------------------------------------
>
> Proposed Resolution:
>
>  (packet encryption and integrity verification) is provided by the  
> WTP or the AC.
>   replay is expected to be very small. In most conditions, it is  
> expected that
> On 11/28/06, Saravanan Govindan  
> <[email-masked]> wrote:
> Hello All,
>
>
> Considerations section should include Scott Kelly's analysis on  
> running 802.11i in the CAPWAP architecture.
>
>
> As to the recommendation involved, I continue to prefer the  
> approach of assigning the KeyRSC at the WTP. In the interest of  
> moving forward, I will support the WG's consensus decision on this.
>
>
> Cheers,
>
>
> Saravanan
>
>
>

---

From: Charles Clancy <[email-masked]>
Date: Thu, 30 Nov 2006 07:26:06 -0500

I concur with option #4, and Dorothy's text.

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