From nobody Wed Nov 15 21:16:43 2017 Return-Path: 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 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 , Jim Schaad CC: Security Area Advisory Group , , References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> From: Mohit Sethi Message-ID: 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: Subject: [Emu] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:16:31 -0000 --------------ms060203040909000608070202 Content-Type: multipart/alternative; boundary="------------13B46F11EA805B7B309F12A7" Content-Language: en-US This is a multi-part message in MIME format. --------------13B46F11EA805B7B309F12A7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Bernard, Coming back to our motivation for this draft. 3GPP has decided that=20 authentication in 5G can be done with any type of credential that the=20 operator accepts and that EAP will be used for authentication. The=20 working assumption is that EAP-TLS will be used for mutual=20 authentication with certificates. 3GPP would likely want to use TLS 1.3=20 as much as possible, especially for EAP-TLS, as TLS 1.3 reduces the=20 numbers of roundtrips in EAP-TLS as well as providing encryption of the=20 handshake including the certificates. If the EAP community decides that RFC5216 adequately describes how to=20 use TLS 1.3 and does not need an update we can live with that. Our=20 conclusion is however that an update of RFC2516 is needed for several=20 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=20 1.3, it is likely that 3GPP will do that, we would much rather see an=20 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=20 > mandatory ciphersuites in order to ensure interoperability with legacy = > implementations and avoid an Internet-wide =E2=80=9Cflag day=E2=80=9D r= equiring=20 > millions of hardware devices to be replaced. But if a site wants to=20 > impose a TLS version (and ciphersuite) policy, it can. > > Mandatory to support algorithms apply to a TLS version, so EAP-TLS=20 > inherits them when that version is negotiated. Similarly, EAP-TLS=20 > 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=20 > be recycled at Proposed in a non-backward compatible manner with vast=20 > new IPR encumbrance, completely new authors, and nearly identical=20 > text, rather than being left alone or moving to the next standards leve= l. > > > > > > > > On Oct 29, 2017, at 5:20 PM, Jim Schaad > wrote: > >> There is one advantage that can be obtained by using TLS 1.3, if you=20 >> want to hide the client name then it is no longer necessary to do an=20 >> anonymous connection followed immediately by a re-negotiation with=20 >> the proper client certificate.=C2=A0 But that and perhaps mandatory=20 >> 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 Abo= ba >> *Sent:* Sunday, October 29, 2017 3:59 PM >> *To:* Randy Bush > >> *Cc:* Mohit Sethi > >; Security Area Advisory Group=20 >> > >> *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=20 >> negotiation so it is both forward and backward compatible. So far,=20 >> implementations of RFC 5216 based on TLS 1.3 have not demonstrated=20 >> any EAP-related issues, as far as I am aware. >> >> In general, EAP-TLS can leverage TLS policies the administrator=20 >> chooses to impose. So=C2=A0 if the administrator wants to impose a ver= sion=20 >> policy (e.g. TLS versions 1.2 or later) or a ciphersuite policy (e.g. = >> no RC4),=C2=A0 there are a number of EAP servers that can be configure= d to=20 >> support this. >> >> So rather than attempting to impose an Internet-wide TLS version or=20 >> 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=20 >> guidance from organizations they trust, such as NIST.=C2=A0 This is ho= w=20 >> things have been working for more than a decade. >> >> On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush > > 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 --------------13B46F11EA805B7B309F12A7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 specifi= es that "EAP-TLS implementations MUST support TLS v1.0".
  • RFC5216 specifi= es 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).
=C2=A0If 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=

=C2=A0


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 =E2=80=9Cflag d= ay=E2=80=9D requiring millions of hardware devices to be replaced. But if a site wants to impose a TLS version (and ciphersuite) policy, it can.

Mand= atory 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.=C2=A0

=


=


=

=

On Oct 29, 2017, at 5:20 PM, Jim Schaad <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.=C2=A0 But that and perhaps mandatory algorithms is the only think I can think of right off the bat.

=C2=A0

Jim

=C2=A0

=C2=A0

From: saag [mailto:saag-bounces@ietf.o= rg] On Behalf Of Bernard Aboba
Sent: Sunday, October 29, 2017 3:59 PM
To: Randy Bush <randy@psg.com>
Cc: Mohit Sethi <mohit.m.sethi@ericsson.com= >; Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods

=C2=A0

Randy asked:=C2=A0

=C2=A0

"bernard, for the clueless here, what change is needed for tls 1.3?"

and=C2=A0

=C2=A0

[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.

=C2=A0

In general, EAP-TLS can leverage= TLS policies the administrator chooses to impose.=C2=A0= So=C2=A0 if the administrator wants to impose a versi= on policy (e.g. TLS versions 1.2 or later) or a ciphersuite policy (e.g. no RC4),=C2=A0 there are a number of EAP servers that can be configured to support this.

=C2=A0

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.=C2=A0 Th= is is how things have been working for more than a decade.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 29, 2017 at 2:07 PM,= Randy Bush <randy@ps= g.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

=C2=A0



_______________________________________________
saag mailing list
saag@=
ietf.org
https://www.ietf.org/mailman/listinfo/saag

--------------13B46F11EA805B7B309F12A7-- --------------ms060203040909000608070202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMUwggX7MIID46ADAgECAhBcf8Ki080s7KKjg2APnSBWMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEwMDgxMDAzMjJaFw0yMDEwMDgxMDAzMjFaMGgxETAPBgNV BAoMCEVyaWNzc29uMRYwFAYDVQQDDA1Nb2hpdCBTZXRoaSBNMSkwJwYJKoZIhvcNAQkBFhpt b2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZXNldG1vaDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAN23/VIr1UI1NLeaFL45vzBE0NglNKyyUQknMqT5zRxm ocJ74fYRJmfHmaQxEYdxp6cCYFxbM2OJOiMN5LRxEQG282Dsjnff6mHXt5wNsMrHZ88poT3X yZCzFBkQF/kswJKu6OD9v1J6WWl9fV2h0QRP0ju+B/H2O3OzioHDP9Qazzr5TMTvmRmXoMfh WXyH/joBaGVyn8SCeRaI0wVGRCKDp93UzdL5o+qGqCUPJQP/2SR/4UoCUTqEtSgh4iCBNAs/ OwhHwbWdU73/EJtsaaOG2fhwMTgWR3KJOIUMyWtRBcO9cIan+82SNgAByR4x2BKIWgFvSPNo GXKn1nOi0W0CAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1 c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUFBwEB BHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGm1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUM0z7o31aA+qQasQqDc7/Ppn7u5MwHwYDVR0jBBgwFoAUHHsZ npecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQCB 35yJmyIRJUmxQmpYX7hNdQJXxJdIAMzCe+rQsz+0F1zA8xsYn4Rn5m7SVGKbE4ONC+EUHHzQ o1OpA5txlK+IPRMqZTM2cQpAet8Qy2vRqFVd0pFDmPx0Az/SPooz7gnuIaPaCGeXOSSxtSOu rX+7fE2EiE/SuCFKmtsFmwnZH62hDDtzd3XTwmJia/5Ab+8/elAstT5a1cP52SorrkuLPgAB ny/XJzsU3LOQQ37Wm5DMyMPEK+zkBG/+2t1cOGgryvu7Hq14NfkAUZxHMei6Yf2UABNxbapB 4tyxqpZuPZDl1AwRKMGYHPsnywK4PZDdsD6R+O/YCWdfq9Q3MMCT3C6vu38phy1r6QDCVHVI IPdirDfZ2ypbeqHAwkswioykkBTln9DEyaTYMlxb41EYh/3JwUQmuQQ4ozSfcLTwoaQ+M+Z4 1J/n7AARwD7u3Lb2ls+fmvOLrC+tc0pXlvTKspIhpaNC1Cz7sbsjMSbSqBW9PtY+Vex7GB2J zI8fDHTT/8Jx+33cta2BE6mPFeUY2lu12zQiqNVUc9zEQ7WqGz4VTGFZDnzfU2gCAAYsuimf kQJD+Sr2G3wXs38yN1OhWHBuG1fglz0k5URhXMNC8HtRityIm2504ym5GpTrriJ8X1fQDYN1 WlOPvv4xJpfHAz4NMKJKQmCNtfuZ8BNNyTCCBsIwggSqoAMCAQICEFO4foPhnJkok7CbSRzs uOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRl bGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8A ALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL 7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhV W4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujn whljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W0 7nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBR QGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1 fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77 /NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioIT KffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAt BggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUF BzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQB gg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFz b25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVs aWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OOR auPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUA A4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNH CZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKv dASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQy sshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgb MgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6L kIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3T QYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX 2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDk ZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEBMFswRzELMAkGA1UE BhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlk dWFsIENBIHYzAhBcf8Ki080s7KKjg2APnSBWMA0GCWCGSAFlAwQCAQUAoIIBsTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTYwNTE2MjFaMC8GCSqG SIb3DQEJBDEiBCBZDJovbASejCQ3AoMT0bttu32tYZrM4qS/yjOnYz+ONzBqBgkrBgEEAYI3 EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQXH/CotPNLOyio4NgD50gVjBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMGwGCyqGSIb3 DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEFx/wqLTzSzsoqODYA+dIFYwDQYJKoZI hvcNAQEBBQAEggEASn0I6VhWuI7CflZ1EUvWZlno6QTRz3MlVxdQAg/wyqqPm6n/CuMKS4Ej sGN3cI/C8suiRurST6xIz16wNs9XHlEY8R6R955bSZ0x/A+d/I7193wldYmunq1bR+hLWjZs cQsLNFCuYkH/iQycRejCOzW/fERuNiz0C5kx8CgmRxBS+HsZXy60IsswpkudZaYhyxVv+SfC 0ePuHiBj9wWXQI46zEk8IGghz/WPY+B9BZShqShWx+zt2JLluciKWbel39Q7zVpaLn/BJ9Kf R7ed3/QGg4Y+HGXL7jZwsmnSJP5w/q0ahcX1Ptyg1fevpjerjIgkYY+PPWAfQ6Q/+nfvTwAA AAAAAA== --------------ms060203040909000608070202-- From nobody Wed Nov 15 22:13:00 2017 Return-Path: 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 E5A761294D8; Wed, 15 Nov 2017 22:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HmVIdAPy1uI9; Wed, 15 Nov 2017 22:12:51 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 510BF129521; Wed, 15 Nov 2017 22:12:51 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id f14so7877688uaa.5; Wed, 15 Nov 2017 22:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ShP3e3tUxe2Mt0Jg+VAaS8zAl4mfnisRhQqnBeYACMQ=; b=bC5Oj94BsIr/O8FKFDTWDis/8GWO4imDKzUvBnbEnbvSugHpxqe0Bhom7EpU5Ck8ne Em5npfOBvDOUTU6EbNYlgWnhkv5SqIl24g9EQQgaJ96b/HjDj379ffsuqwVac5fPWnoJ vwoTtAaOPK8YN5SVxhj1qi/wcpEYPcL93IBhK2oeDs+vPBDUDDEyQ9Edxn7SAY0XVdno on87CiGP6W8LyWZIjV5Ba2CGwcShg/wIJYxowChBqSs8JnZAcWl8YffxoOGDtKLpen+0 JN7RwwuSozmLCUKejLdpXwozirhreFcXwmj2d4OgEhu5vWqM8hVhwLQs+f+g7XCmnP60 JeGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ShP3e3tUxe2Mt0Jg+VAaS8zAl4mfnisRhQqnBeYACMQ=; b=PQrrgU6YOqQn+ZwMxpn7OJ/IkiAtHsrWFzjbC8Q2cSnuq0MvVgZJJklIXclBtDugcB kNr2mAqVNV7jlxHsDHI5nrHLQaAY2rwFMEDcD+fqqisDcuqsoDF7js7REMmbGpeU9hlv +AraxWhnsQZmM9eNG+DEg6L9eWQ03kSdzLFoGpDw1UVgJWoTdBLCH05VsiRbqC8O/sUe e0p3bnA1CjPA2BJldThWi74pATNQvlknCb6RoqQmzfi+jT22olxtselC0c/7Ad0vxiDu 18s+VPloWTUURkh4z9SoGsraSSmSc1Hp6INHlpV0PG476FLsdbwJnScogkf3Wf+VSv3K x9+g== X-Gm-Message-State: AJaThX52qXTYEi+ln/AfqMCr7rk++1E0ncrgepsC/leTKVGL0vmsbcbm o/o0X+5JSE8IuUD3DPDKeZG3AjRG69/gK9YmMzo= X-Google-Smtp-Source: AGs4zMbpS3Lszz06wLVp8a4NdSFeLak/EkMixO4Bs4Zd1CO9s2vaFDsiRMBTh6SKuWA5YCJU+eApQz/Ztc/wVXrQy4w= X-Received: by 10.176.20.225 with SMTP id f30mr447813uae.66.1510812770197; Wed, 15 Nov 2017 22:12:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Wed, 15 Nov 2017 22:12:29 -0800 (PST) In-Reply-To: References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> From: Bernard Aboba Date: Wed, 15 Nov 2017 22:12:29 -0800 Message-ID: To: Mohit Sethi Cc: Jim Schaad , Security Area Advisory Group , emu@ietf.org, reap@ietf.org Content-Type: multipart/alternative; boundary="001a1145ab007d661f055e138206" Archived-At: Subject: Re: [Emu] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 06:12:54 -0000 --001a1145ab007d661f055e138206 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable - RFC5216 is very much tied to the message flows and message formats in TLS 1.0 - 1.2. [BA] EAP-TLS encapsulates TLS within EAP so the basic protocol flow is not version dependent. The (non-normative) examples were designed to illustrate the EAP-TLS protocol flow, so though they are based on TLS 1.0/1.1 (1.2 came later) that doesn't affect the protocol. - 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 wors= t case, implementations would not even be compatible. [BA] While the TLS protocol changes with version 1.3, the basic flow of the EAP conversation (and EAP-TLS) does not change - it's just a tunneling protocol that takes TLS blobs and encapsulates them in EAP. As a result, there are already experimental implementations of EAP-TLS based on version 1.3 that required minimal code changes in EAP-TLS. Do you have an implementation of EAP-TLS that supported earlier versions? - 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 definin= g the Key Hierarchy in terms of the TLS-Exporter (similar to what is done = in draft-ietf-quic-tls) is needed. TLS 1.3 Section 7.3 defines how the keys are calculated - and so the TLS-Exporter changes should be straightforward. - RFC5216 specifies that "EAP-TLS implementations MUST support TLS v1.0"= . [BA] Support for TLS v1.0 is required for backward compatibility. EAP-TLS has been deployed on over 2+ billion systems and is supported by a hardware ecosystem. Many of those existing implementations would be broken if the requirement to support TLS v1.0 were to be removed. So while any organization can decide they only want to allow a given version of TLS, the requirement to support 1.0 must remain. - 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). Those ciphersuite choices were based on the need for backward compatibility. An organization mandating more advanced versions of TLS will automatically inherit the mandatory ciphersuites of those versions. So this doesn't preclude interoperability of EAP-TLS 1.1, 1.2, 1.3 or any future version of TLS. On Wed, Nov 15, 2017 at 9:16 PM, Mohit Sethi wrote: > 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 workin= g > 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 wh= at 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 IET= F > 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 =E2=80=9Cflag day=E2=80=9D req= uiring 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 inherit= s > 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 IP= R > encumbrance, completely new authors, and nearly identical text, rather th= an > being left alone or moving to the next standards level. > > > > > > > > On Oct 29, 2017, at 5:20 PM, Jim Schaad 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 clien= t > 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 > *Cc:* Mohit Sethi ; Security Area Advisory > Group > *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, a= s > far as I am aware. > > > > In general, EAP-TLS can leverage TLS policies the administrator chooses t= o > 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 tha= t > there are 2+ billion devices supporting EAP-TLS), it makes a lot more sen= se > 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 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 listsaag@ietf.orghttps://www.ietf.org/mailman/listinfo/saag > > > --001a1145ab007d661f055e138206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
  • RFC5216 is very much tied= to the message flows and message formats in TLS 1.0 - 1.2.
    • [BA] EAP-TLS encapsulates TLS wit= hin EAP so the basic protocol flow is not version dependent.=C2=A0 The (non= -normative) examples were designed to illustrate the EAP-TLS protocol flow,= so though they are based on TLS 1.0/1.1 (1.2 came later) that doesn't = affect the protocol.=C2=A0
    • =C2= =A0The message flows and message content in TLS 1.3 is very different. Whil= e 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, i= mplementations would not even be compatible.
    [BA] While the TLS protocol changes with version= 1.3, the basic flow of the EAP conversation (and EAP-TLS) does not change = - it's just a tunneling protocol that takes TLS blobs and encapsulates = them in EAP.=C2=A0 As a result, there are already experimental implementati= ons of EAP-TLS based on version 1.3 that required minimal code changes in E= AP-TLS. Do you have an implementation of EAP-TLS that supported earlier ver= sions?
    • TLS 1.3 makes major cha= nges 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 o= f the TLS-Exporter (similar to what is done in draft-ietf-quic-tls) is need= ed.
    TLS 1.3 Section 7.3 defines how the = keys are calculated - and so the TLS-Exporter changes should be straightfor= ward.
  • RFC5216 specifies that &= quot;EAP-TLS implementations MUST sup= port TLS v1.0".
[BA] Support for TL= S v1.0 is required for backward compatibility.=C2=A0 EAP-TLS has been deplo= yed on over 2+ billion systems and is supported by a hardware ecosystem. Ma= ny of those existing implementations would be broken if the requirement to = support TLS v1.0 were to be removed.=C2=A0 So while any organization can de= cide they only want to allow a given version of TLS, the requirement to sup= port 1.0 must remain.=C2=A0
  • RF= C5216 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).=C2=A0
Those ciphersuite = choices were based on the need for backward compatibility.=C2=A0 An organiz= ation mandating more advanced versions of TLS will automatically inherit th= e mandatory ciphersuites of those versions.=C2=A0 So this doesn't precl= ude interoperability of EAP-TLS 1.1, 1.2, 1.3 or any future version of TLS.= =C2=A0

On Wed, Nov 15, 2017 at 9:16 PM, Mohit Sethi <= mohit.m.set= hi@ericsson.com> wrote:
=20 =20 =20
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).
=C2=A0If 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

=

= =C2=A0


On 10/30/2017 10:3= 7 AM, Bernard Aboba wrote:
=20
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 =E2=80=9Cflag day= =E2=80=9D 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.=C2=A0







On Oct 29, 2017, at 5:20 PM, Jim Schaad <ietf@augustcellars.com> wrote:

=20 =20 =20

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.=C2=A0 But that and perhaps mandatory algorithms is the only think I can think of right off the bat.

=C2=A0

Jim

=C2=A0

=C2=A0

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>
Cc: Mohit Sethi <mohit.m.sethi@ericsson.com>; Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods

=C2=A0

Randy asked:=C2=A0

=C2=A0

"bernard, for the clueless here, what change is needed for tls 1.3?"

and=C2=A0

=C2=A0

[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.

=C2=A0

In general, EAP-TLS can leverage TLS policies the administrator chooses to impose.=C2=A0 So=C2=A0 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),=C2=A0 there are a number of EAP servers that can be configured to support this.

=C2=A0

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.=C2=A0 This is how things have been working for more than a decade.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush <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<= /span>

=C2=A0



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/saag


--001a1145ab007d661f055e138206-- From nobody Thu Nov 16 04:02:52 2017 Return-Path: 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 48607129435; Thu, 16 Nov 2017 04:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Nj9nC2H7ivrL; Thu, 16 Nov 2017 04:02:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id B5CF0128B44; Thu, 16 Nov 2017 04:02:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DF9BD2D199; Thu, 16 Nov 2017 14:02:32 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mmxdeeXxkbN; Thu, 16 Nov 2017 14:02:31 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 6292B2CD0D; Thu, 16 Nov 2017 14:02:30 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Thu, 16 Nov 2017 20:02:28 +0800 Cc: reap@ietf.org, Security Area Advisory Group , emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <58815EFC-3CF9-4F62-A7E3-6E76FBAA295A@piuha.net> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> To: Bernard Aboba , Mohit Sethi X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Emu] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 12:02:38 -0000 I don=E2=80=99t want to push the decision in either direction without = looking into the details. But I wanted to point out that there=E2=80=99s usually a third = alternative between =E2=80=9Cno need for new documents=E2=80=9D and = =E2=80=9Cneed a new RFC to describe the new version=E2=80=9D. Explaining = that the old protocol can be used and what the implications are may by = itself be a useful document. In the specific example, is not immediately = obvious to me for instance if the security consideration would somehow = change, or if 0-RTT can or can not be used, etc. Jari From nobody Thu Nov 16 05:02:14 2017 Return-Path: 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 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 In-Reply-To: Date: Thu, 16 Nov 2017 08:02:03 -0500 Cc: Bernard Aboba , Jim Schaad , reap@ietf.org, Security Area Advisory Group , 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> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> To: Mohit Sethi X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Emu] [Reap] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 13:02:13 -0000 On Nov 16, 2017, at 12:16 AM, Mohit Sethi = wrote: >=20 > 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: > =E2=80=A2 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. > =E2=80=A2 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. > =E2=80=A2 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. > =E2=80=A2 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).=20 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. From nobody Thu Nov 16 05:56:55 2017 Return-Path: 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 736C51293F3; Thu, 16 Nov 2017 05:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nQPVxqFkSu6N; Thu, 16 Nov 2017 05:56:46 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 AEC69126C2F; Thu, 16 Nov 2017 05:56:45 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id b7so16556921vkh.12; Thu, 16 Nov 2017 05:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TABAMLXA0H2f2C+KvuNuE5eVolyDDQ7CPP/BB4YEd5A=; b=tHxD5iK1vIsKBq1UbVGm20nAGffTWgfuVJwZatt7SC1MtGTUlLmlsf7/ezpwLHfrKL 8mGdFKyyD0oivIREkIu4I6rhpWYDk2fqbrrDTnxKjIi8Ypb8zQZI/KhDBNm5mQu4whlt l8F6ptw6Hx1Frz+9pBTC7gIqVCZjf449nBC+G1bDeew69BfhGxAMpZ/y5C8b/Plfme7O rjJ4WhrzB7lwi0AHxQvyY0lps3ckNyJYccjdr7BigN09/eisPCbRSQ1nBN54HeWI/4Hk 4BWDwdYf6N+GW2NqfUqvvaHJkyjy0sxdp8LvlPiohUQBmwmRx8PMfRqO12ir8Nrv31ln Nmlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TABAMLXA0H2f2C+KvuNuE5eVolyDDQ7CPP/BB4YEd5A=; b=GrvpKoB2OsoU3SQWIluFmx+9f4IMrMcNvGE0BWVY5u4LSKcc11WsXs2sX/5hdsyyVC IN/GXTI0VbFEtYxVFTdAzJjBNbVqZd9Ga/Q009Kn/qZgHUF+/8Qwxy9OsILxc70mBf6D 6kMe0akEylJY3SUhewJvxSueSjCVeEmgTqM6M9r00NBUiYtGOuIAqx4xoSmU3qZQUbVE qKS2+ioUN2IxC1IGFxOpEngvWwll6Su1hYZUl22rULAfOjfyxI4PH4ktoHuux4RBZJzx OFgeEQ1sTLQA1SygA5KWIYPTBKWPl7zAckggRxZG/m42DZExB903gfl7Xe4Fa4QOTY+8 TLJQ== X-Gm-Message-State: AJaThX6K9FqHRtdWT7yi6Db0GgcrSW6QrlP/gxl46fkoNEc0nqOlY4C0 0hNkLm03B5bbew8C4QIAl/hZgQhxP14leKy20pg= X-Google-Smtp-Source: AGs4zMafyGUjUMVtGq2OBBrWFpwNj7q9a37xGDy5EhQsq1JbR13rfb4yx8/SjZh+z1xNoPk/fTT1sVTjemv3iugSM6I= X-Received: by 10.31.13.14 with SMTP id 14mr1182174vkn.24.1510840604353; Thu, 16 Nov 2017 05:56:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Thu, 16 Nov 2017 05:56:23 -0800 (PST) In-Reply-To: <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com> From: Bernard Aboba Date: Thu, 16 Nov 2017 05:56:23 -0800 Message-ID: To: Alan DeKok Cc: Mohit Sethi , Jim Schaad , reap@ietf.org, Security Area Advisory Group , emu@ietf.org Content-Type: multipart/alternative; boundary="001a1143835a8905dc055e19fdb2" Archived-At: Subject: Re: [Emu] [Reap] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 13:56:48 -0000 --001a1143835a8905dc055e19fdb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alan said: "That's good. But as Bernard points out, there's no need to change EAP-TLS. You can just use TLS 1.3." [BA] Existing implementations enable organizations to impose TLS version and ciphersuite requirements on *their* devices. For example, I have worked with organizations that require FIPS 140-3 support, who impose those cryptographic requirements through policy. Of course, such a constraint may bring with it the need to upgrade EAP-TLS clients and AAA servers - but that cost is imposed *only* on the organization imposing the policy. "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." [BA] The proposal would force the replacement of 2+ billion EAP implementations along with millions of smartcards and other hardware that is incompatible with TLS 1.3. It would also make every EAP-TLS implementation subject to patent declarations on later TLS versions. A search through the IPR declaration database discloses a horrifying number of declarations that would apply as a result. A proposal imposing such extraordinary costs requires extraordinary justification. So far, I am not aware of a declaration from any standards organization or authority that versions of TLS prior to 1.3 need to be phased out. "In addition, your other arguments are hand-waving, and don't provide concrete details to back up your position. Having concrete details would help." [BA] So far, I read the argument as "Someone implementing EAP-TLS from scratch with TLS 1.3 might not get it right." But given the *huge* number of deployed devices out there, we need something much more concrete - like test data demonstrating a real interoperability problem. On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok wrote: > On Nov 16, 2017, at 12:16 AM, Mohit Sethi > 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 workin= g > 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: > > =E2=80=A2 RFC5216 is very much tied to the message flows and mess= age > 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 t= o > 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. > > =E2=80=A2 TLS 1.3 makes major changes to the Key Schedule. The PR= F 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 limite= d > to the TLS library, not the EAP-TLS code. > > > =E2=80=A2 RFC5216 specifies that "EAP-TLS implementations MUST su= pport TLS > v1.0". > > You're free to deprecate TLS 1.0 in documents which update RFC5216... i= f > 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. > > > =E2=80=A2 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 TL= S > 1.3, it is likely that 3GPP will do that, we would much rather see an IET= F > 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. > > --001a1143835a8905dc055e19fdb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alan said:

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

[BA] Existing implementations enable organizations to imp= ose TLS version and ciphersuite requirements on *their* devices.=C2=A0 For = example, I have worked with organizations that require FIPS 140-3 support, = who impose those cryptographic requirements through policy. Of course, such= a constraint may bring with it the need to upgrade EAP-TLS clients and AAA= servers - but that cost is imposed *only* on the organization imposing the= policy.=C2=A0

=C2=A0"I think one of the conc= erns here is the procedural aspect.=C2=A0 Your proposal was to forbid every= one *else* from using TLS 1.0 because your requirements were for TLS 1.3.= =C2=A0 That's not the way to gain support."

<= div>[BA] The proposal would force the replacement of 2+ billion EAP impleme= ntations along with millions of smartcards and other hardware that is incom= patible with TLS 1.3.=C2=A0 It would also make every EAP-TLS implementation= subject to patent declarations on later TLS versions.=C2=A0 A search throu= gh the IPR declaration database discloses a horrifying number of declaratio= ns that would apply as a result.

A proposal imposi= ng such extraordinary costs requires extraordinary justification.=C2=A0 So = far, I am not aware of a declaration from any standards organization or aut= hority that versions of TLS prior to 1.3 need to be phased out.=C2=A0
=

"In addition, you= r other arguments are hand-waving, and don't provide concrete details t= o back up your position.=C2=A0 Having concrete details would help.&q= uot;

[BA] So far, I read the argument as "= ;Someone implementing EAP-TLS from scratch with TLS 1.3 might not get it ri= ght."=C2=A0 But given the *huge* number of deployed devices out there,= we need something much more concrete - like test data demonstrating a real= interoperability problem.

On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok <aland@deployingradius.com> wrote:
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 au= thentication in 5G can be done with any type of credential that the operato= r accepts and that EAP will be used for authentication. The working assumpt= ion is that EAP-TLS will be used for mutual authentication with certificate= s. 3GPP would likely want to use TLS 1.3 as much as possible, especially fo= r 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.

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

=C2=A0 I think one of the concerns here is the procedural aspect.=C2=A0 You= r proposal was to forbid everyone *else* from using TLS 1.0 because your re= quirements were for TLS 1.3.=C2=A0 That's not the way to gain support.<= br>
=C2=A0 In addition, your other arguments are hand-waving, and don't pro= vide concrete details to back up your position.=C2=A0 Having concrete detai= ls 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 conclusi= on is however that an update of RFC2516 is needed for several reasons:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 is very much tied to the m= essage flows and message formats in TLS 1.0 - 1.2. The message flows and me= ssage content in TLS 1.3 is very different. While a developer could theoret= ically figure out how to use EAP-TLS with TLS 1.3, such an implementation w= ould not follow RFC5216

=C2=A0 How so?=C2=A0 5216 says (essentially) "encapsulate TLS w= ithin EAP".=C2=A0 How, exactly, does this change with TLS 1.3?

> and in the worst case, implementations would not even be compatible. >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 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 under= standing is that an update defining the Key Hierarchy in terms of the TLS-E= xporter (similar to what is done in draft-ietf-quic-tls) is needed.

=C2=A0 Implementations of EAP-TLS do need to change when the key der= ivation changes.=C2=A0 Such as for TLS 1.2.=C2=A0 However, those changes ar= e largely limited to the TLS library, not the EAP-TLS code.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 specifies that "EAP-T= LS implementations MUST support TLS v1.0".

=C2=A0 You're free to deprecate TLS 1.0 in documents which update RFC52= 16... if you have IETF consensus.

=C2=A0 Further, you're free to mandate use of TLS 1.3 in 5G specificati= ons.=C2=A0 They're your specifications, and you're free to ignore I= ETF requirements if you so choose.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 specifies that cipher suit= es with 3DES, SHA-1, RC4, CBC, and MD5 are mandatory-to-implement for EAP-T= LS (i.e. not based on the TLS version).

=C2=A0 The same comment as above applies here.

>=C2=A0 If IETF does not provide new message flow diagrams for EAP-TLS w= ith 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.

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

=C2=A0 Please be specific.

=C2=A0 Alan DeKok.


--001a1143835a8905dc055e19fdb2-- From nobody Thu Nov 16 06:15:19 2017 Return-Path: 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 D590F12954B; Thu, 16 Nov 2017 06:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qsJp_NAnSlnx; Thu, 16 Nov 2017 06:15:15 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 413E01293FD; Thu, 16 Nov 2017 06:15:15 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id k82so8465268vkd.5; Thu, 16 Nov 2017 06:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h+gUjhU4N+7Z6jkhAAB97DijI2qcRD1D0kNoWJqJ+dk=; b=d+tWYc4XNWdQL4yn8ALhm4aLHw4rVULAeSMfty7dLNCSUF8PaSuaVfEk0quImhbDVT aenal7UzrIQCYdQB7Wpkjxj806dDZq/m+8mZP+sZTSPyhBRZv/liLgNZeBJYqUBz5SrT cdFnceMhFn5gEQ5XyWGRoOjCq+lvAGSWwjYociHQ3zXLAaX+UjFj0L63079XHKhR6e1B AY5kWvpL86xjzlNePRAnmx3NV/JfJjLLPWQ/dIoLVEwEjVR+e0K11hapWuIFYWsKw2Iv ZUnCiCsZnbTGBAmOAOawt4gAAwedLw9pyoh/KQp6AG0kJz/FDIOMpmh1n5hHhdbm58HX F8OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h+gUjhU4N+7Z6jkhAAB97DijI2qcRD1D0kNoWJqJ+dk=; b=Keet7q4tLrJtKFmcfc39SuEJoPS60fxHwYTGIZNh+yhyAGtl9iw8oFTCRF2r+cgZnC 6d5YIL0rqAEjeHh2Bzm1LAw3fNzthsjZNTY2SYHLjO9r7Mfe8JgzREy52t2xPhb9CXb4 blPYDyiQfWhv31H+CBX/AtJXilkYi3ewUWSvD84ODXY2KjOB0KZFkwMDczk821n/gVUM khw6KUlaq71IkzmRtkRHosTnz8l0YWFevJrDXzXvyJwk8zKSGZHmRy7S+TSxHPUrRSS7 334r0SR5oeZbZS/SdQUXnrAomzZvaksmWEPIFol9w/WPlE3fcolx4y9uT4BG1Bh1CVde n20g== X-Gm-Message-State: AJaThX5yb+VSb7t50xMGAZZaITGxgKYxqlQ1NcSk7kfXZ5vhASDVqpW8 5qO/xa6EmkON+UvVpaeGmGQeEAUSDck6rQ06rxE= X-Google-Smtp-Source: AGs4zMYoAjhq9OFYkVIn+Yd/6Qu3gOuQHZSufxvG1v64trAya2o3Lh1IfkWIVu1Gu+t76OnE8KvMAQrspptYAndSd8s= X-Received: by 10.31.13.14 with SMTP id 14mr1257644vkn.24.1510841713957; Thu, 16 Nov 2017 06:15:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Thu, 16 Nov 2017 06:14:53 -0800 (PST) In-Reply-To: <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com> From: Bernard Aboba Date: Thu, 16 Nov 2017 06:14:53 -0800 Message-ID: To: Alan DeKok Cc: Mohit Sethi , Jim Schaad , reap@ietf.org, Security Area Advisory Group , emu@ietf.org Content-Type: multipart/alternative; boundary="001a1143835aac1fa5055e1a3fd2" Archived-At: Subject: Re: [Emu] [Reap] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 14:15:18 -0000 --001a1143835aac1fa5055e1a3fd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alan said: " 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." [BA] There are many organizations who have imposed cryptographic or version policies on their EAP-TLS implementations. For example, governments requiring FIPS 140-3 compliance configure their AAA servers to impose that requirement. No change to the specification is required for members of 3GPP to configure such restrictions in their AAA servers. Of course, imposing such a restriction is only practical if you're willing to deny access to devices that don't implement TLS 1.3. That typically is only workable in the case of a new service that can only be accessed with new devices conforming to a new specification. If that is the situation we're talking about, 3GPP can add TLS cryptographic or version restrictions to their specifications. That wouldn't violate RFC 5216, and it would avoid imposing huge costs on everyone else. On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok wrote: > On Nov 16, 2017, at 12:16 AM, Mohit Sethi > 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 workin= g > 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: > > =E2=80=A2 RFC5216 is very much tied to the message flows and mess= age > 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 t= o > 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. > > =E2=80=A2 TLS 1.3 makes major changes to the Key Schedule. The PR= F 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 limite= d > to the TLS library, not the EAP-TLS code. > > > =E2=80=A2 RFC5216 specifies that "EAP-TLS implementations MUST su= pport TLS > v1.0". > > You're free to deprecate TLS 1.0 in documents which update RFC5216... i= f > 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. > > > =E2=80=A2 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 TL= S > 1.3, it is likely that 3GPP will do that, we would much rather see an IET= F > 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. > > --001a1143835aac1fa5055e1a3fd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alan said:=C2=A0

"=C2=A0Further, you're free to mandate use of TLS 1.3 i= n 5G specifications.=C2=A0 They're your specifications, and you're = free to ignore IETF requirements if you so choose."
<= br>
[BA] There are many organizations who have imposed cryptograp= hic or version policies on their EAP-TLS implementations.=C2=A0 For example= , governments requiring FIPS 140-3 compliance configure their AAA servers t= o impose that requirement.=C2=A0 No change to the specification is required= for members of 3GPP to configure such restrictions in their AAA servers.= =C2=A0

Of course, imposing such a restriction is o= nly practical if you're willing to deny access to devices that don'= t implement TLS 1.3. That typically is only workable in the case of a new s= ervice that can only be accessed with new devices conforming to a new speci= fication.=C2=A0

If that is the situation we're= talking about, 3GPP can add TLS cryptographic or version restrictions to t= heir specifications.=C2=A0 That wouldn't violate RFC 5216, and it would= avoid imposing huge costs on everyone else.=C2=A0

On Thu, Nov 16, 2017 at 5:02 A= M, Alan DeKok <aland@deployingradius.com> wrote:
=
On Nov 16, 2017, at 12:16 A= M, Mohit Sethi <mohit.m.se= thi@ericsson.com> wrote:
>
> Coming back to our motivation for this draft. 3GPP has decided that au= thentication in 5G can be done with any type of credential that the operato= r accepts and that EAP will be used for authentication. The working assumpt= ion is that EAP-TLS will be used for mutual authentication with certificate= s. 3GPP would likely want to use TLS 1.3 as much as possible, especially fo= r 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.

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

=C2=A0 I think one of the concerns here is the procedural aspect.=C2=A0 You= r proposal was to forbid everyone *else* from using TLS 1.0 because your re= quirements were for TLS 1.3.=C2=A0 That's not the way to gain support.<= br>
=C2=A0 In addition, your other arguments are hand-waving, and don't pro= vide concrete details to back up your position.=C2=A0 Having concrete detai= ls 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 conclusi= on is however that an update of RFC2516 is needed for several reasons:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 is very much tied to the m= essage flows and message formats in TLS 1.0 - 1.2. The message flows and me= ssage content in TLS 1.3 is very different. While a developer could theoret= ically figure out how to use EAP-TLS with TLS 1.3, such an implementation w= ould not follow RFC5216

=C2=A0 How so?=C2=A0 5216 says (essentially) "encapsulate TLS w= ithin EAP".=C2=A0 How, exactly, does this change with TLS 1.3?

> and in the worst case, implementations would not even be compatible. >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 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 under= standing is that an update defining the Key Hierarchy in terms of the TLS-E= xporter (similar to what is done in draft-ietf-quic-tls) is needed.

=C2=A0 Implementations of EAP-TLS do need to change when the key der= ivation changes.=C2=A0 Such as for TLS 1.2.=C2=A0 However, those changes ar= e largely limited to the TLS library, not the EAP-TLS code.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 specifies that "EAP-T= LS implementations MUST support TLS v1.0".

=C2=A0 You're free to deprecate TLS 1.0 in documents which update RFC52= 16... if you have IETF consensus.

=C2=A0 Further, you're free to mandate use of TLS 1.3 in 5G specificati= ons.=C2=A0 They're your specifications, and you're free to ignore I= ETF requirements if you so choose.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 specifies that cipher suit= es with 3DES, SHA-1, RC4, CBC, and MD5 are mandatory-to-implement for EAP-T= LS (i.e. not based on the TLS version).

=C2=A0 The same comment as above applies here.

>=C2=A0 If IETF does not provide new message flow diagrams for EAP-TLS w= ith 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.

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

=C2=A0 Please be specific.

=C2=A0 Alan DeKok.


--001a1143835aac1fa5055e1a3fd2-- From nobody Sun Nov 19 15:20:41 2017 Return-Path: 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 647E71200C1; Sun, 19 Nov 2017 15:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lRdfAJj2oGNW; Sun, 19 Nov 2017 15:20:37 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 9CA3312009C; Sun, 19 Nov 2017 15:20:37 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id o145so4583719vkd.0; Sun, 19 Nov 2017 15:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uy6Aqva3JGxqjO/+FMOghJIh+UYx2DP6JK/A733C4XE=; b=KUmziprSGpqdmzACtInWbkgdLxxzlNjkMlzh7M/ssb81NBTsB2IPUdQ8qzrS+Q3BpD WW3j4v+xGsZ/GewiugDs1NSj9Zw/eSZ0FQfpSLP37MKuv+8w/TmYMYmOtS+lPQ/4QYUn qWaSwQMnZY0vS945W/dpM5jMZdHPrp64afvj8wJa9cD3sKt8OpHmBL7akupjyHPUfy5q SeVatxXHlwHhSkcYSHYZL5zpbg6/D5IjQLK6EBjLowj3fQZdwKIxL7JYC75/+IhXY5If WzTAsfEv5zUNLrKqeA7RIqmhdjbVdFxjvMLPnUVZ+LkDwfayfvPzFIWvzDgYe0BhZHgL 5ppw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uy6Aqva3JGxqjO/+FMOghJIh+UYx2DP6JK/A733C4XE=; b=C0t764zlQLP1rfZqxWQmg3HGgccKEZK6zGiykfkJ8oKseJG46jEihtFoT/t3IczXaV PMkbapEge38PC/c4t93XkcPjuZmOuCYeYQaGjtPb524/soviTP2JRhI2G2WqxAwNArCi fiiCFv1B9s8QQ/jl6+2BHyK8F4SS0OQu2i6VnmpPJNbDzk8FRYpEy22TKdWJj+sVzz+m UekIbnHCJjPfCbO6dLnqoeyTZWeYlfumg+H8F2fM4kWzJz6Zk7hIGzh4fJeSxbMdYLNR 432VzqeJS5q3xB5RUUH9ljtIIUcZoqEeLEMuFewv5eUIniTFwz/7SxRJmJOTg4aUd8Hz 2FwQ== X-Gm-Message-State: AJaThX5o04XpzW9O6YIwIOYgVyUyxiXJcPC/DH3ej1LrriZVfbyvkFEB dGXNFvVw0xBhAw6T/4SBLzeU1FgnBuBZyFZVj0Q= X-Google-Smtp-Source: AGs4zMYDN8CLqHBhN2b+jK77nZrQaVYp4Zr16ay6QCdtcJNEqq/V2aw5fFxGpKdtqddg47ntC7RH1B+qFdnuP26No8s= X-Received: by 10.31.178.205 with SMTP id b196mr5017052vkf.85.1511133635860; Sun, 19 Nov 2017 15:20:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.230 with HTTP; Sun, 19 Nov 2017 15:20:15 -0800 (PST) In-Reply-To: <58815EFC-3CF9-4F62-A7E3-6E76FBAA295A@piuha.net> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <58815EFC-3CF9-4F62-A7E3-6E76FBAA295A@piuha.net> From: Bernard Aboba Date: Sun, 19 Nov 2017 15:20:15 -0800 Message-ID: To: Jari Arkko Cc: Mohit Sethi , reap@ietf.org, Security Area Advisory Group , emu@ietf.org Content-Type: multipart/alternative; boundary="001a11440b3492df7d055e5e37b5" Archived-At: Subject: Re: [Emu] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 23:20:39 -0000 --001a11440b3492df7d055e5e37b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The big question is "Why not create a new EAP method"? The overall intent seems to be to create an pre-shared key EAP method optimized for 5G, based on EAP-TLS v1.3. Since the protocol described will not interoperate with any of the existing 2+ billion EAP-TLS devices, why reuse the EAP-TLS code point or EAP-TLS name? What has been described is an entirely distinct authentication method, not a "clarification" to an existing specification. In fact, from how it has been described, it would appear that the new protocol is only for use with new devices supporting 5G and new 5G servers supporting the new method. In which case, if the new method is not for general use on the Internet, why can't 3GPP just define the method themselves and allocate their own private EAP type code? On Thu, Nov 16, 2017 at 4:02 AM, Jari Arkko wrote: > I don=E2=80=99t want to push the decision in either direction without loo= king into > the details. > > But I wanted to point out that there=E2=80=99s usually a third alternativ= e between > =E2=80=9Cno need for new documents=E2=80=9D and =E2=80=9Cneed a new RFC t= o describe the new > version=E2=80=9D. Explaining that the old protocol can be used and what t= he > implications are may by itself be a useful document. In the specific > example, is not immediately obvious to me for instance if the security > consideration would somehow change, or if 0-RTT can or can not be used, e= tc. > > Jari > > --001a11440b3492df7d055e5e37b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The big question is "Why not create a new EAP method&= quot;?=C2=A0

The overall intent seems to be to create an= pre-shared key EAP method optimized for 5G, based on EAP-TLS v1.3.=C2=A0= =C2=A0

Since the protocol described will not inter= operate with any of the existing 2+ billion EAP-TLS devices, why reuse the = EAP-TLS code point or EAP-TLS name?=C2=A0 =C2=A0What has been described is = an entirely distinct authentication method, not a "clarification"= to an existing specification.

In fact, from how i= t has been described, it would appear that the new protocol is only for use= with new devices supporting 5G and new 5G servers supporting the new metho= d.=C2=A0 In which case, if the new method is not for general use on the Int= ernet, why can't 3GPP just define the method themselves and allocate th= eir own private EAP type code?=C2=A0
=
On Thu, Nov 16, 2017 at 4:02 AM, Jari Arkko = <jari.arkko@piuha.net> wrote:
I don=E2=80=99t want to push the decision in either direction withou= t looking into the details.

But I wanted to point out that there=E2=80=99s usually a third alternative = between =E2=80=9Cno need for new documents=E2=80=9D and =E2=80=9Cneed a new= RFC to describe the new version=E2=80=9D. Explaining that the old protocol= can be used and what the implications are may by itself be a useful docume= nt. In the specific example, is not immediately obvious to me for instance = if the security consideration would somehow change, or if 0-RTT can or can = not be used, etc.

Jari


--001a11440b3492df7d055e5e37b5-- From nobody Mon Nov 20 09:02:51 2017 Return-Path: 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 13640129BFC; Mon, 20 Nov 2017 09:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XUHbaMsMAtzW; Mon, 20 Nov 2017 09:02:42 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA7F129C40; Mon, 20 Nov 2017 09:02:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D04E42CD39; Mon, 20 Nov 2017 19:02:31 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxZF0qbCN7lC; Mon, 20 Nov 2017 19:02:31 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 5AAE02CD0D; Mon, 20 Nov 2017 19:02:31 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Mon, 20 Nov 2017 19:02:30 +0200 Cc: Mohit Sethi , Security Area Advisory Group , emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2DE75B43-BB07-4A15-BC81-442DFA0521C4@piuha.net> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <58815EFC-3CF9-4F62-A7E3-6E76FBAA295A@piuha.net> To: Bernard Aboba X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Emu] [Reap] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 17:02:45 -0000 I think it would be perhaps useful to take some sort of reset on this = thread :-) I think there are at least three groups of people talking = past each other, and making assumptions that may not be correct. While this isn=E2=80=99t really a topic that I=E2=80=99m driving, let me = make a first cut at doing that reset. But I may not be correct either, = feel free to suggest a better description of where the world is. But = this is what I am seeing: 1. First, I don=E2=80=99t think I=E2=80=99ve seen any demand for any = special pre-shared key EAP TLS version (from 3GPP or otherwise). =46rom = what I understand, if 3GPP wants to use EAP-TLS, they=E2=80=99d do it = mostly for the certificates. 2. EAP-TLS continues to be important in the world, with lots of = deployment, and potentially more coming down the line. 3. Anything we do should ensure installed base continues to work. 4. Documenting what the implications of using TLS 1.3 in EAP-TLS are = seems useful advice. I don=E2=80=99t know how trivial this is, but at = least there should be some security implications. 5. If there=E2=80=99s any need to profile algorithms or TLS versions or = anything like that for any use case, it should be taken separately. And = perhaps that=E2=80=99s something that any individual deployment can just = do on their own. Jari P.S. I took Kathleen=E2=80=99s advice from earlier in this thread and = start reducing the number of lists this discussion is copied on.