Subject: Re: [Capwap] Encryption Capabilities

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 9 Jun 2006 06:55:04 -0700

I agree with Nancy. It's almost like CAPWAP products would need to
ship a "security requirements table", and allow the customer to pick
and choose from what they think they need, and then enable the various
features. Why not simply support a single mechanism that is a superset
of all features and call it a day? 

We seem to be contradicting ourselves here. In some threads we are 
arguing for protocol simplicity, then in others we seem to accept
complexity (and, yes, I view multiple options that provide similar
features are adding complexity, because in the end we all have to
implement them, and leave it to the customer to deal with the issue).

To date, other than stating that "we need to support it", no one has 
been able to state how 802.11i packet encryption services in the AC
allows an AC/WTP to actually support the complete 802.11 protocol.

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.
so I see this as just adding yet another option for end users to deal
with. BTW, if we need the WTP to do packet classification, we need
to create a new issue because the protocol does not have the means 
to push down rules.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Nancy Winget (ncamwing) 
> Sent: Thursday, June 08, 2006 3:38 PM
> To: Scott G. Kelly; capwap
> Subject: Re: [Capwap] Encryption Capabilities
> 
> 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
> ---
>    # - 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
> 
> _________________________________________________________________
> 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
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Mon, 12 Jun 2006 07:42:18 -0700

I support Mike's suggestion for solving the original issue raised by David:

move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the
WTP Radio Information message element (Section 4.4.39)

> of all features and call it a day?

There isn't a single mechanism to support all features. One feature
is to decrypt at the AC. This enables capwap implementations to
provide functionality not available at the WTP. Another feature is to
protect data over the WTP/AC link. These are not the same.

> implement them, and leave it to the customer to deal with the issue).

 In the case
we are discussing here, implementation of 802.11 crypto at the
AC is an optional feature. It is not required, and need not be implemented.

> allows an AC/WTP to actually support the complete 802.11 protocol.

There are mandatory and optional portions of the 802.11 protocol.
For example,  both security and QOS are optional portions of the
protocol, and the QOS services that are typically supported are WMM based,
not 802.11(e) based. 802.11i packet encryption services in the AC
allow the AC to support, for example AES encryption for WTPs which
do not support it, and allows vendor flexibility. It is an option that is
currently in the draft - do not have to implement if you don't want to, e.g.
an AC implementation that supports local MAC only does not have to do this.

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