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

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 30 Nov 2006 17:52:07 +0800

Hi Dorothy,

I actually agree with option 4. I would just like to suggest a slight
editorial to clarify one option for the KeyRSC vulnerability. 

Cheers,

Saravanan

 

________________________________

From: Dorothy Stanley [mailto:[email-masked]] 
Sent: Wednesday, November 29, 2006 11:12 PM
To: Saravanan Govindan
Cc: [email-masked]
Subject: Re: Proposed resolution to Isse 43/ wasRe: [Capwap] Security
Considerations

Hi Saravanan,

Adoption of  text proposed for consideration would lead us back to
option 1, since
the WTP cannot update a field in Message 3 without knowledge of the KCK.
Option 1 is not the option that seemed to be agreed to in San Diego, and
thus not consistent
with text for Option 4, which is what is intended here.

Thanks,

Dorothy

On 11/28/06, Saravanan Govindan <[email-masked]>
wrote: 

Hi Dorothy,

Thank you for the text.

This update is related to paragraph 7 of the proposed text.

Current proposed text:  

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

For consideration:

"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. This is achieved by the AC
sending message 3 of the 4-way exchange without setting the KeyRSC
field. The WTP then updates message 3 of the 4-way handshake with the
exact KeyRSC value. The exact KeyRSC value MAY be used to completely
overcome this vulnerability."

My concern here is about the WG defining design complexity. I think the
specification should let implementers decide what is complex. 

Cheers,

Saravanan 

 

________________________________

From: Dorothy Stanley [mailto:[email-masked]] 
Sent: Wednesday, November 29, 2006 6:05 AM
To: Saravanan Govindan
Cc: [email-masked]
Subject: Proposed resolution to Isse 43/ wasRe: [Capwap] Security
Considerations

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

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]
<mailto:[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