Re: [OPSAWG] Simplified Alternative to CAPWAP

["Rajesh Pazhyannur (rpazhyan)" <[e-mail]>]

This is the reason we insist on always implementing both 802.11 encryption and 802.1X authentication at the tunnel termination point (e.g. an access router) in our SDWN architecture [2]. Unlike the WTP the tunnel termination point can often be physically protected. This provides strong guarantees of user data plane integrity and confidentiality, and also protects the mutual authentication property of the underlying IEEE 802.11i security mechanism.

>  I think I understand the problem even better now :) . It appears that the draft Alternate Tunnel Encapsulation for Data Frames in CAPWAP", http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/  would meet the requirement to tunnel data traffic to different tunnel end point. You would set the MAC mode to split mac and tunnel mode to 802.11. The only missing piece would be to specify the that 802.11 frame encryption should happen at the tunnel termination point and not the WTP.  There is no current way to negotiate that. Note that we are solving a similar problem (in the context where AC is the tunnel termination point) http://tools.ietf.org/html/draft-ietf-opsawg-capwap-hybridmac-02.
So potentially a new split MAC profile in the case the tunnel termination is not at the AC.

-----Original Message-----
From: Björn Smedman [mailto:[e-mail]]
Sent: Tuesday, February 25, 2014 5:23 AM
To: Cao,Zhen
Cc: Rajesh Pazhyannur (rpazhyan); [e-mail]
Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP

Hi Zhen,

On Tue, Feb 25, 2014 at 9:27 AM, Cao,Zhen <[e-mail]<mailto:[e-mail]>> wrote:
> Appreciate your analysis.

Thanks, likewise.

>> True, in CAPWAP it's a border case that 802.1X key exchange and
>> 802.11 encryption protects the user data plane all the way from the
>> mobile STA to the AC. But I think there are strong reasons to make
>> this the
>> default:
>
> But I do not agree here. The 802.11 key only protect the data from STA
> to WTP, NOT the AC, both in local MAC and also one option in the split
> model.  http://tools.ietf.org/html/rfc5416#section-2.2.2

I share your understanding that in the CAPWAP Local MAC mode, and most implementations of Split MAC, the 802.11 key only protects user data between STA and WTP. But what I'm saying is that this is unfortunate.

In the corporate WLAN environment for which CAPWAP was originally designed there is an assumption that WTPs and the Distribution System
(DS) are physically protected, by doors, badges and security personnel. If somebody gets through those protections and can access the WTP or DS then there are other things to worry about.

But in a carrier Wi-Fi environment this assumption no-longer holds true. WTPs are installed in coffee shops, restaurants, stadiums and even fixed-line subscriber homes (as a "second SSID" on a residential gateway). There is ample opportunity for an attacker to go to work on a WTP, perhaps even in the privacy of their own home.

If a single one of those WTPs is compromised (and CAPWAP mode is Local MAC or Split MAC with encryption in WTP) then there is no-longer any guarantee of user plane integrity or confidentiality for users of that WTP. But perhaps more alarmingly there is now also a gaping hole in the mutual authentication property of IEEE 802.11i, which means that all users of the wireless network are opened up to possible man-in-the-middle (MITM) attack [1]. If you combine this fact with automatic SIM authentication and global roaming the potential impact is significant.

This is the reason we insist on always implementing both 802.11 encryption and 802.1X authentication at the tunnel termination point (e.g. an access router) in our SDWN architecture [2]. Unlike the WTP the tunnel termination point can often be physically protected. This provides strong guarantees of user data plane integrity and confidentiality, and also protects the mutual authentication property of the underlying IEEE 802.11i security mechanism.

Best regards,

Björn

1. This risk of MITM in a "secure" Wi-Fi network may not be entirely obvious. We explain this risk when an attacker has access to authentication credentials/interface here:
http://anyfi.net/documentation#i_mutual_authentication. The same reasoning however holds true if the attacker can forward IEEE 802.11 frames between a targeted device and a CAPWAP AC, and get the 802.11 key from that AC (as in http://tools.ietf.org/html/rfc5416#section-6.15).

2. http://anyfi.net/documentation#a_data_plane