Subject: Re: [Capwap] proposed security changes to objectives draft

From: Oleg Volinsky <[email-masked]>
Date: Thu, 19 May 2005 11:40:01 -0400

Charles,
I do not see why split-mac and local-mac CAPWAP should have different 
requirements for handoff authentication between WTPs.  I think it puts 
more stringent requirements on Local-MAC implementations vs. 
split-MAC.   I would recommend not impose architectural specific 
limitation in this case.
                   Oleg

>--__--__--
>
>Message: 1
>Date: Wed, 18 May 2005 09:44:34 -0400 (EDT)
>From: Charles Clancy <[email-masked]>
>To: [email-masked]
>Subject: [Capwap] proposed security changes to objectives draft
>
>Comments?  Suggestions?
>
>---
>
>5.1.8  CAPWAP Protocol Security
>
>---
>
>OLD TEXT:
>
>    The CAPWAP protocol must first provide for the participating entities
>    - WLAN controller and WTPs - to be mutually authenticated.  This is
>    to ensure that rogue WTPs do not breach legitimate WLAN systems.  For
>    example, WTPs may need to regularly renew their authentication state
>    with the WLAN controller.
>
>NEW TEXT:
>
>    The CAPWAP protocol must first provide for the participating entities
>    - WLAN controller and WTPs - to be explicity mutually authenticated.
>    If authentication is performed via an authenticated key exchange,
>    future knowledge of derived keys is not sufficient for authentication.
>    This is to ensure that rogue WTPs do not breach legitimate WLAN
>    systems.  For example, WTPs may need to regularly renew their
>    authentication state with the WLAN controller.
>
>    Any session keys used between the AC and WTP MUST be mutually drived
>    using entropy contributed by both parties.  This ensures that no one
>    party has control over the resulting session keys.
>
>---
>
>OLD TEXT:
>
>    While mutual authentication is necessary for CAPWAP, the protocol
>    should not prevent the use of asymmetric, non-mutual authentication.
>    The security considerations of such asymmetric authentication are
>    described in the Security Considerations section.
>
>NEW TEXT:
>
>    CAPWAP should not prevent the use of asymmetric authentication.  The
>    security considerations of such asymmetric authentication are
>    described in the Security Considerations section.
>
>---
>
>5.1.9  System-wide Security
>
>---
>
>NEW TEXT:
>
>    While CAPWAP does not govern the wireless interface, the security used
>    on that link will affect overall system security.  Consequently,
>    CAPWAP MUST disclaim the use of WEP by normatively recommending that
>    WEP not be used in conjunction with CAPWAP.
>
>    CAPWAP SHOULD authenticate handoffs between WTPs.  When split-MAC
>    CAPWAP is used in conjunction with 802.11i, this authentication happens
>    implicitly via the 4-Way Handshake.  With local-MAC CAPWAP, this will
>    involve the derivation of a new PMK, either through an EAP
>    reauthentication, or some other mechanism.
>
>
>[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
>[ computer science ]-----[ university of maryland | college park ]
>
>--__--__--
>  
>
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Charles Clancy <[email-masked]>
Date: Thu, 19 May 2005 12:32:55 -0400 (EDT)

Perhaps something more generic would be appropriate?

    CAPWAP SHOULD authenticate handoffs between WTPs.  When CAPWAP is used
    in a dynamically-keyed environment, STAs MUST derive new transport keys
    upon association to a new WTP.

On Thu, 19 May 2005, Oleg Volinsky wrote:

> requirements for handoff authentication between WTPs.  I think it puts more 
> stringent requirements on Local-MAC implementations vs. split-MAC.   I would 
> recommend not impose architectural specific limitation in this case.
>                  Oleg
>
>> --__--__--
>> 
>> Message: 1