Re: [OPSAWG] Simplified Alternative to CAPWAP

Björn Smedman <bjorn.smedman@anyfinetworks.com> Tue, 25 February 2014 13:22 UTC

Return-Path: <bjorn.smedman@anyfinetworks.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 3C70F1A06EF for <opsawg@ietfa.amsl.com>; Tue, 25 Feb 2014 05:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.622
X-Spam-Level: *
X-Spam-Status: No, score=1.622 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 uXwaQ_Fx8cnp for <opsawg@ietfa.amsl.com>; Tue, 25 Feb 2014 05:22:38 -0800 (PST)
Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id D5C3B1A06F0 for <opsawg@ietf.org>; Tue, 25 Feb 2014 05:22:37 -0800 (PST)
Received: by mail-oa0-f54.google.com with SMTP id n16so345663oag.27 for <opsawg@ietf.org>; Tue, 25 Feb 2014 05:22:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zMtY6C1H3ylBHA+IQ41FZ7MWau+Xn/MYaLoG//qq3fQ=; b=Ev3VAeVlJ8YkhecQGcEiNcPI7sdYPRNY1RM5Sg6NqNImgaZUitALkDutnM7gOA1wNg OKun+wHZf+eZfPrqfvJ+XSKMe5e2x68X4Q2d47fPjWdI6mtn1ufDUeoKn3TNHlBAuXDy jGqx1thZ/JJ1OsarmDej2Lizhu60IcEfgttB5Q06mNiVlW3f0pPA28KJZMz44x91sp/Y XDRwiEKAO6L7pqdPxRtmzWWr2TebfjQm1Rf40LjFhe7/cGa5w0tZCZcbkD9xATGelMtc F3r9w0el1Pj8M1OVbcRPLg12F/68idu5q5Ep/M2Z7cqLZ08XkG+3m8I5Epfb9ZRWlKwM dtXQ==
X-Gm-Message-State: ALoCoQmo7/2qEc2+c6lZS+jSecnBMNBiyVyhgOqx56vOmo2EVejkzXDGyj8AEBp2+T50iFzjdGQG
MIME-Version: 1.0
X-Received: by 10.182.55.65 with SMTP id q1mr827329obp.70.1393334556898; Tue, 25 Feb 2014 05:22:36 -0800 (PST)
Received: by 10.182.191.9 with HTTP; Tue, 25 Feb 2014 05:22:36 -0800 (PST)
X-Originating-IP: [82.99.7.230]
In-Reply-To: <CAProHAQvrVgkDtQN-CRyPj-zHGFomcZB0pd0VmCQGnYUQ7rY=g@mail.gmail.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>
Date: Tue, 25 Feb 2014 14:22:36 +0100
Message-ID: <CAO_acpt4C+hSrimt7Seaxx7H5-U+12wAGfHM5cp6LGVPRCwH8g@mail.gmail.com>
From: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= <bjorn.smedman@anyfinetworks.com>
To: "Cao,Zhen" <zehn.cao@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/I4kuRWEjOmMyc7u6D_8l3UVWbpg
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 13:22:40 -0000

Hi Zhen,

On Tue, Feb 25, 2014 at 9:27 AM, Cao,Zhen <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