Subject: [Capwap] New Security Considerations Section

From: Charles Clancy <[email-masked]>
Date: Tue, 21 Mar 2006 11:19:37 -0500

CAPWAP Editors,

The current security considerations section seems more like a 
placeholder than anything else.  Here's a new one that addresses a lot 
more issues.  I'm sure there's more that can be added, but I think it 
covers the major issues.

15.  Security Considerations

    This section describes security considerations for the CAPWAP
    protocol.  It also provides security recommendations for protocols
    used in conjunction with CAPWAP.

15.1.  CAPWAP Security

    As it is currently specified, the CAPWAP protocol sits between the
    security mechanisms specified by IEEE 802.11i and AAA.  One goal of
    CAPWAP is to bootstrap trust between the STA and WTP using a series
    of preestablished trust relationships.

      STA            WTP           AC            AAA
      ==============================================

                         DTLS Cred     AAA Cred
                      <------------><------------->

                      EAP Credential
       <------------------------------------------>

          802.11i PTK
       <-------------->
           (derived)

    Within CAPWAP, DTLS is used to secure the link between the WTP and
    AC.  In addition to securing control messages, it's also a link in
    this chain of trust for establishing client keys.  Consequently, much
    rests on the security of DTLS.

    The use of parallel protected and unprotected channels deserves
    special consideration, but does not create a threat.  There are two
    potential concerns: attempting to convert protected data into un-
    protected data and attempting to convert un-protected data into
    protected data.  The use of message authentication makes it
    impossible for the attacker to forge protected records.  The attacker
    can easily remove protected records from the stream (this is a
    consequence of unreliability), though not undetectably so.  If a non-
    encrypted cipher suite is in use, the attacker can turn such a record
    into an un-protected record.  However, this attack is really no
    different from simple injection into the unprotected stream.

    Perfect Forward Secrecy is not a requirement for the CAPWAP
    protocol, though it can be accomplished using a
    Diffie-Hellman-based DTLS ciphersuite, as described in sections
    10.1.1 and 10.1.2.

    When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP
    SHOULD have a unique PSK.  Since WTPs will likely be widely
    deployed, their physical security is not guaranteed.  If PSKs are
    not unique for each WTP, key reuse would allow the compromise of
    one WTP to result in the compromise of others.  Generating PSKs
    from low entropy passwords is NOT RECOMMENDED.

    It is RECOMMENDED that implementations that allow the administrator
    to manually configure the PSK also provide a functionality for
    generating a new random PSK, taking RFC 1750 [4] into account.

    For public-key-based DTLS deployments, each device SHOULD have
    unique credentials, with a certificate profile authorizing them to
    act as either a WTP or AC.  Each device is responsible for
    authenticating and authorizing devices to which they communicate.

15.2.  IEEE 802.11i 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 against IEEE 802.11.  Implementors
    SHOULD discourage the use of WEP to allow the market to move
    towards technically sound cryptographic solutions, such as IEEE
    802.11i.

    STA authentication in CAPWAP is performed using IEEE 802.lX, and
    consequently EAP.  Implementors SHOULD use EAP methods meeting
    the requirements specified in RFC 4017 [ref].  These properties
    include:

    * generation of symmetric keying material
    * strong session keys
    * mutual authentication
    * shared state equivalence
    * resistance to dictionary attacks
    * protection against man-in-the-middle attacks
    * protected ciphersuite negotiation

15.3.  AAA Security

    The AAA protocol is used to distribute EAP keys to the ACs, and
    consequently its security is important to the overall system
    security.  When used with TLS or IPsec, security guidelines
    specified in RFC 3539 [ref] SHOULD be followed.

    In general, the link between the AC and AAA server SHOULD be
    secured using a strong ciphersuite keyed with mutually
    authenticated session keys.  Basic RADIUS shared secret
    authentication SHOULD NOT be implemented, as it is often
    vulnerable to dictionary attacks.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 21 Mar 2006 08:43:08 -0800 (GMT-08:00)

I agree with Charles' assessment - the current text actually *is* a place-holder :-) 

I think the suggested text below looks good and should be added to the draft.

-----Original Message-----
>From: Charles Clancy <[email-masked]>
>Sent: Mar 21, 2006 8:19 AM
>To: [email-masked]
>Subject: [Capwap] New Security Considerations Section
>
>CAPWAP Editors,
>