Re: [Emu] EAP-TLS 1.3 Section 2.2 text

Heikki Vatiainen <hvn@radiatorsoftware.com> Tue, 25 May 2021 14:46 UTC

Return-Path: <hvn@radiatorsoftware.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 214CE3A0DC1 for <emu@ietfa.amsl.com>; Tue, 25 May 2021 07:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=radiatorsoftware-com.20150623.gappssmtp.com
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 TftS0rUKlUvM for <emu@ietfa.amsl.com>; Tue, 25 May 2021 07:46:01 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42C43A0DD3 for <emu@ietf.org>; Tue, 25 May 2021 07:46:00 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id u133so16892406wmg.1 for <emu@ietf.org>; Tue, 25 May 2021 07:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radiatorsoftware-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oiG7WkVyIiCGd32em9/kL1UZOqEzK84Js3Kjn1HN6C8=; b=s/+s2ig8uzaF6UM8qNxKSgHSNUf5dg+dWvAqNMukdwyaQ4vxAenEjrrBSNOFl6KhGm +YklJxs5U9Wdt1HWai5cPw8yqLfanNgBXgtqvWW6IXgwUBwCAVdEItHkLBsGwQ+NDBk3 qIbQhXVR38X3dZLyBZjmXvOIgByeawM2T1rrPUpAcKRflP4PtZDLKza3y0mCUK0wpvyt 0uMF44UhoD+vcufwIsYDewIVFB8ezklS6QodyLl8poJZNQXc4PELMyPyy9rQB38Pm4N2 avB2yowJfd/xgioMeUYwQzcQV6CovMdCXopBg5mk7jP4LjorqGxWptDq5yZ0sumyWExz rbjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oiG7WkVyIiCGd32em9/kL1UZOqEzK84Js3Kjn1HN6C8=; b=hML/DobCgggsRIRuXRreYQrcfKZ+Edq3xz6fAdWzeuf1B8nipXUgBssAqk1iBqQCM8 H2DOuDz8ivo42WacIwbrwVRv2hZXrz3OmHytTEy9WgaklGkAGKCEcAJY6EJgCRMRoeEN UHTo5DSWW/67SR2Wnk1uZc+UcGBsawz4WpLXncwlT3c3p/CCfzIS0VpgTY0DRZ2f32h1 l/d5CvmVs982p6TRjwx0tf6ocA635IFXbRW1TfV1ivlxgGG0eYcZkuc3fW3hzxMQWhGc S2c1yznjEvVzdYs+KXmyZ8vHFFTFbhw1jJvnzD0FPuN671xKNVfk66pkWzl7Xe+RNQd0 9Yjw==
X-Gm-Message-State: AOAM5333ngIW1W3OnKSlJWVewY+3fE+nKJEyvC4X6IrlMySOt5Lou5vX 6dAD8TDvapn73zEjnuTUZ1H2GzwFiWyebqJUnFdhcg==
X-Google-Smtp-Source: ABdhPJy/k/Ec9AVGVTvPkobQFh2W5xWnQYiqJmbvkjb+FtDV+EOpJYwP2heB9tj/nH3oxT9n5FOV5cMIK+x+jKtKLNc=
X-Received: by 2002:a1c:7909:: with SMTP id l9mr4357459wme.129.1621953953943; Tue, 25 May 2021 07:45:53 -0700 (PDT)
MIME-Version: 1.0
References: <CAOgPGoBDcbDxGB3_Qy_xXymhnxrfMaOPNP545eMh8XLvU6OX+A@mail.gmail.com> <92D9824F-82C2-440F-807F-7B4799DCF1B6@deployingradius.com> <CAOgPGoAd3CcaqPYd0aYXBDtCmv32T8hpGH+6ysEn7Pi9M+FSiw@mail.gmail.com> <4698EFD4-83B5-4B77-93E8-0E12FE8BC2DD@vigilsec.com> <CABXxEz-Jzfd4_8=bx8DquchkQVj8Hf07m0U8tYWO9-rFtBjqBw@mail.gmail.com> <CABXxEz9th6-JOgHKqEC5W7XQoi3NKUN3_8F3O_14k6nAdwmgRQ@mail.gmail.com> <F6B720FD-CF54-4953-A598-C6713CC10042@deployingradius.com> <CAOgPGoD4hGS4FBaVV4oopEy+0YOeLzUuYD=hGcTrHXcqSQo9AA@mail.gmail.com> <CAOgPGoCVodHuiQAF1Uz6NqNXy_5kjLccrj9=1VYS8yrmoEwytA@mail.gmail.com>
In-Reply-To: <CAOgPGoCVodHuiQAF1Uz6NqNXy_5kjLccrj9=1VYS8yrmoEwytA@mail.gmail.com>
From: Heikki Vatiainen <hvn@radiatorsoftware.com>
Date: Tue, 25 May 2021 17:45:37 +0300
Message-ID: <CAA7Lko_ZuCrNyvc0nKzLZQ25UKWpxW8YYcDXFihchawNT=2ALw@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Cc: EMU WG <emu@ietf.org>, stpeter@mozilla.com
Content-Type: multipart/alternative; boundary="000000000000446a6505c328951c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/O-DK2-FI8FKn6ZYdj0RT-oKT-2k>
Subject: Re: [Emu] EAP-TLS 1.3 Section 2.2 text
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, 25 May 2021 14:46:07 -0000

On Tue, 25 May 2021 at 07:45, Joseph Salowey <joe@salowey.net> wrote:

> I made some changes to the pull request to address some of the comments
> and make the text clearer:
>

One note about the TOFU mechanism: What we've seen is that certificate
renewal also triggers server certificate re-trust query/prompt/other
action. That is, even if the issuing CA, public key and subject/SAN names
remain the same, the certificate is deemed as changed by the EAP peer. In
other words, if only validity dates have changed in the certified
information, users a prompted again.

Should TOFU defined more closely in a future document, it could be
beneficial to give guidance which changes are accepted without validation.
One option is to not allow any changes, but allowing some renewals to be
accepted transparently could be useful. This is espcially seen with public
root CAs where certificate validity periods are getting shorter.

I'm not suggesting changes to the text below. The above is just a
consideration for any possible future documents that relate to TOFU.


>    The process of configuring a root CA certificate and a server name is
>    non-trivial and therefore automated methods of provisioning are
>    RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
>    a Configuration Assistant Tool (CAT) to automate the configuration
>    process.  In the absence of a trusted root CA certificate (user
>    configured or system-wide), EAP peers MAY implement a trust on first
>    use (TOFU) mechanism where the peer trusts and stores the server
>    certificate during the first connection attempt.  The EAP peer
>    ensures that the server presents the same stored certificate on
>    subsequent interactions.  Use of a TOFU mechanism does not allow for
>    the server certificate to change without out-of-band validation of
>    the certificate and is therefore not suitable for many deployments
>    including ones where multiple EAP servers are deployed for high
>    availability.
>
>
-- 
Heikki Vatiainen
hvn@radiatorsoftware.com