Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

Alan DeKok <aland@deployingradius.com> Thu, 14 November 2019 11:59 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 C6D6512011E for <emu@ietfa.amsl.com>; Thu, 14 Nov 2019 03:59:54 -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 xiu7WB3wD6VE for <emu@ietfa.amsl.com>; Thu, 14 Nov 2019 03:59:52 -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 153A412011B for <emu@ietf.org>; Thu, 14 Nov 2019 03:59:51 -0800 (PST)
Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 8406219AD; Thu, 14 Nov 2019 11:59:49 +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 12.4 \(3445.104.11\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <240b3611-706c-303f-82aa-3fc3d78b7aa3@sandelman.ca>
Date: Thu, 14 Nov 2019 06:59:48 -0500
Cc: emu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AD503C8-EE44-4EEC-B87E-8BBC11EB031A@deployingradius.com>
References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <D735A4DB-1CFB-4DF4-ACB7-BC6EFDBC6CDE@deployingradius.com> <E0B8DAA7-8C7C-455F-B5BE-128670A093D3@vigilsec.com> <BD30A64D-539C-422D-9413-880AF8D6A16F@deployingradius.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <MN2PR11MB3901077F38165EE241D30BC5DB740@MN2PR11MB3901.namprd11.prod.outlook.com> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <F45360DB-D474-4600-BEFD-3C844FA4CB0A@deployingradius.com> <240b3611-706c-303f-82aa-3fc3d78b7aa3@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/ycV9iwV0NbmP5Z0M9BbxEnjSV2w>
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
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, 14 Nov 2019 11:59:55 -0000

On Nov 13, 2019, at 6:23 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> I think that the issue isn't, can we find or define a OID that has the
> right semantics.
> I think that the issue whether or not any public CAs are willing to
> include that into a certificate.

  That's less relevant than it may be.

  The common practice for years has been to recommend self-signed or "internal" CAs.  The original reason was that supplicants didn't do certificate pinning.  So if they were configured to trust a root CA, they would send user credentials to *any* EAP authentication server which had a certificate signed by that CA.  With certificate pinning, they now warn if the server certificate changes.

  The other reason is that supplicant configuration is still largely a manual process.  If admins need a complex process to configure the supplicant, then adding a self-signed CA to the mix has near-zero cost.  And supplicant vendors seem entirely disinterested in a standard way to configure them.

  The other benefit of self-signed CAs is that they're free.  No verification is required.  Since the admin controls both the CA and the end user machine, he's free to do whatever he wants, when he wants.

  As to why self-signed CAs are appealing, here's an example.   I've had "interesting" times trying to renew a simple certificate for HTTPS usage.  The CA was happy to take my money and "verify" ownership of a domain.  But they were entirely uninterested in sending me an actual certificate.  Their support system was similarly unhelpful.  In the end, I went with a simpler approach.  And I can't be the only person that this happened too.

  The gating issue for me is supplicants.  It's easy to update Open Source supplicants to check new OIDs.  The larger vendors might upgrade.  Eventually.  Maybe.

  On a technical front, a major issue is also *how* to upgrade.  What do supplicants do?  Allow both OIDs?  When do they start rejecting certificates with the "TLS web server" OIDs?

  Alan DeKok.