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

Alan DeKok <aland@deployingradius.com> Mon, 20 January 2020 16:19 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 D604C12089F; Mon, 20 Jan 2020 08:19:45 -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 AMURqBtqEXQq; Mon, 20 Jan 2020 08:19:32 -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 955B51208A1; Mon, 20 Jan 2020 08:19:26 -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 C1FDCC3A; Mon, 20 Jan 2020 16:19:22 +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 13.0 \(3608.40.2.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAErg=HGE-AwviP-VurLJ58vsmkK4uqVCfoqRK4TkEdbSRegN_g@mail.gmail.com>
Date: Mon, 20 Jan 2020 11:19:21 -0500
Cc: Benjamin Kaduk <kaduk@mit.edu>, EMU WG <emu@ietf.org>, Joseph Salowey <joe@salowey.net>, Michael Richardson <mcr+ietf@sandelman.ca>, "Owen Friel (ofriel)" <ofriel@cisco.com>, "spasm@ietf.org" <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B648503-5B4D-4512-8692-94820388B894@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> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <CAErg=HH8LjqMR37Ek1uK12uCDj4N89Ot=Fm_PLOBdeXsv3sdpw@mail.gmail.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <CAErg=HF9SQCmP9hi8SP-EstyYL-qVLWMeitP2AHc3T6ZWZM4vQ@mail.gmail.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <CAErg=HE8WO1oU=ZUxMeJZpxVyM_6ypCn-3_9UqKkMv44c7Do=Q@mail.gmail.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <CAErg=HGf=3z+_S2f+_ciSunpi4W05aKxoxx=ozH9kXtooAJL9w@mail.gmail.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <CAErg=HFM4=V1YjD2Z7Rd5cNsDv6v9oTwKcbaTwhDdrQvOwtS9w@mail.gmail.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <CAErg=HF2L-XSQExoKz71QcZMqJdA-gn3KxnZwT1qypzBA9Hi3Q@mail.gmail.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <CAErg=HGE-AwviP-VurLJ58vsmkK4uqVCfoqRK4TkEdbSRegN_g@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/ehMjMOPR64Wr7Rnh1BX8UwoR3Cw>
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: Mon, 20 Jan 2020 16:19:46 -0000

On Jan 20, 2020, at 9:29 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> As I hoped my previous message conveyed, but it looks like it may not have been clear for you, I'm not dismissive that for supplicants distributed by the OS vendor, you (eventually) need to convince that OS vendor to distribute roots with their supplicants, and from the end-user perspective, a default install of that OS "just works". However, it's a very meaningful distinction in the context of root stores, even if it may not be for supplicant authors, to highlight the need to distribute roots _with the supplicant_, not the OS. This is not a corporate distinction, but it is meaningful to how solutions are engineered and the problem space, and that's why it does a great disservice to dismiss that distinction.

  We'll have to disagree here.  That distinction is entirely a technical detail which is irrelevant to the end user.  It doesn't matter to the standards bodies, either.

  The distinction doesn't even matter in the content of root stores.  The vendor downloads N root CAs, and places them into files / DBs in the product.  Whether those files from from A and go to B, or come from C and go to D is *entirely* irrelevant to the end product.  Whether it's Department A that downloads the roots CAs or Department B is also irrelevant.

  Whether we have to convince "the OS vendor", or just "the supplicant division in the OS vendor" is largely the same thing.

>   The same goes for root CAs.  While it's superficially true that someone can start "Billy Bobs Tackle Shop & CA", no one has any reason to *use* that CA.  Saying "you can start a CA" and by implication have people *use* it, is no more realistic than me saying "you write software, Bill Gates wrote software, there's nothing preventing you from being as rich as he is." 
> 
> This is again shifting the discussion. If you don't believe it is, then certainly, how you're communicating is not coming across clearly.

  It's not shifting the discussion.  It's directly addressing your point, as clearly as I can make it.

> As I've mentioned several times, anyone can issue certificates, which is all that matters for manual configuration. There's no need for anyone special or blessed - it's just manual configuration.

  The issue, as I've mentioned several times, is that's where we are today.  There's no need to bring up current behaviour as an option - we know it's an option.  We're trying to fix it.

> If you'd like to go to automatic configuration, then you need to define policies and practices for issuance and verification. Anyone who can comply with those can become a CA. The usefulness of "Billy Bob's Tackle Shop & CA" is dictated by those who need a CA - the supplicants - and how well Billy Bob complies with the policies and practices. You're absolutely correct that if you don't define those, then _no one_ can become a CA. There's no reason to believe that Billy Bob is more or less qualified than an extant CA unless and until you define those. And, of course, once you define those, the usefuless of Billy Bob - how likely his CA-slash-tackle-shop is to be included - is dictated by those defining the root store. That's where the SDOs come in to place. 

  Which is largely what I was saying.  So I think we're in agreement here.

  But again, this doesn't *help*.  I can't get my CA shipped with vendor products, and nothing you've said convinces me that it's possible.

> Then why are we wasting electrons discussing how to do it? If you believe it's a doomed effort from the start, why bother replying?

  I never said it was "doomed".  I was trying to suggest that there we need to have clear benefits, and a clear path to implementing the benefits.

> The nice thing about the transition plan I've outlined several times is you don't need the OS vendors to all adopt apriori for it to be useful. Other supplicant vendors can go ahead, define their policies and practices, select their CAs, and build their root store.

  And not a single person will download and use the new supplicant software.  Making it 100% useless.

  Any "supplicant division" of an OS vendor will require high-level signify before massively changing user workflow.  So in the end, it *is* the "OS vendor" who has to be convinced.

> I'm afraid you've considerably misunderstood the proposal then, as I've tried to express several times. I'm well aware the end goal is that on a 'stock' install of your OS of choice, everything just works. I've outlined several times a plan to get to that - and which does not involve shipping roots in the OS, but roots in the supplicant that comes with the OS. The distinction is quite meaningful for the reasons outlined throughout this thread, even if the end user experience is "it just works" 

   When I do RADIUS stuff, I say "the vendor has to do X".  It's never been useful to say "Bob in engineering department X has to do it".  The distinction you're making is 100% irrelevant.

  If this distinction is necessary and important, why has every other WG avoided doing it?

  i think we're at an impass.  We agree on the end goal, but disagree fundamentally on some major points.

  Alan DeKok.