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

Benjamin Kaduk <kaduk@mit.edu> Thu, 16 January 2020 04:07 UTC

Return-Path: <kaduk@mit.edu>
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 ABB2D120855; Wed, 15 Jan 2020 20:07:25 -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 EozK5G9qKxBZ; Wed, 15 Jan 2020 20:07:24 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A7012002F; Wed, 15 Jan 2020 20:07:23 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00G47GIU009898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 23:07:18 -0500
Date: Wed, 15 Jan 2020 20:07:15 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Joseph Salowey <joe@salowey.net>
Cc: Alan DeKok <aland@deployingradius.com>, "spasm@ietf.org" <spasm@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, EMU WG <emu@ietf.org>
Message-ID: <20200116040715.GC80030@kduck.mit.edu>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOgPGoDADPY125Bf7mbPCpEVkwVF=YmbG9wAN0S-WyCWg27BCw@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/gWnGA7kjXO2QO4Kd7AtxOM0Q9-g>
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: Thu, 16 Jan 2020 04:07:25 -0000

A couple things that stand out to me from having basically read the whole
thread in one go (this is not intended to be an exhaustive list of open
questions):

It was implied but not fully clear to me, that Ryan thinks that someone so
inclined could, right now, go around trying to connect to wifi using EAP
authentication, grab a packet capture of the remote server using its
id-kp-serverAuth certificate for authenticating the TLS-over-EAP
connection, and report that certificate to its issuing CA as "misuse"
requiring prompt revocation, at least for several major CAs.  It's quite
probably that I missed them as they went by, but specific links to specific
CA policy documents that would classify such certificate usage as "misuse"
(requiring revocation) would help clarify things, at least for me.

Is there anything better for implementations to actually do (as distinct
from what we write down as recommendations) than to start setting up a
parallel (purpose-specific) PKI now and trusting that in parallel with what
they're currently doing, with the hope of being able to have a flag day
many years down the line when the new PKI becomes the only thing that's
trusted?

-Ben

On Wed, Jan 15, 2020 at 07:20:37PM -0800, Joseph Salowey wrote:
> There has been a lot of discussion on this thread, but I do not see
> anything actionable for the EAP-TLS 1.3 specification.
> 
> Joe
> 
> On Wed, Jan 8, 2020 at 12:48 PM Alan DeKok <aland@deployingradius.com>
> wrote:
> 
> > On Jan 8, 2020, at 3:00 PM, Michael Richardson <mcr+ietf@sandelman.ca>
> > wrote:
> > >
> > >
> > > Alan DeKok <aland@deployingradius.com> wrote:
> > >    alan> Many people use private CAs.  Many use public CAs.  *All* of
> > them
> > >    alan> use id-kp-serverAuth.  Common EAP supplicants (MS / Apple /
> > etc.)
> > >    alan> ship with known root CAs.  These root CAs are trusted by default
> > >    alan> for web browsing.  None are trusted by default for EAP.
> > >
> > > How can anyone be using public CAs for EAP, if none are trusted for EAP,
> > and no
> > > public CAs issue certificates with id-kp-serverAuth?
> >
> >   Every CA is manually enabled.
> >
> >   Either by an end user, or by / on behalf of, an administrator.
> >
> >   The goal I'd like to reach is some method to allow supplicants to
> > automatically trust and enable certificates for EAP.
> >
> >   Alan DeKok.
> >
> > _______________________________________________
> > Emu mailing list
> > Emu@ietf.org
> > https://www.ietf.org/mailman/listinfo/emu
> >

> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm