Hi!
I performed an AD review of draft-ietf-oauth-step-up-authn-challenge-08.
Thanks for this document. My feedback is below:
** The text uses the phrase "authentication level" a few times. Was that a
phrase that was heavily negotiated? To me a level implies that some notion of
linear progression -- level-n+1 is "more security" than level-n; and that there
is some notion of hierarchy of level-n-1, level-n, and level-n+1. I didn't see
that in the construct of an acr claim. My skim of the OIDC materials suggests
that an acr is a label assigned to set a requirements for a token. Is there a
reference that can be provided to explain the hierarchy of levels?
** Abstract and Section 1. Editorial consistency. Does the setup-up
authentication provide different "authentication strength and/or freshness"
(Abstract) or "authentication strength or recentness"? Please choose one.
** Section 2. Editorial. s/Following is an/The following is an/
** Section 2.
This document doesn't recommend any
specific token caching strategy, as that will be dependent on the
characteristics of every particular scenario. Also recall that OAuth
2.0 [RFC6749] assumes access tokens are treated as opaque by clients.
The token format might be unreadable to the client or might change at
any time to become unreadable. So, during the course of any token
caching strategy, a client must not attempt to inspect the content of
the access token to determine the associated authentication
information or other details (see Section 6 of [RFC9068] for a more
detailed discussion).
The text seems to be suggesting that a caching strategy might be needed but
noting that the specifics will have to be application specific. It also
reminds the reader that tokens are supposed to be opaque and not inspected. If
tokens are supposed to be treated as opaque, how exactly does one know which
token to pull from the cache? Can the text provide guidance on what non-token
properties is should be using as an index? Would it be acr_values + max_age +
resource?
** Section 3. acr_values is defined here and makes reference to
"authentication context class reference values" however there is no text or
reference to define it.
** Section 3.
max_age Indicates the allowable elapsed time in seconds since the
last active authentication event associated with the access token.
Should this definition be clearer on whether the authentication is to the AS or
to the RS? The OIDC definition uses "elapsed time in seconds since the last
time the End-User was actively authenticated by the OP" (Section 3.1.2.1 of
OIDC)
** Section 4. Typo. s/precessing/processing/
** Section 5.
The same section
also establishes that in case the desired authentication level cannot
be met, the authorization server SHOULD include in the acr claim a
value reflecting the authentication level of the current session (if
any).
What is a "authentication level"? The [OIDC] text in Section 5.5.1.1. says
that the return acr claim should be the name of the Authentication Context
class.
** Section 5. Editorial.
Section 5.5.1.1 of [OIDC] establishes ...
The same section also states that if a request includes the
max_age parameter, the authorization server MUST include the
auth_time claim in the issued ID Token.
That section of [OIDC] makes no reference to auth_time. The guidance on
auth_time is in Section 3.1.2.1.
** Section 9. Please add the various security considerations this document
inherits -
Proposed NEW:
This specification adds to previously defined OAuth mechanisms. Their
respective Security Considerations apply - OAuth 2.0 [RFC6749], JWT access
tokens [RFC9068], Bearer WWW-Authentication [RFC5750], token introspection
[RFC7662], and server metadata [RFC8414].
** Section 9. Editorial.
OLD
This document should, in no circumstance, be used to position OAuth
as an authentication protocol.
NEW
This document MUST NOT be used to position OAuth as an authentication protocol.
** Section 9. Editorial.
The specification focuses on the
authentication event of the user with the authorization server by
which the access token was obtained, so that its characteristics can
be evaluated by a resource server to determine whether they meet its
requirements, but relies on a separate authentication layer to take
care of the mechanics leading to that event.
Can this sentence is restated? It's dense to read.
** Section 9.
Depending on the
policies adopted by the resource server, the acr_values parameter
introduced in Section 3 might unintentionally disclose information
about the authenticated user, the resource itself, the authorization
server, and any other context-specific data that an attacker might
use to gain knowledge about their target.
Can this text be more specific on what linkability there is between acr_values
and the user/RS/AS.
** Section 9.
The
resource server is free to choose whatever method fits best for its
needs, however, it's important to remember that returning a challenge
without having verified that the caller presented a valid token
(according to the validation method of choice) might mean disclosing
information to an actor that didn't prove it had the ability to
obtain a valid token for the resource server, albeit of insufficient
level.
Editorial recommendation and restatement of what's being disclosed more
formally.
NEW Proposed:
(new paragraph)
The resource server MAY return a challenge without verifying the client
presented a valid token. However, this approach will leak the required
properties of an authorization token to an actor who has not proven they can
obtain a token for this resource server.
Thanks,
Roman
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
