IETF Logo Mail Archive

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

Alan DeKok <aland@deployingradius.com> Tue, 12 November 2019 01:07 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 7562A120072 for <emu@ietfa.amsl.com>; Mon, 11 Nov 2019 17:07:40 -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 FSGqZdlSXH8v for <emu@ietfa.amsl.com>; Mon, 11 Nov 2019 17:07:38 -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 1BFF11200FE for <emu@ietf.org>; Mon, 11 Nov 2019 17:07:21 -0800 (PST)
Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id A91C78F8; Tue, 12 Nov 2019 01:07:18 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <MN2PR11MB3901077F38165EE241D30BC5DB740@MN2PR11MB3901.namprd11.prod.outlook.com>
Date: Mon, 11 Nov 2019 20:07:16 -0500
Cc: Jan-Frederik Rieckers <rieckers@uni-bremen.de>, Russ Housley <housley@vigilsec.com>, "emu@ietf.org" <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6632D477-CB45-4A41-8B17-74C38D1141FE@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>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/UsLaaFW6UhFWeNh8t2a_GC3ow30>
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 01:07:40 -0000

On Nov 11, 2019, at 6:15 PM, Owen Friel (ofriel) <ofriel@cisco.com> wrote:
> 
> This is also related to ongoing anima discussions about RFC 8366, and how it can bootstrap trust when the pinned domain cert is a public PKI CA, and not a private CA, and hence additional domain (or realm or FQDN) info is also needed in order for the peer to verify the identity of the server.
> 
> Its also relevant for ongoing Wi-Fi Alliance DPP discussions about bootstrapping a supplicant onto an 802.1X network - after a supplicant completes DPP and gets provisioned with a trust anchor - what if that trust anchor is a public PKI? It’s the same problem.
> 
> 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.

  That sounds reasonable.

  Certificates for 802.1X authentication already use DNS names.  It's not wide-spread, but it's not rare.  There's no *meaning* to these names, as nothing checks them.

  It would be useful to suggest how a supplicant can use these fields to further verify a server certificate.  And for servers, what these fields should contain.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email