From nobody Sat Aug 1 06:52:56 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 C0B073A0770 for ; Sat, 1 Aug 2020 06:52:53 -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 1Zannc8RfBd5 for ; Sat, 1 Aug 2020 06:52:51 -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 AF4143A076C for ; Sat, 1 Aug 2020 06:52:51 -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 F083983; Sat, 1 Aug 2020 13:52:48 +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: <045301d66757$f1a0c7f0$d4e257d0$@augustcellars.com> Date: Sat, 1 Aug 2020 09:52:47 -0400 Cc: Mohit Sethi M , EMU WG , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <88D67F36-0817-49D3-B90C-7BB97A26D96E@deployingradius.com> References: <045301d66757$f1a0c7f0$d4e257d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 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, 01 Aug 2020 13:52:54 -0000 On Jul 31, 2020, at 12:30 PM, Jim Schaad wrote: >=20 > Ok =E2=80=93 so this issue was raised at IETF 102. (presentation = https://www.ietf.org/proceedings/102/slides/slides-102-emu-eap-tls-with-tl= s-13-00) > =20 > Just reading the slides is not telling me what was the problem. I = think I am going to need to hear the audio of the presentation. I have = an extremely vague memory that there was an OpenSSL problem involved = here but I would not swear to that. You might be a better description = either from John Mattsson or Jouni. IIRC it's that OpenSSL doesn't have an API to send a zero bytes of = application data. I think other TLS implementations have similar = limitations. Regardless of what solution is implemented, the requirement is to have = a positive acknowledgement that TLS setup is finished. This step seems = to be missing by default in TLS 1.3. I suspect that most uses of TLS will *always* send application data. = Which makes EAP-TLS an outlier. Hence the need for hacks like "send = application data as one octet of zero". Alan DeKok. From nobody Sat Aug 1 08:23:25 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 43B793A0C08 for ; Sat, 1 Aug 2020 08:23:14 -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 sliLtuEXsZOG for ; Sat, 1 Aug 2020 08:23:11 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222A43A0C00 for ; Sat, 1 Aug 2020 08:23:10 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 1 Aug 2020 08:23:03 -0700 From: Jim Schaad To: 'Alan DeKok' CC: 'Mohit Sethi M' , 'EMU WG' , 'Benjamin Kaduk' References: <045301d66757$f1a0c7f0$d4e257d0$@augustcellars.com> <88D67F36-0817-49D3-B90C-7BB97A26D96E@deployingradius.com> In-Reply-To: <88D67F36-0817-49D3-B90C-7BB97A26D96E@deployingradius.com> Date: Sat, 1 Aug 2020 08:23:01 -0700 Message-ID: <049901d66817$a73b5bb0$f5b21310$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKU+za7jsbb79qc1fYt8rWIA46HpwJ46U6ZAeAUDg2ng2f7EA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 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, 01 Aug 2020 15:23:15 -0000 -----Original Message----- From: Alan DeKok =20 Sent: Saturday, August 1, 2020 6:53 AM To: Jim Schaad Cc: Mohit Sethi M ; EMU WG ; = Benjamin Kaduk Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 On Jul 31, 2020, at 12:30 PM, Jim Schaad wrote: >=20 > Ok =E2=80=93 so this issue was raised at IETF 102. (presentation = https://www.ietf.org/proceedings/102/slides/slides-102-emu-eap-tls-with-t= ls-13-00) > =20 > Just reading the slides is not telling me what was the problem. I = think I am going to need to hear the audio of the presentation. I have = an extremely vague memory that there was an OpenSSL problem involved = here but I would not swear to that. You might be a better description = either from John Mattsson or Jouni. IIRC it's that OpenSSL doesn't have an API to send a zero bytes of = application data. I think other TLS implementations have similar = limitations. Regardless of what solution is implemented, the requirement is to have = a positive acknowledgement that TLS setup is finished. This step seems = to be missing by default in TLS 1.3. I suspect that most uses of TLS will *always* send application data. = Which makes EAP-TLS an outlier. Hence the need for hacks like "send = application data as one octet of zero". [JLS] Cobwebs are slowly being shaken out of my brain. =20 * I made an incorrect statement yesterday because I got EAP-TEAP and = EAP-TLS confused. Not surprising because I only ever spent any time on = EAP-TEAP . In EAP-TLS, once the handshake has been completed the tunnel = does not need to be kept open. This is the opposite of the case for = EAP-TEAP where the tunnel is used for application EAP data. * Based on that I agree with EKR that the close notification could be = used instead of sending the one byte of application data. Sending the = close notification means that the server will no longer be sending any = data and thus would not send any new session tickets. 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 <-------- (close_notify) EAP-Response/ EAP-Type=3DEAP-TLS --------> <-------- EAP-Success Jim Alan DeKok. From nobody Mon Aug 3 11:23: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 9CC013A0D2F for ; Mon, 3 Aug 2020 11:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[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 MVZ3-hhOLtei for ; Mon, 3 Aug 2020 11:23:47 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2124.outbound.protection.outlook.com [40.107.220.124]) (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 D37EF3A0A56 for ; Mon, 3 Aug 2020 11:23:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oe1xgdu2QP0Ta9Ofd36Xa/gB8FwcrTXBT1fgZH6SE7Ajt2DAGP2UJhxlnEbyd8yDRSj82zevPjpVaGnBKkGmKbb0b0d8FE+A6/UQkXichMv8Mm62hqlxItWucUJ02TeqgAACLxqGzdlg54sTVkXzXXPHCczNWXOYNrP6U1mRT39fQKFIl816mIuOPIDHV6Z232FrOoW5xf1N+Xx/Vveb1M/1n4xgB2ydXbcQ3S5lzAe70AATKtLHRXk3FqByYN+n+B0Wqc/sI4URZYzxR3gem9svDSe1OdCNfjtatbBmPJK9O1RjxdBPVCeld0ZMlR4r8r+O9sBKFXSTYjvBhn0/8Q== 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=5jHNEKtvMgwmEGh6Lb6p0hdxVrawJBzuACs4dsaRoVs=; b=DauwQJt3DZnvFtaWkzJtjlmb1RWvGqN/KSKPeyBNx9R7oJ3kKDpz27JxW9xldZKwtoL4bOvU9m4EdlaB7sgMix/nZ6pQqbbcmWHJPC2F7xZLRGUWdfPeWKJwpJU/WvoinD3WBgXyLInN1KeGvDo+CRIO7wO1XwcrkoX50kenoLx1QIhPX8lvkg9Z4g3rvY5RvgIwNCI2u+owa2K5mF2qbueCp4YSbdWA99N0a+PnfF6Ey0rH4RUlaR8cJedMw+Gln8LufldV22OsROMLhGR0ObeCYNlob37jhgiW/T6M33bon+jAmRvMSkGzEbAGIF+royCKl4CWFpSd7VgbPTP3sA== 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=5jHNEKtvMgwmEGh6Lb6p0hdxVrawJBzuACs4dsaRoVs=; b=QbKaZ+zt6D9g1zEkaypBmXcFGl2yCv6PkRdHWp2UhZJfM7yIro6RN9tJhJZZOEyTSuE+3R5j1sc9zS4SJJIL505/Qt3pjtc3VZvW9zBwFQQU6HvVEt51E+cR7Pjju3+YLOLsG9QHTidldbYXWLunw+hETpZWDOHrM+BEsT/7d3s= Received: from CH2PR21MB1381.namprd21.prod.outlook.com (2603:10b6:610:8e::12) by CH2PR21MB1525.namprd21.prod.outlook.com (2603:10b6:610:5f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.1; Mon, 3 Aug 2020 18:23:45 +0000 Received: from CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::4053:c9ec:1bc0:c97c]) by CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::4053:c9ec:1bc0:c97c%2]) with mapi id 15.20.3283.002; Mon, 3 Aug 2020 18:23:45 +0000 From: Jorge Vergara To: Jim Schaad , 'Alan DeKok' CC: 'Mohit Sethi M' , 'EMU WG' , 'Benjamin Kaduk' Thread-Topic: [Emu] Commitment Message handling in EAP-TLS 1.3 Thread-Index: AQHWZ0QZLBwuPJQ+v0OkdIGZnEzxbqkh4VaAgAFmNYCAABk2gIADVrig Date: Mon, 3 Aug 2020 18:23:45 +0000 Message-ID: References: <045301d66757$f1a0c7f0$d4e257d0$@augustcellars.com> <88D67F36-0817-49D3-B90C-7BB97A26D96E@deployingradius.com> <049901d66817$a73b5bb0$f5b21310$@augustcellars.com> In-Reply-To: <049901d66817$a73b5bb0$f5b21310$@augustcellars.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-08-03T18:23:43Z; 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=ff8039e4-9117-403d-8104-4ded482d24dd; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:9:1f3:2a9:d667:7450] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f51dbe63-4c9c-443f-1452-08d837da5bc0 x-ms-traffictypediagnostic: CH2PR21MB1525: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RVHzGxeX72EdEAm6hOr2ftkGBv+spEOmYyMkZR9RVB4iR1CpgPG94RUNbR8qspaDP7ctZTSJJ2aGGaC+MhJbuzencrodkFcQVlyDv2vPz8Wa7urwTdUjyJw091c3iO1RWDBFAmSKilsBjoyezm/vWEmvJgx55HFikXE/PTQtM/QnSHbXHK8y1FqtTPO+30t9bdUAax9T7UuWpvUGZ019z57Yvd3RLuB7ec65Y4fOGe6lt0m1JSPf/I1QL+BazpEYd+xcTAPlc7BcINMtcM/QnBimYwagj/hMJ55/mnNgLY6hcVv38CVnpnqYoJF2Gd/hr81waR9xx0vjtAiBQEZB2mpZ2m3y4sPbHzlJ9z3o3sWHU1M+0rPlml7OxnSgYWP3ofNjQeL99Q4v+mJqTk7wAA== 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; SFS:(4636009)(136003)(346002)(376002)(396003)(366004)(39860400002)(82950400001)(82960400001)(33656002)(5660300002)(83380400001)(966005)(478600001)(52536014)(9686003)(86362001)(64756008)(66446008)(66556008)(71200400001)(55016002)(2906002)(4326008)(186003)(8990500004)(10290500003)(66946007)(15650500001)(53546011)(66476007)(6506007)(54906003)(110136005)(7696005)(76116006)(8936002)(8676002)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: BFAgKiJGTRQUePDVQ0NIXJHseHF9gRBX1rQCRhVKAv8tzItWZX0jyaix7vLBywY+GgmIQIzZ99debVNg0Ew/X7+EwJJn72s0DI9nBRiozygQYJJ7NuzXHMnjUifILQsYu+i92a3hbpaL+9vp9NHO+TOasjs7OpKYUS1bz93IvtFYUEDON6OMsb07pgXmPSo9cqHCOJQ04LfWHNn+eXoZWY1jgy36tmb72xDrsfuzKJUJqv/RjpnB90mjxULZhfH8r2kIfSvdaU09Fk2AN/UF8rKDVXtMoDkf8kwPk5WlxroKV5op2u9idAkeZOUlhXlzydDjKx3C8r2vl8UGNMgX7zNGB0C1YpPbLiP9pLv07/XqjaR2T/TGxEy2/HrcYvGLf5+kqB8IennzYFXukWdTl3duo2rWwZBhsOq+y3KIycndmhKv0Gz55kb2a5kDlMs3jYkGY/G+Sq/AdnckuZtvask3TX++I+anL/XmGVmbeGKf6TNE8+T4GaBilgcs3lLsLePj843npsvYVqe2beGKyU55xtXJKBPcbvSioPZ0wXhdPrZWQ8GroBAK/Zy9U0JsbHTihwmwK2nyZybXjj6I1sJahGyP7KCQ10est+v+gMVaWXaqoMZrFReOccCQYZ7+XNQzGk14ztjfWiTn+V6jGM/8jVId1g2VyKeWhc26xWDW2Kv5hTlO9YYIcse1FQvuLOs4dSX8aOK/N6B5fIGC0A== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR21MB1381.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f51dbe63-4c9c-443f-1452-08d837da5bc0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 18:23:45.3224 (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: 7q4tV2owC2RntWtVoqpjEPy0O4Cj61PBfrNEi0Huk8eNluuYnpZ72H2Ty7yfDKwwuHj38192YITHxOf+cUp4Mg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR21MB1525 Archived-At: Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 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, 03 Aug 2020 18:23:49 -0000 QUNLIHRoYXQgRUFQLVRMUyBkb2VzIG5vdCBuZWVkIHRvIGtlZXAgdGhlIGNvbm5lY3Rpb24gb3Bl bi4NCg0KUXVlc3Rpb246IHNob3VsZCBzb21lIGNvbnNpZGVyYXRpb24gYmUgZ2l2ZW4gdG8gY29u c2lzdGVuY3kgd2l0aCBvdGhlciBFQVAgbWV0aG9kcyB0aGF0IGRvIG5lZWQgdG8ga2VlcCB0aGUg Y29ubmVjdGlvbiBvcGVuPyBpLmUuIFBFQVAvRUFQLVRUTFMvVEVBUA0KDQpKb3JnZQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRW11IDxlbXUtYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIEppbSBTY2hhYWQNClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMSwgMjAyMCA4 OjIzIEFNDQpUbzogJ0FsYW4gRGVLb2snIDxhbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tPg0KQ2M6 ICdNb2hpdCBTZXRoaSBNJyA8bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+OyAnRU1VIFdHJyA8 ZW11QGlldGYub3JnPjsgJ0JlbmphbWluIEthZHVrJyA8a2FkdWtAbWl0LmVkdT4NClN1YmplY3Q6 IFJlOiBbRW11XSBDb21taXRtZW50IE1lc3NhZ2UgaGFuZGxpbmcgaW4gRUFQLVRMUyAxLjMNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGFuIERlS29rIDxhbGFuZEBk ZXBsb3lpbmdyYWRpdXMuY29tPiANClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMSwgMjAyMCA2OjUz IEFNDQpUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4NCkNjOiBNb2hpdCBT ZXRoaSBNIDxtb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbT47IEVNVSBXRyA8ZW11QGlldGYub3Jn PjsgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQpTdWJqZWN0OiBSZTogW0VtdV0gQ29t bWl0bWVudCBNZXNzYWdlIGhhbmRsaW5nIGluIEVBUC1UTFMgMS4zDQoNCk9uIEp1bCAzMSwgMjAy MCwgYXQgMTI6MzAgUE0sIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3Rl Og0KPiANCj4gT2sg4oCTIHNvIHRoaXMgaXNzdWUgd2FzIHJhaXNlZCBhdCBJRVRGIDEwMi4gIChw cmVzZW50YXRpb24gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGcHJvY2VlZGluZ3MlMkYxMDIlMkZz bGlkZXMlMkZzbGlkZXMtMTAyLWVtdS1lYXAtdGxzLXdpdGgtdGxzLTEzLTAwJmFtcDtkYXRhPTAy JTdDMDElN0Nqb3ZlcmdhciU0MG1pY3Jvc29mdC5jb20lN0M3OWY5OGUzZTZmN2Y0OTk3MWM0NjA4 ZDgzNjJlZDM1MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzczMTg5MjIwMjg0NDM5ODQmYW1wO3NkYXRhPW5FeExZaTZwMEpOTmVaOFRac2ZYa1JJbTUzJTJC SHVVaWRFaFUyR3JyaW9BNCUzRCZhbXA7cmVzZXJ2ZWQ9MCkNCj4gIA0KPiBKdXN0IHJlYWRpbmcg dGhlIHNsaWRlcyBpcyBub3QgdGVsbGluZyBtZSB3aGF0IHdhcyB0aGUgcHJvYmxlbS4gIEkgdGhp bmsgSSBhbSBnb2luZyB0byBuZWVkIHRvIGhlYXIgdGhlIGF1ZGlvIG9mIHRoZSBwcmVzZW50YXRp b24uICBJIGhhdmUgYW4gZXh0cmVtZWx5IHZhZ3VlIG1lbW9yeSB0aGF0IHRoZXJlIHdhcyBhbiBP cGVuU1NMIHByb2JsZW0gaW52b2x2ZWQgaGVyZSBidXQgSSB3b3VsZCBub3Qgc3dlYXIgdG8gdGhh dC4gIFlvdSBtaWdodCBiZSBhIGJldHRlciBkZXNjcmlwdGlvbiBlaXRoZXIgZnJvbSBKb2huIE1h dHRzc29uIG9yIEpvdW5pLg0KDQogIElJUkMgaXQncyB0aGF0IE9wZW5TU0wgZG9lc24ndCBoYXZl IGFuIEFQSSB0byBzZW5kIGEgemVybyBieXRlcyBvZiBhcHBsaWNhdGlvbiBkYXRhLiAgSSB0aGlu ayBvdGhlciBUTFMgaW1wbGVtZW50YXRpb25zIGhhdmUgc2ltaWxhciBsaW1pdGF0aW9ucy4NCg0K ICBSZWdhcmRsZXNzIG9mIHdoYXQgc29sdXRpb24gaXMgaW1wbGVtZW50ZWQsIHRoZSByZXF1aXJl bWVudCBpcyB0byBoYXZlIGEgcG9zaXRpdmUgYWNrbm93bGVkZ2VtZW50IHRoYXQgVExTIHNldHVw IGlzIGZpbmlzaGVkLiAgVGhpcyBzdGVwIHNlZW1zIHRvIGJlIG1pc3NpbmcgYnkgZGVmYXVsdCBp biBUTFMgMS4zLg0KDQogIEkgc3VzcGVjdCB0aGF0IG1vc3QgdXNlcyBvZiBUTFMgd2lsbCAqYWx3 YXlzKiBzZW5kIGFwcGxpY2F0aW9uIGRhdGEuICBXaGljaCBtYWtlcyBFQVAtVExTIGFuIG91dGxp ZXIuICBIZW5jZSB0aGUgbmVlZCBmb3IgaGFja3MgbGlrZSAic2VuZCBhcHBsaWNhdGlvbiBkYXRh IGFzIG9uZSBvY3RldCBvZiB6ZXJvIi4NCg0KW0pMU10gIENvYndlYnMgYXJlIHNsb3dseSBiZWlu ZyBzaGFrZW4gb3V0IG9mIG15IGJyYWluLiAgDQoqICBJIG1hZGUgYW4gaW5jb3JyZWN0IHN0YXRl bWVudCB5ZXN0ZXJkYXkgYmVjYXVzZSBJIGdvdCBFQVAtVEVBUCBhbmQgRUFQLVRMUyBjb25mdXNl ZC4gIE5vdCBzdXJwcmlzaW5nIGJlY2F1c2UgSSBvbmx5IGV2ZXIgc3BlbnQgYW55IHRpbWUgb24g RUFQLVRFQVAgLiAgSW4gRUFQLVRMUywgb25jZSB0aGUgaGFuZHNoYWtlIGhhcyBiZWVuIGNvbXBs ZXRlZCB0aGUgdHVubmVsIGRvZXMgbm90IG5lZWQgdG8gYmUga2VwdCBvcGVuLiAgVGhpcyBpcyB0 aGUgb3Bwb3NpdGUgb2YgdGhlIGNhc2UgZm9yIEVBUC1URUFQIHdoZXJlIHRoZSB0dW5uZWwgaXMg dXNlZCBmb3IgYXBwbGljYXRpb24gRUFQIGRhdGEuDQoNCiogQmFzZWQgb24gdGhhdCBJIGFncmVl IHdpdGggRUtSIHRoYXQgdGhlIGNsb3NlIG5vdGlmaWNhdGlvbiBjb3VsZCBiZSB1c2VkIGluc3Rl YWQgb2Ygc2VuZGluZyB0aGUgb25lIGJ5dGUgb2YgYXBwbGljYXRpb24gZGF0YS4gICBTZW5kaW5n IHRoZSBjbG9zZSBub3RpZmljYXRpb24gbWVhbnMgdGhhdCB0aGUgc2VydmVyIHdpbGwgbm8gbG9u Z2VyIGJlIHNlbmRpbmcgYW55IGRhdGEgYW5kIHRodXMgd291bGQgbm90IHNlbmQgYW55IG5ldyBz ZXNzaW9uIHRpY2tldHMuDQoNCkVBUCBQZWVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEVBUCBTZXJ2ZXINCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRUFQLVJlcXVlc3QvDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0gICAgICAgICAgICAgICAgICBJZGVudGl0eQ0K ICAgIEVBUC1SZXNwb25zZS8NCiAgICBJZGVudGl0eSAoUHJpdmFjeS1GcmllbmRseSkgIC0tLS0t LS0tPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRUFQLVJlcXVlc3QvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRUFQLVR5cGU9RUFQLVRMUw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPC0tLS0tLS0tICAgICAgICAgICAgICAgIChUTFMgU3RhcnQpDQogICAgRUFQLVJl c3BvbnNlLw0KICAgIEVBUC1UeXBlPUVBUC1UTFMNCiAgIChUTFMgQ2xpZW50SGVsbG8pICAgICAg ICAgICAgIC0tLS0tLS0tPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRUFQLVJlcXVlc3QvDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRUFQLVR5cGU9RUFQLVRMUw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChUTFMgU2VydmVySGVsbG8s DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUTFMgRW5jcnlw dGVkRXh0ZW5zaW9ucywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUTFMgQ2VydGlmaWNhdGVSZXF1ZXN0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUTFMgQ2VydGlmaWNhdGUsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRMUyBDZXJ0aWZpY2F0ZVZlcmlmeSwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLSAgICAgICAgICAgICAg VExTIEZpbmlzaGVkKQ0KICAgIEVBUC1SZXNwb25zZS8NCiAgICBFQVAtVHlwZT1FQVAtVExTDQog ICAoVExTIENlcnRpZmljYXRlLA0KICAgIFRMUyBDZXJ0aWZpY2F0ZVZlcmlmeSwNCiAgICBUTFMg RmluaXNoZWQpICAgICAgICAgICAgICAgIC0tLS0tLS0tPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRUFQLVJlcXVlc3QvDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRUFQLVR5cGU9RUFQ LVRMUw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tICAgICAgICAo Y2xvc2Vfbm90aWZ5KQ0KICAgIEVBUC1SZXNwb25zZS8NCiAgICBFQVAtVHlwZT1FQVAtVExTICAg ICAgICAgICAgIC0tLS0tLS0tPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0t LS0tLS0tICAgICAgICAgICAgICAgRUFQLVN1Y2Nlc3MNCg0KSmltDQoNCg0KDQogIEFsYW4gRGVL b2suDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkVtdSBtYWlsaW5nIGxpc3QNCkVtdUBpZXRmLm9yZw0KaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGZW11JmFtcDtkYXRhPTAyJTdDMDElN0Nqb3ZlcmdhciU0MG1p Y3Jvc29mdC5jb20lN0M3OWY5OGUzZTZmN2Y0OTk3MWM0NjA4ZDgzNjJlZDM1MSU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzczMTg5MjIwMjg0NDg5NzQmYW1w O3NkYXRhPWM0MG5FNWJVcFQ2OUNZWTlxRE54N2RSeVZXekZScWdvS2NVdmdWMHA5eUUlM0QmYW1w O3Jlc2VydmVkPTANCg== From nobody Tue Aug 4 10:15: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 103073A0D2C for ; Tue, 4 Aug 2020 10:15: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqMzzbfH-pUj for ; Tue, 4 Aug 2020 10:15:41 -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 0CADF3A0D29 for ; Tue, 4 Aug 2020 10:15:40 -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 445AF5FA; Tue, 4 Aug 2020 17:15:38 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: Date: Tue, 4 Aug 2020 13:15:36 -0400 Cc: Jim Schaad , Mohit Sethi M , EMU WG , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <21053ED1-142B-4B2B-B159-E8FDAB130058@deployingradius.com> References: <045301d66757$f1a0c7f0$d4e257d0$@augustcellars.com> <88D67F36-0817-49D3-B90C-7BB97A26D96E@deployingradius.com> <049901d66817$a73b5bb0$f5b21310$@augustcellars.com> To: Jorge Vergara X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 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, 04 Aug 2020 17:15:43 -0000 On Aug 3, 2020, at 2:23 PM, Jorge Vergara = wrote: >=20 > ACK that EAP-TLS does not need to keep the connection open. I agree. I'm happy to change the implementations to send "close = notify". > Question: should some consideration be given to consistency with other = EAP methods that do need to keep the connection open? i.e. = PEAP/EAP-TTLS/TEAP When those methods send application data, they don't need to do = anything else. When those methods use fast reconnect, they don't send application = data. So the other EAP methods should also send "close notify" in that = case. Alan DeKok. From nobody Tue Aug 4 10:34: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 36DAE3A0931 for ; Tue, 4 Aug 2020 10:34:19 -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 ZZk8l9s6n5ph for ; Tue, 4 Aug 2020 10:34:18 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF74A3A0D7A for ; Tue, 4 Aug 2020 10:34:17 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Aug 2020 10:34:09 -0700 From: Jim Schaad To: 'Alan DeKok' , 'Jorge Vergara' CC: 'Mohit Sethi M' , 'EMU WG' , 'Benjamin Kaduk' References: <045301d66757$f1a0c7f0$d4e257d0$@augustcellars.com> <88D67F36-0817-49D3-B90C-7BB97A26D96E@deployingradius.com> <049901d66817$a73b5bb0$f5b21310$@augustcellars.com> <21053ED1-142B-4B2B-B159-E8FDAB130058@deployingradius.com> In-Reply-To: <21053ED1-142B-4B2B-B159-E8FDAB130058@deployingradius.com> Date: Tue, 4 Aug 2020 10:34:07 -0700 Message-ID: <059f01d66a85$76763020$63629060$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKU+za7jsbb79qc1fYt8rWIA46HpwJ46U6ZAeAUDg0CHPaPtgJ5WrL3AUh31a2nWVXl8A== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 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, 04 Aug 2020 17:34:19 -0000 I think it might be a good idea to specify that the close_notify is always sent when the TLS channel is closed. I was thinking that if we really wanted a content on the EAP Response, then it be reasonable to have the client respond with a close_notify as well. -----Original Message----- From: Alan DeKok Sent: Tuesday, August 4, 2020 10:16 AM To: Jorge Vergara Cc: Jim Schaad ; Mohit Sethi M ; EMU WG ; Benjamin Kaduk Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 On Aug 3, 2020, at 2:23 PM, Jorge Vergara wrote: > > ACK that EAP-TLS does not need to keep the connection open. I agree. I'm happy to change the implementations to send "close notify". > Question: should some consideration be given to consistency with other EAP methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP When those methods send application data, they don't need to do anything else. When those methods use fast reconnect, they don't send application data. So the other EAP methods should also send "close notify" in that case. Alan DeKok. From nobody Tue Aug 4 14:18: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 140B13A10D9 for ; Tue, 4 Aug 2020 14:18:08 -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, 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 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 PLyCvOOEYgcb for ; Tue, 4 Aug 2020 14:18:06 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7E1AC3A10D3 for ; Tue, 4 Aug 2020 14:18:06 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 074LHtah025967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Aug 2020 17:17:58 -0400 Date: Tue, 4 Aug 2020 14:17:55 -0700 From: Benjamin Kaduk To: Mohit Sethi M Cc: "emu@ietf.org" , Jim Schaad , Eric Rescorla Message-ID: <20200804211755.GU92412@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 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, 04 Aug 2020 21:18:08 -0000 Hi Mohit, Sorry for the slow response. On Fri, Jul 31, 2020 at 02:08:44PM +0000, Mohit Sethi M wrote: > Dear all, > > Thanks all for the discussion on the commitment message. > > draft-ietf-emu-eap-tls13-10 (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows the ticket establishment and commitment message: [snip] > > and the relevant text on commitment message: > > 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 [reordering] > > I couldn't parse the comments about the "KeyUpdate" message. Perhaps having the discussion over email will help me understand the issue. > I was referring to the specific promise to not send any more *handshake* messages here -- the only currently defined handshake messages that the EAP server could be sending are NewSessionTicket and KeyUpdate. (Okay, or EKTKey from draft-ietf-per-srtp-ekt-diet, but EAP is not using that at all.) I was not sure if the need was to avoid sending KeyUpdate vs. NewSessionTicket, and why the application layer needed to be concerned with it at all -- to some extent both can be handled internally by the TLS implementation. The application probably wants to get involved if it wants to resume using a session ticket, but it's permitted to just drop the tickets on the floor and never use them. > a TLS record with application data 0x00 (i.e. a TLS record with > TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and > TLSPlaintext.fragment = 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 > handshake messages. 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. This construction feels weird to me because it's using application data to try to make a promise about the TLS layer, which is a fragile construction and could break if there are changes to the TLS implementation without corresponding changes to the application code. In general, the application will not even know when/whether the TLS implementation is going to send more messages (though it would be fairly surprising for the TLS implementation to spontaneously send stuff in the absence of other application messages). Using close_notify as we seem to be agreeing upon feels better since it's the TLS-layer mechanism for doing so and the TLS implementation is expected to do the right thing in terms of not sending more messages, once it's sent or received. -Ben From nobody Wed Aug 5 02:31: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 B97D43A13DE for ; Wed, 5 Aug 2020 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 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, NICE_REPLY_A=-0.949, 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 1rbUFPNZ3nIv for ; Wed, 5 Aug 2020 02:31:35 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80049.outbound.protection.outlook.com [40.107.8.49]) (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 172813A13DD for ; Wed, 5 Aug 2020 02:31:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NlKf1AHOv+ac5y+bO5sNmoxU16GwIolcYGmTG0gyEEr5nQBCE2pr6SwFEJTNrdl0xduwLhj67yHIcm6LD3ihgJAMIOc3eJX4BhFt/PwNqqRKPs5mYZKt+8ROcdshQZY9MUbDWOK29RnK3n8142nPKUBFYDBBu7C+sROCYVRJzSqICgndXd9m7gIpaXcby/W4mF8gDS32SJ2x3gqdIzUTkCWCD2D2bRoMQHXdh/WIRXjOSxSoYSzuvrJvSNYAKGyohb+8Dm3yQ1myKrz74TqsWtOpJDbnC2tLxzE+J8Nv0+vFVNjuDrx/Ibrh8XCzyqAkVpiBIYXv8sdNSGEqw88iuQ== 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=1DHhFVmyYMvTgo+GHnRzVhMAYuzA0SSk3uG+TWEzPKE=; b=jI1aVzlVbQ0tPLQmX2Y8nxwir4Gi2R+Hex3aOUrhAbzDXTt6jZBHyuoxW4CVJobFhAMmNxICZrTjIF2Td66y+yJcl06Ik6ooa8kU2f3GM+TRHzMQ3XryimemrTZIAArh7H/q+Ixn6g1iO1X8qYGw1M9q9MBwG3n7fg5onGKkGiQQa/TPYBOBfBExvqOLkA6nr+kIJJpcAC5FUCfj2Hu+iDnrQGe+rGETmGnmn4dvT8Mhy5KY6Eu/I8ZD53L6aAA3Oog2kHrGqAgF8GgP9RjREBzI20+ybHz5TDjFSoHd42fo3fyGVsHtayRje6EKYD1v8/Tto6Ion35M3ldpx65ctA== 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=1DHhFVmyYMvTgo+GHnRzVhMAYuzA0SSk3uG+TWEzPKE=; b=PKkKaqNcQ/mxiNhM5Iq34Og+RqEXxwUeSTXJTJfKdZ+Axo1Tn6RfZ5UkiK8e1EZcN/ODizVv/dBnUj7dDq8ZiC0tlhZoleO3Kl3AQkjnGwdNYNEP3suY6n4KAHrQPHT52VWqvEy8fySAlV7IwKC9q7N17lH5K+k8LhF5D4eOD2M= 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.3261.13; Wed, 5 Aug 2020 09:31:29 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3%6]) with mapi id 15.20.3261.015; Wed, 5 Aug 2020 09:31:29 +0000 From: Mohit Sethi M To: Alan DeKok , Jorge Vergara CC: Benjamin Kaduk , Mohit Sethi M , EMU WG Thread-Topic: [Emu] Commitment Message handling in EAP-TLS 1.3 Thread-Index: AQHWZ0QZLBwuPJQ+v0OkdIGZnEzxbqkh4VaAgAFmNYCAABk2gIADVriggAF/uwCAARCnAA== Date: Wed, 5 Aug 2020 09:31:28 +0000 Message-ID: References: <045301d66757$f1a0c7f0$d4e257d0$@augustcellars.com> <88D67F36-0817-49D3-B90C-7BB97A26D96E@deployingradius.com> <049901d66817$a73b5bb0$f5b21310$@augustcellars.com> <21053ED1-142B-4B2B-B159-E8FDAB130058@deployingradius.com> In-Reply-To: <21053ED1-142B-4B2B-B159-E8FDAB130058@deployingradius.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.10.0 authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:190:38bb:8f55:cf11:c732:89e1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: de178ce9-8c5e-47b7-4069-08d8392254f7 x-ms-traffictypediagnostic: HE1PR07MB3274: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n8TyGsYLv89EMJrAuAmvQ3aBoLlItxuWO4HddgzcXVahEegxladRzSvkaeg/BFOTk8TFXUcdVyf+Ew38OXFOJtaAp82flwkdEhXdsyJ3oMOxNSBh8wCLkLyvxcgcnd0xU8RZP9h/z6nlK5K30NBd7zfvSiNW6Zts9McX/pvYT5vBr3doX1kvBWmG1AD1pQCTz+jHn8+Bfw4aFpdrrakyWLpbvXAESrlp99Je9Z6TfOcSdV1bQRSqQ+2l6epjcS1U8Dq6M64f6CkLkQkxy0HbfVSezMXmOJoAhPlwhpeoGZHhsFiJhW8vF3dwSHX9/E8GSr3Fxd79/uU5ZQYDeIlVIpezvuyNsm/HqJiIeMEPOfJYSafSmg8FzXp5jSJ5uMWAAjYs07yLQsL58BffvDbLEFi2H5QhdJsWKxah+T8S4xQui+NYCmj3n7nrshIdjtH0SeLFBsv0DJh3qyswn/ulJA== 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)(376002)(366004)(346002)(39860400002)(136003)(966005)(316002)(2906002)(8676002)(186003)(31686004)(31696002)(36756003)(5660300002)(4326008)(54906003)(8936002)(110136005)(66446008)(6512007)(66476007)(478600001)(66946007)(66556008)(64756008)(86362001)(6506007)(76116006)(71200400001)(6486002)(83380400001)(53546011)(15650500001)(2616005)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EQ8fn2KWRG/PEkgtQuD5YpVmUnVbg/CoZgMR19qcm+x8HzVJcf5pNT0TPkf/wPs4+NZl+kW1SL3VlcFQQGfPdZZJxxlNe6HU+gdPi16fd+h2ON5lBjR+urTNYyWNOT4JFtFaidj5O2BtIDkPi+SteW03Y20RDY88p/EOY3tUaKV32RUQgHkD3nAVkW8WjN5vfKw05+NZrTlVr5hOAt4meghKja2TsGgWGZ8LYPIL3VcnR9FADenB0cSmWfaSu68V/lfuMR8DefS3oZTWyrUuZMX0GKfcbum5A0gm/2SxMSHrnMouXqm/TEkNK7k1ZLxIv+vkMD6Lm4jbjdIJJlQLiEZcDXSCkmqdRNTtvRLBumJ+26foKr+yn76QVTYnd30DzJOGvx3SjnkQuCzlpHhRGiJcUXmpg4G+iP/f60vOV6EKf3pDZmrEDvX1JMd9dGWL9DEEMTVPuMQkYos8VoZsev89xHvdair0BO83zhxkx9lMlQ2fvhSusEI/GzhDJ7GJco4J7bHnFS5zB15hE54URO3gFUP8XqgLQWDGDl6j7ccdwWHYOnZJCVYjgK1WU//95CMV/cZnxRn9c+EJTuqFCYjh5Ye8lEmTaZ6+AOWMYBMfSwrIdo9Cef12bVkMBeeos8d078WqUgiMPaNSaT4r94lRGIZp4r5HgVs3dl7rYQW8HaR3xefMK6pBRuJxNrh4qjrEqVAM+NUbHtojSamgfg== 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: HE1PR07MB3386.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: de178ce9-8c5e-47b7-4069-08d8392254f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 09:31:28.8397 (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: xoPeQPT3Ca9ZRGM4K447QPbToBhN0LIQ39DJ89l96439spb7ulw0cmIp+SNyl8Du5Gu984JUHHZFsxaKBjKJ7NNrztY0UopyKLQo3nCv7ag= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3274 Archived-At: Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 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, 05 Aug 2020 09:31:37 -0000 SSBzZWVtIHRvIGFncmVlIHdpdGggdGhlIGNvbnNlbnN1cyBhcm91bmQgdGhlIHVzYWdlIG9mIGNs b3NlX25vdGlmeSANCmluc3RlYWQgb2YgYSBieXRlIG9mIDB4MDAuIEluIGZhY3QsIEkgY2FuJ3Qg ZXZlbiByZW1lbWJlciB0aGUgcmVhc29uIGZvciANCnRoYXQgY2hvaWNlIGFueW1vcmUuDQoNClRo ZSBkcmFmdCBpcyBub3cgdXBkYXRlZCBpbiBnaXRodWIgdG8gc3BlY2lmeSB0aGUgdXNhZ2Ugb2Yg Y2xvc2Vfbm90aWZ5Og0KaHR0cHM6Ly9naXRodWIuY29tL2VtdS13Zy9kcmFmdC1pZXRmLWVtdS1l YXAtdGxzMTMNCg0KSGVyZSBpcyB0aGUgZGlmZiBmb3IgeW91ciBjb252ZW5pZW5jZToNCg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9aHR0cHM6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMudHh0JnVybDI9aHR0cHM6Ly9lbXUtd2cuZ2l0aHVi LmlvL2RyYWZ0LWlldGYtZW11LWVhcC10bHMxMy9kcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMudHh0 DQoNClRoaXMgZWRpdCBwcm9iYWJseSBzdGlsbCByZXF1aXJlcyBzb21lIHNhbml0eSBjaGVja2lu Zy4gSSB3aWxsIHdhaXQgDQp1bnRpbCB3ZSBoYXZlIGNvbmZpcm1hdGlvbiBmcm9tIHRoZSBkaWZm ZXJlbnQgaW1wbGVtZW50YXRpb25zIGJlZm9yZSANCmNsZWFuaW5nIHVwIGFuZCBwdWJsaXNoaW5n IGEgbmV3IHZlcnNpb24uDQoNCi0tTW9oaXQNCg0KT24gOC80LzIwIDg6MTUgUE0sIEFsYW4gRGVL b2sgd3JvdGU6DQo+IE9uIEF1ZyAzLCAyMDIwLCBhdCAyOjIzIFBNLCBKb3JnZSBWZXJnYXJhIDxq b3ZlcmdhckBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4+IEFDSyB0aGF0IEVBUC1UTFMgZG9lcyBu b3QgbmVlZCB0byBrZWVwIHRoZSBjb25uZWN0aW9uIG9wZW4uDQo+ICAgIEkgYWdyZWUuICBJJ20g aGFwcHkgdG8gY2hhbmdlIHRoZSBpbXBsZW1lbnRhdGlvbnMgdG8gc2VuZCAiY2xvc2Ugbm90aWZ5 Ii4NCj4NCj4+IFF1ZXN0aW9uOiBzaG91bGQgc29tZSBjb25zaWRlcmF0aW9uIGJlIGdpdmVuIHRv IGNvbnNpc3RlbmN5IHdpdGggb3RoZXIgRUFQIG1ldGhvZHMgdGhhdCBkbyBuZWVkIHRvIGtlZXAg dGhlIGNvbm5lY3Rpb24gb3Blbj8gaS5lLiBQRUFQL0VBUC1UVExTL1RFQVANCj4gICAgV2hlbiB0 aG9zZSBtZXRob2RzIHNlbmQgYXBwbGljYXRpb24gZGF0YSwgdGhleSBkb24ndCBuZWVkIHRvIGRv IGFueXRoaW5nIGVsc2UuDQo+DQo+ICAgIFdoZW4gdGhvc2UgbWV0aG9kcyB1c2UgZmFzdCByZWNv bm5lY3QsIHRoZXkgZG9uJ3Qgc2VuZCBhcHBsaWNhdGlvbiBkYXRhLiAgU28gdGhlIG90aGVyIEVB UCBtZXRob2RzIHNob3VsZCBhbHNvIHNlbmQgImNsb3NlIG5vdGlmeSIgaW4gdGhhdCBjYXNlLg0K Pg0KPiAgICBBbGFuIERlS29rLg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBFbXUgbWFpbGluZyBsaXN0DQo+IEVtdUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0K From nobody Fri Aug 7 08:35: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 A5EA33A0B13 for ; Fri, 7 Aug 2020 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H3=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=um.es 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 g6GfKWVvwfJW for ; Fri, 7 Aug 2020 08:35:21 -0700 (PDT) Received: from mx02.puc.rediris.es (outbound6sev.lav.puc.rediris.es [130.206.19.181]) (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 473863A0AF9 for ; Fri, 7 Aug 2020 08:35:21 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by mx02.puc.rediris.es with ESMTP id 077FZF3Y014535-077FZF3Z014535; Fri, 7 Aug 2020 17:35:19 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 4016621FCD; Fri, 7 Aug 2020 17:35:15 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EpmfByffqgOT; Fri, 7 Aug 2020 17:35:15 +0200 (CEST) Received: from MacBook-Pro-de-Dan.local (unknown [84.17.62.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 2646121E91; Fri, 7 Aug 2020 17:35:10 +0200 (CEST) From: Dan Garcia To: EMU WG Cc: dan.garcia@um.es, OdinS - Rafael Marin-Perez , =?UTF-8?Q?Eduardo_Ingl=c3=a9s_S=c3=a1nchez?= Message-ID: <98fe2b58-de58-eb88-f359-35c21ae76cb4@um.es> Date: Fri, 7 Aug 2020 17:35:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of dan.garcia@um.es designates 155.54.212.171 as permitted sender) smtp.mailfrom=dan.garcia@um.es DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:subject:to:cc:message-id:date:mime-version:content-type; bh=vjOadFG0Qio57iPIyd1pUryrhA1m4J6e5uBEydLlC9U=; b=vEilJFHR1dk1HewvlGbzFkFbCl4woQhYrN1nZIi/ogOP9OgvOJdck4TH9XO4sAalTNx+IJjN8nW1 8FS7jLtsmYxG4sPHiMYkXcgA5wl1unCPzqKZITiu3JP96m+B6neXLbb6LWVcsNcSjQbkbOxDWJ5v e3295+3TWf+QZBX0T+5Zdxk+CpeHLPwX46CYZ6Z7Lza+6XIS6dEpkxpyE8iIwsmuL402dH+q74UT 6wDMcNQBJLQPvxl3IlvNsAsrgALFdD45+m7CfPVFYQSgtJz38XkR8d4jUNqug7r8g35JrZHzhJyo vHyKzvvbDa7YHDJlUick4afEZVZmn7C+GPV0lg== Archived-At: Subject: [Emu] New draft about EAP-EDHOC 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, 07 Aug 2020 15:35:23 -0000 Dear EMU, We have submitted a draft with an idea about an EAP-EDHOC method. There is still work to do. https://datatracker.ietf.org/doc/draft-ingles-eap-edhoc/ Any comments are welcome. Best Regards, Dan. From terry.burton@gmail.com Mon Aug 10 08:59:08 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 CD61B3A046E for ; Mon, 10 Aug 2020 08:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOx5SnQ58rLe for ; Mon, 10 Aug 2020 08:59:07 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 851673A0114 for ; Mon, 10 Aug 2020 08:59:07 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id j23so4453624vsq.7 for ; Mon, 10 Aug 2020 08:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=ia65nCHcQh4V6rLGCLwJi2B+mkzkCoeu9+io0iLkVJ8=; b=rBfMGK/odVd+Hxajm7hcdxdsNsGjXtgmzTFf0xEsz3BWs9bHe/EYf9r0XCMSEFhxKv j1AoiK/3ht/KzydVAJEeM2S6bl5nuhdyU6cfkO4zkwhcyzgEDOFw+ryj7Wn4HrvTU32n hfEUwGeiRrU/0+Hl9v9WtdVsszvqrjjvz7yxxyW37689QB2Mw/twXVmlVUnZfpmWFWGI 11CLXYS2Aq44QUDq7kbInuBWlP/zwDTi/R3YF1sVuVEDDEz8OH70TzYFh+hNdrduPshF XH2A1e1bU+vAhpHZ8N90n6He51QMxQO6LS4KeEbbtgpznElDE9bAsy1dc5eEkWHzIUSY U/PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=ia65nCHcQh4V6rLGCLwJi2B+mkzkCoeu9+io0iLkVJ8=; b=CkPZR/IILEwYfSl665rNOGtTN/hi+hflojBtGyGGQ2RWBD3Pq1F5DsgdWR/+SHx4Ux RZhUMkCMAbqu1w/0KftsCiuBFkSOauuVIkKr86t1ooyrY2e53V3eUxZPTVkRLYsnWC8J bcCfIdg/mPRwwF/zLS8CSkxUkx7MMshwrpg/sUAGkxuSn+8STQoXZmT8R0jgNls5403Z N8f43o7Q5fv7Y/tlaB3Yb6kYsYAcaQu9F7suJmpK5TE1ykowtFMBGFZclB6h59mXtlc8 gA2DGIKZg6ZEvS+yc5XxE1CktSsexadQyg5goeeX8xylvebzhyNjWqzqeQAgbxWO/RsB D2ww== X-Gm-Message-State: AOAM532VziuTH4c4We2m43WiO6NkGJwugU0jBTcAW8C2dOuIfbNJL3eT kTmR773EzjLu7sCI0F2j5f8ZK2l2iQpy40m0YCInM+HW4W8= X-Google-Smtp-Source: ABdhPJwn6cqjN2cdczDglnLo14Gkx8knKErBRtEoEAmYIkwjlmJBWToiSTiX+g/+VmVlc2xqcD9GapdtAyivUSXfqnk= X-Received: by 2002:a05:6102:30a3:: with SMTP id y3mr19241361vsd.201.1597075146250; Mon, 10 Aug 2020 08:59:06 -0700 (PDT) MIME-Version: 1.0 Reply-To: tez@terryburton.co.uk From: Terry Burton Date: Mon, 10 Aug 2020 16:58:30 +0100 Message-ID: To: emu@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption 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, 10 Aug 2020 17:45:56 -0000 Hi, Reading "Using EAP-TLS with TLS 1.3" I find the text potentially misleading when it comes to resumption within TLS 1.3, specifically for the case where the peer wishes to re-validate the certificate originally provided by the server during the initial handshake using only its locally cached data and without redoing the handshake, e.g. to determine that the original certificate hasn't expired or been revoked. 5.7. Resumption ... To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve authorization information such as certificate chains from the initial full handshake. ... There are two ways to retrieve the cached information from the original full handshake. ... The second method for retrieving cached information is via [RFC5077] or [RFC8446], where the TLS server encapsulates the information into a ticket and sends it to the client. The client can subsequently do resumption using the obtained ticket. Note that the client still needs to cache the information locally. In TLS 1.3, the PSK ticket is defined as being encrypted using a key that only the server knows. Even without encryption, the format for the ticket is opaque to the client with only a suggested format presented in RFC 8446. How is the original handshake data determined? A casual reading of the text seems to imply that the client performs some verification using the encapsulated information within the ticket. However I believe that the intent is to use the full PSK blob, or some digest thereof, as a key to lookup the corresponding cached handshake data. Perhaps this could be made clearer? Thanks, Terry From nobody Mon Aug 10 11:42:16 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 F1E613A0AA8 for ; Mon, 10 Aug 2020 11:42:14 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw7McI_43v7Z for ; Mon, 10 Aug 2020 11:42:13 -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 EDE203A0AA2 for ; Mon, 10 Aug 2020 11:42:12 -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 75759126; Mon, 10 Aug 2020 18:42:10 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: Date: Mon, 10 Aug 2020 14:42:08 -0400 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Terry Burton X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption 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, 10 Aug 2020 18:42:15 -0000 On Aug 10, 2020, at 11:58 AM, Terry Burton = wrote: > Reading "Using EAP-TLS with TLS 1.3" I find the text potentially > misleading when it comes to resumption within TLS 1.3, specifically > for the case where the peer wishes to re-validate the certificate > originally provided by the server during the initial handshake using > only its locally cached data and without redoing the handshake, e.g. > to determine that the original certificate hasn't expired or been > revoked. I suspect that the client needs to cache the server certificate, and = associate it with the session ticket. The certificate can then be = re-validated on fast reconnect. >=20 > 5.7. Resumption > ... > To perform resumption in a secure way, the EAP-TLS peer and > EAP-TLS server need to be able to securely retrieve authorization > information such as certificate chains from the initial full > handshake. > ... > There are two ways to retrieve the cached information from the > original full handshake. > ... > The second method for retrieving cached information is > via [RFC5077] or [RFC8446], where the TLS server encapsulates the > information into a ticket and sends it to the client. The client = can > subsequently do resumption using the obtained ticket. Note that the > client still needs to cache the information locally. Hmm... yes, it should be nice to discuss *what* information is cached, = and why it is cached, and what is done with it to re-validate it. > In TLS 1.3, the PSK ticket is defined as being encrypted using a key > that only the server knows. Even without encryption, the format for > the ticket is opaque to the client with only a suggested format > presented in RFC 8446. >=20 > How is the original handshake data determined? A casual reading of the > text seems to imply that the client performs some verification using > the encapsulated information within the ticket. If so, that should be clarified. The ticket is an opaque blob to the = client. > However I believe that the intent is to use the full PSK blob, or some > digest thereof, as a key to lookup the corresponding cached handshake > data. >=20 > Perhaps this could be made clearer? I agree. Alan DeKok. From nobody Tue Aug 11 01:11: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 AC9533A0E52 for ; Tue, 11 Aug 2020 01:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 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, NICE_REPLY_A=-0.949, 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 lYON9p0CZZXz for ; Tue, 11 Aug 2020 01:11:06 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80049.outbound.protection.outlook.com [40.107.8.49]) (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 143CF3A0E50 for ; Tue, 11 Aug 2020 01:11:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iKlTnqTvUHxsH16TYMUQP3kYUlbElZV2IfhnSzTGvfCazitE43G22FInjjyJ6WHkrU2OIIp1FA1ap/C2/Iz3/PXVggQIVDue25VIDeQC5zWFRgsJJTnQIHIaDWcV3ZrGbEZjENuBRlO8W3el2o89MIfN89LyiVpiCEYrhVJYJqRMiABQyY8guwKQgoQpHyELkTRo0J6tjRoMXfOAWR+5wzp+F+146rZsRwsY5vgfR2388k5hbRED0JO9EplGLC9zfLRziGJbBfpy3ds7346NhiVMqpWfISQChgfwRsBXXu/UZBjNlRU4HT/y4pt0qjOyM/0PTr9I6MUberF+cTRrhw== 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=VrKp1VhL9VqoMLn7uxIM2rk19qfhuO61LJYSNSGl7/0=; b=YkdB5vsWkKUtBM46CzozaBUjU+s8wgrcFd1ulUcsreU/QYyrC5S8+PmxTCBpIaZyl662Gelo2uuCRtXm1h10wx4DMEjRBJT5o/a/ttg4XRculvPsduFTur7uhObW743g4uJIm2ZBK1RZXEgMv7+nBmevHqe1UwhVVIqxcGdcgwyhUsKSrfJaJC7nu7ET9+5GE21w6TY5aaEUayIK+kabFCCQPivKvGKB/NmlL6r29AlZhzN4w5aoGvN4LX0iAXpSo3k0/w2K00sKy/NWLqOC0MgEPzfCjvJO9GkV5m+fbL6Ysuro5qKCdzoIxHfwGbrMG4hRWbjsDT7T0NHGr52yvQ== 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=VrKp1VhL9VqoMLn7uxIM2rk19qfhuO61LJYSNSGl7/0=; b=UBzFFj4uIb7bEmgY6nfsr9ABTTj52w+DAYcbuMQI03ZMOzIt8CvrVtKNVZpXRodH1zTg8X412fnYaTN336epZ+1/PRH56/nt+W6Y4w60nIe+AURSnSnFQE7/AGQozOB4dYgxY0izKDGSzvXN6vPLNNk8F4ZNRj5HzQcZ/Onb6DI= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR07MB3148.eurprd07.prod.outlook.com (2603:10a6:7:2d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.11; Tue, 11 Aug 2020 08:10:59 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3%6]) with mapi id 15.20.3283.015; Tue, 11 Aug 2020 08:10:59 +0000 From: Mohit Sethi M To: "tez@terryburton.co.uk" , "emu@ietf.org" Thread-Topic: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption Thread-Index: AQHWb7bxqeMRt4tiSkeZ2uLPasx49Q== Date: Tue, 11 Aug 2020 08:10:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: terryburton.co.uk; dkim=none (message not signed) header.d=none;terryburton.co.uk; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:190:1057:9ca3:9842:291d:a58f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1cebbd76-3a0e-4c85-7248-08d83dce14d9 x-ms-traffictypediagnostic: HE1PR07MB3148: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Wdfyi2wNtAVMrcRLyCsA/BZoxLT9xctWlPTK4JfpzN2DV/fsmM2verwh6RRGWfAyHTpM75izZWSbAzMJEUaVYv1n8ljspi1SwO3dKg3mX7fmp5IM7Wt5zgakdKprgDCZ2Htb68kb1+VTNW+rqNr1UP+y8SpPcdAFzRqig/yrSk1P8+Ko1819rYYRz/mwDw1t0U6a1yadRXEx9/Zqhhv/XD7YIF+sBnQGBAcpkzP4By9yPNRv7JjFwXC78BJ2pEAKgcaH+b6YcCxQfyNPJg7MJs8fTRNSAShdZxihR2hqmp8HKExJ9FXtzlLwydKlYN+x/Bi/VXIxE4/QtxcRihsN/bA4zAXua578SFBxoUbDXw0UkbQh/JzEVud9MUVDfyBopMtv1oHEgs7ibgeEQM2rDUkrSWqRTHOZscNxMByj0JXN8Jx8wqIFh4KIcGSh6BCtfrVMwiNLXZ1mchEYce86Cg== 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; SFS:(4636009)(396003)(376002)(346002)(39860400002)(366004)(136003)(316002)(36756003)(110136005)(8936002)(6486002)(86362001)(71200400001)(966005)(5660300002)(2616005)(66446008)(64756008)(66556008)(66476007)(66946007)(8676002)(6512007)(31696002)(76116006)(83380400001)(478600001)(2906002)(31686004)(53546011)(186003)(6506007)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Om/oMvxO7PN4UEM+CF9SunSnuRIWutf4rCe4xN+/Z120Ft1osZG+EN22r9GhMsH034T2MFn2mCi+1Q80uzoSg9FuZa+LFjTWq5g6uX1UzgrHq2Pr6dQkxseR8jNiUm2IEUngeVQuWaSi84DD98jYgw1IM88d/n0JPR8B5ZNFTtor3isEoFAedH2523S4pK+/+VjiP1UWFAgL3CMjKB5T9xGyjweIFf5UNlkcCwdHxppMhbCcSjzmArK+/YLxaWKfeDOFykpJag6J1sh77p+l2gSq1puMhIu7BO2c6JtEtIWyMKi7hkNbmIDTCien/7hG1A56uEv0ORGMApvwVGwUpKT4m3yQBmCLMnui4bBLWTDPR/P7IGJ+ui4GjItr9C0RbUh90dqfq1GSwiCfUgxg5TIogAeTeBpd8VMbTIHN9V50/LXDwAhnW2SNR1HO3F3mdJ8Y8XmwBQjGi6yR29h5wZY7Od+fPoa62SuTZGfHrK5UMzy5LqHpvBjh6aBBeRSnQc1Xa5R/FS5g08aDUj/QXxsiTT6GcpZMmpzCXyHgU6W+hEOVo2ttW0uWMq0l+TYZ9v69abPpnBZOUeaEgols9cfgQToqgprUwGfrJyoVyxQ4KqDH1hgj9L1SffDa8OB95emythKi8hvsjhO/yXX15QpyN9BHUpSHB9trfzGlfsD0u3k3Bu+J/Hy+jhTcoDm0cNuU2iBNX5uXZUAJntfnvA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <95E6A146DC4D554DB5354A4975908F67@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3386.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1cebbd76-3a0e-4c85-7248-08d83dce14d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 08:10:59.1489 (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: x9NxFIUDEeTZLm7n+jBE0AggI/lYcVoScpZWAyYoDd3enKw5m2a7kZh8TU1/F2C+3DNJ1ZS84UrBDyqIdoz7MabK0kFxqX8kkUTmPHTNun0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3148 Archived-At: Subject: Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption 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, 11 Aug 2020 08:11:09 -0000 SGkgVGVycnksDQoNClNlY3Rpb24gNS43wqAgIlJlc3VtcHRpb24iIHNheXM6DQoNCj4gV2hlbiBy ZXN1bXB0aW9uIG9jY3VycywgaXQgaXMgYmFzZWQgb24gY2FjaGVkIGluZm9ybWF0aW9uIGF0IHRo ZSBUTFMNCj4gwqDCoCBsYXllci7CoCBUbyBwZXJmb3JtIHJlc3VtcHRpb24gaW4gYSBzZWN1cmUg d2F5LCB0aGUgRUFQLVRMUyBwZWVyIGFuZA0KPiDCoMKgIEVBUC1UTFMgc2VydmVyIG5lZWQgdG8g YmUgYWJsZSB0byBzZWN1cmVseSByZXRyaWV2ZSBhdXRob3JpemF0aW9uDQo+IMKgwqAgaW5mb3Jt YXRpb24gc3VjaCBhcyBjZXJ0aWZpY2F0ZSBjaGFpbnMgZnJvbSB0aGUgaW5pdGlhbCBmdWxsDQo+ IMKgwqAgaGFuZHNoYWtlLsKgIFdlIHVzZSB0aGUgdGVybSAiY2FjaGVkIGRhdGEiIHRvIGRlc2Ny aWJlIHN1Y2gNCj4gwqDCoCBpbmZvcm1hdGlvbi7CoCBBdXRob3JpemF0aW9uIGR1cmluZyByZXN1 bXB0aW9uIE1VU1QgYmUgYmFzZWQgb24gc3VjaA0KPiDCoMKgIGNhY2hlZCBkYXRhLsKgIFRoZSBF QVAgcGVlciBhbmQgc2V2ZXIgTUFZIHBlcmZvcm0gZnJlc2ggcmV2b2NhdGlvbg0KPiDCoMKgIGNo ZWNrcyBvbiB0aGUgY2FjaGVkIGNlcnRpZmljYXRlIGRhdGEuIA0KDQpUaGlzIHRleHQgaW5kaWNh dGVzIHdoYXQgbmVlZHMgdG8gYmUgY2FjaGVkIGFuZCBzZWVtcyBwcmV0dHkgY2xlYXIgdG8gbWUu DQoNClRoZSBuZXh0IHF1ZXN0aW9uIGlzIGhvdyB0byBsb29rdXAgdGhlIGNhY2hlZCBpbmZvcm1h dGlvbi4gVGhpcyBpcyB3aGF0IA0KdGhlIHRleHQgc2F5cyBjdXJyZW50bHk6DQoNCj4gwqDCoCBU aGVyZSBhcmUgdHdvIHdheXMgdG8gcmV0cmlldmUgdGhlIGNhY2hlZCBpbmZvcm1hdGlvbiBmcm9t IHRoZQ0KPiDCoMKgIG9yaWdpbmFsIGZ1bGwgaGFuZHNoYWtlLsKgIFRoZSBmaXJzdCBtZXRob2Qg aXMgdGhhdCB0aGUgVExTIHNlcnZlciBhbmQNCj4gwqDCoCBjbGllbnQgY2FjaGUgdGhlIGluZm9y bWF0aW9uIGxvY2FsbHkuwqAgVGhlIGNhY2hlZCBpbmZvcm1hdGlvbiBpcw0KPiDCoMKgIGlkZW50 aWZpZWQgYnkgYW4gaWRlbnRpZmllci7CoCBGb3IgVExTIHZlcnNpb25zIGJlZm9yZSAxLjMsIHRo ZQ0KPiDCoMKgIGlkZW50aWZpZXIgY2FuIGJlIHRoZSBzZXNzaW9uIElELCBmb3IgVExTIDEuMywg dGhlIGlkZW50aWZpZXIgaXMgdGhlDQo+IMKgwqAgUFNLIGlkZW50aXR5LsKgIFRoZSBzZWNvbmQg bWV0aG9kIGZvciByZXRyaWV2aW5nIGNhY2hlZCBpbmZvcm1hdGlvbiBpcw0KPiDCoMKgIHZpYSBb UkZDNTA3N10gb3IgW1JGQzg0NDZdLCB3aGVyZSB0aGUgVExTIHNlcnZlciBlbmNhcHN1bGF0ZXMg dGhlDQo+IMKgwqAgaW5mb3JtYXRpb24gaW50byBhIHRpY2tldCBhbmQgc2VuZHMgaXQgdG8gdGhl IGNsaWVudC7CoCBUaGUgY2xpZW50IGNhbg0KPiDCoMKgIHN1YnNlcXVlbnRseSBkbyByZXN1bXB0 aW9uIHVzaW5nIHRoZSBvYnRhaW5lZCB0aWNrZXQuwqAgTm90ZSB0aGF0IHRoZQ0KPiDCoMKgIGNs aWVudCBzdGlsbCBuZWVkcyB0byBjYWNoZSB0aGUgaW5mb3JtYXRpb24gbG9jYWxseS7CoCBUaGUg Zm9sbG93aW5nDQo+IMKgwqAgcmVxdWlyZW1lbnRzIGFwcGx5IHRvIGJvdGggbWV0aG9kcy4NClRo ZSBmaXJzdCBtZWNoYW5pc20gaXMgb2J2aW91cywgYm90aCBzaWRlcyBzdG9yZSB0aGUgaW5mb3Jt YXRpb24gZnJvbSANCnRoZSBpbml0aWFsIGhhbmRzaGFrZSBhbmQgbG9va3VwIHVzaW5nIHRoZSBT ZXNzaW9uIElEIG9yIHRoZSBQU0sgaWRlbnRpdHkuDQoNCkluIHRoZSBzZWNvbmQgbWVjaGFuaXNt LCB0aGUgc2VydmVyIGNhbiBhdm9pZCBzdG9yaW5nIGluZm9ybWF0aW9uLiBJdCANCmluc3RlYWQg cHV0cyB0aGF0IGluZm9ybWF0aW9uIGluIHRoZSBQU0sgb3IgdGhlIHNlc3Npb24gdGlja2V0IGFu ZCBzZW5kcyANCml0IHRvIHRoZSBjbGllbnQuIEhvd2V2ZXIsIHRoZSBjbGllbnQgc3RpbGwgbmVl ZHMgdG8gc3RvcmUgaW5mb3JtYXRpb24gDQpmcm9tIHRoZSBvcmlnaW5hbCBoYW5kc2hha2UuIFRo aXMgaXMgd2h5IHRoZXJlIGlzIHRoZSBzZW50ZW5jZSAiTm90ZSANCnRoYXQgdGhlIGNsaWVudCBz dGlsbCBuZWVkcyB0byBjYWNoZSB0aGUgaW5mb3JtYXRpb24gbG9jYWxseS4iLiBUaGUgDQpjbGll bnQgY2FuJ3Qgb2J2aW91c2x5IHJlYWQgdGhlIGNvbnRlbnRzIG9mIHRoZSB0aWNrZXQgb3IgdGhl IFBTSy4NCg0KRG8geW91IGhhdmUgc29tZSBjb25jcmV0ZSBzdWdnZXN0aW9uIG9uIGltcHJvdmlu ZyB0aGUgdGV4dD8gV2UgYXJlIGhhcHB5IA0KdG8gZWRpdCBvciByZWNlaXZlIHB1bGwgcmVxdWVz dHMgb24gZ2l0aHViOiANCmh0dHBzOi8vZ2l0aHViLmNvbS9lbXUtd2cvZHJhZnQtaWV0Zi1lbXUt ZWFwLXRsczEzDQoNCldvdWxkIHRoaXMgYmUgYmV0dGVyOg0KDQo+IMKgVGhlIHNlY29uZCBtZXRo b2QgZm9yIHJldHJpZXZpbmcgY2FjaGVkIGluZm9ybWF0aW9uIGlzDQo+IMKgwqAgdmlhIFtSRkM1 MDc3XSBvciBbUkZDODQ0Nl0sIHdoZXJlIHRoZSBUTFMgc2VydmVyIGF2b2lkcyBzdG9yaW5nDQo+ IMKgwqAgaW5mb3JtYXRpb24gbG9jYWxseSBhbmQgaW5zdGVhZCBlbmNhcHN1bGF0ZXMgdGhlIGlu Zm9ybWF0aW9uIGludG8gYQ0KPiDCoMKgIHRpY2tldCBvciBQU0sgYW5kIHNlbmRzIGl0IHRvIHRo ZSBjbGllbnQuwqAgTm90ZSB0aGF0IHRoZSBjbGllbnQgc3RpbGwNCj4gwqDCoCBuZWVkcyB0byBj YWNoZSB0aGUgaW5mb3JtYXRpb24gbG9jYWxseS7CoCBUaGUgY2xpZW50IGNhbiBzdWJzZXF1ZW50 bHkNCj4gwqDCoCBkbyByZXN1bXB0aW9uIHVzaW5nIHRoZSBvYnRhaW5lZCB0aWNrZXQuIA0KLS1N b2hpdA0KDQpPbiA4LzEwLzIwIDY6NTggUE0sIFRlcnJ5IEJ1cnRvbiB3cm90ZToNCj4gSGksDQo+ DQo+IFJlYWRpbmcgIlVzaW5nIEVBUC1UTFMgd2l0aCBUTFMgMS4zIiBJIGZpbmQgdGhlIHRleHQg cG90ZW50aWFsbHkNCj4gbWlzbGVhZGluZyB3aGVuIGl0IGNvbWVzIHRvIHJlc3VtcHRpb24gd2l0 aGluIFRMUyAxLjMsIHNwZWNpZmljYWxseQ0KPiBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIHBlZXIg d2lzaGVzIHRvIHJlLXZhbGlkYXRlIHRoZSBjZXJ0aWZpY2F0ZQ0KPiBvcmlnaW5hbGx5IHByb3Zp ZGVkIGJ5IHRoZSBzZXJ2ZXIgZHVyaW5nIHRoZSBpbml0aWFsIGhhbmRzaGFrZSB1c2luZw0KPiBv bmx5IGl0cyBsb2NhbGx5IGNhY2hlZCBkYXRhIGFuZCB3aXRob3V0IHJlZG9pbmcgdGhlIGhhbmRz aGFrZSwgZS5nLg0KPiB0byBkZXRlcm1pbmUgdGhhdCB0aGUgb3JpZ2luYWwgY2VydGlmaWNhdGUg aGFzbid0IGV4cGlyZWQgb3IgYmVlbg0KPiByZXZva2VkLg0KPg0KPg0KPiA1LjcuICBSZXN1bXB0 aW9uDQo+ICAgICAuLi4NCj4gICAgIFRvIHBlcmZvcm0gcmVzdW1wdGlvbiBpbiBhIHNlY3VyZSB3 YXksIHRoZSBFQVAtVExTIHBlZXIgYW5kDQo+ICAgICBFQVAtVExTIHNlcnZlciBuZWVkIHRvIGJl IGFibGUgdG8gc2VjdXJlbHkgcmV0cmlldmUgYXV0aG9yaXphdGlvbg0KPiAgICAgaW5mb3JtYXRp b24gc3VjaCBhcyBjZXJ0aWZpY2F0ZSBjaGFpbnMgZnJvbSB0aGUgaW5pdGlhbCBmdWxsDQo+ICAg ICBoYW5kc2hha2UuDQo+ICAgICAuLi4NCj4gICAgIFRoZXJlIGFyZSB0d28gd2F5cyB0byByZXRy aWV2ZSB0aGUgY2FjaGVkIGluZm9ybWF0aW9uIGZyb20gdGhlDQo+ICAgICBvcmlnaW5hbCBmdWxs IGhhbmRzaGFrZS4NCj4gICAgIC4uLg0KPiAgICAgVGhlIHNlY29uZCBtZXRob2QgZm9yIHJldHJp ZXZpbmcgY2FjaGVkIGluZm9ybWF0aW9uIGlzDQo+ICAgICB2aWEgW1JGQzUwNzddIG9yIFtSRkM4 NDQ2XSwgd2hlcmUgdGhlIFRMUyBzZXJ2ZXIgZW5jYXBzdWxhdGVzIHRoZQ0KPiAgICAgaW5mb3Jt YXRpb24gaW50byBhIHRpY2tldCBhbmQgc2VuZHMgaXQgdG8gdGhlIGNsaWVudC4gIFRoZSBjbGll bnQgY2FuDQo+ICAgICBzdWJzZXF1ZW50bHkgZG8gcmVzdW1wdGlvbiB1c2luZyB0aGUgb2J0YWlu ZWQgdGlja2V0LiAgTm90ZSB0aGF0IHRoZQ0KPiAgICAgY2xpZW50IHN0aWxsIG5lZWRzIHRvIGNh Y2hlIHRoZSBpbmZvcm1hdGlvbiBsb2NhbGx5Lg0KPg0KPg0KPiBJbiBUTFMgMS4zLCB0aGUgUFNL IHRpY2tldCBpcyBkZWZpbmVkIGFzIGJlaW5nIGVuY3J5cHRlZCB1c2luZyBhIGtleQ0KPiB0aGF0 IG9ubHkgdGhlIHNlcnZlciBrbm93cy4gRXZlbiB3aXRob3V0IGVuY3J5cHRpb24sIHRoZSBmb3Jt YXQgZm9yDQo+IHRoZSB0aWNrZXQgaXMgb3BhcXVlIHRvIHRoZSBjbGllbnQgd2l0aCBvbmx5IGEg c3VnZ2VzdGVkIGZvcm1hdA0KPiBwcmVzZW50ZWQgaW4gUkZDIDg0NDYuDQo+DQo+IEhvdyBpcyB0 aGUgb3JpZ2luYWwgaGFuZHNoYWtlIGRhdGEgZGV0ZXJtaW5lZD8gQSBjYXN1YWwgcmVhZGluZyBv ZiB0aGUNCj4gdGV4dCBzZWVtcyB0byBpbXBseSB0aGF0IHRoZSBjbGllbnQgcGVyZm9ybXMgc29t ZSB2ZXJpZmljYXRpb24gdXNpbmcNCj4gdGhlIGVuY2Fwc3VsYXRlZCBpbmZvcm1hdGlvbiB3aXRo aW4gdGhlIHRpY2tldC4NCj4NCj4gSG93ZXZlciBJIGJlbGlldmUgdGhhdCB0aGUgaW50ZW50IGlz IHRvIHVzZSB0aGUgZnVsbCBQU0sgYmxvYiwgb3Igc29tZQ0KPiBkaWdlc3QgdGhlcmVvZiwgYXMg YSBrZXkgdG8gbG9va3VwIHRoZSBjb3JyZXNwb25kaW5nIGNhY2hlZCBoYW5kc2hha2UNCj4gZGF0 YS4NCj4NCj4gUGVyaGFwcyB0aGlzIGNvdWxkIGJlIG1hZGUgY2xlYXJlcj8NCj4NCj4NCj4gVGhh bmtzLA0KPg0KPiBUZXJyeQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBFbXUgbWFpbGluZyBsaXN0DQo+IEVtdUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0K From nobody Tue Aug 11 05:40:42 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 533463A102C for ; Tue, 11 Aug 2020 05:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_FROM=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 H2jBPSLG5wmu for ; Tue, 11 Aug 2020 05:40:39 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 6FE7C3A102D for ; Tue, 11 Aug 2020 05:40:39 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id b26so5879817vsa.13 for ; Tue, 11 Aug 2020 05:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=csp/g3HturvFyxiin3Fo4IVB/T1ifgchde6TTtRlz24=; b=Zz6GezEWX0AEjLAuQ8rYqYaM9PasIzo5wM+nd5GZUrryI0OOCr+wVRWGFFKdxZ16uf yqZwVvVopG9VPaVP/YPOfISrSY/+M7WgefXyNu1vwAAY3aL/vtiz7kQWPHGrQWwp22ts ciDYd44WObpHBxIW39wDBKxVsrcmjj1ZQMLBhOKeoFWHK00W1arF4G/49K5OErhofmkN Uvtw4q6mk9Szx02Goff7uD3Ad2mxulWadayVCii8nI3dO2exgACrLEpJ5iKw8BtJb8Ls FoqFl7G8OIv+XjZMQrNMP/odY4CSTsVlJAeMMJva06KBVuYKnUZz4ho85lnfSpt3hecF FiIA== 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=csp/g3HturvFyxiin3Fo4IVB/T1ifgchde6TTtRlz24=; b=K/bZWxhhr71J+QpdIq8HxaS6CY3zYT/tUTVrMRxrojVzGYFAVtqZRXDtBV+9Fb9Jxq GZSlhFdrB4QOPK2CR0YVUXpMHPhdanhtKt3RITchs9vCasTpJyn3VEvaLpcuDWuQPi+6 /mTJr8+77vUn2qCF2bYFodwm9X+7OQUXZMBIyvzkp26eQn7aJnKMhyPfNpnj3Q5vHNuF /V6mD0yADHhspyKjxu9tt87F/Q0emaRlsOieVFuzZhBoC/lX8aCjZNCyRiPdifuycaQh OLZu1532Yd4l9Lu6dVRJgLeVA09UlybGeBuYwNmAdlS/uWfxXJcvnPZaA8h8zSarOlif USEA== X-Gm-Message-State: AOAM531PYpZu/kb9/oHBL/L0dvedjvan9bQaosRPEgFi6db7cOv9VEWY 2ruWVUuXf6X0Qsm6r31JYYa1PnKWZy3d6Nv8t0E= X-Google-Smtp-Source: ABdhPJz09/oFQy3W+5VoBur1xMIE6Wi61IE7xM1H0GJoTPM59BpUn3MqHIkGi9BmPy8qbArjHaA5sTdvw5rVTk2C0WY= X-Received: by 2002:a05:6102:3025:: with SMTP id v5mr22960581vsa.194.1597149638131; Tue, 11 Aug 2020 05:40:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: tez@terryburton.co.uk From: Terry Burton Date: Tue, 11 Aug 2020 13:40:01 +0100 Message-ID: To: Mohit Sethi M Cc: "emu@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption 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, 11 Aug 2020 12:40:41 -0000 On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M wr= ote: > > Section 5.7 "Resumption" says: > > > When resumption occurs, it is based on cached information at the TLS > > layer. To perform resumption in a secure way, the EAP-TLS peer and > > EAP-TLS server need to be able to securely retrieve authorization > > information such as certificate chains from the initial full > > handshake. We use the term "cached data" to describe such > > information. Authorization during resumption MUST be based on such > > cached data. The EAP peer and sever MAY perform fresh revocation > > checks on the cached certificate data. > > This text indicates what needs to be cached and seems pretty clear to me. Hi Mohit, Agreed, that's clear. Typo: "sever" > The next question is how to lookup the cached information. This is what > the text says currently: > > > There are two ways to retrieve the cached information from the > > original full handshake. The first method is that the TLS server an= d > > client cache the information locally. The cached information is > > identified by an identifier. For TLS versions before 1.3, the > > identifier can be the session ID, for TLS 1.3, the identifier is the > > PSK identity. The second method for retrieving cached information i= s > > via [RFC5077] or [RFC8446], where the TLS server encapsulates the > > information into a ticket and sends it to the client. The client ca= n > > subsequently do resumption using the obtained ticket. Note that the > > client still needs to cache the information locally. The following > > requirements apply to both methods. > The first mechanism is obvious, both sides store the information from > the initial handshake and lookup using the Session ID or the PSK identity= . No disagreement here. > In the second mechanism, the server can avoid storing information. It > instead puts that information in the PSK or the session ticket and sends > it to the client. However, the client still needs to store information > from the original handshake. This is why there is the sentence "Note > that the client still needs to cache the information locally.". The > client can't obviously read the contents of the ticket or the PSK. I agree with the sentiment, but the current text seems a bit "Sherlock": Once you've eliminated all other possibilities whatever remains must be the case. I think it should directly state that the client uses the opaque ticket or PSK as a key to identify the cached information corresponding to the original session. Whereas the server may use the decoded content of the ticket or PSK to achieve the goal of remaining stateless. Aside: The latter part might be obvious since shifting the burden of storing the server-side state from the server to the client is the whole point of ticket/PSK schemes. However it's not obvious to me that the additional goal introduced by this RFC of performing a deep revalidation of the authorisation data (resume-time certificate checks, etc.) is shared with the RFC5077 or RFC8446 whose concern appears to be with lightweight bootstrapping of the connection using the original parameters. (Maybe I have missed something?) If that's true then as Alan mentions, perhaps it is worth enumerating the types of information that should be stored in the ticket to facilitate the resume-time authorisation check rather than merely to reestablish the crypto parameters required to perform an abbreviated handshake? > Do you have some concrete suggestion on improving the text? We are happy > to edit or receive pull requests on github: > https://github.com/emu-wg/draft-ietf-emu-eap-tls13 > > Would this be better: > > > The second method for retrieving cached information is > > via [RFC5077] or [RFC8446], where the TLS server avoids storing > > information locally and instead encapsulates the information into a > > ticket or PSK and sends it to the client. Note that the client stil= l > > needs to cache the information locally. The client can subsequently > > do resumption using the obtained ticket. IMO, that's better. How about: > The second method for retrieving cached information is via [RFC5077] or [= RFC8446], where the TLS server avoids storing information locally and inste= ad encapsulates the information into a ticket or PSK, which it encrypts usi= ng a key that only the server knows, and sends to the client. Note that the= client still needs to cache the original handshake information locally and= will use the opaque ticket or PSK to lookup this information during resump= tion, however the server is able to decrypt the ticket or PSK to obtain the= original handshake information. I think this emphasises that the ticket is opaque to the client yet clear to the server, and that it is the blob itself that is used by the client to lookup the information in its cache. This gives the correct intuition for why the scheme works without needing to understand the detail in the aforementioned RFCs to read between the lines. Terry > On 8/10/20 6:58 PM, Terry Burton wrote: > > Hi, > > > > Reading "Using EAP-TLS with TLS 1.3" I find the text potentially > > misleading when it comes to resumption within TLS 1.3, specifically > > for the case where the peer wishes to re-validate the certificate > > originally provided by the server during the initial handshake using > > only its locally cached data and without redoing the handshake, e.g. > > to determine that the original certificate hasn't expired or been > > revoked. > > > > > > 5.7. Resumption > > ... > > To perform resumption in a secure way, the EAP-TLS peer and > > EAP-TLS server need to be able to securely retrieve authorization > > information such as certificate chains from the initial full > > handshake. > > ... > > There are two ways to retrieve the cached information from the > > original full handshake. > > ... > > The second method for retrieving cached information is > > via [RFC5077] or [RFC8446], where the TLS server encapsulates the > > information into a ticket and sends it to the client. The client c= an > > subsequently do resumption using the obtained ticket. Note that th= e > > client still needs to cache the information locally. > > > > > > In TLS 1.3, the PSK ticket is defined as being encrypted using a key > > that only the server knows. Even without encryption, the format for > > the ticket is opaque to the client with only a suggested format > > presented in RFC 8446. > > > > How is the original handshake data determined? A casual reading of the > > text seems to imply that the client performs some verification using > > the encapsulated information within the ticket. > > > > However I believe that the intent is to use the full PSK blob, or some > > digest thereof, as a key to lookup the corresponding cached handshake > > data. > > > > Perhaps this could be made clearer? > > > > > > Thanks, > > > > Terry From nobody Tue Aug 11 07:58: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 E32053A10F1 for ; Tue, 11 Aug 2020 07:58:37 -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 n-A5Fkmb_JVV for ; Tue, 11 Aug 2020 07:58:35 -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 A852F3A1178 for ; Tue, 11 Aug 2020 07:58:02 -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 14BEB92; Tue, 11 Aug 2020 14:57:59 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: Date: Tue, 11 Aug 2020 10:57:58 -0400 Cc: Mohit Sethi M , "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Terry Burton X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption 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, 11 Aug 2020 14:58:38 -0000 On Aug 11, 2020, at 8:40 AM, Terry Burton = wrote: >=20 > On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M = wrote: >>=20 >> Section 5.7 "Resumption" says: >>=20 >>> When resumption occurs, it is based on cached information at the TLS >>> layer. To perform resumption in a secure way, the EAP-TLS peer = and >>> EAP-TLS server need to be able to securely retrieve authorization >>> information such as certificate chains from the initial full >>> handshake. Is there more information which needs to be cached? If so, are there = examples? >> In the second mechanism, the server can avoid storing information. It >> instead puts that information in the PSK or the session ticket and = sends >> it to the client. However, the client still needs to store = information >> from the original handshake. This is why there is the sentence "Note >> that the client still needs to cache the information locally.". The >> client can't obviously read the contents of the ticket or the PSK. >=20 > I agree with the sentiment, but the current text seems a bit > "Sherlock": Once you've eliminated all other possibilities whatever > remains must be the case. I think it should directly state that the > client uses the opaque ticket or PSK as a key to identify the cached > information corresponding to the original session. Whereas the server > may use the decoded content of the ticket or PSK to achieve the goal > of remaining stateless. I agree. It's a minor point, but clarifying it is helpful. > Aside: The latter part might be obvious since shifting the burden of > storing the server-side state from the server to the client is the > whole point of ticket/PSK schemes. However it's not obvious to me that > the additional goal introduced by this RFC of performing a deep > revalidation of the authorisation data (resume-time certificate > checks, etc.) is shared with the RFC5077 or RFC8446 whose concern > appears to be with lightweight bootstrapping of the connection using > the original parameters. (Maybe I have missed something?) If that's > true then as Alan mentions, perhaps it is worth enumerating the types > of information that should be stored in the ticket to facilitate the > resume-time authorisation check rather than merely to reestablish the > crypto parameters required to perform an abbreviated handshake? Just re-checking 5.7, it should also have a discussion on expiring = the cached data. How long should it be cached for on each side? I'd = like to see some discussion. My $0.02 is that the cached data MUST expire no later than the expiry = time of any certificate involved. i.e. client, server, or any cert in = the CA chain. Perhaps it would also be good to suggest that expiry times SHOULD be = no longer than 48h? I also note: The above requirements also apply if the EAP server expects some system to perform accounting for the session. Since accounting must be tied to an authenticated identity, and resumption does not supply such an identity, accounting is impossible without access to cached data. It would be good to add a sentence such as: Therefore systems which expect to perform accounting for the = session SHOULD cache an identifier which can be used in subsequent = accounting. In RADIUS, this would involve sending back User-Name or CUI in the = Access-Accept. Alan DeKok. From nobody Tue Aug 11 23:17:19 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 81D823A1079 for ; Tue, 11 Aug 2020 23:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 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, NICE_REPLY_A=-0.949, 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 mfwXCJUBxtgD for ; Tue, 11 Aug 2020 23:17:15 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2051.outbound.protection.outlook.com [40.107.22.51]) (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 06A883A1078 for ; Tue, 11 Aug 2020 23:17:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A4iRslsZ4BH8YvV7unzEs6m1KExyi+wneXHdAPDQraTa8slXAi7fPvKSPTZLkeSofkL/8UvLJfcbTuj330b1xVKIXRVDuuxpS/sZfqReZr9LPrgbzbjHM8F+kjEbDtqKovWHkmD+ibw4sLodA9IeFsJow9Yv1TWJRFwvv1olfcmQx9SO+/BlRUvZzz2AH/HfTtcomf8uo5mn9003zF/WU6SYt7hk7xYmxKLOz7LALtxZ12d/wqxeBBTXqOI4YS7AIFZPV98HaCLmi79bxsY8aM3ekpe6bqVafgwYUR9ja/P8aduv/+Bcbo2C8OdXImrdw6Qp7Z7/vcKmkLOib4NcEw== 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=x9divU5WM3vjBGHi4NYcYpJ+n73KbyCpYPLwId89fF0=; b=DXJs/FVs1GDsxr/KHIqVTLGxHTb45ou1CvjOQulNMKeJ++m5TGUzvyxL50sVRPi/QOgk/eyRlhGrNCO2DsG+KY/UzQXx2B/ylYtHvkpTzUfMgYpZGGj7JkLB3sb2AiWBoVzehZ2HH3UQ7TViAAt8sbLdqIXzI1bYrYtY7dCcG5xl58uGLWt2sMcZbL/eo2J1GmIY5z0K9Yh9ErbXxuf8vacP0/rB5IF31dl0QRsxR3Ni6IzrJoayFBvoGjV8zEeWA2t/euxqyAwD1lbjFodW5lLvtdvqxZ1UAydZUQ35jPjrAdCAXx8MYhO0TjAnWanKwWG8M0c9p0+nIWPK2t1rHg== 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=x9divU5WM3vjBGHi4NYcYpJ+n73KbyCpYPLwId89fF0=; b=o/ZThmbJfbZcqxycpGHNJONxoyQeve9ZIqnRg+yXTomnN7b9WFTsyEY1kaFzTI6Cw8ph9zOvzVF58C0xmLbSH2bABe0ZxdIT/rCkZKzaNI6ekfLhZ/eiXOsGVawTEnqPvICNHyOWjzqNdMltFSx+3VXHqpWawau7fHysn+suf8Q= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR07MB3147.eurprd07.prod.outlook.com (2603:10a6:7:39::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.11; Wed, 12 Aug 2020 06:17:12 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3%6]) with mapi id 15.20.3283.015; Wed, 12 Aug 2020 06:17:12 +0000 From: Mohit Sethi M To: Alan DeKok , Terry Burton CC: Mohit Sethi M , "emu@ietf.org" Thread-Topic: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption Thread-Index: AQHWb7bxqeMRt4tiSkeZ2uLPasx49aky2aGAgAAmigCAAQDUgA== Date: Wed, 12 Aug 2020 06:17:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:190:1057:9ca3:9842:291d:a58f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca61be09-4dc5-457c-fe00-08d83e8759d9 x-ms-traffictypediagnostic: HE1PR07MB3147: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lESRDvI94/wRKrTyulRwDblkI6Hise8iC174b0IdEhfx0nElIxYd0+SC7mv6XtHbR4ul4gxl7HB9LjJLxERjzXFmCP8kJ6cfd868PuEt/qgeCkWHiIcWDRt9TX5AYkZYcRU3G7a9B2vTiPlgyHMni8v3FkVNbYUZi0nWwYfHjy6KXgJJtDxkW4hFPK+jbXVGU6mzWQnJ7FYNdAKV5cGiMuhHWkdyyX0nFAbRms/LMhHRqIclKbQn4aPvOvZfAbwli2459q/vy4yrlwyZVYXHmuuec1bF6gKAhaMiM183qvzHHpWrnUvgC2RGi326iBY/0NIv/qjxFsfLmYrMtBAh/fCiQeCvsBWsGB2Z0J7yN7854JrKd8eIZKFd9kQeQ4j7/Ux6lMgPRpjWXRAFK/hYG9pfHCNkpwdMT0Ci7XDCjLIZZw5NYgaS3YmPcEw5Fvi5PN0JQkiHC5o8JRXZ0JtPPg== 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; SFS:(4636009)(346002)(39860400002)(376002)(396003)(366004)(136003)(54906003)(4326008)(31696002)(76116006)(31686004)(86362001)(2906002)(6486002)(8676002)(2616005)(66946007)(6506007)(53546011)(36756003)(8936002)(5660300002)(83380400001)(316002)(6512007)(110136005)(966005)(83080400001)(186003)(64756008)(66476007)(66446008)(66556008)(71200400001)(478600001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: YuLHuJELfwUO5R4cdZ/F3MBpI17FuVy0k6fmKihr3K/E5ozf8yrhqJTfEunQRzCkEnra+/7KqUhL3n9bwR4I1AgsqWigjLG1MRohJ5S274b1Le34H5cqXSCBHA4/zNT7tIOUF45Ti/UcHxm/lItyoW+xSrS9Qm90J2IAVlIErUutoMeglDRM8WmkcD0DUXjqtF0qnpqs3buLFCBWIJ5BqglJj6z9VZlXWbWyIfvcNeZt4UPadahCw4u9gpVlxB7RSHr79bvlgsCymtfWm3cbK1tOHPGBkiH9s8bHFI1mC3/cSHa5cttkILjS0W3u7CZgDfqNyH0HOJnk02duwNprvCKNoUNL3Rc3fBodf49Mgxka/yhSjX+K30j2mzlGpOfYaT3OsjmXw0b4nEglu2pXXNyGsxnYeAXraBceKhvH/oCEHbIMHvF3PvRQTiEP7l8J4ZckO2Ok6UCf3tNWnyNaXpl1OZztKPFf2bKD6/52m13nR6vcsoNQtDclXF4/Vxs2p3X9FQMUdnkbxoNcfpzvpNuvNx/adRdOVrG8jZd6jGZ8FS5iuIDQXeiTMDxTIWKMDvHf0bUR1/SPE4O8Y42rbqjrDOOtw+q8wRTQaLTySD/oFIPHg+xgKzT01vmR7eEM8oHXhA2fmkDng+RGstug49+AoaaLfa6VCaPGKI/gbVwIUbLQlzgFixBB2Ry+WTDQNNdoaun1JYjKYYvAFEMZvg== Content-Type: text/plain; charset="utf-8" Content-ID: <9309EB523CB0904FAB4F063E53D3337E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3386.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca61be09-4dc5-457c-fe00-08d83e8759d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 06:17:12.0911 (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: 9i3LIqSjXwWYdGYLDCcR5wcQRvbErn7MmLi3w/nCAC6aI+ryAi4dSvE+n5aifD17lvNvHbZbDR+tUFOItieYG1xGBYPpNgQxYxwx0Nu9xRU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3147 Archived-At: Subject: Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption 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, 12 Aug 2020 06:17:18 -0000 SGkgQWxhbiBhbmQgVGVycnksDQoNClRoYW5rIHlvdSBhZ2FpbiBmb3IgdGhlIGZlZWRiYWNrLiBJ IGhhdmUgdXBkYXRlZCB0aGUgdGV4dCBpbiBnaXRodWI6DQpodHRwczovL2VtdS13Zy5naXRodWIu aW8vZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzL2RyYWZ0LWlldGYtZW11LWVhcC10bHMxMy5odG1s I3JmYy5zZWN0aW9uLjUuNw0KDQpIZXJlIGlzIHRoZSBkaWZmIGZvciB5b3VyIGNvbnZlbmllbmNl Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMudHh0JnVybDI9aHR0cHM6Ly9lbXUtd2cu Z2l0aHViLmlvL2RyYWZ0LWlldGYtZW11LWVhcC10bHMxMy9kcmFmdC1pZXRmLWVtdS1lYXAtdGxz MTMudHh0DQoNCldlJ2xsIHN1Ym1pdCB0aGUgbmV3IHZlcnNpb24gb25jZSB3ZSBoYXZlIHN1ZmZp Y2llbnQgaW1wbGVtZW50YXRpb24gDQpleHBlcmllbmNlIHdpdGggdGhlIHVzZSBvZiB0aGUgY2xv c2Vfbm90aWZ5IGFsZXJ0Lg0KDQotLU1vaGl0DQoNCk9uIDgvMTEvMjAgNTo1NyBQTSwgQWxhbiBE ZUtvayB3cm90ZToNCj4gT24gQXVnIDExLCAyMDIwLCBhdCA4OjQwIEFNLCBUZXJyeSBCdXJ0b24g PHRlcnJ5LmJ1cnRvbkBnbWFpbC5jb20+IHdyb3RlOg0KPj4gT24gVHVlLCAxMSBBdWcgMjAyMCBh dCAwOToxMSwgTW9oaXQgU2V0aGkgTSA8bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+IHdyb3Rl Og0KPj4+IFNlY3Rpb24gNS43ICAiUmVzdW1wdGlvbiIgc2F5czoNCj4+Pg0KPj4+PiBXaGVuIHJl c3VtcHRpb24gb2NjdXJzLCBpdCBpcyBiYXNlZCBvbiBjYWNoZWQgaW5mb3JtYXRpb24gYXQgdGhl IFRMUw0KPj4+PiAgICBsYXllci4gIFRvIHBlcmZvcm0gcmVzdW1wdGlvbiBpbiBhIHNlY3VyZSB3 YXksIHRoZSBFQVAtVExTIHBlZXIgYW5kDQo+Pj4+ICAgIEVBUC1UTFMgc2VydmVyIG5lZWQgdG8g YmUgYWJsZSB0byBzZWN1cmVseSByZXRyaWV2ZSBhdXRob3JpemF0aW9uDQo+Pj4+ICAgIGluZm9y bWF0aW9uIHN1Y2ggYXMgY2VydGlmaWNhdGUgY2hhaW5zIGZyb20gdGhlIGluaXRpYWwgZnVsbA0K Pj4+PiAgICBoYW5kc2hha2UuDQo+ICAgIElzIHRoZXJlIG1vcmUgaW5mb3JtYXRpb24gd2hpY2gg bmVlZHMgdG8gYmUgY2FjaGVkPyAgSWYgc28sIGFyZSB0aGVyZSBleGFtcGxlcz8NCj4NCj4+PiBJ biB0aGUgc2Vjb25kIG1lY2hhbmlzbSwgdGhlIHNlcnZlciBjYW4gYXZvaWQgc3RvcmluZyBpbmZv cm1hdGlvbi4gSXQNCj4+PiBpbnN0ZWFkIHB1dHMgdGhhdCBpbmZvcm1hdGlvbiBpbiB0aGUgUFNL IG9yIHRoZSBzZXNzaW9uIHRpY2tldCBhbmQgc2VuZHMNCj4+PiBpdCB0byB0aGUgY2xpZW50LiBI b3dldmVyLCB0aGUgY2xpZW50IHN0aWxsIG5lZWRzIHRvIHN0b3JlIGluZm9ybWF0aW9uDQo+Pj4g ZnJvbSB0aGUgb3JpZ2luYWwgaGFuZHNoYWtlLiBUaGlzIGlzIHdoeSB0aGVyZSBpcyB0aGUgc2Vu dGVuY2UgIk5vdGUNCj4+PiB0aGF0IHRoZSBjbGllbnQgc3RpbGwgbmVlZHMgdG8gY2FjaGUgdGhl IGluZm9ybWF0aW9uIGxvY2FsbHkuIi4gVGhlDQo+Pj4gY2xpZW50IGNhbid0IG9idmlvdXNseSBy ZWFkIHRoZSBjb250ZW50cyBvZiB0aGUgdGlja2V0IG9yIHRoZSBQU0suDQo+PiBJIGFncmVlIHdp dGggdGhlIHNlbnRpbWVudCwgYnV0IHRoZSBjdXJyZW50IHRleHQgc2VlbXMgYSBiaXQNCj4+ICJT aGVybG9jayI6IE9uY2UgeW91J3ZlIGVsaW1pbmF0ZWQgYWxsIG90aGVyIHBvc3NpYmlsaXRpZXMg d2hhdGV2ZXINCj4+IHJlbWFpbnMgbXVzdCBiZSB0aGUgY2FzZS4gSSB0aGluayBpdCBzaG91bGQg ZGlyZWN0bHkgc3RhdGUgdGhhdCB0aGUNCj4+IGNsaWVudCB1c2VzIHRoZSBvcGFxdWUgdGlja2V0 IG9yIFBTSyBhcyBhIGtleSB0byBpZGVudGlmeSB0aGUgY2FjaGVkDQo+PiBpbmZvcm1hdGlvbiBj b3JyZXNwb25kaW5nIHRvIHRoZSBvcmlnaW5hbCBzZXNzaW9uLiBXaGVyZWFzIHRoZSBzZXJ2ZXIN Cj4+IG1heSB1c2UgdGhlIGRlY29kZWQgY29udGVudCBvZiB0aGUgdGlja2V0IG9yIFBTSyB0byBh Y2hpZXZlIHRoZSBnb2FsDQo+PiBvZiByZW1haW5pbmcgc3RhdGVsZXNzLg0KPiAgICBJIGFncmVl LiAgSXQncyBhIG1pbm9yIHBvaW50LCBidXQgY2xhcmlmeWluZyBpdCBpcyBoZWxwZnVsLg0KPg0K Pj4gQXNpZGU6IFRoZSBsYXR0ZXIgcGFydCBtaWdodCBiZSBvYnZpb3VzIHNpbmNlIHNoaWZ0aW5n IHRoZSBidXJkZW4gb2YNCj4+IHN0b3JpbmcgdGhlIHNlcnZlci1zaWRlIHN0YXRlIGZyb20gdGhl IHNlcnZlciB0byB0aGUgY2xpZW50IGlzIHRoZQ0KPj4gd2hvbGUgcG9pbnQgb2YgdGlja2V0L1BT SyBzY2hlbWVzLiBIb3dldmVyIGl0J3Mgbm90IG9idmlvdXMgdG8gbWUgdGhhdA0KPj4gdGhlIGFk ZGl0aW9uYWwgZ29hbCBpbnRyb2R1Y2VkIGJ5IHRoaXMgUkZDIG9mIHBlcmZvcm1pbmcgYSBkZWVw DQo+PiByZXZhbGlkYXRpb24gb2YgdGhlIGF1dGhvcmlzYXRpb24gZGF0YSAocmVzdW1lLXRpbWUg Y2VydGlmaWNhdGUNCj4+IGNoZWNrcywgZXRjLikgaXMgc2hhcmVkIHdpdGggdGhlIFJGQzUwNzcg b3IgUkZDODQ0NiB3aG9zZSBjb25jZXJuDQo+PiBhcHBlYXJzIHRvIGJlIHdpdGggbGlnaHR3ZWln aHQgYm9vdHN0cmFwcGluZyBvZiB0aGUgY29ubmVjdGlvbiB1c2luZw0KPj4gdGhlIG9yaWdpbmFs IHBhcmFtZXRlcnMuIChNYXliZSBJIGhhdmUgbWlzc2VkIHNvbWV0aGluZz8pIElmIHRoYXQncw0K Pj4gdHJ1ZSB0aGVuIGFzIEFsYW4gbWVudGlvbnMsIHBlcmhhcHMgaXQgaXMgd29ydGggZW51bWVy YXRpbmcgdGhlIHR5cGVzDQo+PiBvZiBpbmZvcm1hdGlvbiB0aGF0IHNob3VsZCBiZSBzdG9yZWQg aW4gdGhlIHRpY2tldCB0byBmYWNpbGl0YXRlIHRoZQ0KPj4gcmVzdW1lLXRpbWUgYXV0aG9yaXNh dGlvbiBjaGVjayByYXRoZXIgdGhhbiBtZXJlbHkgdG8gcmVlc3RhYmxpc2ggdGhlDQo+PiBjcnlw dG8gcGFyYW1ldGVycyByZXF1aXJlZCB0byBwZXJmb3JtIGFuIGFiYnJldmlhdGVkIGhhbmRzaGFr ZT8NCj4gICAgIEp1c3QgcmUtY2hlY2tpbmcgNS43LCBpdCBzaG91bGQgYWxzbyBoYXZlIGEgZGlz Y3Vzc2lvbiBvbiBleHBpcmluZyB0aGUgY2FjaGVkIGRhdGEuICBIb3cgbG9uZyBzaG91bGQgaXQg YmUgY2FjaGVkIGZvciBvbiBlYWNoIHNpZGU/ICBJJ2QgbGlrZSB0byBzZWUgc29tZSBkaXNjdXNz aW9uLg0KPg0KPiAgICBNeSAkMC4wMiBpcyB0aGF0IHRoZSBjYWNoZWQgZGF0YSBNVVNUIGV4cGly ZSBubyBsYXRlciB0aGFuIHRoZSBleHBpcnkgdGltZSBvZiBhbnkgY2VydGlmaWNhdGUgaW52b2x2 ZWQuICBpLmUuIGNsaWVudCwgc2VydmVyLCBvciBhbnkgY2VydCBpbiB0aGUgQ0EgY2hhaW4uDQo+ DQo+ICAgIFBlcmhhcHMgaXQgd291bGQgYWxzbyBiZSBnb29kIHRvIHN1Z2dlc3QgdGhhdCBleHBp cnkgdGltZXMgU0hPVUxEIGJlIG5vIGxvbmdlciB0aGFuIDQ4aD8NCj4NCj4gICAgSSBhbHNvIG5v dGU6DQo+DQo+ICAgICBUaGUgYWJvdmUgcmVxdWlyZW1lbnRzIGFsc28gYXBwbHkgaWYgdGhlIEVB UCBzZXJ2ZXIgZXhwZWN0cyBzb21lDQo+ICAgICBzeXN0ZW0gdG8gcGVyZm9ybSBhY2NvdW50aW5n IGZvciB0aGUgc2Vzc2lvbi4gIFNpbmNlIGFjY291bnRpbmcgbXVzdA0KPiAgICAgYmUgdGllZCB0 byBhbiBhdXRoZW50aWNhdGVkIGlkZW50aXR5LCBhbmQgcmVzdW1wdGlvbiBkb2VzIG5vdCBzdXBw bHkNCj4gICAgIHN1Y2ggYW4gaWRlbnRpdHksIGFjY291bnRpbmcgaXMgaW1wb3NzaWJsZSB3aXRo b3V0IGFjY2VzcyB0byBjYWNoZWQNCj4gICAgIGRhdGEuDQo+DQo+ICAgIEl0IHdvdWxkIGJlIGdv b2QgdG8gYWRkIGEgc2VudGVuY2Ugc3VjaCBhczoNCj4NCj4gCVRoZXJlZm9yZSBzeXN0ZW1zIHdo aWNoIGV4cGVjdCB0byBwZXJmb3JtIGFjY291bnRpbmcgZm9yIHRoZSBzZXNzaW9uIFNIT1VMRCBj YWNoZSBhbiBpZGVudGlmaWVyIHdoaWNoIGNhbiBiZSB1c2VkIGluIHN1YnNlcXVlbnQgYWNjb3Vu dGluZy4NCj4NCj4gICAgSW4gUkFESVVTLCB0aGlzIHdvdWxkIGludm9sdmUgc2VuZGluZyBiYWNr IFVzZXItTmFtZSBvciBDVUkgaW4gdGhlIEFjY2Vzcy1BY2NlcHQuDQo+DQo+ICAgIEFsYW4gRGVL b2suDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IEVtdSBtYWlsaW5nIGxpc3QNCj4gRW11QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZW11DQo= From nobody Wed Aug 12 06:16: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 2D0183A12D2 for ; Wed, 12 Aug 2020 06:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_FROM=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 0h8CYR9r5Yh1 for ; Wed, 12 Aug 2020 06:16:06 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 AB6223A12B3 for ; Wed, 12 Aug 2020 06:16:06 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id o184so1067620vsc.0 for ; Wed, 12 Aug 2020 06:16: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:reply-to:from:date:message-id :subject:to:cc; bh=dZMpLAhO4aXdLofSZ2YEO9g5EaDxquHHH/z7koStm/c=; b=Kz2HkMShzhCYvzb7uNI74nHdFVODBCTgIF/zvsIQ0QHaL02q0CfrLp5qVp6ju/Qlnd EOKgfQjzNzouzp9okWqHTE3KfwHDwrs52pUc0YDOpBrC2M/P2f/LaLe8dxSnhTGrB1OU x5FidvSUr8pWmSEr3iO02GJGJH91aabx710W0ZE2C6xm+0MwuNNFE+vvoP1i9Fti5cqj adHXTr6OR4JsbHrmKRkI9Ahvd4LjifKzRqgnwyNXskX7s4GnmBhI2+awfJAfxBorEFWG uostS+UT3IbXeyoTNGjmaRHWNtOJ4Zf4P86hRC+7batORlK9SP2LdaRw6udItknfdZhq GgEA== 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:reply-to :from:date:message-id:subject:to:cc; bh=dZMpLAhO4aXdLofSZ2YEO9g5EaDxquHHH/z7koStm/c=; b=loYhe/5lVsCe8uMAacJzQjiJSsUConOh8YABjTEu1kPCvY6PIZaYlHk8rvmvxdi97G +dmhvk+Q5+xthrpY8PCQTXBMTf1nvAJ+3lBP824DZ7bYkMo/muoafX0OdTmdFchDoYVc ZlmLEyzhsrn03A7ebKfov5ZFQ3W6gSjmdZVfh7C3U0Eflnjr7fUUKlIvH79pdK+N8IL4 85YpVYqmmYSppsMK4WpFQF7C4piUNCr0mdw0vEC0zTMDQ4vxPgNwwf3Xn5JdMXnZ0Nd6 zk3aWyctcJ+51IrJoZPoww8V8LNIEbgbtFwrlt9tj9kh6X3vGYEqORxaCm/uecwcgt0P jmUA== X-Gm-Message-State: AOAM532LaO1McXJCrlgMbcwVfau8VCOahd91KUVs4GGULTtbr6ykIZo2 ghK5P5w23cKaI1qIRCvhlguAwo6HnzCaJxhqgGAcDHRK X-Google-Smtp-Source: ABdhPJxS2jj2SgigQtZv1nF4coJcyzlRukAROPPj5b61B2jkLmqFB5jP3VxoOuLH+MY9Inm6v/DqbiY+YE5U4NWrS0E= X-Received: by 2002:a05:6102:3025:: with SMTP id v5mr27282757vsa.194.1597238165566; Wed, 12 Aug 2020 06:16:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: tez@terryburton.co.uk From: Terry Burton Date: Wed, 12 Aug 2020 14:15:29 +0100 Message-ID: To: Mohit Sethi M Cc: Alan DeKok , Mohit Sethi M , "emu@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption 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, 12 Aug 2020 13:16:15 -0000 On Wed, 12 Aug 2020 at 07:17, Mohit Sethi M wrote: > Thank you again for the feedback. I have updated the text in github: > https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.html#rfc.section.5.7 > > Here is the diff for your convenience: > https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt&url2=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt Thanks Mohit. I believe that update successfully addresses the issues that I raised. From nobody Wed Aug 19 17:39:49 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 BD7693A0FC3 for ; Wed, 19 Aug 2020 17:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HqekN_XVI_g for ; Wed, 19 Aug 2020 17:39:46 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 48ABD3A0FC2 for ; Wed, 19 Aug 2020 17:39:46 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id s29so83469uae.1 for ; Wed, 19 Aug 2020 17:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=NJddlNE2e0eMoUTlK8GQ/smwVLPkWws62uztJ4r2V8E=; b=Vuug4yI2sq5BDDSCK6QQoSkGnZnePgcM2Gvta8cNwE24g20pkfDy+rnRczmir+UKuB vDlaIEn1Vm9pip+8Rzq80WZXcEq9JCf+jkKLbNM7Av1FJfed2Zn/Ait21FHl0WOUx7yl Fa0XWqwUvh7J11yey+PuqiFk9cChQx5QnviCM+ttV2bSmG9xrSI5uiHAp5sdFyguS92h j9qXbpOx2xUjCTtTTLOLJ6JkcsfoVI3OwbdrFOe4JqkCmCwbVhZ3qXqJwNd2aq7Wyw/1 1595PW9EeAUuILP7Wzn+sMmW9kNZqT9jz5hJ+psrmrDYbL8oRLfDoY/1hHf6rt/mVzb1 I28w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=NJddlNE2e0eMoUTlK8GQ/smwVLPkWws62uztJ4r2V8E=; b=HiTS4sgHMEpeM0fFAO5AHxwUQms7UX1uC99ZWjw5sYbjbi7irK2GJAADwKkpznar93 VrgCSi86lYrRNQLe0RUK+MkU8AyIBBLSukVFaS0t5AFNJ4QcYdIwswp33G/AN0orklhx LzVYCj3ncoHWmgvJivtGad1SiBwPOKmkopNZbrcxJm7ne8gtp5tFOciE7oAumS3P1tQP mNRExNjPYF67JEkXqcIaTBEcn8AaEsY/NQOvInkTwBF+JxMSDOGBDXIiGo8X3Q+lOO8/ 0HdliutQJJWLhoSn3ln5NXbMB+Y8yU+5PplmFKTDiwZslavtAVgLaWaGBUlY79z/T8ax MCIA== X-Gm-Message-State: AOAM530tJA6/3mLYZPk37v8aJ11fDL+xu3TR4YFbiPIUmFgYvQjDM7Mm MuGYJV08xnF7dILgwH9W6d4gDfUyxgZrKccyvOtv+LCdKd2A7w== X-Google-Smtp-Source: ABdhPJyEzTQHKwoW7oOx7gjtSuPyUJqGecGg5OllU/ntJcVE8179kt0e7dbrZuLfvu9wtA8R6Ps0Tx8/oxBD4RzelBg= X-Received: by 2002:ab0:6585:: with SMTP id v5mr216637uam.73.1597883984812; Wed, 19 Aug 2020 17:39:44 -0700 (PDT) MIME-Version: 1.0 Reply-To: tez@terryburton.co.uk From: Terry Burton Date: Thu, 20 Aug 2020 01:39:08 +0100 Message-ID: To: emu@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 20 Aug 2020 00:39:48 -0000 Hi, I'm unable to find the authoritative source that state exactly how the following conversation continues (TL;DR; the peer NAKs the original method and the AAA doesn't support any of the peer's proposals): 1. NAS --> Peer : EAP-Request / Identity 2. Peer --> NAS : EAP-Response / Identity ( ID ) 3. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / Identity ( ID ) 4. AAA --> NAS: RADIUS Access-Challenge / EAP-Message / EAP-Request / Method Foo 5. NAS --> Peer: EAP-Request / Method Foo 6. Peer --> NAK: EAP-Response / EAP-Type=NAK (Methods [Bar]) 7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / NAK ( Methods [ Bar ] ) (* Let's assume that the AAA does not support Method Bar so we have derived that there are no overlapping methods.) 8. AAA: Now what? I've reviewed RFC 3748 (EAP) and RFC 3579 (RADIUS Support For EAP) and neither seems to be explicit about what the AAA should do in response to a NAK in the event of no overlapping methods. In practise: * FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure. * hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message / EAP-Failure. * A commercial RADIUS server implementation sends nothing. It seems right to indicate an EAP-Failure to the peer in the case of no overlapping methods (as well as to terminate the NAS's outstanding RADIUS Access-Request with an Access-Reject), as is the case for a number of other failure conditions, e.g. authentication failure *within* an EAP method (Appendix A by way of example), invalid packets leading to a fatal error within an EAP method (section 2.2). RFC 3748 section 4.2 on Success and Failure introduces these messages within the context of finalising an ongoing EAP method: The Success packet is sent by the authenticator to the peer after completion of an EAP authentication method (Type 4 or greater) to indicate that the peer has authenticated successfully to the authenticator. The authenticator MUST transmit an EAP packet with the Code field set to 3 (Success). If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests), then after unsuccessful completion of the EAP method in progress, the implementation MUST transmit an EAP packet with the Code field set to 4 (Failure). Perhaps one can argue that a NAK is an unacceptable response to an ongoing method and therefore the method is unsuccessfully completed so a Failure should be generated? That's not entirely clear, if that is the case. RFC 3748 section 5.3.1 throws in some more doubt, having the following text that deals explicitly with the peer sending a NAK containing "no desired alternative" method: Type zero (0) is used to indicate that the sender has no viable alternatives, and therefore the authenticator SHOULD NOT send another Request after receiving a Nak Response containing a zero value. That's specific to one case for which a strict reading would indicate that the EAP server should remain quiet and consider the EAP conversation to be complete. It's tempting to think that the same response (i,e. no response!) should apply more broadly as none of the AAA implementations I've tested actually differentiate between a NAK with no desired alternative method vs a NAK with an incompatible list of alternative methods. (A subtle difference might be relevant: In the case of NAK / method = [] the peer knows that the EAP conversion can go no further, whereas in the case that it sends a list of methods that the AAA happens to not support it does not know this unless it is subsequently told.) If I've not missed something then this looks an omission (or lack of clarity) and the intended AAA response to no overlapping methods (and indeed "no desired alternative") should be decided and codified. Thanks, Terry From nobody Wed Aug 19 18:43:28 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 83E123A1217 for ; Wed, 19 Aug 2020 18:43:18 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFuCQ8GVh-hN for ; Wed, 19 Aug 2020 18:43:16 -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 0F1223A10C7 for ; Wed, 19 Aug 2020 18:42:56 -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 5992B291; Thu, 20 Aug 2020 01:42:54 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: Date: Wed, 19 Aug 2020 21:42:52 -0400 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4DC6CA39-0DE1-4AE0-B92C-FC42A9ED4B4F@deployingradius.com> References: To: Terry Burton X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 20 Aug 2020 01:43:21 -0000 On Aug 19, 2020, at 8:39 PM, Terry Burton = wrote: > I'm unable to find the authoritative source that state exactly how the > following conversation continues (TL;DR; the peer NAKs the original > method and the AAA doesn't support any of the peer's proposals): > ... > 8. AAA: Now what? Run around screaming? It's at least not forbidden by the RFCs. :( > I've reviewed RFC 3748 (EAP) and RFC 3579 (RADIUS Support For EAP) and > neither seems to be explicit about what the AAA should do in response > to a NAK in the event of no overlapping methods. Those specs were written 15+ years ago, when the IETF reviews were a = lot less stringent about corner cases. RFC 3579 Section 2.1 says: Where the initial EAP-Request sent by the NAS is for an authentication Type (4 or greater), the peer MAY respond with a Nak indicating that it would prefer another authentication method that is not implemented locally. =20 I suspect the "not" here is wrong, and the text should say: ... it would prefer another authentication method that is implemented = locally. =20 The text finishes with: ... is possible for the RADIUS server to choose an unacceptable method, and for the peer to respond with another Nak. And... what then? There's no suggestion that this NAK exchange should = stop after N rounds, and there's no suggestion for how to handle no = overlapping methods. In short, "here be dragons". > In practise: >=20 > * FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure. We treat "no overlapping methods" as similar to other protocol errors. = For example: * NAK Type-Data with no contents (forbidden by RFC 3748 Section 5.3.1) * NAK Type-Data of 0, which indicates "no proposed alternative". We'll = not that RFC 3748 Section 5.3.1 doesn't say what to do here. * NAK Type-data of 1..3, which is also forbidden by Section 5.3.1 All of these situations result in RADIUS Access-Reject / EAP-Message / = EAP-Failure. One reason for choosing this response is that it is a *positive* = acknowledgement that the EAP session has failed. This behaviour seems = better than dropping the packet on the floor. If that happened, the NAS = would be unable to distinguish "RADIUS server down" from "EAP protocol = failure". RFC 3579 Section 2.2. "Invalid Packets" would seem to be applicable = here: Since EAP method fields (Type, Type-Data) are typically not validated by a NAS operating as a pass-through, despite these checks it is possible for a NAS to forward an invalid EAP packet to or from the RADIUS server. A RADIUS server receiving EAP-Message attribute(s) it does not understand SHOULD make the determination of whether the error is fatal or non-fatal based on the EAP Type. A RADIUS server determining that a fatal error has occurred MUST send an Access-Reject containing an EAP-Message attribute encapsulating EAP-Failure. I would suggest that protocol failures are "fatal errors" as per this = text, and MUST therefore result in Access-Reject / EAP-Message / = EAP-Failure. At least, where RADIUS is concerned. > * hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message / > EAP-Failure. I haven't delved into hostap's implementation, but I suspect that they = made the same choices we did in FreeRADIUS, for similar reasons. > * A commercial RADIUS server implementation sends nothing. That seems bad. > It seems right to indicate an EAP-Failure to the peer in the case of > no overlapping methods (as well as to terminate the NAS's outstanding > RADIUS Access-Request with an Access-Reject), as is the case for a > number of other failure conditions, e.g. authentication failure > *within* an EAP method (Appendix A by way of example), invalid packets > leading to a fatal error within an EAP method (section 2.2). Yes. I would argue that inability to agree on what to do is a = protocol failure, and should result in an explicit failure signal. > RFC 3748 section 4.2 on Success and Failure introduces these messages > within the context of finalising an ongoing EAP method: >=20 > The Success packet is sent by the authenticator to the peer after > completion of an EAP authentication method (Type 4 or greater) to > indicate that the peer has authenticated successfully to the > authenticator. The authenticator MUST transmit an EAP packet with > the Code field set to 3 (Success). If the authenticator cannot > authenticate the peer (unacceptable Responses to one or more > Requests), then after unsuccessful completion of the EAP method in > progress, the implementation MUST transmit an EAP packet with the > Code field set to 4 (Failure). >=20 > Perhaps one can argue that a NAK is an unacceptable response to an > ongoing method and therefore the method is unsuccessfully completed so > a Failure should be generated? That's not entirely clear, if that is > the case. NAK is a reasonable response to the *first* packet coming from a = server. RFC 3748 Section 2.1 forbids NAKs which occur later in the = authentication sequence: A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an authenticator receiving an unexpected Nak SHOULD discard it and log the event. I would argue that discarding packets is wrong in the context of AAA. = The NAS needs a positive acknowledgement that the EAP session has been = torn down, and that the RADIUS server is still alive. So the correct response would be Access-Reject / EAP-Message / = EAP-Failure > RFC 3748 section 5.3.1 throws in some more doubt, having the following > text that deals explicitly with the peer sending a NAK containing "no > desired alternative" method: >=20 > Type zero (0) is used to indicate that the sender has > no viable alternatives, and therefore the authenticator SHOULD = NOT > send another Request after receiving a Nak Response containing a > zero value. >=20 > That's specific to one case for which a strict reading would indicate > that the EAP server should remain quiet and consider the EAP > conversation to be complete. I would argue that it's OK to send EAP-Failure here. EAP-Failure is = Code 4, whereas Request is Code 1. The above text reads as forbidding *ongoing* EAP conversations after a = failure to negotiate a mutually acceptable method. But sending Success = or Failure would seem to be OK. I would then suggest that the text SHOULD say: Type zero (0) is used to indicate that the sender has no viable alternatives, and therefore the authenticator MUST send a Failure packet after receiving a Nak Response containing a zero value. > It's tempting to think that the same > response (i,e. no response!) should apply more broadly as none of the > AAA implementations I've tested actually differentiate between a NAK > with no desired alternative method vs a NAK with an incompatible list > of alternative methods. (A subtle difference might be relevant: In the > case of NAK / method =3D [] the peer knows that the EAP conversion can > go no further, whereas in the case that it sends a list of methods > that the AAA happens to not support it does not know this unless it is > subsequently told.) I agree. Protocol failures or negotiation failures MUST result in EAP = Failure being sent. > If I've not missed something then this looks an omission (or lack of > clarity) and the intended AAA response to no overlapping methods (and > indeed "no desired alternative") should be decided and codified. Implementations have largely decided on a mutually acceptable set of = behaviour. This works in practice. That point is not to be taken lightly. A different set of behaviours = may cause network instabilities, etc. And a response of "our = implementation is compatible with the RFCs" is not appropriate when that = behaviour is causing problems for others. I would agree with at the minimum technical errata being reported for = RFC 3748 and/or RFC 3579. I'm not sure that updated documents are = required, though. Alan DeKok. From nobody Thu Aug 20 02:00:41 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 90FC03A0A3D for ; Thu, 20 Aug 2020 02:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 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, NICE_REPLY_A=-0.949, 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 fvsvuYO_YCQk for ; Thu, 20 Aug 2020 02:00:39 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2077.outbound.protection.outlook.com [40.107.22.77]) (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 850663A0A3B for ; Thu, 20 Aug 2020 02:00:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lwSMjWAYrm2r/yWmy9cRzjtf3Mxeg5vBQLFyDJdCwZRtEwCFEPB5jafBYqHZfIkM6imkZ1/pjeZM+SBsqrcj4C8vljnrLlCpWCjklnGxobIDXKFAU+sjRaKBSMUi+Y4huDy720jQ4Ug9JC2vrhQZHwE5XYXKy/HnYkFdKsW7O89oS2xchtJEF5pdXW8UFkdw65Roh3AHtKMe9XmPAH/YLZYUFoVSXK/XLWC3LCHxKzMwfr+ELrXKei284yxk2v4qR8DXcqUxl3ehES/GjsDPKr9EcEzBcXg3q91ZjFAxnwRweAXUS703jDxG2dxFb7ZaQOPG7xMjLiM+iMM/V6ctRQ== 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=NSP/DbC4O6+Nz6kzxRqnMsg14LvFQvNd6uE9aE+v1WM=; b=TNfqHYml9SyQxPNdf6inT9GC9u20LSaMXxTM5Tbl38H3SMwdZtn4aPbsEdmuWPSxKakuIJneNUDl4VPpfkTDEWnlrcXfvBRGqRsPrKg2a2hW6qyzsVhk1T84p7H8SKMH0xpMDqS4K+8LCXzN7S8Qb13VE5XMAunxL3WF22tyOhgBmZnGZ2xoGjoa6p86ljqEAui7VJ+L1o/sv6mVO6uATujvX01a0GZJs4cN/B92zJn9o9TS/GvSh53KdrhNmkiowkwObLml6tueWj6CU6JwEcq+d4Q+Uf6ogPjfCdKe4NBNqSlK5oZ5CJyctGf3uDY+5parZ31azA5c3sEjKkyynA== 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=NSP/DbC4O6+Nz6kzxRqnMsg14LvFQvNd6uE9aE+v1WM=; b=XRaoZFn8/Bs2l4/XaTuLmqxoNzi1qb4wy0vutnMQO4LF6NC44hTYqzDjfmslhX9uKbqZ/qrr3zkz8XW/h/ZuWeAYLEZcACWIGkRb1cp6W6jUBp+zGX1OMXeQ+uPcMQtbON5V0vuOpFQthpCWAKnhz3fBU9/XZR+aF9Ph00rpV+s= Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR07MB4362.eurprd07.prod.outlook.com (2603:10a6:7:9a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Thu, 20 Aug 2020 09:00:35 +0000 Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6%5]) with mapi id 15.20.3305.021; Thu, 20 Aug 2020 09:00:35 +0000 From: Mohit Sethi M To: "tez@terryburton.co.uk" , "emu@ietf.org" Thread-Topic: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods Thread-Index: AQHWdtBd6/Chl5vFm0Cl50TEYc0wYQ== Date: Thu, 20 Aug 2020 09:00:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: terryburton.co.uk; dkim=none (message not signed) header.d=none;terryburton.co.uk; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:190:2a7d:eafd:b986:ec2:5e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c6d51c3a-55d2-44f8-18ec-08d844e780a4 x-ms-traffictypediagnostic: HE1PR07MB4362: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fHBQIBLFXCe7+Y/zWkZSk37rWKzV6JPUZWI16wcfZekRbUTLcZdXqpGoBWgOGjPbZPkKZbdEYxBZq1gfsdicvBzQsIAbH3s4pAogqoR0b38vogp3S/5oiJgdPrFCDNlF36BFQI0pRjmhjrq3lfgFxQlqx+7Ut8Iev7voWcSgLr913h5w8qHJm2JiRqZ3Ckz685KjdWZ0/MvqFF0a4Z0svNV2IOwHY3Az/oLD/8+rVNGjN7PkecLOhLiM0UjPPOFH2RtPgNKwJBBF7X5qtaYwXpreixqc3EcXAyYir74zxFJnnip9Fr/O6ejqdxmcC/qx0vIy1+QuKV9VXL/4fk1PM1cumnv7irxKhDzsq+MAuixWP42lefsW7pPSM0G06kZ8z1Z25I3EGqzbKZdVspcn4/M7tezPjO+IEetV1eAuU5RGCfAecTqYjyuAoxoqpED06BfyCbaF7NBYbRA2fVKE/Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(396003)(376002)(136003)(39860400002)(2616005)(316002)(6486002)(186003)(86362001)(6512007)(71200400001)(31686004)(83380400001)(166002)(31696002)(2906002)(66556008)(8936002)(5660300002)(66446008)(64756008)(66476007)(76116006)(66946007)(110136005)(53546011)(478600001)(8676002)(36756003)(966005)(6506007)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WfUeW4KJayN0hqtH+L26EY/Mj4CRkG3zJNrgHYeUhtCVge73tE6KZ9k9LOPbHj2XeGtyO9Ie1mtHV9sq+jUj5OG5HbjHL/1cda4ioL15DMkxSjCacGTaT3oqilxwV33Mxjx3u291DXTMj7liemZXuuS8P4tx5Jw2+/QjBW3WUI13Do6FVuSYP4myfyE167QLPrzR0tkYN7BA3MUzvZckrEgsjo7E/mRn+6kbtrV7T7xQCYh8wTFprOe9z21aMpTVGi3Jo3UK4deTZsO6lrrmA8waTfJrj/+iyV9g9p7rREIONiVg9B6b3RIlfavSRvexOuCrOaaOc4jKwkejn26Eajb9S+6scbAlMIY/rEHebsGjm1OPTYRRFTKtGFSVfmXpSQ3Tptjm7iYflIDZ7JvYYoqJeyHYJOktQO3Xn635HYnAT2iyCL3S7fkgsN74dQZFqMuNhKAoUXEPYOmBJVXTusnTM1ZV212Rr/tnAxqWdCuhtYXzQ3DYX4B/o90WE1Oy0Agne8b8p+lnUuEb4OWs1d/6EDMQzDge/GteEn6Pglp9dO2wZHzUY2tOKkXQ60rtVJQjn3hLdIGkXmTMKf2KH+s++9za5hoM20iImphcoqTX8s91ofSFCTsvhMyzEB6+15yEcJetxDRpd6mkan366sMkpQJGqt/kDpTeRDzQl3CaHEah209mD6uk+Ivg99r0NHN73rfdVtGe6nolI2rU+w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_ce1bd45385e671293b89034785e5231aericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3209.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c6d51c3a-55d2-44f8-18ec-08d844e780a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2020 09:00:35.7308 (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: X8uEZLXU/jvHyV3zcL5e8rFw4gDP4utqbNPJcqUAP81+DiQcXPD87cxPXGQQTgC8KxCZiKzcZXGGMMSGvbY0EdTSJ2iVdMUzaVAYcjG8XGw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4362 Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 20 Aug 2020 09:00:41 -0000 --_000_ce1bd45385e671293b89034785e5231aericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVycnksDQoNCkkgc3VyZWx5IG11c3QgYmUgbWlzc2luZyBzb21ldGhpbmcgaGVyZToNCg0K UGFja2V0IDYgaXMgYW4gRUFQLVJlc3BvbnNlIGZyb20gdGhlIHBlZXIuIFBhY2tldCA3IGNvbnRh aW5zIGFub3RoZXIgRUFQLVJlc3BvbnNlIGluc2lkZSBhIFJBRElVUyBBY2Nlc3MtUmVxdWVzdD8g VGhhdCBkb2Vzbid0IG1ha2Ugc2Vuc2UuIEVBUCBpcyBsb2NrLXN0ZXAgcmVxdWVzdC1yZXNwb25z ZSBwcm90b2NvbC4gVGhlIGNvbnZlcnNhdGlvbiB5b3UgZGVzY3JpYmUgaXMgaW5jb3JyZWN0Lg0K DQpNeSByZWFkaW5nIG9mIFJGQyAzNzQ4IGlzIGNsZWFyIHRoYXQgYWZ0ZXIgcmVjZWl2aW5nIGEg TkFLIGZyb20gdGhlIHBlZXIsIHRoZSBzZXJ2ZXIgc2hvdWxkIHNlbmQgYW5vdGhlciBFQVAtUmVx dWVzdCB3aXRoIGEgZGlmZmVyZW50IEVBUCBtZXRob2QgaWYgaXRzIHBvbGljeSBhbGxvd3Mgb3Ig dGhlbiBzZW5kIGEgZmFpbHVyZS4gVGhlIHNlcnZlciBzaG91bGQgYWxzbyBzZW5kIGEgZmFpbHVy ZSBpZiB0aGUgcGVlciBOQUsgVHlwZS1EYXRhIHdhcyAwIChpbmRpY2F0aW5nIG5vIHByb3Bvc2Vk IGFsdGVybmF0aXZlKS4NCg0KRllJOiBSRkMgNDEzNyBzYXlzOg0KDQogICBvICBTZW5kaW5nIGEg TkFLIHRvIHRoZSBhdXRoZW50aWNhdG9yIGFmdGVyIHRoZSBhdXRoZW50aWNhdG9yIGZpcnN0DQog ICAgICBwcm9wb3NlcyBhbiBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9kIHRvIHRoZSBwZWVyLiAg V2hlbiB0aGUNCiAgICAgIG1ldGhvZFN0YXRlIHZhcmlhYmxlIGhhcyB0aGUgdmFsdWUgUFJPUE9T RUQsIHRoZSBhdXRoZW50aWNhdG9yIGlzDQogICAgICBvYmxpZ2VkIHRvIHByb2Nlc3MgYSBOQUsg dGhhdCBpcyByZWNlaXZlZCBpbiByZXNwb25zZSB0byBpdHMgZmlyc3QNCiAgICAgIHBhY2tldCBv ZiBhbiBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9kLg0KDQpzbyB0aGUgY29tbWVyY2lhbCBSQURJ VVMgc2VydmVyIGlzIGluIHZpb2xhdGlvbiBpZiBpdCBkb2Vzbid0IHJlc3BvbmQgdG8gYSBOQUsg ZnJvbSB0aGUgcGVlciB3aXRoIGVpdGhlciBhbm90aGVyIEVBUC1SZXF1ZXN0IG9yIGZhaWx1cmUu DQoNCi0tTW9oaXQNCg0KDQpPbiA4LzIwLzIwIDM6MzkgQU0sIFRlcnJ5IEJ1cnRvbiB3cm90ZToN Cg0KSGksDQoNCkknbSB1bmFibGUgdG8gZmluZCB0aGUgYXV0aG9yaXRhdGl2ZSBzb3VyY2UgdGhh dCBzdGF0ZSBleGFjdGx5IGhvdyB0aGUNCmZvbGxvd2luZyBjb252ZXJzYXRpb24gY29udGludWVz IChUTDtEUjsgdGhlIHBlZXIgTkFLcyB0aGUgb3JpZ2luYWwNCm1ldGhvZCBhbmQgdGhlIEFBQSBk b2Vzbid0IHN1cHBvcnQgYW55IG9mIHRoZSBwZWVyJ3MgcHJvcG9zYWxzKToNCg0KMS4gTkFTIC0t PiBQZWVyIDogRUFQLVJlcXVlc3QgLyBJZGVudGl0eQ0KMi4gUGVlciAtLT4gTkFTIDogRUFQLVJl c3BvbnNlIC8gSWRlbnRpdHkgKCBJRCApDQozLiBOQVMgLS0+IEFBQTogUkFESVVTIEFjY2Vzcy1S ZXF1ZXN0IC8gRUFQLU1lc3NhZ2UgLyBFQVAtUmVzcG9uc2UgLw0KSWRlbnRpdHkgKCBJRCApDQo0 LiBBQUEgLS0+IE5BUzogIFJBRElVUyBBY2Nlc3MtQ2hhbGxlbmdlIC8gRUFQLU1lc3NhZ2UgLyBF QVAtUmVxdWVzdCAvDQpNZXRob2QgRm9vDQo1LiBOQVMgLS0+IFBlZXI6IEVBUC1SZXF1ZXN0IC8g TWV0aG9kIEZvbw0KNi4gUGVlciAtLT4gTkFLOiBFQVAtUmVzcG9uc2UgLyBFQVAtVHlwZT1OQUsg KE1ldGhvZHMgW0Jhcl0pDQo3LiBOQVMgLS0+IEFBQTogUkFESVVTIEFjY2Vzcy1SZXF1ZXN0IC8g RUFQLU1lc3NhZ2UgLyBFQVAtUmVzcG9uc2UgLw0KTkFLICggTWV0aG9kcyBbIEJhciBdICkNCigq IExldCdzIGFzc3VtZSB0aGF0IHRoZSBBQUEgZG9lcyBub3Qgc3VwcG9ydCBNZXRob2QgQmFyIHNv IHdlIGhhdmUNCmRlcml2ZWQgdGhhdCB0aGVyZSBhcmUgbm8gb3ZlcmxhcHBpbmcgbWV0aG9kcy4p DQo4LiBBQUE6IE5vdyB3aGF0Pw0KDQpJJ3ZlIHJldmlld2VkIFJGQyAzNzQ4IChFQVApIGFuZCBS RkMgMzU3OSAoUkFESVVTIFN1cHBvcnQgRm9yIEVBUCkgYW5kDQpuZWl0aGVyIHNlZW1zIHRvIGJl IGV4cGxpY2l0IGFib3V0IHdoYXQgdGhlIEFBQSBzaG91bGQgZG8gaW4gcmVzcG9uc2UNCnRvIGEg TkFLIGluIHRoZSBldmVudCBvZiBubyBvdmVybGFwcGluZyBtZXRob2RzLg0KDQpJbiBwcmFjdGlz ZToNCg0KKiBGcmVlUkFESVVTIHNlbmRzIFJBRElVUyBBY2Nlc3MtUmVqZWN0IC8gRUFQLU1lc3Nh Z2UgLyBFQVAtRmFpbHVyZS4NCiogaG9zdGFwZCdzIFJBRElVUyBzZXJ2ZXIgc2VuZHMgUkFESVVT IEFjY2Vzcy1SZWplY3QgLyBFQVAtTWVzc2FnZSAvDQpFQVAtRmFpbHVyZS4NCiogQSBjb21tZXJj aWFsIFJBRElVUyBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gc2VuZHMgbm90aGluZy4NCg0KSXQgc2Vl bXMgcmlnaHQgdG8gaW5kaWNhdGUgYW4gRUFQLUZhaWx1cmUgdG8gdGhlIHBlZXIgaW4gdGhlIGNh c2Ugb2YNCm5vIG92ZXJsYXBwaW5nIG1ldGhvZHMgKGFzIHdlbGwgYXMgdG8gdGVybWluYXRlIHRo ZSBOQVMncyBvdXRzdGFuZGluZw0KUkFESVVTIEFjY2Vzcy1SZXF1ZXN0IHdpdGggYW4gQWNjZXNz LVJlamVjdCksIGFzIGlzIHRoZSBjYXNlIGZvciBhDQpudW1iZXIgb2Ygb3RoZXIgZmFpbHVyZSBj b25kaXRpb25zLCBlLmcuIGF1dGhlbnRpY2F0aW9uIGZhaWx1cmUNCip3aXRoaW4qIGFuIEVBUCBt ZXRob2QgKEFwcGVuZGl4IEEgYnkgd2F5IG9mIGV4YW1wbGUpLCBpbnZhbGlkIHBhY2tldHMNCmxl YWRpbmcgdG8gYSBmYXRhbCBlcnJvciB3aXRoaW4gYW4gRUFQIG1ldGhvZCAoc2VjdGlvbiAyLjIp Lg0KDQpSRkMgMzc0OCBzZWN0aW9uIDQuMiBvbiBTdWNjZXNzIGFuZCBGYWlsdXJlIGludHJvZHVj ZXMgdGhlc2UgbWVzc2FnZXMNCndpdGhpbiB0aGUgY29udGV4dCBvZiBmaW5hbGlzaW5nIGFuIG9u Z29pbmcgRUFQIG1ldGhvZDoNCg0KICAgVGhlIFN1Y2Nlc3MgcGFja2V0IGlzIHNlbnQgYnkgdGhl IGF1dGhlbnRpY2F0b3IgdG8gdGhlIHBlZXIgYWZ0ZXINCiAgIGNvbXBsZXRpb24gb2YgYW4gRUFQ IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCAoVHlwZSA0IG9yIGdyZWF0ZXIpIHRvDQogICBpbmRpY2F0 ZSB0aGF0IHRoZSBwZWVyIGhhcyBhdXRoZW50aWNhdGVkIHN1Y2Nlc3NmdWxseSB0byB0aGUNCiAg IGF1dGhlbnRpY2F0b3IuICBUaGUgYXV0aGVudGljYXRvciBNVVNUIHRyYW5zbWl0IGFuIEVBUCBw YWNrZXQgd2l0aA0KICAgdGhlIENvZGUgZmllbGQgc2V0IHRvIDMgKFN1Y2Nlc3MpLiAgSWYgdGhl IGF1dGhlbnRpY2F0b3IgY2Fubm90DQogICBhdXRoZW50aWNhdGUgdGhlIHBlZXIgKHVuYWNjZXB0 YWJsZSBSZXNwb25zZXMgdG8gb25lIG9yIG1vcmUNCiAgIFJlcXVlc3RzKSwgdGhlbiBhZnRlciB1 bnN1Y2Nlc3NmdWwgY29tcGxldGlvbiBvZiB0aGUgRUFQIG1ldGhvZCBpbg0KICAgcHJvZ3Jlc3Ms IHRoZSBpbXBsZW1lbnRhdGlvbiBNVVNUIHRyYW5zbWl0IGFuIEVBUCBwYWNrZXQgd2l0aCB0aGUN CiAgIENvZGUgZmllbGQgc2V0IHRvIDQgKEZhaWx1cmUpLg0KDQpQZXJoYXBzIG9uZSBjYW4gYXJn dWUgdGhhdCBhIE5BSyBpcyBhbiB1bmFjY2VwdGFibGUgcmVzcG9uc2UgdG8gYW4NCm9uZ29pbmcg bWV0aG9kIGFuZCB0aGVyZWZvcmUgdGhlIG1ldGhvZCBpcyB1bnN1Y2Nlc3NmdWxseSBjb21wbGV0 ZWQgc28NCmEgRmFpbHVyZSBzaG91bGQgYmUgZ2VuZXJhdGVkPyBUaGF0J3Mgbm90IGVudGlyZWx5 IGNsZWFyLCBpZiB0aGF0IGlzDQp0aGUgY2FzZS4NCg0KUkZDIDM3NDggc2VjdGlvbiA1LjMuMSB0 aHJvd3MgaW4gc29tZSBtb3JlIGRvdWJ0LCBoYXZpbmcgdGhlIGZvbGxvd2luZw0KdGV4dCB0aGF0 IGRlYWxzIGV4cGxpY2l0bHkgd2l0aCB0aGUgcGVlciBzZW5kaW5nIGEgTkFLIGNvbnRhaW5pbmcg Im5vDQpkZXNpcmVkIGFsdGVybmF0aXZlIiBtZXRob2Q6DQoNCiAgICAgIFR5cGUgemVybyAoMCkg aXMgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBzZW5kZXIgaGFzDQogICAgICBubyB2aWFibGUg YWx0ZXJuYXRpdmVzLCBhbmQgdGhlcmVmb3JlIHRoZSBhdXRoZW50aWNhdG9yIFNIT1VMRCBOT1QN CiAgICAgIHNlbmQgYW5vdGhlciBSZXF1ZXN0IGFmdGVyIHJlY2VpdmluZyBhIE5hayBSZXNwb25z ZSBjb250YWluaW5nIGENCiAgICAgIHplcm8gdmFsdWUuDQoNClRoYXQncyBzcGVjaWZpYyB0byBv bmUgY2FzZSBmb3Igd2hpY2ggYSBzdHJpY3QgcmVhZGluZyB3b3VsZCBpbmRpY2F0ZQ0KdGhhdCB0 aGUgRUFQIHNlcnZlciBzaG91bGQgcmVtYWluIHF1aWV0IGFuZCBjb25zaWRlciB0aGUgRUFQDQpj b252ZXJzYXRpb24gdG8gYmUgY29tcGxldGUuIEl0J3MgdGVtcHRpbmcgdG8gdGhpbmsgdGhhdCB0 aGUgc2FtZQ0KcmVzcG9uc2UgKGksZS4gbm8gcmVzcG9uc2UhKSBzaG91bGQgYXBwbHkgbW9yZSBi cm9hZGx5IGFzIG5vbmUgb2YgdGhlDQpBQUEgaW1wbGVtZW50YXRpb25zIEkndmUgdGVzdGVkIGFj dHVhbGx5IGRpZmZlcmVudGlhdGUgYmV0d2VlbiBhIE5BSw0Kd2l0aCBubyBkZXNpcmVkIGFsdGVy bmF0aXZlIG1ldGhvZCB2cyBhIE5BSyB3aXRoIGFuIGluY29tcGF0aWJsZSBsaXN0DQpvZiBhbHRl cm5hdGl2ZSBtZXRob2RzLiAoQSBzdWJ0bGUgZGlmZmVyZW5jZSBtaWdodCBiZSByZWxldmFudDog SW4gdGhlDQpjYXNlIG9mIE5BSyAvIG1ldGhvZCA9IFtdIHRoZSBwZWVyIGtub3dzIHRoYXQgdGhl IEVBUCBjb252ZXJzaW9uIGNhbg0KZ28gbm8gZnVydGhlciwgd2hlcmVhcyBpbiB0aGUgY2FzZSB0 aGF0IGl0IHNlbmRzIGEgbGlzdCBvZiBtZXRob2RzDQp0aGF0IHRoZSBBQUEgaGFwcGVucyB0byBu b3Qgc3VwcG9ydCBpdCBkb2VzIG5vdCBrbm93IHRoaXMgdW5sZXNzIGl0IGlzDQpzdWJzZXF1ZW50 bHkgdG9sZC4pDQoNCklmIEkndmUgbm90IG1pc3NlZCBzb21ldGhpbmcgdGhlbiB0aGlzIGxvb2tz IGFuIG9taXNzaW9uIChvciBsYWNrIG9mDQpjbGFyaXR5KSBhbmQgdGhlIGludGVuZGVkIEFBQSBy ZXNwb25zZSB0byBubyBvdmVybGFwcGluZyBtZXRob2RzIChhbmQNCmluZGVlZCAibm8gZGVzaXJl ZCBhbHRlcm5hdGl2ZSIpIHNob3VsZCBiZSBkZWNpZGVkIGFuZCBjb2RpZmllZC4NCg0KDQpUaGFu a3MsDQoNClRlcnJ5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpFbXUgbWFpbGluZyBsaXN0DQpFbXVAaWV0Zi5vcmc8bWFpbHRvOkVtdUBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW11DQoNCg== --_000_ce1bd45385e671293b89034785e5231aericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <32C508D88F02C34BBBA98AA1B706CD1F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgVGVycnks PC9wPg0KPHA+SSBzdXJlbHkgbXVzdCBiZSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlOjxicj4NCjwv cD4NCjxwPlBhY2tldCA2IGlzIGFuIEVBUC1SZXNwb25zZSBmcm9tIHRoZSBwZWVyLiBQYWNrZXQg NyBjb250YWlucyBhbm90aGVyIEVBUC1SZXNwb25zZSBpbnNpZGUgYSBSQURJVVMgQWNjZXNzLVJl cXVlc3Q/IFRoYXQgZG9lc24ndCBtYWtlIHNlbnNlLiBFQVAgaXMgbG9jay1zdGVwIHJlcXVlc3Qt cmVzcG9uc2UgcHJvdG9jb2wuIFRoZSBjb252ZXJzYXRpb24geW91IGRlc2NyaWJlIGlzIGluY29y cmVjdC4NCjxicj4NCjwvcD4NCjxwPk15IHJlYWRpbmcgb2YgUkZDIDM3NDggaXMgY2xlYXIgdGhh dCBhZnRlciByZWNlaXZpbmcgYSBOQUsgZnJvbSB0aGUgcGVlciwgdGhlIHNlcnZlciBzaG91bGQg c2VuZCBhbm90aGVyIEVBUC1SZXF1ZXN0IHdpdGggYSBkaWZmZXJlbnQgRUFQIG1ldGhvZCBpZiBp dHMgcG9saWN5IGFsbG93cyBvciB0aGVuIHNlbmQgYSBmYWlsdXJlLiBUaGUgc2VydmVyIHNob3Vs ZCBhbHNvIHNlbmQgYSBmYWlsdXJlIGlmIHRoZSBwZWVyIE5BSyBUeXBlLURhdGENCiB3YXMgMCAo aW5kaWNhdGluZyBubyBwcm9wb3NlZCBhbHRlcm5hdGl2ZSkuIDxicj4NCjwvcD4NCjxwPkZZSTog UkZDIDQxMzcgc2F5czo8L3A+DQo8cD48L3A+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxw cmUgY2xhc3M9Im5ld3BhZ2UiPiAgIG8gIFNlbmRpbmcgYSBOQUsgdG8gdGhlIGF1dGhlbnRpY2F0 b3IgYWZ0ZXIgdGhlIGF1dGhlbnRpY2F0b3IgZmlyc3QNCiAgICAgIHByb3Bvc2VzIGFuIEVBUCBh dXRoZW50aWNhdGlvbiBtZXRob2QgdG8gdGhlIHBlZXIuICBXaGVuIHRoZQ0KICAgICAgbWV0aG9k U3RhdGUgdmFyaWFibGUgaGFzIHRoZSB2YWx1ZSBQUk9QT1NFRCwgdGhlIGF1dGhlbnRpY2F0b3Ig aXMNCiAgICAgIG9ibGlnZWQgdG8gcHJvY2VzcyBhIE5BSyB0aGF0IGlzIHJlY2VpdmVkIGluIHJl c3BvbnNlIHRvIGl0cyBmaXJzdA0KICAgICAgcGFja2V0IG9mIGFuIEVBUCBhdXRoZW50aWNhdGlv biBtZXRob2QuPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQpzbyB0aGUgY29tbWVyY2lhbCBSQURJVVMg c2VydmVyIGlzIGluIHZpb2xhdGlvbiBpZiBpdCBkb2Vzbid0IHJlc3BvbmQgdG8gYSBOQUsgZnJv bSB0aGUgcGVlciB3aXRoIGVpdGhlciBhbm90aGVyIEVBUC1SZXF1ZXN0IG9yIGZhaWx1cmUuDQo8 YnI+DQo8cD48L3A+DQo8cD4tLU1vaGl0PGJyPg0KPC9wPg0KPHA+PGJyPg0KPC9wPg0KPGRpdiBj bGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiA4LzIwLzIwIDM6MzkgQU0sIFRlcnJ5IEJ1cnRvbiB3 cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpDQU5z aVhFTHRyR1k1ZHluUzBrPXY2U055VUR2dl81aFIwVFlPUURpejQxZGJpZ0VQK1FAbWFpbC5nbWFp bC5jb20iPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5IaSwNCg0KSSdtIHVu YWJsZSB0byBmaW5kIHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSB0aGF0IHN0YXRlIGV4YWN0bHkg aG93IHRoZQ0KZm9sbG93aW5nIGNvbnZlcnNhdGlvbiBjb250aW51ZXMgKFRMO0RSOyB0aGUgcGVl ciBOQUtzIHRoZSBvcmlnaW5hbA0KbWV0aG9kIGFuZCB0aGUgQUFBIGRvZXNuJ3Qgc3VwcG9ydCBh bnkgb2YgdGhlIHBlZXIncyBwcm9wb3NhbHMpOg0KDQoxLiBOQVMgLS0mZ3Q7IFBlZXIgOiBFQVAt UmVxdWVzdCAvIElkZW50aXR5DQoyLiBQZWVyIC0tJmd0OyBOQVMgOiBFQVAtUmVzcG9uc2UgLyBJ ZGVudGl0eSAoIElEICkNCjMuIE5BUyAtLSZndDsgQUFBOiBSQURJVVMgQWNjZXNzLVJlcXVlc3Qg LyBFQVAtTWVzc2FnZSAvIEVBUC1SZXNwb25zZSAvDQpJZGVudGl0eSAoIElEICkNCjQuIEFBQSAt LSZndDsgTkFTOiAgUkFESVVTIEFjY2Vzcy1DaGFsbGVuZ2UgLyBFQVAtTWVzc2FnZSAvIEVBUC1S ZXF1ZXN0IC8NCk1ldGhvZCBGb28NCjUuIE5BUyAtLSZndDsgUGVlcjogRUFQLVJlcXVlc3QgLyBN ZXRob2QgRm9vDQo2LiBQZWVyIC0tJmd0OyBOQUs6IEVBUC1SZXNwb25zZSAvIEVBUC1UeXBlPU5B SyAoTWV0aG9kcyBbQmFyXSkNCjcuIE5BUyAtLSZndDsgQUFBOiBSQURJVVMgQWNjZXNzLVJlcXVl c3QgLyBFQVAtTWVzc2FnZSAvIEVBUC1SZXNwb25zZSAvDQpOQUsgKCBNZXRob2RzIFsgQmFyIF0g KQ0KKCogTGV0J3MgYXNzdW1lIHRoYXQgdGhlIEFBQSBkb2VzIG5vdCBzdXBwb3J0IE1ldGhvZCBC YXIgc28gd2UgaGF2ZQ0KZGVyaXZlZCB0aGF0IHRoZXJlIGFyZSBubyBvdmVybGFwcGluZyBtZXRo b2RzLikNCjguIEFBQTogTm93IHdoYXQ/DQoNCkkndmUgcmV2aWV3ZWQgUkZDIDM3NDggKEVBUCkg YW5kIFJGQyAzNTc5IChSQURJVVMgU3VwcG9ydCBGb3IgRUFQKSBhbmQNCm5laXRoZXIgc2VlbXMg dG8gYmUgZXhwbGljaXQgYWJvdXQgd2hhdCB0aGUgQUFBIHNob3VsZCBkbyBpbiByZXNwb25zZQ0K dG8gYSBOQUsgaW4gdGhlIGV2ZW50IG9mIG5vIG92ZXJsYXBwaW5nIG1ldGhvZHMuDQoNCkluIHBy YWN0aXNlOg0KDQoqIEZyZWVSQURJVVMgc2VuZHMgUkFESVVTIEFjY2Vzcy1SZWplY3QgLyBFQVAt TWVzc2FnZSAvIEVBUC1GYWlsdXJlLg0KKiBob3N0YXBkJ3MgUkFESVVTIHNlcnZlciBzZW5kcyBS QURJVVMgQWNjZXNzLVJlamVjdCAvIEVBUC1NZXNzYWdlIC8NCkVBUC1GYWlsdXJlLg0KKiBBIGNv bW1lcmNpYWwgUkFESVVTIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBzZW5kcyBub3RoaW5nLg0KDQpJ dCBzZWVtcyByaWdodCB0byBpbmRpY2F0ZSBhbiBFQVAtRmFpbHVyZSB0byB0aGUgcGVlciBpbiB0 aGUgY2FzZSBvZg0Kbm8gb3ZlcmxhcHBpbmcgbWV0aG9kcyAoYXMgd2VsbCBhcyB0byB0ZXJtaW5h dGUgdGhlIE5BUydzIG91dHN0YW5kaW5nDQpSQURJVVMgQWNjZXNzLVJlcXVlc3Qgd2l0aCBhbiBB Y2Nlc3MtUmVqZWN0KSwgYXMgaXMgdGhlIGNhc2UgZm9yIGENCm51bWJlciBvZiBvdGhlciBmYWls dXJlIGNvbmRpdGlvbnMsIGUuZy4gYXV0aGVudGljYXRpb24gZmFpbHVyZQ0KKndpdGhpbiogYW4g RUFQIG1ldGhvZCAoQXBwZW5kaXggQSBieSB3YXkgb2YgZXhhbXBsZSksIGludmFsaWQgcGFja2V0 cw0KbGVhZGluZyB0byBhIGZhdGFsIGVycm9yIHdpdGhpbiBhbiBFQVAgbWV0aG9kIChzZWN0aW9u IDIuMikuDQoNClJGQyAzNzQ4IHNlY3Rpb24gNC4yIG9uIFN1Y2Nlc3MgYW5kIEZhaWx1cmUgaW50 cm9kdWNlcyB0aGVzZSBtZXNzYWdlcw0Kd2l0aGluIHRoZSBjb250ZXh0IG9mIGZpbmFsaXNpbmcg YW4gb25nb2luZyBFQVAgbWV0aG9kOg0KDQogICBUaGUgU3VjY2VzcyBwYWNrZXQgaXMgc2VudCBi eSB0aGUgYXV0aGVudGljYXRvciB0byB0aGUgcGVlciBhZnRlcg0KICAgY29tcGxldGlvbiBvZiBh biBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9kIChUeXBlIDQgb3IgZ3JlYXRlcikgdG8NCiAgIGlu ZGljYXRlIHRoYXQgdGhlIHBlZXIgaGFzIGF1dGhlbnRpY2F0ZWQgc3VjY2Vzc2Z1bGx5IHRvIHRo ZQ0KICAgYXV0aGVudGljYXRvci4gIFRoZSBhdXRoZW50aWNhdG9yIE1VU1QgdHJhbnNtaXQgYW4g RUFQIHBhY2tldCB3aXRoDQogICB0aGUgQ29kZSBmaWVsZCBzZXQgdG8gMyAoU3VjY2VzcykuICBJ ZiB0aGUgYXV0aGVudGljYXRvciBjYW5ub3QNCiAgIGF1dGhlbnRpY2F0ZSB0aGUgcGVlciAodW5h Y2NlcHRhYmxlIFJlc3BvbnNlcyB0byBvbmUgb3IgbW9yZQ0KICAgUmVxdWVzdHMpLCB0aGVuIGFm dGVyIHVuc3VjY2Vzc2Z1bCBjb21wbGV0aW9uIG9mIHRoZSBFQVAgbWV0aG9kIGluDQogICBwcm9n cmVzcywgdGhlIGltcGxlbWVudGF0aW9uIE1VU1QgdHJhbnNtaXQgYW4gRUFQIHBhY2tldCB3aXRo IHRoZQ0KICAgQ29kZSBmaWVsZCBzZXQgdG8gNCAoRmFpbHVyZSkuDQoNClBlcmhhcHMgb25lIGNh biBhcmd1ZSB0aGF0IGEgTkFLIGlzIGFuIHVuYWNjZXB0YWJsZSByZXNwb25zZSB0byBhbg0Kb25n b2luZyBtZXRob2QgYW5kIHRoZXJlZm9yZSB0aGUgbWV0aG9kIGlzIHVuc3VjY2Vzc2Z1bGx5IGNv bXBsZXRlZCBzbw0KYSBGYWlsdXJlIHNob3VsZCBiZSBnZW5lcmF0ZWQ/IFRoYXQncyBub3QgZW50 aXJlbHkgY2xlYXIsIGlmIHRoYXQgaXMNCnRoZSBjYXNlLg0KDQpSRkMgMzc0OCBzZWN0aW9uIDUu My4xIHRocm93cyBpbiBzb21lIG1vcmUgZG91YnQsIGhhdmluZyB0aGUgZm9sbG93aW5nDQp0ZXh0 IHRoYXQgZGVhbHMgZXhwbGljaXRseSB3aXRoIHRoZSBwZWVyIHNlbmRpbmcgYSBOQUsgY29udGFp bmluZyAmcXVvdDtubw0KZGVzaXJlZCBhbHRlcm5hdGl2ZSZxdW90OyBtZXRob2Q6DQoNCiAgICAg IFR5cGUgemVybyAoMCkgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBzZW5kZXIgaGFzDQog ICAgICBubyB2aWFibGUgYWx0ZXJuYXRpdmVzLCBhbmQgdGhlcmVmb3JlIHRoZSBhdXRoZW50aWNh dG9yIFNIT1VMRCBOT1QNCiAgICAgIHNlbmQgYW5vdGhlciBSZXF1ZXN0IGFmdGVyIHJlY2Vpdmlu ZyBhIE5hayBSZXNwb25zZSBjb250YWluaW5nIGENCiAgICAgIHplcm8gdmFsdWUuDQoNClRoYXQn cyBzcGVjaWZpYyB0byBvbmUgY2FzZSBmb3Igd2hpY2ggYSBzdHJpY3QgcmVhZGluZyB3b3VsZCBp bmRpY2F0ZQ0KdGhhdCB0aGUgRUFQIHNlcnZlciBzaG91bGQgcmVtYWluIHF1aWV0IGFuZCBjb25z aWRlciB0aGUgRUFQDQpjb252ZXJzYXRpb24gdG8gYmUgY29tcGxldGUuIEl0J3MgdGVtcHRpbmcg dG8gdGhpbmsgdGhhdCB0aGUgc2FtZQ0KcmVzcG9uc2UgKGksZS4gbm8gcmVzcG9uc2UhKSBzaG91 bGQgYXBwbHkgbW9yZSBicm9hZGx5IGFzIG5vbmUgb2YgdGhlDQpBQUEgaW1wbGVtZW50YXRpb25z IEkndmUgdGVzdGVkIGFjdHVhbGx5IGRpZmZlcmVudGlhdGUgYmV0d2VlbiBhIE5BSw0Kd2l0aCBu byBkZXNpcmVkIGFsdGVybmF0aXZlIG1ldGhvZCB2cyBhIE5BSyB3aXRoIGFuIGluY29tcGF0aWJs ZSBsaXN0DQpvZiBhbHRlcm5hdGl2ZSBtZXRob2RzLiAoQSBzdWJ0bGUgZGlmZmVyZW5jZSBtaWdo dCBiZSByZWxldmFudDogSW4gdGhlDQpjYXNlIG9mIE5BSyAvIG1ldGhvZCA9IFtdIHRoZSBwZWVy IGtub3dzIHRoYXQgdGhlIEVBUCBjb252ZXJzaW9uIGNhbg0KZ28gbm8gZnVydGhlciwgd2hlcmVh cyBpbiB0aGUgY2FzZSB0aGF0IGl0IHNlbmRzIGEgbGlzdCBvZiBtZXRob2RzDQp0aGF0IHRoZSBB QUEgaGFwcGVucyB0byBub3Qgc3VwcG9ydCBpdCBkb2VzIG5vdCBrbm93IHRoaXMgdW5sZXNzIGl0 IGlzDQpzdWJzZXF1ZW50bHkgdG9sZC4pDQoNCklmIEkndmUgbm90IG1pc3NlZCBzb21ldGhpbmcg dGhlbiB0aGlzIGxvb2tzIGFuIG9taXNzaW9uIChvciBsYWNrIG9mDQpjbGFyaXR5KSBhbmQgdGhl IGludGVuZGVkIEFBQSByZXNwb25zZSB0byBubyBvdmVybGFwcGluZyBtZXRob2RzIChhbmQNCmlu ZGVlZCAmcXVvdDtubyBkZXNpcmVkIGFsdGVybmF0aXZlJnF1b3Q7KSBzaG91bGQgYmUgZGVjaWRl ZCBhbmQgY29kaWZpZWQuDQoNCg0KVGhhbmtzLA0KDQpUZXJyeQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRW11IG1haWxpbmcgbGlzdA0KPGEgY2xh c3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOkVtdUBpZXRmLm9yZyI+ RW11QGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXUiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZW11PC9hPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_ce1bd45385e671293b89034785e5231aericssoncom_-- From nobody Thu Aug 20 05:03: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 11EF83A09F5 for ; Thu, 20 Aug 2020 05:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_FROM=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 WgaIAEGYSYnW for ; Thu, 20 Aug 2020 05:03:15 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 0F03E3A09EC for ; Thu, 20 Aug 2020 05:03:14 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id a127so924604vsd.1 for ; Thu, 20 Aug 2020 05:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=pjGlo5SO2VD2LmX+ZLk9hHba4gO8WWul1hxrAPn9g98=; b=QP6BzL6h/L0mWuem0KKfU5wQV2HIOpYzQgebVW+zG9M9YMzKlZw9/U50WBT9+9ifTO W8ydhT5U5w1yY4nTXs/3XdVIGPgmP387oOy1udCyIua0daHHI/64eCcCynGcHWyjjKiy ocCA617pUGJpvflB+ujaXIoAeJ1S4jFJ9rdoTKWOBjYBE3/iZP8QYh15IERmSDLj6VqW vm1rtTTmGiJN0G226+MOU6+Tu4xT197mS6lFiet5Mrc14U5yQ4hRN66DA+EPoWjqtnWK GXoZ7AEmSQ9Y7Kk+oRAdugHWjGoLA44LX9P8yyS/aDJxcSRKUlHkQEkYKMOhBi5hxphr Bz1w== 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=pjGlo5SO2VD2LmX+ZLk9hHba4gO8WWul1hxrAPn9g98=; b=gqhmmBKPAiquc5YUX2zv+jViCX5evBVI3DlDV05HH2I7n1SK6INCIKNbGJm4Y8B/fR kCQzmjEH2ZJHsK9MwOkmalP8nHeNLyVJnkEtJdISoGlxMnvZki2K0IW+78CaPfdJNGMy jeJLI7E4WWE4WzrVBxNAV0ft79A7HsCr1pW0w/YR7VITE5RPrvJSs/vWc/Rf9gi50zkA Wvb7KiUK44td4P12FBmCbZzYn7GVAQ1tt9W4aG5DVbvEKYx8MzE8XXO0asQuIxoasb6f N7Tt8uncYs7kD2HnYjHj1NrxvketuxFq3Vu95emEqvq5RRmco3HTa7opJWLKHH+98op1 EHPA== X-Gm-Message-State: AOAM5300yi9jpa6gePR41HxKiMkWXoajTBZWygNKyyDXfFH6y/rOC9k/ M7qZz6qriNeLRbxpDmquObDj+xKVrMmUgj72qM2PXJSbGb0QDA== X-Google-Smtp-Source: ABdhPJxIMok1HIfGMi1UXsXnGmLcdyyY1qwOaFqxsxlXNvrl46HxUfw7rRDiJEiIHXFcS65JcJDizUUfbkh0sdlC47E= X-Received: by 2002:a05:6102:3025:: with SMTP id v5mr1483543vsa.194.1597924993764; Thu, 20 Aug 2020 05:03:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: tez@terryburton.co.uk From: Terry Burton Date: Thu, 20 Aug 2020 13:02:37 +0100 Message-ID: To: Mohit Sethi M Cc: "emu@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 20 Aug 2020 12:03:17 -0000 On Thu, 20 Aug 2020 at 10:00, Mohit Sethi M wrote: > I surely must be missing something here: > > Packet 6 is an EAP-Response from the peer. Packet 7 contains another EAP-= Response inside a RADIUS Access-Request? That doesn't make sense. EAP is lo= ck-step request-response protocol. The conversation you describe is incorre= ct. Hi, Maybe you were thrown by my typo (to make sure readers were awake). It should have read "6. Peer --> NAS", i.e.: 6. Peer --> NAS: EAP-Response / EAP-Type=3DNAK (Methods [Bar]) 7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / NAK ( Methods [ Bar ] ) Packet 7 is just the NAS encapsulating the Peer's NAK within RADIUS for the AAA, not a separately originating request. The language is the same as the fourth example in RFC 3579 Appendix A, however that example skips the identity phase and goes on to successfully negotiate a method. > My reading of RFC 3748 is clear that after receiving a NAK from the peer,= the server should send another EAP-Request with a different EAP method if = its policy allows or then send a failure. The server should also send a fai= lure if the peer NAK Type-Data was 0 (indicating no proposed alternative). I'm still not seeing a clear reference for what to send in the event of no overlapping methods from the text in these RFCs. > FYI: RFC 4137 says: > > o Sending a NAK to the authenticator after the authenticator first > proposes an EAP authentication method to the peer. When the > methodState variable has the value PROPOSED, the authenticator is > obliged to process a NAK that is received in response to its first > packet of an EAP authentication method. > > so the commercial RADIUS server is in violation if it doesn't respond to = a NAK from the peer with either another EAP-Request or failure. That's relevant in the sense that it restates that it is appropriate for a peer to NAK the server's original method selection and that the server must process the NAK. It doesn't state what happens on the wire (specifically that an EAP-Failure is sent to the peer, as seems to be the case in practise) as a result of this processing. It's also contrary to... > Type zero (0) is used to indicate that the sender has > no viable alternatives, and therefore the authenticator SHOULD NOT > send another Request after receiving a Nak Response containing a > zero value. ... unless the language is loose and we say that an EAP-Failure request isn't actually a "Request", but that's hard to argue due to capital "R"equest. Nevertheless, RFC 4137 Appendix A.2. and A.3. is clear on what to do: * When the peer sends a NAK with no alternatives we are in RECEIVED. * In RECEIVED: respMethod =3D=3D NAK therefore we transition to NAK. * In NAK: We update the policy to exclude the NAKed method and transition to SELECT_ACTION. * In SELECT_ACTION: the result of Policy.getDecision() is presumably FAILURE for no overlapping methods. Transition to FAILURE. * In FAILURE: We build a failure response. I note that both receiving a NAK (RECEIVED -> NAK -> SELECT_ACTION -> FAILURE transition) and receiving an unacceptable method response (RECEIVED -> INTEGRITY_CHECK -> METHOD_RESPONSE -> SELECT_ACTION transition) ultimately arrive at the same FAILURE state that builds a EAP-Failure packet. It appears that the agreed upon behaviour is codified here. Its behaviour also does not differentiate between a peer NAK of "type 0" and one containing a list of alternative methods. Terry > On 8/20/20 3:39 AM, Terry Burton wrote: > > Hi, > > I'm unable to find the authoritative source that state exactly how the > following conversation continues (TL;DR; the peer NAKs the original > method and the AAA doesn't support any of the peer's proposals): > > 1. NAS --> Peer : EAP-Request / Identity > 2. Peer --> NAS : EAP-Response / Identity ( ID ) > 3. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / > Identity ( ID ) > 4. AAA --> NAS: RADIUS Access-Challenge / EAP-Message / EAP-Request / > Method Foo > 5. NAS --> Peer: EAP-Request / Method Foo > 6. Peer --> NAK: EAP-Response / EAP-Type=3DNAK (Methods [Bar]) > 7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / > NAK ( Methods [ Bar ] ) > (* Let's assume that the AAA does not support Method Bar so we have > derived that there are no overlapping methods.) > 8. AAA: Now what? > > I've reviewed RFC 3748 (EAP) and RFC 3579 (RADIUS Support For EAP) and > neither seems to be explicit about what the AAA should do in response > to a NAK in the event of no overlapping methods. > > In practise: > > * FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure. > * hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message / > EAP-Failure. > * A commercial RADIUS server implementation sends nothing. > > It seems right to indicate an EAP-Failure to the peer in the case of > no overlapping methods (as well as to terminate the NAS's outstanding > RADIUS Access-Request with an Access-Reject), as is the case for a > number of other failure conditions, e.g. authentication failure > *within* an EAP method (Appendix A by way of example), invalid packets > leading to a fatal error within an EAP method (section 2.2). > > RFC 3748 section 4.2 on Success and Failure introduces these messages > within the context of finalising an ongoing EAP method: > > The Success packet is sent by the authenticator to the peer after > completion of an EAP authentication method (Type 4 or greater) to > indicate that the peer has authenticated successfully to the > authenticator. The authenticator MUST transmit an EAP packet with > the Code field set to 3 (Success). If the authenticator cannot > authenticate the peer (unacceptable Responses to one or more > Requests), then after unsuccessful completion of the EAP method in > progress, the implementation MUST transmit an EAP packet with the > Code field set to 4 (Failure). > > Perhaps one can argue that a NAK is an unacceptable response to an > ongoing method and therefore the method is unsuccessfully completed so > a Failure should be generated? That's not entirely clear, if that is > the case. > > RFC 3748 section 5.3.1 throws in some more doubt, having the following > text that deals explicitly with the peer sending a NAK containing "no > desired alternative" method: > > Type zero (0) is used to indicate that the sender has > no viable alternatives, and therefore the authenticator SHOULD NOT > send another Request after receiving a Nak Response containing a > zero value. > > That's specific to one case for which a strict reading would indicate > that the EAP server should remain quiet and consider the EAP > conversation to be complete. It's tempting to think that the same > response (i,e. no response!) should apply more broadly as none of the > AAA implementations I've tested actually differentiate between a NAK > with no desired alternative method vs a NAK with an incompatible list > of alternative methods. (A subtle difference might be relevant: In the > case of NAK / method =3D [] the peer knows that the EAP conversion can > go no further, whereas in the case that it sends a list of methods > that the AAA happens to not support it does not know this unless it is > subsequently told.) > > If I've not missed something then this looks an omission (or lack of > clarity) and the intended AAA response to no overlapping methods (and > indeed "no desired alternative") should be decided and codified. > > > Thanks, > > Terry From nobody Thu Aug 20 05:34: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 BB1AF3A0867 for ; Thu, 20 Aug 2020 05:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 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, NICE_REPLY_A=-0.949, 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 PAI9d2h-0Aot for ; Thu, 20 Aug 2020 05:34:20 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60054.outbound.protection.outlook.com [40.107.6.54]) (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 DA12B3A0857 for ; Thu, 20 Aug 2020 05:34:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ap/5luNwodcAcmMLAyVFM1xWvEB6x3yYxNGGe3rq0+9m+MS7qOcOUNLMA9pIthQ0CduW7SsIJptQjMTvIUWOA0Q5K7xPw9YVSfgFYkVTQAbA9Cv6OBuMOtnvTMGCAVPIydFgttII4DQLAQ4oFbvR1E4+6GSz3tVNDYFCROEmkR5qfHssOjlPOV2ANjBasUgDOz3K0cdDdMi6d9jX3xpUW7H2WpBfmMQrgHVQvjLebxBeKu0G8BY48K6dtR7nYy2UfoH00JI96xsQqHSMIUI6mOF/XB9WWAg7v9NHUGS9wFkDFQY7dXB0xva6ra9CmTDhZb8prvrzYri3EiCB7HafBA== 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=5WglDK5GGpTLIU0blWq7sP+5KESWf4UuPVXh6TJBxIM=; b=TUHH0ThpZZKzonaJROwKl7jMXOvB07UbSjvHEERcMOUmciMb4WdK3VQietzVKPtNfmob5NmpUH1/+tTryGJriHBIQM0LFC1BAN6JKOoaCetFIphKfN32SIwBUfU7cq2QLI754PoBSf9BRytUyFPaWVuV040kFBUtbvLtmCHfsRrlVJDBz7NNQ0ffhAT4NJPL0zgHsWdUWsTkC5sVeqB/4BakWLMq5B1vRJsFf9sXedXuR/awXbIjfCiAB7xrkSd/dBnnRpVRu7OCFku/a94uZjOkAWBdhp59aLltJV2G2hjSPknMbYLPrHz2SAdESxmS3/n63fdKPTXaMhUgbbYFlg== 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=5WglDK5GGpTLIU0blWq7sP+5KESWf4UuPVXh6TJBxIM=; b=ZJ6nNMGnapiw/u2El75nCuF02V8DKi+EuHsKU/NZi3azq/Z5Kljk8/onMOpYX3lvmZFDCbSqIGlVNDYas7CjtQNKISzHTS7ExDhCozdyfe5IERcgN61kqnCSefTJstpeiej6++TDgybUCfWjzTKWbGB/J4DsPkGoTCErrOSIFH8= Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR07MB3194.eurprd07.prod.outlook.com (2603:10a6:7:31::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Thu, 20 Aug 2020 12:34:17 +0000 Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6%5]) with mapi id 15.20.3305.021; Thu, 20 Aug 2020 12:34:17 +0000 From: Mohit Sethi M To: "emu@ietf.org" Thread-Topic: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods Thread-Index: AQHWdtBd6/Chl5vFm0Cl50TEYc0wYalA5faAgAAI2AA= Date: Thu, 20 Aug 2020 12:34:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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:2a7d:eafd:b986:ec2:5e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fefb3dff-c669-45b4-c5e5-08d845055aba x-ms-traffictypediagnostic: HE1PR07MB3194: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FQoYyNBdahmk1Ub2YdcKbgkUmdfb/I/PyKLBZ8TGEIPucIdj/pXlkHDmXK216fek099bWndz8185pKhBerkC13Hjj6zsjScS4ACB7BpVrsfan+VMJCAAOvcGiFz4YSyG/x15QKKV8x3hE3UZgzCY+rGp5LtqVBdJFvy8T4i42sc0Mx7eECiVguoAMk6pLuieISnf+FS+IHlUARMTpEPuNSCmRk1WDoQAjHi3pVs0LKx5fBPNF06Jz1jSgA3kd0mwm8qYrzqS1E7+wfdbnDSwJqKpg58iP/wkZyaKPMWeT39gzv7LrxROyOg8vWZQFahiXLGqtls+SYqVyAL2pS0EHkacpHaxx63dN8URnfLI+y3d9POq7GW3byoH/7LTn/UuaTDv50lJ7nYxYi91EROKPXxLCoeQLejmdq+IXRnoVo4maQEl0K7We5Cha4413HUdX1SQBc+jzzHX8+55I+3/mw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39860400002)(366004)(346002)(376002)(76116006)(31686004)(478600001)(966005)(6506007)(53546011)(36756003)(186003)(2616005)(71200400001)(31696002)(86362001)(6512007)(166002)(83380400001)(66556008)(66476007)(6916009)(6486002)(66446008)(316002)(66946007)(2906002)(8936002)(64756008)(5660300002)(8676002)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: jQZgsV36JOT0FAZCJ0gnTEcGE0pu/a3km4aLCDGUxVxFaOSQlKzkJnR0f6dmE9VprJhn17XyUh+Ksc4vtUZgw+4JUMtjNE8PBRPnErwEuxM5FHa05pG1gr+yRF8hqZT+KfzXsqkScD/sx9xcx1De1Ro5RROOGojzUyrm6t17h+Sq/yfKS4Sap0F0JXwqeuqCARPG4w5I4Z5d+fAZWXzjaOfwysl5dwZLkfQQXReZFqgXaqIYdhnymQvL9weYIUptJlm1HKXVl93ppuBscLIco9hI5XvEwpp0M/+fYAOZ3w5PhGPdOhsPnZr3/MO+0mlFyJcuepTsQyeHxkpVtRCmdVCE/SENxKzVtIeAJrldzjlcgUou3I4NIon+yLQqLviORK7nNCN9MG2iijzboJNHUuPFqo9M4FtzD1VBV+gvitabDz8NUVxnlltmWmRYQI2fsWoAiCswiiDtndBIJ6+PSURx0jeAtyfKW4mhyMDgbhEN4XGHHT5zYomJMrzT6dfGfbRR438BkRHcXNzTdBiI1dCdG7xgwwcD+jngW8uwB1424Ppix+c0bJpVertrbioyJzhsqY7S02MZAXt9p+afYe8jC8WNAe2AnrE8Vc1qb68ZcTY2yXqMtpuknColitm6XiRH3oVmAqEW+s9CPO2avQMEz7dNIUxNbsdwcipczsz90/mDcVWdiOFi7+dbY+6Dv5yPsP/mO8tIp2AvT0PEDQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_dc5042e36f07b1e3b0985063fb955f58ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3209.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fefb3dff-c669-45b4-c5e5-08d845055aba X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2020 12:34:17.1128 (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: OsHyGOR6QCkYsHJ796c5EEzZAy+4vMaL/pMe4mDAkvUZCnqsOygbrxXcMWiJ1BqrCvXXCyK/mjI5i8Q/6B1GxH2QJK42fSktkLDsj6slnJs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3194 Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 20 Aug 2020 12:34:23 -0000 --_000_dc5042e36f07b1e3b0985063fb955f58ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVycnksDQoNCk9uIDgvMjAvMjAgMzowMiBQTSwgVGVycnkgQnVydG9uIHdyb3RlOg0KDQpP biBUaHUsIDIwIEF1ZyAyMDIwIGF0IDEwOjAwLCBNb2hpdCBTZXRoaSBNDQo8bW9oaXQubS5zZXRo aT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz48bWFpbHRvOm1vaGl0Lm0uc2V0aGk9NDBl cmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCkkgc3VyZWx5IG11c3QgYmUg bWlzc2luZyBzb21ldGhpbmcgaGVyZToNCg0KUGFja2V0IDYgaXMgYW4gRUFQLVJlc3BvbnNlIGZy b20gdGhlIHBlZXIuIFBhY2tldCA3IGNvbnRhaW5zIGFub3RoZXIgRUFQLVJlc3BvbnNlIGluc2lk ZSBhIFJBRElVUyBBY2Nlc3MtUmVxdWVzdD8gVGhhdCBkb2Vzbid0IG1ha2Ugc2Vuc2UuIEVBUCBp cyBsb2NrLXN0ZXAgcmVxdWVzdC1yZXNwb25zZSBwcm90b2NvbC4gVGhlIGNvbnZlcnNhdGlvbiB5 b3UgZGVzY3JpYmUgaXMgaW5jb3JyZWN0Lg0KDQoNCg0KSGksDQoNCk1heWJlIHlvdSB3ZXJlIHRo cm93biBieSBteSB0eXBvICh0byBtYWtlIHN1cmUgcmVhZGVycyB3ZXJlIGF3YWtlKS4gSXQNCnNo b3VsZCBoYXZlIHJlYWQgIjYuIFBlZXIgLS0+IE5BUyIsIGkuZS46DQoNCkluZGVlZC4gSSBtaXNy ZWFkIHRoZSBwYWNrZXQgc2VxdWVuY2UgdG8gaW1wbHkgdGhhdCB0aGUgc2VydmVyIHdhcyBzZW5k aW5nIGFuIEVBUC1SZXNwb25zZSAod2hpY2ggaXMgd2h5IEkgaGFkIGEgZGlzY2xhaW1lciBhdCB0 aGUgYmVnaW5uaW5nIDopKS4NCg0KDQoNCjYuIFBlZXIgLS0+IE5BUzogRUFQLVJlc3BvbnNlIC8g RUFQLVR5cGU9TkFLIChNZXRob2RzIFtCYXJdKQ0KNy4gTkFTIC0tPiBBQUE6IFJBRElVUyBBY2Nl c3MtUmVxdWVzdCAvIEVBUC1NZXNzYWdlIC8gRUFQLVJlc3BvbnNlIC8NCk5BSyAoIE1ldGhvZHMg WyBCYXIgXSApDQoNClBhY2tldCA3IGlzIGp1c3QgdGhlIE5BUyBlbmNhcHN1bGF0aW5nIHRoZSBQ ZWVyJ3MgTkFLIHdpdGhpbiBSQURJVVMNCmZvciB0aGUgQUFBLCBub3QgYSBzZXBhcmF0ZWx5IG9y aWdpbmF0aW5nIHJlcXVlc3QuIFRoZSBsYW5ndWFnZSBpcyB0aGUNCnNhbWUgYXMgdGhlIGZvdXJ0 aCBleGFtcGxlIGluIFJGQyAzNTc5IEFwcGVuZGl4IEEsIGhvd2V2ZXIgdGhhdA0KZXhhbXBsZSBz a2lwcyB0aGUgaWRlbnRpdHkgcGhhc2UgYW5kIGdvZXMgb24gdG8gc3VjY2Vzc2Z1bGx5IG5lZ290 aWF0ZQ0KYSBtZXRob2QuDQoNCg0KDQpNeSByZWFkaW5nIG9mIFJGQyAzNzQ4IGlzIGNsZWFyIHRo YXQgYWZ0ZXIgcmVjZWl2aW5nIGEgTkFLIGZyb20gdGhlIHBlZXIsIHRoZSBzZXJ2ZXIgc2hvdWxk IHNlbmQgYW5vdGhlciBFQVAtUmVxdWVzdCB3aXRoIGEgZGlmZmVyZW50IEVBUCBtZXRob2QgaWYg aXRzIHBvbGljeSBhbGxvd3Mgb3IgdGhlbiBzZW5kIGEgZmFpbHVyZS4gVGhlIHNlcnZlciBzaG91 bGQgYWxzbyBzZW5kIGEgZmFpbHVyZSBpZiB0aGUgcGVlciBOQUsgVHlwZS1EYXRhIHdhcyAwIChp bmRpY2F0aW5nIG5vIHByb3Bvc2VkIGFsdGVybmF0aXZlKS4NCg0KDQoNCkknbSBzdGlsbCBub3Qg c2VlaW5nIGEgY2xlYXIgcmVmZXJlbmNlIGZvciB3aGF0IHRvIHNlbmQgaW4gdGhlIGV2ZW50DQpv ZiBubyBvdmVybGFwcGluZyBtZXRob2RzIGZyb20gdGhlIHRleHQgaW4gdGhlc2UgUkZDcy4NCg0K DQoNCkZZSTogUkZDIDQxMzcgc2F5czoNCg0KICAgbyAgU2VuZGluZyBhIE5BSyB0byB0aGUgYXV0 aGVudGljYXRvciBhZnRlciB0aGUgYXV0aGVudGljYXRvciBmaXJzdA0KICAgICAgcHJvcG9zZXMg YW4gRUFQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCB0byB0aGUgcGVlci4gIFdoZW4gdGhlDQogICAg ICBtZXRob2RTdGF0ZSB2YXJpYWJsZSBoYXMgdGhlIHZhbHVlIFBST1BPU0VELCB0aGUgYXV0aGVu dGljYXRvciBpcw0KICAgICAgb2JsaWdlZCB0byBwcm9jZXNzIGEgTkFLIHRoYXQgaXMgcmVjZWl2 ZWQgaW4gcmVzcG9uc2UgdG8gaXRzIGZpcnN0DQogICAgICBwYWNrZXQgb2YgYW4gRUFQIGF1dGhl bnRpY2F0aW9uIG1ldGhvZC4NCg0Kc28gdGhlIGNvbW1lcmNpYWwgUkFESVVTIHNlcnZlciBpcyBp biB2aW9sYXRpb24gaWYgaXQgZG9lc24ndCByZXNwb25kIHRvIGEgTkFLIGZyb20gdGhlIHBlZXIg d2l0aCBlaXRoZXIgYW5vdGhlciBFQVAtUmVxdWVzdCBvciBmYWlsdXJlLg0KDQoNCg0KVGhhdCdz IHJlbGV2YW50IGluIHRoZSBzZW5zZSB0aGF0IGl0IHJlc3RhdGVzIHRoYXQgaXQgaXMgYXBwcm9w cmlhdGUNCmZvciBhIHBlZXIgdG8gTkFLIHRoZSBzZXJ2ZXIncyBvcmlnaW5hbCBtZXRob2Qgc2Vs ZWN0aW9uIGFuZCB0aGF0IHRoZQ0Kc2VydmVyIG11c3QgcHJvY2VzcyB0aGUgTkFLLiBJdCBkb2Vz bid0IHN0YXRlIHdoYXQgaGFwcGVucyBvbiB0aGUgd2lyZQ0KKHNwZWNpZmljYWxseSB0aGF0IGFu IEVBUC1GYWlsdXJlIGlzIHNlbnQgdG8gdGhlIHBlZXIsIGFzIHNlZW1zIHRvIGJlDQp0aGUgY2Fz ZSBpbiBwcmFjdGlzZSkgYXMgYSByZXN1bHQgb2YgdGhpcyBwcm9jZXNzaW5nLg0KDQpJdCdzIGFs c28gY29udHJhcnkgdG8uLi4NCg0KDQoNCiAgICAgIFR5cGUgemVybyAoMCkgaXMgdXNlZCB0byBp bmRpY2F0ZSB0aGF0IHRoZSBzZW5kZXIgaGFzDQogICAgICBubyB2aWFibGUgYWx0ZXJuYXRpdmVz LCBhbmQgdGhlcmVmb3JlIHRoZSBhdXRoZW50aWNhdG9yIFNIT1VMRCBOT1QNCiAgICAgIHNlbmQg YW5vdGhlciBSZXF1ZXN0IGFmdGVyIHJlY2VpdmluZyBhIE5hayBSZXNwb25zZSBjb250YWluaW5n IGENCiAgICAgIHplcm8gdmFsdWUuDQoNCg0KDQouLi4uIHVubGVzcyB0aGUgbGFuZ3VhZ2UgaXMg bG9vc2UgYW5kIHdlIHNheSB0aGF0IGFuIEVBUC1GYWlsdXJlDQpyZXF1ZXN0IGlzbid0IGFjdHVh bGx5IGEgIlJlcXVlc3QiLCBidXQgdGhhdCdzIGhhcmQgdG8gYXJndWUgZHVlIHRvDQpjYXBpdGFs ICJSImVxdWVzdC4NCg0KV2h5IGlzIEVBUC1GYWlsdXJlIGEgcmVxdWVzdD8gSXQncyBhbiBFQVAg cGFja2V0IHdpdGggYSBkaWZmZXJlbnQgQ29kZT8gU28gdGhlIFNIT1VMRCBOT1QgZG9lc24ndCBm b3JiaWQgdGhlIHNlcnZlciBmcm9tIHNlbmRpbmcgYW4gRUFQLUZhaWx1cmUuIFJGQyAzNzQ4IGV2 ZW4gY2FsbHMgRmFpbHVyZSBhcyBhIHJlc3BvbnNlOiAiQW4gYXV0aGVudGljYXRvciBNQVkgd2lz aCB0byBpc3N1ZSBtdWx0aXBsZSBSZXF1ZXN0cyBiZWZvcmUgc2VuZGluZyBhIEZhaWx1cmUgcmVz cG9uc2UgaW4gb3JkZXIgdG8gYWxsb3cgZm9yIGh1bWFuIHR5cGluZyBtaXN0YWtlcy4iDQoNCg0K DQpOZXZlcnRoZWxlc3MsIFJGQyA0MTM3IEFwcGVuZGl4IEEuMi4gYW5kIEEuMy4gaXMgY2xlYXIg b24gd2hhdCB0byBkbzoNCg0KKiBXaGVuIHRoZSBwZWVyIHNlbmRzIGEgTkFLIHdpdGggbm8gYWx0 ZXJuYXRpdmVzIHdlIGFyZSBpbiBSRUNFSVZFRC4NCiogSW4gUkVDRUlWRUQ6IHJlc3BNZXRob2Qg PT0gTkFLIHRoZXJlZm9yZSB3ZSB0cmFuc2l0aW9uIHRvIE5BSy4NCiogSW4gTkFLOiBXZSB1cGRh dGUgdGhlIHBvbGljeSB0byBleGNsdWRlIHRoZSBOQUtlZCBtZXRob2QgYW5kDQp0cmFuc2l0aW9u IHRvIFNFTEVDVF9BQ1RJT04uDQoqIEluIFNFTEVDVF9BQ1RJT046IHRoZSByZXN1bHQgb2YgUG9s aWN5LmdldERlY2lzaW9uKCkgaXMgcHJlc3VtYWJseQ0KRkFJTFVSRSBmb3Igbm8gb3ZlcmxhcHBp bmcgbWV0aG9kcy4gVHJhbnNpdGlvbiB0byBGQUlMVVJFLg0KKiBJbiBGQUlMVVJFOiBXZSBidWls ZCBhIGZhaWx1cmUgcmVzcG9uc2UuDQoNCkkgbm90ZSB0aGF0IGJvdGggcmVjZWl2aW5nIGEgTkFL IChSRUNFSVZFRCAtPiBOQUsgLT4gU0VMRUNUX0FDVElPTiAtPg0KRkFJTFVSRSB0cmFuc2l0aW9u KSBhbmQgcmVjZWl2aW5nIGFuIHVuYWNjZXB0YWJsZSBtZXRob2QgcmVzcG9uc2UNCihSRUNFSVZF RCAtPiBJTlRFR1JJVFlfQ0hFQ0sgLT4gTUVUSE9EX1JFU1BPTlNFIC0+IFNFTEVDVF9BQ1RJT04N CnRyYW5zaXRpb24pIHVsdGltYXRlbHkgYXJyaXZlIGF0IHRoZSBzYW1lIEZBSUxVUkUgc3RhdGUg dGhhdCBidWlsZHMgYQ0KRUFQLUZhaWx1cmUgcGFja2V0LiBJdCBhcHBlYXJzIHRoYXQgdGhlIGFn cmVlZCB1cG9uIGJlaGF2aW91ciBpcw0KY29kaWZpZWQgaGVyZS4NCg0KSXRzIGJlaGF2aW91ciBh bHNvIGRvZXMgbm90IGRpZmZlcmVudGlhdGUgYmV0d2VlbiBhIHBlZXIgTkFLIG9mICJ0eXBlDQow IiBhbmQgb25lIGNvbnRhaW5pbmcgYSBsaXN0IG9mIGFsdGVybmF0aXZlIG1ldGhvZHMuDQoNClRo aXMgc2VlbXMgdG8gYmUgdGhlIGNvcnJlY3QgYmVoYXZpb3IgKGF0IGxlYXN0IGZvciBtZSkuDQoN Ci0tTW9oaXQNCg0KDQoNCg0KVGVycnkNCg0KDQoNCg0KT24gOC8yMC8yMCAzOjM5IEFNLCBUZXJy eSBCdXJ0b24gd3JvdGU6DQoNCkhpLA0KDQpJJ20gdW5hYmxlIHRvIGZpbmQgdGhlIGF1dGhvcml0 YXRpdmUgc291cmNlIHRoYXQgc3RhdGUgZXhhY3RseSBob3cgdGhlDQpmb2xsb3dpbmcgY29udmVy c2F0aW9uIGNvbnRpbnVlcyAoVEw7RFI7IHRoZSBwZWVyIE5BS3MgdGhlIG9yaWdpbmFsDQptZXRo b2QgYW5kIHRoZSBBQUEgZG9lc24ndCBzdXBwb3J0IGFueSBvZiB0aGUgcGVlcidzIHByb3Bvc2Fs cyk6DQoNCjEuIE5BUyAtLT4gUGVlciA6IEVBUC1SZXF1ZXN0IC8gSWRlbnRpdHkNCjIuIFBlZXIg LS0+IE5BUyA6IEVBUC1SZXNwb25zZSAvIElkZW50aXR5ICggSUQgKQ0KMy4gTkFTIC0tPiBBQUE6 IFJBRElVUyBBY2Nlc3MtUmVxdWVzdCAvIEVBUC1NZXNzYWdlIC8gRUFQLVJlc3BvbnNlIC8NCklk ZW50aXR5ICggSUQgKQ0KNC4gQUFBIC0tPiBOQVM6ICBSQURJVVMgQWNjZXNzLUNoYWxsZW5nZSAv IEVBUC1NZXNzYWdlIC8gRUFQLVJlcXVlc3QgLw0KTWV0aG9kIEZvbw0KNS4gTkFTIC0tPiBQZWVy OiBFQVAtUmVxdWVzdCAvIE1ldGhvZCBGb28NCjYuIFBlZXIgLS0+IE5BSzogRUFQLVJlc3BvbnNl IC8gRUFQLVR5cGU9TkFLIChNZXRob2RzIFtCYXJdKQ0KNy4gTkFTIC0tPiBBQUE6IFJBRElVUyBB Y2Nlc3MtUmVxdWVzdCAvIEVBUC1NZXNzYWdlIC8gRUFQLVJlc3BvbnNlIC8NCk5BSyAoIE1ldGhv ZHMgWyBCYXIgXSApDQooKiBMZXQncyBhc3N1bWUgdGhhdCB0aGUgQUFBIGRvZXMgbm90IHN1cHBv cnQgTWV0aG9kIEJhciBzbyB3ZSBoYXZlDQpkZXJpdmVkIHRoYXQgdGhlcmUgYXJlIG5vIG92ZXJs YXBwaW5nIG1ldGhvZHMuKQ0KOC4gQUFBOiBOb3cgd2hhdD8NCg0KSSd2ZSByZXZpZXdlZCBSRkMg Mzc0OCAoRUFQKSBhbmQgUkZDIDM1NzkgKFJBRElVUyBTdXBwb3J0IEZvciBFQVApIGFuZA0KbmVp dGhlciBzZWVtcyB0byBiZSBleHBsaWNpdCBhYm91dCB3aGF0IHRoZSBBQUEgc2hvdWxkIGRvIGlu IHJlc3BvbnNlDQp0byBhIE5BSyBpbiB0aGUgZXZlbnQgb2Ygbm8gb3ZlcmxhcHBpbmcgbWV0aG9k cy4NCg0KSW4gcHJhY3Rpc2U6DQoNCiogRnJlZVJBRElVUyBzZW5kcyBSQURJVVMgQWNjZXNzLVJl amVjdCAvIEVBUC1NZXNzYWdlIC8gRUFQLUZhaWx1cmUuDQoqIGhvc3RhcGQncyBSQURJVVMgc2Vy dmVyIHNlbmRzIFJBRElVUyBBY2Nlc3MtUmVqZWN0IC8gRUFQLU1lc3NhZ2UgLw0KRUFQLUZhaWx1 cmUuDQoqIEEgY29tbWVyY2lhbCBSQURJVVMgc2VydmVyIGltcGxlbWVudGF0aW9uIHNlbmRzIG5v dGhpbmcuDQoNCkl0IHNlZW1zIHJpZ2h0IHRvIGluZGljYXRlIGFuIEVBUC1GYWlsdXJlIHRvIHRo ZSBwZWVyIGluIHRoZSBjYXNlIG9mDQpubyBvdmVybGFwcGluZyBtZXRob2RzIChhcyB3ZWxsIGFz IHRvIHRlcm1pbmF0ZSB0aGUgTkFTJ3Mgb3V0c3RhbmRpbmcNClJBRElVUyBBY2Nlc3MtUmVxdWVz dCB3aXRoIGFuIEFjY2Vzcy1SZWplY3QpLCBhcyBpcyB0aGUgY2FzZSBmb3IgYQ0KbnVtYmVyIG9m IG90aGVyIGZhaWx1cmUgY29uZGl0aW9ucywgZS5nLiBhdXRoZW50aWNhdGlvbiBmYWlsdXJlDQoq d2l0aGluKiBhbiBFQVAgbWV0aG9kIChBcHBlbmRpeCBBIGJ5IHdheSBvZiBleGFtcGxlKSwgaW52 YWxpZCBwYWNrZXRzDQpsZWFkaW5nIHRvIGEgZmF0YWwgZXJyb3Igd2l0aGluIGFuIEVBUCBtZXRo b2QgKHNlY3Rpb24gMi4yKS4NCg0KUkZDIDM3NDggc2VjdGlvbiA0LjIgb24gU3VjY2VzcyBhbmQg RmFpbHVyZSBpbnRyb2R1Y2VzIHRoZXNlIG1lc3NhZ2VzDQp3aXRoaW4gdGhlIGNvbnRleHQgb2Yg ZmluYWxpc2luZyBhbiBvbmdvaW5nIEVBUCBtZXRob2Q6DQoNCiAgIFRoZSBTdWNjZXNzIHBhY2tl dCBpcyBzZW50IGJ5IHRoZSBhdXRoZW50aWNhdG9yIHRvIHRoZSBwZWVyIGFmdGVyDQogICBjb21w bGV0aW9uIG9mIGFuIEVBUCBhdXRoZW50aWNhdGlvbiBtZXRob2QgKFR5cGUgNCBvciBncmVhdGVy KSB0bw0KICAgaW5kaWNhdGUgdGhhdCB0aGUgcGVlciBoYXMgYXV0aGVudGljYXRlZCBzdWNjZXNz ZnVsbHkgdG8gdGhlDQogICBhdXRoZW50aWNhdG9yLiAgVGhlIGF1dGhlbnRpY2F0b3IgTVVTVCB0 cmFuc21pdCBhbiBFQVAgcGFja2V0IHdpdGgNCiAgIHRoZSBDb2RlIGZpZWxkIHNldCB0byAzIChT dWNjZXNzKS4gIElmIHRoZSBhdXRoZW50aWNhdG9yIGNhbm5vdA0KICAgYXV0aGVudGljYXRlIHRo ZSBwZWVyICh1bmFjY2VwdGFibGUgUmVzcG9uc2VzIHRvIG9uZSBvciBtb3JlDQogICBSZXF1ZXN0 cyksIHRoZW4gYWZ0ZXIgdW5zdWNjZXNzZnVsIGNvbXBsZXRpb24gb2YgdGhlIEVBUCBtZXRob2Qg aW4NCiAgIHByb2dyZXNzLCB0aGUgaW1wbGVtZW50YXRpb24gTVVTVCB0cmFuc21pdCBhbiBFQVAg cGFja2V0IHdpdGggdGhlDQogICBDb2RlIGZpZWxkIHNldCB0byA0IChGYWlsdXJlKS4NCg0KUGVy aGFwcyBvbmUgY2FuIGFyZ3VlIHRoYXQgYSBOQUsgaXMgYW4gdW5hY2NlcHRhYmxlIHJlc3BvbnNl IHRvIGFuDQpvbmdvaW5nIG1ldGhvZCBhbmQgdGhlcmVmb3JlIHRoZSBtZXRob2QgaXMgdW5zdWNj ZXNzZnVsbHkgY29tcGxldGVkIHNvDQphIEZhaWx1cmUgc2hvdWxkIGJlIGdlbmVyYXRlZD8gVGhh dCdzIG5vdCBlbnRpcmVseSBjbGVhciwgaWYgdGhhdCBpcw0KdGhlIGNhc2UuDQoNClJGQyAzNzQ4 IHNlY3Rpb24gNS4zLjEgdGhyb3dzIGluIHNvbWUgbW9yZSBkb3VidCwgaGF2aW5nIHRoZSBmb2xs b3dpbmcNCnRleHQgdGhhdCBkZWFscyBleHBsaWNpdGx5IHdpdGggdGhlIHBlZXIgc2VuZGluZyBh IE5BSyBjb250YWluaW5nICJubw0KZGVzaXJlZCBhbHRlcm5hdGl2ZSIgbWV0aG9kOg0KDQogICAg ICBUeXBlIHplcm8gKDApIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgc2VuZGVyIGhhcw0K ICAgICAgbm8gdmlhYmxlIGFsdGVybmF0aXZlcywgYW5kIHRoZXJlZm9yZSB0aGUgYXV0aGVudGlj YXRvciBTSE9VTEQgTk9UDQogICAgICBzZW5kIGFub3RoZXIgUmVxdWVzdCBhZnRlciByZWNlaXZp bmcgYSBOYWsgUmVzcG9uc2UgY29udGFpbmluZyBhDQogICAgICB6ZXJvIHZhbHVlLg0KDQpUaGF0 J3Mgc3BlY2lmaWMgdG8gb25lIGNhc2UgZm9yIHdoaWNoIGEgc3RyaWN0IHJlYWRpbmcgd291bGQg aW5kaWNhdGUNCnRoYXQgdGhlIEVBUCBzZXJ2ZXIgc2hvdWxkIHJlbWFpbiBxdWlldCBhbmQgY29u c2lkZXIgdGhlIEVBUA0KY29udmVyc2F0aW9uIHRvIGJlIGNvbXBsZXRlLiBJdCdzIHRlbXB0aW5n IHRvIHRoaW5rIHRoYXQgdGhlIHNhbWUNCnJlc3BvbnNlIChpLGUuIG5vIHJlc3BvbnNlISkgc2hv dWxkIGFwcGx5IG1vcmUgYnJvYWRseSBhcyBub25lIG9mIHRoZQ0KQUFBIGltcGxlbWVudGF0aW9u cyBJJ3ZlIHRlc3RlZCBhY3R1YWxseSBkaWZmZXJlbnRpYXRlIGJldHdlZW4gYSBOQUsNCndpdGgg bm8gZGVzaXJlZCBhbHRlcm5hdGl2ZSBtZXRob2QgdnMgYSBOQUsgd2l0aCBhbiBpbmNvbXBhdGli bGUgbGlzdA0Kb2YgYWx0ZXJuYXRpdmUgbWV0aG9kcy4gKEEgc3VidGxlIGRpZmZlcmVuY2UgbWln aHQgYmUgcmVsZXZhbnQ6IEluIHRoZQ0KY2FzZSBvZiBOQUsgLyBtZXRob2QgPSBbXSB0aGUgcGVl ciBrbm93cyB0aGF0IHRoZSBFQVAgY29udmVyc2lvbiBjYW4NCmdvIG5vIGZ1cnRoZXIsIHdoZXJl YXMgaW4gdGhlIGNhc2UgdGhhdCBpdCBzZW5kcyBhIGxpc3Qgb2YgbWV0aG9kcw0KdGhhdCB0aGUg QUFBIGhhcHBlbnMgdG8gbm90IHN1cHBvcnQgaXQgZG9lcyBub3Qga25vdyB0aGlzIHVubGVzcyBp dCBpcw0Kc3Vic2VxdWVudGx5IHRvbGQuKQ0KDQpJZiBJJ3ZlIG5vdCBtaXNzZWQgc29tZXRoaW5n IHRoZW4gdGhpcyBsb29rcyBhbiBvbWlzc2lvbiAob3IgbGFjayBvZg0KY2xhcml0eSkgYW5kIHRo ZSBpbnRlbmRlZCBBQUEgcmVzcG9uc2UgdG8gbm8gb3ZlcmxhcHBpbmcgbWV0aG9kcyAoYW5kDQpp bmRlZWQgIm5vIGRlc2lyZWQgYWx0ZXJuYXRpdmUiKSBzaG91bGQgYmUgZGVjaWRlZCBhbmQgY29k aWZpZWQuDQoNCg0KVGhhbmtzLA0KDQpUZXJyeQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkVtdSBtYWlsaW5nIGxpc3QNCkVtdUBpZXRmLm9y ZzxtYWlsdG86RW11QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lbXUNCg0K --_000_dc5042e36f07b1e3b0985063fb955f58ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgVGVycnks PC9wPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiA4LzIwLzIwIDM6MDIgUE0sIFRl cnJ5IEJ1cnRvbiB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNp dGU9Im1pZDpDQU5zaVhFK1lnalV6a2NwTmorTUpXMzNtTWR2R241NVNRSEdlT2ZtVTJEM0xBdEFC Q0FAbWFpbC5nbWFpbC5jb20iPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5P biBUaHUsIDIwIEF1ZyAyMDIwIGF0IDEwOjAwLCBNb2hpdCBTZXRoaSBNDQo8YSBjbGFzcz0ibW96 LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86bW9oaXQubS5zZXRoaT00MGVyaWNzc29u LmNvbUBkbWFyYy5pZXRmLm9yZyI+Jmx0O21vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1h cmMuaWV0Zi5vcmcmZ3Q7PC9hPiB3cm90ZToNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPkkgc3VyZWx5IG11c3QgYmUg bWlzc2luZyBzb21ldGhpbmcgaGVyZToNCg0KUGFja2V0IDYgaXMgYW4gRUFQLVJlc3BvbnNlIGZy b20gdGhlIHBlZXIuIFBhY2tldCA3IGNvbnRhaW5zIGFub3RoZXIgRUFQLVJlc3BvbnNlIGluc2lk ZSBhIFJBRElVUyBBY2Nlc3MtUmVxdWVzdD8gVGhhdCBkb2Vzbid0IG1ha2Ugc2Vuc2UuIEVBUCBp cyBsb2NrLXN0ZXAgcmVxdWVzdC1yZXNwb25zZSBwcm90b2NvbC4gVGhlIGNvbnZlcnNhdGlvbiB5 b3UgZGVzY3JpYmUgaXMgaW5jb3JyZWN0Lg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNs YXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPg0KSGksDQoNCk1heWJlIHlvdSB3ZXJlIHRocm93 biBieSBteSB0eXBvICh0byBtYWtlIHN1cmUgcmVhZGVycyB3ZXJlIGF3YWtlKS4gSXQNCnNob3Vs ZCBoYXZlIHJlYWQgJnF1b3Q7Ni4gUGVlciAtLSZndDsgTkFTJnF1b3Q7LCBpLmUuOjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KSW5kZWVkLiBJIG1pc3JlYWQgdGhlIHBhY2tldCBzZXF1ZW5jZSB0byBp bXBseSB0aGF0IHRoZSBzZXJ2ZXIgd2FzIHNlbmRpbmcgYW4gRUFQLVJlc3BvbnNlICh3aGljaCBp cyB3aHkgSSBoYWQgYSBkaXNjbGFpbWVyIGF0IHRoZSBiZWdpbm5pbmcgOikpLjxicj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpDQU5zaVhFK1lnalV6a2NwTmorTUpXMzNtTWR2 R241NVNRSEdlT2ZtVTJEM0xBdEFCQ0FAbWFpbC5nbWFpbC5jb20iPg0KPHByZSBjbGFzcz0ibW96 LXF1b3RlLXByZSIgd3JhcD0iIj4NCg0KNi4gUGVlciAtLSZndDsgTkFTOiBFQVAtUmVzcG9uc2Ug LyBFQVAtVHlwZT1OQUsgKE1ldGhvZHMgW0Jhcl0pDQo3LiBOQVMgLS0mZ3Q7IEFBQTogUkFESVVT IEFjY2Vzcy1SZXF1ZXN0IC8gRUFQLU1lc3NhZ2UgLyBFQVAtUmVzcG9uc2UgLw0KTkFLICggTWV0 aG9kcyBbIEJhciBdICkNCg0KUGFja2V0IDcgaXMganVzdCB0aGUgTkFTIGVuY2Fwc3VsYXRpbmcg dGhlIFBlZXIncyBOQUsgd2l0aGluIFJBRElVUw0KZm9yIHRoZSBBQUEsIG5vdCBhIHNlcGFyYXRl bHkgb3JpZ2luYXRpbmcgcmVxdWVzdC4gVGhlIGxhbmd1YWdlIGlzIHRoZQ0Kc2FtZSBhcyB0aGUg Zm91cnRoIGV4YW1wbGUgaW4gUkZDIDM1NzkgQXBwZW5kaXggQSwgaG93ZXZlciB0aGF0DQpleGFt cGxlIHNraXBzIHRoZSBpZGVudGl0eSBwaGFzZSBhbmQgZ29lcyBvbiB0byBzdWNjZXNzZnVsbHkg bmVnb3RpYXRlDQphIG1ldGhvZC4NCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+TXkgcmVhZGluZyBvZiBSRkMgMzc0 OCBpcyBjbGVhciB0aGF0IGFmdGVyIHJlY2VpdmluZyBhIE5BSyBmcm9tIHRoZSBwZWVyLCB0aGUg c2VydmVyIHNob3VsZCBzZW5kIGFub3RoZXIgRUFQLVJlcXVlc3Qgd2l0aCBhIGRpZmZlcmVudCBF QVAgbWV0aG9kIGlmIGl0cyBwb2xpY3kgYWxsb3dzIG9yIHRoZW4gc2VuZCBhIGZhaWx1cmUuIFRo ZSBzZXJ2ZXIgc2hvdWxkIGFsc28gc2VuZCBhIGZhaWx1cmUgaWYgdGhlIHBlZXIgTkFLIFR5cGUt RGF0YSB3YXMgMCAoaW5kaWNhdGluZyBubyBwcm9wb3NlZCBhbHRlcm5hdGl2ZSkuDQo8L3ByZT4N CjwvYmxvY2txdW90ZT4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+DQpJJ20g c3RpbGwgbm90IHNlZWluZyBhIGNsZWFyIHJlZmVyZW5jZSBmb3Igd2hhdCB0byBzZW5kIGluIHRo ZSBldmVudA0Kb2Ygbm8gb3ZlcmxhcHBpbmcgbWV0aG9kcyBmcm9tIHRoZSB0ZXh0IGluIHRoZXNl IFJGQ3MuDQoNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIGNsYXNzPSJt b3otcXVvdGUtcHJlIiB3cmFwPSIiPkZZSTogUkZDIDQxMzcgc2F5czoNCg0KICAgbyAgU2VuZGlu ZyBhIE5BSyB0byB0aGUgYXV0aGVudGljYXRvciBhZnRlciB0aGUgYXV0aGVudGljYXRvciBmaXJz dA0KICAgICAgcHJvcG9zZXMgYW4gRUFQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCB0byB0aGUgcGVl ci4gIFdoZW4gdGhlDQogICAgICBtZXRob2RTdGF0ZSB2YXJpYWJsZSBoYXMgdGhlIHZhbHVlIFBS T1BPU0VELCB0aGUgYXV0aGVudGljYXRvciBpcw0KICAgICAgb2JsaWdlZCB0byBwcm9jZXNzIGEg TkFLIHRoYXQgaXMgcmVjZWl2ZWQgaW4gcmVzcG9uc2UgdG8gaXRzIGZpcnN0DQogICAgICBwYWNr ZXQgb2YgYW4gRUFQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZC4NCg0Kc28gdGhlIGNvbW1lcmNpYWwg UkFESVVTIHNlcnZlciBpcyBpbiB2aW9sYXRpb24gaWYgaXQgZG9lc24ndCByZXNwb25kIHRvIGEg TkFLIGZyb20gdGhlIHBlZXIgd2l0aCBlaXRoZXIgYW5vdGhlciBFQVAtUmVxdWVzdCBvciBmYWls dXJlLg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3 cmFwPSIiPg0KVGhhdCdzIHJlbGV2YW50IGluIHRoZSBzZW5zZSB0aGF0IGl0IHJlc3RhdGVzIHRo YXQgaXQgaXMgYXBwcm9wcmlhdGUNCmZvciBhIHBlZXIgdG8gTkFLIHRoZSBzZXJ2ZXIncyBvcmln aW5hbCBtZXRob2Qgc2VsZWN0aW9uIGFuZCB0aGF0IHRoZQ0Kc2VydmVyIG11c3QgcHJvY2VzcyB0 aGUgTkFLLiBJdCBkb2Vzbid0IHN0YXRlIHdoYXQgaGFwcGVucyBvbiB0aGUgd2lyZQ0KKHNwZWNp ZmljYWxseSB0aGF0IGFuIEVBUC1GYWlsdXJlIGlzIHNlbnQgdG8gdGhlIHBlZXIsIGFzIHNlZW1z IHRvIGJlDQp0aGUgY2FzZSBpbiBwcmFjdGlzZSkgYXMgYSByZXN1bHQgb2YgdGhpcyBwcm9jZXNz aW5nLg0KDQpJdCdzIGFsc28gY29udHJhcnkgdG8uLi4NCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+ICAgICAgVHlw ZSB6ZXJvICgwKSBpcyB1c2VkIHRvIGluZGljYXRlIHRoYXQgdGhlIHNlbmRlciBoYXMNCiAgICAg IG5vIHZpYWJsZSBhbHRlcm5hdGl2ZXMsIGFuZCB0aGVyZWZvcmUgdGhlIGF1dGhlbnRpY2F0b3Ig U0hPVUxEIE5PVA0KICAgICAgc2VuZCBhbm90aGVyIFJlcXVlc3QgYWZ0ZXIgcmVjZWl2aW5nIGEg TmFrIFJlc3BvbnNlIGNvbnRhaW5pbmcgYQ0KICAgICAgemVybyB2YWx1ZS4NCjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4NCi4uLi4gdW5s ZXNzIHRoZSBsYW5ndWFnZSBpcyBsb29zZSBhbmQgd2Ugc2F5IHRoYXQgYW4gRUFQLUZhaWx1cmUN CnJlcXVlc3QgaXNuJ3QgYWN0dWFsbHkgYSAmcXVvdDtSZXF1ZXN0JnF1b3Q7LCBidXQgdGhhdCdz IGhhcmQgdG8gYXJndWUgZHVlIHRvDQpjYXBpdGFsICZxdW90O1ImcXVvdDtlcXVlc3QuPC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQpXaHkgaXMgRUFQLUZhaWx1cmUgYSByZXF1ZXN0PyBJdCdzIGFuIEVB UCBwYWNrZXQgd2l0aCBhIGRpZmZlcmVudCBDb2RlPyBTbyB0aGUgU0hPVUxEIE5PVCBkb2Vzbid0 IGZvcmJpZCB0aGUgc2VydmVyIGZyb20gc2VuZGluZyBhbiBFQVAtRmFpbHVyZS4gUkZDIDM3NDgg ZXZlbiBjYWxscyBGYWlsdXJlIGFzIGEgcmVzcG9uc2U6ICZxdW90O0FuIGF1dGhlbnRpY2F0b3Ig TUFZIHdpc2ggdG8gaXNzdWUgbXVsdGlwbGUgUmVxdWVzdHMgYmVmb3JlIHNlbmRpbmcNCiBhIEZh aWx1cmUgPGI+cmVzcG9uc2U8L2I+IGluIG9yZGVyIHRvIGFsbG93IGZvciBodW1hbiB0eXBpbmcg bWlzdGFrZXMuJnF1b3Q7PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkNB TnNpWEUrWWdqVXprY3BOaitNSlczM21NZHZHbjU1U1FIR2VPZm1VMkQzTEF0QUJDQUBtYWlsLmdt YWlsLmNvbSI+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPg0KDQpOZXZlcnRo ZWxlc3MsIFJGQyA0MTM3IEFwcGVuZGl4IEEuMi4gYW5kIEEuMy4gaXMgY2xlYXIgb24gd2hhdCB0 byBkbzoNCg0KKiBXaGVuIHRoZSBwZWVyIHNlbmRzIGEgTkFLIHdpdGggbm8gYWx0ZXJuYXRpdmVz IHdlIGFyZSBpbiBSRUNFSVZFRC4NCiogSW4gUkVDRUlWRUQ6IHJlc3BNZXRob2QgPT0gTkFLIHRo ZXJlZm9yZSB3ZSB0cmFuc2l0aW9uIHRvIE5BSy4NCiogSW4gTkFLOiBXZSB1cGRhdGUgdGhlIHBv bGljeSB0byBleGNsdWRlIHRoZSBOQUtlZCBtZXRob2QgYW5kDQp0cmFuc2l0aW9uIHRvIFNFTEVD VF9BQ1RJT04uDQoqIEluIFNFTEVDVF9BQ1RJT046IHRoZSByZXN1bHQgb2YgUG9saWN5LmdldERl Y2lzaW9uKCkgaXMgcHJlc3VtYWJseQ0KRkFJTFVSRSBmb3Igbm8gb3ZlcmxhcHBpbmcgbWV0aG9k cy4gVHJhbnNpdGlvbiB0byBGQUlMVVJFLg0KKiBJbiBGQUlMVVJFOiBXZSBidWlsZCBhIGZhaWx1 cmUgcmVzcG9uc2UuDQoNCkkgbm90ZSB0aGF0IGJvdGggcmVjZWl2aW5nIGEgTkFLIChSRUNFSVZF RCAtJmd0OyBOQUsgLSZndDsgU0VMRUNUX0FDVElPTiAtJmd0Ow0KRkFJTFVSRSB0cmFuc2l0aW9u KSBhbmQgcmVjZWl2aW5nIGFuIHVuYWNjZXB0YWJsZSBtZXRob2QgcmVzcG9uc2UNCihSRUNFSVZF RCAtJmd0OyBJTlRFR1JJVFlfQ0hFQ0sgLSZndDsgTUVUSE9EX1JFU1BPTlNFIC0mZ3Q7IFNFTEVD VF9BQ1RJT04NCnRyYW5zaXRpb24pIHVsdGltYXRlbHkgYXJyaXZlIGF0IHRoZSBzYW1lIEZBSUxV UkUgc3RhdGUgdGhhdCBidWlsZHMgYQ0KRUFQLUZhaWx1cmUgcGFja2V0LiBJdCBhcHBlYXJzIHRo YXQgdGhlIGFncmVlZCB1cG9uIGJlaGF2aW91ciBpcw0KY29kaWZpZWQgaGVyZS4NCg0KSXRzIGJl aGF2aW91ciBhbHNvIGRvZXMgbm90IGRpZmZlcmVudGlhdGUgYmV0d2VlbiBhIHBlZXIgTkFLIG9m ICZxdW90O3R5cGUNCjAmcXVvdDsgYW5kIG9uZSBjb250YWluaW5nIGEgbGlzdCBvZiBhbHRlcm5h dGl2ZSBtZXRob2RzLjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+VGhpcyBzZWVtcyB0byBiZSB0 aGUgY29ycmVjdCBiZWhhdmlvciAoYXQgbGVhc3QgZm9yIG1lKS4mbmJzcDsgPGJyPg0KPC9wPg0K PHA+LS1Nb2hpdDxicj4NCjwvcD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpD QU5zaVhFK1lnalV6a2NwTmorTUpXMzNtTWR2R241NVNRSEdlT2ZtVTJEM0xBdEFCQ0FAbWFpbC5n bWFpbC5jb20iPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4NCg0KDQpUZXJy eQ0KDQoNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIGNsYXNzPSJtb3ot cXVvdGUtcHJlIiB3cmFwPSIiPk9uIDgvMjAvMjAgMzozOSBBTSwgVGVycnkgQnVydG9uIHdyb3Rl Og0KDQpIaSwNCg0KSSdtIHVuYWJsZSB0byBmaW5kIHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSB0 aGF0IHN0YXRlIGV4YWN0bHkgaG93IHRoZQ0KZm9sbG93aW5nIGNvbnZlcnNhdGlvbiBjb250aW51 ZXMgKFRMO0RSOyB0aGUgcGVlciBOQUtzIHRoZSBvcmlnaW5hbA0KbWV0aG9kIGFuZCB0aGUgQUFB IGRvZXNuJ3Qgc3VwcG9ydCBhbnkgb2YgdGhlIHBlZXIncyBwcm9wb3NhbHMpOg0KDQoxLiBOQVMg LS0mZ3Q7IFBlZXIgOiBFQVAtUmVxdWVzdCAvIElkZW50aXR5DQoyLiBQZWVyIC0tJmd0OyBOQVMg OiBFQVAtUmVzcG9uc2UgLyBJZGVudGl0eSAoIElEICkNCjMuIE5BUyAtLSZndDsgQUFBOiBSQURJ VVMgQWNjZXNzLVJlcXVlc3QgLyBFQVAtTWVzc2FnZSAvIEVBUC1SZXNwb25zZSAvDQpJZGVudGl0 eSAoIElEICkNCjQuIEFBQSAtLSZndDsgTkFTOiAgUkFESVVTIEFjY2Vzcy1DaGFsbGVuZ2UgLyBF QVAtTWVzc2FnZSAvIEVBUC1SZXF1ZXN0IC8NCk1ldGhvZCBGb28NCjUuIE5BUyAtLSZndDsgUGVl cjogRUFQLVJlcXVlc3QgLyBNZXRob2QgRm9vDQo2LiBQZWVyIC0tJmd0OyBOQUs6IEVBUC1SZXNw b25zZSAvIEVBUC1UeXBlPU5BSyAoTWV0aG9kcyBbQmFyXSkNCjcuIE5BUyAtLSZndDsgQUFBOiBS QURJVVMgQWNjZXNzLVJlcXVlc3QgLyBFQVAtTWVzc2FnZSAvIEVBUC1SZXNwb25zZSAvDQpOQUsg KCBNZXRob2RzIFsgQmFyIF0gKQ0KKCogTGV0J3MgYXNzdW1lIHRoYXQgdGhlIEFBQSBkb2VzIG5v dCBzdXBwb3J0IE1ldGhvZCBCYXIgc28gd2UgaGF2ZQ0KZGVyaXZlZCB0aGF0IHRoZXJlIGFyZSBu byBvdmVybGFwcGluZyBtZXRob2RzLikNCjguIEFBQTogTm93IHdoYXQ/DQoNCkkndmUgcmV2aWV3 ZWQgUkZDIDM3NDggKEVBUCkgYW5kIFJGQyAzNTc5IChSQURJVVMgU3VwcG9ydCBGb3IgRUFQKSBh bmQNCm5laXRoZXIgc2VlbXMgdG8gYmUgZXhwbGljaXQgYWJvdXQgd2hhdCB0aGUgQUFBIHNob3Vs ZCBkbyBpbiByZXNwb25zZQ0KdG8gYSBOQUsgaW4gdGhlIGV2ZW50IG9mIG5vIG92ZXJsYXBwaW5n IG1ldGhvZHMuDQoNCkluIHByYWN0aXNlOg0KDQoqIEZyZWVSQURJVVMgc2VuZHMgUkFESVVTIEFj Y2Vzcy1SZWplY3QgLyBFQVAtTWVzc2FnZSAvIEVBUC1GYWlsdXJlLg0KKiBob3N0YXBkJ3MgUkFE SVVTIHNlcnZlciBzZW5kcyBSQURJVVMgQWNjZXNzLVJlamVjdCAvIEVBUC1NZXNzYWdlIC8NCkVB UC1GYWlsdXJlLg0KKiBBIGNvbW1lcmNpYWwgUkFESVVTIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBz ZW5kcyBub3RoaW5nLg0KDQpJdCBzZWVtcyByaWdodCB0byBpbmRpY2F0ZSBhbiBFQVAtRmFpbHVy ZSB0byB0aGUgcGVlciBpbiB0aGUgY2FzZSBvZg0Kbm8gb3ZlcmxhcHBpbmcgbWV0aG9kcyAoYXMg d2VsbCBhcyB0byB0ZXJtaW5hdGUgdGhlIE5BUydzIG91dHN0YW5kaW5nDQpSQURJVVMgQWNjZXNz LVJlcXVlc3Qgd2l0aCBhbiBBY2Nlc3MtUmVqZWN0KSwgYXMgaXMgdGhlIGNhc2UgZm9yIGENCm51 bWJlciBvZiBvdGhlciBmYWlsdXJlIGNvbmRpdGlvbnMsIGUuZy4gYXV0aGVudGljYXRpb24gZmFp bHVyZQ0KKndpdGhpbiogYW4gRUFQIG1ldGhvZCAoQXBwZW5kaXggQSBieSB3YXkgb2YgZXhhbXBs ZSksIGludmFsaWQgcGFja2V0cw0KbGVhZGluZyB0byBhIGZhdGFsIGVycm9yIHdpdGhpbiBhbiBF QVAgbWV0aG9kIChzZWN0aW9uIDIuMikuDQoNClJGQyAzNzQ4IHNlY3Rpb24gNC4yIG9uIFN1Y2Nl c3MgYW5kIEZhaWx1cmUgaW50cm9kdWNlcyB0aGVzZSBtZXNzYWdlcw0Kd2l0aGluIHRoZSBjb250 ZXh0IG9mIGZpbmFsaXNpbmcgYW4gb25nb2luZyBFQVAgbWV0aG9kOg0KDQogICBUaGUgU3VjY2Vz cyBwYWNrZXQgaXMgc2VudCBieSB0aGUgYXV0aGVudGljYXRvciB0byB0aGUgcGVlciBhZnRlcg0K ICAgY29tcGxldGlvbiBvZiBhbiBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9kIChUeXBlIDQgb3Ig Z3JlYXRlcikgdG8NCiAgIGluZGljYXRlIHRoYXQgdGhlIHBlZXIgaGFzIGF1dGhlbnRpY2F0ZWQg c3VjY2Vzc2Z1bGx5IHRvIHRoZQ0KICAgYXV0aGVudGljYXRvci4gIFRoZSBhdXRoZW50aWNhdG9y IE1VU1QgdHJhbnNtaXQgYW4gRUFQIHBhY2tldCB3aXRoDQogICB0aGUgQ29kZSBmaWVsZCBzZXQg dG8gMyAoU3VjY2VzcykuICBJZiB0aGUgYXV0aGVudGljYXRvciBjYW5ub3QNCiAgIGF1dGhlbnRp Y2F0ZSB0aGUgcGVlciAodW5hY2NlcHRhYmxlIFJlc3BvbnNlcyB0byBvbmUgb3IgbW9yZQ0KICAg UmVxdWVzdHMpLCB0aGVuIGFmdGVyIHVuc3VjY2Vzc2Z1bCBjb21wbGV0aW9uIG9mIHRoZSBFQVAg bWV0aG9kIGluDQogICBwcm9ncmVzcywgdGhlIGltcGxlbWVudGF0aW9uIE1VU1QgdHJhbnNtaXQg YW4gRUFQIHBhY2tldCB3aXRoIHRoZQ0KICAgQ29kZSBmaWVsZCBzZXQgdG8gNCAoRmFpbHVyZSku DQoNClBlcmhhcHMgb25lIGNhbiBhcmd1ZSB0aGF0IGEgTkFLIGlzIGFuIHVuYWNjZXB0YWJsZSBy ZXNwb25zZSB0byBhbg0Kb25nb2luZyBtZXRob2QgYW5kIHRoZXJlZm9yZSB0aGUgbWV0aG9kIGlz IHVuc3VjY2Vzc2Z1bGx5IGNvbXBsZXRlZCBzbw0KYSBGYWlsdXJlIHNob3VsZCBiZSBnZW5lcmF0 ZWQ/IFRoYXQncyBub3QgZW50aXJlbHkgY2xlYXIsIGlmIHRoYXQgaXMNCnRoZSBjYXNlLg0KDQpS RkMgMzc0OCBzZWN0aW9uIDUuMy4xIHRocm93cyBpbiBzb21lIG1vcmUgZG91YnQsIGhhdmluZyB0 aGUgZm9sbG93aW5nDQp0ZXh0IHRoYXQgZGVhbHMgZXhwbGljaXRseSB3aXRoIHRoZSBwZWVyIHNl bmRpbmcgYSBOQUsgY29udGFpbmluZyAmcXVvdDtubw0KZGVzaXJlZCBhbHRlcm5hdGl2ZSZxdW90 OyBtZXRob2Q6DQoNCiAgICAgIFR5cGUgemVybyAoMCkgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBzZW5kZXIgaGFzDQogICAgICBubyB2aWFibGUgYWx0ZXJuYXRpdmVzLCBhbmQgdGhlcmVm b3JlIHRoZSBhdXRoZW50aWNhdG9yIFNIT1VMRCBOT1QNCiAgICAgIHNlbmQgYW5vdGhlciBSZXF1 ZXN0IGFmdGVyIHJlY2VpdmluZyBhIE5hayBSZXNwb25zZSBjb250YWluaW5nIGENCiAgICAgIHpl cm8gdmFsdWUuDQoNClRoYXQncyBzcGVjaWZpYyB0byBvbmUgY2FzZSBmb3Igd2hpY2ggYSBzdHJp Y3QgcmVhZGluZyB3b3VsZCBpbmRpY2F0ZQ0KdGhhdCB0aGUgRUFQIHNlcnZlciBzaG91bGQgcmVt YWluIHF1aWV0IGFuZCBjb25zaWRlciB0aGUgRUFQDQpjb252ZXJzYXRpb24gdG8gYmUgY29tcGxl dGUuIEl0J3MgdGVtcHRpbmcgdG8gdGhpbmsgdGhhdCB0aGUgc2FtZQ0KcmVzcG9uc2UgKGksZS4g bm8gcmVzcG9uc2UhKSBzaG91bGQgYXBwbHkgbW9yZSBicm9hZGx5IGFzIG5vbmUgb2YgdGhlDQpB QUEgaW1wbGVtZW50YXRpb25zIEkndmUgdGVzdGVkIGFjdHVhbGx5IGRpZmZlcmVudGlhdGUgYmV0 d2VlbiBhIE5BSw0Kd2l0aCBubyBkZXNpcmVkIGFsdGVybmF0aXZlIG1ldGhvZCB2cyBhIE5BSyB3 aXRoIGFuIGluY29tcGF0aWJsZSBsaXN0DQpvZiBhbHRlcm5hdGl2ZSBtZXRob2RzLiAoQSBzdWJ0 bGUgZGlmZmVyZW5jZSBtaWdodCBiZSByZWxldmFudDogSW4gdGhlDQpjYXNlIG9mIE5BSyAvIG1l dGhvZCA9IFtdIHRoZSBwZWVyIGtub3dzIHRoYXQgdGhlIEVBUCBjb252ZXJzaW9uIGNhbg0KZ28g bm8gZnVydGhlciwgd2hlcmVhcyBpbiB0aGUgY2FzZSB0aGF0IGl0IHNlbmRzIGEgbGlzdCBvZiBt ZXRob2RzDQp0aGF0IHRoZSBBQUEgaGFwcGVucyB0byBub3Qgc3VwcG9ydCBpdCBkb2VzIG5vdCBr bm93IHRoaXMgdW5sZXNzIGl0IGlzDQpzdWJzZXF1ZW50bHkgdG9sZC4pDQoNCklmIEkndmUgbm90 IG1pc3NlZCBzb21ldGhpbmcgdGhlbiB0aGlzIGxvb2tzIGFuIG9taXNzaW9uIChvciBsYWNrIG9m DQpjbGFyaXR5KSBhbmQgdGhlIGludGVuZGVkIEFBQSByZXNwb25zZSB0byBubyBvdmVybGFwcGlu ZyBtZXRob2RzIChhbmQNCmluZGVlZCAmcXVvdDtubyBkZXNpcmVkIGFsdGVybmF0aXZlJnF1b3Q7 KSBzaG91bGQgYmUgZGVjaWRlZCBhbmQgY29kaWZpZWQuDQoNCg0KVGhhbmtzLA0KDQpUZXJyeQ0K PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIi Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVtdSBt YWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1h aWx0bzpFbXVAaWV0Zi5vcmciPkVtdUBpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJtb3otdHh0LWxp bmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZW11Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdTwvYT4NCjwvcHJl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_dc5042e36f07b1e3b0985063fb955f58ericssoncom_-- From nobody Thu Aug 20 06:07:42 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 573233A08CD for ; Thu, 20 Aug 2020 06:07:41 -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, RCVD_IN_DNSWL_BLOCKED=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 JR0a0Y4wvRNy for ; Thu, 20 Aug 2020 06:07:39 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 D0A0A3A08C4 for ; Thu, 20 Aug 2020 06:07:39 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id u24so1775191oic.7 for ; Thu, 20 Aug 2020 06:07:39 -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; bh=MHHRKxoh8sYIECZVHmCNwXUJIYv+bSvUFDL1myDzoJc=; b=V7+SJef95u9sZEVeEv4uALAAHGhcC5heeKWk/N64ZMBD/95zLv5ChnJv43dv4TmREN Q/pSUBNlZRmxAQQc3tfkT3+ssTYOe28z/c0AxUkKESL2bRe67Pv3D/cUU/Laur+WhBj1 T2THW8WVYH5Veuuoyl+zgaL2ljtu49XdMDPtdmN59R/Tn5IR7KmUNTzG/GE2yk15Zbxm OadgRNsiltPYKN5gecyOApE6kwLIsY80QrHgqGxcntirNxb+kxX6QG6+equQTJM7LKRj YhxjxZ7kMHp7ouHueGCN28nCshlwjItP44Ba1x86IbsnL22iJxO4qUIzigpicVT/AImT qxVg== 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; bh=MHHRKxoh8sYIECZVHmCNwXUJIYv+bSvUFDL1myDzoJc=; b=oigp3jwS4K3aituVWp7/lytSzS1+meVUhwBu4lt9mwO01YS3W8zTiN+a6S6X1SOam/ wN0haiRim9JmVtE1GPK368v5o60LrWBSJGuEyUNxQDheuwsL+lET/FYjXEzq2wQzFq5C y0c/H+mIyqH7ZN3PRpp1MQhP9s3NtmgQZpOPBrUuik5vjQLs9O2zQdl/xRrq9NZdlLvl PU50++t7DCOcWPxoJ+718BICtTJHXZv7ogqG9VcMkacH8c87F9Y2Z2eqnbC8zQdwO9lt D0CoWznRLN9Iu4wERBKHXanNLCI/cBaSVrh18+6KQMIOzIF3TIG9lGocsmdw4PSVf3T5 iCUQ== X-Gm-Message-State: AOAM532DUXHg7KOFfgE9VTlyyj7ZfXRhL0u9dB2J5N2LbrrugUWCOnpx YAnQ/30Y8k8qTtxhaoE2aR/X2Pww1pMJoDJXGb6VCavqlxI= X-Google-Smtp-Source: ABdhPJz8oJ2J4MbJ90hX21IkgMBi9dgT/8XDDODv1JILq4XEhC6qvozWFx5H9WW3/tEcL9EwA8IhCnwSltO60PK67a0= X-Received: by 2002:aca:a8c4:: with SMTP id r187mr1621549oie.113.1597928858657; Thu, 20 Aug 2020 06:07:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Oleg Pekar Date: Thu, 20 Aug 2020 16:07:27 +0300 Message-ID: To: EMU WG , tez@terryburton.co.uk Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Emu] Fwd: Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 20 Aug 2020 13:07:41 -0000 Hi Terry >In practise: > >* FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure. >* hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message / EAP-Failure. >* A commercial RADIUS server implementation sends nothing. Cisco Identity Services Engine RADIUS also returns RADIUS Access-Reject / EAP-Message / EAP-Failure in this case. Not sure that if AAA server will send a list of his allowed protocols in reply to NAK - the EAP client would be able to use it. Usually credentials are configured per protocol and not always interchangeable. So if the client wants EAP-GTC as an inner method in PEAP and claims this in an inner EAP NAK message and the server will reply that it has EAP-MSCHAPv2 and EAP-TLS inner methods - client can be unable to leverage this info. -Oleg On Thu, Aug 20, 2020 at 3:39 AM Terry Burton wrote: > > Hi, > > I'm unable to find the authoritative source that state exactly how the > following conversation continues (TL;DR; the peer NAKs the original > method and the AAA doesn't support any of the peer's proposals): > > 1. NAS --> Peer : EAP-Request / Identity > 2. Peer --> NAS : EAP-Response / Identity ( ID ) > 3. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / > Identity ( ID ) > 4. AAA --> NAS: RADIUS Access-Challenge / EAP-Message / EAP-Request / > Method Foo > 5. NAS --> Peer: EAP-Request / Method Foo > 6. Peer --> NAK: EAP-Response / EAP-Type=NAK (Methods [Bar]) > 7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / > NAK ( Methods [ Bar ] ) > (* Let's assume that the AAA does not support Method Bar so we have > derived that there are no overlapping methods.) > 8. AAA: Now what? > > I've reviewed RFC 3748 (EAP) and RFC 3579 (RADIUS Support For EAP) and > neither seems to be explicit about what the AAA should do in response > to a NAK in the event of no overlapping methods. > > In practise: > > * FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure. > * hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message / > EAP-Failure. > * A commercial RADIUS server implementation sends nothing. > > It seems right to indicate an EAP-Failure to the peer in the case of > no overlapping methods (as well as to terminate the NAS's outstanding > RADIUS Access-Request with an Access-Reject), as is the case for a > number of other failure conditions, e.g. authentication failure > *within* an EAP method (Appendix A by way of example), invalid packets > leading to a fatal error within an EAP method (section 2.2). > > RFC 3748 section 4.2 on Success and Failure introduces these messages > within the context of finalising an ongoing EAP method: > > The Success packet is sent by the authenticator to the peer after > completion of an EAP authentication method (Type 4 or greater) to > indicate that the peer has authenticated successfully to the > authenticator. The authenticator MUST transmit an EAP packet with > the Code field set to 3 (Success). If the authenticator cannot > authenticate the peer (unacceptable Responses to one or more > Requests), then after unsuccessful completion of the EAP method in > progress, the implementation MUST transmit an EAP packet with the > Code field set to 4 (Failure). > > Perhaps one can argue that a NAK is an unacceptable response to an > ongoing method and therefore the method is unsuccessfully completed so > a Failure should be generated? That's not entirely clear, if that is > the case. > > RFC 3748 section 5.3.1 throws in some more doubt, having the following > text that deals explicitly with the peer sending a NAK containing "no > desired alternative" method: > > Type zero (0) is used to indicate that the sender has > no viable alternatives, and therefore the authenticator SHOULD NOT > send another Request after receiving a Nak Response containing a > zero value. > > That's specific to one case for which a strict reading would indicate > that the EAP server should remain quiet and consider the EAP > conversation to be complete. It's tempting to think that the same > response (i,e. no response!) should apply more broadly as none of the > AAA implementations I've tested actually differentiate between a NAK > with no desired alternative method vs a NAK with an incompatible list > of alternative methods. (A subtle difference might be relevant: In the > case of NAK / method = [] the peer knows that the EAP conversion can > go no further, whereas in the case that it sends a list of methods > that the AAA happens to not support it does not know this unless it is > subsequently told.) > > If I've not missed something then this looks an omission (or lack of > clarity) and the intended AAA response to no overlapping methods (and > indeed "no desired alternative") should be decided and codified. > > > Thanks, > > Terry > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From nobody Thu Aug 20 06:27:16 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 0A8083A0A3C for ; Thu, 20 Aug 2020 06:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_FROM=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 w3LnQISpARa4 for ; Thu, 20 Aug 2020 06:27:13 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 59DE93A0A3D for ; Thu, 20 Aug 2020 06:27:13 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id q68so570737uaq.0 for ; Thu, 20 Aug 2020 06:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=EAfv81ySpc/35q0uCT1Gb8RMwQcwqcUWASoXsyoFbhs=; b=NqnG97bFHPF81NHd/NPe/JXmLzEVCF5xVrTIYABObTj2sjKn6fhitqNn5cI4l+KxNQ 73zQvktgm5wY9H+e1fzB5UOJ3sDPYt3PyPIqGy1aWVj9Y3xRX23nMUERzPfr3vQxhFUW dm78jyBJiQsgJM9mT51yFcYMPs5FjJQzA8/gPvtyqgJ+TAjHcFav3xSOAQb6A+5o7wpr ycmaZY1DdFaxXEOjucJ7oSIrcGcT916SNA6BDkN69amyxB230oCM0VqRlLbs7mD5pprA ryyhg2gB/i0j66I5JIi/Do6o2BEdJoMTjKgCsZvxiRf4RYPRmfg+vOvQ4pPeSBm6165B TH8g== 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=EAfv81ySpc/35q0uCT1Gb8RMwQcwqcUWASoXsyoFbhs=; b=alcezFxw10qOnyaXMxCm2Z1it46J4u4yXyATkOflUIQ6nMt35Wmcf0a3wF+iumgiHt SVzlO5sHpQjpX++OdpWsH69ZxZwldnIjl7SKQaMRs6GJ4FCAgqLCFlqwogWMahnH+pWp fJnEqEeaTm7xdV5FXCLzsc4HnBKC7MnegU6YFpoGkPT3cFxKPmqG/dMrz/Yky90xyruA w/ZbdP+6tg1z3JyBtXMvgippip/dh7oNf+l9aJj7ukQX4JeGTVNAcE7G6qXedRUfLliH ZqPatNqjfZRJmhywRJOU1TUXi2qROcamuhksK0bhB2wD1DzjE1sTTemlxE50soyGgTXe CRBA== X-Gm-Message-State: AOAM531Wla8A+NzMVgCO0S1oz3a3DiYwRtXjJIv1eEUwMgGyJcxG8Cjf sXTqv0eYt2a8kGl9h8KSrkCH2KHa+h4BI1VW9IWaIPtrzPs= X-Google-Smtp-Source: ABdhPJwfjdn2IntZ1leozOFtqDT3KpD7GGiJKfu6Bz445nBmD8PUph9ufXXNXU0ZDzCkLWA8+uVu2tMoTEMXQKyyx6A= X-Received: by 2002:ab0:6585:: with SMTP id v5mr1580652uam.73.1597930032238; Thu, 20 Aug 2020 06:27:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: tez@terryburton.co.uk From: Terry Burton Date: Thu, 20 Aug 2020 14:26:36 +0100 Message-ID: To: Mohit Sethi M Cc: "emu@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 20 Aug 2020 13:27:15 -0000 On Thu, 20 Aug 2020 at 13:34, Mohit Sethi M wrote: <...snip...> > It's also contrary to... > > Type zero (0) is used to indicate that the sender has > no viable alternatives, and therefore the authenticator SHOULD NOT > send another Request after receiving a Nak Response containing a > zero value. > > .... unless the language is loose and we say that an EAP-Failure > request isn't actually a "Request", but that's hard to argue due to > capital "R"equest. > > Why is EAP-Failure a request? It's an EAP packet with a different Code? S= o the SHOULD NOT doesn't forbid the server from sending an EAP-Failure. RFC= 3748 even calls Failure as a response: "An authenticator MAY wish to issue= multiple Requests before sending a Failure response in order to allow for = human typing mistakes." That's a small "r"esponse and I'd dare to say that even that usage isn't particularly helpful! :-) I think it's well established that any message from the authenticator to the peer (Code =3D 1) is an "R"equest and that any message from the peer to the authenticator (Code =3D 2) is an EAP "R"esponse. NAK is just a "Type" of Request / Response (depending on direction). So when the above text mentions "R"equest it actually refers to EAP packets with Code =3D 1, i.e. it says (seemingly erroneously as Alan points out) that no further messages of any type should be sent from the authenticator to the peer within the conversation. From nobody Thu Aug 20 06:54:08 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 452573A0ABE for ; Thu, 20 Aug 2020 06:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 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, NICE_REPLY_A=-0.949, 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 OEfS8fZtbvhb for ; Thu, 20 Aug 2020 06:54:06 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2080.outbound.protection.outlook.com [40.107.22.80]) (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 A257E3A0ABD for ; Thu, 20 Aug 2020 06:54:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LN7JArGAMuHGdQFzUHXMRPDhFuyYHwAFNCkxbWkGG3tCB8Z0uBglvPDd15cOqq3Lteep7SNItz6+CBLFElhsYcTtGvyO5aWfc/zJ68sRPHAkbkPrIfkk258+pBpeFwf+Xo9vZEOs8BadZNxXC97RC+ulAmRGIrTou8TFXRPrr+DuPufm0qkwkwOxwJ4zq+cENVQvNCwVQKXVW2gHEYluBT3d132ko/pVokxk9HmhdufR13SdmOWsui/TdJUKQm0+MXZpFXSUBwu7Kl1aHmIHBb3g4tCjjRNC4TnmO0HKJWvzhliGQVtDNhOEHaaP5IX+5kn+ofTMwrkRrD6EfcKGew== 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=uUPcDLoytETwxn0YLTFRCRk+hbdjF+9NWgsaIKxMu3U=; b=H94PDNu6IIAMajCVYUDLbA1dqi+mEQ0oYBazYT+Qjkjiiq5kfb1teEOKGLNtvju8ZWtz90oTybCLGzB1UzhjTqCAmJxPZUYegNxbX+dR5CO2Wpw3sMU5RhrGD0EYIsLjkhkMOJF1xq1ZeDaQkCvbZGT1Z+1qDKwfAs5gxrEwg+qoefv1l1W11InHutJug0ZH8cRcvP3xIoVCednB8yRwmdUwpwVGJWwdFNPtuL/zMUiVLNoYB1RQA5WrBzj8/3lTETvvygwr67PK2aYyBxGeNIfHGQ6nIL4oPprDTfzipORKgOIcHU9VUCZUQecc2opz2TYkEbrZlvHcb4hJvOqBVQ== 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=uUPcDLoytETwxn0YLTFRCRk+hbdjF+9NWgsaIKxMu3U=; b=QB1DaV87W6Z655dQFOvr4DgT6vxFB9tAy/l0kZjfxjnKbwfBEsGTGva/tG+fkySAwFH/3ErYF81dOPdI19D5zEcajX19Y73RxBSpFTH7y4yayUivDiinjce35XeibWjU0jbW+i1iQw+Hms0R1cwj2Z49t7ClZCCWHURvEZStP0s= Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Thu, 20 Aug 2020 13:54:02 +0000 Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6%5]) with mapi id 15.20.3305.021; Thu, 20 Aug 2020 13:54:02 +0000 From: Mohit Sethi M To: "tez@terryburton.co.uk" CC: "emu@ietf.org" Thread-Topic: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods Thread-Index: AQHWdtBd6/Chl5vFm0Cl50TEYc0wYalA5faAgAAI2ACAAA6fAIAAB6mA Date: Thu, 20 Aug 2020 13:54:02 +0000 Message-ID: <4f300bbd-f37b-3b1b-7aee-7e6c448a077d@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.10.0 authentication-results: terryburton.co.uk; dkim=none (message not signed) header.d=none;terryburton.co.uk; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:190:2a7d:eafd:b986:ec2:5e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e58c97e-fbd8-4bc4-ca72-08d845107f2e x-ms-traffictypediagnostic: HE1PR0701MB3050: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sMrft09q5xAUISUMtR1syaM5/HBwd13mz30nsmvouSXQANfexonS/7ZDzTYZ0GzlVIc5ia6B4oyNOTIbIUpYMsfCbMWd/lXzU82VLS2Hs6bv0e9Mgc5nZzEU7yRN7uQVRH83Jm4IjgNDlPro1CZRDdscsKeO5iYHqPwsmMNEALzFEBJ6EKo6UBzsJ9zSASboMZ5SxutBTlqWKwjPUsl5DzX31zeye053NLGK5EE0MI6UB3ypYdh+YGyF8HTgQ4vITyoWM2jfByT6ikHOQQCxZkBxNr4MYUoAcC2KhENNQQ4C/B8d/mK4RnGEQPTnA5Hjz6ihGQPwlcNVtQmrM+J5JU/rwVRD/RQ5vuPFsp5RgBvKxODWVuLVnosckx7WECTx x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39860400002)(136003)(376002)(366004)(6486002)(76116006)(66556008)(66476007)(5660300002)(66446008)(6506007)(316002)(31696002)(53546011)(8676002)(6916009)(66946007)(71200400001)(36756003)(64756008)(31686004)(8936002)(83380400001)(186003)(2906002)(478600001)(86362001)(6512007)(2616005)(4326008)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: s2Z7I1DFbL/3/SXDFMgNKMK8pc9x3gP4JNabAyxoElXLIkBPlq9aujG3q4DPaxzaldQayNRqR0IWjyacav9npngbYM70nD2IuL9kOkOyKBgGlwMu++XBkGRwizIQxo/3Q4tbCfLaXWxoj6Xn6p9u8oneLhD3Ay60xy9mR+Y4APcm83hs2hfNJCKLd0gtWxb7u4zio9DVCg/EhRDgY3W+Em/BUa1mMLoGEz6m57imQY5PK+A07vHknWcF6263B1P8X2cHycEwzEKEyDoehu1TE8zlWCb1N2gAEnj4O3rwYiKe5Qvctr2YFXzJuE+hd1uG0eMqYn49hJNYJ6AKbV54lidvw58LZOHlEpMiD/Njx2zzQ8hS1EqbDGECobEbHyTJAtw9WxhD3/f3J9Yz+e7iYvW3OpIWuHe/FXtUPHlcUJ9hkYunOy+vrryJYOqp3myYYAI526TmRq+/FTjvS3hnw4gSLVJSbakpyZxt3+f+nYKAY5nrGd8vx3TKyFVpngOKOPB8aZ62zx+bRf/0yHORVmFQAbJtA3Q9Kilqcjnt2awV0hmbnakL0jw8moTAq2JxrZRi8/6zki13aNoN96JpdQ0Q6ukHyuQXSZ3dsnKRpu3hTDeWlnJbip1U1Mtgu5LefC92TXC66h6r4/k4682CLi7/lkYIzqddz3uQmhk84I4f30ZZW26qJgOJBFy0mDaz9vgBd0OQC1N6zGBXBh9OuQ== 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: HE1PR07MB3209.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e58c97e-fbd8-4bc4-ca72-08d845107f2e X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2020 13:54:02.7252 (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: Po5FCrm1PGZl+jj8PDwhfRRcTjrLg2BOnTp4aztXW+dLLJ7IDzh+HVLell1k+7b5D4lbnnsxPkRIFdtPeMI+RhQE0/oL4Oe2P/B3Kwu4rqM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3050 Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 20 Aug 2020 13:54:07 -0000 SGkgVGVycnksDQoNCkl0IHdvdWxkIGJlIGEgbWlzaW50ZXJwcmV0YXRpb24gdG8gc2F5IHRoYXQg ZXZlcnl0aGluZyBmcm9tIHRoZSANCmF1dGhlbnRpY2F0b3IgaXMgYW4gRUFQLVJlcXVlc3QgaGVu Y2UgRUFQLUZhaWx1cmUgaXMgYWxzbyBhIFJlcXVlc3QuIA0KSXQncyBhbiBFQVAgcGFja2V0IHdp dGggYSBkaWZmZXJlbnQgQ29kZS4gVGh1cywgaXQgaXMgd3JvbmcgdG8gc2F5IHRoYXQgDQp0ZXh0 ICJ0aGUgYXV0aGVudGljYXRvciBTSE9VTEQgTk9UIHNlbmQgYW5vdGhlciBSZXF1ZXN0IiBhbHNv IGltcGxpZXMgDQp0aGF0IHRoZSBhdXRoZW50aWNhdG9yIFNIT1VMRCBOT1Qgc2VuZCBhbiBFQVAt RmFpbHVyZS4NCg0KQWxzbywgU2VjdGlvbiA1IG9mIFJGQyAzNzQ4IHNheXMgdGhhdCBOQUsgaXMg cmVzcG9uc2Ugb25seS4gU28gSSBkb24ndCANCnVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBieSAn TkFLIGlzIGp1c3QgYSAiVHlwZSIgb2YgUmVxdWVzdCAvIFJlc3BvbnNlIA0KKGRlcGVuZGluZyBv biBkaXJlY3Rpb24pJy4gTkFLcyBhcmUgb25seSBzZW50IGJ5IHRoZSBwZWVyIHRvIHRoZSANCmF1 dGhlbnRpY2F0b3Ivc2VydmVyLiBTZW5kaW5nIGEgTkFLIGluIHRoZSBvdGhlciBkaXJlY3Rpb24g d291bGQgYmUgYSANCnZpb2xhdGlvbiBvZiBSRkMgMzc0OCBhbmQgaXMgbm90IHN1cHBvcnRlZCBv ciBpbXBsZW1lbnRlZC4NCg0KLS1Nb2hpdA0KDQpPbiA4LzIwLzIwIDQ6MjYgUE0sIFRlcnJ5IEJ1 cnRvbiB3cm90ZToNCj4gT24gVGh1LCAyMCBBdWcgMjAyMCBhdCAxMzozNCwgTW9oaXQgU2V0aGkg TQ0KPiA8bW9oaXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6 DQo+IDwuLi5zbmlwLi4uPg0KPj4gSXQncyBhbHNvIGNvbnRyYXJ5IHRvLi4uDQo+Pg0KPj4gICAg ICAgIFR5cGUgemVybyAoMCkgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBzZW5kZXIgaGFz DQo+PiAgICAgICAgbm8gdmlhYmxlIGFsdGVybmF0aXZlcywgYW5kIHRoZXJlZm9yZSB0aGUgYXV0 aGVudGljYXRvciBTSE9VTEQgTk9UDQo+PiAgICAgICAgc2VuZCBhbm90aGVyIFJlcXVlc3QgYWZ0 ZXIgcmVjZWl2aW5nIGEgTmFrIFJlc3BvbnNlIGNvbnRhaW5pbmcgYQ0KPj4gICAgICAgIHplcm8g dmFsdWUuDQo+Pg0KPj4gLi4uLiB1bmxlc3MgdGhlIGxhbmd1YWdlIGlzIGxvb3NlIGFuZCB3ZSBz YXkgdGhhdCBhbiBFQVAtRmFpbHVyZQ0KPj4gcmVxdWVzdCBpc24ndCBhY3R1YWxseSBhICJSZXF1 ZXN0IiwgYnV0IHRoYXQncyBoYXJkIHRvIGFyZ3VlIGR1ZSB0bw0KPj4gY2FwaXRhbCAiUiJlcXVl c3QuDQo+Pg0KPj4gV2h5IGlzIEVBUC1GYWlsdXJlIGEgcmVxdWVzdD8gSXQncyBhbiBFQVAgcGFj a2V0IHdpdGggYSBkaWZmZXJlbnQgQ29kZT8gU28gdGhlIFNIT1VMRCBOT1QgZG9lc24ndCBmb3Ji aWQgdGhlIHNlcnZlciBmcm9tIHNlbmRpbmcgYW4gRUFQLUZhaWx1cmUuIFJGQyAzNzQ4IGV2ZW4g Y2FsbHMgRmFpbHVyZSBhcyBhIHJlc3BvbnNlOiAiQW4gYXV0aGVudGljYXRvciBNQVkgd2lzaCB0 byBpc3N1ZSBtdWx0aXBsZSBSZXF1ZXN0cyBiZWZvcmUgc2VuZGluZyBhIEZhaWx1cmUgcmVzcG9u c2UgaW4gb3JkZXIgdG8gYWxsb3cgZm9yIGh1bWFuIHR5cGluZyBtaXN0YWtlcy4iDQo+IFRoYXQn cyBhIHNtYWxsICJyImVzcG9uc2UgYW5kIEknZCBkYXJlIHRvIHNheSB0aGF0IGV2ZW4gdGhhdCB1 c2FnZQ0KPiBpc24ndCBwYXJ0aWN1bGFybHkgaGVscGZ1bCEgOi0pDQo+DQo+IEkgdGhpbmsgaXQn cyB3ZWxsIGVzdGFibGlzaGVkIHRoYXQgYW55IG1lc3NhZ2UgZnJvbSB0aGUgYXV0aGVudGljYXRv cg0KPiB0byB0aGUgcGVlciAoQ29kZSA9IDEpIGlzIGFuICJSImVxdWVzdCBhbmQgdGhhdCBhbnkg bWVzc2FnZSBmcm9tIHRoZQ0KPiBwZWVyIHRvIHRoZSBhdXRoZW50aWNhdG9yIChDb2RlID0gMikg aXMgYW4gRUFQICJSImVzcG9uc2UuIE5BSyBpcyBqdXN0DQo+IGEgIlR5cGUiIG9mIFJlcXVlc3Qg LyBSZXNwb25zZSAoZGVwZW5kaW5nIG9uIGRpcmVjdGlvbikuIFNvIHdoZW4gdGhlDQo+IGFib3Zl IHRleHQgbWVudGlvbnMgIlIiZXF1ZXN0IGl0IGFjdHVhbGx5IHJlZmVycyB0byBFQVAgcGFja2V0 cyB3aXRoDQo+IENvZGUgPSAxLCBpLmUuIGl0IHNheXMgKHNlZW1pbmdseSBlcnJvbmVvdXNseSBh cyBBbGFuIHBvaW50cyBvdXQpIHRoYXQNCj4gbm8gZnVydGhlciBtZXNzYWdlcyBvZiBhbnkgdHlw ZSBzaG91bGQgYmUgc2VudCBmcm9tIHRoZSBhdXRoZW50aWNhdG9yDQo+IHRvIHRoZSBwZWVyIHdp dGhpbiB0aGUgY29udmVyc2F0aW9uLg0KDQo= From nobody Thu Aug 20 07:42:36 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 AE4DB3A09C6 for ; Thu, 20 Aug 2020 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_FROM=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 Ald2jtDT7Wbd for ; Thu, 20 Aug 2020 07:42:33 -0700 (PDT) Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (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 15C153A09B8 for ; Thu, 20 Aug 2020 07:42:33 -0700 (PDT) Received: by mail-vs1-xe42.google.com with SMTP id i129so1190080vsi.3 for ; Thu, 20 Aug 2020 07:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=KS2gEiPBtgFYSois/48YMoDPYtU4n0A0aGmLrPegCxY=; b=NnvD3zIgB84yQNjQt+BNd2nEOFmMGvB5JZjrZKHlVhd4WnX+tXFHSWgrmmg5WKHI1Z YJgvA+kubhLAXwHzZm08KwAa8KkzfVsq0LjwCmska6ykViz5TbDf6QHjduoVgvBiUT3K sARiA34Ugimd5XgUKrnQOj4Vz3bQGAtLcYONYVsyclnabocWyf7kgwywn5Nbb+dFPdLw NDHd+zIIbF+TZ6su4JyjcSalo9rdVTkf8DpjnLvC6x6XGlLp+AaahLYvt95N6zaGc3pP q/EKkeABVh4Vg0nCV92hzDxDRTQExGBvGssnGkNRcs4rkf7kVLbaJlQrh0c78Ug86IP6 6I5A== 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=KS2gEiPBtgFYSois/48YMoDPYtU4n0A0aGmLrPegCxY=; b=Na88Qdd1NRUQlyBTGA4MZt9tb20O8SxAa2YW+83V1SpNnMkSSOqS1B9ZptEcxj6gKD TZvh6urUOyTDxRnUSCp4tHd0F/RFZjwvUFs5aARAeBeAMFzSccWnekibMvCfPSVwVJ5A UuCNeZN4q7r8oRHPH3XntqDk9q9Pi421OUwo4e+oO7TfPyXS/AaFydHKCHXOCituz5jv kp2YXjO//zD2t2RddcYG92HBLW1tVaQ+JFS8zX0ky8PkML4tWbhrDSqlQYzEoy4U83MY Er25vF0oapeZ7J5nqS+1PuisP2ds6FrhCiU9h2Sp3Hfz2lwoA26HRIS14nzTC4G0zLqB 3Vuw== X-Gm-Message-State: AOAM530O97+0XxIdsyVZqcyTxFHpCHS3QdLgw0mph22OBumnKtcrwmfa QxA8UZdRGx5N1qUv4YuFPnK2Fz/yjosTzFLZlZHnf2NDxo5MPA== X-Google-Smtp-Source: ABdhPJwn8MtC8uxe5PjkvmXiJzNKDK9ZZO6EK4snzN6a/B4bS7pQC4tcwi6Xd5W7AcgHGd08G6kB5xoxh6tV2KusDMY= X-Received: by 2002:a05:6102:3025:: with SMTP id v5mr2121614vsa.194.1597934551985; Thu, 20 Aug 2020 07:42:31 -0700 (PDT) MIME-Version: 1.0 References: <4f300bbd-f37b-3b1b-7aee-7e6c448a077d@ericsson.com> In-Reply-To: <4f300bbd-f37b-3b1b-7aee-7e6c448a077d@ericsson.com> Reply-To: tez@terryburton.co.uk From: Terry Burton Date: Thu, 20 Aug 2020 15:41:55 +0100 Message-ID: To: Mohit Sethi M Cc: "emu@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 20 Aug 2020 14:42:35 -0000 On Thu, 20 Aug 2020 at 14:54, Mohit Sethi M wrote: > It would be a misinterpretation to say that everything from the > authenticator is an EAP-Request hence EAP-Failure is also a Request. > It's an EAP packet with a different Code. Thus, it is wrong to say that > text "the authenticator SHOULD NOT send another Request" also implies > that the authenticator SHOULD NOT send an EAP-Failure. You're right. Thanks. > Also, Section 5 of RFC 3748 says that NAK is response only. So I don't > understand what you mean by 'NAK is just a "Type" of Request / Response > (depending on direction)'. NAKs are only sent by the peer to the > authenticator/server. Sending a NAK in the other direction would be a > violation of RFC 3748 and is not supported or implemented. I was probably thrown because RFC 3579 section 2.6.2 on Role Reversal has t= his: Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. However, role reversal is not supported by this specification. A RADIUS server MUST respond to an Access-Request encapsulating an EAP-Request with an Access-Reject. In order to avoid retransmissions by the peer, the Access-Reject SHOULD include an EAP-Response/Nak packet indicating no preferred method, encapsulated within EAP-Message attribute(s). Notionally that's an "EAP-Response/NAK" sent in the "wrong" direction: AAA --> NAS --> Peer However I believe that this is considering the case where the peer contains an EAP server that is trying to initiate an authentication of the NAS (not allowed), and therefore the AAA tells the peer to go away. > On 8/20/20 4:26 PM, Terry Burton wrote: > > On Thu, 20 Aug 2020 at 13:34, Mohit Sethi M > > wrote: > > <...snip...> > >> It's also contrary to... > >> > >> Type zero (0) is used to indicate that the sender has > >> no viable alternatives, and therefore the authenticator SHOULD = NOT > >> send another Request after receiving a Nak Response containing = a > >> zero value. > >> > >> .... unless the language is loose and we say that an EAP-Failure > >> request isn't actually a "Request", but that's hard to argue due to > >> capital "R"equest. > >> > >> Why is EAP-Failure a request? It's an EAP packet with a different Code= ? So the SHOULD NOT doesn't forbid the server from sending an EAP-Failure. = RFC 3748 even calls Failure as a response: "An authenticator MAY wish to is= sue multiple Requests before sending a Failure response in order to allow f= or human typing mistakes." > > That's a small "r"esponse and I'd dare to say that even that usage > > isn't particularly helpful! :-) > > > > I think it's well established that any message from the authenticator > > to the peer (Code =3D 1) is an "R"equest and that any message from the > > peer to the authenticator (Code =3D 2) is an EAP "R"esponse. NAK is jus= t > > a "Type" of Request / Response (depending on direction). So when the > > above text mentions "R"equest it actually refers to EAP packets with > > Code =3D 1, i.e. it says (seemingly erroneously as Alan points out) tha= t > > no further messages of any type should be sent from the authenticator > > to the peer within the conversation. From nobody Fri Aug 21 00:27: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 9509B3A02BC for ; Fri, 21 Aug 2020 00:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2nwC3ocB6Ycs for ; Fri, 21 Aug 2020 00:27:18 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2064.outbound.protection.outlook.com [40.107.21.64]) (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 894723A012A for ; Fri, 21 Aug 2020 00:27:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c7V9J4RjM+GFKkhXSLOwRf+rBEzFdDYz7K6C5FW1Do72dBwNz9ITQX+g0VwTPy8uu/9nBaacfVvI3MQqd3DAS8q8RphTGxnvFvDEgn3FrO8rXdqRwtUxFRH7YNWbIW9hicoeRbtiSUbw0nYmOfADKmpdbLSd3OY/65cM2I8eYe8bMKtMEqyQaCNogJUncT93AIgK9GbG12Lu/645R6uURAh0ydxj/CFRziNeckZaCy8Y/zhy11P23LLUpCFrTUeSklyyQQao0mLoKF3EuKkec4n/gyP48Wpkt1gdZBmvtbKcpO/JmfZWPdIyFTGnqpQg6GBfSEflkFqEjE1Q2NdYCw== 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=Yv984GzFOVd6HvlTRjZ/xVk1Wa318+vTFaVkNQtRhFM=; b=WipLfitN3wQXB0gOBNZNth4oxuLNwKKPvrTyI0citlGF2u6VBWbciDAtawa7dHHvdj3lOW1x0ac0sH+XQnD7w+kAUgpgejoEvz3cI6boy0zBjDVO6WUJrM7EIkWOV2h8MGnvVJZzEIJlRbpRhoUxbFbve3FeiBvwcGIa8ZDCVTGHnYKSh2FoyQuCAuMoGYHPPjrD4hHwvyVsXdVg86g8ZIJiHtXlkMhZlj2FjMGVtjunjAQrN7QyZief4ppUuI4rHe+HnzTm6T6hzbcBrexJGoUFhEXVPOourYg6u2+hjVxZDNbSXyjAgIVoRw91Y6bCsYS1IvonJkTJLwmHkmBKQA== 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=Yv984GzFOVd6HvlTRjZ/xVk1Wa318+vTFaVkNQtRhFM=; b=Ao3qB1UdHQl8GiRbxNsp7VxpoxT6tDO7dw3XZsKm/yw9rWheeqIvKbrWXHD1ZgWdAnNIIen92dYbit4X5sr1tfoGqsdTtPl0iepKxkfSZZCf425zxM5sTLLlZEEJGhdCUoQ1OJcyoNXRU50ICWI68rjrsI3kL+Xgqq7Feheo6W4= Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR0701MB3051.eurprd07.prod.outlook.com (2603:10a6:3:57::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.13; Fri, 21 Aug 2020 07:27:09 +0000 Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6%5]) with mapi id 15.20.3305.021; Fri, 21 Aug 2020 07:27:09 +0000 From: Mohit Sethi M To: "tez@terryburton.co.uk" , Mohit Sethi M CC: "emu@ietf.org" Thread-Topic: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods Thread-Index: AQHWdtBd6/Chl5vFm0Cl50TEYc0wYalA5faAgAAI2ACAAA6fAIAAB6mAgAANYoCAARjagA== Date: Fri, 21 Aug 2020 07:27:08 +0000 Message-ID: References: <4f300bbd-f37b-3b1b-7aee-7e6c448a077d@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.10.0 authentication-results: terryburton.co.uk; dkim=none (message not signed) header.d=none;terryburton.co.uk; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:4384:9700:db31:7396:a479] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9ee24e94-0cf7-465d-5ae8-08d845a39d30 x-ms-traffictypediagnostic: HE1PR0701MB3051: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gZy28FSlNH1DKoRJX0COtTQLUQXQnuYLO0ShlAY1SPorJiUc/2pNDfEXCbrwW1F9DNMoKUTR9t+gAoL5g/+bwtj7MUT4M7Hy8ToD2ZZ0DnLLOUDA0wpWzkDn8mMhXJOyN+0/vO28xQSkEYwhFTAtzSQs8sVs0fTdcSA4wNxxMyaDMKE/VdD7cHYzgqcQfW0HL5nvdy1lbLRXwYFSxa8OzJNzHEJeil5czYohwyuY7Cttf7vcOfPokN8LboZQKaaDM+5il2bGXd5i4oNyqLRcPfzKyWAa9CNyJOTOViVjs0Joxqu5Lyfhi8e3fM7YY62hLa7XxVrOFnmJb/8+zM8oX6Ozgm8x0DJx3rKk/HB/3bUmG+gYbWipf7Qz3FjyOSFNv90ZSM4h9nrbCZIWkEi5XwprNvHz6IKtHoKocelnLSG3ePZ2R//jcz3ocgHlyZLL++NX0en+f6WqUPD01/WSjA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(376002)(346002)(366004)(396003)(83380400001)(6512007)(76116006)(2616005)(110136005)(8676002)(86362001)(4326008)(31686004)(36756003)(316002)(6506007)(66946007)(8936002)(478600001)(6486002)(66476007)(966005)(64756008)(71200400001)(186003)(66446008)(66556008)(31696002)(5660300002)(53546011)(2906002)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: X3e73nhBqQNupveFu4/FyoIhBYNobZFfIkldgxQyX+kWkcMJGqyPDhusTYP9cUMfskUo5ReCHGrQu+yp46wwYykplIWWhalo6ObYJD7DfJJw58QIivd7M3u5v679uXGd622TMchDOy8DJIU0d3ltsA0f9panbV7FetPAa/Y656sXK2TssNP7hRuTZJkISDWJ1nNnFZ9GbLrLi/BAjYiB9Smer73hxwBhjcsuRM+62EPjTvHQMA41uxa7pR6DVPuVskVCW3nvPjRwsVY6bH5I1v7glWHUufFIGv0wgEqXaEjaxz8rRcamxU/j85qjlxIHvCsB4I2kN3K391kfzPlmPuPAqZXnYRExmfNsMWrRY+qNcY5NeMbZpk3hGAeh2KLKRiaKXIapcjidhCHfJd7YEjjKrfgu37Tciyy2OJMabB4qDoSnM4cqHDgu7c3BhB/tYAdVIQSapb2lBSL09HL0hcBzRMs9HnNcM1TO6dwaplI5HI1NYrrqiQ/IzxEcqeF7vrvnucuQbeXkAOw+wP8uytVpDUw59PU4Ytswtn9QLu5YcPQUBwYQDKvtC46BV9Wt4KcyYLDw4bYlYTy/VO6rSvPkcza8TE0XEUp4X3eRDkdzepyYTmgR3h7HvIE0QUHiywncD5hItObu4sPbu4icujuqr8ExvYf0FG3YY848EzrCh3ZBFaulBvdeIezv3eOoSgJjgI3UAsFuI6aej5Nm/w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3F96B3E3C6AB5B4F837F79C3026C491D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3209.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ee24e94-0cf7-465d-5ae8-08d845a39d30 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2020 07:27:08.9114 (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: 05ERbwfLIBBqjXzdZXTB2E51vHdtg3sNdT8nKKLsGgwvLVxl2mk9b9DosRZ6tu021OciEDEuwarQBqAwVtb5/PosLx++3iNrYWSNNMxlYaY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3051 Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 21 Aug 2020 07:27:21 -0000 SGkgVGVycnksDQoNCk9uIDgvMjAvMjAgNTo0MSBQTSwgVGVycnkgQnVydG9uIHdyb3RlOg0KPiBP biBUaHUsIDIwIEF1ZyAyMDIwIGF0IDE0OjU0LCBNb2hpdCBTZXRoaSBNDQo+IDxtb2hpdC5tLnNl dGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiAgd3JvdGU6DQo+PiBJdCB3b3VsZCBi ZSBhIG1pc2ludGVycHJldGF0aW9uIHRvIHNheSB0aGF0IGV2ZXJ5dGhpbmcgZnJvbSB0aGUNCj4+ IGF1dGhlbnRpY2F0b3IgaXMgYW4gRUFQLVJlcXVlc3QgaGVuY2UgRUFQLUZhaWx1cmUgaXMgYWxz byBhIFJlcXVlc3QuDQo+PiBJdCdzIGFuIEVBUCBwYWNrZXQgd2l0aCBhIGRpZmZlcmVudCBDb2Rl LiBUaHVzLCBpdCBpcyB3cm9uZyB0byBzYXkgdGhhdA0KPj4gdGV4dCAidGhlIGF1dGhlbnRpY2F0 b3IgU0hPVUxEIE5PVCBzZW5kIGFub3RoZXIgUmVxdWVzdCIgYWxzbyBpbXBsaWVzDQo+PiB0aGF0 IHRoZSBhdXRoZW50aWNhdG9yIFNIT1VMRCBOT1Qgc2VuZCBhbiBFQVAtRmFpbHVyZS4NCj4gWW91 J3JlIHJpZ2h0LiBUaGFua3MuDQo+DQo+PiBBbHNvLCBTZWN0aW9uIDUgb2YgUkZDIDM3NDggc2F5 cyB0aGF0IE5BSyBpcyByZXNwb25zZSBvbmx5LiBTbyBJIGRvbid0DQo+PiB1bmRlcnN0YW5kIHdo YXQgeW91IG1lYW4gYnkgJ05BSyBpcyBqdXN0IGEgIlR5cGUiIG9mIFJlcXVlc3QgLyBSZXNwb25z ZQ0KPj4gKGRlcGVuZGluZyBvbiBkaXJlY3Rpb24pJy4gTkFLcyBhcmUgb25seSBzZW50IGJ5IHRo ZSBwZWVyIHRvIHRoZQ0KPj4gYXV0aGVudGljYXRvci9zZXJ2ZXIuIFNlbmRpbmcgYSBOQUsgaW4g dGhlIG90aGVyIGRpcmVjdGlvbiB3b3VsZCBiZSBhDQo+PiB2aW9sYXRpb24gb2YgUkZDIDM3NDgg YW5kIGlzIG5vdCBzdXBwb3J0ZWQgb3IgaW1wbGVtZW50ZWQuDQo+IEkgd2FzIHByb2JhYmx5IHRo cm93biBiZWNhdXNlIFJGQyAzNTc5IHNlY3Rpb24gMi42LjIgb24gUm9sZSBSZXZlcnNhbCBoYXMg dGhpczoNCj4NCj4gICAgIFNpbmNlIEVBUCBpcyBhIHBlZXItdG8tcGVlciBwcm90b2NvbCwgYW4g aW5kZXBlbmRlbnQgYW5kIHNpbXVsdGFuZW91cw0KPiAgICAgYXV0aGVudGljYXRpb24gbWF5IHRh a2UgcGxhY2UgaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLiAgQm90aCBwZWVycw0KPiAgICAgbWF5 IGFjdCBhcyBhdXRoZW50aWNhdG9ycyBhbmQgYXV0aGVudGljYXRlZXMgYXQgdGhlIHNhbWUgdGlt ZS4NCj4NCj4gICAgIEhvd2V2ZXIsIHJvbGUgcmV2ZXJzYWwgaXMgbm90IHN1cHBvcnRlZCBieSB0 aGlzIHNwZWNpZmljYXRpb24uICBBDQo+ICAgICBSQURJVVMgc2VydmVyIE1VU1QgcmVzcG9uZCB0 byBhbiBBY2Nlc3MtUmVxdWVzdCBlbmNhcHN1bGF0aW5nIGFuDQo+ICAgICBFQVAtUmVxdWVzdCB3 aXRoIGFuIEFjY2Vzcy1SZWplY3QuICBJbiBvcmRlciB0byBhdm9pZCByZXRyYW5zbWlzc2lvbnMN Cj4gICAgIGJ5IHRoZSBwZWVyLCB0aGUgQWNjZXNzLVJlamVjdCBTSE9VTEQgaW5jbHVkZSBhbiBF QVAtUmVzcG9uc2UvTmFrDQo+ICAgICBwYWNrZXQgaW5kaWNhdGluZyBubyBwcmVmZXJyZWQgbWV0 aG9kLCBlbmNhcHN1bGF0ZWQgd2l0aGluDQo+ICAgICBFQVAtTWVzc2FnZSBhdHRyaWJ1dGUocyku DQo+DQo+IE5vdGlvbmFsbHkgdGhhdCdzIGFuICJFQVAtUmVzcG9uc2UvTkFLIiBzZW50IGluIHRo ZSAid3JvbmciIGRpcmVjdGlvbjoNCj4gQUFBIC0tPiBOQVMgLS0+IFBlZXINCj4NCj4gSG93ZXZl ciBJIGJlbGlldmUgdGhhdCB0aGlzIGlzIGNvbnNpZGVyaW5nIHRoZSBjYXNlIHdoZXJlIHRoZSBw ZWVyDQo+IGNvbnRhaW5zIGFuIEVBUCBzZXJ2ZXIgdGhhdCBpcyB0cnlpbmcgdG8gaW5pdGlhdGUg YW4gYXV0aGVudGljYXRpb24gb2YNCj4gdGhlIE5BUyAobm90IGFsbG93ZWQpLCBhbmQgdGhlcmVm b3JlIHRoZSBBQUEgdGVsbHMgdGhlIHBlZXIgdG8gZ28NCj4gYXdheS4NCg0KU29ycnkgZm9yIG5p dHBpY2tpbmcgaGVyZS4gQnV0IGl0IGlzIGltcG9ydGFudCB0byBkaXN0aW5ndWlzaCB0aGUgdHdv IA0KY29tcG9uZW50cyB0aGF0IGNvbXByaXNlIGEgQUFBIHNlcnZlcjogUkFESVVTIHNlcnZlciBh bmQgRUFQIHNlcnZlci4gUkZDIA0KMzU3OSBicmllZmx5IGFsbHVkZXMgdG8gdGhpcyBkaWZmZXJl bmNlIGFuZCB1c2VzIGRpZmZlcmVudCB0ZXJtcyBmb3IgYSANClJBRElVUyBzZXJ2ZXIgYW5kIGFu IEVBUCBzZXJ2ZXIuIFN1cmUsIHRoZXkgd2lsbCBsaWtlbHkgcnVuIG9uIHRoZSBzYW1lIA0KbWFj aGluZSBhbmQgYXJlIHRpZ2h0bHkgaW50ZWdyYXRlZCwgeWV0IHRoZXkgYXJlIGluZGVwZW5kZW50 IGNvbXBvbmVudHMuIA0KVGhlIHRleHQgeW91IHBvaW50IHRvIGluIFJGQyAzNTc5IGRvZXNuJ3Qg aW1wbHkgdGhhdCB0aGUgTkFLIGlzIHNlbnQgDQpmcm9tIHRoZSBFQVAgc2VydmVyLiBJdCBvbmx5 IHNheXMgdGhhdCB0byBhdm9pZCByZXRyYW5zbWlzc2lvbnMsIGEgDQpSQURJVVMgc2VydmVyIHNo b3VsZCBnZW5lcmF0ZSBhbiBBY2Nlc3MtUmVqZWN0IGNvbnRhaW5pbmcgYSANCkVBUC1SZXNwb25z ZS9OYWsgb24gaXRzIG93biAod2l0aG91dCBpbnZvbHZpbmcgdGhlIEVBUCBzZXJ2ZXIpLiBTbyAN CnRlY2huaWNhbGx5LCB0aGlzIE5BSyBpcyBzdGlsbCBub3Qgc2VudCBieSB0aGUgRUFQIHNlcnZl ciBpbiB0aGUgDQpzby1jYWxsZWQgJ3dyb25nIGRpcmVjdGlvbicuIEluIGNvbW1vbiByZWFsaXN0 aWMgaW1wbGVtZW50YXRpb25zLCBSQURJVVMgDQpzZXJ2ZXJzIG9ubHkgcHJveHkgZGF0YSB0by9m cm9tIHRoZSBFQVAgc2VydmVyIGFuZCBkbyBub3QgZ2VuZXJhbGx5IA0KaW5qZWN0IEVBUCBwYWNr ZXRzIG9uIHRoZWlyIG93bi4gV2hpY2ggaXMgd2h5IEkgc3VzcGVjdCB0aGF0IHRoaXMgaXMgbm90 IA0KaW1wbGVtZW50ZWQgaW4gdGhlIHJhZGl1cyBzZXJ2ZXIgb2YgaG9zdGFwOiANCmh0dHBzOi8v dzEuZmkvY2dpdC9ob3N0YXAvdHJlZS9zcmMvcmFkaXVzL3JhZGl1c19zZXJ2ZXIuYyNuMTQzNw0K DQotLU1vaGl0DQoNCj4+IE9uIDgvMjAvMjAgNDoyNiBQTSwgVGVycnkgQnVydG9uIHdyb3RlOg0K Pj4+IE9uIFRodSwgMjAgQXVnIDIwMjAgYXQgMTM6MzQsIE1vaGl0IFNldGhpIE0NCj4+PiA8bW9o aXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4gIHdyb3RlOg0KPj4+IDwu Li5zbmlwLi4uPg0KPj4+PiBJdCdzIGFsc28gY29udHJhcnkgdG8uLi4NCj4+Pj4NCj4+Pj4gICAg ICAgICBUeXBlIHplcm8gKDApIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgc2VuZGVyIGhh cw0KPj4+PiAgICAgICAgIG5vIHZpYWJsZSBhbHRlcm5hdGl2ZXMsIGFuZCB0aGVyZWZvcmUgdGhl IGF1dGhlbnRpY2F0b3IgU0hPVUxEIE5PVA0KPj4+PiAgICAgICAgIHNlbmQgYW5vdGhlciBSZXF1 ZXN0IGFmdGVyIHJlY2VpdmluZyBhIE5hayBSZXNwb25zZSBjb250YWluaW5nIGENCj4+Pj4gICAg ICAgICB6ZXJvIHZhbHVlLg0KPj4+Pg0KPj4+PiAuLi4uIHVubGVzcyB0aGUgbGFuZ3VhZ2UgaXMg bG9vc2UgYW5kIHdlIHNheSB0aGF0IGFuIEVBUC1GYWlsdXJlDQo+Pj4+IHJlcXVlc3QgaXNuJ3Qg YWN0dWFsbHkgYSAiUmVxdWVzdCIsIGJ1dCB0aGF0J3MgaGFyZCB0byBhcmd1ZSBkdWUgdG8NCj4+ Pj4gY2FwaXRhbCAiUiJlcXVlc3QuDQo+Pj4+DQo+Pj4+IFdoeSBpcyBFQVAtRmFpbHVyZSBhIHJl cXVlc3Q/IEl0J3MgYW4gRUFQIHBhY2tldCB3aXRoIGEgZGlmZmVyZW50IENvZGU/IFNvIHRoZSBT SE9VTEQgTk9UIGRvZXNuJ3QgZm9yYmlkIHRoZSBzZXJ2ZXIgZnJvbSBzZW5kaW5nIGFuIEVBUC1G YWlsdXJlLiBSRkMgMzc0OCBldmVuIGNhbGxzIEZhaWx1cmUgYXMgYSByZXNwb25zZTogIkFuIGF1 dGhlbnRpY2F0b3IgTUFZIHdpc2ggdG8gaXNzdWUgbXVsdGlwbGUgUmVxdWVzdHMgYmVmb3JlIHNl bmRpbmcgYSBGYWlsdXJlIHJlc3BvbnNlIGluIG9yZGVyIHRvIGFsbG93IGZvciBodW1hbiB0eXBp bmcgbWlzdGFrZXMuIg0KPj4+IFRoYXQncyBhIHNtYWxsICJyImVzcG9uc2UgYW5kIEknZCBkYXJl IHRvIHNheSB0aGF0IGV2ZW4gdGhhdCB1c2FnZQ0KPj4+IGlzbid0IHBhcnRpY3VsYXJseSBoZWxw ZnVsISA6LSkNCj4+Pg0KPj4+IEkgdGhpbmsgaXQncyB3ZWxsIGVzdGFibGlzaGVkIHRoYXQgYW55 IG1lc3NhZ2UgZnJvbSB0aGUgYXV0aGVudGljYXRvcg0KPj4+IHRvIHRoZSBwZWVyIChDb2RlID0g MSkgaXMgYW4gIlIiZXF1ZXN0IGFuZCB0aGF0IGFueSBtZXNzYWdlIGZyb20gdGhlDQo+Pj4gcGVl ciB0byB0aGUgYXV0aGVudGljYXRvciAoQ29kZSA9IDIpIGlzIGFuIEVBUCAiUiJlc3BvbnNlLiBO QUsgaXMganVzdA0KPj4+IGEgIlR5cGUiIG9mIFJlcXVlc3QgLyBSZXNwb25zZSAoZGVwZW5kaW5n IG9uIGRpcmVjdGlvbikuIFNvIHdoZW4gdGhlDQo+Pj4gYWJvdmUgdGV4dCBtZW50aW9ucyAiUiJl cXVlc3QgaXQgYWN0dWFsbHkgcmVmZXJzIHRvIEVBUCBwYWNrZXRzIHdpdGgNCj4+PiBDb2RlID0g MSwgaS5lLiBpdCBzYXlzIChzZWVtaW5nbHkgZXJyb25lb3VzbHkgYXMgQWxhbiBwb2ludHMgb3V0 KSB0aGF0DQo+Pj4gbm8gZnVydGhlciBtZXNzYWdlcyBvZiBhbnkgdHlwZSBzaG91bGQgYmUgc2Vu dCBmcm9tIHRoZSBhdXRoZW50aWNhdG9yDQo+Pj4gdG8gdGhlIHBlZXIgd2l0aGluIHRoZSBjb252 ZXJzYXRpb24uDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IEVtdSBtYWlsaW5nIGxpc3QNCj4gRW11QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZW11DQo= From nobody Fri Aug 21 05:50: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 205EA3A0924 for ; Fri, 21 Aug 2020 05:50:16 -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=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 xMsuYKQTWd4t for ; Fri, 21 Aug 2020 05:50:13 -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 BAC063A0925 for ; Fri, 21 Aug 2020 05:50:12 -0700 (PDT) Received: from [192.168.0.14] (24-212-230-21.cable.teksavvy.com [24.212.230.21]) by mail.networkradius.com (Postfix) with ESMTPSA id 8E815128; Fri, 21 Aug 2020 12:50:09 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: Date: Fri, 21 Aug 2020 08:50:07 -0400 Cc: "tez@terryburton.co.uk" , "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1276BE8C-F9C1-4F13-9A4F-7220A891D051@deployingradius.com> References: <4f300bbd-f37b-3b1b-7aee-7e6c448a077d@ericsson.com> To: Mohit Sethi M X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 21 Aug 2020 12:50:16 -0000 On Aug 21, 2020, at 3:27 AM, Mohit Sethi M = wrote: > Sorry for nitpicking here. But it is important to distinguish the two=20= > components that comprise a AAA server: RADIUS server and EAP server. = RFC=20 > 3579 briefly alludes to this difference and uses different terms for a=20= > RADIUS server and an EAP server. Sure, they will likely run on the = same=20 > machine and are tightly integrated, yet they are independent = components.=20 Some minor nit picking here... In practice, EAP servers are tightly coupled with RADIUS servers. At = least for ones which implement non-trivial EAP methods. But I agree that they need to be treated as independent components. FWIW, I've looked for EAP server implementations. As best I can tell = for Open Source, it's just hostap and FreeRADIUS. Everything else is = either dead, or implements only a tiny subset of EAP, such as EAP-MD5. > The text you point to in RFC 3579 doesn't imply that the NAK is sent=20= > from the EAP server. It only says that to avoid retransmissions, a=20 > RADIUS server should generate an Access-Reject containing a=20 > EAP-Response/Nak on its own (without involving the EAP server). So=20 > technically, this NAK is still not sent by the EAP server in the=20 > so-called 'wrong direction'. In common realistic implementations, = RADIUS=20 > servers only proxy data to/from the EAP server I'm wary of the word "proxy". Proxying implies some kind of = transport, as with RADIUS proxying. The public implementations of RADIUS+EAP have the two components in = the same process, using shared libraries. The interaction between the = two is just API calls. > and do not generally=20 > inject EAP packets on their own. Which is why I suspect that this is = not=20 > implemented in the radius server of hostap:=20 > https://w1.fi/cgit/hostap/tree/src/radius/radius_server.c#n1437 The RADIUS side of hostap doesn't inject the EAP Failure. The = underlying EAP implementation injects it. The eap_sm_Policy_getDecision() function returns failure if there are = no compatible EAP methods. The calling function then returns EAP = Failure. https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server.c#n1722 The EAP server implementation in FreeRADIUS also returns an EAP = Failure packet if there are no compatible EAP methods. The underlying principle here is that silently dropping packets is = considered bad. Therefore, no matter what happens inside of the EAP = state machine, the outcome is one of 3 things: * more EAP negotiation * Success * Failure The only time the RADIUS side injects an EAP Failure is if the session = is rejected for administrative reasons. And, the EAP state machine is = bypassed. e.g. deny this particular user on this particular device, = even if their EAP credentials are OK. In that case, the EAP stack is bypassed. The Access-Reject handler = checks for an EAP-Message in the Access-Request. If found, the RADIUS = layer synthesizes an EAP Failure inside of an EAP-Message. Since hostap doesn't really have policies in it's RADIUS server = implementation, it doesn't implement this check. Alan DeKok. =20= From nobody Sun Aug 23 06:48:56 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 375793A09C7 for ; Sun, 23 Aug 2020 06:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, 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 xZQVOubeU5F4 for ; Sun, 23 Aug 2020 06:48:52 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40081.outbound.protection.outlook.com [40.107.4.81]) (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 3D6B83A0833 for ; Sun, 23 Aug 2020 06:48:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WjRC9BL7dPZOZgWIx/ZYjEhRuUwoCj4gK2nXM4bai6hRdXsZI4i8Zdzsn9+i7KiFHJ0zhaX+hMl9+jAxmzJtfz2nYfnegrTYqAkuGglz+kZoyc+NyqBuqOa88rCxGQXsV5NWSUa9inZGINwKmVmTD2Vx1tBD9LIFaojjPMGLJGMwqAtQ0BxMyBI+SK0Af7YHyMoRZnl24Q8lMW3mryaRaugKj3M7sFpPUyvhrGQPulU0n45aIcxqEXoqpE/coD9nfVMQCrICO+wEzupb4aRY9ZQJEG8oGllTd4TG0O6by8cJFzfkvV3FWIkln5nHtrZcx/eul/i1krnyINK3kNQn8A== 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=SbSy+mZvoe0ilyk//ERhIny8545mzTyVFXxRviM5Mxo=; b=K3CYQn2p2Ik2BvqeM7Z9/BzSSoUdAbWzQ/7r/if2eZXVNQ1OB+nwqEMlx1l5+mgPyepzxflpHrP6kryR7eRoLgL8nOt2DdVhfEbDj/B6B/4O2Qj9Q0OD5eIWgpeyklBrYOT3ajdu18stxRwzIdpSu2v/TwIWUyV5YOchleXeqQTJbEbRARWYFx2itdfWPAkewNOFWfIN83foBfmos97VC4EoZJJUmDuPrBlGNA3gg5zIQrCU3P/fgRJ9KzHssZ0ir4g5646Dd3xR27Xtz5o40L6xgZIBD0Qe0rhFs4GSLHiHsARE4ubcnpF0RfBzievN0bH+19LuPBLflHl9NihKCA== 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=SbSy+mZvoe0ilyk//ERhIny8545mzTyVFXxRviM5Mxo=; b=m/0ILiQmC7xFYc6+mkCkA2QxBPqPAI4kl23r/3jgmF7vLj1mcvVAODkb/RclJI8HvnQ1dSTpHMLr6s+W0xU+PLFW8UJCbWcCdQD92csEXzlXaxgUG9PDymIrDAmhKCNdo83UNcQu4WlomZKYVOUZiRk/jS9o9ROoXSugXUXfgS8= Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR07MB3435.eurprd07.prod.outlook.com (2603:10a6:7:2e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Sun, 23 Aug 2020 13:48:49 +0000 Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6%5]) with mapi id 15.20.3326.016; Sun, 23 Aug 2020 13:48:48 +0000 From: Mohit Sethi M To: Alan DeKok , Mohit Sethi M CC: "emu@ietf.org" Thread-Topic: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods Thread-Index: AQHWdtBd6/Chl5vFm0Cl50TEYc0wYalA5faAgAAI2ACAAA6fAIAAB6mAgAANYoCAARjagIAAWj6AgAM1DoA= Date: Sun, 23 Aug 2020 13:48:48 +0000 Message-ID: <7f063355-d02b-8e2f-5eea-6b15580cf3e8@ericsson.com> References: <4f300bbd-f37b-3b1b-7aee-7e6c448a077d@ericsson.com> <1276BE8C-F9C1-4F13-9A4F-7220A891D051@deployingradius.com> In-Reply-To: <1276BE8C-F9C1-4F13-9A4F-7220A891D051@deployingradius.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.10.0 authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:4384:9700:db31:7396:a479] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc8e6df2-df89-47d5-ba71-08d8476b433d x-ms-traffictypediagnostic: HE1PR07MB3435: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oiL+ypCBpVWt5to0aKq8rqtdopUxEfURoGX1POTgPaj+v36DeTb2tfjI38iiDVmrJ5Br0jEk+LikqKNhLFDwMGKK9g9R23oG5UckFUpBX3xTuDjHptXbgUXqvKh4i7M7Xaf5wQR9ycDI47SwEGdu2IfwP7fih2OGlroVv3YnEQsXU7s6hV9RnknsHlXvcRfOsGoiqRxbiI6s7R2WPIu83X8wn4D6+rmj4+gJDU2RF2FayCRGzI/qTJ6+m00RWoU3CdV7WQkQsuoVm4nRrzlKn7xxYErdu2X6tOYv2it+YGImzo0KFprh2+rgLroO+3XhgVS0bU0ZgMq1yS2CczDZtb7x436coZ4IqhB5/hA78Gjas7EsASoSnTm35gxZXrnnKBWx4ZxiukyMTaB0LKlJDu/VT5CdO24sMFJg0v2MVJCYZz4a5VQUDPhmktHcJz9cR40YbkAXUMLrQNwhjRg/DA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(64756008)(66476007)(8676002)(66946007)(5660300002)(966005)(71200400001)(2906002)(83380400001)(66446008)(66556008)(8936002)(53546011)(6506007)(86362001)(6486002)(6512007)(36756003)(4326008)(498600001)(31686004)(2616005)(186003)(76116006)(31696002)(110136005)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ks3L9tZ70E0tfzqO6iDF9lhN631gCjqVwBA8OHelPYdWoTMIN3381bfXClILPqDhg0HBadMkFDsQpzb5JHufbLW2q3PYtDTU3LEWzn0HeJ82zGLiFgeCEFl7pcby6NRxkIr9rbT7NpZUoJKeY68BoQyosFHk5PLivrac9qzCe+gZqXA4Vz+0VnYp36Rblg8PRIHyMs8rH2HmWW1PnrQeZia+B8AqL9CWuWX11CpawYhlIr9bnVMeWGAOOUAO/ezXIop74xdyDKa3VPF4dQ2fTkfgVNcuQORZZxVu+B55yWu6waJBtzIzBCQys95iyQxfHHHCzzpKE0Dr0vJvI2D9A6hdbIoIIb/NvrplK8Hl/tWeRod5XkRjxUudC19Accw4dFe3cbK8cG6+6cFHKByaZxHndwAKqT3+i9hLTdy+iA8jALMtPcB7cs0IuOIV5kOtpPjB8aky0SXtACZzpT+ymlzYxTQXClAPze8aqF38HDaH7+MeO6WDCmviTzh6qZZHAylj0bZI0J8pRrdrHGuUtM9pM4N8UpMeW4G5JIF9ABG/H2PA0jvgbY1TVc95HXpqVzA6Myo2e+Wqnt5Ug/8V38V5SZQzaSXYpsBtLr8uKy2+uGTor4zGiQcoBcUGd1FEwjEcyyQdfY1E4qRmU4yY9hHM7Zn0h5huXnavopTS6BBiK5MekBujHITB+Nvupk821Le0eWMDFBwN01vlCk6u8w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7FC7EAF1EEE7E44EB8E61E61A45A36EB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3209.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc8e6df2-df89-47d5-ba71-08d8476b433d X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2020 13:48:48.6737 (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: PXvLVVLNSj/YiCZE7lLpLwUddwGkB0YQS2KytjmlnDvQdOXou5Qa7vQAG+4ebBp1eJTenKrnlW4wkn5g0zKuZ6D9eatAblftM17F4JFtSPI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3435 Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 23 Aug 2020 13:48:54 -0000 SGkgQWxhbiwNCg0KT24gOC8yMS8yMCAzOjUwIFBNLCBBbGFuIERlS29rIHdyb3RlOg0KPiBPbiBB dWcgMjEsIDIwMjAsIGF0IDM6MjcgQU0sIE1vaGl0IFNldGhpIE0gPG1vaGl0Lm0uc2V0aGk9NDBl cmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPj4gU29ycnkgZm9yIG5pdHBpY2tp bmcgaGVyZS4gQnV0IGl0IGlzIGltcG9ydGFudCB0byBkaXN0aW5ndWlzaCB0aGUgdHdvDQo+PiBj b21wb25lbnRzIHRoYXQgY29tcHJpc2UgYSBBQUEgc2VydmVyOiBSQURJVVMgc2VydmVyIGFuZCBF QVAgc2VydmVyLiBSRkMNCj4+IDM1NzkgYnJpZWZseSBhbGx1ZGVzIHRvIHRoaXMgZGlmZmVyZW5j ZSBhbmQgdXNlcyBkaWZmZXJlbnQgdGVybXMgZm9yIGENCj4+IFJBRElVUyBzZXJ2ZXIgYW5kIGFu IEVBUCBzZXJ2ZXIuIFN1cmUsIHRoZXkgd2lsbCBsaWtlbHkgcnVuIG9uIHRoZSBzYW1lDQo+PiBt YWNoaW5lIGFuZCBhcmUgdGlnaHRseSBpbnRlZ3JhdGVkLCB5ZXQgdGhleSBhcmUgaW5kZXBlbmRl bnQgY29tcG9uZW50cy4NCj4gICAgU29tZSBtaW5vciBuaXQgcGlja2luZyBoZXJlLi4uDQo+DQo+ ICAgIEluIHByYWN0aWNlLCBFQVAgc2VydmVycyBhcmUgdGlnaHRseSBjb3VwbGVkIHdpdGggUkFE SVVTIHNlcnZlcnMuICBBdCBsZWFzdCBmb3Igb25lcyB3aGljaCBpbXBsZW1lbnQgbm9uLXRyaXZp YWwgRUFQIG1ldGhvZHMuDQo+DQo+ICAgIEJ1dCBJIGFncmVlIHRoYXQgdGhleSBuZWVkIHRvIGJl IHRyZWF0ZWQgYXMgaW5kZXBlbmRlbnQgY29tcG9uZW50cy4NCk5vdCBzdXJlIHdoYXQgeW91IGFy ZSBuaXQgcGlja2luZy4gQmVjYXVzZSB5b3UgZXNzZW50aWFsbHkgYWdyZWUgdGhhdCANCnRoZXkg YXJlIGluZGVwZW5kZW50IGNvbXBvbmVudHMgeWV0IHRpZ2h0bHkgaW50ZWdyYXRlZCBpbiBtb3N0 IA0KaW1wbGVtZW50YXRpb25zLg0KPg0KPiAgICBGV0lXLCBJJ3ZlIGxvb2tlZCBmb3IgRUFQIHNl cnZlciBpbXBsZW1lbnRhdGlvbnMuICBBcyBiZXN0IEkgY2FuIHRlbGwgZm9yIE9wZW4gU291cmNl LCBpdCdzIGp1c3QgaG9zdGFwIGFuZCBGcmVlUkFESVVTLiAgRXZlcnl0aGluZyBlbHNlIGlzIGVp dGhlciBkZWFkLCBvciBpbXBsZW1lbnRzIG9ubHkgYSB0aW55IHN1YnNldCBvZiBFQVAsIHN1Y2gg YXMgRUFQLU1ENS4NCkkgYm93IHRvIHlvdSBhbmQgSm91bmkgZm9yIGFsbCB0aGUgaGFyZCB3b3Jr IGluIG1haW50YWluaW5nIHRoZXNlIA0KZXhjZWxsZW50IHBpZWNlcyBvZiBzb2Z0d2FyZS4NCj4N Cj4+IFRoZSB0ZXh0IHlvdSBwb2ludCB0byBpbiBSRkMgMzU3OSBkb2Vzbid0IGltcGx5IHRoYXQg dGhlIE5BSyBpcyBzZW50DQo+PiBmcm9tIHRoZSBFQVAgc2VydmVyLiBJdCBvbmx5IHNheXMgdGhh dCB0byBhdm9pZCByZXRyYW5zbWlzc2lvbnMsIGENCj4+IFJBRElVUyBzZXJ2ZXIgc2hvdWxkIGdl bmVyYXRlIGFuIEFjY2Vzcy1SZWplY3QgY29udGFpbmluZyBhDQo+PiBFQVAtUmVzcG9uc2UvTmFr IG9uIGl0cyBvd24gKHdpdGhvdXQgaW52b2x2aW5nIHRoZSBFQVAgc2VydmVyKS4gU28NCj4+IHRl Y2huaWNhbGx5LCB0aGlzIE5BSyBpcyBzdGlsbCBub3Qgc2VudCBieSB0aGUgRUFQIHNlcnZlciBp biB0aGUNCj4+IHNvLWNhbGxlZCAnd3JvbmcgZGlyZWN0aW9uJy4gSW4gY29tbW9uIHJlYWxpc3Rp YyBpbXBsZW1lbnRhdGlvbnMsIFJBRElVUw0KPj4gc2VydmVycyBvbmx5IHByb3h5IGRhdGEgdG8v ZnJvbSB0aGUgRUFQIHNlcnZlcg0KPiAgICBJJ20gd2FyeSBvZiB0aGUgd29yZCAicHJveHkiLiAg UHJveHlpbmcgaW1wbGllcyBzb21lIGtpbmQgb2YgdHJhbnNwb3J0LCBhcyB3aXRoIFJBRElVUyBw cm94eWluZy4NCj4NCj4gICAgVGhlIHB1YmxpYyBpbXBsZW1lbnRhdGlvbnMgb2YgUkFESVVTK0VB UCAgaGF2ZSB0aGUgdHdvIGNvbXBvbmVudHMgaW4gdGhlIHNhbWUgcHJvY2VzcywgdXNpbmcgc2hh cmVkIGxpYnJhcmllcy4gIFRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSB0d28gaXMganVzdCBB UEkgY2FsbHMuDQo+DQo+PiBhbmQgZG8gbm90IGdlbmVyYWxseQ0KPj4gaW5qZWN0IEVBUCBwYWNr ZXRzIG9uIHRoZWlyIG93bi4gV2hpY2ggaXMgd2h5IEkgc3VzcGVjdCB0aGF0IHRoaXMgaXMgbm90 DQo+PiBpbXBsZW1lbnRlZCBpbiB0aGUgcmFkaXVzIHNlcnZlciBvZiBob3N0YXA6DQo+PiBodHRw czovL3cxLmZpL2NnaXQvaG9zdGFwL3RyZWUvc3JjL3JhZGl1cy9yYWRpdXNfc2VydmVyLmMjbjE0 MzcNCj4gICAgVGhlIFJBRElVUyBzaWRlIG9mIGhvc3RhcCBkb2Vzbid0IGluamVjdCB0aGUgRUFQ IEZhaWx1cmUuICBUaGUgdW5kZXJseWluZyBFQVAgaW1wbGVtZW50YXRpb24gaW5qZWN0cyBpdC4N Cj4NCj4gICAgVGhlIGVhcF9zbV9Qb2xpY3lfZ2V0RGVjaXNpb24oKSBmdW5jdGlvbiByZXR1cm5z IGZhaWx1cmUgaWYgdGhlcmUgYXJlIG5vIGNvbXBhdGlibGUgRUFQIG1ldGhvZHMuICBUaGUgY2Fs bGluZyBmdW5jdGlvbiB0aGVuIHJldHVybnMgRUFQIEZhaWx1cmUuDQo+DQo+IGh0dHBzOi8vdzEu ZmkvY2dpdC9ob3N0YXAvdHJlZS9zcmMvZWFwX3NlcnZlci9lYXBfc2VydmVyLmMjbjE3MjINCj4N Cj4gICAgVGhlIEVBUCBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gaW4gRnJlZVJBRElVUyBhbHNvIHJl dHVybnMgYW4gRUFQIEZhaWx1cmUgcGFja2V0ICBpZiB0aGVyZSBhcmUgbm8gY29tcGF0aWJsZSBF QVAgbWV0aG9kcy4NCj4NCj4gICAgVGhlIHVuZGVybHlpbmcgcHJpbmNpcGxlIGhlcmUgaXMgdGhh dCBzaWxlbnRseSBkcm9wcGluZyBwYWNrZXRzIGlzIGNvbnNpZGVyZWQgYmFkLiAgVGhlcmVmb3Jl LCBubyBtYXR0ZXIgd2hhdCBoYXBwZW5zIGluc2lkZSBvZiB0aGUgRUFQIHN0YXRlIG1hY2hpbmUs IHRoZSBvdXRjb21lIGlzIG9uZSBvZiAzIHRoaW5nczoNCj4NCj4gKiBtb3JlIEVBUCBuZWdvdGlh dGlvbg0KPiAqIFN1Y2Nlc3MNCj4gKiBGYWlsdXJlDQo+DQo+ICAgIFRoZSBvbmx5IHRpbWUgdGhl IFJBRElVUyBzaWRlIGluamVjdHMgYW4gRUFQIEZhaWx1cmUgaXMgaWYgdGhlIHNlc3Npb24gaXMg cmVqZWN0ZWQgZm9yIGFkbWluaXN0cmF0aXZlIHJlYXNvbnMuICBBbmQsIHRoZSBFQVAgc3RhdGUg bWFjaGluZSBpcyBieXBhc3NlZC4gICBlLmcuIGRlbnkgdGhpcyBwYXJ0aWN1bGFyIHVzZXIgb24g dGhpcyBwYXJ0aWN1bGFyIGRldmljZSwgZXZlbiBpZiB0aGVpciBFQVAgY3JlZGVudGlhbHMgYXJl IE9LLg0KPg0KPiAgICAgSW4gdGhhdCBjYXNlLCB0aGUgRUFQIHN0YWNrIGlzIGJ5cGFzc2VkLiAg VGhlIEFjY2Vzcy1SZWplY3QgaGFuZGxlciBjaGVja3MgZm9yIGFuIEVBUC1NZXNzYWdlIGluIHRo ZSBBY2Nlc3MtUmVxdWVzdC4gIElmIGZvdW5kLCB0aGUgUkFESVVTIGxheWVyIHN5bnRoZXNpemVz IGFuIEVBUCBGYWlsdXJlIGluc2lkZSBvZiBhbiBFQVAtTWVzc2FnZS4NCj4NCj4gICAgU2luY2Ug aG9zdGFwIGRvZXNuJ3QgcmVhbGx5IGhhdmUgcG9saWNpZXMgaW4gaXQncyBSQURJVVMgc2VydmVy IGltcGxlbWVudGF0aW9uLCBpdCBkb2Vzbid0IGltcGxlbWVudCB0aGlzIGNoZWNrLg0KDQpTb3Jy eSwgYnV0IHlvdSBhcmUgbWlzc2luZyBjb250ZXh0IGhlcmUuIFRoZSBkaXNjdXNzaW9uIHdhcyBu byBsb25nZXIgDQphYm91dCBzZW5kaW5nIGFuIEVBUCBmYWlsdXJlIHdoZW4gbm8gc3VpdGFibGUg RUFQIG1ldGhvZHMgYXJlIGF2YWlsYWJsZS4gDQpUZXJyeSBhbmQgSSB3ZXJlIGRpc2N1c3Npbmcg dGhlIGRpcmVjdGlvbiBvZiBOQUsgbWVzc2FnZXMgaW4gYW4gRUFQIA0KY29udmVyc2F0aW9uLiBJ IGhpZ2hsaWdodGVkIHRoYXQgYSBOQUsgaXMgb25seSBzZW50IGJ5IHRoZSBwZWVyIHRvIHRoZSAN CnNlcnZlciAoYW5kIG5vdCBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24pLiBUbyB0aGlzLCBUZXJy eSBwb2ludGVkIHRvIHRoZSANCmZvbGxvd2luZyB0ZXh0IGluIFJGQyAzNTc5IFNlY3Rpb24gMi42 LjIgdGl0bGVkICJSb2xlIFJldmVyc2FsIjoNCg0KPiAgICAgIFNpbmNlIEVBUCBpcyBhIHBlZXIt dG8tcGVlciBwcm90b2NvbCwgYW4gaW5kZXBlbmRlbnQgYW5kIHNpbXVsdGFuZW91cw0KPiAgICAg IGF1dGhlbnRpY2F0aW9uIG1heSB0YWtlIHBsYWNlIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbi4g IEJvdGggcGVlcnMNCj4gICAgICBtYXkgYWN0IGFzIGF1dGhlbnRpY2F0b3JzIGFuZCBhdXRoZW50 aWNhdGVlcyBhdCB0aGUgc2FtZSB0aW1lLg0KPg0KPiAgICAgIEhvd2V2ZXIsIHJvbGUgcmV2ZXJz YWwgaXMgbm90IHN1cHBvcnRlZCBieSB0aGlzIHNwZWNpZmljYXRpb24uICBBDQo+ICAgICAgUkFE SVVTIHNlcnZlciBNVVNUIHJlc3BvbmQgdG8gYW4gQWNjZXNzLVJlcXVlc3QgZW5jYXBzdWxhdGlu ZyBhbg0KPiAgICAgIEVBUC1SZXF1ZXN0IHdpdGggYW4gQWNjZXNzLVJlamVjdC4gIEluIG9yZGVy IHRvIGF2b2lkIHJldHJhbnNtaXNzaW9ucw0KPiAgICAgIGJ5IHRoZSBwZWVyLCB0aGUgQWNjZXNz LVJlamVjdCBTSE9VTEQgaW5jbHVkZSBhbiBFQVAtUmVzcG9uc2UvTmFrDQo+ICAgICAgcGFja2V0 IGluZGljYXRpbmcgbm8gcHJlZmVycmVkIG1ldGhvZCwgZW5jYXBzdWxhdGVkIHdpdGhpbg0KPiAg ICAgIEVBUC1NZXNzYWdlIGF0dHJpYnV0ZShzKS4NCkl0IG1heSBzZWVtIGZyb20gdGhpcyB0ZXh0 IHRoYXQgYSBOQUsgaXMgc2VudCBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24gDQooaS5lLiBmcm9t IHNlcnZlciB0byBwZWVyKS4gQnV0IEkgd2FzIHBvaW50aW5nIHRvIFRlcnJ5IHRoYXQgdGhpcyBO QUsgaXMgDQpzZW50IGJ5IHRoZSBSQURJVVMgc2VydmVyIChhbmQgbm90IHRoZSBFQVAgc2VydmVy KS4gU28gdGhlIGZhY3QgdGhhdCBOQUsgDQptZXNzYWdlcyBhcmUgc2VudCBieSB0aGUgRUFQIHBl ZXIgb25seSBzdGlsbCBob2xkcyB0cnVlLiBUaGlzIHByb3RlY3Rpb24gDQphZ2FpbnN0IHJldHJh bnNtaXNzaW9ucyBpcyBub3QgaW1wbGVtZW50ZWQgaW4gaG9zdGFwICggYXMgeW91IGNhbiBzZWUg aW4gDQpodHRwczovL3cxLmZpL2NnaXQvaG9zdGFwL3RyZWUvc3JjL3JhZGl1cy9yYWRpdXNfc2Vy dmVyLmMjbjE0MzcpIG9yIA0KRnJlZVJBRElVUy4gSSBzdXNwZWN0IGJlY2F1c2UgZGVwbG95bWVu dHMgZG9uJ3QgZW5jb3VudGVyIHRoaXMga2luZCBvZiANCnJvbGUgcmV2ZXJzYWwgaW4gcHJhY3Rp Y2UuDQoNCi0tTW9oaXQNCg0KPg0KPiAgICAgQWxhbiBEZUtvay4NCj4gICANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRW11IG1haWxpbmcgbGlz dA0KPiBFbXVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9lbXUNCg== From nobody Sun Aug 23 09:12: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 727F63A0B31 for ; Sun, 23 Aug 2020 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 s71OgBj3ob8H for ; Sun, 23 Aug 2020 09:12: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 99E013A0B2D for ; Sun, 23 Aug 2020 09:12:33 -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 1581B7B; Sun, 23 Aug 2020 16:12:30 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: <7f063355-d02b-8e2f-5eea-6b15580cf3e8@ericsson.com> Date: Sun, 23 Aug 2020 12:12:29 -0400 Cc: Mohit Sethi M , "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4f300bbd-f37b-3b1b-7aee-7e6c448a077d@ericsson.com> <1276BE8C-F9C1-4F13-9A4F-7220A891D051@deployingradius.com> <7f063355-d02b-8e2f-5eea-6b15580cf3e8@ericsson.com> To: Mohit Sethi M X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 23 Aug 2020 16:12:35 -0000 On Aug 23, 2020, at 9:48 AM, Mohit Sethi M = wrote: > Sorry, but you are missing context here. The discussion was no longer=20= > about sending an EAP failure when no suitable EAP methods are = available.=20 > Terry and I were discussing the direction of NAK messages in an EAP=20 > conversation. I highlighted that a NAK is only sent by the peer to the=20= > server (and not in the reverse direction). To this, Terry pointed to = the=20 > following text in RFC 3579 Section 2.6.2 titled "Role Reversal": Ok. >> Since EAP is a peer-to-peer protocol, an independent and = simultaneous >> authentication may take place in the reverse direction. Both = peers >> may act as authenticators and authenticatees at the same time. >>=20 >> However, role reversal is not supported by this specification. A >> RADIUS server MUST respond to an Access-Request encapsulating an >> EAP-Request with an Access-Reject. In order to avoid = retransmissions >> by the peer, the Access-Reject SHOULD include an EAP-Response/Nak >> packet indicating no preferred method, encapsulated within >> EAP-Message attribute(s). FreeRADIUS allows EAP-Request, largely for LEAP. Tho TBH that should = probably be deleted. > It may seem from this text that a NAK is sent in the reverse direction=20= > (i.e. from server to peer). But I was pointing to Terry that this NAK = is=20 > sent by the RADIUS server (and not the EAP server). So the fact that = NAK=20 > messages are sent by the EAP peer only still holds true. This = protection=20 > against retransmissions is not implemented in hostap ( as you can see = in=20 > https://w1.fi/cgit/hostap/tree/src/radius/radius_server.c#n1437) or=20 > FreeRADIUS. I suspect because deployments don't encounter this kind of=20= > role reversal in practice. Yes, I haven't seen EAP -Request sent to RADIUS servers, other than = for LEAP. I'm not sure what you mean by "protection against retransmissions" = though. Alan DeKok. From nobody Sun Aug 23 09:52: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 61F933A0B57 for ; Sun, 23 Aug 2020 09:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 WjL4NiSM9ppX for ; Sun, 23 Aug 2020 09:52:55 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60071.outbound.protection.outlook.com [40.107.6.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 CF8EE3A0B2D for ; Sun, 23 Aug 2020 09:52:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DabMtLbHgw8oaJbNNBbhOboCwqo8EY6MogphGHGLmdpTjHaycdEqA2ZCedZ96fr+VcU+V9Zc1jsr4WRx+uR8KnL51hD+LEukr62T9zbAkoUJI2ryRAlTEluaeNVu6UvEFSgZBbs9And6mOGxpgvEadOhJwIFfiirUy5O5UFuQnHFzfpHsOCFuRQ8RW5wgKORCf2fPGRQFNKKJvweLFVu3+OWsOsXIt8dCB3cG066uKs/Xs9VY8xdG/CGXmYeseqW2ndOm+qX23dDTCzqi/KQS13cqdpXb0wh3du6cwJOehMqwt1qtJohPy1LRJVPv7YZBxNe7Kp8zTlgG4s8JyH3DQ== 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=j0dJv537EsD+BM6a/aQ99S/L6XsDv7Rs7SdPeOoAqvo=; b=lWNGRXROl5ke09U50Xa/if3/utomiboMAiojD3DOI/7cXzP0nI7BVfMID/p+kcamvs/ZBqkAzJ0v50IL11lPD4ZgQpOeD+20kNVMPdCo3VO/6ZA+4nqrPYWZ1nbgWVqKsZlzK5CgSx1HDsVSTtfs/dj5wODlTN9aZjMGDhyV4oo8Xp3+jeLc411oDe2WwkHG+47kIED32PHjrCzNE6tPy1rZhY1Zcj9HLM9yRmNOSLXJ9nedQlGlQsQL2F0oiwzPGp6lD6nsJ3TUxKpgLGOgJdxpCntoI1/dlN265AgsEAmHJXns462d6h2Z9ZY70yapXsyfKaRbO6WK93YsCQaV6w== 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=j0dJv537EsD+BM6a/aQ99S/L6XsDv7Rs7SdPeOoAqvo=; b=MqJIOq4mus+oi6EFCLE/wKqxwkYz+bbtBl6RMUuGdfkhX4MH6vDoRHp3nCuL7fzykR+U6jyhcQIVTFL4FrMzaShzgCun+XlXRxm31S6rjDx3XvCRjklfNspgvhoslAk4ttGsRRgUURh7T/jOwIMsoHKpKxmghXtwlRuCVfxPwTY= Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR0701MB2939.eurprd07.prod.outlook.com (2603:10a6:3:52::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.12; Sun, 23 Aug 2020 16:52:52 +0000 Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::89f5:f583:b074:b4f6%5]) with mapi id 15.20.3326.016; Sun, 23 Aug 2020 16:52:52 +0000 From: Mohit Sethi M To: Alan DeKok , Mohit Sethi M CC: "emu@ietf.org" , Mohit Sethi M Thread-Topic: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods Thread-Index: AQHWdtBd6/Chl5vFm0Cl50TEYc0wYalA5faAgAAI2ACAAA6fAIAAB6mAgAANYoCAARjagIAAWj6AgAM1DoCAACgmgIAAC0iA Date: Sun, 23 Aug 2020 16:52:51 +0000 Message-ID: <13d9ed53-7daf-8697-67b0-29bd884224f8@ericsson.com> References: <4f300bbd-f37b-3b1b-7aee-7e6c448a077d@ericsson.com> <1276BE8C-F9C1-4F13-9A4F-7220A891D051@deployingradius.com> <7f063355-d02b-8e2f-5eea-6b15580cf3e8@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.10.0 authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:4384:9700:db31:7396:a479] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 076bd9dd-5c3b-4c21-8dd6-08d84784f98d x-ms-traffictypediagnostic: HE1PR0701MB2939: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1850; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o8TPcnLnv7yQQtWvRB3druQB8RTsTkj2OFGTDE90jy/0t/t/0MJ0af9RKXqLczTJ6OhYaa8cSc8MltBAMMs1jMvE6q+q/tvflFdy1rpwL6Q7y1BrVkLmfuujbBxwU0aUmBniPCVSDblmyA2ufOvSirAY+/tnfoeTnzBh2DZMam74wCNHWYCF/wGjRVJLj4vCzLnw//Vfcpq6ZMFuVvmll2KksV42mPEAtUPBzOoVIe/OpqMpeaRVFTIIPH/zt7S1QZf2L42q31L+DaZc4ZZuGuGfCiw6DVdOXDo+kzLB1OVeUeIFhHCrzajuruxCdUW4JrIUUoWNhL7PhCU2AJquASOOsUoriKQVymcVQh1k22WnGLcm3mMtX8JVohnq/ccDjkSuHuJi2YV56C6iO+Vq5Cxe9H6EkdEv3xKW5ZmPDIRwbQYpCjLGeLLCebmbtFlu3uI8+kiKvfg4cbcORIdo5A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(39860400002)(366004)(396003)(376002)(2616005)(2906002)(36756003)(83380400001)(966005)(6506007)(8676002)(53546011)(31696002)(186003)(8936002)(478600001)(86362001)(5660300002)(6512007)(316002)(66946007)(66556008)(76116006)(66446008)(66476007)(64756008)(6486002)(71200400001)(4326008)(54906003)(31686004)(110136005)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: CGKTfNnqpPY6VSzHp63vfkGYitUiavjoIQCSoJAAH4d9Zj8t6SxdDL1XuVkn3vOtyWE6CBrO1WmGuLyVMk/qnBH8cWKST85u44MCNNxqgCYAly0UEN52QPgYdQE/CQKNfq/QbgBrRP+VZPMuOPsvUDUGlDEJYtaoILF8rjv0lG6bxEWsD2/SRUegH0E3mFqWKqUMRIUdk1UqvaXFNIKNuoDAPQGTs8D9ntLn+gqZoO36I65DrmzkIwEWUFa4qqGb7j54iXSVT8dGtpx28T5VAT8t3qlnDAFXD8NWaVfpPzOfD1hTCoPYN1iFWmE8AnWBapVI7x56mSrPee2pExVO+nV3UV6Al8rlp1GEB2LyrN719ea39abyibx1a0u5M0BvUBQhL4VZbm35DxPeoQDeDRjppPVK4khAVpCtJFWqcCVTVhfJj6iNrq8cDptqZ4CPIUpUzt4ICsXc5cW2mHaeDywWBTxQS+jfcnWQ2SZt6s7uPdXOXKMQB80zxSHqYpP39KEX92oZQsGIrv+1CWUdEej+cSnU06KMFyPc1DxlQv+Xk7Ru1ANm6j+FATrO4ZNUrzeplEapRGNuMGv+Uu7YC/51EVttSq4ogwe+g2XUxQ8iiE+sBB25UUhCk8QO2VckTLQ4TOEgUI1qRPFal3rOAXWZZeMAqLz5axR3TosoFN7oJl6Ty9KMCAmn3aWFYA0I7uIarDjfCmxsnCz+9/MQUw== Content-Type: text/plain; charset="utf-8" Content-ID: <4566AE5FFA319347830E8B55C437932B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3209.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 076bd9dd-5c3b-4c21-8dd6-08d84784f98d X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2020 16:52:51.9574 (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: kDEbHP/UpY+nlrqQsLtpp7iIoxdti6L6vdhTiYSjj9F/E9zGapQONZ4O9qq94o/wBEzfrS5UHbipokygcivdmTv8BfKe54uI9nzGyCp6y/A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2939 Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 23 Aug 2020 16:52:56 -0000 SGkgYWdhaW4sDQoNCk9uIDgvMjMvMjAgNzoxMiBQTSwgQWxhbiBEZUtvayB3cm90ZToNCj4gT24g QXVnIDIzLCAyMDIwLCBhdCA5OjQ4IEFNLCBNb2hpdCBTZXRoaSBNIDxtb2hpdC5tLnNldGhpQGVy aWNzc29uLmNvbT4gd3JvdGU6DQo+PiBTb3JyeSwgYnV0IHlvdSBhcmUgbWlzc2luZyBjb250ZXh0 IGhlcmUuIFRoZSBkaXNjdXNzaW9uIHdhcyBubyBsb25nZXINCj4+IGFib3V0IHNlbmRpbmcgYW4g RUFQIGZhaWx1cmUgd2hlbiBubyBzdWl0YWJsZSBFQVAgbWV0aG9kcyBhcmUgYXZhaWxhYmxlLg0K Pj4gVGVycnkgYW5kIEkgd2VyZSBkaXNjdXNzaW5nIHRoZSBkaXJlY3Rpb24gb2YgTkFLIG1lc3Nh Z2VzIGluIGFuIEVBUA0KPj4gY29udmVyc2F0aW9uLiBJIGhpZ2hsaWdodGVkIHRoYXQgYSBOQUsg aXMgb25seSBzZW50IGJ5IHRoZSBwZWVyIHRvIHRoZQ0KPj4gc2VydmVyIChhbmQgbm90IGluIHRo ZSByZXZlcnNlIGRpcmVjdGlvbikuIFRvIHRoaXMsIFRlcnJ5IHBvaW50ZWQgdG8gdGhlDQo+PiBm b2xsb3dpbmcgdGV4dCBpbiBSRkMgMzU3OSBTZWN0aW9uIDIuNi4yIHRpdGxlZCAiUm9sZSBSZXZl cnNhbCI6DQo+ICAgIE9rLg0KPg0KPj4+ICAgICAgU2luY2UgRUFQIGlzIGEgcGVlci10by1wZWVy IHByb3RvY29sLCBhbiBpbmRlcGVuZGVudCBhbmQgc2ltdWx0YW5lb3VzDQo+Pj4gICAgICBhdXRo ZW50aWNhdGlvbiBtYXkgdGFrZSBwbGFjZSBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24uICBCb3Ro IHBlZXJzDQo+Pj4gICAgICBtYXkgYWN0IGFzIGF1dGhlbnRpY2F0b3JzIGFuZCBhdXRoZW50aWNh dGVlcyBhdCB0aGUgc2FtZSB0aW1lLg0KPj4+DQo+Pj4gICAgICBIb3dldmVyLCByb2xlIHJldmVy c2FsIGlzIG5vdCBzdXBwb3J0ZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLiAgQQ0KPj4+ICAgICAg UkFESVVTIHNlcnZlciBNVVNUIHJlc3BvbmQgdG8gYW4gQWNjZXNzLVJlcXVlc3QgZW5jYXBzdWxh dGluZyBhbg0KPj4+ICAgICAgRUFQLVJlcXVlc3Qgd2l0aCBhbiBBY2Nlc3MtUmVqZWN0LiAgSW4g b3JkZXIgdG8gYXZvaWQgcmV0cmFuc21pc3Npb25zDQo+Pj4gICAgICBieSB0aGUgcGVlciwgdGhl IEFjY2Vzcy1SZWplY3QgU0hPVUxEIGluY2x1ZGUgYW4gRUFQLVJlc3BvbnNlL05haw0KPj4+ICAg ICAgcGFja2V0IGluZGljYXRpbmcgbm8gcHJlZmVycmVkIG1ldGhvZCwgZW5jYXBzdWxhdGVkIHdp dGhpbg0KPj4+ICAgICAgRUFQLU1lc3NhZ2UgYXR0cmlidXRlKHMpLg0KPiAgICBGcmVlUkFESVVT IGFsbG93cyBFQVAtUmVxdWVzdCwgbGFyZ2VseSBmb3IgTEVBUC4gIFRobyBUQkggdGhhdCBzaG91 bGQgcHJvYmFibHkgYmUgZGVsZXRlZC4NCj4NCj4+IEl0IG1heSBzZWVtIGZyb20gdGhpcyB0ZXh0 IHRoYXQgYSBOQUsgaXMgc2VudCBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24NCj4+IChpLmUuIGZy b20gc2VydmVyIHRvIHBlZXIpLiBCdXQgSSB3YXMgcG9pbnRpbmcgdG8gVGVycnkgdGhhdCB0aGlz IE5BSyBpcw0KPj4gc2VudCBieSB0aGUgUkFESVVTIHNlcnZlciAoYW5kIG5vdCB0aGUgRUFQIHNl cnZlcikuIFNvIHRoZSBmYWN0IHRoYXQgTkFLDQo+PiBtZXNzYWdlcyBhcmUgc2VudCBieSB0aGUg RUFQIHBlZXIgb25seSBzdGlsbCBob2xkcyB0cnVlLiBUaGlzIHByb3RlY3Rpb24NCj4+IGFnYWlu c3QgcmV0cmFuc21pc3Npb25zIGlzIG5vdCBpbXBsZW1lbnRlZCBpbiBob3N0YXAgKCBhcyB5b3Ug Y2FuIHNlZSBpbg0KPj4gaHR0cHM6Ly93MS5maS9jZ2l0L2hvc3RhcC90cmVlL3NyYy9yYWRpdXMv cmFkaXVzX3NlcnZlci5jI24xNDM3KSBvcg0KPj4gRnJlZVJBRElVUy4gSSBzdXNwZWN0IGJlY2F1 c2UgZGVwbG95bWVudHMgZG9uJ3QgZW5jb3VudGVyIHRoaXMga2luZCBvZg0KPj4gcm9sZSByZXZl cnNhbCBpbiBwcmFjdGljZS4NCj4gICAgWWVzLCBJIGhhdmVuJ3Qgc2VlbiBFQVAgLVJlcXVlc3Qg c2VudCB0byBSQURJVVMgc2VydmVycywgb3RoZXIgdGhhbiBmb3IgTEVBUC4NCj4NCj4gICAgSSdt IG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgInByb3RlY3Rpb24gYWdhaW5zdCByZXRyYW5zbWlz c2lvbnMiIHRob3VnaC4NCg0KV2VsbC4gSSBhbSByZWZlcnJpbmcgdG8gdGhlIHRleHQgZnJvbSB0 aGUgUkZDIDM1Nzk6ICJJbiBvcmRlciB0byBhdm9pZCANCnJldHJhbnNtaXNzaW9ucyBieSB0aGUg cGVlciwgdGhlIEFjY2Vzcy1SZWplY3QgU0hPVUxEIGluY2x1ZGUgYW4gDQpFQVAtUmVzcG9uc2Uv TmFrIHBhY2tldCBpbmRpY2F0aW5nIG5vIHByZWZlcnJlZCBtZXRob2QsIGVuY2Fwc3VsYXRlZCAN CndpdGhpbiBFQVAtTWVzc2FnZSBhdHRyaWJ1dGUocykuIiBJdCBpcyBjbGVhciB0aGF0IGhvc3Rh cCBkb2VzIG5vdCAoeWV0KSANCmltcGxlbWVudCB0aGlzIFNIT1VMRC4gSSBzdXNwZWN0IHRoYXQg RnJlZVJBRElVUyBkb2Vzbid0IGVpdGhlci4gTWF5YmUgDQp0aGF0J3MgYmVjYXVzZSBpdCBuZWVk cyB0byBhbGxvdyByb2xlIHJldmVyc2FsIChpLmUuIHBlZXIgc2VuZGluZyBhbiANCkVBUC1SZXF1 ZXN0KSBmb3IgTEVBUD8NCg0KLS1Nb2hpdA0KDQo+DQo+ICAgIEFsYW4gRGVLb2suDQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVtdSBtYWls aW5nIGxpc3QNCj4gRW11QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZW11DQo= From nobody Sun Aug 23 13:50: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 223423A0E55 for ; Sun, 23 Aug 2020 13:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 wwsAB_m4oY36 for ; Sun, 23 Aug 2020 13:50:35 -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 79C103A0E56 for ; Sun, 23 Aug 2020 13:50:35 -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 5F679295; Sun, 23 Aug 2020 20:50:33 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Alan DeKok In-Reply-To: <13d9ed53-7daf-8697-67b0-29bd884224f8@ericsson.com> Date: Sun, 23 Aug 2020 16:50:32 -0400 Cc: "emu@ietf.org" , Mohit Sethi M Content-Transfer-Encoding: quoted-printable Message-Id: <44F00A6D-3D0C-4A5C-A665-9A0E6052B1C5@deployingradius.com> References: <4f300bbd-f37b-3b1b-7aee-7e6c448a077d@ericsson.com> <1276BE8C-F9C1-4F13-9A4F-7220A891D051@deployingradius.com> <7f063355-d02b-8e2f-5eea-6b15580cf3e8@ericsson.com> <13d9ed53-7daf-8697-67b0-29bd884224f8@ericsson.com> To: Mohit Sethi M X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods 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, 23 Aug 2020 20:50:37 -0000 On Aug 23, 2020, at 12:52 PM, Mohit Sethi M = wrote: > Well. I am referring to the text from the RFC 3579: "In order to avoid=20= > retransmissions by the peer, the Access-Reject SHOULD include an=20 > EAP-Response/Nak packet indicating no preferred method, encapsulated=20= > within EAP-Message attribute(s)." Ah, OK. > It is clear that hostap does not (yet)=20 > implement this SHOULD. I suspect that FreeRADIUS doesn't either. Maybe=20= > that's because it needs to allow role reversal (i.e. peer sending an=20= > EAP-Request) for LEAP? Yes. TBH, it's 2020. I'll just go delete support for LEAP. There's just = no reason to allow it to be used. I'll also add the NAK in the access-Reject as per RFC 3579. Alan DeKok. From nobody Wed Aug 26 09:12: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 1E9973A1623; Wed, 26 Aug 2020 09:12:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Joseph Salowey , joe@salowey.net, iesg-secretary@ietf.org, emu@ietf.org, emu-chairs@ietf.org Message-ID: <159845832410.18299.9257108256505967361@ietfa.amsl.com> Date: Wed, 26 Aug 2020 09:12:04 -0700 Archived-At: Subject: [Emu] Publication has been requested for draft-ietf-emu-eaptlscert-05 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, 26 Aug 2020 16:12:04 -0000 Joseph Salowey has requested publication of draft-ietf-emu-eaptlscert-05 as Informational on behalf of the EMU working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/ From nobody Wed Aug 26 09:15:00 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 E3D363A1603 for ; Wed, 26 Aug 2020 09:14:58 -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 EUS4vf5NqyqG for ; Wed, 26 Aug 2020 09:14:57 -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 E57DA3A15F6 for ; Wed, 26 Aug 2020 09:14:55 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id z3so2393140qkz.7 for ; Wed, 26 Aug 2020 09:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=oV0iBgfR9f0lCnuA91HiKo3E0IEQstzLPsnSIw70nFA=; b=N3s2SD3jzBUt/MArAA5P8yUacE4kvmjLbLLpOzo/ggW4kh7xykEsqcwFhjjNZD6dEN K0j8FR4V+9Q57jWEzJ4/GiUqGXcm6J22xXuRgKWbeAf/CVW7ec8xWNF9IN/zVcLWP2rD LUYgBpOGRTjvEfGz9TRmJlPYwwsrgjphLTOr69nPDB8DUn67xs5yCKe0F4jDNBjp07lD 6BXsGOb67FV2SB1tvh3Kt6x9RAuxUJ1MfrGHwnbohbvICClIc8lmwBGf/QVHtWqN41uO TUGOCFZ3Jx8lNziMRkEssjlKBTfqr6V6y53HHojkBaYGTBkWWV+rTj+gn1Fo7VhteLJv cdfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oV0iBgfR9f0lCnuA91HiKo3E0IEQstzLPsnSIw70nFA=; b=oqysMIISa+ihFtPnjDNYobsNDwOkcKeNu0VG3MQ5e66eRhbiSSI0w8qzzAE6lB/W1m pDSB2g5VIxV+uEuHQlGxDLVmJdwfHLIsIsCp5wxoCkmjVhGLNm+DQ6FOEkPUn1Qy35wt gD2IrXpZR1ub2REZoHWt8sna29AvAHu3A1g5EIEFQ/mMA/5LjGusrglhkU/JPRFdOmUw rG+6Ku14b7jbB3UsTSECyjt/CtNQuSaAym0TkEncNEgBnSxHobUBp3LpGq7WAkWGz5QR BD+WCctlGCjaRGj7DqHZBlJXx1AVMDO6Jxyt3Sk2iMSxoCzN3Ech6K+kOwgnY7Umjefs RvrA== X-Gm-Message-State: AOAM532yZESXv4e5FSK+lMet6ZZsMvGuqvmcE7+4NKvS5HAb9MIl0YjC W3JgtfpiG+gSjjRUV+YNOep0V5FBxpogNDWAyk9PhSSoSOdTqA== X-Google-Smtp-Source: ABdhPJw+dbpK4KDHNG12+d/0/KLogX5lEkdbZnwdi2BKYJJmAr6DeV8MqoEl1jstKWRNGEhBXyTE3Q5hdl0z0XpAxCU= X-Received: by 2002:a37:4e8a:: with SMTP id c132mr14242711qkb.472.1598458494777; Wed, 26 Aug 2020 09:14:54 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Wed, 26 Aug 2020 09:14:44 -0700 Message-ID: To: EMU WG Content-Type: multipart/alternative; boundary="000000000000c5156b05adca1e22" Archived-At: Subject: [Emu] Handling Large Certificates and Long Certificate Chains submitted for publication 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, 26 Aug 2020 16:14:59 -0000 --000000000000c5156b05adca1e22 Content-Type: text/plain; charset="UTF-8" Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods (draft-ietf-emu-eaptlscert-05) has been submitted to the IESG for publication. The shepherd write-up can be found here - https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/shepherdwriteup/ Cheers, Joe --000000000000c5156b05adca1e22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Handling Large Certificates and Long Certificate Chains in= TLS-based EAP Methods (draft-ietf-emu-eaptlscert-05) has been submitted to= the IESG for publication.=C2=A0 The shepherd write-up can be found=C2=A0 h= ere -=C2=A0https://datatracker.ietf.org/doc/draft-ietf-emu-eap= tlscert/shepherdwriteup/

Cheers,

Joe
--000000000000c5156b05adca1e22--