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

Ryan Sleevi <ryan-ietf@sleevi.com> Sat, 18 January 2020 13:55 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 8A19C12001B; Sat, 18 Jan 2020 05:55:52 -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 fvh3FT4IrSqU; Sat, 18 Jan 2020 05:55:51 -0800 (PST)
Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (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 D39E1120013; Sat, 18 Jan 2020 05:55:50 -0800 (PST)
Received: by mail-ed1-f44.google.com with SMTP id r21so25057643edq.0; Sat, 18 Jan 2020 05:55:50 -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=6iZMViH8RsQBgsh/7mJ02/OgLNa/Ze+xqJDUTtVpG5o=; b=jpUcEDaUueuW3ubd39XPIpX5f4mTBAx6xUFBp3KEifrryQne7BDcXpOdl7BYUARlLl BxgzraT8VCvgOuw8AD1rM2XayBQZ3W4R7Mj180AzZBvAGRRdrhTPCIt6NsQgz2cilbDS /BHPpbp13EeAyIjJ9zfWBPDrGYrxmGkQ9exlE1VmgU+KrJAmInQeNJ6jlckLb4mneKki eDPVgRp3fQ9t6V5dvO1siP4be8uuMDz3tkfP00d+oDrKaGBry+XdNwoPfMvvfz6H6sx2 /GklWYYsKB/J9Xns+kryJENED1T43XQlrk14pVOEvVUDQ0yRv4lGCkek58JUsW938Z/B 1sXQ==
X-Gm-Message-State: APjAAAUs3g3aOESX1yHEg0+Q/4RK8fGc3//gTrD3PslE8OxLeGmFBCuc kmsVUXuRQvnWxm2ZlNGk/rmQqcpS
X-Google-Smtp-Source: APXvYqxaYyNWTSC3RZey9JMEY9hw4wmYkYjZf3hvAG9+nYwuhSd9xT3GTMFYkDr6S0uaZZaItNq6zg==
X-Received: by 2002:a05:6402:153:: with SMTP id s19mr8892359edu.149.1579355748997; Sat, 18 Jan 2020 05:55:48 -0800 (PST)
Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com. [209.85.128.44]) by smtp.gmail.com with ESMTPSA id n2sm862385ejd.86.2020.01.18.05.55.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jan 2020 05:55:47 -0800 (PST)
Received: by mail-wm1-f44.google.com with SMTP id u2so10315960wmc.3; Sat, 18 Jan 2020 05:55:47 -0800 (PST)
X-Received: by 2002:a1c:ddd7:: with SMTP id u206mr10247438wmg.159.1579355747165; Sat, 18 Jan 2020 05:55:47 -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>
In-Reply-To: <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Sat, 18 Jan 2020 08:55:32 -0500
X-Gmail-Original-Message-ID: <CAErg=HH8LjqMR37Ek1uK12uCDj4N89Ot=Fm_PLOBdeXsv3sdpw@mail.gmail.com>
Message-ID: <CAErg=HH8LjqMR37Ek1uK12uCDj4N89Ot=Fm_PLOBdeXsv3sdpw@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="00000000000048ad90059c6a6af7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/wvDgxvW2-IVZ7EtBULFqNmuf42k>
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:55:53 -0000

On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok <aland@deployingradius.com>
wrote:

>   As noted by Michael, CAs are using certificates in a way that violates
> their own policy.


Um, no. I largely didn’t respond to Michael’s email because it missed the
mark rather substantially, and I suspect folks still haven’t actually read
the CP/CPSes or done the work.

As I explain again, later on, this is fixating on a branch on a tree and
ignoring the forest in which it is in. I provided the example to illustrate
the broader problem, but apparently I picked too distracting an example.

>
>   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.


Right. These people are wrong and their reasons bas :)

For example, a certain CA, no longer in business, vociferously opposed the
deployment of Certificate Transparency and the forbidding of issuance to
non-qualified domain names (e.g. “mail” and “intranet” and the like). More
than half of their business selling their premium ($2000+/cert) EV
certificates was selling them to enterprises they had convinced required EV
certificates, and they were opposed to anything that would disrupt or
diminish that practice. Yet it’s obviously laughable to believe someone
validated unique control, via DNS on the public internet, of the name
“mail” - effectively a TLD.

I mention this anecdote because I’m quite familiar with corporate security
teams requiring things, “for reasons” (typically, an effective
sales/marketing team), but that doesn’t make it any more correct. This is
where supplicants and servers refusing such certificates is not
unreasonable as a means of signaling technically that which is
operationally true.

  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.


No. The root store operators make the rules. Standards that align with
their needs are the standards they use and apply.

Nothing you say or do has any impact without implementor, and if you go
against the grain of where implementors are going or already at, they are
useless standards that will be ignored.

It would similarly be a mistake to think “Ah, but I control an SMTP server,
I am thus an implementor and empowered”. You are indeed an implementor...
for your root store. And if existing contracts and requirements prevent a
CA from serving your needs from the same hierarchy they are serving other
root store needs, which they increasingly will, then again, there’s no real
power unless you define your own root store.

When a vendor, be it Apple or Microsoft or Mozilla or Google, says a CA in
their root store needs to do something, they need to do it. If you don’t
like that, which the email clearly demonstrates, there isn’t a heckler’s
veto via the IETF: you instead need to create your own root store to do the
things you want or like. Attempting to change those policies via the IETF,
without understanding why they exist, just leads to IETF standards being
ignored because they are not useful nor aligned with the needs of consumers.

Put differently: This is as explicitly an area of policy, not technology.
As tempting as it may seem to focus on individual problems and say “Ah, but
those could be addressed by technology and more standards,” without
appreciating the broader and big picture, which is inherently policy, the
work on the technology is doomed.

  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.


Yes, and the latter is more relevant than the former.

You’re seemingly fixated on the detail of the EKU, without acknowledging
that the EKU is merely a technical example of the broader point of how
requirements and policies work and flow, and how certificate consumers,
even when used over the same transport substrate (TLS), have substantially
different operational considerations. Those operational considerations
impact the design of the PKI and thus the selection of the roots, and why
multiple root stores, with their own policies and expectations, is the
natural end-point.

We don’t expect IETF to be the One Standards Org for everything, such a
railway gauge tolerances and fire resistant building material codes and
maximum reflectivity of space equipment. Those are both beyond our ken and
our focus. The same is true for PKI: there does not need to be one set of
Policy to Rule Them All, and it’s ok to have many policies, each written by
different constituents to reflect their needs.

The important thing, that I keep trying to emphasize, is that separate
policies are best technically accounted for at different roots. Yes, the
dream of PKI was one root per organization and a grand and global mesh
network of policy, and so we have all this technical complexity in specs
like RFC 5280 to accomplish that. But the technology does not work, in the
real world, and in fact makes it more difficult and risky, rather than
less. So just use separate PKIs, built to common profiles when
applicable/relevant, and move on. What happens in other PKIs shouldn’t
affect you or be relevant, much like ISO standardizing how food processing
equipment should be inspected is not really relevant here.