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

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

Speaking as an individual, I also agree that the AC load information sent in the clear during discovery is not a significant threat above and beyond doing discovery without this information.  I support post-discovery encryption setup.  
 
So would it be correct to say we want security negotiated at the Join phase (control channel setup)?
 
-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: "T. Charles Clancy" <[email-masked]>
Date: Mon, 3 Oct 2005 09:52:04 -0400 (EDT)

I see no problems with post-discovery DTLS.  Pre-discovery really doesn't 
make much sense.  I suppose there is a chance for a DoS if someone sends 
bogus discovery response messages, but the mutual authentication 
requirements prevents any compromise of data.  I also see no problem with 
transporting plaintext keys within the DTLS session.

As a side note, IMHO the existing LWAPP security features are adequate. 
However, in the spirit of modular standards, I think reusing a security 
protocol would be a good idea.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

---

From: "Darren Loher" <[email-masked]>
Date: Tue, 4 Oct 2005 09:58:49 -0700

You are right, it was my mistake to refer to PMK/GMK, we are talking
about the PTK and GTK between the AC and WTP.  

So we agree that it's highly unlikely that there is any issue with
transmission of the PTK/GTK over the secure CAPWAP control channel
between the AC and WTP.

-Darren

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]]
> Sent: Sunday, October 02, 2005 6:07 PM
> To: Darren Loher
> Cc: James Kempf; Pat Calhoun (pacalhou); [email-masked]
>   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
> >
> > 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
> > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute
for
> PMK
> > would prefer to leave this as a deployment option, with appropriate
text
> in
> > >> security mechanism with DTLS instead. This specific change is
tricky
> as
> > >> 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
> > >> 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
> > >> Performing DTLS prior to the Discovery Request would mean that
the
> WTP
> > >> a. The WTP establishes a DTLS session with every AC it knows
about.
> The
> > >> that a WTP would only connect to the AC of its choice, regardless
of
> the
> > >> and the Discovery phase is done in the clear. While it is true
that
> this
> > >> of the response packet has created limited damage (although the
WG
> needs
> > >> that this change should be made. While I will make the change
based
> on
> > >> 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
> > >> meeting with NIST, we discussed the transport of 802.11i PMKs
within
> the
> > >> them to evaluate whether IPSec would be appropriate for the
transport
> of

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 5 Oct 2005 07:07:44 -0700

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

> 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
> 
> 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
> 
> 
> 
> > attacker could do during the DTLS "hello" exchange-- modify 
> packets in 
> > flight, redirect packets-- and the result would be the same: an 
> > 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.
> >
> >> 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.
> >>
> >> 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.
> >> 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).
> >>
> >> 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).
> >>
> >> 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.
> >>
> >> CTO, Wireless Networking Business Unit Cisco Systems

---

From: "Darren Loher" <[email-masked]>
Date: Wed, 5 Oct 2005 07:36:23 -0700

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

> 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]
the

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 5 Oct 2005 11:56:12 -0700

Great idea. Anyone willing to sign up?

Pat Calhoun

> 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]
> 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
> 
> 
> From: "Nancy Winget (ncamwing)" <[email-masked]>
> To: "Darren Loher" <[email-masked]>; "Pat Calhoun 
> (pacalhou)" 
> <[email-masked]>; "James Kempf" 
> <[email-masked]>; "Dan Harkins" <[email-masked]>
> Sent: Wednesday, October 05, 2005 11:35 AM
> 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.
> 
> 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]
> 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
> 
> > > mandatory that these attributes are sent over the secured control 
> > > channel.  So we should be covered on the AC <-> WTP communication.
> > >
> > > and a AAA server and therefore outside the scope of CAPWAP?
> > >
> > > -Darren
> > >
> post-discovery is
> > > 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.
> > >
> > > 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 
> > > 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
> > >
> > >
> > >
> > > > discovery of AC-- but any middlebox can start dropping 
> packets on
> a
> > > >> its policy. The policy can be either least loaded AC, 
> or through
> a

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Wed, 5 Oct 2005 12:25:33 -0700

I wholly agree.....unless we see the proposed integration detailed (and
written), it will be hard to assess it's viability not to mention its
security properties.  It is still not clear to me though, what added
benefits DTLS would provide over what has already been proposed in
LWAPP?  It would be useful to have that data as well.

Thanks,

	Nancy. 

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Wednesday, October 05, 2005 12:04 PM
To: Susan Hares; Nancy Winget (ncamwing); Darren Loher; Pat Calhoun
(pacalhou); Dan Harkins
Cc: [email-masked]

Sue,

Sure, that's why I think we need something written. It is entirely
possible that the process of trying to figure out how it would work
would result in realizing that it won't work (something which did, in
fact, happen to me recently on another draft). On the other hand, the
technical details may be surmountable, thereby allowing LWAPP to accrue
the benefits of using what appears likely to be a widely implemented and
used security protocol.

            jak

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

James:

The issues regarding DTLS state machine interaction are not 100% spelled
out in the SLAPP proposal.

Sue

Dan - I believe I've gone through my reasons with you 8-9 months ago.
Glad to provide you offline with this information again.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Kempf
Sent: Wednesday, October 05, 2005 2:55 PM
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)

-Darren

> > protocols, so any bugs will most likely be found more quickly than
> > option, with appropriate text in the Security Considerations section

> > are described. I realize that there is an interoperability concern
> > here, but I can imagine cases where a network operator might prefer
> > 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

the

---

From: Michael Montemurro <[email-masked]>
Date: Wed, 5 Oct 2005 16:19:44 -0400

All,

There seems to be a number of people in favour of DTLS. I think that for
this topic, I would like to see a detailed description for how DTLS would be
applied to the CAPWAP protocol and how it compares to the solution
documented in LWAPP. Simply stating that we should "use DTLS" does not
provide enough information to compare with what has been proposed.

Could one of the people in favour of DTLS provide this detail?

Thanks,

	Mike

> [mailto:[email-masked]] On Behalf Of James Kempf
> Sent: October 5, 2005 3:04 PM
> To: Susan Hares; Nancy Winget (ncamwing); Darren Loher; Pat 
> Calhoun (pacalhou); Dan Harkins
> Cc: [email-masked]
> Sure, that's why I think we need something written. It is 
> entirely possible that the process of trying to figure out 
> how it would work would result in realizing that it won't 
> work (something which did, in fact, happen to me recently on 
> another draft). On the other hand, the technical details may 
> be surmountable, thereby allowing LWAPP to accrue the 
> benefits of using what appears likely to be a widely 
> implemented and used security protocol.
> 
>             jak
> 
> <[email-masked]>; "Darren Loher" 
> <[email-masked]>; "Pat Calhoun (pacalhou)" 
> <[email-masked]>; "Dan Harkins" <[email-masked]>
> The issues regarding DTLS state machine interaction are not 
> 100% spelled out in the SLAPP proposal.
> 
> Sue
> 
> [mailto:[email-masked]] On Behalf Of James Kempf
> IPSec were
> suggested but
> no way for
> be secure,

---

From: "Darren Loher" <[email-masked]>
Date: Wed, 5 Oct 2005 16:18:19 -0700

I propose the following process for making a decision about 9.1.2
(Control Channel Security) would be to gather WG consensus on the
following points: 

1. Is using DTLS instead of the currently proposed LWAPP security
channel a good enough idea that it is worth the effort to develop a new,
DTLS based control channel security mechanism?

2. If so, a proposal must be developed which can replace LWAPP's
security mechanism.  We need volunteers from the working group to
develop this.

3. Does this proposal meet the WG objectives and will it meet the IETF
requirements better than the original LWAPP security mechanism?

4. If yes, officially adopt the DTLS based control channel specification
for LWAPP.

In order to help address question #1, the evaluation draft 9.1.2 points
out a few benefits that using DTLS should bring and detractors from
using the LWAPP developed security mechanism.  

At best, the proposed LWAPP security protocol will face a longer, slower
approval process from the Security Area Directorate and the IESG.  Use
of an existing security mechanism would also need to be reviewed, but if
properly specified, it will likely be quickly accepted.  

In particular, the following questions will be asked of the LWAPP
security mechanism.  It is these questions that lead the evaluation team
to recommend the replacement of the LWAPP mechanism with DTLS.  

- What is uniquely required by CAPWAP that is not available from an
existing standard protocol?

- How will CAPWAP's security protocol meet security area requirements
for extensibility, such as the ability to support future cipher suites
and new key exchange methods?

- How does this ability compare to established security protocols which
have these capabilities?

All these issues could be addressed by adopting an appropriate, existing
security protocol.  DTLS appears to be the leading candidate protocol.  

If we can get consensus that this is true, then we should proceed to
step #2, creation of a proposal for use of DTLS in CAPWAP.

Section 9.1.2 of the evaluation draft specifically recommends that a
detailed specification of the application of DTLS be developed.  The
specification should include a detailed description of the
authentication procedure and a mandatory cipher suite.  A proper
development of this specification should address Nancy's concerns. 

-Darren

> From: Michael Montemurro [mailto:[email-masked]]
> Sent: Wednesday, October 05, 2005 2:20 PM
> To: James Kempf; Susan Hares; Nancy Winget (ncamwing); Darren Loher;
Pat
> this topic, I would like to see a detailed description for how DTLS
would
> be
(pacalhou)"
> > > I think you meant PTK/GTK, but I was just making an observation
that
> > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius
attribute
> > > > > preceived weakness in IPsec. It was because there is nothing
in
> > > > > will be available everywhere). Putting the security for
passing
> > > > >> removed, and the Discovery phase is done in the clear. While
it
> > > > >> exchanged on a separate UDP port, which is not a big change
to

---

From: "Nelson, David" <[email-masked]>
Date: Thu, 6 Oct 2005 13:45:55 -0400

Pat Calhoun writes...

> I do believe that if we were to aggressively pursue security reviews
> today, we could alleviate some backend delays.

Certainly.  However, this remains me of an old saying: "With sufficient
thrust, even a Buick can be made to fly."  The relevant question is:
"What's the level of return-on-investment for the effort required?".
This comment isn't intended to disparage the engineering quality of the
current LWAPP security mechanism, but rather to question where the WG
should allocate its energies.

There are good reasons for the IETF community to prefer well-used
security mechanisms in its protocols.  Formal security review addresses
some of them.  There is also some value in commonality for commonality's
sake, such as the benefit of ongoing review of the protocols and ongoing
attempts to find attacks.  The commonly used protocols will receive more
scrutiny that more specialized ones.

The reasons of suggesting a non-novel security mechanism for CAPWAP
included the onus of undertaking multiple, independent security reviews,
as well as the general preference for re-use of common mechanisms.  The
potential desire to achieve external certification of CAPWAP
implementations, e.g. NIST/FIPS, is another reason for choosing a
commonly used security mechanism.