From nobody Fri Dec 1 05:17:08 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 To: "aland@deployingradius.com" , Mohit Sethi M , Bernard Aboba , "Jim Schaad" , "reap@ietf.org" , "saag@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: 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: 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: Subject: Re: [Emu] [Reap] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 13:16:45 -0000 VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIEFsYW4uIFZlcnkgaGVscGZ1bC4gU2VlIGFuc3dlcnMg YW5kIGNvbW1lbnRzIGJlbG93Og0KDQpPbiBOb3YgMTYsIDIwMTcsIEFsYW4gRGVLb2sgd3JvdGU6 DQoNCj5UaGF0J3MgZ29vZC4gIEJ1dCBhcyBCZXJuYXJkIHBvaW50cyBvdXQsIHRoZXJlJ3Mgbm8g bmVlZCB0byBjaGFuZ2UNCj5FQVAtVExTLiAgWW91IGNhbiBqdXN0IHVzZSBUTFMgMS4zLg0KDQpJ IGRvbuKAmXQgYWdyZWUgd2l0aCB0aGF0LCBzZWUgY29uY3JldGUgZGV0YWlscyBiZWxvdy4NCg0K DQo+SG93IHNvPyA1MjE2IHNheXMgKGVzc2VudGlhbGx5KSAiZW5jYXBzdWxhdGUgVExTIHdpdGhp biBFQVAiLiBIb3csIGV4YWN0bHksID5kb2VzIHRoaXMgY2hhbmdlIHdpdGggVExTIDEuMz8NCg0K SWYgUkZDNTIxNiBhY3R1YWxseSBzYWlkIHRoYXQgaXQgd291bGQgYmUgbGVzcyBvZiBhIHByb2Js ZW0sIGJ1dCBSRkM1MjE2IGhhcyBhIGxhcmdlIGFtb3VudCBvZiBub3JtYXRpdmUgdGVybWlub2xv Z3kgdGhhdCBpcyBjb3JyZWN0IGZvciBUTFMgMS4wIC0gMS4yLCBidXQgd3JvbmcgZm9yIFRMUyAx LjMuIEp1c3QgbG9va2luZyBxdWlja2x5IGF0IHRoZSBiYXNlIGNhc2UgaW4gUkZDNTIxNiAoU2Vj dGlvbiAyLjEuMS4pOg0KDQoidW50aWwgdGhlIGNoYW5nZV9jaXBoZXJfc3BlYyBtZXNzYWdlIg0K KEluIFRMUyAxLjMgY2hhbmdlX2NpcGhlcl9zcGVjIGlzIGFuIG9wdGluYWwgZHVtbXkgcmVjb3Jk IG9ubHkgdXNlZCBmb3IgTWlkZGxlYm94IGNvbXBhdGliaWxpdHkpLg0KDQoiYSBzZXJ2ZXJfaGVs bG9fZG9uZSBoYW5kc2hha2UgbWVzc2FnZSBNVVNUIGJlIHRoZSBsYXN0IGhhbmRzaGFrZSBtZXNz YWdlIGVuY2Fwc3VsYXRlZCBpbiB0aGlzIEVBUC1SZXF1ZXN0IHBhY2tldC4iDQooc2VydmVyX2hl bGxvX2RvbmUgaXMgdXNlZCBpbiBUTFMgMS4zKS4NCg0KImEgVExTIHNlcnZlcl9rZXlfZXhjaGFu Z2UgaGFuZHNoYWtlIG1lc3NhZ2UgTVVTVCBhbHNvIGJlIGluY2x1ZGVkIg0KKHNlcnZlcl9rZXlf ZXhjaGFuZ2UgaXMgdXNlZCBpbiBUTFMgMS4zKS4NCg0KIk1VU1QgZW5jYXBzdWxhdGUgb25lIG9y IG1vcmUgVExTIHJlY29yZHMgY29udGFpbmluZyBhIFRMUyBjbGllbnRfa2V5X2V4Y2hhbmdlLCBj aGFuZ2VfY2lwaGVyX3NwZWMiDQooY2xpZW50X2tleV9leGNoYW5nZSBpcyB1c2VkIGluIFRMUyAx LjMpLg0KDQoidGhlIHBlZXIgTVVTVCBzZW5kIG9ubHkgdGhlIGNoYW5nZV9jaXBoZXJfc3BlYyIN CihzZWUgYWJvdmUpDQoNCkVBUC1UTFMgd2l0aCBUTFMgMS4zIHdvdWxkIGJyZWFrIGEgX2xhcmdl XyBhbW91bnQgb2YgTVVTVCBpbiBSRkM1MjE2Lg0KDQoNCj5XaGF0LCBleGFjdGx5IGlzIGRpZmZl cmVudCB3aXRoIHRoZSBtZXNzYWdlIGZsb3dzIGluIEVBUC1UTFMgd2hlbiBUTFMgMS4zIGlzID51 c2VkPw0KDQpXaGlsZSB0aGUgbWVzc2FnZSBmbG93cyBhcmUgZXhhY3RseSB0aGUgc2FtZSBpbiBU TFMgMS4wLCBUTFMgMS4xLCBhbmQgVExTIDEuMg0KDQogICAgIENsaWVudEhlbGxvICAgICAgICAg ICAgICAgICAgLS0tLS0tLS0+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBTZXJ2ZXJIZWxsbw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZSoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VydmVyS2V5RXhjaGFuZ2UqDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVSZXF1ZXN0 Kg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0gICAgICBTZXJ2 ZXJIZWxsb0RvbmUNCiAgICAgIENlcnRpZmljYXRlKg0KICAgICAgQ2xpZW50S2V5RXhjaGFuZ2UN CiAgICAgIENlcnRpZmljYXRlVmVyaWZ5Kg0KICAgICAgW0NoYW5nZUNpcGhlclNwZWNdDQogICAg ICBGaW5pc2hlZCAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbQ2hhbmdlQ2lwaGVyU3BlY10NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tICAgICAgICAgICAgIEZpbmlz aGVkDQoNClRoZSBtZXNzYWdlIGZsb3cgYW5kIGl0cyBjb250ZW50IGlzIGNvbXBsZXRlbHkgZGlm ZmVyZW50IGluIFRMUyAxLjMNCg0KS2V5ICBeIENsaWVudEhlbGxvDQpFeGNoIHwgKyBrZXlfc2hh cmUqDQogICAgIHwgKyBzaWduYXR1cmVfYWxnb3JpdGhtcyoNCiAgICAgfCArIHBza19rZXlfZXhj aGFuZ2VfbW9kZXMqDQogICAgIHYgKyBwcmVfc2hhcmVkX2tleSogICAgICAgICAtLS0tLS0tLT4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT ZXJ2ZXJIZWxsbyAgXiBLZXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICsga2V5X3NoYXJlKiAgfCBFeGNoDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyBwcmVfc2hhcmVkX2tleSogIHYNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHtFbmNyeXB0ZWRFeHRlbnNp b25zfSAgXiAgU2VydmVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB7Q2VydGlmaWNhdGVSZXF1ZXN0Kn0gIHYgIFBhcmFtcw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHtDZXJ0aWZpY2F0ZSp9ICBeDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAge0NlcnRpZmljYXRlVmVy aWZ5Kn0gIHwgQXV0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB7RmluaXNoZWR9ICB2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8LS0tLS0tLS0gICAgIFtBcHBsaWNhdGlvbiBEYXRhKl0NCiAgICAgXiB7Q2VydGlmaWNh dGUqfQ0KQXV0aCB8IHtDZXJ0aWZpY2F0ZVZlcmlmeSp9DQogICAgIHYge0ZpbmlzaGVkfSAgICAg ICAgICAgICAgICAtLS0tLS0tLT4NCg0KKEkgYWdyZWUgd2l0aCBCZXJuYW5kIHRoYW4gZGV2ZWxv cGVycyB3b3VsZCBsaWtlbHkgZ2V0IHRoZSBtZXNzYWdlIGZsb3dzIHJpZ2h0LCBob3dldmVyIHN1 Y2ggYW4gaW1wbGVtZW50YXRpb24gd291bGQgYnJlYWsgYSBfbGFyZ2VfIG51bWJlciBvZiBNVVNU IGluIFJGQzUyMTYgKHNlZSBhYm92ZSkuIEkgYWxzbyB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRv IGdpdmUgcGVvcGxlIHdhbnRpbmcgdG8gdXNlIEVBUC1UTFMgaG93IG1hbnkgcm91bmR0cmlwcyB0 aGV5IGNhbiBleHBlY3Qgd2l0aCBUTFMgMS4zIChpbiBnZW5lcmFsIG9uZSBsZXNzIHRoYXQgd2l0 aCBUTFMgMS4wIC0gMS4yKS4NCg0KICANCj5JIHRoaW5rIG9uZSBvZiB0aGUgY29uY2VybnMgaGVy ZSBpcyB0aGUgcHJvY2VkdXJhbCBhc3BlY3QuICBZb3VyIHByb3Bvc2FsDQo+d2FzIHRvIGZvcmJp ZCBldmVyeW9uZSAqZWxzZSogZnJvbSB1c2luZyBUTFMgMS4wIGJlY2F1c2UgeW91ciByZXF1aXJl bWVudHMNCj53ZXJlIGZvciBUTFMgMS4zLiAgVGhhdCdzIG5vdCB0aGUgd2F5IHRvIGdhaW4gc3Vw cG9ydC4NCg0KWWVzLCBwcm9jZWR1cmFsIGFzcGVjdHMgc2VlbSB0byBiZSBhIGxhcmdlIGNvbmNl cm4sIGJ1dCDigJxvYnNvbGV0ZeKAnSBkb2VzIG5vdCBmb3JiaWQgYW55b25lIGZyb20gdXNpbmcg RUFQLVRMUyB3aXRoIFRMUyAxLjAuIEUuZy4gVExTIDEuMyBvYnNvbGV0ZXMgVExTIDEuMiwgd2hp Y2ggb2Jzb2xldGVzIFRMUyAxLjEgZXRjLiBidXQgdGhhdCBkb2VzIG5vdCBtZWFuIHRoYXQgcGVv cGxlIGFyZSBmb3JiaWRkZW4gdG8gdXNlIFRMUyAxLjIuIElmIGZhY3QgVExTIHByb3ZpZGVzIGEg dmVyc2lvbmluZyBtZWNoYW5pc20gYW5kIHRoZSBUTFMgd29ya2luZyBncm91cCBpcyBldmVuIHBs YW5uaW5nIFRMUyAxLjIgTG9uZy10ZXJtIHN1cHBvcnQuIFRoYXQgc2FpZCwgSSBhbSBwZXJmZWN0 bHkgZmluZSB3aXRoIOKAnHVwZGF0ZeKAnSBpZiB0aGF0IGlzIHdoYXQgdGhlIG1haWxpbmcgbGlz dCB3YW50cywgSSB3aWxsIGNoYW5nZSAib2Jzb2xldGUiIHRvICJ1cGRhdGUiIGluIHRoZSAtMDEg dmVyc2lvbiwgYW5kIG1ha2UgaXQgY2xlYXIgdGhhdCBpbiB0aGUgdGV4dCB0aGF0IHRoZSB1cGRh dGUgaXMgc3RpbGwgY29tcGF0aWJsZSB3aXRoIFJGQzUyMTYgdXNpbmcgVExTIDEuMC4NCg0KDQo+ SW1wbGVtZW50YXRpb25zIG9mIEVBUC1UTFMgZG8gbmVlZCB0byBjaGFuZ2Ugd2hlbiB0aGUga2V5 IGRlcml2YXRpb24gY2hhbmdlcy4NCj5TdWNoIGFzIGZvciBUTFMgMS4yLiAgSG93ZXZlciwgdGhv c2UgY2hhbmdlcyBhcmUgPmxhcmdlbHkgbGltaXRlZCB0byB0aGUgVExTDQo+bGlicmFyeSwgbm90 IHRoZSBFQVAtVExTIGNvZGUuDQoNClJGQzUyMTYsIFNlY3Rpb24gMi41IGRlZmluZXMgdGhhdCBN U0ssIEVNU0ssIGFuZCBJViBpcyBkZXJpdmVkIHdpdGggdGhlIFRMUy1QUkYsIHdoaWNoIGlzIHRo ZSByaWdodCB3YXkgdG8gZG8gaXQgaW4gVExTIDEuMCwgVExTIDEuMSwgVExTIDEuMi4gVExTIDEu MyByZXBsYWNlcyB0aGUgUFJGIHdpdGggSEtERiwgdGh1cyByZXF1aXJpbmcgYSBuZXcgY29uc3Ry dWN0aW9uLiBIb3cgd291bGQgc29tZW9uZSB0cnlpbmcgdG8gaW1wbGVtZW50IFRMUyAxLjMgd2l0 aCBSRkM1MjE2IGRlcml2ZSB0aGUga2V5cz8NCg0KMS4gRm9sbG93IFJGQzUyMTYgYW5kIHVzZSB0 aGUgb2xkIFRMUy1QUkYgdG8gZGVyaXZlIE1TSywgRU1TSywgSVY/DQoNCiAgS2V5X01hdGVyaWFs ID0gVExTLVBSRi0xMjgobWFzdGVyX3NlY3JldCwgImNsaWVudCBFQVAgZW5jcnlwdGlvbiIsDQog ICAgICAgICAgICAgICAgICAgICBjbGllbnQucmFuZG9tIHx8IHNlcnZlci5yYW5kb20pDQogICAg ICAgICAgICAgICAgICAgICANClRoaXMgd291bGQgbWVhbiB0aGF0IHRoZSBFQVAtVExTIGNvZGUg d291bGQgaGF2ZSB0byBpbXBsZW1lbnQgdGhlIFRMUy1QUkYsIHRoZSBUTFMgbGlicmFyeSB3b3Vs ZCBhbHNvIG5lZWQgdG8gYmUgbW9kaWZpZWQgdG8gZW5hYmxlIGV4dHJhY3Rpb24gb2YgbWFzdGVy X3NlY3JldCwgY2xpZW50LnJhbmRvbSwgYW5kIHNlcnZlci5yYW5kb20uIFRoYXQgc2VlbXMgbGlr ZSBhIHZlcnkgYmFkIHNvbHV0aW9uLg0KDQpBbHNvIHdvdWxkIHN1Y2ggYW4gaW1wbGVtZW50YXRp b24gdXNlIHRoZSBUTFMgMS4yIG9yIFRMUyAxLjEgUFJGPw0KDQoyLiBUcnkgdG8gZ3Vlc3MgaG93 IHRvIGRvIHNvbWV0aGluZyBzaW1pbGFyIHdpdGggdGhlIFRMUyBIS0RGIGNvbnN0cnVjdGlvbg0K DQogIEtleV9NYXRlcmlhbCA9IERlcml2ZS1TZWNyZXQoTWFzdGVyIFNlY3JldCwgImNsaWVudCBF QVAgZW5jcnlwdGlvbiIsIGNsaWVudC5yYW5kb20gfHwgc2VydmVyLnJhbmRvbSkNCg0KMy4gT3Ig ZXF1YWxseSBsaWtlbHkgcmVwbGFjZSBDbGllbnRIZWxsby5yYW5kb20gKyBTZXJ2ZXJIZWxsby5y YW5kb20gd2l0aCBDbGllbnRIZWxsby4uLnNlcnZlciBGaW5pc2hlZCBhcyBkb25lIGluIGFsbCBr ZXkgZGVyaXZhdGlvbiBpbiBUTFMgMS4zICAgIA0KDQogIEtleV9NYXRlcmlhbCA9IERlcml2ZS1T ZWNyZXQoTWFzdGVyIFNlY3JldCwgImNsaWVudCBFQVAgZW5jcnlwdGlvbiIsIENsaWVudEhlbGxv Li4uc2VydmVyIEZpbmlzaGVkKQ0KDQo0LiBPciBkbyBpdCB0aGUgbmF0dXJhbCB3YXkgaW4gVExT IDEuMyAoVXNlZCBpbiBlLmcuIGRyYWZ0LWlldGYtcXVpYy10bHMpIA0KDQogIEtleV9NYXRlcmlh bCA9IFRMUy1FeHBvcnRlcigiY2xpZW50IEVBUCBlbmNyeXB0aW9uIiwgIiIsIDEyOCkNCg0KSSB0 aGluayB0aGlzIGlzIGV4dHJlbWVseSBsaWtlbHkgdG8gbGVhZCB0byBpbmNvbXBhdGlibGUgaW1w bGVtZW50YXRpb25zIG9mIEVBUC1UTFMgd2l0aCBUTFMgMS4zIHVubGVzcyBJRVRGIGdpdmVzIGd1 aWRhbmNlLiBNeSB2aWV3IGlzIHRoYXQgYSBkb2N1bWVudCBpcyBuZWVkZWQgc3RhdGluZyBob3cg dGhlIGtleSBkZXJpdmF0aW9uIGlzIGRvbmUgd2hlbiBFQVAtVExTIGlzIHVzZWQgd2l0aCBUTFMg MS4zLCBteSBwcm9wb3NhbCB3b3VsZCBiZToNCg0KICBLZXlfTWF0ZXJpYWwgPSBUTFMtRXhwb3J0 ZXIoImNsaWVudCBFQVAgZW5jcnlwdGlvbiIsICIiLCAxMjgpDQoNCg0KPkluIGFkZGl0aW9uLCB5 b3VyIG90aGVyIGFyZ3VtZW50cyBhcmUgaGFuZC13YXZpbmcsIGFuZCBkb24ndCBwcm92aWRlIGNv bmNyZXRlID5kZXRhaWxzIHRvIGJhY2sgdXAgeW91ciBwb3NpdGlvbi4gIEhhdmluZyBjb25jcmV0 ZSBkZXRhaWxzIHdvdWxkIGhlbHAuDQoNCkkgaG9wZSB0aGF0IHRoZSBkZXRhaWxzIGFib3ZlIGls bHVzdHJhdGUgd2h5IEkgdGhpbmsgYW4gc2hvcnQgZG9jdW1lbnQgZGVzY3JpYmluZyBob3cgdG8g dXNlIEVBUC1UTFMgd2l0aCBUTFMgMS4zIGlzIG5lZWRlZC4gSSB3aWxsIHVwZGF0ZSB0aGUgZG9j dW1lbnQgYWxpZ25pbmcgd2l0aCB0aGUgY29tbWVudHMgcmVjZWl2ZWQ6DQoNCi0gInVwZGF0ZSIg aW5zdGVhZCBvZiAib2Jzb2xldGUiIGFuZCBhbHNvIG1ha2luZyBjbGVhciB0aGF0IGFuIGltcGxh bWVudGF0aW9uIGZvbGxvd2luZyB0aGUgZG9jdW1lbnQgaXMgc3RpbGwgY29tcGF0aWJsZSB3aXRo IEVBUC1UTFMgd2l0aCBUTFMgMS4wICh1cCB0byB0aGUgYXBwbGljYXRpb24gdG8gZGVjaWRlKS4g VGhpcyBtZWFucyB0aGF0IHRoZSBFQVAtVExTIHdpdGggVExTIDEuMyBkb2N1bWVudCBjYW4gYmUg c2hvcnRlciB0b3RhbGx5IGF2b2lkaW5nIG92ZXJsYXAgd2l0aCBSRkM1MjE2LCBvbmx5IGRlc2Ny aWJpbmcgYW55IGRpZmZlcmVuY2Ugd2hlbiB1c2lnbiBUTFMgMS4zLg0KDQotIEhpZ2hsaWdodCB3 aGljaCBwYXJ0cyByZWxldmFudCBmb3IgRUFQLVRMUyB0aGF0IGNoYW5nZXMgaW4gVExTIDEuMyBh bmQgd2h5IGFuIHVwZGF0ZSBpcyBuZWVkZWQuDQoNCi0gQWRkIGluZm9ybWF0aW9uIG9uIGhvdyBL ZXlfTWF0ZXJpYWwgYW5kIElWIGlzIGRlcml2ZWQgd2hlbiB1c2luZyBFQVAtVExTIHdpdGggVExT IDEuMy4gUmVmZXJpbmcgdG8gUkZDNTIxNiBmb3IgdG8gZ2V0IE1TSywgRU1TSywgZXRjLCBmcm9t IEtleWluZ19NYXRlcmlhbC4NCg0KQ2hlZXJzLA0KSm9obg0KDQoNCg0KDQoNCg0K From nobody Fri Dec 1 05:58:19 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD97128D44; Fri, 1 Dec 2017 05:58:05 -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 67OmPCCPYAby; Fri, 1 Dec 2017 05:58:03 -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 B8CAE126DFE; Fri, 1 Dec 2017 05:58:02 -0800 (PST) X-AuditID: c1b4fb25-36dff70000000151-99-5a215fe8e754 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 54.6B.00337.8EF512A5; Fri, 1 Dec 2017 14:58:00 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 14:58:00 +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=wBP7e2wXgWYJuEPjhW8GLIrK4h7CWHzdC5JeJfxMkkw=; b=m+WK8SmKy8cRwTqOcingu4B7CBVlE87t/hCzu9v0CtMix1CxmeXLfFdzEaVb0vvduKb3pmLxliu04iXGcMU+EF+4aaaFywe6QjPLiLaQ8GpAh5vrT0JITKsBnS8JEOjcP28CLz8GmO/lvTQKwSvg8De7HgO+gLdCV553Gko+YWE= Received: from DB5PR0701MB2005.eurprd07.prod.outlook.com (10.167.228.147) by DB6PR07MB3270.eurprd07.prod.outlook.com (10.175.233.29) 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:57:58 +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:57:58 +0000 From: John Mattsson To: Bernard Aboba , Jari Arkko , Mohit Sethi M , "reap@ietf.org" , "saag@ietf.org" , "emu@ietf.org" Thread-Topic: [Reap] [Emu] EAP - TLS 1.3 Thread-Index: AQHTaqxkTIQHAGf0302lfanrf7k7pg== Date: Fri, 1 Dec 2017 13:57:58 +0000 Message-ID: <8C04ED3B-0D84-443B-8853-3EBD950C1732@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 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.47.185] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3270; 6:5HLOip5+XrVZJZDUZ1CjEWMO0LpGeCFMC6VUZYeHceutJdfO3CR2L6JqLy0z+1BfxcLFc1sJD4OVUZlYFSbMVIUhxTwc6nWiuzpf5GQjq0SbVIKD4dNQNYsxx2oSYhdk8DjNNVC2ZwfWw4UeTchXekBhA7fwT7snj24D+hsavFikx05giGpi91tDyL34w9orFtMdMxWS1LGdH6EmTU6roOvmNpyGhj7Fwo4/n9IAoHtuf6z0/L1SbZ+7hTGyb+xCBN7Na23CyaSz9b+DgMInncxIJU29piyzceRUXGqqL2u3ICC04JEPjInhloZbg1gO1m4hDZKmwLBokxc/sQFN+ke+TmaM1B1Neda6qJm9esc=; 5:B3wuv4UFVlPPQw8DtuX0nkl5vDq/bdHoVBNeg9Wes9ejMMOsSZL1o1bGbR8YuInpkWKhB+qluzKrr/LJKyToNYJPT/sDAiGBPyF6U5omAKeburQjX0/EThiNk/urB+zpd0QWaPJmBEVRl4Mc/5+kuYrB9ecYXTUF5TiIqTyNnNg=; 24:4uQNMgiKaerJnvXUX5PDkvsKHQh3NkAzafAcdkR+RMoc/hFgtmEOp0jEgOg6Vd9l1HzVVXjJ2tc3odN6nBGhCYiLqqJal0tvw8g6UAHf+J0=; 7:i/27peTXJsQUJ7JQ0Ad84Rmjfr464TVoElD4Zb9px6ibDzSCh69rJYJHouDf+4crXlKEiHCeUPUqjkYb/9vxkApJxMIkbLQRauTLT6dJgtIa06+3ms67aref/9+51JUCYGmPtCIEUUy4xyVjk6RtENaQva4idrTq5o3Gv0YlGq0HnAZgG9QNot959Cm6Vr6IJcpCD+Uye7sQilKvpD7C0Y3Im5FfvLmfOBZLU7WCvuZtqsC3xruIo6gou16q9Qzl x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 685a6b2b-af22-4d4c-f51c-08d538c387a6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:DB6PR07MB3270; x-ms-traffictypediagnostic: DB6PR07MB3270: x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231022)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011); SRVR:DB6PR07MB3270; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR07MB3270; x-forefront-prvs: 05087F0C24 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(366004)(346002)(39860400002)(24454002)(51444003)(199003)(189002)(305945005)(8676002)(7736002)(81156014)(68736007)(6486002)(83506002)(229853002)(81166006)(99286004)(6506006)(8936002)(66066001)(14454004)(478600001)(58126008)(110136005)(101416001)(3846002)(5660300001)(2201001)(316002)(54356011)(189998001)(36756003)(6436002)(6116002)(97736004)(102836003)(2501003)(83716003)(3660700001)(2900100001)(3280700002)(53936002)(39060400002)(86362001)(82746002)(5250100002)(106356001)(33656002)(25786009)(6512007)(2906002)(105586002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3270; H:DB5PR0701MB2005.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <93E298844DEBA0469B42C7966A02578C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 685a6b2b-af22-4d4c-f51c-08d538c387a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 13:57:58.7499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3270 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUyM2K7se6LeMUog+W7TS027PvPbHFs/VoW i3Mrj7NYTOnvZHJg8dg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MiZ/6mMqOCde0XIjuIGx QbyLkZNDQsBEYvfeS4xdjFwcQgKHGSXWbrrGCpIQEjjOKPGkRR8kwSLQyyxx79o3ZoiqGUwS 85YtZoOoesYocfqyHIjNJmAgMXdPAxtIkYjAE0aJzgX9zCAJYQF1ifX3tjOB2CICGhIPv+9j hLD1JLb+PAO2jkVARWL6/G6wobwC9hLvmhrB6hkFxCS+n1oDZjMLiEs0fVnJCnG3gMSSPeeZ IWxRiZeP/4HFRYFm/tv5Gqo3VqK1dTpUvaLE0qPToGxZiUvzu8F+lhA4xC7x7foiFogE0EET 3zJC2L4SJ5ZsZoEoWsIoMffqDqiElkTH5qtQto3EjO7pUFdkSxxrecIEV3NkFhNE8wJmiQf/ b0NtkJG4vmsv1NSHrBJPnu9lnsCoNwvJe7MYOYBsTYn1u/Qhwh4SJxub2CBsRYkp3Q/ZZ4FD SVDi5MwnLAsYWVcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBCaZg1t+q+5gvPzG8RCjAAej Eg+vjL9ilBBrYllxZe4hRgkOZiUR3lg/oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC 6YklqdmpqQWpRTBZJg5OqQZGtt+K7lJ5aoFiBQb7WHu2OTfWK85p3HH0sYpsMk9j3ixPQc/z nBMefTS7f8zhRjxbPl/Lvb+fStQPBbn1vLhnrRm2z97WwvvI7lfrD3U9SDzNmPjp+5WwuVue hGi+fuuUnrKQa6aO3a59xtzvvI9bu/i6qiVtD57wtf4370mz+pP8O+1PqDEosRRnJBpqMRcV JwIAp19PCS4DAAA= Archived-At: Subject: Re: [Emu] [Reap] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 13:58:05 -0000 SGkgQmVybmFyZCwNCg0KT24gVGh1LCBOb3YgMTksIDIwMTcsIEJlcm5hcmQgQWJvYmEgd3JvdGU6 DQoNCj5UaGUgYmlnIHF1ZXN0aW9uIGlzICJXaHkgbm90IGNyZWF0ZSBhIG5ldyBFQVAgbWV0aG9k Ij/CoA0KDQo+VGhlIG92ZXJhbGwgaW50ZW50IHNlZW1zIHRvIGJlIHRvIGNyZWF0ZSBhbiBwcmUt c2hhcmVkIGtleSBFQVAgbWV0aG9kIG9wdGltaXplZCBmb3IgNUcsDQo+YmFzZWQgb24gRUFQLVRM UyB2MS4zLsKgwqANCg0KSSBkb27igJl0IGtub3cgd2h5IHlvdSBoYXZlIGdvdHRlbiB0aGUgaWRl YSB0aGF0IHRoZSBpbnRlbnQgaXMgcHJlLXNoYXJlZCBrZXkgYXV0aGVudGljYXRpb24uIDNHUFAg aGFzIG5vIGludGVyZXN0IGluIEVBUC1UTFMgd2l0aCBwcmUtc2hhcmVkIGtleSBhdXRoZW50aWNh dGlvbi4gM0dQUCB3YW50cyB0byB1c2UgRUFQLVRMUyB3aXRoIGNlcnRpZmljYXRlIGF1dGhlbnRp Y2F0aW9uLg0KDQo+U2luY2UgdGhlIHByb3RvY29sIGRlc2NyaWJlZCB3aWxsIG5vdCBpbnRlcm9w ZXJhdGUgd2l0aCBhbnkgb2YgdGhlIGV4aXN0aW5nIDIrIGJpbGxpb24NCj5FQVAtVExTIGRldmlj ZXMsIHdoeSByZXVzZSB0aGUgRUFQLVRMUyBjb2RlIHBvaW50IG9yIEVBUC1UTFMgbmFtZT/CoCDC oFdoYXQgaGFzIGJlZW4NCj5kZXNjcmliZWQgaXMgYW4gZW50aXJlbHkgZGlzdGluY3QgYXV0aGVu dGljYXRpb24gbWV0aG9kLCBub3QgYSAiY2xhcmlmaWNhdGlvbiIgdG8gYW4NCj5leGlzdGluZyBz cGVjaWZpY2F0aW9uLg0KDQo+SW4gZmFjdCwgZnJvbSBob3cgaXQgaGFzIGJlZW4gZGVzY3JpYmVk LCBpdCB3b3VsZCBhcHBlYXIgdGhhdCB0aGUgbmV3IHByb3RvY29sIGlzIG9ubHkgZm9yIHVzZQ0K PndpdGggbmV3IGRldmljZXMgc3VwcG9ydGluZyA1RyBhbmQgbmV3IDVHIHNlcnZlcnMgc3VwcG9y dGluZyB0aGUgbmV3IG1ldGhvZC7CoCBJbiB3aGljaCBjYXNlLA0KPmlmIHRoZSBuZXcgbWV0aG9k IGlzIG5vdCBmb3IgZ2VuZXJhbCB1c2Ugb24gdGhlIEludGVybmV0LCB3aHkgY2FuJ3QgM0dQUCBq dXN0IGRlZmluZSB0aGUgbWV0aG9kID50aGVtc2VsdmVzIGFuZCBhbGxvY2F0ZSB0aGVpciBvd24g cHJpdmF0ZSBFQVAgdHlwZSBjb2RlP8KgDQoNCkkgZG9u4oCZdCBrbm93IHdoeSB5b3UgaGFzIGNv bWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCB0aGlzIHdvdWxkIG5vdCBpbnRlcm9wZXJhdGUgd2l0 aCBleGlzdGluZyBFQVAtVExTIGRldmljZXMuIFRMUyAxLjMgZS5nLiBvYnNvbGV0ZXMgVExTIDEu MiBidXQgc3RpbGwgaW50ZXJvcGVyYXRlIGp1c3QgZmluZSB3aXRoIGFsbCBvbGQgdmVyc2lvbnMg b2YgVExTLiAzR1BQIHBsYW5zIHRvIHVzZSBFQVAtVExTIChSRkM1MjE2KSB3aXRoIGN1cnJlbnQg dmVyc2lvbnMgb2YgVExTLiBJbiB0aGUgZnV0dXJlLCAzR1BQIChhbmQgcHJvYmFibHkgbWFueSBv dGhlcnMpIHdvdWxkIGxpa2UgdG8gdXNlIEVBUC1UTFMgd2l0aCBUTFMgMS4zLg0KDQozR1BQIGhh cyBubyBzcGVjaWFsIHJlcXVpcmVtZW50cyB3aGVuIGl0IGNvbWVzIHRvIHVzaW5nIEVBUC1UTFMg d2l0aCBUTFMgMS4zLCBhbmQgd291bGQgbGlrZSB0byBiZSBpbnRlcm9wZXJhYmxlIHdpdGggYWxs IGltcGxlbWVudGF0aW9ucyBvZiBFQVAtVExTIHdpdGggVExTIDEuMy4gVGhlIG1ham9yIHBvaW50 IHdpdGggRUFQLVRMUyBpcyB0byB1c2UgdGhlIFRMUyB2ZXJzaW9uIG5lZ290aWF0aW9uLCBkZWZp bmluZyBFQVAtVExTIHdpdGggVExTIDEuMyBhcyBhIGRpZmZlcmVudCBjb2RlIGlzIG5vdCBhIGdv b2QgaWRlYS4NCg0KTXkgdmlldyBpcyB0aGF0IGl0IGlzIG5vdCBjbGVhciBob3cgdGhlIGtleSBk ZXJpdmF0aW9uIGlzIGRvbmUgd2hlbiBFQVAtVExTIGlzIHVzZWQgd2l0aCBUTFMgMS4zLiBOb24t aW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgd291bGQgbm90IGJlIGdvb2QgZm9yIHRoZSBJ bnRlcm5ldC4gRnVydGhlcm1vcmUsIGFuIGltcGxlbWVudGF0aW9uIG9mIEVBUC1UTFMgd2l0aCBU TFMgMS4zIHdvdWxkIGJyZWFrIGEgX2xhcmdlXyBhbW91bnQgb2YgTVVTVHMgaW4gUkZDNTEyNiBh cyBUTFMgMS4zIGNoYW5nZXMgYSBsb3QgZnJvbSBUTFMgMS4wIOKAkyAxLjIuIEkgdGhpbmsgdGhh dCBhbiB1cGRhdGUgdG8gUkZDNTIxNSBpcyBuZWVkZWQgaXJyZXNwZWN0aXZlbHkgb2YgM0dQUCB1 c2luZyBFQVAtVExTIG9yIG5vdC4NCg0KQ2hlZXJzLA0KSm9obg0KDQo= From nobody Fri Dec 1 06:10:53 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD07128BB7 for ; Fri, 1 Dec 2017 06:10:51 -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 cLc2WpB0EC40 for ; Fri, 1 Dec 2017 06:10:49 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCC71289B0 for ; Fri, 1 Dec 2017 06:10:49 -0800 (PST) Received: from [192.168.20.53] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id 6A48A161; Fri, 1 Dec 2017 14:10:48 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 1 Dec 2017 09:10:46 -0500 Cc: Mohit Sethi M , "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5CC374EB-51C4-419E-BF2C-E0C04FF0ED24@deployingradius.com> References: To: John Mattsson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Emu] [Reap] EAP - TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 14:10:51 -0000 (trimming down the CC list to EMU) > On Dec 1, 2017, at 8:16 AM, John Mattsson = wrote: >=20 > 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. Then the suggestion would be to write a document "EAP-TLS with TLS = 1.3", that updates RFC 5216. The concern was (again), that the proposal was to *obsolete* 5216, and = *replace* it with a mandate to use TLS 1.3. That's just not going to = happen. > Yes, procedural aspects seem to be a large concern, but =E2=80=9Cobsolet= e=E2=80=9D does not forbid anyone from using EAP-TLS with TLS 1.0. The proposal mandated TLS 1.3. That *would* forbid usage of TLS 1.0. = i.e. 5216 has MUST language which is now inappropriate for TLS 1.3, the = proposal had MUST language which was inappropriate for TLS 1.0, 1.1, and = 1.2. > 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 = =E2=80=9Cupdate=E2=80=9D 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. If you're *adding* language which shows how to use TLS 1.3 with = EAP-TLS, then the correct process is to "update" 5216. And the best way = to do that is to just have a proposal describing how to use EAP-TLS with = TLS 1.3. There's no need to change copy 5216 and edit it. You can just = reference 5216, and describe the *differences* for TLS 1.3. > 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? That's what standards are for... > 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. Which is why I was confused that the proposal *replaced* 5216 in it's = entirety, and said that implementations MUST support TLS 1.3. > I will update the document aligning with the comments received: >=20 > - "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. >=20 > - Highlight which parts relevant for EAP-TLS that changes in TLS 1.3 = and why an update is needed. >=20 > - 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. That's the best approach. Alan DeKok. From nobody Fri Dec 15 06:05:32 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA3F128BB6 for ; Fri, 15 Dec 2017 06:05:31 -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 6i2dYS0UGAmN for ; Fri, 15 Dec 2017 06:05:15 -0800 (PST) Received: from li674-96.members.linode.com (mail.w1.fi [212.71.239.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56ECC126C25 for ; Fri, 15 Dec 2017 06:05:15 -0800 (PST) Received: from jm (37-136-100-69.rev.dnainternet.fi [37.136.100.69]) by li674-96.members.linode.com (Postfix) with ESMTPSA id CE5D511196 for ; Fri, 15 Dec 2017 14:05:11 +0000 (UTC) Received: by jm (sSMTP sendmail emulation); Fri, 15 Dec 2017 16:05:05 +0200 Date: Fri, 15 Dec 2017 16:05:05 +0200 From: Jouni Malinen To: emu@ietf.org Message-ID: <20171215140505.GA25653@w1.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Emu] EAP-SIM/AKA and missing Session-Id derivation rules for fast reauth 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, 15 Dec 2017 14:05:32 -0000 It looks like EAP Session-Id derivation has not been defined for EAP-SIM, EAP-AKA, and EAP-AKA' when using the fast re-authentication exchange instead of full authentication. RFC 5247 defines Session-Id for these EAP methods, but that derivation is only applicable for the full authentication case. I filed an errata on RFC 4247 about a half a year ago, but have not received any kind of response to this so far: https://www.rfc-editor.org/errata_search.php?rfc=5247 Since it looks likely for the FILS authentication to get deployed in the near term and that needing Session-Id for ERP to work, it would be important to get this resolved with a clearly defined and agreed derivation rules to allow fast re-authentication cases to be used to derive ERP key hierarchy. Would someone on this list have sufficient interest to reviewing the filed errata and/or suggest ways on how to get this moving ahead? I'm copy-pasting that errata information below for easier access for reviewing/commenting: Status: Reported Type: Technical Reported By: Jouni Malinen Date Reported: 2017-05-07 Section Appendix A says: EAP-AKA EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the concatenation of the EAP Type Code (0x17) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute: Session-Id = 0x17 || RAND || AUTN It should say: EAP-AKA EAP-AKA is defined in [RFC4187]. When using full authentication, the EAP-AKA Session-Id is the concatenation of the EAP Type Code (0x17) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute: Session-Id = 0x17 || RAND || AUTN When using fast re-authentication, the EAP-AKA Session-Id is the concatenation of the EAP Type Code (0x17) with the contents of the NONCE_S field from the AT_NONCE_S attribute, followed by the contents of the MAC field from the AT_MAC attribute from EAP-Request/AKA-Reauthentication: Session-Id = 0x17 || NONCE_S || MAC Notes: RFC 5247 was supposed to define exported parameters for existing EAP methods in Appendix A. The way Session-Id was defined for EAP-AKA and EAP-SIM works only for the full authentication case, i.e., it cannot be used when the optional fast re-authentication case is used since the used parameters (RAND, AUTN, NONCE_MT) are not used in the fast re-authentication case. Based on RFC 4187 chapter 5.2 (and similar chapter in RFC 4186), NONCE_S corresponds to RAND and MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN. That would seem to imply that the Session-Id could be defined using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT. The corrected text in this errata shows the changes for EAP-AKA. Similar changes should be done for EAP-SIM (replace RAND || NONCE_MT with NONCE_S || MAC for fast re-authentication). It should be noted that EAP-AKA' (RFC 5448) specification did not follow the MUST requirement in RFC 5247, i.e., it did not define Session-Id derivation. That could be done in an update of RFC 5247 with a clone of EAP-AKA design. In addition, RFC 5247 did not define Session-Id definition for PEAP and there does not seem to exist any IETF RFC which such definition. That could also be included in RFC 5247 update and done similarly to EAP-TLS (Session-Id = EAP type || client.random || server.random). It would be good to have a clear IETF reference for these details since EAP Session-Id is needed for ERP (RFC 6696) and that is now seeing additional implementation and deployment interest as a component of FILS authentication (IEEE 802.11ai). Same definition of EAP Session-Id is needed to make FILS shared key authentication implementation interoperable. -- Jouni Malinen PGP id EFC895FA From nobody Fri Dec 15 08:07:35 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB14E126D3F for ; Fri, 15 Dec 2017 08:07:33 -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 jgjUHklFyyfg for ; Fri, 15 Dec 2017 08:07:31 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 87C1A1293E0 for ; Fri, 15 Dec 2017 08:07:30 -0800 (PST) Received: from [192.168.20.47] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id E775516A; Fri, 15 Dec 2017 16:07:28 +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: <20171215140505.GA25653@w1.fi> Date: Fri, 15 Dec 2017 11:07:28 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3F674CCD-B241-4B96-A2C3-FDDD106F4A75@deployingradius.com> References: <20171215140505.GA25653@w1.fi> To: Jouni Malinen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Emu] EAP-SIM/AKA and missing Session-Id derivation rules for fast reauth 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, 15 Dec 2017 16:07:33 -0000 On Dec 15, 2017, at 9:05 AM, Jouni Malinen wrote: >=20 > It looks like EAP Session-Id derivation has not been defined for > EAP-SIM, EAP-AKA, and EAP-AKA' when using the fast re-authentication > exchange instead of full authentication. RFC 5247 defines Session-Id = for > these EAP methods, but that derivation is only applicable for the full > authentication case. >=20 > I filed an errata on RFC 4247 about a half a year ago, but have not > received any kind of response to this so far: > https://www.rfc-editor.org/errata_search.php?rfc=3D5247 I think EMU is the best place to discuss this. I don't think anyone = had opinions, TBH. > Since it looks likely for the FILS authentication to get deployed in = the > near term and that needing Session-Id for ERP to work, it would be > important to get this resolved with a clearly defined and agreed > derivation rules to allow fast re-authentication cases to be used to > derive ERP key hierarchy. OK. That raises the priority of the problem. > Would someone on this list have sufficient interest to reviewing the > filed errata and/or suggest ways on how to get this moving ahead? I'm > copy-pasting that errata information below for easier access for > reviewing/commenting: I'll give my $002. The authors of RFC 5247 may also have opinions. > It should say: >=20 > EAP-AKA >=20 > EAP-AKA is defined in [RFC4187]. When using full authentication, > the EAP-AKA Session-Id is the > concatenation of the EAP Type Code (0x17) with the contents of = the > RAND field from the AT_RAND attribute, followed by the contents = of > the AUTN field in the AT_AUTN attribute: >=20 > Session-Id =3D 0x17 || RAND || AUTN >=20 > When using fast re-authentication, the EAP-AKA Session-Id is the > concatenation of the EAP Type Code (0x17) with the contents of = the > NONCE_S field from the AT_NONCE_S attribute, followed by the > contents of the MAC field from the AT_MAC attribute from > EAP-Request/AKA-Reauthentication: >=20 > Session-Id =3D 0x17 || NONCE_S || MAC The one question here is whether or not this definition is new, or is = taken from an existing reference? > Notes: >=20 > RFC 5247 was supposed to define exported parameters for existing EAP > methods in Appendix A. The way Session-Id was defined for EAP-AKA and > EAP-SIM works only for the full authentication case, i.e., it cannot = be > used when the optional fast re-authentication case is used since the > used parameters (RAND, AUTN, NONCE_MT) are not used in the fast > re-authentication case. Based on RFC 4187 chapter 5.2 (and similar > chapter in RFC 4186), NONCE_S corresponds to RAND and MAC in > EAP-Request/AKA-Reauthentication corresponds to AUTN. That would seem = to > imply that the Session-Id could be defined using NONCE_S and MAC = instead > of RAND and AUTN/NONCE_MT. Hmm... so it's a new definition. That's an issue. I don't think we = can define new specifications in an errata. The ADs may disagree, of course. > The corrected text in this errata shows the changes for EAP-AKA. = Similar > changes should be done for EAP-SIM (replace RAND || NONCE_MT with > NONCE_S || MAC for fast re-authentication). >=20 > It should be noted that EAP-AKA' (RFC 5448) specification did not = follow > the MUST requirement in RFC 5247, i.e., it did not define Session-Id > derivation. That could be done in an update of RFC 5247 with a clone = of > EAP-AKA design. I would suggest filing a separate errata for RFC 5448. Please = reference the one for RFC 5247. > In addition, RFC 5247 did not define Session-Id definition for PEAP = and > there does not seem to exist any IETF RFC which such definition. That > could also be included in RFC 5247 update and done similarly to = EAP-TLS > (Session-Id =3D EAP type || client.random || server.random). That makes sense. > It would be good to have a clear IETF reference for these details = since > EAP Session-Id is needed for ERP (RFC 6696) and that is now seeing > additional implementation and deployment interest as a component of = FILS > authentication (IEEE 802.11ai). Same definition of EAP Session-Id is > needed to make FILS shared key authentication implementation > interoperable.=20 My $0.02 is to publish an individual draft. It should update the = previous RFCs, and just define the missing pieces. That way the issue gets fixed in something other than errata, without = re-publishing all of the EAP type definitions. Since there's no more EMU WG, this document can't be processed through = a WG. But the discussion should still be on this list. I think also = that it could be sponsored by an AD, and could be published quickly. To summarize: - the errata should probably be held for a document update - a similar errata should be filed for 5448 - a new document should define the session IDs - hopefully only a 3-4 page document with boilerplate.. Alan DeKok. From nobody Thu Dec 21 05:29:15 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADB612D86D for ; Thu, 21 Dec 2017 05:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MlyIJJm2-ghu for ; Thu, 21 Dec 2017 05:29:11 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3294412D86B for ; Thu, 21 Dec 2017 05:29:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 12C572D19C; Thu, 21 Dec 2017 15:29:09 +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 LF2w4d5jNAQk; Thu, 21 Dec 2017 15:29:08 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 906E32CD0D; Thu, 21 Dec 2017 15:29:08 +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: <3F674CCD-B241-4B96-A2C3-FDDD106F4A75@deployingradius.com> Date: Thu, 21 Dec 2017 15:29:08 +0200 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5F653997-AFEF-4A01-A461-2482BC937340@piuha.net> References: <20171215140505.GA25653@w1.fi> <3F674CCD-B241-4B96-A2C3-FDDD106F4A75@deployingradius.com> To: Alan DeKok , Jouni Malinen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Emu] EAP-SIM/AKA and missing Session-Id derivation rules for fast reauth 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, 21 Dec 2017 13:29:13 -0000 Thanks for bringing this up, Jouni. I agree that this need to be = specified somehow. (Another possible way to document this is to put it in the revision that = we were planning for EAP-AKA=E2=80=99.) Jari From nobody Thu Dec 21 05:41:04 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF38212D7EE for ; Thu, 21 Dec 2017 05:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 UN0LT2CnxsFK for ; Thu, 21 Dec 2017 05:40:59 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2F26F120725 for ; Thu, 21 Dec 2017 05:40:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 996E62D19C for ; Thu, 21 Dec 2017 15:40:57 +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 ZDIzbL7q4jeU for ; Thu, 21 Dec 2017 15:40:56 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 55D512CD0D for ; Thu, 21 Dec 2017 15:40:56 +0200 (EET) (envelope-from jari.arkko@piuha.net) From: Jari Arkko Content-Type: multipart/alternative; boundary="Apple-Mail=_CB216A18-AF95-4710-B97D-F529C704DFD9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <4D44B5F1-AE1E-4564-8366-31903B76FA9D@piuha.net> Date: Thu, 21 Dec 2017 15:40:55 +0200 To: emu@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [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: Thu, 21 Dec 2017 13:41:04 -0000 --Apple-Mail=_CB216A18-AF95-4710-B97D-F529C704DFD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99ve been thinking of what to do with the EAP work that got = discussed both in the SAAG meeting last time (my drafts), as well on the = list. The latter was more on the EAP-TLS side, and it seems that the = discussion has converged to a reasonable direction recently. Wondering how we could get the work moving forward. The first thought = that came to my mind was to start a small working group. Thoughts? A = very drafty idea of what it would do is below. Comments appreciated. =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. The specification should also be updated to define session identifiers for the fast- re-authentication mode, for which there is an errata against the existing RFCs. 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. - 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. - Potentially something else, too, but I have not seen requests for other things yet. It would be beneficial to keep the WG scope small. 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=_CB216A18-AF95-4710-B97D-F529C704DFD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80= =99ve been thinking of what to do with the EAP work that got discussed = both in the SAAG meeting last time (my drafts), as well on the list. The = latter was more on the EAP-TLS side, and it seems that the discussion = has converged to a reasonable direction recently.

Wondering how we could get the work moving forward. The first = thought that came to my mind was to start a small working group. = Thoughts?  A very drafty idea of what it would do is below. = Comments appreciated.

=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. The specification
    =  should also be updated to define session identifiers for the = fast-
     re-authentication mode, = for which there is an errata against the
  =    existing RFCs.

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

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

   - = Potentially something else, too, but I have not seen requests
     for other things yet. It would = be beneficial to keep the WG scope
     small.

   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=_CB216A18-AF95-4710-B97D-F529C704DFD9-- From nobody Thu Dec 21 06:01:43 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9847A12D870 for ; Thu, 21 Dec 2017 06:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 RRnjdV6BD0bs for ; Thu, 21 Dec 2017 06:01:39 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA0112D7F7 for ; Thu, 21 Dec 2017 06:01:39 -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 D23F36F7; Thu, 21 Dec 2017 14:01:37 +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: <4D44B5F1-AE1E-4564-8366-31903B76FA9D@piuha.net> Date: Thu, 21 Dec 2017 09:01:36 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <574BCF7A-8172-4B12-9FB2-96CD3E4ECD76@deployingradius.com> References: <4D44B5F1-AE1E-4564-8366-31903B76FA9D@piuha.net> To: Arkko Jari X-Mailer: Apple Mail (2.3124) 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: Thu, 21 Dec 2017 14:01:41 -0000 On Dec 21, 2017, at 8:40 AM, Jari Arkko wrote: >=20 > I=E2=80=99ve been thinking of what to do with the EAP work that got = discussed both in the SAAG meeting last time (my drafts), as well on the = list. The latter was more on the EAP-TLS side, and it seems that the = discussion has converged to a reasonable direction recently. >=20 > Wondering how we could get the work moving forward. The first thought = that came to my mind was to start a small working group. Thoughts? A = very drafty idea of what it would do is below. Comments appreciated. The Session ID also needs to be defined for SIM and AKA, as per = Jouni's comments. That doesn't fit in with AKA' changes. 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. Alan DeKok. From nobody Thu Dec 21 06:07:09 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD6B127337 for ; Thu, 21 Dec 2017 06:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bPn8XT_LxW9Z for ; Thu, 21 Dec 2017 06:07:06 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id BE416127078 for ; Thu, 21 Dec 2017 06:07:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C60BB2D19C; Thu, 21 Dec 2017 16:07:04 +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 e9pzAjDXeMOX; Thu, 21 Dec 2017 16:07:04 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 3C3992CD0D; Thu, 21 Dec 2017 16:07:04 +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: <574BCF7A-8172-4B12-9FB2-96CD3E4ECD76@deployingradius.com> Date: Thu, 21 Dec 2017 16:07:03 +0200 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <78D280C5-865B-4655-B7A2-52200D4CEC69@piuha.net> References: <4D44B5F1-AE1E-4564-8366-31903B76FA9D@piuha.net> <574BCF7A-8172-4B12-9FB2-96CD3E4ECD76@deployingradius.com> To: Alan DeKok 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: Thu, 21 Dec 2017 14:07:08 -0000 > The Session ID also needs to be defined for SIM and AKA, as per = Jouni's comments. That doesn't fit in with AKA' changes. Yeah, I was thinking about that but didn=E2=80=99t go far enough. But = you=E2=80=99re right. Maybe this needs to be a separate item for = EAP-SIM. > 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. >=20 > 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. That=E2=80=99s interesting. Do you have any suggestions on what to do about this issue, or were you = thinking about just stating that implementations should not stop that = early in the exchange? Jari From nobody Thu Dec 21 06:40:38 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6BB124D68 for ; Thu, 21 Dec 2017 06:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 sKg2zLytBFTN for ; Thu, 21 Dec 2017 06:40:24 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7661C12D87C for ; Thu, 21 Dec 2017 06:40: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 09A3765C; Thu, 21 Dec 2017 14:40:00 +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: <78D280C5-865B-4655-B7A2-52200D4CEC69@piuha.net> Date: Thu, 21 Dec 2017 09:39:59 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <31DF2824-8EC9-4091-8341-A1C7A17750DC@deployingradius.com> References: <4D44B5F1-AE1E-4564-8366-31903B76FA9D@piuha.net> <574BCF7A-8172-4B12-9FB2-96CD3E4ECD76@deployingradius.com> <78D280C5-865B-4655-B7A2-52200D4CEC69@piuha.net> To: Arkko Jari X-Mailer: Apple Mail (2.3124) 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: Thu, 21 Dec 2017 14:40:27 -0000 On Dec 21, 2017, at 9:07 AM, Jari Arkko wrote: >=20 >> 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 > That=E2=80=99s interesting. >=20 > Do you have any suggestions on what to do about this issue, or were = you thinking about just stating that implementations should not stop = that early in the exchange? I think it's good for implementations to have limits on the number of = packets being exchanged. 40-50 is even a reasonable limit. The question I have is whether we can do anything to EAP-TLS to = address the issue. Answering that question requires a deeper dive into = TLS. Alan DeKok. From nobody Fri Dec 22 10:12:43 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BE4124B18 for ; Fri, 22 Dec 2017 10:12:40 -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 oUGJlzG7xsTe for ; Fri, 22 Dec 2017 10:12:38 -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 3B99012025C for ; Fri, 22 Dec 2017 10:12:38 -0800 (PST) X-AuditID: c1b4fb2d-b4dff70000007932-7a-5a3d4b1495a7 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9C.C1.31026.41B4D3A5; Fri, 22 Dec 2017 19:12:36 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 22 Dec 2017 19:12:36 +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=UCfgHzwwM3xh2alPdVPyKGkqpiwVmIkhoXS74ExM3Dg=; b=cweR/6q++TnnJ3aOD128s8Zy2LAxB6S/pckXaY843D81obyE0LelWn3duC/DpmDctjJ4vFl3uU1au7katp1dQIapGfT5F2588Z4PQxSmgCfU7EFUMYNITaYdepeLbzEHvhmGtC1fknEWNTSlOTryF5A/Krfc1XGmqbsQhSPP/WM= Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com (10.167.189.149) by HE1PR0701MB2187.eurprd07.prod.outlook.com (10.168.36.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.3; Fri, 22 Dec 2017 18:12:35 +0000 Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::e053:8a18:a6e0:70e4]) by HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::e053:8a18:a6e0:70e4%13]) with mapi id 15.20.0366.003; Fri, 22 Dec 2017 18:12:34 +0000 From: John Mattsson To: "emu@ietf.org" Thread-Topic: [Emu] Potential re-establishment of the EMU working group Thread-Index: AQHTe1BwxAh4XIWM7UqBYia8+Nl+0g== Date: Fri, 22 Dec 2017 18:12:34 +0000 Message-ID: <8712B7E8-D3DD-49F8-9F9C-2C267E519AAE@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: [82.214.50.105] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2187; 6:9As+D8fkT+IS3UhV4SvgtyYgWyQTy6Nco35ItqxXi635RUfi/+ymk/bX1t0J9Ekba5ZR8qz58LsHCpucx9j/F/AnoVTsVNK0FG/onUQh5WQtksDbn2+SgzYMzSpCbd2n6y8bpkY0rpjwABOvR7jtUH6MEWtDJudDcJz7TVnL9m5VqXwSmJ7dMSJNqoKqxqi1eWJyZmUVRlLkJUbOA8GIfx7g0P3YOiUA69HrsH+Zcigud0deoezEDi+KSG4aYi8enPyAfCwybgxgS8zg4IyFm8P3lBbgpZ/8Iff9x2CVWGKfWR2a+HML1lpd0LCLLDyb0i3PgfkqD3R1lH08Yx/SyKaC/xL0GRpJNDRdJr59Gu4=; 5:2V2pwxWEuD6H7eCfu4AiosWawaXloQrkRhob9bpku5dsANJc/Tfh/ZZzKpNWJPEMu8+FztJ607rr6pk2GaCb5Cfjz5Ch5840fyhmB5uGxrBoQwzTmcgSC7kBPnDOh77g7ejPDkbEQnVDxP9vR4oic7ouYn9i9KYTq0Z88G4xYz8=; 24:78g3CbXa82gDsaLozi5hC/0uiDWgwSi1Qe8YzZQ9DRooMgXRUGfi5ir8hCfnmVZF0owTxD79p9SSeZxe7SZROqFp6Khp88iXKSbVnsjO/U0=; 7:opfAXNDZv6rxdKcyqKocL01X0UoOvz5ksHPGZdkU4Z4Z+JFhoW+SkA0iSpzWcbCuRCR3eQDj/zJ9WwVyuUkydFGUuQFpJzeOlmwmJQRIpaetyZfII7uQQd/zmWLBFyDTCmX+WWWFaaIraJNqTMCydZFlKV3XkVas1XpHT+//OsEusGVSWzREbnLanO+8ypHy/Uwsjh8IBNwsu3L2JAy0jwhuRm2jqCXgpKpHJ8+B0h/2Zr3n2dn15nwxRbS/nnJQ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 94e1173a-a3af-414b-ec9d-08d54967939c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(3008031)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:HE1PR0701MB2187; x-ms-traffictypediagnostic: HE1PR0701MB2187: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(10201501046)(3002001)(93006095)(93001095)(6041268)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR0701MB2187; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB2187; x-forefront-prvs: 05299D545B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39380400002)(346002)(39860400002)(376002)(189003)(199004)(24454002)(14454004)(6246003)(229853002)(6436002)(53936002)(478600001)(5640700003)(6512007)(66066001)(6486002)(106356001)(3280700002)(36756003)(2906002)(105586002)(2351001)(1730700003)(82746002)(8676002)(81156014)(6116002)(2501003)(33656002)(81166006)(5660300001)(2900100001)(86362001)(83506002)(3660700001)(59450400001)(3846002)(5250100002)(83716003)(6506007)(58126008)(305945005)(6916009)(99286004)(8936002)(316002)(102836004)(68736007)(25786009)(7736002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2187; H:HE1PR0701MB2011.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: <29D042CD23E5E0489E0D1546D05FEDBE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 94e1173a-a3af-414b-ec9d-08d54967939c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2017 18:12:34.8380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2187 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42KZGbFdS1fE2zbK4OUMRYtj69eyODB6LFny kymAMYrLJiU1J7MstUjfLoEr437Hb7aCdxwVz1ZOYWxgvMDRxcjJISFgItE+uYOxi5GLQ0jg MKPEgcXvmSCcE4wStxohMiwCvcwSSy6fZYfIzGKS6O7vZYVwnjNKzFywiRVkGJuAgcTcPQ1s ILaIgKLEj0ttzCC2sICbxIWTq1gg4u4SZ1+B7ACx9STOXzrNDmKzCKhKdL/dBzaHV8BeYnP3 DbAaRgExie+n1oDZzALiEk1fVrJCHC4gsWTPeWYIW1Ti5eN/YHFRoJkvzlxjh+iNlWhtnQ5V ryjxZuZiRghbVuLS/G4o+wi7xNOpoRC2nsTWiW+h4r4Sn84+hurdwSixbXUuhK0jMa35NTuE nS/RPWsTVI2WRMeRWeCwkxBYwiyxqmUR1HEyEs9f7mKDsG+zSrzdKgNiCwmkSixf28o4gVF3 FpLfZjFyANmaEut36UOEPSQW3mhlhrAVJaZ0P2SfBQ4iQYmTM5+wLGBkXcUoWpxaXJybbmSs l1qUmVxcnJ+nl5dasokRmDoObvmtu4Nx9WvHQ4wCHIxKPLynPW2jhFgTy4orcw8xSnAwK4nw lp2wiRLiTUmsrEotyo8vKs1JLT7EKM3BoiTOe9KTN0pIID2xJDU7NbUgtQgmy8TBKdXAuELI kOnb1sRPXW/mLuf7VJWz8sAexjOOt2b9CJS5Pk9jdu2zCYdeZn4+8O7zsYPSmzZUq3tmnue7 ISK5b/Wqu3sWLw2IU0n0XflkLj97R+2H9CnXfws7vT654dgW+Rn1nGfd1p9Yr9338PfNpwFr qgoXOoRuYbn2qYgvpLr3TzgfL9erx1uZBOyUWIozEg21mIuKEwHpuKAsGQMAAA== 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: Fri, 22 Dec 2017 18:12:40 -0000 T24gRGVjIDIxLCAyMDE3LCBBbGFuIERlS29rIHdyb3RlOg0KDQo+VGhlIHF1ZXN0aW9uIEkgaGF2 ZSBpcyB3aGV0aGVyIHdlIGNhbiBkbyBhbnl0aGluZyB0byBFQVAtVExTIHRvIGFkZHJlc3MgdGhl IGlzc3VlLiAgQW5zd2VyaW5nIHRoYXQgcXVlc3Rpb24gPnJlcXVpcmVzIGEgZGVlcGVyIGRpdmUg aW50byBUTFMuDQoNCkluIFRMUyAxLjMsIEVDQyBpcyBtYW5kYXRvcnkgdG8gc3VwcG9ydC4gVGhp cyBkcmFzdGljYWxseSByZWR1Y2VzIHRoZSBzaXplcyBvZiBjZXJ0aWZpY2F0ZXMgYW5kIHNpZ25h dHVyZXMgKHB1YmxpYyBrZXkgc2l6ZXMgZnJvbSAzODQgYnl0ZXMgKFJTQSBhbmQgREhFKSB0byAz MiBieXRlcyAoRUNESEUpIGFuZCBzaWduYXR1cmVzIGZyb20gMzg0IGJ5dGVzIChSU0EpIHRvIDY0 IGJ5dGVzIChFQ0RTQSBhbmQgRWREU0EpICkuDQoNCkFueXRoaW5nIGZvciBvbGRlciB2ZXJzaW9u IG9mIFRMUyB3b3VsZCBoYXZlIHRvIGJlIHB1cmUgcmVjb21tZW5kYXRpb25zIG9yIGd1aWRhbmNl IHRvIHByZXNlcnZlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuIEkgdGhpbmsgd2Ugc2hvdWxkIHVw ZGF0ZSB0aGUgY2hhcnRlciB0byBjb3ZlciBndWlkYW5jZSBvbiBob3cgdG8gaGFuZGxlIGxhcmdl IGNlcnRpZmljYXRlcyBhbmQgbG9uZyBjZXJ0aWZpY2F0ZSBjaGFpbnMgaW4gRUFQLVRMUyB3aXRo IGFsbCB2ZXJzaW9ucyBvZiBUTFMuIFRoaXMgY291bGQgYmUgaGFuZGxlZCBpbiB0aGUgc2FtZSBi dWxsZXQgYXMg4oCcZ3VpZGFuY2Ugb3IgdXBkYXRlIHRvIGVuYWJsZSB0aGUgdXNlIG9mIFRMUyAx LjPigJ0uDQoNCkNoZWVycywNCkpvaG4gDQoNCg== From nobody Sat Dec 23 04:15:48 2017 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65CC129966 for ; Sat, 23 Dec 2017 04:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 PSGNIRgY6x1N for ; Sat, 23 Dec 2017 04:15:45 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C4A2A124234 for ; Sat, 23 Dec 2017 04:15:45 -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 45BB366E; Sat, 23 Dec 2017 12:15:42 +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: <8712B7E8-D3DD-49F8-9F9C-2C267E519AAE@ericsson.com> Date: Sat, 23 Dec 2017 07:15:41 -0500 Cc: "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <09F5EF34-2C03-4B93-8CF9-DDA129F45F14@deployingradius.com> References: <8712B7E8-D3DD-49F8-9F9C-2C267E519AAE@ericsson.com> To: John Mattsson X-Mailer: Apple Mail (2.3124) 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: Sat, 23 Dec 2017 12:15:48 -0000 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) ). This doesn't help people with established certificates, business = practices, etc. > 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. That would definitely be useful. Alan DeKok.