Re: [saag] Would love some feedback on Opportunistic Wireless Encryption

"Dan Harkins" <> Thu, 27 August 2015 05:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DC8B51A892E for <>; Wed, 26 Aug 2015 22:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CmQJ_1P1JZct for <>; Wed, 26 Aug 2015 22:44:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6FCF51A00AC for <>; Wed, 26 Aug 2015 22:44:27 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 0D70C1022404A; Wed, 26 Aug 2015 22:44:27 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Wed, 26 Aug 2015 22:44:27 -0700 (PDT)
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Wed, 26 Aug 2015 22:44:27 -0700 (PDT)
From: "Dan Harkins" <>
To: "Warren Kumari" <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <>
Cc: "" <>
Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Aug 2015 05:44:29 -0000

  Hi Warren,

  One more thing...

On Wed, August 26, 2015 7:53 am, Warren Kumari wrote:
> Hi there all,
> I'd appreciate it if folk could have a look at this draft and provide
> any feedback.
> I'm not sure that SAAG is the right place for it, but I couldn't think
> of anywhere better.
> Note that this is NOT intended to be the be all and end all of secure
> wireless, it is simply intended to make open wifi suck somewhat less.
> We are not claiming great security (the WPA2 4-way handshake
> significantly limits what can be achieved), and so much of the draft /
> idea is making sure that users do not get a false (or any) sense of
> security - this should be transparent to them.
> We also want it to be *really* simple, so that commodity CPE vendors
> will include "support" (basically a flag in the beacon) - this removes
> other solutions like .1X, etc.

  Typically, the AP advertises its security policy with an "RSN element"
in its beacons and probe responses. This lists the unicast and broadcast
ciphers it supports, the capabilities (current broadcast replay counter,
whether an extended key ID is used, etc) and some other stuff. The
client selects a complete subset and adds the "RSN element" when
associating to indicate it is agreeing to do that particular set of
policy and the AP acks it back in the associate response. The policy
offer and selection are confirmed in the 4-way handshake to prevent
downgrade attacks.

  If you're gonna make this look like an open network you're gonna
have to somehow plumb this information into other components of the
frames since the presence of an "RSN element" would mean the SSID is
not open. You could include an "RSN element" in the OWE Vendor-Specific
OWE Support Advertisement element you define but you're gonna need to
somehow get the client to select a proper subset and the AP to ack it
prior to beginning the 4-way handshake. You may want to add the OWE
Support Advertisement (with the "RSN element" embedded in it) to
associate requests and associate responses too. This is getting a
bit ungainly.

  You might want to reconsider making it an open network. You could
specify an encrypted network but use a Vendor-specific "AKM Suite"
in the "RSN element" to indicate OWE. That way it won't show up on
legacy clients as a network that needs a password. Legacy clients
just won't know what the hell it is. This would allow you to keep
the existing "RSN element" in the beacons, probe responses, associate
request/responses, and 4-way handshake. Add on the Vendor-specific
element to pass DH exponentials (what I suggested in my previous
email) and do a DH in the 4-way handshake and I think you've got
something workable. No password needed, resistant to passive attack,
still susceptible to an active MiTH (which is problematic because it
requires the MiTM to impersonate the AP while in range of it),
better than WPA2-PSK, genuinely sucks less.