Subject: Re: [Capwap] Encryption Capabilities

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 5 Jun 2006 08:22:29 -0700

I should have noted that securing the data plane should be optional.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Pat Calhoun (pacalhou) 
	Sent: Monday, June 05, 2006 8:21 AM
	To: Michael Montemurro; David T. Perkins
	Cc: [email-masked]
	Subject: Re: [Capwap] Encryption Capabilities

	Actually, this field was intended to allow the WTP to
communicate whether it is capable of providing its capabilities, and
therefore allow the AC to determine whether it should perform
centralized encryption. However, with the transition to DTLS, I propose
that we always require the WTP to provide wireless encryption, and use
DTLS between the AC and the WTP. 

	Pat Calhoun
	CTO, Wireless Networking Business Unit
	Cisco Systems

________________________________

		From: Michael Montemurro
[mailto:[email-masked]] 
		Sent: Saturday, June 03, 2006 12:12 PM
		To: David T. Perkins
		Cc: [email-masked]
		Subject: Re: [Capwap] Encryption Capabilities

		David,
		 
		Would it be sufficient to move Encryption Capabilities
from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information
message element (Section 4.4.39)?
		 
		Mike

		On 6/3/06, Michael Montemurro
<[email-masked]> wrote: 

			David, 
			
			I've created issue 125 to track this issue.
			 
			Mike

			On 6/1/06, David T. Perkins
<[email-masked] > wrote: 

				HI,
				
				The "(4.4.34)WTP Descriptor" message
element has the
				subfield "encryption capabilities". What
is this used 
				for? If for radios, then it should be
per radio. If
				for the user data between the WTP and
AC, then
				it doesn't seem appropriate to say the
value is
				defined by "specific binding"
definitions because
				the WTP can be supporting multiple
radios with
				some that provide encryption services
and some
				that don't.
				
				In general, I don't feel that this
subfield is
				well defined, and it appears to me that
it
				should be a per radio attribute. 
				
				Regards,
				/david t. perkins

_________________________________________________________________
				To unsubscribe or modify your
subscription options, please visit:
	
http://lists.frascone.com/mailman/listinfo/capwap
				
				Archives:
http://lists.frascone.com/pipermail/capwap 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 5 Jun 2006 10:05:43 -0700

Yes, I agree.

Pat Calhoun

	From: Michael Montemurro [mailto:[email-masked]] 
	Sent: Monday, June 05, 2006 9:13 AM
	To: Pat Calhoun (pacalhou)
	Cc: David T. Perkins; [email-masked]
	Subject: Re: [Capwap] Encryption Capabilities

	Pat,
	 
	Are you saying that we should remove the Encryption Capabilities
field? If not, do you agree that it makes more sense to include it as
part of the radio information.
	 
	Cheers,
	 
	Mike

	On 6/5/06, Pat Calhoun (pacalhou) <[email-masked]> wrote: 

		Pat Calhoun

			From: Michael Montemurro

		David,

		Mike

		On 6/3/06, Michael Montemurro
<[email-masked] > wrote: 

			David, 

			Mike

				HI,

				
				Regards,
				/david t. perkins

				
				Archives:

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 7 Jun 2006 07:40:11 -0700

> As you have noted,  DTLS in the data path is going
> to require the WTPs to seriously beef up their
> crypto capabilities, especially with 802.11n around
> the corner.  Terminating roughly 300-350Mbps of
> 802.11i encryption traffic and then re-encrypting it
> for DTLS is going to be a challenge at low cost points.

What about the AC that now needs to double encrypt/decrypt
packets? The standard allows for the AC to perform both
functions, which is expensive.

So the way I see it, both crypto functions provide a different
level of security, but if the purpose of the function is to
protect the packets over the wire, 802.11i doesn't do that 
because it only protects the 802.11 payload - not the CAPWAP 
header.

> It's amusing that within a span of roughly
> 2 years we have gone from "fat"  APs to "fit" APs and
> now to "weight-lifter" APs. :-)

Abhijit, the purpose of CAPWAP is not to make Aps cheaper. In fact
the whole "light weight" concept was not really about making them
less expensive, but repositioning the functions to make more effective
use of the processor in the WTP.

Pat Calhoun

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Wed, 7 Jun 2006 08:13:16 -0700

Hi Michael,

Many thanks for the clarification!  Though to reiterate, the
"centralized encryption" is only pertinent to the implementation of the
packet crypto in 802.11i only and orthogonal to the security of CAPWAP.

	Nancy.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: Wednesday, June 07, 2006 12:21 AM
To: Nancy Winget (ncamwing); [email-masked]; Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: RE: [Capwap] Encryption Capabilities

Hi Nancy,

Comments inline... 

-----Original Message-----
From: ext Nancy Winget (ncamwing) [mailto:[email-masked]]
Sent: Tuesday, June 06, 2006 9:43 PM
To: Charles Clancy; Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Encryption Capabilities

Charles,

I think I agree with you though I'm not sure I understand the full
thread.

It seems that the current email thread is mixing the securing of
different transport layers, e.g. CAPWAP with that of 802.11i.

802.11i is designed to afford protection of the 802.11 transport layer,
providing both packet confidentiality and authentication; but it does
not address securing the CAPWAP transport layer.  An obvious example of
this is that the CAPWAP header is not authenticated!  

So whether the 802.11i crypto is done either at the WTP or AC should be
construed as a different feature than that of securing the CAPWAP
transport layer.  

/mgw/ Yes. I read Charles as also agreeing with this.

Also, I do not understand what the notion of "centralized" encryption is
as the client has no clue of the topology or architecture behind the AP?

/mgw/ The centralized comment refers to where the upstream 802.11i
decryption is happening. If it is happening at the AC endpoint of the
CAPWAP tunnel (centralized), then the WTP is only performing encryption
for the CAPWAP tunnel and is not involved in downstream OTA encryption.
If the .11i decryption is happening at the WTP, then the WTP is
decrypting packets from the STA first, then encrypting to send the clear
text packet through the protected CAPWAP tunnel upstream to the AC.

>From a threat model, if we are intending to address secure transport of
data packets within CAPWAP, doing 802.11i at the AC does not address
this requirement, CAPWAP must secure its own encapsulation as well.
That is why the draft includes the option of establishing a DTLS tunnel
for its data transport.  

/mgw/ Agreed!

   Nancy.

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]]
Sent: Tuesday, June 06, 2006 7:53 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Encryption Capabilities

Removing centralized encryption doesn't change the security properties
of CAPWAP.

HOWEVER, if you really want packets encrypted all the way to the AC, and
you remove centralized encryption, your WTPs first have to decrypt the
802.11 packet, and then re-encrypt it for DTLS transport.  This seems
like a lot of extra processor time for devices that need to be cheap and
disposable.  For example, OpenSSL on my dual 2.8GHz P4 machine can
process AES at roughly 424Mbps [1].  An embedded device with 1/10 my
processing power could only keep up with a 21.2 Mbps data flow.

[1] openssl speed -elapsed -evp aes-128-cbc

--
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

Pat Calhoun (pacalhou) wrote:
> But what we end up doing is providing two means to do the exact same 
> thing. I admit that I was surprised when the optional DTLS support was

> added for data frames in the CAPWAP draft. However, having thought 
> through the impact of this change, it actually does address the 
> previous issues I had raised against centralized 802.11i security,
which are:
>  
> 1. By encrypting at the AC, how does one support 802.11e (specifically

> frame fragmentation to fit a service period) 2. How does the AC 
> provide 802.11n A-MPDU/MSDU aggregation?
>  
> So I would propose we define one way, and I prefer the DTLS mechanism 
> as it doesn't introduce any issues in supporting any 802.11 feature.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit Cisco Systems
> 
>  
> 
>
------------------------------------------------------------------------
>     *From:* Dorothy Stanley [mailto:[email-masked]]
>     *Sent:* Monday, June 05, 2006 5:04 PM
>     *To:* Pat Calhoun (pacalhou)
>     *Cc:* Michael Montemurro; David T. Perkins; [email-masked]
>     *Subject:* Re: [Capwap] Encryption Capabilities
> 
> 
>     I do not agree with always requiring the WTP to provide wireless
>     encryption. The split MAC architecture allows 802.11
>     encryption/decryption
>     at either the WTP or the AC, and this flexibility should be
>     retained, with use of the
>     field in question clearly defined.
> 
>     Dorothy
> 
> 
>     On 6/5/06, *Pat Calhoun (pacalhou)* <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         communicate whether it is capable of providing its
capabilities,
>         and therefore allow the AC to determine whether it should
>         perform centralized encryption. However, with the transition
to
>         DTLS, I propose that we always require the WTP to provide
>         wireless encryption, and use DTLS between the AC and the WTP.
>          
> 
>         Pat Calhoun
------------------------------------------------------------------------
>             *From:* Michael Montemurro
>             [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             *Sent:* Saturday, June 03, 2006 12:12 PM
>             *To:* David T. Perkins
>             *Cc:* [email-masked] <mailto:[email-masked]>
>             *Subject:* Re: [Capwap] Encryption Capabilities
> 
>         David,
>          
>         Would it be sufficient to move Encryption Capabilities from
the
>         WTP Descriptor (Section 4.4.34) to the WTP Radio Information
>         On 6/3/06, *Michael Montemurro* <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             David,
> 
>             On 6/1/06, *David T. Perkins* <[email-masked]
>             <mailto:[email-masked]>> wrote:
> 
>                 HI,
> 
>                 The "(4.4.34)WTP Descriptor" message element has the
>                 subfield "encryption capabilities". What is this used
>                 for? If for radios, then it should be per radio. If
>                 for the user data between the WTP and AC, then
>                 it doesn't seem appropriate to say the value is
>                 defined by "specific binding" definitions because
>                 the WTP can be supporting multiple radios with
>                 some that provide encryption services and some
>                 that don't.
> 
>                 In general, I don't feel that this subfield is
>                 well defined, and it appears to me that it
>                 <http://lists.frascone.com/mailman/listinfo/capwap>
> 
>                 <http://lists.frascone.com/pipermail/capwap>
> 
> 
> 
> 
>
>         <http://lists.frascone.com/pipermail/capwap>
> 
> 
> 
> ----------------------------------------------------------------------
> --
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 7 Jun 2006 21:06:58 -0400 (EDT)

I've been watching this debate with some interest, being quite surprised that an optional feature would suddenly draw such attention and energy.

Still, I guess I should comment along with everyone else. First, I agree with Charles on the point that having or not having this feature has no impact on the security properties of the capwap protocol itself. Also, I agree with a number of folks on the point that these two features are orthogonal. AC termination of 802.11 link security does not (indeed, is not intended to) provide for capwap data channel security. However, this feature is not security-neutral - it provides a unique set of security properties that are useful. Before explaining further, here are some pictures, along with some descriptive text (hoping my webmail interface doesn't mangle them):

KEY
---
   # - 802.11 link security boundary

   % - capwap security boundary

Case 1: 802.11 link security terminates at the WTP
   
   #####################
   #                   #  %%%%%%%%%%%%%%%%%%%%%%%
   # +------+         +#--%-+   CAPWAP  +----+  %
   # |client|---------| WTP |===========| AC |  %
   # +------+         +#--%-+           +----+  %
   #                   #  %%%%%%%%%%%%%%%%%%%%%%%
   #####################

This is the situation when you en/decrypt 802.11 traffic at the WTP. In this case, the client and WTP are within the 802.11 link security boundary. Of course, this picture does not include key establishment, because during that phase, the security boundary is more like the one below, and also, the AAA server (not pictured) is involved. Also, one might choose to include the AC in the 802.11 link security boundary pictured above (even though it doesn't participate in the crypto ops) because it is privy to the 802.11 keying material, but I'm leaving this out because it simplifies the ascii drawing, and will add nothing material to the discussion below.

Case 2: 802.11 link security terminates at the AC

                                   %%%%%%%%%%%%%%%%%
                                   %  +-----+      %
                 /-----------------%--| WTP |      %
                 |                 %  +--++-+      %
                 |                 %     ||capwap  %
                 |                 %     ||        %
                 |                 % +---++--+     %
                 |                 % |       |     %
                 |                 %%%%%%%%%%%%%%%%%
   ##############|###############################
   # +------+    |                   |   AC  |  #
   # |client|----/   802.11          |       |  #
   # +------+                        +-------+  #
   ##############################################

Here is the case when you en/decrypt 802.11 at the AC. Note that the WTP is not within the 802.11 link security boundary. It is "out of the loop", so to speak, being little more than a transport provider. Also note that the capwap security boundary is the same as for case 1 - no change.

Now, let's get to the questions about whether this is useful or not, and let's keep in mind that since this is an *optional* feature, the "burden of proof" with respect to utility is much lower than it would be if it were mandatory to implement.

As noted above, in case 2, the WTP is simply a transport provider. That  means that if the WTP were somehow compromised, unless the attacker also compromised one or more of the other security mechanisms as well (802.1x, the AC's credential, etc), he could do little more than effect a DoS attack.

In case 1, various methods of WTP compromise could give an attacker access to the data as it is unencrypted and then re-encrypted. In this case, the attacker gets access to the cleartext data via relatively low-cost methods (compared to breaking .11 crypto), essentially attacking the weakest link.

In case 2, WTP's can be deployed in hostile territory, and if the attacker can't break the 802.11 crypto, he can't have the same security impact (aside from DoS, which he can have in any event). It's like running 802.11 security over the air - he has to break the crypto. No matter how completely the attacker might compromise a WTP, all he will see is encrypted data. This is good!

Of course, there is additional value to the centralized encryption model, as Dorothy Stanley pointed out: architectural flexibility, enabling CAPWAP compliant solutions to centralize the 802.11i crypto functions in the AC if they wish, reducing dependencies on WTP capabilities (e.g. legacy hardware that only supports TKIP),  potentially support a broader range of existing and future applications  - even when the primary motivation is not 'to secure the WTP-AC data  connection'". Some vendors chose this approach to MAC splitting while others chose encryption at the WTP. That's one reason why it should remain optional.

--Scott

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Thu, 8 Jun 2006 15:38:13 -0700

While it is true that the originating 802.11 data payload will be
obscured, it is not clear to me that we can construe it as "good".
Since there is no protection of the CAPWAP encapsulation, it is still
susceptible to attack, as is the entire CAPWAP encapsulation (should we
choose not to protect it).  Thus, in my view, it does not help a whole
lot.  Sure, if we believe the system is uncompromised then you are
correct that the data is not readily discernible but can we trust that
the data has not been compromised anyway?  No, not until it has gone up
to the AC and by that point, it is not clear whether the attack occurred
at the link between STA and WTP or WTP to AC.

	Nancy.

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Wednesday, June 07, 2006 6:07 PM
To: capwap
Subject: Re: [Capwap] Encryption Capabilities

I've been watching this debate with some interest, being quite surprised
that an optional feature would suddenly draw such attention and energy.

Still, I guess I should comment along with everyone else. First, I agree
with Charles on the point that having or not having this feature has no
impact on the security properties of the capwap protocol itself. Also, I
agree with a number of folks on the point that these two features are
orthogonal. AC termination of 802.11 link security does not (indeed, is
not intended to) provide for capwap data channel security. However, this
feature is not security-neutral - it provides a unique set of security
properties that are useful. Before explaining further, here are some
pictures, along with some descriptive text (hoping my webmail interface
doesn't mangle them):

KEY
---

   
   #####################

This is the situation when you en/decrypt 802.11 traffic at the WTP. In
this case, the client and WTP are within the 802.11 link security
boundary. Of course, this picture does not include key establishment,
because during that phase, the security boundary is more like the one
below, and also, the AAA server (not pictured) is involved. Also, one
might choose to include the AC in the 802.11 link security boundary
pictured above (even though it doesn't participate in the crypto ops)
because it is privy to the 802.11 keying material, but I'm leaving this
out because it simplifies the ascii drawing, and will add nothing
material to the discussion below.

                                   %%%%%%%%%%%%%%%%%
                                   %  +-----+      %

Here is the case when you en/decrypt 802.11 at the AC. Note that the WTP
is not within the 802.11 link security boundary. It is "out of the
loop", so to speak, being little more than a transport provider. Also
note that the capwap security boundary is the same as for case 1 - no
change.

Now, let's get to the questions about whether this is useful or not, and
let's keep in mind that since this is an *optional* feature, the "burden
of proof" with respect to utility is much lower than it would be if it
were mandatory to implement.

As noted above, in case 2, the WTP is simply a transport provider. That
means that if the WTP were somehow compromised, unless the attacker also
compromised one or more of the other security mechanisms as well
(802.1x, the AC's credential, etc), he could do little more than effect
a DoS attack.

In case 1, various methods of WTP compromise could give an attacker
access to the data as it is unencrypted and then re-encrypted. In this
case, the attacker gets access to the cleartext data via relatively
low-cost methods (compared to breaking .11 crypto), essentially
attacking the weakest link.

In case 2, WTP's can be deployed in hostile territory, and if the
attacker can't break the 802.11 crypto, he can't have the same security
impact (aside from DoS, which he can have in any event). It's like
running 802.11 security over the air - he has to break the crypto. No
matter how completely the attacker might compromise a WTP, all he will
see is encrypted data. This is good!

Of course, there is additional value to the centralized encryption
model, as Dorothy Stanley pointed out: architectural flexibility,
enabling CAPWAP compliant solutions to centralize the 802.11i crypto
functions in the AC if they wish, reducing dependencies on WTP
capabilities (e.g. legacy hardware that only supports TKIP),
potentially support a broader range of existing and future applications
- even when the primary motivation is not 'to secure the WTP-AC data
connection'". Some vendors chose this approach to MAC splitting while
others chose encryption at the WTP. That's one reason why it should
remain optional.

--Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 12 Jun 2006 12:58:24 -0700

At a minimum, the spec issues need to be addressed, so I'm ok with the
change. However, I do want to open up the discussion of whether we need
to keep this in the protocol to begin with, but as a separate topic.
Thanks for creating the issue to track it.

Pat Calhoun

	From: Michael Montemurro [mailto:[email-masked]] 
	Sent: Monday, June 12, 2006 11:58 AM
	To: Pat Calhoun (pacalhou)
	Cc: Dorothy Stanley; capwap
	Subject: Re: [Capwap] Encryption Capabilities

	So, again I propose the following changes for draft 2.0:
	 
	Would it be sufficient to move Encryption Capabilities from the
WTP Descriptor (Section 4.4.34) to the WTP Radio Information message
element (Section 4.4.39).
	 
	This addresses the comment on the WTP Descriptor and that change
can be made for draft 2.0.
	 
	Now it seems there is another broader issue on the support for
different modes of wireless link layer encryption in the CAPWAP
architecture. I've created issue 138 to address this issue.
	 
	Cheers,
	 
	     Mike

	On 6/12/06, Pat Calhoun (pacalhou) <[email-masked]> wrote: 

			However, the MUX issue has raised another
interesting problem, which 
			was raised by Scott, which is that in order for
the WTP to perform 
			packet classification, and tagging, it needs to
have access to the
			data frames in the clear, which is not possible
with this feature.

		The WTP can perform marking by
		mapping the WMM or 802.11e header info into DSCP/.1q/.1d
markings 
		Access to data frames in the clear is not needed.
		
		As raised a few times, one cannot trust a client's
marking. Centralized
		802.11i encryption does not allow the WTP to inspect
packets for TSPEC
		conformance.

		Pat Calhoun

_________________________________________________________________
		To unsubscribe or modify your subscription options,
please visit:
		http://lists.frascone.com/mailman/listinfo/capwap