From nobody Wed Jul 13 07:41:31 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 4A1D7C15A720 for ; Wed, 13 Jul 2022 07:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 zaNUgthPRL52 for ; Wed, 13 Jul 2022 07:41:25 -0700 (PDT) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 E6B1FC157B58 for ; Wed, 13 Jul 2022 07:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=25883; q=dns/txt; s=VRSN; t=1657723282; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=okYOTbT2XUiypGLosYYmYFHurVgJwmVqXKc1BPhGHQU=; b=p5nFaWym19Z3sXfLjiGgayJCbAmHJz9wCk3SA5LcfC0T1RDmUsI+vZRV XM3cz1bJhmLilGGdClTGkfdJub+odFRYNXb6AZGyBRScNalj68jLXqWwg YUxevPbURGK+Vd23o+/zl8X0K5WjmPssiOifZYsTdHy3liacGk7gP8WsE hDDZ+oJiq/iDx8vdkknoN0T+FCCxOCrH91l7uCkBck/bCGsW9cLOF6CS/ JfCOCVxClpKPw7ZTHdeAZ+nJ2HF7iWfDUhc5co3c5Mol5PErHkxb/1314 1TDMxgr4lMHq2gR0qjv3NTnCqi4DT9ht0a2YhSsYE362BRfUfvKXO7grq Q==; IronPort-Data: A9a23:WQnzuqNkBlN/aiLvrR3IlsFynXyQoLVcMsEvi/4bfWQNrUoigzUAn GJNXWiBOKuMazH0f9txaovl8kwCuJLdzdFmSQZtpSBmQkwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oAMKRCQ7InQLlbGILes1htZGEk1Ek/NtTo5w7Rj2tEx2oDja++wk YiaT/P3aQfNNwFcbzp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMebS4K8bhL wr15Orgoj6GpUdF5uSNyd4XemVSKlLbFVbW1ioOA8BOiDAazsA5+v5T2Pbx9S67IthG9jx84 IwliHC+desmFvXJntQwQxxCLzxVYKkfu4DaAEWn7MPGmiUqc1O0qxlvJGsMG9Qn3MtHWTsI6 /cfMihLZxzFmfitxvSwTewEasYLdZGtZdxE/Cg9lneFXJ7KQriaK0nOzcRY2zM0i8ZEEP3dT 9QUczt0bRvGJRZIPz/7Dbpnwbz02iWvLlW0rnrWl4Ea7Vfd9TYq75vPbPbTRfWxQupsyxPwS mXuuj6R7gshHOaAyD6F/3aprvfOh2X8Qo16PL+38eNujAjPnnIeEhwNVFS95/K+j2ayXttFI AoV9zYg668o+ySDVNTyUg2kiH+JohBaXMBfe9DW8ymH0KyN/ACUFjBeCyVfcpojtdRzTzts3 EWPxpX3Hydp9raSTBpx64upkN97AgBNRUdqWMPOZVJtDwXLyG3rsi/ycw== IronPort-HdrOrdr: A9a23:cTbJBa6KAHZWSzf8zAPXwP3XdLJyesId70hD6qkoc20xTiXqrb HLoB17726NtN9/YhAdcLy7UpVoBEmsl6KdgrNhRotKPjOHhILAFugLhrcKgQeQeBEWndQw6U 4UScZD4arLYmSS4/yW3ODyKadG/DDOytHPuQ7x9QYVcT1X X-IronPort-AV: E=Sophos; i="5.92,267,1650931200"; d="scan'208,217"; a="15344485" Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Wed, 13 Jul 2022 10:41:18 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) by BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) with mapi id 15.01.2375.024; Wed, 13 Jul 2022 10:41:18 -0400 From: "Hollenbeck, Scott" To: "Rwilhelm@PIR.org" , "jgould=40verisign.com@dmarc.ietf.org" , "regext@ietf.org" Thread-Topic: [regext] Login/Logout Processing (was RE: I-D Action: draft-ietf-regext-rdap-openid-15.txt) Thread-Index: AQHYlfErOYryTOFLcEa1k/pEddYKCK16txaAgABw+g2AASvHQA== Date: Wed, 13 Jul 2022 14:41:18 +0000 Message-ID: <4c501148e5d84084bf9f92467e2747d5@verisign.com> References: <920FFD8E-B060-416D-B838-61010E51C50A@verisign.com> <08c3a4aecaeb467eac9152b880cc85ba@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01D896A5.15100010" MIME-Version: 1.0 Archived-At: Subject: Re: [regext] 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: Wed, 13 Jul 2022 14:41:30 -0000 ------=_NextPart_000_0043_01D896A5.15100010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Notes below, Rick. From: Rick Wilhelm Sent: Tuesday, July 12, 2022 4:05 PM To: Hollenbeck, Scott ; jgould=40verisign.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) Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Briefly, I think that (per a point that Mario made) the situations described below are different and might merit consideration differently. Specifically, these situations: > Let's look at the server-side options again for situations in which the server > 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 active > session: - Login followed by login: sounds similar to a point that Mario made related to extending a session; seems fine, not an error [SAH] Under certain circumstances, 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, though (the server is seeing a second login request on an active session), I'd prefer to keep command processing idempotent such that the second login isn't processed differently than the original login was, and return an error since the request conflicts with the current state of the server. That'll make client processing consistent. - 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 about the client. Therefore, is there harm in just saying "ok" ?? [SAH] Please elaborate regarding "security info". I'm inclined to return an error because, again, the request conflicts with the current state of the server. The client won't be misled into thinking that it ended a session when there was no session to begin with. - 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=40verisign.com@dmarc.ietf.org >, Rick Wilhelm >, 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 outside your organization. Don't trust emails, 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 feedback. 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 click 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 current > 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=40verisign.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 server > >> gets a > >> "login" during an active session, it can either ignore the second "login", > >> or it > >> can return an error. Similarly, it the server gets a "logout" when there'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 implementation 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). 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 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 server > 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 active > 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 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 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 > ------=_NextPart_000_0043_01D896A5.15100010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Notes below, Rick.

 

From: Rick Wilhelm <Rwilhelm@PIR.org> =
Sent: Tuesday, July 12, 2022 4:05 PM
To: = Hollenbeck, Scott <shollenbeck@verisign.com>; = jgould=3D40verisign.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)

 

Caution:<= /strong> This email originated from outside the = organization. Do not click links or open attachments unless you = recognize the sender and know the content is = safe. 

Briefly,

 

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

 

> Let's look at = the server-side options again for situations in which the server
> = 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 active
> = session:

 

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

[SAH] Under = certain circumstances, 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, though (the = server is seeing a second login request on an active session), I’d = prefer to keep command processing idempotent such that the second login = isn’t processed differently than the original login was, and = return an error since the request conflicts with the current state of = the server. That’ll make client processing = consistent.

- 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 about the = client.  Therefore, is there harm in just saying “ok” = ??

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

- refresh without an = active session:  should give back error

- session status = without an active session:  should give back = error

 

Thanks

Rick

 

 

 

 

From: Hollenbeck, Scott <shollenbeck@verisign.com>=
Date: Tuesday, July 12, 2022 at 9:17 AM
To: jgould=3D40verisig= n.com@dmarc.ietf.org <jgould=3D40verisig= n.com@dmarc.ietf.org>, Rick 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 outside your = organization. Don’t trust emails, 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 feedback. = I'm planning to include text that describes error return = conditions.

Scott

> -----Original Message-----
> = From: Gould, James <jgould=3D40verisig= n.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
> = Action: 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 content
> is safe.
>
> Scott,
>
> = My preference is option 1, where if the request conflicts with the = current
> state it needs to result in an error.
>
> = --
>
> JG
>
>
>
> James = Gould
> Fellow Engineer
> jgould@Verisign.com = <applewebdata://13890C55-AAE8-4BF3-A6CE-
> B4BA42740803/jgould@Veri= sign.com>
>
> 703-948-3271
> 12061 Bluemont = Way
> Reston, VA 20190
>
> Verisign.com <http://secure-web.cisco.com/146IYbLb06o7EQ5y= -
> = 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=3D= 40verisign.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 server
> >> gets = a
> >> "login" during an active session, it can = either ignore the second "login",
> >> or = it
> >> can return an error. Similarly, it the server gets a = "logout" when there'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 implementation 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). 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 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 = server
> 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 active
> = 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 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 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
>

------=_NextPart_000_0043_01D896A5.15100010--