Subject: [Capwap] proposed security changes to objectives draft

From: Charles Clancy <[email-masked]>
Date: Wed, 18 May 2005 09:44:34 -0400 (EDT)

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: Matt Holdrege <[email-masked]>
Date: Wed, 18 May 2005 08:33:19 -0700

Charles,

Looks fine to me. Thanks for the comprehensive review and text suggestions.

One small nit. I haven't been following all the new text in recent weeks 
(months?), but is WLAN Controller a normative or defined term for CAPWAP?

-Matt

---

From: "James Kempf" <[email-masked]>
Date: Wed, 18 May 2005 09:49:15 -0700

Charles,

IETF really can't control what people deploy, though it can make
recommendations (BCPs are of this nature). Regarding the WEP question, I
believe the key point is that we want to warn people who deploy CAPWAP that
they should not think CAPWAP security is sufficient to make up for WEP's
deficiencies. Whether or not they decide to deploy WEP with CAPWAP is their
choice, but they should have no illusions about the resulting system
security. Consequently, I'd like to suggest modifying the suggested text as
follows:

----- > 5.1.9  System-wide Security
>     reauthentication, or some other mechanism.

PROPOSED MODIFICATION:

     While CAPWAP does not govern the wireless interface, the security used
     on that link will affect overall system security.  Although it is not
possible
     within the CAPWAP protocol to establish normative constraints on
wireless
     interface security for this reason, it is nevertheless important that
the CAPWAP
     specification contain clear guidelines to avoid confusion or mistaken
assumptions
     in deployment of CAPWAP. Consequently, the CAPWAP specification MUST
     recommend that WEP not be used on the wireless interface, and the
specification
     MUST clearly indicate that the strong security design of CAPWAP will
not
     compensate for inadequate or easily compromised security on the
wireless
     interface.

How does that sound?

            jak

---

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 19 May 2005 00:17:11 -0700

I like the text proposed by Charles, with one comment:

> Consequently, CAPWAP MUST disclaim the use of WEP by normatively
recommending that WEP not be used in conjunction with > CAPWAP.
At the beginning of the CAPWAP initiative, we clearly stated that the
working group would not require changes to the 802.11 protocol. There are
many products today that support WEP, and the architecture of the products
does not make WEP more or less secure. WEP is part of the 802.11 protocol,
and it's required for WFA certification. WEP is just a plain ol' bad idea,
but it's there and there are many applications that use it. Forcing CAPWAP
products to not support WEP will cause enterprise customers that may be
securing their sensitive data with a strong crypto, but using WEP for their
less sensitive data (and in some cases they just don't have a choice), to go
with non CAPWAP products.

So I realize that I'm repeating myself here, but I have to formally object
to this sentence. I'm ok with a SHOULD instead of a MUST. I'm ok with adding
a statement stating that products must warn people that using WEP is bad and
not secure.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Clancy
> Sent: Wednesday, May 18, 2005 6:45 AM
> To: [email-masked]
> Subject: [Capwap] proposed security changes to objectives draft
> 
> Comments?  Suggestions?
> 
> ---
> 
> [ t. charles clancy ]--[ [email-masked] ]--[ 
> www.cs.umd.edu/~clancy ] [ computer science ]-----[ 
> university of maryland | college park ]

---

From: Charles Clancy <[email-masked]>
Date: Thu, 19 May 2005 07:51:57 -0400 (EDT)

On Thu, 19 May 2005, Pat Calhoun wrote:

>> recommending that WEP not be used in conjunction with
>> CAPWAP.
>
> I'm ok with a SHOULD instead of a MUST.

... okay ...

> I'm ok with adding a statement stating that products must warn people 
> that using WEP is bad and not secure.

Isn't that exactly what the above statement requires of CAPWAP drafts? 
The SHOULD/MUST argument is about inclusion in the proposed protocol, not 
support for WEP.  If you're okay with including a disclaimer, then why 
SHOULD instead of MUST?

---

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 19 May 2005 13:43:36 -0700

I stand corrected. I now realize the text said disclaim, while somehow I had
read disallow.

My apologies.

Pat Calhoun

> Sent: Thursday, May 19, 2005 4:52 AM
> To: [email-masked]
> Subject: RE: [Capwap] proposed security changes to objectives draft
> 
> >> recommending that WEP not be used in conjunction with CAPWAP.
> >
> The SHOULD/MUST argument is about inclusion in the proposed 
> protocol, not support for WEP.  If you're okay with including 
> a disclaimer, then why SHOULD instead of MUST?
>

---

From: Charles Clancy <[email-masked]>
Date: Fri, 20 May 2005 15:19:26 -0400 (EDT)

Alright, we seemed to have reached a WG consensus on the security changes 
to the objectives draft.  Below is an updated version of my original 
proposal that hopefully takes into account everyones concerns.

Provided there are no objections, can the I-D.ietf-capwap-objectives 
editors update the draft as follows:

---

---

OLD TEXT:

NEW TEXT:

     The CAPWAP protocol must first provide for the participating entities
     - ACs 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.

---

OLD TEXT:

NEW TEXT:

---

---

NEW TEXT:

     While CAPWAP does not govern the wireless interface, the security used
     on that link will affect overall system security.  Although it is not
     possible within the CAPWAP protocol to establish normative constraints
     on wireless interface security for this reason, it is nevertheless
     important that the CAPWAP specification contain clear guidelines to
     avoid confusion or mistaken assumptions in deployment of CAPWAP.
     Consequently, the CAPWAP specification MUST recommend that WEP not be
     used on the wireless interface, and the specification MUST clearly
     indicate that the strong security design of CAPWAP will not compensate
     for inadequate or easily compromised security on the wireless
     interface.

     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.