Re: [Reap] EAP - TLS 1.3

Alan DeKok <aland@deployingradius.com> Thu, 16 November 2017 13:02 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: reap@ietfa.amsl.com
Delivered-To: reap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BEC129454; Thu, 16 Nov 2017 05:02:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 ZKxMl7xdfFqR; Thu, 16 Nov 2017 05:02:10 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id AE6001273B1; Thu, 16 Nov 2017 05:02:06 -0800 (PST)
Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id 81775673; Thu, 16 Nov 2017 13:02:04 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <c740099f-4635-0853-5542-3d02eadf6ead@ericsson.com>
Date: Thu, 16 Nov 2017 08:02:03 -0500
Cc: Bernard Aboba <bernard.aboba@gmail.com>, Jim Schaad <ietf@augustcellars.com>, reap@ietf.org, Security Area Advisory Group <saag@ietf.org>, emu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com>
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <CAOW+2ds9Sez7otrs682hqzzXR8qbJYAdPwW8A8TEL+ms_a0=UA@mail.gmail.com> <ACE2CDE6-4D04-4049-BB15-1E82C214A553@gmail.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <CAOW+2dtzq4d5p3JxwbbdwHqrS+0TpRveJkGb3vYzmdmLVvdcFQ@mail.gmail.com> <m2d1558xyi.wl-randy@psg.com> <CAOW+2du+teg8nicw6eDoSCKx_ZfAAXKtpLb0ogPUTk1Bzr1n_A@mail.gmail.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <c740099f-4635-0853-5542-3d02eadf6ead@ericsson.com>
To: Mohit Sethi <mohit.m.sethi@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/reap/68YqLWCcZ4CgIovs2yPMdWsn9Dw>
Subject: Re: [Reap] EAP - TLS 1.3
X-BeenThere: reap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "REAP \(RENEW\) EAP" <reap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/reap>, <mailto:reap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/reap/>
List-Post: <mailto:reap@ietf.org>
List-Help: <mailto:reap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/reap>, <mailto:reap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 13:02:13 -0000

On Nov 16, 2017, at 12:16 AM, Mohit Sethi <mohit.m.sethi@ericsson.com>; wrote:
> 
> Coming back to our motivation for this draft. 3GPP has decided that authentication in 5G can be done with any type of credential that the operator accepts and that EAP will be used for authentication. The working assumption is that EAP-TLS will be used for mutual authentication with certificates. 3GPP would likely want to use TLS 1.3 as much as possible, especially for EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in EAP-TLS as well as providing encryption of the handshake including the certificates.

  That's good.  But as Bernard points out, there's no need to change EAP-TLS.  You can just use TLS 1.3.

  I think one of the concerns here is the procedural aspect.  Your proposal was to forbid everyone *else* from using TLS 1.0 because your requirements were for TLS 1.3.  That's not the way to gain support.

  In addition, your other arguments are hand-waving, and don't provide concrete details to back up your position.  Having concrete details would help.

> If the EAP community decides that RFC5216 adequately describes how to use TLS 1.3 and does not need an update we can live with that. Our conclusion is however that an update of RFC2516 is needed for several reasons:
> 	• RFC5216 is very much tied to the message flows and message formats in TLS 1.0 - 1.2. The message flows and message content in TLS 1.3 is very different. While a developer could theoretically figure out how to use EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216

  How so?  5216 says (essentially) "encapsulate TLS within EAP".  How, exactly, does this change with TLS 1.3?

> and in the worst case, implementations would not even be compatible.
> 	• TLS 1.3 makes major changes to the Key Schedule. The PRF in TLS 1.0 is 1.2 is replaced with a HKDF. Our understanding is that an update defining the Key Hierarchy in terms of the TLS-Exporter (similar to what is done in draft-ietf-quic-tls) is needed.

  Implementations of EAP-TLS do need to change when the key derivation changes.  Such as for TLS 1.2.  However, those changes are largely limited to the TLS library, not the EAP-TLS code.

> 	• RFC5216 specifies that "EAP-TLS implementations MUST support TLS v1.0".

  You're free to deprecate TLS 1.0 in documents which update RFC5216... if you have IETF consensus.

  Further, you're free to mandate use of TLS 1.3 in 5G specifications.  They're your specifications, and you're free to ignore IETF requirements if you so choose.

> 	• RFC5216 specifies that cipher suites with 3DES, SHA-1, RC4, CBC, and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS version). 

  The same comment as above applies here.

>  If IETF does not provide new message flow diagrams for EAP-TLS with TLS 1.3, it is likely that 3GPP will do that, we would much rather see an IETF RFC that 3GPP and other can refer to.

  What, exactly is different with the message flows in EAP-TLS when TLS 1.3 is used?

  Please be specific.

  Alan DeKok.