From nobody Tue Jan 9 05:46:50 2018 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 404F412D851 for ; Tue, 9 Jan 2018 05:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 Yf_YA6qc9HOv for ; Tue, 9 Jan 2018 05:46:46 -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 49F8612D861 for ; Tue, 9 Jan 2018 05:46:45 -0800 (PST) X-AuditID: c1b4fb25-473ff7000000341b-4a-5a54c7c30d0f Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E8.0B.13339.3C7C45A5; Tue, 9 Jan 2018 14:46:43 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 9 Jan 2018 14:46:43 +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=vZhgCxBpqWelK+Po6Ki6kGwClBgfYLgEtuY1mGsLC74=; b=Fqh1H9z2dJdiOQgbp3R3W7lokgJAc+5Wm5a3UaMpNAQYghVGBqaz4XujU9aXS8fSXonv0oORUnMWlUNEybn+AiNLzzD29IRF/e7Ou6Rt2YLGqiT9ezPFc7vjeuG+QpW/+4G+OcjJmg8tp7bwds2TCrvWlqvb1Ybg6WrZOtzr25U= Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com (10.167.189.149) by HE1PR0701MB2745.eurprd07.prod.outlook.com (10.168.188.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.1; Tue, 9 Jan 2018 13:46:41 +0000 Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::b8af:635a:701a:fa6f]) by HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::b8af:635a:701a:fa6f%13]) with mapi id 15.20.0407.005; Tue, 9 Jan 2018 13:46:41 +0000 From: John Mattsson To: "emu@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-eap-tls13-01.txt Thread-Index: AQHTiUv/x7iDQ4Wq/k29zYlQDPBcKKNrnreA Date: Tue, 9 Jan 2018 13:46:41 +0000 Message-ID: References: <151550369667.9592.15640677591631889787.idtracker@ietfa.amsl.com> In-Reply-To: <151550369667.9592.15640677591631889787.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.29.0.171205 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2745; 7:pjuCyTNmZCOvGSTDaNNoNSOScKYvK3GrbKAxTaapOQwNA9ugtkkNcFcDfx4kkZoCQfOO1M9+2LDO7qtJe9di0lwIYlWmT83/afQvq2kiwOEc8Qfl64s7MtNZc30d9Ednq+QtESyr26fzhqIhLeZor90pjO/qLPS88PDq0W0i6VO22XQfugwoGOIUd2BO810cJmgqEPTaGxfytM3C9ZPK5QfZMCGarnYyXr5pPpWbEEIsc7erOb9n+7R/F5sL168C x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cf8fdcda-a969-4b1d-c3cd-08d557676a42 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0701MB2745; x-ms-traffictypediagnostic: HE1PR0701MB2745: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(944501075)(10201501046)(6041268)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR0701MB2745; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB2745; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(376002)(39860400002)(366004)(346002)(377424004)(199004)(189003)(24454002)(3846002)(6506007)(6116002)(53936002)(97736004)(36756003)(83506002)(102836004)(68736007)(3660700001)(82746002)(59450400001)(99286004)(229853002)(230783001)(53546011)(83716003)(5640700003)(76176011)(6436002)(6486002)(86362001)(2906002)(2473003)(33656002)(7736002)(305945005)(6512007)(14454004)(5660300001)(8936002)(2950100002)(966005)(66066001)(15650500001)(81166006)(106356001)(1730700003)(81156014)(5250100002)(8676002)(2900100001)(105586002)(2501003)(316002)(6306002)(6916009)(2351001)(478600001)(25786009)(58126008)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2745; H:HE1PR0701MB2011.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: xaQuqt6azyLIa0oGgtnxA0KZeeL9t0hsLrIGzhqU1TdP7UAtH3KdNsEEeTuL74gy/N+D5WtfEJBOMwAiKipUrQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cf8fdcda-a969-4b1d-c3cd-08d557676a42 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 13:46:41.7551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2745 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42KZGbFdQvfw8ZAog+tTZC2OrV/L4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ5lK5kL/shW3L9xhqWBcYZsFyMnh4SAicSLiz3sXYxcHEIC hxkltm65yQjhHGeUaD/9jhnEYRHoZZaYvKiHCSIzl0ni+qOXrBDOM0aJP08OMIMMYxMwkJi7 p4ENxBYRUJT4cakNLC4s4Cmx5uAGFoi4l8TLydegaowkeh49AZrKAbRCReLwgiSQMK+AvcSf ts1gJUICvhK7Hp5mBSnhFPCT6HsdAhJmFBCT+H5qDROIzSwgLtH0ZSUrxDsCEkv2nGeGsEUl Xj7+BxYXFdCTeHHmGjtEb6xEa+t0qHoFiWMzVrJA2LISl+Z3g30vIbCNSeLr4mdQRXoSWye+ ZYSwfSUmX/4LVXSQUeJk5zmobh2J+cemsUPY+RKvjt+EavCR6N+1iB2iYT2zxJp3/5ggEjIS T3Z2s09gNJiF5ItZQI8yC2hKrN+lDxH2kDjf8Z0JwlaUmNL9kH0WOIwEJU7OfMKygJF1FaNo cWpxUm66kbFealFmcnFxfp5eXmrJJkZg6ji45bfqDsbLbxwPMQpwMCrx8J7eHBIlxJpYVlyZ e4hRgoNZSYTXd35wlBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC6YklqdmpqQWpRTBZ Jg5OqQZGx83/pod+Fev70Cj98/AHk7o3UyNCKnWua7P0rOP3W3FoR8nVA8u8FV1jDx2sL+j+ q/Dj3zbR5yrKH9J0D5i/bztsmcvqHap5z9//qRb7LMuV9V08+odSzl5I/tIuuOXak/27pFbO 31/gEaT/5FVq7ekmo/hPk7xLyjdf9I+/dZVBLPC+mVCVEktxRqKhFnNRcSIAivbdOBkDAAA= Archived-At: Subject: [Emu] FW: New Version Notification for draft-mattsson-eap-tls13-01.txt 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: Tue, 09 Jan 2018 13:46:49 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1tYXR0 c3Nvbi1lYXAtdGxzMTMuIFRoZSBuZXcgdmVyc2lvbiBpcyBhIHNpZ25pZmljYW50IHVwZGF0ZSBi YXNlZCBvbiB0aGUgZmVlZGJhY2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBFQVAgYW5kIEVNVSBtYWls aW5nIGxpc3RzLiBUaGUgbmV3IHZlcnNpb24gYWxzbyBmaWxscyBpbiBhbGwgdGhlIHNlY3Rpb25z IHRoYXQgd2FzIFREQiBpbiB0aGUgLTAwIHZlcnNpb24uDQoNCi0gVGhlIGRyYWZ0IG5vdyB1cGRh dGVzIHZlcnNpb24gdXBkYXRlcyBSRkM1MjE2IChpbnN0ZWFkIG9mIG9ic29sZXRpbmcpIGFuZCBh bGwgdGV4dCBoYXZlIGJlZW4gdXBkYXRlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgdXBkYXRlIHN0 YXlzIGNvbXBhdGlibGUgd2l0aCBhbGwgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIEVBUC1U TFMuDQoNCi0gQWRkZWQgbW9yZSB0ZXh0IG9uIHdoYXQgVExTIDEuMyBjaGFuZ2VzIGFuZCB3aHkg YW4gdXBkYXRlIHRvIFJGQzUyMTYgaXMgbmVlZGVkLg0KDQotIEFzIHRoaXMgaXMgbm93IGFuIHVw ZGF0ZSwgYWxsIGR1cGxpY2F0ZWQgdGV4dCBpcyByZW1vdmVkLCBhbmQgdGhlIGRyYWZ0IG9ubHkg ZGVzY3JpYmUgdGhlIGNoYW5nZXMgdG8gbWVzc2FnZSBmbG93LCBtZXNzYWdlcywga2V5IGRlcml2 YXRpb24sIHByaXZhY3ksIGV0Yy4gd2hlbiBUTFMgMS4zIGlzIHVzZWQuIFRoZSBuZXcgZHJhZnQg Zm9sbG93cyB0aGUgc3RydWN0dXJlIG9mIFJGQzUyMTYgYW5kIGxpc3RzIHVwZGF0ZXMgKGlmIGFu eSkgdG8gZWFjaCBzZWN0aW9uLg0KDQotIENsZWFybHkgc3RhdGVkIHRoYXQgUFNLIGF1dGhlbnRp Y2F0aW9uIFNIQUxMIG5vdCBiZSB1c2VkIChleGNlcHQgZm9yIHJlc3VtcHRpb24pLg0KDQotIER1 ZSB0byB0aGUgZW5jcnlwdGVkIGhhbmRzaGFrZSBpbiBUTFMgMS4zIHRoZXJlIGlzIG5vIGxvbmdl ciBhbnkgbmVlZCBmb3IgdGhlIEVBUCBjbGllbnQgdG8gc2VuZCBhbmQgZW1wdHkgY2VydGlmaWNh dGUgbGlzdC4gQSBwcml2YWN5IHNlY3Rpb24gaGFzIGJlZW4gYWRkZWQgdGhhdCBleHBsYWlucyB0 aGlzLg0KDQotIEEga2V5IGhpZXJhcmNoeSBzZWN0aW9uIGhhcyBiZWVuIGFkZGVkIHNwZWNpZnlp bmcgdGhhdCB3aGVuIFRMUyAxLjMgaXMgdXNlZCB0aGVuIEtleV9NYXRlcmlhbCwgSVYsIGFuZCBT ZXNzaW9uLUlkIFNIQUxMIGJlIGRlcml2ZWQgZnJvbSB0aGUgZXhwb3J0ZXJfbWFzdGVyX3NlY3Jl dCB1c2luZyB0aGUgVExTIGV4cG9ydGVyIGludGVyZmFjZS4NCg0KQ29tbWVudHMgYXBwcmVjaWF0 ZWQuDQoNCkNoZWVycywNCkpvaG4NCiANCk9uIDIwMTgtMDEtMDksIDE0OjE2LCAiaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KICAg IA0KICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXR0c3Nvbi1lYXAtdGxzMTMtMDEu dHh0DQogICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIE1hdHRzc29u IGFuZCBwb3N0ZWQgdG8gdGhlDQogICAgSUVURiByZXBvc2l0b3J5Lg0KICAgIA0KICAgIE5hbWU6 CQlkcmFmdC1tYXR0c3Nvbi1lYXAtdGxzMTMNCiAgICBSZXZpc2lvbjoJMDENCiAgICBUaXRsZToJ CVVzaW5nIEVBUC1UTFMgd2l0aCBUTFMgMS4zDQogICAgRG9jdW1lbnQgZGF0ZToJMjAxOC0wMS0w OA0KICAgIEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAgUGFnZXM6CQkxNQ0KICAg IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbWF0dHNzb24tZWFwLXRsczEzLTAxLnR4dA0KICAgIFN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYXR0c3Nvbi1lYXAtdGxzMTMvDQogICAg SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nv bi1lYXAtdGxzMTMtMDENCiAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tYXR0c3Nvbi1lYXAtdGxzMTMtMDENCiAgICBEaWZmOiAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1hdHRzc29u LWVhcC10bHMxMy0wMQ0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIHRoZSB1c2Ugb2YgRUFQLVRMUyB3aXRoIFRMUyAxLjMgd2hpbGUNCiAgICAgICBy ZW1haW5pbmcgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlv bnMgb2YgRUFQLQ0KICAgICAgIFRMUy4gIFRMUyAxLjMgcHJvdmlkZXMgc2lnbmlmaWNhbnRseSBp bXByb3ZlZCBzZWN1cml0eSwgcHJpdmFjeSwgYW5kDQogICAgICAgcmVkdWNlZCBsYXRlbmN5IHdo ZW4gY29tcGFyZWQgdG8gZWFybGllciB2ZXJzaW9ucyBvZiBUTFMuDQogICAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N CiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQogICAgDQog ICAgDQoNCg== From nobody Wed Jan 10 13:18:11 2018 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 E64F012D950 for ; Wed, 10 Jan 2018 13:18:09 -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 RfA1cZ8GS96N for ; Wed, 10 Jan 2018 13:18:02 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD3012D880 for ; Wed, 10 Jan 2018 13:18:02 -0800 (PST) Received: from [192.168.20.77] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id AFD5F790; Wed, 10 Jan 2018 21:18:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Wed, 10 Jan 2018 16:18:04 -0500 Cc: "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1A0CA4CA-E1A7-4FDF-B494-6E004D18B460@deployingradius.com> References: <151550369667.9592.15640677591631889787.idtracker@ietfa.amsl.com> To: John Mattsson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Emu] New Version Notification for draft-mattsson-eap-tls13-01.txt 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: Wed, 10 Jan 2018 21:18:10 -0000 On Jan 9, 2018, at 8:46 AM, John Mattsson = wrote: >=20 > We have submitted an updated version of draft-mattsson-eap-tls13. The = new version is a significant update based on the feedback and comments = on the EAP and EMU mailing lists. The new version also fills in all the = sections that was TDB in the -00 version. That looks a lot cleaner, thanks. > - The draft now updates version updates RFC5216 (instead of = obsoleting) and all text have been updated to make sure that the update = stays compatible with all existing implementations of EAP-TLS > - Added more text on what TLS 1.3 changes and why an update to RFC5216 = is needed. Nit: This means that significant parts of the normative text in the previous EAP-TLS specification [RFC5216] no longer apply, and aspects such as privacy handling, resumption, and key derivation need to be handled differently. Instead of "no longer apply", I would say "are not applicable to = EAP-TLS using TLS 1.3". A simple "no longer applies" text could be = interpreted as meaning it no longer applies to *any* variant of EAP-TLS. > - As this is now an update, all duplicated text is removed, and the = draft only describe the changes to message flow, messages, key = derivation, privacy, etc. when TLS 1.3 is used. The new draft follows = the structure of RFC5216 and lists updates (if any) to each section. Nit: The EAP server MUST authenticate with a certificate and SHOULD require the EAP peer to authenticate with a certificate. If the client certificate isn't provided, how is the client to be = authenticated? It may be better to say that the peer MUST authenticate = itself initially with a certificate, and then MUST use a provisioned PSK = for session resumption. Only those two authentication methods are = allowed. > - Clearly stated that PSK authentication SHALL not be used (except for = resumption). Why would PSK be forbidden? The TLS 1.3 spec clearly allows PSKs to be established out of band: = https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.2= .2 While RFC 5216 doesn't explicitly allow PSKs to be used, it doesn't = forbid them or define how they're used. The only other reference to = EAP-TLS with PSK seems to be draft-otto-emu-eap-tls-psk-02.txt, from = 2007. I guess my question here is how to allow PSK for session resumption, = while forbidding the use of static keys everywhere else. Nit: ... If the client has received a NewSessionTicket message from the server, the client can use the PSK identity =20 "can" use the PSK identity? What if it chooses to not use the PSK = identity? I suspect it would be better to say that the EAP server MUST provide = an identity and PSK for session resumption. When doing session = resumption, the EAP peer MUST use that identity and PSK. There's no benefit to the peer using a *different* identity. The = current phrasing "can use..." sounds philosophical instead of = prescriptive. It would be better to mandate the correct behaviour. Nit: A subsequent authentication using resumption, where both sides authenticate successfully is shown in Figure 3. It would be good to show a subsequent authentication using session = resumption, where the server rejects the resumption, and requests that = the EAP peer re-authenticate from scratch. It would also be good to note that if the session resumption is = rejected, the EAP peer MUST discard the ticket, along with any = associated identity and PSK.=20 > - Due to the encrypted handshake in TLS 1.3 there is no longer any = need for the EAP client to send and empty certificate list. A privacy = section has been added that explains this. >=20 > - A key hierarchy section has been added specifying that when TLS 1.3 = is used then Key_Material, IV, and Session-Id SHALL be derived from the = exporter_master_secret using the TLS exporter interface. That's good. Alan DeKok. From nobody Mon Jan 15 04:59:52 2018 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 7702312762F for ; Mon, 15 Jan 2018 04:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 rtqHlq_-1Xff for ; Mon, 15 Jan 2018 04:59:49 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA41126CC7 for ; Mon, 15 Jan 2018 04:59:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8D0E02CD0D; Mon, 15 Jan 2018 14:59:47 +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 iEd-pVdnUoCw; Mon, 15 Jan 2018 14:59:46 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id CA7C12CCBA; Mon, 15 Jan 2018 14:59:46 +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: <09F5EF34-2C03-4B93-8CF9-DDA129F45F14@deployingradius.com> Date: Mon, 15 Jan 2018 14:59:46 +0200 Cc: "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8712B7E8-D3DD-49F8-9F9C-2C267E519AAE@ericsson.com> <09F5EF34-2C03-4B93-8CF9-DDA129F45F14@deployingradius.com> To: Alan DeKok , John Mattsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Emu] Potential re-establishment of the EMU working group 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, 15 Jan 2018 12:59:51 -0000 Alan, John, > On Dec 22, 2017, at 1:12 PM, John Mattsson = wrote: >> In TLS 1.3, ECC is mandatory to support. This drastically reduces the = sizes of certificates and signatures (public key sizes from 384 bytes = (RSA and DHE) to 32 bytes (ECDHE) and signatures from 384 bytes (RSA) to = 64 bytes (ECDSA and EdDSA) ). >=20 > This doesn't help people with established certificates, business = practices, etc. >=20 >> Anything for older version of TLS would have to be pure = recommendations or guidance to preserve backward compatibility. I think = we should update the charter to cover guidance on how to handle large = certificates and long certificate chains in EAP-TLS with all versions of = TLS. This could be handled in the same bullet as =E2=80=9Cguidance or = update to enable the use of TLS 1.3=E2=80=9D. >=20 > That would definitely be useful. I think all this calls for something in the charter. The substance of = what we actually say in any final documents is something that we=E2=80=99l= l need to work on in the coming months, but for now I think something = about understanding and documenting the issues and making = recommendations where possible suffices. Some of this is a choice in the hands of whoever deploys EAP servers = (e.g., cert chains, algorithms) while other things may be harder to = change (what clients support, what existing NASes consider a maximum = message number limits, etc). Jari From nobody Thu Jan 18 06:25:58 2018 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 DBE0212706D for ; Thu, 18 Jan 2018 06:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 pnur5ObW5TYW for ; Thu, 18 Jan 2018 06:25:53 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7821205D3 for ; Thu, 18 Jan 2018 06:25:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7E7182CFCB for ; Thu, 18 Jan 2018 16:25:50 +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 a4L92O15whD2 for ; Thu, 18 Jan 2018 16:25:49 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 238672CD0D for ; Thu, 18 Jan 2018 16:25:49 +0200 (EET) (envelope-from jari.arkko@piuha.net) From: Jari Arkko Content-Type: multipart/alternative; boundary="Apple-Mail=_72708A88-2FD5-4B9B-9DC1-D6954D4206F4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 18 Jan 2018 16:25:48 +0200 References: <4D44B5F1-AE1E-4564-8366-31903B76FA9D@piuha.net> To: emu@ietf.org In-Reply-To: <4D44B5F1-AE1E-4564-8366-31903B76FA9D@piuha.net> Message-Id: <43641965-6EDC-4EDE-A844-4E30753F7AB3@piuha.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Emu] Potential re-establishment of the EMU working group, version 2 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, 18 Jan 2018 14:25:56 -0000 --Apple-Mail=_72708A88-2FD5-4B9B-9DC1-D6954D4206F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s a second spin of the potential WG charter. I will talk to = the ADs and see what we can do with this=E2=80=A6 would also appreciate = any further comments or expressions of support or objection from you all = :-) Jari =E2=80=94=E2=80=94=E2=80=94=E2=80=94 EAP Maintenance Update (emu) or EAP Method Maintenance Update (emmu) ------------------------------------ Chairs: TBD Security Area Directors: Eric Rescorla > Kathleen Moriarty > Security Area Advisor: TBD Mailing Lists: General Discussion: emu@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emu = Archive: http://www.ietf.org/mail-archive/web/emu/ = Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used, for instance, in 802.11 and VPN networks and mobile networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 50 different EAP methods exist, including several methods developed in the IETF, and support for EAP exists in a broad set of different devices. Previous larger EAP-related efforts at the IETF included rewriting the base EAP protocol documentation and the development of several standards track EAP methods. EAP methods are generally based on existing other security technologies, such as TLS, SIM cards, and various algorithms. Some of these technologies continue to evolve. And the understanding of security threats in today's Internet evolves as well, which has driven some of the evolution in these underlying technologies. At the same time, some new use cases for EAP have been identified, such as broader use of EAP in mobile network authentication. This working group has been chartered to provide updates to some commonly used EAP method. Specifically, the working group shall produce documents to: - Provide a guidance or update to enable the use of TLS 1.3 in the context of EAP TLS (RFC 5216). Update the security considerations relating to EAP TLS, to document the implications of using new vs. old TLS version, any recently gained new knowledge on vulnerabilities, and the possible implications of pervasive survellaince or other new concerns. - Update the EAP-AKA' specification (RFC 5448) to ensure that its capability to provide a cryptographic binding to network context stays in sync with what updates may come to the referenced 3GPP specifications through the use of EAP in 5G. Also, the group should document any recently gained new=20 knowledge on vulnerabilities or the possible implications of=20 pervasive surveillance or other new concerns. - Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, and EAP-AKA=E2=80=99. The lack of this definition is a recently discovered bug in the original RFCs. - Develop an extension to EAP-AKA' such that Perfect Forward Secrecy can be provided. There may also be privacy improvements that have become feasible with the introduction of recent identity privacy improvements in 3GPP networks. - Gather experience regarding the use of large certificate and certificate chain sizes in the context of EAP-TLS (all versions), as some implementations and access networks may limit the=20 number of EAP packet exchanges that can be handled. Document operational recommendations or other mitigation strategies to avoid issues. In all of the above, it is a requirement that none of the updates break backwards compatibility with existing specifications or implementations. The current RFCs shall not be obsoleted but rather updated with either new information or instructions on what is needed, for instance, to employ a new TLS version. The working group is expected to stay in close collaboration with the EAP deployment community, the TLS working group (for EAP-TLS work), and the 3GPP security architecture group (for EAP-AKA' work). Milestones: TBD --Apple-Mail=_72708A88-2FD5-4B9B-9DC1-D6954D4206F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Here=E2=80=99s a second spin of the potential = WG charter. I will talk to the ADs and see what we can do with this=E2=80=A6= would also appreciate any further comments or expressions of support or = objection from you all :-)

Jari

=E2=80=94=E2=80=94=E2=80=94=E2=80=94

EAP Maintenance Update (emu)
       or
EAP = Method Maintenance Update (emmu)
------------------------------------

Chairs:
    TBD

Security Area Directors:
    Eric Rescorla <ekr@rtfm.com>
    Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

Security Area Advisor:
    TBD

Mailing Lists:
    General = Discussion: emu@ietf.org
    To = Subscribe:       https://www.ietf.org/mailman/listinfo/emu
    Archive: =            http://www.ietf.org/mail-archive/web/emu/
Description of Working Group:

   The Extensible Authentication Protocol = (EAP) [RFC 3748] is a network
   access = authentication framework used, for instance, in 802.11 and VPN
   networks and mobile networks. EAP itself is = a simple
   protocol and actual = authentication happens in EAP methods.

   Over 50 different EAP methods exist, = including several methods
   developed in = the IETF, and support for EAP exists in a broad set
   of different devices. Previous larger = EAP-related efforts at the
   IETF included = rewriting the base EAP protocol documentation and
   the development of several standards track = EAP methods.

   EAP methods = are generally based on existing other security
   technologies, such as TLS, SIM cards, and = various algorithms.
   Some of these = technologies continue to evolve. And the
   understanding of security threats in = today's Internet evolves as
   well, which = has driven some of the evolution in these underlying
   technologies. At the same time, some new = use cases for EAP have
   been identified, = such as broader use of EAP in mobile network
   authentication.

   This working group has been chartered to = provide updates to some
   commonly used = EAP method. Specifically, the working group shall
   produce documents to:

   - Provide a guidance or update to enable = the use of TLS 1.3 in the
     context of EAP TLS (RFC 5216). = Update the security
     considerations relating to EAP = TLS, to document the implications
     of using new vs. old TLS = version, any recently gained new
     knowledge on vulnerabilities, = and the possible implications of
     pervasive survellaince or other = new concerns.

   - Update = the EAP-AKA' specification (RFC 5448) to ensure that its
     capability to provide a = cryptographic binding to network context
     stays in sync with what updates = may come to the referenced 3GPP
     specifications through the use = of EAP in 5G.

     Also, the group should document = any recently gained new 
    =  knowledge on vulnerabilities or the possible implications = of 
     pervasive surveillance = or other new concerns.

   - = Define session identifiers for fast re-authentication for
     EAP-SIM, EAP-AKA, and EAP-AKA=E2=80=99. = The lack of this definition
     is = a recently discovered bug in the original RFCs.

   - Develop an extension to EAP-AKA' such = that Perfect Forward Secrecy
     can be provided. There may also = be privacy improvements that
    =  have become feasible with the introduction of recent = identity
     privacy improvements = in 3GPP networks.

   - = Gather experience regarding the use of large certificate and
     certificate chain sizes in the context of = EAP-TLS (all versions),
     as some = implementations and access networks may limit the 
     number of EAP packet exchanges that can = be handled.
     Document = operational recommendations or other mitigation
     strategies to avoid issues.

   In all of the above, it is a = requirement that none of the updates
   break= backwards compatibility with existing specifications or
   implementations. The current RFCs shall not = be obsoleted but
   rather updated with = either new information or instructions on
   what is needed, for instance, to employ a = new TLS version.

   The = working group is expected to stay in close collaboration with
   the EAP deployment community, the TLS = working group (for EAP-TLS
   work), and = the 3GPP security architecture group (for EAP-AKA'
   work).

Milestones:

   TBD
= --Apple-Mail=_72708A88-2FD5-4B9B-9DC1-D6954D4206F4-- From nobody Thu Jan 18 06:45:26 2018 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 E5DC0127023 for ; Thu, 18 Jan 2018 06:45:24 -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 b07M29IPBNoe for ; Thu, 18 Jan 2018 06:45:23 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2A89B12700F for ; Thu, 18 Jan 2018 06:45:23 -0800 (PST) Received: from [192.168.2.28] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id C90A420E7; Thu, 18 Jan 2018 14:45:21 +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: <43641965-6EDC-4EDE-A844-4E30753F7AB3@piuha.net> Date: Thu, 18 Jan 2018 09:45:35 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3A5B10A2-E365-49D7-8030-7BED345B9B2F@deployingradius.com> References: <4D44B5F1-AE1E-4564-8366-31903B76FA9D@piuha.net> <43641965-6EDC-4EDE-A844-4E30753F7AB3@piuha.net> To: Arkko Jari X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Emu] Potential re-establishment of the EMU working group, version 2 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, 18 Jan 2018 14:45:25 -0000 > On Jan 18, 2018, at 9:25 AM, Jari Arkko wrote: >=20 > Here=E2=80=99s a second spin of the potential WG charter. I will talk = to the ADs and see what we can do with this=E2=80=A6 would also = appreciate any further comments or expressions of support or objection = from you all :-) That looks good to me. I think it covers all of the open topics of = conversation. Alan DeKok. From nobody Fri Jan 19 09:26:37 2018 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 86FB112E043 for ; Fri, 19 Jan 2018 09:26:35 -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 YcQXqoCzysIX for ; Fri, 19 Jan 2018 09:26:34 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 C920A12E042 for ; Fri, 19 Jan 2018 09:26:33 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id t6so1566238ual.7 for ; Fri, 19 Jan 2018 09:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uxgDDgh37oU/oZDQC6its/+PnlTgh9yuNlGFnUCJMjk=; b=IhfylGYCG/JSkJKBPhEYd4um8GEyxcjQqgjAwvwgPNY+zxORzF2rMlp8D1nOxE2xrE 1DPKSkw8zjKI2lC4pBMcYRK4d2rkzFA0GeuGmi+A7g3mRyAlpdB7TgBeohgh+mtYcCe3 X8wSfeR3xOEu40mY/aeNzCvkyDGkPPVWzZot8XSRgQEfB9o7xysrgF5OZhXoOj4x0Fd3 KJ65hKh9UQvY5U6aBnZZOr0c8FDU+dFbsbnRyhFy7S3KYy0ZVik/bFQqejNRGOK7FES6 jnHDixI9f9zfN8iY6d290F0Hv6ZNblWgm7dPZv9Gp/kHzGUOu4CCbjeRBMuOm18Vz4KY nxuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uxgDDgh37oU/oZDQC6its/+PnlTgh9yuNlGFnUCJMjk=; b=YPNrBatnI0OWlh/uaylphTt4exUb0wgjbUMvcywLHSk4sP+5tAG+BpTretD2DZb+pQ SW936uK0s4oeKFpJGvHMH4Y/qdJxbbLL14FUK8Ejd+QsHNN8Htbx05S6STf5xA+uJs7o 0443mnuMy6HVBP8++OmevTvE6oKCmn53RDczgF6J6oPz5DGhwV7LuDCa5qSMO2lTQimB 10m658PFV+aMqWk7RKCDfXh1XArlD1TN2keuWtIlsG8lqRRZ0iLBzb0+oT56qHR8vNSF jkLtHz5Bukzv6uEsUTmCf5mA9UX1Sqy/3YdU2esnA67fXbSwVGwV+gkvHltRp/fjJlKY 8onQ== X-Gm-Message-State: AKwxyteCrex9DaSvHQ+g0mGj/ka3fCeG2foHJnfkS8zEj6N0SCCpWrGR +V8wbDBDScNE0CNFUFHpOKnpRszqDbLb85W7QrOOxDVn X-Google-Smtp-Source: ACJfBovP2qx2jAAK3+VO05PpkMHAaJ+lGUXs7CEhqtJ6L5JfYDbr6W+VqRDFdBC/lOxnNThhPyGh0r1U/6Q73yPFR/s= X-Received: by 10.176.32.10 with SMTP id v10mr8142605uak.20.1516382792353; Fri, 19 Jan 2018 09:26:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.92.200 with HTTP; Fri, 19 Jan 2018 09:26:11 -0800 (PST) From: Bernard Aboba Date: Fri, 19 Jan 2018 09:26:11 -0800 Message-ID: To: emu@ietf.org Content-Type: multipart/alternative; boundary="f40304359638ae987e0563246190" Archived-At: Subject: [Emu] Comments on draft-mattsson-eap-tls13-01 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: Fri, 19 Jan 2018 17:26:35 -0000 --f40304359638ae987e0563246190 Content-Type: text/plain; charset="UTF-8" Overall, this draft is a significant improvement over the previous one. However, this draft appears to add support for new authentication modes such as PSK and ticket authentication. As far as I know, these features are not supported in any existing implementation and therefore would complicate testing and advancement of EAP-TLS to Standards status. I am also concerned that these changes will invalidate prior EAP-TLS security proofs and introduce new potential security vulnerabilities. John Mattsson said: Hi, We have submitted an updated version of draft-mattsson-eap-tls13. The new version is a significant update based on the feedback and comments on the EAP and EMU mailing lists. The new version also fills in all the sections that was TDB in the -00 version. - The draft now updates version updates RFC5216 (instead of obsoleting) and all text have been updated to make sure that the update stays compatible with all existing implementations of EAP-TLS. - Added more text on what TLS 1.3 changes and why an update to RFC5216 is needed. - As this is now an update, all duplicated text is removed, and the draft only describe the changes to message flow, messages, key derivation, privacy, etc. when TLS 1.3 is used. The new draft follows the structure of RFC5216 and lists updates (if any) to each section. - Clearly stated that PSK authentication SHALL not be used (except for resumption). [BA] Why add support for PSK authentication outside of resumption? AFAIK there are no implementations of this. - Due to the encrypted handshake in TLS 1.3 there is no longer any need for the EAP client to send and empty certificate list. A privacy section has been added that explains this. - A key hierarchy section has been added specifying that when TLS 1.3 is used then Key_Material, IV, and Session-Id SHALL be derived from the exporter_master_secret using the TLS exporter interface. Comments appreciated. Cheers, John --f40304359638ae987e0563246190 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Overall, this draft is a significant improvement over= the previous one.=C2=A0

However, this draft appea= rs to add support for new authentication modes such as PSK and ticket authe= ntication. As far as I know, these features are not supported in any existi= ng implementation
and therefore would complicate testing and adva= ncement of EAP-TLS to Standards status. I am also concerned that these chan= ges will invalidate prior EAP-TLS security proofs and introduce new potenti= al security vulnerabilities.=C2=A0

John Mattsson s= aid:=C2=A0

Hi,

We have submitted an updated version of draft-mattsson-eap-tls13. The new v=
ersion is a significant update based on the feedback and comments on the EA=
P and EMU mailing lists. The new version also fills in all the sections tha=
t was TDB in the -00 version.

- The draft now updates version updates RFC5216 (instead of obsoleting) and=
 all text have been updated to make sure that the update stays compatible w=
ith all existing implementations of EAP-TLS.

- Added more text on what TLS 1.3 changes and why an update to RFC5216 is n=
eeded.

- As this is now an update, all duplicated text is removed, and the draft o=
nly describe the changes to message flow, messages, key derivation, privacy=
, etc. when TLS 1.3 is used. 
The new =
draft follows the structure of RFC5216 and lists updates (if any) to each s=
ection.
- Clearly stated that PSK auth=
entication SHALL not be used (except for resumption).
[BA] Why add support for PSK authentication outside of resu=
mption? AFAIK there
are no implementat=
ions of this. 
- Due to the encrypted =
handshake in TLS 1.3 there is no longer any need for the EAP client to send=
 and empty certificate list. 
A privac=
y section has been added that explains this.
- A key hierarchy section has been added specifying that when TLS 1.=
3 is used then Key_Material, IV, and Session-Id 
SHALL be derived from the exporter_master_secret using the TLS e=
xporter interface.

Comments appreciated.

Cheers,
John
--f40304359638ae987e0563246190-- From nobody Fri Jan 19 09:45:55 2018 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 AEC59127337 for ; Fri, 19 Jan 2018 09:45:53 -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 6uDKUB4kv7GG for ; Fri, 19 Jan 2018 09:45:52 -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 28CA2126CF6 for ; Fri, 19 Jan 2018 09:45:52 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id z9so1188764vkd.5 for ; Fri, 19 Jan 2018 09:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qCcn4J3ln4yMmbwBMifmo1LTaC1C2TXvWyuO7s8lDHw=; b=DRwX10EgxfVF5tx2aCRuhUqyqI6I5pGSB81cfKQlh8LiO+9h5T8N/QN7qw8bV0UB4W p7ab5i895g37NUMU4eoGAiVEU/aV1ud7DeWIhABbhCm46EF7WfFt9a4mBDPbG5O2rDr/ gOLxAEbpGvDH+UbOLh58tLuvMdF+HW5GZ3fIw7vNHy3pJyAepQQEKJIX+52ewlRIdogl kMkMJeCBabEuKeNYAw7HNzFGmftOKYka2niNHTX0GRbjEY+0BO5U47OZQosQOd/QvHOq N+Din4v8KjyVlO5XtTm3clhXQVpxIGg/l2DZvVp6pdgfumUK9UuQPP9udp6UbHRbBw1t MOhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qCcn4J3ln4yMmbwBMifmo1LTaC1C2TXvWyuO7s8lDHw=; b=uRvEVTosauOlatAfnsPb7FBj7khyl0ia6HjFb6xnAePv4e22WLXa7wSysbopgqGde1 dcp3m7mYpLEM9lfba720Sqm9PGW7Q45mzcx+mUlt0l6kmLWLxpKHMVnTJQ14kbVaaXPB mt2OP+Eukod4AuWvQPMIIopUTRinlPC/Ad9wq3KldzKhbAaNEMTRVrcY6SNJInHbqE3r oF2h0+S0hDZPEsVMjWHS4ZrTSHOAEI+oBN+U2jf54M9VvOCUNuiTkWcV6+aECo9B/kY8 aka4xQq/pmTEdM4TlYD8iiUN/M+BKX5OWNTiXmMSIbNA6ACOXd7Ns8ppAUZfzSJNKTRi JRAA== X-Gm-Message-State: AKwxytczniZPqUCPLdq3r/mLyM9yPeY2cKgGlabba1qGvsJGggwu5AfR SZtxoG0+WgsOPZ3glpgQMT0XtHYkA7AFMWSPiHftziK1 X-Google-Smtp-Source: ACJfBougmjXkiV6dO+h4c8Wkn1Tnj6Lh+04RTyg194+Gl7Tvo6VQtmAFkCMa70VXysALYyzFOyivY0/UEqoBltj6OXw= X-Received: by 10.31.192.80 with SMTP id q77mr7353260vkf.7.1516383950669; Fri, 19 Jan 2018 09:45:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.92.200 with HTTP; Fri, 19 Jan 2018 09:45:30 -0800 (PST) From: Bernard Aboba Date: Fri, 19 Jan 2018 09:45:30 -0800 Message-ID: To: emu@ietf.org Content-Type: multipart/alternative; boundary="001a114396ccb90d9f056324a649" Archived-At: Subject: Re: [Emu] EAP-TLS with large certificates 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: Fri, 19 Jan 2018 17:45:54 -0000 --001a114396ccb90d9f056324a649 Content-Type: text/plain; charset="UTF-8" Alan DeKok said: " It may also be worth re-examining EAP-TLS. Modern certificates are getting large, and people are using longer certificate chains. The result can be that initial EAP-TLS authentication takes many packets. This has issues not just for latency, but also access point implementations. Most implementations will drop an EAP session if it hasn't finished after 40-50 packets. I've seen people run into this issue with large certificates and long certificate chains. It would be good to find a way to allow this use-case." [BA] I have encountered this problem in a number of situations, particularly in enterprise deployments with several levels of intermediate CAs. Since the certificate hierarchy is relatively static, this seems like a problem that could be addressed via caching. For example, if client A has previously authenticated to server B and has cached the certificate chain, why does it need to be transmitted again? Similarly, if server B has already cached certificates from intermediate CAs, why does the client need to transmit that information again? Seems like this could be addressed by a small extension to TLS. --001a114396ccb90d9f056324a649 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alan DeKok said:=C2=A0

" It may also be worth re-examining EAP-TLS. Modern= certificates are getting large, and people are using longer certificate ch= ains. The result can be that initial EAP-TLS authentication takes many pac= kets. This has issues not just for latency, but also access point implemen= tations. Most implementations will drop an EAP session if it hasn't fi= nished after 40-50 packets.
=C2=A0 I've seen people run into this issue with large certificates = and long certificate chains. It would be good to find a way to allow this = use-case."

[BA] I have encountered thi= s problem in a number of situations, particularly in enterprise deployments= with several levels of intermediate CAs.=C2=A0 Since the certificate hiera= rchy is relatively static, this seems like a problem that could be addresse= d via caching.=C2=A0

For example, if client A has = previously authenticated to server B and has cached the certificate chain, = why does it need to be transmitted again? Similarly, if server B has alread= y cached certificates from intermediate CAs, why does the client need to tr= ansmit that information again?=C2=A0

Seems like th= is could be addressed by a small extension to TLS.=C2=A0
--001a114396ccb90d9f056324a649-- From nobody Fri Jan 19 10:55:45 2018 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 1A0C11277BB for ; Fri, 19 Jan 2018 10:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 uFnsgGmniycC for ; Fri, 19 Jan 2018 10:55:40 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC2A127867 for ; Fri, 19 Jan 2018 10:55:40 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 19 Jan 2018 10:53:36 -0800 From: Jim Schaad To: 'Bernard Aboba' , References: In-Reply-To: Date: Fri, 19 Jan 2018 10:55:04 -0800 Message-ID: <037501d39157$06124800$1236d800$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0376_01D39113.F7F1EE30" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFmKMbNLoC95OEiFvBYjp3Ub5kZTKRWW5dA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Emu] EAP-TLS with large certificates 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: Fri, 19 Jan 2018 18:55:44 -0000 ------=_NextPart_000_0376_01D39113.F7F1EE30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are already a couple of things in TLS 1.3 that can be used to = address some of these issues =20 From: Emu [mailto:emu-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Friday, January 19, 2018 9:46 AM To: emu@ietf.org Subject: Re: [Emu] EAP-TLS with large certificates =20 Alan DeKok said:=20 =20 " It may also be worth re-examining EAP-TLS. Modern certificates are = getting large, and people are using longer certificate chains. The = result can be that initial EAP-TLS authentication takes many packets. = This has issues not just for latency, but also access point = implementations. Most implementations will drop an EAP session if it = hasn't finished after 40-50 packets. I've seen people run into this issue with large certificates and long = certificate chains. It would be good to find a way to allow this = use-case." =20 [BA] I have encountered this problem in a number of situations, = particularly in enterprise deployments with several levels of = intermediate CAs. Since the certificate hierarchy is relatively static, = this seems like a problem that could be addressed via caching.=20 =20 [JLS] There is already a way to say that you have a specific set of = certificates and CRLs in RFC 7924 =E2=80=93 TLS Cached Information = Extension. There is also a new TLS 1.3 extension that is being looked = at for compressions of certificates. This seems to get some decent = compressions, but it is still up in the air just how good it is going to = be. =20 For example, if client A has previously authenticated to server B and = has cached the certificate chain, why does it need to be transmitted = again? Similarly, if server B has already cached certificates from = intermediate CAs, why does the client need to transmit that information = again?=20 =20 Seems like this could be addressed by a small extension to TLS.=20 ------=_NextPart_000_0376_01D39113.F7F1EE30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

There are already a couple of things in TLS 1.3 that = can be used to address some of these issues

 

From: Emu = [mailto:emu-bounces@ietf.org] On Behalf Of Bernard = Aboba
Sent: Friday, January 19, 2018 9:46 AM
To: = emu@ietf.org
Subject: Re: [Emu] EAP-TLS with large = certificates

 

Alan = DeKok said: 

 

" It may also be = worth re-examining EAP-TLS. Modern certificates are getting large, and = people are using longer certificate chains. The result can be that = initial EAP-TLS authentication takes many packets. This has issues not = just for latency, but also access point implementations. Most = implementations will drop an EAP session if it hasn't finished after = 40-50 packets.

  I've seen people = run into this issue with large certificates and long certificate chains. = It would be good to find a way to allow this = use-case."

 

[BA] I have encountered this problem in a number of = situations, particularly in enterprise deployments with several levels = of intermediate CAs.  Since the certificate hierarchy is relatively = static, this seems like a problem that could be addressed via = caching. 

 

[JLS] There = is already a way to say that you have a specific set of certificates and = CRLs=C2=A0 in RFC 7924 =E2=80=93 TLS Cached Information Extension.=C2=A0 = There is also a new TLS 1.3 extension that is being looked at for = compressions of certificates.=C2=A0 This seems to get some decent = compressions, but it is still up in the air just how good it is going to = be.

 

For example, if client A has previously authenticated = to server B and has cached the certificate chain, why does it need to be = transmitted again? Similarly, if server B has already cached = certificates from intermediate CAs, why does the client need to transmit = that information again? 

 

Seems like this could be addressed by a small = extension to = TLS. 

------=_NextPart_000_0376_01D39113.F7F1EE30-- From nobody Thu Jan 25 05:54:11 2018 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 0EA501205F0 for ; Thu, 25 Jan 2018 05:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 fENJEpeKFKdp for ; Thu, 25 Jan 2018 05:54:07 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 3485B120227 for ; Thu, 25 Jan 2018 05:54:07 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-34-5a69e17c6e91 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 97.64.27591.C71E96A5; Thu, 25 Jan 2018 14:54:05 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 25 Jan 2018 14:54:04 +0100 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; bh=qTSeRga6EE+GpuRY14NcJPEokTHf972R6WlNQnO9HtA=; b=O/9OeK0RncoHKWTnbOlMdCjPW5kVkbq8dtD5sbzAnPgbffzzHkwFu6u/QIsctV7NLIkrOok8fB1fCdfAfT1lOFTuOMhMqklGXJ3vTE40jgtQCNMBDwDV2esw4Sg1jGdWgY/GXjabTyweO6Rqkkjs5a9XPzBCBQdvv8IC5Qp9YQE= Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com (10.167.189.149) by HE1PR0701MB2537.eurprd07.prod.outlook.com (10.168.129.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Thu, 25 Jan 2018 13:54:03 +0000 Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::b8af:635a:701a:fa6f]) by HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::b8af:635a:701a:fa6f%13]) with mapi id 15.20.0464.006; Thu, 25 Jan 2018 13:54:03 +0000 From: John Mattsson To: "emu@ietf.org" Thread-Topic: [Emu] EAP-TLS with large certificates Thread-Index: AQHTleP1CM6+QVFgJE6gMOGXqbgdkA== Date: Thu, 25 Jan 2018 13:54:02 +0000 Message-ID: <3F5C1A72-20AC-4F3D-9FA5-60E086CB1949@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.29.0.171205 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2537; 7:HsYonklWdqDQ5xpFnLepHYKO2F7iHOn2Mwvot1QGPJTVknaNllOeH15rGy7KGucXaS+cNwaKxz2vCY3ESeMMNoEdJWksaUqarXKOY7F9iNxP78i8Zxl/tsyW2ZxRijDbZRW1BeUbIvvMO5tEh5qBKDxXxcjXN0y6QRcMaK1c4kYnfK5QVFTE40kXGg4/RII88Nw9wUWAKdhbXpFRmF2SV+THzuQwxl+PNfYd55js9UjW734d6kS/OE9x4ygZ2xKg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ea5ceeed-1194-4321-a9ce-08d563fb17df x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0701MB2537; x-ms-traffictypediagnostic: HE1PR0701MB2537: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(10201501046)(93006095)(93001095)(3002001)(6041288)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR0701MB2537; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2537; x-forefront-prvs: 0563F2E8B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(39380400002)(39860400002)(346002)(199004)(189003)(3280700002)(68736007)(14454004)(97736004)(102836004)(2906002)(8936002)(82746002)(83506002)(6436002)(33656002)(186003)(6116002)(229853002)(83716003)(26005)(3846002)(5250100002)(5640700003)(6916009)(5660300001)(6486002)(6512007)(2900100001)(2351001)(7736002)(36756003)(86362001)(2501003)(81166006)(25786009)(478600001)(99286004)(6506007)(316002)(53936002)(6246003)(59450400001)(8676002)(105586002)(106356001)(1730700003)(3660700001)(66066001)(81156014)(54896002)(6306002)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2537; H:HE1PR0701MB2011.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 6xECw5Wxe4dFiYoCA2vjcyL5dp1CWR14lkXjOeg/Pi0Drcs848EkQkGSf8XQPWUAeu5s8hT+dDxuZLkgDnPptA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3F5C1A7220AC4F3D9FA560E086CB1949ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ea5ceeed-1194-4321-a9ce-08d563fb17df X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 13:54:02.9393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2537 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUyM2K7vW7tw8wog8ndvBbH1q9lcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvEt3ewFbSYVy98uYmlgPGzUxcjJISFgIjF5+1W2LkYuDiGB w4wSK/4eZ4RwTjBK3OtYC5ZhEfjEJHH53C5miMxsJonG9oXsEM5zRomJr7YygQxjEzCQmLun gQ3EFhFQlPhxqY0ZxBYWMJI4u2oDaxcjB1DcWGL2V3UIU0+i/ZweSAWLgKrE6mf/mEDCvAL2 EnP3lYKEGQXEJL6fWgM2nFlAXKLpy0pWiKsFJJbsOc8MYYtKvHz8DywuCjTxxZlr7BC9sRKt rdOh6hUkjs1YyQJhy0pcmt8N9qSEwDYmidX/3kEV6UlsnfiWEcL2ldjz4BATRNEpRom+/+/Y IRI6EkvfH4fanC/R9+0fE4QdLdG8+zsbRMMcZon7T1qhJslIPP76gh0i8YJVYv7mW2AJIYFU ieVrWxknMOrMQvIehJ0ssbV5OQuIzSsgKHFy5hMgmwMorimxfpc+RImixJTuh+wQtoZE65y5 ULaHRN+6pczIahYwcqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECExBB7f8NtjB+PK54yFG AQ5GJR7e56cyo4RYE8uKK3MPMUpwMCuJ8F5uz4gS4k1JrKxKLcqPLyrNSS0+xCjNwaIkznvS kzdKSCA9sSQ1OzW1ILUIJsvEwSnVwFh3TK/j+mbFI99F0qwOBn4+2Bt+ov2L313W3W4ajHqb +4NmbDx10vxZJQ9D3e5eYUHN18Wlr39lLVOU6/v703kjQ9+rldf9b3OHiLLmNJoUShpKhLcW 7oyaY7zV3K2iaE1w7rPnL24oftvuYsG/uG5X5N0V1msMn1Qt//7HT/mgeE1ZMOudTCWW4oxE Qy3mouJEAAosaRs9AwAA Archived-At: Subject: Re: [Emu] EAP-TLS with large certificates 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, 25 Jan 2018 13:54:09 -0000 --_000_3F5C1A7220AC4F3D9FA560E086CB1949ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VExTIDEuMyBhbHNvIGNoYW5nZXMgd2hpY2ggb2YgdGhlIGNlcnRpZmljYXRlcyB0aGF0IGNhbiBi ZSBvbWl0dGVkLiBUTFMgMS4yIChhbmQgZWFybGllcikgb25seSBhbGxvd3Mgb21pdHRpbmcgdGhl IHNlbGYtc2lnbmVkIHJvb3QgY2VydGlmaWNhdGUgd2hpbGUgVExTIDEuMyBhbGxvd3Mgb21pdHRp bmcgYW55IHRydXN0IGFuY2hvciBjZXJ0aWZpY2F0ZS4gVGhpcyB3b3VsZCBiZSB1c2VmdWwgaW4g Y2FzZXMgd2hlcmUgdGhlIHBvc3Nlc3NlZCB0cnVzdCBhbmNob3JzIGFyZSBrbm93bi4NCg0KVExT IDEuMjogInRoZSBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZSB0aGF0IHNwZWNpZmllcyB0aGUgcm9v dCBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkgTUFZIGJlIG9taXR0ZWQgZnJvbSB0aGUgY2hhaW4sIHVu ZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIHJlbW90ZSBlbmQgbXVzdCBhbHJlYWR5IHBvc3Nl c3MgaXQgaW4gb3JkZXIgdG8gdmFsaWRhdGUgaXQgaW4gYW55IGNhc2UuIg0KDQpUTFMgMS4zOiAi YSBjZXJ0aWZpY2F0ZSB0aGF0IHNwZWNpZmllcyBhIHRydXN0IGFuY2hvciBNQVkgYmUgb21pdHRl ZCBmcm9tIHRoZSBjaGFpbiwgcHJvdmlkZWQgdGhhdCBzdXBwb3J0ZWQgcGVlcnMgYXJlIGtub3du IHRvIHBvc3Nlc3MgYW55IG9taXR0ZWQgY2VydGlmaWNhdGVzLiINCg0KUkZDIDc5MjQgc2VlbXMg dXNlZnVsLCBidXQgb25seSBzaG9ydGVucyB0aGUgc2VydmVy4oCZcyBjZXJ0aWZpY2F0ZSBsaXN0 LiBUbyBzaG9ydGVuIHRoZSBjbGllbnTigJlzIGNlcnRpZmljYXRlIGxpc3QsIHRoZSBjYWNoZWQg aW5mb3JtYXRpb24gZXh0ZW5zaW9uIHdvdWxkIGhhdmUgdG8gYmUgc2VudCBpbiB0aGUgQ2VydGlm aWNhdGVSZXF1ZXN0IGZyb20gdGhlIHNlcnZlci4gQXMgZmFyIGFzIEkgY2FuIHVuZGVyc3RhbmQs IHRoaXMgaXMgbm90IGFsbG93ZWQgaW4gVExTIDEuMy4gSXQgc2hvdWxkIHByb2JhYmx5IGJlIGFk ZGVkLg0KDQo= --_000_3F5C1A7220AC4F3D9FA560E086CB1949ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <8F205E5724C73F45A43DA2587938D11F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciIsc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIixzZXJpZjt9DQpz cGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFt ZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw Ljg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5UTFMgMS4zIGFsc28gY2hhbmdlcyB3aGljaCBvZiB0aGUgY2VydGlmaWNhdGVzIHRo YXQgY2FuIGJlIG9taXR0ZWQuIFRMUyAxLjIgKGFuZCBlYXJsaWVyKSBvbmx5IGFsbG93cyBvbWl0 dGluZyB0aGUgc2VsZi1zaWduZWQgcm9vdCBjZXJ0aWZpY2F0ZSB3aGlsZSBUTFMgMS4zIGFsbG93 cyBvbWl0dGluZyBhbnkgdHJ1c3QgYW5jaG9yIGNlcnRpZmljYXRlLiBUaGlzDQogd291bGQgYmUg dXNlZnVsIGluIGNhc2VzIHdoZXJlIHRoZSBwb3NzZXNzZWQgdHJ1c3QgYW5jaG9ycyBhcmUga25v d24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UTFMgMS4yOiAm cXVvdDt0aGUgc2VsZi1zaWduZWQgY2VydGlmaWNhdGUgdGhhdCBzcGVjaWZpZXMgdGhlIHJvb3Qg Y2VydGlmaWNhdGUgYXV0aG9yaXR5IE1BWSBiZSBvbWl0dGVkIGZyb20gdGhlIGNoYWluLCB1bmRl ciB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSByZW1vdGUgZW5kIG11c3QgYWxyZWFkeSBwb3NzZXNz IGl0IGluIG9yZGVyIHRvIHZhbGlkYXRlIGl0IGluDQogYW55IGNhc2UuJnF1b3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UTFMgMS4zOiAmcXVvdDthIGNlcnRp ZmljYXRlIHRoYXQgc3BlY2lmaWVzIGEgdHJ1c3QgYW5jaG9yIE1BWSBiZSBvbWl0dGVkIGZyb20g dGhlIGNoYWluLCBwcm92aWRlZCB0aGF0IHN1cHBvcnRlZCBwZWVycyBhcmUga25vd24gdG8gcG9z c2VzcyBhbnkgb21pdHRlZCBjZXJ0aWZpY2F0ZXMuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SRkMgNzkyNCBzZWVtcyB1c2VmdWwsIGJ1dCBvbmx5IHNo b3J0ZW5zIHRoZSBzZXJ2ZXLigJlzIGNlcnRpZmljYXRlIGxpc3QuIFRvIHNob3J0ZW4gdGhlIGNs aWVudOKAmXMgY2VydGlmaWNhdGUgbGlzdCwgdGhlIGNhY2hlZCBpbmZvcm1hdGlvbiBleHRlbnNp b24gd291bGQgaGF2ZSB0byBiZSBzZW50IGluIHRoZSBDZXJ0aWZpY2F0ZVJlcXVlc3QgZnJvbSB0 aGUgc2VydmVyLg0KIEFzIGZhciBhcyBJIGNhbiB1bmRlcnN0YW5kLCB0aGlzIGlzIG5vdCBhbGxv d2VkIGluIFRMUyAxLjMuIEl0IHNob3VsZCBwcm9iYWJseSBiZSBhZGRlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3F5C1A7220AC4F3D9FA560E086CB1949ericssoncom_--