From nobody Thu Jul 14 00:31:38 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 054F8C157B51 for ; Thu, 14 Jul 2022 00:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.907 X-Spam-Level: X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, 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=ham autolearn_force=no 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 4Yjm6_h2_ELS for ; Thu, 14 Jul 2022 00:31:33 -0700 (PDT) Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.58.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF4DC14CF15 for ; Thu, 14 Jul 2022 00:31:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 34BF7B80816; Thu, 14 Jul 2022 09:31:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-yc_YDQ2-pN; Thu, 14 Jul 2022 09:31:17 +0200 (CEST) Received: from [192.12.193.108] (pc-loffredo.staff.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id E68F5B804B5; Thu, 14 Jul 2022 09:31:16 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------YeORo0C1BUAaugMi90iD0PTp" Message-ID: <671352ca-d76d-e9b1-a3ae-2cfe9f6c64d7@iit.cnr.it> Date: Thu, 14 Jul 2022 09:28:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 To: "Hollenbeck, Scott" , "Rwilhelm@PIR.org" , "jgould=40verisign.com@dmarc.ietf.org" , "regext@ietf.org" References: <920FFD8E-B060-416D-B838-61010E51C50A@verisign.com> <08c3a4aecaeb467eac9152b880cc85ba@verisign.com> <4c501148e5d84084bf9f92467e2747d5@verisign.com> From: Mario Loffredo In-Reply-To: <4c501148e5d84084bf9f92467e2747d5@verisign.com> 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: Thu, 14 Jul 2022 07:31:38 -0000 This is a multi-part message in MIME format. --------------YeORo0C1BUAaugMi90iD0PTp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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=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./* > [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. Forbidding 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 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 servers 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 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./* > [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 least 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 server hasn't returned a session cookie, and nevertheless it sends some requests 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 scope 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=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 > > > > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext -- Dr. Mario Loffredo Technological Unit “Digital Innovation” 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 --------------YeORo0C1BUAaugMi90iD0PTp Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


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 <shollenbeck@verisign.com>; 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.

[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. Forbidding 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 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 servers 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 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.

[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 least 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 server hasn't returned a session cookie, and nevertheless it sends some requests 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 scope 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 <shollenbeck@verisign.com>
Date: Tuesday, July 12, 2022 at 9:17 AM
To: jgould=40verisign.com@dmarc.ietf.org <jgould=40verisign.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=40verisign.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@Verisign.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=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
>


_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
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
--------------YeORo0C1BUAaugMi90iD0PTp--