[Reap] EAP - TLS 1.3

Mohit Sethi <mohit.m.sethi@ericsson.com> Thu, 16 November 2017 05:16 UTC

Return-Path: <mohit.m.sethi@ericsson.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 BF12D1201F2; Wed, 15 Nov 2017 21:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.714
X-Spam-Level:
X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 LR1yWqqfoULV; Wed, 15 Nov 2017 21:16:28 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775481286B1; Wed, 15 Nov 2017 21:16:27 -0800 (PST)
X-AuditID: c1b4fb25-d91ff700000020f7-71-5a0d1f299c52
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.75.08439.92F1D0A5; Thu, 16 Nov 2017 06:16:25 +0100 (CET)
Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.352.0; Thu, 16 Nov 2017 06:16:24 +0100
Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id E15074EE1F; Thu, 16 Nov 2017 07:18:53 +0200 (EET)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 297F54E689; Thu, 16 Nov 2017 07:18:51 +0200 (EET)
To: Bernard Aboba <bernard.aboba@gmail.com>, Jim Schaad <ietf@augustcellars.com>
CC: Security Area Advisory Group <saag@ietf.org>, emu@ietf.org, reap@ietf.org
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>
From: Mohit Sethi <mohit.m.sethi@ericsson.com>
Message-ID: <c740099f-4635-0853-5542-3d02eadf6ead@ericsson.com>
Date: Thu, 16 Nov 2017 13:16:21 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms060203040909000608070202"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsUyM2K7rq6mPG+UwdUzihYb9v1ntji2fi2L xerp39kszq08zmIxpb+TyYHVY+Oc6WweO2fdZfdYsuQnUwBzFJdNSmpOZllqkb5dAldG54r3 jAU7LzJWTH28hLmBcf4ixi5GTg4JAROJGf92AdlcHEIChxkluiceZwJJCAnsYJS4dqsEIrGR UeLsm4lsEM4CRolt8w6DVQkLiElsed/N3sXIwSEiECSx96IDSJhZIFji+6FfrBD1bSwS5zft BFvHJqAn0XnuODOIzStgL/Hj9S4WEJtFQFVi5snHrCC2qECExPPm96wQNYISJ2c+AavhFLCV 2PehC2wos0A3o8T0WX/ZIX5Qk7h6bhMzxNnqEls7DjBOYBSahaR/FrKeWWAXhknsX/iHBcIW l7j1ZD4ThG0mMW/zQ2YIW1ti2cLXQDYHkK0msaxVCVUYxLaWmPHrIBuErSgxpfsh1HhTiddH PzJC2MYSy9b9ZVvAyLOKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCiD275rbqD8fIbx0OM AhyMSjy872V5o4RYE8uKK3MPMaoAzXm0YfUFRimWvPy8VCUR3jvSQGnelMTKqtSi/Pii0pzU 4kOM0hwsSuK8HiLcUUIC6YklqdmpqQWpRTBZJg5OqQZGG8+k8KWBUbYcW50jbqWpyy4QNymW fi0bv/B//YurD46w85roPbV+WWl0wPiU8Sleq2tJT22Drs5dvuPFoQPH7qiGLd4ucj85OScz R3mNkIVS7+szCxYGbMm37TCJKmxZdupESKWAR7LHBvu5KlerlxUJqOqUXJ01IaZ0u43s8UyN aIZDUdFKLMUZiYZazEXFiQC4+DT48AIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/reap/fcMk7HMWWWf7enNKcqcefJiyhyo>
Subject: [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 05:16:31 -0000

Hi Bernard,

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.

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 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.
  * RFC5216 specifies that "EAP-TLS implementations MUST support TLS v1.0".
  * 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).

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.

John and Mohit


On 10/30/2017 10:37 AM, Bernard Aboba wrote:
> RFC 5216 only insists on support (not use) of TLS 1.0 and its 
> mandatory ciphersuites in order to ensure interoperability with legacy 
> implementations and avoid an Internet-wide “flag day” requiring 
> millions of hardware devices to be replaced. But if a site wants to 
> impose a TLS version (and ciphersuite) policy, it can.
>
> Mandatory to support algorithms apply to a TLS version, so EAP-TLS 
> inherits them when that version is negotiated. Similarly, EAP-TLS 
> inherits features of each TLS version - all it does is tunnel TLS.
>
> Given this, I am puzzled as to why it is being proposed that RFC 5216 
> be recycled at Proposed in a non-backward compatible manner with vast 
> new IPR encumbrance, completely new authors, and nearly identical 
> text, rather than being left alone or moving to the next standards level.
>
>
>
>
>
>
>
> On Oct 29, 2017, at 5:20 PM, Jim Schaad <ietf@augustcellars.com 
> <mailto:ietf@augustcellars.com>> wrote:
>
>> There is one advantage that can be obtained by using TLS 1.3, if you 
>> want to hide the client name then it is no longer necessary to do an 
>> anonymous connection followed immediately by a re-negotiation with 
>> the proper client certificate.  But that and perhaps mandatory 
>> algorithms is the only think I can think of right off the bat.
>>
>> Jim
>>
>> *From:* saag [mailto:saag-bounces@ietf.org] *On Behalf Of *Bernard Aboba
>> *Sent:* Sunday, October 29, 2017 3:59 PM
>> *To:* Randy Bush <randy@psg.com <mailto:randy@psg.com>>
>> *Cc:* Mohit Sethi <mohit.m.sethi@ericsson.com 
>> <mailto:mohit.m.sethi@ericsson.com>>; Security Area Advisory Group 
>> <saag@ietf.org <mailto:saag@ietf.org>>
>> *Subject:* Re: [saag] [Reap] PSA: New list for discussing EAP related 
>> methods
>>
>> Randy asked:
>>
>> "bernard, for the clueless here, what change is needed for tls 1.3?"
>>
>> and
>>
>> [BA] None as far as I know. EAP-TLS makes use of TLS version 
>> negotiation so it is both forward and backward compatible. So far, 
>> implementations of RFC 5216 based on TLS 1.3 have not demonstrated 
>> any EAP-related issues, as far as I am aware.
>>
>> In general, EAP-TLS can leverage TLS policies the administrator 
>> chooses to impose. So  if the administrator wants to impose a version 
>> policy (e.g. TLS versions 1.2 or later) or a ciphersuite policy (e.g. 
>> no RC4),  there are a number of EAP servers that can be configured to 
>> support this.
>>
>> So rather than attempting to impose an Internet-wide TLS version or 
>> ciphersuite policy (which would impose a huge cost on everyone, given 
>> that there are 2+ billion devices supporting EAP-TLS), it makes a lot 
>> more sense to let the administrators decide, possibly based on 
>> guidance from organizations they trust, such as NIST.  This is how 
>> things have been working for more than a decade.
>>
>> On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush <randy@psg.com 
>> <mailto:randy@psg.com>> wrote:
>>
>>     > Creating a separate list has real drawbacks and very little in
>>     the way of
>>     > benefits.
>>
>>     bernard, for the clueless here, what change is needed for tls 1.3?
>>
>>     randy
>>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag