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

Ryan Sleevi <ryan-ietf@sleevi.com> Mon, 20 January 2020 18:09 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 D80B9120A63; Mon, 20 Jan 2020 10:09:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, 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 XGS9hKn8Vy95; Mon, 20 Jan 2020 10:09:02 -0800 (PST)
Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (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 E5507120871; Mon, 20 Jan 2020 10:09:01 -0800 (PST)
Received: by mail-ed1-f42.google.com with SMTP id l8so411957edw.1; Mon, 20 Jan 2020 10:09:01 -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=hrG8SgQ1PoyST2KiroqNbAG533N7Mt/eZf3E98SvqwY=; b=OMAsRwknikKUBx3K5o0APB08GqkcqUX5vzZL/NgLpf6jB1C01koPKTvdAZykpB5C+7 dhVuh6wHYVntWQTOTkpKBqJm9HEZok955F/oX7QkEihSkaEhtwiuYQrmpFFkNn3E26Si O7Y9V/073VCZqElUBkZhjOlMf3u3LxYdIc/MUZfsq45dtGY2+rRJ6/zbvAzik1sSGGkf M5nGfNLB8o6nJ9BFBbuthU1YlHC8k5JSU5JSMUI3UpYgFZAxv/SiMASp0O6OHdP515Oy LLMFN24B1KpDJ0R6lviYuOrZOJUS7R6S4WXg5Bs+rYJ3gQ/9c7bAAgi3NWtbNBAhvq8W nOjA==
X-Gm-Message-State: APjAAAWhQR79S3paRdErCuyXI07LCl2pg+9+bNTKy8nkWfth4kY7UwF0 4+N3GciLxLYIT4shK1vmSPF68HQb
X-Google-Smtp-Source: APXvYqzZ3MElT4LU6nhfU2wA6OKLP0aNF4fhWprK60ETrkRBfEGTYsLBDKYexNbs/mWz+TZbEt4Utg==
X-Received: by 2002:a05:6402:1b84:: with SMTP id cc4mr280731edb.383.1579543740062; Mon, 20 Jan 2020 10:09:00 -0800 (PST)
Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com. [209.85.128.54]) by smtp.gmail.com with ESMTPSA id v2sm1431955edx.92.2020.01.20.10.08.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jan 2020 10:08:59 -0800 (PST)
Received: by mail-wm1-f54.google.com with SMTP id p9so266142wmc.2; Mon, 20 Jan 2020 10:08:59 -0800 (PST)
X-Received: by 2002:a1c:9c4c:: with SMTP id f73mr100911wme.125.1579543739248; Mon, 20 Jan 2020 10:08:59 -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> <D6C98596-AA42-48DA-B6BC-74F6506B8ED7@comcast.net>
In-Reply-To: <D6C98596-AA42-48DA-B6BC-74F6506B8ED7@comcast.net>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Mon, 20 Jan 2020 13:08:47 -0500
X-Gmail-Original-Message-ID: <CAErg=HGCO43eFTY+HC++Va9s+3D+8WG88q3Vh5-NM9Tjv0xOwQ@mail.gmail.com>
Message-ID: <CAErg=HGCO43eFTY+HC++Va9s+3D+8WG88q3Vh5-NM9Tjv0xOwQ@mail.gmail.com>
To: "David B. Nelson" <d.b.nelson@comcast.net>
Cc: Alan DeKok <aland@deployingradius.com>, Benjamin Kaduk <kaduk@mit.edu>, EMU WG <emu@ietf.org>, Ryan Sleevi <ryan-ietf@sleevi.com>, "spasm@ietf.org" <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007c34e5059c962fcf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/L7y_ZI7-MigffW0PJ214Ald71hc>
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 18:09:06 -0000

On Mon, Jan 20, 2020 at 12:28 PM David B. Nelson <d.b.nelson@comcast.net>
wrote:

> On Jan 20, 2020, at 11:51 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>
>
>   Whether we have to convince "the OS vendor", or just "the supplicant
>> division in the OS vendor" is largely the same thing.
>
>
> It isn’t, and there’s been zero evidence to support that conclusion, but I
> can tell reality isn’t that convincing :)
>
>
> I have to disagree with that.  There are exceptions to very rule, of
> course, but I have never downloaded, installed and configured a supplicant
> on any of my computing devices.  I’m a highly technical end-user (long time
> IETF and IEEE contributor).
>

How is this related? This isn’t about downloading third-party supplicant
software, this is about scoping the problem and the solution. Shipping as
part of the OS, as a root store, is several magnitudes more work than
shipping as part of a supplicant that is part of that OS, and which itself
is exponentionally more work - and risk, both technical and legal - to
requiring manual configuration.

In the context of the original post, it’s about using a hammer as a
screwdriver, when we all seemingly agree a screwdriver is the right tool.

This is not about which department is involved. The distinction is about
> the scope of trust. Saying shipped in the OS, both in the context of this
> thread and more generally, is presuming a broad scope and maintained
> interfaces for third-parties, neither of which you need. Not recognizing
> that a “root store” on a modern OS is merely an abstraction over disparate
> trust bits is meaningful, particularly when not addressing what the “trust
> bits” should be or how they’re maintained.
>
>
> And *that* is an artifact of the way vendors have chosen to ship their OS
> products.  I think what you’re saying is that large industry software
> providers aren’t going to change their behavior just because it
> inconveniences users (customers).
>

You’re right that organizations are not going to take on more technical
complexity, more security risk across their products, and more legal risk
to the organization, “just” because some folks are inconvenienced.
Especially when that fraction of inconvenienced folk represent a remarkable
minority of their user base. That’s why advocates _have_ to demonstrate
value AND demonstrate solutions that understands those complexities and
risks and mitigates them appropriately. Ignoring those needs is bound to
get half-assed solutions that get ignored.

Maybe that’s true.  However, it’s an organizational and implementation
> argument, not a technical one.
>

This isn’t correct either. The point - going back to the very original
reply - is that the primary means of mitigating those risks and
complexities is of a technical nature. It’s absolutely true that legal
risks, for example, are not easily expressed as technical solutions, but
this design and selection of root stores, and the risks involved, very much
depends on technical decisions that are made. If folks want to ignore those
concerns, it’s at their peril, but different technical decisions amplify or
mitigate those concerns. Hence, again, back to profiles and their
corresponding policies.

Sure.  Standards are voluntary.  All *good* standards start with clear and
> accurate Use Cases and User Stories.  The ”users” have to include
> end-users, not just developers. Technical standards are successful when
> they solve end-user, market driven problems.  Standards that seek
> (primarily or secondarily) to preserve “the way we’ve always done it” among
> the vendor base, are not very useful, IMHO.
>
>
Sure, but standards that exist to ignore the problems of constituents, and
then lament no one adopts them, are not very useful. There isn’t
disagreement on the benefit to users, but there’s clearly not an
understanding how the entire discussion of PKI is a risk-shifting design,
and has been since its very inception as a framework outside of the scope
of X.500 DIT authorization.

Standards that shift all risk onto the vendor are almost certainly doomed,
even if it’s incredibly convenient for end-users to have someone else bear
the burden. That’s why it’s essential for _good_ and _useful_ standards to
understand how the technical decisions affect the implementation risks and
costs, so that they actually have a shot at adoption. If the rationale
behind a standard is to write checks that get debited out of someone else’s
account, then it needs to be clearly documented for all stakeholders to see.

I’d like to avoid that scenario, which is why I keep trying to emphasize
designs that have a chance at achieving the end-goal, are incrementally
deployable, and which can demonstrate real value to vendors. Trying to make
it one size fits all, and with existing solutions, is simply doomed, if
only because the market has realized the substantial and non-trivial hidden
costs of that. Centralizing configuration, which the whole idea of a root
store is about, centralizes risk, and it’s essential that the risk be both
managed and not bleed into unrelated areas if you want to convince vendors
to take on that risk.