Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

Alan DeKok <aland@deployingradius.com> Sat, 18 January 2020 13:05 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 C91F712001E; Sat, 18 Jan 2020 05:05:19 -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 L8ZM3Mu--S7S; Sat, 18 Jan 2020 05:05:14 -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 7C1E01200C1; Sat, 18 Jan 2020 05:05:14 -0800 (PST)
Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id E1A74650; Sat, 18 Jan 2020 13:05:10 +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 13.0 \(3608.40.2.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAErg=HE0XDbhuibtky5VhvZYUnQxDitLSEuf4uzXnuByNQN+4Q@mail.gmail.com>
Date: Sat, 18 Jan 2020 08:05:09 -0500
Cc: "Owen Friel (ofriel)" <ofriel@cisco.com>, Benjamin Kaduk <kaduk@mit.edu>, EMU WG <emu@ietf.org>, Joseph Salowey <joe@salowey.net>, Michael Richardson <mcr+ietf@sandelman.ca>, "spasm@ietf.org" <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com>
References: <B2989B0E-8B6B-4B7A-B871-AF520310B3FC@deployingradius.com> <CAErg=HG06ZpiRUYogiVwoJPsZDsjzAVvO0B4=K=PE7aAHe44rA@mail.gmail.com> <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <CAErg=HFPCYKgUEXHaOC0sQECYaVmt0TZXe-uDrKzFiNSAcdckg@mail.gmail.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <CAErg=HFYQpfqTE9==TzGo795ZiuNBGVMqWuXS6GJ2DV0nGxPzA@mail.gmail.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <CB67C090-4D6A-4586-AD7C-99A29EF5D92D@deployingradius.com> <CAOgPGoDADPY125Bf7mbPCpEVkwVF=YmbG9wAN0S-WyCWg27BCw@mail.gmail.com> <20200116040715.GC80030@kduck.mit.edu> <CAErg=HHwLOw9sL2=nGca5MuuyiV2Zghrp6prR7SqLJAvfCLmjA@mail.gmail.com> <B3A03277-C176-4E63-ADB3-70133E2ABA46@deployingradius.com> <MN2PR11MB3901D1B17802F2DACCC8966CDB300@MN2PR11MB3901.namprd11.prod.outlook.com> <CAErg=HE0XDbhuibtky5VhvZYUnQxDitLSEuf4uzXnuByNQN+4Q@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/mvSSNXWR4R1SP7IZ9xsVUSI7Vu4>
Subject: Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
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, 18 Jan 2020 13:05:20 -0000

On Jan 18, 2020, at 2:20 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> 
> Or... just stop using those certs/roots already? We’ve already identified that there is absolutely zero reason to do so in the extant status quo, because it still requires manual configuration.

  ... for EAP.  And only for EAP.

  That comment doesn't apply to SMTP, XMPP, IMAP, DNS over TLS, VPNs, RADIUS over TLS, etc..  SMTP servers mis-use "WWW" certificates precisely *because* it requires zero client configuration.  It leverages an existing trust store to increase security.  And that's a good thing.

  As noted by Michael, CAs are using certificates in a way that violates their own policy.  The mis-use problem is therefore larger, and worse, than the minor issue of EAP *sometimes* using WWW certs.

  My previous messages explained that the common practice for EAP is to use private CAs.  For the reasons you outlined above, and more.  Pretty much everyone in the EAP community was convinced of this 15+ years ago.  It has been standard / recommended practices for 15+ years.

  Finally, there are reasons to use public CAs for EAP.  I have customers who do this today, for internal corporate policy reasons.  I've recommended that they don't do it, but their internal "security" team over-rules me.

  The rest of your comments are trying to convince people of things that they're already convinced of.  We already know this, we already agree (mostly).

  The disagreement is this: your underlying assumption is that these are the rules, and they have to be followed.  I believe that this is the IETF, and that we make the rules.  If we need to change the rules, then we just do so.  And the Internet community has to follow.

  There are details as to which rules apply where, and to who.  But as the IETF, we are entirely within our purview to allow the use of id-kp-serverAuth in EAP, SMTP, etc..  Or, to come up with a new scheme that replaces id-kp-serverAuth.

  If the rules have to be applied strictly, then you have been made aware that the CAs you pointed to are violating their own policies.  Therefore, you are under a moral obligation to report this mis-use to them.  Failure to do so is a tacit admission that you are not applying the rules in practice.  While at the same time, claiming that the rules have to be stringently followed.

  Alan DeKok.