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

[Mario Loffredo <[e-mail]>]

Il 13/07/2022 16:41, Hollenbeck, Scott ha scritto:
>
> Notes below, Rick.
>
> *From:*Rick Wilhelm <[e-mail]>
> *Sent:* Tuesday, July 12, 2022 4:05 PM
> *To:* Hollenbeck, Scott <[e-mail]>; 
> jgould=[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 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]>
> *Date: *Tuesday, July 12, 2022 at 9:17 AM
> *To: *jgould=[e-mail] 
> <jgould=[e-mail]>, Rick Wilhelm 
> <[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.
>
> 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]>
> > Sent: Tuesday, July 12, 2022 9:13 AM
> > To: Hollenbeck, Scott <[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 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] <applewebdata://13890C55-AAE8-4BF3-A6CE-
> > B4BA42740803/[e-mail]>
> >
> > 703-948-3271
> > 12061 Bluemont Way
> > Reston, VA 20190
> >
> > Verisign.com <http://secure-web.cisco.com/146IYbLb06o7EQ5y- 
> <https://secure-web.cisco.com/14tl_My5ZME5EWUyAX5a7wWHLqYU5eMXkGAJG3kWsISx8PHh1liKD7ofsNq9qr59NAKu3-xshnpp-LDNozsB7tWkGqsyc1BsK6ABNp9qgUH8I2SKGdYCy4WUhmiLVSGvuVH8QqMlnFkMAvd-xHlUM0GOyUB2fcp4OoDQs0SfGknwIrwlYg0Ef0EI96IzjnOCgXJnfvFxNLmUeg1p5f6WVyudP1hcjvqNSA_wIWYcGcZkqxj56CR5-E_Ntq2aS_1Q0/https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FKdwUCOYzm8CAvABCvFYvF%3Fdomain%3Dsecure-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] on behalf of 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]
> > 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]
> 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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo