Subject: Re: [Capwap] CONSENSUS CHECK: Proposed resolution to Issue 43

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 4 Dec 2006 09:31:25 +0800

Hi Margaret,

In the spirit of moving forward to consensus, I agree with the option of
including text about the 2 approaches to 802.11i. 

However I feel strongly about the specific text. The current proposal
suggests that the option of using exact KeyRSC values is complex. I
think this is a decision to be made by implementers based on their
priorities ~ full security vs. OK-security. 

My suggestion is to edit the text (from my email on 29 November) to
clarify how exact KeyRSC values can be used and that it may be used to
fully overcome the vulnerability that is discussed.

Cheers,

Saravanan

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Wednesday, November 29, 2006 11:29 PM
To: capwap
Subject: [Capwap] CONSENSUS CHECK: Proposed resolution to Issue 43

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:
>
> 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

_________________________________________________________________
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: Mon, 4 Dec 2006 14:49:40 -0500

> including text about the 2 approaches to 802.11i.

Our current rough consensus (unless we find otherwise before  
Wednesday) is to document only one approach:  use zero, unless  the  
AC is aware of a more optimal value.  Unless there are sufficient  
objections to overcome our consensus from the WG meeting, the plan is  
to document only that one approach, not to document both approaches  
and allow implementors and/or users to choose.

> fully overcome the vulnerability that is discussed.

This text is at odds with the analysis of our security advisors, who  
found that both approaches has security vulnerabilities.

Thanks,
Margaret