Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

tom.rixom@securew2.com Thu, 08 July 2021 06:52 UTC

Return-Path: <tom.rixom@securew2.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 5E1BE3A003B for <emu@ietfa.amsl.com>; Wed, 7 Jul 2021 23:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 0Hf6foFFVyFD for <emu@ietfa.amsl.com>; Wed, 7 Jul 2021 23:52:46 -0700 (PDT)
Received: from mail.securew2.com (mail.securew2.com [54.217.203.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2813A0035 for <emu@ietf.org>; Wed, 7 Jul 2021 23:52:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.securew2.com (Postfix) with ESMTP id 65BBE811CD for <emu@ietf.org>; Thu, 8 Jul 2021 06:52:44 +0000 (UTC)
Received: from mail.securew2.com ([127.0.0.1]) by localhost (ip-10-197-82-174.eu-west-1.compute.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU-k3l0dpvRx for <emu@ietf.org>; Thu, 8 Jul 2021 06:52:43 +0000 (UTC)
Received: from DESKTOP6S6T9RM (83-86-75-32.cable.dynamic.v4.ziggo.nl [83.86.75.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.securew2.com (Postfix) with ESMTPSA id 5E6A180128 for <emu@ietf.org>; Thu, 8 Jul 2021 06:52:43 +0000 (UTC)
From: <tom.rixom@securew2.com>
To: "'EMU WG'" <emu@ietf.org>
References: <CAOgPGoDX9HdmgvmnWz_xUTqXMM7pd4_T9W3opFR77ce8CNWdQQ@mail.gmail.com> <CABXxEz9GSgGof6t_3w3AngH6-FrMbKzDGKpDS90-N2gtmgqgnA@mail.gmail.com> <CAOgPGoBLb-70jynH7o26nyF4T=+ZcCk6GMb6zyXk6E8+erTjqQ@mail.gmail.com> <CAOgPGoADC_z4v2pUOAXC+HW1-P_OOuLOL5zR9tBjTCXXV7-22A@mail.gmail.com> <2c67a3b5-de25-cd3e-5b7c-e01e11a05ab1@ericsson.com>
In-Reply-To: <2c67a3b5-de25-cd3e-5b7c-e01e11a05ab1@ericsson.com>
Date: Thu, 8 Jul 2021 08:52:42 +0200
Message-ID: <085b01d773c5$d9d167d0$8d743770$@securew2.com>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGFCY+rSMHBcKAYowSOmy9XlZITQgEKcQauAmnqVz0B3LVf4gFMSN43q6iMFFA=
Content-Language: en-us
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0854_01D773D6.9CEDBA60"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/L7fvy4TMK4ec9A3B7iAVjXdPeck>
X-Mailman-Approved-At: Thu, 08 Jul 2021 00:19:04 -0700
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)
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, 08 Jul 2021 07:04:34 -0000

>1) "Since EAP-TLS deployments may use more than one EAP

   server, each with a different certificate, EAP peer implementations
   SHOULD allow for the configuration of a unique trusted root (CA
   certificate) to authenticate the server certificate and one or more
   server names to match against the SubjectAltName (SAN) extension in
   the server certificate.  To simplify name matching, an EAP-TLS
   deployment can assign a name to represent an authorized EAP server
   and EAP Server certificates can include this name in the list of SANs
   for each certificate that represents an EAP-TLS server." 

Hi,


I am not sure if I am allowed to respond on this but is the spec now restricting it to 1 “unique trusted root root (CA certificate)”?

Maybe this has been discussed already, but we often see the need for multiple root cas when people are migrating the root CA of their RADIUS server. They would then configure both the old and new Root CA in the client to allow seamless transition. 

Thanks,

Tom
SecureW2

 

From: Emu <emu-bounces@ietf.org> On Behalf Of Mohit Sethi M
Sent: Thursday, July 8, 2021 7:31 AM
To: Joseph Salowey <joe@salowey.net>et>; Oleg Pekar <oleg.pekar.2017@gmail.com>
Cc: EMU WG <emu@ietf.org>
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

 

Hi Oleg, Joe, all,

On 7/8/21 8:06 AM, Joseph Salowey wrote:

 

 

On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey <joe@salowey.net <mailto:joe@salowey.net> > wrote:

 

 

On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar <oleg.pekar.2017@gmail.com <mailto:oleg.pekar.2017@gmail.com> > wrote:

I still see unclearness in Section "2.2. Identity Verification", I'm trying to look from the implementer's perspective. 

 

1) "Since EAP-TLS deployments may use more than one EAP

   server, each with a different certificate, EAP peer implementations
   SHOULD allow for the configuration of a unique trusted root (CA
   certificate) to authenticate the server certificate and one or more
   server names to match against the SubjectAltName (SAN) extension in
   the server certificate.  To simplify name matching, an EAP-TLS
   deployment can assign a name to represent an authorized EAP server
   and EAP Server certificates can include this name in the list of SANs
   for each certificate that represents an EAP-TLS server." 

 

--- question: Should the server name match *any* of SAN extensions in the server certificate? If so - then suggest to say this explicitly.

 

 

[Joe] DOes adding the following sentence help? 

 

"If any of the configured names match any of the names in the SAN extension then the name check passes."

This makes sense. I will update the draft in github. 

 

 

[Joe] yes the behavior is to match any.

 

2) "If server

   name matching is not used, then peers may end up trusting servers for
   EAP authentication that are not intended to be EAP servers for the
   network." 

 

--- question: It looks like a warning, right? Suggest to make it more explicit. Something like "If server name matching is not used, then it essentially decreases the level of security of peer's authentication since the peer may end up trusting servers for EAP authentication that are not intended to be EAP servers for the network."  

 

 

[Joe] Thanks, I think that is better wording.  

I find the text a little hard to parse. I am not sure how comfortable we are with defining "levels" of security. Also, "peer's authentication" might confuse the reader since we are talking about server name matching. I don't really have a better suggestion. Perhaps something along the lines: .... it essentially degrades the peer's confidence that the EAP server with which it is interacting is authoritative for the given network....??

--Mohit

 

Regards,

Oleg

 

On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey <joe@salowey.net <mailto:joe@salowey.net> > wrote:

This is the working group last-call (WGLC) for draft-ietf-emu-eap-tls13.  Please review the draft, focus on the changes since the last WGLC and submit your comments to the list by July 8, 2021.    

 

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-17

A diff from the previous WGLC version (-15):

https://www.ietf.org//rfcdiff?url1=draft-ietf-emu-eap-tls13-17 <https://www.ietf.org/rfcdiff?url1=draft-ietf-emu-eap-tls13-17&url2=draft-ietf-emu-eap-tls13-15> &url2=draft-ietf-emu-eap-tls13-15


A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-17

 

Thanks,

 

Joe

_______________________________________________
Emu mailing list
Emu@ietf.org <mailto:Emu@ietf.org> 
https://www.ietf.org/mailman/listinfo/emu





_______________________________________________
Emu mailing list
Emu@ietf.org <mailto:Emu@ietf.org> 
https://www.ietf.org/mailman/listinfo/emu