Il 13/07/2022 16:41, Hollenbeck, Scott ha scritto:
Notes below, Rick.
*From:*Rick Wilhelm <[email protected]>
*Sent:* Tuesday, July 12, 2022 4:05 PM
*To:* Hollenbeck, Scott <[email protected]>;
[email protected]; [email protected]
*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 <[email protected]>
*Date: *Tuesday, July 12, 2022 at 9:17 AM
*To: *[email protected]
<[email protected]>, Rick Wilhelm
<[email protected]>, [email protected] <[email protected]>
*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 <[email protected]>
> Sent: Tuesday, July 12, 2022 9:13 AM
> To: Hollenbeck, Scott <[email protected]>; [email protected];
> [email protected]
> 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
> [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-
> B4BA42740803/[email protected]>
>
> 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-
> [email protected] on behalf of [email protected]>
> 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
> [email protected]
> 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
[email protected]
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
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
