Subject: [Capwap] Change Request 9.1.2 (Control Channel Security)

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 28 Sep 2005 14:32:16 -0700

The evaluation team has made a request to modify LWAPP's built-in
security mechanism with DTLS instead. This specific change is tricky as
we first need to identify whether the DTLS session should be created
prior to, or post, the discovery phase.

Here are my high level thoughts on the issue:
1. Pre-Discovery DTLS.

One of the LWAPP features is load balancing of WTPs among ACs. This load
balancing can occur within, or across multiple, ACs. How this works is
that a WTP would perform the discovery phase by initiating a Discovery
Request packet to one or more ACs. The receiving ACs respond with a
Discovery Response, which also includes the total number of WTPs
supported (see section 5.2.2), as well as its current WTP load (see
section 5.2.3). The WTP collects all of the Discovery Responses, and
then decides which AC it wishes to connect to based on its policy. The
policy can be either least loaded AC, or through a list of preferred ACs
(see section 7.2.3). Further, the WTP can opt to not establish a session
with the AC if it determines that it does not have the basic
capabilities required by the AC.

Performing DTLS prior to the Discovery Request would mean that the WTP
would mean one of two  things:
a. The WTP establishes a DTLS session with every AC it knows about. The
side effect here is the LWAPP connect time on the WTP, not to mention
the CPU load imposed on the AC.
b. The LWAPP protocol eliminates this feature altogether. This means
that a WTP would only connect to the AC of its choice, regardless of the
AC's current load of configuration.

2. Post-Discovery DTLS. In this mode, the above limitations are removed,
and the Discovery phase is done in the clear. While it is true that this
raises some security concerns, the information in the Discovery Response
is relatively benign, and therefore any malicious tweaking (or altering)
of the response packet has created limited damage (although the WG needs
to evaluate this, but it was not found to be problematic during the
security review).

This change would also require that the the Discovery packets be
exchanged on a separate UDP port, which is not a big change to the
protocol.

while I understand the evaluation team's recommendation to adopt DTLS, I
would also like to get a larger WG rough consensus on whether we feel
that this change should be made. While I will make the change based on
rough consensus, I want to make sure that we think and agree on this
decision through as a group. I understand the concerns raised about
increasing the time of the protocol development phase in having our own
security approach, there are strategies that can be done to help us. For
instance, initiate another security review with another reviewer
identified by Russ Housely asap (he did recommend Charles Clancy, btw). 

I think that another important point here is that during a recent
meeting with NIST, we discussed the transport of 802.11i PMKs within the
RADIUS protocol. During this discussion, we proposed two methods. The
first would explicitely encrypt the PMK using AES-KeyWrap within a
RADIUS attribute. The second approach was simply to encrypt the whole
RADIUS transaction with IPSec. It was NIST's opinion at that time that
they felt comfortable with option one, while option two would require
them to evaluate whether IPSec would be appropriate for the transport of
PMKs. Given that CAPWAP has a requirement to allow the WTP to perform
encryption, this means that PTKs (and GTKs) would have to be transported
over a DTLS session, and therefore I wonder whether we would have
similar issues as those mentioned above. If this were an issue, then
FIPS certification of any CAPWAP based system could become impossible.

Your comments are appreciated,

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "James Kempf" <[email-masked]>
Date: Wed, 28 Sep 2005 14:52:44 -0700

jak>> What was the security concern with doing discovery in the clear?

            jak

---

From: Dan Harkins <[email-masked]>
Date: Wed, 28 Sep 2005 15:16:34 -0700

Pat,

  I agree that the information in the discovery phase is benign. Also,
anything an attacker could do to at that point is the same as what an
attacker could do during the DTLS "hello" exchange-- modify packets
in flight, redirect packets-- and the result would be the same: an
unsuccessful DTLS exchange or unsuccessful discovery. An attacker 
could deny service-- prevent a successful DTLS exchange or successful
discovery of AC-- but any middlebox can start dropping packets on a
whim and do the same thing. I don't believe there is a possibility of
a resource exhaustion attack or launch a man-in-the-middle attack
against the AC or WTP.

  I don't think we really need to worry about doing DTLS post-discovery.

  To address your call for wider WG response to this recommendation:
I strongly believe that (D)TLS should be used for the key exchange and
authentication protocol.

  My understanding on the reason that NIST preferred AES-KeyWrap over
IPsec for the transporting of PMKs had nothing to do with any
preceived weakness in IPsec. It was because there is nothing in the
IPsec standard to allow a user-space app-- like a RADIUS client-- to
know whether the packets it is sending are in the clear or are IPsec-
protected. Therefore a mis-configuration could result in PMKs being
sent over-the-wire in-the-clear. (There are IPsec implementations that
do allow for such queries of the SADB but that isn't part of the IPsec
standard and therefore there isn't a guarantee that such a capability
will be available everywhere). Putting the security for passing the
PMKs directly into the RADIUS app-- i.e. using AES-KeyWrap-- addresses
that concern. Therefore I don't believe NIST would have a problem sending
PTKs down a (D)TLS-protected link because the app that is sending and
receiving them knows whether that link is protected or not.

  Dan.

On Wed, 28 Sep 2005 14:32:16 PDT you wrote

---

From: "James Kempf" <[email-masked]>
Date: Thu, 29 Sep 2005 08:54:56 -0700

I agree with Dan. I think the risk from doing DTLS post-discovery is 
minimal.

Security protocols have a history of bugs turning up after some years of 
deployment. An added benefit of using DTLS is that LWAPP benefits from the 
attention given to DTLS by users of other protocols, so any bugs will most 
likely be found more quickly than if LWAPP designs its own, specialized 
protocol.

Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute for PMK 
distribution, I don't have any real opinion on this. Actually, I think I 
would prefer to leave this as a deployment option, with appropriate text in 
the Security Considerations section about the requirement to use one of 
these method, and the methods are described. I realize that there is an 
interoperability concern here, but I can imagine cases where a network 
operator might prefer one method over another due to their existing 
deployment. As Dan mentioned, the concerns expressed about using IPsec 
related to particular implementation issues rather than any fundamental 
architectural or design issue with the protocol. But I don't have a real 
strong opinion on this, and I can think of reasons why it might be a good 
idea to include a particular "required to implement" method too.

            jak