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

From: "Darren Loher" <[email-masked]>
Date: Sun, 2 Oct 2005 12:17:16 -0700

Regarding secure distribtion of PMK/GMK between AC and WTP, it is mandatory that these attributes are sent over the secured control channel.  So we should be covered on the AC <-> WTP communication.
 
Isn't the transmission of RADIUS attributes an issue between the AC and a AAA server and therefore outside the scope of CAPWAP?  
 
-Darren

________________________________

From: [email-masked] on behalf of James Kempf
Sent: Thu 9/29/2005 9:54 AM
To: Pat Calhoun (pacalhou); Dan Harkins
Cc: [email-masked]
Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) 

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

----- Original Message -----
From: "Dan Harkins" <[email-masked]>
To: "Pat Calhoun (pacalhou)" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 28, 2005 3:16 PM
Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security)

>  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
>> 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
>>
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
>

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Dan Harkins <[email-masked]>
Date: Sun, 02 Oct 2005 17:07:19 -0700

Darren,

  It is the PTK and GTK that are being sent between the AC and WTP not
the PMK and GMK, and yes they are secured by the since the control channel
through which they are sent is secured. You never want to send a PMK from
the AC to the WTP. The PMK is bound to the authenticator and if the
authenticator resides on the AC the PMK stays on the AC, if the authent-
icator resides on the WTP the PMK stays on the WTP.

  Yes, RADIUS attributes sent from an AS to an authenticator are outside
the scope of CAPWAP but the reason for bringing it up was to point out
that NIST has a problem with an IPsec-protected channel (from the AS to
the authenticator) and might it also with a DTLS-protected channel (from
the AC to the WTP). For the reasons I mentioned below I think the
answer is no.

  Dan.

On Sun, 02 Oct 2005 12:17:16 PDT you wrote
> Regarding secure distribtion of PMK/GMK between AC and WTP, it is mandatory t
>hat these attributes are sent over the secured control channel.  So we should 
>be covered on the AC <-> WTP communication.
>  
> Isn't the transmission of RADIUS attributes an issue between the AC and a AAA
> server and therefore outside the scope of CAPWAP?  
>  
> -Darren
>