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

Alan DeKok <aland@deployingradius.com> Wed, 13 November 2019 00: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 982EC1200E3 for <emu@ietfa.amsl.com>; Tue, 12 Nov 2019 16:59:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3pVlGS6q9T6s for <emu@ietfa.amsl.com>; Tue, 12 Nov 2019 16:59:47 -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 09BF11200C1 for <emu@ietf.org>; Tue, 12 Nov 2019 16:59:46 -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 37B56370; Wed, 13 Nov 2019 00:59:44 +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: <98294862-6601-4479-9690-ad04f62f2d8d@hpe.com>
Date: Tue, 12 Nov 2019 19:59:42 -0500
Cc: Russ Housley <housley@vigilsec.com>, "emu@ietf.org" <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B7835F2-C713-464C-AA98-3CE02041EF59@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> <AT5PR8401MB05309002D11E8AEF1018D250DB770@AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> <98294862-6601-4479-9690-ad04f62f2d8d@hpe.com>
To: "Cappalli, Tim (Aruba)" <timc@hpe.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/eb5dQJoC1yRQXOgP3sqMwSQCW6k>
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: Wed, 13 Nov 2019 00:59:50 -0000

On Nov 12, 2019, at 6:59 PM, Cappalli, Tim (Aruba) <timc@hpe.com> wrote:
> 
> Regardless of validation levels, it is not possible to own an ESSID. It is possible, however, to own a domain, email address, physical address, etc. That's the difference. 

  I think that's largely begging the question.

  Your comment seems to be that it's OK for a certificate to include incorrect a physical address, because that address is "owned" by someone.  Even if the owner of that address knows nothing about the certificate request.

  I don't see how that's useful.

  Which is why I asked about validation.  If the CA doesn't validate addresses, why should it validate SSIDs?   Even worse, the CAs verify *control* of domain names.  They don't verify *ownership* of the domain name.  They're not quite the same thing.

  Is the person requesting the certificate the "owner" of the domain name?  If not, is the certificate request authorized by the owner?  None of this is checked by CAs right now.

> Putting an ESSID in a certificate is a slippery slope. I doubt any public CA or OS vendor would ever entertain this.

  Both are well known to do "surprising" things with certificates.  I'm not sure why they would care about additional fields in a certificate.

  My point is that we have loose rules around the subjects of "ownership" and "validation".  Simplistic statements are easy to make, but aren't particularly helpful.

  In my view, if something is useful, practical and can be shown to be not harmful, then I think it can be used.  Putting SSIDs into a certificate seems useful, and (at least) the PKIX WG seemed to have agreed.

  Further,  RFC 4334 in fact contains no text about "ownership" of the SSID.  i.e. inclusion of an SSID in a certificate is *not* a statement about "ownership" of that SSID.  So your comments seem to be against an issue that doesn't exist.

  Alan DeKok.