Re: [OPSAWG] Simplified Alternative to CAPWAP

"Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com> Tue, 25 February 2014 17:18 UTC

Return-Path: <rpazhyan@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471DD1A01DB for <opsawg@ietfa.amsl.com>; Tue, 25 Feb 2014 09:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.747
X-Spam-Level:
X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7nv2Z_GUj45 for <opsawg@ietfa.amsl.com>; Tue, 25 Feb 2014 09:18:20 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id D28C61A0111 for <opsawg@ietf.org>; Tue, 25 Feb 2014 09:18:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16102; q=dns/txt; s=iport; t=1393348699; x=1394558299; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EGx1PLeRWJXsJeGUQxCAls0iCLgNlVKCkvpmUJ5uyXU=; b=eU7cbhOEsIr64Jk/WMzgNMqF3/gQulIAgmz1YFrbOAJv+kjEKUTKir8W Eqp05ZOjUi4dZEQYsIN+WF83imLKUIYwXFmuSlTkBFWHNXU4WESRMCZSL 1lLtIoQSRNtjjhviIcCc+1RWhiqqE4jOxWjYXoE/lW546h2pPg5nxI2hb g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0GAFfPDFOtJXHB/2dsb2JhbABZgkJEO1eDA6g+jTiIWBiBABZ0giUBAQEDASMKOhIFBwQCAQgRAQMBAQEKHQMCAgIfERQDBggCBA4FCIdpAwkIDaZDmUkNhnEXjE+BZDEHBoJpNYEUBJZHgx+LLoVHgy2CKg
X-IronPort-AV: E=Sophos; i="4.97,541,1389744000"; d="scan'208,217"; a="23063092"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-3.cisco.com with ESMTP; 25 Feb 2014 17:18:18 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1PHIIK9020297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 17:18:18 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.22]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 11:18:18 -0600
From: "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>
To: =?utf-8?B?QmrDtnJuIFNtZWRtYW4=?= <bjorn.smedman@anyfinetworks.com>, "Cao, Zhen" <zehn.cao@gmail.com>
Thread-Topic: [OPSAWG] Simplified Alternative to CAPWAP
Thread-Index: AQHPMbPgQtd3dWdjMUewmYg0xTSiXZrFGNzwgACBJoCAAG38AIAAUnsA///bPFA=
Date: Tue, 25 Feb 2014 17:18:17 +0000
Message-ID: <4ED2E36A22261145861BAB2C24088B4320F5E1E9@xmb-aln-x09.cisco.com>
References: <CAO_acptCXNzu09qH1sxig+qbjJXX0KMUmbA35LOo6KoRrG8vPg@mail.gmail.com> <4ED2E36A22261145861BAB2C24088B4320F5D75F@xmb-aln-x09.cisco.com> <CAO_acpvjJOjqRD8xc3Kf4T19RjA3XossrwwiNKrzFUrU+aa-Fg@mail.gmail.com> <CAProHAQvrVgkDtQN-CRyPj-zHGFomcZB0pd0VmCQGnYUQ7rY=g@mail.gmail.com> <CAO_acpt4C+hSrimt7Seaxx7H5-U+12wAGfHM5cp6LGVPRCwH8g@mail.gmail.com>
In-Reply-To: <CAO_acpt4C+hSrimt7Seaxx7H5-U+12wAGfHM5cp6LGVPRCwH8g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.35.68.69]
Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F5E1E9xmbalnx09ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/nS-qi8yuI2QzSuJyuU2lyZV8Lpw
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 17:18:23 -0000

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:bjorn.smedman@anyfinetworks.com]
Sent: Tuesday, February 25, 2014 5:23 AM
To: Cao,Zhen
Cc: Rajesh Pazhyannur (rpazhyan); opsawg@ietf.org
Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP

Hi Zhen,

On Tue, Feb 25, 2014 at 9:27 AM, Cao,Zhen <zehn.cao@gmail.com<mailto:zehn.cao@gmail.com>> 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