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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 29 Nov 2006 06:41:48 -0800

I completely disagree because this would require the AC to push the
necessary keys for the WTP to protect messages 3 and 4. The protocol
does not currently define these mechanisms, and we've already had the
discussions on why it isn't a good idea.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Saravanan Govindan
[mailto:[email-masked]] 
	Sent: Tuesday, November 28, 2006 9:09 PM
	To: Dorothy Stanley
	Cc: [email-masked]
	Subject: Re: [Capwap] Proposed resolution to Isse 43/ wasRe:
SecurityConsiderations

	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]> 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: "Saravanan Govindan" <[email-masked]>
Date: Wed, 29 Nov 2006 23:18:13 +0800

I thought the text under review is to provide full analysis of the options 
to address the KeyRSC vulnerability.

Saravanan

----Original Message Follows----
From: "Pat Calhoun (pacalhou)" <[email-masked]>
To: "Saravanan Govindan" <[email-masked]>,"Dorothy 
Stanley" <[email-masked]>
CC: [email-masked]
Subject: Re: [Capwap] Proposed resolution to Isse 43/ 
wasRe:SecurityConsiderations
Date: Wed, 29 Nov 2006 06:41:48 -0800

Pat Calhoun

	From: Saravanan Govindan

	Hi Dorothy,

	Thank you for the text.

	Current proposed text:

	For consideration:

	Cheers,

	Saravanan

	All,

	Comments welcome,

	Thanks,

	Dorothy

	Proposed Resolution:

	9.1 IEEE 802.11 Security

	to

	Hello All,

	Cheers,

	Saravanan

_________________________________________________________________
Get an advanced look at the new version of MSN Messenger. 
http://messenger.msn.com.sg/Beta/Default.aspx