Re: [Reap] EAP - TLS 1.3

John Mattsson <john.mattsson@ericsson.com> Fri, 01 December 2017 13:16 UTC

Return-Path: <john.mattsson@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 15148128D3E; Fri, 1 Dec 2017 05:16:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 Gezm9FO531xq; Fri, 1 Dec 2017 05:16:42 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 21A73128BBB; Fri, 1 Dec 2017 05:16:40 -0800 (PST)
X-AuditID: c1b4fb2d-d6fff700000036aa-81-5a215637fa56
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3E.C0.13994.736512A5; Fri, 1 Dec 2017 14:16:39 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 14:16:38 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QZKEGlploxq4ldQ3gS//CLtOcYnaMEnFYmCtDqx/xO8=; b=Uuj1hAvHSpDI9aC2A/EAqubD2PRmk+V0AxFlB2Ufn59SJqeY23ylLxx+DCVCNL7quQ0Aljv83gZLtmFp/sR2m5P1irIhWN9uPSTFQOyhMBhIrSYFjrkZikEIRhuNJwUoRuGhZG+LaPjYA0RgxhT2YpKMCyKYwJum7mumL/peK/A=
Received: from DB5PR0701MB2005.eurprd07.prod.outlook.com (10.167.228.147) by DB5PR0701MB2005.eurprd07.prod.outlook.com (10.167.228.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 13:16:37 +0000
Received: from DB5PR0701MB2005.eurprd07.prod.outlook.com ([fe80::cded:d65b:8eb2:a1bd]) by DB5PR0701MB2005.eurprd07.prod.outlook.com ([fe80::cded:d65b:8eb2:a1bd%14]) with mapi id 15.20.0282.006; Fri, 1 Dec 2017 13:16:37 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: "aland@deployingradius.com" <aland@deployingradius.com>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, Bernard Aboba <bernard.aboba@gmail.com>, "Jim Schaad" <ietf@augustcellars.com>, "reap@ietf.org" <reap@ietf.org>, "saag@ietf.org" <saag@ietf.org>, "emu@ietf.org" <emu@ietf.org>
Thread-Topic: [Reap] EAP - TLS 1.3
Thread-Index: AQHTaqadALXEaMxOiE21NMZBzoSXMg==
Date: Fri, 1 Dec 2017 13:16:36 +0000
Message-ID: <CA2994E1-C8EE-4F4D-9838-C832B910EFC7@ericsson.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.28.0.171108
x-originating-ip: [82.214.47.185]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR0701MB2005; 6:rTJCAuBmtvGfpDlfojfITW33vvYS6Nkgx6K+IlXtAICXvrxrJCM45/L8elTun3eeMyo+wATbs610LEckD9zJQ5QtsCoVZPwDafpSFyzGLFjcMhkl8rOKLhqywXJcQB7NEaWymUpAIGePRIB0YdIzLko3CMtjEWN5OYkinUBOwQn0lC83AxYiP2kxCNbJMYBwMG/AuDWpRxCOtDKHOMFUzbqE/JhA29+a4VcQeQwb3l8DTJeijeZke1gNU9nl7z4IyGT5199RpMUhvrci3jJTQy+vUASP7BhSez3fU/Da4IAnxgEY/43B93CAnA66soiF/W3IwM5uWw0rS6OqfKWXl0IMPqBzFSw9zBviTQIE3rw=; 5:vrdpHJAng3tzT4jCrlzK7Cq0UkzPXaZLJNDN6A3BYUfaj7e2xz1hMBuI0uiphbVQmnEuoqAeN2O6rgBocrYQLs/pCkGqqydUwU2SkYzt+/m6uBWwb7wqpGlEPvBAmseQncKkU/e7R0axOWRWI10fYy+aYRPCa0gNQr9iuX4gvZg=; 24:1GRIbeILISUZPx05HhT1MVZPv4gvdFEoKN0170oBAGpRzIb1U3KbKB6XPkRDwu2dBVEZb3SfybwnmJWMEJBm3o02dQJnS663yn53HNIoaA8=; 7:SxpDMqfA864rApIaRyf/EhzVr/lnTMt6LN1zLzufIM1+Fix8nuLs+Z5tgdyivkqkfbnayZbYFqQ+1/TsPBT/DklUOQMF9jhW27Y6qMW6wBxbNn/K1IGRII5SIOp/78UN3q1Sp9V7N6QWNjtcMzp7o40wqg8yTl8AAdh9Fc7E41t2LXMu3nbKF3rtM0kWxH4mOETo0LELDaL+MaI1qpuUcQuHbrBgGCPiFu8VdEkpAUkc+py34faORafZWzas5JmT
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 27115dd0-9085-42e6-b432-08d538bdc064
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:DB5PR0701MB2005;
x-ms-traffictypediagnostic: DB5PR0701MB2005:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-microsoft-antispam-prvs: <DB5PR0701MB20054AFBA6C0563D72D909B589390@DB5PR0701MB2005.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231022)(10201501046)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011); SRVR:DB5PR0701MB2005; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB5PR0701MB2005;
x-forefront-prvs: 05087F0C24
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(366004)(346002)(189002)(199003)(24454002)(2501003)(316002)(110136005)(5660300001)(66066001)(83506002)(2906002)(36756003)(5250100002)(229853002)(25786009)(86362001)(58126008)(6436002)(81166006)(6506006)(8676002)(6486002)(105586002)(81156014)(53936002)(102836003)(97736004)(82746002)(2201001)(478600001)(2900100001)(3846002)(3660700001)(106356001)(6116002)(561944003)(99286004)(8936002)(83716003)(33656002)(14454004)(189998001)(3280700002)(68736007)(54356011)(305945005)(39060400002)(7736002)(6246003)(101416001)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR0701MB2005; H:DB5PR0701MB2005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <4DDF76905BFF5F409B7709A38BAE9C0E@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 27115dd0-9085-42e6-b432-08d538bdc064
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 13:16:36.9811 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0701MB2005
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SWUwTURiFvZ3pdGhscilF/iCYtPFBkM0lWo0RfTApYrW+qCEhUmECKFs6 lYBPTQFFFqGCIoVSNQVZZA2ILCKibBolYgwGkD0StrhgQmS17dTEt++ec/4/595cmhA38N3p 6Dgto4lTx8goIVl4qfm87+EL0pCAvimxXL+sF8jrOrYIeU9tNSmvKlih5B8qekl5fs5t3glK UV9cQClSu1NJRYvxq0BhsfzhqcgQ4bEIJiY6kdH4Hw8TRqXUjVEJZcqk9OFSQofKgzOQEw34 IOR8/E5kICEtxq8RmLMe8bhDLwL93ChpO5A4m4CWlA4B55h4MGv45Zj5hsCQ3ci3LaNwAJja dZTNkOASHnzZKhfYDBcshQef5ykbS7AMJlLWEcd+oK8f5NmYxLvhjnnVziIcCCUjRnse4R2w 8vapXSewG+h/V/C55hgs7QMEx64wN71p112tOzdbFnicLoXS7vuOvCcMmjORrRzgNwIYHxp1 GH7QZFhCHCuhZrmW5EJlCF5mTJKc4QN9pveORqGQllbgGI6H9o4aRyYIusYyCG7YQsCAaYji DA8Yan3h2DrDh5tNs/Z+YszAk+o0lIt8jf9dz4hoK3tBbas/JytgKeUxn2Mp5GdOCoz2V3KG /sIZ8iHiVyJXlmHZ2Mj9B/wYTXQ4y8bH+cUx2gZk/UmvGtd8n6OqhZNdCNNItl1UoZKGiPnq RDY5tgsBTcgkotCzVkkUoU6+wWjiL2uuxzBsF9pJkzI3UX+QKESMI9Va5hrDJDCafy6PdnLX Iefmc52q8bDByKt7Ww1320QttzZmB8cX8opHgn36j74by6rKa9R3mr3SD9WH9lickxuYDqVk 4+Janj53yq2oL3t6Ln74SGWAKsmzLSC8ik738N/wTlj9qVtXbpPUFwWemn925czSPQKbdDKX cK1Uvyj5cZpZq/m0y1hmztmzOCEj2Sj1Pm9Cw6r/AmnbLXxFAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/reap/-pxpcQJXlu4O88dh5mOAhmJ4ktw>
Subject: Re: [Reap] EAP - TLS 1.3
X-BeenThere: reap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "REAP \(RENEW\) EAP" <reap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/reap>, <mailto:reap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/reap/>
List-Post: <mailto:reap@ietf.org>
List-Help: <mailto:reap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/reap>, <mailto:reap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Dec 2017 13:16:45 -0000

Thanks for your comments Alan. Very helpful. See answers and comments below:

On Nov 16, 2017, Alan DeKok wrote:

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

I don’t agree with that, see concrete details below.


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

If RFC5216 actually said that it would be less of a problem, but RFC5216 has a large amount of normative terminology that is correct for TLS 1.0 - 1.2, but wrong for TLS 1.3. Just looking quickly at the base case in RFC5216 (Section 2.1.1.):

"until the change_cipher_spec message"
(In TLS 1.3 change_cipher_spec is an optinal dummy record only used for Middlebox compatibility).

"a server_hello_done handshake message MUST be the last handshake message encapsulated in this EAP-Request packet."
(server_hello_done is used in TLS 1.3).

"a TLS server_key_exchange handshake message MUST also be included"
(server_key_exchange is used in TLS 1.3).

"MUST encapsulate one or more TLS records containing a TLS client_key_exchange, change_cipher_spec"
(client_key_exchange is used in TLS 1.3).

"the peer MUST send only the change_cipher_spec"
(see above)

EAP-TLS with TLS 1.3 would break a _large_ amount of MUST in RFC5216.


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

While the message flows are exactly the same in TLS 1.0, TLS 1.1, and TLS 1.2

     ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished

The message flow and its content is completely different in TLS 1.3

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*         -------->
                                                       ServerHello  ^ Key
                                                      + key_share*  | Exch
                                                 + pre_shared_key*  v
                                             {EncryptedExtensions}  ^  Server
                                             {CertificateRequest*}  v  Params
                                                    {Certificate*}  ^
                                              {CertificateVerify*}  | Auth
                                                        {Finished}  v
                                 <--------     [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}                -------->

(I agree with Bernand than developers would likely get the message flows right, however such an implementation would break a _large_ number of MUST in RFC5216 (see above). I also think it would be good to give people wanting to use EAP-TLS how many roundtrips they can expect with TLS 1.3 (in general one less that with TLS 1.0 - 1.2).

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

Yes, procedural aspects seem to be a large concern, but “obsolete” does not forbid anyone from using EAP-TLS with TLS 1.0. E.g. TLS 1.3 obsoletes TLS 1.2, which obsoletes TLS 1.1 etc. but that does not mean that people are forbidden to use TLS 1.2. If fact TLS provides a versioning mechanism and the TLS working group is even planning TLS 1.2 Long-term support. That said, I am perfectly fine with “update” if that is what the mailing list wants, I will change "obsolete" to "update" in the -01 version, and make it clear that in the text that the update is still compatible with RFC5216 using TLS 1.0.


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

RFC5216, Section 2.5 defines that MSK, EMSK, and IV is derived with the TLS-PRF, which is the right way to do it in TLS 1.0, TLS 1.1, TLS 1.2. TLS 1.3 replaces the PRF with HKDF, thus requiring a new construction. How would someone trying to implement TLS 1.3 with RFC5216 derive the keys?

1. Follow RFC5216 and use the old TLS-PRF to derive MSK, EMSK, IV?

  Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
                     client.random || server.random)
                     
This would mean that the EAP-TLS code would have to implement the TLS-PRF, the TLS library would also need to be modified to enable extraction of master_secret, client.random, and server.random. That seems like a very bad solution.

Also would such an implementation use the TLS 1.2 or TLS 1.1 PRF?

2. Try to guess how to do something similar with the TLS HKDF construction

  Key_Material = Derive-Secret(Master Secret, "client EAP encryption", client.random || server.random)

3. Or equally likely replace ClientHello.random + ServerHello.random with ClientHello...server Finished as done in all key derivation in TLS 1.3    

  Key_Material = Derive-Secret(Master Secret, "client EAP encryption", ClientHello...server Finished)

4. Or do it the natural way in TLS 1.3 (Used in e.g. draft-ietf-quic-tls) 

  Key_Material = TLS-Exporter("client EAP encryption", "", 128)

I think this is extremely likely to lead to incompatible implementations of EAP-TLS with TLS 1.3 unless IETF gives guidance. My view is that a document is needed stating how the key derivation is done when EAP-TLS is used with TLS 1.3, my proposal would be:

  Key_Material = TLS-Exporter("client EAP encryption", "", 128)


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

I hope that the details above illustrate why I think an short document describing how to use EAP-TLS with TLS 1.3 is needed. I will update the document aligning with the comments received:

- "update" instead of "obsolete" and also making clear that an implamentation following the document is still compatible with EAP-TLS with TLS 1.0 (up to the application to decide). This means that the EAP-TLS with TLS 1.3 document can be shorter totally avoiding overlap with RFC5216, only describing any difference when usign TLS 1.3.

- Highlight which parts relevant for EAP-TLS that changes in TLS 1.3 and why an update is needed.

- Add information on how Key_Material and IV is derived when using EAP-TLS with TLS 1.3. Refering to RFC5216 for to get MSK, EMSK, etc, from Keying_Material.

Cheers,
John