Re: [Emu] Issue 47 Certificate identity checks

Alan DeKok <aland@deployingradius.com> Mon, 12 April 2021 17:54 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 780E73A0FC4 for <emu@ietfa.amsl.com>; Mon, 12 Apr 2021 10:54:23 -0700 (PDT)
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 BUIzHMqepV0B for <emu@ietfa.amsl.com>; Mon, 12 Apr 2021 10:54:19 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175613A0FC2 for <emu@ietf.org>; Mon, 12 Apr 2021 10:54:18 -0700 (PDT)
Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id B3BA191; Mon, 12 Apr 2021 17:54:16 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAOgPGoBm7pas9i6n-y8g1yqP+ea68=_8DueHqywDQLBcMGEJ9g@mail.gmail.com>
Date: Mon, 12 Apr 2021 13:54:15 -0400
Cc: EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DE1DAF6-FA19-4F57-AF5C-BA6A39869B0C@deployingradius.com>
References: <CAOgPGoArm2RdEN4V-L9XEUvOeG0Vs+58Zj_p3Y2yRY0aYsVV_A@mail.gmail.com> <950CF2A7-2C9A-4BAE-8EA2-0FC2DE3C740C@deployingradius.com> <CAOgPGoBm7pas9i6n-y8g1yqP+ea68=_8DueHqywDQLBcMGEJ9g@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/yRPDAjcJAdhHqt_2i8dRIIPLe1k>
Subject: Re: [Emu] Issue 47 Certificate identity checks
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: Mon, 12 Apr 2021 17:54:23 -0000

On Apr 12, 2021, at 12:22 PM, Joseph Salowey <joe@salowey.net> wrote:
> [Joe]  without some sort of name matching using certs from a public CA is unwise.  

  The only other alternative is to "pin" the server cert.  Many systems support this.  Perhaps mentioning Time of First Use (TOFU) would help here.

  i.e. if the peer pins both the CA and the server cert, then the contents of the server cert matter less.  All that matters is that the peer detects if/when the server cert changes.

  If we rely on names, then which one?  There are many fields in a certificate which could be used.

>   After looking into this in some depth, the only real thing you can depend on is the CA.  If the CA is trusted, nothing else matters.  If the CA is not trusted, then nothing else matters.
> 
> [Joe] In this case we would have to rule out CAs that are not under the organizations control (public CAs)

  Only if the peer doesn't notice if the server cert changes.

  I think it's safe to recommend that clients pin both the server cert and the CA cert.  Anything else is "there be dragons".

  Alan DeKok.