Subject: Re: [Capwap] Consensus check for Issue 138: encryption/decryption at WTP/AC

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 1 Mar 2007 20:52:40 -0500 (EST)

Hi Dorothy,

I'm repeating some early commentary on this topic below. For those who don't want to read through it, the short summary is this: centralized encryption support has been a part of the capwap effort since very early on. The push to remove it has been primarily sponsored by one person, and most other folks have stayed out of the fray. Central encryption provides clear value, and no valid arguments for its removal have been presented here. This issue should be closed, and the existing text should remain.

Centralized encryption 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:

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. 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. Interoperability entails supporting both approaches.

Scott

-----Original Message-----
>From: [email-masked]
>Sent: Mar 1, 2007 2:33 PM
>To: [email-masked], [email-masked]
>Cc: [email-masked], [email-masked]
>Subject: Re: [Capwap] Consensus check for Issue 138: encryption/decryption	at WTP/AC
>
>Dear CAPWAP WG-
>
>We've had only 2 comments on the consensus call for issue 138, and the
>consensus check will end today.  This is not enough response to claim
>consesus and close the issue before the upcomning draft deadline of
>March 5th.  
>
>Is there some confusion on this issue that the group doesn't want to
>weigh in on consensus?  Should 138 be removed from the issue DB due to
>lack of interest?
>
>This issue will have to remain open and will not be included in the next
>draft that is targeted for IEEE review.
>
>Best Regards,
>Dorothy, Mani and Margaret.
>
>
>
>> _____________________________________________ 
>> From: 	Gellert Dorothy (Nokia-SIR/MtView)  
>> Sent:	Friday, February 23, 2007 2:46 PM
>> To:	[email-masked]
>> Cc:	ext Mani, Mahalingam (Mani); [email-masked]; Gellert
>> Dorothy (Nokia-SIR/MtView)
>> Subject:	Consensus check for Issue 138: encryption/decryption at
>> WTP/AC
>> 
>> Dear CAPWAP WG,
>> During the CAPWAP Interim meeting in San Jose last month, we discussed
>> issue 138: Wireless Encryption/Decryption at the WTP/AC, but did not
>> achieve clear consensus. This issue has been discussed at length since
>> IETF 67 in San Diego and on the list over the past few months. 
>> The chairs would like to close this issue  with WG consensus on one of
>> the following proposals that have the most WG support:
>> 1) To provide system component interoperability, the WTP MUST support
>> 802.11 encryption/decryption at the WTP, and the WTP MUST support
>> 802.11 encryption/decryption at the AC. The AC MUST support either
>> 802.11 encryption/decryption at the WTP or 802.11
>> encryption/decryption at the AC.
>> The AC MAY support both 802.11 encryption/decryption at the WTP and
>> 802.11 encryption/decryption at the AC.
>> -OR-
>> 2) To provide system component interoperability, the WTP and AC must
>> support 802.11 encryption/decryption at the WTP. The WTP and AC MAY
>> support 802.11 encryption/decryption at the AC. 
>> Note the 2 proposals differ with support of 802.11
>> encryption/decryption at the AC.
>> As there has been no objections to the optional use of DTLS in the
>> Data Plane, this portion of issue 138 is closed. 
>> Please submit your choice and opinions on this topic to the WG list by
>> March 1st for a final consensus call on this feature.   This is a
>> short consensus call since the last date to submit drafts for IETF 68
>> is March 5th.   If we cannot agree to come to consensus in the next
>> week, this issue will remain unresolved in the draft targeted for
>> review in IEEE.  
>> Best Regards,
>> Dorothy, Mani and Margaret.
>> 

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

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

---

From: <[email-masked]>
Date: Thu, 1 Mar 2007 21:45:33 -0600

Hi Scott,

<capwap chair hat off>

I can see some the points raised for centralized encryption and agree we
need to support this case.  But it seems to me, the most interoperable
case is the one where the AC may or may not support encryption, Option
2.

If we have option 2, and AC encryption (centralized) is a MAY, then all
your points will still be covered, and in addition we ensure greater
backward compatability with 802.11 chipsets, for environments with
existing hardware, thus gaining better interoperability and CAPWAP
compliance.

Its important to preserve the case where an enterprise may have a mix of
802.11 equipment.  I believe supporting a wider base will make CAPWAP a
greater market success, especially in an initial version.

-DorothyG

> From: ext Scott G. Kelly [mailto:[email-masked]] 
> Sent: Thursday, March 01, 2007 5:53 PM
> To: Gellert Dorothy (Nokia-SIR/MtView); [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Capwap] Consensus check for Issue 138: 
> encryption/decryptionat WTP/AC
> 
> Hi Dorothy,
> 
> I'm repeating some early commentary on this topic below. For 
> those who don't want to read through it, the short summary is 
> this: centralized encryption support has been a part of the 
> capwap effort since very early on. The push to remove it has 
> been primarily sponsored by one person, and most other folks 
> have stayed out of the fray. Central encryption provides 
> clear value, and no valid arguments for its removal have been 
> presented here. This issue should be closed, and the existing 
> text should remain.
> 
> Centralized encryption 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:
> 
> 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 
> Now, let's get to the questions about whether this is useful 
> or not. 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 
> 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. 
> Interoperability entails supporting both approaches.
> 
> Scott
> 
> 
> >This issue will have to remain open and will not be included in the 
> >next draft that is targeted for IEEE review.
> >
> >Best Regards,
> >> During the CAPWAP Interim meeting in San Jose last month, we 
> >> discussed issue 138: Wireless Encryption/Decryption at the WTP/AC, 
> >> but did not achieve clear consensus. This issue has been 
> discussed at 
> >> length since IETF 67 in San Diego and on the list over the 
> past few months.
> >> The chairs would like to close this issue  with WG 
> consensus on one 
> >> of the following proposals that have the most WG support:

---

From: Scott G Kelly <[email-masked]>
Date: Fri, 02 Mar 2007 04:56:49 -0800

What 802.11 chipsets don't support this functionality?

[email-masked] wrote:
>> encryption/decryption	at WTP/AC
>>> Dear CAPWAP WG-
>>>