Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

Alan DeKok <aland@deployingradius.com> Tue, 12 November 2019 16:32 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5713120108 for <emu@ietfa.amsl.com>; Tue, 12 Nov 2019 08:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lIkeVl4LZRuH for <emu@ietfa.amsl.com>; Tue, 12 Nov 2019 08:32:07 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAD6120098 for <emu@ietf.org>; Tue, 12 Nov 2019 08:32:07 -0800 (PST)
Received: from [192.168.20.141] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id A2993606; Tue, 12 Nov 2019 16:32:04 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de>
Date: Tue, 12 Nov 2019 11:32:03 -0500
Cc: "emu@ietf.org" <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <58473B30-802F-469A-8967-CE90316974E7@deployingradius.com>
References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <D735A4DB-1CFB-4DF4-ACB7-BC6EFDBC6CDE@deployingradius.com> <E0B8DAA7-8C7C-455F-B5BE-128670A093D3@vigilsec.com> <BD30A64D-539C-422D-9413-880AF8D6A16F@deployingradius.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <MN2PR11MB3901077F38165EE241D30BC5DB740@MN2PR11MB3901.namprd11.prod.outlook.com> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de>
To: Jan-Frederik Rieckers <rieckers@uni-bremen.de>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/XxM8WtVv_r7NhMwVctM7dkzRK9U>
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 16:32:10 -0000

On Nov 12, 2019, at 2:53 AM, Jan-Frederik Rieckers <rieckers@uni-bremen.de> wrote:
> 
> Signed PGP part
> On 12.11.19 00:15, Owen Friel (ofriel) wrote:
>> One deployment consideration is if an operator wants to use a public PKI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, before these extensions could be supported (as Alan alludes to), so it would also be good to define how this could work with standard RFC 6125 DNS-IDs / RFC 5280 dNSNames.
> 
> I had a lot of thoughts about this topic.
> I am experimenting with certificates in EAP-TLS contexts and experienced
> the problems with getting a certificate with specific extension
> properties from our public PKI. (In my case a test certificate with a
> critical MustStaple extension)
> 
> The Problem with dNSNames is that they are also used in other contexts
> (mainly HTTPS).

  They're also domain names, not realms.  A particular certificate may be valid for authenticating uses to the realm "example.org".  That same certificate may not be valid for the main web site for "example.org".

  This means that domain names are a hint, but not authoritative.  Only the NAIRealm field would be authoritative.  i.e. "this certificate really is for users authenticating to a realm".

> There would be the possibility to define a specific
> prefix to bind it to a Realm without having the certificate being valid
> for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm
> uni-bremen.de) but I don't see the advantage in that.
> This will probably don't really lead to a change in the supplicants
> implementations.

  A common short-hand is for certificates to use the "radius" subdomain.  e.g. "radius.example.org".  While not perfect, it's something.

> My deployment experience shows, that the certificate check is the main
> security problem in WPA2-Enterprise networks. I have seen instructions
> for installing WPA2-Enterprise networks where they have explicitly
> suggested switching off the certificate check, probably because it was
> too complicated for the users and would lead to people complaining at
> the IT department about the complicated setup.

  Exactly.

 
> A setup of WPA2-Enterprise can be secure if all devices are part of a
> centralized Device Management, but especially in eduroam this isn't
> possible. We have a lot of people who don't really care about security.

 What's worse is that there's no cross-platform way to set up 802.1X.  It would be nice if a user could visit an HTTPS secured web site for example.com, and then download a supplicant configuration.  Stefan Winter has a draft:

https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00

  But it received little support from vendors.

  Security should be simple, and it should be the default.  Users don't care about security because it's hard, and because it too often prevents them from getting things done.  If security is useful, they will use it.

  Alan DeKok.