Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-00.txt
John Mattsson <john.mattsson@ericsson.com> Thu, 28 June 2018 09:49 UTC
Return-Path: <john.mattsson@ericsson.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E155130F3F for <emu@ietfa.amsl.com>; Thu, 28 Jun 2018 02:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=fiGzUqIC; dkim=pass (1024-bit key) header.d=ericsson.com header.b=S9wFtN2J
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 AQ8UMAAAkKQx for <emu@ietfa.amsl.com>; Thu, 28 Jun 2018 02:49:26 -0700 (PDT)
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 CF0BA130F46 for <emu@ietf.org>; Thu, 28 Jun 2018 02:49:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530179364; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YLgkqLkgFPL5/Z4GevSmV7CFJUd56fYFyHN0an9w57o=; b=fiGzUqICY9O2BZFCT9Qzw1vteMOQC5YJrQV+HOkdH00mcGmIklXEylyirB6qdoQc uWIGXoe8Dlpj1l76PTrAYIarGOa7nzaoCUvPW+ykPghkokoIw9LAzV375GPzX5EB Be26siCEdTssUv+V01L7JqyjJGTFgEY6DMJGV2pJNQ8=;
X-AuditID: c1b4fb25-202c69c000006310-5c-5b34af24aefb
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 17.15.25360.42FA43B5; Thu, 28 Jun 2018 11:49:24 +0200 (CEST)
Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 28 Jun 2018 11:49:18 +0200
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 28 Jun 2018 11:49:17 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YLgkqLkgFPL5/Z4GevSmV7CFJUd56fYFyHN0an9w57o=; b=S9wFtN2JkApSbYxLIwhI5J87JGlny0t62u2RLWxhFBrCktTnkpROHvmqFy9mFjmLShkiLIQPZu2KHeJSXKkfKEi12AeiFgjVNEnljz2eh+1vm7OSO3Qz1JUCRITYVggS2HoeIZFeZn6noeGLBsfS5ErWMKncH7aGYIkRG+ATbaI=
Received: from AM0PR07MB4388.eurprd07.prod.outlook.com (52.133.61.33) by AM0PR07MB4563.eurprd07.prod.outlook.com (52.135.151.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.23; Thu, 28 Jun 2018 09:49:17 +0000
Received: from AM0PR07MB4388.eurprd07.prod.outlook.com ([fe80::3d7f:2499:58bd:bc4c]) by AM0PR07MB4388.eurprd07.prod.outlook.com ([fe80::3d7f:2499:58bd:bc4c%5]) with mapi id 15.20.0930.005; Thu, 28 Jun 2018 09:49:17 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: "kmalinen@gmail.com" <kmalinen@gmail.com>, "emu@ietf.org" <emu@ietf.org>
Thread-Topic: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-00.txt
Thread-Index: AQHUDsVH6scwNDvSXUOXJNaMt/+NUw==
Date: Thu, 28 Jun 2018 09:49:17 +0000
Message-ID: <8D604363-9C41-4603-98BA-B3D5971D474B@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.c.0.180410
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [82.214.50.105]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4563; 7:hQZSGt+9kNn2JFSOKoIcCkpW4Y05D0mr2OjQTIC+1wR4o1QPwdSgh5F8I1edXK06g9ZhSFeaFPEMNOnzdRPzJ55m4e1oQQqTcqQdeRFFhKgumqbPAQtbQf9SDQsNLmxmDuSFKdc4ybH1lYqO4HaEMJ4xw8YljCqg9n+I0BHfyAWlmPY9B7tK/xrgH4CQJSkdjPsbUqrmptXZ381M+VLDNkiNf457o2KlUHnzxjCMzFyNH+knCeUPiWjn+IPJuL9w
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 8c760f89-d39f-4267-200a-08d5dcdc6a0a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB4563;
x-ms-traffictypediagnostic: AM0PR07MB4563:
x-microsoft-antispam-prvs: <AM0PR07MB4563A145D482F9FE5214FF2D894F0@AM0PR07MB4563.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM0PR07MB4563; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4563;
x-forefront-prvs: 0717E25089
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(376002)(136003)(346002)(189003)(52314003)(199004)(6246003)(6512007)(229853002)(6306002)(39060400002)(26005)(2906002)(6486002)(58126008)(25786009)(316002)(5250100002)(110136005)(68736007)(102836004)(6506007)(66066001)(53936002)(15650500001)(99286004)(36756003)(2501003)(186003)(44832011)(106356001)(966005)(33656002)(105586002)(81166006)(82746002)(83716003)(486006)(14454004)(2900100001)(2616005)(86362001)(3846002)(6116002)(476003)(256004)(14444005)(97736004)(8936002)(305945005)(6436002)(7736002)(81156014)(5660300001)(8676002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4563; H:AM0PR07MB4388.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: rByFKhTq2XVNt52qIN3DUOcK0ZNBRzu7w6RJoUoaIdW1L77/5UDU/TbMJpJaY8QiykPE9GQAMVm86o63plHZH2dqAgdr8yC0lCagXkfmPALE6L89V3ZeBzUhFgaBq2FF4GlimSk5GpkhwCqHbS2+/BNf8QHUNdShSE5RScpmq1mn2OJ6XZrvyrHj/ttyhrmwJlRG9HzvzHZKHE+MI6l/3zCNpzQnMB4fBZT4jtTZN+zPFED2T5F6pr5FTVZDnuG+jr2EYu80Jc6aHQT6cXF3INS0ljX7n/uOObx+owxh6wCCOVeoEQ2ySzKQ0uKnqisc601ROVyS4yrhuvarp/fBugSK+H7P0y1mZ+YVsFlUUEI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <D6A6F5BBE1CAED4EA61B43908A2F70CE@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c760f89-d39f-4267-200a-08d5dcdc6a0a
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2018 09:49:17.1516 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4563
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe+69266j1dNSd7CMGgolTE2NjKIUIfYhSe1LaFIzL7qcU7Zp 6pfMl5SppOJWG/mWy3L4Ero0h46cLahIxXwJSWIlReYHezFZQrW7u6Bvv3PO/5z/OQ8PTYob eCG0Uq1jNGqFSsoXUqbzI1dlYQNxGdGzLkH8s4E+Kn6+rUWQQMhHzcsCucXiIVKIdOGJbEal LGY0UScvCXNNNaP8wm+JJVbPMFGObifoUQANOA4WOt0CPRLSYuxCULF4h+SCnwie3nNSrEqM LQS86abYAoUbSfjosPhbmggw/jEjLniPYObXCI9t4eNoaB0r5+sRTQfiM9B/U87ibpwKU3Nq VhGI02BovIbiOBI2eucQyxQOhx/GKl9ehE+Bx9pNsIxwMGy+6PUxiSWwtNJOcCdgsIxNkxwH wecPv3msVZB3ZvMTHdeaCdXVt3ic5ACsmboQx6Ew217n2x6wjYD5Do+/IIN1g8E/MxmGjY94 nGgGwQ1HhYA1ABwBD9aCOU0eGBb1foPj0LO67ud9YG1wUxw7SFibOMbxXrC/nRY0omjzf+eY vVNJfAgG7FFcWg7G1SrE8QFoqXMLzL5X2QXPTStUB+JZUZCW0Wbl58TERjIa5WWttkAdqWZ0 g8j7SSZsW+GP0eu1RCfCNJJuF6W3xmWIeYpibWm+EwFNSgNF+5O8KVG2orSM0RRc1BSpGK0T 7aEpqUTkPjqULsY5Ch2TxzCFjOZflaADQspRqVXlCJWExy7dvRKkrKdispJEYotssvZLf/KG QVaZlvMu02aJSa181bnDZRzZ0jl50pl6SexZ3fo2qSIzc/p7W+r1vmpyXDTbk9IcYp/KqrEu HBkMWz5X2ZDX/vWCpyTfdfrawa1PCeFl810PbUU7LU0vJ2uVtGDLHjHUunlfSmlzFYcjSI1W 8RcJghpEIAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk>
Subject: Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-00.txt
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2018 09:49:30 -0000
John: Thanks Jouni, very good comments. Great to get feedback from implementation. I think there is a slight mismatch between the assumptions in TLS and EAP, in TLS the connection is assumed to stay open for a long time after the client sends Finished, in EAP the connection is assumed to be closed shortly after. > Based on implementation experiment of this (or well, the previous draft, so > with the old labels), the most inconvenient part of this design was the way > the session resumption is handled in TLS v1.3. When that is mapped to > EAP-TLS in the way it is in this draft, the peer has no idea whether the > NewSessionTicket is delivered after ClientFinished. In other words, the > next message in the sequence could be either continuation of EAP-TLS method > or EAP-Success. This means that the peer cannot use methodState=DONE, > decision=UNCOND_SUCC per RFC 4137 state machine whenever using TLS v1.3 > (while being able to continue to use that combination with TLS v1.0, v1.1, > and v1.2). Instead, for TLS v1.3, methodState=MAY_CONT, decision=COND_SUCC > needs to be used. While this may not sound very critical, it was a bit > inconvenient to have make that behavior conditional on the TLS version. John: In general, a TLS 1.3 server could send several NewSessionTicket before sending EAP-Success. Theoretically, the Peer and Server may also exchange other Post-Handshake Messages (Section 4.6 in TLS 1.3) after the main handshake but before the EAP-Success. One option would to restrict EAP-TLS to a subset of TLS, but that could also make it incompatible with future extensions. Based on your comments, the draft may need to specify which Post-Handshake messages that can be sent in EAP-TLS. > Would there be any way of avoiding this uncertainty about the next message > on the client side within the EAP-TLS method itself? John: EAP-TLS Request and Response packets have a byte called ‘Flags’ with 5 reserved bits that could be used if it helps. Flags 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ |L M S R R R R R| +-+-+-+-+-+-+-+-+ One of the bits could be used to signal information from the EAP Server to the EAP Peer. But I think the meaning of the bit would need some analysis in that case, I am not certain that the TLS server knows whether it will send more EAP-Requests before receiving the Finished message from the TLS client. Another question is how much information the EAP-TLS layer gets from the TLS layer. > If not, I might as > well as bring up another comment regarding the extra round trip from this > NewSessionTicket delivery. That does not look very efficient. If we would > not care about layering between the EAP method and EAP peer/server > implementation, NewSessionTicket could actually be piggybacked on top of > the EAP-Success message.. Sure, that would require a change in the > EAP-Success definition, but this would remove this undesired uncertainty > about the next message in the sequence and would get rid of one extra > roundtrip in the exchange which could be a significant reduction in overall > latency for the handshake. John: Interesting suggestion, I think reducing latency is certainly worthwhile, but as you say it would require an update to RFC 3748. I think this is something we should discuss on the list and in Montreal. > Having to change the MSK/EMSK derivation just for the sake of getting a new > label string into use based on the TLS version is also a bit inconvenient. > This is obviously assuming that the previous implementation was already > using TLS-Exporter interface. In general, it would have been nicer if > existing EAP-TLS implementations would work simply by updating the TLS > implementation from v1.2 to v1.3. John: Good comments. The main goal is to exactly define how to derive the keys when using TLS 1.3. The key derivation has been causing interoperability problems for EAP-TLS. Let's discuss what the best tradeoff is based on implementation convinient, what the API is supposed to be between TLS and EAP-TLS, and security. As far as I can see the derivation of Key_Material in RFC 5216 is compatible with the Exporter interface defined in RFC 5705. A definition like: Key_Material = TLS-Exporter("client EAP encryption", null, 128) could potentially work for all versions of TLS and be compatible with RFC 5216. This definition would use the master_secret for TLS 1.0 -- TLS 1.2 and the exporter_master_secret for TLS 1.3. The Session-ID definition could potentially stay the same, i.e. the EAP Peer and EAP Server reads 32 bytes at TLS_Data[6] to get the random numbers. The derivation of the IV in RFC 5216 is however not compatible with the TLS-Exporter interface (as far as I see) as it uses the PRF with an empty key. What API are we assuming between EAP-TLS and TLS? To use the PRF directly, EAP-TLS needs to be aware of both the TLS version and the negotiated PRF. Not using a standardized API could definitely lead to combability problems in the future. E.g. if someone standardizes something like https://tools.ietf.org/html/draft-rescorla-tls-extended-random While public IVs used to be the norm, deriving a secret IV is now becoming the default (TLS 1.3, QUIC, OSCORE) > Anyway, if any one of these change is > going to be needed in the end, the EAP method implementation will need to > be made aware of the negotiated TLS version and other changes are coming > with somewhat reduced implementation complexity. John: Your earlier comments seem to indicate the EAP-TLS needs to be aware of the negotiated TLS version to handle the quite different message flows. And if the EAP-TLS implementation knows the TLS version, the key derivation could be updated as well. If the EAP-TLS implementation does not need to be aware of the TLS version to handle the different message flows, then other tradeoffs might be better. Based on this discussion I think it would be good to agree and write down the assumptions on how the interface between TLS and EAP-TLS is supposed to look like. Cheers, John
- Re: [Emu] New Version Notification for draft-ietf… John Mattsson
- Re: [Emu] New Version Notification for draft-ietf… John Mattsson
- Re: [Emu] New Version Notification for draft-ietf… Jouni Malinen