IETF Logo Mail Archive

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

Alan DeKok <aland@deployingradius.com> Thu, 16 January 2020 20:56 UTC

Return-Path: <aland@deployingradius.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 80FCF12008D; Thu, 16 Jan 2020 12:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 HwkQQlnRsazY; Thu, 16 Jan 2020 12:56:42 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853CC120026; Thu, 16 Jan 2020 12:56:42 -0800 (PST)
Received: from [192.168.20.221] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id 58107D8D; Thu, 16 Jan 2020 20:56:39 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <20200116040715.GC80030@kduck.mit.edu>
Date: Thu, 16 Jan 2020 15:56:37 -0500
Cc: Joseph Salowey <joe@salowey.net>, "spasm@ietf.org" <spasm@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <07F783A9-96C0-4E75-91AB-898F9EDF028D@deployingradius.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>
To: Benjamin Kaduk <kaduk@MIT.EDU>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/yow1chT2nK9i8JrvBWdEcI2qznA>
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 20:56:45 -0000

On Jan 15, 2020, at 11:07 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> 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?

  I don't think so.

  It's common practice to use private CAs.  Usually, self-signed ones.

  One major driver for private CAs was initially that EAP supplicant implementations did not cache the server certificate.  So if the supplicant trusted a root CA, it trusted *all* certificates issued by that root CA.  Which was a major security issue.

  Supplicants now cache the server certificate, even if they trust the root CA.  This lets them warn the user if the server certificate changes.

  But this process also means that the user is warned on normal certificate expiration / replacement.  There is currently no guidance to implementations as to what should be done here.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email