From nobody Thu Jul 14 05:58:28 2022 Return-Path: X-Original-To: regext@ietfa.amsl.com Delivered-To: regext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805E4C16ECBF for ; Thu, 14 Jul 2022 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pirorg.onmicrosoft.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCEfzmdIruDD for ; Thu, 14 Jul 2022 05:58:22 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2105.outbound.protection.outlook.com [104.47.55.105]) (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 BA2B6C16ECBE for ; Thu, 14 Jul 2022 05:58:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UG58L5HZYw7439MmDp040NljlZ/1aYy2QSE+lgmQZtoe7rkXc8trPcdzJv4GwqQqbA+DuHbJpH3x5B+vU1YFq4FfkqNhG4QVVzR4NsxGjYNHiZfTRpCbhxGGPees7AKiX30CytT97hlvlDRVlYckWyJxIifnipyS1RspRx4wT/0ecUumP9GxBKDmCvs+Ul0V6by0RQaw0U1RoXZhU0u+JNFOcBEanD1BrBOzZBJ/9p1/J6y0VYZS/SCFzEU+NiXcnZ4THsEcLLat5tsAM8Arrnu0ZP9nlNBxrRJDX/UyxksHPMoxLHh5WFFRdh5n7WPoIzbm+q301pHPY2jPYXAqyA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5X8Z5Yngree3WGx6SNO4c4aucbmEs3i/yzCaipqUfkQ=; b=O+pT4oAdMMkSqXFARdWjmTnmjtmdtGSa5GJCcVPMG7Js2EI5+fB5B1M17BbWQzuH++KOKFq7+AiksFz0yHLSCTpFRu1Bu2N74tpfZuGgxgNzy0s67+tvza6iexpoU+Fqdk0PknV+LD99yWlZA8IiLSso6ZqYKD0FIAIiJYEAxfM23AX5J335JPU2Q/k9ujH3jgCKDTNvMR77k5qJdkHM7QiHxhKtTO2aNhXlyfNSkHVFMqWJIPbCyQgs2prTweRxiJppbvCjhtDJ3Atdo6r5mYkPByiZPQ/lx/BwhmSs0j9iKrPlhC3oex9iDiRPG4bCUGYOkjFDqTkIqnL8bJM/7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=pir.org; dmarc=pass action=none header.from=pir.org; dkim=pass header.d=pir.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pirorg.onmicrosoft.com; s=selector2-pirorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5X8Z5Yngree3WGx6SNO4c4aucbmEs3i/yzCaipqUfkQ=; b=iAKofCPeSDu9iPoAxy7NIC0qlI8JxML1VduXVaeNCLTHaJWIzCRuyflxaHSVTKxTebv6T9Q0wFEyvM/C63fprH19Cn6AY3f0Dp13nn7xzzCrd6NroMpjNbCSj9I6hFQE+3ZNZhtOoLdY/jg3uTsawUXjGmMkLIaxt62DQ3inF7o= Received: from BY5PR10MB4179.namprd10.prod.outlook.com (2603:10b6:a03:206::8) by DM6PR10MB3802.namprd10.prod.outlook.com (2603:10b6:5:1f9::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5438.12; Thu, 14 Jul 2022 12:58:16 +0000 Received: from BY5PR10MB4179.namprd10.prod.outlook.com ([fe80::1521:31a5:949b:8aee]) by BY5PR10MB4179.namprd10.prod.outlook.com ([fe80::1521:31a5:949b:8aee%5]) with mapi id 15.20.5438.012; Thu, 14 Jul 2022 12:58:16 +0000 From: Rick Wilhelm To: Mario Loffredo , "Hollenbeck, Scott" , "jgould=40verisign.com@dmarc.ietf.org" , "regext@ietf.org" Thread-Topic: NA Re: [regext] Login/Logout Processing (was RE: I-D Action: draft-ietf-regext-rdap-openid-15.txt) Thread-Index: AQHYl4FiR9P/xNhHFEah5nTjhhojfQ== Date: Thu, 14 Jul 2022 12:58:16 +0000 Message-ID: References: <920FFD8E-B060-416D-B838-61010E51C50A@verisign.com> <08c3a4aecaeb467eac9152b880cc85ba@verisign.com> <4c501148e5d84084bf9f92467e2747d5@verisign.com> <671352ca-d76d-e9b1-a3ae-2cfe9f6c64d7@iit.cnr.it> In-Reply-To: <671352ca-d76d-e9b1-a3ae-2cfe9f6c64d7@iit.cnr.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=PIR.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 50421843-82c4-4703-152f-08da65988517 x-ms-traffictypediagnostic: DM6PR10MB3802:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kMW1TNiCsFbGnsU1H1oWzA39dYLj+iXNY2nTRpiX5n9ihgfPKVtKa53Cd+ZkYgFH8EdnH1QNHZZwfXuT5Ai35VDYDEfAdTZ4Qr604GlUHsJwzQ7HHIaocrGB7zqwfoPqGG3bhufEMwbGghgtYMsuGSiDA/2fibYy2bQRmtQ3bKnM1Dz9Z0dQHPE4sTw3TbwKbdqQFGmhuD20Z8WQce24S6UhaAAbuq5jzfphh0rGXSXAv05ek0KhJE99sERBuVWh5mfpWehr3jnje8gXBK5llzOv3GJt4Pe/BfxlxB6zKYm5EG6eww9p6I3ta7eLNWEiqCJlIfsF3C6EjtTv2F+kFKk0PtaAJO/FqJq/d4xT6mHVa8OQcl5bBGnbAEbRZjUFc6m2BlxDspsDGJmSUUvYV90I7R0mFNDGT5heAihkeT5ol3Bf/NLYuHxsQpRy/tGSQGu4GuclvMQo2OxeF4A/egEtySum8fg/sWCxONTW0O7JKA3moi5DXm35lF3ukoL/C8t+LPimmtGxuwUIeIbKz9eRzM1+/yK9zjYwulciQidds/lz76xQMb0Tg2KCIgumk0Pti6bdlJ8575QzZHUuQdIjjItGl1EOVNLjpGfWn8HPgHmj1aCbGjoD6xMxIzdSsuq4uLlKqCYAhKO5GJeAC4rAHxdQWljSNxbuc8xftkDykz87pv39oMaWYxxpGWRDlc0x76oxRnXveHALgpzKjtCfpZKX9J+zGhgNW3Onlb0qRi5bhm/GuKAO7XBVtlRMG9lLCuZYUOgUIDcv08HA53IMMA7wU43TDjaQvE6Po5OWXW0RFKcbZDI55dXXFh/CFxuMaLg7P/lLdAsHUrzqb6ZbfCGnwbu450SPW3rQN/rfpOHg6aqRzG3QjyuLQHfx x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR10MB4179.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(396003)(39830400003)(136003)(346002)(366004)(376002)(55016003)(83380400001)(84970400001)(166002)(40140700001)(86362001)(66574015)(122000001)(38070700005)(8936002)(38100700002)(52536014)(5660300002)(33656002)(30864003)(53546011)(2906002)(478600001)(41300700001)(71200400001)(316002)(8676002)(110136005)(966005)(66556008)(66446008)(76116006)(64756008)(186003)(66946007)(9686003)(26005)(66476007)(6506007)(7696005)(91956017); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?Atf9eqkJ6dibw4FwkQGW0+BNjqpSeXNBl6m4lHznC/7ZJUDrWrEqsfxe?= =?Windows-1252?Q?UtWqnaXaE/MQAIBFDugF98pLCKk73Bm6L9yPJRJVlbPEcvf/VabBuoxL?= =?Windows-1252?Q?4IJm0IPPbbqrTM0WIFpXY1MOCw0PSby75XJqVkJABd4se6VD0T156V1A?= =?Windows-1252?Q?JUl8bbYwuBNFqYPaNYOqcMhr2QCtWEBxNX3pqKlBFFulWeyLw9nNlKjp?= =?Windows-1252?Q?5AfvgL7wtDdH5+r13T+so5ujsm7iNEw3aZZCg1PXsndDQqQlKfH97TNJ?= =?Windows-1252?Q?vO6qpiQXnUW26RJIvx6aakWQi3GPMD1IZYm9H2DoGUg/LrBZC1pPgL+1?= =?Windows-1252?Q?QE5IsVFYEB2ejDecBztMajoFi2jey3bFriptjPc3UPaqhNSLIRTAdEiN?= =?Windows-1252?Q?G/v6KYWESCUAjYqyBWX9mMFobKZTLMVBwe1hM7a+FiA2ymSbubqRKUIY?= =?Windows-1252?Q?uaYTaryJU9zrSUap9rKJCoUFvPnSKCKIVRZBjX8ebGiD86Qae2lYKmza?= =?Windows-1252?Q?W8VEfzR2VfA4oB0jwedcUBFv4lqOZg5w9jW6MDir98RInIGwpwfbtvY7?= =?Windows-1252?Q?NxcPRrMo3cG570PWHL4dn0Ix/d/FyXhaQ2QATKI+NGZTWXNG+uyJHcCD?= =?Windows-1252?Q?Ofx7MbY2uTmXX+j8q2TPFCwTJYX/GaVVsUwJCqMTw8sJaUeSl0men2Oj?= =?Windows-1252?Q?rn5ltOGzHGhmg7YZgGicBG/aojXdym4UZVNJ8jnaIl12wI36SeFR0nEx?= =?Windows-1252?Q?hQFf81z+eEA1O5UtJi9WG/3wxDttQiNS7q4dHGk/nekDeV3aWK3XIB6u?= =?Windows-1252?Q?FJnnCT7rIQV/Rp57jDMOso/cAvUmbAbr+4mNqMdOu8QxP347UX2sOajL?= =?Windows-1252?Q?3OUIYSWXpt8vZZSDevmPHq2FosFOxKGGpFCnz8qoV8qNZ9Z17VL9hV2X?= =?Windows-1252?Q?zkfGgSv5Ficoo0b/OYMlJfCbbHxvGPprh7AnaKsZO3OoWqCZay7zaps+?= =?Windows-1252?Q?3miOeZNNr+QaXRSS9u47UVhaddIYTnIybJdsbZF8yccrZb+gbJFIqxgU?= =?Windows-1252?Q?die5ImVZgU1sC9UE+j1IdvdufcPWoMe4wym2iZqtYY0LYWyAZxjsFEr/?= =?Windows-1252?Q?VwKe23II1aWCmii1qCaqDA0Yjq6w5jY4eyb5xcfsDxpllpusWlG6o8zN?= =?Windows-1252?Q?60TOriBvR07Mr33xmNYKROV+i/3FWOBQCheZ3eJhFVkqt9Mt+rMyrGCs?= =?Windows-1252?Q?VCUx2XGOHbezljhnnuQdqaN7qWnoIyeTZvSJzhJI7mtm/m5UJ8xaEuYi?= =?Windows-1252?Q?pLvIFXbOYdnkto7rERK/3Mc1NMEL27OjmrIjlSIz83t+6BIplKO2BTHv?= =?Windows-1252?Q?WSUdhdTwHQ1yKh14sdiioPQj2u6elofPmvd1hcfN3JENaSqdp1LPbAJt?= =?Windows-1252?Q?ZJr2JO+6Gp6/T7ki4DTmP6HRE3mOdmezo9RsjrwKVSy8uFkSS2N6RpTj?= =?Windows-1252?Q?+bqkRxBA4LMpXh0jM4QOdSGj76H9zsNLi8AbvcdAfrF8s9k0pp5Ko6R8?= =?Windows-1252?Q?7w72lKRbsKqspyh/SG15MOerPnSlvCb0m+cjcCAmesjL7Hhlb+f0qQpt?= =?Windows-1252?Q?rg/Q7kHlqVjAl9prsk2wLU+b5dsNm/Hu3IuITOwizYAWuMoCNPv+7N/L?= =?Windows-1252?Q?f1QzqP180nEWPgymfV8SFwVeAs5OdmQ7q+Atq9KRIx0ja/5pXXGx0Q?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY5PR10MB4179D8F37EF7EF9E9239D9BAC9889BY5PR10MB4179namp_" MIME-Version: 1.0 X-OriginatorOrg: pir.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4179.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50421843-82c4-4703-152f-08da65988517 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2022 12:58:16.8350 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6c8ced78-b98f-4fa4-b6df-38beaa0d935d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tpPBFifFZGEvtDMRnmk9TG7/lgx0htSWkoP3/IzoHc+s2YZVT2ZRsv5OcHyUkESUMY5/QG70yaBy/h542T7a1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB3802 Archived-At: Subject: Re: [regext] NA Re: Login/Logout Processing (was RE: I-D Action: draft-ietf-regext-rdap-openid-15.txt) X-BeenThere: regext@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Registration Protocols Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2022 12:58:27 -0000 --_000_BY5PR10MB4179D8F37EF7EF9E9239D9BAC9889BY5PR10MB4179namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good inputs and upgrades from Mario. In summary, I agree about returning a= n error because of the expected typical complexity of cookies. But for I=92ll elaborate a bit regarding the =93giving up security info=94 = that I had mentioned in a prior message, which was admittedly vague and lik= ely overstated. Assuming that the cookie doesn=92t contain identity information about the c= lient, this wouldn=92t be an issue. But if the cookie has identity (login)= info embedded, and the server just processes the logout request by respond= ing with overly verbose errors like =93 not logged in=94 or =93 not registered=94 rather than simply rejecting with a vague error messag= e, then the server would be giving up information about the status of that = login. Hope that helps=85 and apologies for any over-complexifying on this use-cas= e. Thanks Rick From: Mario Loffredo Date: Thursday, July 14, 2022 at 3:32 AM To: Hollenbeck, Scott , Rick W= ilhelm , jgould=3D40verisign.com@dmarc.ietf.org , regext@ietf.org Subject: [EXTERNAL] Re: [regext] Login/Logout Processing (was RE: I-D Actio= n: draft-ietf-regext-rdap-openid-15.txt) CAUTION: This email came from outside your organization. Don=92t trust emai= ls, links, or attachments from senders that seem suspicious or you are not = expecting. ________________________________ Il 13/07/2022 16:41, Hollenbeck, Scott ha scritto: Notes below, Rick. From: Rick Wilhelm Sent: Tuesday, July 12, 2022 4:05 PM To: Hollenbeck, Scott ; jgould=3D40verisign.com@dmarc.ietf.org; regext@ietf.org Subject: [EXTERNAL] Re: [regext] Login/Logout Processing (was RE: I-D Actio= n: draft-ietf-regext-rdap-openid-15.txt) Caution: This email originated from outside the organization. Do not click = links or open attachments unless you recognize the sender and know the cont= ent is safe. Briefly, I think that (per a point that Mario made) the situations described below a= re different and might merit consideration differently. Specifically, these= situations: > Let's look at the server-side options again for situations in which the s= erver > receives a login followed by a login, or a logout where there's been no > login, > or a refresh without an active session, or a session status without an ac= tive > session: - Login followed by login: sounds similar to a point that Mario made relat= ed to extending a session; seems fine, not an error [SAH] Under certain circumstances, I now agree. A client might be serving m= ultiple end-users, and the server should be able to start another session f= or a different user if it receives a second login request without a cookie.= If the server receives a login request with a valid cookie, though (the se= rver is seeing a second login request on an active session), I=92d prefer t= o keep command processing idempotent such that the second login isn=92t pro= cessed differently than the original login was, and return an error since t= he request conflicts with the current state of the server. That=92ll make c= lient processing consistent. [ML] Just for clarifying what I've said. Every login without a cookie is valid in general. The only exception to tha= t is when it breaks some server policy, e.g. a server limits the number of = concurrent sessions per user and this limit has been exceeeded. Forbidding = always two subsequent login coming from the same user means that such a lim= it i set to 1. Therefore, it is a special case of a constraint depending on server policy.= For this reason, it's wrong to define it as specification constraint but i= 'm inclined to include it in the security consideration as a measure server= s can implements to mitigate the risk of DoS or huge consumption of resourc= es. - logout where there has been no login: while it might be tempting to want= to give back an error, I would argue that this gives up security info abou= t the client. Therefore, is there harm in just saying =93ok=94 ?? [SAH] Please elaborate regarding =93security info=94. I=92m inclined to ret= urn an error because, again, the request conflicts with the current state o= f the server. The client won=92t be misled into thinking that it ended a se= ssion when there was no session to begin with. [ML] I would like to give a further contribution that could be helpful. When does it happen that a logout include an invalid cookie? There are at l= east two cases coming in my mind: - the client sends a logout on a session that has been ended by the server = (e.g. due to timeout or the session max time has been exceeded) - the clients sends an unsuccessful login, then it doesn't check that the s= erver hasn't returned a session cookie, and nevertheless it sends some requ= ests and a final logout In both cases, returning an error on the logout request can be helpful for = the client: - in the former, the client realizes that the session has been dropped - in the latter, the client realizes that the session has not been started = at all For that being said, I agree with Scott about returning an error. A consequence of the above scenarios is how a server can inform a user that= he is submitting authenticated requests. Think that a good practice could be to add an ad-hoc notice to the response= informing the user that the related request have been submitted in the sco= pe of a session (e.g. "This is a response to an authenticated request") Best, Mario - refresh without an active session: should give back error - session status without an active session: should give back error Thanks Rick From: Hollenbeck, Scott > Date: Tuesday, July 12, 2022 at 9:17 AM To: jgould=3D40verisign.com@dmarc.ietf.org >, Rick Wilhelm >, regext@ietf.org > Subject: [EXTERNAL] RE: [regext] Login/Logout Processing (was RE: I-D Actio= n: draft-ietf-regext-rdap-openid-15.txt) CAUTION: This email came from outside your organization. Don=92t trust emai= ls, links, or attachments from senders that seem suspicious or you are not = expecting. Thanks, Jim. I'm working on -16 to address this topic and other recent feed= back. I'm planning to include text that describes error return conditions. Scott > -----Original Message----- > From: Gould, James > > Sent: Tuesday, July 12, 2022 9:13 AM > To: Hollenbeck, Scott >; Rwilhelm@PIR.org; > regext@ietf.org > Subject: [EXTERNAL] Re: [regext] Login/Logout Processing (was RE: I-D > Action: draft-ietf-regext-rdap-openid-15.txt) > > Caution: This email originated from outside the organization. Do not clic= k links > or open attachments unless you recognize the sender and know the content > is safe. > > Scott, > > My preference is option 1, where if the request conflicts with the curren= t > state it needs to result in an error. > > -- > > JG > > > > James Gould > Fellow Engineer > jgould@Verisign.com B4BA42740803/jgould@Verisign.com= > > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > S9CI7Wv51aAaxl8hFAuOBaHou3sDkfQPFMQu6BUoW4k5ofYC5YtOj6XXRCKD > HYzan_NZGxdaN0YSvV0pwQb7R9i9kzQj1h9R05Pagm54- > 27p6uMqOMzoZGv2vinpZe2J8m4PKqdSLdJjiCepHPZ1JM1mtuI50NVmuZ8vRF > i_0YBy7IEEjGceS0HpXLfup5UC4X63esKGLab9WHmN- > OZdrNHmUQpEtHd1kkwxdbMiJ2nTpenX/http%3A%2F%2Fverisigninc.com%2 > F> > > On 7/7/22, 11:02 AM, "regext on behalf of Hollenbeck, Scott" bounces@ietf.org on behalf of shollenbeck=3D40ve= risign.com@dmarc.ietf.org> > wrote: > > > Thanks, Rick. Trimming things up a bit and changing the subject > appropriately... > > >>> In the last sentence: Is the client required to wait until the access > >>> token has > >>> expired before submitting the new login request? Or can it send > logout > >>> and > >>> login back-to-back? (Or even just a login command while currently > logged > >>> in?) > > >> [SAH] Let's talk about this. What's appropriate behavior? IF the serve= r > >> gets a > >> "login" during an active session, it can either ignore the second "log= in", > >> or it > >> can return an error. Similarly, it the server gets a "logout" when the= re's > >> no > >> active session, it can either ignore the "logout" or return an error. = I'm > >> inclined to return an error to explicitly note that the submitted > >> query/command > >> wasn't processed as requested. > > > [RW] First off, I will certainly defer to those with more implementatio= n in > > this > > realm. However, based on my experience as a user, I would expect a > login > > that > > happens during an active session to "just work" and override the > previous > > active > > session. This could happen when I have an active session at the server > but > > the > > client browser (with the session) crashes or is otherwise inaccessible. > > This > > seems better than the alternative: If the new login request is refused, > > then > > the user is (essentially) locked out until the session timeout value > > expires. > > Related, if the server gets a "logout" when there is no active session,= I > > think > > that it should ignore the "logout" (rather than returning an error). Th= e > > thinking being that returning an error is at best useless and at worst = could > > be > > an information leak (aka security risk). > > The document currently describes a session/refresh path segment to > perform the > kind of "override" behavior described above. Having a "login followed by = a > login" do the same thing seems counter-intuitive. My own experience with > server-side session management is that there is no lockout. If the client > sends the right HTTP cookie, and the session is still active, there won't= be a > problem. Another login should be possible if the "old" session gets > corrupted. > > Let's look at the server-side options again for situations in which the s= erver > receives a login followed by a login, or a logout where there's been no > login, > or a refresh without an active session, or a session status without an ac= tive > session: > > 1. Return an error. HTTP includes a 409 (Conflict) response that can be > returned if a received request conflicts with the current state of the se= rver. > > 2. Accept the request and ignore it. I'm not sure what an appropriate HTT= P > response code would be for this situation. > > 3. Accept the request and do "something". > > Option 1 can be done consistently for all the above request sequences. > Option > 2 seems like it could mislead the client into thinking that something has > happened unless there is, in fact, an appropriate HTTP response code > available > to describe a no-op (I couldn't find one). Option 3 might be doable if we > can > figure out what the "somethings" are, like processing a second login > received > while a session is active, but the other command sequences present > problems. > As you described above, a logout received without an active session is > processed differently than the "login followed by a login" situation. Is = that > really the best course of action? I think consistent behavior would be > preferred. > > Scott > > _______________________________________________ > regext mailing list > regext@ietf.org > https://secure- > web.cisco.com/1zzMrKkgYlj9VhlxPYw6YLgXo4UAztsC_b_SIIxy0OJCV9U2y757 > cdfeXR- > TsC4CBsm4x0Yza6BzHsVVgxL47gZOr0EEg3eYwSmzQahgfdLx6MCjcvGofpNEU > HHZt2Y9yHuOqVA2iKKNDFe4kYtLZHy4rnHFrCuG4pBqHTT16_dC9eQWYrcA7F > A4k25iCZW0YD3jfVPuhbDXOJoN5T2R71VL27lBZvgz67YLjIgfoeMRu8B5U9- > yu2qyTAFnQ2bvd/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2 > Fregext > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dr. Mario Loffredo Technological Unit =93Digital Innovation=94 Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo --_000_BY5PR10MB4179D8F37EF7EF9E9239D9BAC9889BY5PR10MB4179namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Good inputs and upg= rades from Mario.  In summary, I agree about returning an error becaus= e of the expected typical complexity of cookies. 

 

But for I=92ll elab= orate a bit regarding the =93giving up security info=94 that I had mentione= d in a prior message, which was admittedly vague and likely overstated.

 

Assuming that the c= ookie doesn=92t contain identity information about the client, this wouldn= =92t be an issue.  But if the cookie has identity (login) info embedde= d, and the server just processes the logout request by responding with overly verbose errors like =93<login> not logged = in=94 or =93<login> not registered=94 rather than simply rejecting wi= th a vague error message, then the server would be giving up information ab= out the status of that login.

 

Hope that helps=85 = and apologies for any over-complexifying on this use-case.

 

Thanks

Rick

 

 

From: Mario Loffredo <= mario.loffredo@iit.cnr.it>
Date: Thursday, July 14, 2022 at 3:32 AM
To: Hollenbeck, Scott <shollenbeck=3D40verisign.com@dmarc.ietf.or= g>, Rick Wilhelm <Rwilhelm@PIR.org>, jgould=3D40verisign.com@dmarc= .ietf.org <jgould=3D40verisign.com@dmarc.ietf.org>, regext@ietf.org &= lt;regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] Login/Logout Processing (was RE: I-= D Action: draft-ietf-regext-rdap-openid-15.txt)

CAUTION: This email came from outsi= de your organization. Don=92t trust emails, links, or attachments from send= ers that seem suspicious or you are not expecting.

 

Il 13/07/2022 16:41= , Hollenbeck, Scott ha scritto:

Notes below, Rick.

 

From: Rick Wilhelm <Rwilhelm@PIR.org>
Sent: Tuesday, July 12, 2022 4:05 PM
To: Hollenbeck, Scott &l= t;shollenbeck@verisign.com>; jgould=3D40verisi= gn.com@dmarc.ietf.org; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Login/Logout Processing (was RE: I-= D Action: draft-ietf-regext-rdap-openid-15.txt)

 

Cauti= on: This email originated from outside the organizatio= n. Do not click links or open attachments unless you recognize the sender a= nd know the content is safe. 

Briefly,

 

I think that (per a point that Ma= rio made) the situations described below are different and might merit cons= ideration differently. Specifically, these situations:

 

> Let's look at the server-sid= e options again for situations in which the server
> receives a login followed by a login, or a logout where there's been n= o
> login,
> or a refresh without an active session, or a session status without an= active
> session:

 

- Login followed by login:  = sounds similar to a point that Mario made related to extending a session; s= eems fine, not an error

[SAH] Under certain circums= tances, I now agree. A client might be serving multiple end-users, and the = server should be able to start another session for a different user if it receives a second login request without= a cookie. If the server receives a login request with a valid cookie, thou= gh (the server is seeing a second login request on an active session), I=92= d prefer to keep command processing idempotent such that the second login isn=92t processed differently than t= he original login was, and return an error since the request conflicts with= the current state of the server. That=92ll make client processing consiste= nt.

[ML] Just for clarifying what I've said.

Every login without a cookie is valid in general. The only exception to = that is when it breaks some server policy, e.g. a server limits the number = of concurrent sessions per user and this limit has been exceeeded. Forbiddi= ng always two subsequent login coming from the same user means that such a limit i set to 1.

Therefore, it is a special case of a constraint depending on server poli= cy. For this reason, it's wrong to define it as specification constraint bu= t i'm inclined to include it in the security consideration as a measure ser= vers can implements to mitigate the risk of DoS or huge consumption of resources.

- logout where there has been no = login:  while it might be tempting to want to give back an error, I wo= uld argue that this gives up security info about the client.  Therefore, is there harm in just saying =93ok=94 ?= ?

[SAH] Please elaborate rega= rding =93security info=94. I=92m inclined to return an error because, again= , the request conflicts with the current state of the server. The client won=92t be misled into thinking that it ended a = session when there was no session to begin with.

[ML] I would like to give a further contribution that could be helpful. =

When does it happen that a logout include an invalid cookie? There are a= t least two cases coming in my mind:

- the client sends a logout on a session that has been ended by the serv= er (e.g. due to timeout or the session max time has been exceeded)

- the clients sends an unsuccessful login, then it doesn't check that th= e server hasn't returned a session cookie, and nevertheless it sends some r= equests and a final logout

In both cases, returning an error on the logout request can be helpful f= or the client:

- in the former, the client realizes that the session has been dropped

- in the latter, the client realizes that the session has not been start= ed at all

For that being said, I agree with Scott about returning an error.

 

A consequence of the above scenarios is how a server can inform a user t= hat he is submitting authenticated requests.

Think that a good practice could be to add an ad-hoc notice to the respo= nse informing the user that the related request have been submitted in the = scope of a session (e.g. "This is a response to an authenticated reque= st")

 

Best,

Mario

- refresh without an active sessi= on:  should give back error

- session status without an activ= e session:  should give back error

 

Thanks

Rick

 

 

 

 

From: Hollenbeck, Scott <shollenbeck@verisign.com>
Date: Tuesday, July 12, 2022 at 9:17 AM
To: jgould= =3D40verisign.com@dmarc.ietf.org <jgould=3D40verisign.com@dmarc.ietf.org>, Ric= k Wilhelm <Rwilhelm@PIR.org>, regext@ietf.org <regext@ietf.org>
Subject: [EXTERNAL] RE: [regext] Login/Logout Processing (was RE: I-= D Action: draft-ietf-regext-rdap-openid-15.txt)

CAUTION: This email came from out= side your organization. Don=92t trust emails, links, or attachments from se= nders that seem suspicious or you are not expecting.

Thanks, Jim. I'm working on -16 to address this topic and other recent feed= back. I'm planning to include text that describes error return conditions.<= br>
Scott

> -----Original Message-----
> From: Gould, James <jgould=3D40verisign.com@dmarc.ietf.org>
> Sent: Tuesday, July 12, 2022 9:13 AM
> To: Hollenbeck, Scott <= shollenbeck@verisign.com>; Rwilhelm@PIR.org;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Login/Logout Processing (was RE: I-D<= br> > Action: draft-ietf-regext-rdap-openid-15.txt)
>
> Caution: This email originated from outside the organization. Do not c= lick links
> or open attachments unless you recognize the sender and know the conte= nt
> is safe.
>
> Scott,
>
> My preference is option 1, where if the request conflicts with the cur= rent
> state it needs to result in an error.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgould@Verisign.com <app= lewebdata://13890C55-AAE8-4BF3-A6CE-
> B4BA42740803/jgoul= d@Verisign.com>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://secure-web.cisco.com/14= 6IYbLb06o7EQ5y-
> S9CI7Wv51aAaxl8hFAuOBaHou3sDkfQPFMQu6BUoW4k5ofYC5YtOj6XXRCKD
> HYzan_NZGxdaN0YSvV0pwQb7R9i9kzQj1h9R05Pagm54-
> 27p6uMqOMzoZGv2vinpZe2J8m4PKqdSLdJjiCepHPZ1JM1mtuI50NVmuZ8vRF
> i_0YBy7IEEjGceS0HpXLfup5UC4X63esKGLab9WHmN-
> OZdrNHmUQpEtHd1kkwxdbMiJ2nTpenX/http%3A%2F%2Fverisigninc.com%2
> F>
>
> On 7/7/22, 11:02 AM, "regext on behalf of Hollenbeck, Scott"= <regext-
> bounces@ietf.org on behalf of = shollenbeck=3D40verisign.com@dmarc.ietf.org>
> wrote:
>
>
> Thanks, Rick. Trimming things up a bit and changing the subject
> appropriately...
>
> >>> In the last sentence: Is the client required to wait unti= l the access
> >>> token has
> >>> expired before submitting the new login request? Or can i= t send
> logout
> >>> and
> >>> login back-to-back? (Or even just a login command while c= urrently
> logged
> >>> in?)
>
> >> [SAH] Let's talk about this. What's appropriate behavior? IF = the server
> >> gets a
> >> "login" during an active session, it can either ign= ore the second "login",
> >> or it
> >> can return an error. Similarly, it the server gets a "lo= gout" when there's
> >> no
> >> active session, it can either ignore the "logout" o= r return an error. I'm
> >> inclined to return an error to explicitly note that the submi= tted
> >> query/command
> >> wasn't processed as requested.
>
> > [RW] First off, I will certainly defer to those with more impleme= ntation in
> > this
> > realm. However, based on my experience as a user, I would expect = a
> login
> > that
> > happens during an active session to "just work" and ove= rride the
> previous
> > active
> > session. This could happen when I have an active session at the s= erver
> but
> > the
> > client browser (with the session) crashes or is otherwise inacces= sible.
> > This
> > seems better than the alternative: If the new login request is re= fused,
> > then
> > the user is (essentially) locked out until the session timeout va= lue
> > expires.
> > Related, if the server gets a "logout" when there is no= active session, I
> > think
> > that it should ignore the "logout" (rather than returni= ng an error). The
> > thinking being that returning an error is at best useless and at = worst could
> > be
> > an information leak (aka security risk).
>
> The document currently describes a session/refresh path segment to
> perform the
> kind of "override" behavior described above. Having a "= login followed by a
> login" do the same thing seems counter-intuitive. My own experien= ce with
> server-side session management is that there is no lockout. If the cli= ent
> sends the right HTTP cookie, and the session is still active, there wo= n't be a
> problem. Another login should be possible if the "old" sessi= on gets
> corrupted.
>
> Let's look at the server-side options again for situations in which th= e server
> receives a login followed by a login, or a logout where there's been n= o
> login,
> or a refresh without an active session, or a session status without an= active
> session:
>
> 1. Return an error. HTTP includes a 409 (Conflict) response that can b= e
> returned if a received request conflicts with the current state of the= server.
>
> 2. Accept the request and ignore it. I'm not sure what an appropriate = HTTP
> response code would be for this situation.
>
> 3. Accept the request and do "something".
>
> Option 1 can be done consistently for all the above request sequences.=
> Option
> 2 seems like it could mislead the client into thinking that something = has
> happened unless there is, in fact, an appropriate HTTP response code > available
> to describe a no-op (I couldn't find one). Option 3 might be doable if= we
> can
> figure out what the "somethings" are, like processing a seco= nd login
> received
> while a session is active, but the other command sequences present
> problems.
> As you described above, a logout received without an active session is=
> processed differently than the "login followed by a login" s= ituation. Is that
> really the best course of action? I think consistent behavior would be=
> preferred.
>
> Scott
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://secure-
> web.cisco.com/1zzMrKkgYlj9VhlxPYw6YLgXo4UAztsC_b_SIIxy0OJCV9U2y757
> cdfeXR-
> TsC4CBsm4x0Yza6BzHsVVgxL47gZOr0EEg3eYwSmzQahgfdLx6MCjcvGofpNEU
> HHZt2Y9yHuOqVA2iKKNDFe4kYtLZHy4rnHFrCuG4pBqHTT16_dC9eQWYrcA7F
> A4k25iCZW0YD3jfVPuhbDXOJoN5T2R71VL27lBZvgz67YLjIgfoeMRu8B5U9-
> yu2qyTAFnQ2bvd/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2
> Fregext
>



_______________________________________________
regext mailing list
regext@ietf.org

https://www.ietf.org/mailman/listinfo/regext=



-- 
Dr. Mario Loffredo
Technological Unit =93Digital Innovation=94
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo<=
/pre>
--_000_BY5PR10MB4179D8F37EF7EF9E9239D9BAC9889BY5PR10MB4179namp_--