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

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Wed, 5 Oct 2005 16:52:56 -0700

Hi Dan,

The devil is in the details.  We can state that particular protocols are
secure because they have been deemed secure.  But just because they are
secure does not mean that when they are applied to some other context,
their security properties are retained or that it meets the security
requirements posed on the applied context.   That is the gist of what
NIST conveyed and I am trying to reiterate the same for our context,
e.g. CAPWAP/LWAPP and DTLS.

DTLS carries its own state machine that am not sure how it fits in the
CAPWAP realm.  DTLS depending on selected cipher suites, credential
types provides a range of security properties.  Thus, my comment/request
is that those that are proposing DTLS provide more information of how it
fits into the CAPWAP model and how it addresses the groups requirements.

As a proposer of LWAPP, I can state that the group of proposers did put
the "onus" on ourselves to ensure that both the draft be as complete and
descriptive of how it meets the CAPWAP model as well as ensuring that it
be fully reviewed inclusive of its security properties.  It's not clear
to me how DTLS fits into the CAPWAP model....so, as I am not a proposer
of this suggestion, I am requesting those who are to provide one.

	Nancy.
 
-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Wednesday, October 05, 2005 12:51 PM
To: Nancy Winget (ncamwing)
Cc: Darren Loher; Pat Calhoun (pacalhou); James Kempf;
[email-masked]; [email-masked]
Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) 

  Nancy,

  IPsec was designed to protect IP and anything that rides on top of it,
it was not designed for one specific "application". Much care and review
was put into it to ensure that it met its design goals.
If you know of any security analysis that demonstrate a vulnerability
that IPsec has with respect to that design than please tell us. Since
RADIUS uses UDP which rides on top of IP then IPsec is designed to
protect it.

  If you know of anything specific to RADIUS that would make it
vulnerable if protected by IPsec then please tell us, it would be a
great service to the industry.

  TLS has had much more security review than LWAPP (whose security was
deemed "adequate"). 

  You say that modifications will have to be made to DTLS to ensure it's
appropriate for use with CAPWAP. Please elaborate. What parts of DTLS
need modification and why?

  Having a strong recommendation in CAPWAP on which ciphersuites to use
is a fantastic idea but the necessity of that should not derail the
whole idea of using a secure, standards-based protocol. I think the onus
is on someone who insists on reinventing the wheel on why it is
necessary or why this new wheel will be more round than the one we
already have.

  Dan.

On Wed, 05 Oct 2005 11:35:39 PDT you wrote
> 
> 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

---

From: Dan Harkins <[email-masked]>
Date: Thu, 06 Oct 2005 10:15:28 -0700

Hi Nancy,

On Wed, 05 Oct 2005 16:52:56 PDT you wrote
> e.g. CAPWAP/LWAPP and DTLS.

Yes, a good example of a protocol being secure in one context and 
problematic when used in a another context is IPsec protecting RADIUS.
And the _specific_ complaint NIST had was that the RADIUS app (client or
server) did not have a standard way of knowing whether the keys being
transmitted (received or sent, respectively) were IPsec-protected or not.
It was possible for a mis-configuration to not be noticed by the entities
taking part in the key dissemination. That is a FIPS-140 no no.

Now, when you think about that _specific_ example in our context-- CAPWAP
and DTLS-- it becomes obvious that the entities taking part in the key
dissemination, the AC and WTP, will know whether that transmission is
protected by DTLS or not because they took part in the exchange. The DTLS
exchange will be a mandatory step in CAPWAP and a mis-configuration of the
AC or WTP that resulted in a DTLS failure will not allow for the AC to
manage the WTP. 

> fits into the CAPWAP model and how it addresses the groups requirements.

It will fit in very nicely. As has been discussed on this list it should
be post-discovery which is basically where the exchange it is replacing
resides. It's probably not a simple ker-splat drop in, some loose ends may
have to be tied up but that is straightforward and not difficult.

I'm surprised by your request for more information on how DTLS fits into
this group's requirements. It is widely accepted that it does fit the
group's requirements and the evalution team even recommended it. Can you
be more specific in your request for information?

> of this suggestion, I am requesting those who are to provide one.

I know the the proposers of LWAPP considered DTLS. Can you tell me why
you chose not to use it? Perhaps you were not on the team back then so
maybe one of the other proposers can chime in.

Again, if you can be more specific about what is not clear to you perhaps
your questions can be answered. 

  Dan.