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

Alan DeKok <aland@deployingradius.com> Tue, 19 November 2019 12:18 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 62DEB120917 for <emu@ietfa.amsl.com>; Tue, 19 Nov 2019 04:18:05 -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 rPLsP8zl56Pj for <emu@ietfa.amsl.com>; Tue, 19 Nov 2019 04:18:03 -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 8162D120874 for <emu@ietf.org>; Tue, 19 Nov 2019 04:18:03 -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 5DC8EA8B; Tue, 19 Nov 2019 12:18:01 +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: <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org>
Date: Tue, 19 Nov 2019 07:17:59 -0500
Cc: emu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <822C82FA-4AF5-4BAF-8A19-40CE0E57B391@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> <c54e1c65-8600-9b36-5b97-7c1425a82fc3@lounge.org> <CB7B2197-7984-4EB0-95CB-1BDCD701E3DE@deployingradius.com> <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org>
To: Dan Harkins <dharkins@lounge.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/FtycRaKB9cgCuFwhRFey4ZY5tTw>
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: Tue, 19 Nov 2019 12:18:05 -0000

On Nov 18, 2019, at 7:39 PM, Dan Harkins <dharkins@lounge.org> wrote:
>>   What happens if the CA checks some things, and not others?
> 
>   Then it means the CA is certifying things it shouldn't.

  Well, that's what happens with most CA's.

>>   Define "validation" :)
> 
>   I'll pass on playing that game.

  We have a good "feel" for what validation means in casual conversation.  We're less clear what it means as a *process*.

  How does a CA validate a field?  The answer is too often "it validates the field", which seems a bit circular.

  My point is that validation isn't black and white.  There are various kinds of validation, each of which give you different kinds of information.  My goal is to understand what those are, and to find out how we can use that information.  Your position seems to be "it's either perfectly validated or perfectly useless".

>>   My point for SSIDs is that validation means whatever we define it to mean.  So long as everyone agrees that the SSID field is a hint and is not validated by the CA, it's OK to use it.
> 
>   Use it how? What value do you put in an attribute that hasn't been validated (and
> don't ask me what that word means since you used it)?

  RFC 4334 describes this in some detail.  See section 3 for discussion on SSIDs.

>>   In addition, CAs currently validate *control* of a domain.  But they don't (and can't) really validate *ownership* as such.  i.e. if I own a company, I can tell an employee to ask a CA for certificates for that domain.  He may be making that request, even if he doesn't "own" the domain.  He can convince the CA that he controls the domain.  I'm not sure how the CA would check that the owner of the domain has properly delegated the certificate request to the employee.
> 
>   Then what you can infer from a domain name in a certificate issued by such a CA
> is that the holder of the corresponding private key controls that domain. Nothing
> more, nothing less. But you can't infer anything from other attributes that have not
> been validated (again, using a word you used yourself)

  Certificates contain serial numbers.  They haven't been validated by a CA.  The lack of validation therefore means that you can't infer anything from that field?

  I would argue that you *can* make inferences from that field.

>>   The same applies for telephone numbers.  Do CAs call the numbers?  Do they check that the person answering is the same person who made the request?  Maybe.
> 
>   You tell me if a CA "calls the numbers". If it doesn't then what can you infer
> from a telephone number in a certificate it signs?

  This isn't difficult.  It means that the certificate owner has claimed he can be reached at that number.  And the CA has signed the statement, agreeing that it's a statement made by the certificate owner.

>>   These issues can't be answered with simple black & white statements.  If the data in a certificate is imperfect, it might still be useful.
> 
>   OK, convince me of its utility.

  See RFC 4334 and its discussion of SSIDs.

  Alan DeKok.