Re: [regext] NA Re: Login/Logout Processing (was RE: I-D Action: draft-ietf-regext-rdap-openid-15.txt)

[Rick Wilhelm <[e-mail]>]

Good inputs and upgrades from Mario.  In summary, I agree about returning an error because of the expected typical complexity of cookies.

But for I’ll elaborate a bit regarding the “giving up security info” that I had mentioned in a prior message, which was admittedly vague and likely overstated.

Assuming that the cookie doesn’t contain identity information about the client, this wouldn’t be an issue.  But if the cookie has identity (login) info embedded, and the server just processes the logout request by responding with overly verbose errors like “<login> not logged in” or “<login> not registered” rather than simply rejecting with a vague error message, then the server would be giving up information about the status of that login.

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

Thanks
Rick


From: Mario Loffredo <[e-mail]>
Date: Thursday, July 14, 2022 at 3:32 AM
To: Hollenbeck, Scott <shollenbeck=[e-mail]>, Rick Wilhelm <[e-mail]>, jgould=[e-mail] <jgould=[e-mail]>, [e-mail] <[e-mail]>
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.
________________________________


Il 13/07/2022 16:41, Hollenbeck, Scott ha scritto:
Notes below, Rick.

From: Rick Wilhelm <[e-mail]><mailto:[e-mail]>
Sent: Tuesday, July 12, 2022 4:05 PM
To: Hollenbeck, Scott <[e-mail]><mailto:[e-mail]>; jgould=[e-mail]<mailto:jgould=[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 12, 2022 at 9:17 AM
To: jgould=[e-mail]<mailto:jgould=[e-mail]> <jgould=[e-mail]<mailto:jgould=[e-mail]>>, Rick Wilhelm <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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=[e-mail]<mailto:jgould=[e-mail]>>
> Sent: Tuesday, July 12, 2022 9:13 AM
> To: Hollenbeck, Scott <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]> <applewebdata://13890C55-AAE8-4BF3-A6CE-
> B4BA42740803/[e-mail]<mailto:B4BA42740803/[e-mail]>>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://secure-web.cisco.com/146IYbLb06o7EQ5y-<https://protect-us.mimecast.com/s/LZ4GCpYl42CzOXVfDtirv?domain=secure-web.cisco.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" <regext-
> [e-mail]<mailto:[e-mail]> on behalf of shollenbeck=[e-mail]<mailto:shollenbeck=[e-mail]>>
> 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
> [e-mail]<mailto:[e-mail]>
> 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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext<https://protect-us.mimecast.com/s/ol5_CqxmgZSOkmETQL_zq?domain=ietf.org>

--

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: [phone]

Web: http://www.iit.cnr.it/mario.loffredo<https://protect-us.mimecast.com/s/e623Crknj9FAnLkFy_vyt?domain=iit.cnr.it>