From nobody Mon Jun 1 06:44:01 2020 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 C30893A1068; Mon, 1 Jun 2020 06:43:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-emu-eap-session-id@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Mohit Sethi , mohit.m.sethi@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <159101903977.29937.11122568970604500216@ietfa.amsl.com> Date: Mon, 01 Jun 2020 06:43:59 -0700 Archived-At: Subject: [Emu] Warren Kumari's No Objection on draft-ietf-emu-eap-session-id-04: (with COMMENT) 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: Mon, 01 Jun 2020 13:44:00 -0000 Warren Kumari has entered the following ballot position for draft-ietf-emu-eap-session-id-04: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document — this is far outside my expertise, so I’m balloting NoObjection, because, well, I have no objection :-) Do please see the OpsDir comments at https://datatracker.ietf.org/doc/review-ietf-emu-eap-session-id-03-opsdir-lc-dodge-2020-05-24/ , for some useful nits... From nobody Mon Jun 1 09:59:03 2020 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 AEFC03A1277; Mon, 1 Jun 2020 09:58:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <159103073666.19793.14987376135189550235@ietfa.amsl.com> Date: Mon, 01 Jun 2020 09:58:56 -0700 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eap-noob-01.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: Mon, 01 Jun 2020 16:58:57 -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 : Nimble out-of-band authentication for EAP (EAP-NOOB) Authors : Tuomas Aura Mohit Sethi Filename : draft-ietf-emu-eap-noob-01.txt Pages : 63 Date : 2020-06-01 Abstract: Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB message between the peer device and authentication server to authenticate the in-band key exchange. The device must have an input or output interface, such as a display, microphone, speakers or blinking light, which can send or receive dynamically generated messages of tens of bytes in length. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-01 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 Tue Jun 2 00:29:20 2020 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 AA1143A08E4 for ; Tue, 2 Jun 2020 00:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=microsoft.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 kxxkoI0MPho0 for ; Tue, 2 Jun 2020 00:29:16 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690102.outbound.protection.outlook.com [40.107.69.102]) (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 98A713A08E3 for ; Tue, 2 Jun 2020 00:29:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TJGE1vM15F6PXuWJM5t3TtYJHFRZjsKr9b952c7hsg8hVCyrynCcmBkh7qB8QpxG65DQ361/NSIeDofxETrDjklZVEM2Xe/q3S1flaxDRtF8xZIxwZ36R2zsgZPXekGEmI2eDEcuHMYhL8A+HWA99xjJG7oC994tQKX3+sHe8ytnbEy7ut5xd+fzJ9b/hC9W5lUJsy4GN/C2PheuXgY21of+uHwo8JRPd7MI5/SgnqYGiVqigEDZLtQYWZ7BJVRciGu9QuuQkNyPLkA9TIw7On6pX/3eW6tF22W56UvtsK11CF1k9+TAJLp/s3a8HHSL6ZmIlP/q6NLIy62wQQKrTQ== 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=3aC3KPMGZhtrPYjMdt+f3v4fuYSXQ1HSg1WYJoPPxz0=; b=lsNj+gvtJlyQ/jqaofbc9CZui90KWF3V5udy8uXTnNtztGZDlJAtKcW8tkFQ320N2A1Q0Ct/n9hep/4hi0HOaf/YREyzyhf6lE+D2bUWQMBMT34ca5KQ4hRfxqDcPMQjX5o/dqRyWYgjVBUnkkn2URJRKyUMaVnFbuzr/U5OohELbBo7KqiBFm+NN9O5YQoLKf6I+rn1xfSO5JdNu4r7va/mHdA87QhZaglbR6SH3oXBcHpqh7TQ50rJeu1loc6u6xvRiETHVTSmRJYqDRBHi85Kyh8aL5X73mhYwSkHNBMqwcSaLTBiSRFrQXzOqNTbYiWsrCs6984Xrbz9QkvTjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3aC3KPMGZhtrPYjMdt+f3v4fuYSXQ1HSg1WYJoPPxz0=; b=dPauDt3fYeAcQ/c3Ix85NDbRSQ7LY3vMVXAYjdU3rYk9UDQ/kEN55YXmc+GheFgAC1AbZjBc3Ej1tEIP0KkxwWebhEMJOUWmH7sFAMS6pJaAkb8JRivx93Ju7Vc00rjCFheRd6Q+B7rNGRdYNHZGwZdiVofk9zCFgEhyvDKwj2Y= Received: from CH2PR21MB1381.namprd21.prod.outlook.com (2603:10b6:610:8e::12) by CH2PR21MB1496.namprd21.prod.outlook.com (2603:10b6:610:89::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.3; Tue, 2 Jun 2020 07:29:15 +0000 Received: from CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::ed84:e1bc:d1e6:76f8]) by CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::ed84:e1bc:d1e6:76f8%6]) with mapi id 15.20.3088.000; Tue, 2 Jun 2020 07:29:15 +0000 From: Jorge Vergara To: EMU WG Thread-Topic: jovergar review of draft-dekok-emu-tls-eap-types-02 Thread-Index: AdY4qHgFlRXQO3eHSmyWCI8KYiEUtA== Date: Tue, 2 Jun 2020 07:29:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-02T07:29:13Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=e422eea4-7c2f-4c1e-ba32-e4c4bc779731; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8:b859:e465:5fdd:aa5e] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1eb13f43-c313-4ddc-0616-08d806c6a734 x-ms-traffictypediagnostic: CH2PR21MB1496: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0422860ED4 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4F+18a/Jlv4Jz6ap7E5Dux2PjYlcD3UlfdtfVFec0oNk7sFb0wDqY8OrEUcb+anxCT9oYzrdEJxUpUWxJLIjernCwNsb7+VkGNpQfiLMiJoMhh3unGSgVsctTNsAS4B73XtqTD9tl5m4m9zQfFCL1DsflN0LwAqIWVMOMXi1ytql4wsxSvue8FIbLtDvUGe1PeCXvCyUulpA1iMLrYHymhxGnCu3QrK7UtjAmK+yQXFbTMYOvmllEFOvpkLOoVR9aoPaBoDoXzhm4ljyrNGyvdQeU+vGqE0K0c6htolLljFfN2eXgEDths7QdoAhmJ65XRwQ1ravZQBr4ftLCidVKx1pT3V2ejYCskpOeAflsQiXC0QWLNQKHCB07IBrxHb6bsRkfMyBhjZRG77HLOzhpw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR21MB1381.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(366004)(39860400002)(396003)(346002)(186003)(76116006)(71200400001)(5660300002)(7696005)(6506007)(64756008)(66556008)(2906002)(66446008)(33656002)(66946007)(316002)(66476007)(10290500003)(55016002)(86362001)(478600001)(8676002)(6916009)(8990500004)(8936002)(9686003)(83380400001)(82950400001)(82960400001)(52536014)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: rFJw7KD91y1KpMfpmIz1LybRz+VAguyWnWYiihPsyqgpGmv4/5wcweN8N9Z7eqRAAOZF2EXun6S/wXh5x94NuGTNy8BxPGLHQHEpoYiWyQNVDaYi4gFJkw6JTK9oK+5NuMzIT6of1XxHyUMGSwcaRM1DS6vGqoHFSwx4YR83llwiMd6G1U+AvHO4YVISwmf8NPXQTYsJw45tGdE3xMGKrr7tIElw2Okj39y/3gMUKFv+HuvSkv/QUVvqjLbgpraDg+MfnSmc3GXM9UVmdRqOaM6hVJivmZDADnoI6janSk5/b1jjS2ak61lyE8UVqsMtIIVI8ZmJRuiPAAefQWHoI+Ox5B+vQTPG7Po2bAYs4lHQiAtT9iO+gDT6c09g0X5ZJ44Ohup18vKUn7XkrO5n+TG/BPBfTFCe5RLHB+JA5yXnGkhDMNM2abLGAftcNEGbCGtpah1CYXt/z3qurFpNkbi35T0dYeiywpzkWjQJ+bGDLg8pcRS/YyP1WYrjanmSXoDAxaAxTm1g1BdqWkpZu166v6ESCeaSb71crrHAB8g= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR21MB13812FAA89097AE25F72186DD18B0CH2PR21MB1381namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1eb13f43-c313-4ddc-0616-08d806c6a734 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2020 07:29:14.9987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: m/5FeifydUZdfGZtKV1x4R93K+OEOeHtXcMmnBEAddy8nTA9YWs25uRvxUvdEPeQmBpDRLm3vp0HHxgnjkLzdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR21MB1496 Archived-At: Subject: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02 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, 02 Jun 2020 07:29:19 -0000 --_000_CH2PR21MB13812FAA89097AE25F72186DD18B0CH2PR21MB1381namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've attempted/completed a prototype implementation of EAP-TLS, PEAP, EAP-T= TLS, and TEAP clients using TLS 1.3. EAP-TLS went smoothly so this boils do= wn to a review of the subject line document which addresses the rest of the= EAP types. I am not necessarily an expert on all of TLS 1.3 so some of my = issues may just be a lack of understanding - please point this out if so. I had the following questions/issues that may need to be addressed in this = document: 1. PEAP Key Material when crypto binding is used. When PEAP uses crypto = binding, it uses a different key material calculation that consumes inner method key material. This is not addressed i= n this document. If we fallback to what is currently defined, we end up wit= h PEAP's definition of PRF+, which despite = the name is hardcoded to SHA1. Since it's hard-coded to SHA1 and doesn't te= chnically depend on the TLS-PRF, it technically could continue to be used. = But, is there a desire to update this key material calculation as well to u= se the TLS-Exporter as with the rest of the calculations? If not, I believ= e it's still worth a mention, since I see it being a point of confusion. 1. TTLS Implicit Challenge. The TLS-PRF is currently used to calculate t= he implicit challenge for= CHAP, MS-CHAP, and MS-CHAP-V2 (non-EAP). This isn't currently covered in t= he document. In TTLS, differing amounts of challenge material are needed ba= sed on whether CHAP, MS-CHAP, or MS-CHAP-V2 is being used. It's probably su= fficient to define one exporter of a suitable length for all three and trun= cate to the amount needed. 2. TEAP Compound MAC. The TEAP Compound MAC is currently defined in terms of the "MAC function neg= otiated in TLS 1.2." If TEAP is to remain in this document, I believe this = should be clarified. Here my familiarity with TLS 1.3 becomes an issue as I= am not sure whether this is a simple wording update or if the calculation = needs to be re-defined. (as an aside, I am in favor of TEAP in this documen= t but understand if the consensus is to separate it) 3. TEAP Inner Method Session Key. When an inner authentication method su= pports exporting an EMSK, the definition of the IMSK relies on the TLS-PRF and so needs to be adjuste= d. 4. Section 5 of this document is out of date with the EAP-TLS document. = It mentions that an empty application record is used to indicate negotiatio= n has finished - this is now a size 1 0x00 application record. 5. Section 5 further mentions that methods which use inner tunnel method= s should instead begin their inner tunnel negotiation by sending type speci= fic application data. The inner tunnel is optional for PEAP, EAP-TTLS, and = TEAP, especially if resumption is used. So it's not clear to me how to indi= cate negotiation has finished in these methods. I believe the 0x00 octet fr= om EAP-TLS is needed here as well. I appreciate the effort gone into this thus far. I believe the adjustments = needed are fairly simple and after the above issues are solved I could comp= lete my prototypes. Thanks, Jorge Vergara --_000_CH2PR21MB13812FAA89097AE25F72186DD18B0CH2PR21MB1381namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’ve attempted/completed a prototype implement= ation of EAP-TLS, PEAP, EAP-TTLS, and TEAP clients using TLS 1.3. EAP-TLS w= ent smoothly so this boils down to a review of the subject line document wh= ich addresses the rest of the EAP types. I am not necessarily an expert on all of TLS 1.3 so some of my issues may = just be a lack of understanding – please point this out if so.

 

I had the following questions/issues that may need t= o be addressed in this document:

 

  1. PEAP Key Material when crypto binding is used. When PEAP uses crypto = binding, it uses a different key material calculation that consumes inner method key mater= ial. This is not addressed in this document. If we fallback to what is curr= ently defined, we end up with PEAP’s definition of PRF+, which despite the name is hardcode= d to SHA1. Since it’s hard-coded to SHA1 and doesn’t technicall= y depend on the TLS-PRF, it technically could continue to be used. But, is = there a desire to update this key material calculation as well to use the TLS-Exporter as with the rest of the calculations? &nbs= p;If not, I believe it’s still worth a mention, since I see it being = a point of confusion.

 

  1. TTLS Implicit Challenge. The TLS-PRF is currently used to calculate t= he implicit chall= enge for CHAP, MS-CHAP, and MS-CHAP-V2 (non-EAP). This isn’t curr= ently covered in the document. In TTLS, differing amounts of challenge mate= rial are needed based on whether CHAP, MS-CHAP, or MS-CHAP-V2 is being used. It’s probably sufficient to define one = exporter of a suitable length for all three and truncate to the amount need= ed.

  2. TEAP Compound MAC. The TEAP Compound M= AC is currently defined in terms of the “MAC function negotiated = in TLS 1.2.” If TEAP is to remain in this document, I believe this sh= ould be clarified. Here my familiarity with TLS 1.3 becomes an issue as I am not sure whether this is a simple wording upd= ate or if the calculation needs to be re-defined. (as an aside, I am in fav= or of TEAP in this document but understand if the consensus is to separate = it)

  3. TEAP Inner Method Session Key. When an inner authenti= cation method supports exporting an EMSK, the definition of t= he IMSK relies on the TLS-PRF and so needs to be adjusted.

  4. Section 5 of this document is out of date with the EA= P-TLS document. It mentions that an empty application record is used to ind= icate negotiation has finished – this is now a size 1 0x00 application record.

  5. Section 5 further mentions that methods which use inn= er tunnel methods should instead begin their inner tunnel negotiation by se= nding type specific application data. The inner tunnel is optional for PEAP, EAP-TTLS, and TEAP, especially if resumption is used= . So it’s not clear to me how to indicate negotiation has finished in= these methods. I believe the 0x00 octet from EAP-TLS is needed here as wel= l.

 

I appreciate the effort gone into this thus far. I b= elieve the adjustments needed are fairly simple and after the above issues = are solved I could complete my prototypes.

 

Thanks,

Jorge Vergara

--_000_CH2PR21MB13812FAA89097AE25F72186DD18B0CH2PR21MB1381namp_-- From nobody Tue Jun 2 06:09:37 2020 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 8EECA3A08E3 for ; Tue, 2 Jun 2020 06:09:35 -0700 (PDT) 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 dclKeIHenAA2 for ; Tue, 2 Jun 2020 06:09:33 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED40D3A08E9 for ; Tue, 2 Jun 2020 06:09:32 -0700 (PDT) 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 2D0EAC4; Tue, 2 Jun 2020 13:09:29 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: Date: Tue, 2 Jun 2020 09:09:28 -0400 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <28E366D3-AEB0-49FF-A155-F4B08B47030E@deployingradius.com> References: To: Jorge Vergara X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02 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, 02 Jun 2020 13:09:36 -0000 On Jun 2, 2020, at 3:29 AM, Jorge Vergara = wrote: > =20 > I=E2=80=99ve attempted/completed a prototype implementation of = EAP-TLS, PEAP, EAP-TTLS, and TEAP clients using TLS 1.3. EAP-TLS went = smoothly so this boils down to a review of the subject line document = which addresses the rest of the EAP types. I am not necessarily an = expert on all of TLS 1.3 so some of my issues may just be a lack of = understanding =E2=80=93 please point this out if so. Thanks. Is the source available somewhere? It would be good to have = multiple implementations for interoperability testing. > I had the following questions/issues that may need to be addressed in = this document: > =20 > =E2=80=A2 PEAP Key Material when crypto binding is used. When = PEAP uses crypto binding, it uses a different key material calculation = that consumes inner method key material. This is not addressed in this = document. If we fallback to what is currently defined, we end up with = PEAP=E2=80=99s definition of PRF+, which despite the name is hardcoded = to SHA1. Since it=E2=80=99s hard-coded to SHA1 and doesn=E2=80=99t = technically depend on the TLS-PRF, it technically could continue to be = used. But, is there a desire to update this key material calculation as = well to use the TLS-Exporter as with the rest of the calculations? If = not, I believe it=E2=80=99s still worth a mention, since I see it being = a point of confusion. I'm happy to leave the PRF+ calculation alone. It uses HMAC-SHA1, = which seems fine. > =20 > =E2=80=A2 TTLS Implicit Challenge. The TLS-PRF is currently used = to calculate the implicit challenge for CHAP, MS-CHAP, and MS-CHAP-V2 = (non-EAP). This isn=E2=80=99t currently covered in the document. In = TTLS, differing amounts of challenge material are needed based on = whether CHAP, MS-CHAP, or MS-CHAP-V2 is being used. It=E2=80=99s = probably sufficient to define one exporter of a suitable length for all = three and truncate to the amount needed. I don't see that this needs to change, but it is worth a mention in = the document. i.e. TTLS uses the TLS-PRF with a label of "ttls challenge". The = length of the challenge material can simply be taken from the = requirements. So we don't need to define multiple exporters. > =E2=80=A2 TEAP Compound MAC. The TEAP Compound MAC is currently = defined in terms of the =E2=80=9CMAC function negotiated in TLS 1.2.=E2=80= =9D If TEAP is to remain in this document, I believe this should be = clarified. Here my familiarity with TLS 1.3 becomes an issue as I am not = sure whether this is a simple wording update or if the calculation needs = to be re-defined. (as an aside, I am in favor of TEAP in this document = but understand if the consensus is to separate it) I'm not sure here. > =E2=80=A2 TEAP Inner Method Session Key. When an inner = authentication method supports exporting an EMSK, the definition of the = IMSK relies on the TLS-PRF and so needs to be adjusted.=20 OK. I'm less sure of what should be done here. I'll take a look. > =E2=80=A2 Section 5 of this document is out of date with the = EAP-TLS document. It mentions that an empty application record is used = to indicate negotiation has finished =E2=80=93 this is now a size 1 0x00 = application record. Good point. I'll update the doc. > =E2=80=A2 Section 5 further mentions that methods which use = inner tunnel methods should instead begin their inner tunnel negotiation = by sending type specific application data. The inner tunnel is optional = for PEAP, EAP-TTLS, and TEAP, especially if resumption is used.. So = it=E2=80=99s not clear to me how to indicate negotiation has finished in = these methods. I believe the 0x00 octet from EAP-TLS is needed here as = well. I think so, yes. > I appreciate the effort gone into this thus far. I believe the = adjustments needed are fairly simple and after the above issues are = solved I could complete my prototypes. I'll take a look this week. I also hope to have FreeRADIUS updated = for TLS 1.3, too. Alan DeKok. From nobody Tue Jun 2 11:50:37 2020 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 A55EA3A0F2E for ; Tue, 2 Jun 2020 11:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=microsoft.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 cUThOXtNur8y for ; Tue, 2 Jun 2020 11:50:34 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750100.outbound.protection.outlook.com [40.107.75.100]) (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 D41C33A0F17 for ; Tue, 2 Jun 2020 11:50:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RWuVqqYyDI7iUHfIUwa/1dBebwuLLq2fQs1wKT9RGhKWSSCnLPrA0x7qOH1GGm+McnYIPDryJ9bfcZuOSmRN0qqyBrHZ8rSRqeWAwMLBnbhoFY+2N9M7cNNvnSmz5W6VYMoEaru5YNnaIu7dTlWWejS4vPjHiRWoRQopyNXpfAB4whPQqIAqOJh5lvJ+rmFUlmviBjrwpnle7/uqgKSHk7UaxX/6f5vi78oZZ1Pb3M8x1uqBciZ0CkOTDv6+y/ptRE7lX5loU1jET8iLqKk0XqXXOEFn9ulNZUlZldMlPtucm1ABhGcTEKx6Phf+kWz03z5RIGq3bMo19smdBnlKWA== 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=NwugfwWioj4C65ov/mDFuakkIthzlrxpKOXaoX0G/rs=; b=A3Th/6pUUC5bHbhv7MsuTFBR8yxy4LNkNkIHp4XZEITmU9RVTeojBnjbRnuQXGgqcOKMb5lDFq9NELXrUsq8A8t/tdLTDjpR5FftSuhinKI3uCVSpYoegNiJ7PRwCDo6LrSIwH6aBFdzYMR0yGRhvMiBEBEqoeAZQkZ6YhwKaXgbL0T4JOn41vjZIKyhg/gT/TBFM9sI6oaRHn4NYX17yRZIFUEYba5BFYHpHUhHY0SP/t1C4mSnoMMxVP+qZL+7vFzx2yoqh/f1LtHRUrtCycD8CZfGro3c3XTCn+H10bQpY25rx8KlFNr0d9XlFRaI8lK4PwubSuYYM7Tuv+f0iQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NwugfwWioj4C65ov/mDFuakkIthzlrxpKOXaoX0G/rs=; b=VSl4pZb8iFuO3qEbmi7DmdZ8empIliY9Abki5k5ZwsBeo0PSS0YOR5yRa6dZ6hljJup6WlQE74q0aUD9/fhs3U7CPS9jkSmTBWRpCNlObzJLV2LPB+1+M/dCrPdHtk5Ddo04ia0cBQ5LJ+whoEONlqWOQNmXiz/R3RwS47zz9aQ= Received: from CH2PR21MB1381.namprd21.prod.outlook.com (2603:10b6:610:8e::12) by CH2PR21MB1447.namprd21.prod.outlook.com (2603:10b6:610:8c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.3; Tue, 2 Jun 2020 18:50:31 +0000 Received: from CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::ed84:e1bc:d1e6:76f8]) by CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::ed84:e1bc:d1e6:76f8%6]) with mapi id 15.20.3088.000; Tue, 2 Jun 2020 18:50:31 +0000 From: Jorge Vergara To: Alan DeKok CC: EMU WG Thread-Topic: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02 Thread-Index: AdY4qHgFlRXQO3eHSmyWCI8KYiEUtAANpO4AAAvHbdA= Date: Tue, 2 Jun 2020 18:50:31 +0000 Message-ID: References: <28E366D3-AEB0-49FF-A155-F4B08B47030E@deployingradius.com> In-Reply-To: <28E366D3-AEB0-49FF-A155-F4B08B47030E@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-02T18:50:30Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b5237714-01e3-428f-907e-c502e0fce0e9; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8:b859:e465:5fdd:aa5e] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0c850bbb-11b6-4197-acc7-08d80725d3ac x-ms-traffictypediagnostic: CH2PR21MB1447: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0422860ED4 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MvoGu+w9Thu5FGYjbhr/v6tA4tRyF3rFUE85zF+VVF86w+0TU26R7MCIENyZKtGyiIAtxpPxctrk1moU00Z7p5Z1p9YTeSFojPJB3t9+Pe5krTF0LzM5/RpYQe1PPgg/y+g3Yy6fvUEXl6765SsRRre5lSVWqmou9B/4KVfMR98gK5kB8mIB7UT78eF6RDTx3UerzN6AnOQayrryc+5P5YEmtM8xv5A4x6p6XDxVuAfhVILAzULQRaad2Gsrs4yhzmYV3EreTK/10IOYlvfgngkugTrUni915zyK1MevUBpI/GNl6FzB0zV1wcVUho4iB+DnheqttQoNAfylFWb4kg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR21MB1381.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(33656002)(10290500003)(66476007)(5660300002)(66946007)(186003)(66556008)(76116006)(64756008)(478600001)(55016002)(4326008)(8990500004)(8676002)(52536014)(9686003)(86362001)(316002)(83380400001)(2906002)(7696005)(66446008)(6506007)(53546011)(8936002)(82960400001)(82950400001)(6916009)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 8YVj17TJAjktffZRypaKixHnpy1EIrUX/bBf1Gm8sCS2IRkC7tyaC0MeZQ2v7XjE8ZnQcOSnLpggKlMBpR0YI25Y/gGwlVG86mWNchN2ZZ0YHrdc88FMKS2HW6cSsg7PdBURv+JGRnjgDRHS+TRsKBGqY+SglMAtmUMqnaGEWSVGczZTk5zLdeJ2uG/RLH/Yamcaa6sahLfuHUsfBaran2jaDNhJr19vWbMVGYOChwD9ecuxVjIJJGo2rwA/J6GAaAAbbajD0/7j0dHG2x/FbyYW6PiqstVBsYZlt2p6ycUj+aJUdK6oxTT3u69hX84YofCByokDAX2zLM0X9N3cPcfdeVjOGyrSn3Ag9R0yXSIgdor3Kbg4rsQpvXCJhwW0dxgzDn2iT8837jgKB1ICySasNrKyBl4UYkznKaJQYEwSJbMGzOfoEy2p1MEAu3qC2mIDYeBnRHTePSj6SOkAjevXE/tkhFkhqKS4bRg+HVhHvWW9qsjaiJqz9XYiNFQVnwbOWtSK0sjKGittGDV4v/+nb3ZyFnV57MCJ4LvCnBY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c850bbb-11b6-4197-acc7-08d80725d3ac X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2020 18:50:31.8532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sdwR9JD2YHbxo6d0sQcG1DCUi3+Q1oJQnSyXyeMuqGvMuTxdl3rPBtJo7q1TsnKHnt/2vdxZ60AP9tOmdbNGdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR21MB1447 Archived-At: Subject: Re: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02 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, 02 Jun 2020 18:50:36 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGFuIERlS29rIDxhbGFuZEBk ZXBsb3lpbmdyYWRpdXMuY29tPiANClNlbnQ6IFR1ZXNkYXksIEp1bmUgMiwgMjAyMCA2OjA5IEFN DQpUbzogSm9yZ2UgVmVyZ2FyYSA8am92ZXJnYXJAbWljcm9zb2Z0LmNvbT4NCkNjOiBFTVUgV0cg PGVtdUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRW11XSBqb3ZlcmdhciByZXZpZXcgb2YgZHJh ZnQtZGVrb2stZW11LXRscy1lYXAtdHlwZXMtMDINCg0KT24gSnVuIDIsIDIwMjAsIGF0IDM6Mjkg QU0sIEpvcmdlIFZlcmdhcmEgPGpvdmVyZ2FyPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y Zz4gd3JvdGU6DQo+PiAgDQo+PiBJ4oCZdmUgYXR0ZW1wdGVkL2NvbXBsZXRlZCBhIHByb3RvdHlw ZSBpbXBsZW1lbnRhdGlvbiBvZiBFQVAtVExTLCBQRUFQLCBFQVAtVFRMUywgYW5kIFRFQVAgY2xp ZW50cyB1c2luZyBUTFMgMS4zLiBFQVAtVExTIHdlbnQgc21vb3RobHkgc28gdGhpcyBib2lscyBk b3duIHRvIGEgcmV2aWV3IG9mIHRoZSBzdWJqZWN0IGxpbmUgZG9jdW1lbnQgd2hpY2ggYWRkcmVz c2VzIHRoZSByZXN0IG9mIHRoZSBFQVAgdHlwZXMuIEkgYW0gbm90IG5lY2Vzc2FyaWx5IGFuIGV4 cGVydCBvbiBhbGwgb2YgVExTIDEuMyBzbyBzb21lIG9mIG15IGlzc3VlcyBtYXkganVzdCBiZSBh IGxhY2sgb2YgdW5kZXJzdGFuZGluZyDigJMgcGxlYXNlIHBvaW50IHRoaXMgb3V0IGlmIHNvLg0K DQo+ICBUaGFua3MuICBJcyB0aGUgc291cmNlIGF2YWlsYWJsZSBzb21ld2hlcmU/ICBJdCB3b3Vs ZCBiZSBnb29kIHRvIGhhdmUgbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zIGZvciBpbnRlcm9wZXJh YmlsaXR5IHRlc3RpbmcuDQoNClVuZm9ydHVuYXRlbHkgSSB1c2UgY29kZSBmcm9tIHRoZSBXaW5k b3dzIG9wZXJhdGluZyBzeXN0ZW0gYW5kIHNvIGFtIG5vdCBhYmxlIHRvIHNoYXJlIG15IHNvdXJj ZSBhdCB0aGlzIHRpbWUuIEkgdW5kZXJzdGFuZCBhbiBvcGVuIHNvdXJjZSBpbXBsZW1lbnRhdGlv biB3b3VsZCBiZSBiZXR0ZXIgYnV0IGFtIGhhcHB5IHRvIHRlc3QgYWdhaW5zdCBhbnkgc2VydmVy IGltcGxlbWVudGF0aW9ucyB0aGF0IGJlY29tZSBhdmFpbGFibGUuIEknbSBjdXJyZW50bHkgdGVz dGluZyBhZ2FpbnN0IGhvc3RhcGQuDQoNCj4+IEkgaGFkIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25z L2lzc3VlcyB0aGF0IG1heSBuZWVkIHRvIGJlIGFkZHJlc3NlZCBpbiB0aGlzIGRvY3VtZW50Og0K Pj4gIA0KPj4gCeKAoiBQRUFQIEtleSBNYXRlcmlhbCB3aGVuIGNyeXB0byBiaW5kaW5nIGlzIHVz ZWQuIFdoZW4gUEVBUCB1c2VzIGNyeXB0byBiaW5kaW5nLCBpdCB1c2VzIGEgZGlmZmVyZW50IGtl eSBtYXRlcmlhbCBjYWxjdWxhdGlvbiB0aGF0IGNvbnN1bWVzIGlubmVyIG1ldGhvZCBrZXkgbWF0 ZXJpYWwuIFRoaXMgaXMgbm90IGFkZHJlc3NlZCBpbiB0aGlzIGRvY3VtZW50LiBJZiB3ZSBmYWxs YmFjayB0byB3aGF0IGlzIGN1cnJlbnRseSBkZWZpbmVkLCB3ZSBlbmQgdXAgd2l0aCBQRUFQ4oCZ cyBkZWZpbml0aW9uIG9mIFBSRissIHdoaWNoIGRlc3BpdGUgdGhlIG5hbWUgaXMgaGFyZGNvZGVk IHRvIFNIQTEuIFNpbmNlIGl04oCZcyBoYXJkLWNvZGVkIHRvIFNIQTEgYW5kIGRvZXNu4oCZdCB0 ZWNobmljYWxseSBkZXBlbmQgb24gdGhlIFRMUy1QUkYsIGl0IHRlY2huaWNhbGx5IGNvdWxkIGNv bnRpbnVlIHRvIGJlIHVzZWQuIEJ1dCwgaXMgdGhlcmUgYSBkZXNpcmUgdG8gdXBkYXRlIHRoaXMg a2V5IG1hdGVyaWFsIGNhbGN1bGF0aW9uIGFzIHdlbGwgdG8gdXNlIHRoZSBUTFMtRXhwb3J0ZXIg YXMgd2l0aCB0aGUgcmVzdCBvZiB0aGUgY2FsY3VsYXRpb25zPyAgSWYgbm90LCBJIGJlbGlldmUg aXTigJlzIHN0aWxsIHdvcnRoIGEgbWVudGlvbiwgc2luY2UgSSBzZWUgaXQgYmVpbmcgYSBwb2lu dCBvZiBjb25mdXNpb24uDQoNCj4gIEknbSBoYXBweSB0byBsZWF2ZSB0aGUgUFJGKyBjYWxjdWxh dGlvbiBhbG9uZS4gIEl0IHVzZXMgSE1BQy1TSEExLCB3aGljaCBzZWVtcyBmaW5lLg0KDQpXb3Jr cyBmb3IgbWUsIEkganVzdCB3YW50ZWQgdG8gcmFpc2UgdGhlIHF1ZXN0aW9uLg0KDQo+PiAgDQo+ PiAJ4oCiIFRUTFMgSW1wbGljaXQgQ2hhbGxlbmdlLiBUaGUgVExTLVBSRiBpcyBjdXJyZW50bHkg dXNlZCB0byBjYWxjdWxhdGUgdGhlIGltcGxpY2l0IGNoYWxsZW5nZSBmb3IgQ0hBUCwgTVMtQ0hB UCwgYW5kIE1TLUNIQVAtVjIgKG5vbi1FQVApLiBUaGlzIGlzbuKAmXQgY3VycmVudGx5IGNvdmVy ZWQgaW4gdGhlIGRvY3VtZW50LiBJbiBUVExTLCBkaWZmZXJpbmcgYW1vdW50cyBvZiBjaGFsbGVu Z2UgbWF0ZXJpYWwgYXJlIG5lZWRlZCBiYXNlZCBvbiB3aGV0aGVyIENIQVAsIE1TLUNIQVAsIG9y IE1TLUNIQVAtVjIgaXMgYmVpbmcgdXNlZC4gSXTigJlzIHByb2JhYmx5IHN1ZmZpY2llbnQgdG8g ZGVmaW5lIG9uZSBleHBvcnRlciBvZiBhIHN1aXRhYmxlIGxlbmd0aCBmb3IgYWxsIHRocmVlIGFu ZCB0cnVuY2F0ZSB0byB0aGUgYW1vdW50IG5lZWRlZC4NCg0KPiAgSSBkb24ndCBzZWUgdGhhdCB0 aGlzIG5lZWRzIHRvIGNoYW5nZSwgYnV0IGl0IGlzIHdvcnRoIGEgbWVudGlvbiBpbiB0aGUgZG9j dW1lbnQuDQo+DQo+ICBpLmUuIFRUTFMgdXNlcyB0aGUgVExTLVBSRiB3aXRoIGEgbGFiZWwgb2Yg InR0bHMgY2hhbGxlbmdlIi4gIFRoZSBsZW5ndGggb2YgdGhlIGNoYWxsZW5nZSBtYXRlcmlhbCBj YW4gc2ltcGx5IGJlIHRha2VuIGZyb20gdGhlIHJlcXVpcmVtZW50cy4gIFNvIHdlIGRvbid0IG5l ZWQgdG8gZGVmaW5lIG11bHRpcGxlIGV4cG9ydGVycy4NCg0KU3VyZSwgdGhpcyB3b3JrcyB0b28s IGFzIGxvbmcgYXMgVExTLUV4cG9ydGVyIHJlcGxhY2VzIHRoZSBUTFMtUFJGLg0KDQo+PiAJ4oCi IFRFQVAgQ29tcG91bmQgTUFDLiBUaGUgVEVBUCBDb21wb3VuZCBNQUMgaXMgY3VycmVudGx5IGRl ZmluZWQgaW4gdGVybXMgb2YgdGhlIOKAnE1BQyBmdW5jdGlvbiBuZWdvdGlhdGVkIGluIFRMUyAx LjIu4oCdIElmIFRFQVAgaXMgdG8gcmVtYWluIGluIHRoaXMgZG9jdW1lbnQsIEkgYmVsaWV2ZSB0 aGlzIHNob3VsZCBiZSBjbGFyaWZpZWQuIEhlcmUgbXkgZmFtaWxpYXJpdHkgd2l0aCBUTFMgMS4z IGJlY29tZXMgYW4gaXNzdWUgYXMgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgYSBzaW1w bGUgd29yZGluZyB1cGRhdGUgb3IgaWYgdGhlIGNhbGN1bGF0aW9uIG5lZWRzIHRvIGJlIHJlLWRl ZmluZWQuIChhcyBhbiBhc2lkZSwgSSBhbSBpbiBmYXZvciBvZiBURUFQIGluIHRoaXMgZG9jdW1l bnQgYnV0IHVuZGVyc3RhbmQgaWYgdGhlIGNvbnNlbnN1cyBpcyB0byBzZXBhcmF0ZSBpdCkNCg0K PiAgSSdtIG5vdCBzdXJlIGhlcmUuDQoNCkkgcmVhY2hlZCBvdXQgdG8gYSBjb2xsZWFndWUgb24g dGhlIFdpbmRvd3MgVExTIHRlYW0uIEhlIG1lbnRpb25lZCB0aGF0IHRoZSBIS0RGIGFsc28gaGFz IGEgaGFzaCBmdW5jdGlvbiB0aGF0IGlzIHNpbWlsYXIgdG8gdGhlIFRMUyAxLjIgUFJGIGZ1bmN0 aW9uLiBTbyBhdCBmaXJzdCBnbGFuY2UsIGhlIGRpZCBub3Qgc2VlIGEgbmVlZCB0byByZWRlZmlu ZSB0aGlzIGVudGlyZWx5OyBqdXN0IHJld29yZCB0aGUgdGV4dC4gSGUgc3VnZ2VzdGVkIHNvbWV0 aGluZyBsaWtlICJoYXNoIGZ1bmN0aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgY2lwaGVyIHN1aXRl IG5lZ290aWF0ZWQgZm9yIHRoZSBUTFMgc2Vzc2lvbi4iIGUuZy4sIGZvciBUTFNfQUVTXzEyOF9H Q01fU0hBMjU2LCBFQVAgdXNlcyBTSEEyNTYuDQoNCkhvcGluZyBvdGhlcnMgd2l0aCBtb3JlIFRM UyBleHBlcmllbmNlIGNhbiBjaGltZSBpbiBoZXJlIG9yIHNwZW5kIG1vcmUgdGltZSBvbiB0aGUg d29yZGluZywgYnV0IGEgZmlyc3QgcGFzcyB3b3VsZCBzZWVtIHRvIGluZGljYXRlIHRoaXMgaXMg bW9zdGx5IG9rYXkuDQoNCj4+IAnigKIgVEVBUCBJbm5lciBNZXRob2QgU2Vzc2lvbiBLZXkuIFdo ZW4gYW4gaW5uZXIgYXV0aGVudGljYXRpb24gbWV0aG9kIHN1cHBvcnRzIGV4cG9ydGluZyBhbiBF TVNLLCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgSU1TSyByZWxpZXMgb24gdGhlIFRMUy1QUkYgYW5k IHNvIG5lZWRzIHRvIGJlIGFkanVzdGVkLiANCg0KPiAgT0suICBJJ20gbGVzcyBzdXJlIG9mIHdo YXQgc2hvdWxkIGJlIGRvbmUgaGVyZS4gIEknbGwgdGFrZSBhIGxvb2suDQoNCj4+IAnigKIgU2Vj dGlvbiA1IG9mIHRoaXMgZG9jdW1lbnQgaXMgb3V0IG9mIGRhdGUgd2l0aCB0aGUgRUFQLVRMUyBk b2N1bWVudC4gSXQgbWVudGlvbnMgdGhhdCBhbiBlbXB0eSBhcHBsaWNhdGlvbiByZWNvcmQgaXMg dXNlZCB0byBpbmRpY2F0ZSBuZWdvdGlhdGlvbiBoYXMgZmluaXNoZWQg4oCTIHRoaXMgaXMgbm93 IGEgc2l6ZSAxIDB4MDAgYXBwbGljYXRpb24gcmVjb3JkLg0KDQo+ICBHb29kIHBvaW50LiAgSSds bCB1cGRhdGUgdGhlIGRvYy4NCg0KPj4gCeKAoiBTZWN0aW9uIDUgZnVydGhlciBtZW50aW9ucyB0 aGF0IG1ldGhvZHMgd2hpY2ggdXNlIGlubmVyIHR1bm5lbCBtZXRob2RzIHNob3VsZCBpbnN0ZWFk IGJlZ2luIHRoZWlyIGlubmVyIHR1bm5lbCBuZWdvdGlhdGlvbiBieSBzZW5kaW5nIHR5cGUgc3Bl Y2lmaWMgYXBwbGljYXRpb24gZGF0YS4gVGhlIGlubmVyIHR1bm5lbCBpcyBvcHRpb25hbCBmb3Ig UEVBUCwgRUFQLVRUTFMsIGFuZCBURUFQLCBlc3BlY2lhbGx5IGlmIHJlc3VtcHRpb24gaXMgdXNl ZC4uIFNvIGl04oCZcyBub3QgY2xlYXIgdG8gbWUgaG93IHRvIGluZGljYXRlIG5lZ290aWF0aW9u IGhhcyBmaW5pc2hlZCBpbiB0aGVzZSBtZXRob2RzLiBJIGJlbGlldmUgdGhlIDB4MDAgb2N0ZXQg ZnJvbSBFQVAtVExTIGlzIG5lZWRlZCBoZXJlIGFzIHdlbGwuDQoNCj4gICBJIHRoaW5rIHNvLCB5 ZXMuDQoNCj4+IEkgYXBwcmVjaWF0ZSB0aGUgZWZmb3J0IGdvbmUgaW50byB0aGlzIHRodXMgZmFy LiBJIGJlbGlldmUgdGhlIGFkanVzdG1lbnRzIG5lZWRlZCBhcmUgZmFpcmx5IHNpbXBsZSBhbmQg YWZ0ZXIgdGhlIGFib3ZlIGlzc3VlcyBhcmUgc29sdmVkIEkgY291bGQgY29tcGxldGUgbXkgcHJv dG90eXBlcy4NCg0KPiAgSSdsbCB0YWtlIGEgbG9vayB0aGlzIHdlZWsuICBJIGFsc28gaG9wZSB0 byBoYXZlIEZyZWVSQURJVVMgdXBkYXRlZCBmb3IgVExTIDEuMywgdG9vLg0KDQpUaGFua3MgZm9y IHRoZSB3b3JrIGFuZCBsb29raW5nIGZvcndhcmQgdG8gdGhlIHVwZGF0ZS4NCg0KSm9yZ2UgVmVy Z2FyYQ0K From nobody Tue Jun 2 19:54:52 2020 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 8E64A3A082E; Tue, 2 Jun 2020 19:54:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-emu-eap-session-id@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Mohit Sethi , mohit.m.sethi@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <159115288456.10873.12340295955718946084@ietfa.amsl.com> Date: Tue, 02 Jun 2020 19:54:44 -0700 Archived-At: Subject: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eap-session-id-04: (with COMMENT) 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: Wed, 03 Jun 2020 02:54:45 -0000 Barry Leiba has entered the following ballot position for draft-ietf-emu-eap-session-id-04: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Section 2 — This section updates [RFC5247] ... It further defines Session-ID derivation for PEAP. This section does not address PEAP; that’s done in Section 3. I suggest removing that last sentence. — Section 3 — [RFC5247] did not define Session-Id definition for Microsoft's Protected EAP (PEAP). For consistency with EAP-TLS the definition given in [RFC5216] Section 2.3, we define it as: Both sentences here need some fixing: NEW [RFC5247] did not define Session-Id for Microsoft's Protected EAP (PEAP). For consistency with the EAP-TLS definition given in [RFC5216] Section 2.3, we define it as: END From nobody Wed Jun 3 06:07:03 2020 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 037353A0AB7; Wed, 3 Jun 2020 06:06:57 -0700 (PDT) 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 txkSXZqcf5yX; Wed, 3 Jun 2020 06:06:55 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEB63A0AB6; Wed, 3 Jun 2020 06:06:54 -0700 (PDT) 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 08D7664F; Wed, 3 Jun 2020 13:06:51 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: <159115288456.10873.12340295955718946084@ietfa.amsl.com> Date: Wed, 3 Jun 2020 09:06:51 -0400 Cc: The IESG , draft-ietf-emu-eap-session-id@ietf.org, Mohit Sethi M , emu-chairs@ietf.org, emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8D9D73D6-6A88-420B-9862-623D9BD71C31@deployingradius.com> References: <159115288456.10873.12340295955718946084@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eap-session-id-04: (with COMMENT) 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: Wed, 03 Jun 2020 13:06:57 -0000 On Jun 2, 2020, at 10:54 PM, Barry Leiba via Datatracker = wrote: > =E2=80=94 Section 2 =E2=80=94 >=20 > This section updates [RFC5247] ... > It further > defines Session-ID derivation for PEAP. >=20 > This section does not address PEAP; that=E2=80=99s done in Section 3. = I suggest > removing that last sentence. Done. > =E2=80=94 Section 3 =E2=80=94 >=20 > [RFC5247] did not define Session-Id definition for Microsoft's > Protected EAP (PEAP). For consistency with EAP-TLS the definition > given in [RFC5216] Section 2.3, we define it as: >=20 > Both sentences here need some fixing: >=20 > NEW > [RFC5247] did not define Session-Id for Microsoft's > Protected EAP (PEAP). For consistency with the EAP-TLS definition > given in [RFC5216] Section 2.3, we define it as: > END Done. Thanks. Alan DeKok. From nobody Wed Jun 3 21:39:53 2020 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 603183A040F; Wed, 3 Jun 2020 21:39:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee via Datatracker To: Cc: last-call@ietf.org, emu@ietf.org, draft-ietf-emu-eap-session-id.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159124559130.10155.12607567064734353025@ietfa.amsl.com> Reply-To: Peter Yee Date: Wed, 03 Jun 2020 21:39:51 -0700 Archived-At: Subject: [Emu] Genart last call review of draft-ietf-emu-eap-session-id-04 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, 04 Jun 2020 04:39:51 -0000 Reviewer: Peter Yee Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-emu-eap-session-id-04 Reviewer: Peter Yee Review Date: 2020-06-03 IETF LC End Date: 2020-05-27 IESG Telechat date: 2020-06-11 Summary: This draft adds the definition of EAP Session-ID for EAP-SIM and EAP-AKA when using fast re-authentication. Those changes look fine, but one other change should be better highlighted. [Ready with Issues] Major issues: None Minor issues: Page 4, Section 1, 3rd paragraph. Aside from correcting the deficiencies in the fast re-authentication cases, you also have updated the EAP-SIM full authentication Session-ID derivation as well. This really ought to be mentioned here in the introduction because that change goes beyond the purported scope of the document (dealing with fast re-authentication). I believe the change you have made (substituting the RAND values from the first two authentication triplets for the RAND in AT_RAND) is fine, although I dislike RAND1 and RAND2 which are not specified in RFC 4186 (or in this draft) except by usage in an example in the test vectors annex. While that's not really your problem, it would be good if it were there were prescriptive text that explain what RAND1 and RAND2 mean. Nits/editorial comments: Page 4, 2nd paragraph, 1st sentence: change "is defining" to "has defined". IEEE 802.11ai completed the FILS specification several years ago. Page 7, Section 3, 1st paragraph, 1st sentence: change "define" to "provide a", just so we aren't defining a definition. From nobody Fri Jun 5 05:05:27 2020 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 45C443A12CE for ; Fri, 5 Jun 2020 05:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=maxcrone.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 uTO_H9fi61Bs for ; Fri, 5 Jun 2020 05:05:24 -0700 (PDT) Received: from dal2relay82.mxroute.com (dal2relay82.mxroute.com [64.40.26.82]) (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 B00053A1205 for ; Fri, 5 Jun 2020 05:05:24 -0700 (PDT) Received: from filter003.mxroute.com ([168.235.111.26] 168-235-111-26.cloud.ramnode.com) (Authenticated sender: mN4UYu2MZsgR) by dal2relay82.mxroute.com (ZoneMTA) with ESMTPSA id 172845f099900068e3.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 05 Jun 2020 12:05:20 +0000 X-Zone-Loop: 728683f62a02dc806cea0e6f7a993df1b5bc972213b0 X-Originating-IP: [168.235.111.26] Received: from ghost.mxroute.com (ghost.mxroute.com [138.201.205.224]) by filter003.mxroute.com (Postfix) with ESMTPS id 4B7FB610F8 for ; Fri, 5 Jun 2020 12:05:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=maxcrone.org; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jK18caYpCmhCnBF+LZkfL1gC6KyDV/SBN6kse5gfhAY=; b=88nm9hEkKcN/zHdJ7pXld6x5p/ 9e/X85IXQFEyxhhLVXCFBELqUMhrG7KlA4z2dNu8jm+asRfoyYnQfn+H4VK5F4xxh+LsMyOECF5Wy 0ciytUNXMoVSl52Cj23ECQEn49Bx01P2favBqlbHJd9/JFr3HJBgJevbTXaTjhY49NAZnAEz+28ft N02U+Jin+1IaIBG5TmWY4r0jIeHzGOz/49WcOwE+doWxZqd6jkGBPXi17eT8qJfVplP5DRPt3GW2Y vza2hdPcrT7FxZuzLf8YKDNJaDfYQxGdi9/MZ10OvN4I1ffOLWprtqfEds85ShCNsTHqjtI7Yg6j7 Aj81NJjg==; From: Max Crone To: EMU WG Message-ID: Date: Fri, 5 Jun 2020 15:05:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: max@maxcrone.org Archived-At: Subject: [Emu] draft-ietf-emu-eap-noob-01: Outdated statement in Initial Exchange description 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: Fri, 05 Jun 2020 12:05:26 -0000 Hi, I noticed that the current draft version of EAP-NOOB still contains an outdated sentence in the description of the Initial Exchange. 3.2.2 The server allocates a new PeerId in the Initial Exchange regardless of any old PeerId in the username part of the received NAI. However, the PeerId is not sent as part of the NAI anymore because of earlier privacy concerns. I would suggest to change it to the following. The server allocates a new PeerId in the Initial Exchange regardless of any old PeerId sent by the peer during the common handshake. With kind regards, Max Crone From nobody Sun Jun 7 01:42:00 2020 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 4C0733A0C49; Sun, 7 Jun 2020 01:41:59 -0700 (PDT) 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: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <159151931922.17504.13485846600679338848@ietfa.amsl.com> Date: Sun, 07 Jun 2020 01:41:59 -0700 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-10.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: Sun, 07 Jun 2020 08:42:00 -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-10.txt Pages : 30 Date : 2020-06-07 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 also provides guidance on authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used). 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-10 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-10 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 Sun Jun 7 04:19:38 2020 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 AB7E53A0D5A for ; Sun, 7 Jun 2020 04:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 yynq7cfLFP63 for ; Sun, 7 Jun 2020 04:19:34 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2078.outbound.protection.outlook.com [40.107.21.78]) (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 8A8033A0D59 for ; Sun, 7 Jun 2020 04:19:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YsIhLCWP4LtwPvLhhs2KR7tUkLECSNo9Cv3ykUwS63i/8MfTqWD/NWnaUBAcFxsRWKTVUW7nunHM+7dJSebvcVRsq+3YeZLvf5R3+s0ibNN3KzD8wuM8g6+Sjr5m4/jw5lWRSfR1IfSzs7QvOnC+WzzsHnAvBQNXTNTt0jeSnvBf1g4LIOG/21pMAOUPeedX5JLHnlumOmiisrcWM0zh9XY48tdJmSach1vEIqKj63yNtIaiKEs5zJcEEM1Iugrf5f6BNtKIW99ySuPujxGTDQw3ie+FFxdjD2Oj1q6fSwKc0OVOULSo/luImWuHnvg7G1boHNFnwsT42qjFkckxKA== 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=KdGgvwa0LwXsagjXgyjTiSGIDLRtcefka+bxNYBhfFU=; b=gREVS/zjnWfmQ1QKR3+seG3sDykwpVENet8gMUwKtGk3GsKRIbgGO8ecLjx8nH8zvrcP/YXgNfw1CoQUmICiRjdt3lfQXink1MrWvIoz3KS+mlp6mW+nZSGkIXQXqyrhJdDf+J3Jvk8eSk6C9joSerjj1u+ixqweEjLKLcyivMK8mRPmRn+/pf7FIz5it536KtDg6X98AlImznWQijVHBQHFxMf7wHo1SM6OnQ+9HJMqTzCgBk78fWsRA3nEdLg5c2C9fRKvBz2GRDKU8S/aYV+Pb/1Lj40fUod5koQ0gr2s8Sm+39v1BbhsP/vppwb8Ab7PlLDV+lFo3/sSAcQk9w== 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=KdGgvwa0LwXsagjXgyjTiSGIDLRtcefka+bxNYBhfFU=; b=JxU0QUcZpoq8fHkroDZ/4CxxH/vHqjJsbijWWqTkoqFryckkaB5YoCPwR2Tv2YPmzEPpjkHLQ6FH9cZIz2nifZMvRLEVzKpaLaqwKnqggAOjofSACfyEd3JkYmAO0wEteBQq5DG1AGwjjwR73itFBsIovmoHBqrGh58IpVsDESw= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR0701MB2139.eurprd07.prod.outlook.com (2603:10a6:3:28::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.13; Sun, 7 Jun 2020 11:19:29 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e%7]) with mapi id 15.20.3088.016; Sun, 7 Jun 2020 11:19:29 +0000 From: Mohit Sethi M To: Roman Danyliw , "emu@ietf.org" Thread-Topic: [Emu] AD review of draft-ietf-emu-eap-tls13-09 Thread-Index: AQHWPL2Cehhy4ZewekqtWJ6lDyTLOg== Date: Sun, 7 Jun 2020 11:19:28 +0000 Message-ID: <93c44fe1-16a9-9a89-a517-7a3e066327e2@ericsson.com> 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.7.0 authentication-results: cert.org; dkim=none (message not signed) header.d=none;cert.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [176.93.104.195] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c280b8a-124c-4362-9fd6-08d80ad4a501 x-ms-traffictypediagnostic: HE1PR0701MB2139: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04270EF89C x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4JM+dDbBpZtZubzrX2YTbw6+3YNSktR2HfAv3IpcdqDCDfuG66J/zdJTvuY/0VyINiGdwv3IBLG/2BBN0oP/q/Eesx52ffAvP8fHV08EGyR46ttNXMK1+qL9G3cUiLbo4NY2nkRY3WO8L2OWvse2R9ofZ3Xl5Htz6K36Pke4rqHfe5kZSZVT7Bt8fQDQjkxctoBDTEbrKSn6QsRoRwcsrmQwzFJp/S0D7hzrBJLO7/a6k544/NM6+nrzNstS7IpUpZWkolFtsFzWFep2Sc0TrPw4QSTP+6Uj0Y34ft97ETV6NHicl1NjIJXyN4QZHXaKTtYYaApNJ3pE8j2n3aL3cGjf7ydMQNlLWrVuL2C5HopmJGjkGhre8q9CFJO7E8nzczS/MrqtDkzpyUCadU7CuXd/tu41Vk1p1kQ+pIpgoL9OLBmJPnl95ITXMKwIw9FnbVYLP9pEKXlh00TD5hpU+Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(39860400002)(366004)(396003)(478600001)(966005)(53546011)(6506007)(186003)(26005)(2906002)(6512007)(6486002)(8936002)(8676002)(316002)(31686004)(110136005)(2616005)(31696002)(86362001)(5660300002)(66946007)(76116006)(64756008)(30864003)(66476007)(66556008)(66446008)(83380400001)(36756003)(71200400001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: YnlkwShS0VQtS4HMMHy03NvPYptOBMRgWxiVHr85DwWIHx1DcSgZ5aU2AsV0u3y6VDqXEp+1Jj+xoLvRgx500pmNzrdFsc0CLrBXAJV+eWXgAgVBK6on+FQScBCzXf9vIyo6RxEwaqlzxIxuum3G8pF9UATAN3h069NxqTFLaBvnVrq//pzpdD51+ykDvo85H6VJLCLUN47deEZlO0Z4Nykjgz4h7nit4rGVu7RgmnXfkdymVlu6+wRd9JaOKgfv/HvCodrLab6Upz6Gr++qpOgWq9D7R/Tpsh+azBAdZmDLwjcj1Itf9EzAr8F+V69oJXaDO/0cTAQ6vK9puOjAUs2I0ptKsjvJ3ncGb8KhdUfc2VABbRv7gDMKAzg+0bbYJJtpjBHOSA+fgCX0VAwXR3bYYU6CrS+i+v6M4K+3HaNkVIPoJcrr8Fs4lg8OeLYnDX3ye3yyZx3K397M33MXLCzQyY+k4Gr+1mg3u3i0jS987qoTyQWaUsdkktxE48wA x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7031BE1EE1A99946B82D713C14E8604D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c280b8a-124c-4362-9fd6-08d80ad4a501 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2020 11:19:28.9327 (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: x75/eaEWC/JKHA1wNCoIpLO+O+uOz+5pAeEBaMbmksXILbRUpQ+AJnZQu+FZ1rUejdyLNW2AzNef4mYNvodxXbpcSZGH22M18eoGc7E9/0k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2139 Archived-At: Subject: Re: [Emu] AD review of draft-ietf-emu-eap-tls13-09 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, 07 Jun 2020 11:19:37 -0000 SGkgUm9tYW4sDQoNClRoYW5rcyBmb3IgeW91ciB1c3VhbCBjYXJlZnVsIHJldmlldy4gSSBoYXZl IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIA0KdGhhdCBob3BlZnVsbHkgYWRkcmVzc2VzIGFsbCB0 aGUgaXNzdWVzLiBIZXJlIGlzIHRoZSBkaWZmIGZvciB5b3VyIA0KY29udmVuaWVuY2U6IGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMtMTAN Cg0KUGxlYXNlIHNlZSBpbi1saW5lIGZvciBkZXRhaWxzIG9uIGhvdyB3ZSBoYXZlIGhhbmRsZWQg ZWFjaCBpc3N1ZS4NCg0KLS1Nb2hpdA0KDQpPbiA1LzI4LzIwIDk6MzEgUE0sIFJvbWFuIERhbnls aXcgd3JvdGU6DQo+IEhpIQ0KPg0KPiBJIHBlcmZvcm1lZCBhbiBBRCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1lbXUtZWFwLXRsczEzLTA5LiAgVGhhbmtzIGZvciB0aGUgd29yayBvbiBtb2Rlcm5pemlu ZyBleGlzdGluZyBndWlkYW5jZSB0byBjb3ZlciBUTFMgMS4zLg0KPg0KPiBUd28gaGlnaCBsZXZl bCB0aGluZ3MgY2F1Z2h0IG15IGF0dGVudGlvbjoNCj4NCj4gKiogVGhlIGFic3RyYWN0LCBpbnRy b2R1Y3Rpb24gYW5kIHRpdGxlIHN1Z2dlc3RlZCB0byBtZSB0aGF0IHRoaXMgZG9jdW1lbnQgaXMg b25seSBhYm91dCBUTFMgMS4zK0VBUC4gIElmIEkgd2Fzbid0IHVzaW5nIFRMUyAxLjMsIHRoZW4g dGhlcmUgaXMgbm90aGluZyBoZXJlIG9mIGludGVyZXN0LiAgSG93ZXZlciwgdGhlcmUgYXBwZWFy cyB0byBiZSB0ZXh0IGhlcmUgdGhhdCB1cGRhdGVzIG5vbi1UTFMgMS4zIGd1aWRhbmNlLiAgSSBy ZWNvbW1lbmQgYmVpbmcgY2xlYXIgYWJvdXQgdGhhdCB1cCBmcm9udCAoaW4gdGhlIGFic3RyYWN0 IGFuZCBpbnRyb2R1Y3Rpb24pLg0KPg0KPiAqKiBTZWN0aW9uIDIuMSBleHBsaWNpdGx5IHNheXMg dGhhdCAiW3RdaGlzIGRvY3VtZW50IG9ubHkgbGlzdHMgYWRkaXRpb25hbCBhbmQgZGlmZmVyZW50 IHJlcXVpcmVtZW50cywgcmVzdHJpY3Rpb25zLCBhbmQgcHJvY2Vzc2luZyBjb21wYXJlZCB0byBb UkZDODQ0Nl0gYW5kIFtSRkM1MjE2XS4iICBUaGUgdGV4dCB0cmllcyB0byBtYXRjaCBzZWN0aW9u IGhlYWRlcnMgbmFtZXMgd2l0aCBbUkZDNTIxNl0gKHdoaWNoIGlzIGhlbHBmdWwpLiAgSG93ZXZl ciwgSSBkaWRuJ3QgYWx3YXlzIGZvbGxvdyB0aGUgInVwZGF0ZXMiIHdpdGhvdXQgc29tZSBzZWFy Y2hpbmcuICBFZGl0b3JpYWxseSwgZ2l2ZW4gYSBwYXJ0aWN1bGFyIGRlc2NyaXB0aW9uIG9mIGJl aGF2aW9yLCBJIHJlY29tbWVuZCBiZWluZyBjbGVhcmVyIGJ5IGNvbnNpc3RlbnRseSBtYWtpbmcg ZXhwbGljaXQgcmVmZXJlbmNlIHRvIGEgcGFydGljdWxhciBzZWN0aW9uIGluIFJGQzUyMTYgdGhh dCBpcyBiZWluZyB1cGRhdGVkLg0KDQpXZSBpbml0aWFsbHkgbWFpbnRhaW5lZCBhIHN0cmljdCBt YXRjaGluZyBiZXR3ZWVuIHNlY3Rpb25zIG9mIFJGQyA1MjE2IA0KYW5kIHRoaXMgZG9jdW1lbnQu IEhvd2V2ZXIsIHRoZXJlIHdlcmUgcmVxdWVzdHMgZm9yIG5ldyBzZWN0aW9uczogDQpJZGVudGl0 eSAoQWxhbiBEZUtvaykgYW5kIEhlbGxvIFJldHJ5IFJlcXVlc3QgKEppbSBTY2hhYWQpLiBJbiBz b21lIA0KY2FzZXMsIGl0IHdhcyBhbHNvIG5lY2Vzc2FyeSB0byBoYXZlIGEgbmV3IHNlY3Rpb24u IEZvciBleGFtcGxlLCBhIG5ldyANCnNlY3Rpb24gd2FzIG5lZWRlZCB0byBleHBsYWluIGhvdyBz ZXJ2ZXIgaXNzdWVkIHRpY2tldHMgYXJlIGEgbmVjZXNzYXJ5IA0KcHJlY3Vyc29yIGZvciBzZXNz aW9uIHJlc3VtcHRpb24gaW4gVExTIDEuMy4gRWFjaCBzZWN0aW9uIG5vdyBiZWdpbnMgYnkgDQpl eHBsaWNpdGx5IGluZm9ybWluZyB0aGUgcmVhZGVyIGlmIGl0IHVwZGF0ZXMgYSBzcGVjaWZpYyBz ZWN0aW9uIG9mIFJGQyANCjUyMTYuIE5ldyBzZWN0aW9ucyB0aGF0IGRpZG4ndCBleGlzdCBpbiBS RkMgNTIxNiBhcmUgYWxzbyBjbGVhcmx5IGxhYmVsZWQuDQoNCkl0IGlzIHRydWUgdGhhdCB0aGUg Z3VpZGFuY2Ugb24gcmVzdW1wdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBpcyBub3QgDQpzcGVjaWZp YyB0byBUTFMgdmVyc2lvbiAxLjMuIFRoZSB0ZXh0IGluIHRoZSBhYnN0cmFjdCBhbmQgaW50cm9k dWN0aW9uIA0Kbm93IHN0YXRlIHRoYXQgIlRoaXMgZG9jdW1lbnQgYWxzbyBwcm92aWRlcyBndWlk YW5jZSBvbiBhdXRob3JpemF0aW9uIA0KYW5kIHJlc3VtcHRpb24gZm9yIEVBUC1UTFMgaW4gZ2Vu ZXJhbCAocmVnYXJkbGVzcyBvZiB0aGUgdW5kZXJseWluZyBUTFMgDQp2ZXJzaW9uIHVzZWQpIi4N Cg0KPg0KPiBNb3JlIGRldGFpbHMgb24gdGhlIGFib3ZlIG9ic2VydmF0aW9ucyBhbmQgb3RoZXJz IGJlbG93Og0KPg0KPiAoMSkgQ2FuIHlvdSBwbGVhc2UgY2hlY2sgdGhlIGJvaWxlciBwbGF0ZSBs YW5ndWFnZSwgaWRuaXRzIGlzIGNvbXBsYWluaW5nIGlzIGFzIGZvbGxvd3M6DQo+ICAgID09IFRo ZSBkb2N1bWVudCBzZWVtcyB0byBsYWNrIHRoZSByZWNvbW1lbmRlZCBSRkMgMjExOSBib2lsZXJw bGF0ZSwgZXZlbiBpZg0KPiAgICAgICBpdCBhcHBlYXJzIHRvIHVzZSBSRkMgMjExOSBrZXl3b3Jk cyAtLSBob3dldmVyLCB0aGVyZSdzIGEgcGFyYWdyYXBoIHdpdGgNCj4gICAgICAgYSBtYXRjaGlu ZyBiZWdpbm5pbmcuIEJvaWxlcnBsYXRlIGVycm9yPw0KPg0KPiAgICAgICAoVGhlIGRvY3VtZW50 IGRvZXMgc2VlbSB0byBoYXZlIHRoZSByZWZlcmVuY2UgdG8gUkZDIDIxMTkgd2hpY2ggdGhlDQo+ ICAgICAgIElELUNoZWNrbGlzdCByZXF1aXJlcykuDQo+ICAgICAgIChVc2luZyB0aGUgY3JlYXRp b24gZGF0ZSBmcm9tIFJGQzUyMTYsIHVwZGF0ZWQgYnkgdGhpcyBkb2N1bWVudCwgZm9yDQo+ICAg ICAgIFJGQzUzNzggY2hlY2tzOiAyMDA3LTA3LTAxKQ0KPg0KPiAgICAtLSBUaGUgZG9jdW1lbnQg c2VlbXMgdG8gbGFjayBhIGRpc2NsYWltZXIgZm9yIHByZS1SRkM1Mzc4IHdvcmssIGJ1dCBtYXkN Cj4gICAgICAgaGF2ZSBjb250ZW50IHdoaWNoIHdhcyBmaXJzdCBzdWJtaXR0ZWQgYmVmb3JlIDEw IE5vdmVtYmVyIDIwMDguICBJZiB5b3UNCj4gICAgICAgaGF2ZSBjb250YWN0ZWQgYWxsIHRoZSBv cmlnaW5hbCBhdXRob3JzIGFuZCB0aGV5IGFyZSBhbGwgd2lsbGluZyB0byBncmFudA0KPiAgICAg ICB0aGUgQkNQNzggcmlnaHRzIHRvIHRoZSBJRVRGIFRydXN0LCB0aGVuIHRoaXMgaXMgZmluZSwg YW5kIHlvdSBjYW4gaWdub3JlDQo+ICAgICAgIHRoaXMgY29tbWVudC4gIElmIG5vdCwgeW91IG1h eSBuZWVkIHRvIGFkZCB0aGUgcHJlLVJGQzUzNzggZGlzY2xhaW1lci4NCj4gICAgICAgKFNlZSB0 aGUgTGVnYWwgUHJvdmlzaW9ucyBkb2N1bWVudCBhdA0KPiAgICAgICBodHRwczovL3RydXN0ZWUu aWV0Zi5vcmcvbGljZW5zZS1pbmZvIGZvciBtb3JlIGluZm9ybWF0aW9uLikNClRoZSBib2lsZXJw bGF0ZSBlcnJvciBzaG93ZWQgdXAgYmVjYXVzZSBvZiBhIG1pc3Npbmcgc3BhY2UuIEl0IHNob3Vs ZG4ndCANCnNob3cgdXAgYW55bW9yZS4gRXZlbiB0aG91Z2ggUkZDNTIxNiBpcyBwcmUtUkZDNTM3 OCB3b3JrLCBpdCBoYWQgZ3JhbnRlZCANCkJDUDc4IHJpZ2h0cyB0byB0aGUgSUVURiB0cnVzdC4g U28gd2Ugc2hvdWxkIGJlIGZpbmUuIChUaGlzIGlzc3VlIHdhcyANCmFsc28gbm90ZWQgYnkgdGhl IGRvY3VtZW50IHNoZXBoZXJkIChKb2UgU2Fsb3dleSkuKQ0KPg0KPiAoMikgU2VjdGlvbiAxLiAg RWRpdG9yaWFsLiAgSW5zdGVhZCBvZiBzb21ldGhpbmcgd29ya2luZyAicGVyZmVjdGx5IiwgbWF5 YmUganVzdCAic3VwcG9ydHMiDQo+IE9MRA0KPiAgICAgRUFQLVRMUyBbUkZDNTIxNl0gcmVmZXJl bmNlcyBUTFMgMS4wIFtSRkMyMjQ2XSBhbmQgVExTIDEuMSBbUkZDNDM0Nl0sDQo+ICAgICBidXQg d29ya3MgcGVyZmVjdGx5IGFsc28gd2l0aCBUTFMgMS4yIFtSRkM1MjQ2XS4NCj4NCj4gTkVXDQo+ IEVBUC1UTFMgW1JGQzUyMTZdIGV4cGxpY2l0bHkgcmVmZXJlbmNlcyBUTFMgMS4wIFtSRkMyMjQ2 XSBhbmQgVExTIDEuMSBbUkZDNDM0Nl0sIGJ1dCBpdCBhbHNvIHN1cHBvcnRzIFRMUyAxLjIgW1JG QzUyNDZdLg0KSSBhbSBzb21ld2hhdCB1bmNvbWZvcnRhYmxlIHdpdGggdGhlIHdvcmQgInN1cHBv cnQiLiBJbiBteSBvcGluaW9uLCANCkVBUC1UTFMgdXNlcyBhIHZlcnNpb24gVExTIHJhdGhlciB0 aGFuIHN1cHBvcnRzIGEgdmVyc2lvbiBvZiBUTFMuIEkgaGF2ZSANCnVwZGF0ZWQgdGhlIHRleHQg dG8gc2F5ICJFQVAtVExTIFtSRkM1MjE2XSByZWZlcmVuY2VzIFRMUyAxLjAgW1JGQzIyNDZdIA0K YW5kIFRMUyAxLjEgW1JGQzQzNDZdLCBidXQgY2FuIGFsc28gd29yayB3aXRoIFRMUyAxLjIgW1JG QzUyNDZdIi4gSSBhbSANCndpbGxpbmcgdG8gbW9kaWZ5IGlmIHRoaXMgaXMgbm90IGFwcHJvcHJp YXRlLg0KPg0KPiAoMykgU2VjdGlvbiAxLiAgRWRpdG9yaWFsLiAgIkVhc3kiIG1pZ2h0IGJlIHJl bGF0aXZlLg0KPg0KPiBPTEQNCj4gICAgIFByaXZhY3kgaXMgbWFuZGF0b3J5IGFuZCBhY2hpZXZl ZCB3aXRob3V0IGFueSBhZGRpdGlvbmFsIHJvdW5kLXRyaXBzLA0KPiAgICAgcmV2b2NhdGlvbiBj aGVja2luZyBpcyBtYW5kYXRvcnkgYW5kIGVhc3kgd2l0aCBPQ1NQIHN0YXBsaW5nLA0KPg0KPiBO RVcNCj4gUHJpdmFjeSBpcyBtYW5kYXRvcnkgYW5kIGFjaGlldmVkIHdpdGhvdXQgYW55IGFkZGl0 aW9uYWwgcm91bmQtdHJpcHMsICAgcmV2b2NhdGlvbiBjaGVja2luZyBpcyBtYW5kYXRvcnkgYW5k IHNpbXBsaWZpZWQgd2l0aCBPQ1NQIHN0YXBsaW5nLA0KRml4ZWQgYXMgcmVjb21tZW5kZWQuDQo+ DQo+ICgzKSBTZWN0aW9uIDIuMS4xLiAgV2hhdCBpcyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4g dGhpcyBzZWN0aW9uIGFuZCBOQUkgZ3VpZGFuY2UgaW4gUkZDNTIxNiBTZWN0aW9uIDIuMS40PyAg SXMgaXQgdGhhdCBhbm9ueW1vdXMgTkFJcyBhcmUgUkVDT01NRU5ERUQgZm9yIFRMUyAxLjMsIGJ1 dCBzdGF5IGEgTUFZIGluIG9sZCBFQVAtVExTPw0KPg0KPiAoNCkgU2VjdGlvbiAyLjEuMy4gIEVk aXRvcmlhbC4gIFRvIHByZXZlbnQgdGhlIHJlYWRlciBmcm9tIGhhdmluZyB0byBsaW5lIHVwIHdo aWNoIHBhcmFncmFwaHMgYXJlIGJlaW5nIHJlcGxhY2VkIGluIFNlY3Rpb24gMi4xLjMgb2YgW1JG QzUyMTZdLCBJIHdvdWxkIHJlY29tbWVuZCBjaXRpbmcgdGhlIG9sZCB0ZXh0IGFuZCBzaG93aW5n IGhvdyB0aGlzIHRleHQgcmVwbGFjZXMgaXQuICBBZGRpdGlvbmFsbHksIHNpbmNlIFJGQzUyMTYg bGlzdHMgdGhlIHBlZXIgZ3VpZGFuY2UgYmVmb3JlIHRoZSBzZXJ2ZXIsIEknZCByZWNvbW1lbmQg cmV2ZXJzaW5nIHRoZSBvcmRlci4gIEZvciBleGFtcGxlOg0KPg0KPiBPcmlnaW5hbCBUTFMgZ3Vp ZGFuY2UgZnJvbSBSRkM1MjE2Og0KPiBJZiB0aGUgcGVlciBhdXRoZW50aWNhdGVzIHN1Y2Nlc3Nm dWxseSwgdGhlIEVBUCBzZXJ2ZXIgTVVTVCByZXNwb25kDQo+ICAgICB3aXRoIGFuIEVBUC1SZXF1 ZXN0IHBhY2tldCB3aXRoIEVBUC1UeXBlPUVBUC1UTFMsIHdoaWNoIGluY2x1ZGVzLCBpbg0KPiAg ICAgdGhlIGNhc2Ugb2YgYSBuZXcgVExTIHNlc3Npb24sIG9uZSBvciBtb3JlIFRMUyByZWNvcmRz IGNvbnRhaW5pbmcgVExTDQo+ICAgICBjaGFuZ2VfY2lwaGVyX3NwZWMgYW5kIGZpbmlzaGVkIGhh bmRzaGFrZSBtZXNzYWdlcy4gIFRoZSBsYXR0ZXINCj4gICAgIGNvbnRhaW5zIHRoZSBFQVAgc2Vy dmVyJ3MgYXV0aGVudGljYXRpb24gcmVzcG9uc2UgdG8gdGhlIHBlZXIuICBUaGUNCj4gICAgIHBl ZXIgd2lsbCB0aGVuIHZlcmlmeSB0aGUgZmluaXNoZWQgbWVzc2FnZSBpbiBvcmRlciB0byBhdXRo ZW50aWNhdGUNCj4gICAgIHRoZSBFQVAgc2VydmVyLg0KPiAuLi4uDQo+ICAgICBJZiB0aGUgRUFQ IHNlcnZlciBhdXRoZW50aWNhdGVzIHN1Y2Nlc3NmdWxseSwgdGhlIHBlZXIgTVVTVCBzZW5kIGFu DQo+ICAgICBFQVAtUmVzcG9uc2UgcGFja2V0IG9mIEVBUC1UeXBlPUVBUC1UTFMsIGFuZCBubyBk YXRhLiAgVGhlIEVBUCBTZXJ2ZXINCj4gICAgIHRoZW4gTVVTVCByZXNwb25kIHdpdGggYW4gRUFQ LVN1Y2Nlc3MgbWVzc2FnZS4NCj4NCj4gVExTIDEuMyBndWlkYW5jZToNCj4gW2luc2VydCBuZXcg bGFuZ3VhZ2UgaW4gdGhlIGRyYWZ0IG5vd10NCkkgYW0gc29tZXdoYXQgaGVzaXRhbnQgdG8gY29w eSBvbGQgcGFydHMgb2YgUkZDIDUyMTYuIFRoZSBkb2N1bWVudCANCmxlbmd0aCB3b3VsZCBxdWlj a2x5IGV4cGxvZGUuIFRoZSBpc3N1ZSBoZXJlIGlzIHRoYXQgUkZDNTIxNiB3YXMgc2F5aW5nIA0K dGhhdCB0aGUgc2VydmVyL3BlZXIgbXVzdCByZXNwb25kIHdpdGggc3BlY2lmaWMgVExTIHJlY29y ZHMgaW4gdGhlIA0KbWVzc2FnZS4gV2hpbGUgdGhlIGluZm9ybWF0aW9uIHdhcyBjb3JyZWN0IGZv ciBlYXJsaWVyIHZlcnNpb25zIG9mIFRMUywgDQppdCB3b3VsZCBoYXZlIGJlZW4gaW4gY29uZmxp Y3Qgd2l0aCBUTFMgMS4zLiBTbyB0aGUgbmV3IHRleHQgc2ltcGx5IA0KdXBkYXRlcyBSRkMgNTIx NiB0byBzYXkgdGhhdCB0aGUgcGVlci9zZXJ2ZXIgTVVTVCBzZW5kIGFuIA0KRUFQLVJlc3BvbnNl L1JlcXVlc3QgcGFja2V0IGNvbnRhaW5pbmcgVExTIHJlY29yZHMgY29uZm9ybWluZyB0byB0aGUg DQp2ZXJzaW9uIG9mIFRMUyB1c2VkLg0KPg0KPiAoNSkgU2VjdGlvbiAyLjEuNS4gIElzIEZpZ3Vy ZSA2IHN1cHBvc2VkIHRvIGJlIHJlYWQgYXMgYmVpbmcgaW5jbHVzaXZlIG9mIGFsbCBUTFMgbWVz c2FnZXM/ICBUaGUgZmlndXJlIGRvZXNuJ3QgY29udGFpbiBUTFMgQ2VydGlmaWNhdGVSZXF1ZXN0 LCBUTFMgQ2VydGlmaWNhdGUsIG9yIFRMUyBDZXJ0aWZpY2F0ZVZlcmlmeS4gIEl0IHdvdWxkbid0 IGJlIGdlcm1hbmUgdG8gd2hhdCB0aGUgZmlndXJlIGlzIHRyeWluZyB0byBkZW1vbnN0cmF0ZSBi dXQgdGhlIGV4YW1wbGVzIGluIHByaW9yIHNlY3Rpb25zIGFyZSAiY29tcGxldGUiLg0KR29vZCBj YXRjaC4gSSBoYXZlIHVwZGF0ZWQgdGhlIGZpZ3VyZSB0byBiZSBjb21wbGV0ZS4NCj4NCj4gKDYp IFNlY3Rpb24gMi4xLjYuICBUaGUgdGV4dCBoZXJlIHNlZW1zIHJpZ2h0IHRvIGRlc2NyaWJlIFRM UyAxLjMgYmVoYXZpb3IuICBSZWNvbW1lbmQgYmVpbmcgY2xlYXJlciBvbiB3aGljaCBiZWhhdmlv ciB0aGlzIGlzIHJlcGxhY2luZyBpbiBUTFMtRUFQIChpLmUuLCBleHBsaWNpdGx5IGNpdGluZyBh IGdpdmVuIHNlY3Rpb24gaW4gUkZDNTIxNjsgaXMgaXQgU2VjdGlvbiAyLjEuMj8pDQo+DQo+ICg3 KSBTZWN0aW9uIDIuMS43LiAgVGhlIHRleHQgaGVyZSBzZWVtcyByaWdodCB0byBkZXNjcmliZSBU TFMgMS4zIGJlaGF2aW9yLiAgUmVjb21tZW5kIGJlaW5nIGNsZWFyZXIgb24gd2hpY2ggYmVoYXZp b3IgdGhpcyBpcyByZXBsYWNpbmcgaW4gVExTIEVBUCAoaS5lLiwgZXhwbGljaXRseSBjaXRpbmcg YSBnaXZlbiBzZWN0aW9uIGluIFJGQzUyMTYpDQo+DQo+ICg4KSBTZWN0aW9uIDIuMS43LiAgUGVy ICJXaGVuIE5BSSByZXVzZSBjYW4gYmUgZG9uZSB3aXRob3V0IHByaXZhY3kgaW1wbGljYXRpb25z IiwgaXMgdGhlcmUgYW55IGd1aWRhbmNlIHRoYXQgY2FuIGJlIHByb3ZpZGVkIG9uIHdoZXJlIHRo ZXJlIHdvdWxkIGJlIGEgcHJpdmFjeSBpc3N1ZT8NCkkgYmVsaWV2ZSB0aGF0IHRoZSBzZW50ZW5j ZXMgZm9sbG93aW5nIHRoaXMgcGhyYXNlIHRyeSB0byBleHBsYWluIHdoZXJlIA0KdGhlcmUgd291 bGQgYmUgYSBwcml2YWN5IGlzc3VlLiBJdCBzYXlzICJFLmcuIHRoZSBOQUkgQHJlYWxtIGNhbiBz YWZlbHkgDQpiZSByZXVzZWQsIHdoaWxlIHRoZSBOQUkgWm14bGVHOD1AcmVhbG0gY2Fubm90LiIg U28gaWYgdGhlIHBlZXIgaGFkIHVzZSANCiJAcmVhbG0iIGR1cmluZyBpbml0aWFsIGZ1bGwgYXV0 aGVudGljYXRpb24sIGl0IGNhbiBzYWZlbHkgcmV1c2UgdGhhdCANCnNpbmNlIGl0IGRvZXMgbm90 IHJldmVhbCBhbnkgYWRkaXRpb25hbCBpbmZvcm1hdGlvbi4gSWYgdGhlIHBlZXIgaG93ZXZlciAN CnVzZWQgIlpteGxlRzg9QHJlYWxtIiBkdXJpbmcgaW5pdGlhbCBmdWxsIGF1dGhlbnRpY2F0aW9u LCByZXVzaW5nIHRoZSANCnNhbWUgTkFJIHdvdWxkIHJldmVhbCBpbmZvcm1hdGlvbiB0aGF0IGl0 IGlzIHRoZSBzYW1lIGRldmljZS91c2VyIA0KcmVjb25uZWN0aW5nLiBMZXQgdXMga25vdyBpZiB0 aGlzIGV4cGxhbmF0aW9uIGNhbiBiZSBpbXByb3ZlZCBzb21laG93Lg0KPg0KPiAoOSkgU2VjdGlv biAyLjEuOS4gIFRoZSB0ZXh0IGhlcmUgc2VlbXMgcmlnaHQgdG8gZGVzY3JpYmUgVExTIDEuMyBi ZWhhdmlvci4gIFJlY29tbWVuZCBiZWluZyBjbGVhcmVyIG9uIHdoaWNoIGJlaGF2aW9yIHRoaXMg aXMgcmVwbGFjaW5nIGluIFRMUyBFQVAgKGkuZS4sIGV4cGxpY2l0bHkgY2l0aW5nIGEgZ2l2ZW4g c2VjdGlvbiBpbiBSRkM1MjE2LCBpcyBpdCBTZWN0aW9uIDIuMS41PykNCj4NCj4gKDEwKSBTZWN0 aW9uIDUuMS4gRWRpdG9yaWFsLiAgV3Jvbmcgc2VjdGlvbiByZWZlcmVuY2UuIHMvU2VjdGlvbiA0 LjEuIG9mIFtSRkM1MjE2XS9TZWN0aW9uIDUuMSBvZiBbUkZDNTIxNl0vDQpHb29kIGNhdGNoLiBG aXhlZC4NCj4NCj4gKDExKSBTZWN0aW9uIDUuMS4gIFBlciAiYmV0dGVyIGNvbmZpZGVudGlhbGl0 eSIgaW4gWzJdLCB0aGlzIHNlZW1zIGltcHJlY2lzZQ0KPg0KPiAoMTIpIFNlY3Rpb24gNS40LiAg UGVyICJXaGlsZSBjZXJ0aWZpY2F0ZXMgb2Z0ZW4gaGF2ZSBhIGxvbmcgdmFsaWRpdHkgcGVyaW9k IHNwYW5uaW5nIHNldmVyYWwgeWVhcnMsIHRoZXJlIGFyZSAuLi4iLCBhcyB0aGlzIGlzIGNoYW5n aW5nIHBlcmhhcHMganVzdCBzYXkgIldoaWxlIGNlcnRpZmljYXRlcyBtYXkgaGF2ZSBsb25nIHZh bGlkaXR5IHBlcmlvZHMsIHRoZXJlIGFyZSAuLi4iDQpGaXhlZCBhcyByZWNvbW1lbmRlZC4NCj4N Cj4gKDEzKSBTZWN0aW9uIDUuNS4gIFJlY29tbWVuZCB0aGF0IHRoaXMgc2VjdGlvbiByZWFkICJO byB1cGRhdGVzIHRvIFNlY3Rpb24gNS41IG9mIFtSRkM1MjE2XSINCkZpeGVkIGFzIHJlY29tbWVu ZGVkLg0KPg0KPiAoMTQpIFNlY3Rpb24gNS42LiAgVGhlIGd1aWRhbmNlIGluIHRoaXMgc2VjdGlv biBkb2VzIGFwcGVhciB0byBiZSBUTFMgMS4zIHNwZWNpZmljLiAgSWYgaXQgaXNuJ3QsIGl0IHNo b3VsZCBiZSBub3RlZCBhcyBzdWNoLg0KVGhlIHRleHQgbm93IHNheXMgIlRoZSBndWlkYW5jZSBp biB0aGlzIHNlY3Rpb24gaXMgcmVsZXZhbnQgZm9yIEVBUC1UTFMgDQppbiBnZW5lcmFsIChyZWdh cmRsZXNzIG9mIHRoZSB1bmRlcmx5aW5nIFRMUyB2ZXJzaW9uIHVzZWQpLiINCj4NCj4gKDE1KSBT ZWN0aW9uIDUuNy4gIFBlciAiU2luY2UgYWNjb3VudGluZyBtdXN0IGJlIHRpZWQgdG8gYW4gYXV0 aGVudGljYXRlZCBpZGVudGl0eSAuLi4iLCBpcyB0aGVyZSBpcyBhIHJlYXNvbiBub3QgdG8gdXNl IGEgbm9ybWF0aXZlIE1VU1QgaGVyZT8gIEVzcGVjaWFsbHkgc2luY2UgbGF0ZXIgYSBub3JtYXRp dmUgUkVDT01NRU5ERUQgaXMgdXNlZCBmb3IgIkl0IGlzIFJFQ09NTUVOREVEIHRoYXQgYXV0aG9y aXphdGlvbiwgYWNjb3VudGluZyBhbmQgcG9saWN5IGRlY2lzaW9ucyBhcmUgcmVldmFsdWF0ZWQg YmFzZWQgb24gaW5mb3JtYXRpb24gZ2l2ZW4gaW4gcmVzdW1wdGlvbnMiLg0KVGhpcyB3YXMgbW9y ZSBvZiBhIGhpZ2gtbGV2ZWwgc3RhdGVtZW50IHRoYW4gYSBwcm90b2NvbCBzcGVjaWZpYyANCnJl cXVpcmVtZW50LiBIZW5jZSwgd2UgdXNlZCAibXVzdCIgaW5zdGVhZCBvZiAiTVVTVCIuIEhhcHB5 IHRvIGVkaXQgaWYgDQpub3Qgc3VpdGFibGUuDQo+DQo+ICgxNikgU2VjdGlvbiA1LjguICBFZGl0 b3JpYWwuIFBlciAiW1JGQzY5NzNdIHN1Z2dlc3RzIHRoYXQgdGhlIHByaXZhY3kgY29uc2lkZXJh dGlvbnMgb2YgSUVURiBwcm90b2NvbHMgYmUgZG9jdW1lbnRlZCIsIGl0IGlzbid0IGNsZWFyIHRv IG1lIHdoYXQgdGhpcyBzZW50ZW5jZSBpcyBhZGRpbmcuDQpSZW1vdmVkLg0KPg0KPiAoMTcpIFNl Y3Rpb24gNS44LiAgRWRpdG9yaWFsLiAgcy9UTFMgMS4zIG9mZmVycyBtdWNoIGJldHRlciBwcml2 YWN5IHRoYW4gLi4uL1RMUyAxLjMgb2ZmZXJzIGJldHRlciBwcml2YWN5IHByb3BlcnRpZXMgdGhh biAuLi4vDQpGaXhlZCBhcyByZWNvbW1lbmRlZC4NCj4NCj4gKDE4KSBTZWN0aW9uIDUuOC4gIEVk aXRvcmlhbC4gUGVyICJJZiBwcml2YWN5LWZyaWVuZGx5IGlkZW50aWZpZXJzIHdpdGggZW5jcnlw dGVkIHVzZXJuYW1lcyBuZWVkIHRvIGJlIGdlbmVyYXRlZCB3aXRoIGNhcmUiLCBhcyB3cml0dGVu LCB0aGlzIGlzIGEgb25seSBzZW50ZW5jZSBmcmFnbWVudC4NClNvbWUgdGV4dCB3ZW50IG1pc3Np bmcgaGVyZS4gVGhlIG5ldyBzZW50ZW5jZSBzYXlzOiAiSWYgQW5vbnltb3VzIE5BSXMgDQphcmUg bm90IHVzZWQsIHRoZSBwcml2YWN5LWZyaWVuZGx5IGlkZW50aWZpZXJzIG5lZWQgdG8gYmUgZ2Vu ZXJhdGVkIHdpdGggDQpjYXJlLiINCj4NCj4gKDE5KSBTZWN0aW9uIDUuOC4gIFBlciAiQW4gRUFQ IHBlZXIgd2l0aCBhIHBvbGljeSBhbGxvd2luZyBjb21tdW5pY2F0aW9uIHdpdGggRUFQIHNlcnZl cnMgc3VwcG9ydGluZyBvbmx5IFRMUyAxLjIgd2l0aG91dCBwcml2YWN5ICBhbmQgd2l0aCBhIHN0 YXRpYyBSU0Ega2V5IGV4Y2hhbmdlIGlzIHZ1bG5lcmFibGUgdG8gZGlzY2xvc3VyZSBvZiB0aGUg cGVlciB1c2VybmFtZSIsIHRoZSAid2l0aG91dCBwcml2YWN5IiB3b3VsZCBiZW5lZml0IGZyb20g YmVpbmcgbW9yZSBwcmVjaXNlbHkgc3RhdGVkLg0KDQpUaGlzIGF0dGFjayAoYW5kIGd1aWRhbmNl KSBpcyBzb21ld2hhdCBjb252b2x1dGVkIHRvIGV4cGxhaW4uIExldCBtZSB0cnk6DQoNClJGQyA1 MjE2IHNheXMgdGhhdCAiYW4gRUFQLVRMUyBwZWVyIGNvbmZpZ3VyZWQgZm9yIHByaXZhY3kgTVVT VCANCm5lZ290aWF0ZSBhIFRMUyBjaXBoZXJzdWl0ZSBzdXBwb3J0aW5nIGNvbmZpZGVudGlhbGl0 eSBhbmQgTVVTVCBwcm92aWRlIA0KYSBjbGllbnQgY2VydGlmaWNhdGUgbGlzdCBjb250YWluaW5n IG5vIGVudHJpZXMgaW4gcmVzcG9uc2UgdG8gdGhlIA0KaW5pdGlhbCBjZXJ0aWZpY2F0ZV9yZXF1 ZXN0IGZyb20gdGhlIEVBUC1UTFMgc2VydmVyIi4gVGhpcyBhbGxvd3MgdGhlIA0KcGVlciB0byBu b3QgcmV2ZWFsIGl0cyBpZGVudGl0eSB1bnRpbCBpdCBoYXMgcmVjZWl2ZWQgYW5kIHZlcmlmaWVk IHRoZSANCnNlcnZlciBpZGVudGl0eS4gSXQgaXMgYSBnb29kIHByaXZhY3kgZmVhdHVyZSB0byBo YXZlLiBXaGVuIHdlIHdyb3RlIA0KIndpdGhvdXQgcHJpdmFjeSIsIHdlIHdlcmUgcmVmZXJyaW5n IHRvIGEgcGVlciB0aGF0IGRvZXMgbm90IGluc2lzdCBvbiANCnNlcnZlcnMgcmV2ZWFsaW5nIHRo ZWlyIGlkZW50aXR5IGZpcnN0Lg0KDQpUaGUgYXR0YWNrIHNjZW5hcmlvIHdlIGFyZSByZWZlcnJp bmcgaXMgYXMgZm9sbG93czoNCg0KLSBBIGZha2UgRUFQIHNlcnZlciBwcmV0ZW5kcyB0aGF0IGl0 IHN1cHBvcnRzIFRMUyAxLjIgKGV2ZW4gdGhvdWdoIHRoZSANCmhvbmVzdCBzZXJ2ZXIgYWxsb3dz IFRMUyAxLjMpLiBBIGZha2UgRUFQIHNlcnZlciB3b3VsZCBuYXR1cmFsbHkgYmUgDQpkZXRlY3Rl ZCBkdXJpbmcgdGhlIFRMUyBoYW5kc2hha2Ugc2luY2UgaXQgd2lsbCBub3QgaGF2ZSB0aGUgcHJp dmF0ZSBrZXkgDQooY29ycmVzcG9uZGluZyB0byB0aGUgcHVibGljIGtleSBpbiB0aGUgY2VydGlm aWNhdGUpLiBIb3dldmVyLCBpZiB0aGUgDQpmYWtlIHNlcnZlciBvZmZlcnMgc3RhdGljIFJTQSBr ZXkgZXhjaGFuZ2UgYW5kIHRoZSBwZWVyIGFjY2VwdHMgaXQsIHRoZSANCnByb29mLW9mLXBvc3Nl c3Npb24gb2YgdGhlIHNlcnZlciBwcml2YXRlIGtleSBpcyBub3QgZGVtb25zdHJhdGVkIHVudGls IA0KdGhlIEZpbmlzaGVkIG1lc3NhZ2UuIFNvIHRoZXJlIGlzIGEgY2hhbmNlIHRoYXQgdGhlIHBl ZXIgd291bGQgaGF2ZSANCnJldmVhbGVkIGl0cyBpZGVudGl0eSBiZWZvcmUgZmluZGluZyBvdXQg dGhhdCB0aGUgc2VydmVyIGlzIGZha2UuDQoNCkkgaGF2ZSBub3cgYWRkZWQgdGhlIGZvbGxvd2lu ZyBzZW50ZW5jZTogIlRoaXMgaW1wbGllcyB0aGF0IGFuIEVBUCBwZWVyIA0KU0hPVUxEIE5PVCBj b250aW51ZSB0aGUgaGFuZHNoYWtlIGlmIGEgVExTIDEuMiBFQVAgc2VydmVyIHJlc3BvbmRzIHRv IGFuIA0KZW1wdHkgY2VydGlmaWNhdGUgbWVzc2FnZSB3aXRoIGEgVExTIGFsZXJ0IG1lc3NhZ2Uu Ii4gVGh1cyB0aGUgcGVlciANCnNob3VsZCBpbnNpc3Qgb24gc2VydmVyIHJldmVhbGluZyBpdHMg aWRlbnRpdHkgZmlyc3QuIExldCB1cyBrbm93IGlmIHRoZSANCnRleHQgY2FuIGJlIGltcHJvdmVk IHNvbWVob3cuDQoNCj4NCj4gKDIwKSBTZWN0aW9uIDUuOS4gIEVkaXRvcmlhbC4gUGVyICJBcyBy ZXF1aXJlZCBieSBbUkZDNzI1OF0gLi4uIiwgSSdtIG5vdCBzdXJlIHdoYXQgdGhpcyBzZW50ZW5j ZSBhZGRzLg0KUmVtb3ZlZC4NCj4NCj4gKDIxKSBTZWN0aW9uIDUuOS4gIENvdWxkIHlvdSBjb250 ZXh0dWFsaXplIHRoaXMgIndpZGVzcHJlYWQgc3VydmVpbGxhbmNlIG9mIHVzZXJzICIgbW9yZSBz cGVjaWZpY2FsbHkgd2l0aGluIHRoZSBFQVAgY29udGV4dC4NCkFkZGVkIGEgc2VudGVuY2Ugc2F5 aW5nICJJbiB0aGUgY29udGV4dCBFQVAtVExTLCBwZXJ2YXNpdmUgbW9uaXRvcmluZyANCmF0dGFj a3MgY2FuIHRhcmdldCBwZWVyIGRldmljZXMgZm9yIHRyYWNraW5nIHRoZW0gKGFuZCB0aGVpciB1 c2VycykgYXMgDQphbmQgd2hlbiB0aGV5IGpvaW4gYSBuZXR3b3JrLiINCj4NCj4gUmVnYXJkcywN Cj4gUm9tYW4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gRW11IG1haWxpbmcgbGlzdA0KPiBFbXVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXUNCg== From nobody Mon Jun 8 03:08:18 2020 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 1979B3A083F; Mon, 8 Jun 2020 03:08:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-emu-eap-session-id@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Mohit Sethi , mohit.m.sethi@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159161089606.1395.15339284220368772862@ietfa.amsl.com> Date: Mon, 08 Jun 2020 03:08:16 -0700 Archived-At: Subject: [Emu] Robert Wilton's No Objection on draft-ietf-emu-eap-session-id-04: (with COMMENT) 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: Mon, 08 Jun 2020 10:08:16 -0000 Robert Wilton has entered the following ballot position for draft-ietf-emu-eap-session-id-04: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Like Warren, this document a long way outside of my area of expertise. However, having said that, I found the document easy to read and follow, and believe that this represents useful work, so thank you. Regards, Rob From nobody Mon Jun 8 04:25:31 2020 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 E6B983A0847 for ; Mon, 8 Jun 2020 04:25:29 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=S9MUu8D+; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=S9MUu8D+ 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 6y5juhq-5h3T for ; Mon, 8 Jun 2020 04:25:27 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2060.outbound.protection.outlook.com [40.107.21.60]) (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 47E813A083F for ; Mon, 8 Jun 2020 04:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8qAQGyZsW4VtoDeC9ESrJz30QBWKnB0bEJ6zPiw9QQ0=; b=S9MUu8D+H7v7Y1K6N+MaHe9g0fdYI2783/CjN27n5qrROhPKCaisicn0cyQmds9yaOEo5U1/6623qb8JPDB7Rx8RmZ/wv+Pdu6Ix13H0alwOfbilj7CoDRTmTacVd5Qc6vrSyZ/u3g4tS6O2Z3RVr4bSv0WBt0aosptihql/cfE= Received: from DB7PR05CA0065.eurprd05.prod.outlook.com (2603:10a6:10:2e::42) by AM0PR08MB3218.eurprd08.prod.outlook.com (2603:10a6:208:5b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Mon, 8 Jun 2020 11:25:24 +0000 Received: from DB5EUR03FT010.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:2e:cafe::64) by DB7PR05CA0065.outlook.office365.com (2603:10a6:10:2e::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 11:25:24 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT010.mail.protection.outlook.com (10.152.20.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 11:25:24 +0000 Received: ("Tessian outbound 56dbe829191e:v59"); Mon, 08 Jun 2020 11:25:24 +0000 X-CR-MTA-TID: 64aa7808 Received: from 5384de4e415b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D1D10377-ECD0-4F5A-B3B5-40FC6F1DD519.1; Mon, 08 Jun 2020 11:25:19 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5384de4e415b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 08 Jun 2020 11:25:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kHo4ex+K4ITl53JNn2xJrlihaivJXPRQEdHoYF8frRENWOFnet88tx4Vk8jXw9jsLBnsHEdJUCPEkr0huNj/BbM0ZV0LhpLDrF2gBGQjZL8ZHvgPHQyrXjqirBPhx1rFo9gEpQijJmDdaJC+e3zSy6hwQRHxcqNd9lrMsnWD7/ngzQYuGDfqreP5uqhv6LgGFKojZ+ufra7P3EW8jXkVa7VM97scDTXiD5X+KdWjP33juYEjlviGd3Km2hpe7r6lUWIXh5WsX4QlR8WOAPZrganiChg4tUyrQabJ2mbnJYEaaYxlmQmVBbEe0Y6tUJzOvNMjkaznT5XBW2uHRbNp3Q== 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=8qAQGyZsW4VtoDeC9ESrJz30QBWKnB0bEJ6zPiw9QQ0=; b=Ht2Uar+LPJO+7O4con/U/kgcfqVlNFzXIVXKAHO8Mz/SLfFZ2gxGfxMVZluV4d7WAfD1SJ523FntupcKdgLDZtS78pAjqR5LWwSbf34ABM3lE2I6NuYLkwfKu4NDCO4BqTYeGN8HJdUrx6mHRJ+foxqwcCcxmYp0jW2ztfp/6xeoz0TxGzuu7SRtoyxHVjCAeHnZkGzGi1YlvEj0iy/goHFwQJiLTaIUxdkOJ5E4VlXR6I2/u2axiFiHLgiLMBoRo/wfXP0mYO/QFaspT011Xk+p5uRjLN41UdmPiJs7pe/vGGdMtI6zEQiHnW3bQ0RS8Fbp8XLKYZBUYgsQNtOFFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8qAQGyZsW4VtoDeC9ESrJz30QBWKnB0bEJ6zPiw9QQ0=; b=S9MUu8D+H7v7Y1K6N+MaHe9g0fdYI2783/CjN27n5qrROhPKCaisicn0cyQmds9yaOEo5U1/6623qb8JPDB7Rx8RmZ/wv+Pdu6Ix13H0alwOfbilj7CoDRTmTacVd5Qc6vrSyZ/u3g4tS6O2Z3RVr4bSv0WBt0aosptihql/cfE= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3411.eurprd08.prod.outlook.com (2603:10a6:208:dd::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.19; Mon, 8 Jun 2020 11:25:17 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 11:25:17 +0000 From: Hannes Tschofenig To: EMU WG Thread-Topic: eap-noob Thread-Index: AdY9daurhhDfbfAXQfql56Pf802Imw== Date: Mon, 8 Jun 2020 11:25:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 33b56795-1a26-47c2-92ae-33d3789f8d94.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2b7109e4-f96d-493d-d143-08d80b9ea34a x-ms-traffictypediagnostic: AM0PR08MB3411:|AM0PR08MB3218: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 042857DBB5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: zDhf9d/swZIw5DRCTrvUR6UiM5SJ0QoMkgMuDnOdbvhfptKgk3MBFBL1cPx7AwFKdy8qniO9lHtMf2oQ6uywLbFFDdHCZnG7Xbq3IaDg4DupQb6YcQKq87iDU1+KFLNIW0japj+sPCKMjzMdWr7YpZ9+sWNk510jhO77zao/qkbWhRH+o1aODzZts+5f25JVHwGgClO2Aes77MLLs1/yKh5MrJo/nxM4ejuQcnmDH6M85EIHZuy6yHNLAt760U4lpJZqnLMWw55N1Eh4hTJbJsUfOYe/Tu300wAAC9/nDR/Bz7ASnnsiea3vQJHg2l5kovljev4rJdI7Gp7Pz2WNPw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(366004)(39860400002)(376002)(136003)(76116006)(86362001)(66476007)(8936002)(478600001)(55016002)(5660300002)(71200400001)(8676002)(83380400001)(66946007)(316002)(6506007)(66556008)(64756008)(66446008)(26005)(3480700007)(7696005)(6916009)(52536014)(33656002)(186003)(9686003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: eLh1ABM7w/G0to8mGa2kiFAbr5SR/OG2Kru5mbNI2n1UrxtGLHKuoQR6TQ1dxdNTG7mAKUzeqtKDndEthXl53mR3tyr8hMMwwqkZ4E6xYQLJOGABd8wqbzjxGC1tanw0oTq+kCBnoP3rfOcD2jyfGQ+OYTZrgg+6vnkqkM4ffp/vZ5/gJhloTMnrh7mAQSrGKIdTcm7N7RlLyGKWvYQbDbT8Np5YO+AjezRDcQoQh8LXLc3FFmKC/AngShepZL0LNWVmD8hDfDiZS59sAtPblp77IzU86MiqIh8uzvqMoZpWVTj2TFdqYEOVdxVUBYPPF0enXlVSlrcjlioS2QRQcTyvF5tPO2GLh3zBATBXtiiwMVVvIFTEWan7ubHthVAPmcwTPAtTjOUqvNPLUP0af75EVe8r1Z3iST2QOKa7t0UZJ4Wu6T6pkGR3KAQ4wjT5oPgQseg7ZmMPvvMmJSUyJJIKTIafWoKTTsVGGo0LO8ZxBo1P63o7EgEp4222E1Si x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB371626BE44457F8C0B6170F5FA850AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3411 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT010.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(39860400002)(346002)(46966005)(6916009)(316002)(9686003)(5660300002)(70206006)(6506007)(33656002)(336012)(70586007)(2906002)(7696005)(55016002)(8676002)(82740400003)(52536014)(8936002)(186003)(26005)(82310400002)(356005)(3480700007)(478600001)(86362001)(83380400001)(81166007)(47076004); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 05975363-ffbc-42b9-d801-08d80b9e9f0e X-Forefront-PRVS: 042857DBB5 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tgNIjYJF0P6RrzngrswqsnD5tgHtB1CJtse9Tr4Qrn1kklGzyyahXRr0bIs9bsaVXLfN3OtGdseDnkLKB5rbtUpENm0jieeM/BNWCt2YbbdcxGqnw/Pgh3wD+owOBpzXjezc2NdhxLs28ysnN3530ttf1OqU303rJksROVwnAx2Kgzl6/llrFcJABpMikzuGnJLJAnJErmC/TzUHEabExPsORKLNsbq3DFB4snC13PMwx0DGHKxWFxNMAlYeaIlIv+Sa1t3n5MNtJm8ti4wKRsNfJ7wz+Xinsq8OZ4if7qiqXmfQUuxg2zLYXJmXZZi3kjrx3WNXTH6oGoI7TedOGxSwLt+U8Dkqeec+uCxey7klm+5dGIVvPrPxmimmIqpi5m0rq9IrKksCKPcM54cwSg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2020 11:25:24.5182 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2b7109e4-f96d-493d-d143-08d80b9ea34a X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3218 Archived-At: Subject: [Emu] eap-noob 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, 08 Jun 2020 11:25:30 -0000 --_000_AM0PR08MB371626BE44457F8C0B6170F5FA850AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all I read through draft-aura-eap-noob-08 during the call for adoption. The draft acknowledges that the concept of "onboarding" is a new term for a= n old concept, namely network access authentication. I like the draft from that point of view. The content looks fine good and the design is well described. There is a fo= rmal analysis available and sample code available. I believe it would be good to note that the solution does not support any f= orm of cloning prevention because the device is assumed to be "blank" from = the point of view of keying material. I was wondering about one aspect, and maybe I missed it somewhere: what are= you actually authenticating? The identifier for the client is assigned by the EAP server. The server is = also unknown at the start of the protocol. I also got the impression that the authors are not entirely sure about repe= ating the OOB step. Earlier in the document it sounds like the authors do n= ot really like the idea to repeat it and then later in the document they ac= knowledge that it will be necessary to deal with it anyway. Am I reading in= -between the lines here? There is also a not-so-bright side of this draft: the deployment. The solut= ion places many constraints on potential solutions, the authors have little= influence on the deployment environment, the use of EAP is not that common= in IoT communication technologies, there are many other competing solution= s, etc. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB371626BE44457F8C0B6170F5FA850AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

 

I read through draft-aura-eap-noob-08 during the cal= l for adoption.

 

The draft acknowledges that the concept of “on= boarding” is a new term for an old concept, namely network access aut= hentication.

I like the draft from that point of view.

 

The content looks fine good and the design is well d= escribed. There is a formal analysis available and sample code available.

 

I believe it would be good to note that the solution= does not support any form of cloning prevention because the device is assu= med to be “blank” from the point of view of keying material.

 

I was wondering about one aspect, and maybe I missed= it somewhere: what are you actually authenticating?

The identifier for the client is assigned by the EAP= server. The server is also unknown at the start of the protocol.

 

I also got the impression that the authors are not e= ntirely sure about repeating the OOB step. Earlier in the document it sound= s like the authors do not really like the idea to repeat it and then later = in the document they acknowledge that it will be necessary to deal with it anyway. Am I reading in-between the l= ines here?

 

There is also a not-so-bright side of this draft: th= e deployment. The solution places many constraints on potential solutions, = the authors have little influence on the deployment environment, the use of= EAP is not that common in IoT communication technologies, there are many other competing solutions, etc.

 

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB371626BE44457F8C0B6170F5FA850AM0PR08MB3716eurp_-- From nobody Mon Jun 8 05:08:41 2020 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 CFEFC3A03F6; Mon, 8 Jun 2020 05:08:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-emu-eap-session-id@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Mohit Sethi , mohit.m.sethi@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <159161811942.10302.2209931489538055081@ietfa.amsl.com> Date: Mon, 08 Jun 2020 05:08:39 -0700 Archived-At: Subject: [Emu] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?emu-eap-session-id-04=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: Mon, 08 Jun 2020 12:08:40 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-emu-eap-session-id-04: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Alan, Thank you for the work put into this document. The short document is easy to read and I am trusting the security AD for the security aspects. Just wondering why there is no -03 ;-) and suggest to update errata 5011 (that is still open) Regards -éric From nobody Mon Jun 8 05:19:45 2020 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 7F7613A0998 for ; Mon, 8 Jun 2020 05:19:43 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=y8MGC/q7; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=y8MGC/q7 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 IIgAZIuOa_Hs for ; Mon, 8 Jun 2020 05:19:39 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.40]) (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 B0FA63A0A1C for ; Mon, 8 Jun 2020 05:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LJKpy3AN8/g8YIGDP1Oy7PsZJ9mMWwQLE1MN8Pvjm2U=; b=y8MGC/q7wtaUMJEIKbvqwD9vqC2CZEseTsqx4+TqX7bCS1iHImsoKHxfDtvieKi5FsQSlJamfGge6qDGS3HM8XbTZZBdUKtcPVineqrk3UoF9bzX9JLImn22fwfoFe4hFyPzHsLTTPXWGGedRdw10kRi5bHnkk9FBBwh7hDaQf4= Received: from DB6PR0601CA0010.eurprd06.prod.outlook.com (2603:10a6:4:7b::20) by AM6PR08MB4406.eurprd08.prod.outlook.com (2603:10a6:20b:71::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.22; Mon, 8 Jun 2020 12:19:35 +0000 Received: from DB5EUR03FT057.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:7b:cafe::d6) by DB6PR0601CA0010.outlook.office365.com (2603:10a6:4:7b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 12:19:35 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT057.mail.protection.outlook.com (10.152.20.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 12:19:35 +0000 Received: ("Tessian outbound 1145f7a293ca:v59"); Mon, 08 Jun 2020 12:19:35 +0000 X-CR-MTA-TID: 64aa7808 Received: from aaee1585e912.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B72FBC0A-3838-4064-9280-BCAFA43E6968.1; Mon, 08 Jun 2020 12:19:30 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id aaee1585e912.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 08 Jun 2020 12:19:30 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uc9l4ZWeKevRh7Z4ykS/gq2lkjO9wC00n1ajbSs1J1pXVQeqBOafRtt3IjuZ8rL2JC6cHGL1Ez8nzM9PgvjJqUbGnbruJ6xXTQJ1maeNk6VwrpkhsHXTP/2Jbfg8PjSABS+KkWJuKPANrLh55rqNm/2uqmWXr8PHka5AkP2hHS8Ysfpp5euI8YC0QjfFxrJwU56eZ7ar7Yc6oMi9uBBU248PFp50DGNk8wOha1Qkaiy2rA240yYkGud9S5AAmmgPpfNhI66gtoAmErg+EZH7cnFO+ElXoKvDPTPj8YjASvObBxRMG1LO0HTivTw66JaIpSBsDPkT3HULhvh8x5SmiQ== 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=LJKpy3AN8/g8YIGDP1Oy7PsZJ9mMWwQLE1MN8Pvjm2U=; b=X1rvnwhqXQYHv1m+uRuRGQFqqz2ZfcXrGea6OclLAVlnZPs5+OZAG+RFo5eBfJO6vMUjRTdT6BFYcK3py+P3ZZtiWNyfA/0heJoHyzBMZhxJDcSskw2d5PMbxGYjJS/27TYlY+g0EBh+whpx3j52VTfDq2M9os5nKNNi9IL5IeeQVrG9tJUlhDlznDrJvz+r1HpgoRv2rOhLyuu/TFyYknBJLuXYjqb7VM6cQJmkBkD3AvdC1BzTfl/Yhiby0FHg4RWgJ4Li+4YZ0UNmCoARaQbd/go/KxFFdThFQ58mhIgKuJ1c0Vwaplpn6FpEBqlTAnbRUHKrVrRXMFJ9xggvBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LJKpy3AN8/g8YIGDP1Oy7PsZJ9mMWwQLE1MN8Pvjm2U=; b=y8MGC/q7wtaUMJEIKbvqwD9vqC2CZEseTsqx4+TqX7bCS1iHImsoKHxfDtvieKi5FsQSlJamfGge6qDGS3HM8XbTZZBdUKtcPVineqrk3UoF9bzX9JLImn22fwfoFe4hFyPzHsLTTPXWGGedRdw10kRi5bHnkk9FBBwh7hDaQf4= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4404.eurprd08.prod.outlook.com (2603:10a6:208:137::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Mon, 8 Jun 2020 12:19:28 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 12:19:28 +0000 From: Hannes Tschofenig To: Mohit Sethi M , Michael Richardson , "emu@ietf.org" Thread-Topic: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt Thread-Index: AQHWJd6vdJG1qJnBQEKWVNcpaao/fKjOz8Nw Date: Mon, 8 Jun 2020 12:19:28 +0000 Message-ID: References: <0c843ca8-8bfc-8bf6-2cb2-a8517359842f@ericsson.com> In-Reply-To: <0c843ca8-8bfc-8bf6-2cb2-a8517359842f@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 746b650c-018f-4519-ada0-f1ed4e1bb629.0 x-checkrecipientchecked: true Authentication-Results-Original: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 7c25c7dd-4565-4152-b941-08d80ba6352d x-ms-traffictypediagnostic: AM0PR08MB4404:|AM6PR08MB4406: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 042857DBB5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: S6olHeO7iHYwWjkXhBUP12MmfI1iNlxTv1Dtu1B0Hnq5npGhjacuA2eX/Huqfh2GxKsX9EwEbQu4mo/p4djOLZOvwME3jkME4/ubmFvASDsDXeeeUETrsVKSBXtFtL7Ef7XO1UbrZ/SQ8BcozJ409iVRNVbq89TQ4u1z1Z41G6MBMNaHi8KnX4obVf24tLYeaqIML7qqjkqK4dYQEEJC0rIQA7MCJP9W9XS4dYmm24tg6eaSimRGYeA+SBzcNQKPr07U8nIRNjqm5rzJYBxxIRLYzEUKQiWQoQnJzYIDv3x71fPIdV+5oc0DoSJ2hDxSyRF1cfafbZ3Cso2vSjWReLOhDaqmKyNO9M+cbjFaSYwi5GfSB4v8Qzj6zZCIXyI9Wln0a/ZIVauxssN/Se25hg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(376002)(136003)(346002)(396003)(966005)(478600001)(64756008)(66556008)(316002)(66476007)(66446008)(53546011)(186003)(66946007)(7696005)(6506007)(83380400001)(26005)(110136005)(9686003)(55016002)(52536014)(2906002)(71200400001)(5660300002)(76116006)(8936002)(86362001)(33656002)(30864003)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: nqueN0y8Rqo5KWikMn144D5qfoxZSt+HbkpXruPMD/hsq1COt+7uei37IV+zbG/hlzajWJlGmLzSFb/UGMdpgpw+KMyih5ilgAsLsLBAEsIXOEWq2pore4v791iY3rIUfHbYejaEoA25tyn3Zxhu/LGvJ7QmuN2QaP6C3Va4e+A/QZPhEp75IEqUSHvmjfvldsicgriEbvWqCDEk/lr9wB4m3Sg7FMiuoVRaS3KSZu5ll759LcB1T+Y6VoeXIml3p0zYCnoGy27bIwT8SyfneJE7j/Ih25w3bFXGyhmsJ8+WCAaZSULy/kfpHJX0bbR8TVngPDzo9Y5M2gwbcdPKTHCEQUpaqct3Ohy2MbWfotrhqbp+a621LGGvI3imjdHNzQ/OXkdqDq3GZQvBpp5rU/aegIKPLJjbyj8y5mIm31KuTSGCJUTAUvt0tNF2/FwC8CeOMvVQYNQvibZ1aYRxC2u0MDp3GhdNSmkfpBwlCmVFdvsfg5kkCpj7qVyruH7h x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4404 Original-Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT057.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(396003)(39860400002)(46966005)(82740400003)(70586007)(2906002)(82310400002)(81166007)(70206006)(55016002)(26005)(83380400001)(7696005)(336012)(30864003)(9686003)(33656002)(8676002)(356005)(52536014)(8936002)(5660300002)(186003)(53546011)(316002)(966005)(47076004)(478600001)(6506007)(86362001)(110136005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 3ce31e7a-fd2a-48ee-668b-08d80ba630eb X-Forefront-PRVS: 042857DBB5 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Z7Z6Pw3KQ+yZVoig/aFMqLLcuh3MLDkxI8VjJpDXb7BvgtDNL81PMIsVm/6VE0feTtrIomMoat7smoDl++Ydx1h1D30WovlwuTWUDqtMPwR6dGdvLZog5rkXJUiwAG3xgo9iWinHvfjqbFRCGafUeTDGpFqW6BG4V8mTiU5NnmOyp7yVt8XlgU/a9NV9INWSQ+RX6wqLLUWeVOc+Sn4be5MmpWst4uECAihMDwNpTu9Qao8fxuidnUl2gvx3fts8fC4gC1I3drth2b+HcI2i3YhV+vjiKj1KEbydgMxICugA/I1gFydOemhC1HVPltWRIsFiVpPYSvY9zWsZW5V+rk7UyFuQFDrEm71sHs/KGLY4LJCOttYFtf481wiRikFdzAu0KDpuNCxu/2QqKn+/9mqDav1hqmlr0cLn+cP5ZhSFgDosdtIxHySWaeZBu+Y1cGlovg9jWmOte40rfA/b8qOj+ohdyrVcZsuzZOkv93M= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2020 12:19:35.7510 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7c25c7dd-4565-4152-b941-08d80ba6352d X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4406 Archived-At: Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.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: Mon, 08 Jun 2020 12:19:44 -0000 VGhhbmtzIGZvciB0aGUgdXBkYXRlLCBNb2hpdC4NCg0KQSBmZXcgbWlub3IgcmVtYXJrczoNCg0K RlJPTToNCg0KIg0KICAgVExTIGNlcnRpZmljYXRlcyBpbiBFQVAgZGVwbG95bWVudHMgY2FuIGJl IHJlbGF0aXZlbHkgbGFyZ2UsIGFuZCB0aGUNCiAgIGNlcnRpZmljYXRlIGNoYWlucyBjYW4gYmUg bG9uZy4NCiINCg0KVE86DQoNCiINCiAgIENlcnRpZmljYXRlcyBpbiBFQVAgZGVwbG95bWVudHMg Y2FuIGJlIHJlbGF0aXZlbHkgbGFyZ2UsIGFuZCB0aGUNCiAgIGNlcnRpZmljYXRlIGNoYWlucyBj YW4gYmUgbG9uZy4NCiINCg0KUmVhc29uOiBDZXJ0aWZpY2F0ZXMgYXJlIGxhcmdlIGFuZCB0aGVy ZSBpcyBub3RoaW5nIGluIFRMUyB0aGF0IGNvbnRyaWJ1dGVzIHRvIHRoZSBzaXplLg0KDQpJbiBT ZWN0aW9uIDQgSSB3b3VsZCBzdGF0ZSB0aGUgb2J2aW91cyB0byB0aGUgcmVhZGVyOiBLZWVwIHRo ZSBjZXJ0aWZpY2F0ZSBzaXplIHNtYWxsIGJ5IG5vdCBzdHVmZmluZyBsb3RzIG9mIGZpZWxkcyBp biBpdCBhbmQga2VlcCB0aGUgY2hhaW4gc2hvcnQuDQpBIGNvbW1vbiByZWFzb24gd2h5IHRoZXNl IGNlcnRzIGFyZSBsb25nIGlzIGJlY2F1c2UgZGV2ZWxvcGVycyBkb24ndCB1bmRlcnN0YW5kIHRo YXQgdGhleSBkbyBub3QgbmVlZCB0byBtYXAgdGhlIG9yZ2FuaXphdGlvbmFsIGhpZXJhcmNoeSB0 byBhIENBIGhpZXJhcmNoeS4NClRoaXMgaXMgdGhlIHNpbXBsZXN0IGFwcHJvYWNoIHRvIHJlZHVj ZSB0aGUgc2l6ZSBvZiBjZXJ0aWZpY2F0ZXMgc2VudCBvdmVyIHRoZSB3aXJlLg0KDQpSZWdhcmRp bmcgNC4yLjMuICBDb21wYWN0IFRMUyAxLjMNCg0KICAgW0ktRC5pZXRmLXRscy1jdGxzXSBkZWZp bmVzIGEgImNvbXBhY3QiIHZlcnNpb24gb2YgVExTIDEuMyBhbmQNCiAgIHJlZHVjZXMgdGhlIG1l c3NhZ2Ugc2l6ZSBvZiB0aGUgcHJvdG9jb2wgYnkgcmVtb3Zpbmcgb2Jzb2xldGUNCiAgIG1hdGVy aWFsIGFuZCB1c2luZyBtb3JlIGVmZmljaWVudCBlbmNvZGluZy4gIFRoaXMgbmF0dXJhbGx5IG1l YW5zDQogICB0aGF0IGNUTFMgaXMgbm90IGludGVyb3BlcmFibGUgd2l0aCBwcmV2aW91cyB2ZXJz aW9ucyBvZiB0aGUgVExTDQogICBwcm90b2NvbC4gIEl0IGFsc28gZGVmaW5lcyBhIGNvbXByZXNz aW9uIHByb2ZpbGUgd2l0aCB3aGljaCBlaXRoZXINCiAgIHNpZGUgY2FuIGRlZmluZSBkaWN0aW9u YXJ5IG9mICJrbm93biBjZXJ0aWZpY2F0ZXMiLiAgVGh1cywgY1RMUyBjYW4NCiAgIHByb3ZpZGUg YW5vdGhlciBtZWNoYW5pc20gZm9yIEVBUC1UTFMgZGVwbG95bWVudHMgdG8gcmVkdWNlIHRoZSBz aXplDQogICBvZiBtZXNzYWdlcyBhbmQgYXZvaWQgZXhjZXNzaXZlIGZyYWdtZW50YXRpb24uDQoN ClRoZSBwb2ludCBmb3IgbWVudGlvbmluZyBjVExTIHdhcyByZWxhdGVkIHRvIHRoZSBjZXJ0aWZp Y2F0ZSBjb21wcmVzc2lvbi4gSSB3b3VsZCB0aGVyZWZvcmUgY2hhbmdlIHRoZSBwYXJhZ3JhcGgg dG86DQoNCjQuMi4zLiAgQ29tcGFjdCBUTFMgMS4zDQoNCiAgIFtJLUQuaWV0Zi10bHMtY3Rsc10g ZGVmaW5lcyBhICJjb21wYWN0IiB2ZXJzaW9uIG9mIFRMUyAxLjMgYW5kDQogICByZWR1Y2VzIHRo ZSBtZXNzYWdlIHNpemUgb2YgdGhlIHByb3RvY29sIGJ5IHJlbW92aW5nIG9ic29sZXRlDQogICBt YXRlcmlhbCBhbmQgdXNpbmcgbW9yZSBlZmZpY2llbnQgZW5jb2RpbmcuICBJdCBhbHNvIGRlZmlu ZXMgYQ0KICAgY29tcHJlc3Npb24gcHJvZmlsZSB3aXRoIHdoaWNoIGVpdGhlciAgc2lkZSBjYW4g ZGVmaW5lIGRpY3Rpb25hcnkNCiAgIG9mICJrbm93biBjZXJ0aWZpY2F0ZXMiLg0KDQpJIHdvbmRl ciB3aGV0aGVyIHlvdSB3YW50IHRvIG1lbnRpb24gYWxzbyBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtdHNjaG9mZW5pZy10bHMtY3d0LTAxIGFuZCBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcy0wMD8NClNpbmNl IHRob3NlIGFyZSBzdGlsbCBpbmRpdmlkdWFsIGRyYWZ0cyB5b3UgY291bGQgcG9pbnQgb3V0IHRo YXQgdGhvc2UgYXJlIHdvcmsgaW4gcHJvZ3Jlc3MuDQoNCkNpYW8NCkhhbm5lcw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTW9oaXQgU2V0aGkgTSA8bW9oaXQubS5zZXRoaUBl cmljc3Nvbi5jb20+DQpTZW50OiBTYXR1cmRheSwgTWF5IDksIDIwMjAgMTA6NDkgQU0NClRvOiBI YW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT47IE1pY2hhZWwgUmlj aGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgZW11QGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW0VtdV0gTXkgcmV2aWV3IC4uLiB3YXMgUkU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZW11 LWVhcHRsc2NlcnQtMDIudHh0DQoNCkhpIEhhbm5lcywNCg0KSSBoYXZlIHN1Ym1pdHRlZCBhIG5l dyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aGljaCBJIGJlbGlldmUgYWRkcmVzc2VzIHlvdXIgY29u Y2VybnMuIEhlcmUgaXMgYSBkaWZmIGZvciB5b3VyIGNvbnZlbmllbmNlOg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZW11LWVhcHRsc2NlcnQtMDMNCg0KV2hp bGUgQWxhbiBhbmQgSm91bmkgaGF2ZSBhbHJlYWR5IHByb3ZpZGVkIGV4Y2VsbGVudCBhbnN3ZXJz IHRvIG1vc3Qgb2YgeW91ciBjb21tZW50cywgaW4tbGluZSB5b3UgY2FuIGZpbmQgYSBmZXcgbW9y ZSBjbGFyaWZpY2F0aW9ucyBmb3IgdGhlIGNoYW5nZXMgSSBtYWRlLg0KDQotLU1vaGl0DQoNCk9u IDMvMjQvMjAgMTA6MDAgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOg0KPiBIaSBNaWNoYWVs LCBIaSBkcmFmdCBhdXRob3JzLA0KPg0KPj4gSSB3YXMgc3VycHJpc2VkIHRvIGdldCB0byB0aGUg ZW5kIG9mIHRoZSBkb2N1bWVudCB3aXRob3V0IGFueSBzdWdnZXN0aW9ucyBhYm91dCBzZW5kaW5n IGNlcnRpZmljYXRlcyBieSByZWZlcmVuY2UgcmF0aGVyIHRoYW4gdmFsdWUuDQo+IEhhdmluZyBz ZWVuIHRoaXMgc3RhdGVtZW50IGZyb20gTWljaGFlbCBJIGhhdmUgcmV2aWV3ZWQgdGhlIGRvY3Vt ZW50LiBUd28gZ2VuZXJpYyBvYnNlcnZhdGlvbnMgYWJvdXQgdGhlIGRyYWZ0Og0KPg0KPiAxKSBN YW55IHN0YXRlbWVudHMgYXJlIG1hZGUgYWJvdXQgZGVwbG95bWVudHMgYW5kIG5vIHJlZmVyZW5j ZXMgYXJlIHByb3ZpZGVkLiBUbyBpbXByb3ZlIHF1YWxpdHkgb2YgdGhlIHdyaXRlLXVwIEkgd291 bGQgc3Ryb25nbHkgc3VnZ2VzdCB0byBhZGQgc3VjaCByZWZlcmVuY2VzLCBhcyB5b3Ugd291bGQg aGF2ZSB0byBkbyB3aXRoIGFuIGFjYWRlbWljIHB1YmxpY2F0aW9uIGFzIHdlbGwuDQo+DQo+IDIp IEEgZmV3IHRlY2huaXF1ZXMgYXJlIG1pc3NpbmcgKENlcnRpZmljYXRlIFVSTHMgYW5kIGNUTFMp IGFuZCBUTFMgQ2FjaGVkIEluZm8gd2FzIHdyb25nbHkgaW50ZXJwcmV0ZWQuICBUaGV5IGFjdHVh bGx5IHJlbGF0ZSB0byB0aGUgcmVtYXJrIGZyb20gTWljaGFlbC4NCj4NCj4+IFRMUyBjZXJ0aWZp Y2F0ZXMgYXJlIG9mdGVuIHJlbGF0aXZlbHkgbGFyZ2UsIGFuZCB0aGUgY2VydGlmaWNhdGUNCj4+ ICAgIGNoYWlucyBhcmUgb2Z0ZW4gbG9uZy4NCj4gSSB0aGluayB0aGlzIHN0YXRlbWVudCBpcyBp biBnZW5lcmFsIGluY29ycmVjdC4gWW91IGNvdWxkIHNheSB0aGF0IGluIGRlcGxveW1lbnQgWCBj ZXJ0aWZpY2F0ZXMgaGF2ZSBzaXplIFggYW5kIHRoZSBjaGFpbiBpcyBZIGxvbmcuDQo+DQo+DQo+ PiBBbHNvLA0KPj4gICBmcm9tIGRlcGxveW1lbnQgZXhwZXJpZW5jZSwgRUFQIHBlZXJzIHR5cGlj YWxseSBoYXZlIGxvbmdlcg0KPj4gICAgY2VydGlmaWNhdGUgY2hhaW5zIHRoYW4gc2VydmVycy4N Cj4gSSB3b3VsZCBsaWtlIGEgcmVmZXJlbmNlIHRvIGJlIGluY2x1ZGVkIGhlcmUuIFRoZW9yZXRp Y2FsbHksIGl0IG1ha2VzDQo+IG5vIHNlbnNlIHRvIGhhdmUgYSBjZXJ0aWZpY2F0ZSBjaGFpbiBm b3IgYW4gRUFQIHBlZXIgdG8gaGF2ZSBhIGxvbmdlcg0KPiBjZXJ0aWZpY2F0ZSBjaGFpbiB0aGFu IGEgc2VydmVyIGdpdmVuIGEgRUFQIHBlZXIgdGFsa3MgdG8gb25lIEVBUCBzZXJ2ZXIuDQo+DQo+ IEluIG5ldHdvcmsgYWNjZXNzIGF1dGhlbnRpY2F0aW9uIGl0IGlzIG5vdCBvbmx5IGFib3V0IGF1 dGhlbnRpY2F0aW9uIGJ1dCB0aGUgbW9zdCBpbXBvcnRhbnQgcGFydCBpcyBhdXRob3JpemF0aW9u LiBIZW5jZSwgeW91IHByZXR0eSBtdWNoIGFsd2F5cyBoYXZlIGEgb25lLXRvLW9uZSByZWxhdGlv bnNoaXAgYmV0d2VlbiB0aGUgRUFQIHBlZXIgYW5kIHRoZSBFQVAgc2VydmVyLiBUaGVyZSBhcmUg bm8gZ29vZCByZWFzb25zIHRvIGhhdmUgY29tcGxleCBDQSBoaWVyYXJjaGllcyBoZXJlLg0KPg0K Pj4gVGhpcyBpcyBiZWNhdXNlIEVBUCBwZWVycyBvZnRlbg0KPj4gICBmb2xsb3cgb3JnYW5pemF0 aW9uYWwgaGllcmFyY2hpZXMgYW5kIHRlbmQgdG8gaGF2ZSBtYW55IGludGVybWVkaWF0ZQ0KPj4g ICAgY2VydGlmaWNhdGVzLiAgVGh1cywgRUFQLVRMUyBhdXRoZW50aWNhdGlvbiB1c3VhbGx5IGlu dm9sdmUNCj4+ICAgIHNpZ25pZmljYW50bHkgbW9yZSBvY3RldHMgdGhhbiB3aGVuIFRMUyBpcyB1 c2VkIGFzIHBhcnQgb2YgSFRUUFMuDQo+IEkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSB0byBl eHBsYWluIHRoaXMgb3JnYW5pemF0aW9uYWwgaGllcmFyY2h5DQo+IGFzcGVjdCBpbiBhIGJpdCBt b3JlIGRldGFpbC4NCj4NCj4+IFRoZSBFQVAgZnJhZ21lbnQgc2l6ZQ0KPj4gICBpbiB0eXBpY2Fs IGRlcGxveW1lbnRzIGlzIGp1c3QgMTAyMCAtIDE1MDAgb2N0ZXRzLg0KPiBSZWZlcmVuY2UgZm9y IHRoZSAxNTAwIG9jdGV0cy4NCkFkZGVkIHRoYXQgdGhpcyBsaW1pdGF0aW9uIGNvbWUgZnJvbSBF dGhlcm5ldCBJSSBmcmFtZSBzaXplLg0KPg0KPg0KPj4gRm9yIGV4YW1wbGUsIG1hbnkgRUFQIGF1 dGhlbnRpY2F0b3IgKGFjY2VzcyBwb2ludCkNCj4+ICAgaW1wbGVtZW50YXRpb25zIHdpbGwgZHJv cCBhbiBFQVAgc2Vzc2lvbiBpZiBpdCBoYXMgbm90IGZpbmlzaGVkIGFmdGVyDQo+PiAgICA0MCAt IDUwIHJvdW5kLXRyaXBzLg0KPiBJcyB0aGVyZSBhIHJlZmVyZW5jZSB0aGF0IGNvdWxkIGJlIGlu Y2x1ZGVkPw0KPg0KPj4gSG93ZXZlciwgZGVwbG95bWVudA0KPj4gICAgZXhwZXJpZW5jZSBoYXMg c2hvd24gdGhhdCB0aGVzZSBqdW1ibyBmcmFtZXMgYXJlIG5vdCBhbHdheXMNCj4+ICAgaW1wbGVt ZW50ZWQgY29ycmVjdGx5Lg0KPiBBZGQgYSByZWZlcmVuY2UgaGVyZS4NCj4NCj4+IFJBRElVUyBj YW4gZ2VuZXJhbGx5IHRyYW5zcG9ydCBvbmx5IGFib3V0IDQwMDANCj4+ICAgb2N0ZXRzIG9mIEVB UCBpbiBhIHNpbmdsZSBtZXNzYWdlLg0KPiBIb3cgd2FzIHRoaXMgbnVtYmVyIGNvbnN0cnVjdGVk Pw0KQWRkZWQgdGhhdCBSQURJVVMgUkZDMjg2NSBsaW1pdHMgbGVuZ3RoIHRvIDQwOTYgb2N0ZXRz Lg0KPg0KPj4gICAgQSBjZXJ0aWZpY2F0ZSBjaGFpbiAoY2FsbGVkIGEgY2VydGlmaWNhdGlvbiBw YXRoIGluIFtSRkM1MjgwXSkgY2FuDQo+PiAgICBoYXZlIDIgLSA2IGludGVybWVkaWF0ZSBjZXJ0 aWZpY2F0ZXMgYmV0d2VlbiB0aGUgZW5kLWVudGl0eQ0KPj4gICAgY2VydGlmaWNhdGUgYW5kIHRo ZSB0cnVzdCBhbmNob3IgW1JGQzUyODBdLg0KPiBUaGUgUEtJWCByZWZlcmVuY2UgaGVyZSBpcyBt aXNsZWFkaW5nLiBJIHRoaW5rIHlvdSBpbmNsdWRlZCBpdCB0bw0KPiByZWZlciB0byB0aGUgdGVy bXMgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZSBzdGF0ZW1lbnQgdGhhdCB0aGUgY2hhaW4gY2FuIGhh dmUgMi02IGludGVybWVkaWF0ZSBDQSBjZXJ0aWZpY2F0ZXMuDQo+DQo+IEkgd291bGQgYWRkIHRo ZSB0ZXJtcyB0byB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBhbmQgcmVtb3ZlIHRoZSBQS0lYIHJl ZmVyZW5jZSBoZXJlLg0KRG9uZS4gVGhhbmtzLiBJbmRlZWQgdGhhdCB3YXMgbWlzbGVhZGluZy4N Cj4NCj4gSSBhbSBhbHNvIHdvbmRlcmluZyB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIHNheSBoZXJl IHdpdGggdGhpcw0KPiBzZW50ZW5jZS4gQXJlIHlvdSBzYXlpbmcgdGhhdCB5b3UgaGF2ZSBzZWVu IGRlcGxveW1lbnRzIGZvciBuZXR3b3JrIGFjY2VzcyBhdXRoZW50aWNhdGlvbiB0aGF0IGhhdmUg dXAgdG8gNiBpbnRlcm1lZGlhdGUgQ0EgY2VydGlmaWNhdGVzIGluIHRoZSBjaGFpbj8NCj4NCj4N Cj4+IDMuICBFeHBlcmllbmNlIHdpdGggRGVwbG95bWVudHMNCj4+ICAgIE1vc3QgY29tbW9uIGFj Y2VzcyBwb2ludCBpbXBsZW1lbnRhdGlvbnMgZHJvcCBFQVAgc2Vzc2lvbnMgdGhhdCBkbw0KPj4g ICAgbm90IGNvbXBsZXRlIHdpdGhpbiA1MCByb3VuZC10cmlwcy4NCj4gVGhpcyBzZW50ZW5jZSBp cyBhIHJlcGV0aXRpb24uDQo+DQo+PiBUaGlzIG1lYW5zIHRoYXQgaWYgdGhlIGNoYWluIGlzDQo+ PiAgIGxhcmdlciB0aGFuIH4gNjAga0IsIEVBUC1UTFMgYXV0aGVudGljYXRpb24gY2Fubm90IGNv bXBsZXRlDQo+PiAgIHN1Y2Nlc3NmdWxseSBpbiBtb3N0IGRlcGxveW1lbnRzLg0KPiBSZWdhcmRp bmcgdGhlIDYwIGtCIGNlcnRpZmljYXRlIGNoYWluOiBTaG91bGQgdGhpcyBiZSBhbiBpbmRpY2F0 aW9uIHRvDQo+IHNvbWVvbmUgZGVwbG95aW5nIHRoZSB0ZWNobm9sb2d5IGZvciBhY2Nlc3MgbmV0 d29yayBhdXRoZW50aWNhdGlvbiB0aGF0IHNvbWV0aGluZyBoYXMgZ29uZSB3cm9uZz8NCj4NCj4g SXMgdGhpcyBzb21lb25lIHlvdSBoYXZlIG9ic2VydmVkIG9yIGlzIHRoaXMganVzdCBhIHRoZW9y ZXRpY2FsIHN0YXRlbWVudD8gSSBob3BlIGl0IGlzIHRoZSBsYXR0ZXIuDQo+DQo+DQo+IDQuMi4x LiAgUHJlLWRpc3RyaWJ1dGluZyBhbmQgT21pdHRpbmcgQ0EgQ2VydGlmaWNhdGVzDQo+DQo+DQo+ PiBXaGVuIHVzaW5nIFRMUyAxLjMsIGFsbCBjZXJ0aWZpY2F0ZXMgdGhhdCBzcGVjaWZ5IGEgdHJ1 c3QgYW5jaG9yDQo+PiBrbm93biBieSB0aGUgb3RoZXIgZW5kcG9pbnQgbWF5IGJlIG9taXR0ZWQg KHNlZSBTZWN0aW9uIDQuNC4yIG9mDQo+PiBbUkZDODQ0Nl0pLiAgV2hlbiB1c2luZyBUTFMgMS4y IG9yIGVhcmxpZXIsIG9ubHkgdGhlIHNlbGYtc2lnbmVkDQo+PiBjZXJ0aWZpY2F0ZSB0aGF0IHNw ZWNpZmllcyB0aGUgcm9vdCBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkgbWF5IGJlDQo+PiBvbWl0dGVk IChzZWUgU2VjdGlvbiA3LjQuMiBvZiBbUkZDNTI0Nl0NCj4gVGhlc2Ugc2VudGVuY2VzIHNvdW5k IHN0cmFuZ2UuDQo+DQo+IEluIFRMUyAoYW5kIHByb2JhYmx5IG90aGVyIHByb3RvY29scykgaXQg bWFrZXMgbm8gc2Vuc2UgdG8gZGlzdHJpYnV0ZQ0KPiB0aGUgdHJ1c3QgYW5jaG9ycyBpbiB0aGUg cHJvdG9jb2wgaXRzZWxmIChiZWNhdXNlIHRoZW4gdGhleSB3b3VsZG4ndA0KPiBzZXJ2ZSBhcyBh biBhbmNob3IgZm9yIHRydXN0KS4NCj4NCj4gSXQgaXMgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRo ZSBUTFMgMS4zIHNwZWMgZG9lcyBub3QgcmVxdWlyZSB5b3UgdG8NCj4gc2VuZCBpbnRlcm1lZGlh dGUgQ0EgY2VydGlmaWNhdGVzIGlmIHRoZXkgaGF2ZSBiZWVuIHByb3Zpc2lvbmVkIHRvIHRoZQ0K PiBwZWVyIG91dC1vZi1iYW5kIGFscmVhZHkuIFRoZSB0ZXh0IGluIHRoZSBUTFMgMS4yIHNwZWMg aXMgYSBiaXQgZnV6enkNCj4gYW5kIGNhbGxzIG91dCB0aGF0IHRoZSBzZWxmLXNpZ25lZCByb290 IGNlcnRpZmljYXRlIE1BWSBiZSBvbWl0dGVkIGJ1dA0KPiBpdCBkb2VzIG5vdCBzYXkgYW55dGhp bmcgYWJvdXQgb21pdHRpbmcgdGhlIG90aGVyIGNlcnRzLg0KUkZDODQ0NiBzYXlzIGluIFNlY3Rp b24gNC40LjIgImEgY2VydGlmaWNhdGUgdGhhdCBzcGVjaWZpZXMgYSB0cnVzdCBhbmNob3IgTUFZ IGJlIG9taXR0ZWQgZnJvbSB0aGUgY2hhaW4sIHByb3ZpZGVkIHRoYXQgc3VwcG9ydGVkIHBlZXJz IGFyZSBrbm93biB0byBwb3NzZXNzIGFueSBvbWl0dGVkIGNlcnRpZmljYXRlcy4iLiBXZSB3cml0 ZSAiYWxsIGNlcnRpZmljYXRlcyB0aGF0IHNwZWNpZnkgYSB0cnVzdCBhbmNob3Iga25vd24gYnkg dGhlIG90aGVyIGVuZHBvaW50IG1heSBiZSBvbWl0dGVkIi4NClBsZWFzZSBsZXQgdXMga25vdyBp ZiB5b3UgaGF2ZSBzdWdnZXN0aW9ucyBmb3IgaW1wcm92aW5nIHRoZSB0ZXh0Lg0KPg0KPj4gNC4y LjIuICBDYWNoaW5nIENlcnRpZmljYXRlcw0KPiBUaGVyZSBzZWVtcyB0byBiZSB0aGUgbWlzY29u Y2VwdGlvbiB0aGF0IFRMUyBDYWNoZWQgSW5mbyByZXF1aXJlcyBhIGZ1bGwgZXhjaGFuZ2UgdG8g d29yay4NCj4gSXQgaXMgdGhlIG90aGVyIHdheSBhcm91bmQ6ICBJZiB5b3UgcHJlLWRpc3RyaWJ1 dGUgY2VydGlmaWNhdGVzDQo+IHVwZnJvbnQgdGhlbiB0aGVyZSBpcyBubyBuZWVkIHRvIGV4Y2hh bmdlIHRoZSBjZXJ0cyBhZ2Fpbi4gWW91IGNvdWxkIGp1c3Qgc2VuZCB0aGUgZmluZ2VycHJpbnRz IHJpZ2h0IGF3YXkuDQo+DQo+IEEgc3BlYywgaG93ZXZlciwgaGFzIHRvIGFsc28gY292ZXIgdGhl IGJvb3RzdHJhcHBpbmcgcHJvYmxlbS4NCg0KV2hlcmUgZG9lcyBSRkMgNzkyNCBzYXkgdGhpcz8g VGhlIHRleHQgaW4gdGhlIFJGQyBjbGVhcmx5IHN0YXRlcyB0aGF0Og0KIlRoaXMgc3BlY2lmaWNh dGlvbiBkZWZpbmVzIGEgVExTIGV4dGVuc2lvbiB0aGF0IGFsbG93cyBhIGNsaWVudCBhbmQgYSBz ZXJ2ZXIgdG8gZXhjbHVkZSB0cmFuc21pc3Npb24gaW5mb3JtYXRpb24gY2FjaGVkIGluIGFuIGVh cmxpZXIgVExTIGhhbmRzaGFrZS4iLiBOb3RpY2UgdGhlICJlYXJsaWVyIFRMUyBoYW5kc2hha2Ui IHBhcnQuIFdlIGRpc2N1c3NlZCBhdCBJRVRGIDEwMiB3aGV0aGVyIHdlIGFsbG93IGNhY2hpbmcg b2YgdmFsaWRhdGVkIGNlcnRpZmljYXRlIGNoYWluIGV2ZW4gaWYgRUFQLVRMUyBhdXRoZW50aWNh dGlvbiBmYWlscy4gU2VlIHNsaWRlIDU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvMTAyL21hdGVyaWFscy9zbGlkZXMtMTAyLWVtdS1sYXJnZS1jZXJ0aWZpY2F0ZXMtaW4t ZWFwLXRscy0wMC4NClRoZSBjb25zZW5zdXMgd2FzIG5vdCB0byBkbyB0aGF0Lg0KDQo+DQo+PiA0 LjIuNS4gIFVzaW5nIEZld2VyIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZXMNCj4+ICAgIFRoZSBF QVAgcGVlciBjZXJ0aWZpY2F0ZSBjaGFpbiBkb2VzIG5vdCBoYXZlIHRvIG1pcnJvciB0aGUNCj4+ ICAgIG9yZ2FuaXphdGlvbmFsIGhpZXJhcmNoeS4gIEZvciBzdWNjZXNzZnVsIEVBUC1UTFMgYXV0 aGVudGljYXRpb24sDQo+PiAgICBjZXJ0aWZpY2F0ZSBjaGFpbnMgc2hvdWxkIG5vdCBjb250YWlu IG1vcmUgdGhhbiAyLTQgaW50ZXJtZWRpYXRlDQo+PiAgICBjZXJ0aWZpY2F0ZXMuDQo+IEkgd291 bGQgbWFrZSBhIHN0cm9uZ2VyIHN0YXRlbWVudCBoZXJlLiBUaGVyZSBpcyBhYnNvbHV0ZWx5IG5v IHJlYXNvbg0KPiBmb3IgdGhlIGNlcnRpZmljYXRlIGNoYWluIHRvIG1pcnJvciB0aGUgb3JnYW5p emF0aW9uYWwgc3RydWN0dXJlLg0KPg0KPiBJIGFsc28gZG9uJ3QgdW5kZXJzdGFuZCB3aHkgeW91 IHdvdWxkIG5lZWQgYSBoaWVyYXJjaHkgb2YgNCBpbnRlcm1lZGlhdGUgQ0FzLg0KPg0KPiBGaW5h bGx5LCBhdCB0aGUgZW5kOiBXaHkgZGlkIHlvdSBvbWl0DQo+IC0gQ2xpZW50IENlcnRpZmljYXRl IFVSTHMgLSBSRkMgNjA2NiksIHdoaWNoIGlzIGFsc28gcmVmZXJlbmNlZCBpbiBSRkMNCj4gNzky NSBhbmQNCj4gLSBjVExTICh3aGljaCBhbHNvIGhhcyBhIGNlcnRpZmljYXRlIGNvbXByZXNzaW9u IHNjaGVtZSBpbmNsdWRlZCkuDQpBZGRlZCBhIHNlY3Rpb24gb24gYm90aC4gV2hpbGUgSSB3YXMg YXdhcmUgb2YgdGhlIGNUTFMgd29yaywgSSBoYWQgY29tcGxldGVseSBtaXNzZWQgUkZDNjA2Ni4g UmV2aWV3cyBmcm9tIGV4cGVyaWVuY2VkIHBlb3BsZSBsaWtlIHlvdSBlbnN1cmUgdGhhdCB3ZSBk b24ndCBtaXNzIGltcG9ydGFudCBleGlzdGluZyB3b3JrLg0KPg0KPiBUaGVvcmV0aWNhbGx5LCB5 b3UgY291bGQgZXZlbiBsaXN0IHRoZSBhYmlsaXR5IHRvIHVzZSBhbHRlcm5hdGl2ZSBjZXJ0aWZp Y2F0ZSBmb3JtYXQgaGVyZS4gVGhlbiwgeW91IGNvdWxkIGxpc3QgcmF3IHB1YmxpYyBrZXlzIG9y IHRoZSBDV1QgZXh0ZW5zaW9uLg0KSSB0aGluayB0aXQgaXMgYmV0dGVyIHRvIGxlYXZlIHRoZXNl IGZvciBhIHNlcGFyYXRlIGRvY3VtZW50Lg0KPg0KPiBDaWFvDQo+IEhhbm5lcw0KPg0KPiBQUzog SXQgaXMgZ29vZCB0byBzZWUgSm9obidzIG5hbWUgb24gYSBkb2N1bWVudCB0aGF0IHRhbGtzIGFi b3V0IFRMUy4NCg0KSGUgaXMgYWxzbyBhbiBhdXRob3Igb2YgRUFQLVRMUzEzIGFuZCBFQVAtVExT LVBTSy4gSSBjZXJ0YWlubHkgaG9wZSB0aGF0IHRoZSBiYXR0bGVzIGZvciBhIGxpZ2h0d2VpZ2h0 IGF1dGhlbnRpY2F0ZWQga2V5IGV4Y2hhbmdlIChsYWtlKSBzdGF5IHRoZXJlIGFuZCBkb24ndCBh ZmZlY3QgdGhlIHdvcmsgb2Ygb3RoZXIgZ3JvdXBzLg0KDQotLU1vaGl0DQoNCj4gSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFbXUgbWFpbGluZyBsaXN0DQo+IEVtdUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0KSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Mon Jun 8 07:03:05 2020 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 710DD3A0ACE; Mon, 8 Jun 2020 07:03:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <159162498337.29675.8088537802846580802@ietfa.amsl.com> Date: Mon, 08 Jun 2020 07:03:03 -0700 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eaptlscert-04.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: Mon, 08 Jun 2020 14:03:04 -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 : Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods Authors : Mohit Sethi John Mattsson Sean Turner Filename : draft-ietf-emu-eaptlscert-04.txt Pages : 13 Date : 2020-06-08 Abstract: EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round-trips is a major deployment problem. This document looks at the this problem in detail and describes the potential solutions available. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-eaptlscert-04 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-04 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 Mon Jun 8 07:13:54 2020 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 403573A0B42 for ; Mon, 8 Jun 2020 07:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 bUGG7-8V0z0L for ; Mon, 8 Jun 2020 07:13:45 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2052.outbound.protection.outlook.com [40.107.21.52]) (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 B4D2A3A0B32 for ; Mon, 8 Jun 2020 07:13:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LY9428F/LqlQ5MuZeDpGB0zR5NkmVG//lEfJd/2SJJXf+nSZLzPqtM6z9sENlWym2jVBeCzu9B5VxeN6J7N0RS/g/7Vu3+UKypuNErek1oZdrcPZEbUf91LgZ/LsXC8OkcnUqDILZZtxr294ARepvrnAa5fCQjzQ67kXA411skGBa7c756ZJH6Nn9c4Aah5R/j6X6gjrXu5p4EYv4HCmZTHWlcES7NQeRgABLafMCMhvJ79w6u02w8bhZyUqRnoDGBmFwbsciIrpRVZ5Pss/Rk2V00Hb+V+t7VnaVF6dqwNwcs74RPuiqb7goeLNaoCf5ThrugEOOgdxnkH/TDmH4w== 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=5MTKaR9rq77zMOlCYDM5oG88SeHQt0yntdd4DD2/TU0=; b=RWTif6Yhb1PoeCTu7tKeeGXJvYSu0u5mwF1ejM4pjBSq+bpsy6OL/godmGVaHV4+RjZSEWdxzzRAE18fqUlBSX22pP3tun7SxmifcgyI49how1cCdW1HR+dKi7Ff1DvggDemEpwRvXyOLMGSo0J+EDAI40uT2ovS87exenE+em7dEhQu87GB+Cw0heEc/587ly3RqvtWuf2+8jUf6pii1sJe0M0Nh4OnWBD2UqC7CveG/MdJg4Sl96+X1CuPbulQjQEv7j+YbwvBtykm59sYBKgz/N5y/WGYZA5/QyDLGFjirhvAaqDkW7a7Iy9v+iyXwROLuzXdHzSx9mB0Mhm67w== 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=5MTKaR9rq77zMOlCYDM5oG88SeHQt0yntdd4DD2/TU0=; b=TrK0tmy7Ds8LFVwHsI4mAjDqXxtFMqii7NQkgHDtsovq0rcERdzFAglAEfks7nDXaw/z1zA0pYcElgT8Io+8wqM80aagXiCYhiTgBzylZZB3sxB8MM35PFqHG68z77iUL0yf54YgK0Z0sZ9lFUfUUzZIRlQNLsUmvv040nl5GRI= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR0701MB2140.eurprd07.prod.outlook.com (2603:10a6:3:2a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.13; Mon, 8 Jun 2020 14:13:40 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e%7]) with mapi id 15.20.3088.016; Mon, 8 Jun 2020 14:13:40 +0000 From: Mohit Sethi M To: Hannes Tschofenig , Mohit Sethi M , Michael Richardson , "emu@ietf.org" Thread-Topic: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt Thread-Index: AQHWJd6sewrKoRh7dEOMQf3xkb8SvKjO0l4AgAAf54A= Date: Mon, 8 Jun 2020 14:13:40 +0000 Message-ID: References: <0c843ca8-8bfc-8bf6-2cb2-a8517359842f@ericsson.com> 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.7.0 authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:150:4228:c90b:d9d5:6512:359a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f8cba086-4f9b-4db3-71a8-08d80bb62521 x-ms-traffictypediagnostic: HE1PR0701MB2140: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 042857DBB5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2rM2bF5XjeA1sp2pc+m4OUNrU6n6P4n3Vq2QEs0TL+9QdRR3tizIWDxEgDlwb9pJ5j64Sy5Y+Cg7yvJJdUjvOaLYoSTD5SEY6F9b8SldzBgvTkJOcgWQcLD4b81iONrBrIifcnRe7M4JsjRXZX34tIMfsmcAhK1D/bnLhik1hASnPfWSAI2A8wlOGnCur8sKfQCCgLls3g5SOO6x+H/IZofDhjEEHFaaGZ0mnhkpfyLAO5c4XsViCgCC+2oBn36L6+7EzD/3aVGKkpQtF4dKVx1kyc4XSibk+ZZDEylqHEgDe2tsM2zn35Q9U1odzCGvil5kKgVwTbz6ZTI0GxkBwM1Hz367bMy9ZpAQGD5sF1XqdR2onTbIf1Zp7q4xDa6njwu60nmjKPdjMe3KNxZ5ez50/lGitvCM2aq3kqxMYllD+75MTLBxLFVkYBWTX+eG7iFW2pLcRDIw5bpet8cObw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(6486002)(86362001)(6512007)(31686004)(110136005)(83380400001)(31696002)(316002)(2616005)(36756003)(71200400001)(30864003)(66446008)(66556008)(66476007)(64756008)(76116006)(66946007)(53546011)(5660300002)(6506007)(8936002)(966005)(8676002)(478600001)(186003)(2906002)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xg2IkTBPcMmrBaBbWH6VsQMqbbAgOPyJs8deQWBZMNA47FNlFrJ3gh90q31aa7pjsn+tJNiuzTMR4ZJ+byLI0U1Z/dKH9NMR6DYgceWvCCOAfj16vUg475TaaOuJZdANQ43Sn5V0yqwOUMyhzwlI9iiZR5sJkO2tPjTms8X6xk7IDxGB6ZzNmrMPrw+KU02fRMtv38T4AjYjixafH4RSn0m9/t3uDXFi3CDJGFLlaH4qukgBpX9VdbX9loL5JBl0KXjpdQ/Ys2V67puXPbf7JoE+WcYvhjvKbMGLo4ECdcY4y2kcaYHhOAKuIzdnScLMVkZHjD81sF8LBF4M2jpxgOjyYL+y9dtoHI1r4VZ8RYE5AV/uzFzDViht2UPozJPhhMsIUSQm1Ct5d7y3JpQ2LeQq/Kund+6iV+D43fCNaw7mAPqkYjxPncmEwSIB1RYJy0Vx/Xh6iukigNI/C6BG1PdN+WbI3JSA2SqP44MQEhm8no4leM2LA/0QVTQ9bg4qZdskIWT8uYItSQylqs/WgVnQrL9RiU8hA19n7gDNr8rl8wtBd11ev0WZasGEMrp2 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f8cba086-4f9b-4db3-71a8-08d80bb62521 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 14:13:40.6058 (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: Oq22CVSI/+GxD4VOpldphkN2ZZN1KIWH9Yxi2JtFXn+zgCuuCHyjhJu4Utciwx8pFJmrzMTFJfKJjzmDzu5BSJ2HTsBitdFSB/GIywKF+bY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2140 Archived-At: Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.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: Mon, 08 Jun 2020 14:13:52 -0000 SGkgSGFubmVzLA0KDQpUaGFua3MgZm9yIHRoZSBmb2xsb3cgdXAuIEkgaGF2ZSBzdWJtaXR0ZWQg YSBuZXcgdmVyc2lvbiB3aGljaCBzaG91bGQgDQphZGRyZXNzIHlvdXIgY29uY2VybnMuIEhlcmUg aXMgYSBkaWZmIGZvciB5b3VyIGNvbnZlbmllbmNlOiANCmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWVtdS1lYXB0bHNjZXJ0LTA0DQoNClBsZWFzZSBzZWUgaW4t bGluZSBmb3Igc29tZSBkZXRhaWxzLg0KDQotLU1vaGl0DQoNCk9uIDYvOC8yMCAzOjE5IFBNLCBI YW5uZXMgVHNjaG9mZW5pZyB3cm90ZToNCj4gVGhhbmtzIGZvciB0aGUgdXBkYXRlLCBNb2hpdC4N Cj4NCj4gQSBmZXcgbWlub3IgcmVtYXJrczoNCj4NCj4gRlJPTToNCj4NCj4gIg0KPiAgICAgVExT IGNlcnRpZmljYXRlcyBpbiBFQVAgZGVwbG95bWVudHMgY2FuIGJlIHJlbGF0aXZlbHkgbGFyZ2Us IGFuZCB0aGUNCj4gICAgIGNlcnRpZmljYXRlIGNoYWlucyBjYW4gYmUgbG9uZy4NCj4gIg0KPg0K PiBUTzoNCj4NCj4gIg0KPiAgICAgQ2VydGlmaWNhdGVzIGluIEVBUCBkZXBsb3ltZW50cyBjYW4g YmUgcmVsYXRpdmVseSBsYXJnZSwgYW5kIHRoZQ0KPiAgICAgY2VydGlmaWNhdGUgY2hhaW5zIGNh biBiZSBsb25nLg0KPiAiDQpEb25lIQ0KPg0KPiBSZWFzb246IENlcnRpZmljYXRlcyBhcmUgbGFy Z2UgYW5kIHRoZXJlIGlzIG5vdGhpbmcgaW4gVExTIHRoYXQgY29udHJpYnV0ZXMgdG8gdGhlIHNp emUuDQo+DQo+IEluIFNlY3Rpb24gNCBJIHdvdWxkIHN0YXRlIHRoZSBvYnZpb3VzIHRvIHRoZSBy ZWFkZXI6IEtlZXAgdGhlIGNlcnRpZmljYXRlIHNpemUgc21hbGwgYnkgbm90IHN0dWZmaW5nIGxv dHMgb2YgZmllbGRzIGluIGl0IGFuZCBrZWVwIHRoZSBjaGFpbiBzaG9ydC4NCj4gQSBjb21tb24g cmVhc29uIHdoeSB0aGVzZSBjZXJ0cyBhcmUgbG9uZyBpcyBiZWNhdXNlIGRldmVsb3BlcnMgZG9u J3QgdW5kZXJzdGFuZCB0aGF0IHRoZXkgZG8gbm90IG5lZWQgdG8gbWFwIHRoZSBvcmdhbml6YXRp b25hbCBoaWVyYXJjaHkgdG8gYSBDQSBoaWVyYXJjaHkuDQo+IFRoaXMgaXMgdGhlIHNpbXBsZXN0 IGFwcHJvYWNoIHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiBjZXJ0aWZpY2F0ZXMgc2VudCBvdmVyIHRo ZSB3aXJlLg0KSSBhZGRlZCBhIHNlbnRlbmNlICJUaGUgZ2VuZXJhbCBndWlkZWxpbmUgb2Yga2Vl cGluZyB0aGUgY2VydGlmaWNhdGUgDQpzaXplIHNtYWxsIGJ5IG5vdCBwb3B1bGF0aW5nIGZpZWxk cyB3aXRoIGV4Y2Vzc2l2ZSBpbmZvcm1hdGlvbiBjYW4gaGVscCANCmF2ZXJ0IHRoZSBwcm9ibGVt cyBvZiBmYWlsZWQgRUFQLVRMUyBhdXRoZW50aWNhdGlvbi4iLiBZb3VyIGNvbW1lbnQgb24gDQp0 aGUgbmVlZGxlc3MgbWFwcGluZyBvZiB0aGUgb3JnYW5pemF0aW9uYWwgaGllcmFyY2h5IHRvIHRo ZSBDQSBoaWVyYXJjaHkgDQppcyBhbHJlYWR5IGNvdmVyZWQgaW4gc2VjdGlvbiA0LjIuNy4NCj4N Cj4gUmVnYXJkaW5nIDQuMi4zLiAgQ29tcGFjdCBUTFMgMS4zDQo+DQo+ICAgICBbSS1ELmlldGYt dGxzLWN0bHNdIGRlZmluZXMgYSAiY29tcGFjdCIgdmVyc2lvbiBvZiBUTFMgMS4zIGFuZA0KPiAg ICAgcmVkdWNlcyB0aGUgbWVzc2FnZSBzaXplIG9mIHRoZSBwcm90b2NvbCBieSByZW1vdmluZyBv YnNvbGV0ZQ0KPiAgICAgbWF0ZXJpYWwgYW5kIHVzaW5nIG1vcmUgZWZmaWNpZW50IGVuY29kaW5n LiAgVGhpcyBuYXR1cmFsbHkgbWVhbnMNCj4gICAgIHRoYXQgY1RMUyBpcyBub3QgaW50ZXJvcGVy YWJsZSB3aXRoIHByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBUTFMNCj4gICAgIHByb3RvY29sLiAg SXQgYWxzbyBkZWZpbmVzIGEgY29tcHJlc3Npb24gcHJvZmlsZSB3aXRoIHdoaWNoIGVpdGhlcg0K PiAgICAgc2lkZSBjYW4gZGVmaW5lIGRpY3Rpb25hcnkgb2YgImtub3duIGNlcnRpZmljYXRlcyIu ICBUaHVzLCBjVExTIGNhbg0KPiAgICAgcHJvdmlkZSBhbm90aGVyIG1lY2hhbmlzbSBmb3IgRUFQ LVRMUyBkZXBsb3ltZW50cyB0byByZWR1Y2UgdGhlIHNpemUNCj4gICAgIG9mIG1lc3NhZ2VzIGFu ZCBhdm9pZCBleGNlc3NpdmUgZnJhZ21lbnRhdGlvbi4NCj4NCj4gVGhlIHBvaW50IGZvciBtZW50 aW9uaW5nIGNUTFMgd2FzIHJlbGF0ZWQgdG8gdGhlIGNlcnRpZmljYXRlIGNvbXByZXNzaW9uLiBJ IHdvdWxkIHRoZXJlZm9yZSBjaGFuZ2UgdGhlIHBhcmFncmFwaCB0bzoNCj4NCj4gNC4yLjMuICBD b21wYWN0IFRMUyAxLjMNCj4NCj4gICAgIFtJLUQuaWV0Zi10bHMtY3Rsc10gZGVmaW5lcyBhICJj b21wYWN0IiB2ZXJzaW9uIG9mIFRMUyAxLjMgYW5kDQo+ICAgICByZWR1Y2VzIHRoZSBtZXNzYWdl IHNpemUgb2YgdGhlIHByb3RvY29sIGJ5IHJlbW92aW5nIG9ic29sZXRlDQo+ICAgICBtYXRlcmlh bCBhbmQgdXNpbmcgbW9yZSBlZmZpY2llbnQgZW5jb2RpbmcuICBJdCBhbHNvIGRlZmluZXMgYQ0K PiAgICAgY29tcHJlc3Npb24gcHJvZmlsZSB3aXRoIHdoaWNoIGVpdGhlciAgc2lkZSBjYW4gZGVm aW5lIGRpY3Rpb25hcnkNCj4gICAgIG9mICJrbm93biBjZXJ0aWZpY2F0ZXMiLg0KSSBoYXZlbid0 IGNoYW5nZWQgdGhlIHBhcmFncmFwaC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gbGV0IHRo ZSANCnJlYWRlciBrbm93IHRoYXQgY1RMUyBpcyBub3QgaW50ZXJvcGVyYWJsZSB3aXRoIHByZXZp b3VzIHZlcnNpb25zIFRMUy4gDQpTbyB1cGRhdGluZyB0aGUgcGVlciBpbXBsZW1lbnRhdGlvbiB3 aXRob3V0IHVwZGF0aW5nIHRoZSBzZXJ2ZXIgDQppbXBsZW1lbnRhdGlvbiB3b3VsZCBub3QgaGVs cC4NCj4NCj4gSSB3b25kZXIgd2hldGhlciB5b3Ugd2FudCB0byBtZW50aW9uIGFsc28gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctdGxzLWN3dC0wMSBhbmQgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29t cHJlc3MtMDA/DQo+IFNpbmNlIHRob3NlIGFyZSBzdGlsbCBpbmRpdmlkdWFsIGRyYWZ0cyB5b3Ug Y291bGQgcG9pbnQgb3V0IHRoYXQgdGhvc2UgYXJlIHdvcmsgaW4gcHJvZ3Jlc3MuDQpJIHdhcyBh IGJpdCBoZXNpdGFudCB0byBhZGQgdGhlc2Ugc2luY2UgdGhleSBhcmUgc3RpbGwgaW4gZWFybHkg cGhhc2VzIA0Kb2YgZGV2ZWxvcG1lbnQuIEhvd2V2ZXIsIEkgaGF2ZSBub3cgYWRkZWQgYSBzZWN0 aW9uIHRpdGxlZCAiTmV3IA0KQ2VydGlmaWNhdGUgVHlwZXMgYW5kIENvbXByZXNzaW9uIEFsZ29y aXRobXMiLiBIb3BlIHRoaXMgaXMgc3VmZmljaWVudC4NCj4NCj4gQ2lhbw0KPiBIYW5uZXMNCj4N Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTW9oaXQgU2V0aGkgTSA8bW9o aXQubS5zZXRoaUBlcmljc3Nvbi5jb20+DQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXkgOSwgMjAyMCAx MDo0OSBBTQ0KPiBUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b20+OyBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IGVtdUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW0VtdV0gTXkgcmV2aWV3IC4uLiB3YXMgUkU6IEktRCBBY3Rp b246IGRyYWZ0LWlldGYtZW11LWVhcHRsc2NlcnQtMDIudHh0DQo+DQo+IEhpIEhhbm5lcywNCj4N Cj4gSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aGljaCBJIGJl bGlldmUgYWRkcmVzc2VzIHlvdXIgY29uY2VybnMuIEhlcmUgaXMgYSBkaWZmIGZvciB5b3VyIGNv bnZlbmllbmNlOg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1lbXUtZWFwdGxzY2VydC0wMw0KPg0KPiBXaGlsZSBBbGFuIGFuZCBKb3VuaSBoYXZlIGFscmVh ZHkgcHJvdmlkZWQgZXhjZWxsZW50IGFuc3dlcnMgdG8gbW9zdCBvZiB5b3VyIGNvbW1lbnRzLCBp bi1saW5lIHlvdSBjYW4gZmluZCBhIGZldyBtb3JlIGNsYXJpZmljYXRpb25zIGZvciB0aGUgY2hh bmdlcyBJIG1hZGUuDQo+DQo+IC0tTW9oaXQNCj4NCj4gT24gMy8yNC8yMCAxMDowMCBBTSwgSGFu bmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+PiBIaSBNaWNoYWVsLCBIaSBkcmFmdCBhdXRob3JzLA0K Pj4NCj4+PiBJIHdhcyBzdXJwcmlzZWQgdG8gZ2V0IHRvIHRoZSBlbmQgb2YgdGhlIGRvY3VtZW50 IHdpdGhvdXQgYW55IHN1Z2dlc3Rpb25zIGFib3V0IHNlbmRpbmcgY2VydGlmaWNhdGVzIGJ5IHJl ZmVyZW5jZSByYXRoZXIgdGhhbiB2YWx1ZS4NCj4+IEhhdmluZyBzZWVuIHRoaXMgc3RhdGVtZW50 IGZyb20gTWljaGFlbCBJIGhhdmUgcmV2aWV3ZWQgdGhlIGRvY3VtZW50LiBUd28gZ2VuZXJpYyBv YnNlcnZhdGlvbnMgYWJvdXQgdGhlIGRyYWZ0Og0KPj4NCj4+IDEpIE1hbnkgc3RhdGVtZW50cyBh cmUgbWFkZSBhYm91dCBkZXBsb3ltZW50cyBhbmQgbm8gcmVmZXJlbmNlcyBhcmUgcHJvdmlkZWQu IFRvIGltcHJvdmUgcXVhbGl0eSBvZiB0aGUgd3JpdGUtdXAgSSB3b3VsZCBzdHJvbmdseSBzdWdn ZXN0IHRvIGFkZCBzdWNoIHJlZmVyZW5jZXMsIGFzIHlvdSB3b3VsZCBoYXZlIHRvIGRvIHdpdGgg YW4gYWNhZGVtaWMgcHVibGljYXRpb24gYXMgd2VsbC4NCj4+DQo+PiAyKSBBIGZldyB0ZWNobmlx dWVzIGFyZSBtaXNzaW5nIChDZXJ0aWZpY2F0ZSBVUkxzIGFuZCBjVExTKSBhbmQgVExTIENhY2hl ZCBJbmZvIHdhcyB3cm9uZ2x5IGludGVycHJldGVkLiAgVGhleSBhY3R1YWxseSByZWxhdGUgdG8g dGhlIHJlbWFyayBmcm9tIE1pY2hhZWwuDQo+Pg0KPj4+IFRMUyBjZXJ0aWZpY2F0ZXMgYXJlIG9m dGVuIHJlbGF0aXZlbHkgbGFyZ2UsIGFuZCB0aGUgY2VydGlmaWNhdGUNCj4+PiAgICAgY2hhaW5z IGFyZSBvZnRlbiBsb25nLg0KPj4gSSB0aGluayB0aGlzIHN0YXRlbWVudCBpcyBpbiBnZW5lcmFs IGluY29ycmVjdC4gWW91IGNvdWxkIHNheSB0aGF0IGluIGRlcGxveW1lbnQgWCBjZXJ0aWZpY2F0 ZXMgaGF2ZSBzaXplIFggYW5kIHRoZSBjaGFpbiBpcyBZIGxvbmcuDQo+Pg0KPj4NCj4+PiBBbHNv LA0KPj4+ICAgIGZyb20gZGVwbG95bWVudCBleHBlcmllbmNlLCBFQVAgcGVlcnMgdHlwaWNhbGx5 IGhhdmUgbG9uZ2VyDQo+Pj4gICAgIGNlcnRpZmljYXRlIGNoYWlucyB0aGFuIHNlcnZlcnMuDQo+ PiBJIHdvdWxkIGxpa2UgYSByZWZlcmVuY2UgdG8gYmUgaW5jbHVkZWQgaGVyZS4gVGhlb3JldGlj YWxseSwgaXQgbWFrZXMNCj4+IG5vIHNlbnNlIHRvIGhhdmUgYSBjZXJ0aWZpY2F0ZSBjaGFpbiBm b3IgYW4gRUFQIHBlZXIgdG8gaGF2ZSBhIGxvbmdlcg0KPj4gY2VydGlmaWNhdGUgY2hhaW4gdGhh biBhIHNlcnZlciBnaXZlbiBhIEVBUCBwZWVyIHRhbGtzIHRvIG9uZSBFQVAgc2VydmVyLg0KPj4N Cj4+IEluIG5ldHdvcmsgYWNjZXNzIGF1dGhlbnRpY2F0aW9uIGl0IGlzIG5vdCBvbmx5IGFib3V0 IGF1dGhlbnRpY2F0aW9uIGJ1dCB0aGUgbW9zdCBpbXBvcnRhbnQgcGFydCBpcyBhdXRob3JpemF0 aW9uLiBIZW5jZSwgeW91IHByZXR0eSBtdWNoIGFsd2F5cyBoYXZlIGEgb25lLXRvLW9uZSByZWxh dGlvbnNoaXAgYmV0d2VlbiB0aGUgRUFQIHBlZXIgYW5kIHRoZSBFQVAgc2VydmVyLiBUaGVyZSBh cmUgbm8gZ29vZCByZWFzb25zIHRvIGhhdmUgY29tcGxleCBDQSBoaWVyYXJjaGllcyBoZXJlLg0K Pj4NCj4+PiBUaGlzIGlzIGJlY2F1c2UgRUFQIHBlZXJzIG9mdGVuDQo+Pj4gICAgZm9sbG93IG9y Z2FuaXphdGlvbmFsIGhpZXJhcmNoaWVzIGFuZCB0ZW5kIHRvIGhhdmUgbWFueSBpbnRlcm1lZGlh dGUNCj4+PiAgICAgY2VydGlmaWNhdGVzLiAgVGh1cywgRUFQLVRMUyBhdXRoZW50aWNhdGlvbiB1 c3VhbGx5IGludm9sdmUNCj4+PiAgICAgc2lnbmlmaWNhbnRseSBtb3JlIG9jdGV0cyB0aGFuIHdo ZW4gVExTIGlzIHVzZWQgYXMgcGFydCBvZiBIVFRQUy4NCj4+IEkgdGhpbmsgaXQgd291bGQgbWFr ZSBzZW5zZSB0byBleHBsYWluIHRoaXMgb3JnYW5pemF0aW9uYWwgaGllcmFyY2h5DQo+PiBhc3Bl Y3QgaW4gYSBiaXQgbW9yZSBkZXRhaWwuDQo+Pg0KPj4+IFRoZSBFQVAgZnJhZ21lbnQgc2l6ZQ0K Pj4+ICAgIGluIHR5cGljYWwgZGVwbG95bWVudHMgaXMganVzdCAxMDIwIC0gMTUwMCBvY3RldHMu DQo+PiBSZWZlcmVuY2UgZm9yIHRoZSAxNTAwIG9jdGV0cy4NCj4gQWRkZWQgdGhhdCB0aGlzIGxp bWl0YXRpb24gY29tZSBmcm9tIEV0aGVybmV0IElJIGZyYW1lIHNpemUuDQo+Pg0KPj4+IEZvciBl eGFtcGxlLCBtYW55IEVBUCBhdXRoZW50aWNhdG9yIChhY2Nlc3MgcG9pbnQpDQo+Pj4gICAgaW1w bGVtZW50YXRpb25zIHdpbGwgZHJvcCBhbiBFQVAgc2Vzc2lvbiBpZiBpdCBoYXMgbm90IGZpbmlz aGVkIGFmdGVyDQo+Pj4gICAgIDQwIC0gNTAgcm91bmQtdHJpcHMuDQo+PiBJcyB0aGVyZSBhIHJl ZmVyZW5jZSB0aGF0IGNvdWxkIGJlIGluY2x1ZGVkPw0KPj4NCj4+PiBIb3dldmVyLCBkZXBsb3lt ZW50DQo+Pj4gICAgIGV4cGVyaWVuY2UgaGFzIHNob3duIHRoYXQgdGhlc2UganVtYm8gZnJhbWVz IGFyZSBub3QgYWx3YXlzDQo+Pj4gICAgaW1wbGVtZW50ZWQgY29ycmVjdGx5Lg0KPj4gQWRkIGEg cmVmZXJlbmNlIGhlcmUuDQo+Pg0KPj4+IFJBRElVUyBjYW4gZ2VuZXJhbGx5IHRyYW5zcG9ydCBv bmx5IGFib3V0IDQwMDANCj4+PiAgICBvY3RldHMgb2YgRUFQIGluIGEgc2luZ2xlIG1lc3NhZ2Uu DQo+PiBIb3cgd2FzIHRoaXMgbnVtYmVyIGNvbnN0cnVjdGVkPw0KPiBBZGRlZCB0aGF0IFJBRElV UyBSRkMyODY1IGxpbWl0cyBsZW5ndGggdG8gNDA5NiBvY3RldHMuDQo+Pj4gICAgIEEgY2VydGlm aWNhdGUgY2hhaW4gKGNhbGxlZCBhIGNlcnRpZmljYXRpb24gcGF0aCBpbiBbUkZDNTI4MF0pIGNh bg0KPj4+ICAgICBoYXZlIDIgLSA2IGludGVybWVkaWF0ZSBjZXJ0aWZpY2F0ZXMgYmV0d2VlbiB0 aGUgZW5kLWVudGl0eQ0KPj4+ICAgICBjZXJ0aWZpY2F0ZSBhbmQgdGhlIHRydXN0IGFuY2hvciBb UkZDNTI4MF0uDQo+PiBUaGUgUEtJWCByZWZlcmVuY2UgaGVyZSBpcyBtaXNsZWFkaW5nLiBJIHRo aW5rIHlvdSBpbmNsdWRlZCBpdCB0bw0KPj4gcmVmZXIgdG8gdGhlIHRlcm1zIGJ1dCBpdCBzb3Vu ZHMgbGlrZSB0aGUgc3RhdGVtZW50IHRoYXQgdGhlIGNoYWluIGNhbiBoYXZlIDItNiBpbnRlcm1l ZGlhdGUgQ0EgY2VydGlmaWNhdGVzLg0KPj4NCj4+IEkgd291bGQgYWRkIHRoZSB0ZXJtcyB0byB0 aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBhbmQgcmVtb3ZlIHRoZSBQS0lYIHJlZmVyZW5jZSBoZXJl Lg0KPiBEb25lLiBUaGFua3MuIEluZGVlZCB0aGF0IHdhcyBtaXNsZWFkaW5nLg0KPj4gSSBhbSBh bHNvIHdvbmRlcmluZyB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIHNheSBoZXJlIHdpdGggdGhpcw0K Pj4gc2VudGVuY2UuIEFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91IGhhdmUgc2VlbiBkZXBsb3ltZW50 cyBmb3IgbmV0d29yayBhY2Nlc3MgYXV0aGVudGljYXRpb24gdGhhdCBoYXZlIHVwIHRvIDYgaW50 ZXJtZWRpYXRlIENBIGNlcnRpZmljYXRlcyBpbiB0aGUgY2hhaW4/DQo+Pg0KPj4NCj4+PiAzLiAg RXhwZXJpZW5jZSB3aXRoIERlcGxveW1lbnRzDQo+Pj4gICAgIE1vc3QgY29tbW9uIGFjY2VzcyBw b2ludCBpbXBsZW1lbnRhdGlvbnMgZHJvcCBFQVAgc2Vzc2lvbnMgdGhhdCBkbw0KPj4+ICAgICBu b3QgY29tcGxldGUgd2l0aGluIDUwIHJvdW5kLXRyaXBzLg0KPj4gVGhpcyBzZW50ZW5jZSBpcyBh IHJlcGV0aXRpb24uDQo+Pg0KPj4+IFRoaXMgbWVhbnMgdGhhdCBpZiB0aGUgY2hhaW4gaXMNCj4+ PiAgICBsYXJnZXIgdGhhbiB+IDYwIGtCLCBFQVAtVExTIGF1dGhlbnRpY2F0aW9uIGNhbm5vdCBj b21wbGV0ZQ0KPj4+ICAgIHN1Y2Nlc3NmdWxseSBpbiBtb3N0IGRlcGxveW1lbnRzLg0KPj4gUmVn YXJkaW5nIHRoZSA2MCBrQiBjZXJ0aWZpY2F0ZSBjaGFpbjogU2hvdWxkIHRoaXMgYmUgYW4gaW5k aWNhdGlvbiB0bw0KPj4gc29tZW9uZSBkZXBsb3lpbmcgdGhlIHRlY2hub2xvZ3kgZm9yIGFjY2Vz cyBuZXR3b3JrIGF1dGhlbnRpY2F0aW9uIHRoYXQgc29tZXRoaW5nIGhhcyBnb25lIHdyb25nPw0K Pj4NCj4+IElzIHRoaXMgc29tZW9uZSB5b3UgaGF2ZSBvYnNlcnZlZCBvciBpcyB0aGlzIGp1c3Qg YSB0aGVvcmV0aWNhbCBzdGF0ZW1lbnQ/IEkgaG9wZSBpdCBpcyB0aGUgbGF0dGVyLg0KPj4NCj4+ DQo+PiA0LjIuMS4gIFByZS1kaXN0cmlidXRpbmcgYW5kIE9taXR0aW5nIENBIENlcnRpZmljYXRl cw0KPj4NCj4+DQo+Pj4gV2hlbiB1c2luZyBUTFMgMS4zLCBhbGwgY2VydGlmaWNhdGVzIHRoYXQg c3BlY2lmeSBhIHRydXN0IGFuY2hvcg0KPj4+IGtub3duIGJ5IHRoZSBvdGhlciBlbmRwb2ludCBt YXkgYmUgb21pdHRlZCAoc2VlIFNlY3Rpb24gNC40LjIgb2YNCj4+PiBbUkZDODQ0Nl0pLiAgV2hl biB1c2luZyBUTFMgMS4yIG9yIGVhcmxpZXIsIG9ubHkgdGhlIHNlbGYtc2lnbmVkDQo+Pj4gY2Vy dGlmaWNhdGUgdGhhdCBzcGVjaWZpZXMgdGhlIHJvb3QgY2VydGlmaWNhdGUgYXV0aG9yaXR5IG1h eSBiZQ0KPj4+IG9taXR0ZWQgKHNlZSBTZWN0aW9uIDcuNC4yIG9mIFtSRkM1MjQ2XQ0KPj4gVGhl c2Ugc2VudGVuY2VzIHNvdW5kIHN0cmFuZ2UuDQo+Pg0KPj4gSW4gVExTIChhbmQgcHJvYmFibHkg b3RoZXIgcHJvdG9jb2xzKSBpdCBtYWtlcyBubyBzZW5zZSB0byBkaXN0cmlidXRlDQo+PiB0aGUg dHJ1c3QgYW5jaG9ycyBpbiB0aGUgcHJvdG9jb2wgaXRzZWxmIChiZWNhdXNlIHRoZW4gdGhleSB3 b3VsZG4ndA0KPj4gc2VydmUgYXMgYW4gYW5jaG9yIGZvciB0cnVzdCkuDQo+Pg0KPj4gSXQgaXMg bXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBUTFMgMS4zIHNwZWMgZG9lcyBub3QgcmVxdWlyZSB5 b3UgdG8NCj4+IHNlbmQgaW50ZXJtZWRpYXRlIENBIGNlcnRpZmljYXRlcyBpZiB0aGV5IGhhdmUg YmVlbiBwcm92aXNpb25lZCB0byB0aGUNCj4+IHBlZXIgb3V0LW9mLWJhbmQgYWxyZWFkeS4gVGhl IHRleHQgaW4gdGhlIFRMUyAxLjIgc3BlYyBpcyBhIGJpdCBmdXp6eQ0KPj4gYW5kIGNhbGxzIG91 dCB0aGF0IHRoZSBzZWxmLXNpZ25lZCByb290IGNlcnRpZmljYXRlIE1BWSBiZSBvbWl0dGVkIGJ1 dA0KPj4gaXQgZG9lcyBub3Qgc2F5IGFueXRoaW5nIGFib3V0IG9taXR0aW5nIHRoZSBvdGhlciBj ZXJ0cy4NCj4gUkZDODQ0NiBzYXlzIGluIFNlY3Rpb24gNC40LjIgImEgY2VydGlmaWNhdGUgdGhh dCBzcGVjaWZpZXMgYSB0cnVzdCBhbmNob3IgTUFZIGJlIG9taXR0ZWQgZnJvbSB0aGUgY2hhaW4s IHByb3ZpZGVkIHRoYXQgc3VwcG9ydGVkIHBlZXJzIGFyZSBrbm93biB0byBwb3NzZXNzIGFueSBv bWl0dGVkIGNlcnRpZmljYXRlcy4iLiBXZSB3cml0ZSAiYWxsIGNlcnRpZmljYXRlcyB0aGF0IHNw ZWNpZnkgYSB0cnVzdCBhbmNob3Iga25vd24gYnkgdGhlIG90aGVyIGVuZHBvaW50IG1heSBiZSBv bWl0dGVkIi4NCj4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIHN1Z2dlc3Rpb25zIGZv ciBpbXByb3ZpbmcgdGhlIHRleHQuDQo+Pj4gNC4yLjIuICBDYWNoaW5nIENlcnRpZmljYXRlcw0K Pj4gVGhlcmUgc2VlbXMgdG8gYmUgdGhlIG1pc2NvbmNlcHRpb24gdGhhdCBUTFMgQ2FjaGVkIElu Zm8gcmVxdWlyZXMgYSBmdWxsIGV4Y2hhbmdlIHRvIHdvcmsuDQo+PiBJdCBpcyB0aGUgb3RoZXIg d2F5IGFyb3VuZDogIElmIHlvdSBwcmUtZGlzdHJpYnV0ZSBjZXJ0aWZpY2F0ZXMNCj4+IHVwZnJv bnQgdGhlbiB0aGVyZSBpcyBubyBuZWVkIHRvIGV4Y2hhbmdlIHRoZSBjZXJ0cyBhZ2Fpbi4gWW91 IGNvdWxkIGp1c3Qgc2VuZCB0aGUgZmluZ2VycHJpbnRzIHJpZ2h0IGF3YXkuDQo+Pg0KPj4gQSBz cGVjLCBob3dldmVyLCBoYXMgdG8gYWxzbyBjb3ZlciB0aGUgYm9vdHN0cmFwcGluZyBwcm9ibGVt Lg0KPiBXaGVyZSBkb2VzIFJGQyA3OTI0IHNheSB0aGlzPyBUaGUgdGV4dCBpbiB0aGUgUkZDIGNs ZWFybHkgc3RhdGVzIHRoYXQ6DQo+ICJUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIFRMUyBl eHRlbnNpb24gdGhhdCBhbGxvd3MgYSBjbGllbnQgYW5kIGEgc2VydmVyIHRvIGV4Y2x1ZGUgdHJh bnNtaXNzaW9uIGluZm9ybWF0aW9uIGNhY2hlZCBpbiBhbiBlYXJsaWVyIFRMUyBoYW5kc2hha2Uu Ii4gTm90aWNlIHRoZSAiZWFybGllciBUTFMgaGFuZHNoYWtlIiBwYXJ0LiBXZSBkaXNjdXNzZWQg YXQgSUVURiAxMDIgd2hldGhlciB3ZSBhbGxvdyBjYWNoaW5nIG9mIHZhbGlkYXRlZCBjZXJ0aWZp Y2F0ZSBjaGFpbiBldmVuIGlmIEVBUC1UTFMgYXV0aGVudGljYXRpb24gZmFpbHMuIFNlZSBzbGlk ZSA1Og0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAyL21hdGVyaWFs cy9zbGlkZXMtMTAyLWVtdS1sYXJnZS1jZXJ0aWZpY2F0ZXMtaW4tZWFwLXRscy0wMC4NCj4gVGhl IGNvbnNlbnN1cyB3YXMgbm90IHRvIGRvIHRoYXQuDQo+DQo+Pj4gNC4yLjUuICBVc2luZyBGZXdl ciBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGVzDQo+Pj4gICAgIFRoZSBFQVAgcGVlciBjZXJ0aWZp Y2F0ZSBjaGFpbiBkb2VzIG5vdCBoYXZlIHRvIG1pcnJvciB0aGUNCj4+PiAgICAgb3JnYW5pemF0 aW9uYWwgaGllcmFyY2h5LiAgRm9yIHN1Y2Nlc3NmdWwgRUFQLVRMUyBhdXRoZW50aWNhdGlvbiwN Cj4+PiAgICAgY2VydGlmaWNhdGUgY2hhaW5zIHNob3VsZCBub3QgY29udGFpbiBtb3JlIHRoYW4g Mi00IGludGVybWVkaWF0ZQ0KPj4+ICAgICBjZXJ0aWZpY2F0ZXMuDQo+PiBJIHdvdWxkIG1ha2Ug YSBzdHJvbmdlciBzdGF0ZW1lbnQgaGVyZS4gVGhlcmUgaXMgYWJzb2x1dGVseSBubyByZWFzb24N Cj4+IGZvciB0aGUgY2VydGlmaWNhdGUgY2hhaW4gdG8gbWlycm9yIHRoZSBvcmdhbml6YXRpb25h bCBzdHJ1Y3R1cmUuDQo+Pg0KPj4gSSBhbHNvIGRvbid0IHVuZGVyc3RhbmQgd2h5IHlvdSB3b3Vs ZCBuZWVkIGEgaGllcmFyY2h5IG9mIDQgaW50ZXJtZWRpYXRlIENBcy4NCj4+DQo+PiBGaW5hbGx5 LCBhdCB0aGUgZW5kOiBXaHkgZGlkIHlvdSBvbWl0DQo+PiAtIENsaWVudCBDZXJ0aWZpY2F0ZSBV UkxzIC0gUkZDIDYwNjYpLCB3aGljaCBpcyBhbHNvIHJlZmVyZW5jZWQgaW4gUkZDDQo+PiA3OTI1 IGFuZA0KPj4gLSBjVExTICh3aGljaCBhbHNvIGhhcyBhIGNlcnRpZmljYXRlIGNvbXByZXNzaW9u IHNjaGVtZSBpbmNsdWRlZCkuDQo+IEFkZGVkIGEgc2VjdGlvbiBvbiBib3RoLiBXaGlsZSBJIHdh cyBhd2FyZSBvZiB0aGUgY1RMUyB3b3JrLCBJIGhhZCBjb21wbGV0ZWx5IG1pc3NlZCBSRkM2MDY2 LiBSZXZpZXdzIGZyb20gZXhwZXJpZW5jZWQgcGVvcGxlIGxpa2UgeW91IGVuc3VyZSB0aGF0IHdl IGRvbid0IG1pc3MgaW1wb3J0YW50IGV4aXN0aW5nIHdvcmsuDQo+PiBUaGVvcmV0aWNhbGx5LCB5 b3UgY291bGQgZXZlbiBsaXN0IHRoZSBhYmlsaXR5IHRvIHVzZSBhbHRlcm5hdGl2ZSBjZXJ0aWZp Y2F0ZSBmb3JtYXQgaGVyZS4gVGhlbiwgeW91IGNvdWxkIGxpc3QgcmF3IHB1YmxpYyBrZXlzIG9y IHRoZSBDV1QgZXh0ZW5zaW9uLg0KPiBJIHRoaW5rIHRpdCBpcyBiZXR0ZXIgdG8gbGVhdmUgdGhl c2UgZm9yIGEgc2VwYXJhdGUgZG9jdW1lbnQuDQo+PiBDaWFvDQo+PiBIYW5uZXMNCj4+DQo+PiBQ UzogSXQgaXMgZ29vZCB0byBzZWUgSm9obidzIG5hbWUgb24gYSBkb2N1bWVudCB0aGF0IHRhbGtz IGFib3V0IFRMUy4NCj4gSGUgaXMgYWxzbyBhbiBhdXRob3Igb2YgRUFQLVRMUzEzIGFuZCBFQVAt VExTLVBTSy4gSSBjZXJ0YWlubHkgaG9wZSB0aGF0IHRoZSBiYXR0bGVzIGZvciBhIGxpZ2h0d2Vp Z2h0IGF1dGhlbnRpY2F0ZWQga2V5IGV4Y2hhbmdlIChsYWtlKSBzdGF5IHRoZXJlIGFuZCBkb24n dCBhZmZlY3QgdGhlIHdvcmsgb2Ygb3RoZXIgZ3JvdXBzLg0KPg0KPiAtLU1vaGl0DQo+DQo+PiBJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBp bmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo+Pg0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEVtdSBtYWlsaW5nIGxpc3QN Cj4+IEVtdUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9lbXUNCj4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxl Z2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFbXUgbWFpbGluZyBs aXN0DQo+IEVtdUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2VtdQ0K From nobody Tue Jun 9 20:27:54 2020 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 2D9CA3A0E06; Tue, 9 Jun 2020 20:27:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-emu-eap-session-id@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Mohit Sethi , mohit.m.sethi@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159175967272.17813.10689161410731354249@ietfa.amsl.com> Date: Tue, 09 Jun 2020 20:27:53 -0700 Archived-At: Subject: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-session-id-04: (with DISCUSS and COMMENT) 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: Wed, 10 Jun 2020 03:27:53 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-session-id-04: Discuss 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Should be a couple easy ones: Section 2.2 discusses the "AT_MAC attribute from the EAP-Request/AKA-Reauthentication" in the context of computing the EAP-SIM Session-Id, but there is no such EAP-Request message for EAP-SIM. Presumably it should be "EAP-Request/SIM/Re-authentication", and a similar change in Session 2.3 (which would need to cover both the AKA and SIM cases)? We need some kind of a reference for PEAP. (Is draft-josefsson-pppext-eap-tls-eap tolerable?) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm pretty underwhelmed by the level of security analysis that this document suggests has been done for these new Session-Id constructions. That said, it's probably still worth publishing the document so that everyone agrees on the same construction, and they seem to already be in sufficiently wide use that we'll have a fire drill if there's a problem with the construction, whether or not we hold up the document to get more analysis. RFC 5247 (and 3748) refer to a "fast reconnect" mechanism, not a "fast re-authentication" mechanism as we discuss it here (though it does discuss "fast EAP re-authentication"). Is there a consistent terminology to settle on? Also, some of the attributes we use for the fast re-authentication Session-Id generation are encrypted for transit. Should we say something about the decrypted version being needed for producing the right input? I also want to mention an observation that I made (which may itself be erroneous), and ask how that relates to the Session-Id usage: in EAP-AKA, the full authentication's Session-Id construction uses just the RAND and AUTN, which are server-generated and are related in a way that can be validated using just(?) the peer's identity as additional input. When we start pulling in AT_MAC for the fast re-authentication Session-Id, the MAC can no longer be validated without the context of the full EAP packet it was obtained from. I don't know of any case where there would be a need to do internal consistency checking on a Session-Id in a way that's made difficult by using AT_MAC divorced from the containing EAP packet, but it seemed worth checking. I agree with the genart reviewer that the abstract+introduction should mention that the definition of Session-Id for EAP-SIM full authentication gets some additional clarification. Section 1 The IEEE is defining FILS authentication [FILS], which needs the EAP nit: can we expand Fast Initial Link Setup here? Further, [RFC5247] did not define Session-Id for PEAP. We correct these deficiencies here by updating [RFC5247] with the Session-Id derivation during fast-authentication exchange for EAP-SIM and EAP- AKA; and defining Session-Id derivation for PEAP. Perhaps note that this definition for PEAP is for both the fast-authentication and full-authentication cases? Section 2.2 It's not entirely clear that we need to expend the text to introduce the "RAND1", "RAND2", "RAND3" terminology, that AFAICT is not defined in RFC 4186 itself (though it is used in one example). Also, I'm not entirely sure why we copy the Peer-Id/Server-Id paragraph unchanged and put the fast re-auth case after it for EAP-SIM, when we ignored that paragraph for EAP-AKA. Section 2.3 re-authentication case. Based on [RFC4187] Section 5.2, and similar text in [RFC4186], NONCE_S corresponds to RAND and MAC in EAP- The RFC 4186 text is its section 5.2 (as well), which might be worth mentioning more clearly. 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. This "would seem to imply" language is not terribly confidence inspiring. Perhaps we want to talk about providing a random value contributed by the server and a value derived from that random value with inclusion of secret key material and the peer's identity, which seem to be the relevant "corresponding properties" to this reader. My question above about independent validation still stands, though. Section 3 Protected EAP (PEAP). For consistency with EAP-TLS the definition given in [RFC5216] Section 2.3, we define it as: nit: the grammar here is a bit wonky, perhaps "consistency with the definition given in [RFC5216] Section 2.3 for EAP-TLS"? This definition is already in wide-spread use in multiple PEAP implementations. More details about these implementations (and, for that matter, the EAP-AKA and EAP-SIM ones) in the shepherd writeup would have been helpful. Note that this definition for Session-Id only applies when TLS 1.2 is used. A different derivation is defined for TLS 1.3 in [TLS-EAP- Is PEAP defined for use with TLS 1.1 or prior? (I know that we're in the process of deprecating TLS prior to 1.2, but that's not quite done yet.) Section 4 We probably want to say something about how these constructions are unique per session and unforgeable+unguessable by an outside party. (Section 5.10 of RFC 5247 implies a need for the unguessable property.) "No known security issues" is a pretty low bar. Who has looked (how hard?) and what are their qualifications? Section 6.1 I don't think RFC 6696 needs to be a normative reference. Acknowledgments I guess we should mark eid 5011 as "Hold For Document Update" before this document gets published (it's currently just "Reported")? From nobody Wed Jun 10 02:02:43 2020 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 572BC3A07B6 for ; Wed, 10 Jun 2020 02:02:42 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=qKd1MTlf; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=qKd1MTlf 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 h20Q3E3OQktm for ; Wed, 10 Jun 2020 02:02:40 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2070.outbound.protection.outlook.com [40.107.20.70]) (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 8EA143A07B1 for ; Wed, 10 Jun 2020 02:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cz2ldns9q66ogwwtpGEjEIOySufG73gIFINsOVMGKMU=; b=qKd1MTlf6OnsOZAH8dYNcEckrUp5WSkiDRUyUBuih7IxNaW/mI7U5W1Ul/OREuErU3D8bGjW0DR6hxDCCo4JywU0e4qUY0chSfCRkTkcGKD+LDv0RfP3XRtdH/Hhj0G8QBW8R9VP6vVcIso95WyZcRclhAfRWT4vqxjspBgu0H8= Received: from AM6P194CA0083.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:8f::24) by VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.22; Wed, 10 Jun 2020 09:02:37 +0000 Received: from AM5EUR03FT053.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8f:cafe::18) by AM6P194CA0083.outlook.office365.com (2603:10a6:209:8f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Wed, 10 Jun 2020 09:02:36 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT053.mail.protection.outlook.com (10.152.16.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Wed, 10 Jun 2020 09:02:36 +0000 Received: ("Tessian outbound 4f5776643448:v59"); Wed, 10 Jun 2020 09:02:36 +0000 X-CR-MTA-TID: 64aa7808 Received: from e0d2c30b9a06.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8E7C2363-FE61-4424-9B07-B1C9229F278E.1; Wed, 10 Jun 2020 09:02:31 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e0d2c30b9a06.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 10 Jun 2020 09:02:31 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T8Iq/mAK4UjCD52swmWGvnwj8U0AiQ4k/DyilxFPNBRJW1gaPAJwxbS2qCsGXplfp05vu8yi6ep4qHN/v7cEtl944AXWsUSdCWh+XeSfiARrj74YDcs8RuffV9PsAxglyJJNkijv05QyEYpvT1JstmeX7ZRZayTuu+/R1D4gxGRHyB9CEcT0bIedA9eBriHfSCEX1hRKiBwAX5BqPOL/0+WeFSW2gMbQGi4QxHFXLERx/0P4wWjDIOe9wKY4iY9sL7c0Xehv039fqsEbVpb2A9W24rjprk2w8yJd3UCf9FxKXUBguceRHjTRJQYv6T8kEbryATF4P3j4AIYtfYVbTQ== 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=Cz2ldns9q66ogwwtpGEjEIOySufG73gIFINsOVMGKMU=; b=jZg+kkyRzU8TtCCDd6o0tbZalEoLnpH3xamgBBhI3Wd1Cap9d0m0AVcLIwS4/AOdRUtaoHTSx3Hx8D/eHeMrIvznVqtSYPbiX0NZpiNqlKt8cGzK06iXZiOXOUygLcZqTrDfT55nCEVaSmNPoIntpGHEbECKWRGRkHpOj6Y8ns/o9wv41YiBZM3yUxNJYHOhfMej9QFgchJcsDU41SwMxQu2HMZdJspLHWaEHpTwe1ScjyppHCnbOjbjne5l9+VoMEIj7mE0ijQB7O1Oywjgg2YWGH6+T0YcoW3Q1pi4AqiP5Q7T2DcwFz/KzjKWCQbTJRtAVPNldwi3xHSJYqS73Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cz2ldns9q66ogwwtpGEjEIOySufG73gIFINsOVMGKMU=; b=qKd1MTlf6OnsOZAH8dYNcEckrUp5WSkiDRUyUBuih7IxNaW/mI7U5W1Ul/OREuErU3D8bGjW0DR6hxDCCo4JywU0e4qUY0chSfCRkTkcGKD+LDv0RfP3XRtdH/Hhj0G8QBW8R9VP6vVcIso95WyZcRclhAfRWT4vqxjspBgu0H8= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3796.eurprd08.prod.outlook.com (2603:10a6:208:100::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Wed, 10 Jun 2020 09:02:28 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3066.023; Wed, 10 Jun 2020 09:02:27 +0000 From: Hannes Tschofenig To: "emu@ietf.org" Thread-Topic: draft-ietf-emu-eaptlscert-04 Thread-Index: AdY/A+a7cI/+21ekRcieJ5sNz2jGnw== Date: Wed, 10 Jun 2020 09:02:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: ec8ee5e8-508e-4e80-83c1-6685a7dde9f5.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0bd83c03-6acd-4db6-2cd5-08d80d1d0566 x-ms-traffictypediagnostic: AM0PR08MB3796:|VI1PR08MB5325: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0430FA5CB7 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: AXPyHdDViDYnUaEOVdZNDqOytuwYfPfXavRQmViFDlMHsws34h/ccj64euoRKuctYs9TCmnPUTeT+imvZjXzyStFElaMxFEhTdNsdc9goDlrelhTyHi1/dlBDr3d5CA/Hg0GsVJrxpJQcQ/FEQ5xZVSV6iLlKm3Zj4QvEk4yWEuDjhA6uQW78zCuehMZH1T98QdmX27Sfy/N67VdFluMfb0bu+ZX8oH/3BxN4PYpY/JzUH+aPI5Y39cxYcY3g6nc3pM8niICPTInDUwd21zTmoqIZLd6ucoyoO6Rrcxtitrap7lIoi9LIIZaNh3z2wF27ZO2fV1xjkszZeN2bUiqMYBoLkz+FOhk0+yobMFI+BWw0MNdTO6hRGYnD0mG/8ZyoLhvMGUrxSI8N9ODzYmikA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(346002)(39860400002)(136003)(396003)(83380400001)(8936002)(52536014)(5660300002)(8676002)(55016002)(9686003)(66946007)(71200400001)(66556008)(66476007)(2906002)(64756008)(316002)(66446008)(33656002)(26005)(86362001)(6916009)(186003)(478600001)(6506007)(76116006)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 5y6lkWVIn297BKYoT4zO9IR37yvsGtQ1zxPiGlEMmnynC7dkm1obqvcwZhKP5WOdCfoxGO1bBIBeVuB0tlHZfKixKecvg71rs4KuVrT6m94xg2VJog+nKSyq38o71XMvlXzG7sULzImPRltkWv9R0dLTpqMRtewZdY2TX6H5twCoW+cU9K8llS0L+8mKx9hAUTcVuYgaDnUUsbV1vjnZFSy/3tOi7cSjQgXBmTJez25cOYnTYEJ062DA5T5gf8llzDfLPrY7YwMe2NFKCcDfy5bOMpdEpb8CudwuX4639vSfo3KLFwZpSFug4tq0EpLZI2CEFXs+jF8jgY7lh+6Uyl8HQOeCovrUm3a/KuUcqm9Tv3Vu86yMsD0QQIrTSJZwFG2vDpk7kMMpV/hj0PSvGQtPHMHt1nUSDoW1uhTEO6+UJf0vzJK3Y8aXWE7tSapxvfX93pFTfgmVOXQu+jwhJaxHxkkN8qdS7KZ8gNLoTlvq1g4QhyOufcb80QT+RrWn x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3796 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT053.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(346002)(376002)(46966005)(316002)(8936002)(5660300002)(336012)(83380400001)(478600001)(81166007)(47076004)(186003)(36906005)(2906002)(82740400003)(55016002)(9686003)(70586007)(52536014)(356005)(6506007)(7696005)(82310400002)(86362001)(70206006)(26005)(6916009)(33656002)(8676002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: fe251072-1a25-4709-0fa4-08d80d1d0016 X-Forefront-PRVS: 0430FA5CB7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OSRj4TlVfOE/Swlcxp206eFYITxORO6PZlpX7B8W9+vWiaBF+tIaz1uX2PVsuqkK0H0OYoNviz1lUQe99hXDZhdYvpS3Zf59DEjDzaNqb4Bu7sAGdilgf8pVSt6W4zUKiLckV6OlDZ+zyOUl6gW2SzkzY7dp9TPwHkJYQ5FiH53Xd2Zj1sDHDzBcqGbJ6S7+bXHEz+5gF5np+RZua/CpxaxplYdlxLNQfNFw51y/uCXUVzw8iHCV3bzTD/Td9ohC9ypUDCnWsojOCZtVychQSObA+vFDWjlJdedMLP39LIyVV8MjWJ5sCSbtUt/lgm683O1c7h7wUJYgC+58MGzC2yG8S/TOLxWri/itHbZMhdpcnJRbCgclCu9OkxvwJjEHD6O7/I8U9qsM0T4nDYO1gQ7QUBJ/w4SQ4i9rb9qcqhlo6OAqgOQc92WmvoZ7Rv40/f2GInRawisqFP0K5c2Dzu22jIHrbLFvJT2UW+KVwAA= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2020 09:02:36.8160 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0bd83c03-6acd-4db6-2cd5-08d80d1d0566 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5325 Archived-At: Subject: [Emu] draft-ietf-emu-eaptlscert-04 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: Wed, 10 Jun 2020 09:02:42 -0000 Thanks for the update. A few more minor comments on -04: Section 4.1: "TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations to = support ECC." This is only true absent an application profile defining something else. The UTA group has just adopted a WG item that defines such a profile. Hence, I suggest to add the remark about the profile. Something like "In the absence of an application profile standard specifying otherwise, a TLS 1.3-compliant application must support ECC." 4.2. Updating TLS and EAP-TLS Code Why are you calling the section "updating code"? The suggestion in 4.2.1 do= es not require code update and whether something requires a code update dep= ends what you have in the code already. Maybe you just need to enable the f= eature. Updating the code is also a negative aspect because you are likely= going to update the code on a regular basis anyway to fix bugs and to supp= ort new algorithms. Luckily TLS has the extension negotiation built-in and = hence you can detect and negotiate new features on the fly. 4.2.4. Caching Certificates "The extension however necessitates a successful full handshake before any = caching." This is not true. The spec defines a way to populate the cache by running a= full handshake. However, you could also populate the cache by out-of-band means, for exampl= e by pre-distributing certs. The mechanism to re-run the handshake to populate the cache is, however, a = safe fallback in case configuration changes and the pre-distributed certs b= ecome invalid. It is better to have a fallback. I thought I made that comment before. 4.2.3. Compact TLS 1.3 You are still stating "This naturally means that cTLS is not interoperable = with previous versions of the TLS protocol." cTLS is a compression of TLS, which means that you can fall-back to TLS, if= the other peer does not support cTLS. As mentioned in my previous email, I= don't understand why you are mentioning this aspect at all given that this= document is about certificate size reduction. Raw Public Keys I wonder whether you should mention the possibility to use RPKs (https://to= ols.ietf.org/html/rfc7250) in Section 4.1.2 because those would be a fairly= obvious choice in EAP-TLS given that we are talking about a nailed up conn= ection between the EAP peer and the EAP server. This would obviously reduce= the overhead associated with certificates considerably. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Fri Jun 12 01:29:50 2020 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 678BF3A0DBB for ; Fri, 12 Jun 2020 01:29:48 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=u5NCyxJO; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=u5NCyxJO 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 I4P1FpznHPVR for ; Fri, 12 Jun 2020 01:29:47 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80052.outbound.protection.outlook.com [40.107.8.52]) (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 98A8B3A0DB8 for ; Fri, 12 Jun 2020 01:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZQyOxdHHak06RfkKdv9k4Hnp4sCufi8hSqgOk22DAWs=; b=u5NCyxJOU3n8aX8d/N2Yd9UkduIQ8/0BuFiQ3vZmHPSPv5/+d6QnQ8oSpzKJNWK4eqb5fvIcWh6EnkvbDb/u0wbEOcOOwKB+KWpLCYOwT2u7WI52Dv4TY/nlUTO9gMB05IaE7kHJFf+j2teHkQ7N48zzZoOMWRPtlC6RwQr13Ew= Received: from AM6P193CA0069.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:8e::46) by DB8PR08MB5195.eurprd08.prod.outlook.com (2603:10a6:10:bf::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 08:29:43 +0000 Received: from AM5EUR03FT020.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8e:cafe::be) by AM6P193CA0069.outlook.office365.com (2603:10a6:209:8e::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Fri, 12 Jun 2020 08:29:43 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT020.mail.protection.outlook.com (10.152.16.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 08:29:43 +0000 Received: ("Tessian outbound 3e82c366635e:v59"); Fri, 12 Jun 2020 08:29:43 +0000 X-CR-MTA-TID: 64aa7808 Received: from e94feea67711.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 19DAD10E-AEA5-4B14-8617-0FD7924B35D7.1; Fri, 12 Jun 2020 08:29:38 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e94feea67711.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Jun 2020 08:29:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=En/JTUwEFqck3Mny5taWa4b2YorwGblhX+PWFwUR92ZEN/9lF6YOTJChxKw8xufeqZr/PhxaSSHnAP/mlW+ErVQPLvbsyToSIKpUJEsB6lh+9gzDdqW4+vwZo2wRS9G8WOK0/IEEuOXqEvDLYkyxkmLc5Uqn1gJKc9EqN/TmlKAMFPMD6bgLlHr4dwNID57QJcVWq9ORC1849SgwCQa3aC2fXHSOi5zYtpcFqcdkQNK95aTRvpLmAJpGb/JbJdOn0fvZ5miz8oCND61I9HDxrW8mDwZcOhel3nUIJuc5xg7FQK++vyksnEkqD6PDs0VSpTBHLdqsclG5cSTY+1QXzA== 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=ZQyOxdHHak06RfkKdv9k4Hnp4sCufi8hSqgOk22DAWs=; b=fc/zHVOXLEzvPrZh4IbHH27wX6LtixtNLHwraJMV90fPGv2AOzmQuqgm+QM44Q/GvME0jifUhM+ReMu76y04qkDUQeNVcuSNaOCkyHzr1SAtX3Gpcgpd1Z+S6HiX8V1Utp86WGOVxP8rviZOl1ekfKGuaxAUJ4uVR21DkJiIrbTzyKIdRF49CYcypPmbeZbDG6umMADwBvTOG2DVAx5kxao7hA4KHiOz9fK6nFc4V65v1r3GgAh8c4jaKfggRgHOX+kuwxsJijFix9/zj3Snf9d9IwrQq5/uff6A7ixqgL+9pBGqhNEL3SsThHPmOvC9dmmVtuaozH8eDj+G9dokFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZQyOxdHHak06RfkKdv9k4Hnp4sCufi8hSqgOk22DAWs=; b=u5NCyxJOU3n8aX8d/N2Yd9UkduIQ8/0BuFiQ3vZmHPSPv5/+d6QnQ8oSpzKJNWK4eqb5fvIcWh6EnkvbDb/u0wbEOcOOwKB+KWpLCYOwT2u7WI52Dv4TY/nlUTO9gMB05IaE7kHJFf+j2teHkQ7N48zzZoOMWRPtlC6RwQr13Ew= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB5474.eurprd08.prod.outlook.com (2603:10a6:208:187::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Fri, 12 Jun 2020 08:29:37 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3088.023; Fri, 12 Jun 2020 08:29:37 +0000 From: Hannes Tschofenig To: "emu@ietf.org" Thread-Topic: draft-ietf-emu-eap-tls13-09 Thread-Index: AdY/BkwoNfvYGwBmQuGwz/IONkiEYwBjQ/wA Date: Fri, 12 Jun 2020 08:29:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 29c9296d-b06e-4152-931d-e70b86c12265.1 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0f1ed28d-a582-4b8e-004d-08d80eaac1d7 x-ms-traffictypediagnostic: AM0PR08MB5474:|DB8PR08MB5195: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:7219;OLM:9508; x-forefront-prvs: 0432A04947 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: GThuYnM7qShWyuTe0hCU1pQIAGlGIexGIpdtxGBK2E4i11skcyjdSWefkOLX4sY2yIzrdqLEGRoxK2jaLwzYEnULQ1pA8z+x+ajUs7OQE4eJN435Vy9kgfgYQXzzfm9d7gPWVwRnq5rWsE6mWDn/2+5dtMpmCtiKBTAWrPaffH2qWecMvrWCKVsQ5zotjb71m0mCRf3qjn3MVwm8rRivoUlxYpdWatOrNx2Ho2VLWkvuUxIZa52sdIY9PdSd4xr1rGcb3Qbxi2vKsH4bB+4Uv/+JZ2QnuBMWSqxwgRd3M5yBm9rs7Id3zOu3WWUom0SDuOz8652ZcnN/EU4VPOORSg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(346002)(136003)(39860400002)(366004)(9686003)(66446008)(6916009)(2940100002)(76116006)(2906002)(55016002)(64756008)(66476007)(71200400001)(186003)(5660300002)(86362001)(66946007)(66556008)(52536014)(8676002)(4744005)(6506007)(478600001)(33656002)(8936002)(7696005)(316002)(83380400001)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: amiNGe3oMb295uW/8TshmbnV6smA2EUb/+OdxMVlfgyuNLQbdHEUvkdOPzggD9+q3IirCZ6zxCD0iDAfbqpFoBAbvDrl5ckA012O0zl/b8JHKsCM9s/LRhiyF+djwvlN8cyLSvg7krgQaD6M0BigLopKW7/Pi1D+/tEkg4sa2QI8BLJWJv6ufePTG4ibIs/SxXCBY5jI5fyzMO0P/CsWxkZazq6GBPsXTrNOKmD5TILhE/u8JbSlMMx1EZF56/EksfxfsfhSVT5jDZ2lZq1tnwBaDosLAXVZ+TrgZWHLMzEOLwtHFhguLFcbKmRZwUarvX7C7NtM0u4HurvyhKJBBFdHPiXNQHHtWwDayR/by8PxQDBkgPI4xgEvaDg21tKgfiGL1ORxIh7QNI41ThO4OUiQ0WBPcfoVnH8wFIfW2dQs9XBU/9Tiq8kF9WehL/H9eR0viXBVJE6h8TuCIDAhFLADAY1OHdAGo5AbkBtI84JiKmLKcPScHyzODHK8dRCG x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5474 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT020.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(39860400002)(396003)(46966005)(8676002)(2906002)(8936002)(356005)(83380400001)(47076004)(4744005)(2940100002)(5660300002)(52536014)(33656002)(82310400002)(86362001)(336012)(81166007)(82740400003)(316002)(70586007)(6916009)(70206006)(26005)(9686003)(36906005)(7696005)(55016002)(478600001)(186003)(6506007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 27cb56bb-455c-4319-2c0d-08d80eaabe3b X-Forefront-PRVS: 0432A04947 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: k2qxFsYQyyuYQtCbZVJKEXZnejbjxS++xlkoyW1WT4FICRah6Y78FSqs4vt2W2g0ETtft5BrqqB3i3BFMDeqau+zp9qDI5pSwYeeA5Rw+6I8ZrCbZcZmFSDtUJGBahG5o5WLUNMUFZJYnqohTWirwpJDUHJFaZgZGsGgyaCfHs5TM/vktY6Hx1+2lD3trAZpzrYq3dTb8T5ssd4M3c0H9QUWIuB3UdFMVNOxwdVM3NLsAJfip3D5uwMEZmuSMyN0Ug7btRm9kaTkIvqxB6wneQrevDasX9RyZG7rC8UsAuQJ8R8fL953H3Z62xaxm2g/4x5gu/8LeCdh8VfYQzwLSgh5i29Sd0dvIT9R/NySIncrYWykM2B3Cr91cuAenK+b2gwLm0F8PgKQ4sUjlYNtNQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2020 08:29:43.1647 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f1ed28d-a582-4b8e-004d-08d80eaac1d7 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5195 Archived-At: Subject: Re: [Emu] draft-ietf-emu-eap-tls13-09 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: Fri, 12 Jun 2020 08:29:48 -0000 A short follow-up on my own review: I wrote: > " > Pre-Shared Key (PSK) authentication SHALL NOT be used except > for resumption. > " > What you want to say that that EAP-TLS MUST NOT use external PSKs. I wond= er why you want to rule that use case out? It is a perfectly fine use case = for TLS 1.3 and there is even the possibility to use PSK with ECDHE. What i= s the motivation? I noticed now that the working group had a discussion about this already an= d that there is a new document being published specifically focused on EAP-= TLS-PSK-based authentication. Hence, ignore the second part of my comment. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Fri Jun 12 01:36:58 2020 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 615773A0DEA for ; Fri, 12 Jun 2020 01:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=THRvKaD7; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=THRvKaD7 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 XcsOgG7eK9JL for ; Fri, 12 Jun 2020 01:36:54 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2069.outbound.protection.outlook.com [40.107.20.69]) (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 6B26B3A0DE9 for ; Fri, 12 Jun 2020 01:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TS5DAXiKwtxFt0UeTSDPmvR15bNHBymafYLjDr4c2r4=; b=THRvKaD7/RIKyw6S1vIimHYOyT27pYkZX4VhvDi06yZApJUc216FDSYoWb/3tN/qzyRJ6IF7OErVI1DgflYxzmZYiaRc3d9+5GzwjZUyxI8Yj/i7czz/oqTKk6g4ydFA2DPlViN/Ms+PpSVgcgoktfr8LRS0Kfzt8IMStm39+L8= Received: from AM6P193CA0142.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:85::47) by AM0PR08MB4209.eurprd08.prod.outlook.com (2603:10a6:208:10c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 12 Jun 2020 08:36:51 +0000 Received: from VE1EUR03FT030.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:85:cafe::aa) by AM6P193CA0142.outlook.office365.com (2603:10a6:209:85::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Fri, 12 Jun 2020 08:36:51 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT030.mail.protection.outlook.com (10.152.18.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 08:36:51 +0000 Received: ("Tessian outbound 4f5776643448:v59"); Fri, 12 Jun 2020 08:36:51 +0000 X-CR-MTA-TID: 64aa7808 Received: from 61483ea47525.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3FEBF553-9C0B-44F6-BCCC-854CBC2E3B99.1; Fri, 12 Jun 2020 08:36:46 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 61483ea47525.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Jun 2020 08:36:46 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GudmWueUF+qyoiWR5ZW0/9wF+3UXh3dz6xDhIyBK/5F9fvrwKBtI9/0X+wqtZn0RdQw+zBx95aowru6x5BrOQaKvyktiRy36u5gE2QCq07v4JmEmsQsgGGlmanfoYM8miMncLpSw+tB0A6fvT/W44Cqcd7qiVTtBIG08zayQRfbOg5e+cHxzf8OlQqqR7/yFgOVYeQ3os1C/AFj+bXGcDT2SaKE2iOcAjTqbzKuMI7enAdUUwbeAIxzVZPfs4Ktmi4/C/H5Yx7cnZQXgASO4DDdk473UqeHis83daTUE3TxDNfnOwhdSsIv7ZiruEsbwnqSChQN8YnkYAkIAmG009w== 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=TS5DAXiKwtxFt0UeTSDPmvR15bNHBymafYLjDr4c2r4=; b=mHaQhvoEpYRpdoNOSJgCoj9W1zeZ18mue/chKU3cGc7e35iUev+Z97Y227hFmLhJ4bxWCBMUMWSlVzOxIW96h/FND4si4OIqD3y3x/xYOJ1pHcYfdM55EeuTFO/K8P9kDCAzbuUKOCpsa5uru1I6tMwEpmt7fRrd2U67LwDVeeO8dkfnY4maGlOF8KnsEh3Oi0jK1C7+t0k6KfSy9lxkKi5frJET6pG68/3hRvBn3aKCNULmewKsNI+40mbj3q3swddI5sc01mPg+EXbCRcca+znAF0KRDF2PoEeylHHmnj392S3X8arzCGQHjqfjlqXzRpLotAPIA76zaGiA28iNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TS5DAXiKwtxFt0UeTSDPmvR15bNHBymafYLjDr4c2r4=; b=THRvKaD7/RIKyw6S1vIimHYOyT27pYkZX4VhvDi06yZApJUc216FDSYoWb/3tN/qzyRJ6IF7OErVI1DgflYxzmZYiaRc3d9+5GzwjZUyxI8Yj/i7czz/oqTKk6g4ydFA2DPlViN/Ms+PpSVgcgoktfr8LRS0Kfzt8IMStm39+L8= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4209.eurprd08.prod.outlook.com (2603:10a6:208:10c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 12 Jun 2020 08:36:44 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3088.023; Fri, 12 Jun 2020 08:36:44 +0000 From: Hannes Tschofenig To: "emu@ietf.org" Thread-Topic: Commitment Message in draft-ietf-emu-eap-tls13 Thread-Index: AdZAkc+cCh243U45Rdqk3n8/SPrXVQ== Date: Fri, 12 Jun 2020 08:36:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: c2d67adf-be6a-4723-adde-9ecfa121d2ef.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 158c9570-9305-46ea-665f-08d80eabc0f3 x-ms-traffictypediagnostic: AM0PR08MB4209: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 0432A04947 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: bym2vYZLTvQnxI7IlrgADnp+v9mG26TKiz0Ei+Tf5TVWotdKytIIkLc1QSfJb1I4fc+BwB83IMCdKg3oYw5JQbaenOZ8RYfUg/9i80SqkQy7Kxwx4BMXvuU/7fAM7Ut8Gs7sUCjQlAV/8N0jwXx9sJlkJje51huz1+xoCCwr7dsXgXHfXKFZk63n1bQj2/084lfSrAangNXB5+KlfNtuPMdhiRKIia8eONBULWB1/fwTjEe9LDlbqVlXVNOyoT/NNANyyhnWAMIKuG6DB/dvikg0Ue8jlU5VO1AESL9KwGEKee4dw8Won5w462hue3rJo1O8qqslya8o+Y21DenzqA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(66476007)(7696005)(316002)(15650500001)(8936002)(26005)(2906002)(6506007)(8676002)(33656002)(478600001)(66946007)(66556008)(83380400001)(64756008)(5660300002)(71200400001)(76116006)(66446008)(55016002)(186003)(9686003)(52536014)(18074004)(86362001)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: g2G/Cv5k+5ZD0N+cmrxjbWrk92apNkf9WWO+diHRG6mf8LO5yNMTgrPI4r5al4hjHY/5jWxhR6qprbBAtQqrewv4hKSbfevT0P1wABRQqk0OJLoHBfu+CCoGN/5wiTkIAbS78flc7XvGh0BeeH4pTL/wv5t4NydcLf8q6M1IBa8mrBziSCRjvpTAJwAlRUBP6IFQ3X7qvnfSqbDrI1B157geOPDem9uqikhFr71x2Ht68Lq1QYgqZLAvz8sz/l9VPJe9SLguyKDe4fggJrNEiOZbI7eOguuZ2shPtrNlCdZ9CfqdEVwz9LHc069v6+CaMf70CBfZ3ywiNma5Bzihd2fB+8FyRHsyIdjTkCQ1DXWdM3+/SBAcYatKlKtewMrVLA66z572qG2D9S3MqIPmdvB/qvocttYcbbMoC2dF2nSdL8WzdB9JqhOtdvuPW3PZBsb9TrWVJy3ibO7cc9XIYYRMaibGmMNJK87rvK5yJbeFOJdoylj29Qzr6bruXvAc x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37162AE5F0175B95A237B31EFA810AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4209 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT030.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(136003)(396003)(46966005)(36906005)(336012)(7696005)(316002)(15650500001)(8936002)(26005)(2906002)(6506007)(8676002)(33656002)(478600001)(70586007)(83380400001)(70206006)(82740400003)(47076004)(5660300002)(81166007)(82310400002)(55016002)(186003)(9686003)(52536014)(356005)(18074004)(86362001)(6916009); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 15a5ed25-c28c-48f5-ec8b-08d80eabbcb3 X-Forefront-PRVS: 0432A04947 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: VqYJzLUcEMJCb7IXUXhAg8WfelBqdaEEu0gbNLw6R+J5G+jtzQImxAzB2GhRdxGY/6Ef+Hcl1fMt5OQ5Pjrv4r8GEU8HuG1/ilOTlfjJ+QckJt9EXMK5t+ykoUnthW2og+DDOYQeLdr9RzzbffB1lp1eWPfw4QgDJWpSpJqUfZ+/C9wrrQrGT6gZHwX4vA6m1bAEyP/JLgvAs2paRRbpSK9LI7Ix4yRr881W/z+6+42dGWkW2oGGCLILvaqSw3KwIGknE6bQ1sS24dQFUKxkHABhRnsg8wLVX7cj4OxbRrdQX5l9Jy2ClEPFuh0inRs3C1pKgh4/c0CB3giE4OAcu0PNDge6cDwJmeEnhJxuhtl24CzlGWul/jDBRDjPuhHPlY95erlo75Uq7HbioXZqnA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2020 08:36:51.1200 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 158c9570-9305-46ea-665f-08d80eabc0f3 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4209 Archived-At: Subject: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 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: Fri, 12 Jun 2020 08:36:57 -0000 --_000_AM0PR08MB37162AE5F0175B95A237B31EFA810AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This has probably been discussed extensively in the EMU group. I am sorry t= o bring it up again but I believe this is a bad design decision. I raised i= t in my short review just sent to the list but I believe it is worthwhile t= o point it out separately. draft-ietf-emu-eap-tls13 introduces a new message to EAP-TLS, namely the Co= mmitment Message. This requires extra code in an implementation because the= normal behavior would be to run a TLS stack and then send encrypted data. EAP-TLS does, however, not send application data*. This message changes thi= s. Not only does it not send encrypted application data it requires an impl= ementation to transmit a plaintext application data record after the applic= ation traffic secret has been created and before that application traffic s= ecret is used to protect post handshake messages. This will make it difficu= lt to re-use an off-the-shelf TLS 1.3 stack. There is very little motivation about this message other than " When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. " I might miss something important here but why cannot the EAP-Success or EAP= -Failure serve that purpose? Here are two examples to explain what I mean: 1. Failed exchange EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, TLS Finished, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Fatal Alert) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Failure 1. Successful Exchange with Post-Handshake NewSession Ticket EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS NewSessionTicket, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Success Ciao Hannes (*): FWIW Post handshake messages are protected with the application traffi= c secrets. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB37162AE5F0175B95A237B31EFA810AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This has probably been discussed extensively in the = EMU group. I am sorry to bring it up again but I believe this is a bad desi= gn decision. I raised it in my short review just sent to the list but I bel= ieve it is worthwhile to point it out separately.

 

draft-ietf-emu-eap-tls13 introduces a new message to= EAP-TLS, namely the Commitment Message. This requires extra code in an imp= lementation because the normal behavior would be to run a TLS stack and the= n send encrypted data.

EAP-TLS does, however, not send application data*. T= his message changes this. Not only does it not send encrypted application d= ata it requires an implementation to transmit a plaintext application data = record after the application traffic secret has been created and before that application traffic secret is used= to protect post handshake messages. This will make it difficult to re-use = an off-the-shelf TLS 1.3 stack.

 

There is very little motivation about this message other than 
 
“
   When an EAP server has sent i=
ts last handshake message (Finished or a
   Post-Handshake), it commits t=
o not sending any more handshake
   messages by sending a Commitm=
ent Message.
“

 

I might miss something important here but why cannot= the EAP-Success or EAP-Failure serve that purpose?

 

Here are two examples to explain what I mean: <= /o:p>

 

  1. Failed exchange

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS=

   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
            &nb=
sp;           TLS Finishe=
d,
       =
            &nb=
sp;            =
 <--------        Commitment Message)<=
/o:p>
    EAP-Response/
    EAP-Type=3DEAP-TLS=

   (TLS Certificate,<=
/span>
    TLS CertificateVerify,<=
o:p>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          (TLS Fa=
tal Alert)
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Failure

 

 

  1. Successful Exchange with Post-Handshake NewSession Ticket<= /li>

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS=

   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
 <--------          &n=
bsp;   TLS Finished)
    EAP-Response/
    EAP-Type=3DEAP-TLS=

   (TLS Certificate,<=
/span>
    TLS CertificateVerify,<=
o:p>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
        =
;            &n=
bsp;            =
;            &n=
bsp;           EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
            &nb=
sp;  (TLS NewSessionTicket,
       =
            &nb=
sp;            =
 <--------        Commitment Message)<=
/o:p>
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Success

 

 

Ciao

Hannes

 

(*): FWIW Post handshake messages are protected with= the application traffic secrets.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB37162AE5F0175B95A237B31EFA810AM0PR08MB3716eurp_-- From nobody Fri Jun 12 04:54:55 2020 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 191653A0E0D for ; Fri, 12 Jun 2020 01:15:49 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=uy5cPDFq; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=uy5cPDFq 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 AoLAAXDezZDX for ; Fri, 12 Jun 2020 01:15:44 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10044.outbound.protection.outlook.com [40.107.1.44]) (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 19DB33A0E06 for ; Fri, 12 Jun 2020 01:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GeStB4AUk2f9vY5m+ipfVtd2HEc6marutFZoDER8ueQ=; b=uy5cPDFqZGxtqB5TBwlnb79J/z/cIcTAMONnFQInfG3ZuqYE6bUcjnUpNS3odr7DrFjbiZnmEktHTQm6PZ97py+hiY0B22Jo0SY6IYIMBxsqK2SCecADWhj/xgqUUwiVg0eeQHC1YBSv/XhBeQyotJiZQB0Sh5VGR1yPpbPfz3I= Received: from AM6P191CA0068.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:7f::45) by AM0PR08MB4353.eurprd08.prod.outlook.com (2603:10a6:208:144::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 08:15:40 +0000 Received: from AM5EUR03FT027.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:7f:cafe::6d) by AM6P191CA0068.outlook.office365.com (2603:10a6:209:7f::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21 via Frontend Transport; Fri, 12 Jun 2020 08:15:40 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT027.mail.protection.outlook.com (10.152.16.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 08:15:40 +0000 Received: ("Tessian outbound 56dbe829191e:v59"); Fri, 12 Jun 2020 08:15:40 +0000 X-CR-MTA-TID: 64aa7808 Received: from a7a78cd54b1f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 479BC2E4-EC63-4D38-8BBE-B431E7199323.1; Fri, 12 Jun 2020 08:15:35 +0000 Received: from EUR03-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a7a78cd54b1f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Jun 2020 08:15:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AW6xw52WzU35+htPQoh/my/iyZRAWlyxlmQDQJa1E1w3h4Gc/x2tFOfsoJaiyCPV56uB6L3l9wkZ152Gk6pdWd4oBsS2xhQvxTnYyv9uqt4wdpBku4WQVDZUKgCCfObBpt5ev68rHWVLYl6py2Q2SpPQf/MfVbq1uob+YaD9kTMnr9wQXDsxN6oKVhFRhbnota9oIcmvwfe2ecWKoLBo2+cpp16VWUovf7UsSEpPSFXDEpscdS+jSvdPM8Jqrbz9MDkZkK0uXwHJIs+Oc36s05rS4RXJKWsgPofy+BuErpd3FXIrKM7hQQQtBBNdesmThz+HEFmaCC8hjSDmo5fK6g== 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=GeStB4AUk2f9vY5m+ipfVtd2HEc6marutFZoDER8ueQ=; b=F+R52BSm28JOB2tlhbomtaPEDhvmworsz0OcaPtz5Vvkm6OoTz3ZslcTswpfMoCe9oQRz+RuarMneNx96MCmLQNnxlxDUAjgfQwiy2X2tAAeLZYaSDtTrnT8DwQ+TCGw0l9wP9tkC9EsmZvfeqKVpXaYIBlo2vfSBud/geydmUx7rczvF6sCcLvurEox1iRvIqlTmWrmEvTPqMJM3Y6bLf0XI7q4KMdg1hPhkOfjher1VI8EwW5U43UAHpliamWnEi0n0z4u3E0ywswuE63G9+okwC0rOadTUWUI29hKgZWtsN90/iVzrsGrhathJWq6TE0EwMsEfZfCe/aPDb+r1w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GeStB4AUk2f9vY5m+ipfVtd2HEc6marutFZoDER8ueQ=; b=uy5cPDFqZGxtqB5TBwlnb79J/z/cIcTAMONnFQInfG3ZuqYE6bUcjnUpNS3odr7DrFjbiZnmEktHTQm6PZ97py+hiY0B22Jo0SY6IYIMBxsqK2SCecADWhj/xgqUUwiVg0eeQHC1YBSv/XhBeQyotJiZQB0Sh5VGR1yPpbPfz3I= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB5490.eurprd08.prod.outlook.com (2603:10a6:208:184::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19; Fri, 12 Jun 2020 08:15:34 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3088.023; Fri, 12 Jun 2020 08:15:34 +0000 From: Hannes Tschofenig To: "emu@ietf.org" Thread-Topic: draft-ietf-emu-eap-tls13-09 Thread-Index: AdY/BkwoNfvYGwBmQuGwz/IONkiEYw== Date: Fri, 12 Jun 2020 08:15:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: ae8c93ba-7121-4d39-be76-713c31662672.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 558d9fd3-28d9-49e9-6c8a-08d80ea8cbad x-ms-traffictypediagnostic: AM0PR08MB5490:|AM0PR08MB4353: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 0432A04947 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: eXTE/lEXzgAfcplFVGTGr5xfXsp6eAENg6aDMFU+Y5fk+anz4aCQBrUUjKh4VlboU+dvcIFMGt4ZZhTSPaGLKFlpOjsijrR8KdAJcAcFs+x7LQWE6jEtIpk8SYOYOk2NJArSAGubl4VRtjFioWDvfdEAWdJjWPTSUg/kcA4Rfd9hYiczFsD3bJvXsgvJDOJ1vrc7sPLVFBDgWU0EFxm58H5fIhSrzM0vybX1syQ3UoxviF/S6WMY55GoAaDf112pugCwNY0iwWtXDMbmB8o4+2fyHOdyH97UNUjpwurR/HLWQ2hlOzaFxy0SbunuzuPWapwrrshpaR64+JNukjr3AlsuhHW8SqLyxxz48FBi58q4GIHhM1vtR4w6REyL7+a9ZB5Un49VqViCL8SHVtv25Q== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(346002)(39860400002)(396003)(136003)(7696005)(166002)(9686003)(8936002)(316002)(186003)(6506007)(26005)(55016002)(6916009)(5660300002)(71200400001)(66556008)(83380400001)(966005)(8676002)(33656002)(52536014)(76116006)(478600001)(66446008)(64756008)(66476007)(66946007)(2906002)(86362001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: x3IJyZq8SP//PVbeLCyqlGBi3+huTfaG0agpHhQ+dumf0VhG6pYJpdOooeJiNBxNLGeY1r+cN+d2NTtSZrXaGfmWVwRwgN+udgumbaHntoEk4c/x9L0M5iiI4FWaiV7CnB1NU+V2RSOtJiF+bgjAKoZNTWS+w+m6nJzZ0KG9t242H123MH2JsaXJlxijehCOhohCZvVhyV1KNTLTnFGo+mbMerlMFL202rknVkJJQCsJO/m1pd8rWHMUr5wZ8xZSPmlW2ELROnvugoWpJ+zDJjN2dwVyHNkmbEQn35rDiN8dVvAPaXkU3RhobkAamEb8tgQnheqj8boYOxF4rHp57FLyFEj6lsaqIYePTJx/4qKBU6Ou/GX09XG7A4w0j5bw1zNQXn2UW3835y8NH0B1apr59URUshB4+94KWeEyqcYBrMgR+tk+lZxJlWx8ueAKXXuaoHI+/Fg9fo51LhGxa9ZpSd8FoRyO6bht2IESvxhdzoO6++3CQIxiOodeIHSJ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37167810AD2FA9E36DAE2418FA810AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5490 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT027.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(39860400002)(346002)(46966005)(82310400002)(82740400003)(81166007)(70206006)(47076004)(30864003)(5660300002)(52536014)(70586007)(33656002)(166002)(86362001)(356005)(2906002)(36906005)(7696005)(478600001)(9686003)(316002)(55016002)(8676002)(336012)(8936002)(186003)(6506007)(83380400001)(6916009)(966005)(26005)(579004)(559001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 313821de-4e26-4088-8b70-08d80ea8c808 X-Forefront-PRVS: 0432A04947 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ULCC/jOiP8H+P3iwi1DOcmTbi9M+i0J2OpXgd2rqtJR4w4VIxL2f9/W5Gj7xuJrS5BcsrCEBvacYSFYoSDk2yVxLt2Oy81s+G71IvZBVZkhGs7n4v8Cn5sd9smXTtxqlGypiH3m0EfwA+u261wxQlEhhnEzSUfzuZm9GAaJVb5nFWMvcZ1jVQ7GRNdeXQ53kS1xzHAleolPm3mkKF/scyAFbto74BQ4g3+XgpPE/+5QKx0u7KwrAookaCvk6gOj0tCNH/mYSbLAA6k9cw8AWNXZF9OC0RxlRb62TyaCIJU/g2qpXNgFf0jMXoEMbYJlToEil368v9AwBC8chOYb2C/Y0W3rUrpQHMakcDwswlq+cXcltd3gckS3MIafJXeEIlvRqTPIilX521xlJX1SZpAuOtlOMf5bZeWel1ZpwKRc86oKITmn2x8Q/pBLMPYdkrLgOVuJMtJwuJETTd94IimKKV+ofyatuXJvl5J1KEho= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2020 08:15:40.6540 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 558d9fd3-28d9-49e9-6c8a-08d80ea8cbad X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4353 Archived-At: X-Mailman-Approved-At: Fri, 12 Jun 2020 04:54:54 -0700 Subject: [Emu] draft-ietf-emu-eap-tls13-09 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: Fri, 12 Jun 2020 08:15:51 -0000 --_000_AM0PR08MB37167810AD2FA9E36DAE2418FA810AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I took a quick look at the -09 draft. Here are a few comments. 1. Introduction The text in the introduction is confusing. To be honest, this document is a= ctually not needed because TLS allows you to negotiate version and features= . Obviously, the introduction does not say that and instead dances around t= he reason of why this document is needed by saying TLS 1.3 made a lot of ch= anges but then concludes everything is backwards compatible. In more details, the first paragraph is fine. It talks about where EAP-TLS = is used. Then, the second paragraph says: " TLS 1.3 is in large parts a complete remodeling of the TLS handshake protocol including a different message flow, different handshake messages, different key schedule, different cipher suites, different resumption, different privacy protection, and record padding. This means that significant parts of the normative text in the previous EAP-TLS specification [RFC5216] are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, aspects such as resumption, privacy handling, and key derivation need to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). " The change from 1.2 to 1.3 is certainly larger than the change from 1.1. to= 1.2. For the user of the EAP method not much has changed though. In fact, you ca= n seamless switch from one version of TLS to the next version. In fact, you say that in the next paragraph: " While this document updates EAP-TLS [RFC5216], it remains backwards compatible with it and existing implementations of EAP-TLS. " In the last paragraph you say: " Privacy is mandatory and achieved without any additional round-trips, revocation checking is mandatory and easy with OCSP stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. " You have some specific features in mind when you talk about "privacy" and I= wonder what those are. In what sense is revocation checking mandatory? OCSP stapling has been a fe= ature before. What is this issue about fragmentation? As you know from your work on the o= ther document, fragmentation is really introduced by certificates. The cert= ificate format in TLS 1.3 has not changed. Before you answer these questions look at my suggestion below. I would delete large part of the introduction and basically leave the first= paragraph intact and then add the following sentences: " EAP-TLS [RFC5216] references TLS 1.0 [= RFC2246] and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are formally deprecated and prohibited to negotiate and use [I-D.ietf-tls-oldversions-deprecate]. Weaknesses foun= d in TLS 1.2, as well as new requirements for security, privacy, and reduced latency has led to the specification of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. This specification updates RFC 5216 and updates the description to cover TLS 1.3. Security and privacy considerations of this EAP method are updated to reflected the improved security and privacy functionality of TLS 1.3. " Section 2.1 Delete this paragraph. It does not say much. TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not a= pply for TLS 1.3 (or higher). Section 2.1.1 Many client certificates contains an identity such as an email address, which is already in NAI format. A NAI looks like an email address but actually isn't. " The EAP server MUST authenticate with a certificate and SHOULD require the EAP peer to authenticate with a certificate. " You might want to mention the emergency services use case here. You do much= later in the document but I believe this is the first occurrence of the se= rver-side only authentication concept. " Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption. " What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder= why you want to rule that use case out? It is a perfectly fine use case fo= r TLS 1.3 and there is even the possibility to use PSK with ECDHE. What is = the motivation? " SessionID is deprecated in TLS 1.3 and the EAP server SHALL ignore the legacy_session_id field if TLS 1.3 is negotiated. " I am curious why you are pointing out this change in TLS 1.3. Yes, the sess= ion id field has been deprecated and the session resumption concept was har= monized but for the EAP layer this appears to be irrelevant. " After the TLS handshake has completed and all Post-Handshake messages have been sent, the EAP server sends EAP-Success. " I think you have to be more precise here with your recommendations regardin= g post-handshake messages. The following paragraph from the same section (b= ut later in the text) appears relevant to this topic. " When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support of resumption in the initial authentication. To indicate support of resumption, the EAP server sends a NewSessionTicket message (containing a PSK and other parameters) after it has received the Finished message. " Unfortunately, it is not entirely correct. It is not the EAP server role th= at makes this session resumption support indication but it is a feature of = TLS. So, you might want to change the sentence to: " When using session resumption in TLS 1.3, a NewSessionTicket message is = sent as a post-handshake message. " " As stated in [RFC5216], the TLS cip= her suite shall not be used to protect application data. This applies also for early application data. When EAP-TLS is used with TLS 1.3, early application data SHALL NOT be used. " You might want to say that TLS 1.3 in EAP is only used for authentication a= nd the establishment of keys rather than for application data protection. T= hen, this paragraph becomes more understandable for someone not familiar wi= th the network access authentication concept in general. In Figure 1 you show the "Commitment Message" and I was wondering why you n= eed it. You talk about it later in Section 2.5 but I still don't get it. Th= is appears to be an unnecessary deviation from the TLS 1.3 implementation. Btw, I would give Figure 1 the following title "EAP-TLS 1.3: Full Public Ke= y-based Exchange with mutual authentication". In Figure 2 you show the NewSessionTicket message and this is one possible = exchange. I believe you can also add the NewSessionTicket message right aft= er the Finished message and thereby saving an extra roundtrip, if you want. 2.1.2. Ticket Establishment " This is a new section when compared to [RFC5216]. " While it is new to RFC 5216 it is not new at all in context of https://tool= s.ietf.org/html/rfc5077 I don't understand why you introduce a section 2.1.2 for ticket establishme= nt and a separate section 2.1.3 on resumption when the two actually belong = together. I suggest to combine the two sections and to call them Resumption= . TLS 1.3 combined three mechanisms into one: PSK-based authentication, cla= ssic session resumption and session resumption without server-side state. " TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange. When EAP-TLS is used with TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism compatible with that version of TLS. " I would delete this paragraph because it states the obvious. You state that EAP peers and EAP servers should use the client tracking pre= ventions and then you make recommendations regarding the NAI construction i= n the following paragraph. How do you see the two to interwork? " As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply a "key_share" extension when attempting resumption, which allows the EAP server to potentially decline resumption and fall back to a full handshake. " This is not a good advice IMHO. In the deployments where EAP-TLS is used th= e EAP peer and the EAP server know quite well what the other parties do and= being as conservative as in the web environment does not appear to be appr= opriate. Considering that the key share(s) cost a fair amount of computatio= n and over-the-wire bandwidth, I would actually recommend the opposite. It = is more likely that the EAP exchange succeeds. If you are uncertain, make no recommendations and explain the tradeoffs ins= tead. " Also during resumption, the server can respond with a Hello Retry Request (see Section 2.1.6) or issue a new ticket (see Section 2.1.2) " Not sure why you are stating this. This issue is explained in great detail = in the TLS 1.3 specification. I would not repeat the TLS 1.3 here. 2.1.4. Termination " TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, some normative text in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3 or higher. " I would not repeatedly make this statement. 2.1.8. Privacy TLS 1.3 significantly improves privacy when compared to earlier versions of TLS by forbidding cipher suites without confidentiality and encrypting large parts of the TLS handshake including the certificate messages. This is not the entire privacy story in TLS 1.3. IMHO TLS 1.2 already had n= o ciphersuites that allowed integrity only. TLS 1.3 got rid of RSA key transport. TLS also added improved padding and b= etter unlinkability support for session resumption. I stop here for now. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB37167810AD2FA9E36DAE2418FA810AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I took a quick look at the -09 draft.

 

Here are a few comments.

 

 

1.  Introduction

 

The text in the introduction is confusing. To = be honest, this document is actually not needed because TLS allows you to n= egotiate version and features. Obviously, the introduction does not say that and instead dances around the reason of why= this document is needed by saying TLS 1.3 made a lot of changes but then c= oncludes everything is backwards compatible.

 

In more details, the first paragraph is fine. = It talks about where EAP-TLS is used.

 

Then, the second paragraph says:

 

“

   TLS 1.3 is in large parts a c=
omplete
   remodeling of the TLS handsha=
ke protocol including a different
   message flow, different hands=
hake messages, different key schedule,
   different cipher suites, diff=
erent resumption, different privacy
   protection, and record paddin=
g.

 

This means that significant parts of<=
/o:p>
   the normative text in the pre=
vious EAP-TLS specification [RFC5216]
   are not applicable to EAP-TLS=
 with TLS 1.3 (or higher).  Therefore,
   aspects such as resumption, p=
rivacy handling, and key derivation need
   to be appropriately addressed=
 for EAP-TLS with TLS 1.3 (or higher).

 

“

 

The change from 1.2 to 1.3 is certainly larger= than the change from 1.1. to 1.2.

 

For the user of the EAP method not much has ch= anged though. In fact, you can seamless switch from one version of TLS to t= he next version.

 

In fact, you say that in the next paragraph:

 

“

   While this document updates E=
AP-TLS [RFC5216], it remains backwards
   compatible with it and existi=
ng implementations of EAP-TLS.

"

 

In the last paragraph you say:

 

“

   Privacy is mandatory and achieved= without any additional round-trips,

   revocation checking is mandatory = and easy with OCSP stapling, and TLS

   1.3 introduces more possibilities= to reduce fragmentation when

   compared to earlier versions of T= LS.

“

 

You have some specific features in mind when you tal= k about “privacy” and I wonder what those are.

 

In what sense is revocation checking mandatory? OCSP= stapling has been a feature before.

 

What is this issue about fragmentation? As you know = from your work on the other document, fragmentation is really introduced by= certificates. The certificate format in TLS 1.3 has not changed.

 

Before you answer these questions look at my suggest= ion below.

 

I would delete large part of the introduction and ba= sically leave the first paragraph intact and then add the following sentenc= es:

 

“

EAP-TLS [RF=
C5216] references TLS 1.0 [RFC2246] and TLS=
 1.1 [RFC4346],=

but works perfectly also with TLS 1.2 [RFC5246].  TLS 1.0=
 and 1.1 are
formally deprecated and prohibited to nego=
tiate and use
[I-D.ietf-tls-oldversions-depre=
cate].  Weaknesses found in TLS 1.2,
as well as new requirements for security, =
privacy, and reduced
latency has led to the specification of TL=
S 1.3 [RFC8446], whi=
ch
obsoletes TLS 1.2 [RFC5246].

 

This specification updates RFC 5216 and update= s the description to  

cover TLS 1.3. Security and privacy considerat= ions of this EAP method

are updated to reflected the improved security= and privacy functionality

of TLS 1.3.  

”

 

Section 2.1

 

Delete this paragraph. It does not say much.

 

   TLS 1.3 changes both the mess=
age flow and the handshake messages
   compared to earlier versions =
of TLS.  Therefore, much of Section 2.1
   of [RFC5216] does not apply for TLS 1.3 (or higher).

 

Section 2.1.1

 

   Many client certificates=

   contains an identity such as =
an email address, which is already in
   NAI format.  =

 

A NAI looks like an email address but actually isn&#= 8217;t.

 

 

“

   The EAP server MUST authentic=
ate with a certificate and SHOULD
   require the EAP peer to authe=
nticate with a certificate.

“

 

You might want to mention the emergency services use= case here. You do much later in the document but I believe this is the fir= st occurrence of the server-side only authentication concept.

 

 

“

Pre-Shared Key (PSK) authentication SHALL =
NOT be used except
   for resumption. 

“

 

What you want to say that that EAP-TLS MUST NOT use = external PSKs. I wonder why you want to rule that use case out? It is a per= fectly fine use case for TLS 1.3 and there is even the possibility to use P= SK with ECDHE. What is the motivation?

 

“

SessionID is deprecated in TLS 1.3 and the=
 EAP
   server SHALL ignore the legac=
y_session_id field if TLS 1.3 is
   negotiated.=

“

 

I am curious why you are pointing out this change in= TLS 1.3. Yes, the session id field has been deprecated and the session res= umption concept was harmonized but for the EAP layer this appears to be irr= elevant.

 

“

   After the TLS handshake has c=
ompleted and all Post-Handshake messages
   have been sent, the EAP serve=
r sends EAP-Success.

"

 

I think you have to be more precise here with your r= ecommendations regarding post-handshake messages. The following paragraph from the same section (bu= t later in the text) appears relevant to this topic.

“

   When using EAP-TLS with TLS 1.3, the EAP serv=
er MUST indicate support
   of resumption in the initial authentication.&=
nbsp; To indicate support of
   resumption, the EAP server sends a NewSession=
Ticket message
   (containing a PSK and other parameters) after=
 it has received the
   Finished message.

“<=
o:p>


Unfortunately, it is not entirely correct. It is not the EAP server ro=
le that makes this session resumption support indication but it is a featur=
e of TLS. So, you might want to change the sentence
 to: 


 


“


   When using session resumption in TLS 1.3, a N=
ewSessionTicket message is sent as a post-handshake message. 


“


 


&nb=
sp;


“<=
o:p>


   As stated in [RFC5=
216<=
/a>], the TLS cipher suite shall not be used to=



   protect application data.  This applies =
also for early application


   data.  When EAP-TLS is used with TLS 1.3=
, early application data


   SHALL NOT be used.

“


 


You might want to say that TLS 1.3 in EAP is only used for authenticat=
ion and the establishment of keys rather than for application data protecti=
on. Then, this paragraph becomes more understandable
 for someone not familiar with the network access authentication concept in=
 general.



 


In Figure =
1 you show the “Commitment Message=
” and I was wondering why you need it. You talk about it later in Sectio=
n 2.5 but I still don’t get it. This appears to be an unnecessary dev=
iation from the TLS 1.3 implementation. 


 =
;


Btw, I wou=
ld give Figure 1 the following title “EAP-TLS 1.3: Full Public Key-ba=
sed Exchange with mutual authentication”. 

 


In Figure 2 you show the NewSessionTicket message and this is one poss=
ible exchange. I believe you can also add the NewSessionTicket message righ=
t after the Finished message and thereby saving
 an extra roundtrip, if you want. 


 


=
2.1.2. 
 Ticket Establishment


 


“


   This is a new section when compared to [RFC5216].


"


 


While it is new to RFC 5216 it is not new at all in contex=
t of https://tools.ietf.org/htm=
l/rfc5077


 


I don’t understand why you introduce a section 2.1.2 for ticket =
establishment and a separate section 2.1.3 on resumption when the two actua=
lly belong together. I suggest to combine the two sections
 and to call them Resumption. TLS 1.3 combined three mechanisms into one: P=
SK-based authentication, classic session resumption and session resumption =
without server-side state.



 


 


“


   TLS 1.3 replaces the session resumption mecha=
nisms in earlier


   versions of TLS with a new PSK exchange. =
; When EAP-TLS is used with


   TLS version 1.3 or higher, EAP-TLS SHALL use =
a resumption mechanism


   compatible with that version of TLS.


“


 


I would delete this paragraph because it states the obvious.



 


You state that EAP peers and EAP servers should use the client trackin=
g preventions and then you make recommendations regarding the NAI construct=
ion in the following paragraph. How do you see
 the two to interwork? 


“<=
o:p>


As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD =
supply


   a "key_share" extension when attemp=
ting resumption, which allows the


   EAP server to potentially decline resumption =
and fall back to a full


   handshake.


"


 


This is not a good advice IMHO. In th=
e deployments where EAP-TLS is used the EAP peer and the EAP server know qu=
ite well what the other parties do and being as
 conservative as in the web environment does not appear to be appropriate. =
Considering that the key share(s) cost a fair amount of computation and ove=
r-the-wire bandwidth, I would actually recommend the opposite. It is more l=
ikely that the EAP exchange succeeds.



If you are uncertain, make no recomme=
ndations and explain the tradeoffs instead.



“<=
o:p>


   Also during resumption, the server can respon=
d with a Hello Retry


   Request (see Section 2.1.6) or i=
ssue a new ticket (see Section 2.1.2)=



"


Not sure why you are stating this. Th=
is issue is explained in great detail in the  TLS 1.3 specification. I=
 would not repeat the TLS 1.3 here.



=
2.1.4. 
 Termination


 


"


TLS 1.3 changes both the message flow and the handshake me=
ssages


   compared to earlier versions of TLS.  Th=
erefore, some normative text


   in Section 2.1.3 of [RFC5216] does not apply fo=
r TLS 1.3 or higher.


“<=
o:p>


I would not repeatedly make this stat=
ement.



&nb=
sp;


=
2.1.8=
=
.&nbs=
p;
 Privacy


 


 


 


   TLS 1.3 significantly improve=
s privacy when compared to earlier


   versions of TLS by forbidding=
 cipher suites without confidentiality


   and encrypting large parts of=
 the TLS handshake including the


   certificate messages.


 


This is not the ent=
ire privacy story in TLS 1.3. IMHO TLS 1.2 already had no ciphersuites that=
 allowed integrity only.



TLS 1.3 got rid of =
RSA key transport. TLS also added improved padding and better unlinkability=
 support for session resumption.



 


I stop here for now=
. 


 


Ciao


Hannes


 
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB37167810AD2FA9E36DAE2418FA810AM0PR08MB3716eurp_-- From nobody Fri Jun 12 17:06:05 2020 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 E0C4D3A0A5F for ; Fri, 12 Jun 2020 17:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aalto.fi 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 NQh_QJFHpgYl for ; Fri, 12 Jun 2020 17:06:01 -0700 (PDT) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) (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 226703A0A55 for ; Fri, 12 Jun 2020 17:06:00 -0700 (PDT) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E563E11573F_EE41863B; Sat, 13 Jun 2020 00:05:55 +0000 (GMT) Received: from exng4.org.aalto.fi (exng4.org.aalto.fi [130.233.223.23]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng4.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTPS id 7B08611572B_EE41863F; Sat, 13 Jun 2020 00:05:55 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng4.org.aalto.fi (130.233.223.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sat, 13 Jun 2020 03:05:55 +0300 Received: from exng6.org.aalto.fi ([fe80::3dc2:a1e7:902b:1296]) by exng6.org.aalto.fi ([fe80::3dc2:a1e7:902b:1296%17]) with mapi id 15.01.1979.003; Sat, 13 Jun 2020 03:05:55 +0300 From: Aura Tuomas To: Hannes Tschofenig , EMU WG Thread-Topic: eap-noob Thread-Index: AdY9daurhhDfbfAXQfql56Pf802ImwDmlZXg Date: Sat, 13 Jun 2020 00:05:55 +0000 Message-ID: <550918638bf043d1946463cbd3e9cbb3@aalto.fi> References: <13526_1591615540_5EDE2033_13526_154_1_AM0PR08MB371626BE44457F8C0B6170F5FA850@AM0PR08MB3716.eurprd08.prod.outlook.com> In-Reply-To: <13526_1591615540_5EDE2033_13526_154_1_AM0PR08MB371626BE44457F8C0B6170F5FA850@AM0PR08MB3716.eurprd08.prod.outlook.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.233.0.5] Content-Type: multipart/alternative; boundary="_000_550918638bf043d1946463cbd3e9cbb3aaltofi_" MIME-Version: 1.0 X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=from:to:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=its18; bh=LqqCYtyWKMkaYcEt8hVhvCL++w8sspd9vwYJPj/GUXo=; b=YOtJ5qqYM86/4Uqlmndq0kAPd/UbjagT/7TEE4/XvSH21cUcRlTGc3+j+i9LtBRqDT5d0r0nT7EuEeBJOqxlxrixkw57ZUtcThPS/c8pTuxALZ5GieQQXmkmbIhDzyLcYy8P7JOcib0zlAEPO3187BSPS+ELupcBgk1vfyT8jCQ1QAtBRp5H4NPAYzHenZd7aXkpj7vdwQgjrLW3mzx0lMNcysCI+bWXi7XhT6H4knx8Uafu2eoVA0PlSotR07dJQhfY3UsI4bbQFPNqnPbgd9tuOtEYSPPG+rgf6Hb6akqjmsxW3PprIuPg4+KMtXXGtSPchIOT+lVxFjxvF+erUg== Archived-At: Subject: Re: [Emu] eap-noob 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, 13 Jun 2020 00:06:04 -0000 --_000_550918638bf043d1946463cbd3e9cbb3aaltofi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 6/8/20 2:25 PM, Hannes Tschofenig wrote: > Hi all > I read through draft-aura-eap-noob-08 during the call for adoption. > The draft acknowledges that the concept of "onboarding" is a new term for= an old concept, namely network access authentication. I like the draft fro= m that point of view. > The content looks fine good and the design is well described. There is a = formal analysis available and sample code available. Thank you for taking the time to review, and also for the positive feedback= . > I believe it would be good to note that the solution does not support any= form of cloning prevention because the device is assumed to be "blank" fro= m the point of view of keying material. This is a good point. We'll add text in the security considerations. All bl= ank devices are treated the same in EAP-NOOB. Thus, technically you can mak= e as many clones of a blank device as you want. To prevent cloning, the pro= tocol could be extended to bind the peer identity a TEE. > I was wondering about one aspect, and maybe I missed it somewhere: what = are you actually authenticating? > The identifier for the client is assigned by the EAP server. The server i= s also unknown at the start of the protocol. The peer device is authenticated based on the fact that the user has physic= al access to it. The user typically authenticates the server based on a web= certificate, but that depends on the OOB channel. EAP-NOOB is akin to devi= ce-pairing protocols (such as Bluetooth); the difference is that, instead o= f associating two devices with each other, EAP-NOOB associates a device wit= h a server (and a user account in the server). > I also got the impression that the authors are not entirely sure about re= peating the OOB step. Earlier in the document it sounds like the authors do= not really like the idea to repeat it and then later in the document they = acknowledge that it will be necessary to deal with it anyway. Am I reading = in-between the lines here? I think this point could be written more clearly in the draft. It is mentio= ned multiple times because one of our most important goals for the design w= as to avoid repeating the OOB step after a successful association whenever = it possibly can be avoided. In the protocol, this means creating an associa= tion that will be used for reauthentication, and that a temporary network o= r server failure should not cause the peer device to go back to its initial= state. The protocol also supports rekeying and, unlike typical OOB pairing= protocols, algorithm update (ECDH curve update) without a new OOB step. T= he exception is that, if the device or server lose the association state, t= here is no way to recover without resetting also the other endpoint. > There is also a not-so-bright side of this draft: the deployment. The sol= ution places many constraints on potential solutions, the authors have litt= le influence on the deployment environment, the use of EAP is not that comm= on in IoT communication technologies, there are many other competing soluti= ons, etc. This is a reasonable point to make about EAP-NOOB and for EAP more generall= y. There is always tension between generic protocols like EAP and proprieta= ry or technology-specific solutions. The advantages of EAP include the abil= ity to change the authentication method without changing anything else in y= our protocol and system, independence of the lower-layer technology, lower = cost of application development given the existing specifications and imple= mentations, and ready support for roaming. For example 3GPP moved from tech= nology-specific protocols to EAP, and they must see some advantage in it. I= t escapes me why 802.11 has not given up on the non-EAP authentication meth= ods that add lots of complexity to their specification. > Ciao > Hannes Thank you again for your comments. Tuomas --_000_550918638bf043d1946463cbd3e9cbb3aaltofi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On 6/8/20 2:25 PM, Hannes Tschofenig wrote:

> Hi all

 

> I read through draft= -aura-eap-noob-08 during the call for adoption.  

> The draft acknowledg= es that the concept of “onboarding” is a new term for an old co= ncept, namely network access authentication. I like the draft from that poi= nt of view.

> The content looks fi= ne good and the design is well described. There is a formal analysis availa= ble and sample code available.

 

Thank you for taking the time to review, and also fo= r the positive feedback.

> I believe it would b= e good to note that the solution does not support any form of cloning preve= ntion because the device is assumed to be “blank” from the poin= t of view of keying material.

 

This is a good point. We'll add text in the security= considerations. All blank devices are treated the same in EAP-NOOB. Thus, = technically you can make as many clones of a blank device as you want. To p= revent cloning, the protocol could be extended to bind the peer identity a TEE.

>  I was wonderin= g about one aspect, and maybe I missed it somewhere: what are you actually = authenticating?

> The identifier for t= he client is assigned by the EAP server. The server is also unknown at the = start of the protocol.

 

The peer device is authenticated based on the fact t= hat the user has physical access to it. The user typically authenticates th= e server based on a web certificate, but that depends on the OOB channel. E= AP-NOOB is akin to device-pairing protocols (such as Bluetooth); the difference is that, instead of associat= ing two devices with each other, EAP-NOOB associates a device with a server= (and a user account in the server).

> I also got the impre= ssion that the authors are not entirely sure about repeating the OOB step. = Earlier in the document it sounds like the authors do not really like the i= dea to repeat it and then later in the document they acknowledge that it will be necessary to deal with it anyway= . Am I reading in-between the lines here?

I think this point could be written more clearly in the draft. It is men= tioned multiple times because one of our most important goals for the desig= n was to avoid repeating the OOB step after a successful association whenev= er it possibly can be avoided. In the protocol, this means creating an association that will be used for rea= uthentication, and that a temporary network or server failure should not ca= use the peer device to go back to its initial state. The protocol also supp= orts rekeying and, unlike typical OOB pairing protocols, algorithm update (ECDH curve update) without a new = OOB step.  The exception is that, if the device or server lose the ass= ociation state, there is no way to recover without resetting also the other= endpoint.

> There is also a not-= so-bright side of this draft: the deployment. The solution places many cons= traints on potential solutions, the authors have little influence on the de= ployment environment, the use of EAP is not that common in IoT communication technologies, there are many other co= mpeting solutions, etc.

This is a reasonable point to make about EAP-NOOB and for EAP more gener= ally. There is always tension between generic protocols like EAP and propri= etary or technology-specific solutions. The advantages of EAP include the a= bility to change the authentication method without changing anything else in your protocol and system, indepen= dence of the lower-layer technology, lower cost of application development = given the existing specifications and implementations, and ready support fo= r roaming. For example 3GPP moved from technology-specific protocols to EAP, and they must see some advantag= e in it. It escapes me why 802.11 has not given up on the non-EAP authentic= ation methods that add lots of complexity to their specification.

> Ciao

> Hannes

 

Thank you again for your comments.

Tuomas

--_000_550918638bf043d1946463cbd3e9cbb3aaltofi_-- From nobody Fri Jun 12 17:40:18 2020 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 463973A0CB1; Fri, 12 Jun 2020 17:40:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Dave Thaler via Datatracker To: Cc: draft-ietf-emu-eap-noob.all@ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159200881222.13853.13790945720958773822@ietfa.amsl.com> Reply-To: Dave Thaler Date: Fri, 12 Jun 2020 17:40:12 -0700 Archived-At: Subject: [Emu] Iotdir early review of draft-ietf-emu-eap-noob-01 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: Sat, 13 Jun 2020 00:40:12 -0000 Reviewer: Dave Thaler Review result: Ready with Issues A marked up copy with my comments inline, including editorial nits not covered in this email is at https://www.microsoft.com/en-us/research/uploads/prod/2018/06/draft-ietf-emu-eap-noob-01.pdf (a Word version is also available if requested, but the PDF should suffice). See change tracking in red throughout the PDF for editorial nits. Summary of issues: Applicability ------------- 1) The document states that it does not support static printed registration codes. It would benefit from stating the *rationale* for not supporting things like QR code stickers. E.g., does the WG believe that such things are less secure? The document does say this "also" prevents attacks where a static secret code would be leaked, but the use of "also" implies that's not the main rationale. 2) Section 3.2.5 says: > A peer that has not received an OOB message MUST wait at > least the server-specified minimum waiting time in seconds This means that this protocol cannot be easily implemented in IoT devices that have no relative time clock. Does EAP itself already have this limitation regardless of EAP method? If not, it would be good to call this out, since this limits applicability to constrained devices. Maybe add an "Applicability" section like EAP (RFC 3748) section 1.3 has. 3) Section 3.3.2 says: > The in-band messages are formatted as JSON objects [RFC8259] So this limits applicability to constrained IoT devices, since JSON can be verbose compared to, say, CBOR, and if the IoT device already uses CBOR for its normal protocol use this requires adding a separate parser for JSON which may cause code size issues. Is there a rationale for why CBOR could not be an option? E.g., if this protocol is not applicable for constrained devices, then say so. (I don’t know whether EAP itself already inherently has problems that limit its applicability for constrained devices.) 4) Appendix E says: > The ServerInfo in this case includes a JSON member called ServerUrl > of the following format with maximum length of 60 characters: Just an observation: This limits applicability to servers that can get short hostnames (and paths), which might make it less applicable users in some cultures/languages. Interoperability ---------------- 5) Section 3.1 says: > The server and peer MAY implement user reset of > the association by deleting the state data from that endpoint. If an > endpoint continues to store data about the association after the user > reset, its behavior SHOULD be equivalent to having deleted the > association data. As phrased, there are 3 compliant behaviors: Behavior 1) Follow the MAY and delete the data Behavior 2) Don’t follow the MAY, do follow the If, and follow the SHOULD and act as if data was deleted Behavior 3) Don’t follow the MAY, do follow the If, and don’t follow the SHOULD and hence act in any other way. In my experience, such undefined behavior can cause interoperability issues. Is there any reason to permit behavior 3? Why can’t you make the SHOULD be a MUST (since the If already makes it conditional on implementations that don’t follow the MAY). 6) Section 3.2.5 says: > If the server has not sent any SleepTime > value, the peer SHOULD wait for an application-specified minimum time > (SleepTimeDefault). Since the minimum time is app-specified as this sentence says, what does it mean to not follow this SHOULD? I.e., why is it not a MUST? 7) Section 3.4.2 says: > The endpoints MAY send updated Realm, ServerInfo and PeerInfo objects > in the Reconnect Exchange. So if this MAY is not followed, does that mean any updates are not sent at all, or that they are sent via some other mechanism? 8) Appendix C says: > They contain > JSON objects whose structure may be specified separately for each > application and each type of OOB channel. It doesn’t look like you’re specifying an IANA registry to contain field names. Given that, how do you get interoperability? If every app and type of OOB channel specifies a different structure, how do you do capability negotiation to agree on which structure definition is being used? (Since two specifications might use the same field names for very different purposes, in theory.) I didn’t see any identifier that can be used as the “type” of the ServerInfo or PeerInfo data. Attacks and mitigations ----------------------- 9) Section 3.1 says: > For example, consider a printer > (peer) that outputs the OOB message on paper, which is then scanned > for the server. Elaborate on this use case… Is the assumption that the printer would automatically consume paper in response to any unauthenticated message (hence being a resource consumption attack)? Or that it would only do so after getting approval from a human to output the OOB message? 10) Section 6.3 discusses misbinding attacks, but another attack is where a rogue device keeps generating random IDs (MAC, etc.) in order to cause havoc with the server, whether that’s a memory attack, or an attempt to cause so much UI noise to users that it DoS’s the user's ability to add valid devices. I didn't see such attacks discussed. Internationalization -------------------- 11) Section 3.4.1, Table 2, says about PeerId: > UTF-8 string (typically 22 bytes) Top of page 17 says “Another way to generate the identifiers is to choose a random 22-character alphanumeric string” and “alphanumeric” is defined at https://www.merriam-webster.com/dictionary/alphanumeric as being letters and numbers. Unicode of course does not restrict “letters” or “numbers” to ascii. Note that a UTF-8 character can be anywhere from 1 to 4 bytes long. A 22 character string could thus be up to 88 bytes long. The word “typically” means you think ASCII (1 byte UTF-8) is typical. If you meant ASCII back on page 17 (and I suspect you did), then say so there. Otherwise, change this to “characters”. 12) Section 3.4.3 says: > including situations where the server does not recognize the PeerId The server “recognizing” the PeerId implies that it compares it to existing state, but PeerId is a utf-8 string. Is comparison to be done byte-wise? (I.e., it must match exactly, with no differences in NFC vs NFD, or half-width vs full-width, or case, or punycode-encoded realm vs not, etc.) If I understand correctly, the peerId is assigned by the server, and sent back to the same server, and does not need to be entered by a human or be in any specific form the peer would use natively, and so a byte-wise comparison should suffice and you can say that explicitly. 13) Table 11 says, about SSIDList and Base64SSIDList: > JSON array of UTF-8 encoded SSID strings. and similarly for SSID in table 12. And appendix D says: > If present, the peer MAY use this list as a hint to determine the > networks where the EAP-NOOB association can be used for access > authorization This is pretty vague. Is the SSID supposed to be normalized in any way (normalization form, half-width vs full-width, etc.)? Is the peer responsible for normalizing the SSIDList Unicode strings if it needs to match the networks? Or is the server responsible for sending them in a normalized form that the AP expects? Miscellaneous ------------- 14) Section 4.3 reserves space for Experimental Use. https://tools.ietf.org/html/rfc8126#section-4.2 says: “When code points are set aside for Experimental Use, it's important to make clear any expected restrictions on experimental scope. For example, say whether it's acceptable to run experiments using those code points over the open Internet or whether such experiments should be confined to more closed environments. See [RFC6994] for an example of such considerations.” 15) Table 11 says, about SSIDList: > List of wireless network identifier (SSID) > strings used for roaming support, ... Is table 11 specific to 802.11? Or is this suggesting that SSIDList is a field not specific to 802.11 SSIDs? Same question on table 12. 16) Table 12 says MACAddress and BSSId are EUI-48 strings. Are both upper case A-F and lower case a-f allowed? 17) Section 6.4 says: > Without > verification by the user or authentication with vendor certificates > on the application level, the PeerInfo is not authenticated > information and should not be relied on. The PeerInfo can be anything, right? So draft-ietf-rats-eat could be used as the PeerInfo structure to provide attestability of the information for example. I'd suggest at least mentioning that attestation could be used with the PeerInfo to provide such authentication. (Optionally add an informative reference to draft-ietf-rats-eat as a "for example", but ok if you choose not to reference it.) From nobody Mon Jun 15 02:30:28 2020 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 530A33A0A6C; Mon, 15 Jun 2020 02:30:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <159221342328.21045.2689244767183553030@ietfa.amsl.com> Date: Mon, 15 Jun 2020 02:30:23 -0700 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eaptlscert-05.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: Mon, 15 Jun 2020 09:30:23 -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 : Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods Authors : Mohit Sethi John Mattsson Sean Turner Filename : draft-ietf-emu-eaptlscert-05.txt Pages : 14 Date : 2020-06-15 Abstract: EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round-trips is a major deployment problem. This document looks at the this problem in detail and describes the potential solutions available. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-eaptlscert-05 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-05 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 Mon Jun 15 02:31:17 2020 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 E43F33A0B68 for ; Mon, 15 Jun 2020 02:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 TbZIVyaWv-vZ for ; Mon, 15 Jun 2020 02:31:14 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60050.outbound.protection.outlook.com [40.107.6.50]) (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 6CDD03A0B25 for ; Mon, 15 Jun 2020 02:31:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kAJLF9kdux+Mq/BLofQRrOzwQFJwwzJiEp4f5sMTshPJYtsqCihGCqbFnXt28KZqKVHsJZxP0lNE+xhzRYiFtT3mtUf45IEA5lc7Abh/fwXMwiogRPzY1yEKqnqj1QiVjNoUmuWSPKGIsMNvUtpwrhlJQoJ0eC+5nQCUlEPO9AlH85mWhIfwmg0+BkcjhdlJEEnakSLgh+cSlRw6LqhklVkhdqNBU2PAzqJDgHhitSBnNNZAyGDu3eK3a57T2I3cPjrj4wUzyVtJCs2vB/4bKIrSm9GVvFvwvt+KPHdbcvKM78DyL+tLGExUoRIDwhYfDS6FE+JtkCB6g2F6eVYKJQ== 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=/rMpMRR90HL96w54IaqyCntQ/Oslrjd9uq2OFa95XUM=; b=nKxWwTbSBrIddhX2OcpZ8D/RBQD7ufHMHDVr/ws2EhUTmcsGivJ2NcgZ674t3hTI+09HxVkuLD1WkCvveabUva+bl4mHz0Nlq7XV5U9wIPdluFpYR2LsEpVKxSK2fZh77bkA/MhThMGHdJBN0TnwQ1ABUm8o6BrAEHZ2lpNvRb5TIGIl+rgD3eFRGF4cMiJorN2TebWOpJjFIdrRrMyurHCsCI9747JJQxs+E/yr7J6UQt3b8gZiP98MBP0NGsfLJtR2xaahuRkh71UEcwHgUKX6My/iC1g9Mwp5vi60C11I7J//uBbg2DQbp9V0i4UUCh9vXIEKXHAfsZzM+DWuQQ== 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=/rMpMRR90HL96w54IaqyCntQ/Oslrjd9uq2OFa95XUM=; b=M+9LjkBBc+WrWQtx0HKSudpwxsGGT1NcrNJAGAvbXIqA1tP5fkyxJWUd4VNx1O2Jmxqf7yiidQQRJ9iuudGHiFSnjzo6GB9lbQrA5NVQfF6CQ5qJcMIW3Ncjg5ho/xR0J5QhQ/ctR3ENxGdu+ilMn+9PaA1RqSfUv9BPjz0XqrI= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR0701MB2554.eurprd07.prod.outlook.com (2603:10a6:3:94::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.11; Mon, 15 Jun 2020 09:31:04 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e%7]) with mapi id 15.20.3109.010; Mon, 15 Jun 2020 09:31:04 +0000 From: Mohit Sethi M To: Hannes Tschofenig , "emu@ietf.org" Thread-Topic: [Emu] draft-ietf-emu-eaptlscert-04 Thread-Index: AQHWQvevvXLTCVkc1kWEopXjeZvdfA== Date: Mon, 15 Jun 2020 09:31:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:4147:9db5:d2f7:7e10:bb6b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b17dfcd6-e152-4495-302d-08d8110ed30c x-ms-traffictypediagnostic: HE1PR0701MB2554: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Yjet4fdWT842Qim5QkQYPtFVhIl93g/384DEMUoivpmfY/iEHFoEAeYo2qsPx2q754OeP25Avg7aWMG3RB2plBoRurDfyRw5a7Y35fc+FwM/robx9AwuGj7B8Z2mZObNMnmEGlax9UGuVEYuBFVZBBMOeqYpX5Vc87f90115Y13efDo1DCxm8Ojw2x2lBH4kYyjLMSN++3JDfqp2St+bXtw/XRACsBM1IVsZyG1XG73KwO9y28h+0JE4WgBRSZ2NeXt3ZEDtMjh6Kkdi9KYoL66l2KEGfVEt34yqDcWrpL60r+twucbKvtn+K0jfN2V+zGMco+NLtUZ5XwIuNkpXXlP/I7mD3M8UUzzdZAaDZg5fpkKQOnBMqErPv/gkbmODPxIx5WDimq4qbvCwAsR59M8Bv9cka+Zrx7ltw4qwKlSmrCIPkfrZ3WTyaHIPjyxcu0ZQ5WfH+ybC8B7xF9D+tw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(396003)(136003)(366004)(64756008)(66616009)(66476007)(6486002)(66556008)(76116006)(66446008)(86362001)(71200400001)(966005)(8936002)(6512007)(31696002)(5660300002)(66946007)(83380400001)(99936003)(8676002)(31686004)(186003)(478600001)(36756003)(6506007)(53546011)(2906002)(2616005)(110136005)(316002)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: x78VSqkDaGpz0eDiMSRadPyNjH8PZ0hB7gNM5N60H0Ru3xhd74GUVmf7UmFwVjRdmOjM97V/FHQOoqx6kscph53NXvUrNk8xVZROfEUJNkI+aP9d5b8WwYZWQai3iwm8ziUY2AwbM4aQMoMP8awoxcYQYpGvH/dchl/oTGhA3VQ/xy5fHjpOxX8YxCADFYr4WJPOKgEhPYPAAF6NXPsOJnQ1rSjZsdhfb5E5oshtaXX4KOchggQ5ALSsRy3l5rvFPinykXs2hmvVg/gnWiprE9bWUtGcmcDnqrmi7xCF5u4qf8QtWaafTEU9JENx13eE6A+tsfPlufAIWFl2GG74+lyU0a2/CAzVKmTmBRPFaYHuF5Ddjt/IkOlesEUWUKxgco+buoXrMibNJ7oIpSVC6rezfNXAUNOgmnpDhQ+LBjBW1W6Xh1yM/3ouDuNgYsJseA0UyNhLFRd2a7DhNd+wiDpudM+Eq5hiyqkMtYmpNTw/9V/CahRzrCaeUT6R50Hp0WqhGdkriN7p1tVw6uEskesJ7zFpj/ohyBHs/R3j48+nehbhBC/eaKfG7JbTDinr x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050406030507080209010105" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b17dfcd6-e152-4495-302d-08d8110ed30c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 09:31:03.9681 (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: Iq5+MAsnc76y1sM68shBkX0aGaNzF0m5gl8L0KhNK+XwCDYy3AZ/tM7CUmDFgiLU8LirB7/qoH0JFE33ftQR5POjpOQ7AEygyi6nrhr7BaY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2554 Archived-At: Subject: Re: [Emu] draft-ietf-emu-eaptlscert-04 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, 15 Jun 2020 09:31:16 -0000 --------------ms050406030507080209010105 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Hannes, Thanks for the follow up. I have submitted a new version which should=20 address your concerns. Here is a diff for your convenience: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eaptlscert-05 Please see in-line for details. I believe that the draft is now ready for publication. --Mohit On 6/10/20 12:02 PM, Hannes Tschofenig wrote: > Thanks for the update. > > A few more minor comments on -04: > > Section 4.1: > > "TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations= to support ECC." > > This is only true absent an application profile defining something else= =2E > The UTA group has just adopted a WG item that defines such a profile. > > Hence, I suggest to add the remark about the profile. Something like > > "In the absence of an application profile standard specifying > otherwise, a TLS 1.3-compliant application must support ECC." Done! > > 4.2. Updating TLS and EAP-TLS Code > > Why are you calling the section "updating code"? The suggestion in 4.2.= 1 does not require code update and whether something requires a code upda= te depends what you have in the code already. Maybe you just need to enab= le the feature. Updating the code is also a negative aspect because you = are likely going to update the code on a regular basis anyway to fix bugs= and to support new algorithms. Luckily TLS has the extension negotiation= built-in and hence you can detect and negotiate new features on the fly.= I agree that all code indeed should be updated to fix bugs and=20 vulnerabilities. However, updating applications and certificates is=20 certainly different from updating the underlying TLS library and EAP=20 implementation. Administrators in enterprise environments (where EAP-TLS = is widely used) have great control over when and how the server and=20 client updates are rolled out. The categorization in section 4 should=20 help administrators to decide how to avoid the fragmentation problem.=20 Whether it is issuing new certificates, updating the access points, or=20 updating the TLS and EAP-TLS implementation. Nonetheless, I have added=20 the following text: "This section discusses how the fragmentation=20 problem can be avoided by updating the underlying TLS or EAP-TLS=20 implementation. Note that in many cases the new feature may already be=20 implemented in the underlying library and simply needs to be taken into=20 use." > > 4.2.4. Caching Certificates > > "The extension however necessitates a successful full handshake before = any caching." > > This is not true. The spec defines a way to populate the cache by runni= ng a full handshake. > However, you could also populate the cache by out-of-band means, for ex= ample by pre-distributing certs. > > The mechanism to re-run the handshake to populate the cache is, however= , a safe fallback in case configuration changes and the pre-distributed c= erts become invalid. It is better to have a fallback. > > I thought I made that comment before. You had raised this issue before and I had responded to you before. Here = is the response again: Where does RFC 7924 (https://tools.ietf.org/html/rfc7924) talk about=20 populating the cache with an out-of-band mechanism? The text in Section=20 1 of RFC 7924 clearly states that:=C2=A0 "This specification defines a TL= S=20 extension that allows a client and a server to exclude transmission=20 information cached in an earlier TLS handshake.". Notice the "earlier=20 TLS handshake" part. I certainly refuse to add or describe new=20 functionality which isn't discussed in the original RFC. > > 4.2.3. Compact TLS 1.3 > > You are still stating "This naturally means that cTLS is not interopera= ble with previous versions of the TLS protocol." > > cTLS is a compression of TLS, which means that you can fall-back to TLS= , if the other peer does not support cTLS. As mentioned in my previous em= ail, I don't understand why you are mentioning this aspect at all given t= hat this document is about certificate size reduction. I understand your desire of making cTLS look good. I am not sure how=20 hiding the information that cTLS doesn't interoperate with older=20 versions of TLS helps. Anyhow, I have removed that sentence since=20 progressing the draft at this is stage is more important than arguing=20 over one sentence. > > Raw Public Keys > > I wonder whether you should mention the possibility to use RPKs (https:= //tools.ietf.org/html/rfc7250) in Section 4.1.2 because those would be a = fairly obvious choice in EAP-TLS given that we are talking about a nailed= up connection between the EAP peer and the EAP server. This would obviou= sly reduce the overhead associated with certificates considerably. Added a new sub-section. With this, I believe that all issues are resolved and the document is=20 ready for publication. > > Ciao > Hannes > > > IMPORTANT NOTICE: The contents of this email and any attachments are co= nfidential and may also be privileged. If you are not the intended recipi= ent, please notify the sender immediately and do not disclose the content= s to any other person, use it for any purpose, or store or copy the infor= mation in any medium. Thank you. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --------------ms050406030507080209010105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMUwggX7MIID46ADAgECAhBcf8Ki080s7KKjg2APnSBWMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEwMDgxMDAzMjJaFw0yMDEwMDgxMDAzMjFaMGgxETAPBgNV BAoMCEVyaWNzc29uMRYwFAYDVQQDDA1Nb2hpdCBTZXRoaSBNMSkwJwYJKoZIhvcNAQkBFhpt b2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZXNldG1vaDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAN23/VIr1UI1NLeaFL45vzBE0NglNKyyUQknMqT5zRxm ocJ74fYRJmfHmaQxEYdxp6cCYFxbM2OJOiMN5LRxEQG282Dsjnff6mHXt5wNsMrHZ88poT3X yZCzFBkQF/kswJKu6OD9v1J6WWl9fV2h0QRP0ju+B/H2O3OzioHDP9Qazzr5TMTvmRmXoMfh WXyH/joBaGVyn8SCeRaI0wVGRCKDp93UzdL5o+qGqCUPJQP/2SR/4UoCUTqEtSgh4iCBNAs/ OwhHwbWdU73/EJtsaaOG2fhwMTgWR3KJOIUMyWtRBcO9cIan+82SNgAByR4x2BKIWgFvSPNo GXKn1nOi0W0CAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1 c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUFBwEB BHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGm1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUM0z7o31aA+qQasQqDc7/Ppn7u5MwHwYDVR0jBBgwFoAUHHsZ npecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQCB 35yJmyIRJUmxQmpYX7hNdQJXxJdIAMzCe+rQsz+0F1zA8xsYn4Rn5m7SVGKbE4ONC+EUHHzQ o1OpA5txlK+IPRMqZTM2cQpAet8Qy2vRqFVd0pFDmPx0Az/SPooz7gnuIaPaCGeXOSSxtSOu rX+7fE2EiE/SuCFKmtsFmwnZH62hDDtzd3XTwmJia/5Ab+8/elAstT5a1cP52SorrkuLPgAB ny/XJzsU3LOQQ37Wm5DMyMPEK+zkBG/+2t1cOGgryvu7Hq14NfkAUZxHMei6Yf2UABNxbapB 4tyxqpZuPZDl1AwRKMGYHPsnywK4PZDdsD6R+O/YCWdfq9Q3MMCT3C6vu38phy1r6QDCVHVI IPdirDfZ2ypbeqHAwkswioykkBTln9DEyaTYMlxb41EYh/3JwUQmuQQ4ozSfcLTwoaQ+M+Z4 1J/n7AARwD7u3Lb2ls+fmvOLrC+tc0pXlvTKspIhpaNC1Cz7sbsjMSbSqBW9PtY+Vex7GB2J zI8fDHTT/8Jx+33cta2BE6mPFeUY2lu12zQiqNVUc9zEQ7WqGz4VTGFZDnzfU2gCAAYsuimf kQJD+Sr2G3wXs38yN1OhWHBuG1fglz0k5URhXMNC8HtRityIm2504ym5GpTrriJ8X1fQDYN1 WlOPvv4xJpfHAz4NMKJKQmCNtfuZ8BNNyTCCBsIwggSqoAMCAQICEFO4foPhnJkok7CbSRzs uOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRl bGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8A ALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL 7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhV W4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujn whljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W0 7nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBR QGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1 fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77 /NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioIT KffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAt BggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUF BzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQB gg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFz b25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVs aWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OOR auPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUA A4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNH CZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKv dASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQy sshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgb MgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6L kIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3T QYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX 2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDk ZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEBMFswRzELMAkGA1UE BhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlk dWFsIENBIHYzAhBcf8Ki080s7KKjg2APnSBWMA0GCWCGSAFlAwQCAQUAoIIBsTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MTUwOTMxMDJaMC8GCSqG SIb3DQEJBDEiBCD7z+RefnSn/IpFvgtyoIO4len9kH52DEHKYKZ8OEMF6zBqBgkrBgEEAYI3 EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQXH/CotPNLOyio4NgD50gVjBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMGwGCyqGSIb3 DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEFx/wqLTzSzsoqODYA+dIFYwDQYJKoZI hvcNAQEBBQAEggEAvP0dN0LZ8VJfXsIk84FbEenAWrzfZnV6oFPNfQu5bNCEhlNpwoZMqkPT eDAzgfRDFBYppO5btBiXymNPHEmB7yRGhehOS+I2J0tbzfgs29UnKRR2XCUuDCPf7ZlUVuEb 8DmICQuvI4UdZl8ftl647cSrNxx7qXoLnSkHVbyxYrIz5SrE4kilEigGd1oU2jMOqYXY5CwU 2St3xz/lKTUoRxf5f0nYpjHAGpj9L7eTOubcBF9QBLIsf4McrQdY7Gqw2HSCj0v2DHBDg3op /veYfoYI8u5VYDlODqyJG1V5mLY0TiUYXCu7Cd3XcxI69yFvxy3sdTuD4qJjl5Ope0UJTgAA AAAAAA== --------------ms050406030507080209010105-- From nobody Mon Jun 15 06:51:18 2020 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 494033A0D95 for ; Mon, 15 Jun 2020 06:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 gvtJqbdGtnJG for ; Mon, 15 Jun 2020 06:51:14 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60084.outbound.protection.outlook.com [40.107.6.84]) (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 1F5FB3A0D94 for ; Mon, 15 Jun 2020 06:51:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xqu6GOQzBdbipvWBrGwo9JlmTwr92DTXuZbxFc7Sm8WRRqkxwVlotdyODEsO/t/lCQ78JpQHNIweXdQYbVQFiJdAkGYiNIT+F4kaWxOAzCXBcR1dvZQhNZRMjAbQFrBj390lEFzqLMJCL4RGfa+ND6lkxorNYVsK9U6xs6PBgVVkl7xQgsMHxtbr8AiJ4e0KMgxISr6H6Trr8sJT7/wBG2VXQKmqkcSgcf5RJv9JWmyKndP+2Y5CL5/aik7TyoT4Wik6kslV7PvAP+8bHd4RAYekV2JYZUKy18APguobFHWfaZsf1LPApNakhRnHwRrKuoaLWJvdD8/L5JERASUHdA== 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=4uvJMTErScsoX38qMpFpLTiNc6G4wsYsc+k4Hai93qo=; b=Ki5uhbnzdItv/mPPizNm6GUXpcuKNioj9r4N2utyDPUB5Xq36QFjhNApw1fmf6g1JFt2wZKl8AQ/pMG38kRs3HxyB3n3oZUA0wMKkrKKcJEGGrosDsntofqOAb/BUG5Ao+w7shPYtwJQVEiDfI1iVG9TRLttsDEVITl1rUF1bCuUSnyOqtuyP1cReeyG6BNM0mcHcqTbxsjKhJRCvdc08dgoZDRJ1Vb8hyjk2wH3PMiOhh1+v6zny4v1wWJfoBoWN8CI8EiPzp02484qHtGU2/PIDZWz5WLmAQ4g73pIXo+lYUWbbbXiWuhpO+EawJ0NBvRFIqU7YxIluo95M5AEog== 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=4uvJMTErScsoX38qMpFpLTiNc6G4wsYsc+k4Hai93qo=; b=PgJfJOCb9cSbxq5nlW3+gSTSFBGsFz9XCS1c4zVEGhwIDhngYqQys2L5iCvhvK3DYoV4Z9XSo2pWs4re+9I3JlULFxOztbL1l7g+KsxCb/yiOSd1+Pz4Cqth0WpwwcgxGoU/t+1BwSFBApZ5sdPmvucKB6Ap+mRt2mnaZpNBGy8= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10; Mon, 15 Jun 2020 13:51:10 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e%7]) with mapi id 15.20.3109.010; Mon, 15 Jun 2020 13:51:09 +0000 From: Mohit Sethi M To: Hannes Tschofenig , "emu@ietf.org" Thread-Topic: [Emu] draft-ietf-emu-eap-tls13-09 Thread-Index: AQHWQxwEQ1vOCJx6OkCAyy8r1ceuEg== Date: Mon, 15 Jun 2020 13:51:09 +0000 Message-ID: <62ec9fad-583e-ed51-1f6c-dcfa3835c0ec@ericsson.com> 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.8.0 authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:4147:9db5:d2f7:7e10:bb6b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c30bc4ae-c69c-485c-5a6d-08d8113328d6 x-ms-traffictypediagnostic: HE1PR07MB3386: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GXjBqLGeQ2HEIsDyDtHkN/+bUQ+wJm6BWKqYC7DHBGdqc/kENcqqz2wLZE6vTv8+W36pPboa1p7iHWhzDoENtSF5Sf9w8DITAFaKEHoHqa7WzDN1wPMzz/8Y1KD1GoXAWvWI7m8NDmqnsf8piUfBhoK2uvwMKUoABx0UxLra1BzgHLahPdbzuiZPtQk+d7/onyvp9Yc9k0t7hqnyPmSfYmVU/q1X8R9fzAvrH9XOMsgz6jjflo8BsprSosP0f4Nb8OqPaJT3LmbfWoTjbU+j/zSVUn6I4Hu9yxWWdE4YIrJSsBENxky218uxOuRcntFtSxupiUw1N+v5KN4uP6L2iL/CjuGxmlkMkcZlImpgTvd67oDI4oE/V9ee4DQcwi18zsbmEbCAcYEaoIKQ7m/PQbFuvutCMvbYoTTOpyvJ/KxT1glWoDSDhDuuFug/fgl99ihwz6SwnieFn+1/enLNEQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(366004)(346002)(376002)(136003)(66556008)(66946007)(8676002)(66446008)(71200400001)(66476007)(2906002)(6512007)(53546011)(6506007)(76116006)(36756003)(166002)(8936002)(5660300002)(31686004)(186003)(2616005)(6486002)(64756008)(86362001)(110136005)(31696002)(83380400001)(316002)(966005)(478600001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: RiEK88x+EqtrDUj2d+IMmgqDDmKykxzFNumLpMJE11zh79B4/DG00JPdzDfKo2/HQmrVHXzINS4CRU/hdtMXHfu0uX9Yce4qAAfYZDQrHo6yKJn/wZbGIMdlgCRWjkv7jLoOtFhjDr7YYighj6QsEYL5/AdHuFL0X1ms1E5fbWTM12ZEoEfaKrSuNWgjGUosCXaHRzvJAQiYtyPG9/XzVqQ669fTtciLp8we4RxNwOxZYxAsOdqHS5izPC+OYRlMORR6yd8/Pmf0Hy4xITvLiCRKzVnVKSPo/NvWvAWBpCl4RVYvO3v1LeVggFHPFbtsyUAG6feKwxWVuIeNPvQv9ssbPP2sGUnpov+OXT/rvVOl+2vfutJgWYKkGskn3deGhMdLzN8LorpmA6ysqoCdKuRWjxzHn2yqi1b8KZrmME6a3GgN9yJa89msrHT9siCyeciw6WW2SxA6GCBd2FtEQ4IlGES8ZkMUIMLn2VQooKRnZY9uvA5DVr6wewkyZ3H3oU05gqTLuBE0JeTzQfsADky40FBpXIAg17lS6mpwYTmN+aL1K2fJxPBESeumgpS/ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_62ec9fad583eed511f6cdcfa3835c0ecericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c30bc4ae-c69c-485c-5a6d-08d8113328d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 13:51:09.7416 (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: pFGAf58C8pfWOIjDTYS4brh8A5PssMBHjc2YzNAcQz5RXG32nrwHAIAlZx+KI8gJjUX0/+4EN21vJefOAve312b+zc+3gGSyqYSbGE69sVk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3386 Archived-At: Subject: Re: [Emu] draft-ietf-emu-eap-tls13-09 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, 15 Jun 2020 13:51:16 -0000 --_000_62ec9fad583eed511f6cdcfa3835c0ecericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpPbiA2LzEyLzIwIDExOjI5IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90 ZToNCg0KQSBzaG9ydCBmb2xsb3ctdXAgb24gbXkgb3duIHJldmlldzoNCg0KSSB3cm90ZToNCg0K DQoNCiINClByZS1TaGFyZWQgS2V5IChQU0spIGF1dGhlbnRpY2F0aW9uIFNIQUxMIE5PVCBiZSB1 c2VkIGV4Y2VwdA0KICAgZm9yIHJlc3VtcHRpb24uDQoiDQpXaGF0IHlvdSB3YW50IHRvIHNheSB0 aGF0IHRoYXQgRUFQLVRMUyBNVVNUIE5PVCB1c2UgZXh0ZXJuYWwgUFNLcy4gSSB3b25kZXIgd2h5 IHlvdSB3YW50IHRvIHJ1bGUgdGhhdCB1c2UgY2FzZSBvdXQ/IEl0IGlzIGEgcGVyZmVjdGx5IGZp bmUgdXNlIGNhc2UgZm9yIFRMUyAxLjMgYW5kIHRoZXJlIGlzIGV2ZW4gdGhlIHBvc3NpYmlsaXR5 IHRvIHVzZSBQU0sgd2l0aCBFQ0RIRS4gV2hhdCBpcyB0aGUgbW90aXZhdGlvbj8NCg0KDQoNCkkg bm90aWNlZCBub3cgdGhhdCB0aGUgd29ya2luZyBncm91cCBoYWQgYSBkaXNjdXNzaW9uIGFib3V0 IHRoaXMgYWxyZWFkeSBhbmQgdGhhdCB0aGVyZSBpcyBhIG5ldyBkb2N1bWVudCBiZWluZyBwdWJs aXNoZWQgc3BlY2lmaWNhbGx5IGZvY3VzZWQgb24gRUFQLVRMUy1QU0stYmFzZWQgYXV0aGVudGlj YXRpb24uIEhlbmNlLCBpZ25vcmUgdGhlIHNlY29uZCBwYXJ0IG9mIG15IGNvbW1lbnQuDQoNCklu ZGVlZC4gVGhlcmUgaGFzIGJlZW4gbG90cyBvZiBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMuIFRv IHN1bW1hcml6ZToNCg0KUkZDIDUyMTYgZXhwbGljaXRseSByZXF1aXJlZCBjZXJ0aWZpY2F0ZSBi YXNlZCBUTFMgYXV0aGVudGljYXRpb24gd2l0aCB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCiAgIElm IHRoZSBFQVAgc2VydmVyIGlzIG5vdCByZXN1bWluZyBhIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQg c2Vzc2lvbiwNCiAgIHRoZW4gaXQgTVVTVCBpbmNsdWRlIGEgVExTIHNlcnZlcl9jZXJ0aWZpY2F0 ZSBoYW5kc2hha2UgbWVzc2FnZSwgYW5kDQogICBhIHNlcnZlcl9oZWxsb19kb25lIGhhbmRzaGFr ZSBtZXNzYWdlIE1VU1QgYmUgdGhlIGxhc3QgaGFuZHNoYWtlDQogICBtZXNzYWdlIGVuY2Fwc3Vs YXRlZCBpbiB0aGlzIEVBUC1SZXF1ZXN0IHBhY2tldC4NCg0KICAgVGhlIGNlcnRpZmljYXRlIG1l c3NhZ2UgY29udGFpbnMgYSBwdWJsaWMga2V5IGNlcnRpZmljYXRlIGNoYWluIGZvcg0KICAgZWl0 aGVyIGEga2V5IGV4Y2hhbmdlIHB1YmxpYyBrZXkgKHN1Y2ggYXMgYW4gUlNBIG9yIERpZmZpZS1I ZWxsbWFuDQogICBrZXkgZXhjaGFuZ2UgcHVibGljIGtleSkgb3IgYSBzaWduYXR1cmUgcHVibGlj IGtleSAoc3VjaCBhcyBhbiBSU0Egb3INCiAgIERpZ2l0YWwgU2lnbmF0dXJlIFN0YW5kYXJkIChE U1MpIHNpZ25hdHVyZSBwdWJsaWMga2V5KS4NCg0KQmVybmFyZCBBYm9iYSBvcGluZWQgdGhhdCBl eHRlcm5hbCBQU0sgYmFzZWQgYXV0aGVudGljYXRpb24gc2hvdWxkbid0IGJlIGFkZGVkIHRvIEVB UC1UTFMgaW4gdGhpcyB1cGRhdGUuIEluc3RlYWQgYSBzZXBhcmF0ZSBkb2N1bWVudCAod2l0aCBh IHNlcGFyYXRlIEVBUCBtZXRob2QgdHlwZSkgc2hvdWxkIGRvIHRoYXQuIEhlbmNlLCB3ZSBub3cg aGF2ZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHRzc29uLWVtdS1lYXAt dGxzLXBzay0wMC4gRm9yIHJlZmVyZW5jZSwgaGVyZSBhcmUgc29tZSBlbWFpbCBjb252ZXJzYXRp b25zIGNvbnRhaW5pbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljOg0KDQotIGh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZW11L0Z0eFJKSFRqelNZMHlWZFZyOFZqeWs5RC12 ay8NCi0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUvQ1JoM1ZYTERu cEpGRkliSFdKQWppT2dmekFnLw0KLSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL2VtdS9uWXJJQTRQS3FrMm1yVW9OdkF0Rmg3Uy1YYjgvDQotIGh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvZW11L2hWRzM1N0hYcXZ5MEVqWjJ5ck9MZHNwSDUzby8NCg0K LS1Nb2hpdA0KDQoNCg0KQ2lhbw0KSGFubmVzDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250 ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0u IFRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkVtdSBtYWlsaW5nIGxpc3QNCkVtdUBpZXRmLm9yZzxtYWlsdG86RW11QGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXUNCg0K --_000_62ec9fad583eed511f6cdcfa3835c0ecericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4ADD5FE65FDC0744A3027FB12793BF4E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgSGFubmVz LDxicj4NCjwvcD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gNi8xMi8yMCAxMToy OSBBTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjaXRlPSJtaWQ6QU0wUFIwOE1CMzcxNjk4NjlBMkMwMTVGMkI3MDFBMzMyRkE4 MTBAQU0wUFIwOE1CMzcxNi5ldXJwcmQwOC5wcm9kLm91dGxvb2suY29tIj4NCjxwcmUgY2xhc3M9 Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+QSBzaG9ydCBmb2xsb3ctdXAgb24gbXkgb3duIHJldmll dzoNCg0KSSB3cm90ZToNCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUg Y2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+JnF1b3Q7DQpQcmUtU2hhcmVkIEtleSAoUFNL KSBhdXRoZW50aWNhdGlvbiBTSEFMTCBOT1QgYmUgdXNlZCBleGNlcHQNCiAgIGZvciByZXN1bXB0 aW9uLg0KJnF1b3Q7DQpXaGF0IHlvdSB3YW50IHRvIHNheSB0aGF0IHRoYXQgRUFQLVRMUyBNVVNU IE5PVCB1c2UgZXh0ZXJuYWwgUFNLcy4gSSB3b25kZXIgd2h5IHlvdSB3YW50IHRvIHJ1bGUgdGhh dCB1c2UgY2FzZSBvdXQ/IEl0IGlzIGEgcGVyZmVjdGx5IGZpbmUgdXNlIGNhc2UgZm9yIFRMUyAx LjMgYW5kIHRoZXJlIGlzIGV2ZW4gdGhlIHBvc3NpYmlsaXR5IHRvIHVzZSBQU0sgd2l0aCBFQ0RI RS4gV2hhdCBpcyB0aGUgbW90aXZhdGlvbj8NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSBj bGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4NCkkgbm90aWNlZCBub3cgdGhhdCB0aGUgd29y a2luZyBncm91cCBoYWQgYSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgYWxyZWFkeSBhbmQgdGhhdCB0 aGVyZSBpcyBhIG5ldyBkb2N1bWVudCBiZWluZyBwdWJsaXNoZWQgc3BlY2lmaWNhbGx5IGZvY3Vz ZWQgb24gRUFQLVRMUy1QU0stYmFzZWQgYXV0aGVudGljYXRpb24uIEhlbmNlLCBpZ25vcmUgdGhl IHNlY29uZCBwYXJ0IG9mIG15IGNvbW1lbnQuPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD5JbmRl ZWQuIFRoZXJlIGhhcyBiZWVuIGxvdHMgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLiBUbyBz dW1tYXJpemU6PC9wPg0KPHA+UkZDIDUyMTYgZXhwbGljaXRseSByZXF1aXJlZCBjZXJ0aWZpY2F0 ZSBiYXNlZCBUTFMgYXV0aGVudGljYXRpb24gd2l0aCB0aGUgZm9sbG93aW5nIHRleHQ6PC9wPg0K PHA+PC9wPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCI+ ICAgSWYgdGhlIEVBUCBzZXJ2ZXIgaXMgbm90IHJlc3VtaW5nIGEgcHJldmlvdXNseSBlc3RhYmxp c2hlZCBzZXNzaW9uLA0KICAgdGhlbiBpdCBNVVNUIGluY2x1ZGUgYSBUTFMgc2VydmVyX2NlcnRp ZmljYXRlIGhhbmRzaGFrZSBtZXNzYWdlLCBhbmQNCiAgIGEgc2VydmVyX2hlbGxvX2RvbmUgaGFu ZHNoYWtlIG1lc3NhZ2UgTVVTVCBiZSB0aGUgbGFzdCBoYW5kc2hha2UNCiAgIG1lc3NhZ2UgZW5j YXBzdWxhdGVkIGluIHRoaXMgRUFQLVJlcXVlc3QgcGFja2V0Lg0KDQogICBUaGUgY2VydGlmaWNh dGUgbWVzc2FnZSBjb250YWlucyBhIHB1YmxpYyBrZXkgY2VydGlmaWNhdGUgY2hhaW4gZm9yDQog ICBlaXRoZXIgYSBrZXkgZXhjaGFuZ2UgcHVibGljIGtleSAoc3VjaCBhcyBhbiBSU0Egb3IgRGlm ZmllLUhlbGxtYW4NCiAgIGtleSBleGNoYW5nZSBwdWJsaWMga2V5KSBvciBhIHNpZ25hdHVyZSBw dWJsaWMga2V5IChzdWNoIGFzIGFuIFJTQSBvcg0KICAgRGlnaXRhbCBTaWduYXR1cmUgU3RhbmRh cmQgKERTUykgc2lnbmF0dXJlIHB1YmxpYyBrZXkpLjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KQmVy bmFyZCBBYm9iYSBvcGluZWQgdGhhdCBleHRlcm5hbCBQU0sgYmFzZWQgYXV0aGVudGljYXRpb24g c2hvdWxkbid0IGJlIGFkZGVkIHRvIEVBUC1UTFMgaW4gdGhpcyB1cGRhdGUuIEluc3RlYWQgYSBz ZXBhcmF0ZSBkb2N1bWVudCAod2l0aCBhIHNlcGFyYXRlIEVBUCBtZXRob2QgdHlwZSkgc2hvdWxk IGRvIHRoYXQuIEhlbmNlLCB3ZSBub3cgaGF2ZToNCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHRzc29uLWVtdS1lYXAt dGxzLXBzay0wMCI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24t ZW11LWVhcC10bHMtcHNrLTAwPC9hPi4gRm9yIHJlZmVyZW5jZSwgaGVyZSBhcmUgc29tZSBlbWFp bCBjb252ZXJzYXRpb25zIGNvbnRhaW5pbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljOg0KPHA+ PC9wPg0KPHA+LSA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZW11L0Z0eFJKSFRqelNZMHlWZFZyOFZqeWs5RC12ay8i Pg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUvRnR4UkpIVGp6U1kw eVZkVnI4Vmp5azlELXZrLzwvYT48YnI+DQotIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJl Zj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUvQ1JoM1ZYTERucEpG RkliSFdKQWppT2dmekFnLyI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L2VtdS9DUmgzVlhMRG5wSkZGSWJIV0pBamlPZ2Z6QWcvPC9hPjxicj4NCi0gPGEgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L2VtdS9uWXJJQTRQS3FrMm1yVW9OdkF0Rmg3Uy1YYjgvIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvZW11L25ZcklBNFBLcWsybXJVb052QXRGaDdTLVhiOC88L2E+PGJy Pg0KLSA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvZW11L2hWRzM1N0hYcXZ5MEVqWjJ5ck9MZHNwSDUzby8iPg0KaHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUvaFZHMzU3SFhxdnkwRWpaMnly T0xkc3BINTNvLzwvYT48YnI+DQo8L3A+DQo8cD4tLU1vaGl0PGJyPg0KPC9wPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkFNMFBSMDhNQjM3MTY5ODY5QTJDMDE1RjJCNzAxQTMz MkZBODEwQEFNMFBSMDhNQjM3MTYuZXVycHJkMDgucHJvZC5vdXRsb29rLmNvbSI+DQo8cHJlIGNs YXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPg0KDQpDaWFvDQpIYW5uZXMNCg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRW11IG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10 eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOkVtdUBpZXRmLm9yZyI+RW11QGlldGYu b3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZW11PC9hPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_62ec9fad583eed511f6cdcfa3835c0ecericssoncom_-- From nobody Mon Jun 15 06:53:45 2020 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 5083F3A0D95 for ; Mon, 15 Jun 2020 06:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 uTAi_XnbP4Ga for ; Mon, 15 Jun 2020 06:51:58 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2046.outbound.protection.outlook.com [40.107.21.46]) (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 24CC23A0D93 for ; Mon, 15 Jun 2020 06:51:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BUh8XL5trT1VZozJ3lwXKpOZVdlT8iJYUhQyXmGxYWkt4Sp193h/w/V56U/oo2xKQtHH1ksk2WZTffnABJcffnt8JGYYuP5TDHkXkRV0guTOrKpFr3S0N6c2dLhhfQbMsseQv5vGHCWDo5HYDHzkqXUHHV0V6eACbA8RE+8comhLEWSOCqbbBj13gPGVUtBwI93TgR2nrwJTvs8/7bcSwtDFybKYThfbvi3KhUbka0IOOXcdgdvSyi1ibCyiUGlCrySHioMcYxC/Mq9HQ8E0DAbCZT6bx+E7a9nEMyWYonmHBVmDW6pHNQlAl+0w1Y/BZZA52+q3IHeJQVS+wexU2Q== 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=b89mafzhtZqBkTHuJ5w2hOLYw5gMj3qNuXq+bN9Qb74=; b=gAggAaDtI+i8ie3cvfJW/o5MY0BviJ6xQ4SDHbP+YBMuWeIQzRbdVtCd8nzJbfJrALMu83qN8zDxRimxqZuZajtTVq5cxR9inuVRABBXO9HEZ/1LPzEy0QQNFc7ti9mb3KP+uQtYCmaXIgeIqTVvxFdykd3FwyGQf0Iewj3udPG9gGhOWaC2OHVTJU3Tp/z7XDonQYjB2W+fplvYs6Z0mma1oY/MxpiufD9dl7od+SRT5mbYFH1BjNK4NnORjdj/YmXjNIPSICex4XEURvbRVjH6XIXJkFYN+1yEfeZNuTdlvDLJzAZV51G/MoKqbDJEp48MnmhB6GFCGABPYDe8Mg== 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=b89mafzhtZqBkTHuJ5w2hOLYw5gMj3qNuXq+bN9Qb74=; b=iZZbU3O7qB3F1W96HownOnv5xypqBKBG9D7LjH0zl+PL8O0CbmpbLBIwXxIm0MaJRqT6ses8kvEugLvPb/dsXWq6OImS2Kabs7Pf3pKeOMHJafcLtr3R49JQ77WT3CrSeCDBTbLlOqE7KlplVCMwZ0KJzI5ExYpE9w/b0KItCzI= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR0701MB2779.eurprd07.prod.outlook.com (2603:10a6:3:94::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10; Mon, 15 Jun 2020 13:51:55 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e%7]) with mapi id 15.20.3109.010; Mon, 15 Jun 2020 13:51:55 +0000 From: Mohit Sethi M To: Hannes Tschofenig , "emu@ietf.org" Thread-Topic: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Thread-Index: AQHWQxwhidapLR1LHUae6YFWy2dwOg== Date: Mon, 15 Jun 2020 13:51:55 +0000 Message-ID: <1e769dbd-b563-0ba6-c398-8066c6151310@ericsson.com> 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.8.0 authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:4147:9db5:d2f7:7e10:bb6b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a8b812c-4ac2-4963-065c-08d8113343ed x-ms-traffictypediagnostic: HE1PR0701MB2779: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iNK2MCxPoHsPGhi7gEurWC528hNRbJSAu1ubF28J23nIQ3Q4OLWzUoStOqAbQ1l9CDSeKHcLmHcojB7Y4vGyczkgtmOPVJ7XkDTtYEVk8ErGg66ox0LqEtiNhU9rUzIRQCvZ0Jv4qyCwcqKVq6ajjVXakufxSLmrjDpxuqukAZRrqa4IKo4PBMJ5jdcYoKyD/tUtCrw65KovYlTHMo7lOTJVchTn67mMzsBFoozRfDHv1b+EAOAExadIjnfcXJN1aTQf/XZAwwXEUj9aYgQVAyenQvgvyILyHCkJE0rPxJNnxEK7/051jr6OqSk/LMEB7cJxankUg/9NMD3GwkbS2VAwtWZ1TfWEyhymiqb5ZnDfjxYffL9rU2rBrvDZ66dwNmm0q+9xmhFbkSS78i4Skq7cjLX7/5UM6wD3+7jVyRfAZcgWxfed+J36F32fFuxt+06U3SxTk4SGoOH9Kj56AQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(39860400002)(396003)(346002)(376002)(66946007)(2616005)(66476007)(66556008)(64756008)(66446008)(478600001)(2906002)(316002)(8936002)(6486002)(36756003)(53546011)(186003)(6506007)(76116006)(6512007)(31686004)(966005)(18074004)(31696002)(86362001)(71200400001)(166002)(8676002)(5660300002)(110136005)(83380400001)(15650500001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: zs1VzAxEPZJMmP4OR2Sh5gteKUojeS1PyPkWwvai8DAf+bq247NMbCDNp+BRhg+/UK2I0IfzCULPVxna74rp7QSZLOvA+yPaU9xY97flt6PNe8zO37ONiWedEib4mDvCvK6piFxuTSULRV0szLPHjGNFXFm3F/q053o3GHZguERwQNujFmDfvPJA8BXMj1vsiuS3b3k8o0DMnUb/aF6P5gBduoFe6T/UQZH6LrIhqr7eXxMe1twZcMsjpqHVCEvUwHDrbGBCGl2YdAQiaMOmmr0W+f2iCaYVUqS1tZwTZsjDfxFI3vzzfy2R3yMhwUsD0J2/7tR8qM0mAOo6HVxAdg/sVvSVYd0y6tZGrwmfvzODrHKNzhC8z2AOLQEqjB9BcKVMpOm+CYLxXfiPa9jDDxXr3wzRqxypNNRM+yCT9Q180KyZRp82dia/g1HBrwLXCJVPQGCwsLzkdIH97zHkm/Zq7MMbYGJbJL2iAza34QIQ+BU4aljs2cAk/u724CFnoIcC/Y/QINNIxjjyITHxn+i5HkVzwM/qsiizKcG6LuQ47U+HPQQY3elQ8fdfBmnD x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1e769dbdb5630ba6c3988066c6151310ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a8b812c-4ac2-4963-065c-08d8113343ed X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 13:51:55.1747 (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: etmjPx9obJs9Ub5GW232WIByMSrj20dXXfTnTy8BBF3NT328xtdspVw9kv30JZN6ByQQY3y6VoDDexEi36hlSt3m/Fk2FHjt9RExqG9vzKc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2779 Archived-At: X-Mailman-Approved-At: Mon, 15 Jun 2020 06:53:44 -0700 Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 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, 15 Jun 2020 13:52:01 -0000 --_000_1e769dbdb5630ba6c3988066c6151310ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Hannes, Unfortunately you are wrong here. The design decision was in fact taken to = avoid changes to the underlying TLS implementation while also avoiding chan= ges to RFC 3748. To summarize: Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP= -TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/= msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. Essentially, TLS 1.3 allows a server = to send a Post-Handshake message with a NewSessionTicket at any time. Howev= er, in EAP-TLS this is not possible. The TLS tunnel is torn down after auth= entication. John notes in his response to Jouni (https://mailarchive.ietf.o= rg/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS the connection is ass= umed to stay open for a long time after the client sends Finished, in EAP t= he connection is assumed to be closed shortly after." An earlier cleaner way of sending NewSessionTicket required an extra round = trip and left the peer uncertain about the next message (https://tools.ietf= .org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted thi= s uncertainty for a peer: " the peer has no idea whether the NewSessionTick= et is delivered after ClientFinished. In other words, the next message in t= he sequence could be either continuation of EAP-TLS method or EAP-Success".= You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". S= ee RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the following: Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. and On the peer, after success result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully. Thus, EAP-Success cannot be used as a reliable notification mechanism. Till= version 05 of the document, we used an empty application data record as a = notification of the last handshake message. The text said: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by appending an empty application data record (i.e. a TLS record with TLSPlaintext.type =3D application_data and TLSPlaintext.length =3D 0) to the last handshake record. After sending an empty application data record, the EAP server may only send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. However, Jouni in a later response (https://mailarchive.ietf.org/arch/msg/e= mu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted that such behavior is non-trivial to= achieve with OpenSSL. He notes " OpenSSL is not willing to send such an em= pty TLSPlaintext structure. SSL_write() has following to say : 'You should = not call SSL_write() with num=3D0, it will return an error. SSL_write_ex() = can be called with num=3D0, but will not send application data to the peer.= '" Therefore, the text was later updated to: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. The Commitment Message is a TLS record with application data 0x00 (i.e. a TLS record with TLSPlaintext.type =3D application_data, TLSPlaintext.length =3D 1, and TLSPlaintext.fragment =3D 0x00). Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handsha= ke messages. There is still a challenge in scenarios where a server chooses not to issue= any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg= /emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni notes this problem: I did see some issues when OpenSSL 1.1.1 when disabling sending of session tickets, though. The current draft indicates that the empty Application Data payload would be send out in the same EAP packet with the server's Finished message, i.e., before the server having authenticated the peer. And this would be done without the peer having used TLS early data (which is explicitly disallowed in the draft). That combination did not work with my experiments since OpenSSL was rejecting the SSL_write() operation after the server having written own Finished message, but before having received the Finished message from the peer. The OpenSSL documentation seemed to imply that SSL_write_early_data() could be used by the server _if_ the client first sent early data.. At least in my tests, OpenSSL rejected that call without early data from the client. This is why the current text also says the following: The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP- Request. Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3. In the case where the server sends the Commitment Message in a separate EAP- Request, the conversation will appear as shown in Figure 9. After sending the Commitment Message, the EAP server may only send an EAP- Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. Thus, the current design decision has been guided by parallel implementatio= n experience and it is the best solution we could come up with (given all t= he practical limitations). --Mohit On 6/12/20 11:36 AM, Hannes Tschofenig wrote: Hi all, This has probably been discussed extensively in the EMU group. I am sorry t= o bring it up again but I believe this is a bad design decision. I raised i= t in my short review just sent to the list but I believe it is worthwhile t= o point it out separately. draft-ietf-emu-eap-tls13 introduces a new message to EAP-TLS, namely the Co= mmitment Message. This requires extra code in an implementation because the= normal behavior would be to run a TLS stack and then send encrypted data. EAP-TLS does, however, not send application data*. This message changes thi= s. Not only does it not send encrypted application data it requires an impl= ementation to transmit a plaintext application data record after the applic= ation traffic secret has been created and before that application traffic s= ecret is used to protect post handshake messages. This will make it difficu= lt to re-use an off-the-shelf TLS 1.3 stack. There is very little motivation about this message other than =93 When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. =93 I might miss something important here but why cannot the EAP-Success or EAP= -Failure serve that purpose? Here are two examples to explain what I mean: 1. Failed exchange EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, TLS Finished, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Fatal Alert) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Failure 1. Successful Exchange with Post-Handshake NewSession Ticket EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS NewSessionTicket, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Success Ciao Hannes (*): FWIW Post handshake messages are protected with the application traffi= c secrets. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --_000_1e769dbdb5630ba6c3988066c6151310ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken = to avoid changes to the underlying TLS implementation while also avoiding c= hanges to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to = EAP-TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/.= Essentially, TLS 1.3 allows a server to send a Post-Handshake message with= a NewSessionTicket at any time. However, in EAP-TLS this is not possible. = The TLS tunnel is torn down after authentication. John notes in his response to Jouni (https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRo= ICUzlk/) "in TLS the connection is assumed to stay open for a long time after the client sends Finished, i= n EAP the connection is assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra rou= nd trip and left the peer uncertain about the next message (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-00#se= ction-2.1.1). Jouni highlighted this uncertainty for a peer: " the peer has no idea= whether the NewSessionTicket is delivered after ClientFinished. In other w= ords, the next message in the sequence could be either continuation of EAP-= TLS method or EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". See RFC 3= 748 (https://tools.ietf.org/html/rfc3748) which says the following:

   Implementation Note: Because the Success and Fail=
ure packets are not
   acknowledged, they are not retransmitted by the authenticator, and
   may be potentially lost.  A peer MUST allow for this circumstance as
   described in this note.
and 

 On the peer, after success result indications have =
been exchanged by
   both sides, a Failure packet MUST be silently discarded.  The peer
   MAY, in the event that an EAP Success is not received, conclude that
   the EAP Success packet was lost and that authentication concluded
   successfully.

Thus, EAP-Success cannot be used as a reliable notification mechanism. Till= version 05 of the document, we used an empty application data record as a = notification of the last handshake message. The text said: 

When an EAP server has sent its last handshake messa=
ge (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type =3D application_data and
   TLSPlaintext.length =3D 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.
However, Jouni in a later response (https:= //mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted= that such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL is not willing to send such = an empty TLSPlaintext structure. SSL_write() has following to say : 'You sh= ould not call SSL_write() with num=3D0, it will return an error. SSL_write_= ex() can be called with num=3D0, but will not send application data to the peer.'"

Therefore, the text was later updated to:

 When an EAP server has sent its last handshake mes=
sage (Finished or a
   Post-Handshake), it commits to not sending =
any more handshake
   messages by sending a Commitment Message.  =
The Commitment Message is
   a TLS record with application data 0x00 (i.=
e. a TLS record with
   TLSPlaintext.type =3D application_data, TLS=
Plaintext.length =3D 1, and
   TLSPlaintext.fragment =3D 0x00).  Note that=
 the length of the plaintext
   is greater than the corresponding TLSPlaint=
ext.length due to the
   inclusion of TLSInnerPlaintext.type and any=
 padding supplied by the
   sender.  EAP server implementations MUST se=
t TLSPlaintext.fragment to
   0x00, but EAP peer implementations MUST acc=
ept any application data
   as a Commitment Message from the EAP server=
 to not send any more handshake messages.

There is still a challenge in scenarios where a server chooses not to is= sue any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ = Jouni notes this problem:

I did see some issues when OpenSSL 1.1.1 when disab=
ling sending of
session tickets, though. The current draft indicates that the empty
Application Data payload would be send out in the same EAP packet with
the server's Finished message, i.e., before the server having
authenticated the peer. And this would be done without the peer having
used TLS early data (which is explicitly disallowed in the draft). That
combination did not work with my experiments since OpenSSL was rejecting
the SSL_write() operation after the server having written own Finished
message, but before having received the Finished message from the peer.
The OpenSSL documentation seemed to imply that SSL_write_early_data()
could be used by the server _if_ the client first sent early data.. At
least in my tests, OpenSSL rejected that call without early data from
the client.

This is why the current text also says the following:

 The Commitment Message may be sent in the same
   EAP-Request as the last handshake record or=
 in a separate EAP-
   Request.  Sending the Commitment Message in=
 a separate EAP-Request
   adds an additional round-trip, but may be n=
ecessary in TLS
   implementations that only implement a subse=
t of TLS 1.3.  In the case
   where the server sends the Commitment Messa=
ge in a separate EAP-
   Request, the conversation will appear as sh=
own in Figure 9.  After
   sending the Commitment Message, the EAP ser=
ver may only send an EAP-
   Success, an EAP-Failure, or an EAP-Request =
with a TLS Alert Message.

Thus, the current design decision has been guided by parallel implementa= tion experience and it is the best solution we could come up with (given al= l the practical limitations).

--Mohit

On 6/12/20 11:36 AM, Hannes Tschofenig wrote= :

Hi all,

 

This has probably been discussed extensively in the = EMU group. I am sorry to bring it up again but I believe this is a bad desi= gn decision. I raised it in my short review just sent to the list but I bel= ieve it is worthwhile to point it out separately.

 

draft-ietf-emu-eap-tls13 introduces a new message to= EAP-TLS, namely the Commitment Message. This requires extra code in an imp= lementation because the normal behavior would be to run a TLS stack and the= n send encrypted data.

EAP-TLS does, however, not send application data*. T= his message changes this. Not only does it not send encrypted application d= ata it requires an implementation to transmit a plaintext application data = record after the application traffic secret has been created and before that application traffic secret is used= to protect post handshake messages. This will make it difficult to re-use = an off-the-shelf TLS 1.3 stack.

 

There is very little motivation about this message other than 
 
=93
   When an EAP server has sent i=
ts last handshake message (Finished or a
   Post-Handshake), it commits t=
o not sending any more handshake
   messages by sending a Commitm=
ent Message.
=93

 

I might miss something important here but why cannot= the EAP-Success or EAP-Failure serve that purpose?

 

Here are two examples to explain what I mean: <= /o:p>

 

  1. Failed exchange

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS=

   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
            &nb=
sp;           TLS Finishe=
d,
       =
            &nb=
sp;            =
 <--------        Commitment Message)<=
/o:p>
    EAP-Response/
    EAP-Type=3DEAP-TLS=

   (TLS Certificate,<=
/span>
    TLS CertificateVerify,<=
o:p>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          (TLS Fa=
tal Alert)
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Failure

 

 

  1. Successful Exchange with Post-Handshake NewSession Ticket<= /li>

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS=

   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
 <--------          &n=
bsp;   TLS Finished)
    EAP-Response/
    EAP-Type=3DEAP-TLS=

   (TLS Certificate,<=
/span>
    TLS CertificateVerify,<=
o:p>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
        =
;            &n=
bsp;            =
;            &n=
bsp;           EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
            &nb=
sp;  (TLS NewSessionTicket,
       =
            &nb=
sp;            =
 <--------        Commitment Message)<=
/o:p>
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Success

 

 

Ciao

Hannes

 

(*): FWIW Post handshake messages are protected with= the application traffic secrets.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. 
____________________________________=
___________
Emu mailing list
Emu@ietf=
.org
https://www.ietf.org/mailman/listinfo/emu
--_000_1e769dbdb5630ba6c3988066c6151310ericssoncom_-- From nobody Mon Jun 15 08:04:48 2020 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 8C7393A0DD3 for ; Mon, 15 Jun 2020 07:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=qtYYnja0; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=qtYYnja0 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 0Flg8XmnGVJ8 for ; Mon, 15 Jun 2020 07:42:05 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2050.outbound.protection.outlook.com [40.107.20.50]) (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 4B8BF3A0DCC for ; Mon, 15 Jun 2020 07:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vsT4urEPg4KYhsvuO4ZHLZTLUVv9nAw0W82jC01q0qU=; b=qtYYnja0JwyTceUF9mhk8qpaiI8QGsaySCj16Plknosu5Y+TvbhwIKSRtoizw1dtOLUVhxiCnOx3+hYWH/fu++J8s+N6mFaCq19rnTawxtVs3cEfjZ7iVBwC1rAOAlUiVNzrECvX0V8ckKE5R5jGvwzYKoHZY0CDJ0q8TlIy1ho= Received: from AM6PR10CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:89::15) by DB6PR08MB2776.eurprd08.prod.outlook.com (2603:10a6:6:1d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Mon, 15 Jun 2020 14:42:02 +0000 Received: from VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:89:cafe::6d) by AM6PR10CA0002.outlook.office365.com (2603:10a6:209:89::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Mon, 15 Jun 2020 14:42:02 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT036.mail.protection.outlook.com (10.152.19.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Mon, 15 Jun 2020 14:42:01 +0000 Received: ("Tessian outbound 4f5776643448:v59"); Mon, 15 Jun 2020 14:42:01 +0000 X-CR-MTA-TID: 64aa7808 Received: from 48c3fb99183a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 989290F7-2B54-48D0-BE68-B93FEDC737C3.1; Mon, 15 Jun 2020 14:41:56 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 48c3fb99183a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 15 Jun 2020 14:41:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dpdK1eYg2rZLCS9vL2I7yM2HZ+tsuxEdk+Zo5IECQorNamG1dNEe+lrBHuP+MSEJ5AmxF7+0SIhUWT4vKqyNOzSqnZj/jAoJPdBfJnaJy71DNugAGT4++hod9I5wcQO50y/6VaFSJYwpY6DKo8m+Wz23RZp8LhIlv9GZq0dctM14T/ly1DWBH0Ga7XT1nudgKiRdfBJFv5xz6h3xPb4RvIX5DYj+R8K/dakxhmh+Q17VL6cHnj8nEFoF+HW1iti+UkbkTMyIqPd2r1atxBaNc4PNl8Mygjp3DhZiqOGfKDlYaMtIiG9XwK6pg8p8BhE9D+Mnwr8xBXJMBXDEm9YwJg== 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=vsT4urEPg4KYhsvuO4ZHLZTLUVv9nAw0W82jC01q0qU=; b=NgXa6rVTMmDWSPGIsKP0kL3VnD6RsDM0XQkVoRc/QADwMMs5hCQjCwSs7Oweni9rnet1frmU5gAP3N+uHFArIAwridic3N6++dz7zdcrl9vLjh1rIGtMaKt9y5DgdlygEZApYhE91eOotgqW8CqF6CmBWeQaHae2YYJkY0p+qW6f7WT+OMjW0wBthgLFwKXtxr70e2tG4zlvQVO+4VRHFrTcgrynB6vqI+sTFiKVpWIfLzwXCyrkn3YkrsZauEkpz/q74cg4aOymt3kzPq2+ARERctVZbyA2DUi+Xr0vy7rBsmTsXt8Uokraf6f5fmUMEwdYzTOG/xC4YqP65F0GPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vsT4urEPg4KYhsvuO4ZHLZTLUVv9nAw0W82jC01q0qU=; b=qtYYnja0JwyTceUF9mhk8qpaiI8QGsaySCj16Plknosu5Y+TvbhwIKSRtoizw1dtOLUVhxiCnOx3+hYWH/fu++J8s+N6mFaCq19rnTawxtVs3cEfjZ7iVBwC1rAOAlUiVNzrECvX0V8ckKE5R5jGvwzYKoHZY0CDJ0q8TlIy1ho= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3107.eurprd08.prod.outlook.com (2603:10a6:208:60::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Mon, 15 Jun 2020 14:41:54 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3088.029; Mon, 15 Jun 2020 14:41:54 +0000 From: Hannes Tschofenig To: Mohit Sethi M , "emu@ietf.org" Thread-Topic: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Thread-Index: AdZAkc+cCh243U45Rdqk3n8/SPrXVQCilGmAAAGz0BA= Date: Mon, 15 Jun 2020 14:41:54 +0000 Message-ID: References: <1e769dbd-b563-0ba6-c398-8066c6151310@ericsson.com> In-Reply-To: <1e769dbd-b563-0ba6-c398-8066c6151310@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 83414081-0c81-4ae7-b6a2-e4cc488240e2.1 x-checkrecipientchecked: true Authentication-Results-Original: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 3a676fde-5829-40f3-90f2-08d8113a4400 x-ms-traffictypediagnostic: AM0PR08MB3107:|DB6PR08MB2776: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04359FAD81 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 8MuAw/NZ1Sja7v4FIPTk05pOh9wCPrDsglu9xxG9pXoz3dCZmlBQ+B2KFBtsN2gLEohOt2dEvoqiorSKmIZbT2cG8t5dYr+E1ABcVSRLsDlL/W2Nepok0wnNv/CTAdOQmrGBFMTk0ygbPMDk59BZUKNsr8mel69TD1h1DowPQyjjrWsMZmlHJUmFwZ1q13F9+70e5ENugyiCZXYAl3+xLhx1mnWRK8+MQU0nDCDQ+TwdgPOoAZYFCbf5Cd83KK4lppTjyO+WMuzWLq8fGX7ZLc9zIsnHD7dgvFPou/XtOnS60vzc1LT7I0AfaZhs4UerqQd4OYBqaWDyyI4FGCY1z6GxBQp6ATzOOmYqcqQXZ3xX/wWir/KQ/Q4+va+ijszQdHxuDYE5S7VPfD7RQjVLKg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(376002)(136003)(366004)(39860400002)(316002)(8936002)(9326002)(8676002)(71200400001)(110136005)(52536014)(5660300002)(966005)(478600001)(15650500001)(18074004)(26005)(7696005)(53546011)(6506007)(186003)(83380400001)(166002)(66946007)(76116006)(33656002)(66556008)(66476007)(66446008)(64756008)(86362001)(2906002)(9686003)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: NosmRVu53JRGrlnd7YoLjcNP60Xf6Yg6+2TO7Bnnkl98B244qdbqPSiQKMyOkBajyFYaVs7VjI060XnbsAE/yInJONZ36HQg1AzbWcghx68tieIilt2xZEGlPQ16FxNgvlbdiLKwmD1OYTWA7rGMGsvrtdtp1Wxa0xhZPNqiu9JUdjXawYstSQ3tAtw9fz2fRqCNAWRUxh1gNbxbdvKDy85TRDT85vp8fQJF4n97/bMXYk84BibxZWN38uWwNYl3FjekmJQkfGqDDmVzXp3Ez95TwljTBArpI55JQdUC8IBEY/A81aDvtKdmwaCp3tEDhn9vlEVw1U8r/liir4PMTo5m6ZzG7TgGAdiA84pSmjTnnyvkAkBkulEt7dapXVPPZTwFH07DZCZ2yf79EIWhOcrkJ1feznDGBsAC8M5Ob1ieHTrDN5RchtbQdxkz/uqYohAuaun4ypD77mLIdBQTnuL9/I2zq4gwC4YDJ++qosT8jCqQcCSHzubNoYqeJyKU x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB371610DEF383566F51D75B60FA9C0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3107 Original-Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT036.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(346002)(39860400002)(46966005)(2906002)(47076004)(55016002)(478600001)(110136005)(966005)(30864003)(316002)(83380400001)(15650500001)(166002)(9686003)(186003)(18074004)(9326002)(82740400003)(6506007)(52536014)(8936002)(33656002)(86362001)(70586007)(70206006)(336012)(81166007)(8676002)(53546011)(7696005)(5660300002)(356005)(36906005)(82310400002)(26005)(579004); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 8a4bbbb7-fe60-410b-3e41-08d8113a3f5a X-Forefront-PRVS: 04359FAD81 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rMeXs+dJ+l0HFm3PKm7nNO5i2LqCID/lyPBFGsmx5C6V1laHe5K3/lURRGoZKM4yP/Tje6iHVgeK4+NetYSQInzfRXTFJOiRIJqu0lk5CiwnOh/6XZnz3hoUdgLR6rdcSqvm8xQ9WVzAtrF/GcUgR27pX51qhQL6Uu7lDPD9g+cRGFVDJyYnktHaJNTclzKx6g8YzV5CqFKcIsmaYV53WKTPvjB07aSE6wZXP0iF5zctRJbQNA5aSWdDC/Cku4Ttw7wZKxcQ0iyacZzZ222f1tyQKqAHPzl0VsOQZ9ci9YwWWcn3e08Mea6XKPegjcKZl4krL84JrtCM9E6zjKOpb+oSYEEhnVEZM5p1lSSOzfTvbSe5WEiuwrA5epJYGIWrAWbkKspHZpuUqtyucMIZsOkvPlE/xduHZFUplIAhLWQTa8LHfMP92qePgjpesd2iN50f4wAYfBfl0YtCDrVpsA6OzZGvjTndsFvLZf+SZ/E= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2020 14:42:01.8119 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3a676fde-5829-40f3-90f2-08d8113a4400 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2776 Archived-At: X-Mailman-Approved-At: Mon, 15 Jun 2020 08:04:47 -0700 Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 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, 15 Jun 2020 14:42:09 -0000 --_000_AM0PR08MB371610DEF383566F51D75B60FA9C0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mohit, Thanks for the super-detailed response. Give me till tomorrow to parse your response. Glad to hear that you talked = about this topic already. Ciao Hannes From: Mohit Sethi M Sent: Monday, June 15, 2020 3:52 PM To: Hannes Tschofenig ; emu@ietf.org Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Hi Hannes, Unfortunately you are wrong here. The design decision was in fact taken to = avoid changes to the underlying TLS implementation while also avoiding chan= ges to RFC 3748. To summarize: Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP= -TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/= msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. Essentially, TLS 1.3 allows a server = to send a Post-Handshake message with a NewSessionTicket at any time. Howev= er, in EAP-TLS this is not possible. The TLS tunnel is torn down after auth= entication. John notes in his response to Jouni (https://mailarchive.ietf.o= rg/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS the connection is ass= umed to stay open for a long time after the client sends Finished, in EAP t= he connection is assumed to be closed shortly after." An earlier cleaner way of sending NewSessionTicket required an extra round = trip and left the peer uncertain about the next message (https://tools.ietf= .org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted thi= s uncertainty for a peer: " the peer has no idea whether the NewSessionTick= et is delivered after ClientFinished. In other words, the next message in t= he sequence could be either continuation of EAP-TLS method or EAP-Success".= You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". S= ee RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the following: Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. and On the peer, after success result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully. Thus, EAP-Success cannot be used as a reliable notification mechanism. Till= version 05 of the document, we used an empty application data record as a = notification of the last handshake message. The text said: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by appending an empty application data record (i.e. a TLS record with TLSPlaintext.type =3D application_data and TLSPlaintext.length =3D 0) to the last handshake record. After sending an empty application data record, the EAP server may only send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. However, Jouni in a later response (https://mailarchive.ietf.org/arch/msg/e= mu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted that such behavior is non-trivial to= achieve with OpenSSL. He notes " OpenSSL is not willing to send such an em= pty TLSPlaintext structure. SSL_write() has following to say : 'You should = not call SSL_write() with num=3D0, it will return an error. SSL_write_ex() = can be called with num=3D0, but will not send application data to the peer.= '" Therefore, the text was later updated to: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. The Commitment Message is a TLS record with application data 0x00 (i.e. a TLS record with TLSPlaintext.type =3D application_data, TLSPlaintext.length =3D 1, and TLSPlaintext.fragment =3D 0x00). Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handsha= ke messages. There is still a challenge in scenarios where a server chooses not to issue= any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg= /emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni notes this problem: I did see some issues when OpenSSL 1.1.1 when disabling sending of session tickets, though. The current draft indicates that the empty Application Data payload would be send out in the same EAP packet with the server's Finished message, i.e., before the server having authenticated the peer. And this would be done without the peer having used TLS early data (which is explicitly disallowed in the draft). That combination did not work with my experiments since OpenSSL was rejecting the SSL_write() operation after the server having written own Finished message, but before having received the Finished message from the peer. The OpenSSL documentation seemed to imply that SSL_write_early_data() could be used by the server _if_ the client first sent early data.. At least in my tests, OpenSSL rejected that call without early data from the client. This is why the current text also says the following: The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP- Request. Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3. In the case where the server sends the Commitment Message in a separate EAP- Request, the conversation will appear as shown in Figure 9. After sending the Commitment Message, the EAP server may only send an EAP- Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. Thus, the current design decision has been guided by parallel implementatio= n experience and it is the best solution we could come up with (given all t= he practical limitations). --Mohit On 6/12/20 11:36 AM, Hannes Tschofenig wrote: Hi all, This has probably been discussed extensively in the EMU group. I am sorry t= o bring it up again but I believe this is a bad design decision. I raised i= t in my short review just sent to the list but I believe it is worthwhile t= o point it out separately. draft-ietf-emu-eap-tls13 introduces a new message to EAP-TLS, namely the Co= mmitment Message. This requires extra code in an implementation because the= normal behavior would be to run a TLS stack and then send encrypted data. EAP-TLS does, however, not send application data*. This message changes thi= s. Not only does it not send encrypted application data it requires an impl= ementation to transmit a plaintext application data record after the applic= ation traffic secret has been created and before that application traffic s= ecret is used to protect post handshake messages. This will make it difficu= lt to re-use an off-the-shelf TLS 1.3 stack. There is very little motivation about this message other than " When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. " I might miss something important here but why cannot the EAP-Success or EAP= -Failure serve that purpose? Here are two examples to explain what I mean: 1. Failed exchange EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, TLS Finished, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Fatal Alert) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Failure 1. Successful Exchange with Post-Handshake NewSession Ticket EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS NewSessionTicket, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Success Ciao Hannes (*): FWIW Post handshake messages are protected with the application traffi= c secrets. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB371610DEF383566F51D75B60FA9C0AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mohit,

 

Thanks for the super-detailed response. <= /p>

 

Give me till tomorrow to parse your response. Glad t= o hear that you talked about this topic already.

 

Ciao

Hannes

 

From: Mohit Sethi M <mohit.m.sethi@ericsso= n.com>
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; emu@ietf.or= g
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

 

Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken = to avoid changes to the underlying TLS implementation while also avoiding c= hanges to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to = EAP-TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/.= Essentially, TLS 1.3 allows a server to send a Post-Handshake message with= a NewSessionTicket at any time. However, in EAP-TLS this is not possible. = The TLS tunnel is torn down after authentication. John notes in his response to Jouni (https://maila= rchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS= the connection is assumed to stay open for a long time after the client sends Finished, in EAP the connection is = assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra rou= nd trip and left the peer uncertain about the next message (https://= tools.ietf.org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted this uncertainty for a peer: " the peer has no idea= whether the NewSessionTicket is delivered after ClientFinished. In other w= ords, the next message in the sequence could be either continuation of EAP-= TLS method or EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". See RFC 3= 748 (https://tools.ietf.org= /html/rfc3748) which says the following:

   Implementation Note: Because the Success and Failure pack=
ets are not
   acknowledged, they are not retransmitted by the authentic=
ator, and
   may be potentially lost.  A peer MUST allow for this=
 circumstance as
   described in this note. 

and 

 On the peer, after success result indications have been exchange=
d by
   both sides, a Failure packet MUST be silently discarded.&=
nbsp; The peer
   MAY, in the event that an EAP Success is not received, co=
nclude that
   the EAP Success packet was lost and that authentication c=
oncluded
   successfully.


Thus, EAP-Success cannot be used as a reliable notification mechanism. Till= version 05 of the document, we used an empty application data record as a = notification of the last handshake message. The text said: 

When an EAP server has sent its last handshake message (Finished or a<=
o:p>
   Post-Handshake), it commits to not sending any more hands=
hake
   messages by appending an empty application data record (i=
.e. a TLS
   record with TLSPlaintext.type =3D application_data and
   TLSPlaintext.length =3D 0) to the last handshake record.&=
nbsp; After sending
   an empty application data record, the EAP server may only=
 send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS=
 Alert
   Message.

However, Jouni in a later response (https://= mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted t= hat such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL is not willing to send such = an empty TLSPlaintext structure. SSL_write() has following to say : 'You sh= ould not call SSL_write() with num=3D0, it will return an error. SSL_write_= ex() can be called with num=3D0, but will not send application data to the peer.'"

Therefore, the text was later updated to:

 When an EAP server has sent its last handshake message (=
Finished or a
   Post-Handshake), it commits to not sending any more hands=
hake
   messages by sending a Commitment Message.  The Commi=
tment Message is
   a TLS record with application data 0x00 (i.e. a TLS recor=
d with
   TLSPlaintext.type =3D application_data, TLSPlaintext.leng=
th =3D 1, and
   TLSPlaintext.fragment =3D 0x00).  Note that the leng=
th of the plaintext
   is greater than the corresponding TLSPlaintext.length due=
 to the
   inclusion of TLSInnerPlaintext.type and any padding suppl=
ied by the
   sender.  EAP server implementations MUST set TLSPlai=
ntext.fragment to
   0x00, but EAP peer implementations MUST accept any applic=
ation data
   as a Commitment Message from the EAP server to not send a=
ny more handshake messages.

 

There is still a challenge in scenarios where a server chooses not to is= sue any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ = Jouni notes this problem:

I did see some issues when OpenSSL 1.1.1 when disabling sending of
session tickets, though. The current draft indicates that the empty
Application Data payload would be send out in the same EAP packet with=

the server's Finished message, i.e., before the server having
authenticated the peer. And this would be done without the peer having=

used TLS early data (which is explicitly disallowed in the draft). Tha=
t
combination did not work with my experiments since OpenSSL was rejecti=
ng
the SSL_write() operation after the server having written own Finished=

message, but before having received the Finished message from the peer=
.
The OpenSSL documentation seemed to imply that SSL_write_early_data()<=
o:p>
could be used by the server _if_ the client first sent early data.. At=

least in my tests, OpenSSL rejected that call without early data from<=
o:p>
the client.

 

This is why the current text also says the following:

 The Commitment Message may be sent in the same
   EAP-Request as the last handshake record or in a separate=
 EAP-
   Request.  Sending the Commitment Message in a separa=
te EAP-Request
   adds an additional round-trip, but may be necessary in TL=
S
   implementations that only implement a subset of TLS 1.3.&=
nbsp; In the case
   where the server sends the Commitment Message in a separa=
te EAP-
   Request, the conversation will appear as shown in Figure =
9.  After
   sending the Commitment Message, the EAP server may only s=
end an EAP-
   Success, an EAP-Failure, or an EAP-Request with a TLS Ale=
rt Message.

 

Thus, the current design decision has been guided by parallel implementa= tion experience and it is the best solution we could come up with (given al= l the practical limitations).

--Mohit

On 6/12/20 11:36 AM, Hannes Tschofenig wrote:

Hi all,

 

This has probably been discussed extensively in the = EMU group. I am sorry to bring it up again but I believe this is a bad desi= gn decision. I raised it in my short review just sent to the list but I bel= ieve it is worthwhile to point it out separately.

 

draft-ietf-emu-eap-tls13 introduces a new message to= EAP-TLS, namely the Commitment Message. This requires extra code in an imp= lementation because the normal behavior would be to run a TLS stack and the= n send encrypted data.

EAP-TLS does, however, not send application data*. T= his message changes this. Not only does it not send encrypted application d= ata it requires an implementation to transmit a plaintext application data = record after the application traffic secret has been created and before that application traffic secret is used= to protect post handshake messages. This will make it difficult to re-use = an off-the-shelf TLS 1.3 stack.

 

There is very little motivation about this message other than =

 
“
   When an EAP server has sent i=
ts last handshake message (Finished or a
   Post-Handshake), it commits t=
o not sending any more handshake
   messages by sending a Commitm=
ent Message.
“

 

I might miss something important here but why cannot= the EAP-Success or EAP-Failure serve that purpose?

 

Here are two examples to explain what I mean: <= /o:p>

 

  1. Failed exchange

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,<=
/o:p>
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
            &nb=
sp;           TLS Finishe=
d,
       =
            &nb=
sp;            =
 <--------        Commitment Message)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS Certificate,=

    TLS CertificateVerify,<=
/span>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          (TLS Fa=
tal Alert)
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Failure

 

 

  1. Successful Exchange with Post-Handshake NewSession Ticket<= /li>

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,<=
/o:p>
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
 <--------          &n=
bsp;   TLS Finished)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS Certificate,=

    TLS CertificateVerify,<=
/span>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
        =
;            &n=
bsp;            =
;            &n=
bsp;           EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
            &nb=
sp;  (TLS NewSessionTicket,
       =
            &nb=
sp;            =
 <--------        Commitment Message)
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Success

 

 

Ciao

Hannes

 

(*): FWIW Post handshake messages are protected with= the application traffic secrets.

 

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you. 

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf=
.org/mailman/listinfo/emu
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB371610DEF383566F51D75B60FA9C0AM0PR08MB3716eurp_-- From nobody Mon Jun 15 08:15:24 2020 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 23B093A082D; Mon, 15 Jun 2020 08:15:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lflynn@amsl.com, emu@ietf.org, rdd@cert.org, emu-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159223412153.3507.13275281148526658745@ietfa.amsl.com> Date: Mon, 15 Jun 2020 08:15:22 -0700 Archived-At: Subject: [Emu] emu - New Meeting Session Request for IETF 108 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: Mon, 15 Jun 2020 15:15:22 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the emu working group. --------------------------------------------------------- Working Group Name: EAP Method Update Area Name: Security Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: saag tls cfrg lwig Technology Overlap: curdle uta secdispatch oauth mls t2trg pearg lake Key Participant Conflict: sacm quic kitten bier acme 6lo People who must be present: Jari Arkko Joseph A. Salowey Roman Danyliw Alan DeKok John Mattsson Mohit Sethi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 16 02:02:40 2020 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 A086E3A115B for ; Tue, 16 Jun 2020 02:02:38 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=MYYubVue; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=MYYubVue 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 3S8Le44dnIBq for ; Tue, 16 Jun 2020 02:02:36 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70041.outbound.protection.outlook.com [40.107.7.41]) (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 C98F23A1156 for ; Tue, 16 Jun 2020 02:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ztEuVzrk+hFjyIYUNQDGN2k0GlGsgjxPeVM8xYxUF44=; b=MYYubVueaBh99H5D31aBmWD6w7y1HW4+SZ/MxTEAotIK7S+zshTnPu34EpV18CRVxmcz1vFA62JQwReviC1kOJeAQe71KqOmO+H9cD0QT4w1qist91U6uf6j8wgqO+kXVjXKfLR9Q5NReeQgCPg5zdmWdwW9O7UqwZWrNOUR46I= Received: from DB6PR07CA0179.eurprd07.prod.outlook.com (2603:10a6:6:43::33) by VE1PR08MB4750.eurprd08.prod.outlook.com (2603:10a6:802:a2::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Tue, 16 Jun 2020 09:02:31 +0000 Received: from DB5EUR03FT005.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:43:cafe::fe) by DB6PR07CA0179.outlook.office365.com (2603:10a6:6:43::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10 via Frontend Transport; Tue, 16 Jun 2020 09:02:31 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT005.mail.protection.outlook.com (10.152.20.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Tue, 16 Jun 2020 09:02:30 +0000 Received: ("Tessian outbound 79611f28bf50:v59"); Tue, 16 Jun 2020 09:02:30 +0000 X-CR-MTA-TID: 64aa7808 Received: from a1067c7d1e6d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 5B0154D0-2F1F-405C-84C7-0945B1465125.1; Tue, 16 Jun 2020 09:02:25 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a1067c7d1e6d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 16 Jun 2020 09:02:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XFW8LL32vHgtkRMwsvHhfBFgVA1KDBB/Efr3YLuy1xZO38DmcgqH3nYL/u+TG7D6q30SybMpnvUGG8q5Zrsgo5HFVr7aVrHyrE1Bx63z7bmVmnJG17tYnb3+NniI1QfiPXapsWATScmxTiRgwIdu3pVjs+quM+qU+JJ9FJwUn8d34qJDpo4Hw00RmEwmk4WlMQ2p/w/tfiV5e+7e+FafZ2R/0/VE8nM5wvL2anEHcBTdhXpU/OWcMM6me+xrvdxVY7nEYK/h+c/jv8Q5j3F+58J93B36mpeB8JD59B+1YcDAH9vmqOfl0qq8ZQHk3FnirNE2GP4Mb1aGAHjmCgUm4Q== 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=ztEuVzrk+hFjyIYUNQDGN2k0GlGsgjxPeVM8xYxUF44=; b=j6CwNkkOuhsS+iNT8fMnoqHAIATbVMi0r68GjaZQuqaaW1lcA61f7gjy1vhhwXN4mYcSfz8y+GfNzeTamzfNwamZHULSRZ9lL9CT957QfvpQgybE1dCxKkothIBZmT3DP16rOfdflygoZ4ZInzpvXJVR9yX6U8GY+zTK6vlrAJL8UtROmQkdXY6KiwLuH1HbkpX+eQFZbjWFUkUZQcU3VxTkjtlRwZiCIPJvTY/RA7sbPdrSUM6GUr0SvdWtRG6Y+ycls+SiL1ZkCLik9IJo3LHqeCoEwhsrKRFwsFp4h/IH20QY6bqc9xKgD9kbPrs8ALCUeau3s6aVsTg+uC3pHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ztEuVzrk+hFjyIYUNQDGN2k0GlGsgjxPeVM8xYxUF44=; b=MYYubVueaBh99H5D31aBmWD6w7y1HW4+SZ/MxTEAotIK7S+zshTnPu34EpV18CRVxmcz1vFA62JQwReviC1kOJeAQe71KqOmO+H9cD0QT4w1qist91U6uf6j8wgqO+kXVjXKfLR9Q5NReeQgCPg5zdmWdwW9O7UqwZWrNOUR46I= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4178.eurprd08.prod.outlook.com (2603:10a6:208:133::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Tue, 16 Jun 2020 09:02:24 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3088.029; Tue, 16 Jun 2020 09:02:24 +0000 From: Hannes Tschofenig To: Mohit Sethi M , "emu@ietf.org" Thread-Topic: [Emu] draft-ietf-emu-eap-tls13-09 Thread-Index: AdY/BkwoNfvYGwBmQuGwz/IONkiEYwBjQ/wAAKIqb4AAKCu1oA== Date: Tue, 16 Jun 2020 09:02:24 +0000 Message-ID: References: <62ec9fad-583e-ed51-1f6c-dcfa3835c0ec@ericsson.com> In-Reply-To: <62ec9fad-583e-ed51-1f6c-dcfa3835c0ec@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: df791d93-9e68-490b-b134-cceecce990b9.0 x-checkrecipientchecked: true Authentication-Results-Original: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: bdc570b4-8128-46f1-4ecf-08d811d40059 x-ms-traffictypediagnostic: AM0PR08MB4178:|VE1PR08MB4750: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 04362AC73B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: wRZ9bo2k33X7k17fkamSKxPeYCj1q8eK2C9SBepmLfYdDQJ/q+i+PMbhRo8f4v6HlxGqMIMtE0qo6Kah/zHkMWIRwgnjdBgr+YqzpBqCbHKibGfJwkSHVbsXjezWHNHbRmbgvX79if9wm6fgsYWz7viYWC184RqNVUNwAAZAunvpyWpo3GeLUq4/G4YiM7KM37diAeS497t7BgH6BsrbDKkknoOwMJxamgugDiOXZnxfLpMVcIZnMRDpyfwheoVlPAvjq7r+IQgm8TSisaGEgKcW5cHrq50rMOI/XEiyYS+3SrzRIk3z7D6TQ6TWKi50eX6OL4AJN4AB4niiHgdOt3YgqoCzSKjADdDxjN3FabFsyj3UgwdYQaw52SAYmyX+pf96bZh5djOPKcV8UJkNMw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(396003)(366004)(39860400002)(76116006)(66446008)(66476007)(66556008)(64756008)(66946007)(52536014)(6506007)(186003)(7696005)(53546011)(86362001)(5660300002)(2906002)(55016002)(26005)(33656002)(9686003)(166002)(8936002)(8676002)(966005)(110136005)(316002)(83380400001)(71200400001)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: I1QJQwudeXnU0fGPeOQh9SrACN/degKobihcoozfI7+vonQpbMFf9gHW5wOyRx+iao/m1Of/DVvaduj47PVsUGXsnFaqf0YLqWb9ckYKVS60hPZBKzna1Y+QwPJW7sqC0flIdRfM7RbXGSVg4eDIgbCq5twhcamjpixNH6xXaV+V8VeuxdgeXZg8WxXmKZoHl7yxeaZQyI+7Xp6J7MEC0ODVi3FGpdzwFNqmLGy2m6jXXntYRiymgXBxEbaCCDNiHBC5GqnyU+gx8ybihoGlRgvuCaCtlnVg0nzLRIi6ehA+YJNT1TR7chIZNyQOAaCOOKJhsu+8ZHnPqJZmWZj1ruIJgephKaxsZeFcblf7PNZ5ViGEkbbOZU6DcVS7BzBx1t4Zj16nlM19FvXgrvJABZ7CTKd363oxd3tQFVp2MzvxuYuoJ1Yyjc4zAaGZAbRq4HSWHEjbBnvFNhkw3+CgcXvZ7pPyOxH8AwjUTOifYTZbgac5IuQJkwc7GuoS4uRC x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB371618D7FCE9EB29F2327B66FA9D0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4178 Original-Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT005.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(396003)(346002)(39860400002)(46966005)(81166007)(33656002)(186003)(26005)(356005)(2906002)(55016002)(9686003)(8676002)(8936002)(478600001)(7696005)(966005)(70586007)(5660300002)(52536014)(82310400002)(82740400003)(83380400001)(86362001)(47076004)(336012)(110136005)(166002)(6506007)(53546011)(70206006)(33964004)(316002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 7abd8f06-b19e-4256-a79e-08d811d3fc55 X-Forefront-PRVS: 04362AC73B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FaMFCBHJK+5CrL4zlHMQWi5r7XWZPXBXQieV6eX61U+VkIeNuuEUsX+PNYhDiFOWdwhTGTsWvOGs1c3M6gE6/72ojrzUgHJxFrE9pdXCq58f2XJKVoLBFt4ehA6CyOhaWqE/isLsDzDzlFMaeAwnXjzKwAux+wdpgXiowlMcPQ9k0gEH9qGCcJEaK3xKzXPO+OXdHSdIQBQTDvxz1vG6NkQA4IIYxr5rP3cDFUjQM+aa3jkDHcX2wusA/aTweXjwl1ORdN31RwykUHZGwCLpNy9rY2USosHT2NkdtIAIZDyxHP7ShaloQqKRhZkphaxBJm96feXf4vu47lFspb9Y/9u+Mr+4D5lS/AKojXBZT9NLVroQAxffuGdvahnvdjaqUcwKRaMRMpWy17NsqbbNeJ+TOWAA7iSwGb7LvfkDRiE6JDiL/gyO7HblxrfQElFOYPx6f5yz3Q0oKgIA751pMlCvEI1issHTmB2yWmYsmMM= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2020 09:02:30.9437 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bdc570b4-8128-46f1-4ecf-08d811d40059 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4750 Archived-At: Subject: Re: [Emu] draft-ietf-emu-eap-tls13-09 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, 16 Jun 2020 09:02:39 -0000 --_000_AM0PR08MB371618D7FCE9EB29F2327B66FA9D0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcywgb2YgY291cnNlLCBhIGRlY2lzaW9uIG9mIHRoZSBncm91cCBhbmQgdGhlIG1haW4g dXNlIGNhc2VzIG9mIGEgVExTLWJhc2VkIEVBUCBtZXRob2QgaXMgaW4gdGhlIHVzZSBvZiBwdWJs aWMga2V5LWJhc2VkIGF1dGhlbnRpY2F0aW9uLg0KVGVjaG5pY2FsbHksIHRoZXJlIGlzLCBob3dl dmVyLCBubyByZWFzb24gd2h5IHRoaXMgd291bGRu4oCZdCB3b3JrLg0KDQpDaWFvDQpIYW5uZXMN Cg0KRnJvbTogTW9oaXQgU2V0aGkgTSA8bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+DQpTZW50 OiBNb25kYXksIEp1bmUgMTUsIDIwMjAgMzo1MSBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxI YW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPjsgZW11QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Vt dV0gZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzLTA5DQoNCg0KSGkgSGFubmVzLA0KT24gNi8xMi8y MCAxMToyOSBBTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQoNCkEgc2hvcnQgZm9sbG93LXVw IG9uIG15IG93biByZXZpZXc6DQoNCg0KDQpJIHdyb3RlOg0KDQoNCg0KIg0KDQpQcmUtU2hhcmVk IEtleSAoUFNLKSBhdXRoZW50aWNhdGlvbiBTSEFMTCBOT1QgYmUgdXNlZCBleGNlcHQNCg0KICAg Zm9yIHJlc3VtcHRpb24uDQoNCiINCg0KV2hhdCB5b3Ugd2FudCB0byBzYXkgdGhhdCB0aGF0IEVB UC1UTFMgTVVTVCBOT1QgdXNlIGV4dGVybmFsIFBTS3MuIEkgd29uZGVyIHdoeSB5b3Ugd2FudCB0 byBydWxlIHRoYXQgdXNlIGNhc2Ugb3V0PyBJdCBpcyBhIHBlcmZlY3RseSBmaW5lIHVzZSBjYXNl IGZvciBUTFMgMS4zIGFuZCB0aGVyZSBpcyBldmVuIHRoZSBwb3NzaWJpbGl0eSB0byB1c2UgUFNL IHdpdGggRUNESEUuIFdoYXQgaXMgdGhlIG1vdGl2YXRpb24/DQoNCg0KDQpJIG5vdGljZWQgbm93 IHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFkIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIGFscmVh ZHkgYW5kIHRoYXQgdGhlcmUgaXMgYSBuZXcgZG9jdW1lbnQgYmVpbmcgcHVibGlzaGVkIHNwZWNp ZmljYWxseSBmb2N1c2VkIG9uIEVBUC1UTFMtUFNLLWJhc2VkIGF1dGhlbnRpY2F0aW9uLiBIZW5j ZSwgaWdub3JlIHRoZSBzZWNvbmQgcGFydCBvZiBteSBjb21tZW50Lg0KDQpJbmRlZWQuIFRoZXJl IGhhcyBiZWVuIGxvdHMgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLiBUbyBzdW1tYXJpemU6 DQoNClJGQyA1MjE2IGV4cGxpY2l0bHkgcmVxdWlyZWQgY2VydGlmaWNhdGUgYmFzZWQgVExTIGF1 dGhlbnRpY2F0aW9uIHdpdGggdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQogICBJZiB0aGUgRUFQIHNl cnZlciBpcyBub3QgcmVzdW1pbmcgYSBwcmV2aW91c2x5IGVzdGFibGlzaGVkIHNlc3Npb24sDQoN CiAgIHRoZW4gaXQgTVVTVCBpbmNsdWRlIGEgVExTIHNlcnZlcl9jZXJ0aWZpY2F0ZSBoYW5kc2hh a2UgbWVzc2FnZSwgYW5kDQoNCiAgIGEgc2VydmVyX2hlbGxvX2RvbmUgaGFuZHNoYWtlIG1lc3Nh Z2UgTVVTVCBiZSB0aGUgbGFzdCBoYW5kc2hha2UNCg0KICAgbWVzc2FnZSBlbmNhcHN1bGF0ZWQg aW4gdGhpcyBFQVAtUmVxdWVzdCBwYWNrZXQuDQoNCg0KDQogICBUaGUgY2VydGlmaWNhdGUgbWVz c2FnZSBjb250YWlucyBhIHB1YmxpYyBrZXkgY2VydGlmaWNhdGUgY2hhaW4gZm9yDQoNCiAgIGVp dGhlciBhIGtleSBleGNoYW5nZSBwdWJsaWMga2V5IChzdWNoIGFzIGFuIFJTQSBvciBEaWZmaWUt SGVsbG1hbg0KDQogICBrZXkgZXhjaGFuZ2UgcHVibGljIGtleSkgb3IgYSBzaWduYXR1cmUgcHVi bGljIGtleSAoc3VjaCBhcyBhbiBSU0Egb3INCg0KICAgRGlnaXRhbCBTaWduYXR1cmUgU3RhbmRh cmQgKERTUykgc2lnbmF0dXJlIHB1YmxpYyBrZXkpLg0KQmVybmFyZCBBYm9iYSBvcGluZWQgdGhh dCBleHRlcm5hbCBQU0sgYmFzZWQgYXV0aGVudGljYXRpb24gc2hvdWxkbid0IGJlIGFkZGVkIHRv IEVBUC1UTFMgaW4gdGhpcyB1cGRhdGUuIEluc3RlYWQgYSBzZXBhcmF0ZSBkb2N1bWVudCAod2l0 aCBhIHNlcGFyYXRlIEVBUCBtZXRob2QgdHlwZSkgc2hvdWxkIGRvIHRoYXQuIEhlbmNlLCB3ZSBu b3cgaGF2ZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHRzc29uLWVtdS1l YXAtdGxzLXBzay0wMC4gRm9yIHJlZmVyZW5jZSwgaGVyZSBhcmUgc29tZSBlbWFpbCBjb252ZXJz YXRpb25zIGNvbnRhaW5pbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljOg0KDQotIGh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZW11L0Z0eFJKSFRqelNZMHlWZFZyOFZqeWs5 RC12ay8NCi0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUvQ1JoM1ZY TERucEpGRkliSFdKQWppT2dmekFnLw0KLSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL2VtdS9uWXJJQTRQS3FrMm1yVW9OdkF0Rmg3Uy1YYjgvDQotIGh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZW11L2hWRzM1N0hYcXZ5MEVqWjJ5ck9MZHNwSDUzby8N Cg0KLS1Nb2hpdA0KDQoNCg0KDQoNCkNpYW8NCg0KSGFubmVzDQoNCg0KDQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpFbXUgbWFpbGluZyBsaXN0DQoNCkVtdUBpZXRmLm9y ZzxtYWlsdG86RW11QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2VtdQ0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9y ZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_AM0PR08MB371618D7FCE9EB29F2327B66FA9D0AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBpcywgb2YgY291cnNlLCBhIGRlY2lzaW9uIG9mIHRoZSBncm91cCBh bmQgdGhlIG1haW4gdXNlIGNhc2VzIG9mIGEgVExTLWJhc2VkIEVBUCBtZXRob2QgaXMgaW4gdGhl IHVzZSBvZiBwdWJsaWMga2V5LWJhc2VkIGF1dGhlbnRpY2F0aW9uLg0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWNobmljYWxseSwgdGhlcmUgaXMsIGhvd2V2ZXIsIG5v IHJlYXNvbiB3aHkgdGhpcyB3b3VsZG7igJl0IHdvcmsuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gTW9oaXQgU2V0aGkgTSAmbHQ7bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20mZ3Q7 IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTUsIDIwMjAgMzo1MSBQTTxicj4NCjxi PlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20m Z3Q7OyBlbXVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtFbXVdIGRyYWZ0LWll dGYtZW11LWVhcC10bHMxMy0wOTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SGkgSGFubmVzLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDYvMTIvMjAgMTE6Mjkg QU0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw cmU+QSBzaG9ydCBmb2xsb3ctdXAgb24gbXkgb3duIHJldmlldzo8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIHdyb3RlOjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+JnF1b3Q7PG86cD48L286 cD48L3ByZT4NCjxwcmU+UHJlLVNoYXJlZCBLZXkgKFBTSykgYXV0aGVudGljYXRpb24gU0hBTEwg Tk9UIGJlIHVzZWQgZXhjZXB0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZv ciByZXN1bXB0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZxdW90OzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPldoYXQgeW91IHdhbnQgdG8gc2F5IHRoYXQgdGhhdCBFQVAtVExTIE1VU1QgTk9U IHVzZSBleHRlcm5hbCBQU0tzLiBJIHdvbmRlciB3aHkgeW91IHdhbnQgdG8gcnVsZSB0aGF0IHVz ZSBjYXNlIG91dD8gSXQgaXMgYSBwZXJmZWN0bHkgZmluZSB1c2UgY2FzZSBmb3IgVExTIDEuMyBh bmQgdGhlcmUgaXMgZXZlbiB0aGUgcG9zc2liaWxpdHkgdG8gdXNlIFBTSyB3aXRoIEVDREhFLiBX aGF0IGlzIHRoZSBtb3RpdmF0aW9uPzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgbm90aWNlZCBub3cgdGhhdCB0aGUg d29ya2luZyBncm91cCBoYWQgYSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgYWxyZWFkeSBhbmQgdGhh dCB0aGVyZSBpcyBhIG5ldyBkb2N1bWVudCBiZWluZyBwdWJsaXNoZWQgc3BlY2lmaWNhbGx5IGZv Y3VzZWQgb24gRUFQLVRMUy1QU0stYmFzZWQgYXV0aGVudGljYXRpb24uIEhlbmNlLCBpZ25vcmUg dGhlIHNlY29uZCBwYXJ0IG9mIG15IGNvbW1lbnQuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx dW90ZT4NCjxwPkluZGVlZC4gVGhlcmUgaGFzIGJlZW4gbG90cyBvZiBkaXNjdXNzaW9uIG9uIHRo aXMgdG9waWMuIFRvIHN1bW1hcml6ZTo8bzpwPjwvbzpwPjwvcD4NCjxwPlJGQyA1MjE2IGV4cGxp Y2l0bHkgcmVxdWlyZWQgY2VydGlmaWNhdGUgYmFzZWQgVExTIGF1dGhlbnRpY2F0aW9uIHdpdGgg dGhlIGZvbGxvd2luZyB0ZXh0OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiZuYnNwOyZuYnNwOyBJ ZiB0aGUgRUFQIHNlcnZlciBpcyBub3QgcmVzdW1pbmcgYSBwcmV2aW91c2x5IGVzdGFibGlzaGVk IHNlc3Npb24sPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoZW4gaXQgTVVT VCBpbmNsdWRlIGEgVExTIHNlcnZlcl9jZXJ0aWZpY2F0ZSBoYW5kc2hha2UgbWVzc2FnZSwgYW5k PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGEgc2VydmVyX2hlbGxvX2RvbmUg aGFuZHNoYWtlIG1lc3NhZ2UgTVVTVCBiZSB0aGUgbGFzdCBoYW5kc2hha2U8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbWVzc2FnZSBlbmNhcHN1bGF0ZWQgaW4gdGhpcyBFQVAt UmVxdWVzdCBwYWNrZXQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBjZXJ0aWZpY2F0ZSBtZXNzYWdlIGNvbnRhaW5z IGEgcHVibGljIGtleSBjZXJ0aWZpY2F0ZSBjaGFpbiBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgZWl0aGVyIGEga2V5IGV4Y2hhbmdlIHB1YmxpYyBrZXkgKHN1Y2ggYXMg YW4gUlNBIG9yIERpZmZpZS1IZWxsbWFuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IGtleSBleGNoYW5nZSBwdWJsaWMga2V5KSBvciBhIHNpZ25hdHVyZSBwdWJsaWMga2V5IChz dWNoIGFzIGFuIFJTQSBvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBEaWdp dGFsIFNpZ25hdHVyZSBTdGFuZGFyZCAoRFNTKSBzaWduYXR1cmUgcHVibGljIGtleSkuPG86cD48 L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlcm5hcmQg QWJvYmEgb3BpbmVkIHRoYXQgZXh0ZXJuYWwgUFNLIGJhc2VkIGF1dGhlbnRpY2F0aW9uIHNob3Vs ZG4ndCBiZSBhZGRlZCB0byBFQVAtVExTIGluIHRoaXMgdXBkYXRlLiBJbnN0ZWFkIGEgc2VwYXJh dGUgZG9jdW1lbnQgKHdpdGggYSBzZXBhcmF0ZSBFQVAgbWV0aG9kIHR5cGUpIHNob3VsZCBkbyB0 aGF0LiBIZW5jZSwgd2Ugbm93IGhhdmU6DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbWF0dHNzb24tZW11LWVhcC10bHMtcHNrLTAwIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24tZW11LWVhcC10bHMtcHNrLTAwPC9hPi4gRm9yIHJl ZmVyZW5jZSwgaGVyZSBhcmUgc29tZSBlbWFpbCBjb252ZXJzYXRpb25zIGNvbnRhaW5pbmcgZGlz Y3Vzc2lvbiBvbiB0aGlzIHRvcGljOg0KPG86cD48L286cD48L3A+DQo8cD4tIDxhIGhyZWY9Imh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZW11L0Z0eFJKSFRqelNZMHlWZFZy OFZqeWs5RC12ay8iPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUv RnR4UkpIVGp6U1kweVZkVnI4Vmp5azlELXZrLzwvYT48YnI+DQotIDxhIGhyZWY9Imh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZW11L0NSaDNWWExEbnBKRkZJYkhXSkFqaU9n ZnpBZy8iPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUvQ1JoM1ZY TERucEpGRkliSFdKQWppT2dmekFnLzwvYT48YnI+DQotIDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZW11L25ZcklBNFBLcWsybXJVb052QXRGaDdTLVhiOC8i Pg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUvbllySUE0UEtxazJt clVvTnZBdEZoN1MtWGI4LzwvYT48YnI+DQotIDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvZW11L2hWRzM1N0hYcXZ5MEVqWjJ5ck9MZHNwSDUzby8iPg0KaHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUvaFZHMzU3SFhxdnkwRWpaMnly T0xkc3BINTNvLzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPi0tTW9oaXQ8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT5DaWFvPG86cD48L286cD48L3ByZT4NCjxwcmU+SGFubmVzPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS4gVGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+RW11IG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpFbXVAaWV0Zi5vcmciPkVtdUBpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2VtdSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lbXU8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBp bmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR08MB371618D7FCE9EB29F2327B66FA9D0AM0PR08MB3716eurp_-- From nobody Tue Jun 16 03:03:44 2020 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 189E23A143C for ; Tue, 16 Jun 2020 02:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=1gzNcf89; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=1gzNcf89 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 comUnbkFem6p for ; Tue, 16 Jun 2020 02:38:21 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2067.outbound.protection.outlook.com [40.107.22.67]) (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 928D53A14B0 for ; Tue, 16 Jun 2020 02:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OGFHv1drxhclQTYvjsd5ZI5qKmzUr587nWVmI/KkKd4=; b=1gzNcf89AVW4DFcEuIz+ICM3L9/xid+dsMVnmmxLZjtKpx9gUAZBz6vA8Qpd96B8Gci1Xl7FZeGrpSEDJN7tUWaWb2QBoUFthYunDVMEUb766tAZNN3XW5qYDen1i/poYmIBaMuDfuzXOLaBdnBM7mFklV/7+5ETmKbSmCG5il0= Received: from DBBPR09CA0016.eurprd09.prod.outlook.com (2603:10a6:10:c0::28) by DB8PR08MB4059.eurprd08.prod.outlook.com (2603:10a6:10:a9::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Tue, 16 Jun 2020 09:38:06 +0000 Received: from DB5EUR03FT005.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:c0:cafe::7a) by DBBPR09CA0016.outlook.office365.com (2603:10a6:10:c0::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21 via Frontend Transport; Tue, 16 Jun 2020 09:38:06 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT005.mail.protection.outlook.com (10.152.20.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Tue, 16 Jun 2020 09:38:06 +0000 Received: ("Tessian outbound c26a22531de7:v59"); Tue, 16 Jun 2020 09:38:06 +0000 X-CR-MTA-TID: 64aa7808 Received: from 4746a8dcca56.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A95BBE28-6624-4A33-8D2E-6B28F50E4A30.1; Tue, 16 Jun 2020 09:38:01 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4746a8dcca56.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 16 Jun 2020 09:38:01 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m1hErRrs6X3bYtYp+ADBk3TpY2EHfV6Fc9MsfhoUGWqmKflbAk9dXRt4aKd4XwAQLMkti/iG+lnZq4DnNum8Tu7FC0BQ+rTL138nzWR/XjT87M+NfUZt70xQGZPZ1EzgF3Srrn1pzp1lq5ncABc1cakkwXPKiMZKaoAYoWz1aOurT19Ld8kbyqLdjaieFTXNx6SykWqwSz2pMbSYoBgmna9sWnz3g/r9yARLzGyQmpN7ZxwP9gnTYCMQbdcuCFZp+hhkw2rsqv1j35pMbXgNVVy3defF5GaqMBTd1t/VkXdsPoEGoKK+n0k5svnDb2JOmH81hj4OhZjPbSmV1EX+iQ== 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=OGFHv1drxhclQTYvjsd5ZI5qKmzUr587nWVmI/KkKd4=; b=c0A7BWnFbjFipEuGm84i+tkLDs/77oicsMNqFGMnvdM0Ya0RI+7ozfu5dO8M2Dos2ooubMnWa8Du2Yw4WuH0jT43y7dsDjAO4bHL8uoLN79oZq+Ahb+npzwwvlGlrjyBp7pgwn/YFoMtqLc1yPyKrFswhXtbSOWLJC9NLfax/AXjF8HblkVInMw7x6G3K5SrS32EOMlZ1clhULN1yHHIxeBMuPrqU8C9+UX7ILY7znIaYwoTLz7+sCV0r5fSd52WqIwfKi//5LHfUjuUpxkWRtxL6J2A3irAtsqnSvBziGpWEGzv9/Py4++2PEow9Aii7GEDcygHXtXrKpHo2wksBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OGFHv1drxhclQTYvjsd5ZI5qKmzUr587nWVmI/KkKd4=; b=1gzNcf89AVW4DFcEuIz+ICM3L9/xid+dsMVnmmxLZjtKpx9gUAZBz6vA8Qpd96B8Gci1Xl7FZeGrpSEDJN7tUWaWb2QBoUFthYunDVMEUb766tAZNN3XW5qYDen1i/poYmIBaMuDfuzXOLaBdnBM7mFklV/7+5ETmKbSmCG5il0= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3795.eurprd08.prod.outlook.com (2603:10a6:208:105::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19; Tue, 16 Jun 2020 09:37:58 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3088.029; Tue, 16 Jun 2020 09:37:58 +0000 From: Hannes Tschofenig To: Mohit Sethi M , "emu@ietf.org" Thread-Topic: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Thread-Index: AdZAkc+cCh243U45Rdqk3n8/SPrXVQCilGmAACgxZ7A= Date: Tue, 16 Jun 2020 09:37:58 +0000 Message-ID: References: <1e769dbd-b563-0ba6-c398-8066c6151310@ericsson.com> In-Reply-To: <1e769dbd-b563-0ba6-c398-8066c6151310@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: a5c85e4f-2dda-4b3e-bb4d-9aa88cb7e0d9.0 x-checkrecipientchecked: true Authentication-Results-Original: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 7fa4e330-35ef-4fa0-f66a-08d811d8f919 x-ms-traffictypediagnostic: AM0PR08MB3795:|DB8PR08MB4059: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04362AC73B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: ES394eu8n03ZbNDs4nLK3DOv8KHhHwGgH+GeIQs36GwOLcWYK7xCPqPXymqFG7paQdXaJd5BacAH4TaWcH+k3uBpb1ksb89ySbrvVp5PkwDDjKTUnkc9y81JmQ8sDsIbOHUjoamAcyDBZ4i+0OHW4iF4SvtYr/wG3HFDb/NKIqk5V/P0nBZd/hUCBSxdvgoMZcKxvAPxoXwhz44wX9HSfnXaKdq3Kh+jel6vY79RtnLrJAtZT2oLG3e3yn6n8r7dCsKeaTrR+5dr8FnFv17Q55weBBqYByYhVl1LQev4yImM+ny/0YorPxB74GUJH3AA5ZV0wQHNDUiQ4FCqrcdhLDUhL3g7LMMbdr5gMjFY+1pL1zWOZ0vY8Pxfc6ZC2h98xVmwlBz5r3C5b7Ieb4DJ2A== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(346002)(39860400002)(136003)(376002)(66476007)(66556008)(66946007)(8936002)(9326002)(64756008)(8676002)(2906002)(66446008)(966005)(15650500001)(478600001)(86362001)(76116006)(166002)(83380400001)(9686003)(55016002)(71200400001)(30864003)(52536014)(5660300002)(316002)(110136005)(6506007)(7696005)(186003)(26005)(53546011)(18074004)(33656002)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: vdVaSWBHbZDYwgIFu1DtQSI+ED58b+uJU89oSf60vsxmWw8s0h6gwFynC1rom2c14S4uN2ew2NshjQzQjNZ/sYRL8lqS01c8oar2Y9fZyoarU1Aq594atLK1WQ6OwK3FRtDpD/jrEsLQQsyH+dUUu9QiuDj1WwoTmzw5BuwQ/nzZrJkNNw7xOzaoyF0cyz726rdpje6OlxQhdd7kRgpuq0LuY07EtBgduDnCKseDnGIethaHv32ZTp1HxoE1iirUfUBReCAbszT24kPf18Q4rV3FXAN9nOiPFm3GrJouUl09MavIjgwxYO3niz/StCDStVVkLerW+PtTNCpiynyuOyizIo6AqKH9EWK7xb6DSx1jqWK+OVO3MEfjNR7AAMnsnymacG028lHZYsEk5Z3zEjeEQ+dwO9E3RUw2pOSI5EhOR/GjAReyq3qtQe+k+29xxRF1EMdgoNU0UKPHA1jWCEzDauYAkI8l2pGMI6yuf/FXv+eOG8b+TQnX0dc9ahMD x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716E91CA6F8D39A6F7AF3AEFA9D0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3795 Original-Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT005.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(136003)(396003)(46966005)(83380400001)(82310400002)(166002)(356005)(33656002)(110136005)(81166007)(8676002)(316002)(9686003)(8936002)(9326002)(26005)(55016002)(2906002)(52536014)(336012)(186003)(30864003)(5660300002)(15650500001)(966005)(6506007)(86362001)(7696005)(18074004)(82740400003)(478600001)(70206006)(47076004)(70586007)(53546011)(579004)(559001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 080f1c78-20b9-4147-4d4c-08d811d8f491 X-Forefront-PRVS: 04362AC73B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2V6Cb/dINj3A09yI+9QoTAfUOCWOIBkSNfc5km44kYMpGpqGiIHexak73v6P5YqIz42IBmVSiXgJOUU3rYDiL/qlfl3Tv23uQa7GT/Bl1HTnNBF/4+UnKztqUV116xAIiwS0pBPzr6KqaJRGCfsGpvZ6t5ZOBlBBVlzcoOGjUho5z7vIoQO8S2oJvm7KlIaIJcbFEtPReBaSt2FD8X0bxFbM9OnmsAkg7Nfb0VLb36272tXdpWQzK2NvS0eQwqkPJOLOJp+a1dW4GGFHH1XaNSzyxfDPdVUcl27XLAooJ0Yn0HLCx2pjZAL/EW+XnyRRlJazNPN5fvQzvTV0drzZ4bResRceXlMI9ykwNmcn3zzxAvEb1M7AybuPH6gRxpJoamnAiTkTnV2bzXZSb5nFcOJwB+prV4GK//PHIWfb0D2SZpxcVEEkciv8tPG4ECduj8gQ2vD2UyDRHK9kph8AmzDYcBm+MG2n81PhEVadBhg= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2020 09:38:06.2691 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7fa4e330-35ef-4fa0-f66a-08d811d8f919 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB4059 Archived-At: X-Mailman-Approved-At: Tue, 16 Jun 2020 03:03:42 -0700 Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 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, 16 Jun 2020 09:38:25 -0000 --_000_AM0PR08MB3716E91CA6F8D39A6F7AF3AEFA9D0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mohit, I had a chance to read through the emails you provided. A good discussion. I can offer three solutions: 1. Use EAP-Success / EAP-Failure as an indication for the completion of = the exchange, even if it is not a reliable notification mechanism. If the E= AP peer does not receive the NewSessionTicket message then it does not matt= er because it is optional to use anyway. It will be a failure case anyway i= f the EAP-Success / EAP-Failure got lost. They EAP peer may not even know w= hether the exchange was successful despite correctly processing TLS handsha= ke messages. 1. Demand that the NewSessionTicket is sent immediately after the Finish= ed, very much like you currently demand that the Commitment Message is atta= ched to the last message. 1. Use the Commitment Message as an application layer payload (encrypted= as it should be). (Note that this has nothing to do with early data.) If t= he OpenSSL spec does not support an application layer message from the serv= er right after the finish then it is not compliant to the TLS 1.3 RFC. The current solution in the draft, for example, does not work with Mbed TLS= because you cannot tell the stack to suddenly bypass the encryption layer = (after successfully establishing it) to send a plaintext message. Ciao Hannes From: Mohit Sethi M Sent: Monday, June 15, 2020 3:52 PM To: Hannes Tschofenig ; emu@ietf.org Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Hi Hannes, Unfortunately you are wrong here. The design decision was in fact taken to = avoid changes to the underlying TLS implementation while also avoiding chan= ges to RFC 3748. To summarize: Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP= -TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/= msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. Essentially, TLS 1.3 allows a server = to send a Post-Handshake message with a NewSessionTicket at any time. Howev= er, in EAP-TLS this is not possible. The TLS tunnel is torn down after auth= entication. John notes in his response to Jouni (https://mailarchive.ietf.o= rg/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS the connection is ass= umed to stay open for a long time after the client sends Finished, in EAP t= he connection is assumed to be closed shortly after." An earlier cleaner way of sending NewSessionTicket required an extra round = trip and left the peer uncertain about the next message (https://tools.ietf= .org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted thi= s uncertainty for a peer: " the peer has no idea whether the NewSessionTick= et is delivered after ClientFinished. In other words, the next message in t= he sequence could be either continuation of EAP-TLS method or EAP-Success".= You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". S= ee RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the following: Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. and On the peer, after success result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully. Thus, EAP-Success cannot be used as a reliable notification mechanism. Till= version 05 of the document, we used an empty application data record as a = notification of the last handshake message. The text said: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by appending an empty application data record (i.e. a TLS record with TLSPlaintext.type =3D application_data and TLSPlaintext.length =3D 0) to the last handshake record. After sending an empty application data record, the EAP server may only send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. However, Jouni in a later response (https://mailarchive.ietf.org/arch/msg/e= mu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted that such behavior is non-trivial to= achieve with OpenSSL. He notes " OpenSSL is not willing to send such an em= pty TLSPlaintext structure. SSL_write() has following to say : 'You should = not call SSL_write() with num=3D0, it will return an error. SSL_write_ex() = can be called with num=3D0, but will not send application data to the peer.= '" Therefore, the text was later updated to: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. The Commitment Message is a TLS record with application data 0x00 (i.e. a TLS record with TLSPlaintext.type =3D application_data, TLSPlaintext.length =3D 1, and TLSPlaintext.fragment =3D 0x00). Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handsha= ke messages. There is still a challenge in scenarios where a server chooses not to issue= any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg= /emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni notes this problem: I did see some issues when OpenSSL 1.1.1 when disabling sending of session tickets, though. The current draft indicates that the empty Application Data payload would be send out in the same EAP packet with the server's Finished message, i.e., before the server having authenticated the peer. And this would be done without the peer having used TLS early data (which is explicitly disallowed in the draft). That combination did not work with my experiments since OpenSSL was rejecting the SSL_write() operation after the server having written own Finished message, but before having received the Finished message from the peer. The OpenSSL documentation seemed to imply that SSL_write_early_data() could be used by the server _if_ the client first sent early data.. At least in my tests, OpenSSL rejected that call without early data from the client. This is why the current text also says the following: The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP- Request. Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3. In the case where the server sends the Commitment Message in a separate EAP- Request, the conversation will appear as shown in Figure 9. After sending the Commitment Message, the EAP server may only send an EAP- Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. Thus, the current design decision has been guided by parallel implementatio= n experience and it is the best solution we could come up with (given all t= he practical limitations). --Mohit On 6/12/20 11:36 AM, Hannes Tschofenig wrote: Hi all, This has probably been discussed extensively in the EMU group. I am sorry t= o bring it up again but I believe this is a bad design decision. I raised i= t in my short review just sent to the list but I believe it is worthwhile t= o point it out separately. draft-ietf-emu-eap-tls13 introduces a new message to EAP-TLS, namely the Co= mmitment Message. This requires extra code in an implementation because the= normal behavior would be to run a TLS stack and then send encrypted data. EAP-TLS does, however, not send application data*. This message changes thi= s. Not only does it not send encrypted application data it requires an impl= ementation to transmit a plaintext application data record after the applic= ation traffic secret has been created and before that application traffic s= ecret is used to protect post handshake messages. This will make it difficu= lt to re-use an off-the-shelf TLS 1.3 stack. There is very little motivation about this message other than " When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. " I might miss something important here but why cannot the EAP-Success or EAP= -Failure serve that purpose? Here are two examples to explain what I mean: 1. Failed exchange EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, TLS Finished, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Fatal Alert) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Failure 1. Successful Exchange with Post-Handshake NewSession Ticket EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS NewSessionTicket, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Success Ciao Hannes (*): FWIW Post handshake messages are protected with the application traffi= c secrets. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB3716E91CA6F8D39A6F7AF3AEFA9D0AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mohit,

 

I had a chance to read through the emails you provid= ed. A good discussion.

 

I can offer three solutions:

 

  1. Use EAP-Success / EAP-Failure as an indication for the completion of = the exchange, even if it is not a reliable notification mechanism. If the E= AP peer does not receive the NewSessionTicket message then it does not matter because it is optional to use anyway. It w= ill be a failure case anyway if the EAP-Success / EAP-Failure got lost. The= y EAP peer may not even know whether the exchange was successful despite co= rrectly processing TLS handshake messages.

 

  1. Demand that the NewSessionTicket is sent immediately after the Finish= ed, very much like you currently demand that the Commitment Message is atta= ched to the last message.

 

  1. Use the Commitment Message as an application layer payload (encrypted= as it should be). (Note that this has nothing to do with early data.) If t= he OpenSSL spec does not support an application layer message from the server right after the finish then it i= s not compliant to the TLS 1.3 RFC.

 

The current solution in the draft, for example, does= not work with Mbed TLS because you cannot tell the stack to suddenly bypas= s the encryption layer (after successfully establishing it) to send a plain= text message.

 

Ciao

Hannes

 

From: Mohit Sethi M <mohit.m.sethi@ericsso= n.com>
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; emu@ietf.or= g
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

 

Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken = to avoid changes to the underlying TLS implementation while also avoiding c= hanges to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to = EAP-TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/.= Essentially, TLS 1.3 allows a server to send a Post-Handshake message with= a NewSessionTicket at any time. However, in EAP-TLS this is not possible. = The TLS tunnel is torn down after authentication. John notes in his response to Jouni (https://maila= rchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS= the connection is assumed to stay open for a long time after the client sends Finished, in EAP the connection is = assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra rou= nd trip and left the peer uncertain about the next message (https://= tools.ietf.org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted this uncertainty for a peer: " the peer has no idea= whether the NewSessionTicket is delivered after ClientFinished. In other w= ords, the next message in the sequence could be either continuation of EAP-= TLS method or EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". See RFC 3= 748 (https://tools.ietf.org= /html/rfc3748) which says the following:

   Implementation Note: Because the Success and Failure pack=
ets are not
   acknowledged, they are not retransmitted by the authentic=
ator, and
   may be potentially lost.  A peer MUST allow for this=
 circumstance as
   described in this note. 

and 

 On the peer, after success result indications have been exchange=
d by
   both sides, a Failure packet MUST be silently discarded.&=
nbsp; The peer
   MAY, in the event that an EAP Success is not received, co=
nclude that
   the EAP Success packet was lost and that authentication c=
oncluded
   successfully.


Thus, EAP-Success cannot be used as a reliable notification mechanism. Till= version 05 of the document, we used an empty application data record as a = notification of the last handshake message. The text said: 

When an EAP server has sent its last handshake message (Finished or a<=
o:p>
   Post-Handshake), it commits to not sending any more hands=
hake
   messages by appending an empty application data record (i=
.e. a TLS
   record with TLSPlaintext.type =3D application_data and
   TLSPlaintext.length =3D 0) to the last handshake record.&=
nbsp; After sending
   an empty application data record, the EAP server may only=
 send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS=
 Alert
   Message.

However, Jouni in a later response (https://= mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted t= hat such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL is not willing to send such = an empty TLSPlaintext structure. SSL_write() has following to say : 'You sh= ould not call SSL_write() with num=3D0, it will return an error. SSL_write_= ex() can be called with num=3D0, but will not send application data to the peer.'"

Therefore, the text was later updated to:

 When an EAP server has sent its last handshake message (=
Finished or a
   Post-Handshake), it commits to not sending any more hands=
hake
   messages by sending a Commitment Message.  The Commi=
tment Message is
   a TLS record with application data 0x00 (i.e. a TLS recor=
d with
   TLSPlaintext.type =3D application_data, TLSPlaintext.leng=
th =3D 1, and
   TLSPlaintext.fragment =3D 0x00).  Note that the leng=
th of the plaintext
   is greater than the corresponding TLSPlaintext.length due=
 to the
   inclusion of TLSInnerPlaintext.type and any padding suppl=
ied by the
   sender.  EAP server implementations MUST set TLSPlai=
ntext.fragment to
   0x00, but EAP peer implementations MUST accept any applic=
ation data
   as a Commitment Message from the EAP server to not send a=
ny more handshake messages.

 

There is still a challenge in scenarios where a server chooses not to is= sue any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ = Jouni notes this problem:

I did see some issues when OpenSSL 1.1.1 when disabling sending of
session tickets, though. The current draft indicates that the empty
Application Data payload would be send out in the same EAP packet with=

the server's Finished message, i.e., before the server having
authenticated the peer. And this would be done without the peer having=

used TLS early data (which is explicitly disallowed in the draft). Tha=
t
combination did not work with my experiments since OpenSSL was rejecti=
ng
the SSL_write() operation after the server having written own Finished=

message, but before having received the Finished message from the peer=
.
The OpenSSL documentation seemed to imply that SSL_write_early_data()<=
o:p>
could be used by the server _if_ the client first sent early data.. At=

least in my tests, OpenSSL rejected that call without early data from<=
o:p>
the client.

 

This is why the current text also says the following:

 The Commitment Message may be sent in the same
   EAP-Request as the last handshake record or in a separate=
 EAP-
   Request.  Sending the Commitment Message in a separa=
te EAP-Request
   adds an additional round-trip, but may be necessary in TL=
S
   implementations that only implement a subset of TLS 1.3.&=
nbsp; In the case
   where the server sends the Commitment Message in a separa=
te EAP-
   Request, the conversation will appear as shown in Figure =
9.  After
   sending the Commitment Message, the EAP server may only s=
end an EAP-
   Success, an EAP-Failure, or an EAP-Request with a TLS Ale=
rt Message.

 

Thus, the current design decision has been guided by parallel implementa= tion experience and it is the best solution we could come up with (given al= l the practical limitations).

--Mohit

On 6/12/20 11:36 AM, Hannes Tschofenig wrote:

Hi all,

 

This has probably been discussed extensively in the = EMU group. I am sorry to bring it up again but I believe this is a bad desi= gn decision. I raised it in my short review just sent to the list but I bel= ieve it is worthwhile to point it out separately.

 

draft-ietf-emu-eap-tls13 introduces a new message to= EAP-TLS, namely the Commitment Message. This requires extra code in an imp= lementation because the normal behavior would be to run a TLS stack and the= n send encrypted data.

EAP-TLS does, however, not send application data*. T= his message changes this. Not only does it not send encrypted application d= ata it requires an implementation to transmit a plaintext application data = record after the application traffic secret has been created and before that application traffic secret is used= to protect post handshake messages. This will make it difficult to re-use = an off-the-shelf TLS 1.3 stack.

 

There is very little motivation about this message other than =

 
“
   When an EAP server has sent i=
ts last handshake message (Finished or a
   Post-Handshake), it commits t=
o not sending any more handshake
   messages by sending a Commitm=
ent Message.
“

 

I might miss something important here but why cannot= the EAP-Success or EAP-Failure serve that purpose?

 

Here are two examples to explain what I mean: <= /o:p>

 

  1. Failed exchange

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,<=
/o:p>
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
            &nb=
sp;           TLS Finishe=
d,
       =
            &nb=
sp;            =
 <--------        Commitment Message)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS Certificate,=

    TLS CertificateVerify,<=
/span>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          (TLS Fa=
tal Alert)
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Failure

 

 

  1. Successful Exchange with Post-Handshake NewSession Ticket<= /li>

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,<=
/o:p>
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
 <--------          &n=
bsp;   TLS Finished)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS Certificate,=

    TLS CertificateVerify,<=
/span>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
        =
;            &n=
bsp;            =
;            &n=
bsp;           EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
            &nb=
sp;  (TLS NewSessionTicket,
       =
            &nb=
sp;            =
 <--------        Commitment Message)
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Success

 

 

Ciao

Hannes

 

(*): FWIW Post handshake messages are protected with= the application traffic secrets.

 

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you. 

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf=
.org/mailman/listinfo/emu
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB3716E91CA6F8D39A6F7AF3AEFA9D0AM0PR08MB3716eurp_-- From nobody Tue Jun 16 03:25:24 2020 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 12B3B3A14CC for ; Tue, 16 Jun 2020 03:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 TvYnuvxu9gLU for ; Tue, 16 Jun 2020 03:25:19 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80071.outbound.protection.outlook.com [40.107.8.71]) (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 2E7C53A117B for ; Tue, 16 Jun 2020 03:25:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KkP5tQZNpIynRu15jJuiuhkYzi5CvXogHjumqxK0b1C1SsJRT2br4W71BA1i5RvSWmY6V9ORKqL3iqjqo+tSv/KBTDQDaGKEHG/LjtPqtBoSM1UjiQcR1ZYU7C8s6M9vTZ7JpxcmsS4gGpX+Coffa6OXjTY307KK3CFk1MFqTrw+F5TyInI+8A7xutmZiE+Hb2R/azrgxA6raTV65FyzXCWHTsGAmsJx0c5I4VXvxqNHka06RuxHZWqoLLGJlpTi+6Aa6hR4L1yZvN6Gzyly+h2C0vVOa4WcfmcPltiE2nGAHc4OnmaQuObOA9iSiG3s53fGkxUkmdzmFjw+V2BYrg== 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=Dp11hRY3pJtOcn3p2k0nkZYppIsPIlN74RbEIRZpZqw=; b=hBTLnyxrXeV8ZoIuZolwQEunvtP1w+rJkO+KuoGLiVtzQ7G5HDDtnN7363tdYMkAHKF2eCAoUr7o0i/fdAwAglFXd67Xn5NfQSnCaujb4UJIwXeO5hcLHii51bMgjEqbXAulhojSrplH1QndOuWRQaAgmXvvxMIp9c3alVXLs2s8+Tt0YMcTnS31769sayWIQfWZqV6yQ0mhZbLc8KgUTLAv+FgjrnSKDTkW6XF1cPgknjjBv7xpW0VBdI2qBlE0AS3IE3gIko93zArZUjtdhdsqssHGPc98HR7u88dx8nDdk4rqILFIb5Hi9/q3dtVR7V2AxTJtd9cVrl7pfxE7Jw== 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=Dp11hRY3pJtOcn3p2k0nkZYppIsPIlN74RbEIRZpZqw=; b=XMms4UIoS2P9xDT+K9mgAOoYbCzh9jIUPFA1SnDj0jJU3nMWcim8G5AZDD2in8Ne18k+wq+j41CfsnfMyTx/qcV+lHox0fDprOuZvX5Ke8oSiNqAPMgbbqE19Nu+Py7LLMowwgxhPe73aD5uJQQ3c2Ljghgq2qBMM3JOYOUXjkg= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR07MB3195.eurprd07.prod.outlook.com (2603:10a6:7:2f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.20; Tue, 16 Jun 2020 10:25:15 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e%7]) with mapi id 15.20.3109.018; Tue, 16 Jun 2020 10:25:14 +0000 From: Mohit Sethi M To: Hannes Tschofenig , Mohit Sethi M , "emu@ietf.org" Thread-Topic: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Thread-Index: AQHWQxwhidapLR1LHUae6YFWy2dwOqja/WsAgAANM4A= Date: Tue, 16 Jun 2020 10:25:14 +0000 Message-ID: <116a2a3f-9d9c-d99e-715a-2531f59da7a8@ericsson.com> References: <1e769dbd-b563-0ba6-c398-8066c6151310@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:4147:9db5:d2f7:7e10:bb6b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 840ebd94-4843-4fb5-aa10-08d811df8f26 x-ms-traffictypediagnostic: HE1PR07MB3195: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 04362AC73B x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7rqZ8zXBxT8aes0npUdjmw+Y+CWgez4fquBV/MHdoqnCKDhhRel/D2EtcLPjcaCo9RHlk7UEsjhiQELul/1k2+4cvhITEFMx+RgIKBZUKr7q2DK0PkiBUWgcuk8HFRLlYq+ZzqtCxx9/oUlLXIsOlhmXeXkUWT5z9ihcYjtMliPDeCjsNgiGSRiEGkp8swzYh7XhxAaC7WpYIG+02eOpPiycvWs9es7DG//LiUcfWanY8R29gYckl/muYtzkVhjJDDp5zqoW+7yLZlOYMBEpd5E4ulbQ4BVaQTpmH6TTafwB3UaFJxafonkBJpU3nDYjU2uSpPoaNHC+QOfVRuYUbIPiX2/M3C9IRhRoHPiWCEPIxFqIS9R9pbYgQq+1s4/RZSHn4goO2S5A5EBIpAHXA0ufBuqY1M43725DzsVj18UmtE2Plhq/ALPY9sLu2qaNhlphkGpWjIE1Jjf0pRvayQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(136003)(346002)(39860400002)(376002)(6486002)(2616005)(186003)(166002)(30864003)(8936002)(6506007)(5660300002)(8676002)(83380400001)(99936003)(53546011)(66556008)(18074004)(31686004)(86362001)(110136005)(478600001)(66446008)(64756008)(76116006)(2906002)(36756003)(15650500001)(31696002)(66476007)(71200400001)(316002)(966005)(66946007)(6512007)(66616009)(43740500002)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: U2w0XwmmNTulE2poy6BanD3JssEc9SYldniRrry5xl5UROUU04s3yW/08euBCm4R05vnNRhtynub/GwZrYszBtdj+sJ4Ey5ib7KJ6h10zOLPuDXZ4PZiMsO0sd+HS7FF5KbrvrUQDtqKEpGjzektjxdzSmSrWKHr2aySvIOJUlpf6B6d/pWe7hNxizDr5CXlsOH3AoT3JkxQXlT2q9gLAoye8dWE7Fytl8CWOcKWfeICfq5VmvW9rXamW9ijdEbgZCP/RQliTPJhSa9nL4QACRdxUnZPr4TnRnIzo78+gkdiwAZ6fKPbei64vc2SNkPTI3xDCSbBNEJe1pWhAJk124eyS8dRsSMoKOj1MhuHU30J4oYEaxh8E9B3YaXnZQy76iy+YahqesZeXdY7V6sEMLEJMp4LR5D1rqwsw91h552BlarxFQ+97x8QHXNntVxSJOLokpZOfJPgiFpj66bW3N+nZxrASK5Z9H1Y/jpnh/3Aw4DG/Ipdo4hKL3ufxTV7khPEIjz8eyT0Z4nDYNuy+E3ZWvw9W95WxvgWhziluhuYMhOkxgMUixGBcRv5kK0H Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090002050804050907000100" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 840ebd94-4843-4fb5-aa10-08d811df8f26 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2020 10:25:14.8061 (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: 46To/Ub3afW5Oa4CuDYmMtaoqqWrSHjs0UUtaytUN8AZaewsXnePuAN8aDqGnzjX+j24ZBoF3POeE8dzT5JYf68gk3B6dyJtZvFC40tZRS4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3195 Archived-At: Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 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, 16 Jun 2020 10:25:23 -0000 --------------ms090002050804050907000100 Content-Type: multipart/alternative; boundary="------------067F9FC09A7D12F5169BD387" Content-Language: en-US This is a multi-part message in MIME format. --------------067F9FC09A7D12F5169BD387 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: base64 SGkgSGFubmVzLAoKT24gNi8xNi8yMCAxMjozNyBQTSwgSGFubmVzIFRzY2hvZmVuaWcgd3Jv dGU6Cj4KPiBIaSBNb2hpdCwKPgo+IEkgaGFkIGEgY2hhbmNlIHRvIHJlYWQgdGhyb3VnaCB0 aGUgZW1haWxzIHlvdSBwcm92aWRlZC4gQSBnb29kIAo+IGRpc2N1c3Npb24uCj4KPiBJIGNh biBvZmZlciB0aHJlZSBzb2x1dGlvbnM6Cj4KPiAgMS4gVXNlIEVBUC1TdWNjZXNzIC8gRUFQ LUZhaWx1cmUgYXMgYW4gaW5kaWNhdGlvbiBmb3IgdGhlIGNvbXBsZXRpb24KPiAgICAgb2Yg dGhlIGV4Y2hhbmdlLCBldmVuIGlmIGl0IGlzIG5vdCBhIHJlbGlhYmxlIG5vdGlmaWNhdGlv bgo+ICAgICBtZWNoYW5pc20uIElmIHRoZSBFQVAgcGVlciBkb2VzIG5vdCByZWNlaXZlIHRo ZSBOZXdTZXNzaW9uVGlja2V0Cj4gICAgIG1lc3NhZ2UgdGhlbiBpdCBkb2VzIG5vdCBtYXR0 ZXIgYmVjYXVzZSBpdCBpcyBvcHRpb25hbCB0byB1c2UKPiAgICAgYW55d2F5LiBJdCB3aWxs IGJlIGEgZmFpbHVyZSBjYXNlIGFueXdheSBpZiB0aGUgRUFQLVN1Y2Nlc3MgLwo+ICAgICBF QVAtRmFpbHVyZSBnb3QgbG9zdC4gVGhleSBFQVAgcGVlciBtYXkgbm90IGV2ZW4ga25vdyB3 aGV0aGVyIHRoZQo+ICAgICBleGNoYW5nZSB3YXMgc3VjY2Vzc2Z1bCBkZXNwaXRlIGNvcnJl Y3RseSBwcm9jZXNzaW5nIFRMUyBoYW5kc2hha2UKPiAgICAgbWVzc2FnZXMuCj4KSSBhbSB1 bmNvbWZvcnRhYmxlIGRvaW5nIHRoaXMgd2l0aG91dCB1cGRhdGluZyBSRkMgMzc0OC4gTm90 IG9ubHkgd2lsbCAKd2UgYmUgdmlvbGF0aW5nIFJGQyAzNzQ4LCB3ZSB3b3VsZCBzdGlsbCBo YXZlIHRoZSBwcm9ibGVtIG9mIHBlZXIgCnVuY2VydGFpbnR5IGFib3V0IHRoZSBuZXh0IG1l c3NhZ2UuIEl0IGNvdWxkIGJlIGEgTmV3U2Vzc2lvblRpY2tldCBvciAKRUFQLVN1Y2Nlc3Mv RmFpbHVyZS4KPgo+ICAyLiBEZW1hbmQgdGhhdCB0aGUgTmV3U2Vzc2lvblRpY2tldCBpcyBz ZW50IGltbWVkaWF0ZWx5IGFmdGVyIHRoZQo+ICAgICBGaW5pc2hlZCwgdmVyeSBtdWNoIGxp a2UgeW91IGN1cnJlbnRseSBkZW1hbmQgdGhhdCB0aGUgQ29tbWl0bWVudAo+ICAgICBNZXNz YWdlIGlzIGF0dGFjaGVkIHRvIHRoZSBsYXN0IG1lc3NhZ2UuCj4KSSBhc3N1bWUgdGhhdCB5 b3UgaW1wbHkgaW1tZWRpYXRlbHkgYWZ0ZXIgdGhlIHNlcnZlciBoYXMgc2VudCBpdHMgVExT IApGaW5pc2hlZCAoYW5kIG5vdCBhZnRlciB0aGUgc2VydmVyIGhhcyByZWNlaXZlZCB0aGUg VExTIEZpbmlzaGVkIGZyb20gCnRoZSBwZWVyKT8gQXJlIHlvdSBhbHNvIGltcGx5aW5nIHRo YXQgYSBOZXdTZXNzaW9uVGlja2V0IHNob3VsZCBhbHdheXMgCmJlIHNlbnQgb3V0LCByZWdh cmRsZXNzIG9mIHdoZXRoZXIgYSBzZXJ2ZXIgd2FudHMgb3Igc3VwcG9ydHMgCnJlc3VtcHRp b24/IFdoYXQgaWYgdGhlIHNlcnZlciBpcyBpc3N1aW5nIHNldmVyYWwgdGlja2V0cz8KPgo+ ICAzLiBVc2UgdGhlIENvbW1pdG1lbnQgTWVzc2FnZSBhcyBhbiBhcHBsaWNhdGlvbiBsYXll ciBwYXlsb2FkCj4gICAgIChlbmNyeXB0ZWQgYXMgaXQgc2hvdWxkIGJlKS4gKE5vdGUgdGhh dCB0aGlzIGhhcyBub3RoaW5nIHRvIGRvCj4gICAgIHdpdGggZWFybHkgZGF0YS4pIElmIHRo ZSBPcGVuU1NMIHNwZWMgZG9lcyBub3Qgc3VwcG9ydCBhbgo+ICAgICBhcHBsaWNhdGlvbiBs YXllciBtZXNzYWdlIGZyb20gdGhlIHNlcnZlciByaWdodCBhZnRlciB0aGUgZmluaXNoCj4g ICAgIHRoZW4gaXQgaXMgbm90IGNvbXBsaWFudCB0byB0aGUgVExTIDEuMyBSRkMuCj4KSG93 IHdvdWxkIHRoYXQgd29yaz8gSG93IGNhbiBzZXJ2ZXIgc2VuZCBlbmNyeXB0ZWQgYXBwbGlj YXRpb24gbGF5ZXIgCnBheWxvYWQgd2l0aG91dCBoYXZpbmcgcmVjZWl2ZWQgdGhlIFRMUyBG aW5pc2hlZCBmcm9tIHRoZSBwZWVyLgoKV2hpbGUgSSBhbSBvcGVuIHRvIGRpc2N1c3Npbmcg YmV0dGVyIGFsdGVybmF0aXZlcywgSSB0aGluayBmcm9tIGFuIAppbXBsZW1lbnRhdGlvbiBw ZXJzcGVjdGl2ZSwgaXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSBhIGRlZmluaXRlIApub3RpZmlj YXRpb24gbWVjaGFuaXNtIGZvciB0aGUgc2VydmVyIHRvIG5vdGlmeSB0aGUgcGVlciB0aGF0 IG5vIG1vcmUgCnBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzIGFyZSB0byBiZSBleHBlY3RlZC4K Ci0tTW9oaXQKCj4gVGhlIGN1cnJlbnQgc29sdXRpb24gaW4gdGhlIGRyYWZ0LCBmb3IgZXhh bXBsZSwgZG9lcyBub3Qgd29yayB3aXRoIAo+IE1iZWQgVExTIGJlY2F1c2UgeW91IGNhbm5v dCB0ZWxsIHRoZSBzdGFjayB0byBzdWRkZW5seSBieXBhc3MgdGhlIAo+IGVuY3J5cHRpb24g bGF5ZXIgKGFmdGVyIHN1Y2Nlc3NmdWxseSBlc3RhYmxpc2hpbmcgaXQpIHRvIHNlbmQgYSAK PiBwbGFpbnRleHQgbWVzc2FnZS4KPgo+IENpYW8KPgo+IEhhbm5lcwo+Cj4gKkZyb206KiBN b2hpdCBTZXRoaSBNIDxtb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbT4KPiAqU2VudDoqIE1v bmRheSwgSnVuZSAxNSwgMjAyMCAzOjUyIFBNCj4gKlRvOiogSGFubmVzIFRzY2hvZmVuaWcg PEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+OyBlbXVAaWV0Zi5vcmcKPiAqU3ViamVjdDoq IFJlOiBbRW11XSBDb21taXRtZW50IE1lc3NhZ2UgaW4gZHJhZnQtaWV0Zi1lbXUtZWFwLXRs czEzCj4KPiBIaSBIYW5uZXMsCj4KPiBVbmZvcnR1bmF0ZWx5IHlvdSBhcmUgd3JvbmcgaGVy ZS4gVGhlIGRlc2lnbiBkZWNpc2lvbiB3YXMgaW4gZmFjdCAKPiB0YWtlbiB0byBhdm9pZCBj aGFuZ2VzIHRvIHRoZSB1bmRlcmx5aW5nIFRMUyBpbXBsZW1lbnRhdGlvbiB3aGlsZSBhbHNv IAo+IGF2b2lkaW5nIGNoYW5nZXMgdG8gUkZDIDM3NDguIFRvIHN1bW1hcml6ZToKPgo+IEpv dW5pIE1hbGluZW4gcG9pbnRlZCBvdXQgdGhhdCBtYXBwaW5nIHNlc3Npb24gcmVzdW1wdGlv biBvZiBUTFMgMS4zIAo+IHRvIEVBUC1UTFMgaXMgbm9uLXRyaXZpYWwuIFNlZSBoaXMgZW1h aWwgaGVyZTogCj4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUv U0JkYmxIbUxRVGJCd29aSEs4UmloLWc1bmU4Ly4gCj4gRXNzZW50aWFsbHksIFRMUyAxLjMg YWxsb3dzIGEgc2VydmVyIHRvIHNlbmQgYSBQb3N0LUhhbmRzaGFrZSBtZXNzYWdlIAo+IHdp dGggYSBOZXdTZXNzaW9uVGlja2V0IGF0IGFueSB0aW1lLiBIb3dldmVyLCBpbiBFQVAtVExT IHRoaXMgaXMgbm90IAo+IHBvc3NpYmxlLiBUaGUgVExTIHR1bm5lbCBpcyB0b3JuIGRvd24g YWZ0ZXIgYXV0aGVudGljYXRpb24uIEpvaG4gbm90ZXMgCj4gaW4gaGlzIHJlc3BvbnNlIHRv IEpvdW5pIAo+IChodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2VtdS9u TlV3NjFjVHZIZ1dqOEYwc09WUm9JQ1V6bGsvKSAKPiAiaW4gVExTIHRoZSBjb25uZWN0aW9u IGlzIGFzc3VtZWQgdG8gc3RheSBvcGVuIGZvciBhIGxvbmcgdGltZSBhZnRlciAKPiB0aGUg Y2xpZW50IHNlbmRzIEZpbmlzaGVkLCBpbiBFQVAgdGhlIGNvbm5lY3Rpb24gaXMgYXNzdW1l ZCB0byBiZSAKPiBjbG9zZWQgc2hvcnRseSBhZnRlci4iCj4KPiBBbiBlYXJsaWVyIGNsZWFu ZXIgd2F5IG9mIHNlbmRpbmcgTmV3U2Vzc2lvblRpY2tldCByZXF1aXJlZCBhbiBleHRyYSAK PiByb3VuZCB0cmlwIGFuZCBsZWZ0IHRoZSBwZWVyIHVuY2VydGFpbiBhYm91dCB0aGUgbmV4 dCBtZXNzYWdlIAo+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1l bXUtZWFwLXRsczEzLTAwI3NlY3Rpb24tMi4xLjEpLiAKPiBKb3VuaSBoaWdobGlnaHRlZCB0 aGlzIHVuY2VydGFpbnR5IGZvciBhIHBlZXI6ICIgdGhlIHBlZXIgaGFzIG5vIGlkZWEgCj4g d2hldGhlciB0aGUgTmV3U2Vzc2lvblRpY2tldCBpcyBkZWxpdmVyZWQgYWZ0ZXIgQ2xpZW50 RmluaXNoZWQuIEluIAo+IG90aGVyIHdvcmRzLCB0aGUgbmV4dCBtZXNzYWdlIGluIHRoZSBz ZXF1ZW5jZSBjb3VsZCBiZSBlaXRoZXIgCj4gY29udGludWF0aW9uIG9mIEVBUC1UTFMgbWV0 aG9kIG9yIEVBUC1TdWNjZXNzIi4gWW91IGFzayAid2h5IGNhbm5vdCAKPiB0aGUgRUFQLVN1 Y2Nlc3Mgb3IgRUFQLUZhaWx1cmUgc2VydmUgdGhhdCBwdXJwb3NlPyIuIFNlZSBSRkMgMzc0 OCAKPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM3NDgpIHdoaWNoIHNheXMg dGhlIGZvbGxvd2luZzoKPgo+ICAgICAgoKAgSW1wbGVtZW50YXRpb24gTm90ZTogQmVjYXVz ZSB0aGUgU3VjY2VzcyBhbmQgRmFpbHVyZSBwYWNrZXRzIGFyZSBub3QKPgo+ICAgICAgoKAg YWNrbm93bGVkZ2VkLCB0aGV5IGFyZSBub3QgcmV0cmFuc21pdHRlZCBieSB0aGUgYXV0aGVu dGljYXRvciwgYW5kCj4KPiAgICAgIKCgIG1heSBiZSBwb3RlbnRpYWxseSBsb3N0LqAgQSBw ZWVyIE1VU1QgYWxsb3cgZm9yIHRoaXMgY2lyY3Vtc3RhbmNlIGFzCj4KPiAgICAgIKCgIGRl c2NyaWJlZCBpbiB0aGlzIG5vdGUuCj4KPiBhbmQKPgo+ICAgICAgoE9uIHRoZSBwZWVyLCBh ZnRlciBzdWNjZXNzIHJlc3VsdCBpbmRpY2F0aW9ucyBoYXZlIGJlZW4gZXhjaGFuZ2VkIGJ5 Cj4KPiAgICAgIKCgIGJvdGggc2lkZXMsIGEgRmFpbHVyZSBwYWNrZXQgTVVTVCBiZSBzaWxl bnRseSBkaXNjYXJkZWQuoCBUaGUgcGVlcgo+Cj4gICAgICCgoCBNQVksIGluIHRoZSBldmVu dCB0aGF0IGFuIEVBUCBTdWNjZXNzIGlzIG5vdCByZWNlaXZlZCwgY29uY2x1ZGUgdGhhdAo+ Cj4gICAgICCgoCB0aGUgRUFQIFN1Y2Nlc3MgcGFja2V0IHdhcyBsb3N0IGFuZCB0aGF0IGF1 dGhlbnRpY2F0aW9uIGNvbmNsdWRlZAo+Cj4gICAgICCgoCBzdWNjZXNzZnVsbHkuCj4KPgo+ IFRodXMsIEVBUC1TdWNjZXNzIGNhbm5vdCBiZSB1c2VkIGFzIGEgcmVsaWFibGUgbm90aWZp Y2F0aW9uIG1lY2hhbmlzbS4gCj4gVGlsbCB2ZXJzaW9uIDA1IG9mIHRoZSBkb2N1bWVudCwg d2UgdXNlZCBhbiBlbXB0eSBhcHBsaWNhdGlvbiBkYXRhIAo+IHJlY29yZCBhcyBhIG5vdGlm aWNhdGlvbiBvZiB0aGUgbGFzdCBoYW5kc2hha2UgbWVzc2FnZS4gVGhlIHRleHQgc2FpZDoK Pgo+ICAgICBXaGVuIGFuIEVBUCBzZXJ2ZXIgaGFzIHNlbnQgaXRzIGxhc3QgaGFuZHNoYWtl IG1lc3NhZ2UgKEZpbmlzaGVkIG9yIGEKPgo+ICAgICAgoKAgUG9zdC1IYW5kc2hha2UpLCBp dCBjb21taXRzIHRvIG5vdCBzZW5kaW5nIGFueSBtb3JlIGhhbmRzaGFrZQo+Cj4gICAgICCg oCBtZXNzYWdlcyBieSBhcHBlbmRpbmcgYW4gZW1wdHkgYXBwbGljYXRpb24gZGF0YSByZWNv cmQgKGkuLmUuIGEgVExTCj4KPiAgICAgIKCgIHJlY29yZCB3aXRoIFRMU1BsYWludGV4dC50 eXBlID0gYXBwbGljYXRpb25fZGF0YSBhbmQKPgo+ICAgICAgoKAgVExTUGxhaW50ZXh0Lmxl bmd0aCA9IDApIHRvIHRoZSBsYXN0IGhhbmRzaGFrZSByZWNvcmQuoCBBZnRlciBzZW5kaW5n Cj4KPiAgICAgIKCgIGFuIGVtcHR5IGFwcGxpY2F0aW9uIGRhdGEgcmVjb3JkLCB0aGUgRUFQ IHNlcnZlciBtYXkgb25seSBzZW5kIGFuCj4KPiAgICAgIKCgIEVBUC1TdWNjZXNzLCBhbiBF QVAtRmFpbHVyZSwgb3IgYW4gRUFQLVJlcXVlc3Qgd2l0aCBhIFRMUyBBbGVydAo+Cj4gICAg ICCgoCBNZXNzYWdlLgo+Cj4gSG93ZXZlciwgSm91bmkgaW4gYSBsYXRlciByZXNwb25zZSAK PiAoaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lbXUvV0E4T1JFaFRz RjhKRVB2YWl4R29Dd21kMXFZLykgCj4gbm90ZWQgdGhhdCBzdWNoIGJlaGF2aW9yIGlzIG5v bi10cml2aWFsIHRvIGFjaGlldmUgd2l0aCBPcGVuU1NMLiBIZSAKPiBub3RlcyAiIE9wZW5T U0wgaXMgbm90IHdpbGxpbmcgdG8gc2VuZCBzdWNoIGFuIGVtcHR5IFRMU1BsYWludGV4dCAK PiBzdHJ1Y3R1cmUuIFNTTF93cml0ZSgpIGhhcyBmb2xsb3dpbmcgdG8gc2F5IDogJ1lvdSBz aG91bGQgbm90IGNhbGwgCj4gU1NMX3dyaXRlKCkgd2l0aCBudW09MCwgaXQgd2lsbCByZXR1 cm4gYW4gZXJyb3IuIFNTTF93cml0ZV9leCgpIGNhbiBiZSAKPiBjYWxsZWQgd2l0aCBudW09 MCwgYnV0IHdpbGwgbm90IHNlbmQgYXBwbGljYXRpb24gZGF0YSB0byB0aGUgcGVlci4nIgo+ Cj4gVGhlcmVmb3JlLCB0aGUgdGV4dCB3YXMgbGF0ZXIgdXBkYXRlZCB0bzoKPgo+ICAgICAg IFdoZW4gYW4gRUFQIHNlcnZlciBoYXMgc2VudCBpdHMgbGFzdCBoYW5kc2hha2UgbWVzc2Fn ZSAoRmluaXNoZWQgb3IgYQo+Cj4gICAgICCgoCBQb3N0LUhhbmRzaGFrZSksIGl0IGNvbW1p dHMgdG8gbm90IHNlbmRpbmcgYW55IG1vcmUgaGFuZHNoYWtlCj4KPiAgICAgIKCgIG1lc3Nh Z2VzIGJ5IHNlbmRpbmcgYSBDb21taXRtZW50IE1lc3NhZ2UuoCBUaGUgQ29tbWl0bWVudCBN ZXNzYWdlIGlzCj4KPiAgICAgIKCgIGEgVExTIHJlY29yZCB3aXRoIGFwcGxpY2F0aW9uIGRh dGEgMHgwMCAoaS5lLiBhIFRMUyByZWNvcmQgd2l0aAo+Cj4gICAgICCgoCBUTFNQbGFpbnRl eHQudHlwZSA9IGFwcGxpY2F0aW9uX2RhdGEsIFRMU1BsYWludGV4dC5sZW5ndGggPSAxLCBh bmQKPgo+ICAgICAgoKAgVExTUGxhaW50ZXh0LmZyYWdtZW50ID0gMHgwMCkuoCBOb3RlIHRo YXQgdGhlIGxlbmd0aCBvZiB0aGUgcGxhaW50ZXh0Cj4KPiAgICAgIKCgIGlzIGdyZWF0ZXIg dGhhbiB0aGUgY29ycmVzcG9uZGluZyBUTFNQbGFpbnRleHQubGVuZ3RoIGR1ZSB0byB0aGUK Pgo+ICAgICAgoKAgaW5jbHVzaW9uIG9mIFRMU0lubmVyUGxhaW50ZXh0LnR5cGUgYW5kIGFu eSBwYWRkaW5nIHN1cHBsaWVkIGJ5IHRoZQo+Cj4gICAgICCgoCBzZW5kZXIuoCBFQVAgc2Vy dmVyIGltcGxlbWVudGF0aW9ucyBNVVNUIHNldCBUTFNQbGFpbnRleHQuZnJhZ21lbnQgdG8K Pgo+ICAgICAgoKAgMHgwMCwgYnV0IEVBUCBwZWVyIGltcGxlbWVudGF0aW9ucyBNVVNUIGFj Y2VwdCBhbnkgYXBwbGljYXRpb24gZGF0YQo+Cj4gICAgICCgoCBhcyBhIENvbW1pdG1lbnQg TWVzc2FnZSBmcm9tIHRoZSBFQVAgc2VydmVyIHRvIG5vdCBzZW5kIGFueSBtb3JlIGhhbmRz aGFrZSBtZXNzYWdlcy4KPgo+IFRoZXJlIGlzIHN0aWxsIGEgY2hhbGxlbmdlIGluIHNjZW5h cmlvcyB3aGVyZSBhIHNlcnZlciBjaG9vc2VzIG5vdCB0byAKPiBpc3N1ZSBhbnkgTmV3U2Vz c2lvblRpY2tldC4gSW4gdGhpcyBlbWFpbDogCj4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9lbXUvUGdHamhtYWZiYlNKQ2NRY3REc0Z3N0F2Tm1VLyAKPiBKb3Vu aSBub3RlcyB0aGlzIHByb2JsZW06Cj4KPiAgICAgSSBkaWQgc2VlIHNvbWUgaXNzdWVzIHdo ZW4gT3BlblNTTCAxLjEuMSB3aGVuIGRpc2FibGluZyBzZW5kaW5nIG9mCj4KPiAgICAgc2Vz c2lvbiB0aWNrZXRzLCB0aG91Z2guIFRoZSBjdXJyZW50IGRyYWZ0IGluZGljYXRlcyB0aGF0 IHRoZSBlbXB0eQo+Cj4gICAgIEFwcGxpY2F0aW9uIERhdGEgcGF5bG9hZCB3b3VsZCBiZSBz ZW5kIG91dCBpbiB0aGUgc2FtZSBFQVAgcGFja2V0IHdpdGgKPgo+ICAgICB0aGUgc2VydmVy J3MgRmluaXNoZWQgbWVzc2FnZSwgaS5lLiwgYmVmb3JlIHRoZSBzZXJ2ZXIgaGF2aW5nCj4K PiAgICAgYXV0aGVudGljYXRlZCB0aGUgcGVlci4gQW5kIHRoaXMgd291bGQgYmUgZG9uZSB3 aXRob3V0IHRoZSBwZWVyIGhhdmluZwo+Cj4gICAgIHVzZWQgVExTIGVhcmx5IGRhdGEgKHdo aWNoIGlzIGV4cGxpY2l0bHkgZGlzYWxsb3dlZCBpbiB0aGUgZHJhZnQpLiBUaGF0Cj4KPiAg ICAgY29tYmluYXRpb24gZGlkIG5vdCB3b3JrIHdpdGggbXkgZXhwZXJpbWVudHMgc2luY2Ug T3BlblNTTCB3YXMgcmVqZWN0aW5nCj4KPiAgICAgdGhlIFNTTF93cml0ZSgpIG9wZXJhdGlv biBhZnRlciB0aGUgc2VydmVyIGhhdmluZyB3cml0dGVuIG93biBGaW5pc2hlZAo+Cj4gICAg IG1lc3NhZ2UsIGJ1dCBiZWZvcmUgaGF2aW5nIHJlY2VpdmVkIHRoZSBGaW5pc2hlZCBtZXNz YWdlIGZyb20gdGhlIHBlZXIuLgo+Cj4gICAgIFRoZSBPcGVuU1NMIGRvY3VtZW50YXRpb24g c2VlbWVkIHRvIGltcGx5IHRoYXQgU1NMX3dyaXRlX2Vhcmx5X2RhdGEoKQo+Cj4gICAgIGNv dWxkIGJlIHVzZWQgYnkgdGhlIHNlcnZlciBfaWZfIHRoZSBjbGllbnQgZmlyc3Qgc2VudCBl YXJseSBkYXRhLi4gQXQKPgo+ICAgICBsZWFzdCBpbiBteSB0ZXN0cywgT3BlblNTTCByZWpl Y3RlZCB0aGF0IGNhbGwgd2l0aG91dCBlYXJseSBkYXRhIGZyb20KPgo+ICAgICB0aGUgY2xp ZW50Lgo+Cj4gVGhpcyBpcyB3aHkgdGhlIGN1cnJlbnQgdGV4dCBhbHNvIHNheXMgdGhlIGZv bGxvd2luZzoKPgo+ICAgICAgIFRoZSBDb21taXRtZW50IE1lc3NhZ2UgbWF5IGJlIHNlbnQg aW4gdGhlIHNhbWUKPgo+ICAgICAgoKAgRUFQLVJlcXVlc3QgYXMgdGhlIGxhc3QgaGFuZHNo YWtlIHJlY29yZCBvciBpbiBhIHNlcGFyYXRlIEVBUC0KPgo+ICAgICAgoKAgUmVxdWVzdC6g IFNlbmRpbmcgdGhlIENvbW1pdG1lbnQgTWVzc2FnZSBpbiBhIHNlcGFyYXRlIEVBUC1SZXF1 ZXN0Cj4KPiAgICAgIKCgIGFkZHMgYW4gYWRkaXRpb25hbCByb3VuZC10cmlwLCBidXQgbWF5 IGJlIG5lY2Vzc2FyeSBpbiBUTFMKPgo+ICAgICAgoKAgaW1wbGVtZW50YXRpb25zIHRoYXQg b25seSBpbXBsZW1lbnQgYSBzdWJzZXQgb2YgVExTIDEuMy6gIEluIHRoZSBjYXNlCj4KPiAg ICAgIKCgIHdoZXJlIHRoZSBzZXJ2ZXIgc2VuZHMgdGhlIENvbW1pdG1lbnQgTWVzc2FnZSBp biBhIHNlcGFyYXRlIEVBUC0KPgo+ICAgICAgoKAgUmVxdWVzdCwgdGhlIGNvbnZlcnNhdGlv biB3aWxsIGFwcGVhciBhcyBzaG93biBpbiBGaWd1cmUgOS6gIEFmdGVyCj4KPiAgICAgIKCg IHNlbmRpbmcgdGhlIENvbW1pdG1lbnQgTWVzc2FnZSwgdGhlIEVBUCBzZXJ2ZXIgbWF5IG9u bHkgc2VuZCBhbiBFQVAtCj4KPiAgICAgIKCgIFN1Y2Nlc3MsIGFuIEVBUC1GYWlsdXJlLCBv ciBhbiBFQVAtUmVxdWVzdCB3aXRoIGEgVExTIEFsZXJ0IE1lc3NhZ2UuCj4KPiBUaHVzLCB0 aGUgY3VycmVudCBkZXNpZ24gZGVjaXNpb24gaGFzIGJlZW4gZ3VpZGVkIGJ5IHBhcmFsbGVs IAo+IGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2UgYW5kIGl0IGlzIHRoZSBiZXN0IHNvbHV0 aW9uIHdlIGNvdWxkIGNvbWUgdXAgCj4gd2l0aCAoZ2l2ZW4gYWxsIHRoZSBwcmFjdGljYWwg bGltaXRhdGlvbnMpLgo+Cj4gLS1Nb2hpdAo+Cj4gT24gNi8xMi8yMCAxMTozNiBBTSwgSGFu bmVzIFRzY2hvZmVuaWcgd3JvdGU6Cj4KPiAgICAgSGkgYWxsLAo+Cj4gICAgIFRoaXMgaGFz IHByb2JhYmx5IGJlZW4gZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5IGluIHRoZSBFTVUgZ3JvdXAu IEkKPiAgICAgYW0gc29ycnkgdG8gYnJpbmcgaXQgdXAgYWdhaW4gYnV0IEkgYmVsaWV2ZSB0 aGlzIGlzIGEgYmFkIGRlc2lnbgo+ICAgICBkZWNpc2lvbi4gSSByYWlzZWQgaXQgaW4gbXkg c2hvcnQgcmV2aWV3IGp1c3Qgc2VudCB0byB0aGUgbGlzdCBidXQKPiAgICAgSSBiZWxpZXZl IGl0IGlzIHdvcnRod2hpbGUgdG8gcG9pbnQgaXQgb3V0IHNlcGFyYXRlbHkuCj4KPiAgICAg ZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzIGludHJvZHVjZXMgYSBuZXcgbWVzc2FnZSB0byBF QVAtVExTLAo+ICAgICBuYW1lbHkgdGhlIENvbW1pdG1lbnQgTWVzc2FnZS4gVGhpcyByZXF1 aXJlcyBleHRyYSBjb2RlIGluIGFuCj4gICAgIGltcGxlbWVudGF0aW9uIGJlY2F1c2UgdGhl IG5vcm1hbCBiZWhhdmlvciB3b3VsZCBiZSB0byBydW4gYSBUTFMKPiAgICAgc3RhY2sgYW5k IHRoZW4gc2VuZCBlbmNyeXB0ZWQgZGF0YS4KPgo+ICAgICBFQVAtVExTIGRvZXMsIGhvd2V2 ZXIsIG5vdCBzZW5kIGFwcGxpY2F0aW9uIGRhdGEqLiBUaGlzIG1lc3NhZ2UKPiAgICAgY2hh bmdlcyB0aGlzLiBOb3Qgb25seSBkb2VzIGl0IG5vdCBzZW5kIGVuY3J5cHRlZCBhcHBsaWNh dGlvbiBkYXRhCj4gICAgIGl0IHJlcXVpcmVzIGFuIGltcGxlbWVudGF0aW9uIHRvIHRyYW5z bWl0IGEgcGxhaW50ZXh0IGFwcGxpY2F0aW9uCj4gICAgIGRhdGEgcmVjb3JkIGFmdGVyIHRo ZSBhcHBsaWNhdGlvbiB0cmFmZmljIHNlY3JldCBoYXMgYmVlbiBjcmVhdGVkCj4gICAgIGFu ZCBiZWZvcmUgdGhhdCBhcHBsaWNhdGlvbiB0cmFmZmljIHNlY3JldCBpcyB1c2VkIHRvIHBy b3RlY3QgcG9zdAo+ICAgICBoYW5kc2hha2UgbWVzc2FnZXMuIFRoaXMgd2lsbCBtYWtlIGl0 IGRpZmZpY3VsdCB0byByZS11c2UgYW4KPiAgICAgb2ZmLXRoZS1zaGVsZiBUTFMgMS4zIHN0 YWNrLgo+Cj4gICAgIFRoZXJlIGlzIHZlcnkgbGl0dGxlIG1vdGl2YXRpb24gYWJvdXQgdGhp cyBtZXNzYWdlIG90aGVyIHRoYW4KPgo+ICAgICAgIAo+Cj4gICAgIJMKPgo+ICAgICCgoCBX aGVuIGFuIEVBUCBzZXJ2ZXIgaGFzIHNlbnQgaXRzIGxhc3QgaGFuZHNoYWtlIG1lc3NhZ2UK PiAgICAgKEZpbmlzaGVkIG9yIGEKPgo+ICAgICCgoCBQb3N0LUhhbmRzaGFrZSksIGl0IGNv bW1pdHMgdG8gbm90IHNlbmRpbmcgYW55IG1vcmUgaGFuZHNoYWtlCj4KPiAgICAgoKAgbWVz c2FnZXMgYnkgc2VuZGluZyBhIENvbW1pdG1lbnQgTWVzc2FnZS4KPgo+ICAgICCTCj4KPiAg ICAgSSBtaWdodCBtaXNzIHNvbWV0aGluZyBpbXBvcnRhbnQgaGVyZSBidXQgd2h5IGNhbm5v dCB0aGUKPiAgICAgRUFQLVN1Y2Nlc3Mgb3IgRUFQLUZhaWx1cmUgc2VydmUgdGhhdCBwdXJw b3NlPwo+Cj4gICAgIEhlcmUgYXJlIHR3byBleGFtcGxlcyB0byBleHBsYWluIHdoYXQgSSBt ZWFuOgo+Cj4gICAgICAxLiBGYWlsZWQgZXhjaGFuZ2UKPgo+ICAgICCgoKAgRUFQIFBlZXKg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgRUFQIFNlcnZl cgo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgIEVBUC1SZXF1ZXN0Lwo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgIDwtLS0tLS0tLaCgoKCgoKCgoKCgoKCgoKCgIElkZW50aXR5Cj4KPiAg ICAgoKCgIEVBUC1SZXNwb25zZS8KPgo+ICAgICCgoKAgSWRlbnRpdHkgKFByaXZhY3ktRnJp ZW5kbHkpoCAtLS0tLS0tLT4KPgo+ICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBFQVAtUmVxdWVzdC8KPgo+ICAgICCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgRUFQLVR5 cGU9RUFQLVRMUwo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDwt LS0tLS0tLaCgoKCgoKCgoKCgoKCgoCAoVExTIFN0YXJ0KQo+Cj4gICAgIKCgoCBFQVAtUmVz cG9uc2UvCj4KPiAgICAgoKCgIEVBUC1UeXBlPUVBUC1UTFMKPgo+ICAgICCgoCAoVExTIENs aWVudEhlbGxvKaCgoKCgoKCgoKCgoCAtLS0tLS0tLT4KPgo+ICAgICCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBFQVAtUmVxdWVz dC8KPgo+ICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgIKCgoKCgoKCgoKAoVExTIFNlcnZlckhlbGxvLAo+Cj4g ICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIFRMUyBF bmNyeXB0ZWRFeHRlbnNpb25zLAo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoCBUTFMgQ2VydGlmaWNhdGVSZXF1ZXN0LAo+Cj4gICAgIKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgVExT IENlcnRpZmljYXRlLAo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgIKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgVExTIENlcnRpZmljYXRlVmVyaWZ5LAo+Cj4gICAgIKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgVExTIEZp bmlzaGVkLAo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDwtLS0t LS0tLSBDb21taXRtZW50IE1lc3NhZ2UpCj4KPiAgICAgoKCgIEVBUC1SZXNwb25zZS8KPgo+ ICAgICCgoKAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4gICAgIKCgIChUTFMgQ2VydGlmaWNhdGUs Cj4KPiAgICAgoKCgIFRMUyBDZXJ0aWZpY2F0ZVZlcmlmeSwKPgo+ICAgICCgoKAgVExTIEZp bmlzaGVkKaCgoKCgoKCgoKCgoKCgoCAtLS0tLS0tLT4KPgo+ICAgICCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBFQVAtUmVxdWVz dC8KPgo+ICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgIDwtLS0tLS0tLaCgoKCgoKAgoKAoVExTIEZhdGFsIEFsZXJ0KQo+Cj4g ICAgIKCgoCBFQVAtUmVzcG9uc2UvCj4KPiAgICAgoKCgIEVBUC1UeXBlPUVBUC1UTFOgoKCg oKCgoKCgoKAgLS0tLS0tLS0+Cj4KPiAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKAgPC0tLS0tLS0tIEVBUC1GYWlsdXJlCj4KPiAgICAgIDIuIFN1Y2Nlc3NmdWwgRXhj aGFuZ2Ugd2l0aCBQb3N0LUhhbmRzaGFrZSBOZXdTZXNzaW9uIFRpY2tldAo+Cj4gICAgIKCg oCBFQVAgUGVlcqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oCBFQVAgU2VydmVyCj4KPiAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgRUFQLVJlcXVlc3QvCj4KPiAgICAgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgPC0tLS0tLS0toKCgoKCgoKCgoKCgoKCgoKAgSWRl bnRpdHkKPgo+ICAgICCgoKAgRUFQLVJlc3BvbnNlLwo+Cj4gICAgIKCgoCBJZGVudGl0eSAo UHJpdmFjeS1GcmllbmRseSmgIC0tLS0tLS0tPgo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIEVBUC1SZXF1ZXN0Lwo+ Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoCBFQVAtVHlwZT1FQVAtVExTCj4KPiAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKAgPC0tLS0tLS0toKCgoKCgoKCgoKCgoKCgIChUTFMgU3RhcnQpCj4KPiAgICAg oKCgIEVBUC1SZXNwb25zZS8KPgo+ICAgICCgoKAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4gICAg IKCgIChUTFMgQ2xpZW50SGVsbG8poKCgoKCgoKCgoKCgIC0tLS0tLS0tPgo+Cj4gICAgIKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg IEVBUC1SZXF1ZXN0Lwo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoCBFQVAtVHlwZT1FQVAtVExTCj4KPiAgICAgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIKCgoKCgoKCgoChUTFMgU2VydmVy SGVsbG8sCj4KPiAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKAgVExTIEVuY3J5cHRlZEV4dGVuc2lvbnMsCj4KPiAgICAgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIFRMUyBDZXJ0aWZpY2F0ZVJlcXVlc3Qs Cj4KPiAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoCBUTFMgQ2VydGlmaWNhdGUsCj4KPiAgICAgoKCgoKCgoKCgoKCgoKCgoKCgIKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBUTFMgQ2VydGlmaWNhdGVWZXJpZnksCj4KPiAg ICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgPC0tLS0tLS0toKCgoKCgoKCg oKCgoCBUTFMgRmluaXNoZWQpCj4KPiAgICAgoKCgIEVBUC1SZXNwb25zZS8KPgo+ICAgICCg oKAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4gICAgIKCgIChUTFMgQ2VydGlmaWNhdGUsCj4KPiAg ICAgoKCgIFRMUyBDZXJ0aWZpY2F0ZVZlcmlmeSwKPgo+ICAgICCgoKAgVExTIEZpbmlzaGVk KaCgoKCgoKCgoKCgoKCgoCAtLS0tLS0tLT4KPgo+ICAgICCgoKCgIKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBFQVAtUmVxdWVzdC8KPgo+ ICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4gICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKAgKFRMUyBOZXdTZXNzaW9uVGlja2V0LAo+Cj4gICAgIKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDwtLS0tLS0tLSBDb21taXRtZW50IE1l c3NhZ2UpCj4KPiAgICAgoKCgIEVBUC1SZXNwb25zZS8KPgo+ICAgICCgoKAgRUFQLVR5cGU9 RUFQLVRMU6CgoKCgoKCgoKCgoCAtLS0tLS0tLT4KPgo+ICAgICCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoCA8LS0tLS0tLS0gRUFQLVN1Y2Nlc3MKPgo+ICAgICBDaWFvCj4K PiAgICAgSGFubmVzCj4KPiAgICAgKCopOiBGV0lXIFBvc3QgaGFuZHNoYWtlIG1lc3NhZ2Vz IGFyZSBwcm90ZWN0ZWQgd2l0aCB0aGUKPiAgICAgYXBwbGljYXRpb24gdHJhZmZpYyBzZWNy ZXRzLgo+Cj4gICAgIElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMKPiAgICAgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlCj4gICAgIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk bwo+ICAgICBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24s IHVzZSBpdCBmb3IgYW55Cj4gICAgIHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4KPgo+ICAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Cj4gICAgIEVtdSBtYWls aW5nIGxpc3QKPgo+ICAgICBFbXVAaWV0Zi5vcmcgIDxtYWlsdG86RW11QGlldGYub3JnPgo+ Cj4gICAgIGh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdSAgPGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW11Pgo+Cj4gSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgCj4gY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgCj4gcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSAKPiB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgCj4gY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Lgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K PiBFbXUgbWFpbGluZyBsaXN0Cj4gRW11QGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9lbXUK --------------067F9FC09A7D12F5169BD387 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Hannes,

On 6/16/20 12:37 PM, Hannes Tschofenig= wrote:

Hi Mohit,

=A0

I had a chance to read through the emails you provided. A good discussion.

=A0

I can offer three solutions:

=A0

  1. Use EAP-Success / EAP-Failure as an indication for the completion of the exchange, even if it is not a reliable notification mechanism. If the EAP peer does not receive the NewSessionTicket message then it does not matter because it is optional to use anyway. It will be a failure case anyway if the EAP-Success / EAP-Failure got lost. They EAP peer may not even know whether the exchange was successful despite correctly processing TLS handshake messages.
    2. =
I am uncomfortable doing this without updating RFC 3748. Not only will we be violating RFC 3748, we would still have the problem of peer uncertainty about the next message. It could be a NewSessionTicket or EAP-Success/Failure.

=A0

  1. Demand that= the NewSessionTicket is sent immediately after the Finished, very much like you currently demand that the Commitment Message is attached to the last message.

=A0

I assume that you imply immediately after the server has sent its TLS Finished (and not after the server has received the TLS Finished from the peer)? Are you also implying that a NewSessionTicket should always be sent out, regardless of whether a server wants or supports resumption? What if the server is issuing several tickets?
  1. Use the Commitment Message as an application layer payload (encrypted as it should be). (Note that this has nothing to do with early data.) If the OpenSSL spec does not support an application layer message from the server right after the finish then it is not compliant to the TLS 1.3 RFC.

=A0

How would that work? How can server send encrypted application layer payload without having received the TLS Finished from the peer.

While I am open to discussing better alternatives, I think from an implementation perspective, it makes sense to have a definite notification mechanism for the server to notify the peer that no more post-handshake messages are to be expected.

--Mohit

The current solution in the draft, for example, does not work with Mbed TLS because you cannot tell the stack to suddenly bypass the encryption layer (after successfully establishing it) to send a plaintext message.

=A0

Ciao

Hannes

=A0

From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

=A0

Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken to avoid changes to the underlying TLS implementation while also avoiding changes to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. Essentially, TLS 1.3 allows a server to send a Post-Handshake message with a NewSessionTicket at any time. However, in EAP-TLS this is not possible. The TLS tunnel is torn down after authentication. John notes in his response to Jouni (https://mailarchive.ietf.org/arch/ms= g/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS the connection is assumed to stay open for a long time after the client sends Finished, in EAP the connection is assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra round trip and left the peer uncertain about the next message (https://tools.ietf.org/html/draft-ie= tf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted this uncertainty for a peer: " the peer has no idea whether the NewSessionTicket is delivered after ClientFinished. In other words, the next message in the sequence could be either continuation of EAP-TLS method or EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". See RFC 3748 (https://tools.ietf.org/html/rfc3748<= /a>) which says the following:

=A0=A0 Implementation Note: Because the Success and Failur=
e packets are not
=A0=A0 acknowledged, they are not retransmitted by the aut=
henticator, and
=A0=A0 may be potentially lost.=A0 A peer MUST allow for t=
his circumstance as
=A0=A0 described in this note.=A0

and 

=A0On the peer, after success result indications have been=
 exchanged by
=A0=A0 both sides, a Failure packet MUST be silently disca=
rded.=A0 The peer
=A0=A0 MAY, in the event that an EAP Success is not receiv=
ed, conclude that
=A0=A0 the EAP Success packet was lost and that authentica=
tion concluded
=A0=A0 successfully.


Thus, EAP-Success cannot be used as a reliable notification mechanism. Till version 05 of the document, we used an empty application data record as a notification of the last handshake message. The text said: 

When an EAP server has sent its last handshake message (Fi=
nished or a
=A0=A0 Post-Handshake), it commits to not sending any more=
 handshake
=A0=A0 messages by appending an empty application data rec=
ord (i..e. a TLS
=A0=A0 record with TLSPlaintext.type =3D application_data =
and
=A0=A0 TLSPlaintext.length =3D 0) to the last handshake re=
cord.=A0 After sending
=A0=A0 an empty application data record, the EAP server ma=
y only send an
=A0=A0 EAP-Success, an EAP-Failure, or an EAP-Request with=
 a TLS Alert
=A0=A0 Message.

However, Jouni in a later response (https://mailarchive.ietf.org/arch/ms= g/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted that such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL is not willing to send such an empty TLSPlaintext structure. SSL_write() has following to say : 'You should not call SSL_write() with num=3D0, it will return= an error. SSL_write_ex() can be called with num=3D0, but will not send application data to the peer.'"

Therefore, the text was later updated to:

 When an EAP server has sent its last handsha=
ke message (Finished or a
=A0=A0 Post-Handshake), it commits to not sending any more=
 handshake
=A0=A0 messages by sending a Commitment Message.=A0 The Co=
mmitment Message is
=A0=A0 a TLS record with application data 0x00 (i.e. a TLS=
 record with
=A0=A0 TLSPlaintext.type =3D application_data, TLSPlaintex=
t.length =3D 1, and
=A0=A0 TLSPlaintext.fragment =3D 0x00).=A0 Note that the l=
ength of the plaintext
=A0=A0 is greater than the corresponding TLSPlaintext.leng=
th due to the
=A0=A0 inclusion of TLSInnerPlaintext.type and any padding=
 supplied by the
=A0=A0 sender.=A0 EAP server implementations MUST set TLSP=
laintext.fragment to
=A0=A0 0x00, but EAP peer implementations MUST accept any =
application data
=A0=A0 as a Commitment Message from the EAP server to not =
send any more handshake messages.

=A0

There is still a challenge in scenarios where a server chooses not to issue any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni notes this problem:

I did see some issues when OpenSSL 1.1.1 when disabling se=
nding of
session tickets, though. The current draft indicates that =
the empty
Application Data payload would be send out in the same EAP=
 packet with
the server's Finished message, i.e., before the server hav=
ing
authenticated the peer. And this would be done without the=
 peer having
used TLS early data (which is explicitly disallowed in the=
 draft). That
combination did not work with my experiments since OpenSSL=
 was rejecting
the SSL_write() operation after the server having written =
own Finished
message, but before having received the Finished message f=
rom the peer..
The OpenSSL documentation seemed to imply that SSL_write_e=
arly_data()
could be used by the server _if_ the client first sent ear=
ly data.. At
least in my tests, OpenSSL rejected that call without earl=
y data from
the client.

=A0

This is why the current text also says the following:

 The Commitment Message may be sent in the sa=
me
=A0=A0 EAP-Request as the last handshake record or in a se=
parate EAP-
=A0=A0 Request.=A0 Sending the Commitment Message in a sep=
arate EAP-Request
=A0=A0 adds an additional round-trip, but may be necessary=
 in TLS
=A0=A0 implementations that only implement a subset of TLS=
 1.3.=A0 In the case
=A0=A0 where the server sends the Commitment Message in a =
separate EAP-
=A0=A0 Request, the conversation will appear as shown in F=
igure 9.=A0 After
=A0=A0 sending the Commitment Message, the EAP server may =
only send an EAP-
=A0=A0 Success, an EAP-Failure, or an EAP-Request with a T=
LS Alert Message.

=A0

Thus, the current design decision has been guided by parallel implementation experience and it is the best solution we could come up with (given all the practical limitations).

--Mohit

On 6/12/20 11:36 AM, Hannes Tschofenig wrote:

Hi all,

=A0

This has probably been discussed extensively in the EMU group. I am sorry to bring it up again but I believe this is a bad design decision. I raised it in my short review just sent to the list but I believe it is worthwhile to point it out separately.

=A0

draft-ietf-emu-eap-tls13 introduces a ne= w message to EAP-TLS, namely the Commitment Message. This requires extra code in an implementation because the normal behavior would be to run a TLS stack and then send encrypted data.

EAP-TLS does, however, not send application data*. This message changes this. Not only does it not send encrypted application data it requires an implementation to transmit a plaintext application data record after the application traffic secret has been created and before that application traffic secret is used to protect post handshake messages. This will make it difficult to re-use an off-the-shelf TLS 1.3 stack.

=A0

There is very little motivation about this message othe=
r than 
=A0
=93
=A0=A0 When an EAP server has =
sent its last handshake message (Finished or a
=A0=A0 Post-Handshake), it com=
mits to not sending any more handshake
=A0=A0 messages by sending a C=
ommitment Message.
=93

=A0

I might miss something important here bu= t why cannot the EAP-Success or EAP-Failure serve that purpose?

=A0

Here are two examples to explain what I mean:

=A0

  1. Failed exchange

=A0

=A0=A0=A0 EAP Peer=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP Server
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Identity=

=A0=A0=A0 EAP-Response/=

=A0=A0=A0 Identity (Privacy-Fr=
iendly)=A0 -------->
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (TLS Start)
=A0=A0=A0 EAP-Response/=

=A0=A0=A0 EAP-Type=3DEAP-TLS
=A0=A0 (TLS ClientHello)=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0(TLS ServerHello,=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS EncryptedExtensions,
          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS CertificateRequest,<=
/pre>
          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Certificate,

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0TLS CertificateVerify,

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Finished=
,

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0 Commitment Message)

          
=A0=A0=A0 EAP-Response/=


          
=A0=A0=A0 EAP-Type=3DEAP-TLS

          
=A0=A0 (TLS Certificate,

          
=A0=A0=A0 TLS CertificateVerif=
y,

          
=A0=A0=A0 TLS Finished)=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->
=

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0 =A0=A0(TLS Fatal Alert)
          
=A0=A0=A0 EAP-Response/=


          
=A0=A0=A0 EAP-Type=3DEAP-TLS=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Failure
=

          
=A0

          
=A0

          
    
            
  1. Successfu=
l
              Exchange with Post-Handshake NewSession Ticket
          

          
=A0

          
=A0=A0=A0 EAP Peer=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP Server

          
=A0

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Identity=


          
=A0=A0=A0 EAP-Response/=


          
=A0=A0=A0 Identity (Privacy-Fr=
iendly)=A0 -------->

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (TLS Start)

          
=A0=A0=A0 EAP-Response/=


          
=A0=A0=A0 EAP-Type=3DEAP-TLS

          
=A0=A0 (TLS ClientHello)=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0(TLS ServerHello,=


          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS EncryptedExtensions,
          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS CertificateRequest,<=
/pre>
          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Certificate,

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0TLS CertificateVerify,

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Finished)

          
=A0=A0=A0 EAP-Response/=


          
=A0=A0=A0 EAP-Type=3DEAP-TLS

          
=A0=A0 (TLS Certificate,

          
=A0=A0=A0 TLS CertificateVerif=
y,

          
=A0=A0=A0 TLS Finished)=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->
=

          
=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0EAP-Reques=
t/

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (TLS NewSessionTicket,

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0 Commitment Message)

          
=A0=A0=A0 EAP-Response/=


          
=A0=A0=A0 EAP-Type=3DEAP-TLS=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->

          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Success
=

          
=A0

          
=A0

          
Ciao

          
Hannes

          
=A0

          
(*): FWIW Post handshake messages are
            protected with the application traffic secrets.
          
=A0

          
IMPORTANT NOTICE: The contents of this
            email and any attachments are confidential and may also be
            privileged. If you are not the intended recipient, please
            notify the sender immediately and do not disclose the
            contents to any other person, use it for any purpose, or
            store or copy the information in any medium. Thank you.
            

            

            

          
_______________________________________________=


          
Emu mailing list

          
E=
mu@ietf.org

          
https://www.ietf..org/mailman/listinfo/emu<=
/o:p>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 
____________________________=
___________________
Emu mailing list
Emu@ie=
tf.org
https://www.ietf.org/mailman/listinfo/emu
--------------067F9FC09A7D12F5169BD387-- --------------ms090002050804050907000100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMUwggX7MIID46ADAgECAhBcf8Ki080s7KKjg2APnSBWMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEwMDgxMDAzMjJaFw0yMDEwMDgxMDAzMjFaMGgxETAPBgNV BAoMCEVyaWNzc29uMRYwFAYDVQQDDA1Nb2hpdCBTZXRoaSBNMSkwJwYJKoZIhvcNAQkBFhpt b2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZXNldG1vaDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAN23/VIr1UI1NLeaFL45vzBE0NglNKyyUQknMqT5zRxm ocJ74fYRJmfHmaQxEYdxp6cCYFxbM2OJOiMN5LRxEQG282Dsjnff6mHXt5wNsMrHZ88poT3X yZCzFBkQF/kswJKu6OD9v1J6WWl9fV2h0QRP0ju+B/H2O3OzioHDP9Qazzr5TMTvmRmXoMfh WXyH/joBaGVyn8SCeRaI0wVGRCKDp93UzdL5o+qGqCUPJQP/2SR/4UoCUTqEtSgh4iCBNAs/ OwhHwbWdU73/EJtsaaOG2fhwMTgWR3KJOIUMyWtRBcO9cIan+82SNgAByR4x2BKIWgFvSPNo GXKn1nOi0W0CAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1 c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUFBwEB BHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGm1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUM0z7o31aA+qQasQqDc7/Ppn7u5MwHwYDVR0jBBgwFoAUHHsZ npecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQCB 35yJmyIRJUmxQmpYX7hNdQJXxJdIAMzCe+rQsz+0F1zA8xsYn4Rn5m7SVGKbE4ONC+EUHHzQ o1OpA5txlK+IPRMqZTM2cQpAet8Qy2vRqFVd0pFDmPx0Az/SPooz7gnuIaPaCGeXOSSxtSOu rX+7fE2EiE/SuCFKmtsFmwnZH62hDDtzd3XTwmJia/5Ab+8/elAstT5a1cP52SorrkuLPgAB ny/XJzsU3LOQQ37Wm5DMyMPEK+zkBG/+2t1cOGgryvu7Hq14NfkAUZxHMei6Yf2UABNxbapB 4tyxqpZuPZDl1AwRKMGYHPsnywK4PZDdsD6R+O/YCWdfq9Q3MMCT3C6vu38phy1r6QDCVHVI IPdirDfZ2ypbeqHAwkswioykkBTln9DEyaTYMlxb41EYh/3JwUQmuQQ4ozSfcLTwoaQ+M+Z4 1J/n7AARwD7u3Lb2ls+fmvOLrC+tc0pXlvTKspIhpaNC1Cz7sbsjMSbSqBW9PtY+Vex7GB2J zI8fDHTT/8Jx+33cta2BE6mPFeUY2lu12zQiqNVUc9zEQ7WqGz4VTGFZDnzfU2gCAAYsuimf kQJD+Sr2G3wXs38yN1OhWHBuG1fglz0k5URhXMNC8HtRityIm2504ym5GpTrriJ8X1fQDYN1 WlOPvv4xJpfHAz4NMKJKQmCNtfuZ8BNNyTCCBsIwggSqoAMCAQICEFO4foPhnJkok7CbSRzs uOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRl bGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8A ALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL 7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhV W4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujn whljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W0 7nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBR QGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1 fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77 /NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioIT KffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAt BggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUF BzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQB gg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFz b25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVs aWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OOR auPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUA A4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNH CZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKv dASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQy sshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgb MgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6L kIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3T QYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX 2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDk ZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEBMFswRzELMAkGA1UE BhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlk dWFsIENBIHYzAhBcf8Ki080s7KKjg2APnSBWMA0GCWCGSAFlAwQCAQUAoIIBsTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MTYxMDI1MTNaMC8GCSqG SIb3DQEJBDEiBCAKtNq+tjRIDUKBH8vrGcbqmUzvmZkNA7ntbtCCBt0H7jBqBgkrBgEEAYI3 EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQXH/CotPNLOyio4NgD50gVjBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMGwGCyqGSIb3 DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEFx/wqLTzSzsoqODYA+dIFYwDQYJKoZI hvcNAQEBBQAEggEAPGl3WFoeyoKO+rz4R0DN9kLZQL7ywRF4IcoinCiAPbJwvHKLdk4F678Y 14+Zh1qoO2d8PtWl03CBjnqFDxAACHPu4KO7U4i/xqGGUh1tB7r5ExC03loPmuEQEZqv3xPo 4HW21uL+aMLBE5WMZwaCZSVsis2lPAB3lPrZ7HaMw/m+3dP48F17qIgeIU7SYIve+lnRMNID +YP14eIILNIRxh9CcwPgaVrffkfJbFiA4xvugiTzjUxRrbOh5/c+GQmCjP57cwbWBVfz2Gq/ gkct0tdxM3p6BL/36q4XolfG4DZSQjPGjlr7Y6mHvFsMCq1CPXBKJuD+6uzqjt8pMtM3uwAA AAAAAA== --------------ms090002050804050907000100-- From nobody Tue Jun 16 03:58:20 2020 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 C4BB83A14EF for ; Tue, 16 Jun 2020 03:43:57 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=lUaJWij3; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=lUaJWij3 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 yydgz7MJm5kT for ; Tue, 16 Jun 2020 03:43:53 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2061.outbound.protection.outlook.com [40.107.20.61]) (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 EDEA13A14ED for ; Tue, 16 Jun 2020 03:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bFKQPEEiDALbR9owV/7qJKBs6IiMfmwk7JxRFWKQr4c=; b=lUaJWij3tK0mvS8QfGQfvhsfuJRaeyw04NwOThfSY/+YWi+51iusQnQKqeLmylljnJCS9jx7Y+cPLC1xFwL3ZhvZM3vbRjXFG0paOl2udrDeWJJJliR9OLhc8zcwU5H8F/VKI507FQ2oyb/Q0BlcS4FSlQO2HrpXJ49F2hi3aCw= Received: from DB6PR0802CA0042.eurprd08.prod.outlook.com (2603:10a6:4:a3::28) by DB7PR08MB4220.eurprd08.prod.outlook.com (2603:10a6:10:7f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Tue, 16 Jun 2020 10:43:47 +0000 Received: from DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:a3:cafe::22) by DB6PR0802CA0042.outlook.office365.com (2603:10a6:4:a3::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21 via Frontend Transport; Tue, 16 Jun 2020 10:43:47 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT052.mail.protection.outlook.com (10.152.21.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Tue, 16 Jun 2020 10:43:47 +0000 Received: ("Tessian outbound f590bea98ab4:v59"); Tue, 16 Jun 2020 10:43:47 +0000 X-CR-MTA-TID: 64aa7808 Received: from fe2013150252.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 42165D3A-2F79-40CE-8986-4A9B742FC2D5.1; Tue, 16 Jun 2020 10:43:41 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fe2013150252.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 16 Jun 2020 10:43:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i5yn2FBHW0m4UBAilfCPq/UGTbbIEYt669pk5+FZq+AEQPhB4tRMNklPvWsFiAmyqPYjV5UKstMnPRM5Ktau9HtLMKQHwy+HL6wPeYe7aVTyfwl2aB3MBfYXdmp8CtU/VWSoKMINq1oJESnQLIPH8kLOau/lCfvNJ/VVolibKpto08CRo3szIKZswd0zCGEbybAvLufsJmYXOP5vsTPviqu5tyU4i8tl5fNCVp0p+gfTrj8KTKPUb/5vbYd0fhcIw9IfHHDvOMxuEsRmZ8atTYMUqLMKMBugLIZZkt8bxFSf49e4T4nFNrDMzMYMYHH9NrDNcLPY+CX9ErJuhUuWAQ== 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=bFKQPEEiDALbR9owV/7qJKBs6IiMfmwk7JxRFWKQr4c=; b=UB7JJdzefm/UgQZ3QTopUJdmlUWfMbeZLELFFF/IhNm1pfaTxhexMILvcP8+p+UI3egJweilnbId49tmmhPe2OHYoP4YvJX8Y0q9beMpJe1hlekfo+it2eKVitD5ifDogY81L1JldPu2yUFRoCA/BiWXNnhfZFc+jNVooCD5cnUYAhhqbDjgZa1hZPbprKsVSnyKpx4o3sbfeFI0AK8n9cSoWzesZ+g5SzCd72kU1Y0xE2iUuPIn5kXqBcuzzqrmtZqcMPnIBIcWnQLLbheFHLRnQTTbkuzfQBSiRb1avlvg5alDYtSm+WF3OGDrlMAIl9tbUbc0EO1vhXR3VsM9xQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bFKQPEEiDALbR9owV/7qJKBs6IiMfmwk7JxRFWKQr4c=; b=lUaJWij3tK0mvS8QfGQfvhsfuJRaeyw04NwOThfSY/+YWi+51iusQnQKqeLmylljnJCS9jx7Y+cPLC1xFwL3ZhvZM3vbRjXFG0paOl2udrDeWJJJliR9OLhc8zcwU5H8F/VKI507FQ2oyb/Q0BlcS4FSlQO2HrpXJ49F2hi3aCw= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3538.eurprd08.prod.outlook.com (2603:10a6:208:de::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Tue, 16 Jun 2020 10:43:40 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3088.029; Tue, 16 Jun 2020 10:43:40 +0000 From: Hannes Tschofenig To: Mohit Sethi M , "emu@ietf.org" Thread-Topic: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Thread-Index: AdZAkc+cCh243U45Rdqk3n8/SPrXVQCilGmAACgxZ7AAAuFOAAAAHnVQ Date: Tue, 16 Jun 2020 10:43:40 +0000 Message-ID: References: <1e769dbd-b563-0ba6-c398-8066c6151310@ericsson.com> <116a2a3f-9d9c-d99e-715a-2531f59da7a8@ericsson.com> In-Reply-To: <116a2a3f-9d9c-d99e-715a-2531f59da7a8@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: aa905715-8108-45e3-bc9b-246f3aa57d52.1 x-checkrecipientchecked: true Authentication-Results-Original: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [156.67.194.193] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: cdc6cb3c-ca12-4781-1636-08d811e225fd x-ms-traffictypediagnostic: AM0PR08MB3538:|DB7PR08MB4220: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04362AC73B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: y0q4XMS7t7ZZtlIFF7KIsWZ72/5+U3Tgcr48KQ/NGizSHWKUCGTLieAWvIb0hEFOv5TNMDPEQrW/gz1qYtONSIOeW0H40UuAGc8ZYte1E/tdKzBlvTaRSt2rU3/YapZAsiUvxHOptjJeGxbbpd/84CM77gGjVZ+uAm0z/d99ync4XV3AQSVD9V8CyXE+GICGLDMUwPJ+uTFDIIfc17NuG6XwzoV3kEUkHJAPnBNhiPi1y6moi6H+g5qmrQ3Yiv/kJURfUpJK+2ozzuD/pMr5d1+bY3VnQusfYXZ0Ky5+wyTzUnuzJO/EyOCOIkX0FXLxn10eciruk4STgnoZcdcIYfSQK3VBHHpL60mUEFLV0AU9BKZ7xYeWJ6yQpjrCZpZpyunWthq0dWbQ7cb0QLzEjA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(346002)(376002)(39860400002)(396003)(30864003)(5660300002)(186003)(66476007)(9326002)(6506007)(18074004)(71200400001)(76116006)(66946007)(66446008)(86362001)(66556008)(53546011)(52536014)(64756008)(55016002)(966005)(478600001)(8676002)(83380400001)(26005)(33656002)(316002)(8936002)(166002)(9686003)(15650500001)(7696005)(110136005)(2906002)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Ul4E6kRzOZaiUaqT5eNBKJYmM2P6QSO3T8SUuq3+o2v8EChIl4jFugZvOop6OSzz5nVTPTiy2x2jVPSlqT+9vWCZByrq06ghmeFM4aizzwUT+Ig0RHoF4tuVBiOOH0KmKpjSofe6KuWwXIws7+ANskugQg01ir6LzHgD+WAg0wYTtav7QFKpxbwp7mqcdZ0+FJqZ+/J0/wwcAfWoNj6v8uhDsBBqNR00T82ilIyP6nk1A1mWgtUIWDMfpltVSBtuDejqH2SiNQhOLGojX/jbSwKnjb3VwllkZp5O2C/TDd1j7s8ePBYRoETGJujY89OXkWI/AB6bcCmCtdlccYGsrAkf8NZNpo5qLQv8LLGT0PmQ92N0Uj7lUmxVFNdlKoEGY4y5ltIdG0xib/Tji8E6pnM8cHbKiXkaGXmZYTmVLr1P3BKOavsmLKNtww8Vtw8ajZLURUnWx7u8SAtWIYlWPpCYprzGM7L+23GY3+2aoeM/7o/+ewZx5EhRjkxpjfw7 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB371611B4AADA5FCF9604E0B6FA9D0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3538 Original-Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(136003)(39860400002)(46966005)(2906002)(9686003)(33656002)(26005)(30864003)(8936002)(316002)(15650500001)(8676002)(7696005)(110136005)(5660300002)(55016002)(18074004)(6506007)(86362001)(53546011)(166002)(83380400001)(478600001)(81166007)(186003)(70206006)(356005)(82310400002)(336012)(47076004)(70586007)(82740400003)(52536014)(9326002)(966005)(579004)(559001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: d24c3de1-84c7-4b0f-733f-08d811e221e3 X-Forefront-PRVS: 04362AC73B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hQVaY8dEtSyEbJ24jTd9mXg0TKtfUPyFvYWGtlL1jtKvF3S1sCp2gXcyrP6ACSMldPbK8cmmUnQVH4ejHbbSuxgW5wLao+khioVic2SPnSJGPDfsLdy/VwnjKtQXJtCe7D1Bb3EsQKfbipwhUPGGiNmDa/X3Q8eIaRInpT1F82vLJtd+H10GXQINVWzIBsSSyNE5qm38SPnHQMM8XlTqxAilBL39tCVXIVnm032CcXTO5l9k8a8nc+bEVWub5NT9vG4uKwkk+ZRj3HHbSL/qZ2XLBkSedMy1CwGdivhwg1uqMSWrNop2hHXIcJNvVOKsWDNwc5rK82c1LlMw/bjen5nLC1Xj4uf8nVlKGsh+tC3FOtxNwM0rkd+3eQ7Z9P1eMg6zS8e2jYyYFGtu1KX+7ykt7FWM2qCMgdqw7B2iOynyQEHbuNPAgwLiQSvGIc/T+TPcYLDiItlxIya6YKbChHsuBuVjc2L/qlGHXF5Zpu4= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2020 10:43:47.0469 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cdc6cb3c-ca12-4781-1636-08d811e225fd X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB4220 Archived-At: X-Mailman-Approved-At: Tue, 16 Jun 2020 03:58:18 -0700 Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 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, 16 Jun 2020 10:43:58 -0000 --_000_AM0PR08MB371611B4AADA5FCF9604E0B6FA9D0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mohit, See below. Thanks for your super quick response. From: Mohit Sethi M Sent: Tuesday, June 16, 2020 12:25 PM To: Hannes Tschofenig ; Mohit Sethi M ; emu@ietf.org Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Hi Hannes, On 6/16/20 12:37 PM, Hannes Tschofenig wrote: Hi Mohit, I had a chance to read through the emails you provided. A good discussion. I can offer three solutions: 1. Use EAP-Success / EAP-Failure as an indication for the completion of = the exchange, even if it is not a reliable notification mechanism. If the E= AP peer does not receive the NewSessionTicket message then it does not matt= er because it is optional to use anyway. It will be a failure case anyway i= f the EAP-Success / EAP-Failure got lost. They EAP peer may not even know w= hether the exchange was successful despite correctly processing TLS handsha= ke messages. I am uncomfortable doing this without updating RFC 3748. Not only will we b= e violating RFC 3748, we would still have the problem of peer uncertainty a= bout the next message. It could be a NewSessionTicket or EAP-Success/Failur= e. [Hannes] What is done in EAP today? 1. Demand that the NewSessionTicket is sent immediately after the Finish= ed, very much like you currently demand that the Commitment Message is atta= ched to the last message. I assume that you imply immediately after the server has sent its TLS Finis= hed (and not after the server has received the TLS Finished from the peer)?= Are you also implying that a NewSessionTicket should always be sent out, r= egardless of whether a server wants or supports resumption? What if the ser= ver is issuing several tickets? [Hannes] I would leave it as an option to send a NewSessionTicket but it is= sent then it has to be in the last message. Here is the exchange: Case 1: NewSessionTicket Message Sent EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished, TLS NewSessionTicket) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> <-------- EAP-Success Case 2: No ticket sent EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> <-------- EAP-Success 1. Use the Commitment Message as an application layer payload (encrypted= as it should be). (Note that this has nothing to do with early data.) If t= he OpenSSL spec does not support an application layer message from the serv= er right after the finish then it is not compliant to the TLS 1.3 RFC. How would that work? How can server send encrypted application layer payloa= d without having received the TLS Finished from the peer. [Hannes] Here is a copy-and-paste from the TLS spec: Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* --------> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] The TLS 1.3 spec says: Note that while the server may send Application Data prior to receiving the client's Authentication messages, any data sent at that point is, of course, being sent to an unauthenticated peer. The question is whether the aspect of sending data to an unauthenticated pe= er matters in this case? I would argue that it does not matter because the = currently defined Commitment message is unencrypted. While I am open to discussing better alternatives, I think from an implemen= tation perspective, it makes sense to have a definite notification mechanis= m for the server to notify the peer that no more post-handshake messages ar= e to be expected. [Hannes] I am trying to find out how to implement this functionality into o= ur stack and it looks painful (developer-visible API changes). Of course, i= t is difficult to accommodate for not yet invented post-handshake authentic= ation messages. We don't even know whether they will be compatible with the= network access authentication use case. Ciao Hannes PS: I believe it would be good to highlight this specific aspect in the int= roduction of the document. For me it appeared that the specification is lar= gely a copy-and-paste job but this clearly is something worth highlighting = to the reader/implementer. --Mohit The current solution in the draft, for example, does not work with Mbed TLS= because you cannot tell the stack to suddenly bypass the encryption layer = (after successfully establishing it) to send a plaintext message. Ciao Hannes From: Mohit Sethi M Sent: Monday, June 15, 2020 3:52 PM To: Hannes Tschofenig ; emu@ietf.org Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Hi Hannes, Unfortunately you are wrong here. The design decision was in fact taken to = avoid changes to the underlying TLS implementation while also avoiding chan= ges to RFC 3748. To summarize: Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP= -TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/= msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. Essentially, TLS 1.3 allows a server = to send a Post-Handshake message with a NewSessionTicket at any time. Howev= er, in EAP-TLS this is not possible. The TLS tunnel is torn down after auth= entication. John notes in his response to Jouni (https://mailarchive.ietf.o= rg/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS the connection is ass= umed to stay open for a long time after the client sends Finished, in EAP t= he connection is assumed to be closed shortly after." An earlier cleaner way of sending NewSessionTicket required an extra round = trip and left the peer uncertain about the next message (https://tools.ietf= .org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted thi= s uncertainty for a peer: " the peer has no idea whether the NewSessionTick= et is delivered after ClientFinished. In other words, the next message in t= he sequence could be either continuation of EAP-TLS method or EAP-Success".= You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". S= ee RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the following: Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. and On the peer, after success result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully. Thus, EAP-Success cannot be used as a reliable notification mechanism. Till= version 05 of the document, we used an empty application data record as a = notification of the last handshake message. The text said: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by appending an empty application data record (i..e. a TLS record with TLSPlaintext.type =3D application_data and TLSPlaintext.length =3D 0) to the last handshake record. After sending an empty application data record, the EAP server may only send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. However, Jouni in a later response (https://mailarchive.ietf.org/arch/msg/e= mu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted that such behavior is non-trivial to= achieve with OpenSSL. He notes " OpenSSL is not willing to send such an em= pty TLSPlaintext structure. SSL_write() has following to say : 'You should = not call SSL_write() with num=3D0, it will return an error. SSL_write_ex() = can be called with num=3D0, but will not send application data to the peer.= '" Therefore, the text was later updated to: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. The Commitment Message is a TLS record with application data 0x00 (i.e. a TLS record with TLSPlaintext.type =3D application_data, TLSPlaintext.length =3D 1, and TLSPlaintext.fragment =3D 0x00). Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handsha= ke messages. There is still a challenge in scenarios where a server chooses not to issue= any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg= /emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni notes this problem: I did see some issues when OpenSSL 1.1.1 when disabling sending of session tickets, though. The current draft indicates that the empty Application Data payload would be send out in the same EAP packet with the server's Finished message, i.e., before the server having authenticated the peer. And this would be done without the peer having used TLS early data (which is explicitly disallowed in the draft). That combination did not work with my experiments since OpenSSL was rejecting the SSL_write() operation after the server having written own Finished message, but before having received the Finished message from the peer.. The OpenSSL documentation seemed to imply that SSL_write_early_data() could be used by the server _if_ the client first sent early data.. At least in my tests, OpenSSL rejected that call without early data from the client. This is why the current text also says the following: The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP- Request. Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3. In the case where the server sends the Commitment Message in a separate EAP- Request, the conversation will appear as shown in Figure 9. After sending the Commitment Message, the EAP server may only send an EAP- Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. Thus, the current design decision has been guided by parallel implementatio= n experience and it is the best solution we could come up with (given all t= he practical limitations). --Mohit On 6/12/20 11:36 AM, Hannes Tschofenig wrote: Hi all, This has probably been discussed extensively in the EMU group. I am sorry t= o bring it up again but I believe this is a bad design decision. I raised i= t in my short review just sent to the list but I believe it is worthwhile t= o point it out separately. draft-ietf-emu-eap-tls13 introduces a new message to EAP-TLS, namely the Co= mmitment Message. This requires extra code in an implementation because the= normal behavior would be to run a TLS stack and then send encrypted data. EAP-TLS does, however, not send application data*. This message changes thi= s. Not only does it not send encrypted application data it requires an impl= ementation to transmit a plaintext application data record after the applic= ation traffic secret has been created and before that application traffic s= ecret is used to protect post handshake messages. This will make it difficu= lt to re-use an off-the-shelf TLS 1.3 stack. There is very little motivation about this message other than " When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. " I might miss something important here but why cannot the EAP-Success or EAP= -Failure serve that purpose? Here are two examples to explain what I mean: 1. Failed exchange EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, TLS Finished, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Fatal Alert) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Failure 1. Successful Exchange with Post-Handshake NewSession Ticket EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=3DEAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=3DEAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=3DEAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=3DEAP-TLS (TLS NewSessionTicket, <-------- Commitment Message) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Success Ciao Hannes (*): FWIW Post handshake messages are protected with the application traffi= c secrets. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf..org/mailman/listinfo/emu IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB371611B4AADA5FCF9604E0B6FA9D0AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mohit,

 

See below. Thanks for your super quick response.

 

 

From: Mohit Sethi M <mohit.m.sethi@ericsso= n.com>
Sent: Tuesday, June 16, 2020 12:25 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Mohit Sethi= M <mohit.m.sethi@ericsson.com>; emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

 

Hi Hannes,

On 6/16/20 12:37 PM, Hannes Tschofenig wrote:

Hi Mohit,

 

I had a chance to read through the emails you provid= ed. A good discussion.

 

I can offer three solutions:

 

  1. Use EAP-Success / EAP-Failure as an indication for the completion of = the exchange, even if it is not a reliable notification mechanism. If the E= AP peer does not receive the NewSessionTicket message then it does not matter because it is optional to use anyway. It w= ill be a failure case anyway if the EAP-Success / EAP-Failure got lost. The= y EAP peer may not even know whether the exchange was successful despite co= rrectly processing TLS handshake messages.

I am uncomfortable doing this without updating RFC 3= 748. Not only will we be violating RFC 3748, we would still have the proble= m of peer uncertainty about the next message. It could be a NewSessionTicke= t or EAP-Success/Failure.

[Hannes] What is done in EAP today?

 

  1. Demand that the NewSessionTicket is sent immediately after the Finish= ed, very much like you currently demand that the Commitment Message is atta= ched to the last message.

 

I assume that you imply immediately after the server= has sent its TLS Finished (and not after the server has received the TLS F= inished from the peer)? Are you also implying that a NewSessionTicket shoul= d always be sent out, regardless of whether a server wants or supports resumption? What if the server is issui= ng several tickets?

 

[Hannes] I would leave it as an option to send a New= SessionTicket but it is sent then it has to be in the last message. Here is= the exchange:

 

= Case 1: NewSessionTicket Message Sent

=  

=     EAP Peer        =             &nb= sp;            =              EA= P Server

=  

=             &nb= sp;            =             &nb= sp;            =        EAP-Request/

=             &nb= sp;            =         <--------   &n= bsp;            = ;  Identity

=     EAP-Response/

=     Identity (Privacy-Friendly)  -------->

=             &nb= sp;            =             &nb= sp;            =        EAP-Request/

=             &nb= sp;            =             &nb= sp;             = ; EAP-Type=3DEAP-TLS

=             &nb= sp;            =         <--------   &n= bsp;            (TLS= Start)

=     EAP-Response/

=     EAP-Type=3DEAP-TLS

=    (TLS ClientHello)       &nb= sp;     -------->

=             &nb= sp;            =             &nb= sp;            =        EAP-Request/

=              &n= bsp;            = ;            &n= bsp;            = ; EAP-Type=3DEAP-TLS

=             &nb= sp;            =             &nb= sp;            =   (TLS ServerHello,

=             &nb= sp;            =             &nb= sp;       TLS EncryptedExtensions,=

=             &nb= sp;            =             &nb= sp;        TLS CertificateRequest,<= /o:p>

=             &nb= sp;            =             &nb= sp;            =    TLS Certificate,

=             &nb= sp;            =             &nb= sp;         TLS CertificateVerify,<= o:p>

=             &nb= sp;            =         <--------   &n= bsp;          TLS Finished,

=             &nb= sp;            =             &nb= sp;         TLS NewSessionTick= et)

=     EAP-Response/

=     EAP-Type=3DEAP-TLS

=    (TLS Certificate,

=     TLS CertificateVerify,

=     TLS Finished)       &= nbsp;        -------->

=             &nb= sp;            =         <--------   &n= bsp;           EAP-Succes= s

=  

= Case 2: No ticket sent

=  

=  

=  

=     EAP Peer        =             &nb= sp;            =              EA= P Server

=  

=             &nb= sp;            =             &nb= sp;            =       EAP-Request/

=             &nb= sp;            =         <--------   &n= bsp;            = ;  Identity

=     EAP-Response/

=     Identity (Privacy-Friendly)  -------->

=             &nb= sp;            =             &nb= sp;            =        EAP-Request/

=             &nb= sp;            =              &n= bsp;            = ; EAP-Type=3DEAP-TLS

=             &nb= sp;            =         <--------   &n= bsp;            (TLS= Start)

=     EAP-Response/

=     EAP-Type=3DEAP-TLS

=    (TLS ClientHello)       &nb= sp;     -------->

=             &nb= sp;            =             &nb= sp;            =        EAP-Request/

=             &nb= sp;            =             &nb= sp;            =   EAP-Type=3DEAP-TLS

=             &nb= sp;            =             &nb= sp;            =   (TLS ServerHello,

=             &nb= sp;            =             &nb= sp;       TLS EncryptedExtensions,=

=             &nb= sp;            =             &nb= sp;        TLS CertificateRequest,<= /o:p>

=             &nb= sp;            =             &nb= sp;            =    TLS Certificate,

=             &nb= sp;            =             &nb= sp;         TLS CertificateVerify,<= o:p>

=             &nb= sp;             = ;       <--------   &n= bsp;          TLS Finished)

=     EAP-Response/

=     EAP-Type=3DEAP-TLS

=    (TLS Certificate,

=     TLS CertificateVerify,

=     TLS Finished)       &= nbsp;        -------->

=             &nb= sp;            =         <--------   &n= bsp;           EAP-Succes= s



  1. Use the Commitment Message as an application layer payload (encrypted= as it should be). (Note that this has nothing to do with early data.) If t= he OpenSSL spec does not support an application layer message from the server right after the finish then it i= s not compliant to the TLS 1.3 RFC.

 

How would that work? How can server send encrypted application layer pay= load without having received the TLS Finished from the peer.

[Hannes] Here is a copy-and-paste from the TLS spec:

 

       Client&nb= sp;            =             &nb= sp;            =      Server

 

Key  ^ ClientHello

Exch | + key_share*

     | + signature_alg= orithms*

     | + psk_key_excha= nge_modes*

     v + pre_shared_ke= y*       -------->

       &nbs= p;            &= nbsp;           &nbs= p;             =     ServerHello  ^ Key

       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   + key_share*  | Exch

       &nbs= p;            &= nbsp;           &nbs= p;           + pre_sh= ared_key*  v

       &nbs= p;            &= nbsp;           &nbs= p;       {EncryptedExtensions}  ^  = Server

       &nbs= p;            &= nbsp;            &nb= sp;      {CertificateRequest*}  v  = Params

       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; {Certificate*}  ^

       &nbs= p;            &= nbsp;           &nbs= p;        {CertificateVerify*}  | A= uth

       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     {Finished}  v

        &nb= sp;            =           <--------&nb= sp; [Application Data*]

     ^ {Certificate*}=

Auth | {CertificateVerify*}<= /p>

     v {Finished} &nb= sp;            -----= --->

       [Applicat= ion Data]      <------->  [Application = Data]

 

The TLS 1.3 spec says:

   Note that while the

   server may send Application Data = prior to receiving the client's

   Authentication messages, any data= sent at that point is, of course,

   being sent to an unauthenticated = peer.

The question is whether the aspect of sending data to an unauthenticated= peer matters in this case? I would argue that it does not matter because t= he currently defined Commitment message is unencrypted.  

 

While I am open to discussing better alternatives, I think from an imple= mentation perspective, it makes sense to have a definite notification mecha= nism for the server to notify the peer that no more post-handshake messages= are to be expected.

 

[Hannes] I am trying to find out how to implement this functionality int= o our stack and it looks painful (developer-visible API changes). Of course= , it is difficult to accommodate for not yet invented post-handshake authen= tication messages. We don’t even know whether they will be compatible with the network access authenticatio= n use case.

 

Ciao

Hannes

PS: I believe it would be good to highlight this specific aspect in the = introduction of the document. For me it appeared that the specification is = largely a copy-and-paste job but this clearly is something worth highlighti= ng to the reader/implementer.

 

--Mohit

The current solution in the draft, for example, does= not work with Mbed TLS because you cannot tell the stack to suddenly bypas= s the encryption layer (after successfully establishing it) to send a plain= text message.

 

Ciao

Hannes

 

From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig &= lt;Hannes.Tschofenig@arm.com>; emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

 

Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken = to avoid changes to the underlying TLS implementation while also avoiding c= hanges to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to = EAP-TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/.= Essentially, TLS 1.3 allows a server to send a Post-Handshake message with= a NewSessionTicket at any time. However, in EAP-TLS this is not possible. = The TLS tunnel is torn down after authentication. John notes in his response to Jouni (https://maila= rchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS= the connection is assumed to stay open for a long time after the client sends Finished, in EAP the connection is = assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra rou= nd trip and left the peer uncertain about the next message (https://= tools.ietf.org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted this uncertainty for a peer: " the peer has no idea= whether the NewSessionTicket is delivered after ClientFinished. In other w= ords, the next message in the sequence could be either continuation of EAP-= TLS method or EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". See RFC 3= 748 (https://tools.ietf.org= /html/rfc3748) which says the following:

   Implementation Note: Because the Success and Failure pack=
ets are not
   acknowledged, they are not retransmitted by the authentic=
ator, and
   may be potentially lost.  A peer MUST allow for this=
 circumstance as
   described in this note. 

and 

 On the peer, after success result indications have been exchange=
d by
   both sides, a Failure packet MUST be silently discarded.&=
nbsp; The peer
   MAY, in the event that an EAP Success is not received, co=
nclude that
   the EAP Success packet was lost and that authentication c=
oncluded
   successfully.


Thus, EAP-Success cannot be used as a reliable notification mechanism. Till= version 05 of the document, we used an empty application data record as a = notification of the last handshake message. The text said: 

When an EAP server has sent its last handshake message (Finished or a<=
o:p>
   Post-Handshake), it commits to not sending any more hands=
hake
   messages by appending an empty application data record (i=
..e. a TLS
   record with TLSPlaintext.type =3D application_data and
   TLSPlaintext.length =3D 0) to the last handshake record.&=
nbsp; After sending
   an empty application data record, the EAP server may only=
 send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS=
 Alert
   Message.

However, Jouni in a later response (https://= mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted t= hat such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL is not willing to send such = an empty TLSPlaintext structure. SSL_write() has following to say : 'You sh= ould not call SSL_write() with num=3D0, it will return an error. SSL_write_= ex() can be called with num=3D0, but will not send application data to the peer.'"

Therefore, the text was later updated to:

 When an EAP server has sent its last handshake message (=
Finished or a
   Post-Handshake), it commits to not sending any more hands=
hake
   messages by sending a Commitment Message.  The Commi=
tment Message is
   a TLS record with application data 0x00 (i.e. a TLS recor=
d with
   TLSPlaintext.type =3D application_data, TLSPlaintext.leng=
th =3D 1, and
   TLSPlaintext.fragment =3D 0x00).  Note that the leng=
th of the plaintext
   is greater than the corresponding TLSPlaintext.length due=
 to the
   inclusion of TLSInnerPlaintext.type and any padding suppl=
ied by the
   sender.  EAP server implementations MUST set TLSPlai=
ntext.fragment to
   0x00, but EAP peer implementations MUST accept any applic=
ation data
   as a Commitment Message from the EAP server to not send a=
ny more handshake messages.

 

There is still a challenge in scenarios where a server chooses not to is= sue any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ = Jouni notes this problem:

I did see some issues when OpenSSL 1.1.1 when disabling sending of
session tickets, though. The current draft indicates that the empty
Application Data payload would be send out in the same EAP packet with=

the server's Finished message, i.e., before the server having
authenticated the peer. And this would be done without the peer having=

used TLS early data (which is explicitly disallowed in the draft). Tha=
t
combination did not work with my experiments since OpenSSL was rejecti=
ng
the SSL_write() operation after the server having written own Finished=

message, but before having received the Finished message from the peer=
..
The OpenSSL documentation seemed to imply that SSL_write_early_data()<=
o:p>
could be used by the server _if_ the client first sent early data.. At=

least in my tests, OpenSSL rejected that call without early data from<=
o:p>
the client.

 

This is why the current text also says the following:

 The Commitment Message may be sent in the same
   EAP-Request as the last handshake record or in a separate=
 EAP-
   Request.  Sending the Commitment Message in a separa=
te EAP-Request
   adds an additional round-trip, but may be necessary in TL=
S
   implementations that only implement a subset of TLS 1.3.&=
nbsp; In the case
   where the server sends the Commitment Message in a separa=
te EAP-
   Request, the conversation will appear as shown in Figure =
9.  After
   sending the Commitment Message, the EAP server may only s=
end an EAP-
   Success, an EAP-Failure, or an EAP-Request with a TLS Ale=
rt Message.

 

Thus, the current design decision has been guided by parallel implementa= tion experience and it is the best solution we could come up with (given al= l the practical limitations).

--Mohit

On 6/12/20 11:36 AM, Hannes Tschofenig wrote:

Hi all,

 

This has probably been discussed extensively in the = EMU group. I am sorry to bring it up again but I believe this is a bad desi= gn decision. I raised it in my short review just sent to the list but I bel= ieve it is worthwhile to point it out separately.

 

draft-ietf-emu-eap-tls13 introduces a new message to= EAP-TLS, namely the Commitment Message. This requires extra code in an imp= lementation because the normal behavior would be to run a TLS stack and the= n send encrypted data.

EAP-TLS does, however, not send application data*. T= his message changes this. Not only does it not send encrypted application d= ata it requires an implementation to transmit a plaintext application data = record after the application traffic secret has been created and before that application traffic secret is used= to protect post handshake messages. This will make it difficult to re-use = an off-the-shelf TLS 1.3 stack.

 

There is very little motivation about this message other than =

 
“
   When an EAP server has sent i=
ts last handshake message (Finished or a
   Post-Handshake), it commits t=
o not sending any more handshake
   messages by sending a Commitm=
ent Message.
“

 

I might miss something important here but why cannot= the EAP-Success or EAP-Failure serve that purpose?

 

Here are two examples to explain what I mean: <= /o:p>

 

  1. Failed exchange

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,<=
/o:p>
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
            &nb=
sp;           TLS Finishe=
d,
       =
            &nb=
sp;            =
 <--------        Commitment Message)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS Certificate,=

    TLS CertificateVerify,<=
/span>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          (TLS Fa=
tal Alert)
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Failure

 

 

  1. Successful Exchange with Post-Handshake NewSession Ticket<= /li>

 

    EAP Peer  &nb=
sp;            =
            &nb=
sp;            =
      EAP Server
 
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
 <--------          &n=
bsp;       Identity
    EAP-Response/
    Identity (Privacy-Frien=
dly)  -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
 <--------          &n=
bsp;     (TLS Start)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS ClientHello)  =
           -------->
       =
            &nb=
sp;            =
            &nb=
sp;            EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
             &n=
bsp;      (TLS ServerHello,=

       =
            &nb=
sp;            =
             TL=
S EncryptedExtensions,
       =
            &nb=
sp;            =
            &nb=
sp; TLS CertificateRequest,
       =
            &nb=
sp;            =
            &nb=
sp;        TLS Certificate,<=
/o:p>
       =
             &n=
bsp;            =
;            &n=
bsp; TLS CertificateVerify,
       =
            &nb=
sp;            =
 <--------          &n=
bsp;   TLS Finished)
    EAP-Response/
    EAP-Type=3DEAP-TLS
   (TLS Certificate,=

    TLS CertificateVerify,<=
/span>
    TLS Finished) &nbs=
p;            &=
nbsp; -------->
        =
;            &n=
bsp;            =
;            &n=
bsp;           EAP-R=
equest/
       =
            &nb=
sp;            =
            &nb=
sp;       EAP-Type=3DEAP-TLS
       =
            &nb=
sp;            =
            &nb=
sp;  (TLS NewSessionTicket,
       =
            &nb=
sp;            =
 <--------        Commitment Message)
    EAP-Response/
    EAP-Type=3DEAP-TLS =
;            -------=
->
       =
            &nb=
sp;            =
 <--------          &n=
bsp;    EAP-Success

 

 

Ciao

Hannes

 

(*): FWIW Post handshake messages are protected with= the application traffic secrets.

 

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you. 


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf=
..org/mailman/listinfo/emu

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you. 

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf=
.org/mailman/listinfo/emu
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB371611B4AADA5FCF9604E0B6FA9D0AM0PR08MB3716eurp_-- From nobody Tue Jun 16 03:58:23 2020 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 C5D483A14F6 for ; Tue, 16 Jun 2020 03:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 563u9iH9px6q for ; Tue, 16 Jun 2020 03:57:54 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2085.outbound.protection.outlook.com [40.107.20.85]) (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 1D39E3A14F2 for ; Tue, 16 Jun 2020 03:57:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l9PczQDVnWk2VYlcy1U5unWCg/Al8qEOCU9Vgv97SCywqnRRYJwLN/kHTR4RJ1eZKln4AAW72UbxnkMpWP+4w9itCd4VUhuWykvk/ZBap+jYnfOZ2QApZfcebM7VdN0iAQ90283Z4Llk+4DgBQI1WdYZ1wQr7+fMZTrFgmVdpmOb/UAbwSrwOf4Wqqsylq0EKqoQ/u1+BcJ4tjhRtMyM1Gd26b8BKKp8aS4bD8U2gwwMCUaBnnq1j9/pHjPAZOKwaSyzVpP5I/7NGn+Zwd2knzB1mts0dTonAY+cY0wKMvhA12zwZFMLwVZV3aC55ZfV+qNyr51QC7ac/KF3WTl3Ew== 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=IwOVG8QG+iruNjuteVJXBTUnvo2qrfdfXLL7IwCmgEE=; b=PVFii166QrfgE3a4erOhRN9Qoj7V5R3+5Gjm7iamf3lwGkLSWK3HhkOI5livTlRZCKNz1rWRmp1AKpn+x4/Gyh9QkwaxQuBalyfViszWY0V5QRWJgQf2EFPgyIPJ6DShFRTtcZhxtoaf4SCHQWfqdZvMwRn2HrF2cdP26XR51w/5oOH+pc/ZVmKW5FcGUToWlxWlhGL2NDhlPzYt8tMlj+Lagjx3LP9RRnW40xeOZ+GinTZQlnU7hzV4ReLUHXH2LAPkfw8wrj5DM1HrUpEr4GfEt5iY6FZIScO8k9PKSp2+C2wgvrzoVAkaKWIbNPhSoeBZbtlyrWmUaV5okLP+6w== 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=IwOVG8QG+iruNjuteVJXBTUnvo2qrfdfXLL7IwCmgEE=; b=vCNUTO5a1l6H5Kdji2O2IoAHwRk0qXUj/Cp+dR84//F1KRwogXFlrpbtarrcG8v/Qszs3mtG/HLskyIlj/Dtlbjr45aCMQLiEkcxSyzwqmQ4Bbh21cKaLB47QK5C5KFdmoGC8oROmzvBbRft3z3TBCC5pwXbyiCM1ItXRIUg4iw= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR07MB3274.eurprd07.prod.outlook.com (2603:10a6:7:2f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.13; Tue, 16 Jun 2020 10:57:50 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e%7]) with mapi id 15.20.3109.018; Tue, 16 Jun 2020 10:57:50 +0000 From: Mohit Sethi M To: Hannes Tschofenig , "emu@ietf.org" Thread-Topic: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 Thread-Index: AQHWQxwhidapLR1LHUae6YFWy2dwOqja/WsAgAANM4CAAAUoAIAAA/SA Date: Tue, 16 Jun 2020 10:57:50 +0000 Message-ID: References: <1e769dbd-b563-0ba6-c398-8066c6151310@ericsson.com> <116a2a3f-9d9c-d99e-715a-2531f59da7a8@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:4147:9db5:d2f7:7e10:bb6b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 098a6433-0bf3-49f5-3f0c-08d811e41cc4 x-ms-traffictypediagnostic: HE1PR07MB3274: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04362AC73B x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DA790j8LqtS0b/maW0Ojf54UOqc22wYXCygZ8ydCC8npWZBTyygM3nKJHMbOLhGjnH/2l3GhBAjiS3GQKOGbJsY5HkykdrrYkJKgS2/ppyNkyVQzhmXAuy/QHo/YXInx7uhjMDDlWhFukp8SlPyofggGV46hzDAgtRVSP9+uvfygKOmcJyPoW19Z83MD8PpdOwOpfqcgOb2WvXTeG3X5iToo9REUyN2hWTVybgN1PQMpQVpq2GE2xOaYsTBsSZrO3bzLJwwwwAGBu+NY3kbGpz55sXFPDncJlDq3wExjkxTd/r+4DNBcTQyFViItidH9deCBqq8xWTWlVIjDLw/HjlOQg9IWI7XXRkw2VVpGgQ1/7w0PfAdh3RUeco6YWxyaeBBNAE1M8DdBa74Cn1ZYfgSkkrEzKFH92mAGcOoBqHPZcwgB6uQDDBZhhQB10/sf8Q77GTFP4PJuxTE2OXB3Iw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(39860400002)(366004)(396003)(376002)(166002)(2906002)(6512007)(316002)(110136005)(83380400001)(30864003)(31686004)(66446008)(186003)(36756003)(66556008)(2616005)(66946007)(66476007)(66616009)(76116006)(8676002)(64756008)(18074004)(5660300002)(966005)(99936003)(6506007)(53546011)(6486002)(31696002)(15650500001)(86362001)(478600001)(71200400001)(8936002)(43740500002)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: jQHuWjLcn3SwlR+0s5TjL4PZe3vbRFHs5O9vcK29pv+vDT8/LRtO49SSphbWaeHtx1/D1b9NTayf/5xvFJ8pj38X9VMU0TbEh+Y/fD6Nk3jyGrn17VGa9JsK6HR/VApAQZVrCeqFXMRMFeZpXCUXAwhB2XQrdLYNSUgbyoorRiBTzjuBhdcqxzc83A/53eI3w//vUtY9syJa3KFTS9mo697KVcUx5Oyqzh0mjlVT3QxlDTiboemEzZtrETmWcN2KoBZMvq1QqGzHxmAda/h+mVH0PDrw/lmOMn8uOkLtcVA03Lt06loLBEysjXjGg4DBccHAT63Nwrsmi5ofMmXxfh2PhfZ5OZXj9lCtsJuTnV6E0ZiiTDHNCi3Ek0H6xYMTSxN6dq8UyWJgdhd343vWNsH0RDPB/PgVtfhzJNkFQaDGpRdvf811ehDpwIch71jaysX+t7YwyCr9ezF+efqZw4HvLoWnX8N4ZlZVvsWJdpfgxLvgzel/ov7T4+vrHsV1CKN70fcHAquOGMH00F94Mdso/yLp2ZpOgZpa0HSiPUjoZ6s7xaHGa++XV8V3UD1c x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060601040200000608060408" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 098a6433-0bf3-49f5-3f0c-08d811e41cc4 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2020 10:57:50.4554 (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: 46aPf+lkKHaJ3YTuI7jL1Miki3og0q3DM8yccidaIeSHfJJMmOR9RHUY8P/fNHxjOJDmoM1Ca77RkYTLXnX8BL7OX2CKqH38ThH8mJfimQ0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3274 Archived-At: X-Mailman-Approved-At: Tue, 16 Jun 2020 03:58:18 -0700 Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13 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, 16 Jun 2020 10:57:59 -0000 --------------ms060601040200000608060408 Content-Type: multipart/alternative; boundary="------------567CEC60B3BFC0097A8E56E5" Content-Language: en-US This is a multi-part message in MIME format. --------------567CEC60B3BFC0097A8E56E5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: base64 SGkgSGFubmVzLAoKVGhhbmtzIGZvciB5b3Ugc3VwZXIgcXVpY2sgcmVzcG9uc2UgdG9vLgoK QmFzZWQgb24geW91ciBmZWVkYmFjaywgSSBhbSBsZWFuaW5nIHRvd2FyZHMgOgoKPiBVc2Ug dGhlIENvbW1pdG1lbnQgTWVzc2FnZSBhcyBhbiBhcHBsaWNhdGlvbiBsYXllciBwYXlsb2Fk IChlbmNyeXB0ZWQgCj4gYXMgaXQgc2hvdWxkIGJlKS4gKE5vdGUgdGhhdCB0aGlzIGhhcyBu b3RoaW5nIHRvIGRvIHdpdGggZWFybHkgZGF0YS4pIAo+IElmIHRoZSBPcGVuU1NMIHNwZWMg ZG9lcyBub3Qgc3VwcG9ydCBhbiBhcHBsaWNhdGlvbiBsYXllciBtZXNzYWdlIGZyb20gCj4g dGhlIHNlcnZlciByaWdodCBhZnRlciB0aGUgZmluaXNoIHRoZW4gaXQgaXMgbm90IGNvbXBs aWFudCB0byB0aGUgVExTIAo+IDEuMyBSRkMuIAoKSXQgd291bGQgYWxzbyByZXN1bHQgaW4g dGhlIHNtYWxsZXN0IGNoYW5nZSB0byB0aGUgY3VycmVudCAKc3BlY2lmaWNhdGlvbi4gT25s eSB0aGUgZGVzY3JpcHRpb24gb2YgaG93IHRoZSBjb21taXRtZW50IG1lc3NhZ2UgaXMgCmNv bnN0cnVjdGVkIG5lZWRzIHRvIGJlIGNoYW5nZWQuIEkgYWdyZWUgdGhhdCBzZW5kaW5nIGEg bm90aWZpY2F0aW9uIHRvIAphbiB1bmF1dGhlbnRpY2F0ZWQgcGVlciBpbiB0aGlzIGNhc2Ug aXMgZmluZS4KCkkgd29uZGVyIGhvdyBvdGhlcnMgZmVlbCBhYm91dCB0aGlzIGNoYW5nZS4K Ci0tTW9oaXQKCk9uIDYvMTYvMjAgMTo0MyBQTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6 Cj4KPiBIaSBNb2hpdCwKPgo+IFNlZSBiZWxvdy4gVGhhbmtzIGZvciB5b3VyIHN1cGVyIHF1 aWNrIHJlc3BvbnNlLgo+Cj4gKkZyb206KiBNb2hpdCBTZXRoaSBNIDxtb2hpdC5tLnNldGhp QGVyaWNzc29uLmNvbT4KPiAqU2VudDoqIFR1ZXNkYXksIEp1bmUgMTYsIDIwMjAgMTI6MjUg UE0KPiAqVG86KiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bT47IE1vaGl0IFNldGhpIE0gCj4gPG1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tPjsgZW11 QGlldGYub3JnCj4gKlN1YmplY3Q6KiBSZTogW0VtdV0gQ29tbWl0bWVudCBNZXNzYWdlIGlu IGRyYWZ0LWlldGYtZW11LWVhcC10bHMxMwo+Cj4gSGkgSGFubmVzLAo+Cj4gT24gNi8xNi8y MCAxMjozNyBQTSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6Cj4KPiAgICAgSGkgTW9oaXQs Cj4KPiAgICAgSSBoYWQgYSBjaGFuY2UgdG8gcmVhZCB0aHJvdWdoIHRoZSBlbWFpbHMgeW91 IHByb3ZpZGVkLiBBIGdvb2QKPiAgICAgZGlzY3Vzc2lvbi4KPgo+ICAgICBJIGNhbiBvZmZl ciB0aHJlZSBzb2x1dGlvbnM6Cj4KPiAgICAgIDEuIFVzZSBFQVAtU3VjY2VzcyAvIEVBUC1G YWlsdXJlIGFzIGFuIGluZGljYXRpb24gZm9yIHRoZQo+ICAgICAgICAgY29tcGxldGlvbiBv ZiB0aGUgZXhjaGFuZ2UsIGV2ZW4gaWYgaXQgaXMgbm90IGEgcmVsaWFibGUKPiAgICAgICAg IG5vdGlmaWNhdGlvbiBtZWNoYW5pc20uIElmIHRoZSBFQVAgcGVlciBkb2VzIG5vdCByZWNl aXZlIHRoZQo+ICAgICAgICAgTmV3U2Vzc2lvblRpY2tldCBtZXNzYWdlIHRoZW4gaXQgZG9l cyBub3QgbWF0dGVyIGJlY2F1c2UgaXQgaXMKPiAgICAgICAgIG9wdGlvbmFsIHRvIHVzZSBh bnl3YXkuIEl0IHdpbGwgYmUgYSBmYWlsdXJlIGNhc2UgYW55d2F5IGlmCj4gICAgICAgICB0 aGUgRUFQLVN1Y2Nlc3MgLyBFQVAtRmFpbHVyZSBnb3QgbG9zdC4gVGhleSBFQVAgcGVlciBt YXkgbm90Cj4gICAgICAgICBldmVuIGtub3cgd2hldGhlciB0aGUgZXhjaGFuZ2Ugd2FzIHN1 Y2Nlc3NmdWwgZGVzcGl0ZQo+ICAgICAgICAgY29ycmVjdGx5IHByb2Nlc3NpbmcgVExTIGhh bmRzaGFrZSBtZXNzYWdlcy4KPgo+IEkgYW0gdW5jb21mb3J0YWJsZSBkb2luZyB0aGlzIHdp dGhvdXQgdXBkYXRpbmcgUkZDIDM3NDguIE5vdCBvbmx5IHdpbGwgCj4gd2UgYmUgdmlvbGF0 aW5nIFJGQyAzNzQ4LCB3ZSB3b3VsZCBzdGlsbCBoYXZlIHRoZSBwcm9ibGVtIG9mIHBlZXIg Cj4gdW5jZXJ0YWludHkgYWJvdXQgdGhlIG5leHQgbWVzc2FnZS4gSXQgY291bGQgYmUgYSBO ZXdTZXNzaW9uVGlja2V0IG9yIAo+IEVBUC1TdWNjZXNzL0ZhaWx1cmUuCj4KPiBbSGFubmVz XSBXaGF0IGlzIGRvbmUgaW4gRUFQIHRvZGF5Pwo+Cj4gICAgICAyLiBEZW1hbmQgdGhhdCB0 aGUgTmV3U2Vzc2lvblRpY2tldCBpcyBzZW50IGltbWVkaWF0ZWx5IGFmdGVyIHRoZQo+ICAg ICAgICAgRmluaXNoZWQsIHZlcnkgbXVjaCBsaWtlIHlvdSBjdXJyZW50bHkgZGVtYW5kIHRo YXQgdGhlCj4gICAgICAgICBDb21taXRtZW50IE1lc3NhZ2UgaXMgYXR0YWNoZWQgdG8gdGhl IGxhc3QgbWVzc2FnZS4KPgo+IEkgYXNzdW1lIHRoYXQgeW91IGltcGx5IGltbWVkaWF0ZWx5 IGFmdGVyIHRoZSBzZXJ2ZXIgaGFzIHNlbnQgaXRzIFRMUyAKPiBGaW5pc2hlZCAoYW5kIG5v dCBhZnRlciB0aGUgc2VydmVyIGhhcyByZWNlaXZlZCB0aGUgVExTIEZpbmlzaGVkIGZyb20g Cj4gdGhlIHBlZXIpPyBBcmUgeW91IGFsc28gaW1wbHlpbmcgdGhhdCBhIE5ld1Nlc3Npb25U aWNrZXQgc2hvdWxkIGFsd2F5cyAKPiBiZSBzZW50IG91dCwgcmVnYXJkbGVzcyBvZiB3aGV0 aGVyIGEgc2VydmVyIHdhbnRzIG9yIHN1cHBvcnRzIAo+IHJlc3VtcHRpb24/IFdoYXQgaWYg dGhlIHNlcnZlciBpcyBpc3N1aW5nIHNldmVyYWwgdGlja2V0cz8KPgo+IFtIYW5uZXNdIEkg d291bGQgbGVhdmUgaXQgYXMgYW4gb3B0aW9uIHRvIHNlbmQgYSBOZXdTZXNzaW9uVGlja2V0 IGJ1dCAKPiBpdCBpcyBzZW50IHRoZW4gaXQgaGFzIHRvIGJlIGluIHRoZSBsYXN0IG1lc3Nh Z2UuIEhlcmUgaXMgdGhlIGV4Y2hhbmdlOgo+Cj4gQ2FzZSAxOiBOZXdTZXNzaW9uVGlja2V0 IE1lc3NhZ2UgU2VudAo+Cj4goKCgIEVBUCBQZWVyoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgIEVBUCBTZXJ2ZXIKPgo+IEVBUC1SZXF1ZXN0Lwo+Cj4g PC0tLS0tLS0toKCgoKCgoKCgoKCgoKCgoKAgSWRlbnRpdHkKPgo+IKCgoCBFQVAtUmVzcG9u c2UvCj4KPiCgoKAgSWRlbnRpdHkgKFByaXZhY3ktRnJpZW5kbHkpoCAtLS0tLS0tLT4KPgo+ IEVBUC1SZXF1ZXN0Lwo+Cj4goKCgoKCgoKCgRUFQLVR5cGU9RUFQLVRMUwo+Cj4gPC0tLS0t LS0toKCgoKCgoKCgoKCgoKCgIChUTFMgU3RhcnQpCj4KPiCgoKAgRUFQLVJlc3BvbnNlLwo+ Cj4goKCgIEVBUC1UeXBlPUVBUC1UTFMKPgo+IKCgIChUTFMgQ2xpZW50SGVsbG8poKCgoKCg oKCgoKCgIC0tLS0tLS0tPgo+Cj4gRUFQLVJlcXVlc3QvCj4KPiCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoEVBUC1UeXBlPUVBUC1UTFMKPgo+IChUTFMg U2VydmVySGVsbG8sCj4KPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoCBUTFMgRW5jcnlwdGVkRXh0ZW5zaW9ucywKPgo+IKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBUTFMgQ2VydGlmaWNhdGVSZXF1ZXN0LAo+ Cj4gVExTIENlcnRpZmljYXRlLAo+Cj4goFRMUyBDZXJ0aWZpY2F0ZVZlcmlmeSwKPgo+IDwt LS0tLS0tLaCgoKCgoKCgoKCgoKAgVExTIEZpbmlzaGVkLAo+Cj4goKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBUTFMgTmV3U2Vzc2lvblRpY2tldCkK Pgo+IKCgoCBFQVAtUmVzcG9uc2UvCj4KPiCgoKAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4goKAg KFRMUyBDZXJ0aWZpY2F0ZSwKPgo+IKCgoCBUTFMgQ2VydGlmaWNhdGVWZXJpZnksCj4KPiCg oKAgVExTIEZpbmlzaGVkKaCgoKCgoKCgoKCgoKCgoCAtLS0tLS0tLT4KPgo+IDwtLS0tLS0t LaCgoKCgoKCgoKCgoKCgIEVBUC1TdWNjZXNzCj4KPiBDYXNlIDI6IE5vIHRpY2tldCBzZW50 Cj4KPiCgoKAgRUFQIFBlZXKgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKAgRUFQIFNlcnZlcgo+Cj4goKCgoKCgRUFQLVJlcXVlc3QvCj4KPiA8LS0tLS0t LS2goKCgoKCgoKCgoKCgoKCgoCBJZGVudGl0eQo+Cj4goKCgIEVBUC1SZXNwb25zZS8KPgo+ IKCgoCBJZGVudGl0eSAoUHJpdmFjeS1GcmllbmRseSmgIC0tLS0tLS0tPgo+Cj4gRUFQLVJl cXVlc3QvCj4KPiCgoKCgoKCgoKCgoKCgoKBFQVAtVHlwZT1FQVAtVExTCj4KPiA8LS0tLS0t LS2goKCgoKCgoKCgoKCgoKAgKFRMUyBTdGFydCkKPgo+IKCgoCBFQVAtUmVzcG9uc2UvCj4K PiCgoKAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4goKAgKFRMUyBDbGllbnRIZWxsbymgoKCgoKCg oKCgoKAgLS0tLS0tLS0+Cj4KPiBFQVAtUmVxdWVzdC8KPgo+IEVBUC1UeXBlPUVBUC1UTFMK Pgo+IChUTFMgU2VydmVySGVsbG8sCj4KPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoCBUTFMgRW5jcnlwdGVkRXh0ZW5zaW9ucywKPgo+IKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBUTFMgQ2VydGlmaWNhdGVS ZXF1ZXN0LAo+Cj4gVExTIENlcnRpZmljYXRlLAo+Cj4gVExTIENlcnRpZmljYXRlVmVyaWZ5 LAo+Cj4goKCgoKCgoKCgoDwtLS0tLS0tLaCgoKCgoKCgoKCgoKAgVExTIEZpbmlzaGVkKQo+ Cj4goKCgoEVBUC1SZXNwb25zZS8KPgo+IKCgoCBFQVAtVHlwZT1FQVAtVExTCj4KPiCgoCAo VExTIENlcnRpZmljYXRlLAo+Cj4goKCgIFRMUyBDZXJ0aWZpY2F0ZVZlcmlmeSwKPgo+IKCg oCBUTFMgRmluaXNoZWQpoKCgoKCgoKCgoKCgoKCgIC0tLS0tLS0tPgo+Cj4gPC0tLS0tLS0t oKCgoKCgoKCgoKCgoKAgRUFQLVN1Y2Nlc3MKPgo+Cj4KPiAgICAgIDMuIFVzZSB0aGUgQ29t bWl0bWVudCBNZXNzYWdlIGFzIGFuIGFwcGxpY2F0aW9uIGxheWVyIHBheWxvYWQKPiAgICAg ICAgIChlbmNyeXB0ZWQgYXMgaXQgc2hvdWxkIGJlKS4gKE5vdGUgdGhhdCB0aGlzIGhhcyBu b3RoaW5nIHRvIGRvCj4gICAgICAgICB3aXRoIGVhcmx5IGRhdGEuKSBJZiB0aGUgT3BlblNT TCBzcGVjIGRvZXMgbm90IHN1cHBvcnQgYW4KPiAgICAgICAgIGFwcGxpY2F0aW9uIGxheWVy IG1lc3NhZ2UgZnJvbSB0aGUgc2VydmVyIHJpZ2h0IGFmdGVyIHRoZQo+ICAgICAgICAgZmlu aXNoIHRoZW4gaXQgaXMgbm90IGNvbXBsaWFudCB0byB0aGUgVExTIDEuMyBSRkMuCj4KPiBI b3cgd291bGQgdGhhdCB3b3JrPyBIb3cgY2FuIHNlcnZlciBzZW5kIGVuY3J5cHRlZCBhcHBs aWNhdGlvbiBsYXllciAKPiBwYXlsb2FkIHdpdGhvdXQgaGF2aW5nIHJlY2VpdmVkIHRoZSBU TFMgRmluaXNoZWQgZnJvbSB0aGUgcGVlci4KPgo+IFtIYW5uZXNdIEhlcmUgaXMgYSBjb3B5 LWFuZC1wYXN0ZSBmcm9tIHRoZSBUTFMgc3BlYzoKPgo+IENsaWVudKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBTZXJ2ZXIKPgo+IEtleaAgXiBDbGllbnRI ZWxsbwo+Cj4gRXhjaCB8ICsga2V5X3NoYXJlKgo+Cj4goKCgoCB8ICsgc2lnbmF0dXJlX2Fs Z29yaXRobXMqCj4KPiCgoKCgIHwgKyBwc2tfa2V5X2V4Y2hhbmdlX21vZGVzKgo+Cj4goKCg oCB2ICsgcHJlX3NoYXJlZF9rZXkqIC0tLS0tLS0tPgo+Cj4goKCgoKCgU2VydmVySGVsbG+g IF4gS2V5Cj4KPiArIGtleV9zaGFyZSqgIHwgRXhjaAo+Cj4gKyBwcmVfc2hhcmVkX2tleSqg IHYKPgo+IHtFbmNyeXB0ZWRFeHRlbnNpb25zfaAgXqAgU2VydmVyCj4KPiCgoKCgoKCgoKCg oKCgoKCgoHtDZXJ0aWZpY2F0ZVJlcXVlc3QqfaAgdqAgUGFyYW1zCj4KPiB7Q2VydGlmaWNh dGUqfaAgXgo+Cj4ge0NlcnRpZmljYXRlVmVyaWZ5Kn2gIHwgQXV0aAo+Cj4ge0ZpbmlzaGVk faAgdgo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoDwtLS0tLS0tLaAgW0FwcGxpY2F0 aW9uIERhdGEqXQo+Cj4goKCgoCBeIHtDZXJ0aWZpY2F0ZSp9Cj4KPiBBdXRoIHwge0NlcnRp ZmljYXRlVmVyaWZ5Kn0KPgo+IKCgoKAgdiB7RmluaXNoZWR9IC0tLS0tLS0tPgo+Cj4goKCg oKCgIFtBcHBsaWNhdGlvbiBEYXRhXSA8LS0tLS0tLT6gIFtBcHBsaWNhdGlvbiBEYXRhXQo+ Cj4gVGhlIFRMUyAxLjMgc3BlYyBzYXlzOgo+Cj4goKCgTm90ZSB0aGF0IHdoaWxlIHRoZQo+ Cj4goKAgc2VydmVyIG1heSBzZW5kIEFwcGxpY2F0aW9uIERhdGEgcHJpb3IgdG8gcmVjZWl2 aW5nIHRoZSBjbGllbnQncwo+Cj4goKAgQXV0aGVudGljYXRpb24gbWVzc2FnZXMsIGFueSBk YXRhIHNlbnQgYXQgdGhhdCBwb2ludCBpcywgb2YgY291cnNlLAo+Cj4goKAgYmVpbmcgc2Vu dCB0byBhbiB1bmF1dGhlbnRpY2F0ZWQgcGVlci4KPgo+IFRoZSBxdWVzdGlvbiBpcyB3aGV0 aGVyIHRoZSBhc3BlY3Qgb2Ygc2VuZGluZyBkYXRhIHRvIGFuIAo+IHVuYXV0aGVudGljYXRl ZCBwZWVyIG1hdHRlcnMgaW4gdGhpcyBjYXNlPyBJIHdvdWxkIGFyZ3VlIHRoYXQgaXQgZG9l cyAKPiBub3QgbWF0dGVyIGJlY2F1c2UgdGhlIGN1cnJlbnRseSBkZWZpbmVkIENvbW1pdG1l bnQgbWVzc2FnZSBpcyAKPiB1bmVuY3J5cHRlZC4KPgo+IFdoaWxlIEkgYW0gb3BlbiB0byBk aXNjdXNzaW5nIGJldHRlciBhbHRlcm5hdGl2ZXMsIEkgdGhpbmsgZnJvbSBhbiAKPiBpbXBs ZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSwgaXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSBhIGRlZmlu aXRlIAo+IG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gZm9yIHRoZSBzZXJ2ZXIgdG8gbm90aWZ5 IHRoZSBwZWVyIHRoYXQgbm8gbW9yZSAKPiBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBhcmUg dG8gYmUgZXhwZWN0ZWQuCj4KPiBbSGFubmVzXSBJIGFtIHRyeWluZyB0byBmaW5kIG91dCBo b3cgdG8gaW1wbGVtZW50IHRoaXMgZnVuY3Rpb25hbGl0eSAKPiBpbnRvIG91ciBzdGFjayBh bmQgaXQgbG9va3MgcGFpbmZ1bCAoZGV2ZWxvcGVyLXZpc2libGUgQVBJIGNoYW5nZXMpLiAK PiBPZiBjb3Vyc2UsIGl0IGlzIGRpZmZpY3VsdCB0byBhY2NvbW1vZGF0ZSBmb3Igbm90IHll dCBpbnZlbnRlZCAKPiBwb3N0LWhhbmRzaGFrZSBhdXRoZW50aWNhdGlvbiBtZXNzYWdlcy4g V2UgZG9uknQgZXZlbiBrbm93IHdoZXRoZXIgCj4gdGhleSB3aWxsIGJlIGNvbXBhdGlibGUg d2l0aCB0aGUgbmV0d29yayBhY2Nlc3MgYXV0aGVudGljYXRpb24gdXNlIGNhc2UuCj4KPiBD aWFvCj4KPiBIYW5uZXMKPgo+IFBTOiBJIGJlbGlldmUgaXQgd291bGQgYmUgZ29vZCB0byBo aWdobGlnaHQgdGhpcyBzcGVjaWZpYyBhc3BlY3QgaW4gCj4gdGhlIGludHJvZHVjdGlvbiBv ZiB0aGUgZG9jdW1lbnQuIEZvciBtZSBpdCBhcHBlYXJlZCB0aGF0IHRoZSAKPiBzcGVjaWZp Y2F0aW9uIGlzIGxhcmdlbHkgYSBjb3B5LWFuZC1wYXN0ZSBqb2IgYnV0IHRoaXMgY2xlYXJs eSBpcyAKPiBzb21ldGhpbmcgd29ydGggaGlnaGxpZ2h0aW5nIHRvIHRoZSByZWFkZXIvaW1w bGVtZW50ZXIuCj4KPiAtLU1vaGl0Cj4KPiAgICAgVGhlIGN1cnJlbnQgc29sdXRpb24gaW4g dGhlIGRyYWZ0LCBmb3IgZXhhbXBsZSwgZG9lcyBub3Qgd29yayB3aXRoCj4gICAgIE1iZWQg VExTIGJlY2F1c2UgeW91IGNhbm5vdCB0ZWxsIHRoZSBzdGFjayB0byBzdWRkZW5seSBieXBh c3MgdGhlCj4gICAgIGVuY3J5cHRpb24gbGF5ZXIgKGFmdGVyIHN1Y2Nlc3NmdWxseSBlc3Rh Ymxpc2hpbmcgaXQpIHRvIHNlbmQgYQo+ICAgICBwbGFpbnRleHQgbWVzc2FnZS4KPgo+ICAg ICBDaWFvCj4KPiAgICAgSGFubmVzCj4KPiAgICAgKkZyb206KiBNb2hpdCBTZXRoaSBNIDxt b2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbT4KPiAgICAgPG1haWx0bzptb2hpdC5tLnNldGhp QGVyaWNzc29uLmNvbT4KPiAgICAgKlNlbnQ6KiBNb25kYXksIEp1bmUgMTUsIDIwMjAgMzo1 MiBQTQo+ICAgICAqVG86KiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdA YXJtLmNvbT4KPiAgICAgPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPjsgZW11 QGlldGYub3JnIDxtYWlsdG86ZW11QGlldGYub3JnPgo+ICAgICAqU3ViamVjdDoqIFJlOiBb RW11XSBDb21taXRtZW50IE1lc3NhZ2UgaW4gZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzCj4K PiAgICAgSGkgSGFubmVzLAo+Cj4gICAgIFVuZm9ydHVuYXRlbHkgeW91IGFyZSB3cm9uZyBo ZXJlLiBUaGUgZGVzaWduIGRlY2lzaW9uIHdhcyBpbiBmYWN0Cj4gICAgIHRha2VuIHRvIGF2 b2lkIGNoYW5nZXMgdG8gdGhlIHVuZGVybHlpbmcgVExTIGltcGxlbWVudGF0aW9uIHdoaWxl Cj4gICAgIGFsc28gYXZvaWRpbmcgY2hhbmdlcyB0byBSRkMgMzc0OC4gVG8gc3VtbWFyaXpl Ogo+Cj4gICAgIEpvdW5pIE1hbGluZW4gcG9pbnRlZCBvdXQgdGhhdCBtYXBwaW5nIHNlc3Np b24gcmVzdW1wdGlvbiBvZiBUTFMKPiAgICAgMS4zIHRvIEVBUC1UTFMgaXMgbm9uLXRyaXZp YWwuIFNlZSBoaXMgZW1haWwgaGVyZToKPiAgICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9lbXUvU0JkYmxIbUxRVGJCd29aSEs4UmloLWc1bmU4Ly4KPiAgICAg RXNzZW50aWFsbHksIFRMUyAxLjMgYWxsb3dzIGEgc2VydmVyIHRvIHNlbmQgYSBQb3N0LUhh bmRzaGFrZQo+ICAgICBtZXNzYWdlIHdpdGggYSBOZXdTZXNzaW9uVGlja2V0IGF0IGFueSB0 aW1lLiBIb3dldmVyLCBpbiBFQVAtVExTCj4gICAgIHRoaXMgaXMgbm90IHBvc3NpYmxlLiBU aGUgVExTIHR1bm5lbCBpcyB0b3JuIGRvd24gYWZ0ZXIKPiAgICAgYXV0aGVudGljYXRpb24u IEpvaG4gbm90ZXMgaW4gaGlzIHJlc3BvbnNlIHRvIEpvdW5pCj4gICAgIChodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2VtdS9uTlV3NjFjVHZIZ1dqOEYwc09WUm9J Q1V6bGsvKQo+ICAgICAiaW4gVExTIHRoZSBjb25uZWN0aW9uIGlzIGFzc3VtZWQgdG8gc3Rh eSBvcGVuIGZvciBhIGxvbmcgdGltZQo+ICAgICBhZnRlciB0aGUgY2xpZW50IHNlbmRzIEZp bmlzaGVkLCBpbiBFQVAgdGhlIGNvbm5lY3Rpb24gaXMgYXNzdW1lZAo+ICAgICB0byBiZSBj bG9zZWQgc2hvcnRseSBhZnRlci4iCj4KPiAgICAgQW4gZWFybGllciBjbGVhbmVyIHdheSBv ZiBzZW5kaW5nIE5ld1Nlc3Npb25UaWNrZXQgcmVxdWlyZWQgYW4KPiAgICAgZXh0cmEgcm91 bmQgdHJpcCBhbmQgbGVmdCB0aGUgcGVlciB1bmNlcnRhaW4gYWJvdXQgdGhlIG5leHQKPiAg ICAgbWVzc2FnZQo+ICAgICAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZW11LWVhcC10bHMxMy0wMCNzZWN0aW9uLTIuMS4xKS4KPiAgICAgSm91bmkgaGlnaGxp Z2h0ZWQgdGhpcyB1bmNlcnRhaW50eSBmb3IgYSBwZWVyOiAiIHRoZSBwZWVyIGhhcyBubwo+ ICAgICBpZGVhIHdoZXRoZXIgdGhlIE5ld1Nlc3Npb25UaWNrZXQgaXMgZGVsaXZlcmVkIGFm dGVyCj4gICAgIENsaWVudEZpbmlzaGVkLiBJbiBvdGhlciB3b3JkcywgdGhlIG5leHQgbWVz c2FnZSBpbiB0aGUgc2VxdWVuY2UKPiAgICAgY291bGQgYmUgZWl0aGVyIGNvbnRpbnVhdGlv biBvZiBFQVAtVExTIG1ldGhvZCBvciBFQVAtU3VjY2VzcyIuCj4gICAgIFlvdSBhc2sgIndo eSBjYW5ub3QgdGhlIEVBUC1TdWNjZXNzIG9yIEVBUC1GYWlsdXJlIHNlcnZlIHRoYXQKPiAg ICAgcHVycG9zZT8iLiBTZWUgUkZDIDM3NDggKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmMzNzQ4KQo+ICAgICB3aGljaCBzYXlzIHRoZSBmb2xsb3dpbmc6Cj4KPiAgICAgICAg ICCgoCBJbXBsZW1lbnRhdGlvbiBOb3RlOiBCZWNhdXNlIHRoZSBTdWNjZXNzIGFuZCBGYWls dXJlIHBhY2tldHMgYXJlIG5vdAo+Cj4gICAgICAgICAgoKAgYWNrbm93bGVkZ2VkLCB0aGV5 IGFyZSBub3QgcmV0cmFuc21pdHRlZCBieSB0aGUgYXV0aGVudGljYXRvciwgYW5kCj4KPiAg ICAgICAgICCgoCBtYXkgYmUgcG90ZW50aWFsbHkgbG9zdC6gIEEgcGVlciBNVVNUIGFsbG93 IGZvciB0aGlzIGNpcmN1bXN0YW5jZSBhcwo+Cj4gICAgICAgICAgoKAgZGVzY3JpYmVkIGlu IHRoaXMgbm90ZS4KPgo+ICAgICBhbmQKPgo+ICAgICAgICAgIKBPbiB0aGUgcGVlciwgYWZ0 ZXIgc3VjY2VzcyByZXN1bHQgaW5kaWNhdGlvbnMgaGF2ZSBiZWVuIGV4Y2hhbmdlZCBieQo+ Cj4gICAgICAgICAgoKAgYm90aCBzaWRlcywgYSBGYWlsdXJlIHBhY2tldCBNVVNUIGJlIHNp bGVudGx5IGRpc2NhcmRlZC6gIFRoZSBwZWVyCj4KPiAgICAgICAgICCgoCBNQVksIGluIHRo ZSBldmVudCB0aGF0IGFuIEVBUCBTdWNjZXNzIGlzIG5vdCByZWNlaXZlZCwgY29uY2x1ZGUg dGhhdAo+Cj4gICAgICAgICAgoKAgdGhlIEVBUCBTdWNjZXNzIHBhY2tldCB3YXMgbG9zdCBh bmQgdGhhdCBhdXRoZW50aWNhdGlvbiBjb25jbHVkZWQKPgo+ICAgICAgICAgIKCgIHN1Y2Nl c3NmdWxseS4KPgo+Cj4gICAgIFRodXMsIEVBUC1TdWNjZXNzIGNhbm5vdCBiZSB1c2VkIGFz IGEgcmVsaWFibGUgbm90aWZpY2F0aW9uCj4gICAgIG1lY2hhbmlzbS4gVGlsbCB2ZXJzaW9u IDA1IG9mIHRoZSBkb2N1bWVudCwgd2UgdXNlZCBhbiBlbXB0eQo+ICAgICBhcHBsaWNhdGlv biBkYXRhIHJlY29yZCBhcyBhIG5vdGlmaWNhdGlvbiBvZiB0aGUgbGFzdCBoYW5kc2hha2UK PiAgICAgbWVzc2FnZS4gVGhlIHRleHQgc2FpZDoKPgo+ICAgICAgICAgV2hlbiBhbiBFQVAg c2VydmVyIGhhcyBzZW50IGl0cyBsYXN0IGhhbmRzaGFrZSBtZXNzYWdlIChGaW5pc2hlZCBv ciBhCj4KPiAgICAgICAgICCgoCBQb3N0LUhhbmRzaGFrZSksIGl0IGNvbW1pdHMgdG8gbm90 IHNlbmRpbmcgYW55IG1vcmUgaGFuZHNoYWtlCj4KPiAgICAgICAgICCgoCBtZXNzYWdlcyBi eSBhcHBlbmRpbmcgYW4gZW1wdHkgYXBwbGljYXRpb24gZGF0YSByZWNvcmQgKGkuLmUuIGEg VExTCj4KPiAgICAgICAgICCgoCByZWNvcmQgd2l0aCBUTFNQbGFpbnRleHQudHlwZSA9IGFw cGxpY2F0aW9uX2RhdGEgYW5kCj4KPiAgICAgICAgICCgoCBUTFNQbGFpbnRleHQubGVuZ3Ro ID0gMCkgdG8gdGhlIGxhc3QgaGFuZHNoYWtlIHJlY29yZC6gIEFmdGVyIHNlbmRpbmcKPgo+ ICAgICAgICAgIKCgIGFuIGVtcHR5IGFwcGxpY2F0aW9uIGRhdGEgcmVjb3JkLCB0aGUgRUFQ IHNlcnZlciBtYXkgb25seSBzZW5kIGFuCj4KPiAgICAgICAgICCgoCBFQVAtU3VjY2Vzcywg YW4gRUFQLUZhaWx1cmUsIG9yIGFuIEVBUC1SZXF1ZXN0IHdpdGggYSBUTFMgQWxlcnQKPgo+ ICAgICAgICAgIKCgIE1lc3NhZ2UuCj4KPiAgICAgSG93ZXZlciwgSm91bmkgaW4gYSBsYXRl ciByZXNwb25zZQo+ICAgICAoaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21z Zy9lbXUvV0E4T1JFaFRzRjhKRVB2YWl4R29Dd21kMXFZLykKPiAgICAgbm90ZWQgdGhhdCBz dWNoIGJlaGF2aW9yIGlzIG5vbi10cml2aWFsIHRvIGFjaGlldmUgd2l0aCBPcGVuU1NMLgo+ ICAgICBIZSBub3RlcyAiIE9wZW5TU0wgaXMgbm90IHdpbGxpbmcgdG8gc2VuZCBzdWNoIGFu IGVtcHR5Cj4gICAgIFRMU1BsYWludGV4dCBzdHJ1Y3R1cmUuIFNTTF93cml0ZSgpIGhhcyBm b2xsb3dpbmcgdG8gc2F5IDogJ1lvdQo+ICAgICBzaG91bGQgbm90IGNhbGwgU1NMX3dyaXRl KCkgd2l0aCBudW09MCwgaXQgd2lsbCByZXR1cm4gYW4gZXJyb3IuCj4gICAgIFNTTF93cml0 ZV9leCgpIGNhbiBiZSBjYWxsZWQgd2l0aCBudW09MCwgYnV0IHdpbGwgbm90IHNlbmQKPiAg ICAgYXBwbGljYXRpb24gZGF0YSB0byB0aGUgcGVlci4nIgo+Cj4gICAgIFRoZXJlZm9yZSwg dGhlIHRleHQgd2FzIGxhdGVyIHVwZGF0ZWQgdG86Cj4KPiAgICAgICAgICAgV2hlbiBhbiBF QVAgc2VydmVyIGhhcyBzZW50IGl0cyBsYXN0IGhhbmRzaGFrZSBtZXNzYWdlIChGaW5pc2hl ZCBvciBhCj4KPiAgICAgICAgICCgoCBQb3N0LUhhbmRzaGFrZSksIGl0IGNvbW1pdHMgdG8g bm90IHNlbmRpbmcgYW55IG1vcmUgaGFuZHNoYWtlCj4KPiAgICAgICAgICCgoCBtZXNzYWdl cyBieSBzZW5kaW5nIGEgQ29tbWl0bWVudCBNZXNzYWdlLqAgVGhlIENvbW1pdG1lbnQgTWVz c2FnZSBpcwo+Cj4gICAgICAgICAgoKAgYSBUTFMgcmVjb3JkIHdpdGggYXBwbGljYXRpb24g ZGF0YSAweDAwIChpLmUuIGEgVExTIHJlY29yZCB3aXRoCj4KPiAgICAgICAgICCgoCBUTFNQ bGFpbnRleHQudHlwZSA9IGFwcGxpY2F0aW9uX2RhdGEsIFRMU1BsYWludGV4dC5sZW5ndGgg PSAxLCBhbmQKPgo+ICAgICAgICAgIKCgIFRMU1BsYWludGV4dC5mcmFnbWVudCA9IDB4MDAp LqAgTm90ZSB0aGF0IHRoZSBsZW5ndGggb2YgdGhlIHBsYWludGV4dAo+Cj4gICAgICAgICAg oKAgaXMgZ3JlYXRlciB0aGFuIHRoZSBjb3JyZXNwb25kaW5nIFRMU1BsYWludGV4dC5sZW5n dGggZHVlIHRvIHRoZQo+Cj4gICAgICAgICAgoKAgaW5jbHVzaW9uIG9mIFRMU0lubmVyUGxh aW50ZXh0LnR5cGUgYW5kIGFueSBwYWRkaW5nIHN1cHBsaWVkIGJ5IHRoZQo+Cj4gICAgICAg ICAgoKAgc2VuZGVyLqAgRUFQIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzZXQgVExT UGxhaW50ZXh0LmZyYWdtZW50IHRvCj4KPiAgICAgICAgICCgoCAweDAwLCBidXQgRUFQIHBl ZXIgaW1wbGVtZW50YXRpb25zIE1VU1QgYWNjZXB0IGFueSBhcHBsaWNhdGlvbiBkYXRhCj4K PiAgICAgICAgICCgoCBhcyBhIENvbW1pdG1lbnQgTWVzc2FnZSBmcm9tIHRoZSBFQVAgc2Vy dmVyIHRvIG5vdCBzZW5kIGFueSBtb3JlIGhhbmRzaGFrZSBtZXNzYWdlcy4KPgo+ICAgICBU aGVyZSBpcyBzdGlsbCBhIGNoYWxsZW5nZSBpbiBzY2VuYXJpb3Mgd2hlcmUgYSBzZXJ2ZXIg Y2hvb3NlcyBub3QKPiAgICAgdG8gaXNzdWUgYW55IE5ld1Nlc3Npb25UaWNrZXQuIEluIHRo aXMgZW1haWw6Cj4gICAgIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv ZW11L1BnR2pobWFmYmJTSkNjUWN0RHNGdzdBdk5tVS8KPiAgICAgSm91bmkgbm90ZXMgdGhp cyBwcm9ibGVtOgo+Cj4gICAgICAgICBJIGRpZCBzZWUgc29tZSBpc3N1ZXMgd2hlbiBPcGVu U1NMIDEuMS4xIHdoZW4gZGlzYWJsaW5nIHNlbmRpbmcgb2YKPgo+ICAgICAgICAgc2Vzc2lv biB0aWNrZXRzLCB0aG91Z2guIFRoZSBjdXJyZW50IGRyYWZ0IGluZGljYXRlcyB0aGF0IHRo ZSBlbXB0eQo+Cj4gICAgICAgICBBcHBsaWNhdGlvbiBEYXRhIHBheWxvYWQgd291bGQgYmUg c2VuZCBvdXQgaW4gdGhlIHNhbWUgRUFQIHBhY2tldCB3aXRoCj4KPiAgICAgICAgIHRoZSBz ZXJ2ZXIncyBGaW5pc2hlZCBtZXNzYWdlLCBpLmUuLCBiZWZvcmUgdGhlIHNlcnZlciBoYXZp bmcKPgo+ICAgICAgICAgYXV0aGVudGljYXRlZCB0aGUgcGVlci4gQW5kIHRoaXMgd291bGQg YmUgZG9uZSB3aXRob3V0IHRoZSBwZWVyIGhhdmluZwo+Cj4gICAgICAgICB1c2VkIFRMUyBl YXJseSBkYXRhICh3aGljaCBpcyBleHBsaWNpdGx5IGRpc2FsbG93ZWQgaW4gdGhlIGRyYWZ0 KS4gVGhhdAo+Cj4gICAgICAgICBjb21iaW5hdGlvbiBkaWQgbm90IHdvcmsgd2l0aCBteSBl eHBlcmltZW50cyBzaW5jZSBPcGVuU1NMIHdhcyByZWplY3RpbmcKPgo+ICAgICAgICAgdGhl IFNTTF93cml0ZSgpIG9wZXJhdGlvbiBhZnRlciB0aGUgc2VydmVyIGhhdmluZyB3cml0dGVu IG93biBGaW5pc2hlZAo+Cj4gICAgICAgICBtZXNzYWdlLCBidXQgYmVmb3JlIGhhdmluZyBy ZWNlaXZlZCB0aGUgRmluaXNoZWQgbWVzc2FnZSBmcm9tIHRoZSBwZWVyLi4KPgo+ICAgICAg ICAgVGhlIE9wZW5TU0wgZG9jdW1lbnRhdGlvbiBzZWVtZWQgdG8gaW1wbHkgdGhhdCBTU0xf d3JpdGVfZWFybHlfZGF0YSgpCj4KPiAgICAgICAgIGNvdWxkIGJlIHVzZWQgYnkgdGhlIHNl cnZlciBfaWZfIHRoZSBjbGllbnQgZmlyc3Qgc2VudCBlYXJseSBkYXRhLi4gQXQKPgo+ICAg ICAgICAgbGVhc3QgaW4gbXkgdGVzdHMsIE9wZW5TU0wgcmVqZWN0ZWQgdGhhdCBjYWxsIHdp dGhvdXQgZWFybHkgZGF0YSBmcm9tCj4KPiAgICAgICAgIHRoZSBjbGllbnQuCj4KPiAgICAg VGhpcyBpcyB3aHkgdGhlIGN1cnJlbnQgdGV4dCBhbHNvIHNheXMgdGhlIGZvbGxvd2luZzoK Pgo+ICAgICAgICAgICBUaGUgQ29tbWl0bWVudCBNZXNzYWdlIG1heSBiZSBzZW50IGluIHRo ZSBzYW1lCj4KPiAgICAgICAgICCgoCBFQVAtUmVxdWVzdCBhcyB0aGUgbGFzdCBoYW5kc2hh a2UgcmVjb3JkIG9yIGluIGEgc2VwYXJhdGUgRUFQLQo+Cj4gICAgICAgICAgoKAgUmVxdWVz dC6gIFNlbmRpbmcgdGhlIENvbW1pdG1lbnQgTWVzc2FnZSBpbiBhIHNlcGFyYXRlIEVBUC1S ZXF1ZXN0Cj4KPiAgICAgICAgICCgoCBhZGRzIGFuIGFkZGl0aW9uYWwgcm91bmQtdHJpcCwg YnV0IG1heSBiZSBuZWNlc3NhcnkgaW4gVExTCj4KPiAgICAgICAgICCgoCBpbXBsZW1lbnRh dGlvbnMgdGhhdCBvbmx5IGltcGxlbWVudCBhIHN1YnNldCBvZiBUTFMgMS4zLqAgSW4gdGhl IGNhc2UKPgo+ICAgICAgICAgIKCgIHdoZXJlIHRoZSBzZXJ2ZXIgc2VuZHMgdGhlIENvbW1p dG1lbnQgTWVzc2FnZSBpbiBhIHNlcGFyYXRlIEVBUC0KPgo+ICAgICAgICAgIKCgIFJlcXVl c3QsIHRoZSBjb252ZXJzYXRpb24gd2lsbCBhcHBlYXIgYXMgc2hvd24gaW4gRmlndXJlIDku oCBBZnRlcgo+Cj4gICAgICAgICAgoKAgc2VuZGluZyB0aGUgQ29tbWl0bWVudCBNZXNzYWdl LCB0aGUgRUFQIHNlcnZlciBtYXkgb25seSBzZW5kIGFuIEVBUC0KPgo+ICAgICAgICAgIKCg IFN1Y2Nlc3MsIGFuIEVBUC1GYWlsdXJlLCBvciBhbiBFQVAtUmVxdWVzdCB3aXRoIGEgVExT IEFsZXJ0IE1lc3NhZ2UuCj4KPiAgICAgVGh1cywgdGhlIGN1cnJlbnQgZGVzaWduIGRlY2lz aW9uIGhhcyBiZWVuIGd1aWRlZCBieSBwYXJhbGxlbAo+ICAgICBpbXBsZW1lbnRhdGlvbiBl eHBlcmllbmNlIGFuZCBpdCBpcyB0aGUgYmVzdCBzb2x1dGlvbiB3ZSBjb3VsZAo+ICAgICBj b21lIHVwIHdpdGggKGdpdmVuIGFsbCB0aGUgcHJhY3RpY2FsIGxpbWl0YXRpb25zKS4KPgo+ ICAgICAtLU1vaGl0Cj4KPiAgICAgT24gNi8xMi8yMCAxMTozNiBBTSwgSGFubmVzIFRzY2hv ZmVuaWcgd3JvdGU6Cj4KPiAgICAgICAgIEhpIGFsbCwKPgo+ICAgICAgICAgVGhpcyBoYXMg cHJvYmFibHkgYmVlbiBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIEVNVSBncm91cC4K PiAgICAgICAgIEkgYW0gc29ycnkgdG8gYnJpbmcgaXQgdXAgYWdhaW4gYnV0IEkgYmVsaWV2 ZSB0aGlzIGlzIGEgYmFkCj4gICAgICAgICBkZXNpZ24gZGVjaXNpb24uIEkgcmFpc2VkIGl0 IGluIG15IHNob3J0IHJldmlldyBqdXN0IHNlbnQgdG8KPiAgICAgICAgIHRoZSBsaXN0IGJ1 dCBJIGJlbGlldmUgaXQgaXMgd29ydGh3aGlsZSB0byBwb2ludCBpdCBvdXQKPiAgICAgICAg IHNlcGFyYXRlbHkuCj4KPiAgICAgICAgIGRyYWZ0LWlldGYtZW11LWVhcC10bHMxMyBpbnRy b2R1Y2VzIGEgbmV3IG1lc3NhZ2UgdG8gRUFQLVRMUywKPiAgICAgICAgIG5hbWVseSB0aGUg Q29tbWl0bWVudCBNZXNzYWdlLiBUaGlzIHJlcXVpcmVzIGV4dHJhIGNvZGUgaW4gYW4KPiAg ICAgICAgIGltcGxlbWVudGF0aW9uIGJlY2F1c2UgdGhlIG5vcm1hbCBiZWhhdmlvciB3b3Vs ZCBiZSB0byBydW4gYQo+ICAgICAgICAgVExTIHN0YWNrIGFuZCB0aGVuIHNlbmQgZW5jcnlw dGVkIGRhdGEuCj4KPiAgICAgICAgIEVBUC1UTFMgZG9lcywgaG93ZXZlciwgbm90IHNlbmQg YXBwbGljYXRpb24gZGF0YSouIFRoaXMKPiAgICAgICAgIG1lc3NhZ2UgY2hhbmdlcyB0aGlz LiBOb3Qgb25seSBkb2VzIGl0IG5vdCBzZW5kIGVuY3J5cHRlZAo+ICAgICAgICAgYXBwbGlj YXRpb24gZGF0YSBpdCByZXF1aXJlcyBhbiBpbXBsZW1lbnRhdGlvbiB0byB0cmFuc21pdCBh Cj4gICAgICAgICBwbGFpbnRleHQgYXBwbGljYXRpb24gZGF0YSByZWNvcmQgYWZ0ZXIgdGhl IGFwcGxpY2F0aW9uCj4gICAgICAgICB0cmFmZmljIHNlY3JldCBoYXMgYmVlbiBjcmVhdGVk IGFuZCBiZWZvcmUgdGhhdCBhcHBsaWNhdGlvbgo+ICAgICAgICAgdHJhZmZpYyBzZWNyZXQg aXMgdXNlZCB0byBwcm90ZWN0IHBvc3QgaGFuZHNoYWtlIG1lc3NhZ2VzLgo+ICAgICAgICAg VGhpcyB3aWxsIG1ha2UgaXQgZGlmZmljdWx0IHRvIHJlLXVzZSBhbiBvZmYtdGhlLXNoZWxm IFRMUyAxLjMKPiAgICAgICAgIHN0YWNrLgo+Cj4gICAgICAgICBUaGVyZSBpcyB2ZXJ5IGxp dHRsZSBtb3RpdmF0aW9uIGFib3V0IHRoaXMgbWVzc2FnZSBvdGhlciB0aGFuCj4KPiAgICAg ICAgICAgCj4KPiAgICAgICAgIJMKPgo+ICAgICAgICAgoKAgV2hlbiBhbiBFQVAgc2VydmVy IGhhcyBzZW50IGl0cyBsYXN0IGhhbmRzaGFrZSBtZXNzYWdlCj4gICAgICAgICAoRmluaXNo ZWQgb3IgYQo+Cj4gICAgICAgICCgoCBQb3N0LUhhbmRzaGFrZSksIGl0IGNvbW1pdHMgdG8g bm90IHNlbmRpbmcgYW55IG1vcmUgaGFuZHNoYWtlCj4KPiAgICAgICAgIKCgIG1lc3NhZ2Vz IGJ5IHNlbmRpbmcgYSBDb21taXRtZW50IE1lc3NhZ2UuCj4KPiAgICAgICAgIJMKPgo+ICAg ICAgICAgSSBtaWdodCBtaXNzIHNvbWV0aGluZyBpbXBvcnRhbnQgaGVyZSBidXQgd2h5IGNh bm5vdCB0aGUKPiAgICAgICAgIEVBUC1TdWNjZXNzIG9yIEVBUC1GYWlsdXJlIHNlcnZlIHRo YXQgcHVycG9zZT8KPgo+ICAgICAgICAgSGVyZSBhcmUgdHdvIGV4YW1wbGVzIHRvIGV4cGxh aW4gd2hhdCBJIG1lYW46Cj4KPiAgICAgICAgICAxLiBGYWlsZWQgZXhjaGFuZ2UKPgo+ICAg ICAgICAgoKCgIEVBUCBQZWVyoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgIEVBUAo+ICAgICAgICAgU2VydmVyCj4KPiAgICAgICAgIKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgCj4gICAgICAg ICBFQVAtUmVxdWVzdC8KPgo+ICAgICAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKAgPC0tLS0tLS0toKCgoKCgoKCgoKCgoKCgoKAKPiAgICAgICAgIElkZW50aXR5Cj4K PiAgICAgICAgIKCgoCBFQVAtUmVzcG9uc2UvCj4KPiAgICAgICAgIKCgoCBJZGVudGl0eSAo UHJpdmFjeS1GcmllbmRseSmgIC0tLS0tLS0tPgo+Cj4gICAgICAgICCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoAo+ICAgICAgICAg RUFQLVJlcXVlc3QvCj4KPiAgICAgICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoAo+ICAgICAgICAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4g ICAgICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA8LS0tLS0tLS2goKCg oKCgoKCgoKCgoKAgKFRMUwo+ICAgICAgICAgU3RhcnQpCj4KPiAgICAgICAgIKCgoCBFQVAt UmVzcG9uc2UvCj4KPiAgICAgICAgIKCgoCBFQVAtVHlwZT1FQVAtVExTCj4KPiAgICAgICAg IKCgIChUTFMgQ2xpZW50SGVsbG8poKCgoKCgoKCgoKCgIC0tLS0tLS0tPgo+Cj4gICAgICAg ICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoAo+ICAgICAgICAgRUFQLVJlcXVlc3QvCj4KPiAgICAgICAgIKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoAo+ICAgICAgICAgRUFQLVR5 cGU9RUFQLVRMUwo+Cj4gICAgICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoCCgoKCgoKCgoKCgKFRMUwo+ICAgICAgICAgU2VydmVySGVsbG8sCj4KPiAg ICAgICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIFRM Uwo+ICAgICAgICAgRW5jcnlwdGVkRXh0ZW5zaW9ucywKPgo+ICAgICAgICAgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIFRMUwo+ICAgICAgICAgQ2Vy dGlmaWNhdGVSZXF1ZXN0LAo+Cj4gICAgICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIFRMUwo+ICAgICAgICAgQ2VydGlmaWNhdGUs Cj4KPiAgICAgICAgIKCgoKCgoKCgoKCgoKCgoKCgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgVExTCj4gICAgICAgICBDZXJ0aWZpY2F0ZVZlcmlmeSwKPgo+ICAgICAgICAgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBU TFMKPiAgICAgICAgIEZpbmlzaGVkLAo+Cj4gICAgICAgICCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoCA8LS0tLS0tLS0gQ29tbWl0bWVudCBNZXNzYWdlKQo+Cj4gICAgICAg ICCgoKAgRUFQLVJlc3BvbnNlLwo+Cj4gICAgICAgICCgoKAgRUFQLVR5cGU9RUFQLVRMUwo+ Cj4gICAgICAgICCgoCAoVExTIENlcnRpZmljYXRlLAo+Cj4gICAgICAgICCgoKAgVExTIENl cnRpZmljYXRlVmVyaWZ5LAo+Cj4gICAgICAgICCgoKAgVExTIEZpbmlzaGVkKaCgoKCgoKCg oKCgoKCgoCAtLS0tLS0tLT4KPgo+ICAgICAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAKPiAgICAgICAgIEVBUC1SZXF1ZXN0 Lwo+Cj4gICAgICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKAKPiAgICAgICAgIEVBUC1UeXBlPUVBUC1UTFMKPgo+ICAgICAgICAgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgPC0tLS0tLS0toKCgoKCgoCCgoChUTFMg RmF0YWwKPiAgICAgICAgIEFsZXJ0KQo+Cj4gICAgICAgICCgoKAgRUFQLVJlc3BvbnNlLwo+ Cj4gICAgICAgICCgoKAgRUFQLVR5cGU9RUFQLVRMU6CgoKCgoKCgoKCgoCAtLS0tLS0tLT4K Pgo+ICAgICAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgPC0tLS0tLS0t IEVBUC1GYWlsdXJlCj4KPiAgICAgICAgICAyLiBTdWNjZXNzZnVsIEV4Y2hhbmdlIHdpdGgg UG9zdC1IYW5kc2hha2UgTmV3U2Vzc2lvbiBUaWNrZXQKPgo+ICAgICAgICAgoKCgIEVBUCBQ ZWVyoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIEVBUAo+ ICAgICAgICAgU2VydmVyCj4KPiAgICAgICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgCj4gICAgICAgICBFQVAtUmVxdWVzdC8K Pgo+ICAgICAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgPC0tLS0tLS0t oKCgoKCgoKCgoKCgoKCgoKAKPiAgICAgICAgIElkZW50aXR5Cj4KPiAgICAgICAgIKCgoCBF QVAtUmVzcG9uc2UvCj4KPiAgICAgICAgIKCgoCBJZGVudGl0eSAoUHJpdmFjeS1GcmllbmRs eSmgIC0tLS0tLS0tPgo+Cj4gICAgICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoAo+ICAgICAgICAgRUFQLVJlcXVlc3QvCj4K PiAgICAgICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoAo+ICAgICAgICAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4gICAgICAgICCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA8LS0tLS0tLS2goKCgoKCgoKCgoKCgoKAgKFRM Uwo+ICAgICAgICAgU3RhcnQpCj4KPiAgICAgICAgIKCgoCBFQVAtUmVzcG9uc2UvCj4KPiAg ICAgICAgIKCgoCBFQVAtVHlwZT1FQVAtVExTCj4KPiAgICAgICAgIKCgIChUTFMgQ2xpZW50 SGVsbG8poKCgoKCgoKCgoKCgIC0tLS0tLS0tPgo+Cj4gICAgICAgICCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoAo+ICAgICAgICAg RUFQLVJlcXVlc3QvCj4KPiAgICAgICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoAo+ICAgICAgICAgRUFQLVR5cGU9RUFQLVRMUwo+Cj4g ICAgICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgoKCg oKCgoKCgKFRMUwo+ICAgICAgICAgU2VydmVySGVsbG8sCj4KPiAgICAgICAgIKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIFRMUwo+ICAgICAgICAgRW5j cnlwdGVkRXh0ZW5zaW9ucywKPgo+ICAgICAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgIFRMUwo+ICAgICAgICAgQ2VydGlmaWNhdGVSZXF1ZXN0 LAo+Cj4gICAgICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgIFRMUwo+ICAgICAgICAgQ2VydGlmaWNhdGUsCj4KPiAgICAgICAgIKCg oKCgoKCgoKCgoKCgoKCgoCCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgVExTCj4gICAg ICAgICBDZXJ0aWZpY2F0ZVZlcmlmeSwKPgo+ICAgICAgICAgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKAgPC0tLS0tLS0toKCgoKCgoKCgoKCgoCBUTFMKPiAgICAgICAgIEZp bmlzaGVkKQo+Cj4gICAgICAgICCgoKAgRUFQLVJlc3BvbnNlLwo+Cj4gICAgICAgICCgoKAg RUFQLVR5cGU9RUFQLVRMUwo+Cj4gICAgICAgICCgoCAoVExTIENlcnRpZmljYXRlLAo+Cj4g ICAgICAgICCgoKAgVExTIENlcnRpZmljYXRlVmVyaWZ5LAo+Cj4gICAgICAgICCgoKAgVExT IEZpbmlzaGVkKaCgoKCgoKCgoKCgoKCgoCAtLS0tLS0tLT4KPgo+ICAgICAgICAgoKCgoAo+ ICAgICAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoEVBUC1SZXF1ZXN0Lwo+Cj4gICAgICAgICCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAKPiAgICAgICAgIEVBUC1UeXBlPUVBUC1U TFMKPgo+ICAgICAgICAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoCAoVExTCj4gICAgICAgICBOZXdTZXNzaW9uVGlja2V0LAo+Cj4gICAgICAgICCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA8LS0tLS0tLS0gQ29tbWl0bWVudCBN ZXNzYWdlKQo+Cj4gICAgICAgICCgoKAgRUFQLVJlc3BvbnNlLwo+Cj4gICAgICAgICCgoKAg RUFQLVR5cGU9RUFQLVRMU6CgoKCgoKCgoKCgoCAtLS0tLS0tLT4KPgo+ICAgICAgICAgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgPC0tLS0tLS0tIEVBUC1TdWNjZXNzCj4K PiAgICAgICAgIENpYW8KPgo+ICAgICAgICAgSGFubmVzCj4KPiAgICAgICAgICgqKTogRldJ VyBQb3N0IGhhbmRzaGFrZSBtZXNzYWdlcyBhcmUgcHJvdGVjdGVkIHdpdGggdGhlCj4gICAg ICAgICBhcHBsaWNhdGlvbiB0cmFmZmljIHNlY3JldHMuCj4KPiAgICAgICAgIElNUE9SVEFO VCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkKPiAgICAgICAg IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn ZWQuIElmCj4gICAgICAgICB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIKPiAgICAgICAgIGltbWVkaWF0ZWx5IGFuZCBkbyBu b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlcgo+ICAgICAgICAgcGVyc29u LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZQo+ICAgICAg ICAgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lgo+Cj4KPiAgICAgICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4KPiAg ICAgICAgIEVtdSBtYWlsaW5nIGxpc3QKPgo+ICAgICAgICAgRW11QGlldGYub3JnICA8bWFp bHRvOkVtdUBpZXRmLm9yZz4KPgo+ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL21h aWxtYW4vbGlzdGluZm8vZW11ICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lbXU+Cj4KPiAgICAgSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cwo+ICAgICBhcmUgY29uZmlkZW50aWFsIGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUKPiAgICAgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvCj4gICAgIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkKPiAgICAgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0 aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lgo+Cj4gICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4KPiAgICAgRW11 IG1haWxpbmcgbGlzdAo+Cj4gICAgIEVtdUBpZXRmLm9yZyAgPG1haWx0bzpFbXVAaWV0Zi5v cmc+Cj4KPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXUK Pgo+IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIAo+IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIAo+IHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2Ug Cj4gdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIAo+IGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRp dW0uIFRoYW5rIHlvdS4gCg== --------------567CEC60B3BFC0097A8E56E5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Hannes,

Thanks for you super quick response too.

Based on your feedback, I am leaning towards :

Use the Commitment Message as an application layer payload (encrypted as it should be). (Note that this has nothing to do with early data.) If the OpenSSL spec does not support an application layer message from the server right after the finish then it is not compliant to the TLS 1.3 RFC.

It would also result in the smallest change to the current specification. Only the description of how the commitment message is constructed needs to be changed. I agree that sending a notification to an unauthenticated peer in this case is fine.

I wonder how others feel about this change.

--Mohit

On 6/16/20 1:43 PM, Hannes Tschofenig wrote:

Hi Mohit,

=A0

See below. Thanks for your super quick response.

=A0

=A0

From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
Sent: Tuesday, June 16, 2020 12:25 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Mohit Sethi M <mohit.m.sethi@ericsson.com>; emu@ietf.org
= Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

=A0

Hi Hannes,

On 6/16/20 12:37 PM, Hannes Tschofenig wrote:

Hi Mohit,

=A0

I had a chance to read through the email= s you provided. A good discussion.

=A0

I can offer three solutions: =

=A0

  1. Use EAP-Success / EAP-Failure as an indication for the completion of the exchange, even if it is not a reliable notification mechanism. If the EAP peer does not receive the NewSessionTicket message then it does not matter because it is optional to use anyway. It will be a failure case anyway if the EAP-Success / EAP-Failure got lost. They EAP peer may not even know whether the exchange was successful despite correctly processing TLS handshake messages.

I am uncomfortable doing this without updating RFC 3748. Not only will we be violating RFC 3748, we would still have the problem of peer uncertainty about the next message. It could be a NewSessionTicket or EAP-Success/Failure.

[Hannes] What is done in EAP today? <= /o:p>

=A0

  1. Demand that the NewSessionTicket is sent immediately after the Finished, very much like you currently demand that the Commitment Message is attached to the last message.

=A0

I assume that you imply immediately after the server has sent its TLS Finished (and not after the server has received the TLS Finished from the peer)? Are you also implying that a NewSessionTicket should always be sent out, regardless of whether a server wants or supports resumption? What if the server is issuing several tickets?

=A0

[Hannes] I would leave it as an option to send a NewSessionTicket but it is sent then it has to be in the last message. Here is the exchange:

=A0

Case 1: NewSessionTicket Message Sent

=A0

=A0=A0=A0 EAP Peer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 EAP Server

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Request/

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Identity

=A0=A0=A0 EAP-Response/

=A0=A0=A0 Identity (Privacy-Friendly)=A0 --------&= gt;

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Request/

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0EAP-Type=3DEAP-TLS

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (TL= S Start)

=A0=A0=A0 EAP-Response/

=A0=A0=A0 EAP-Type=3DEAP-TLS

=

=A0=A0 (TLS ClientHello)=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 -------->

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Request/

=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0EAP-= Type=3DEAP-TLS

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 (TLS ServerHello,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 TLS EncryptedExtensions,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 TLS CertificateRequest,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Certificate,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 =A0TLS CertificateVerify,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Finis= hed,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0TLS NewSessionTicket)

=A0=A0=A0 EAP-Response/

=A0=A0=A0 EAP-Type=3DEAP-TLS

=

=A0=A0 (TLS Certificate,

=A0=A0=A0 TLS CertificateVerify,=

=A0=A0=A0 TLS Finished)=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 -------->

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Su= ccess

=A0

Case 2: No ticket sent

=A0

=A0

=A0

=A0=A0=A0 EAP Peer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 EAP Server

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0EAP-Request/

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Identity

=A0=A0=A0 EAP-Response/

=A0=A0=A0 Identity (Privacy-Friendly)=A0 --------&= gt;

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Request/

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0EAP-Type=3DEAP-T= LS

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (TL= S Start)

=A0=A0=A0 EAP-Response/

=A0=A0=A0 EAP-Type=3DEAP-TLS

=

=A0=A0 (TLS ClientHello)=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 -------->

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Request/

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 (TLS ServerHello,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 TLS EncryptedExtensions,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 TLS CertificateRequest,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Certificate,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 TLS CertificateVerify,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0<--------=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 TLS Finished)

=A0=A0=A0=A0EAP-Response/

=A0=A0=A0 EAP-Type=3DEAP-TLS

=

=A0=A0 (TLS Certificate,

=A0=A0=A0 TLS CertificateVerify,=

=A0=A0=A0 TLS Finished)=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 -------->

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Su= ccess



  1. Use the Commitment Message as an application layer payload (encrypted as it should be). (Note that this has nothing to do with early data.) If the OpenSSL spec does not support an application layer message from the server right after the finish then it is not compliant to the TLS 1.3 RFC.

=A0

How would that work? How can server send encrypted application layer payload without having received the TLS Finished from the peer.

[Hannes] Here is a copy-and-paste from the TLS spec:

=A0

=A0=A0=A0=A0=A0=A0 Client=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Ser= ver

=A0

Key=A0 ^ ClientHello=

Exch | + key_share*<= /p>

=A0=A0=A0=A0 | + signature_algorithms*=

=A0=A0=A0=A0 | + psk_key_exchange_mode= s*

=A0=A0=A0=A0 v + pre_shared_key*=A0=A0= =A0=A0=A0=A0 -------->

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0ServerHello=A0 ^ Key

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 + key_share*=A0 | Exch

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 + pre_shared_key*=A0 v

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 {EncryptedExtensions}=A0 ^=A0 Server

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0{Certifica= teRequest*}=A0 v=A0 Params

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 {Certificate*}=A0 ^

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 {CertificateVerify*}=A0 | Auth

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 {Finished}=A0 v

=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0<--------=A0 [Application Data*]

=A0=A0=A0=A0 ^ {Certificate*}

Auth | {CertificateVerify*}=

=A0=A0=A0=A0 v {Finished}=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 -------->

=A0=A0=A0=A0=A0=A0 [Application Data]=A0= =A0=A0=A0=A0 <------->=A0 [Application Data]

=A0

The TLS 1.3 spec says:

=A0=A0=A0Note that while the

=A0=A0 server may send Application Dat= a prior to receiving the client's

=A0=A0 Authentication messages, any da= ta sent at that point is, of course,

=A0=A0 being sent to an unauthenticate= d peer.

The question is whether the aspect of sending data to an unauthenticated peer matters in this case? I would argue that it does not matter because the currently defined Commitment message is unencrypted. =A0

=A0

While I am open to discussing better alternatives, I think from an implementation perspective, it makes sense to have a definite notification mechanism for the server to notify the peer that no more post-handshake messages are to be expected.

=A0

[Hannes] I am trying to find out how to implement this functionality into our stack and it looks painful (developer-visible API changes). Of course, it is difficult to accommodate for not yet invented post-handshake authentication messages. We don=92t even know whether they will be compatible with the network access authentication use case.

=

=A0

Ciao

Hannes

PS: I believe it would be good to highlight this specific aspect in the introduction of the document. For me it appeared that the specification is largely a copy-and-paste job but this clearly is something worth highlighting to the reader/implementer.

=A0

--Mohit

The current solution in the draft, for example, does not work with Mbed TLS because you cannot tell the stack to suddenly bypass the encryption layer (after successfully establishing it) to send a plaintext message.

=A0

Ciao

Hannes

=A0

From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com&= gt;; = emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

=A0

Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken to avoid changes to the underlying TLS implementation while also avoiding changes to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS is non-trivial. See his email here: https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. Essentially, TLS 1.3 allows a server to send a Post-Handshake message with a NewSessionTicket at any time. However, in EAP-TLS this is not possible. The TLS tunnel is torn down after authentication. John notes in his response to Jouni (https://mailarchive.ietf.org/arch/= msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in TLS the connection is assumed to stay open for a long time after the client sends Finished, in EAP the connection is assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra round trip and left the peer uncertain about the next message (https://tools.ietf.org/html/draft-= ietf-emu-eap-tls13-00#section-2.1.1). Jouni highlighted this uncertainty for a peer: " the peer has no idea whether the NewSessionTicket is delivered after ClientFinished. In other words, the next message in the sequence could be either continuation of EAP-TLS method or EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that purpose?". See RFC 3748 (https://tools.ietf.org/html/rfc374= 8) which says the following:

=A0=A0 Implementation Note: Because the Success and Fail=
ure packets are not
=A0=A0 acknowledged, they are not retransmitted by the a=
uthenticator, and
=A0=A0 may be potentially lost.=A0 A peer MUST allow for=
 this circumstance as
=A0=A0 described in this note.=A0

and 

=A0On the peer, after success result indications have be=
en exchanged by
=A0=A0 both sides, a Failure packet MUST be silently dis=
carded.=A0 The peer
=A0=A0 MAY, in the event that an EAP Success is not rece=
ived, conclude that
=A0=A0 the EAP Success packet was lost and that authenti=
cation concluded
=A0=A0 successfully.


Thus, EAP-Success cannot be used as a reliable notification mechanism. Till version 05 of the document, we used an empty application data record as a notification of the last handshake message. The text said: 

When an EAP server has sent its last handshake message (=
Finished or a
=A0=A0 Post-Handshake), it commits to not sending any mo=
re handshake
=A0=A0 messages by appending an empty application data r=
ecord (i..e. a TLS
=A0=A0 record with TLSPlaintext.type =3D application_dat=
a and
=A0=A0 TLSPlaintext.length =3D 0) to the last handshake =
record.=A0 After sending
=A0=A0 an empty application data record, the EAP server =
may only send an
=A0=A0 EAP-Success, an EAP-Failure, or an EAP-Request wi=
th a TLS Alert
=A0=A0 Message.

However, Jouni in a later response (https://mailarchive.ietf.org/arch/= msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted that such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL is not willing to send such an empty TLSPlaintext structure. SSL_write() has following to say : 'You should not call SSL_write() with num=3D0, it will return an error. SSL_write_ex() can be called with num=3D0, but will not send application data to the peer.'" =

Therefore, the text was later updated to:

 When an EAP server has sent its last hands=
hake message (Finished or a
=A0=A0 Post-Handshake), it commits to not sending any mo=
re handshake
=A0=A0 messages by sending a Commitment Message.=A0 The =
Commitment Message is
=A0=A0 a TLS record with application data 0x00 (i.e. a T=
LS record with
=A0=A0 TLSPlaintext.type =3D application_data, TLSPlaint=
ext.length =3D 1, and
=A0=A0 TLSPlaintext.fragment =3D 0x00).=A0 Note that the=
 length of the plaintext
=A0=A0 is greater than the corresponding TLSPlaintext.le=
ngth due to the
=A0=A0 inclusion of TLSInnerPlaintext.type and any paddi=
ng supplied by the
=A0=A0 sender.=A0 EAP server implementations MUST set TL=
SPlaintext.fragment to
=A0=A0 0x00, but EAP peer implementations MUST accept an=
y application data
=A0=A0 as a Commitment Message from the EAP server to no=
t send any more handshake messages.

=A0

There is still a challenge in scenarios where a server chooses not to issue any NewSessionTicket. In this email: https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni notes this problem:

I did see some issues when OpenSSL 1.1.1 when disabling =
sending of
session tickets, though. The current draft indicates tha=
t the empty
Application Data payload would be send out in the same E=
AP packet with
the server's Finished message, i.e., before the server h=
aving
authenticated the peer. And this would be done without t=
he peer having
used TLS early data (which is explicitly disallowed in t=
he draft). That
combination did not work with my experiments since OpenS=
SL was rejecting
the SSL_write() operation after the server having writte=
n own Finished
message, but before having received the Finished message=
 from the peer..
The OpenSSL documentation seemed to imply that SSL_write=
_early_data()
could be used by the server _if_ the client first sent e=
arly data.. At
least in my tests, OpenSSL rejected that call without ea=
rly data from
the client.

=A0

This is why the current text also says the following:

 The Commitment Message may be sent in the =
same
=A0=A0 EAP-Request as the last handshake record or in a =
separate EAP-
=A0=A0 Request.=A0 Sending the Commitment Message in a s=
eparate EAP-Request
=A0=A0 adds an additional round-trip, but may be necessa=
ry in TLS
=A0=A0 implementations that only implement a subset of T=
LS 1.3.=A0 In the case
=A0=A0 where the server sends the Commitment Message in =
a separate EAP-
=A0=A0 Request, the conversation will appear as shown in=
 Figure 9.=A0 After
=A0=A0 sending the Commitment Message, the EAP server ma=
y only send an EAP-
=A0=A0 Success, an EAP-Failure, or an EAP-Request with a=
 TLS Alert Message.

=A0

Thus, the current design decision has been guided by parallel implementation experience and it is the best solution we could come up with (given all the practical limitations).

--Mohit

On 6/12/20 11:36 AM, Hannes Tschofenig= wrote:

Hi all,

=A0

This has probably been discussed extensively in the EMU group. I am sorry to bring it up again but I believe this is a bad design decision. I raised it in my short review just sent to the list but I believe it is worthwhile to point it out separately.

=A0

draft-ietf-emu-eap-tls13 introduces a new message to EAP-TLS, namely the Commitment Message. This requires extra code in an implementation because the normal behavior would be to run a TLS stack and then send encrypted data.

EAP-TLS does, however, not send application data*. This message changes this. Not only does it not send encrypted application data it requires an implementation to transmit a plaintext application data record after the application traffic secret has been created and before that application traffic secret is used to protect post handshake messages. This will make it difficult to re-use an off-the-shelf TLS 1.3 stack.

=A0

There is very little motivation about this message ot=
her than 
=A0
=93
=A0=A0 When an EAP server ha=
s sent its last handshake message (Finished or a
=A0=A0 Post-Handshake), it c=
ommits to not sending any more handshake
=A0=A0 messages by sending a=
 Commitment Message.
=93

=A0

I might miss something important here but why cannot the EAP-Success or EAP-Failure serve that purpose?

=A0

Here are two examples to explain what = I mean:

=A0

  1. Failed exchange

=A0

=A0=A0=A0 EAP Peer=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP Server
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Identity=

=A0=A0=A0 EAP-Response/
=A0=A0=A0 Identity (Privacy-=
Friendly)=A0 -------->
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (TLS Start)
=A0=A0=A0 EAP-Response/
=A0=A0=A0 EAP-Type=3DEAP-TLS=

=A0=A0 (TLS ClientHello)=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0(TLS ServerHello,=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS EncryptedExtensions,
            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS CertificateRequest,<=
/pre>
            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Certificate,

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0TLS CertificateVerify,

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Finished=
,

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0 Commitment Message)

            
=A0=A0=A0 EAP-Response/

            
=A0=A0=A0 EAP-Type=3DEAP-TLS=


            
=A0=A0 (TLS Certificate,

            
=A0=A0=A0 TLS CertificateVer=
ify,

            
=A0=A0=A0 TLS Finished)=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->
            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0 =A0=A0(TLS Fatal Alert)
            
=A0=A0=A0 EAP-Response/

            
=A0=A0=A0 EAP-Type=3DEAP-TLS=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->
=

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Failure
=

            
=A0

            
=A0

            
    
              
  1. Success=
ful
                Exchange with Post-Handshake NewSession Ticket=

    2. 
            

            
=A0

            
=A0=A0=A0 EAP Peer=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP Server

            
=A0

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Identity=


            
=A0=A0=A0 EAP-Response/

            
=A0=A0=A0 Identity (Privacy-=
Friendly)=A0 -------->

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (TLS Start)

            
=A0=A0=A0 EAP-Response/

            
=A0=A0=A0 EAP-Type=3DEAP-TLS=


            
=A0=A0 (TLS ClientHello)=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Reque=
st/

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0(TLS ServerHello,=


            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS EncryptedExtensions,
            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS CertificateRequest,<=
/pre>
            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Certificate,

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0TLS CertificateVerify,

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TLS Finished)

            
=A0=A0=A0 EAP-Response/

            
=A0=A0=A0 EAP-Type=3DEAP-TLS=


            
=A0=A0 (TLS Certificate,

            
=A0=A0=A0 TLS CertificateVer=
ify,

            
=A0=A0=A0 TLS Finished)=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->
            
=A0=A0=A0=A0 =A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0EAP-Req=
uest/

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Type=3DEAP-TLS

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (TLS NewSessionTicket,

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0 Commitment Message)

            
=A0=A0=A0 EAP-Response/

            
=A0=A0=A0 EAP-Type=3DEAP-TLS=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -------->
=

            
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=
------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP-Success
=

            
=A0

            
=A0

            
Ciao

            
Hannes

            
=A0

            
(*): FWIW Post handshake messages are
              protected with the application traffic secrets.<=
/p>
            
=A0

            
IMPORTANT NOTICE: The contents of this=

              email and any attachments are confidential and may also be
              privileged. If you are not the intended recipient, please
              notify the sender immediately and do not disclose the
              contents to any other person, use it for any purpose, or
              store or copy the information in any medium. Thank you.
              

              

              

              

            
_______________________________________________

            
Emu mailing list

            
Emu@ietf.org

            
https://www.ietf..org/mailman/listinfo/emu

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 

_______________________________________________=

Emu mailing list
E=
mu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--------------567CEC60B3BFC0097A8E56E5-- --------------ms060601040200000608060408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMUwggX7MIID46ADAgECAhBcf8Ki080s7KKjg2APnSBWMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEwMDgxMDAzMjJaFw0yMDEwMDgxMDAzMjFaMGgxETAPBgNV BAoMCEVyaWNzc29uMRYwFAYDVQQDDA1Nb2hpdCBTZXRoaSBNMSkwJwYJKoZIhvcNAQkBFhpt b2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZXNldG1vaDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAN23/VIr1UI1NLeaFL45vzBE0NglNKyyUQknMqT5zRxm ocJ74fYRJmfHmaQxEYdxp6cCYFxbM2OJOiMN5LRxEQG282Dsjnff6mHXt5wNsMrHZ88poT3X yZCzFBkQF/kswJKu6OD9v1J6WWl9fV2h0QRP0ju+B/H2O3OzioHDP9Qazzr5TMTvmRmXoMfh WXyH/joBaGVyn8SCeRaI0wVGRCKDp93UzdL5o+qGqCUPJQP/2SR/4UoCUTqEtSgh4iCBNAs/ OwhHwbWdU73/EJtsaaOG2fhwMTgWR3KJOIUMyWtRBcO9cIan+82SNgAByR4x2BKIWgFvSPNo GXKn1nOi0W0CAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1 c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUFBwEB BHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGm1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUM0z7o31aA+qQasQqDc7/Ppn7u5MwHwYDVR0jBBgwFoAUHHsZ npecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQCB 35yJmyIRJUmxQmpYX7hNdQJXxJdIAMzCe+rQsz+0F1zA8xsYn4Rn5m7SVGKbE4ONC+EUHHzQ o1OpA5txlK+IPRMqZTM2cQpAet8Qy2vRqFVd0pFDmPx0Az/SPooz7gnuIaPaCGeXOSSxtSOu rX+7fE2EiE/SuCFKmtsFmwnZH62hDDtzd3XTwmJia/5Ab+8/elAstT5a1cP52SorrkuLPgAB ny/XJzsU3LOQQ37Wm5DMyMPEK+zkBG/+2t1cOGgryvu7Hq14NfkAUZxHMei6Yf2UABNxbapB 4tyxqpZuPZDl1AwRKMGYHPsnywK4PZDdsD6R+O/YCWdfq9Q3MMCT3C6vu38phy1r6QDCVHVI IPdirDfZ2ypbeqHAwkswioykkBTln9DEyaTYMlxb41EYh/3JwUQmuQQ4ozSfcLTwoaQ+M+Z4 1J/n7AARwD7u3Lb2ls+fmvOLrC+tc0pXlvTKspIhpaNC1Cz7sbsjMSbSqBW9PtY+Vex7GB2J zI8fDHTT/8Jx+33cta2BE6mPFeUY2lu12zQiqNVUc9zEQ7WqGz4VTGFZDnzfU2gCAAYsuimf kQJD+Sr2G3wXs38yN1OhWHBuG1fglz0k5URhXMNC8HtRityIm2504ym5GpTrriJ8X1fQDYN1 WlOPvv4xJpfHAz4NMKJKQmCNtfuZ8BNNyTCCBsIwggSqoAMCAQICEFO4foPhnJkok7CbSRzs uOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRl bGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8A ALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL 7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhV W4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujn whljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W0 7nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBR QGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1 fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77 /NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioIT KffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAt BggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUF BzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQB gg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFz b25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVs aWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OOR auPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUA A4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNH CZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKv dASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQy sshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgb MgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6L kIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3T QYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX 2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDk ZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEBMFswRzELMAkGA1UE BhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlk dWFsIENBIHYzAhBcf8Ki080s7KKjg2APnSBWMA0GCWCGSAFlAwQCAQUAoIIBsTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MTYxMDU3NDlaMC8GCSqG SIb3DQEJBDEiBCAPnjcgf2XF4eIusTAetpkoy8iA09qJGg8WsprVyfueNzBqBgkrBgEEAYI3 EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQXH/CotPNLOyio4NgD50gVjBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMGwGCyqGSIb3 DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEFx/wqLTzSzsoqODYA+dIFYwDQYJKoZI hvcNAQEBBQAEggEAm3ZPMjiH70Z8AK9Dr8C+ZIE+R1EvrBBPfkVcl3SCktS1cDdmdfL+rkQv M21TqkIPF81npSlOEmw8NyOk9R9W8bTbUdlSfmwokfu2OlbTbou2ThMukUHZrPpnjQK33Ti9 dK4m8aiSnY8ifzjveEXGCmaEACX2+5CYAyIw0gXwfXQETQjVAz6kDqLkRnU0v4T0wf9NfD2x bvpXHct2KO3ID4Uy6EXtFYRADdGyxKWxB1A/FjaXz+0xvtOsikKVUAZUhg5Y2L+0Dcbf2PMq edz8LTl2/lFx7QZFucc+mXuytKmMKyqMnvpJxJR667BPJM8hN4ainmEv3z8uD6GfhJ1UaQAA AAAAAA== --------------ms060601040200000608060408-- From nobody Tue Jun 16 07:23:14 2020 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 880553A15CA for ; Tue, 16 Jun 2020 07:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 L4MELxFnhQoV for ; Tue, 16 Jun 2020 07:23:10 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 670243A0DA8 for ; Tue, 16 Jun 2020 07:23:10 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id g62so15561676qtd.5 for ; Tue, 16 Jun 2020 07:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vPJN22emBD0RcbpWD9k53JpxhMZcWCwSQ4dJeuO1XfA=; b=JxvLlw0AprQbVSeihc327LUTf2SYqULOUz1ee0DnlEgfmYUtwQp26xvcEOXpMgGEaN uC15f/6/Rgjjnkwg3zVYl9HJYg5RFmu2AutiszBdoQ5kA+XYpxwFo7Qrq+cVR4ebaM+X eisTFHIsCMHNXgmiuGfGFeg/bchq8VC2j2JRHgWvbN/K12J4ZLv5E+aVhqL5ryI7HMzz xhsjZkvUt2cDTx55KbdV1//wVgiEYwD1VBuyX86dihqeEAjKrVPDw5NDpD3wVZN3lqiG 8AH8JvihJ0c7zemRcr1/K9r17+16S2L2RjedHe5YZdudzXuh8dlAonffs1b/vWVHk4h/ zs6A== 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=vPJN22emBD0RcbpWD9k53JpxhMZcWCwSQ4dJeuO1XfA=; b=oit8mQKueW87Gr265ZNmYlFL8AUjp7YSSZI7USd1rldhDrPTbobUUjHVlSU8fKhZzV kETrxNnGIsyq8v+Numb8ilcYerouq1W6fBwsviGa64wvb7P5qUpzq753EDWgUZt0+H+T ebc0fT4kuwtLwrTpEiT9IdTkebTf0HNpKxrc2IEjvytq4JAvgLa743hSMGIZ2rKAEJAL PNGXauV9dMNDyhsJAYSj3584aFJGLyK5TEkXLciuFwcb+nknMAboOIncKyCfWsnQbRBV dJTQTI4fT5mrGoNjzDseudh9w4y4pkOEk8mBadaz7L6zlUM9mRIr+IxDH0QEOGzS7nxf temg== X-Gm-Message-State: AOAM532DiKSkgbYaMHqzudmljMoA4SH1EJ90Bi7DaxVSqvxEOd1oq7h4 QlpGpz2eP3VF4PMovmyIdsNdeT0ri39GrS3yxrB8hg== X-Google-Smtp-Source: ABdhPJwmETynV+WfZn7P4Z+qc88Kdx4NyMlxqK7WAxrnp9k/rhRsBMag38zXXu4FZ3ILDHEHg9GCTudC39G+FW/j9+4= X-Received: by 2002:ac8:4c8d:: with SMTP id j13mr21846357qtv.38.1592317389379; Tue, 16 Jun 2020 07:23:09 -0700 (PDT) MIME-Version: 1.0 References: <58e59e51-c023-2947-cd6b-4718a32585a5@ericsson.com> In-Reply-To: <58e59e51-c023-2947-cd6b-4718a32585a5@ericsson.com> From: Joseph Salowey Date: Tue, 16 Jun 2020 07:22:58 -0700 Message-ID: To: Mohit Sethi M Cc: EMU WG Content-Type: multipart/alternative; boundary="0000000000005d395605a834489b" Archived-At: Subject: Re: [Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob 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, 16 Jun 2020 14:23:13 -0000 --0000000000005d395605a834489b Content-Type: text/plain; charset="UTF-8" There have been some recent reviews for EAP-NOOB. I think it would be prudent to wait until this round of comments are resolved before moving forward with the request for early allocation. On Tue, May 26, 2020 at 1:53 AM Mohit Sethi M wrote: > I would add that there is also an early implementation of EAP-TLS-PSK: > https://github.com/rohitshubham/EAP-TLS-PSK > > We had agreed that external PSK authentication for EAP-TLS will use a new > method type number. The draft for EAP-TLS-PSK ( > https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00) is still > in the early stages and will undergo many changes before it can be > considered for adoption by the working group. However, allocating a method > type number for EAP-NOOB now would ensure that EAP-TLS-PSK doesn't use the > same code point. > > --Mohit > On 5/26/20 6:56 AM, Joseph Salowey wrote: > > The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have requested early > allocation of the EAP type code value 56. If you object to the early code > point assignment please let the list know why by June 14, 2020. > > The criteria for early assignment includes the following: > > A. The code points must be from a space designated as "RFC Required", > "IETF Review", or "Standards Action". Additionally, requests for early > assignment of code points from a "Specification Required" registry are > allowed if the specification will be published as an RFC. > > EAP Methods have an allocation policy of Designated Expert, with > Specification Required. The specification in this case the > draft-ietf-emu-eap-noob. > > B. The format, semantics, processing, and other rules related to handling > the protocol entities defined by the code points henceforth called > "specifications") must be adequately described in an Internet-Draft. > > The specification draft-ietf-emu-eap-noob-00 contains the protocol > specifics. There are implementations based on this specification listed > below > > C. The specifications of these code points must be stable; i.e., if there > is a change, implementations based on the earlier and later specifications > must be seamlessly interoperable. > > Although the document is a 00 document, the predecessor document > draft-aura-eap-noob > has been > discussed for over a year. This call is a request for working group > members to review the document and object if the specification is not > stable. > > D. There is sufficient interest in the community for early (pre-RFC) > implementation and deployment, or that failure to make an early allocation > might lead to contention for the code point in the field. > > Several implementations exist, but it would be good to see if there is > additional interest in implementing this protocol > > The authors note that currently, the following implementations of EAP-NOOB > exist: > > 1. Implementation with wpa_supplicant (client) and hostapd (server): > https://github.com/tuomaura/eap-noob > > 2. Lightweight implementation on Contiki (client only): > https://github.com/eduingles/coap-eap-noob (Tested with server > implementation from #1) > > 3. Minimal EAP-NOOB (based on #1 with cleaner code and updates to match > current draft version): https://github.com/Vogeltak/eap-noob > > Thanks, > > Joe > > _______________________________________________ > Emu mailing listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu > > --0000000000005d395605a834489b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There have been some recent reviews =C2=A0for EAP-NOO= B.=C2=A0 I think it would be prudent to wait until this round of comments= =C2=A0are resolved=C2=A0before moving forward with the request for early al= location.=C2=A0

On Tue, May 26, 2020 at 1:53 AM Mohit Sethi M <mohit.m.sethi@ericsson.com> w= rote:

I would add that there is also an early implementation of EAP-TLS-PSK: <= a href=3D"https://github.com/rohitshubham/EAP-TLS-PSK" target=3D"_blank"> https://github.com/rohitshubham/EAP-TLS-PSK

We had agreed that external PSK authentication for EAP-TLS will use a ne= w method type number. The draft for EAP-TLS-PSK (https://t= ools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00) is still in the early stages and will undergo many changes before it can b= e considered for adoption by the working group. However, allocating a metho= d type number for EAP-NOOB now would ensure that EAP-TLS-PSK doesn't us= e the same code point.

--Mohit

On 5/26/20 6:56 AM, Joseph Salowey wrote:
The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have req= uested early allocation of the EAP type code value 56.=C2=A0 If you object = to the early code point assignment please let the list know why by June 14,= 2020.=C2=A0=C2=A0

The criteria for early assignment includes the following:

A.=C2=A0 =C2=A0 The code points must be from a space designated as "RF= C Required", "IETF Review", or "Standards Action".= =C2=A0 Additionally,=C2=A0requests for early assignment of code points from= a "Specification Required" registry are allowed if the specifica= tion will be published as an RFC.

EAP Methods have an allocation policy of=C2=A0Designated Expert, with Specification Required= .=C2=A0 The specification in this case the=C2=A0draft-ietf-emu-eap-n= oob.

B.=C2=A0 The format, semantics, processing, and other rules related to hand= ling the protocol entities defined by the code points henceforth called &qu= ot;specifications") must be adequately described in an Internet-Draft.=

The specification draft-ietf-emu-eap-noob-00 contains the protocol spe= cifics.=C2=A0 There are implementations based on this specification listed = below

C. The specifications of these code points must be stable; i.e., if th= ere is a change, implementations based on the earlier and later specificati= ons must be seamlessly interoperable.=C2=A0

Although the document is a 00 document, the predecessor document=C2=A0= draft-aura-eap-noob=C2=A0has been discussed for over a year.=C2=A0 This call is a request for working g= roup members to review the document and object if the specification is not = stable.=C2=A0=C2=A0

D. There is sufficient interest in the community for early (pre-RFC) i= mplementation and deployment, or that failure to make an early allocation m= ight lead to contention for the code point in the field.

Several implementations exist, but it would be good to see if there is= additional interest in implementing this protocol

The authors note that currently, the following implementations of EAP-= NOOB exist:

1. Implementation with wpa_supplicant (client) and hostapd (server):
https://github.com/tuomaura/eap-noob

2. Lightweight implementation on Contiki (client only):
https://github.com/eduingles/coap-eap-noob=C2=A0(Teste= d with server
implementation from #1)

3. Minimal EAP-NOOB (based on #1 with cleaner code and updates to match
current draft version):=C2=A0https://github.com/Vogeltak/eap-noo= b

Thanks,

Joe

_______________________________________________
Emu mailing list
Emu@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/emu
--0000000000005d395605a834489b-- From nobody Thu Jun 18 07:28:50 2020 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 211543A113C for ; Thu, 18 Jun 2020 07:28:49 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=pKFjY+oy; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=pKFjY+oy 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 hgSP4cBipyf5 for ; Thu, 18 Jun 2020 07:28:47 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130052.outbound.protection.outlook.com [40.107.13.52]) (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 6ED063A1139 for ; Thu, 18 Jun 2020 07:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qWX6BY/+SeTDGfSCH9ZvuL5hYugrzpUZ83TmmBp8Wfc=; b=pKFjY+oyiQi2Op4XT1RKhnMQIs6SUJBXRIXzSZ6E1QmwrnBwZWw4j4cjbVprTmJvvr0DxDCI5xkejkLWQ0LyXfU7Kzj/DWgJgacwU4U65aDB0/qx0slWPw93J74Du+4myjp3TvoF1/pydXI5SaeF+UVHAGDdErRuCLHkjKNzCLg= Received: from AM7PR04CA0003.eurprd04.prod.outlook.com (2603:10a6:20b:110::13) by VI1PR0801MB1662.eurprd08.prod.outlook.com (2603:10a6:800:52::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.20; Thu, 18 Jun 2020 14:28:43 +0000 Received: from VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:110:cafe::49) by AM7PR04CA0003.outlook.office365.com (2603:10a6:20b:110::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Thu, 18 Jun 2020 14:28:43 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT010.mail.protection.outlook.com (10.152.18.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Thu, 18 Jun 2020 14:28:42 +0000 Received: ("Tessian outbound cdcc6148d2f4:v59"); Thu, 18 Jun 2020 14:28:42 +0000 X-CR-MTA-TID: 64aa7808 Received: from f1a8a6b7707f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C9EA34EB-E6FB-4FF6-BAF4-00B92E3F7541.1; Thu, 18 Jun 2020 14:28:37 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f1a8a6b7707f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 18 Jun 2020 14:28:37 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P/SiIIjmD2XCbYI2pDfUcDqagkUrweMousohGWFmAirEZwgMFLLeq5P7kz2g9T9bmtDJpNOY50kg6yu5M6imyBbwVptrzF4Hk+uafU80CCgKv4faXRIFFFKGhqZsTOTavFG+Tmd42cdcXiSr9DKu+JVdYqdp9LDx8k+xYhtZfT/yIKFGcinK3XXUfyax1F/1gf0eTHdwrju9zp1AdFAQrRV7tAxyiwUsiJzgdrJjC2SuIhhlKeyb98U6Ajak0SZ+ZrXxolrJKAWpHOToT+zELECYSX7fV4Wo3tfp3TzwZ270VWEA/QJyMEVgSXFSP6lwFRRh4uiBGO7MTPL2hdC3ZA== 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=qWX6BY/+SeTDGfSCH9ZvuL5hYugrzpUZ83TmmBp8Wfc=; b=LClM/Ma9fzfS0aZvlY2dvrUmLtTEU66UEpbiyi1bsZCDVB2rvMjBRgSZw8UTdQX5J8rZLtezU4rEAqtX9bffG6ffS5hAbzCRlGXrDDr4N8SrCG9JhjCb8O1/LCPxyygQPCVi/jmeqX9YwLymnm4A/eDuXjhQKZylZiayC7qTplnBwu+J1DwP356QI0oaHDYQDTXY1kfxsfai2Ie7H9u/B6rZ8r0JIznNnTsnDVs4fOQZu1azSHc3hkIi4ciaVKcJq9m6gaJTXC+wBkykqt/wsFSjzIePKCiUf61tVGVMlQxvkWlbPcjA2AXIzFyLdawvHfOO6+56v5oZgjKxZkRCXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qWX6BY/+SeTDGfSCH9ZvuL5hYugrzpUZ83TmmBp8Wfc=; b=pKFjY+oyiQi2Op4XT1RKhnMQIs6SUJBXRIXzSZ6E1QmwrnBwZWw4j4cjbVprTmJvvr0DxDCI5xkejkLWQ0LyXfU7Kzj/DWgJgacwU4U65aDB0/qx0slWPw93J74Du+4myjp3TvoF1/pydXI5SaeF+UVHAGDdErRuCLHkjKNzCLg= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4529.eurprd08.prod.outlook.com (2603:10a6:208:148::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Thu, 18 Jun 2020 14:28:35 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3109.021; Thu, 18 Jun 2020 14:28:35 +0000 From: Hannes Tschofenig To: Mohit Sethi M , "emu@ietf.org" Thread-Topic: [Emu] draft-ietf-emu-eaptlscert-04 Thread-Index: AdY/A+a7cI/+21ekRcieJ5sNz2jGnwD88kyAAKFB8sA= Date: Thu, 18 Jun 2020 14:28:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: e92d2509-e2db-422d-9ff8-4d82859d9c4b.1 x-checkrecipientchecked: true Authentication-Results-Original: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.122.58] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 5c47e7c6-6d6e-418f-97aa-08d81393e6f7 x-ms-traffictypediagnostic: AM0PR08MB4529:|VI1PR0801MB1662: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0438F90F17 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: nYk4Z2kfx9Aktnfcj7+Ri0tdnupmxRBsgmhBlwFJi4TZhSZ0MJGOsvj0qYFKJosqag5vugQLT4KYqkR6njucdnj+QyAZJK0LzXSins+RZEbiEUZvAtExNtwgrEDBG5ADR6l4FIeIr08JjazIznycTxZx6evS3z6R9P+DXfNwff6g3YAgePCKQwYpKLdeXirdStzuyezdwyy6GFzyT9MHfhapU/6rzj5cSpYJ1zIXptWB/FJNB1qw0Qjdh1OjMCJh2+iVfpVkaDIkevDM3ykGoxQC6IDk7M/EfQNUi0VJ0mIGAVOZzyULYZDT1uNFwzKh8KOpYWVCUdOpxtyKB+gwi6d6bzQn6gzQsVOeDFt6cca+D+GzEXKqunSGOyt+oeTagf7sm6HYDZyuWJcU8CyNyw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(366004)(39860400002)(136003)(7696005)(316002)(76116006)(110136005)(53546011)(86362001)(6506007)(66476007)(83380400001)(186003)(26005)(66556008)(66946007)(64756008)(66446008)(71200400001)(8936002)(2906002)(8676002)(33656002)(55016002)(966005)(5660300002)(52536014)(9686003)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: n7lX22ERX5uuzBPaMAAl1oY4kiHEPpuqKnUvjnKvpj4rQI6T0IM3d/FFBi3vQUl1g8AR8nQfEiRAqXrRJTUQ6YCxFhZtMflALaThdK46H35JwIiEMKNOKJcQsNzjwNOfUulR7iI2bjuZKXTsogRnqJDqWyRV6dx44dXyqrJY61fXqfWW3/JFTes5DZEQSAQGm1ex+kIsBtcJarB8Sw9YpYR5BAIOpdllOkLR2i8G4FqYDQAePWiyP40ZpvvCtKT6oNdVJmxFm8/GA/7JOF7ggmPJniQMsEG1jBs6Ta7E0CNcR6tQJwFqg+U/xQYMdK92KWWgo0koV0AoD/TzFp+D0cp7S57TkX+wCDPNb9Wru/szWa+1/saFsPsYaeUAOEn+1PLh4rRfTmRLinEuWCNhRNDIzPr11RrDxoIJXwr/e0REv41JsXgEnirus/pGY0MJAeCGBDCFxH8Se/mAMsgEYosRttOPSIaGhBFjZzO5WSk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4529 Original-Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(39860400002)(346002)(396003)(46966005)(36906005)(70206006)(316002)(8936002)(82310400002)(33656002)(9686003)(70586007)(26005)(5660300002)(186003)(83380400001)(110136005)(966005)(336012)(47076004)(82740400003)(7696005)(52536014)(81166007)(8676002)(356005)(2906002)(53546011)(6506007)(478600001)(86362001)(55016002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 3997391b-d8b4-4981-d7e4-08d81393e2d0 X-Forefront-PRVS: 0438F90F17 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ddmL3T1Amy4jB92xT1ADXhdlevOCvKR0ic4+J0kJuDNOpzxBNjo5jT93wA4jIS8VIuFdvIf2hB1xhWi1eX/zFidXIajz7ola9iTQidsKxbXcy8EmP2YuI2VdOfBcC/LRMBxHG89gshMt0jAN0aPmuUqASWks/HykFDjf2Fa7nGENY00FQkGYvjbk5ZRslJJc903dYQ7Hf9zQEuTQAGeuJck9IVMyaMgeRVFW80l7OHQ+rjKn0f7qJVV051fZyBeQfw30gShJ1Rhyr373eJ0UKOSsaPmHWx8KCGBPge/eSGxFZJUrS7fm5c+Uhk0/7ea16AWgUNOh3CO5+ZraBeOBD03OcHSF0ZKx1OB7o61AQ0rVk3PBkokDAAk5O668JIeC+yfyxG+4HituL1PE4NOOXvrjN1QkzlkAHEKU7VCK/eEEbr7UtZn5q6s2iMYSoeXBLqPNTmzna3TbMwSXGQuEUkDFZYA50ragU6c5L4ojzEA= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2020 14:28:42.7893 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5c47e7c6-6d6e-418f-97aa-08d81393e6f7 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1662 Archived-At: Subject: Re: [Emu] draft-ietf-emu-eaptlscert-04 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, 18 Jun 2020 14:28:49 -0000 VGhhbmtzIGZvciB0aGUgcXVpY2sgdHVybi1vdmVyLXRpbWUuDQoNCkxvb2tzIGdvb2QgdG8gbWUu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNb2hpdCBTZXRoaSBNIDxtb2hp dC5tLnNldGhpQGVyaWNzc29uLmNvbT4NClNlbnQ6IE1vbmRheSwgSnVuZSAxNSwgMjAyMCAxMToz MSBBTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPjsg ZW11QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0VtdV0gZHJhZnQtaWV0Zi1lbXUtZWFwdGxzY2Vy dC0wNA0KDQpIaSBIYW5uZXMsDQoNClRoYW5rcyBmb3IgdGhlIGZvbGxvdyB1cC4gSSBoYXZlIHN1 Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIHdoaWNoIHNob3VsZA0KYWRkcmVzcyB5b3VyIGNvbmNlcm5z LiBIZXJlIGlzIGEgZGlmZiBmb3IgeW91ciBjb252ZW5pZW5jZToNCmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWVtdS1lYXB0bHNjZXJ0LTA1DQoNClBsZWFzZSBz ZWUgaW4tbGluZSBmb3IgZGV0YWlscy4NCg0KSSBiZWxpZXZlIHRoYXQgdGhlIGRyYWZ0IGlzIG5v dyByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNCi0tTW9oaXQNCg0KT24gNi8xMC8yMCAxMjowMiBQ TSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IFRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4NCj4N Cj4gQSBmZXcgbW9yZSBtaW5vciBjb21tZW50cyBvbiAtMDQ6DQo+DQo+IFNlY3Rpb24gNC4xOg0K Pg0KPiAiVExTIDEuMyBbaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0NDZdIHJlcXVp cmVzIGltcGxlbWVudGF0aW9ucyB0byBzdXBwb3J0IEVDQy4iDQo+DQo+IFRoaXMgaXMgb25seSB0 cnVlIGFic2VudCBhbiBhcHBsaWNhdGlvbiBwcm9maWxlIGRlZmluaW5nIHNvbWV0aGluZyBlbHNl Lg0KPiBUaGUgVVRBIGdyb3VwIGhhcyBqdXN0IGFkb3B0ZWQgYSBXRyBpdGVtIHRoYXQgZGVmaW5l cyBzdWNoIGEgcHJvZmlsZS4NCj4NCj4gSGVuY2UsIEkgc3VnZ2VzdCB0byBhZGQgdGhlIHJlbWFy ayBhYm91dCB0aGUgcHJvZmlsZS4gU29tZXRoaW5nIGxpa2UNCj4NCj4gIkluIHRoZSBhYnNlbmNl IG9mIGFuIGFwcGxpY2F0aW9uIHByb2ZpbGUgc3RhbmRhcmQgc3BlY2lmeWluZw0KPiBvdGhlcndp c2UsIGEgVExTIDEuMy1jb21wbGlhbnQgYXBwbGljYXRpb24gbXVzdCBzdXBwb3J0IEVDQy4iDQpE b25lIQ0KPg0KPiA0LjIuICBVcGRhdGluZyBUTFMgYW5kIEVBUC1UTFMgQ29kZQ0KPg0KPiBXaHkg YXJlIHlvdSBjYWxsaW5nIHRoZSBzZWN0aW9uICJ1cGRhdGluZyBjb2RlIj8gVGhlIHN1Z2dlc3Rp b24gaW4gNC4yLjEgZG9lcyBub3QgcmVxdWlyZSBjb2RlIHVwZGF0ZSBhbmQgd2hldGhlciBzb21l dGhpbmcgcmVxdWlyZXMgYSBjb2RlIHVwZGF0ZSBkZXBlbmRzIHdoYXQgeW91IGhhdmUgaW4gdGhl IGNvZGUgYWxyZWFkeS4gTWF5YmUgeW91IGp1c3QgbmVlZCB0byBlbmFibGUgdGhlIGZlYXR1cmUu ICBVcGRhdGluZyB0aGUgY29kZSBpcyBhbHNvIGEgbmVnYXRpdmUgYXNwZWN0IGJlY2F1c2UgeW91 IGFyZSBsaWtlbHkgZ29pbmcgdG8gdXBkYXRlIHRoZSBjb2RlIG9uIGEgcmVndWxhciBiYXNpcyBh bnl3YXkgdG8gZml4IGJ1Z3MgYW5kIHRvIHN1cHBvcnQgbmV3IGFsZ29yaXRobXMuIEx1Y2tpbHkg VExTIGhhcyB0aGUgZXh0ZW5zaW9uIG5lZ290aWF0aW9uIGJ1aWx0LWluIGFuZCBoZW5jZSB5b3Ug Y2FuIGRldGVjdCBhbmQgbmVnb3RpYXRlIG5ldyBmZWF0dXJlcyBvbiB0aGUgZmx5Lg0KSSBhZ3Jl ZSB0aGF0IGFsbCBjb2RlIGluZGVlZCBzaG91bGQgYmUgdXBkYXRlZCB0byBmaXggYnVncyBhbmQN CnZ1bG5lcmFiaWxpdGllcy4gSG93ZXZlciwgdXBkYXRpbmcgYXBwbGljYXRpb25zIGFuZCBjZXJ0 aWZpY2F0ZXMgaXMNCmNlcnRhaW5seSBkaWZmZXJlbnQgZnJvbSB1cGRhdGluZyB0aGUgdW5kZXJs eWluZyBUTFMgbGlicmFyeSBhbmQgRUFQDQppbXBsZW1lbnRhdGlvbi4gQWRtaW5pc3RyYXRvcnMg aW4gZW50ZXJwcmlzZSBlbnZpcm9ubWVudHMgKHdoZXJlIEVBUC1UTFMNCmlzIHdpZGVseSB1c2Vk KSBoYXZlIGdyZWF0IGNvbnRyb2wgb3ZlciB3aGVuIGFuZCBob3cgdGhlIHNlcnZlciBhbmQNCmNs aWVudCB1cGRhdGVzIGFyZSByb2xsZWQgb3V0LiBUaGUgY2F0ZWdvcml6YXRpb24gaW4gc2VjdGlv biA0IHNob3VsZA0KaGVscCBhZG1pbmlzdHJhdG9ycyB0byBkZWNpZGUgaG93IHRvIGF2b2lkIHRo ZSBmcmFnbWVudGF0aW9uIHByb2JsZW0uDQpXaGV0aGVyIGl0IGlzIGlzc3VpbmcgbmV3IGNlcnRp ZmljYXRlcywgdXBkYXRpbmcgdGhlIGFjY2VzcyBwb2ludHMsIG9yDQp1cGRhdGluZyB0aGUgVExT IGFuZCBFQVAtVExTIGltcGxlbWVudGF0aW9uLiBOb25ldGhlbGVzcywgSSBoYXZlIGFkZGVkDQp0 aGUgZm9sbG93aW5nIHRleHQ6ICJUaGlzIHNlY3Rpb24gZGlzY3Vzc2VzIGhvdyB0aGUgZnJhZ21l bnRhdGlvbg0KcHJvYmxlbSBjYW4gYmUgYXZvaWRlZCBieSB1cGRhdGluZyB0aGUgdW5kZXJseWlu ZyBUTFMgb3IgRUFQLVRMUw0KaW1wbGVtZW50YXRpb24uIE5vdGUgdGhhdCBpbiBtYW55IGNhc2Vz IHRoZSBuZXcgZmVhdHVyZSBtYXkgYWxyZWFkeSBiZQ0KaW1wbGVtZW50ZWQgaW4gdGhlIHVuZGVy bHlpbmcgbGlicmFyeSBhbmQgc2ltcGx5IG5lZWRzIHRvIGJlIHRha2VuIGludG8NCnVzZS4iDQo+ DQo+IDQuMi40LiAgQ2FjaGluZyBDZXJ0aWZpY2F0ZXMNCj4NCj4gIlRoZSBleHRlbnNpb24gaG93 ZXZlciBuZWNlc3NpdGF0ZXMgYSBzdWNjZXNzZnVsIGZ1bGwgaGFuZHNoYWtlIGJlZm9yZSBhbnkg Y2FjaGluZy4iDQo+DQo+IFRoaXMgaXMgbm90IHRydWUuIFRoZSBzcGVjIGRlZmluZXMgYSB3YXkg dG8gcG9wdWxhdGUgdGhlIGNhY2hlIGJ5IHJ1bm5pbmcgYSBmdWxsIGhhbmRzaGFrZS4NCj4gSG93 ZXZlciwgeW91IGNvdWxkIGFsc28gcG9wdWxhdGUgdGhlIGNhY2hlIGJ5IG91dC1vZi1iYW5kIG1l YW5zLCBmb3IgZXhhbXBsZSBieSBwcmUtZGlzdHJpYnV0aW5nIGNlcnRzLg0KPg0KPiBUaGUgbWVj aGFuaXNtIHRvIHJlLXJ1biB0aGUgaGFuZHNoYWtlIHRvIHBvcHVsYXRlIHRoZSBjYWNoZSBpcywg aG93ZXZlciwgYSBzYWZlIGZhbGxiYWNrIGluIGNhc2UgY29uZmlndXJhdGlvbiBjaGFuZ2VzIGFu ZCB0aGUgcHJlLWRpc3RyaWJ1dGVkIGNlcnRzIGJlY29tZSBpbnZhbGlkLiBJdCBpcyBiZXR0ZXIg dG8gaGF2ZSBhIGZhbGxiYWNrLg0KPg0KPiBJIHRob3VnaHQgSSBtYWRlIHRoYXQgY29tbWVudCBi ZWZvcmUuDQoNCllvdSBoYWQgcmFpc2VkIHRoaXMgaXNzdWUgYmVmb3JlIGFuZCBJIGhhZCByZXNw b25kZWQgdG8geW91IGJlZm9yZS4gSGVyZQ0KaXMgdGhlIHJlc3BvbnNlIGFnYWluOg0KDQpXaGVy ZSBkb2VzIFJGQyA3OTI0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzkyNCkgdGFs ayBhYm91dA0KcG9wdWxhdGluZyB0aGUgY2FjaGUgd2l0aCBhbiBvdXQtb2YtYmFuZCBtZWNoYW5p c20/IFRoZSB0ZXh0IGluIFNlY3Rpb24NCjEgb2YgUkZDIDc5MjQgY2xlYXJseSBzdGF0ZXMgdGhh dDogICJUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIFRMUw0KZXh0ZW5zaW9uIHRoYXQgYWxs b3dzIGEgY2xpZW50IGFuZCBhIHNlcnZlciB0byBleGNsdWRlIHRyYW5zbWlzc2lvbg0KaW5mb3Jt YXRpb24gY2FjaGVkIGluIGFuIGVhcmxpZXIgVExTIGhhbmRzaGFrZS4iLiBOb3RpY2UgdGhlICJl YXJsaWVyDQpUTFMgaGFuZHNoYWtlIiBwYXJ0LiBJIGNlcnRhaW5seSByZWZ1c2UgdG8gYWRkIG9y IGRlc2NyaWJlIG5ldw0KZnVuY3Rpb25hbGl0eSB3aGljaCBpc24ndCBkaXNjdXNzZWQgaW4gdGhl IG9yaWdpbmFsIFJGQy4NCg0KPg0KPiA0LjIuMy4gIENvbXBhY3QgVExTIDEuMw0KPg0KPiBZb3Ug YXJlIHN0aWxsIHN0YXRpbmcgIlRoaXMgbmF0dXJhbGx5IG1lYW5zIHRoYXQgY1RMUyBpcyBub3Qg aW50ZXJvcGVyYWJsZSB3aXRoIHByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBUTFMgcHJvdG9jb2wu Ig0KPg0KPiBjVExTIGlzIGEgY29tcHJlc3Npb24gb2YgVExTLCB3aGljaCBtZWFucyB0aGF0IHlv dSBjYW4gZmFsbC1iYWNrIHRvIFRMUywgaWYgdGhlIG90aGVyIHBlZXIgZG9lcyBub3Qgc3VwcG9y dCBjVExTLiBBcyBtZW50aW9uZWQgaW4gbXkgcHJldmlvdXMgZW1haWwsIEkgZG9uJ3QgdW5kZXJz dGFuZCB3aHkgeW91IGFyZSBtZW50aW9uaW5nIHRoaXMgYXNwZWN0IGF0IGFsbCBnaXZlbiB0aGF0 IHRoaXMgZG9jdW1lbnQgaXMgYWJvdXQgY2VydGlmaWNhdGUgc2l6ZSByZWR1Y3Rpb24uDQpJIHVu ZGVyc3RhbmQgeW91ciBkZXNpcmUgb2YgbWFraW5nIGNUTFMgbG9vayBnb29kLiBJIGFtIG5vdCBz dXJlIGhvdw0KaGlkaW5nIHRoZSBpbmZvcm1hdGlvbiB0aGF0IGNUTFMgZG9lc24ndCBpbnRlcm9w ZXJhdGUgd2l0aCBvbGRlcg0KdmVyc2lvbnMgb2YgVExTIGhlbHBzLiBBbnlob3csIEkgaGF2ZSBy ZW1vdmVkIHRoYXQgc2VudGVuY2Ugc2luY2UNCnByb2dyZXNzaW5nIHRoZSBkcmFmdCBhdCB0aGlz IGlzIHN0YWdlIGlzIG1vcmUgaW1wb3J0YW50IHRoYW4gYXJndWluZw0Kb3ZlciBvbmUgc2VudGVu Y2UuDQo+DQo+IFJhdyBQdWJsaWMgS2V5cw0KPg0KPiBJIHdvbmRlciB3aGV0aGVyIHlvdSBzaG91 bGQgbWVudGlvbiB0aGUgcG9zc2liaWxpdHkgdG8gdXNlIFJQS3MgKGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3MjUwKSBpbiBTZWN0aW9uIDQuMS4yIGJlY2F1c2UgdGhvc2Ugd291bGQg YmUgYSBmYWlybHkgb2J2aW91cyBjaG9pY2UgaW4gRUFQLVRMUyBnaXZlbiB0aGF0IHdlIGFyZSB0 YWxraW5nIGFib3V0IGEgbmFpbGVkIHVwIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgRUFQIHBlZXIg YW5kIHRoZSBFQVAgc2VydmVyLiBUaGlzIHdvdWxkIG9idmlvdXNseSByZWR1Y2UgdGhlIG92ZXJo ZWFkIGFzc29jaWF0ZWQgd2l0aCBjZXJ0aWZpY2F0ZXMgY29uc2lkZXJhYmx5Lg0KDQpBZGRlZCBh IG5ldyBzdWItc2VjdGlvbi4NCg0KV2l0aCB0aGlzLCBJIGJlbGlldmUgdGhhdCBhbGwgaXNzdWVz IGFyZSByZXNvbHZlZCBhbmQgdGhlIGRvY3VtZW50IGlzDQpyZWFkeSBmb3IgcHVibGljYXRpb24u DQoNCj4NCj4gQ2lhbw0KPiBIYW5uZXMNCj4NCj4NCj4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gVGhhbmsgeW91Lg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBFbXUgbWFpbGluZyBsaXN0DQo+IEVtdUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0KDQpJTVBPUlRBTlQgTk9USUNFOiBU aGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRl bnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg ZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQg Zm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkg bWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Mon Jun 22 20:53:35 2020 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 BCB3D3A171E for ; Mon, 22 Jun 2020 20:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 03VYxSG9wXX9 for ; Mon, 22 Jun 2020 20:53:31 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 EDF593A171A for ; Mon, 22 Jun 2020 20:53:30 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id f18so17690875qkh.1 for ; Mon, 22 Jun 2020 20:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5D5/lLwTAidGZIik/ZdSlZcM/naYcj/QcqZ3uawT7TQ=; b=KmoXebE1UFgFBXLw09I4buUbu2XA9m5luTesA09RIDQ0Wejk5WVRfrYPGjvG2k79Fg 6F1y0M3Hd4bi1fjzC0aXpfka2hVhh8xT9nfb/wql74Zh8O/0F8SJcpd+pBX0+rAvxCeX Go+tevk6oLb9mIg4OabnvCsNECFiMys+ZBockwI2NwgIHgnQbNKLeAvXdauFZbCFpzez AD6euxhyIewgDZ3tUt4CHMgL/w5H/DT6Oy0bKFtoi4nmNm38iMGw+18/Dq8ao+c5b788 EOHh5y4gBjW7gV1VryPI109xxVeElndTNnWO5sNcjaizsL2zc8ZEwqa3B0dTmVSSYdSx ZZ4g== 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=5D5/lLwTAidGZIik/ZdSlZcM/naYcj/QcqZ3uawT7TQ=; b=pT4IbcOUDZ1Wcmq4WP2vMokNX9+f4IeIQLRsyPrxdQRehaD+eNhF82uM7Qhko5GPGB u139VKJnVY6ObuOy++l3DkYGp++90M5iX5qynz9xpCsaWXfkDVTVoeiSyifoBCOtr+ui 8A00TLA28I3N3DN8hg8GhIy0oyl0czxK6ifJhtdGFnPjHcGiCi+34BvGeHJMqLVJpE7J Lo+Q8ngYXf6VLBu2GA3IKpulj8GReY84zQm/bwwePVW7qpQbLankNtpfqdA8WnNwuk4G OclWaT9KrhbuAbf97ZwnZo5KzxE5ORlFuUq9Zir+3iUeq4jjXQKUVUwbZw9MFRPf+KcP H+qA== X-Gm-Message-State: AOAM531YCvEZ9vTWS5pBiyEAskwtK0qJe16XZi0MgxmSIam8YiQ3ppcb HH4MOpCAS5/ywSaM9+PcORg3bSEjInQlrtHsi6LZxg== X-Google-Smtp-Source: ABdhPJwU84HJWeM9FwRtkj0gpJ1yco0LbKlEi+n/HbuKERzkR6F4whaXNmWwlhvQaIuT6Bm69Z+QSL7HJjCXUD+6hbo= X-Received: by 2002:a37:aec4:: with SMTP id x187mr19246179qke.332.1592884409915; Mon, 22 Jun 2020 20:53:29 -0700 (PDT) MIME-Version: 1.0 References: <20200416102445.GA8757@w1.fi> In-Reply-To: From: Joseph Salowey Date: Mon, 22 Jun 2020 20:53:18 -0700 Message-ID: To: Oleg Pekar Cc: Jorge Vergara , Jouni Malinen , EMU WG Content-Type: multipart/alternative; boundary="0000000000006bf04705a8b84dbf" Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 23 Jun 2020 03:53:34 -0000 --0000000000006bf04705a8b84dbf Content-Type: text/plain; charset="UTF-8" On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar wrote: > >And focusing on that "what to do here.." part and the unused IMCK-zero[j] >> in the previous paragraph.. >> >How is this supposed to work when an inner EAP authentication method >> does not derive either MSK or EMSK? >> >Intermediate result indication of success needs to be done and that >> implies there needs to be Crypto-Binding TLV. >> >But that TLV does not have option of indicating that neither EMSK >> Compound MAC nor MSK Compound MAC are present (Flags field has no value 0 >> defined to do so). >> I agree the 0 value should be explicitly listed for this purpose. Given >> the design of the flags I think it is clear this was the intended usage and >> its omission was likely an oversight. >> >So what are those fields (or one of them) supposed to be set to? >> >And how is that selected for an inner EAP authentication method j? >> >Does this depends on what happened with method j-1 (if one was present)? >> >How would the correct IMCK[j] be determined by the peer and the server >> if one of them derived MSK/EMSK but the other one did not derive either for >> inner EAP method j? >> Assuming we use the value 0 to indicate the state where one of the peers >> did not derive either MSK or EMSK, then I believe the RFC addresses this as >> MSKi = 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK, >> and both sides decided to continue the conversion, then both sides would >> use the zero-MSK for that IMSK[j], >> > Jorge, Jouni, agree with the approach. > > Jorge, please note that the same problem exists in PEAP Crypto-Binding TLV > as specified in its documentation > > - when one side has an inner method that provided MSK and another side has > this inner method that didn't provide MSK. > > [Joe] (catching up) With respect to the case that the method is an MSK generating mechanism and and MSK is not generated/used. I think the original intention was that this case would be a protocol violation, ie if a method generates an MSK it should be available for crypto-binding. I'm concerned that allowing the fallback to 0 MSK actually will cause a security vulnerability in compound binding. Do we know if this method mismatch is a problem in practice? > There is also a case where no inner method is executed. For example, when > client certificate was received during TEAP outer tunnel establishment. In > this case we also need to use zero-MSK. For such case both values of the > flag work - "0 for zero-MSK" and "2 for MSK". This creates unnecessary > ambiguity and thus would be better to request using flag's value "0" for > zero MSK in such case (today we use value "2" and it doesn't create > ambiguity). However there's a question here: in case of TEAP certificate > based authentication that is typically done by running inner method > EAP-TLS, should we allow in sending client certificate during TEAP tunnel > establishment or inside the tunnel and this way skipping EAP-TLS inner > method? On one hand it makes authentication shorter. On the other hand it > causes switching from MSK/EMSK exported by the inner method EAP-TLS to > zero-MSK. > > If we do allow skipping any inner method then we need explicitly say that > zero-MSK should be used in such case. > > I've started rebuilding section "5.2 > . Intermediate Compound > Key Derivations" of the RFC according to the proposal on this thread and > will post it here shortly. > > ~ Oleg > > > > > On Mon, Apr 20, 2020 at 3:57 AM Jorge Vergara > wrote: > >> >And focusing on that "what to do here.." part and the unused >> IMCK-zero[j] in the previous paragraph.. >> >How is this supposed to work when an inner EAP authentication method >> does not derive either MSK or EMSK? >> >Intermediate result indication of success needs to be done and that >> implies there needs to be Crypto-Binding TLV. >> >But that TLV does not have option of indicating that neither EMSK >> Compound MAC nor MSK Compound MAC are present (Flags field has no value 0 >> defined to do so). >> >> I agree the 0 value should be explicitly listed for this purpose. Given >> the design of the flags I think it is clear this was the intended usage and >> its omission was likely an oversight. >> >> >So what are those fields (or one of them) supposed to be set to? >> >And how is that selected for an inner EAP authentication method j? >> >Does this depends on what happened with method j-1 (if one was present)? >> >How would the correct IMCK[j] be determined by the peer and the server >> if one of them derived MSK/EMSK but the other one did not derive either for >> inner EAP method j? >> >> Assuming we use the value 0 to indicate the state where one of the peers >> did not derive either MSK or EMSK, then I believe the RFC addresses this as >> MSKi = 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK, >> and both sides decided to continue the conversion, then both sides would >> use the zero-MSK for that IMSK[j], >> >> Jorge Vergara >> >> -----Original Message----- >> From: Jouni Malinen >> Sent: Thursday, April 16, 2020 3:25 AM >> To: Oleg Pekar >> Cc: Jorge Vergara ; EMU WG >> Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion >> >> On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote: >> > For TEAP errata 5770: >> > Technically TEAP RFC suggests the implicit method of taking the >> > correct IMSK[j] and all the subsequent keys after each inner method >> > via negotiation taking place in Crypto-Binding TLV exchange. >> >> What is "the correct IMSK[j]" and where is this defined? >> >> > Let's say we are on the inner method number j that supports both MSK >> > and EMSK and we are server which implementation generates both MSK and >> > EMSK for this inner method. We generated keys according to the rules >> > below - two sets, for IMSK[j] derived from inner method EMSK and for >> > IMSK[j] equal to inner method MSK. Because we don't know whether >> > client implementation supports both MSK and EMSK. >> > >> > S-IMCK[0] = session_key_seed >> > For j = 1 to n-1 do >> > IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", >> > IMSK[j], 60) >> > S-IMCK[j] = first 40 octets of IMCK[j] >> > CMK[j] = last 20 octets of IMCK[j] >> > >> > >> > So we have two CMK[j] and we create Crypto-Binding TLV with both >> > Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in >> > response and we can understand from it whether it supports EMSK for >> > this inner method or not. And here we can decide which version of >> > IMCK[j] to take for this inner method - derived from EMSK or MSK. This >> > is just not explicitly specified in the RFC. >> >> Is this the proposed definition of "the correct IMSK[J]"? In other words, >> is this to be understood to have two (or three since we have the no >> MSK/EMSK case as well) variants of IMSK[j] during an execution of an >> internal AP authentication method and a single one of those variants is >> selected as _the correct_ IMSK[j] at the successful conclusion of this >> inner authentication method? >> >> Would this single "correct IMSK[j]" then be used for deriving the >> different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when >> deriving EMSK-based-IMSK[j+1]? In other words, is this to work by having >> all following inner authentication rounds and MSK/EMSK derivation to behave >> as if the other variants of IMSK[j] never really existed? >> >> > Could this method work? Should we make it more clearly specified? Or >> > should we change the protocol to arrive explicitly to the >> > understanding which type >> > (MSK/EMSK) of IMSK[j] to use? >> >> Regardless of what is done for the design, it will absolutely need to be >> specified more clearly. >> >> If I understood the proposed design correctly, this should be defined >> with something like following: >> >> For each successful inner EAP authentication method, derive IMCK-MSK[j] >> (if MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was >> derived by the inner method), derive IMSK-zero[j] (for all cases). Derive >> CMK-MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if >> available). Generate Crypto-Binding TLV with all available Compound MAC >> values. Also verify Crypto-Binding TLV with all available Compound MAC >> values. After both ends have transmitted and received Crypto-Binding TLV, >> set IMSK[j] to be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or >> set IMSK[j] to be IMCK-MSK[j] if both ends included MSK Compound MAC but >> either end did not include EMSK Compound MAC, or > this even happen?>. Set S-IMCK[j] based on this IMSK[j]. This results in >> there being only a single S-IMCK[j] and MSK/EMSK derivation being well >> defined. >> >> And focusing on that "what to do here.." part and the unused IMCK-zero[j] >> in the previous paragraph.. How is this supposed to work when an inner EAP >> authentication method does not derive either MSK or EMSK? Intermediate >> result indication of success needs to be done and that implies there needs >> to be Crypto-Binding TLV. But that TLV does not have option of indicating >> that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags >> field has no value 0 defined to do so). >> So what are those fields (or one of them) supposed to be set to? And how >> is that selected for an inner EAP authentication method j? Does this >> depends on what happened with method j-1 (if one was present)? How would >> the correct IMCK[j] be determined by the peer and the server if one of them >> derived MSK/EMSK but the other one did not derive either for inner EAP >> method j? >> >> -- >> Jouni Malinen PGP id EFC895FA >> > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --0000000000006bf04705a8b84dbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 21, 2020 at 11:02 AM Oleg= Pekar <oleg.pekar.2017@gma= il.com> wrote:
>= And focusing on that "what to do here.." part and the unused IMCK= -zero[j] in the previous paragraph..
>How is this supposed to work when an inner EAP authentication me= thod does not derive either MSK or EMSK?
>Intermediate result indication of success needs to be done a= nd that implies there needs to be Crypto-Binding TLV.
>But that TLV does not have option of indicating= that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags fie= ld has no value 0 defined to do so).
I agree the 0 value should be explicitly listed for this purp= ose. Given the design of the flags I think it is clear this was the intende= d usage and its omission was likely an oversight.
>So what are thos= e fields (or one of them) supposed to be set to?
>And how is that selected for an inner EAP authentica= tion method j?
>Does this d= epends on what happened with method j-1 (if one was present)?
>How would the correct IMCK[j] be determ= ined by the peer and the server if one of them derived MSK/EMSK but the oth= er one did not derive either for inner EAP method j?
Assuming we use the value 0 to indicate the s= tate where one of the peers did not derive either MSK or EMSK, then I belie= ve the RFC addresses this as MSKi =3D 32 octets of 0x00s. So if one side ca= lculated neither MSK nor EMSK, and both sides decided to continue the conve= rsion, then both sides would use the zero-MSK for that IMSK[j],
=
Jorge, Jouni, agree with the approach.=C2=A0

Jorge, please note that the same problem exists in PEAP Crypto-Bindi= ng TLV as specified in its documentation - when one side has an inner method that pro= vided MSK and another=C2=A0side has this inner method that didn't provi= de MSK.=C2=A0

[Joe] (catching u= p) With respect to the case that the method is an MSK generating mechanism = and and MSK is not generated/used.=C2=A0 I think the original intention was= that this case would be a protocol violation, ie if a method generates an = MSK it should be available for crypto-binding.=C2=A0 =C2=A0I'm concerne= d that allowing the fallback to 0 MSK actually will cause a security vulner= ability in compound=C2=A0binding.=C2=A0 Do we know if this method mismatch = is a problem in practice?=C2=A0=C2=A0
=C2=A0
There i= s also a case where no inner method is executed. For example, when client c= ertificate was received during TEAP outer tunnel establishment. In this cas= e we also need to use zero-MSK. For such case both values of the flag work = - "0 for zero-MSK" and "2 for MSK". This creates unnece= ssary ambiguity and thus would be better to request using flag's value = "0" for zero MSK in such case=C2=A0(today we use value "2&qu= ot; and it doesn't create ambiguity). However there's a question he= re: in case of TEAP certificate based authentication that is typically done= by running inner method EAP-TLS, should we allow in=C2=A0sending client ce= rtificate during TEAP tunnel establishment or inside the tunnel and this wa= y skipping EAP-TLS inner method? On one hand it makes authentication shorte= r. On the other hand it causes switching from MSK/EMSK exported by the inne= r method EAP-TLS to zero-MSK.

If we do allow skipp= ing any inner method then we need explicitly say that zero-MSK should be us= ed in such case.

I've started=C2=A0rebuilding = section "5.2. Intermediate = Compound Key Derivations" of the RFC according to the proposal on this thread=C2=A0a= nd will post it here shortly.=C2=A0

~ Oleg




On Mon, Apr 20, 2020= at 3:57 AM Jorge Vergara <jovergar@microsoft.com> wrote:
>And focusing on that "what to= do here.." part and the unused IMCK-zero[j] in the previous paragraph= ..
>How is this supposed to work when an inner EAP authentication method do= es not derive either MSK or EMSK?
>Intermediate result indication of success needs to be done and that imp= lies there needs to be Crypto-Binding TLV.
>But that TLV does not have option of indicating that neither EMSK Compo= und MAC nor MSK Compound MAC are present (Flags field has no value 0 define= d to do so).

I agree the 0 value should be explicitly listed for this purpose. Given the= design of the flags I think it is clear this was the intended usage and it= s omission was likely an oversight.

>So what are those fields (or one of them) supposed to be set to?
>And how is that selected for an inner EAP authentication method j?
>Does this depends on what happened with method j-1 (if one was present)= ?
>How would the correct IMCK[j] be determined by the peer and the server = if one of them derived MSK/EMSK but the other one did not derive either for= inner EAP method j?

Assuming we use the value 0 to indicate the state where one of the peers di= d not derive either MSK or EMSK, then I believe the RFC addresses this as M= SKi =3D 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK,= and both sides decided to continue the conversion, then both sides would u= se the zero-MSK for that IMSK[j],

Jorge Vergara

-----Original Message-----
From: Jouni Malinen <j@w1.f= i>
Sent: Thursday, April 16, 2020 3:25 AM
To: Oleg Pekar <oleg.pekar.2017@gmail.com>
Cc: Jorge Vergara <jovergar@microsoft.com>; EMU WG <emu@ietf.org>
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion

On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote:
> For TEAP errata 5770:
> Technically TEAP RFC suggests the implicit method of taking the
> correct IMSK[j] and all the subsequent keys after each inner method > via negotiation taking place in Crypto-Binding TLV exchange.

What is "the correct IMSK[j]" and where is this defined?

> Let's say we are on the inner method number j that supports both M= SK
> and EMSK and we are server which implementation generates both MSK and=
> EMSK for this inner method. We generated keys according to the rules <= br> > below - two sets, for IMSK[j] derived from inner method EMSK and for <= br> > IMSK[j] equal to inner method MSK. Because we don't know whether <= br> > client implementation supports both MSK and EMSK.
>
> S-IMCK[0] =3D session_key_seed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For j =3D 1 to n-1 do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMCK[j] =3D TLS-PRF(S-IMCK[j-= 1], "Inner Methods Compound Keys",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IMSK[j], = 60)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S-IMCK[j] =3D first 40 octets= of IMCK[j]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CMK[j] =3D last 20 octets of = IMCK[j]
>
>
> So we have two CMK[j] and we create Crypto-Binding TLV with both
> Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in =
> response and we can understand from it whether it supports EMSK for > this inner method or not. And here we can decide which version of
> IMCK[j] to take for this inner method - derived from EMSK or MSK. This=
> is just not explicitly specified in the RFC.

Is this the proposed definition of "the correct IMSK[J]"? In othe= r words, is this to be understood to have two (or three since we have the n= o MSK/EMSK case as well) variants of IMSK[j] during an execution of an inte= rnal AP authentication method and a single one of those variants is selecte= d as _the correct_ IMSK[j] at the successful conclusion of this inner authe= ntication method?

Would this single "correct IMSK[j]" then be used for deriving the= different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when d= eriving EMSK-based-IMSK[j+1]? In other words, is this to work by having all= following inner authentication rounds and MSK/EMSK derivation to behave as= if the other variants of IMSK[j] never really existed?

> Could this method work? Should we make it more clearly specified? Or <= br> > should we change the protocol to arrive explicitly to the
> understanding which type
> (MSK/EMSK) of IMSK[j] to use?

Regardless of what is done for the design, it will absolutely need to be sp= ecified more clearly.

If I understood the proposed design correctly, this should be defined with = something like following:

For each successful inner EAP authentication method, derive IMCK-MSK[j] (if= MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was der= ived by the inner method), derive IMSK-zero[j] (for all cases). Derive CMK-= MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if availab= le). Generate Crypto-Binding TLV with all available Compound MAC values. Al= so verify Crypto-Binding TLV with all available Compound MAC values. After = both ends have transmitted and received Crypto-Binding TLV, set IMSK[j] to = be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or set IMSK[j] to = be IMCK-MSK[j] if both ends included MSK Compound MAC but either end did no= t include EMSK Compound MAC, or <what to do here or can this even happen= ?>. Set S-IMCK[j] based on this IMSK[j]. This results in there being onl= y a single S-IMCK[j] and MSK/EMSK derivation being well defined.

And focusing on that "what to do here.." part and the unused IMCK= -zero[j] in the previous paragraph.. How is this supposed to work when an i= nner EAP authentication method does not derive either MSK or EMSK? Intermed= iate result indication of success needs to be done and that implies there n= eeds to be Crypto-Binding TLV. But that TLV does not have option of indicat= ing that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags = field has no value 0 defined to do so).
So what are those fields (or one of them) supposed to be set to? And how is= that selected for an inner EAP authentication method j? Does this depends = on what happened with method j-1 (if one was present)? How would the correc= t IMCK[j] be determined by the peer and the server if one of them derived M= SK/EMSK but the other one did not derive either for inner EAP method j?

--
Jouni Malinen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 PGP id EFC895FA
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--0000000000006bf04705a8b84dbf-- From nobody Mon Jun 22 21:06:14 2020 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 C593F3A172E for ; Mon, 22 Jun 2020 21:06:12 -0700 (PDT) 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=microsoft.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 YPqtaSV_mCyp for ; Mon, 22 Jun 2020 21:06:07 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2093.outbound.protection.outlook.com [40.107.237.93]) (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 C97D63A172D for ; Mon, 22 Jun 2020 21:06:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m6WrOP/RLGPtCFQbouQSiMVmvc9mnKiqI0bqB2NZBgBwYQQyoRKkEFH9jNCmpvNYLasY+wiIMWM15oo8s+YbSQgnbNFBLe1ZG5bCek5W/Hxb2sp2cfgwF5/io6gQEx+fs75223fFhLmVPCdsUZmwF/J4tMYZgJo0kxKxPf6GZqwbdv1suBHmMnki66sdvd4WSiknJMRg1fqoxYzqirhTHlZB/GvUEAg/A4NVYONEWqbOPjs5zn/LIOZeaz2gafMGUCUVL0bQSxmwEcGE7l0tea7awV5Ua9GXAQfdfktu5dcsUesoH68Hc7NpoCKHIIgNN+SjpOI3Q75O3LWSZT0LcQ== 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=/h9yYRFHewVEOOT35c9SRFf7ZdgnS1J+a4L7X+nv75I=; b=jyhoz8gQ2EtGrxt0HFxjE6eUgHewHbfJUULpTKlzmaQ4N1ITvqjuWSMTe2szVr7OFzn5cMjDVGQKpL6kD/AwplFu6hH6U99Qj7gzrAad814kYkoUQNmsByz62qjaxjlpk/1siQ5zISKdHTePkWuj1yCmx6ANiUEX0DIp61UDRKO+u43TLpfNWGEQPwOfYn+cNpaLnQJAo1Vo4Os8BjTxOM+d3vnY+45HlAUPtRZfheI5AeFPtoiOJkijbj1McL4lJZjsNgcDPseT1Y8OeJut7tjseYeHiCDwbf1ot2qsHgSY1hTb0Vc3Iz+6O60GLjhZENXecRWfvlchROe2YTLkSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/h9yYRFHewVEOOT35c9SRFf7ZdgnS1J+a4L7X+nv75I=; b=PbzO/2yLvPp63mHdrGTmKsxUGMgAiEiTeSGj2GbbBIu2k7AYDqBiodOnY8xhRLJa5KFhMs2tC/gqVsgzfl1duj8U5En1ReNfe71FDvwuN3d5O6B61R1LaCIFTeq6PY3RW64kQEUIlEIFxkgkSfKRfVaubZMUrH6zQL/OCeNGFLs= Received: from CH2PR21MB1381.namprd21.prod.outlook.com (20.180.12.12) by CH2PR21MB1495.namprd21.prod.outlook.com (20.180.11.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.4; Tue, 23 Jun 2020 04:06:05 +0000 Received: from CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::ed84:e1bc:d1e6:76f8]) by CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::ed84:e1bc:d1e6:76f8%7]) with mapi id 15.20.3153.005; Tue, 23 Jun 2020 04:06:05 +0000 From: Jorge Vergara To: Joseph Salowey , Oleg Pekar CC: Jouni Malinen , EMU WG Thread-Topic: [Emu] draft-dekok-emu-tls-eap-types discussion Thread-Index: AQHWCflAito/q8SdbkqYuDgLHK2lQ6huIjRAgAxOtACAAS2kgIAFpVSwgAK11wCAYhX/AIAAATvA Date: Tue, 23 Jun 2020 04:06:04 +0000 Message-ID: References: <20200416102445.GA8757@w1.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-23T04:06:02Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=2decff1f-e82b-4ff1-a5fa-e18dba7d89e2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: salowey.net; dkim=none (message not signed) header.d=none;salowey.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:0:1a0f:3fa1:53a3:8a84] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 61bb2f66-923f-40ee-1870-08d8172ac005 x-ms-traffictypediagnostic: CH2PR21MB1495: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04433051BF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WOzo2Qs89/dpjC9zaoE1ZgvKhwU9EwjE+svblivp/bSAAmSrCWhaTh7TG3VB9HQ6lDddIJ27/xl4s+s99AZJ7zbxNS6z/rLNbxS7GF/mWOTswtN3B9mDeY2aEzL3jR0c8FWuiktp62yEjORJ3w1nVCeX/WxXjVU7Xh7XzFX/eOupF8DDVUpKOMy9P2uX9VH4UGq3BjSoqWago8ozKa4jDFKpPin+b6AxvKDnAqPl6ab1YcxsthodwpI0md9RlJL91pQ9C1U+6CnQXpUd9SmSyARV9ehX/HTEp5WPh5rbABXZhWsofIw8GDIX+4To8cr9jTJcthFx9xwH6r8bnAM6OI3X4YSjknpULK7AuF8TP2PAux28ibn3+38xp6gRrFdTaCqC6eZRi21xy/SYFATfrA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR21MB1381.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(366004)(376002)(136003)(6506007)(55016002)(83380400001)(8676002)(966005)(9686003)(8936002)(10290500003)(86362001)(82950400001)(76236003)(82960400001)(478600001)(52536014)(4326008)(166002)(186003)(71200400001)(64756008)(54906003)(33656002)(66556008)(30864003)(316002)(7696005)(66476007)(66946007)(2906002)(53546011)(66446008)(110136005)(8990500004)(5660300002)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: K/CPQEZ0BrowwnuGTgG5vJKQka3gn2lR4btgXz1pokrfMVLFgrbMlgwBqC5hjwIEQTK2Rr9Oy0iqghw3a/Y0/5MnQPHAfLiyfIcd9/yny0S0u2H4y9l56FTkCRcDaEFsyqHsv/exeGnRcQSo3Z5ERPJRVWBkiichYEFjA8SEv2jBlik+WEowdFWyMcXbb56fgLIOWbmyLbfPNNpBHk6AE0CKMLFQyXy2c68oM9osc9/PS1ynW/Xbsw/DyatET0OI3sXd/YXXgxriWf1TSVVf6wRRmgVmi4NgdLYIdQ8Yki4oU8SAsexqSARrlVK4xWzN2N0kvn/TGJkTZtBVdvDV0dlgpWo9NcWBvFemPqhQJ6YJ33N3njCZ5NSmiSlF1Q7Fy/LUiuWobHvFZWaxVcQYfOH0W1gkps0kL71ClEtUPJHxy+hiYQ5oAm3J1vNW6Kd4YKLcAbfXurQhYKWJjlwtDJe53+C8LipHqWyuEao2z2Ow93kRwunKycDZpIP1hp0nZ14AhoYKd7EbrcT2DbS9J+FYOdHPzxh9no48SMSG1yE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR21MB13810828EC6E27F8EBF43E21D1940CH2PR21MB1381namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR21MB1381.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61bb2f66-923f-40ee-1870-08d8172ac005 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 04:06:04.9574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1/J65glFLlK/uvnT+Q1DfCSi0O61ZU4wR/smJgqVoJxcYLhiELK8cJAhliKMFWWNW754KNGo3mFhblH7kB26RA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR21MB1495 Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 23 Jun 2020 04:06:13 -0000 --_000_CH2PR21MB13810828EC6E27F8EBF43E21D1940CH2PR21MB1381namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PltKb2VdIChjYXRjaGluZyB1cCkgV2l0aCByZXNwZWN0IHRvIHRoZSBjYXNlIHRoYXQgdGhlIG1l dGhvZCBpcyBhbiBNU0sgZ2VuZXJhdGluZyBtZWNoYW5pc20gYW5kIGFuZCBNU0sgaXMgbm90IGdl bmVyYXRlZC91c2VkLiAgSSB0aGluayB0aGUgb3JpZ2luYWwgaW50ZW50aW9uIHdhcyB0aGF0IHRo aXMgY2FzZSB3b3VsZCBiZSBhIHByb3RvY29sIHZpb2xhdGlvbiwgaWUgaWYgYSBtZXRob2QgZ2Vu ZXJhdGVzIGFuIE1TSyBpdCBzaG91bGQgYmUgYXZhaWxhYmxlIGZvciBjcnlwdG8tYmluZGluZy4g ICBJJ20gY29uY2VybmVkIHRoYXQgYWxsb3dpbmcgdGhlIGZhbGxiYWNrIHRvIDAgTVNLIGFjdHVh bGx5IHdpbGwgY2F1c2UgYSBzZWN1cml0eSB2dWxuZXJhYmlsaXR5IGluIGNvbXBvdW5kIGJpbmRp bmcuICBEbyB3ZSBrbm93IGlmIHRoaXMgbWV0aG9kIG1pc21hdGNoIGlzIGEgcHJvYmxlbSBpbiBw cmFjdGljZT8NCg0KW2pvdmVyZ2FyXSBJIGFncmVlIHRoYXQgaWYgYSBtZXRob2QgZ2VuZXJhdGVz IGFuIE1TSyBpdCBzaG91bGQgZ2VuZXJhbGx5IGJlIHVzZWQgZm9yIGNyeXB0by1iaW5kaW5nLiBC dXQgdGhpcyBkb2VzIG5vdCBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIGEgbWVjaGFuaXNtIGZvciBl YWNoIHBhcnR5IChjbGllbnQvc2VydmVyKSB0byBjb21tdW5pY2F0ZSB3aGF0IGtpbmQgb2YgY3J5 cHRvLWJpbmRpbmcgdGhleSBhcmUgc2VuZGluZy4gVGhlIGNsaWVudC9zZXJ2ZXIgaXMgZnJlZSB0 byByZWplY3QgdGhlIGNyeXB0by1iaW5kaW5nIGlmIHRoZSBwZWVyIGlzIHVuYWJsZSB0byBwcm9k dWNlIGEgY3J5cHRvLWJpbmRpbmcgdGhhdCBzYXRpc2ZpZXMgdGhlIG1pbmltdW0gcG9saWN5IG9m IHRoZSBpbXBsZW1lbnRhdGlvbi4NCg0KRm9yIGV4YW1wbGUsIGlmIEVBUC1UTFMgaXMgdXNlZCBh cyBhbiBpbm5lciBtZXRob2QsIGFuZCBhIGNsaWVudCBzZW5kcyBhIHplcm8tTVNLLCBJIHdvdWxk IGZ1bGx5IGV4cGVjdCB0aGUgc2VydmVyIHRvIHJlamVjdCB0aGUgY29ubmVjdGlvbiDigJMgbm90 IGZhbGxiYWNrIHRvIHplcm8tTVNLLiBJIHdvdWxkIGV4cGVjdCBhIGNsaWVudCB0byBoYXZlIHNp bWlsYXIgbWluaW11bSBzZWN1cml0eSBwb2xpY2llcyBpdCB3b3VsZCBhY2NlcHQgZm9yIGVhY2gg bWV0aG9kLg0KDQpBcyB0byB3aGV0aGVyIG1ldGhvZCBtaXNtYXRjaCBpcyBhIHByb2JsZW0gaW4g cHJhY3RpY2Ug4oCTIHllcywgdG8gYW4gZXh0ZW50LiBXaW5kb3dzIGRvZXMgbm90IGdlbmVyYXRl IEVNU0sgZm9yIEVBUC1UTFMgZGVzcGl0ZSBpdCBiZWluZyBzcGVjaWZpZWQgaW4gdGhlIFJGQywg c28gdGhlIGNyeXB0by1iaW5kaW5nIHNlbnQgdG8gdGhlIHNlcnZlciBpcyBNU0sgYmFzZWQuIElm IGEgc2VydmVy4oCZcyBwb2xpY3kgcmVxdWlyZXMgRU1TSywgdGhlbiBXaW5kb3dzIGNhbuKAmXQg Y29ubmVjdC4gVGhpcyBpcyBjZXJ0YWlubHkgYSBXaW5kb3dzIGZlYXR1cmUgZ2FwIOKAkyBidXQg c2VydmVycyBhcmUgZnJlZSB0byBkZWNsaW5lIHRoZSBjb25uZWN0aW9uIGlmIHRoZXkgZG8gbm90 IHdhbnQgdG8gZG93bmdyYWRlIHRvIGFuIE1TSyBiYXNlZCBjcnlwdG8gYmluZGluZy4NCg0KRnJv bTogSm9zZXBoIFNhbG93ZXkgPGpvZUBzYWxvd2V5Lm5ldD4NClNlbnQ6IE1vbmRheSwgSnVuZSAy MiwgMjAyMCA4OjUzIFBNDQpUbzogT2xlZyBQZWthciA8b2xlZy5wZWthci4yMDE3QGdtYWlsLmNv bT4NCkNjOiBKb3JnZSBWZXJnYXJhIDxqb3ZlcmdhckBtaWNyb3NvZnQuY29tPjsgSm91bmkgTWFs aW5lbiA8akB3MS5maT47IEVNVSBXRyA8ZW11QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtFbXVd IGRyYWZ0LWRla29rLWVtdS10bHMtZWFwLXR5cGVzIGRpc2N1c3Npb24NCg0KDQoNCk9uIFR1ZSwg QXByIDIxLCAyMDIwIGF0IDExOjAyIEFNIE9sZWcgUGVrYXIgPG9sZWcucGVrYXIuMjAxN0BnbWFp bC5jb208bWFpbHRvOm9sZWcucGVrYXIuMjAxN0BnbWFpbC5jb20+PiB3cm90ZToNCj5BbmQgZm9j dXNpbmcgb24gdGhhdCAid2hhdCB0byBkbyBoZXJlLi4iIHBhcnQgYW5kIHRoZSB1bnVzZWQgSU1D Sy16ZXJvW2pdIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGguLg0KPkhvdyBpcyB0aGlzIHN1cHBv c2VkIHRvIHdvcmsgd2hlbiBhbiBpbm5lciBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9kIGRvZXMg bm90IGRlcml2ZSBlaXRoZXIgTVNLIG9yIEVNU0s/DQo+SW50ZXJtZWRpYXRlIHJlc3VsdCBpbmRp Y2F0aW9uIG9mIHN1Y2Nlc3MgbmVlZHMgdG8gYmUgZG9uZSBhbmQgdGhhdCBpbXBsaWVzIHRoZXJl IG5lZWRzIHRvIGJlIENyeXB0by1CaW5kaW5nIFRMVi4NCj5CdXQgdGhhdCBUTFYgZG9lcyBub3Qg aGF2ZSBvcHRpb24gb2YgaW5kaWNhdGluZyB0aGF0IG5laXRoZXIgRU1TSyBDb21wb3VuZCBNQUMg bm9yIE1TSyBDb21wb3VuZCBNQUMgYXJlIHByZXNlbnQgKEZsYWdzIGZpZWxkIGhhcyBubyB2YWx1 ZSAwIGRlZmluZWQgdG8gZG8gc28pLg0KSSBhZ3JlZSB0aGUgMCB2YWx1ZSBzaG91bGQgYmUgZXhw bGljaXRseSBsaXN0ZWQgZm9yIHRoaXMgcHVycG9zZS4gR2l2ZW4gdGhlIGRlc2lnbiBvZiB0aGUg ZmxhZ3MgSSB0aGluayBpdCBpcyBjbGVhciB0aGlzIHdhcyB0aGUgaW50ZW5kZWQgdXNhZ2UgYW5k IGl0cyBvbWlzc2lvbiB3YXMgbGlrZWx5IGFuIG92ZXJzaWdodC4NCj5TbyB3aGF0IGFyZSB0aG9z ZSBmaWVsZHMgKG9yIG9uZSBvZiB0aGVtKSBzdXBwb3NlZCB0byBiZSBzZXQgdG8/DQo+QW5kIGhv dyBpcyB0aGF0IHNlbGVjdGVkIGZvciBhbiBpbm5lciBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9k IGo/DQo+RG9lcyB0aGlzIGRlcGVuZHMgb24gd2hhdCBoYXBwZW5lZCB3aXRoIG1ldGhvZCBqLTEg KGlmIG9uZSB3YXMgcHJlc2VudCk/DQo+SG93IHdvdWxkIHRoZSBjb3JyZWN0IElNQ0tbal0gYmUg ZGV0ZXJtaW5lZCBieSB0aGUgcGVlciBhbmQgdGhlIHNlcnZlciBpZiBvbmUgb2YgdGhlbSBkZXJp dmVkIE1TSy9FTVNLIGJ1dCB0aGUgb3RoZXIgb25lIGRpZCBub3QgZGVyaXZlIGVpdGhlciBmb3Ig aW5uZXIgRUFQIG1ldGhvZCBqPw0KQXNzdW1pbmcgd2UgdXNlIHRoZSB2YWx1ZSAwIHRvIGluZGlj YXRlIHRoZSBzdGF0ZSB3aGVyZSBvbmUgb2YgdGhlIHBlZXJzIGRpZCBub3QgZGVyaXZlIGVpdGhl ciBNU0sgb3IgRU1TSywgdGhlbiBJIGJlbGlldmUgdGhlIFJGQyBhZGRyZXNzZXMgdGhpcyBhcyBN U0tpID0gMzIgb2N0ZXRzIG9mIDB4MDBzLiBTbyBpZiBvbmUgc2lkZSBjYWxjdWxhdGVkIG5laXRo ZXIgTVNLIG5vciBFTVNLLCBhbmQgYm90aCBzaWRlcyBkZWNpZGVkIHRvIGNvbnRpbnVlIHRoZSBj b252ZXJzaW9uLCB0aGVuIGJvdGggc2lkZXMgd291bGQgdXNlIHRoZSB6ZXJvLU1TSyBmb3IgdGhh dCBJTVNLW2pdLA0KDQpKb3JnZSwgSm91bmksIGFncmVlIHdpdGggdGhlIGFwcHJvYWNoLg0KDQpK b3JnZSwgcGxlYXNlIG5vdGUgdGhhdCB0aGUgc2FtZSBwcm9ibGVtIGV4aXN0cyBpbiBQRUFQIENy eXB0by1CaW5kaW5nIFRMViBhcyBzcGVjaWZpZWQgaW4gaXRzIGRvY3VtZW50YXRpb248aHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZG9jcy5taWNyb3NvZnQuY29tJTJGZW4tdXMlMkZvcGVuc3BlY3MlMkZ3aW5kb3dzX3Byb3Rv Y29scyUyRm1zLXBlYXAlMkZlYmIyYjEyYi1jZDUzLTRmM2EtYWZlZC0zNjU4ODU2NmM3YzImZGF0 YT0wMiU3QzAxJTdDam92ZXJnYXIlNDBtaWNyb3NvZnQuY29tJTdDZjY5MTA2MWY1OTYwNDBiZTg4 MmQwOGQ4MTcyOGZlNWYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM3Mjg0ODEyMTMzNjI1MDk5JnNkYXRhPTlCJTJCckdGOUFkdVhYdUVSWGJEaDR0VFRUNEkl MkJuVmpPSTFHckx3V0pOUGtZJTNEJnJlc2VydmVkPTA+IC0gd2hlbiBvbmUgc2lkZSBoYXMgYW4g aW5uZXIgbWV0aG9kIHRoYXQgcHJvdmlkZWQgTVNLIGFuZCBhbm90aGVyIHNpZGUgaGFzIHRoaXMg aW5uZXIgbWV0aG9kIHRoYXQgZGlkbid0IHByb3ZpZGUgTVNLLg0KDQpbSm9lXSAoY2F0Y2hpbmcg dXApIFdpdGggcmVzcGVjdCB0byB0aGUgY2FzZSB0aGF0IHRoZSBtZXRob2QgaXMgYW4gTVNLIGdl bmVyYXRpbmcgbWVjaGFuaXNtIGFuZCBhbmQgTVNLIGlzIG5vdCBnZW5lcmF0ZWQvdXNlZC4gIEkg dGhpbmsgdGhlIG9yaWdpbmFsIGludGVudGlvbiB3YXMgdGhhdCB0aGlzIGNhc2Ugd291bGQgYmUg YSBwcm90b2NvbCB2aW9sYXRpb24sIGllIGlmIGEgbWV0aG9kIGdlbmVyYXRlcyBhbiBNU0sgaXQg c2hvdWxkIGJlIGF2YWlsYWJsZSBmb3IgY3J5cHRvLWJpbmRpbmcuICAgSSdtIGNvbmNlcm5lZCB0 aGF0IGFsbG93aW5nIHRoZSBmYWxsYmFjayB0byAwIE1TSyBhY3R1YWxseSB3aWxsIGNhdXNlIGEg c2VjdXJpdHkgdnVsbmVyYWJpbGl0eSBpbiBjb21wb3VuZCBiaW5kaW5nLiAgRG8gd2Uga25vdyBp ZiB0aGlzIG1ldGhvZCBtaXNtYXRjaCBpcyBhIHByb2JsZW0gaW4gcHJhY3RpY2U/DQoNClRoZXJl IGlzIGFsc28gYSBjYXNlIHdoZXJlIG5vIGlubmVyIG1ldGhvZCBpcyBleGVjdXRlZC4gRm9yIGV4 YW1wbGUsIHdoZW4gY2xpZW50IGNlcnRpZmljYXRlIHdhcyByZWNlaXZlZCBkdXJpbmcgVEVBUCBv dXRlciB0dW5uZWwgZXN0YWJsaXNobWVudC4gSW4gdGhpcyBjYXNlIHdlIGFsc28gbmVlZCB0byB1 c2UgemVyby1NU0suIEZvciBzdWNoIGNhc2UgYm90aCB2YWx1ZXMgb2YgdGhlIGZsYWcgd29yayAt ICIwIGZvciB6ZXJvLU1TSyIgYW5kICIyIGZvciBNU0siLiBUaGlzIGNyZWF0ZXMgdW5uZWNlc3Nh cnkgYW1iaWd1aXR5IGFuZCB0aHVzIHdvdWxkIGJlIGJldHRlciB0byByZXF1ZXN0IHVzaW5nIGZs YWcncyB2YWx1ZSAiMCIgZm9yIHplcm8gTVNLIGluIHN1Y2ggY2FzZSAodG9kYXkgd2UgdXNlIHZh bHVlICIyIiBhbmQgaXQgZG9lc24ndCBjcmVhdGUgYW1iaWd1aXR5KS4gSG93ZXZlciB0aGVyZSdz IGEgcXVlc3Rpb24gaGVyZTogaW4gY2FzZSBvZiBURUFQIGNlcnRpZmljYXRlIGJhc2VkIGF1dGhl bnRpY2F0aW9uIHRoYXQgaXMgdHlwaWNhbGx5IGRvbmUgYnkgcnVubmluZyBpbm5lciBtZXRob2Qg RUFQLVRMUywgc2hvdWxkIHdlIGFsbG93IGluIHNlbmRpbmcgY2xpZW50IGNlcnRpZmljYXRlIGR1 cmluZyBURUFQIHR1bm5lbCBlc3RhYmxpc2htZW50IG9yIGluc2lkZSB0aGUgdHVubmVsIGFuZCB0 aGlzIHdheSBza2lwcGluZyBFQVAtVExTIGlubmVyIG1ldGhvZD8gT24gb25lIGhhbmQgaXQgbWFr ZXMgYXV0aGVudGljYXRpb24gc2hvcnRlci4gT24gdGhlIG90aGVyIGhhbmQgaXQgY2F1c2VzIHN3 aXRjaGluZyBmcm9tIE1TSy9FTVNLIGV4cG9ydGVkIGJ5IHRoZSBpbm5lciBtZXRob2QgRUFQLVRM UyB0byB6ZXJvLU1TSy4NCg0KSWYgd2UgZG8gYWxsb3cgc2tpcHBpbmcgYW55IGlubmVyIG1ldGhv ZCB0aGVuIHdlIG5lZWQgZXhwbGljaXRseSBzYXkgdGhhdCB6ZXJvLU1TSyBzaG91bGQgYmUgdXNl ZCBpbiBzdWNoIGNhc2UuDQoNCkkndmUgc3RhcnRlZCByZWJ1aWxkaW5nIHNlY3Rpb24gIjUuMjxo dHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM3MTcwJTIzc2VjdGlvbi01LjImZGF0 YT0wMiU3QzAxJTdDam92ZXJnYXIlNDBtaWNyb3NvZnQuY29tJTdDZjY5MTA2MWY1OTYwNDBiZTg4 MmQwOGQ4MTcyOGZlNWYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM3Mjg0ODEyMTMzNjM1MDkzJnNkYXRhPTd4bUVxMXJOSFlTcTdxcWElMkZTdDRaNFhFU3FD YzJGWFR5JTJGNVg4S29iJTJGQmclM0QmcmVzZXJ2ZWQ9MD4uIEludGVybWVkaWF0ZSBDb21wb3Vu ZCBLZXkgRGVyaXZhdGlvbnMiIG9mIHRoZSBSRkMgYWNjb3JkaW5nIHRvIHRoZSBwcm9wb3NhbCBv biB0aGlzIHRocmVhZCBhbmQgd2lsbCBwb3N0IGl0IGhlcmUgc2hvcnRseS4NCg0KfiBPbGVnDQoN Cg0KDQoNCk9uIE1vbiwgQXByIDIwLCAyMDIwIGF0IDM6NTcgQU0gSm9yZ2UgVmVyZ2FyYSA8am92 ZXJnYXJAbWljcm9zb2Z0LmNvbTxtYWlsdG86am92ZXJnYXJAbWljcm9zb2Z0LmNvbT4+IHdyb3Rl Og0KPkFuZCBmb2N1c2luZyBvbiB0aGF0ICJ3aGF0IHRvIGRvIGhlcmUuLiIgcGFydCBhbmQgdGhl IHVudXNlZCBJTUNLLXplcm9bal0gaW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaC4uDQo+SG93IGlz IHRoaXMgc3VwcG9zZWQgdG8gd29yayB3aGVuIGFuIGlubmVyIEVBUCBhdXRoZW50aWNhdGlvbiBt ZXRob2QgZG9lcyBub3QgZGVyaXZlIGVpdGhlciBNU0sgb3IgRU1TSz8NCj5JbnRlcm1lZGlhdGUg cmVzdWx0IGluZGljYXRpb24gb2Ygc3VjY2VzcyBuZWVkcyB0byBiZSBkb25lIGFuZCB0aGF0IGlt cGxpZXMgdGhlcmUgbmVlZHMgdG8gYmUgQ3J5cHRvLUJpbmRpbmcgVExWLg0KPkJ1dCB0aGF0IFRM ViBkb2VzIG5vdCBoYXZlIG9wdGlvbiBvZiBpbmRpY2F0aW5nIHRoYXQgbmVpdGhlciBFTVNLIENv bXBvdW5kIE1BQyBub3IgTVNLIENvbXBvdW5kIE1BQyBhcmUgcHJlc2VudCAoRmxhZ3MgZmllbGQg aGFzIG5vIHZhbHVlIDAgZGVmaW5lZCB0byBkbyBzbykuDQoNCkkgYWdyZWUgdGhlIDAgdmFsdWUg c2hvdWxkIGJlIGV4cGxpY2l0bHkgbGlzdGVkIGZvciB0aGlzIHB1cnBvc2UuIEdpdmVuIHRoZSBk ZXNpZ24gb2YgdGhlIGZsYWdzIEkgdGhpbmsgaXQgaXMgY2xlYXIgdGhpcyB3YXMgdGhlIGludGVu ZGVkIHVzYWdlIGFuZCBpdHMgb21pc3Npb24gd2FzIGxpa2VseSBhbiBvdmVyc2lnaHQuDQoNCj5T byB3aGF0IGFyZSB0aG9zZSBmaWVsZHMgKG9yIG9uZSBvZiB0aGVtKSBzdXBwb3NlZCB0byBiZSBz ZXQgdG8/DQo+QW5kIGhvdyBpcyB0aGF0IHNlbGVjdGVkIGZvciBhbiBpbm5lciBFQVAgYXV0aGVu dGljYXRpb24gbWV0aG9kIGo/DQo+RG9lcyB0aGlzIGRlcGVuZHMgb24gd2hhdCBoYXBwZW5lZCB3 aXRoIG1ldGhvZCBqLTEgKGlmIG9uZSB3YXMgcHJlc2VudCk/DQo+SG93IHdvdWxkIHRoZSBjb3Jy ZWN0IElNQ0tbal0gYmUgZGV0ZXJtaW5lZCBieSB0aGUgcGVlciBhbmQgdGhlIHNlcnZlciBpZiBv bmUgb2YgdGhlbSBkZXJpdmVkIE1TSy9FTVNLIGJ1dCB0aGUgb3RoZXIgb25lIGRpZCBub3QgZGVy aXZlIGVpdGhlciBmb3IgaW5uZXIgRUFQIG1ldGhvZCBqPw0KDQpBc3N1bWluZyB3ZSB1c2UgdGhl IHZhbHVlIDAgdG8gaW5kaWNhdGUgdGhlIHN0YXRlIHdoZXJlIG9uZSBvZiB0aGUgcGVlcnMgZGlk IG5vdCBkZXJpdmUgZWl0aGVyIE1TSyBvciBFTVNLLCB0aGVuIEkgYmVsaWV2ZSB0aGUgUkZDIGFk ZHJlc3NlcyB0aGlzIGFzIE1TS2kgPSAzMiBvY3RldHMgb2YgMHgwMHMuIFNvIGlmIG9uZSBzaWRl IGNhbGN1bGF0ZWQgbmVpdGhlciBNU0sgbm9yIEVNU0ssIGFuZCBib3RoIHNpZGVzIGRlY2lkZWQg dG8gY29udGludWUgdGhlIGNvbnZlcnNpb24sIHRoZW4gYm90aCBzaWRlcyB3b3VsZCB1c2UgdGhl IHplcm8tTVNLIGZvciB0aGF0IElNU0tbal0sDQoNCkpvcmdlIFZlcmdhcmENCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvdW5pIE1hbGluZW4gPGpAdzEuZmk8bWFpbHRvOmpA dzEuZmk+Pg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDIwIDM6MjUgQU0NClRvOiBPbGVn IFBla2FyIDxvbGVnLnBla2FyLjIwMTdAZ21haWwuY29tPG1haWx0bzpvbGVnLnBla2FyLjIwMTdA Z21haWwuY29tPj4NCkNjOiBKb3JnZSBWZXJnYXJhIDxqb3ZlcmdhckBtaWNyb3NvZnQuY29tPG1h aWx0bzpqb3ZlcmdhckBtaWNyb3NvZnQuY29tPj47IEVNVSBXRyA8ZW11QGlldGYub3JnPG1haWx0 bzplbXVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtFbXVdIGRyYWZ0LWRla29rLWVtdS10bHMt ZWFwLXR5cGVzIGRpc2N1c3Npb24NCg0KT24gV2VkLCBBcHIgMTUsIDIwMjAgYXQgMDc6MjU6MDhQ TSArMDMwMCwgT2xlZyBQZWthciB3cm90ZToNCj4gRm9yIFRFQVAgZXJyYXRhIDU3NzA6DQo+IFRl Y2huaWNhbGx5IFRFQVAgUkZDIHN1Z2dlc3RzIHRoZSBpbXBsaWNpdCBtZXRob2Qgb2YgdGFraW5n IHRoZQ0KPiBjb3JyZWN0IElNU0tbal0gYW5kIGFsbCB0aGUgc3Vic2VxdWVudCBrZXlzIGFmdGVy IGVhY2ggaW5uZXIgbWV0aG9kDQo+IHZpYSBuZWdvdGlhdGlvbiB0YWtpbmcgcGxhY2UgaW4gQ3J5 cHRvLUJpbmRpbmcgVExWIGV4Y2hhbmdlLg0KDQpXaGF0IGlzICJ0aGUgY29ycmVjdCBJTVNLW2pd IiBhbmQgd2hlcmUgaXMgdGhpcyBkZWZpbmVkPw0KDQo+IExldCdzIHNheSB3ZSBhcmUgb24gdGhl IGlubmVyIG1ldGhvZCBudW1iZXIgaiB0aGF0IHN1cHBvcnRzIGJvdGggTVNLDQo+IGFuZCBFTVNL IGFuZCB3ZSBhcmUgc2VydmVyIHdoaWNoIGltcGxlbWVudGF0aW9uIGdlbmVyYXRlcyBib3RoIE1T SyBhbmQNCj4gRU1TSyBmb3IgdGhpcyBpbm5lciBtZXRob2QuIFdlIGdlbmVyYXRlZCBrZXlzIGFj Y29yZGluZyB0byB0aGUgcnVsZXMNCj4gYmVsb3cgLSB0d28gc2V0cywgZm9yIElNU0tbal0gZGVy aXZlZCBmcm9tIGlubmVyIG1ldGhvZCBFTVNLIGFuZCBmb3INCj4gSU1TS1tqXSBlcXVhbCB0byBp bm5lciBtZXRob2QgTVNLLiBCZWNhdXNlIHdlIGRvbid0IGtub3cgd2hldGhlcg0KPiBjbGllbnQg aW1wbGVtZW50YXRpb24gc3VwcG9ydHMgYm90aCBNU0sgYW5kIEVNU0suDQo+DQo+IFMtSU1DS1sw XSA9IHNlc3Npb25fa2V5X3NlZWQNCj4gICAgICAgRm9yIGogPSAxIHRvIG4tMSBkbw0KPiAgICAg ICAgICAgIElNQ0tbal0gPSBUTFMtUFJGKFMtSU1DS1tqLTFdLCAiSW5uZXIgTWV0aG9kcyBDb21w b3VuZCBLZXlzIiwNCj4gICAgICAgICAgICAgICAgIElNU0tbal0sIDYwKQ0KPiAgICAgICAgICAg IFMtSU1DS1tqXSA9IGZpcnN0IDQwIG9jdGV0cyBvZiBJTUNLW2pdDQo+ICAgICAgICAgICAgQ01L W2pdID0gbGFzdCAyMCBvY3RldHMgb2YgSU1DS1tqXQ0KPg0KPg0KPiBTbyB3ZSBoYXZlIHR3byBD TUtbal0gYW5kIHdlIGNyZWF0ZSBDcnlwdG8tQmluZGluZyBUTFYgd2l0aCBib3RoDQo+IENvbXBv dW5kIE1BQyBmb3IgTVNLIGFuZCBFTVNLLiBUaGUgY2xpZW50IHNlbmRzIENyeXB0by1CaW5kaW5n IFRMViBpbg0KPiByZXNwb25zZSBhbmQgd2UgY2FuIHVuZGVyc3RhbmQgZnJvbSBpdCB3aGV0aGVy IGl0IHN1cHBvcnRzIEVNU0sgZm9yDQo+IHRoaXMgaW5uZXIgbWV0aG9kIG9yIG5vdC4gQW5kIGhl cmUgd2UgY2FuIGRlY2lkZSB3aGljaCB2ZXJzaW9uIG9mDQo+IElNQ0tbal0gdG8gdGFrZSBmb3Ig dGhpcyBpbm5lciBtZXRob2QgLSBkZXJpdmVkIGZyb20gRU1TSyBvciBNU0suIFRoaXMNCj4gaXMg anVzdCBub3QgZXhwbGljaXRseSBzcGVjaWZpZWQgaW4gdGhlIFJGQy4NCg0KSXMgdGhpcyB0aGUg cHJvcG9zZWQgZGVmaW5pdGlvbiBvZiAidGhlIGNvcnJlY3QgSU1TS1tKXSI/IEluIG90aGVyIHdv cmRzLCBpcyB0aGlzIHRvIGJlIHVuZGVyc3Rvb2QgdG8gaGF2ZSB0d28gKG9yIHRocmVlIHNpbmNl IHdlIGhhdmUgdGhlIG5vIE1TSy9FTVNLIGNhc2UgYXMgd2VsbCkgdmFyaWFudHMgb2YgSU1TS1tq XSBkdXJpbmcgYW4gZXhlY3V0aW9uIG9mIGFuIGludGVybmFsIEFQIGF1dGhlbnRpY2F0aW9uIG1l dGhvZCBhbmQgYSBzaW5nbGUgb25lIG9mIHRob3NlIHZhcmlhbnRzIGlzIHNlbGVjdGVkIGFzIF90 aGUgY29ycmVjdF8gSU1TS1tqXSBhdCB0aGUgc3VjY2Vzc2Z1bCBjb25jbHVzaW9uIG9mIHRoaXMg aW5uZXIgYXV0aGVudGljYXRpb24gbWV0aG9kPw0KDQpXb3VsZCB0aGlzIHNpbmdsZSAiY29ycmVj dCBJTVNLW2pdIiB0aGVuIGJlIHVzZWQgZm9yIGRlcml2aW5nIHRoZSBkaWZmZXJlbnQgdmFyaWFu dHMgb2YgSU1TS1tqKzFdIGluc3RlYWQgb2YgdXNpbmcgRU1TSy1iYXNlZC1JTVNLW2pdIHdoZW4g ZGVyaXZpbmcgRU1TSy1iYXNlZC1JTVNLW2orMV0/IEluIG90aGVyIHdvcmRzLCBpcyB0aGlzIHRv IHdvcmsgYnkgaGF2aW5nIGFsbCBmb2xsb3dpbmcgaW5uZXIgYXV0aGVudGljYXRpb24gcm91bmRz IGFuZCBNU0svRU1TSyBkZXJpdmF0aW9uIHRvIGJlaGF2ZSBhcyBpZiB0aGUgb3RoZXIgdmFyaWFu dHMgb2YgSU1TS1tqXSBuZXZlciByZWFsbHkgZXhpc3RlZD8NCg0KPiBDb3VsZCB0aGlzIG1ldGhv ZCB3b3JrPyBTaG91bGQgd2UgbWFrZSBpdCBtb3JlIGNsZWFybHkgc3BlY2lmaWVkPyBPcg0KPiBz aG91bGQgd2UgY2hhbmdlIHRoZSBwcm90b2NvbCB0byBhcnJpdmUgZXhwbGljaXRseSB0byB0aGUN Cj4gdW5kZXJzdGFuZGluZyB3aGljaCB0eXBlDQo+IChNU0svRU1TSykgb2YgSU1TS1tqXSB0byB1 c2U/DQoNClJlZ2FyZGxlc3Mgb2Ygd2hhdCBpcyBkb25lIGZvciB0aGUgZGVzaWduLCBpdCB3aWxs IGFic29sdXRlbHkgbmVlZCB0byBiZSBzcGVjaWZpZWQgbW9yZSBjbGVhcmx5Lg0KDQpJZiBJIHVu ZGVyc3Rvb2QgdGhlIHByb3Bvc2VkIGRlc2lnbiBjb3JyZWN0bHksIHRoaXMgc2hvdWxkIGJlIGRl ZmluZWQgd2l0aCBzb21ldGhpbmcgbGlrZSBmb2xsb3dpbmc6DQoNCkZvciBlYWNoIHN1Y2Nlc3Nm dWwgaW5uZXIgRUFQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCwgZGVyaXZlIElNQ0stTVNLW2pdIChp ZiBNU0sgd2FzIGRlcml2ZWQgYnkgdGhlIGlubmVyIG1ldGhvZCksIGRlcml2ZSBJTUNLLUVNU0tb al0gKGlmIEVNU0sgd2FzIGRlcml2ZWQgYnkgdGhlIGlubmVyIG1ldGhvZCksIGRlcml2ZSBJTVNL LXplcm9bal0gKGZvciBhbGwgY2FzZXMpLiBEZXJpdmUgQ01LLU1TS1tqXSBmcm9tIElNQ0stTVNL W2pdIGFuZCBDTUstRU1TS1tqXSBmcm9tIElNQ0stRU1TS1tqXSAoYm90aDogaWYgYXZhaWxhYmxl KS4gR2VuZXJhdGUgQ3J5cHRvLUJpbmRpbmcgVExWIHdpdGggYWxsIGF2YWlsYWJsZSBDb21wb3Vu ZCBNQUMgdmFsdWVzLiBBbHNvIHZlcmlmeSBDcnlwdG8tQmluZGluZyBUTFYgd2l0aCBhbGwgYXZh aWxhYmxlIENvbXBvdW5kIE1BQyB2YWx1ZXMuIEFmdGVyIGJvdGggZW5kcyBoYXZlIHRyYW5zbWl0 dGVkIGFuZCByZWNlaXZlZCBDcnlwdG8tQmluZGluZyBUTFYsIHNldCBJTVNLW2pdIHRvIGJlIElN Q0stRU1TS1tqXSBpZiBib3RoIGVuZHMgaW5jbHVkZWQgRU1TSyBDb21wb3VuZCBNQUMsIG9yIHNl dCBJTVNLW2pdIHRvIGJlIElNQ0stTVNLW2pdIGlmIGJvdGggZW5kcyBpbmNsdWRlZCBNU0sgQ29t cG91bmQgTUFDIGJ1dCBlaXRoZXIgZW5kIGRpZCBub3QgaW5jbHVkZSBFTVNLIENvbXBvdW5kIE1B Qywgb3IgPHdoYXQgdG8gZG8gaGVyZSBvciBjYW4gdGhpcyBldmVuIGhhcHBlbj8+LiBTZXQgUy1J TUNLW2pdIGJhc2VkIG9uIHRoaXMgSU1TS1tqXS4gVGhpcyByZXN1bHRzIGluIHRoZXJlIGJlaW5n IG9ubHkgYSBzaW5nbGUgUy1JTUNLW2pdIGFuZCBNU0svRU1TSyBkZXJpdmF0aW9uIGJlaW5nIHdl bGwgZGVmaW5lZC4NCg0KQW5kIGZvY3VzaW5nIG9uIHRoYXQgIndoYXQgdG8gZG8gaGVyZS4uIiBw YXJ0IGFuZCB0aGUgdW51c2VkIElNQ0stemVyb1tqXSBpbiB0aGUgcHJldmlvdXMgcGFyYWdyYXBo Li4gSG93IGlzIHRoaXMgc3VwcG9zZWQgdG8gd29yayB3aGVuIGFuIGlubmVyIEVBUCBhdXRoZW50 aWNhdGlvbiBtZXRob2QgZG9lcyBub3QgZGVyaXZlIGVpdGhlciBNU0sgb3IgRU1TSz8gSW50ZXJt ZWRpYXRlIHJlc3VsdCBpbmRpY2F0aW9uIG9mIHN1Y2Nlc3MgbmVlZHMgdG8gYmUgZG9uZSBhbmQg dGhhdCBpbXBsaWVzIHRoZXJlIG5lZWRzIHRvIGJlIENyeXB0by1CaW5kaW5nIFRMVi4gQnV0IHRo YXQgVExWIGRvZXMgbm90IGhhdmUgb3B0aW9uIG9mIGluZGljYXRpbmcgdGhhdCBuZWl0aGVyIEVN U0sgQ29tcG91bmQgTUFDIG5vciBNU0sgQ29tcG91bmQgTUFDIGFyZSBwcmVzZW50IChGbGFncyBm aWVsZCBoYXMgbm8gdmFsdWUgMCBkZWZpbmVkIHRvIGRvIHNvKS4NClNvIHdoYXQgYXJlIHRob3Nl IGZpZWxkcyAob3Igb25lIG9mIHRoZW0pIHN1cHBvc2VkIHRvIGJlIHNldCB0bz8gQW5kIGhvdyBp cyB0aGF0IHNlbGVjdGVkIGZvciBhbiBpbm5lciBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9kIGo/ IERvZXMgdGhpcyBkZXBlbmRzIG9uIHdoYXQgaGFwcGVuZWQgd2l0aCBtZXRob2Qgai0xIChpZiBv bmUgd2FzIHByZXNlbnQpPyBIb3cgd291bGQgdGhlIGNvcnJlY3QgSU1DS1tqXSBiZSBkZXRlcm1p bmVkIGJ5IHRoZSBwZWVyIGFuZCB0aGUgc2VydmVyIGlmIG9uZSBvZiB0aGVtIGRlcml2ZWQgTVNL L0VNU0sgYnV0IHRoZSBvdGhlciBvbmUgZGlkIG5vdCBkZXJpdmUgZWl0aGVyIGZvciBpbm5lciBF QVAgbWV0aG9kIGo/DQoNCi0tDQpKb3VuaSBNYWxpbmVuICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBQR1AgaWQgRUZDODk1RkENCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFbXUgbWFpbGluZyBsaXN0DQpFbXVAaWV0Zi5v cmc8bWFpbHRvOkVtdUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZW11PGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmVt dSZkYXRhPTAyJTdDMDElN0Nqb3ZlcmdhciU0MG1pY3Jvc29mdC5jb20lN0NmNjkxMDYxZjU5NjA0 MGJlODgyZDA4ZDgxNzI4ZmU1ZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdD MSU3QzAlN0M2MzcyODQ4MTIxMzM2MzUwOTMmc2RhdGE9c0o4S3QyRUIlMkZqNGZhOGJFckp2VnMz a29Mb3dxciUyRkQwTHNPRUIyd2l3TjglM0QmcmVzZXJ2ZWQ9MD4NCg== --_000_CH2PR21MB13810828EC6E27F8EBF43E21D1940CH2PR21MB1381namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1tKb2VdIChjYXRjaGlu ZyB1cCkgV2l0aCByZXNwZWN0IHRvIHRoZSBjYXNlIHRoYXQgdGhlIG1ldGhvZCBpcyBhbiBNU0sg Z2VuZXJhdGluZyBtZWNoYW5pc20gYW5kIGFuZCBNU0sgaXMgbm90IGdlbmVyYXRlZC91c2VkLiZu YnNwOyBJIHRoaW5rIHRoZSBvcmlnaW5hbCBpbnRlbnRpb24gd2FzIHRoYXQgdGhpcyBjYXNlIHdv dWxkIGJlIGEgcHJvdG9jb2wgdmlvbGF0aW9uLCBpZSBpZiBhIG1ldGhvZCBnZW5lcmF0ZXMgYW4N CiBNU0sgaXQgc2hvdWxkIGJlIGF2YWlsYWJsZSBmb3IgY3J5cHRvLWJpbmRpbmcuJm5ic3A7ICZu YnNwO0knbSBjb25jZXJuZWQgdGhhdCBhbGxvd2luZyB0aGUgZmFsbGJhY2sgdG8gMCBNU0sgYWN0 dWFsbHkgd2lsbCBjYXVzZSBhIHNlY3VyaXR5IHZ1bG5lcmFiaWxpdHkgaW4gY29tcG91bmQmbmJz cDtiaW5kaW5nLiZuYnNwOyBEbyB3ZSBrbm93IGlmIHRoaXMgbWV0aG9kIG1pc21hdGNoIGlzIGEg cHJvYmxlbSBpbiBwcmFjdGljZT8mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ W2pvdmVyZ2FyXSBJIGFncmVlIHRoYXQgaWYgYSBtZXRob2QgZ2VuZXJhdGVzIGFuIE1TSyBpdCBz aG91bGQgZ2VuZXJhbGx5IGJlIHVzZWQgZm9yIGNyeXB0by1iaW5kaW5nLiBCdXQgdGhpcyBkb2Vz IG5vdCBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIGEgbWVjaGFuaXNtIGZvciBlYWNoIHBhcnR5IChj bGllbnQvc2VydmVyKSB0byBjb21tdW5pY2F0ZSB3aGF0IGtpbmQgb2YgY3J5cHRvLWJpbmRpbmcg dGhleSBhcmUNCiBzZW5kaW5nLiBUaGUgY2xpZW50L3NlcnZlciBpcyBmcmVlIHRvIHJlamVjdCB0 aGUgY3J5cHRvLWJpbmRpbmcgaWYgdGhlIHBlZXIgaXMgdW5hYmxlIHRvIHByb2R1Y2UgYSBjcnlw dG8tYmluZGluZyB0aGF0IHNhdGlzZmllcyB0aGUgbWluaW11bSBwb2xpY3kgb2YgdGhlIGltcGxl bWVudGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhhbXBsZSwgaWYgRUFQLVRM UyBpcyB1c2VkIGFzIGFuIGlubmVyIG1ldGhvZCwgYW5kIGEgY2xpZW50IHNlbmRzIGEgemVyby1N U0ssIEkgd291bGQgZnVsbHkgZXhwZWN0IHRoZSBzZXJ2ZXIgdG8gcmVqZWN0IHRoZSBjb25uZWN0 aW9uIOKAkyBub3QgZmFsbGJhY2sgdG8gemVyby1NU0suIEkgd291bGQgZXhwZWN0IGEgY2xpZW50 IHRvIGhhdmUgc2ltaWxhciBtaW5pbXVtIHNlY3VyaXR5IHBvbGljaWVzIGl0DQogd291bGQgYWNj ZXB0IGZvciBlYWNoIG1ldGhvZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgdG8gd2hldGhl ciBtZXRob2QgbWlzbWF0Y2ggaXMgYSBwcm9ibGVtIGluIHByYWN0aWNlIOKAkyB5ZXMsIHRvIGFu IGV4dGVudC4gV2luZG93cyBkb2VzIG5vdCBnZW5lcmF0ZSBFTVNLIGZvciBFQVAtVExTIGRlc3Bp dGUgaXQgYmVpbmcgc3BlY2lmaWVkIGluIHRoZSBSRkMsIHNvIHRoZSBjcnlwdG8tYmluZGluZyBz ZW50IHRvIHRoZSBzZXJ2ZXIgaXMgTVNLIGJhc2VkLiBJZiBhIHNlcnZlcuKAmXMgcG9saWN5IHJl cXVpcmVzDQogRU1TSywgdGhlbiBXaW5kb3dzIGNhbuKAmXQgY29ubmVjdC4gVGhpcyBpcyBjZXJ0 YWlubHkgYSBXaW5kb3dzIGZlYXR1cmUgZ2FwIOKAkyBidXQgc2VydmVycyBhcmUgZnJlZSB0byBk ZWNsaW5lIHRoZSBjb25uZWN0aW9uIGlmIHRoZXkgZG8gbm90IHdhbnQgdG8gZG93bmdyYWRlIHRv IGFuIE1TSyBiYXNlZCBjcnlwdG8gYmluZGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEpvc2VwaCBTYWxvd2V5ICZsdDtq b2VAc2Fsb3dleS5uZXQmZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMjIsIDIw MjAgODo1MyBQTTxicj4NCjxiPlRvOjwvYj4gT2xlZyBQZWthciAmbHQ7b2xlZy5wZWthci4yMDE3 QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEpvcmdlIFZlcmdhcmEgJmx0O2pvdmVyZ2Fy QG1pY3Jvc29mdC5jb20mZ3Q7OyBKb3VuaSBNYWxpbmVuICZsdDtqQHcxLmZpJmd0OzsgRU1VIFdH ICZsdDtlbXVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRW11XSBkcmFm dC1kZWtvay1lbXUtdGxzLWVhcC10eXBlcyBkaXNjdXNzaW9uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDIxLCAyMDIwIGF0IDExOjAyIEFNIE9s ZWcgUGVrYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpvbGVnLnBla2FyLjIwMTdAZ21haWwuY29tIj5v bGVnLnBla2FyLjIwMTdAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tdG9wOjYuMHB0O2ZvbnQtc2l6ZTowLjg3NXJlbSIgaWQ9ImdtYWlsLW1fOTAzMzU0NDQwNDgy NzI0NjIxZ21haWwtOjFnbCI+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzUwMDA1MCI+Jmd0O0FuZCBmb2N1c2luZyBvbiB0aGF0ICZx dW90O3doYXQgdG8gZG8gaGVyZS4uJnF1b3Q7IHBhcnQgYW5kIHRoZSB1bnVzZWQgSU1DSy16ZXJv W2pdIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGguLjxicj4NCiZndDtIb3cgaXMgdGhpcyBzdXBw b3NlZCB0byB3b3JrIHdoZW4gYW4gaW5uZXIgRUFQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBkb2Vz IG5vdCBkZXJpdmUgZWl0aGVyIE1TSyBvciBFTVNLPzxicj4NCiZndDtJbnRlcm1lZGlhdGUgcmVz dWx0IGluZGljYXRpb24gb2Ygc3VjY2VzcyBuZWVkcyB0byBiZSBkb25lIGFuZCB0aGF0IGltcGxp ZXMgdGhlcmUgbmVlZHMgdG8gYmUgQ3J5cHRvLUJpbmRpbmcgVExWLjxicj4NCiZndDtCdXQgdGhh dCBUTFYgZG9lcyBub3QgaGF2ZSBvcHRpb24gb2YgaW5kaWNhdGluZyB0aGF0IG5laXRoZXIgRU1T SyBDb21wb3VuZCBNQUMgbm9yIE1TSyBDb21wb3VuZCBNQUMgYXJlIHByZXNlbnQgKEZsYWdzIGZp ZWxkIGhhcyBubyB2YWx1ZSAwIGRlZmluZWQgdG8gZG8gc28pLjxicj4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+SSBhZ3JlZSB0aGUgMCB2YWx1ZSBzaG91bGQgYmUgZXhwbGljaXRseSBsaXN0 ZWQgZm9yIHRoaXMgcHVycG9zZS4gR2l2ZW4gdGhlIGRlc2lnbiBvZiB0aGUgZmxhZ3MgSSB0aGlu ayBpdCBpcyBjbGVhciB0aGlzIHdhcyB0aGUgaW50ZW5kZWQgdXNhZ2UgYW5kIGl0cyBvbWlzc2lv biB3YXMgbGlrZWx5IGFuIG92ZXJzaWdodC48c3BhbiBzdHlsZT0iY29sb3I6IzUwMDA1MCI+PGJy Pg0KJmd0O1NvIHdoYXQgYXJlIHRob3NlIGZpZWxkcyAob3Igb25lIG9mIHRoZW0pIHN1cHBvc2Vk IHRvIGJlIHNldCB0bz88YnI+DQomZ3Q7QW5kIGhvdyBpcyB0aGF0IHNlbGVjdGVkIGZvciBhbiBp bm5lciBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9kIGo/PGJyPg0KJmd0O0RvZXMgdGhpcyBkZXBl bmRzIG9uIHdoYXQgaGFwcGVuZWQgd2l0aCBtZXRob2Qgai0xIChpZiBvbmUgd2FzIHByZXNlbnQp Pzxicj4NCiZndDtIb3cgd291bGQgdGhlIGNvcnJlY3QgSU1DS1tqXSBiZSBkZXRlcm1pbmVkIGJ5 IHRoZSBwZWVyIGFuZCB0aGUgc2VydmVyIGlmIG9uZSBvZiB0aGVtIGRlcml2ZWQgTVNLL0VNU0sg YnV0IHRoZSBvdGhlciBvbmUgZGlkIG5vdCBkZXJpdmUgZWl0aGVyIGZvciBpbm5lciBFQVAgbWV0 aG9kIGo/PGJyPg0KPC9zcGFuPkFzc3VtaW5nIHdlIHVzZSB0aGUgdmFsdWUgMCB0byBpbmRpY2F0 ZSB0aGUgc3RhdGUgd2hlcmUgb25lIG9mIHRoZSBwZWVycyBkaWQgbm90IGRlcml2ZSBlaXRoZXIg TVNLIG9yIEVNU0ssIHRoZW4gSSBiZWxpZXZlIHRoZSBSRkMgYWRkcmVzc2VzIHRoaXMgYXMgTVNL aSA9IDMyIG9jdGV0cyBvZiAweDAwcy4gU28gaWYgb25lIHNpZGUgY2FsY3VsYXRlZCBuZWl0aGVy IE1TSyBub3IgRU1TSywgYW5kIGJvdGggc2lkZXMgZGVjaWRlZCB0bw0KIGNvbnRpbnVlIHRoZSBj b252ZXJzaW9uLCB0aGVuIGJvdGggc2lkZXMgd291bGQgdXNlIHRoZSB6ZXJvLU1TSyBmb3IgdGhh dCBJTVNLW2pdLDxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGltZyBib3JkZXI9IjAi IHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHN0eWxlPSJ3aWR0aDouMDEwNGluO2hlaWdodDouMDEwNGlu IiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vc3NsLmdzdGF0aWMuY29tL3VpL3YxL2lj b25zL21haWwvaW1hZ2VzL2NsZWFyZG90LmdpZiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb3JnZSwgSm91bmksIGFncmVlIHdpdGggdGhlIGFw cHJvYWNoLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Sm9yZ2UsIHBsZWFzZSBub3RlIHRoYXQgdGhlIHNhbWUgcHJvYmxlbSBleGlzdHMgaW4gUEVB UCBDcnlwdG8tQmluZGluZyBUTFYgYXMgc3BlY2lmaWVkIGluIGl0cw0KPGEgaHJlZj0iaHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZG9jcy5taWNyb3NvZnQuY29tJTJGZW4tdXMlMkZvcGVuc3BlY3MlMkZ3aW5kb3dzX3Byb3Rv Y29scyUyRm1zLXBlYXAlMkZlYmIyYjEyYi1jZDUzLTRmM2EtYWZlZC0zNjU4ODU2NmM3YzImYW1w O2RhdGE9MDIlN0MwMSU3Q2pvdmVyZ2FyJTQwbWljcm9zb2Z0LmNvbSU3Q2Y2OTEwNjFmNTk2MDQw YmU4ODJkMDhkODE3MjhmZTVmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNzI4NDgxMjEzMzYyNTA5OSZhbXA7c2RhdGE9OUIlMkJyR0Y5QWR1WFh1RVJYYkRo NHRUVFQ0SSUyQm5Wak9JMUdyTHdXSk5Qa1klM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2Js YW5rIj4NCmRvY3VtZW50YXRpb248L2E+IC0gd2hlbiBvbmUgc2lkZSBoYXMgYW4gaW5uZXIgbWV0 aG9kIHRoYXQgcHJvdmlkZWQgTVNLIGFuZCBhbm90aGVyJm5ic3A7c2lkZSBoYXMgdGhpcyBpbm5l ciBtZXRob2QgdGhhdCBkaWRuJ3QgcHJvdmlkZSBNU0suJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+W0pvZV0gKGNhdGNoaW5nIHVwKSBXaXRoIHJlc3BlY3QgdG8gdGhlIGNhc2UgdGhhdCB0aGUg bWV0aG9kIGlzIGFuIE1TSyBnZW5lcmF0aW5nIG1lY2hhbmlzbSBhbmQgYW5kIE1TSyBpcyBub3Qg Z2VuZXJhdGVkL3VzZWQuJm5ic3A7IEkgdGhpbmsgdGhlIG9yaWdpbmFsIGludGVudGlvbiB3YXMg dGhhdCB0aGlzIGNhc2Ugd291bGQgYmUgYSBwcm90b2NvbCB2aW9sYXRpb24sIGllIGlmIGEgbWV0 aG9kIGdlbmVyYXRlcyBhbg0KIE1TSyBpdCBzaG91bGQgYmUgYXZhaWxhYmxlIGZvciBjcnlwdG8t YmluZGluZy4mbmJzcDsgJm5ic3A7SSdtIGNvbmNlcm5lZCB0aGF0IGFsbG93aW5nIHRoZSBmYWxs YmFjayB0byAwIE1TSyBhY3R1YWxseSB3aWxsIGNhdXNlIGEgc2VjdXJpdHkgdnVsbmVyYWJpbGl0 eSBpbiBjb21wb3VuZCZuYnNwO2JpbmRpbmcuJm5ic3A7IERvIHdlIGtub3cgaWYgdGhpcyBtZXRo b2QgbWlzbWF0Y2ggaXMgYSBwcm9ibGVtIGluIHByYWN0aWNlPyZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlIGlzIGFsc28gYSBjYXNlIHdoZXJlIG5vIGlubmVyIG1ldGhvZCBpcyBl eGVjdXRlZC4gRm9yIGV4YW1wbGUsIHdoZW4gY2xpZW50IGNlcnRpZmljYXRlIHdhcyByZWNlaXZl ZCBkdXJpbmcgVEVBUCBvdXRlciB0dW5uZWwgZXN0YWJsaXNobWVudC4gSW4gdGhpcyBjYXNlIHdl IGFsc28gbmVlZCB0byB1c2UgemVyby1NU0suIEZvciBzdWNoIGNhc2UgYm90aCB2YWx1ZXMgb2Yg dGhlIGZsYWcgd29yayAtICZxdW90OzANCiBmb3IgemVyby1NU0smcXVvdDsgYW5kICZxdW90OzIg Zm9yIE1TSyZxdW90Oy4gVGhpcyBjcmVhdGVzIHVubmVjZXNzYXJ5IGFtYmlndWl0eSBhbmQgdGh1 cyB3b3VsZCBiZSBiZXR0ZXIgdG8gcmVxdWVzdCB1c2luZyBmbGFnJ3MgdmFsdWUgJnF1b3Q7MCZx dW90OyBmb3IgemVybyBNU0sgaW4gc3VjaCBjYXNlJm5ic3A7KHRvZGF5IHdlIHVzZSB2YWx1ZSAm cXVvdDsyJnF1b3Q7IGFuZCBpdCBkb2Vzbid0IGNyZWF0ZSBhbWJpZ3VpdHkpLiBIb3dldmVyIHRo ZXJlJ3MgYSBxdWVzdGlvbiBoZXJlOiBpbiBjYXNlIG9mIFRFQVANCiBjZXJ0aWZpY2F0ZSBiYXNl ZCBhdXRoZW50aWNhdGlvbiB0aGF0IGlzIHR5cGljYWxseSBkb25lIGJ5IHJ1bm5pbmcgaW5uZXIg bWV0aG9kIEVBUC1UTFMsIHNob3VsZCB3ZSBhbGxvdyBpbiZuYnNwO3NlbmRpbmcgY2xpZW50IGNl cnRpZmljYXRlIGR1cmluZyBURUFQIHR1bm5lbCBlc3RhYmxpc2htZW50IG9yIGluc2lkZSB0aGUg dHVubmVsIGFuZCB0aGlzIHdheSBza2lwcGluZyBFQVAtVExTIGlubmVyIG1ldGhvZD8gT24gb25l IGhhbmQgaXQgbWFrZXMgYXV0aGVudGljYXRpb24NCiBzaG9ydGVyLiBPbiB0aGUgb3RoZXIgaGFu ZCBpdCBjYXVzZXMgc3dpdGNoaW5nIGZyb20gTVNLL0VNU0sgZXhwb3J0ZWQgYnkgdGhlIGlubmVy IG1ldGhvZCBFQVAtVExTIHRvIHplcm8tTVNLLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBkbyBhbGxvdyBza2lwcGluZyBhbnkgaW5u ZXIgbWV0aG9kIHRoZW4gd2UgbmVlZCBleHBsaWNpdGx5IHNheSB0aGF0IHplcm8tTVNLIHNob3Vs ZCBiZSB1c2VkIGluIHN1Y2ggY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSBzdGFydGVkJm5ic3A7cmVidWlsZGluZyBzZWN0aW9u ICZxdW90OzxhIG5hbWU9Im1fOTAzMzU0NDQwNDgyNzI0NjIxX3NlY3Rpb24tNS4yIj48L2E+PGEg aHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZjNzE3MCUyM3NlY3Rpb24t NS4yJmFtcDtkYXRhPTAyJTdDMDElN0Nqb3ZlcmdhciU0MG1pY3Jvc29mdC5jb20lN0NmNjkxMDYx ZjU5NjA0MGJlODgyZDA4ZDgxNzI4ZmU1ZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzcyODQ4MTIxMzM2MzUwOTMmYW1wO3NkYXRhPTd4bUVxMXJOSFlTcTdx cWElMkZTdDRaNFhFU3FDYzJGWFR5JTJGNVg4S29iJTJGQmclM0QmYW1wO3Jlc2VydmVkPTAiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOiZxdW90O21fOTAzMzU0NDQw NDgyNzI0NjIxX3NlY3Rpb24tNVwuMiZxdW90OyI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij41LjI8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOiZxdW90O21f OTAzMzU0NDQwNDgyNzI0NjIxX3NlY3Rpb24tNVwuMiZxdW90OyI+PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOiZxdW90O21fOTAzMzU0NDQwNDgyNzI0NjIxX3NlY3Rpb24tNVwu MiZxdW90OyI+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Lg0KIEludGVybWVk aWF0ZSBDb21wb3VuZCBLZXkgRGVyaXZhdGlvbnMmcXVvdDsgPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPm9mIHRoZSBSRkMgYWNjb3JkaW5nIHRvIHRoZSBwcm9wb3NhbCBvbiB0 aGlzIHRocmVhZDwvc3Bhbj4mbmJzcDthbmQgd2lsbCBwb3N0IGl0IGhlcmUgc2hvcnRseS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ fiBPbGVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIE1vbiwgQXByIDIwLCAyMDIwIGF0IDM6NTcgQU0gSm9yZ2UgVmVyZ2FyYSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpvdmVyZ2FyQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r Ij5qb3ZlcmdhckBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7QW5kIGZvY3VzaW5n IG9uIHRoYXQgJnF1b3Q7d2hhdCB0byBkbyBoZXJlLi4mcXVvdDsgcGFydCBhbmQgdGhlIHVudXNl ZCBJTUNLLXplcm9bal0gaW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaC4uPGJyPg0KJmd0O0hvdyBp cyB0aGlzIHN1cHBvc2VkIHRvIHdvcmsgd2hlbiBhbiBpbm5lciBFQVAgYXV0aGVudGljYXRpb24g bWV0aG9kIGRvZXMgbm90IGRlcml2ZSBlaXRoZXIgTVNLIG9yIEVNU0s/PGJyPg0KJmd0O0ludGVy bWVkaWF0ZSByZXN1bHQgaW5kaWNhdGlvbiBvZiBzdWNjZXNzIG5lZWRzIHRvIGJlIGRvbmUgYW5k IHRoYXQgaW1wbGllcyB0aGVyZSBuZWVkcyB0byBiZSBDcnlwdG8tQmluZGluZyBUTFYuPGJyPg0K Jmd0O0J1dCB0aGF0IFRMViBkb2VzIG5vdCBoYXZlIG9wdGlvbiBvZiBpbmRpY2F0aW5nIHRoYXQg bmVpdGhlciBFTVNLIENvbXBvdW5kIE1BQyBub3IgTVNLIENvbXBvdW5kIE1BQyBhcmUgcHJlc2Vu dCAoRmxhZ3MgZmllbGQgaGFzIG5vIHZhbHVlIDAgZGVmaW5lZCB0byBkbyBzbykuPGJyPg0KPGJy Pg0KSSBhZ3JlZSB0aGUgMCB2YWx1ZSBzaG91bGQgYmUgZXhwbGljaXRseSBsaXN0ZWQgZm9yIHRo aXMgcHVycG9zZS4gR2l2ZW4gdGhlIGRlc2lnbiBvZiB0aGUgZmxhZ3MgSSB0aGluayBpdCBpcyBj bGVhciB0aGlzIHdhcyB0aGUgaW50ZW5kZWQgdXNhZ2UgYW5kIGl0cyBvbWlzc2lvbiB3YXMgbGlr ZWx5IGFuIG92ZXJzaWdodC48YnI+DQo8YnI+DQomZ3Q7U28gd2hhdCBhcmUgdGhvc2UgZmllbGRz IChvciBvbmUgb2YgdGhlbSkgc3VwcG9zZWQgdG8gYmUgc2V0IHRvPzxicj4NCiZndDtBbmQgaG93 IGlzIHRoYXQgc2VsZWN0ZWQgZm9yIGFuIGlubmVyIEVBUCBhdXRoZW50aWNhdGlvbiBtZXRob2Qg aj88YnI+DQomZ3Q7RG9lcyB0aGlzIGRlcGVuZHMgb24gd2hhdCBoYXBwZW5lZCB3aXRoIG1ldGhv ZCBqLTEgKGlmIG9uZSB3YXMgcHJlc2VudCk/PGJyPg0KJmd0O0hvdyB3b3VsZCB0aGUgY29ycmVj dCBJTUNLW2pdIGJlIGRldGVybWluZWQgYnkgdGhlIHBlZXIgYW5kIHRoZSBzZXJ2ZXIgaWYgb25l IG9mIHRoZW0gZGVyaXZlZCBNU0svRU1TSyBidXQgdGhlIG90aGVyIG9uZSBkaWQgbm90IGRlcml2 ZSBlaXRoZXIgZm9yIGlubmVyIEVBUCBtZXRob2Qgaj88YnI+DQo8YnI+DQpBc3N1bWluZyB3ZSB1 c2UgdGhlIHZhbHVlIDAgdG8gaW5kaWNhdGUgdGhlIHN0YXRlIHdoZXJlIG9uZSBvZiB0aGUgcGVl cnMgZGlkIG5vdCBkZXJpdmUgZWl0aGVyIE1TSyBvciBFTVNLLCB0aGVuIEkgYmVsaWV2ZSB0aGUg UkZDIGFkZHJlc3NlcyB0aGlzIGFzIE1TS2kgPSAzMiBvY3RldHMgb2YgMHgwMHMuIFNvIGlmIG9u ZSBzaWRlIGNhbGN1bGF0ZWQgbmVpdGhlciBNU0sgbm9yIEVNU0ssIGFuZCBib3RoIHNpZGVzIGRl Y2lkZWQgdG8gY29udGludWUNCiB0aGUgY29udmVyc2lvbiwgdGhlbiBib3RoIHNpZGVzIHdvdWxk IHVzZSB0aGUgemVyby1NU0sgZm9yIHRoYXQgSU1TS1tqXSwgPGJyPg0KPGJyPg0KSm9yZ2UgVmVy Z2FyYTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSm91 bmkgTWFsaW5lbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpAdzEuZmkiIHRhcmdldD0iX2JsYW5rIj5q QHcxLmZpPC9hPiZndDsgPGJyPg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAyMDIwIDM6MjUg QU08YnI+DQpUbzogT2xlZyBQZWthciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9sZWcucGVrYXIuMjAx N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5vbGVnLnBla2FyLjIwMTdAZ21haWwuY29tPC9h PiZndDs8YnI+DQpDYzogSm9yZ2UgVmVyZ2FyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvdmVyZ2Fy QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5qb3ZlcmdhckBtaWNyb3NvZnQuY29tPC9h PiZndDs7IEVNVSBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtdUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmVtdUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtFbXVdIGRyYWZ0 LWRla29rLWVtdS10bHMtZWFwLXR5cGVzIGRpc2N1c3Npb248YnI+DQo8YnI+DQpPbiBXZWQsIEFw ciAxNSwgMjAyMCBhdCAwNzoyNTowOFBNICYjNDM7MDMwMCwgT2xlZyBQZWthciB3cm90ZTo8YnI+ DQomZ3Q7IEZvciBURUFQIGVycmF0YSA1NzcwOjxicj4NCiZndDsgVGVjaG5pY2FsbHkgVEVBUCBS RkMgc3VnZ2VzdHMgdGhlIGltcGxpY2l0IG1ldGhvZCBvZiB0YWtpbmcgdGhlIDxicj4NCiZndDsg Y29ycmVjdCBJTVNLW2pdIGFuZCBhbGwgdGhlIHN1YnNlcXVlbnQga2V5cyBhZnRlciBlYWNoIGlu bmVyIG1ldGhvZCA8YnI+DQomZ3Q7IHZpYSBuZWdvdGlhdGlvbiB0YWtpbmcgcGxhY2UgaW4gQ3J5 cHRvLUJpbmRpbmcgVExWIGV4Y2hhbmdlLjxicj4NCjxicj4NCldoYXQgaXMgJnF1b3Q7dGhlIGNv cnJlY3QgSU1TS1tqXSZxdW90OyBhbmQgd2hlcmUgaXMgdGhpcyBkZWZpbmVkPzxicj4NCjxicj4N CiZndDsgTGV0J3Mgc2F5IHdlIGFyZSBvbiB0aGUgaW5uZXIgbWV0aG9kIG51bWJlciBqIHRoYXQg c3VwcG9ydHMgYm90aCBNU0sgPGJyPg0KJmd0OyBhbmQgRU1TSyBhbmQgd2UgYXJlIHNlcnZlciB3 aGljaCBpbXBsZW1lbnRhdGlvbiBnZW5lcmF0ZXMgYm90aCBNU0sgYW5kIDxicj4NCiZndDsgRU1T SyBmb3IgdGhpcyBpbm5lciBtZXRob2QuIFdlIGdlbmVyYXRlZCBrZXlzIGFjY29yZGluZyB0byB0 aGUgcnVsZXMgPGJyPg0KJmd0OyBiZWxvdyAtIHR3byBzZXRzLCBmb3IgSU1TS1tqXSBkZXJpdmVk IGZyb20gaW5uZXIgbWV0aG9kIEVNU0sgYW5kIGZvciA8YnI+DQomZ3Q7IElNU0tbal0gZXF1YWwg dG8gaW5uZXIgbWV0aG9kIE1TSy4gQmVjYXVzZSB3ZSBkb24ndCBrbm93IHdoZXRoZXIgPGJyPg0K Jmd0OyBjbGllbnQgaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgYm90aCBNU0sgYW5kIEVNU0suPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFMtSU1DS1swXSA9IHNlc3Npb25fa2V5X3NlZWQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Rm9yIGogPSAxIHRvIG4tMSBkbzxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJTUNLW2pdID0gVExTLVBS RihTLUlNQ0tbai0xXSwgJnF1b3Q7SW5uZXIgTWV0aG9kcyBDb21wb3VuZCBLZXlzJnF1b3Q7LDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0lNU0tbal0sIDYwKTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBTLUlNQ0tbal0gPSBmaXJzdCA0MCBvY3RldHMgb2YgSU1DS1tq XTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDTUtb al0gPSBsYXN0IDIwIG9jdGV0cyBvZiBJTUNLW2pdPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgU28gd2UgaGF2ZSB0d28gQ01LW2pdIGFuZCB3ZSBjcmVhdGUgQ3J5cHRvLUJpbmRpbmcg VExWIHdpdGggYm90aCA8YnI+DQomZ3Q7IENvbXBvdW5kIE1BQyBmb3IgTVNLIGFuZCBFTVNLLiBU aGUgY2xpZW50IHNlbmRzIENyeXB0by1CaW5kaW5nIFRMViBpbiA8YnI+DQomZ3Q7IHJlc3BvbnNl IGFuZCB3ZSBjYW4gdW5kZXJzdGFuZCBmcm9tIGl0IHdoZXRoZXIgaXQgc3VwcG9ydHMgRU1TSyBm b3IgPGJyPg0KJmd0OyB0aGlzIGlubmVyIG1ldGhvZCBvciBub3QuIEFuZCBoZXJlIHdlIGNhbiBk ZWNpZGUgd2hpY2ggdmVyc2lvbiBvZiA8YnI+DQomZ3Q7IElNQ0tbal0gdG8gdGFrZSBmb3IgdGhp cyBpbm5lciBtZXRob2QgLSBkZXJpdmVkIGZyb20gRU1TSyBvciBNU0suIFRoaXMgPGJyPg0KJmd0 OyBpcyBqdXN0IG5vdCBleHBsaWNpdGx5IHNwZWNpZmllZCBpbiB0aGUgUkZDLjxicj4NCjxicj4N CklzIHRoaXMgdGhlIHByb3Bvc2VkIGRlZmluaXRpb24gb2YgJnF1b3Q7dGhlIGNvcnJlY3QgSU1T S1tKXSZxdW90Oz8gSW4gb3RoZXIgd29yZHMsIGlzIHRoaXMgdG8gYmUgdW5kZXJzdG9vZCB0byBo YXZlIHR3byAob3IgdGhyZWUgc2luY2Ugd2UgaGF2ZSB0aGUgbm8gTVNLL0VNU0sgY2FzZSBhcyB3 ZWxsKSB2YXJpYW50cyBvZiBJTVNLW2pdIGR1cmluZyBhbiBleGVjdXRpb24gb2YgYW4gaW50ZXJu YWwgQVAgYXV0aGVudGljYXRpb24gbWV0aG9kIGFuZCBhIHNpbmdsZQ0KIG9uZSBvZiB0aG9zZSB2 YXJpYW50cyBpcyBzZWxlY3RlZCBhcyBfdGhlIGNvcnJlY3RfIElNU0tbal0gYXQgdGhlIHN1Y2Nl c3NmdWwgY29uY2x1c2lvbiBvZiB0aGlzIGlubmVyIGF1dGhlbnRpY2F0aW9uIG1ldGhvZD88YnI+ DQo8YnI+DQpXb3VsZCB0aGlzIHNpbmdsZSAmcXVvdDtjb3JyZWN0IElNU0tbal0mcXVvdDsgdGhl biBiZSB1c2VkIGZvciBkZXJpdmluZyB0aGUgZGlmZmVyZW50IHZhcmlhbnRzIG9mIElNU0tbaiYj NDM7MV0gaW5zdGVhZCBvZiB1c2luZyBFTVNLLWJhc2VkLUlNU0tbal0gd2hlbiBkZXJpdmluZyBF TVNLLWJhc2VkLUlNU0tbaiYjNDM7MV0/IEluIG90aGVyIHdvcmRzLCBpcyB0aGlzIHRvIHdvcmsg YnkgaGF2aW5nIGFsbCBmb2xsb3dpbmcgaW5uZXIgYXV0aGVudGljYXRpb24gcm91bmRzIGFuZA0K IE1TSy9FTVNLIGRlcml2YXRpb24gdG8gYmVoYXZlIGFzIGlmIHRoZSBvdGhlciB2YXJpYW50cyBv ZiBJTVNLW2pdIG5ldmVyIHJlYWxseSBleGlzdGVkPzxicj4NCjxicj4NCiZndDsgQ291bGQgdGhp cyBtZXRob2Qgd29yaz8gU2hvdWxkIHdlIG1ha2UgaXQgbW9yZSBjbGVhcmx5IHNwZWNpZmllZD8g T3IgPGJyPg0KJmd0OyBzaG91bGQgd2UgY2hhbmdlIHRoZSBwcm90b2NvbCB0byBhcnJpdmUgZXhw bGljaXRseSB0byB0aGUgPGJyPg0KJmd0OyB1bmRlcnN0YW5kaW5nIHdoaWNoIHR5cGU8YnI+DQom Z3Q7IChNU0svRU1TSykgb2YgSU1TS1tqXSB0byB1c2U/PGJyPg0KPGJyPg0KUmVnYXJkbGVzcyBv ZiB3aGF0IGlzIGRvbmUgZm9yIHRoZSBkZXNpZ24sIGl0IHdpbGwgYWJzb2x1dGVseSBuZWVkIHRv IGJlIHNwZWNpZmllZCBtb3JlIGNsZWFybHkuPGJyPg0KPGJyPg0KSWYgSSB1bmRlcnN0b29kIHRo ZSBwcm9wb3NlZCBkZXNpZ24gY29ycmVjdGx5LCB0aGlzIHNob3VsZCBiZSBkZWZpbmVkIHdpdGgg c29tZXRoaW5nIGxpa2UgZm9sbG93aW5nOjxicj4NCjxicj4NCkZvciBlYWNoIHN1Y2Nlc3NmdWwg aW5uZXIgRUFQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCwgZGVyaXZlIElNQ0stTVNLW2pdIChpZiBN U0sgd2FzIGRlcml2ZWQgYnkgdGhlIGlubmVyIG1ldGhvZCksIGRlcml2ZSBJTUNLLUVNU0tbal0g KGlmIEVNU0sgd2FzIGRlcml2ZWQgYnkgdGhlIGlubmVyIG1ldGhvZCksIGRlcml2ZSBJTVNLLXpl cm9bal0gKGZvciBhbGwgY2FzZXMpLiBEZXJpdmUgQ01LLU1TS1tqXSBmcm9tIElNQ0stTVNLW2pd IGFuZCBDTUstRU1TS1tqXQ0KIGZyb20gSU1DSy1FTVNLW2pdIChib3RoOiBpZiBhdmFpbGFibGUp LiBHZW5lcmF0ZSBDcnlwdG8tQmluZGluZyBUTFYgd2l0aCBhbGwgYXZhaWxhYmxlIENvbXBvdW5k IE1BQyB2YWx1ZXMuIEFsc28gdmVyaWZ5IENyeXB0by1CaW5kaW5nIFRMViB3aXRoIGFsbCBhdmFp bGFibGUgQ29tcG91bmQgTUFDIHZhbHVlcy4gQWZ0ZXIgYm90aCBlbmRzIGhhdmUgdHJhbnNtaXR0 ZWQgYW5kIHJlY2VpdmVkIENyeXB0by1CaW5kaW5nIFRMViwgc2V0IElNU0tbal0NCiB0byBiZSBJ TUNLLUVNU0tbal0gaWYgYm90aCBlbmRzIGluY2x1ZGVkIEVNU0sgQ29tcG91bmQgTUFDLCBvciBz ZXQgSU1TS1tqXSB0byBiZSBJTUNLLU1TS1tqXSBpZiBib3RoIGVuZHMgaW5jbHVkZWQgTVNLIENv bXBvdW5kIE1BQyBidXQgZWl0aGVyIGVuZCBkaWQgbm90IGluY2x1ZGUgRU1TSyBDb21wb3VuZCBN QUMsIG9yICZsdDt3aGF0IHRvIGRvIGhlcmUgb3IgY2FuIHRoaXMgZXZlbiBoYXBwZW4/Jmd0Oy4g U2V0IFMtSU1DS1tqXSBiYXNlZCBvbiB0aGlzDQogSU1TS1tqXS4gVGhpcyByZXN1bHRzIGluIHRo ZXJlIGJlaW5nIG9ubHkgYSBzaW5nbGUgUy1JTUNLW2pdIGFuZCBNU0svRU1TSyBkZXJpdmF0aW9u IGJlaW5nIHdlbGwgZGVmaW5lZC48YnI+DQo8YnI+DQpBbmQgZm9jdXNpbmcgb24gdGhhdCAmcXVv dDt3aGF0IHRvIGRvIGhlcmUuLiZxdW90OyBwYXJ0IGFuZCB0aGUgdW51c2VkIElNQ0stemVyb1tq XSBpbiB0aGUgcHJldmlvdXMgcGFyYWdyYXBoLi4gSG93IGlzIHRoaXMgc3VwcG9zZWQgdG8gd29y ayB3aGVuIGFuIGlubmVyIEVBUCBhdXRoZW50aWNhdGlvbiBtZXRob2QgZG9lcyBub3QgZGVyaXZl IGVpdGhlciBNU0sgb3IgRU1TSz8gSW50ZXJtZWRpYXRlIHJlc3VsdCBpbmRpY2F0aW9uIG9mIHN1 Y2Nlc3MgbmVlZHMgdG8NCiBiZSBkb25lIGFuZCB0aGF0IGltcGxpZXMgdGhlcmUgbmVlZHMgdG8g YmUgQ3J5cHRvLUJpbmRpbmcgVExWLiBCdXQgdGhhdCBUTFYgZG9lcyBub3QgaGF2ZSBvcHRpb24g b2YgaW5kaWNhdGluZyB0aGF0IG5laXRoZXIgRU1TSyBDb21wb3VuZCBNQUMgbm9yIE1TSyBDb21w b3VuZCBNQUMgYXJlIHByZXNlbnQgKEZsYWdzIGZpZWxkIGhhcyBubyB2YWx1ZSAwIGRlZmluZWQg dG8gZG8gc28pLjxicj4NClNvIHdoYXQgYXJlIHRob3NlIGZpZWxkcyAob3Igb25lIG9mIHRoZW0p IHN1cHBvc2VkIHRvIGJlIHNldCB0bz8gQW5kIGhvdyBpcyB0aGF0IHNlbGVjdGVkIGZvciBhbiBp bm5lciBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9kIGo/IERvZXMgdGhpcyBkZXBlbmRzIG9uIHdo YXQgaGFwcGVuZWQgd2l0aCBtZXRob2Qgai0xIChpZiBvbmUgd2FzIHByZXNlbnQpPyBIb3cgd291 bGQgdGhlIGNvcnJlY3QgSU1DS1tqXSBiZSBkZXRlcm1pbmVkIGJ5IHRoZSBwZWVyDQogYW5kIHRo ZSBzZXJ2ZXIgaWYgb25lIG9mIHRoZW0gZGVyaXZlZCBNU0svRU1TSyBidXQgdGhlIG90aGVyIG9u ZSBkaWQgbm90IGRlcml2ZSBlaXRoZXIgZm9yIGlubmVyIEVBUCBtZXRob2Qgaj88YnI+DQo8YnI+ DQotLSA8YnI+DQpKb3VuaSBNYWxpbmVuJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFBHUCBpZCBFRkM4OTVGQTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCkVtdSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86RW11QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+RW11QGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmVtdSZh bXA7ZGF0YT0wMiU3QzAxJTdDam92ZXJnYXIlNDBtaWNyb3NvZnQuY29tJTdDZjY5MTA2MWY1OTYw NDBiZTg4MmQwOGQ4MTcyOGZlNWYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 QzElN0MwJTdDNjM3Mjg0ODEyMTMzNjM1MDkzJmFtcDtzZGF0YT1zSjhLdDJFQiUyRmo0ZmE4YkVy SnZWczNrb0xvd3FyJTJGRDBMc09FQjJ3aXdOOCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW11PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_CH2PR21MB13810828EC6E27F8EBF43E21D1940CH2PR21MB1381namp_-- From nobody Tue Jun 23 21:08:02 2020 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 163973A07AB for ; Tue, 23 Jun 2020 21:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 U4FVyNaiuT-j for ; Tue, 23 Jun 2020 21:07:58 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 DF1EB3A07AA for ; Tue, 23 Jun 2020 21:07:57 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id o38so686509qtf.6 for ; Tue, 23 Jun 2020 21:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HOVI/EZhScyXxqy5vluJkiXNZCTSQryhMuZh77NNBIQ=; b=S60tiQAEoXWLyWyqw4l/LxyjzFZmSJlaI82Ha5pzOkGumew0P+t/zy/TGAVYhxXNfp 74nLvwFJv5BhHOZqOG3OimS2j6oxnWPAjCFrZQ1OanybEKBvNcMLnYAyZG9f8Z5spzCK 3mpv0Li1mmwkFVyD4B8INqaGaTdi110sEGi9RmDBnUdcxdR11q971CRiKfQMprHteTtd N9BnYzSrhicbuwqQwcoR0DZbUU9wmcrCDRDgFcY/60q66ffxXZYYN9pF1f9efSYr8eI1 nzAAINr03BMA79lUbSaGKoTwJgh3xFDO/38IysH9mSjproko0on9Z695N+mA+BwQyCKi 4GkQ== 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=HOVI/EZhScyXxqy5vluJkiXNZCTSQryhMuZh77NNBIQ=; b=GARJ7MgG4Sh7hQX9dHXCEmJfEaDG1bEDvDXMUj+5/C/45A9t09i5f1qcrA3p73qm8m KVPuNt2pRK+zV3YV2Y/2oolrqvgO32JQIrq2/WG5iKP4jWq8To7qVcmZZQ/5oGDLtP/C wQttetiBsiDtHjZ7n2fLSNYw56+An78PjBw+JxduCIoZ5uM9DiYlnt2EmH/T09LBcXBY Ry3nRiEOQ9ztKUvBA6AAaPlxHmDAL9Ea8bCtZP3zYzuIk5Jr/pnJMUQ/eenpXQLvw77t MQY1mk0oKJ+d0CFrwSSW3kqC86EU9i2ilUX1vqVESVelpxDINyWIu4MVqBF2nUqkEwBs hW8w== X-Gm-Message-State: AOAM532nPLIKGZozECBvbTIKeF41zGNYGAJgPPKY8w0Q7X19beAny/zJ CXIMkBeyv1jsxZApSeE6wi9g2rRsaV4UfWA6C4de9g== X-Google-Smtp-Source: ABdhPJxMVCRJTaB65vkRj8dtYtfUQQ7bmxSafnOeHUD2fvxp3o88D9CbsI6NJv/66vShnegq1Cl/Ps4mc2rbFVYT78w= X-Received: by 2002:ac8:4718:: with SMTP id f24mr23285316qtp.95.1592971676762; Tue, 23 Jun 2020 21:07:56 -0700 (PDT) MIME-Version: 1.0 References: <20200416102445.GA8757@w1.fi> In-Reply-To: From: Joseph Salowey Date: Tue, 23 Jun 2020 21:07:45 -0700 Message-ID: To: Jorge Vergara Cc: Oleg Pekar , Jouni Malinen , EMU WG Content-Type: multipart/alternative; boundary="000000000000ee5c0a05a8cc9e7f" Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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: Wed, 24 Jun 2020 04:08:01 -0000 --000000000000ee5c0a05a8cc9e7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 22, 2020 at 9:06 PM Jorge Vergara wrote: > >[Joe] (catching up) With respect to the case that the method is an MSK > generating mechanism and and MSK is not generated/used. I think the > original intention was that this case would be a protocol violation, ie i= f > a method generates an MSK it should be available for crypto-binding. I'= m > concerned that allowing the fallback to 0 MSK actually will cause a > security vulnerability in compound binding. Do we know if this method > mismatch is a problem in practice? > > > > [jovergar] I agree that if a method generates an MSK it should generally > be used for crypto-binding. But this does not eliminate the need for a > mechanism for each party (client/server) to communicate what kind of > crypto-binding they are sending. The client/server is free to reject the > crypto-binding if the peer is unable to produce a crypto-binding that > satisfies the minimum policy of the implementation. > > > For example, if EAP-TLS is used as an inner method, and a client sends a > zero-MSK, I would fully expect the server to reject the connection =E2=80= =93 not > fallback to zero-MSK. I would expect a client to have similar minimum > security policies it would accept for each method. > > > [Joe] I agree that there will be some policy needed on the client and server, but I think the policy for this specific case (method supports MSK but it is not used) could be built into the protocol and simplify things. > As to whether method mismatch is a problem in practice =E2=80=93 yes, to = an > extent. Windows does not generate EMSK for EAP-TLS despite it being > specified in the RFC, so the crypto-binding sent to the server is MSK > based. If a server=E2=80=99s policy requires EMSK, then Windows can=E2=80= =99t connect. This > is certainly a Windows feature gap =E2=80=93 but servers are free to decl= ine the > connection if they do not want to downgrade to an MSK based crypto bindin= g. > [Joe] Yes, and I'm sure this is not the only case where EMSK is defined for a method but not implemented. While it would be better if everyone implemented and used the EMSK, the MSK is better than using 0. I agree clients and servers will need some policy in this case. The policy does complicate the protocol and implementation. > > *From:* Joseph Salowey > *Sent:* Monday, June 22, 2020 8:53 PM > *To:* Oleg Pekar > *Cc:* Jorge Vergara ; Jouni Malinen ; > EMU WG > *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion > > > > > > > > On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar > wrote: > > >And focusing on that "what to do here.." part and the unused IMCK-zero[j= ] > in the previous paragraph.. > >How is this supposed to work when an inner EAP authentication method doe= s > not derive either MSK or EMSK? > >Intermediate result indication of success needs to be done and that > implies there needs to be Crypto-Binding TLV. > >But that TLV does not have option of indicating that neither EMSK > Compound MAC nor MSK Compound MAC are present (Flags field has no value 0 > defined to do so). > I agree the 0 value should be explicitly listed for this purpose. Given > the design of the flags I think it is clear this was the intended usage a= nd > its omission was likely an oversight. > >So what are those fields (or one of them) supposed to be set to? > >And how is that selected for an inner EAP authentication method j? > >Does this depends on what happened with method j-1 (if one was present)? > >How would the correct IMCK[j] be determined by the peer and the server i= f > one of them derived MSK/EMSK but the other one did not derive either for > inner EAP method j? > Assuming we use the value 0 to indicate the state where one of the peers > did not derive either MSK or EMSK, then I believe the RFC addresses this = as > MSKi =3D 32 octets of 0x00s. So if one side calculated neither MSK nor EM= SK, > and both sides decided to continue the conversion, then both sides would > use the zero-MSK for that IMSK[j], > > Jorge, Jouni, agree with the approach. > > > > Jorge, please note that the same problem exists in PEAP Crypto-Binding TL= V > as specified in its documentation > > - when one side has an inner method that provided MSK and another side ha= s > this inner method that didn't provide MSK. > > > > [Joe] (catching up) With respect to the case that the method is an MSK > generating mechanism and and MSK is not generated/used. I think the > original intention was that this case would be a protocol violation, ie i= f > a method generates an MSK it should be available for crypto-binding. I'= m > concerned that allowing the fallback to 0 MSK actually will cause a > security vulnerability in compound binding. Do we know if this method > mismatch is a problem in practice? > > > > There is also a case where no inner method is executed. For example, when > client certificate was received during TEAP outer tunnel establishment. I= n > this case we also need to use zero-MSK. For such case both values of the > flag work - "0 for zero-MSK" and "2 for MSK". This creates unnecessary > ambiguity and thus would be better to request using flag's value "0" for > zero MSK in such case (today we use value "2" and it doesn't create > ambiguity). However there's a question here: in case of TEAP certificate > based authentication that is typically done by running inner method > EAP-TLS, should we allow in sending client certificate during TEAP tunnel > establishment or inside the tunnel and this way skipping EAP-TLS inner > method? On one hand it makes authentication shorter. On the other hand it > causes switching from MSK/EMSK exported by the inner method EAP-TLS to > zero-MSK. > > > > If we do allow skipping any inner method then we need explicitly say that > zero-MSK should be used in such case. > > > > I've started rebuilding section "*5.2* > *. > Intermediate Compound Key Derivations" *of the RFC according to the > proposal on this thread and will post it here shortly. > > > > ~ Oleg > > > > > > > > > > On Mon, Apr 20, 2020 at 3:57 AM Jorge Vergara > wrote: > > >And focusing on that "what to do here.." part and the unused IMCK-zero[j= ] > in the previous paragraph.. > >How is this supposed to work when an inner EAP authentication method doe= s > not derive either MSK or EMSK? > >Intermediate result indication of success needs to be done and that > implies there needs to be Crypto-Binding TLV. > >But that TLV does not have option of indicating that neither EMSK > Compound MAC nor MSK Compound MAC are present (Flags field has no value 0 > defined to do so). > > I agree the 0 value should be explicitly listed for this purpose. Given > the design of the flags I think it is clear this was the intended usage a= nd > its omission was likely an oversight. > > >So what are those fields (or one of them) supposed to be set to? > >And how is that selected for an inner EAP authentication method j? > >Does this depends on what happened with method j-1 (if one was present)? > >How would the correct IMCK[j] be determined by the peer and the server i= f > one of them derived MSK/EMSK but the other one did not derive either for > inner EAP method j? > > Assuming we use the value 0 to indicate the state where one of the peers > did not derive either MSK or EMSK, then I believe the RFC addresses this = as > MSKi =3D 32 octets of 0x00s. So if one side calculated neither MSK nor EM= SK, > and both sides decided to continue the conversion, then both sides would > use the zero-MSK for that IMSK[j], > > Jorge Vergara > > -----Original Message----- > From: Jouni Malinen > Sent: Thursday, April 16, 2020 3:25 AM > To: Oleg Pekar > Cc: Jorge Vergara ; EMU WG > Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion > > On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote: > > For TEAP errata 5770: > > Technically TEAP RFC suggests the implicit method of taking the > > correct IMSK[j] and all the subsequent keys after each inner method > > via negotiation taking place in Crypto-Binding TLV exchange. > > What is "the correct IMSK[j]" and where is this defined? > > > Let's say we are on the inner method number j that supports both MSK > > and EMSK and we are server which implementation generates both MSK and > > EMSK for this inner method. We generated keys according to the rules > > below - two sets, for IMSK[j] derived from inner method EMSK and for > > IMSK[j] equal to inner method MSK. Because we don't know whether > > client implementation supports both MSK and EMSK. > > > > S-IMCK[0] =3D session_key_seed > > For j =3D 1 to n-1 do > > IMCK[j] =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Key= s", > > IMSK[j], 60) > > S-IMCK[j] =3D first 40 octets of IMCK[j] > > CMK[j] =3D last 20 octets of IMCK[j] > > > > > > So we have two CMK[j] and we create Crypto-Binding TLV with both > > Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in > > response and we can understand from it whether it supports EMSK for > > this inner method or not. And here we can decide which version of > > IMCK[j] to take for this inner method - derived from EMSK or MSK. This > > is just not explicitly specified in the RFC. > > Is this the proposed definition of "the correct IMSK[J]"? In other words, > is this to be understood to have two (or three since we have the no > MSK/EMSK case as well) variants of IMSK[j] during an execution of an > internal AP authentication method and a single one of those variants is > selected as _the correct_ IMSK[j] at the successful conclusion of this > inner authentication method? > > Would this single "correct IMSK[j]" then be used for deriving the > different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when > deriving EMSK-based-IMSK[j+1]? In other words, is this to work by having > all following inner authentication rounds and MSK/EMSK derivation to beha= ve > as if the other variants of IMSK[j] never really existed? > > > Could this method work? Should we make it more clearly specified? Or > > should we change the protocol to arrive explicitly to the > > understanding which type > > (MSK/EMSK) of IMSK[j] to use? > > Regardless of what is done for the design, it will absolutely need to be > specified more clearly. > > If I understood the proposed design correctly, this should be defined wit= h > something like following: > > For each successful inner EAP authentication method, derive IMCK-MSK[j] > (if MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK wa= s > derived by the inner method), derive IMSK-zero[j] (for all cases). Derive > CMK-MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if > available). Generate Crypto-Binding TLV with all available Compound MAC > values. Also verify Crypto-Binding TLV with all available Compound MAC > values. After both ends have transmitted and received Crypto-Binding TLV, > set IMSK[j] to be IMCK-EMSK[j] if both ends included EMSK Compound MAC, o= r > set IMSK[j] to be IMCK-MSK[j] if both ends included MSK Compound MAC but > either end did not include EMSK Compound MAC, or this even happen?>. Set S-IMCK[j] based on this IMSK[j]. This results in > there being only a single S-IMCK[j] and MSK/EMSK derivation being well > defined. > > And focusing on that "what to do here.." part and the unused IMCK-zero[j] > in the previous paragraph.. How is this supposed to work when an inner EA= P > authentication method does not derive either MSK or EMSK? Intermediate > result indication of success needs to be done and that implies there need= s > to be Crypto-Binding TLV. But that TLV does not have option of indicating > that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags > field has no value 0 defined to do so). > So what are those fields (or one of them) supposed to be set to? And how > is that selected for an inner EAP authentication method j? Does this > depends on what happened with method j-1 (if one was present)? How would > the correct IMCK[j] be determined by the peer and the server if one of th= em > derived MSK/EMSK but the other one did not derive either for inner EAP > method j? > > -- > Jouni Malinen PGP id EFC895FA > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > > --000000000000ee5c0a05a8cc9e7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 22, 2020 at 9:06 PM Jorge= Vergara <jovergar@microsoft.c= om> wrote:

>[Joe] (catching up) With respect to the case tha= t the method is an MSK generating mechanism and and MSK is not generated/us= ed.=C2=A0 I think the original intention was that this case would be a prot= ocol violation, ie if a method generates an MSK it should be available for crypto-binding.=C2=A0 =C2=A0I'm concern= ed that allowing the fallback to 0 MSK actually will cause a security vulne= rability in compound=C2=A0binding.=C2=A0 Do we know if this method mismatch= is a problem in practice?=C2=A0=C2=A0

=C2=A0

[jovergar] I agree that if a method generates an MSK= it should generally be used for crypto-binding. But this does not eliminat= e the need for a mechanism for each party (client/server) to communicate wh= at kind of crypto-binding they are sending. The client/server is free to reject the crypto-binding if the pee= r is unable to produce a crypto-binding that satisfies the minimum policy o= f the implementation.

=C2=A0=C2=A0

For example, if EAP-TLS is used as an inner method, = and a client sends a zero-MSK, I would fully expect the server to reject th= e connection =E2=80=93 not fallback to zero-MSK. I would expect a client to= have similar minimum security policies it would accept for each method.

=C2=A0

[Joe]= I agree that there will be some policy needed on the client and server, bu= t I think the policy for this specific case (method supports MSK but it is = not used)=C2=A0 could be built into the protocol and simplify things.=C2=A0= =C2=A0
=C2=A0

As to whether method mismatch is a problem in practi= ce =E2=80=93 yes, to an extent. Windows does not generate EMSK for EAP-TLS = despite it being specified in the RFC, so the crypto-binding sent to the se= rver is MSK based. If a server=E2=80=99s policy requires EMSK, then Windows can=E2=80=99t connect. This is certainly a Windows feat= ure gap =E2=80=93 but servers are free to decline the connection if they do= not want to downgrade to an MSK based crypto binding.


[Joe] Yes, and I'm sure this is not the onl= y case where EMSK is defined for a method but not implemented.=C2=A0 While = it would be better if everyone implemented and used the EMSK, the MSK is be= tter than using=C2=A00.=C2=A0 =C2=A0I agree clients and servers will need s= ome policy in this case.=C2=A0 The policy does complicate the protocol and = implementation.=C2=A0=C2=A0

=C2=A0

From: Joseph Salowey <joe@salowey.net>
Sent: Monday, June 22, 2020 8:53 PM
To: Oleg Pekar <oleg.pekar.2017@gmail.com>
Cc: Jorge Vergara <jovergar@microsoft.com>; Jouni Malinen <j@w1.fi>; EMU WG <emu@ietf.org>
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion

=C2=A0

=C2=A0

=C2=A0

On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar <oleg.pekar.2017@= gmail.com> wrote:

>And focusing on that "what to do = here.." part and the unused IMCK-zero[j] in the previous paragraph.. >How is this supposed to work when an inner EAP authentication method do= es not derive either MSK or EMSK?
>Intermediate result indication of success needs to be done and that imp= lies there needs to be Crypto-Binding TLV.
>But that TLV does not have option of indicating that neither EMSK Compo= und MAC nor MSK Compound MAC are present (Flags field has no value 0 define= d to do so).
I = agree the 0 value should be explicitly listed for this purpose. Given the d= esign of the flags I think it is clear this was the intended usage and its = omission was likely an oversight.
>So what are those fields (or one of them) supposed to be set to?
>And how is that selected for an inner EAP authentication method j?
>Does this depends on what happened with method j-1 (if one was present)= ?
>How would the correct IMCK[j] be determined by the peer and the server = if one of them derived MSK/EMSK but the other one did not derive either for= inner EAP method j?
Assuming we use the value 0 to indicate the state where one of the p= eers did not derive either MSK or EMSK, then I believe the RFC addresses th= is as MSKi =3D 32 octets of 0x00s. So if one side calculated neither MSK no= r EMSK, and both sides decided to continue the conversion, then both sides would use the zero-MSK for that I= MSK[j],

Jorge, Jouni, agree with the approach.=C2=A0<= u>

=C2=A0

Jorge, please note that the same problem exists in P= EAP Crypto-Binding TLV as specified in its documentation - when one side has an inner method that provided MSK and= another=C2=A0side has this inner method that didn't provide MSK.=C2=A0=

=C2=A0

[Joe] (catching up) With respect to the case that th= e method is an MSK generating mechanism and and MSK is not generated/used.= =C2=A0 I think the original intention was that this case would be a protoco= l violation, ie if a method generates an MSK it should be available for crypto-binding.=C2=A0 =C2=A0I'm concern= ed that allowing the fallback to 0 MSK actually will cause a security vulne= rability in compound=C2=A0binding.=C2=A0 Do we know if this method mismatch= is a problem in practice?=C2=A0=C2=A0

=C2=A0

There is also a case where no inner method is execut= ed. For example, when client certificate was received during TEAP outer tun= nel establishment. In this case we also need to use zero-MSK. For such case= both values of the flag work - "0 for zero-MSK" and "2 for MSK". This creates unnecessary amb= iguity and thus would be better to request using flag's value "0&q= uot; for zero MSK in such case=C2=A0(today we use value "2" and i= t doesn't create ambiguity). However there's a question here: in ca= se of TEAP certificate based authentication that is typically done by running inner m= ethod EAP-TLS, should we allow in=C2=A0sending client certificate during TE= AP tunnel establishment or inside the tunnel and this way skipping EAP-TLS = inner method? On one hand it makes authentication shorter. On the other hand it causes switching from MSK/EMSK exported by t= he inner method EAP-TLS to zero-MSK.

=C2=A0

If we do allow skipping any inner method then we nee= d explicitly say that zero-MSK should be used in such case.

=C2=A0

I've started=C2=A0rebuilding section "5.2. Intermediate Compound Key Derivations" of the RFC according to the proposal on this thread=C2=A0an= d will post it here shortly.=C2=A0

=C2=A0

~ Oleg

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Apr 20, 2020 at 3:57 AM Jorge Vergara <jovergar@microsof= t.com> wrote:

>And focusing on that "what to do here..&quo= t; part and the unused IMCK-zero[j] in the previous paragraph..
>How is this supposed to work when an inner EAP authentication method do= es not derive either MSK or EMSK?
>Intermediate result indication of success needs to be done and that imp= lies there needs to be Crypto-Binding TLV.
>But that TLV does not have option of indicating that neither EMSK Compo= und MAC nor MSK Compound MAC are present (Flags field has no value 0 define= d to do so).

I agree the 0 value should be explicitly listed for this purpose. Given the= design of the flags I think it is clear this was the intended usage and it= s omission was likely an oversight.

>So what are those fields (or one of them) supposed to be set to?
>And how is that selected for an inner EAP authentication method j?
>Does this depends on what happened with method j-1 (if one was present)= ?
>How would the correct IMCK[j] be determined by the peer and the server = if one of them derived MSK/EMSK but the other one did not derive either for= inner EAP method j?

Assuming we use the value 0 to indicate the state where one of the peers di= d not derive either MSK or EMSK, then I believe the RFC addresses this as M= SKi =3D 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK,= and both sides decided to continue the conversion, then both sides would use the zero-MSK for that IMSK[j], <= br>
Jorge Vergara

-----Original Message-----
From: Jouni Malinen <j@w1.f= i>
Sent: Thursday, April 16, 2020 3:25 AM
To: Oleg Pekar <oleg.pekar.2017@gmail.com>
Cc: Jorge Vergara <jovergar@microsoft.com>; EMU WG <emu@ietf.org>
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion

On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote:
> For TEAP errata 5770:
> Technically TEAP RFC suggests the implicit method of taking the
> correct IMSK[j] and all the subsequent keys after each inner method > via negotiation taking place in Crypto-Binding TLV exchange.

What is "the correct IMSK[j]" and where is this defined?

> Let's say we are on the inner method number j that supports both M= SK
> and EMSK and we are server which implementation generates both MSK and=
> EMSK for this inner method. We generated keys according to the rules <= br> > below - two sets, for IMSK[j] derived from inner method EMSK and for <= br> > IMSK[j] equal to inner method MSK. Because we don't know whether <= br> > client implementation supports both MSK and EMSK.
>
> S-IMCK[0] =3D session_key_seed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For j =3D 1 to n-1 do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMCK[j] =3D TLS-PRF(S-IMCK[j-= 1], "Inner Methods Compound Keys",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IMSK[j], = 60)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S-IMCK[j] =3D first 40 octets= of IMCK[j]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CMK[j] =3D last 20 octets of = IMCK[j]
>
>
> So we have two CMK[j] and we create Crypto-Binding TLV with both
> Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in =
> response and we can understand from it whether it supports EMSK for > this inner method or not. And here we can decide which version of
> IMCK[j] to take for this inner method - derived from EMSK or MSK. This=
> is just not explicitly specified in the RFC.

Is this the proposed definition of "the correct IMSK[J]"? In othe= r words, is this to be understood to have two (or three since we have the n= o MSK/EMSK case as well) variants of IMSK[j] during an execution of an inte= rnal AP authentication method and a single one of those variants is selected as _the correct_ IMSK[j] at the successf= ul conclusion of this inner authentication method?

Would this single "correct IMSK[j]" then be used for deriving the= different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when d= eriving EMSK-based-IMSK[j+1]? In other words, is this to work by having all= following inner authentication rounds and MSK/EMSK derivation to behave as if the other variants of IMSK[j] never re= ally existed?

> Could this method work? Should we make it more clearly specified? Or <= br> > should we change the protocol to arrive explicitly to the
> understanding which type
> (MSK/EMSK) of IMSK[j] to use?

Regardless of what is done for the design, it will absolutely need to be sp= ecified more clearly.

If I understood the proposed design correctly, this should be defined with = something like following:

For each successful inner EAP authentication method, derive IMCK-MSK[j] (if= MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was der= ived by the inner method), derive IMSK-zero[j] (for all cases). Derive CMK-= MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if available). Generate Crypto-Binding TLV with a= ll available Compound MAC values. Also verify Crypto-Binding TLV with all a= vailable Compound MAC values. After both ends have transmitted and received= Crypto-Binding TLV, set IMSK[j] to be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or set IMSK[j]= to be IMCK-MSK[j] if both ends included MSK Compound MAC but either end di= d not include EMSK Compound MAC, or <what to do here or can this even ha= ppen?>. Set S-IMCK[j] based on this IMSK[j]. This results in there being only a single S-IMCK[j] and MSK/EMSK = derivation being well defined.

And focusing on that "what to do here.." part and the unused IMCK= -zero[j] in the previous paragraph.. How is this supposed to work when an i= nner EAP authentication method does not derive either MSK or EMSK? Intermed= iate result indication of success needs to be done and that implies there needs to be Crypto-Binding TLV. But that TL= V does not have option of indicating that neither EMSK Compound MAC nor MSK= Compound MAC are present (Flags field has no value 0 defined to do so). So what are those fields (or one of them) supposed to be set to? And how is= that selected for an inner EAP authentication method j? Does this depends = on what happened with method j-1 (if one was present)? How would the correc= t IMCK[j] be determined by the peer and the server if one of them derived MSK/EMSK but the other one did not d= erive either for inner EAP method j?

--
Jouni Malinen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 PGP id EFC895FA

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.= ietf.org/mailman/listinfo/emu

--000000000000ee5c0a05a8cc9e7f-- From nobody Tue Jun 23 22:10:35 2020 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 9E8BA3A07DC for ; Tue, 23 Jun 2020 22:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 8cgjViRFicp3 for ; Tue, 23 Jun 2020 22:10:27 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80075.outbound.protection.outlook.com [40.107.8.75]) (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 99AF73A07BF for ; Tue, 23 Jun 2020 22:10:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rx/cjjb9+B92YPXYq+sUB6h2x5SaeoqIOBWMHR4qX0Eu2vGq+b20BtulgKpFLH7go+E6sZrlksMk17Ie8MIbqWYz5dB67/6bhYB3lLOg52rRZzE0vr96FcKoRdvtYR3gt2YsVjmImjgBL50PN0lVkCB7f+9ARai76pRupTmCyvZfOTC/pKf5DUNDPQKqDDSUCnyfxzRXrhgmgcp3hePwgBiADfZFT0Vlvj3lR9lsrk9YgbViQ9/wvZlkfeL0OXJQdKTaTTBlfeI4s8zjo30N/2Ww4zvsDVgA2XofFI4T41bwEvTIYCQ6dBaI7e3uVkiHDK5OBtMjwKLHx814b7I7uQ== 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=pe6Z0SCkSRdQWz7UrJ533q6SVfEZk7tqQhb/HoOxIMw=; b=BRVf196+J/HLokoytYW0IzNQgvuHiiStJACrX4VVAvsxp1S6u7sLkxmf0HEX+XzeGDSeWasPg/W1rYzSKDaioBUgJsItJbNxrsjvrvc19yLf0Mb9jGD+X7KgTZUCujYp4BzNjuw8f3Re8f5hz8oNd/8b2z0XVJ8sKkx4Y5U4m/1tH7aBxGG814MbWUQYJNx8y/lcggpNVODYq9EBvxw39LeoDwL0/a9A/S5jCQVupC2ehHI8EcDX1oSuxCPgmx9qE7mJxjeJolK6noC802q60Fbo5yW3o5HLTftZaR3PqrPA0IWYhC3ftaAkNe7X5/exCTIN8gRxTS8BK891riAkEg== 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=pe6Z0SCkSRdQWz7UrJ533q6SVfEZk7tqQhb/HoOxIMw=; b=n6ulKC0r9dlRgxtr5+XBPyCE7tmb7fdTpOGUsHMe1tZyt3jnmefeu9764fEQf3CoJ7g+mjiPGxEUDziLciQXbCIMYSX6GhSLZ4tc6qcq1gfF2nJCk9mcCVD8INzJDTNhQtFCwB6NJKCkrRXr4zPl3AizJTlF4PQLhaGPgUke4YE= Received: from VI1PR07MB3390.eurprd07.prod.outlook.com (2603:10a6:802:1e::16) by VI1PR0702MB3536.eurprd07.prod.outlook.com (2603:10a6:803:e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.13; Wed, 24 Jun 2020 05:10:24 +0000 Received: from VI1PR07MB3390.eurprd07.prod.outlook.com ([fe80::211c:500c:f155:7b16]) by VI1PR07MB3390.eurprd07.prod.outlook.com ([fe80::211c:500c:f155:7b16%4]) with mapi id 15.20.3131.017; Wed, 24 Jun 2020 05:10:24 +0000 From: Mohit Sethi M To: "emu@ietf.org" Thread-Topic: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt Thread-Index: AQHWSeXDHUsV19DukU+sjYX2mouNwg== Date: Wed, 24 Jun 2020 05:10:23 +0000 Message-ID: References: <159047624580.18151.8173719540463566179@ietfa.amsl.com> In-Reply-To: <159047624580.18151.8173719540463566179@ietfa.amsl.com> 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.8.0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:190:2cb3:61bd:1510:35ca:6af2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 304c72b1-80d2-4f57-f980-08d817fce693 x-ms-traffictypediagnostic: VI1PR0702MB3536: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LGEZp16SrDyq9KzUNiwcdzr2oPNQe84EOR9kUlkJ/6CZMxOcE2x57DISLj9bX0mX0SqVaDZB8DrRCNJp/3d5myMtPMD5LASzT5wyLkupSp3q0xGJ9HGyRjhOEXf+ogUfA8ZyQWuIg9UF001p0fjhrslNOQRyWonRO1vwCzbX5nCVZ/dn/dsJoTrttAY79Wfugt1HZ94uemx8jtrn4bs9gs/i7jXLunoxKN8icdKN75ExfpqpCUux855vW1kw6qQbTYlVC1dxB/GLVz3EJAfZk9NVQRH5qUuQR3sDwcc6QQ0VBCM5dfyBaVieRYBCV6lM1klBQJloDnnVmYNmYmbK2GDnm+z7SKzLUAOj9Yl23qRJGFAJ+ZD+DadqwlYTZE7+Kx0FPZ7jkEmAAZvK5CEqXFykkaulSuBwNXPcPHHVG6MqhbPXLOUVazhuhmZt7ZWl2WJaQeZD92joOVYqH0PWHg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB3390.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(346002)(376002)(39860400002)(64756008)(71200400001)(6512007)(6506007)(53546011)(2906002)(8936002)(66446008)(76116006)(66476007)(186003)(966005)(66556008)(66946007)(8676002)(478600001)(86362001)(2616005)(31686004)(31696002)(83380400001)(5660300002)(6486002)(6916009)(66574015)(316002)(36756003)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: dpK4gPWc9M+lOFn92UE8NxvoBkWLkzalhQ+3f60BVCdY2TzFmgUQu85wH5mZmnM6zJh3XP0NQP2MjU26scifcuLc0kV9subq/ylNBf5JvycHt39xAeA962ixJDQS/AlCo+PTXZ9Qh5KHXylPqVGcm3v1mCrltMqia6Pr4uVz5aJMTB3ScI7a4vt/KF6q1EZkVVi1UmYo9ROvhwY6gO+GMM020VetoVnXZS0NFZM//YjmAO7KJkOsaIaIQ7woo67cvE19yGCfGoQpqWTbiwmXIloBHHzb7lC/AKbY+wCqZckYoUo2OOVDkayV/wg+R6aertZPH43zKcQdzvUlxbwI+Cm06+1QZfSCBr6N6fYDFSktX8CVhwx+U2P4Lsa7ItgSebIc48ZMYb7d8Qq8pJynPN3hllnoG9Fxn28xesXVfUscIp5G7XkL4xFtIvX/fFVtE7N7RgxbRvaDWe4xX2NMKhYJYpg3D8pt9BAfpRldtHXiZsWd6d0oJ6MnzsjEKYH8jv1xLSHtFFbfbI1Dv5/bIfz/fMcy/4JqbQtdGzksnXa3SbHiYECLk/XRMVUjYr+P x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB3390.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 304c72b1-80d2-4f57-f980-08d817fce693 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 05:10:23.7731 (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: V4tEhhV6H4tUilH78ruUPCmha82vTgOOipb398C+h74aFuCeS/QH+CgbgVFLvfBcjhm8E70WheAjEi2/kznEkXkvP4Ld7oJoZQQJTPH5vOI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0702MB3536 Archived-At: Subject: Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.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: Wed, 24 Jun 2020 05:10:34 -0000 SGkgYWxsLA0KDQpJIGFtIG5vdCBhIGNyeXB0byBleHBlcnQgYW5kIG15IGtub3dsZWRnZSBvZiBw dWJsaWMga2V5IGVuY29kaW5ncyBpcyANCmJhc2VkIG9uIG15IHdvcmsgd2l0aCBSZW5lIFN0cnVp ayBmb3IgYSBkaWZmZXJlbnQgZHJhZnQuDQoNClRoZSBjdXJyZW50IHRleHQgaW4gZHJhZnQtaWV0 Zi1lbXUtYWthLXBmcy0wNCBzYXlzICJGb3IgUC0yNTYsIHRoZSANCmxlbmd0aCBvZiB0aGlzIHZh bHVlIGlzIDMyIGJ5dGVzLCBlbmNvZGVkIGluIGJpbmFyeSIuIFNob3VsZG4ndCB0aGlzIGJlIA0K MzMgYnl0ZXM/IEFuZCB3b3VsZG4ndCBpdCBtYWtlIHNlbnNlIHRvIGV4cGxpY2l0bHkgc2F5IHRo YXQgdGhpcyBpcyBhbiANCm9jdGV0IHN0cmluZyBpbiB0aGUgY29tcHJlc3NlZCBmb3JtYXQgd2hp bGUgcmVmZXJlbmNpbmcgIlNFQyAxOiBFbGxpcHRpYyANCkN1cnZlIENyeXB0b2dyYXBoeSwgVmVy c2lvbiAyLjAiIGZvciB0aGUgcG9pbnQgdG8gb2N0ZXQgc3RyaW5nIA0KY29udmVyc2lvbiBydWxl cz8NCg0KLS1Nb2hpdA0KDQpPbiA1LzI2LzIwIDk6NTcgQU0sIGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyB3cm90ZToNCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBFQVAgTWV0aG9kIFVwZGF0ZSBXRyBvZiB0aGUgSUVURi4NCj4NCj4g ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUGVyZmVjdC1Gb3J3YXJkIFNlY3JlY3kgZm9yIHRo ZSBFeHRlbnNpYmxlIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIE1ldGhvZCBmb3IgQXV0aGVudGlj YXRpb24gYW5kIEtleSBBZ3JlZW1lbnQgKEVBUC1BS0EnIFBGUykNCj4gICAgICAgICAgQXV0aG9y cyAgICAgICAgIDogSmFyaSBBcmtrbw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBLYXJs IE5vcnJtYW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgVmVzYSBUb3J2aW5lbg0KPiAJ RmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1lbXUtYWthLXBmcy0wNC50eHQNCj4gCVBhZ2Vz ICAgICAgICAgICA6IDI2DQo+IAlEYXRlICAgICAgICAgICAgOiAyMDIwLTA1LTI1DQo+DQo+IEFi c3RyYWN0Og0KPiAgICAgTWFueSBkaWZmZXJlbnQgYXR0YWNrcyBoYXZlIGJlZW4gcmVwb3J0ZWQg YXMgcGFydCBvZiByZXZlbGF0aW9ucw0KPiAgICAgYXNzb2NpYXRlZCB3aXRoIHBlcnZhc2l2ZSBz dXJ2ZWlsbGFuY2UuICBTb21lIG9mIHRoZSByZXBvcnRlZCBhdHRhY2tzDQo+ICAgICBpbnZvbHZl ZCBjb21wcm9taXNpbmcgc21hcnQgY2FyZHMsIHN1Y2ggYXMgYXR0YWNraW5nIFNJTSBjYXJkDQo+ ICAgICBtYW51ZmFjdHVyZXJzIGFuZCBvcGVyYXRvcnMgaW4gYW4gZWZmb3J0IHRvIGNvbXByb21p c2Ugc2hhcmVkIHNlY3JldHMNCj4gICAgIHN0b3JlZCBvbiB0aGVzZSBjYXJkcy4gIFNpbmNlIHRo ZSBwdWJsaWNhdGlvbiBvZiB0aG9zZSByZXBvcnRzLA0KPiAgICAgbWFudWZhY3R1cmluZyBhbmQg cHJvdmlzaW9uaW5nIHByb2Nlc3NlcyBoYXZlIGdhaW5lZCBtdWNoIHNjcnV0aW55DQo+ICAgICBh bmQgaGF2ZSBpbXByb3ZlZC4gIEhvd2V2ZXIsIHRoZSBkYW5nZXIgb2YgcmVzb3VyY2VmdWwgYXR0 YWNrZXJzIGZvcg0KPiAgICAgdGhlc2Ugc3lzdGVtcyBpcyBzdGlsbCBhIGNvbmNlcm4uDQo+DQo+ ICAgICBUaGlzIHNwZWNpZmljYXRpb24gaXMgYW4gb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIHRoZSBF QVAtQUtBJw0KPiAgICAgYXV0aGVudGljYXRpb24gbWV0aG9kIHdoaWNoIHdhcyBkZWZpbmVkIGlu IFtJLUQuaWV0Zi1lbXUtcmZjNTQ0OGJpc10uDQo+ICAgICBUaGUgZXh0ZW5zaW9uLCB3aGVuIG5l Z290aWF0ZWQsIHByb3ZpZGVzIFBlcmZlY3QgRm9yd2FyZCBTZWNyZWN5IGZvcg0KPiAgICAgdGhl IHNlc3Npb24ga2V5IGdlbmVyYXRlZCBhcyBhIHBhcnQgb2YgdGhlIGF1dGhlbnRpY2F0aW9uIHJ1 biBpbiBFQVAtDQo+ICAgICBBS0EnLiAgVGhpcyBwcmV2ZW50cyBhbiBhdHRhY2tlciB3aG8gaGFz IGdhaW5lZCBhY2Nlc3MgdG8gdGhlIGxvbmctDQo+ICAgICB0ZXJtIHByZS1zaGFyZWQgc2VjcmV0 IGluIGEgU0lNIGNhcmQgZnJvbSBiZWluZyBhYmxlIHRvIGRlY3J5cHQgYW55DQo+ICAgICBwYXN0 IGNvbW11bmljYXRpb25zLiAgSW4gYWRkaXRpb24sIGlmIHRoZSBhdHRhY2tlciBzdGF5cyBtZXJl bHkgYQ0KPiAgICAgcGFzc2l2ZSBlYXZlc2Ryb3BwZXIsIHRoZSBleHRlbnNpb24gcHJldmVudHMg YXR0YWNrcyBhZ2FpbnN0IGZ1dHVyZQ0KPiAgICAgc2Vzc2lvbnMuICBUaGlzIGZvcmNlcyBhdHRh Y2tlcnMgdG8gdXNlIGFjdGl2ZSBhdHRhY2tzIGluc3RlYWQuDQo+DQo+DQo+IFRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWVtdS1ha2EtcGZzLw0KPg0KPiBUaGVyZSBh cmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVtdS1ha2EtcGZzLTA0DQo+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1lbXUtYWthLXBmcy0wNA0KPg0KPiBB IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWVtdS1ha2EtcGZzLTA0DQo+ DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj4gSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFbXUgbWFpbGluZyBsaXN0DQo+IEVtdUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0K From nobody Wed Jun 24 13:04:47 2020 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 1E4EF3A1157 for ; Wed, 24 Jun 2020 13:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 wBr9NAsusF8e for ; Wed, 24 Jun 2020 13:04:43 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727443A1155 for ; Wed, 24 Jun 2020 13:04:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C9D68300B3B for ; Wed, 24 Jun 2020 16:04:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bIlY4zkdQmlM for ; Wed, 24 Jun 2020 16:04:39 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 08E99300A93; Wed, 24 Jun 2020 16:04:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: Date: Wed, 24 Jun 2020 16:04:39 -0400 Cc: "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9AB51563-756E-4C9E-8C1B-42302AAF7769@vigilsec.com> References: <159047624580.18151.8173719540463566179@ietfa.amsl.com> To: Mohit Sethi M X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.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: Wed, 24 Jun 2020 20:04:46 -0000 The ECDH public value in RFC 5480 is an OCTET STRING, which means that = the value is exactly 32 bytes. When this gets carried as a subject = public key in a certificate, there is an extra byte only because the = type is a BIT STRING. My conclusion is that the current draft is correct: * For P-256, the length of this value is 32 bytes, encoded in binary as specified in [FIPS186-4]. Russ > On Jun 24, 2020, at 1:10 AM, Mohit Sethi M = wrote: >=20 > Hi all, >=20 > I am not a crypto expert and my knowledge of public key encodings is=20= > based on my work with Rene Struik for a different draft. >=20 > The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the=20 > length of this value is 32 bytes, encoded in binary". Shouldn't this = be=20 > 33 bytes? And wouldn't it make sense to explicitly say that this is an=20= > octet string in the compressed format while referencing "SEC 1: = Elliptic=20 > Curve Cryptography, Version 2.0" for the point to octet string=20 > conversion rules? >=20 > --Mohit >=20 > On 5/26/20 9:57 AM, internet-drafts@ietf.org wrote: >> 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. >>=20 >> Title : Perfect-Forward Secrecy for the Extensible = Authentication Protocol Method for Authentication and Key Agreement = (EAP-AKA' PFS) >> Authors : Jari Arkko >> Karl Norrman >> Vesa Torvinen >> Filename : draft-ietf-emu-aka-pfs-04.txt >> Pages : 26 >> Date : 2020-05-25 >>=20 >> Abstract: >> Many different attacks have been reported as part of revelations >> associated with pervasive surveillance. Some of the reported = attacks >> involved compromising smart cards, such as attacking SIM card >> manufacturers and operators in an effort to compromise shared = secrets >> stored on these cards. Since the publication of those reports, >> manufacturing and provisioning processes have gained much scrutiny >> and have improved. However, the danger of resourceful attackers = for >> these systems is still a concern. >>=20 >> This specification is an optional extension to the EAP-AKA' >> authentication method which was defined in = [I-D.ietf-emu-rfc5448bis]. >> The extension, when negotiated, provides Perfect Forward Secrecy = for >> the session key generated as a part of the authentication run in = EAP- >> AKA'. This prevents an attacker who has gained access to the = long- >> term pre-shared secret in a SIM card from being able to decrypt = any >> past communications. In addition, if the attacker stays merely a >> passive eavesdropper, the extension prevents attacks against = future >> sessions. This forces attackers to use active attacks instead. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04 >> https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-aka-pfs-04 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From nobody Sun Jun 28 16:54:44 2020 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 D219B3A0FC5; Sun, 28 Jun 2020 16:54:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Steve Hanna via Datatracker To: Cc: draft-ietf-emu-eap-noob.all@ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159338848381.14481.6078519980317282415@ietfa.amsl.com> Reply-To: Steve Hanna Date: Sun, 28 Jun 2020 16:54:43 -0700 Archived-At: Subject: [Emu] Secdir early review of draft-ietf-emu-eap-noob-01 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: Sun, 28 Jun 2020 23:54:44 -0000 Reviewer: Steve Hanna Review result: Not Ready Reviewer: Steve Hanna Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a new EAP method for bootstrapping IoT devices. After reading the document, I have many questions: * Bootstrapping an IoT device involves many tasks that extend far beyond what is accomplished by EAP-NOOB: configuring the services that the device can/should employ within its new context (including how to reach and authenticate them), the networks and protocols that it should use and how it should obtain access to those networks, the access control policies that it should use (who is permitted to access the device and what operations can they perform), as well as many other configuration elements such as which lights a switch should control. The current document does not specify how such things are provisioned or even hint at this as an important problem. Without specifying such things, only a tiny part of the IoT device configuration problem has been solved. Perhaps another provisioning protocol could be used after EAP-NOOB but that protocol would need to be specified. With this extra step would come more complexity and user effort. Why not do this all with one protocol? * IoT device provisioning is not a new problem. In fact, it has been solved hundreds of times. Most of those solutions are proprietary but some standards efforts are ongoing now: IoTopia, FIDO IoT, Connected Home over IP, IP-BLiS, etc. Why ignore these? Why not reach out and try to help them? * This proposal assumes that the IoT device has a user interface (camera, screen, etc.). What about those that don’t? Many small IoT devices do not have a user interface of any sort or they only have a very primitive UI: a temperature sensor, motion detector, wall switch, light bulb, circuit breaker, etc. * Won’t this protocol apply to a relatively small subset of the networks that IoT devices will need to connect to? Few IoT networks run EAP. Mainly, EAP seems to be used in cellular networks and enterprise Ethernet and Wi-Fi networks. How will EAP-NOOB work in the Smart Home, where Wi-Fi is the most common network type and EAP is not used? * How will the device know which network to connect to, in the first place? At most locations, there are many wireless networks. Do you envision the user selecting from a list of Wi-Fi SSIDs and entering the network password with a touchscreen and keypad? What about the small IoT devices that don’t have a touchscreen and keypad? The server can’t help because the device is not yet connected to the network. * How will the user get OOB Output from the OOB sender to the OOB receiver? The specification doesn’t seem to As an IoT device maker, what am I supposed to put into the instructions? Ask your local network administrator what to do? * If the server indicates that it can handle peer-to-server OOB, what does that mean? Must the server have a camera? If so, what is it expected to scan and process? And if the peer prints out a page with a QR code, what should go into the code? The same questions apply to OOB implemented with audio, flashing LEDs, NFC, etc. In order to achieve interoperability, all of the details of these OOB methods would need to be specified exactly. The current specification includes no information like this. Without this information, multi-vendor interoperability is highly unlikely. Even if each OOB method was fully specified, consumers would still be frustrated if their server only supports QR codes and their device only supports NFC or audio. In my view, this protocol as currently specified is mainly of theoretical interest. I could not recommend that the IETF adopt it as an RFC as it would have almost no practical value. From nobody Sun Jun 28 18:43:43 2020 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 1F4393A101F; Sun, 28 Jun 2020 18:43:42 -0700 (PDT) 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 c-Om2ah0NSdb; Sun, 28 Jun 2020 18:43:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A4B3A08B3; Sun, 28 Jun 2020 18:43:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6709538990; Sun, 28 Jun 2020 21:40:50 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Po1o2pOtwi03; Sun, 28 Jun 2020 21:40:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A65803898E; Sun, 28 Jun 2020 21:40:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 03BEAF11; Sun, 28 Jun 2020 21:43:35 -0400 (EDT) From: Michael Richardson To: Steve Hanna , emu@ietf.org cc: secdir@ietf.org, draft-ietf-emu-eap-noob.all@ietf.org In-Reply-To: <159338848381.14481.6078519980317282415@ietfa.amsl.com> References: <159338848381.14481.6078519980317282415@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Secdir early review of draft-ietf-emu-eap-noob-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: Mon, 29 Jun 2020 01:43:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Steve Hanna via Datatracker wrote: > Reviewer: Steve Hanna > Review result: Not Ready Steve thanks for the great review! I wanted to respond as an IoT onboarding expert and EMU WG member. > * Bootstrapping an IoT device involves many tasks that extend far bey= ond what > is accomplished by EAP-NOOB: configuring the services that the device > can/should employ within its new context (including how to reach and Hi, so your comments are well taken, but it's really an unreasonably high standard. While it is really important to get the configuration mechanisms in place, they are even more diverse than onboarding. That's an entire ocean of disagreement here. I would certainly love to get a handle on this. When it comes to standardization, really have to be very selective on how b= ig a thing to bite off. I think that we can incrementally get to this, but first we need some success with getting even one onboarding spec working. So I don't think it's reasonable to evaluate EAP-NOOB (or BRSKI-TEEP) by th= is critiera. > * IoT device provisioning is not a new problem. In fact, it has been = solved > hundreds of times. Most of those solutions are proprietary but some s= tandards > efforts are ongoing now: IoTopia, FIDO IoT, Connected Home over IP, I= P-BLiS, > etc. Why ignore these? Why not reach out and try to help them? Well, of those groups, many of them are completely pay-to-play fora, and do all of their work behind closed doors. In many cases, they look to the IETF for components, such as EAP-NOOB, BRSKI, etc. that they can incorporate into their designs. Some are actively hostile towards an an actual written standard, preferring that everyone license a particular software stack inst= ead. I think that EAP-NOOB has benefited greatly from academic and industrial re= view. > * This proposal assumes that the IoT device has a user interface (cam= era, > screen, etc.). What about those that don=E2=80=99t? Yup. Some don't, and you need to do something else. But, a lot of devices *do* have displays. Think about any industrial or hospital instrument. They all go "ping", and have a cool display to put a graph on :-) > * Won=E2=80=99t this protocol apply to a relatively small subset of t= he networks that > IoT devices will need to connect to? Few IoT networks run EAP. EAP is very popular in industrial and enterprise situations. EAP can be easily introduced into home network, with the Authentication Server running locally. Many have done this, and it is supported in Openwr= t today. > * How will the device know which network to connect to, in the first > place? This is a good question, and I can offer no answer for the EAP-NOOB case, a= nd I leave it to the authors to respond to your other comments. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl75R0YACgkQgItw+93Q 3WVSEwf/XLh1lMokJI+hi4FnrGCmPuvPtjB+QwHROA4aFFuQ6DoVOxIKHuis09Gx VNnfet2f9fKf6FilZ2F9mUXEB3yLfb4gsQyytdiINOS6TWoxnxzmQGHhXIioqlLD vG9YuZQ/2LVDmZIwAFBjem6RV5W6dDn8Ktydvfv8g7kBHD+adyGaxswS1hzJXLe7 /K21MGOjF0Dg7ZApRbkMMYsAeVuLhNa3OFLVn/k+/eor7r4+bXS2LCPl/+qTUOf3 8GjgEUkgYeKkfNGXokLE72SbPeIULwQqNKTj8R02xxMTtWY7KVYBR5caTWEH+BSU 8WFTo32gf/rHFZzG3em9Ed4g7e45cg== =SaKs -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 29 06:49:10 2020 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 7AA453A0EF2 for ; Mon, 29 Jun 2020 06:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeeYj2XfIV5a for ; Mon, 29 Jun 2020 06:49:06 -0700 (PDT) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 467233A0EF3 for ; Mon, 29 Jun 2020 06:49:06 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id n5so15572753otj.1 for ; Mon, 29 Jun 2020 06:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mmeB7GV5yzxhnk6+Elv2UAJV6fBl2oEF/Fd1aoj4guQ=; b=G6jjasxphdCzvYPvx6M3wmvaJoQuB4yW0BTtW5+FP59XF+4fO/Rur3mX8YInalP4tp mCA004AHGDV0xP1OVLAvv44sgTxZTmYXjN7pcHfq/u8nj8K1+X4NWF4wD5UoJkYNb6qa YM9XZjhr20CQagSdahIG13z51OotQJrnnWi1eT0ZSxZFl5ODg3QA8MQkphrrQJ2F2Uua J6X+LhiKqwJoyeeS0FCtSAP9eaAgPWq+ZUl0gFD7yD5dHGdtudnQaY/Ek8nc1oT40UZP ygGZ3HZXDVRjUMWiDOVRLOJoOyUk/kMEbSxMRVpbR2cKltDet8pET4AFSNe9p5AMZfjh sWww== 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=mmeB7GV5yzxhnk6+Elv2UAJV6fBl2oEF/Fd1aoj4guQ=; b=qAzfDkyba36aFMYJD0mSzAmJghiN6oZh2QVxXj0spW04GSLITwpUIAU8odVOAktdm0 JzzJGmVBLV5ULE6gBBiQb/fQe0FdMl/mb9y9tC1HIICga3jY7E5Ykx6TIavzu6xdSxd2 z11gOu/VLD9JQ7rAO1IVQFZ+ZVsCBRVnaHLtfzvx8AN1xbxnIBWfdoNd15ElLpOw+ZT5 wW8JKBJQKtsqvfXm02W4wZOiw3T7C4vnRZooNJvBj8+EEivhZMq6PgsQ/sJ3nfx+ulW7 I3TcPvVL164xwTUnDLWGlY7GGTsMF0fU43Z/2aI11/vGtYeGcu5HhXSVY0Ql/DCNHwow NBdA== X-Gm-Message-State: AOAM530cAEQ7NlHk1qa7sa1uOs24j7c5HQdVzbiUI117kDpxTY5NaZHP LhvqVyWRMMwW0BnoWnWMU6jxmS1WZZYjv01QxrE= X-Google-Smtp-Source: ABdhPJz2vDVyET7OtmG7ZN70tr8RhBchFXnGS/fGcLzz8YcKwPqTbknl1meJxdio7K7Lk3iSVeTlGYf4oS4zF5vZayI= X-Received: by 2002:a9d:4c13:: with SMTP id l19mr14053608otf.341.1593438545402; Mon, 29 Jun 2020 06:49:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Oleg Pekar Date: Mon, 29 Jun 2020 16:48:54 +0300 Message-ID: To: Jorge Vergara Cc: Joseph Salowey , Jouni Malinen , EMU WG Content-Type: multipart/alternative; boundary="00000000000078609d05a9395264" Archived-At: Subject: Re: [Emu] TEAP - RFC 7170 - Errata ID 5768 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, 29 Jun 2020 13:49:09 -0000 --00000000000078609d05a9395264 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jorge, Joe, thank you for your comments. So the updated proposal should be: 1) In Section "4.2.13. Crypto-Binding TLV" make "EMSK Compound MAC" and "MSK Compound MAC" fields variable length depending on the number of output bits of the MAC function negotiated by TLS protocol. A field "Compound MAC Length" of size 1 octet is added after the "Nonce" field to represent the length of each of "EMSK Compound MAC" and "MSK Compound MAC" fields. The minimum length for each Compound MAC field is 20 octets (to honor the original RFC fixed size and to allow usage of SHA-1 - that is still used in TLS 1.2 - to provide MAC without padding). The length should never be less than 20 octets since there are no ciphers supported by TLS 1.2 with a digest of less than 160 bits output size. Therefore if "Compound MAC Length" field value is less than 20 then the Crypto-binding TLV should be considered of erroneous format and handled as described in section 3.6. Error Handling. The value of the length field of the whole Crypto-Binding TLV should be calculated accordingly (currently fix 76 octets). The updated structure of Crypto-Binding TLV: The Crypto-Binding TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Version | Received Ver.| Flags|Sub-Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Comp MAC Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ EMSK Compound MAC ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ MSK Compound MAC ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If we would not bump the TEAP protocol version - we still can change the Crypto-Binding TLV version to 2. 2) [This was accepted and stays unchanged] 3) In Section "5.3. Computing the Compound MAC" when specifying the list of fields to be placed in the BUFFER" should say "...2 A single octet contains TEAP EAP method type 0x37". However to let this byte play a role in protection of Crypto-Binding TLV I would suggest to place in it the inner EAP method type related to the calculation or 0x0 if no inner EAP method was executed. What are your opinions on this? Thanks Oleg On Tue, May 26, 2020 at 12:29 PM Jorge Vergara wrote: > > > *From:* Joseph Salowey > *Sent:* Monday, May 25, 2020 9:27 PM > *To:* Jorge Vergara > *Cc:* Oleg Pekar ; Jouni Malinen ; > EMU WG > *Subject:* Re: [Emu] TEAP - RFC 7170 - Errata ID 5768 > > > > > > > > On Fri, May 22, 2020 at 1:18 PM Jorge Vergara 40microsoft.com@dmarc.ietf.org> wrote: > > My review of this errata and the current responses from Oleg: > > > > 1. I agree with this proposed resolution. I do think this is an > important omission that needs to be clarified in the RFC. Otherwise it= is > somewhat guesswork that truncation is the right action. I think the cu= rrent > wording leans toward truncation, but I definitely asked this question > myself while implementing. > > [Joe] Why not just change the TLV to be variable length? It seems if we > hardcode the length to 100 we risk having the same problem in the future? > > > > [Jorge] I have to admit that in my original response my brain skipped ove= r > the TLV length adjustment and focused only on the truncation. If the TLV > length is going to be adjusted at all, I am in favor of making the TLV > variable length. A minimum length could also be added (32 bits seems to b= e > the current recommendation). However, I do believe this is a breaking > change to any TEAP implementation =E2=80=93 would the TEAP version need t= o be > bumped? > > > 1. > 2. This bleeds into Alan=E2=80=99s TLS 1.3 document somewhat, but I ag= ree with > Jouni that this will need to change when the rest of the document is > eventually updated to TLS 1.3.. There are enough TLS 1.3 related thing= s to > address in TEAP that I don=E2=80=99t exactly view this as an errata. I= view it as a > needed update, whether in this document, Alan=E2=80=99s document, or b= oth. > > [Joe] I tend to agree that this is not an errata. However an update to > TEAP should address these. > > > > > 1. > 2. Agree with Jouni that I don=E2=80=99t see the point of the 0x37 oct= et, but > regardless this clarification of how it is encoded is positive (minor) > change. > > [Joe] I think the original reason to include the TEAP method ID in the > specification was to make sure that we differentiated between similar > crypto binding implementations in other protocols such as EAP-FAST. I > don't think there is much ambiguity here, but I am OK with including 0x37 > in the description. > > > > > > Thanks, > > Jorge > > > > *From:* Emu *On Behalf Of *Oleg Pekar > *Sent:* Tuesday, May 5, 2020 6:27 AM > *To:* Jouni Malinen ; EMU WG > *Subject:* [Emu] TEAP - RFC 7170 - Errata ID 5768 > > > > Hi Jouni, > > I propose the following fix for the issues described in this errata id: > > 1) In Section "4.2.13. Crypto-Binding TLV" make "EMSK Compound MAC" and > "MSK Compound MAC" fields 32 octets long (currently 20 octets). The MAC > value is truncated at 32 octets if it is longer than 32 octets or padded = to > a length of 32 octets with zeros to the right if it is less than 32 octet= s. > The length of the TLV should be changed to 100 bytes (currently 76). > > > > The motivation is to keep collision-resistance strength of MAC on 128 bit= . > Hash value truncation is described in "NIST Special Publication 800-107 > Revision 1: Recommendation for Applications Using Approved Hash Algorithm= s" > > > > > > 2) In Section "5.3. Computing the Compound MAC" specify that "MAC is the > MAC function negotiated in TLS of TEAP Phase 1" (currently it says TLS > 1.2) > > > > The motivation is to support TLS 1.2, 1.3 and possibly later TLS versions= . > > > > 3) In Section "5.3. Computing the Compound MAC" when specifying the list > of field to be placed in the BUFFER" should say "...2 A single octet > contains TEAP EAP method type 0x37". Alternatively it could be "...2 A > single octet contains EAP Type of the inner EAP method related to the > calculation or 0 if no inner EAP method was executed" (currently "...2 T= he > EAP Type sent by the other party in the first TEAP message") > > > > Please note that there's still a discussion on sending Crypto-Binding TLV > on "Authentication inner EAP method" or "Inner EAP method that exports MS= K" > only. > > > > Thanks > > Oleg > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > > --00000000000078609d05a9395264 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jorge, Joe, thank you for your comments. = So the updated proposal should be:

1) In Section "4= .2.13.=C2=A0 Crypto-Binding TLV" make "EMSK Compound MAC" an= d "MSK Compound MAC" fields variable length depending on the numb= er of output bits of the MAC function negotiated by TLS protocol. A field &= quot;Compound MAC Length" of size 1 octet is added after the "Non= ce" field to represent the length of each of "EMSK Compound MAC&q= uot; and "MSK Compound MAC" fields. The minimum length for each C= ompound MAC field is 20 octets (to honor the original RFC fixed size and to= allow usage of SHA-1 - that is still used in TLS 1.2 - to provide=C2=A0MAC= without padding). The length should never be=C2=A0less than 20 octets sinc= e there are no ciphers supported by TLS 1.2 with a digest of less than 160 = bits output size. Therefore if "Compound MAC Length" field value = is less than 20 then the Crypto-binding TLV should be considered of erroneo= us=C2=A0format and handled as described in section=C2=A03.6. Error Handling= . The value of the length field of the whole Crypto-Binding TLV should be c= alculated accordingly (currently fix 76 octets).=C2=A0

The updated structure of Crypto-Binding TLV:

<= div>
The Crypto-Binding TLV is defined as follow=
s:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |    Version    |  Received Ver.| Flags|Sub-Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Nonce                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef= ore:page;color:rgb(0,0,0)"> | Comp MAC Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
/pre>
   |    =
                                                           |
   ~                   EMSK Compound MAC                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    MSK Compound MAC                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<=
pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef=
ore:page;color:rgb(0,0,0)">
If we would not bump the TEAP protocol version - we =
still can change the Crypto-Binding TLV version to 2.

2) [This was accept=
ed and stays unchanged]=C2=A0

3)=C2=A0In Section "5.3.=C2=
=A0 Computing the Compound MAC" when specifying the list of fields=C2=
=A0to be placed in the BUFFER" should say=C2=A0"...2 =C2=A0A sing=
le octet contains TEAP EAP method type 0x37". However to let this byte=
 play a role in protection of Crypto-Binding TLV I would suggest to place i=
n it the inner EAP method type related to the calculation or 0x0 if no inne=
r EAP method was executed. What are your opinions on this?

Thanks
Oleg

=

On Tue=
, May 26, 2020 at 12:29 PM Jorge Vergara <jovergar@microsoft.com> wrote:











=C2=A0




From: Joseph Salowey <joe@salowey.net> 

Sent: Monday, May 25, 2020 9:27 PM

To: Jorge Vergara <jovergar@microsoft.com>

Cc: Oleg Pekar <oleg.pekar.2017@gmail.com>; Jouni Malinen <j@w1.fi>; EMU WG <emu@ietf.org>

Subject: Re: [Emu] TEAP - RFC 7170 - Errata ID 5768



=C2=A0






=C2=A0




=C2=A0






On Fri, May 22, 2020 at 1:18 PM Jorge Vergara <jo=
vergar=3D40microsoft.com@dmarc.ietf.org> wrote:










My review of this errata and the current responses f=
rom Oleg:


=C2=A0


    

  1. 
I agree with this proposed resolution. I do think this is an important omis=
sion that needs to be clarified in the RFC. Otherwise it is somewhat guessw=
ork that truncation is the right action. I think the current wording leans =
toward truncation, but I definitely
 asked this question myself while implementing.










[Joe]=C2=A0 Why not just change the TLV to be variab=
le length?=C2=A0 It seems if we hardcode the length to 100 we risk having t=
he same problem in the future?=C2=A0=C2=A0






=C2=A0


[Jorge] I have to admit that in my original response=
 my brain skipped over the TLV length adjustment and focused only on the tr=
uncation. If the TLV length is going to be adjusted at all, I am in favor o=
f making the TLV variable length.
 A minimum length could also be added (32 bits seems to be the current reco=
mmendation). However, I do believe this is a breaking change to any TEAP im=
plementation =E2=80=93 would the TEAP version need to be bumped?<=
/u>










    

  1. 
=C2=A0
  2. 
This bleeds into Alan=E2=80=99s TLS 1.3 document somewhat, but I agree with=
 Jouni that this will need to change when the rest of the document is event=
ually updated to TLS 1.3.. There are enough TLS 1.3 related things to addre=
ss in TEAP that I don=E2=80=99t exactly view this
 as an errata. I view it as a needed update, whether in this document, Alan=
=E2=80=99s document, or both.










[Joe]=C2=A0 I tend to agree that this is not an erra=
ta.=C2=A0 However an update to TEAP should address these.=C2=A0






=C2=A0










    

  1. 
=C2=A0
  2. 
Agree with Jouni that I don=E2=80=99t see the point of the 0x37 octet, but =
regardless this clarification of how it is encoded is positive (minor) chan=
ge.










[Joe] I think the original reason to include the TEA=
P method ID in the specification was to make sure that we differentiated be=
tween similar crypto binding implementations in other protocols such as EAP=
-FAST.=C2=A0 =C2=A0I don't think there is much
 ambiguity here, but I am OK with including 0x37 in the description.=C2=A0=
=C2=A0






=C2=A0










=C2=A0


Thanks,


Jorge


=C2=A0




From: Emu <emu-bounces@ietf.org>
On Behalf Of Oleg Pekar

Sent: Tuesday, May 5, 2020 6:27 AM

To: Jouni Malinen <j=
@w1.fi>; EMU WG <emu@ietf.org>

Subject: [Emu] TEAP - RFC 7170 - Errata ID 5768




=C2=A0




Hi Jouni,




I propose the following fix for the issues described=
 in this errata id:






1) In Section "4.2.13.=C2=A0 Crypto-Binding TLV=
" make "EMSK Compound MAC" and "MSK Compound MAC" =
fields 32 octets long (currently 20 octets). The=C2=A0MAC value is truncate=
d at 32 octets
 if it is longer than 32 octets or=C2=A0padded to a length of 32 octets wit=
h zeros to the right if it is less than 32 octets. The length of the TLV sh=
ould be changed to 100 bytes (currently 76).=C2=A0






=C2=A0






The motivation is to keep=C2=A0collision-resistance =
strength of MAC on 128 bit. Hash value=C2=A0truncation is described in

"NIST Special Publication 800-107 Revision 1: Recommendation for Appli=
cations Using Approved Hash Algorithms"=C2=A0






=C2=A0






2) In Section "5.3.=C2=A0 Computing the Compoun=
d MAC" specify that "MAC is the MAC function negotiated in TLS of=
=C2=A0TEAP Phase 1" =
(currently
 it says TLS 1.2)






=C2=A0






The motivation is to support TLS 1.2, 1.3 and possib=
ly later TLS versions.






=C2=A0






3)=C2=A0In Section "5.3.=C2=A0 Computing the Co=
mpound MAC" when specifying the list of field=C2=A0to be placed in the=
 BUFFER" should say=C2=A0"...2 =C2=A0A single octet contains TEAP=
 EAP method type 0x37".
 Alternatively it could be "...2 =C2=A0A single octet contains EAP Typ=
e of the inner EAP method related to the calculation or 0 if no inner EAP m=
ethod was executed" (currently "...2 =C2=A0The EAP Type sent by t=
he other party in the first TEAP message")






=C2=A0






Please note that there's still a discussion on s=
ending Crypto-Binding TLV on "Authentication inner EAP method" or=
 "Inner EAP method that exports MSK" only.






=C2=A0






Thanks






Oleg










_______________________________________________

Emu mailing list

Emu@ietf.org

https://www.ie=
tf.org/mailman/listinfo/emu

















--00000000000078609d05a9395264--


From nobody Mon Jun 29 06:55:22 2020
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 362BF3A0F08 for ; Mon, 29 Jun 2020 06:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level: 
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIiimYDbwUnn for ; Mon, 29 Jun 2020 06:55:17 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 5E6223A0F06 for ; Mon, 29 Jun 2020 06:55:17 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id 95so4911782otw.10 for ; Mon, 29 Jun 2020 06:55:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uPQ2T1hI76DOFFo1AsCNRMJmd0o6MTkyxyjAcudxiOQ=; b=us0YBVkwAYbsWHH1j/DPLxWsdj8zv08peHFI3LtSYlAVX6SCtCrXZBwLZ43MgYtrDl BKZVStqhPWAOBF5Vx+wg/A0pdORtjcGe3ikAbNcSGqXpIDKKCX5eQK7lJykicyvl0AhH l7ghx9wsDYuPPfjAh1eVBXz2QSUTclPTz6Sh4l6d9WIy/g+Y9+3j9OXIsBLPXNuFlbNr KSJ0SE+Ai3TWCUaJCycEGYgO4v46AAHJvHmT4krNVRdA4Hb8DWreilpbh9KsEi7cDqdP FS623Zo0HHkrJ/zJufDcKl0lo+GgLnDnork71r5BTLvbMTRp+1MFYMl4mAinvcKC+aF2 TD+A==
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=uPQ2T1hI76DOFFo1AsCNRMJmd0o6MTkyxyjAcudxiOQ=; b=jMxQkuo/naRb8UpUv0QEashS1dIsqgPfOZMaL6/FwI/C1JnTRNivg8w2CfAdmuQ3WY bTYqzMiqIcNCJ5OBgyCEo/rLgxuZoy8ciyU4hPhQV504mk99UDhbh7d5zxbPAxfDQ4Aw Zvdm+j76kWj4vbb9gge1iuY7IpJ0yp5tor1QDoo20PgJrftu8I991eXEKLMl2iN51t14 MchwAo61llZ42mXbRJqfBuS3Q15cowfdeSSzl9+1zIDm0jJqMJ3baiJYNvSJk4L7xdSw argRQFt5bywmdj9mUjUur6Gh0YJqhCj6zxUVZmk3BL4CQlN6IO9H+tKGBG8a/zp6twVt PkNQ==
X-Gm-Message-State: AOAM532nFBbdV45MRejQCRJy2Ly7ZLbgnIwX5SNkQngSFii00EpYe2hU XeDzfmLRV5UH8Y6b+/dMREFGuAvqw10DD5+882CeKw59
X-Google-Smtp-Source: ABdhPJwoRK5AkjqFXfvIdurrZZEUUpxZUacMaIj3zvIb1gxSUoBL4frZBv4EjOYQZb3hmTyNo93kb4SB6OYvzfMiW0A=
X-Received: by 2002:a9d:3e57:: with SMTP id h23mr13306876otg.44.1593438916621;  Mon, 29 Jun 2020 06:55:16 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Oleg Pekar 
Date: Mon, 29 Jun 2020 16:55:05 +0300
Message-ID: 
To: Jorge Vergara 
Cc: Jouni Malinen , EMU WG 
Content-Type: multipart/alternative; boundary="00000000000098b89005a93968d5"
Archived-At: 
Subject: Re: [Emu] TEAP - RFC 7170 - Errata
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, 29 Jun 2020 13:55:20 -0000

--00000000000098b89005a93968d5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Jorge, thanks for correction: Intermediate-Result TLV must be sent at the
end of Basic Password Authentication. I think we also need to list all four
inner method cases that I mention in above explicitly, for example in
"3.3.3.  Protected Termination and Acknowledged Result Indication" section.

Since every Intermediate-Result TLV indicating success must be accompanied
with Crypto-Binding TLV (section "4.2.11.  Intermediate-Result TLV") -
please refer to the Zero-MSK addition discussed in the other thread with
subject "[Emu] draft-dekok-emu-tls-eap-types discussion". Zero-MSK based
Crypto-Binding TLV should be used when we have no inner method or after
Basic Password Authentication exchange. Per Joe's suggestion and Jorge's
confirmation we should not support downgrading from MSK to Zero MSK if the
inner method supports MSK.

Thanks
Oleg

On Fri, May 22, 2020 at 11:56 PM Jorge Vergara 
wrote:

> I am going to consider these 3 errata separately as I think it is cleares=
t:
>
>
>
> Errata ID 5767:
>
>
>
> I believe Jouni=E2=80=99s differentiation of an =E2=80=9CEAP authenticati=
on method=E2=80=9D vs
> =E2=80=9CEAP method=E2=80=9D is that an =E2=80=9CEAP authentication metho=
d=E2=80=9D has a type >=3D 4. Jouni
> mentions this in his errata filing and it is also mentioned in RFC 3748
> Section 2.1  (possibly
> other places also). Jouni, I apologize if I have misinterpreted =E2=80=93=
 please
> correct me if so.
>
>
>
> So, an EAP-Identity (type 1) request is an =E2=80=9CEAP method=E2=80=9D, =
but there is
> obviously no intermediate result TLV or crypto binding TLV exchanged afte=
r
> an EAP-Identity exchange.
>
>
>
> Jouni has done an excellent job in this errata of identifying where the
> terminology should be updated, and I agree with Jouni=E2=80=99s changes. =
I think
> the intent of the RFC in the four instances Jouni identified was fairly
> clear.
>
>
>
> Errata ID 5844:
>
>
>
> Oleg, your final proposal seems to indicate that an Intermediate-Result
> TLV should NOT be sent after Basic Password Authentication =E2=80=93 I=E2=
=80=99m not sure I
> follow this. Section 3.3.2 outlines that an Intermediate-Result TLV SHOUL=
D
> be sent after Basic Password Authentication.
>
>
>
> So I find this errata valid and agree with Jouni that section C.1 and C.2
> should be updated to include the Intermediate-Result TLV in the diagrams.
>
>
>
> I agree with the rest of the proposals Jouni has made as well that this
> should be made clearer throughout the document. Most of the time where th=
e
> Intermediate-Result TLV is mentioned, only EAP is discussed and the Basic
> Password Authentication is forgotten. I don=E2=80=99t believe Jouni=E2=80=
=99s proposals
> change any timings =E2=80=93 just clarify the language.
>
>
>
> Errata ID 5845:
>
>
>
> I find the errata valid and agree with Jouni. The direction in the rest o=
f
> the document seems to be that an Intermediate-Result TLV is always
> exchanged (after both EAP authentication methods and Basic Password
> Authentications) and the text in 3.3.1 is confusing.
>
>
>
> *****
>
>
>
> In summary =E2=80=93 I find all of these errata valid and appreciate Joun=
i=E2=80=99s
> suggestions for clarifications. I find them all to be language
> clarifications and don=E2=80=99t believe any exchanges need to be altered=
.
>
>
>
> Oleg, your final proposal seems to be removing the exchange of
> Intermediate-Result TLVs in the Basic Password Authentication case =E2=80=
=93 I am
> not sure I follow this but if you believe this is needed for the resoluti=
on
> of this errata I would like to better understand why.
>
>
>
> Thanks,
>
> Jorge
>
>
>
> *From:* Emu  *On Behalf Of * Oleg Pekar
> *Sent:* Sunday, May 3, 2020 10:02 AM
> *To:* Jouni Malinen ; EMU WG 
> *Subject:* [Emu] TEAP - RFC 7170 - Errata
>
>
>
> Hi Jouni,
>
> You filed Errata ID: 5767, 5844, 5845 regarding sending of
> Intermediate-Result TLV. Can we clarify a general scheme of
> sending Intermediate-Result TLV and Crypto-Binding TLV in all cases? It i=
s
> not exactly clear what is "EAP authentication method" and what is its
> different from "EAP method" (you referred to appendix C.3 as an example o=
f
> "EAP Method" but it is not clear why it is not an "EAP authentication
> method" - could you please clarify).
>
>
>
> Here's the list of cases with the current RFC instructions (please add if
> something is missing):
>
>
>
> 1. A single inner EAP method is executed inside the tunnel.
>
> *** RFC says ***
>
> Section 4.2.11 "An Intermediate-Result TLV indicating success MUST be
> accompanied by a Crypto-Binding TLV". Section 3.3 "Phase 2 MUST always en=
d
> with a Crypto-Binding TLV exchange"
>
>
>
> 2. Multiple inner EAP methods are executed inside the tunnel.
>
> *** RFC says ***
>
> Send Intermediate-Result TLV if more than one method is going to be
> executed in the tunnel. Send Crypto-Binding TLV if Intermediate-Result
> TLV indicates success.
>
> Section 3.3.1 "If more than one method is going to be executed in the
> tunnel, then upon method completion, the server MUST send an
> Intermediate-Result TLV indicating the result" - wrong
>
> Section 3.3.3 "The Crypto-Binding TLV and Intermediate-Result TLV MUST be
> included to perform cryptographic binding after each successful EAP metho=
d
> in a sequence of one or more EAP methods" - correct
>
>
>
> 3. Basic Password Authentication (using Basic-Password-Auth-Req/Response)
> is executed inside the tunnel
>
> *** RFC says ***
>
> Send Intermediate-Result TLV.
>
> Section 3.3.2 "Upon receiving the response, the server indicates the
> success or failure of the exchange using an Intermediate-Result TLV" - th=
us
> Crypto-Binding TLV MUST be also sent as quoted in #1.
>
>
>
> 4. No inner EAP method is executed inside the tunnel.
>
> *** RFC says ***
>
> Section 3.3.3 "A successful TEAP Phase 2 conversation MUST always end in
> a successful Crypto-Binding TLV and Result TLV exchange.  A TEAP server m=
ay
> initiate the Crypto-Binding TLV and Result TLV exchange without initiatin=
g
> any EAP conversation in TEAP Phase 2"
>
> Section 4.2.13 "The Crypto-Binding TLV MUST be exchanged and verified
> before the final Result TLV exchange, regardless of whether there is an
> inner EAP method authentication or not"
>
>
>
> ******
>
> Jouni, you provided multiple suggestions for fixing this. Incorporating
> you suggestions, the bottomline could be:
>
> * Send Intermediate-Result TLV after each inner EAP method but not after =
Basic
> Password Authentication TLV exchange
>
> * Send Crypto-Binding TLV based on inner method MSK/EMSK after each inner
> EAP method that exports MSK/EMSK and send Crypto-Binding TLV based on
> Zero-MSK in case of no inner method was executed
>
>
>
> And then it should be declared explicitly and all the places where these
> TLV are mentioned can be fixed accordingly.
>
>
>
> Please share your opinion.
>
> ~ Oleg
>
>
>
>
>
>
>

--00000000000098b89005a93968d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Jorge, thanks for correction: Intermediate-Result TLV=
 must be sent at the end of Basic Password Authentication. I think we also =
need to list all four inner method cases that I mention in above explicitly=
, for example in "3.3.3.=C2=A0 Protected Termination and Acknowledged =
Result Indication" section.=C2=A0

Since every=
=C2=A0Intermediate-Result TLV indicating success must be accompanied with C=
rypto-Binding TLV (section "4.2.11.=C2=A0 Intermediate-Result TLV"=
;) - please refer to the Zero-MSK addition discussed in the other thread wi=
th subject "[Emu] draft-dekok-emu-tls-eap-types discussion". Zero=
-MSK based Crypto-Binding TLV should be used when we have no inner method o=
r after Basic Password Authentication exchange. Per Joe's suggestion an=
d Jorge's confirmation we should not support downgrading from MSK to Ze=
ro MSK if the inner method supports MSK.

Thanks
Oleg

On Fri, May 22, 2020 at 11:56 PM Jorge Vergara <jovergar@microsoft.co=
m> wrote:











I am going to consider these 3 errata separately as =
I think it is clearest:


=C2=A0


Errata ID 5767:


=C2=A0


I believe Jouni=E2=80=99s differentiation of an =E2=
=80=9CEAP authentication method=E2=80=9D vs =E2=80=9CEAP method=E2=80=9D is=
 that an =E2=80=9CEAP authentication method=E2=80=9D has a type >=3D 4. =
Jouni mentions this in his errata filing and it is also mentioned in
RFC 3748 Section 2.1 (possibly other places also). Jouni, I apologiz=
e if I have misinterpreted =E2=80=93 please correct me if so.=



=C2=A0


So, an EAP-Identity (type 1) request is an =E2=80=9C=
EAP method=E2=80=9D, but there is obviously no intermediate result TLV or c=
rypto binding TLV exchanged after an EAP-Identity exchange.

=C2=A0


Jouni has done an excellent job in this errata of id=
entifying where the terminology should be updated, and I agree with Jouni=
=E2=80=99s changes. I think the intent of the RFC in the four instances Jou=
ni identified was fairly clear.


=C2=A0


Errata ID 5844:


=C2=A0


Oleg, your final proposal seems to indicate that an =
Intermediate-Result TLV should NOT be sent after Basic Password Authenticat=
ion =E2=80=93 I=E2=80=99m not sure I follow this. Section 3.3.2 outlines th=
at an Intermediate-Result TLV SHOULD be sent after
 Basic Password Authentication.


=C2=A0


So I find this errata valid and agree with Jouni tha=
t section C.1 and C.2 should be updated to include the Intermediate-Result =
TLV in the diagrams.


=C2=A0


I agree with the rest of the proposals Jouni has mad=
e as well that this should be made clearer throughout the document. Most of=
 the time where the Intermediate-Result TLV is mentioned, only EAP is discu=
ssed and the Basic Password Authentication
 is forgotten. I don=E2=80=99t believe Jouni=E2=80=99s proposals change any=
 timings =E2=80=93 just clarify the language.


=C2=A0


Errata ID 5845:


=C2=A0


I find the errata valid and agree with Jouni. The di=
rection in the rest of the document seems to be that an Intermediate-Result=
 TLV is always exchanged (after both EAP authentication methods and Basic P=
assword Authentications) and the text
 in 3.3.1 is confusing.


=C2=A0


*****


=C2=A0


In summary =E2=80=93 I find all of these errata vali=
d and appreciate Jouni=E2=80=99s suggestions for clarifications. I find the=
m all to be language clarifications and don=E2=80=99t believe any exchanges=
 need to be altered.


=C2=A0


Oleg, your final proposal seems to be removing the e=
xchange of Intermediate-Result TLVs in the Basic Password Authentication ca=
se =E2=80=93 I am not sure I follow this but if you believe this is needed =
for the resolution of this errata I would
 like to better understand why.


=C2=A0


Thanks,


Jorge


=C2=A0




From: Emu <emu-bounces@ietf.org> On Behalf Of 
Oleg Pekar

Sent: Sunday, May 3, 2020 10:02 AM

To: Jouni Malinen <j=
@w1.fi>; EMU WG <emu@ietf.org>

Subject: [Emu] TEAP - RFC 7170 - Errata




=C2=A0




Hi=C2=A0Jouni,




You filed=C2=A0Errata ID: 5767, 5844, 5845 regarding=
 sending of Intermediate-Result TLV. Can we clarify a general scheme of sen=
ding=C2=A0Intermediate-Result TLV and Crypto-Binding TLV in all cases? It i=
s not exactly clear what is "EAP authentication
 method" and what is its different from "EAP method" (you re=
ferred to appendix C.3 as an example of "EAP Method" but it is no=
t clear why it is not an "EAP authentication method" - could you =
please clarify).






=C2=A0






Here's the list of cases with the current RFC in=
structions (please add if something is missing):






=C2=A0






1. A single inner EAP method is executed inside the =
tunnel.=C2=A0










*** RFC says ***=C2=A0






Section 4=
.2.11 "An Intermediate-Result TLV indicating success MUST be ac=
companied by a Crypto-Binding TLV". Section 3.3 "Phase 2 MUST alw=
ays end with a Crypto-Binding TLV exchange"










=C2=A0






2. Multiple=C2=A0inner EAP methods are executed insi=
de the tunnel.=C2=A0






*** RFC says ***=C2=A0








Send=C2=
=A0Intermediate-Result TLV=C2=A0if more than one method is going to =
be executed in the tunnel. Send=C2=A0Crypto-Binding TLV if=C2=A0Intermediate-Result
 TLV indicates success.






Section 3.3.1 "If more than one method is going=
 to be executed in the tunnel, then upon method completion, the server MUST=
 send an Intermediate-Result TLV indicating the result" - wrong=







Section 3.3.3 "The Crypto-Binding TLV and Inter=
mediate-Result TLV MUST be included to perform cryptographic binding after =
each successful EAP method in a sequence of one or more EAP methods" -=
 correct








=C2=A0






3.=C2=A0B=
asic Password Authentication (using=C2=A0Basic-Password-Auth-Req/Response) =
is executed inside the tunnel








*** RFC says ***






Send=C2=
=A0Intermediate-Result TLV.=C2=A0






Section 3=
.3.2 "Upon receiving the response, the server indicates the suc=
cess or failure of the exchange using an Intermediate-Result TLV" - th=
us Crypto-Binding TLV MUST be also sent as quoted
 in #1.






=C2=A0








4. No inn=
er EAP method is executed inside the tunnel.








*** RFC says ***






Section 3=
.3.3 "A successful TEAP Phase 2 conversation MUST always end in=
 a successful Crypto-Binding TLV and Result TLV exchange.=C2=A0 A TEAP serv=
er may initiate the Crypto-Binding TLV and Result
 TLV exchange without initiating any EAP conversation in TEAP Phase 2"=







Section 4=
.2.13 "The Crypto-Binding TLV MUST be exchanged and verified be=
fore the final Result TLV exchange, regardless of whether there is an inner=
 EAP method authentication or not"








=C2=A0






******






Jouni, yo=
u provided multiple suggestions for=C2=A0fixing this. Incorporating you sug=
gestions, the=C2=A0bottomline could be:






*=C2=A0Se=
nd=C2=A0Intermediate-Result TLV after each inner EAP method but not after=
=C2=A0Basic Password Authentication TLV exchange






* Send=C2=A0Crypto-Binding TLV based on inner method=
 MSK/EMSK after each inner EAP method that exports MSK/EMSK and send Crypto=
-Binding TLV based on Zero-MSK in case of no inner method was executed






=C2=A0






And then it should be declared explicitly and all th=
e places where these TLV are mentioned can be fixed accordingly.=C2=A0






=C2=A0






Please share your opinion.






~ Oleg






=C2=A0






=C2=A0






=C2=A0













--00000000000098b89005a93968d5--


From nobody Mon Jun 29 07:09:26 2020
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 B0E4A3A0E5C for ; Mon, 29 Jun 2020 07:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level: 
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09zb1YmX7DLV for ; Mon, 29 Jun 2020 07:09:23 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 E12963A0941 for ; Mon, 29 Jun 2020 07:09:22 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id t18so2804725otq.5 for ; Mon, 29 Jun 2020 07:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2HNgmYiL51ci6/vLxFvFrVjB4kjVwvMozPx9wngZffs=; b=CMSSzmdJfXVK67rN4pdSaIpitxPBQebThWkD2G2A9M6HqCILn2jU8Qdoo8M5KZ2ZD6 grsx46BGQxVY9IRujkkCbUK6FRvz3ZdyaE3lPPfzQqhwlfl8ifPT6WKfLPoG7ZTMQx79 TM1YfMyej/BGcD7L/84GakXYRBTFAmVMMMgRKINHE3dRngLAlPzEDQVifildH7q9qMsg uf5xvgTE14JBmckXhwl9rq9XOEbT48xYs53YdwkQFYzgOBcnJSZobW55xliazczxBt4j 1kt2gz0oKvs32GZ96R2E1Mv7NpRE3zNP40rDN+MEQ+M4iF1bxCqXnho1s7bp0D+WmY53 z6zA==
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=2HNgmYiL51ci6/vLxFvFrVjB4kjVwvMozPx9wngZffs=; b=MLi7ogDSdZHSqUtbQCt3VnUfuRRZHipb5IbPgkh3g1z8L0k1Y1RamDma7kOzqBt8Jz vfCDFL6qhONiY3lGuARu4eJDIxRSih+3VC30vLD6YgZRq8D8DWEfeR3PfrUSEMlfzckN EqSSI1krJHGEfKxmcWVjXjF4xa9K0R7VDxuREFW0eR9ooSRR6+rlxRVvAf6fKf8kJp/9 Drw7257OxxYkaplt/SFQulYYELpv2wFK9jSXp0zJYtA/UzGTtuXJy0UgwVuLgHmDzYbC ql28O92aKTqP4f75MxvEPLQ1J4uYb0UQs+tw2JsfwEhQiS9wvo62JFRIg30NZtoEZeES KRgQ==
X-Gm-Message-State: AOAM533kA7ZQB4EwuYw6EnbxdIJ578d1LLyEWkYff/8AbB/sfIcy4dYL rIQoCJHSmi9juQY6lVjxT4yS/q7AHbtah1ULEaU=
X-Google-Smtp-Source: ABdhPJxeVt8YRV2pRgBfDUlS9p+2BHRQSftpmgjOXcrIpvgjv2SdfBlSwi/1BlFLrl4vWsCJwSC6iDSIBKapK1bU2HQ=
X-Received: by 2002:a9d:3e57:: with SMTP id h23mr13369378otg.44.1593439762148;  Mon, 29 Jun 2020 07:09:22 -0700 (PDT)
MIME-Version: 1.0
References:  <4642013A-3A2E-42C8-8604-67031D78B757@cisco.com>
In-Reply-To: <4642013A-3A2E-42C8-8604-67031D78B757@cisco.com>
From: Oleg Pekar 
Date: Mon, 29 Jun 2020 17:09:10 +0300
Message-ID: 
To: Eliot Lear 
Cc: Joseph Salowey , EMU WG 
Content-Type: multipart/alternative; boundary="000000000000fe710705a9399abd"
Archived-At: 
Subject: Re: [Emu] TEAP errata 5770
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, 29 Jun 2020 14:09:25 -0000

--000000000000fe710705a9399abd
Content-Type: text/plain; charset="UTF-8"

Joe, nice proposal. Few questions:
1. We have a case of Basic Password Authentication instead of inner method
thus we should also use Crypto-Binding TLV based on Zero-MSK after it
2. As Eliot mentioned, we have a case of no inner method at all - we should
use Crypto-Binding TLV based on Zero-MSK after it
3. Since it is not clear whether MSK or Zero-MSK is used - we should
introduce a new flag value for Crypto-Binding TLV: "0" - Zero-MSK
based Compound MAC is used in place of MSK Compound MAC field.
4. We have a TLS-PRF usage ambiguity here (Errata 5127 and 5128):
TLS 1.2 RFC 5246 in section "5.  HMAC and the Pseudorandom Function"
defines PRF(secret, label, seed) = P_(secret, label + seed)

TEAP RFC uses TLS-PRF several times:
* IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | "\0" |
64)
  The call refers to RFC 5295 that defines USRK = KDF(EMSK, key label |
"\0" | optional data | length) but that RFC says "USRKs MUST be at least 64
octets in length" and IMSK is 32 octets
* IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
* MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64) and
similar for EMSK

We can see that all three times the parameters are different and don't
exactly fit the definition and this creates some confusion.

In the other earlier thread you mentioned that truncation of 64-octets USRK
to 32 octet is valid. In yet another thread you mentioned that we should
define TLS-PRF function with the output size as a parameter and we should
just concatenate for all TLS-PRF calls all the parameters starting from the
second. Is that understanding correct? This should be also helpful when
mapping to TLS1.3 HKDF extract and expand functions.

Thanks
Oleg

On Thu, Oct 10, 2019 at 11:00 AM Eliot Lear  wrote:

> Just one comment:
>
> TEAP does not *require* an inner method, and indeed for IoT it is not
> necessary.
>
> Eliot
>
> On 9 Oct 2019, at 07:46, Joseph Salowey  wrote:
>
> Based on Jouni's analysis the derivation of the S-IMCKs is not well
> specified.  To me it looks like the solution to handle an arbitrary number
> of methods that may or may not make an EMSK available would be fairly
> complex.
>
> I think the most straight forward solution is to either always assume that
> for an EMSK generating method the EMSK is either always available or always
> unavailable.  It seems that it is safer to always assume that the EMSK is
> unavailable and will therefore never be used.  I think this has the
> following implications:
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> -  The EMSK compound MAC is not used
> -  Implementations must have a policy that accepts MSK MACs
>
> It would appear that from a cryptographic analysis point of view the MSK
> and EMSK are equivalent since these keys will only be used in these
> TEAP calculations and not for other purposes..  There are documented
> drawbacks of using the MSK described in RFC7029 (
> https://tools.ietf.org/html/rfc7029#page-12).   If the properties of the
> EMSK binding are needed in the use cases currently under consideration then
> I think we could redefine the way the EMSK MAC to be computed from the EMSK
> of the inner method changing the above to
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
>      Compound-MAC = MAC( EMSK[J], BUFFER )
> -  Implementations have a policy that prevents EMSK downgrade to MSK
>
> Hopefully there is a more elegant solution. Any ideas?
>
> Joe
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>

--000000000000fe710705a9399abd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Joe, nice proposal. Few questions:
1. We have a case o=
f Basic Password Authentication instead of inner method thus we should also=
 use Crypto-Binding TLV based on Zero-MSK after it
2. As Eliot me=
ntioned, we have a case of no inner method at all - we should use Crypto-Bi=
nding TLV based on Zero-MSK after it
3. Since it is not clear whe=
ther MSK or Zero-MSK is used - we should introduce a new flag value for=C2=
=A0Crypto-Binding TLV: "0" - Zero-MSK based=C2=A0Compound MAC is =
used in place of MSK Compound MAC field.
4. We have a TLS-PRF usa=
ge ambiguity here (Errata 5127 and 5128):=C2=A0
TLS 1.2 RFC 5246 =
in section "5.=C2=A0 HMAC and the Pseudorandom Function" defines =
PRF(secret, label, seed) =3D P_<hash>(secret, label + seed)

TEAP RFC uses TLS-PRF several times:
* IMSK =3D F=
irst 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | "\0" | 64)<=
/div>
=C2=A0 The call refers to RFC 5295 that defines=C2=A0USRK =3D KDF=
(EMSK, key label | "\0" | optional data | length) but that RFC sa=
ys "USRKs MUST be at least 64 octets in length" and IMSK is 32 oc=
tets
* IMCK[j] =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Compo=
und Keys", IMSK[j], 60)
*=C2=A0MSK =C2=A0=3D TLS-PRF(S-IMCK[=
j], "Session Key Generating Function", 64) and similar for EMSK

We can see that all three times the parameters are =
different and don't exactly fit the definition and this creates some co=
nfusion.

In the=C2=A0other earlier thread you ment=
ioned that truncation of 64-octets USRK to 32 octet is valid. In yet anothe=
r thread you mentioned that we should define TLS-PRF function with the outp=
ut size as a parameter and we should just concatenate for all TLS-PRF calls=
 all the parameters starting from the second. Is that understanding correct=
? This should be also helpful when mapping to TLS1.3=C2=A0HKDF extract and =
expand functions.

Thanks
Oleg

On Th=
u, Oct 10, 2019 at 11:00 AM Eliot Lear <lear@cisco.com> wrote:
Just one comment:

TEAP does not require=C2=A0an inner method, and indeed for IoT it i=
s not necessary.

Eliot

On 9 Oct 2019, at 07:46, Joseph Salowey <joe@salowey.net> wrote:
<=
br>
Based on Jouni's=C2=A0analysis the derivation =
of the S-IMCKs is not well specified.=C2=A0 To me it looks like the solutio=
n  to handle an arbitrary number of methods that may or may not make an EMS=
K available would be fairly complex.=C2=A0=C2=A0

I think=
 the most straight forward solution is to either always assume that for an =
EMSK generating method the EMSK is either always available or always unavai=
lable.=C2=A0 It seems that it is safer to always assume that the EMSK is un=
available and will therefore never be used.=C2=A0 I think this has the foll=
owing implications:

-=C2=A0 The S-IMCK is always g=
enerated from the inner method MSK=C2=A0or the all-zero value if the method=
 does not generate key material.=C2=A0
-=C2=A0 The EMSK compound =
MAC is not used
-=C2=A0 Implementations must have a policy that a=
ccepts MSK MACs

It would appear that from a crypto=
graphic analysis point of view the MSK and EMSK are equivalent since these =
keys will only be used in these TEAP=C2=A0calculations and not for other pu=
rposes..=C2=A0 There are documented drawbacks of using the MSK described in=
 RFC7029 (https://tools.ietf.org/html/rfc7029#page-12).=C2=A0 =C2=A0If t=
he properties of the EMSK binding are needed in the use cases currently und=
er consideration then I think we could redefine the way the EMSK MAC to be =
computed from the EMSK of the inner method changing the above to=C2=A0
<=
/div>

-=C2=A0 The S-IMCK is always generated from the in=
ner method MSK=C2=A0or the all-zero value if the method does not generate k=
ey material.=C2=A0
- Compute EMSK MAC from the inner-method EMSK =
instead of the S-IMCK
=C2=A0 =C2=A0 =C2=A0Compound-MAC =3D MAC( EMSK[J], BUFFER )
-=C2=A0 Implementations have a policy that p=
revents EMSK downgrade to MSK
=C2=A0=C2=A0
Hopef=
ully there is a more elegant solution. Any ideas?

=

Joe

_______________________________________________
Emu mailing list
Emu@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/emu

<=
/div>_______________________________________________

Emu mailing list

Emu@ietf.org

https://www.ietf.org/mailman/listinfo/emu




--000000000000fe710705a9399abd--


From nobody Mon Jun 29 08:53:57 2020
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 9C8E63A0121 for ; Mon, 29 Jun 2020 08:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level: 
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 dCkhkEfbNdTJ for ; Mon, 29 Jun 2020 08:53:53 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 36D6B3A03F3 for ; Mon, 29 Jun 2020 08:53:53 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id c139so15643607qkg.12 for ; Mon, 29 Jun 2020 08:53:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uGdT3ISwKvpo8Ct0mIyuhczXcimagD6lATK1jv1Ua04=; b=Uagc0JBcFUZhopXbl83dncHOELc4YuPRmGBOtmcmTisz8y9i8Ln6TZYHNa2jlOX71z qcuWZaNdpBDwOc4ZZzn41YpsvbKDkWwS5lg4CRxuWYW1GHWn+cgO9Z+uOzwCv+RYAZ0s eew19+ZfP2SAPNxy0v7VyfgYLQn8yXZwwK59Me6Xj1hBGYm2s0aCtXvLTKFMBokNfYDi NBmLFkIPzPf8niM1/wVR8Mb+QPamFxW+1r0ZLBFWd9vjqzRRyiHLSGptgrOnv8Z5B6eN E65MeCQxCxFW4XxawYHo+LeDlk5Zkgw5+kx4i8dRisp4PxoW/OZomqnXBsDmcmrTgqAi 88Yg==
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=uGdT3ISwKvpo8Ct0mIyuhczXcimagD6lATK1jv1Ua04=; b=mCU2BgF4g4Ul3DMsuIzdgnKvZtQaGElzLbDVOP1CM5QAM72wctSxfew12nX6v64Jut juFej3WJsQVa69L2H3bFVIFMpwQ5vYNx1oiDX6xVIgk84JD3WpwLBvk0/MnqhFly+EBe 3h2ELogX7rg3KD1AviE+3Pbn3K186TN/os1cmGiDirkjIn2LPXOk1sT3h/5Qr3+jWfSO UxxoUhmum3TWDHFV0PmNC64hGJxMa2l/Mgxijtddwuyy15uCG8TnEkWMl5jGiKaI41P9 pi2BPWmXib05XWK8pZxPJM71PBIo+noa2IKvye6RyhrnRmmfoPsYyUvE0Y+0c1CTY0oV Suag==
X-Gm-Message-State: AOAM530ZOr2sL+uScqbH4oar87X6Pdbm9hTb3N8e2e9SvysXZ90a/iBv LONAPtO2S6XNwmP9K2b1ximoVDzXPdwonu708ywCog==
X-Google-Smtp-Source: ABdhPJyN+mLuuRFzDRBJ0Pjfmfd2+kedpcoqBKMtIq3vTXaz8wbKJgfx0CdgeYfdecVP3M1XLTkZn7oAQ+xBu82fBQU=
X-Received: by 2002:a37:4683:: with SMTP id t125mr15563148qka.416.1593446031646;  Mon, 29 Jun 2020 08:53:51 -0700 (PDT)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: Joseph Salowey 
Date: Mon, 29 Jun 2020 08:53:40 -0700
Message-ID: 
To: Oleg Pekar 
Cc: Jorge Vergara , Jouni Malinen , EMU WG 
Content-Type: multipart/alternative; boundary="000000000000b0b05f05a93b103c"
Archived-At: 
Subject: Re: [Emu] TEAP - RFC 7170 - Errata ID 5768
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, 29 Jun 2020 15:53:56 -0000

--000000000000b0b05f05a93b103c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 29, 2020 at 6:49 AM Oleg Pekar 
wrote:

> Jorge, Joe, thank you for your comments. So the updated proposal should b=
e:
>
> 1) In Section "4.2.13.  Crypto-Binding TLV" make "EMSK Compound MAC" and
> "MSK Compound MAC" fields variable length depending on the number of outp=
ut
> bits of the MAC function negotiated by TLS protocol. A field "Compound MA=
C
> Length" of size 1 octet is added after the "Nonce" field to represent the
> length of each of "EMSK Compound MAC" and "MSK Compound MAC" fields. The
> minimum length for each Compound MAC field is 20 octets (to honor the
> original RFC fixed size and to allow usage of SHA-1 - that is still used =
in
> TLS 1.2 - to provide MAC without padding). The length should never be les=
s
> than 20 octets since there are no ciphers supported by TLS 1.2 with a
> digest of less than 160 bits output size. Therefore if "Compound MAC
> Length" field value is less than 20 then the Crypto-binding TLV should be
> considered of erroneous format and handled as described in section 3.6.
> Error Handling. The value of the length field of the whole Crypto-Binding
> TLV should be calculated accordingly (currently fix 76 octets).
>
> [Joe] I'm not sure I see the need to for a length here.  Isn't the MAC
algorithm known before this message is processed and therefore the length
should be known?  The document should clarify how the MAC algorithm is
determined for TLS 1.2 and TLS 1.3. The length could then be defined as the
length of the output of the MAC function.


> The updated structure of Crypto-Binding TLV:
>
> The Crypto-Binding TLV is defined as follows:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |M|R|         TLV Type          |            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Reserved   |    Version    |  Received Ver.| Flags|Sub-Type|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    ~                             Nonce                             ~
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |  Comp MAC Len |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |                                                               |
>    ~                   EMSK Compound MAC                           ~
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    ~                    MSK Compound MAC                           ~
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> If we would not bump the TEAP protocol version - we still can change the =
Crypto-Binding TLV version to 2.
>
>
> 2) [This was accepted and stays unchanged]
>
> 3) In Section "5.3.  Computing the Compound MAC" when specifying the list=
 of fields to be placed in the BUFFER" should say "...2  A single octet con=
tains TEAP EAP method type 0x37". However to let this byte play a role in p=
rotection of Crypto-Binding TLV I would suggest to place in it the inner EA=
P method type related to the calculation or 0x0 if no inner EAP method was =
executed. What are your opinions on this?
>
>
[Joe] I believe the original intent was that the same Compound MAC
construction could be used in multiple protocols (EAP-FAST, PEAP, TEAP).
Using the outer EAP method type would help protect against cross protocol
attacks if this TLV were reused.  If we are going to change the
TLV/protocol version we could revisit this and other aspects of the
compound TLV to validate their security goals and implementation.


>
> Thanks
> Oleg
>
>
> On Tue, May 26, 2020 at 12:29 PM Jorge Vergara 
> wrote:
>
>>
>>
>> *From:* Joseph Salowey 
>> *Sent:* Monday, May 25, 2020 9:27 PM
>> *To:* Jorge Vergara 
>> *Cc:* Oleg Pekar ; Jouni Malinen ;
>> EMU WG 
>> *Subject:* Re: [Emu] TEAP - RFC 7170 - Errata ID 5768
>>
>>
>>
>>
>>
>>
>>
>> On Fri, May 22, 2020 at 1:18 PM Jorge Vergara > 40microsoft.com@dmarc.ietf.org> wrote:
>>
>> My review of this errata and the current responses from Oleg:
>>
>>
>>
>>    1. I agree with this proposed resolution. I do think this is an
>>    important omission that needs to be clarified in the RFC. Otherwise i=
t is
>>    somewhat guesswork that truncation is the right action. I think the c=
urrent
>>    wording leans toward truncation, but I definitely asked this question
>>    myself while implementing.
>>
>> [Joe]  Why not just change the TLV to be variable length?  It seems if w=
e
>> hardcode the length to 100 we risk having the same problem in the future=
?
>>
>>
>>
>> [Jorge] I have to admit that in my original response my brain skipped
>> over the TLV length adjustment and focused only on the truncation. If th=
e
>> TLV length is going to be adjusted at all, I am in favor of making the T=
LV
>> variable length. A minimum length could also be added (32 bits seems to =
be
>> the current recommendation). However, I do believe this is a breaking
>> change to any TEAP implementation =E2=80=93 would the TEAP version need =
to be
>> bumped?
>>
>>
>>    1.
>>    2. This bleeds into Alan=E2=80=99s TLS 1.3 document somewhat, but I a=
gree
>>    with Jouni that this will need to change when the rest of the documen=
t is
>>    eventually updated to TLS 1.3.. There are enough TLS 1.3 related thin=
gs to
>>    address in TEAP that I don=E2=80=99t exactly view this as an errata. =
I view it as a
>>    needed update, whether in this document, Alan=E2=80=99s document, or =
both.
>>
>> [Joe]  I tend to agree that this is not an errata.  However an update to
>> TEAP should address these.
>>
>>
>>
>>
>>    1.
>>    2. Agree with Jouni that I don=E2=80=99t see the point of the 0x37 oc=
tet, but
>>    regardless this clarification of how it is encoded is positive (minor=
)
>>    change.
>>
>> [Joe] I think the original reason to include the TEAP method ID in the
>> specification was to make sure that we differentiated between similar
>> crypto binding implementations in other protocols such as EAP-FAST.   I
>> don't think there is much ambiguity here, but I am OK with including 0x3=
7
>> in the description.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Jorge
>>
>>
>>
>> *From:* Emu  *On Behalf Of *Oleg Pekar
>> *Sent:* Tuesday, May 5, 2020 6:27 AM
>> *To:* Jouni Malinen ; EMU WG 
>> *Subject:* [Emu] TEAP - RFC 7170 - Errata ID 5768
>>
>>
>>
>> Hi Jouni,
>>
>> I propose the following fix for the issues described in this errata id:
>>
>> 1) In Section "4.2.13.  Crypto-Binding TLV" make "EMSK Compound MAC" and
>> "MSK Compound MAC" fields 32 octets long (currently 20 octets). The MAC
>> value is truncated at 32 octets if it is longer than 32 octets or padded=
 to
>> a length of 32 octets with zeros to the right if it is less than 32 octe=
ts.
>> The length of the TLV should be changed to 100 bytes (currently 76).
>>
>>
>>
>> The motivation is to keep collision-resistance strength of MAC on 128
>> bit. Hash value truncation is described in "NIST Special Publication
>> 800-107 Revision 1: Recommendation for Applications Using Approved Hash
>> Algorithms"
>> 
>>
>>
>>
>>
>> 2) In Section "5.3.  Computing the Compound MAC" specify that "MAC is th=
e
>> MAC function negotiated in TLS of TEAP Phase 1" (currently it says TLS
>> 1.2)
>>
>>
>>
>> The motivation is to support TLS 1.2, 1.3 and possibly later TLS version=
s.
>>
>>
>>
>> 3) In Section "5.3.  Computing the Compound MAC" when specifying the lis=
t
>> of field to be placed in the BUFFER" should say "...2  A single octet
>> contains TEAP EAP method type 0x37". Alternatively it could be "...2  A
>> single octet contains EAP Type of the inner EAP method related to the
>> calculation or 0 if no inner EAP method was executed" (currently "...2  =
The
>> EAP Type sent by the other party in the first TEAP message")
>>
>>
>>
>> Please note that there's still a discussion on sending Crypto-Binding TL=
V
>> on "Authentication inner EAP method" or "Inner EAP method that exports M=
SK"
>> only.
>>
>>
>>
>> Thanks
>>
>> Oleg
>>
>> _______________________________________________
>> Emu mailing list
>> Emu@ietf.org
>> https://www.ietf.org/mailman/listinfo/emu
>> 
>>
>>

--000000000000b0b05f05a93b103c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jun 29, 2020 at 6:49 AM Oleg =
Pekar <oleg.pekar.2017@gmai=
l.com> wrote:
Jorge, Joe, thank you for your comme=
nts. So the updated proposal should be:

1) In Section &q=
uot;4.2.13.=C2=A0 Crypto-Binding TLV" make "EMSK Compound MAC&quo=
t; and "MSK Compound MAC" fields variable length depending on the=
 number of output bits of the MAC function negotiated by TLS protocol. A fi=
eld "Compound MAC Length" of size 1 octet is added after the &quo=
t;Nonce" field to represent the length of each of "EMSK Compound =
MAC" and "MSK Compound MAC" fields. The minimum length for e=
ach Compound MAC field is 20 octets (to honor the original RFC fixed size a=
nd to allow usage of SHA-1 - that is still used in TLS 1.2 - to provide=C2=
=A0MAC without padding). The length should never be=C2=A0less than 20 octet=
s since there are no ciphers supported by TLS 1.2 with a digest of less tha=
n 160 bits output size. Therefore if "Compound MAC Length" field =
value is less than 20 then the Crypto-binding TLV should be considered of e=
rroneous=C2=A0format and handled as described in section=C2=A03.6. Error Ha=
ndling. The value of the length field of the whole Crypto-Binding TLV shoul=
d be calculated accordingly (currently fix 76 octets).=C2=A0
=

[Joe] I'm not sure I see the ne=
ed to for a length here.=C2=A0 Isn't the MAC algorithm known before thi=
s message is processed and therefore the length should be known?=C2=A0 The =
document should clarify how the MAC algorithm is determined for TLS 1.2 and=
 TLS 1.3. The length could then be defined as the length of the output of t=
he MAC function.=C2=A0=C2=A0
=C2=A0
The updated structure of Crypto-Binding TLV:

The Crypto-Binding TLV is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|         TLV Type          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |    Version    |  Received Ver.| Flags|Sub-Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Nonce                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef=
ore:page;color:rgb(0,0,0)">   |  Comp MAC Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
/pre>
   |    =
                                                           |
   ~                   EMSK Compound MAC                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    MSK Compound MAC                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<=
pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef=
ore:page;color:rgb(0,0,0)">
If we would not bump the TEAP protocol version - we =
still can change the Crypto-Binding TLV version to 2.

2) [This was accept=
ed and stays unchanged]=C2=A0

3)=C2=A0In Section "5.3.=C2=
=A0 Computing the Compound MAC" when specifying the list of fields=C2=
=A0to be placed in the BUFFER" should say=C2=A0"...2 =C2=A0A sing=
le octet contains TEAP EAP method type 0x37". However to let this byte=
 play a role in protection of Crypto-Binding TLV I would suggest to place i=
n it the inner EAP method type related to the calculation or 0x0 if no inne=
r EAP method was executed. What are your opinions on this?

[Joe] I believe the ori=
ginal intent was that the same Compound MAC construction could be used in m=
ultiple protocols (EAP-FAST, PEAP, TEAP).=C2=A0 Using the outer EAP method =
type would help protect against cross protocol attacks if this TLV were reu=
sed.=C2=A0 If we are going to change the TLV/protocol version we could revi=
sit this and other aspects of the compound TLV to validate their security g=
oals and implementation.=C2=A0=C2=A0
=C2=A0

=

Thanks
Oleg


=

On Tue, Ma=
y 26, 2020 at 12:29 PM Jorge Vergara <jovergar@microsoft.com> wrote:











=C2=A0




From: Joseph Salowey <joe@salowey.net> 

Sent: Monday, May 25, 2020 9:27 PM

To: Jorge Vergara <jovergar@microsoft.com>

Cc: Oleg Pekar <oleg.pekar.2017@gmail.com>; Jouni Malinen <j@w1.fi>; EMU WG <emu@ietf.org>

Subject: Re: [Emu] TEAP - RFC 7170 - Errata ID 5768



=C2=A0






=C2=A0




=C2=A0






On Fri, May 22, 2020 at 1:18 PM Jorge Vergara <jo=
vergar=3D40microsoft.com@dmarc.ietf.org> wrote:










My review of this errata and the current responses f=
rom Oleg:


=C2=A0


    

  1. 
I agree with this proposed resolution. I do think this is an important omis=
sion that needs to be clarified in the RFC. Otherwise it is somewhat guessw=
ork that truncation is the right action. I think the current wording leans =
toward truncation, but I definitely
 asked this question myself while implementing.










[Joe]=C2=A0 Why not just change the TLV to be variab=
le length?=C2=A0 It seems if we hardcode the length to 100 we risk having t=
he same problem in the future?=C2=A0=C2=A0






=C2=A0


[Jorge] I have to admit that in my original response=
 my brain skipped over the TLV length adjustment and focused only on the tr=
uncation. If the TLV length is going to be adjusted at all, I am in favor o=
f making the TLV variable length.
 A minimum length could also be added (32 bits seems to be the current reco=
mmendation). However, I do believe this is a breaking change to any TEAP im=
plementation =E2=80=93 would the TEAP version need to be bumped?<=
/u>










    

  1. 
=C2=A0
  2. 
This bleeds into Alan=E2=80=99s TLS 1.3 document somewhat, but I agree with=
 Jouni that this will need to change when the rest of the document is event=
ually updated to TLS 1.3.. There are enough TLS 1.3 related things to addre=
ss in TEAP that I don=E2=80=99t exactly view this
 as an errata. I view it as a needed update, whether in this document, Alan=
=E2=80=99s document, or both.










[Joe]=C2=A0 I tend to agree that this is not an erra=
ta.=C2=A0 However an update to TEAP should address these.=C2=A0






=C2=A0










    

  1. 
=C2=A0
  2. 
Agree with Jouni that I don=E2=80=99t see the point of the 0x37 octet, but =
regardless this clarification of how it is encoded is positive (minor) chan=
ge.










[Joe] I think the original reason to include the TEA=
P method ID in the specification was to make sure that we differentiated be=
tween similar crypto binding implementations in other protocols such as EAP=
-FAST.=C2=A0 =C2=A0I don't think there is much
 ambiguity here, but I am OK with including 0x37 in the description.=C2=A0=
=C2=A0






=C2=A0










=C2=A0


Thanks,


Jorge


=C2=A0




From: Emu <emu-bounces@ietf.org>
On Behalf Of Oleg Pekar

Sent: Tuesday, May 5, 2020 6:27 AM

To: Jouni Malinen <j=
@w1.fi>; EMU WG <emu@ietf.org>

Subject: [Emu] TEAP - RFC 7170 - Errata ID 5768




=C2=A0




Hi Jouni,




I propose the following fix for the issues described=
 in this errata id:






1) In Section "4.2.13.=C2=A0 Crypto-Binding TLV=
" make "EMSK Compound MAC" and "MSK Compound MAC" =
fields 32 octets long (currently 20 octets). The=C2=A0MAC value is truncate=
d at 32 octets
 if it is longer than 32 octets or=C2=A0padded to a length of 32 octets wit=
h zeros to the right if it is less than 32 octets. The length of the TLV sh=
ould be changed to 100 bytes (currently 76).=C2=A0






=C2=A0






The motivation is to keep=C2=A0collision-resistance =
strength of MAC on 128 bit. Hash value=C2=A0truncation is described in

"NIST Special Publication 800-107 Revision 1: Recommendation for Appli=
cations Using Approved Hash Algorithms"=C2=A0






=C2=A0






2) In Section "5.3.=C2=A0 Computing the Compoun=
d MAC" specify that "MAC is the MAC function negotiated in TLS of=
=C2=A0TEAP Phase 1" =
(currently
 it says TLS 1.2)






=C2=A0






The motivation is to support TLS 1.2, 1.3 and possib=
ly later TLS versions.






=C2=A0






3)=C2=A0In Section "5.3.=C2=A0 Computing the Co=
mpound MAC" when specifying the list of field=C2=A0to be placed in the=
 BUFFER" should say=C2=A0"...2 =C2=A0A single octet contains TEAP=
 EAP method type 0x37".
 Alternatively it could be "...2 =C2=A0A single octet contains EAP Typ=
e of the inner EAP method related to the calculation or 0 if no inner EAP m=
ethod was executed" (currently "...2 =C2=A0The EAP Type sent by t=
he other party in the first TEAP message")






=C2=A0






Please note that there's still a discussion on s=
ending Crypto-Binding TLV on "Authentication inner EAP method" or=
 "Inner EAP method that exports MSK" only.






=C2=A0






Thanks






Oleg










_______________________________________________

Emu mailing list

Emu@ietf.org

https://www.ie=
tf.org/mailman/listinfo/emu



















--000000000000b0b05f05a93b103c--