Capwap Mailing List: Re: Consensus check for Issue 138: encryption/decryption at WTP/AC

[Scott G. Kelly (s.kelly]

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: Dorothy.Gellert [at] nokia.com
>Sent: Mar 1, 2007 2:33 PM
>To: Dorothy.Gellert [at] nokia.com, capwap [at] frascone.com
>Cc: margaret [at] thingmagic.com, DStanley [at] arubanetworks.com
>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:  capwap [at] frascone.com
>> Cc:  ext Mani, Mahalingam (Mani); margaret [at] thingmagic.com; 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.
>>