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

[Rick Wilhelm <[e-mail]>]

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
- 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” ??
- 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://protect-us.mimecast.com/s/KdwUCOYzm8CAvABCvFYvF?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] 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
>