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

[Abhijit Choudhury (abhijit10425]

Hi Scott,

 

I don't think Option 2  in any way prevents centralized encryption from being deployed.  It just doesn't mandate that the WTP vendors MUST support both modes.  An AC doing centralized encryption can still interoperate with WTPs that implement this option.

 

As for your discussion on how secure centralized encryption is, let me point out that with encryption at the WTP and the DTLS on the data channel, one will have to break into the WTP and intercept the data between the 802.11i decryption and the DTLS encryption to compromise the security. On the other hand with centralized encryption,the entire 802.11 header and the CAPWAP header is unauthenticated and in the clear making it possible to launch several kinds of spoofing attacks.

 

Again, like I said, the issue is not to debate which mode of operation - encryption at the WTP or encryption at the AC - is better. The question is whether WTPs should be forced to support both modes, or if supporting encryption at the AC as an option is good enough. I would argue that the latter is sufficient.

 

Regards,

Abhijit

-----Original Message-----
From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com]
Sent: Thursday, March 01, 2007 5:53 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

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.
>>

---

8:00? 8:25? 8:40?  Find a flick in no time
 with theYahoo! Search movie showtime shortcut.