Capwap Mailing List: New Security Considerations Section

[Charles Clancy (clancy]

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 ]--[ tcc [at] umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]