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

From: "James Kempf" <[email-masked]>
Date: Wed, 5 Oct 2005 12:01:10 -0700

Me too. But I can't be the point man with fingers on the keyboard.

            jak

----- Original Message ----- 
From: "Scott G. Kelly" <[email-masked]>
To: "Pat Calhoun (pacalhou)" <[email-masked]>; "James Kempf" 
<[email-masked]>; "Nancy Winget (ncamwing)" <[email-masked]>; 
"Darren Loher" <[email-masked]>; "Dan Harkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 05, 2005 12:00 PM
Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security)

> I'd be willing to help with this.
>
> -----Original Message-----
> From: "Pat Calhoun (pacalhou)" <[email-masked]>
> Sent: Oct 5, 2005 11:56 AM
> To: James Kempf <[email-masked]>, "Nancy Winget (ncamwing)" 
> <[email-masked]>, Darren Loher <[email-masked]>, Dan Harkins 
> <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security)
>
> Great idea. Anyone willing to sign up?
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
>> -----Original Message-----
>> From: James Kempf [mailto:[email-masked]]
>> Sent: Wednesday, October 05, 2005 11:55 AM
>> To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun
>> (pacalhou); Dan Harkins
>> Cc: [email-masked]
>> Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security)
>>
>> Nancy,
>>
>> I think it is only fair to ask for a written proposal (i.e. a
>> draft) about how DTLS would be applied to LWAPP before the WG
>> makes a decision, if only to ensure that the technical
>> details are in order.
>>
>>             jak
>>
>>
>> ----- Original Message -----
>> From: "Nancy Winget (ncamwing)" <[email-masked]>
>> To: "Darren Loher" <[email-masked]>; "Pat Calhoun
>> (pacalhou)"
>> <[email-masked]>; "James Kempf"
>> <[email-masked]>; "Dan Harkins" <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Wednesday, October 05, 2005 11:35 AM
>> Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security)
>>
>>
>>
>> NIST's concern is that care and (re)review is taken when
>> security protocols that were designed for one application are
>> applied to another.
>> In the case of RADIUS, NIST pointed out that both RADIUS and
>> IPSec were complex enough that it was not clearly obvious to
>> them how the use of IPSec would address the key transport
>> security....nor has there been any security analysis to
>> demonstrate what security properties and vulnerabilities
>> IPSec provides when used with RADIUS.
>>
>> As for CAPWAP/LWAPP, it seems that the LWAPP protocol has
>> already undergone security review and has been shown to meet
>> this group's security requirements.  So, how does DTLS
>> improve upon the currently proposed security?
>>
>> My concern is that thus far, the adoption of DTLS has been
>> suggested but I've not readily seen how it would be applied.
>> I believe modifications will have to be made to DTLS to
>> ensure it's appropriate use for this group's application.
>> DTLS is fairly open in how it achieves authentication to the
>> point that it does not guarantee (identity) authenticity, so
>> I think that additional specification for how DTLS is applied
>> will be needed.  That is, strong recommendations of the
>> options of credential and cipher suites will have to be
>> defined to ensure that this group's security requirements are met.
>>
>> Nancy.
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Darren Loher
>> Sent: Wednesday, October 05, 2005 7:36 AM
>> To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins
>> Cc: [email-masked]
>> Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security)
>>
>> I think the main difference between NIST's concern and our
>> scenario is the following:
>>
>> As Pat relayed to us in the RADIUS with IPSec case, there is
>> no way for RADIUS to really know it's using IPSec and
>> therefore does not know if it's transport is secure or not.
>>
>> In the CAPWAP/LWAPP case the control channel is guaranteed to
>> be secure, so it's okay to carry to PTK/GTK within the
>> control channel.  So within the context of CAPWAP, there is
>> implicit knowledge that transient keys are using secure transport.
>>
>> -Darren
>>
>> > -----Original Message-----
>> > From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
>> > Sent: Wednesday, October 05, 2005 8:08 AM
>> > To: Darren Loher; James Kempf; Dan Harkins
>> > Cc: [email-masked]
>> > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel
>> Security)
>> >
>> > I think you meant PTK/GTK, but I was just making an observation that
>> the
>> > use of IPSec to carry keys was considered suspicious by
>> NIST. I see a
>> > parallel here in our proposed direction.
>> >
>> > I will follow what the WG feels is right, I was just making
>> sure folks
>>
>> > had additional info I thought was useful.
>> >
>> > Pat Calhoun
>> > CTO, Wireless Networking Business Unit Cisco Systems
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: Darren Loher [mailto:[email-masked]]
>> > > Sent: Sunday, October 02, 2005 12:17 PM
>> > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins
>> > > Cc: [email-masked]
>> > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel
>> Security)
>> > >
>> > > 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
>>
> _______________________________________________
> 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: "Scott G. Kelly" <[email-masked]>
Date: Wed, 5 Oct 2005 12:00:09 -0700 (GMT-07:00)

-----Original Message-----
From: "Pat Calhoun (pacalhou)" <[email-masked]>
Sent: Oct 5, 2005 11:56 AM
To: James Kempf <[email-masked]>, "Nancy Winget (ncamwing)" <[email-masked]>, Darren Loher <[email-masked]>, Dan Harkins <[email-masked]>
Cc: [email-masked]
Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) 

Pat Calhoun