IETF Logo Mail Archive

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

Alan DeKok <aland@deployingradius.com> Sat, 16 November 2019 14:36 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 3208A120233 for <emu@ietfa.amsl.com>; Sat, 16 Nov 2019 06:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 V72m19bxLu7Q for <emu@ietfa.amsl.com>; Sat, 16 Nov 2019 06:36:34 -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 3C7FF120170 for <emu@ietf.org>; Sat, 16 Nov 2019 06:36:29 -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 7BE4F613; Sat, 16 Nov 2019 14:28:37 +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: <MN2PR11MB39013A3A444461A78C42DE19DB730@MN2PR11MB3901.namprd11.prod.outlook.com>
Date: Sat, 16 Nov 2019 09:28:35 -0500
Cc: Jan-Frederik Rieckers <rieckers@uni-bremen.de>, "emu@ietf.org" <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8F65B52-FDEA-44EB-8ADA-CB88F1D9E3A6@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> <58473B30-802F-469A-8967-CE90316974E7@deployingradius.com> <MN2PR11MB39013A3A444461A78C42DE19DB730@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/2NrkJ5EPKtjW7og4Fa0hVlUeG6Q>
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: Sat, 16 Nov 2019 14:36:38 -0000

On Nov 16, 2019, at 7:59 AM, Owen Friel (ofriel) <ofriel@cisco.com> wrote:
> [ofriel] this seems like something reasonable, but that's more a general deployment recommendation: ensure that the identity/realm of EAP servers is different from the identity/domain of webservers within an org. Therefore in the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert,  clients can still distinguish between the two. Users point their Browser clients point to 'example.org' and wi-fi supplications are configured to look for 'radius.exampe.org'.
> 
> The supplicant logic for verifying EAP server identity (assuming it already knows the root CA and a realm/domain string) could be check for NAIRealm first, then check for id-kp-eapOverLAN, then check for a dnsName.

  There is currently no document which offers guidance for implementors.  There's just common practice, and various standards.  Which are unfortunately different.  Even worse, it's not clear how these practices interact, or how we should migrate from existing practice to using the standards.

  I think it would be useful for this WG to have a document which gives these guidelines.

  Aln DeKok.

v2.23.0 | Report a Bug | By Email