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

Ryan Sleevi <ryan-ietf@sleevi.com> Mon, 20 January 2020 21:03 UTC

Return-Path: <ryan.sleevi@gmail.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 C3FDC12022C; Mon, 20 Jan 2020 13:03:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 fFc6dFZk0LhP; Mon, 20 Jan 2020 13:03:52 -0800 (PST)
Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1265312013D; Mon, 20 Jan 2020 13:03:52 -0800 (PST)
Received: by mail-ed1-f47.google.com with SMTP id v28so787535edw.12; Mon, 20 Jan 2020 13:03:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=exFs/hxCNhwJTN+nFE60DnmyJFs+mZXSWea051+e2gA=; b=I+KurPEbmWBE8P+Iq2DOZsgC09HPEgmjfz2Qt/YFMI7vsgmq7V1CfOPLDtSJwQdF4E qmmuObvx1s7PH/CzyVKIS613OQraFh2KhDXQxWTygHyaW2P8HU8utmbcXDjA1NMP4LTV dmwa9bq65XhobolkxKTWZ/bdu3HuQgF4DLtJsrLXGqqlHXF1sOvtFiHcEms8VQs+dBb7 uRLmP4Tky/NwiQeVI7PeiYHCuqsa7V8NbxYeXI0+PsLF37ntDxyHaYzYjtGKWWVAS4OA CsGQRUY0Rdw/iniFzvCJ6f4daJDNZS1N0QYTCBrZxozfAKhb0+98qESLBFP+Nju/cPPC /jLw==
X-Gm-Message-State: APjAAAWKeVftkm9QGnsy+tNdiG84m9TB9tRWnTMHDvUZYyU+Pid+USlQ 6OND5GU5CTkACdkOtu/pruf7ptEy
X-Google-Smtp-Source: APXvYqz3rQAyIwI5JdI8Wptrfz/u5KVsE7mLKInfcGoSZMaRwuT849lxJW6oWQgjM0duhcpLmAWXKw==
X-Received: by 2002:a50:f982:: with SMTP id q2mr963986edn.55.1579554230254; Mon, 20 Jan 2020 13:03:50 -0800 (PST)
Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com. [209.85.128.53]) by smtp.gmail.com with ESMTPSA id j3sm1370597edb.50.2020.01.20.13.03.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jan 2020 13:03:50 -0800 (PST)
Received: by mail-wm1-f53.google.com with SMTP id p17so793996wma.1; Mon, 20 Jan 2020 13:03:49 -0800 (PST)
X-Received: by 2002:a1c:9c4c:: with SMTP id f73mr639445wme.125.1579554229631; Mon, 20 Jan 2020 13:03:49 -0800 (PST)
MIME-Version: 1.0
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> <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> <CAErg=HFkQQpxprFNRKzn9Jhh=Em8UTLjBe7Em08fppyxROO=kg@mail.gmail.com> <5D696B14-1C74-4073-8785-3515FFAEC2BA@deployingradius.com>
In-Reply-To: <5D696B14-1C74-4073-8785-3515FFAEC2BA@deployingradius.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Mon, 20 Jan 2020 15:58:13 -0500
X-Gmail-Original-Message-ID: <CAErg=HGN7Ek6Yme-7fiNCQGzF9qvWX5r-hyO7kreEprK47RPKQ@mail.gmail.com>
Message-ID: <CAErg=HGN7Ek6Yme-7fiNCQGzF9qvWX5r-hyO7kreEprK47RPKQ@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
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>, Ryan Sleevi <ryan-ietf@sleevi.com>, "spasm@ietf.org" <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c2c0ef059c98a0bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/YaG2Gt68EUvvt9HLDDIMYxzWMpw>
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 21:03:57 -0000

On Mon, Jan 20, 2020 at 3:31 PM Alan DeKok <aland@deployingradius.com>
wrote:

> > Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? You
> have paths forward.
>
>   Cisco: yes.  Jouni: No.
>
>   wpa_supplicant / hostap is just a collection of source code in a git
> tree.  It includes no CAs.  And if it did, people would ignore them.  Any
> open source author has minimal influence on how their end product is used.
> I know this from 20+ years of experience.


I’m afraid this is quite disconnected from reality, then. The premiere root
store on more devices than any other is the Mozilla Root Store, developed
as part of the open-source NSS package, shipped in virtually every
mainstream Linux/BSD distro, and used in wide swaths beside that (e.g.
curl, server programming languages, IoT, cars, thermostats)

The decisions made by Mozilla - to add or remove CAs for given purposes,
like TLS or S/MIME - reverberate on a host of ecosystems, for better and
for worse. The reason for that adoption is on the strength of the profiles
and policies, and addressing a real need, which are the things not being
addressed here for EAP.

There’s nothing that prevents a “Like-Mozilla-but-for-EAP” root store being
developed. Like all root stores, it requires defining your profiles for how
the information is expressed, the practices for how clients validate and
use that information, and the policies for how CAs appropriately vet and
validate that information. The first two - profiles and practices - are
excellent candidates for standardization efforts. The latter, policies, is
as the name suggests, more about policy and left to industry efforts. The
technical decisions in the profiles and practices affect the policies -
some decisions create more work, some less, such as the discussions around
EKUs.

The choice to implement, as an OS/supplicant vendor, is about evaluating
the risk of the policies. How much do the technical decisions expose users
to risk vs mitigate risks of misconfiguration? How can those policies be
customized or adjusted to the needs of the vendor, and what
interoperability risks exist when they are so customized? If you’re talking
PKI, it’s inherently risk management, which is managing the policies to
support the technologies.

We generally don’t hear, for example, the SSH community remarking on a lack
of an out-of-the-box PKI that just works for all their hosts. That’s
because the policies, and the needs of constituents, aren’t really aligned
with that sort of global model. Local PKIs - whether TOFU or local SSH PKIs
- better balance the risk. Today, that calculus is largely true for EAP, at
least from the POV of supplicant implementors. If you want to convince
otherwise, it’s about defining those profiles and policies that can show
that different calculus.

  That is absolutely not the conclusion you can draw from what I said.
> When I say "the customer sees one end product, and therefore I don't care
> which group does the update", I do NOT mean "every individual department
> which works on the OS has to be updated in order to get this new EAP
> functionality".


This is not what I said either.

The notion of “add to the OS root store” has impact on every OS component,
which needs to be evaluated holistically. The decision _impacts_ them, from
a risk management standpoint, even when it doesn’t need to and shouldn’t.
That’s everyone having to move their car, or asking for $10 million.

You don’t need impact on every OS component. You only care about EAP,
clearly. Thats why it’s important to be precise on what is needed -
something _just_ for EAP. That’s only needing Bob to move his car, or
asking for $10.

So when talking about what this hypothetical root store should be, it needs
to be clear that it’s only for EAP, and saying “added to the OS” is far
more than EAP, with far more impact than needed or intended. It leads to
confusion, such as in the original message, around concepts like “public
CAs”, which only hurts the conversation. Plenty of folks have been
confused, for example, ingesting the Mozilla source files without realizing
it is three separate root stores, each with their own policies, management,
and constraints, some of which are not expressed purely in a single file.
That this happens often, or messages like Owen highlight “public CAs”
without qualification, are the same reason it’s important to be clear we’re
talking about a _new_ root store for a _new_ purpose, and thus nothing
extant has any bearing whatsoever on this store.