IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 17 January 2020 22:30 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 B2FAD12008D; Fri, 17 Jan 2020 14:30:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 A2SsNVH0V9EJ; Fri, 17 Jan 2020 14:30:32 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E0712006B; Fri, 17 Jan 2020 14:30:31 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2D47F3897D; Fri, 17 Jan 2020 17:30:02 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A096C5D4; Fri, 17 Jan 2020 17:30:30 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "spasm@ietf.org" <spasm@ietf.org>, EMU WG <emu@ietf.org>
In-Reply-To: <CAErg=HHwLOw9sL2=nGca5MuuyiV2Zghrp6prR7SqLJAvfCLmjA@mail.gmail.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>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 17 Jan 2020 17:30:30 -0500
Message-ID: <28625.1579300230@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/-Hd6yywdB-kQIU-Sih3kV_rOTXA>
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: Fri, 17 Jan 2020 22:30:37 -0000

Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
    > While I think people are missing the forest for the tree, here's an
    > example CP/CPS from a CA:
    > https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf

certsign.ro uses a Fortinet.com certificate on their SMTP server.
Does Fortinet.com's CSP permit SMTP usage?
The certificate does not have the serverAuth bit set.

    > Customer will only use a TLS/SSL Certificate on the servers
    > accessible at the domain names listed in the issued Certificate

    > Remind me how an EAP-TLS/RADIUS server is accessible at that domain
    > name? And if someone points their domain name to my server, would that
    > require revocation?

"accessible" is not defined.  maybe CAFORUM needs to write port 443 from now on?
If you were part of eduroam, and you uses ryan-ietf@sleevi.com as your
identity, then the roaming mechanism would connect eventually to your Radius
server using that name.  Thus, it is accessible.

Your gear analogy is understood, but for many of us, we see the specs as
having been designed by lawyers rather than engineers in order to maximize
profit and minimize interoperability.  I'm not arguing we are right.
It just feels like needless and wastefully restrictive attempts to create market verticals.

    > In the specific context of thinking about "#2" - what a touch-free
    > future looks like - having it use the same root store as Web browsers
    > is the anti-pattern, because the requirements are different.

And yet, almost every single thing out there would like to be connected to by a browser.
They can't, so we have an app-per-thing, and/or no-security.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email