Thank you Roman for the super prompt and thorough review! We went ahead and published draft -10 incorporating your feedback and the changes described below. We are happy to make further changes as necessary, of course.
Comments Inline >** 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. We use the term “authentication level” banking on the same intuition that propelled “step UP” in mainstream use. The concept of authentication level doesn’t require an absolute or even partial ordering on the domain, or that to be encoded in ACR. All that’s needed for the “authentication level” intuition to play out is for a RS to accept multiple ACR values, and to consider the authentication strength associated with certain values of ACR to meet its own bar for accessing a given resource. The RS interpretation of ACR can be entirely private, without relying on commonly accepted standard values, and its resulting hierarchy doesn’t need to be absolute or even a proper lattice. We presented this spec at various conferences, and the audience never seemed to have a hard time grasping the concept. On the other hand, we cannot be sure that they were thinking the above… they might just have assumed the absolute order you described :) Would some clarifying language summarizing the above help, in your opinion? >Is there a reference that can be provided to explain the hierarchy of levels? See above about whether an absolute hierarchy is strictly required. That said, the ACR definition in https://openid.net/specs/openid-connect-core-1_0.html#IDToken hints at the use of NIST assurance levels in ACR values, pointing at https://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#anchor11 and mapping to https://pages.nist.gov/800-63-3-Implementation-Resources/63B/AAL/. Given that those are all mentioned in the ACR definition in OIDC core, I am not sure if it would make a big difference echoing them here, especially given that the RS isn’t forced to stick with that. What do you think? >** 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. Great catch. We’ll go with recentness. >** Section 2. Editorial. s/Following is an/The following is an/ Thx, done! > 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? We postulate that clients save and reuse tokens. Clients (and in particular, SDKs used by clients) already do this today, using a variety of strategies and cache index designs that aren’t explicitly described in detail by any OAuth specification. Those solutions already rely on information that can only be inferred by request and response parameters (resourceID, path, scopes, etc), without the need to access the token’s content. The step-up spec doesn’t change this: the application’s flow keeps invoking resources according to the resource shape (identifier, path, etc) and app needs (eg the API method parameters passed in specific calls) without any need to understand ACR. in other words, if an app obtained a token A for calling the resource http://myapi.com and that token works for http://myapi.com/method1 and http://myapi.com/metho <http://myapi.com/method1>d2, but generates an error and a step-up challenge when attempting to use token A for invoking http://myapi.com/metho <http://myapi.com/method1>d3, leading to obtaining token B… the token caching index doesn’t need to change to include ACR values, as future code invoking the resource and method will simply refer to resource identifier and method path, all we are telling the developer is not to override A with B but the way those tokens will be retrieved from the cache doesn’t require direct knowledge of ACR. We can’t really predict what every app needs to use to index its cache, API method is one example but other scenarios be just as common (e.g. monetary size of a transaction, which would be encoded by parameters rather than methods). TL;DR: token caching doesn’t require remembering particular ACR values, and every app might need to include in the cache index different parameters hence it’s tricky for us to provide guidance. Does that clarify? I know it’s confusing. >** 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. Proposed new language: acr_values : A space-separated string listing the authentication context class reference values, in order of preference, one of which the protected resource requires for the authentication event associated with the access token. The authentication context, as defined in https://openid.net/specs/openid-connect-core-1_0.html#Terminology, carries information about how authentication takes place (e.g., what authentication method or assurance level to meet). >** 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) New language clarifying where auth occurs (the AS), to be added to the max_age definition: An active authentication event entails a user interacting with the authorization server in response to an authentication prompt. >** Section 4. Typo. s/precessing/processing/ Thx, done! >** 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. The authentication level here refers to the RS interpretation of what authentication context corresponds to what the RS demands to meet the requirement of the call that was attempted, failed and led to the request currently being served by the AS. We could refer to authentication context here and be closer to the OIDC formulation, but we would lose the significance of why this particular auth context value is being requested in the circumstances being described by the spec, and why it is important for that value to be included in the acr claims (so that the RS can ultimately verify that the auth level it requires was met by service that articular auth context value). >** 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. Great catch, thanks! New language: Furthermore, section 3.1.2.1 states that.. ** 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]. Thx, done (but RFC6750 rather than 5750] >** 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. Thx, done! >** 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. Proposed new language: For the purposes of this specification, the way in which a user authenticated with the authorization server to obtain an access token is salient information, as a resource server might decide whether to grant access on the basis of how that authentication operation was performed. Nonetheless, this specification doesn’t attempt to define the mechanics by which authentication takes place, relying on a separate authentication layer to take care of the details. >** 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. Proposed extra language: For example, a resource server requesting an acr value corresponding to a high level of assurance for some users but not others might identify possible high privilege users to target with spearhead phishing attacks. >** 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. On Fri, Jan 6, 2023 at 8:17 AM Roman Danyliw <r...@cert.org> wrote: > > This message originated outside your organization. > > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
