Re: [Emu] Best practices for supplicants and authenticators

Alan DeKok <aland@deployingradius.com> Wed, 20 November 2019 14:16 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 0D1081208DA for <emu@ietfa.amsl.com>; Wed, 20 Nov 2019 06:16:30 -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 S5v8VCZoM9Tl for <emu@ietfa.amsl.com>; Wed, 20 Nov 2019 06:16:28 -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 239F91200EB for <emu@ietf.org>; Wed, 20 Nov 2019 06:16:27 -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 D2BF9333; Wed, 20 Nov 2019 14:16:25 +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: <MN2PR11MB3901E1330C1B9E79233B09BADB4F0@MN2PR11MB3901.namprd11.prod.outlook.com>
Date: Wed, 20 Nov 2019 09:16:24 -0500
Cc: EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A77392F7-DCEB-4403-B485-B0670F369BA3@deployingradius.com>
References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> <MN2PR11MB3901E1330C1B9E79233B09BADB4F0@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/nKwoYihyrjrG73Z3p6oMPe6GxWg>
Subject: Re: [Emu] Best practices for supplicants and authenticators
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: Wed, 20 Nov 2019 14:16:30 -0000

On Nov 19, 2019, at 10:40 PM, Owen Friel (ofriel) <ofriel@cisco.com> wrote:
> 
> Assuming that NAIRealm is a registered domain as per RFC 7542, and thus public CAs can verify ownership, the goal / where we want to get to is:
> 
> - CA may be a public CA and thus public CAs can be enabled by default in supplicant config

  I would add: only if the new checks pass.

> - supplicant checks NAI Realm in the EAP identity cert matches that of the user's realm
> - supplicant verifies id-kp-eapOverLAN is set

  In addition to id-kp-serverAuth.  We still need a way to distinguish server certificates from client certificates.

> And also assuming that public CAs will not issue certs with an NAIRealm or id-kp-eapOverLAN bit. (This is certainly true for Let's Encrypt. See below for details.) And it could be years before public CAs do.

  I agree.

> Does that mean there is an intermediate rollout phase where the supplicant checks that the realm the user enters matches a dNSName in the EAP cert?

  It's worth checking that anyways.  It can be done quickly by supplicants, and doesn't require changes to any CAs.

> The rollout / upgrade issue with this is of course if we give guidance that supplicants
> (i) check that entered realm matches NAIRealm; and id-kp-eapOverLAN is set
> If that fails then (ii) check that dNSName matches entered realm

  Yes.

> at what point in time would supplicant behaviour ever change to remove the fallback to option (ii) and checking dNSName only?

  I'm not sure.

> As a data point on RFC 4985 and id-mod-dns-srv-name-93 (or RFC 6125 SRV-IDs): Public CAs generally don't issue these either, so the same issue with supplicants checking for NAIRealm or id-kp-eapOverLAN exists with id-mod-dns-srv-name-93 w.r.t. Public CAs.

   I agree.

  TBH, even if these practices are only implemented in a roaming consortium, they will still be useful.  A roaming consortium can create their own CA with their own rules.

  i.e. even if just Eduroam adopts this practice, then it can be used by millions, if not tens of millions of people.  And making EAP easier to use is always of enormous utility.

  Alan DeKok.