From nobody Thu Dec 5 02:09:40 2019 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A08A11200A4; Thu, 5 Dec 2019 02:09:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: emu-chairs@ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <157554057862.16508.5111660426782980765.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2019 02:09:38 -0800 Archived-At: Subject: [Emu] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charter?= =?utf-8?q?-ietf-emu-05-02=3A_=28with_COMMENT=29?= X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 10:09:38 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-emu-05-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-emu/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think it would be more use to set milestones for when some work is supposed be finished (send to IESG for publication) rather than when it's supposed to start (WG adoption). From nobody Thu Dec 5 06:05:55 2019 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 CA9A51200C7; Thu, 5 Dec 2019 06:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 0ESGX5oXWshT; Thu, 5 Dec 2019 06:05:47 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 6438212004A; Thu, 5 Dec 2019 06:05:47 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xB5E5kgc042421; Thu, 5 Dec 2019 09:05:46 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu xB5E5kgc042421 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1575554746; bh=NVtwn/IecM7ULD5LGrf/WHJUydyQlxV13cXxya9guKg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=oIB1TMhHAR1J60tUL+QxO5hc7glozfM82oT7wYu4e9AWHd8Bw6RlCoH8Atq/beYNM ybRAdaSNH/KXJ1iLF4h5jvF+c9wUutZvb8rKFi0AuqyIyK0NYsIbyF/d/QQMRFe0a+ Ccv9bZ8qsy8MPnB8q6McpGK2eZzO6gxfTC9r5Umw= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xB5E5eHs012409; Thu, 5 Dec 2019 09:05:40 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Thu, 5 Dec 2019 09:05:40 -0500 From: Roman Danyliw To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "emu-chairs@ietf.org" , "emu@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBjaGFydGVyLWll?= =?utf-8?Q?tf-emu-05-02:_(with_COMMENT)?= Thread-Index: AQHVq1QhQlvy027+DEa5QaJTTAW5oqerkpWw Date: Thu, 5 Dec 2019 14:05:40 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E70CF169@marchand> References: <157554057862.16508.5111660426782980765.idtracker@ietfa.amsl.com> In-Reply-To: <157554057862.16508.5111660426782980765.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Emu] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charter?= =?utf-8?q?-ietf-emu-05-02=3A_=28with_COMMENT=29?= X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 14:05:50 -0000 SGkgTWlyamEhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyA8 aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWlyamEgS8O8aGxld2luZCB2aWEN Cj4gRGF0YXRyYWNrZXINCj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA1LCAyMDE5IDU6MTAg QU0NCj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZW11LWNoYWlyc0BpZXRm Lm9yZzsgZW11QGlldGYub3JnDQo+IFN1YmplY3Q6IE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmpl Y3Rpb24gb24gY2hhcnRlci1pZXRmLWVtdS0wNS0wMjogKHdpdGgNCj4gQ09NTUVOVCkNCj4gDQo+ IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRp b24gZm9yDQo+IGNoYXJ0ZXItaWV0Zi1lbXUtMDUtMDI6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hl biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVw bHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxp bmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhv d2V2ZXIuKQ0KPiANCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1lbXUvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSSB0aGluayBpdCB3b3VsZCBi ZSBtb3JlIHVzZSB0byBzZXQgbWlsZXN0b25lcyBmb3Igd2hlbiBzb21lIHdvcmsgaXMNCj4gc3Vw cG9zZWQgYmUgZmluaXNoZWQgKHNlbmQgdG8gSUVTRyBmb3IgcHVibGljYXRpb24pIHJhdGhlciB0 aGFuIHdoZW4gaXQncw0KPiBzdXBwb3NlZCB0byBzdGFydCAoV0cgYWRvcHRpb24pLg0KDQpBY2su ICBXZSdsbCBpdGVyYXRlIGluIHRoZSBXRyB0byBpZGVudGlmeSB0YXJnZXQgY29tcGxldGlvbiBk YXRlcy4NCg0KUm9tYW4NCg== From nobody Fri Dec 6 09:48:08 2019 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E9F12013D; Fri, 6 Dec 2019 09:48:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , emu-chairs@ietf.org, emu@ietf.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157565448566.21061.5899147272001348721.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2019 09:48:05 -0800 Archived-At: Subject: [Emu] WG Action: Rechartered EAP Method Update (emu) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 17:48:06 -0000 The EAP Method Update (emu) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. EAP Method Update (emu) ----------------------------------------------------------------------- Current status: Active WG Chairs: Joseph Salowey Mohit Sethi Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: emu@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: https://mailarchive.ietf.org/arch/search/?email_list=emu Group page: https://datatracker.ietf.org/group/emu/ Charter: https://datatracker.ietf.org/doc/charter-ietf-emu/ The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used, for instance, in VPN and mobile networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Several EAP methods have been developed at the IETF and support for EAP exists in a broad set of devices. Previous larger EAP-related efforts at the IETF included rewriting the base EAP protocol specification and the development of several standards track EAP methods. EAP methods are generally based on existing security technologies such as Transport Layer Security (TLS) and mobile network Authentication and Key Agreement (AKA). Our understanding of security threats is continuously evolving. This has driven the evolution of several of these underlying technologies. As an example, IETF has standardized a new and improved version of TLS (v1.3) in RFC 8446. The group will therefore provide guidance and update EAP method specifications where necessary to enable the use of new versions of these underlying technologies. At the same time, some new use cases for EAP have been identified. EAP is now more broadly used in mobile network authentication. The group will update existing EAP methods such as EAP-AKA' to stay in sync with updates to the referenced 3GPP specifications. RFC 7258 notes that pervasive monitoring is an attack. Forward secrecy is an important security property for modern protocols to thwart pervasive monitoring. The group will work on an extension to EAP-AKA' for providing PFS. Out-of-band (OOB) refers to a separate communication channel independent of the primary in-band channel over which the actual network communication takes place. OOB channels are now used for authentication in a variety of protocols and devices (draft-ietf-oauth-device-flow-13, WhatsApp Web, etc.). Many users are accustomed to tapping NFC or scanning QR codes. However, EAP currently does not have any standard methods that support authentication based on OOB channels. The group will therefore work on an EAP method where authentication is based on an out-of-band channel between the peer and the server. EAP authentication is based on credentials available on the peer and the server. However, some EAP methods use credentials that are time or domain limited (such as EAP-POTP), and there may be a need for creating long term credentials for re-authenticating the peer in a more general context. The group will investigate minimal mechanisms with which limited-use EAP authentication credentials can be used for creating general-use long-term credentials. In summary, the working group shall produce the following documents: * An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC 5216). This document will update the security considerations relating to EAP-TLS, document the implications of using new vs. old TLS versions. It will add any recently gained new knowledge on vulnerabilities and discuss the possible implications of pervasive surveillance. * Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS tunnel. Provide guidance or update the relevant specifications explaining how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will also involve maintenance work based on errata found in published specifications (such as EAP-TEAP). * Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, EAP-PEAP and EAP-AKA’. The lack of this definition is a recently discovered bug in the original RFCs. * Update the EAP-AKA' specification (RFC 5448) to ensure that its capability to provide a cryptographic binding to network context stays in sync with updates to the referenced 3GPP specifications. The document will also contain any recently gained new knowledge on vulnerabilities or the possible implications of pervasive surveillance. * Develop an extension to EAP-AKA' such that 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 certificates and long certificate chains in the context of TLS based EAP methods, 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. * Define a standard EAP method for mutual authentication between a peer and a server that is based on an out-of-band channel. The method itself should be independent of the underlying OOB channel and shall support a variety of OOB channels such as NFC, dynamically generated QR codes, audio, and visible light. * Define mechanisms by which EAP methods can support creation of long-term credentials for the peer based on initial limited-use credentials. The working group is expected to stay in close collaboration with the EAP deployment community, the TLS working group (for work on TLS based EAP methods), and the 3GPP security architecture group (for EAP-AKA' work). Milestones: Nov 2019 - WG last call on operational recommendations for large certificate and chain sizes Nov 2019 - WG last call on definition of session identifiers for fast re- authentication in EAP-SIM and EAP-AKA Nov 2019 - WG adopts initial draft addressing the errata found in EAP-TEAP Nov 2019 - WG adopts initial draft on an EAP method for mutual authentication based on an OOB channel Nov 2019 - WG adopts draft providing guidance for use of TLS 1.3 with TLS based EAP methods Jan 2020 - WG adopts initial draft on creation of long-term credentials for EAP peer based on initial limited-use credentials Mar 2020 - WG last call on extension to EAP-AKA to support forward secrecy From nobody Sun Dec 15 13:01:37 2019 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 3D32212003F; Sun, 15 Dec 2019 13:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 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_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SoQM8+E7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Jox66GGf 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 j58cJV0Mb638; Sun, 15 Dec 2019 13:01:33 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F51120013; Sun, 15 Dec 2019 13:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25823; q=dns/txt; s=iport; t=1576443693; x=1577653293; h=from:to:subject:date:message-id:mime-version; bh=iWFc3oFtBY4eHWhCiqJqpJQb7HKWE2pInRxAKYE60UA=; b=SoQM8+E74s3tcIwOivY7dOo3v1RbVIYXhGOhi560N7oZLFzHjoAlI/7H LGlUB4ffUKejtrUajZD/TIZBJ8b57wNSAzoQchA0wx1TTqdPAYtCz/Gpu ITNzW+FbdpmNoUW1vYGGQt+ytclCpDmjs+znc4/ozI8AUNiLhApQgLiS5 E=; IronPort-PHdr: =?us-ascii?q?9a23=3Aceu77RCn3LMVrucYho4aUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuK/DwbiE+NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AABKnvZd/5tdJa1cBwIbAQEBAQE?= =?us-ascii?q?BAQUBAQERAQEDAwEBAYFsBAEBAQsBgRsvJCwFbFggBAsqCodAA4sNTpoXgS6?= =?us-ascii?q?BJANUCQEBAQwBASMKAgEBhEACgg8kNgcOAgMNAQEEAQEBAgEFBG2FNwyFdxs?= =?us-ascii?q?TAQE4EQE2AghAJgEEARoagwGBeU0DLgECDKFdAoE4iGGCJ4J+AQEFgTkCAgx?= =?us-ascii?q?BgwcYghcDBoE2AYwXGoFBP4ERR4VuAQECAQGBNRQYKxsHBYJugiyNPzOIFpg?= =?us-ascii?q?EcgqCNIcpjneaSIIMhAyINIhPkXoCBAIEBQIOAQEFgVkELiqBLnAVgydQERS?= =?us-ascii?q?NEgwXg1CFFIU/dAGBJ4xcDRUCB4EEAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.69,319,1571702400"; d="scan'208,217";a="454144045" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Dec 2019 21:01:29 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xBFKr4kP005273 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 15 Dec 2019 20:53:05 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 15 Dec 2019 14:53:03 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 15 Dec 2019 14:53:02 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 15 Dec 2019 15:53:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JSAj9xroy35D/1+a62Uzq3fZe66VQxyDlvTxFUgJ9ywtf/g20TROWmLRIH7QLSYDdjkUUwQMhAWNmcL67oPyt67P8q8QyMujjm8ERTmMtTuETCfWdLxyeaf8r9AvXI/A+BMZpUZwrCuu4GGPP2sIia5m5Vlg1icq6KAJoGPwT4RR0BBiTk24i//47JoehZthicgC7du9Ulu15i9rnU1fll+tLJW+OoLfE+Dw/2oDV1nT5R+dfIiTkM7A6VN47bkUtstQTXIGEX30wLNixeyU1mpbsIRFtwkuNeOPmqb/J7InKdjkQ6uIEfC+ug/Nfx8mgeri5FlZWITTLTymsvhQOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AEwQL2UQUgH1dXPKKV400I5DJ70/UZb2SehZakZ+iCM=; b=dPvKaMzMJF8Vd6wZ8XNH2po/pe65X8YO0qNFSM8H+5nB+A7sv5onJJkXMvTDuOL/yZL3/vJLYoK//5vwnfWVNySGtoq+uDozbg4r1dShLnyqM5CohAwpdVYdu2K3UB2LY98prHsYHtU7mh2GZ0xld0LZmEGVpTG/lg3je6gxab1JhPJkHszPeXYWlNgIrZXec3fKsVRlGDrTjzRu5Bv0q6rY7BIohqbpOO7DFPmhosMOOXkgHq+MEtseeCkWXnp6YhBs+sY6sivNNLcM8NUkJalrRHf9vwit9Y/3GAUV8jZ7sSNcY3Czme3QhRGjUqj8h55QNBynoaRX0gsxFnzGAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AEwQL2UQUgH1dXPKKV400I5DJ70/UZb2SehZakZ+iCM=; b=Jox66GGfg4dmICqmeXLPBRugnOlMF63omE/nBaSTS02rJWO79hHtI6cxenReEt5HsOrtfMqh2WoPgaS+iGDLpiZAZJUJMq72cRWO7MQ3gRb4kicsYeGeB7o6jzEzvk50DzLEk+is0zbSl3Sn59NrzVcqUoExDbZEuhvOWPIrAIU= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3823.namprd11.prod.outlook.com (20.178.254.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14; Sun, 15 Dec 2019 20:53:01 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::a0c1:4add:251d:c9a4]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::a0c1:4add:251d:c9a4%7]) with mapi id 15.20.2538.019; Sun, 15 Dec 2019 20:53:01 +0000 From: "Owen Friel (ofriel)" To: "spasm@ietf.org" , EMU WG Thread-Topic: EAP/EMU recommendations for client cert validation logic Thread-Index: AdWxNKzqTmo8NKHtQwSIp+NEgFXHNA== Date: Sun, 15 Dec 2019 20:53:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [75.104.70.26] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7acbaf8b-a843-4dbe-ca3a-08d781a0c64c x-ms-traffictypediagnostic: MN2PR11MB3823: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(366004)(396003)(346002)(136003)(189003)(199004)(478600001)(9326002)(81156014)(86362001)(81166006)(316002)(966005)(8676002)(33656002)(64756008)(66446008)(66946007)(110136005)(9686003)(66556008)(2906002)(71200400001)(66476007)(6506007)(8936002)(450100002)(26005)(7696005)(5660300002)(76116006)(186003)(55016002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3823; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q2OcPralsCKvYXSAeLit6f61Hi8gJpRpwn1fE46/TQkqTtliHBIrCyn0qH3w4HtO5aQIpXaOiJwEZXTTBqUmIS2kqIkaKHx/9wOgrkXiwQI+Ly/Pqe41BndepfM41z79VtJoVZlUmKO2xON8Tgi55Y/GgB547NAuFSJyjQX8ZgHOBonCTKBQOlH4wvFeEisrEGAU5ybAmdG2gMMr8/e8HM0dEDgEuidydQPw/nhGqGLzbCTwavv1s1VyoQouUPiJYVQ5fTPe727tRi/exi25B0upzK94qeyc2oDr4vQOiJ5LQx7jN9Sytanl+ChiEizjjeNIfdQT0DQdrzgTA0rmDVBIBqCuA5LUuFPEeG1z12keqrNcLV1yZb38H1xdAsp59pXeMIUth8bXHmwKDv5hFr5F2MfOZBtutEjLq6mTd+NuoD2Vmgg6PWKzoDtdGvRrqm3jZXl1ZblnNlo7/e1G+O4oYKumrkROHr9npICkE7g= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3901F9B86DAC83AF67FBA49DDB560MN2PR11MB3901namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7acbaf8b-a843-4dbe-ca3a-08d781a0c64c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2019 20:53:01.7296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oLm0lke4CtZKtU18dbwTkxpNhSLKx9VA2sEF2k11jxgp/iAaLmv4vd+MzAEcoNyQUB2k8SRV+N/6Va5gRN7qlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3823 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2019 21:01:36 -0000 --_000_MN2PR11MB3901F9B86DAC83AF67FBA49DDB560MN2PR11MB3901namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At ACME meeting at IETF106, the last discussion of the week was around EMU = looking for recommendations for EAP client/peer/supplicant cert verificatio= n logic when the client is verifying the cert that the EAP server presents.= Minutes here: https://datatracker.ietf.org/doc/minutes-106-acme/ The reco= mmendation was to ask lamps. This was also discussed on EMU mailer recently= . Quoting some additional background that Alan gave on EMU mailer: "Background: a) the current practice in TLS-based EAP methods is to use certificates wit= h "id-kp-serverAuth" OID set for Extended Key Usage. b) many supplicants check for this OID, and refuse to perform authenticatio= n if it is missing c) supplicants do not check DNS names or any other field in the certificate= s d) as a result of this lack of verification, supplicants ship with all know= n CAs disabled for TLS-based EAP methods" The key consideration is that RFCs that recommend cert fields for EAP serve= rs that clients should check for are not currently issued by public CAs, an= d in some instances (e.g. SSID) ownership can often not be proven by CAs. For example: https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm If an EAP server operator wants to use a public CA identity cert on their E= AP server, what recommendations should we give to EAP clients so that the s= upplicant code can handle public or private CA issued EAP server identity i= n a secure a fashion as possible? If at some point in the future, public CAs are willing to issue certs with = some or all of the above fields, then what is the migration plan, what do w= e tell EAP clients to do now, and how to they migrate their verification lo= gic? The ideal experience would be along these lines for a client with real user= interactions: - client connects to an EAP server - client prompts user for userId + realm and password - client verifies server cert has id-kp-eapOverLAN set - NAIRealm in cert matches user's realm - verify the cert signing chain The reality today is that if the server cert is issued by a public CA, then= all that client can really check is: - id-kp-serverAuth is set - dNSName in cert matches user's realm - verify the cert signing chain We would like to document some recommendations for EAP clients and EAP oper= ators so that public CAs could be used, and recommend checks for public vs.= private CA issued EAP server certs. It seems like logic should be something like: - recommend EAP operators with private CA issued certs on their EAP servers= set id-kp-eapOverLAN and NAIRealm set - recommend EAP operators using public CAs get EAP server certs with id-kp-= serverAuth and dNSName set - recommend clients enable trust in public CAs - recommend clients implement different cert verification logic depending o= n whether the EAP server cert is issued by a public CA or private CA - for public CA certs, client checks that id-kp-serverAuth is set *and* dNS= Name matches user realm. If either check fails, reject. - for private CA certs, client checks that id-kp-serverAuth or id-kp-eapOve= rLAN is set *and* NAIRealm matches user realm. If either check fails, rejec= t. - as a longer term goal see if public CAs will issue id-kp-eapOverLAN and N= AIRealm. Although of course if some were to start doing this, then there is= a migration challenge, and clients cannot make a hard check for these valu= es against all public CAs. This doesn't really seem practical in the near t= erm at all. Note that for an IoT device, there is some work to do to define how to e.g.= extend the RFC8366 so that it can specify the dNSName that devices should = check for when verifying EAP identity where they EAP server uses a public C= A. Some related options are outlined in https://tools.ietf.org/html/draft-f= riel-anima-brski-cloud-01. Comments/thoughts? Regards, Owen --_000_MN2PR11MB3901F9B86DAC83AF67FBA49DDB560MN2PR11MB3901namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

At ACME meeting at IETF106, the last discussion of t= he week was around EMU looking for recommendations for EAP client/peer/supp= licant cert verification logic when the client is verifying the cert that t= he EAP server presents. Minutes here: https://data= tracker.ietf.org/doc/minutes-106-acme/  The recommendation was to = ask lamps. This was also discussed on EMU mailer recently.

 

Quoting some additional background that Alan gave on= EMU mailer:

 

“Background:

 

a) the current practice in TLS-based EAP methods = is to use certificates with "id-kp-serverAuth" OID set for Extend= ed Key Usage.

b) many supplicants check for this OID, and refus= e to perform authentication if it is missing

c) supplicants do not check DNS names or any othe= r field in the certificates

d) as a result of this lack of verification, supp= licants ship with all known CAs disabled for TLS-based EAP methods”

 

The key consideration is that RFCs that recommend ce= rt fields for EAP servers that clients should check for are not currently i= ssued by public CAs, and in some instances (e.g. SSID) ownership can often = not be proven by CAs.

 

For example:

 

https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EK= U

 

https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID=

 

https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm

 

If an EAP server operator wants to use a public CA i= dentity cert on their EAP server, what recommendations should we give to EA= P clients so that the supplicant code can handle public or private CA issue= d EAP server identity in a secure a fashion as possible?

 

If at some point in the future, public CAs are willi= ng to issue certs with some or all of the above fields, then what is the mi= gration plan, what do we tell EAP clients to do now, and how to they migrat= e their verification logic?

 

The ideal experience would be along these lines for = a client with real user interactions:

- client connects to an EAP server

- client prompts user for userId + realm and pas= sword

- client verifies server cert has id-kp-eapOverLAN s= et

- NAIRealm in cert matches user’s realm

- verify the cert signing chain

 

The reality today is that if the server cert is issu= ed by a public CA, then all that client can really check is:

- id-kp-serverAuth is set

- dNSName in cert matches user’s realm

- verify the cert signing chain

 

We would like to document some recommendations for E= AP clients and EAP operators so that public CAs could be used, and recommen= d checks for public vs. private CA issued EAP server certs.

 

It seems like logic should be something like:

 

- recommend EAP operators with private CA issued cer= ts on their EAP servers set id-kp-eapOverLAN and NAIRealm set

- recommend EAP operators using public CAs get EAP s= erver certs with id-kp-serverAuth and dNSName set

- recommend clients enable trust in public CAs<= /o:p>

- recommend clients implement different cert verific= ation logic depending on whether the EAP server cert is issued by a public = CA or private CA

- for public CA certs, client checks that id-kp-serv= erAuth is set *and* dNSName matches user realm. If either check fail= s, reject.

- for private CA certs, client checks that id-kp-ser= verAuth or id-kp-eapOverLAN is set *and* NAIRealm matches user realm= . If either check fails, reject.

 

- as a longer term goal see if public CAs will issue= id-kp-eapOverLAN and NAIRealm. Although of course if some were to start do= ing this, then there is a migration challenge, and clients cannot make a ha= rd check for these values against all public CAs. This doesn’t really seem practical in the near term = at all.

 

Note that for an IoT device, there is some work to d= o to define how to e.g. extend the RFC8366 so that it can specify the dNSNa= me that devices should check for when verifying EAP identity where they EAP= server uses a public CA. Some related options are outlined in https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01.

 

Comments/thoughts?

 

Regards,

Owen

 

 

 

 

 

 

 

 

--_000_MN2PR11MB3901F9B86DAC83AF67FBA49DDB560MN2PR11MB3901namp_-- From nobody Sun Dec 15 15:43:47 2019 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 17F5A12000F; Sun, 15 Dec 2019 15:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 S2tHr1vgy_jp; Sun, 15 Dec 2019 15:43:42 -0800 (PST) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (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 A29D7120013; Sun, 15 Dec 2019 15:43:41 -0800 (PST) Received: by mail-ed1-f46.google.com with SMTP id cy15so3571349edb.4; Sun, 15 Dec 2019 15:43:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y2sKwyZa3HBjLiB+zhzrBiGGdAWFJPDdS0Tap0M1XA8=; b=PTB+EgGVTwLe3pDKoIZY/8KBxa3udcEp7LDamjGk/14WGRiZ7HcFLVrRuMaG+D2s+I L6BQL1sJlVwC//wXAFiLMn0km2pCTU4hsNHga5qyJi+jUZnY9loBT7yUotWjW58P1bhM vKS+DxIGmdyR2IcOfzuoyTzbXeh8pTsW92BldTKvxqcK2ODlQm3PSnCzUgh+vvnGAbLX YS7bkVMaSyW8yFY+e1hrSnayqaPNxzvkNdhEYgDJ4lCeu26sR8Ha3m2X83D0L0KmX8X8 xxkTpnhO8yPG6In4PG2kjTB1Mj3okcrh2y7xSmRCiuPJomA7sYogBxbg0V4htsTqYE8i poAg== X-Gm-Message-State: APjAAAUc+LOsgdK/yV4JVMm/ke0vQ1o2Ib7BsTnZv+1yT3DYGGAFHX9B e/A5dFQK8Ne0/YlEDB/7QCa5EEVS X-Google-Smtp-Source: APXvYqxhqMckAVNAVJ8Tlbh96tooK+luSeoGYTIBZdizgQFUic/GeiROex7NP/HDhjEWJY8fM12b1g== X-Received: by 2002:a17:906:681:: with SMTP id u1mr29617292ejb.81.1576453419435; Sun, 15 Dec 2019 15:43:39 -0800 (PST) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com. [209.85.221.48]) by smtp.gmail.com with ESMTPSA id ck19sm1046082ejb.48.2019.12.15.15.43.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Dec 2019 15:43:39 -0800 (PST) Received: by mail-wr1-f48.google.com with SMTP id q10so5077146wrm.11; Sun, 15 Dec 2019 15:43:39 -0800 (PST) X-Received: by 2002:adf:ebc1:: with SMTP id v1mr25609591wrn.351.1576453418798; Sun, 15 Dec 2019 15:43:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Sleevi Date: Sun, 15 Dec 2019 18:43:24 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Owen Friel (ofriel)" Cc: EMU WG , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000008542e0599c6aaf1" Archived-At: Subject: Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2019 23:43:44 -0000 --00000000000008542e0599c6aaf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 15, 2019 at 4:01 PM Owen Friel (ofriel) wrote: > Hi, > > > > At ACME meeting at IETF106, the last discussion of the week was around EM= U > looking for recommendations for EAP client/peer/supplicant cert > verification logic when the client is verifying the cert that the EAP > server presents. Minutes here: > https://datatracker.ietf.org/doc/minutes-106-acme/ The recommendation > was to ask lamps. This was also discussed on EMU mailer recently. > > > > Quoting some additional background that Alan gave on EMU mailer: > > > > =E2=80=9CBackground: > > > > a) the current practice in TLS-based EAP methods is to use certificates > with "id-kp-serverAuth" OID set for Extended Key Usage. > > b) many supplicants check for this OID, and refuse to perform > authentication if it is missing > > c) supplicants do not check DNS names or any other field in the > certificates > > d) as a result of this lack of verification, supplicants ship with all > known CAs disabled for TLS-based EAP methods=E2=80=9D > > > > The key consideration is that RFCs that recommend cert fields for EAP > servers that clients should check for are not currently issued by public > CAs, and in some instances (e.g. SSID) ownership can often not be proven = by > CAs. > > > > For example: > > > > https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU > > > > https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID > > > > https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm > > > > If an EAP server operator wants to use a public CA identity cert on their > EAP server, what recommendations should we give to EAP clients so that th= e > supplicant code can handle public or private CA issued EAP server identit= y > in a secure a fashion as possible? > Define =E2=80=9Cpublic CA=E2=80=9D first, and it=E2=80=99ll be clearer that= the question is really supplicant-specific. That is, most definitions for =E2=80=9Cpublic CAs=E2=80=9D come down to =E2= =80=9CI don=E2=80=99t want to think about / analyze the security or validation practices of the CA, I want my supplicant / software / hardware vendor to do it for me, against some criteria the vendor is responsible for, and hope it all works out=E2= =80=9D. To the extent TLS uses =E2=80=98public CAs=E2=80=99, it either boils down to t= he OS or browser vendors reaching rough (independent) consensus on who is worth trusting, or the vendor going along with everyone else=E2=80=99s decisions for cost (too expensive for the vendor to evaluate) or compatibility (everyone else trusts them and it=E2=80=99d break things if the vendor doesn=E2=80=99t) re= asons. Is the supplicant market likely to reach that consensus? It seems unlikely, unless and until you define the =E2=80=9Cthing everyone can and wants and n= eeds to validate=E2=80=9D, and that thing is either globally unique (like DNS) or sufficiently domain specific (e.g. Passpoint) that vendors can agree. If at some point in the future, public CAs are willing to issue certs with > some or all of the above fields, then what is the migration plan, what do > we tell EAP clients to do now, and how to they migrate their verification > logic? > This statement similarly requires untangling. There are =E2=80=9Cpublic CAs= =E2=80=9D as =E2=80=9CThe set of keys/certificates used for authenticating particular se= rvices=E2=80=9D and =E2=80=9Cpublic CAs=E2=80=9D as the set of organizations that own/opera= te those keys. The case of the former is extremely unlikely, as the industry is actively moving away from that approach to PKI, by trying to ensure separate keys for separate use cases or authentication realms, of which EAP would surely be. The case of the latter is already available from said organizations as part of =E2=80=9Cmanaged CA=E2=80=9D or =E2=80=9Cprivate CA=E2=80=9D offeri= ngs, which are operated by that public CA organization, but that=E2=80=99s effectively greenfield because y= ou aren=E2=80=99t having to interoperate with any extant keys or certificate p= rofiles. The ideal experience would be along these lines for a client with real user > interactions: > > - client connects to an EAP server > > - client prompts user for userId + realm and password > > - client verifies server cert has id-kp-eapOverLAN set > What assurance is this to provide? - NAIRealm in cert matches user=E2=80=99s realm > This only works iff the NAIs are globally unique (e.g. map to DNS), which imposes requirements on NAIs that aren=E2=80=99t present in RFC 7542, and s= eemingly intentionally, compared to 4282. - verify the cert signing chain > > > > The reality today is that if the server cert is issued by a public CA, > then all that client can really check is: > > - id-kp-serverAuth is set > > - dNSName in cert matches user=E2=80=99s realm > > - verify the cert signing chain > > > > We would like to document some recommendations for EAP clients and EAP > operators so that public CAs could be used, and recommend checks for publ= ic > vs. private CA issued EAP server certs. > If you mean the same set of CAs and keys used for TLS by common operating systems and browsers, it bears highlighting again: industry is moving away from that. Which is to say that contracts and requirements for PKIs used =E2=80=9Cby default=E2=80=9D by browsers and operating systems are being ex= plicit about the need to segment purpose and use case and not use such certificates for such purposes. Already, TLS and e-mail, the two dominant uses of PKI in such systems, are required to be distinguished at their intermediate level. Browsers are looking to explicitly only trust the TLS-Web side of the PKI, and making sure that the TLS-Web PKI side is highly agile. Other cases, such as restricted use server to server PKI or industry bespoke cases (such as financial services or system networking) are being restricted to PKIs that aren=E2=80=99t federated-by-default. For example, X9 recently revived their PKI WG, to define PKI requirements appropriate for financial services customers (like ATM to bank), because financial services struggle to move at the same speed as modern software, for understandable reasons. The use of domain/purpose-specific PKIs is something we can and should be embracing more of. It seems like logic should be something like: > > > > - recommend EAP operators with private CA issued certs on their EAP > servers set id-kp-eapOverLAN and NAIRealm set > > - recommend EAP operators using public CAs get EAP server certs with > id-kp-serverAuth and dNSName set > - recommend clients enable trust in public CAs > This is why I started with trying to define what =E2=80=9Cpublic CAs=E2=80= =9D are. If you mean the extant CAs trusted by browsers and operating systems, both this recommendation and the one proceeding it may not be good recommendations or long-term viable practices. That=E2=80=99s not to say you couldn=E2=80=99t, but it means your EAP servi= ces and servers need to be prepared to be as agile as the Web ecosystem is and modern operating systems are converging on. The ability to support or be beholden to =E2=80=9Clegacy=E2=80=9D - whether algorithms, profiles, or trust in par= ticular organizations - is something that industry is recognizing does not align with user needs. This means adopting practices like automation, being able to quantify compatibility risks, and being able to move quickly as expectations change, in response to ecosystem challenges. Maybe that=E2=80=99s fine for EAP, but I=E2=80=99m willing to suspect that = it because updates may involve physically replacing client hardware or physically installing firmware, you really don=E2=80=99t want EAP needing to be behold= en to those agility needs of the Web and OSes. And, again, that=E2=80=99s perfect= ly OK, it just means defining a PKI and set of procedures that is appropriate for that use case, and convincing industry to adopt it as an =E2=80=9Cout of th= e box=E2=80=9D configuration. Or, alternatively, embracing private PKI. - recommend clients implement different cert verification logic depending > on whether the EAP server cert is issued by a public CA or private CA > Why is this good? To the extent browsers or OSes make this distinction, it=E2=80=99s largely = based on simply phasing rollouts of new requirements, with the goal to eventually require consistent and uniform treatment to ensure simpler code with consistent and uniform security properties. Having a long-term segmentation of requirements, or even encouraging them without a clear vision back to harmonization, is definitely an anti-pattern here. - for public CA certs, client checks that id-kp-serverAuth is set **and** > dNSName matches user realm. If either check fails, reject. > > - for private CA certs, client checks that id-kp-serverAuth or > id-kp-eapOverLAN is set **and** NAIRealm matches user realm.. If either > check fails, reject. > > > > - as a longer term goal see if public CAs will issue id-kp-eapOverLAN and > NAIRealm. Although of course if some were to start doing this, then there > is a migration challenge, and clients cannot make a hard check for these > values against all public CAs. This doesn=E2=80=99t really seem practical= in the > near term at all. > The effect of the separate EKU, which is actually quite desirable, is that it functionally makes it difficult for CAs to issue these certificates from intermediated that lack this EKU or any EKU. Further, CAs subject to browser/OS vendor oversight are consistently required to segment out their EKUs at the intermediate level, and required to always specify EKUs. The end result is that, to achieve this long term goal, you=E2=80=99ve effe= ctively required the establishment of a new PKI - just at the intermediate level rather than the root. And as many of the public CAs can tell you, having recently encountered challenges regarding non-TLS intermediates from roots that are subject to browser/OS oversight, it=E2=80=99s often easier to use = separate roots as well. Again, I think that=E2=80=99s desirable, to define an entirely new PKI with= zero overlap with the server auth/TLS PKI used by OSes/browsers, but that does change your recommendations and design a bit :) The short term recommendation becomes =E2=80=9Cdon=E2=80=99t use public CAs=E2=80=9D, and = that seems easier to explain and easier to evolve the technical requirements, until the time that such a new, EAP-specific public PKI can be introduced. In my mind, this is no different from organizations that want TLS certificates for their servers named =E2=80=9Cwebmail=E2=80=9D (not globall= y unique) or =E2=80=9Cmail_01.company.example=E2=80=9D (not preferred name form / LDH). = The answer is =E2=80=9Cuse private CAs, don=E2=80=99t use public CAs=E2=80=9D > > Note that for an IoT device, there is some work to do to define how to > e.g. extend the RFC8366 so that it can specify the dNSName that devices > should check for when verifying EAP identity where they EAP server uses a > public CA. Some related options are outlined in > https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01. > > > > Comments/thoughts? > > > > Regards, > > Owen > > > > > > > > > > > > > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --00000000000008542e0599c6aaf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Dec 15, 2019 at 4:01 PM Owen Friel (ofriel) <ofriel@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">

Hi,

=C2=A0

At ACME meeting at IETF106, the last discussion of t= he week was around EMU looking for recommendations for EAP client/peer/supp= licant cert verification logic when the client is verifying the cert that t= he EAP server presents. Minutes here: https://datatracker.ietf.org/doc/minutes-106-acme/=C2=A0 The reco= mmendation was to ask lamps. This was also discussed on EMU mailer recently= .

=C2=A0

Quoting some additional background that Alan gave on= EMU mailer:

=C2=A0

=E2=80=9CBackground:

=C2=A0

a) the current practice in TLS-based EAP methods is to use certificates = with "id-kp-serverAuth" OID set for Extended Key Usage.=

b) many supplicants check for this OID, and refuse to perform authentica= tion if it is missing

c) supplicants do not check DNS names or any other field in the certific= ates

d) as a result of this lack of verification, supplicants ship with all k= nown CAs disabled for TLS-based EAP methods=E2=80=9D

=C2=A0

The key consideration is that RFCs that recommend ce= rt fields for EAP servers that clients should check for are not currently i= ssued by public CAs, and in some instances (e.g. SSID) ownership can often = not be proven by CAs.

=C2=A0

For example:

=C2=A0

https://tools.ietf.org/html/rfc4334#section-2 i= d-kp-eapOverLAN EKU

=C2=A0

https://tools.ietf.org/html/rfc4334#section-3 i= d-pe-wlanSSID

=C2=A0

https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm

=C2=A0

If an EAP server operator wants to use a public CA i= dentity cert on their EAP server, what recommendations should we give to EA= P clients so that the supplicant code can handle public or private CA issue= d EAP server identity in a secure a fashion as possible?



This statement similarly requires untangling. Th= ere are =E2=80=9Cpublic CAs=E2=80=9D as =E2=80=9CThe set of keys/certificat= es used for authenticating particular services=E2=80=9D and =E2=80=9Cpublic= CAs=E2=80=9D as the set of organizations that own/operate those keys.

The case of the former is ex= tremely unlikely, as the industry is actively moving away from that approac= h to PKI, by trying to ensure separate keys for separate use cases or authe= ntication realms, of which EAP would surely be. The case of the latter is a= lready available from said organizations as part of =E2=80=9Cmanaged CA=E2= =80=9D or =E2=80=9Cprivate CA=E2=80=9D offerings, which are operated by tha= t public CA organization, but that=E2=80=99s effectively greenfield because= you aren=E2=80=99t having to interoperate with any extant keys or certific= ate profiles.

The ideal experience would be along these lines for = a client with real user interactions:

- client connects to an EAP server

- client prompts user for userId + realm and passwor= d

- client verifies server cert has id-kp-eapOverLAN s= et


What assurance is this to provide?

- NAIRealm in cert matches user=E2=80=99s realm

<= /div>

This = only works iff the NAIs are globally unique (e.g. map to DNS), which impose= s requirements on NAIs that aren=E2=80=99t present in RFC 7542, and seeming= ly intentionally, compared to 4282.

- verify the cert signing chain

=C2=A0

The reality today is that if the server cert is issu= ed by a public CA, then all that client can really check is:<= /p>

- id-kp-serverAuth is set

- dNSName in cert matches user=E2=80=99s realm

- verify the cert signing chain

=C2=A0

We would like to document some recommendations for E= AP clients and EAP operators so that public CAs could be used, and recommen= d checks for public vs. private CA issued EAP server certs.

=

If you mean the = same set of CAs and keys used for TLS by common operating systems and brows= ers, it bears highlighting again: industry is moving away from that. Which = is to say that contracts and requirements for PKIs used =E2=80=9Cby default= =E2=80=9D by browsers and operating systems are being explicit about the ne= ed to segment purpose and use case and not use such certificates for such p= urposes.

Already, TLS an= d e-mail, the two dominant uses of PKI in such systems, are required to be = distinguished at their intermediate level. Browsers are looking to explicit= ly only trust the TLS-Web side of the PKI, and making sure that the TLS-Web= PKI side is highly agile. Other cases, such as restricted use server to se= rver PKI or industry bespoke cases (such as financial services or system ne= tworking) are being restricted to PKIs that aren=E2=80=99t federated-by-def= ault.

For example, X9 re= cently revived their PKI WG, to define PKI requirements appropriate for fin= ancial services customers (like ATM to bank), because financial services st= ruggle to move at the same speed as modern software, for understandable rea= sons. The use of domain/purpose-specific PKIs is something we can and shoul= d be embracing more of.

=

It seems like logic should be something like:=

=C2=A0

- recommend EAP operators with private CA issued cer= ts on their EAP servers set id-kp-eapOverLAN and NAIRealm set=

- recommend EAP operators using public CAs get EAP s= erver certs with id-kp-serverAuth and dNSName set

=

- recommend clients enable trust in public CAs<= /p>


<= span style=3D"border-color:rgb(0,0,0)">This is why I started with trying to= define what =E2=80=9Cpublic CAs=E2=80=9D are. If you mean the extant CAs t= rusted by browsers and operating systems, both this recommendation and the = one proceeding it may not be good recommendations or long-term viable pract= ices.

That=E2=80=99s not to say you couldn=E2=80=99t, but it means your EAP = services and servers need to be prepared to be as agile as the Web ecosyste= m is and modern operating systems are converging on. The ability to support= or be beholden to =E2=80=9Clegacy=E2=80=9D - whether algorithms, profiles,= or trust in particular organizations - is something that industry is recog= nizing does not align with user needs. This means adopting practices like a= utomation, being able to quantify compatibility risks, and being able to mo= ve quickly as expectations change, in response to ecosystem challenges.

Maybe th= at=E2=80=99s fine for EAP, but I=E2=80=99m willing to suspect that it becau= se updates may involve physically replacing client hardware or physically i= nstalling firmware, you really don=E2=80=99t want EAP needing to be beholde= n to those agility needs of the Web and OSes. And, again, that=E2=80=99s pe= rfectly OK, it just means defining a PKI and set of procedures that is appr= opriate for that use case, and convincing industry to adopt it as an =E2=80= =9Cout of the box=E2=80=9D configuration. Or, alternatively, embracing priv= ate PKI.

<= u>

- recommend clients implement different cert verific= ation logic depending on whether the EAP server cert is issued by a public = CA or private CA


Why is this good?

To the extent browsers or OSes make this distinction, it=E2=80=99= s largely based on simply phasing rollouts of new requirements, with the go= al to eventually require consistent and uniform treatment to ensure simpler= code with consistent and uniform security properties. Having a long-term s= egmentation of requirements, or even encouraging them without a clear visio= n back to harmonization, is definitely an anti-pattern here.

- for public CA certs, client checks that id-kp-serv= erAuth is set *and* dNSName matches user realm. If either check fail= s, reject.

- for private CA certs, client checks that id-kp-ser= verAuth or id-kp-eapOverLAN is set *and* NAIRealm matches user realm= .. If either check fails, reject.

=C2=A0

- as a longer term goal see if public CAs will issue= id-kp-eapOverLAN and NAIRealm. Although of course if some were to start do= ing this, then there is a migration challenge, and clients cannot make a ha= rd check for these values against all public CAs. This doesn=E2=80=99t really seem practical in the near ter= m at all.


The effect of the separate EKU, which is actually quite desirable= , is that it functionally makes it difficult for CAs to issue these certifi= cates from intermediated that lack this EKU or any EKU. Further, =C2=A0CAs = subject to browser/OS vendor oversight are consistently required to segment= out their EKUs at the intermediate level, and required to always specify E= KUs.

The end result is t= hat, to achieve this long term goal, you=E2=80=99ve effectively required th= e establishment of a new PKI - just at the intermediate level rather than t= he root. And as many of the public CAs can tell you, having recently encoun= tered challenges regarding non-TLS intermediates from roots that are subjec= t to browser/OS oversight, it=E2=80=99s often easier to use separate roots = as well.

Again, I think = that=E2=80=99s desirable, to define an entirely new PKI with zero overlap w= ith the server auth/TLS PKI used by OSes/browsers, but that does change you= r recommendations and design a bit :) The short term recommendation becomes= =E2=80=9Cdon=E2=80=99t use public CAs=E2=80=9D, and that seems easier to e= xplain and easier to evolve the technical requirements, until the time that= such a new, EAP-specific public PKI can be introduced.

In my mind, this is no different from organ= izations that want TLS certificates for their servers named =E2=80=9Cwebmai= l=E2=80=9D (not globally unique) or =E2=80=9Cmail_01.company.example=E2=80= =9D (not preferred name form / LDH). The answer is =E2=80=9Cuse private CAs= , don=E2=80=99t use public CAs=E2=80=9D

 _______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--00000000000008542e0599c6aaf1-- From nobody Sun Dec 15 16:51:01 2019 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 B51A912008F; Sun, 15 Dec 2019 16:50:59 -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_HELO_NONE=0.001, 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 fDZPOrMQgrmB; Sun, 15 Dec 2019 16:50:57 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568AA120059; Sun, 15 Dec 2019 16:50:57 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id BFBB863D; Mon, 16 Dec 2019 00:50:53 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Alan DeKok In-Reply-To: Date: Sun, 15 Dec 2019 19:50:52 -0500 Cc: "Owen Friel (ofriel)" , "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Sleevi X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 00:51:00 -0000 On Dec 15, 2019, at 6:43 PM, Ryan Sleevi wrote: > That is, most definitions for =E2=80=9Cpublic CAs=E2=80=9D come down = to =E2=80=9CI don=E2=80=99t want to think about / analyze the security = or validation practices of the CA, I want my supplicant / software / = hardware vendor to do it for me, against some criteria the vendor is = responsible for, and hope it all works out=E2=80=9D. To the extent TLS = uses =E2=80=98public CAs=E2=80=99, it either boils down to the OS or = browser vendors reaching rough (independent) consensus on who is worth = trusting, or the vendor going along with everyone else=E2=80=99s = decisions for cost (too expensive for the vendor to evaluate) or = compatibility (everyone else trusts them and it=E2=80=99d break things = if the vendor doesn=E2=80=99t) reasons. It's also a way to move trust out of the individual machine, and into = the network. Given the complexity of supplicant configuration, I think = that's a good thing. > Is the supplicant market likely to reach that consensus? It seems = unlikely, unless and until you define the =E2=80=9Cthing everyone can = and wants and needs to validate=E2=80=9D, and that thing is either = globally unique (like DNS) or sufficiently domain specific (e.g. = Passpoint) that vendors can agree. >=20 > > If at some point in the future, public CAs are willing to issue = certs with some or all of the above fields, then what is the migration = plan, what do we tell EAP clients to do now, and how to they migrate = their verification logic? My goal is to answer that question. Which involves some discussion = and analysis. > This statement similarly requires untangling. There are =E2=80=9Cpublic = CAs=E2=80=9D as =E2=80=9CThe set of keys/certificates used for = authenticating particular services=E2=80=9D and =E2=80=9Cpublic CAs=E2=80=9D= as the set of organizations that own/operate those keys. >=20 > The case of the former is extremely unlikely, as the industry is = actively moving away from that approach to PKI, by trying to ensure = separate keys for separate use cases or authentication realms, of which = EAP would surely be.=20 Yes. > > - client verifies server cert has id-kp-eapOverLAN set >=20 > What assurance is this to provide? The use-case for the certificate matches the intended use-case. Right now, I can use the same server certificate for HTTPS, EAP, or = any other TLS-based protocol. That seems wrong. > - NAIRealm in cert matches user=E2=80=99s realm >=20 > This only works iff the NAIs are globally unique (e.g. map to DNS), = which imposes requirements on NAIs that aren=E2=80=99t present in RFC = 7542, and seemingly intentionally, compared to 4282. Huh? RFC 7542 explicitly calls out NAI Realms as mapping to DNS. See = Section 2.5: --- In order to ensure a canonical representation, characters of the realm portion in an NAI MUST match the ABNF in this specification as well as the requirements specified in [RFC5891]. In practice, these requirements consist of the following item: * Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS. This list is significantly shorter and simpler than the list in Section 2.4 of [RFC4282]. --- The intention of RFC 7542 is that NAI Realms are *exactly* DNS names. = This is a change from 4282, where realms were, well, we don't know. = That failure motivated 7542. > Again, I think that=E2=80=99s desirable, to define an entirely new PKI = with zero overlap with the server auth/TLS PKI used by OSes/browsers, = but that does change your recommendations and design a bit :) The short = term recommendation becomes =E2=80=9Cdon=E2=80=99t use public CAs=E2=80=9D= , and that seems easier to explain and easier to evolve the technical = requirements, until the time that such a new, EAP-specific public PKI = can be introduced. The recommendation for EAP has generally been "don't use public CAs". = Originally it was in part because implementations didn't do certificate = pinning. i.e. once a root CA was trusted, a supplicant would accept any = server certificate signed by that root, and send credentials over. Now, over a decade of practice has shown the private CAs for EAP allow = for greater flexibility and control. I've personally had CAs take my = money for a cert, and refuse to give me anything in return. No amount = of complaining will convince them that it's a problem. It's much = simpler to just use a private CA. > In my mind, this is no different from organizations that want TLS = certificates for their servers named =E2=80=9Cwebmail=E2=80=9D (not = globally unique) or =E2=80=9Cmail_01.company.example=E2=80=9D (not = preferred name form / LDH). The answer is =E2=80=9Cuse private CAs, = don=E2=80=99t use public CAs=E2=80=9D I agree. Alan DeKok. From nobody Tue Dec 17 10:52:24 2019 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 DFB2B1208C1; Tue, 17 Dec 2019 10:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 5IMr0vevHG8c; Tue, 17 Dec 2019 10:52:13 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E69120870; Tue, 17 Dec 2019 10:51:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CD1BA38981; Tue, 17 Dec 2019 13:51:06 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B4BD2D36; Tue, 17 Dec 2019 13:51:09 -0500 (EST) From: Michael Richardson To: "spasm\@ietf.org" , EMU WG In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 18:52:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Owen Friel (ofriel) wrote: > =E2=80=9CBackground: > a) the current practice in TLS-based EAP methods is to use certificat= es with > "id-kp-serverAuth" OID set for Extended Key Usage. > b) many supplicants check for this OID, and refuse to perform authent= ication > if it is missing > c) supplicants do not check DNS names or any other field in the certi= ficates > d) as a result of this lack of verification, supplicants ship with al= l known > CAs disabled for TLS-based EAP methods=E2=80=9D > The key consideration is that RFCs that recommend cert fields for EAP= servers > that clients should check for are not currently issued by public CAs,= and in > some instances (e.g. SSID) ownership can often not be proven by CAs. > For example: > https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU > https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID > https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm > If an EAP server operator wants to use a public CA identity cert on t= heir EAP > server, what recommendations should we give to EAP clients so that the > supplicant code can handle public or private CA issued EAP server ide= ntity in > a secure a fashion as possible? > If at some point in the future, public CAs are willing to issue certs= with > some or all of the above fields, then what is the migration plan, wha= t do we > tell EAP clients to do now, and how to they migrate their verification > logic? I think that this is a really big if. So, I want to change the question, which I think can make this problem a lot easier to get traction on. } If at some point in the future, there is one or more well-known trust } anchors that (IoT?) devices can build in, and these CAs are willing to is= sue } certs with some or all of the above fields, can we design a transition } process from one-touch provisioned private CAs to a common DN+extension } based common anchor? > The ideal experience would be along these lines for a client with rea= l user > interactions: 1> - client connects to an EAP server 2> - client prompts user for userId + realm and password 3> - client verifies server cert has id-kp-eapOverLAN set 4> - NAIRealm in cert matches user=E2=80=99s realm 5> - verify the cert signing chain <2> and <3> seem in the wrong order. If the certificate has NAIRealm, why would we need to ask the user for the realm? Wouldn't we instead ask them: "What is your userID in REALM FOO" > The reality today is that if the server cert is issued by a public CA= , then > all that client can really check is: 1> - id-kp-serverAuth is set 2> - dNSName in cert matches user=E2=80=99s realm 3> - verify the cert signing chain I think that <3> happens first, and the connection is dropped if it does not validate. Maybe you aren't expressing an order here at all. > It seems like logic should be something like: > - recommend EAP operators with private CA issued certs on their EAP s= ervers > set id-kp-eapOverLAN and NAIRealm set > - recommend EAP operators using public CAs get EAP server certs with > id-kp-serverAuth and dNSName set > - recommend clients enable trust in public CAs > - recommend clients implement different cert verification logic depen= ding on > whether the EAP server cert is issued by a public CA or private CA Would setting dNSNAME on private CA issued certs reduce complexity? > - as a longer term goal see if public CAs will issue id-kp-eapOverLAN= and > NAIRealm. Although of course if some were to start doing this, then t= here is > a migration challenge, and clients cannot make a hard check for these= values > against all public CAs. This doesn=E2=80=99t really seem practical in= the near term > at all. Trust NAIRealm extension only if id-kp-eapOverLAN is set. having implemented the dNSNAME code path, it seems like there is no point in implementing the other path. > Note that for an IoT device, there is some work to do to define how t= o e.g. > extend the RFC8366 so that it can specify the dNSName that devices sh= ould > check for when verifying EAP identity where they EAP server uses a pu= blic CA. > Some related options are outlined in > https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01. Owen and I have wrangled about the topic of how exactly the pinning is done. The above document does not really outline the problem space in my opinion, focusing on other dimensions of the process. The requirements that Owen has expressed to me are: 1) 8366bis must be able to pin CA + DN/SAN, such that the operator can ro= tate their public key without invalidating the voucher. (possibly including changing public key algorithm) 2) 8366bis must be able to pin (?-public key), such that the operator can switch (public) CAs without invalidating the voucher. There might be a (3) that I can't think of right now. But, if these two requirements seem to contradict each other, then high-five to you, you were paying attention :-) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl35I50ACgkQgItw+93Q 3WUaOwf/a0fRfUVp+1o96EyuuMGwppJVPRU17Au4Rnayq1+FoPiCWGkm9MdBm4Bt agzlJUsKBb1mJZ//prb+L4DR6l3EodggsiDP2mfztKdIc0HS3TaHUa/fheE4g2h8 abf9CEYjDg4a4Kj6o3oZq78vXoSC4vtN+xRV+bCKuiMPIw6NkfVoatnT2+VPL3mg ZtIhu3ZlPZM60gK+VyPdvlLpt4IJHLQPHk3QPMCso6suKBz2L7/9PEpGO/dDOYVU 47Ic2CeHaNNzRQ0sQhuBwJsPdowv9Hc5awc4X+lcaHfHpLESbIeEDS8zOF+Gokyn vsIz8sDsHfnTh8alxrRO8zGgO7sx+A== =Iskc -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 17 11:07:34 2019 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 DCC361208CC; Tue, 17 Dec 2019 11:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 Wl-5gXamTRKr; Tue, 17 Dec 2019 11:07:30 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D75D1208C9; Tue, 17 Dec 2019 11:07:22 -0800 (PST) Received: from [192.168.20.177] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id E450A64E; Tue, 17 Dec 2019 19:07:16 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Alan DeKok In-Reply-To: <6719.1576608669@localhost> Date: Tue, 17 Dec 2019 14:07:15 -0500 Cc: "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <83F3F036-4D6A-4899-AC02-FAEE7685D8C9@deployingradius.com> References: <6719.1576608669@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 19:07:33 -0000 On Dec 17, 2019, at 1:51 PM, Michael Richardson = wrote: > } If at some point in the future, there is one or more well-known = trust > } anchors that (IoT?) devices can build in, and these CAs are willing = to issue > } certs with some or all of the above fields, can we design a = transition > } process from one-touch provisioned private CAs to a common = DN+extension > } based common anchor? I hope so. My $0.02 is that configuration belongs in a machine-readable format, = not in fields in a GUI. i.e. fields in a cert. Once we have a machine-readable format, transition plans become = simpler, because we have a better handle on what systems are doing. >> The ideal experience would be along these lines for a client with = real user >> interactions: >=20 > 1> - client connects to an EAP server > 2> - client prompts user for userId + realm and password > 3> - client verifies server cert has id-kp-eapOverLAN set > 4> - NAIRealm in cert matches user=E2=80=99s realm > 5> - verify the cert signing chain >=20 > <2> and <3> seem in the wrong order. > If the certificate has NAIRealm, why would we need to ask the user for = the > realm? Wouldn't we instead ask them: "What is your userID in REALM = FOO" The server certificate is presented before the user credentials are = sent (PEAP / TTLS). So the client can automatically derive the = NAIRealm. The issue is that users are slow. It's bad to have the EAP session = hang while the user enters "name / password" in a GUI. That's the only = real reason why name / password is requested before the EAP session = starts. >> The reality today is that if the server cert is issued by a public = CA, then >> all that client can really check is: >=20 > 1> - id-kp-serverAuth is set > 2> - dNSName in cert matches user=E2=80=99s realm > 3> - verify the cert signing chain >=20 > I think that <3> happens first, and the connection is dropped if it = does not > validate. Maybe you aren't expressing an order here at all. The only reason to order these checks is cost. i.e. simple checks = should run first, before complex checks. >> It seems like logic should be something like: >=20 >> - recommend EAP operators with private CA issued certs on their EAP = servers >> set id-kp-eapOverLAN and NAIRealm set >> - recommend EAP operators using public CAs get EAP server certs with >> id-kp-serverAuth and dNSName set >> - recommend clients enable trust in public CAs >> - recommend clients implement different cert verification logic = depending on >> whether the EAP server cert is issued by a public CA or private CA >=20 > Would setting dNSNAME on private CA issued certs reduce complexity? No. The DNS names at at least the realm names (example.com), but they = could be more (radius.example.com). There's no good way to automatically derive the NAIrealm from a DNS = name. Given both, you can check if they're compatible. But that's it. >> - as a longer term goal see if public CAs will issue id-kp-eapOverLAN = and >> NAIRealm. Although of course if some were to start doing this, then = there is >> a migration challenge, and clients cannot make a hard check for these = values >> against all public CAs. This doesn=E2=80=99t really seem practical in = the near term >> at all. >=20 > Trust NAIRealm extension only if id-kp-eapOverLAN is set. > having implemented the dNSNAME code path, it seems like there is no = point in > implementing the other path. The NAIRealm tells you exactly which Realm you're using. The DNSName = path doesn't. The NAIRealm can be used to skip the step where the user is prompted = for the realm. Alan DeKok. From nobody Fri Dec 27 10:54:19 2019 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72F120018; Fri, 27 Dec 2019 10:54:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <157747285825.29960.15830219994236578624@ietfa.amsl.com> Date: Fri, 27 Dec 2019 10:54:18 -0800 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-08.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 18:54:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Using EAP-TLS with TLS 1.3 Authors : John Preuß Mattsson Mohit Sethi Filename : draft-ietf-emu-eap-tls13-08.txt Pages : 29 Date : 2019-12-27 Abstract: This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP- TLS. TLS 1.3 provides significantly improved security, privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 further improves security and privacy by mandating use of privacy and revocation checking. This document updates RFC 5216. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-08 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 28 00:25:16 2019 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 C7DE412002F for ; Sat, 28 Dec 2019 00:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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.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 HPtBcRM0ViCO for ; Sat, 28 Dec 2019 00:25:12 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20082.outbound.protection.outlook.com [40.107.2.82]) (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 17B6912001E for ; Sat, 28 Dec 2019 00:25:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e+FGgRJOTK1SJYBeZpnN1LtJQYf4ZR2c2Gp+Pa/AOITFsMaUvCWwIdme2J8G9UOqQi1Wa5iATb8WH/sWnx70vn1+XXo51OfLnUbSJMbc/BLynQ1IVUFdSIk0vSQGc73ThjQWvi+dhc6Oc8TZ1l5jGnrqS2pLqlGyT8RKYwgjodcx0d+ycIcyUXMmZbhybqBXEqyrKM/vSB8PXBeM7q5Re6V6putqt0gy8O4sEsuTlbi8/2zCbo+ekB56yYXlQI+1zFvCXK01DrKCcKM69Rb6pE87Kp19ryjlILcQUCQ/dA+mF2DDl6hSpavi6MqUyCwRPW06oqCrWYIjvPcWaM9hmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z8/0gmT6RM1dR/jhBJZ1705nMNOlC5iAN5NzO5ALHjM=; b=oGvZkDYY/JxriU+rwwohTwrd4ZlEBw+59LmC37TpeiK8BYuTYV/ff8tHpElqaLthlbYTGZ0RydTPnL/irqeqEsr7Agi/UnppOuXTxbdhFVaq/Rq1XiT74Dc5akTu09SZsjh8SyTEYkFy1QVkELxQnTmoetzEYHUrMBHxzALWiWQtLtZsm7gqT3Awck/4NDQsHcvqzg1MyWclQNDSJ4gm1MSA9rJJilExrhF4gKT7S/hxpsJYmvFgWWQgpjuVh8U/Zi4SCgEuxbuWc5bo0Qr02/JXnS+TAPimmNMw2TGTmWCiKghuFvN/5dIV7AzbfREtO+z0Amiuu64az/QKKHmaVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z8/0gmT6RM1dR/jhBJZ1705nMNOlC5iAN5NzO5ALHjM=; b=WjtAwhAIHhhoGmPyYKTcbmNIufUNik9sMEZHiZVuyXg/o9UHwxofsn/XEvhAPbxjx6kgx7SB+hiLaX2xk19oHcWkO5cTg+Q8/cBklAt0g6ClQQXkTqkFL8hfiCOwuZjrqaCBEHfHOZ1VrRBdMc4HDRliWTNdnaqdGGATyYWKZoU= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2298.eurprd07.prod.outlook.com (10.168.126.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.6; Sat, 28 Dec 2019 08:25:09 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::cd13:3dbf:1517:c03c]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::cd13:3dbf:1517:c03c%10]) with mapi id 15.20.2602.009; Sat, 28 Dec 2019 08:25:08 +0000 From: Mohit Sethi M To: "emu@ietf.org" , "aland@deployingradius.com" Thread-Topic: [Emu] WGLC for draft-ietf-emu-eap-session-id-01 Thread-Index: AQHVpFqMI1yTZMmdm068bwW6HgCCZafPZ+qA Date: Sat, 28 Dec 2019 08:25:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:999:3:c71f:4c26:fd0b:6399:d401] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f881a8d1-95c3-4b3d-ef8a-08d78b6f731a x-ms-traffictypediagnostic: HE1PR0701MB2298: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(376002)(39860400002)(396003)(189003)(199004)(71200400001)(186003)(6486002)(8676002)(478600001)(81156014)(81166006)(966005)(66556008)(66476007)(66946007)(53546011)(6506007)(36756003)(66446008)(86362001)(64756008)(2616005)(8936002)(31686004)(31696002)(2906002)(316002)(76116006)(5660300002)(110136005)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2298; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +Fc6JINfETtrG0d2Lj8ZrY7o+OmnncjtVxzSPNSkkSUdx/OE818Qy6yZVXtHiNhXo7gbLd4ejrEh0A2brn6YzIlifDFj0uabTwCelT1Oc15VmJmyprvVw5Zu8Ji+EohSVJJRQI4VoqRU+TUg04JivzeTj/pI/cEKopoWfdlg2VDrLNp55joZ0x/OM1wynlzp72wTSN+8KpV738X6O2tkenN7Iz97RhMn/OlA7QeujOXJDBBJnunyv/ApA9NGtJ+dzbW2SwLDvuJ7lhelK8WmhRnEoyuScgFGvFgbH2zsDYFs04ZTuYH9OUtQHx7zevWMJL2Rli8QYD259FsQl1cu5c9qhTnpqE7E8Nu6/5DiPSftSvkTx9wlpV6oNmPmoMB2BSYvcFaY4VuZpBQsXdG9I/glgA3uPUfmVgpoNDeyKjD8g8E84aLIUHqoluYIbpl+S20gwogRyWLLiXzK4o9qh63iELkTc8kyelEcgPx75GU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5AFB7DEDEA758746A0A2BD8191A9CC92@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f881a8d1-95c3-4b3d-ef8a-08d78b6f731a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2019 08:25:08.3231 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rWnqscoYrjO1Fh5vu64qFl3Vuyrb+0q/oHwqAGsRGEHGf58MdMEhncmibtCU+Rk+EW0856AD1bRyVmMlkreRbzr0vmtQEmikL+ymxlswnTg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2298 Archived-At: Subject: Re: [Emu] WGLC for draft-ietf-emu-eap-session-id-01 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 08:25:15 -0000 VGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIChXR0xDKSBmb3IgdGhpcyBkb2N1bWVudCBoYXMg ZW5kZWQgd2l0aG91dCANCmFueSBvYmplY3Rpb25zLiBJIHJhbiB0aGUgZG9jdW1lbnQgdGhyb3Vn aCB0aGUgaWQtbml0cyB0b29sIGFuZCBub3RpY2VkIA0KdGhlIGZvbGxvd2luZyBpc3N1ZXM6DQoN Ci0gT2Jzb2xldGUgbm9ybWF0aXZlIHJlZmVyZW5jZTogUkZDIDUyOTYgKE9ic29sZXRlZCBieSBS RkMgNjY5NikNCg0KLSByZmM1NDQ4YmlzLTA0LnR4dCBpcyBpbiB0aGUgcmVmZXJlbmNlIGxpc3Qg YnV0IG5vdCBjaXRlZCBpbiB0ZXh0LiBJIA0KcmVjb21tZW5kIHRvIG1vdmUgdGhlIHRleHQgYWJv dXQgcmZjNTQ0OGJpcyBmcm9tIHRoZSBhYnN0cmFjdCB0byB0aGUgDQppbnRyb2R1Y3Rpb24gYW5k IGNpdGUgdGhlIGRvY3VtZW50IHRoZXJlLiBQbGVhc2UgYWxzbyB1cGRhdGUgdGhlIA0KcmVmZXJl bmNlIHRvIHRoZSBsYXRlc3QgdmVyc2lvbjogZHJhZnQtaWV0Zi1lbXUtcmZjNTQ0OGJpcy0wNi4N Cg0KQWxzbywgZm9yIFBFQVAsIHRoZSBjdXJyZW50IHRleHQgc2F5czogJ0EgZGlmZmVyZW50IGRl cml2YXRpb24gaXMgDQpkZWZpbmVkIGZvciBUTFMgMS4zJy4gQ2FuIHlvdSBhZGQgYSByZWZlcmVu Y2UgdG8gDQpkcmFmdC1kZWtvay1lbXUtdGxzLWVhcC10eXBlcy0wMCBoZXJlPw0KDQpAQWxhbjoN Cg0KUGxlYXNlIHN1Ym1pdCBhIG5ldyB2ZXJzaW9uIGFuZCB3ZSB3aWxsIHNlbmQgdGhpcyBmb3J3 YXJkIHRvIHRoZSBJRVNHLiANClRvIGV4cGVkaXRlIHRoZSBwcm9jZXNzLCBsZXQgbWUgYWxyZWFk eSBhc2sgdGhlIGZvbGxvd2luZyA6DQoNCkNhbiB5b3UgY29uZmlybSBpZiBhbGwgYXBwcm9wcmlh dGUgSVBSIGRpc2Nsb3N1cmVzIHJlcXVpcmVkIGZvciBmdWxsIA0KY29uZm9ybWFuY2Ugd2l0aCB0 aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVlbiANCmZp bGVkIGZvciBkcmFmdC1pZXRmLWVtdS1lYXAtc2Vzc2lvbi1pZD8NCg0KLS1Nb2hpdA0KDQpPbiAx MS8yNi8xOSAzOjA4IFBNLCBNb2hpdCBTZXRoaSBNIHdyb3RlOg0KPiBEZWFyIGFsbCwNCj4NCj4g VGhpcyBlbWFpbCBpbml0aWF0ZXMgdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIChXR0xDKSBm b3INCj4gZHJhZnQtaWV0Zi1lbXUtZWFwLXNlc3Npb24taWQNCj4gKGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVtdS1lYXAtc2Vzc2lvbi1pZC0wMSkuMA0KPg0KPiBJZiB5 b3UgaGF2ZSBhbnkgcmVtYWluaW5nIGNvbmNlcm5zIG9yIGlzc3VlcywgcGxlYXNlIGNvbW1lbnQg b24gdGhlDQo+IG1haWxpbmcgbGlzdCBiZWZvcmUgdGhlIFdHTEMgZXhwaXJlcyBvbiBEZWNlbWJl ciAxMCwgMjAxOS4NCj4NCj4gVGhhbmtzLA0KPiBKb2UgYW5kIE1vaGl0DQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVtdSBtYWlsaW5nIGxp c3QNCj4gRW11QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZW11DQo= From nobody Sat Dec 28 05:29:48 2019 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 C05B812007C for ; Sat, 28 Dec 2019 05:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 1CrgH5tVLhKz for ; Sat, 28 Dec 2019 05:29:44 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C0F12004F for ; Sat, 28 Dec 2019 05:29:44 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 8972E253 for ; Sat, 28 Dec 2019 13:29:41 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Sat, 28 Dec 2019 08:29:40 -0500 References: <157747285825.29960.15830219994236578624@ietfa.amsl.com> To: emu@ietf.org In-Reply-To: <157747285825.29960.15830219994236578624@ietfa.amsl.com> Message-Id: <15472C80-D403-4B77-BFEE-574BD2520638@deployingradius.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-08.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 13:29:47 -0000 On Dec 27, 2019, at 1:54 PM, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tls13-08 Which adds some text about identities: It is RECOMMENDED to use anonymous NAIs with the same realm = in the=09 resumption and the original full authentication. This = requirement=09 allows EAP packets to be routable to the same destination as = the=09 original full authentication. That's good, thanks. I still would prefer some additional text as I = had suggested. The text explains related issues in more detail: The alternative is to derive the EAP Identity from the identity used inside of TLS. This derivation is common practice when using certificates, and works because the "common name" field in the certificate is typically compatible with EAP, and it contains a routable identifier such as an email address. This practice cannot be used for resumption, as the PSK identity may be a binary blob, and it might not contain a routable realm as suggested by RFC 7542. In some cases, the PSK identity is derived by the underlying TLS implementation, and cannot be controlled by the EAP authenticator. These limitations make the PSK identity unsuitable for use as the EAP Identity. I find it's easier for people to follow recommendations when they have = a full picture of the pros and cons of the choices being recommended. For the original authentication: Anonymous NAIs MAY be derived from=09 the client certificate used in TLS. Client certificates = typically=09 contains an identity with a routable domain such as an email = address. How is this derivation done? Many things "may" be done, but that = doesn't help guide *why* or *how* things are done. If there's no clear guidance possible, then that should be said, too. I also believe that the document should also RECOMMEND that the = EAP-Response/Identity be in the form of an anonymous NAI. I would prefer to have a separate section about identities. I find the = current text a bit unclear. It helps to explain why an anonymized NAI is = useful, even when there is no email address in a certificate. Alan DeKok.