Hi Vittorio, Brian, Rifaat and OAuth WG members. I volunteered to review the OAuth 2.0 Step-up Authentication Challenge Protocol (https://www.ietf.org/archive/id/draft-bertocci-oauth-step-up-authn-challenge-01.html) at the OAuth working group meeting at IETF 113. I did the review in the context of a "just-in-time" step-up authentication scenario we are exploring and have the following observations:
1. A standard for step-up authentication will be valuable with an increasing need for "just-in-time" step-up authentication to improve user experience and allow customers to protect their assets appropriately. We should pursue this work. 2. There is an implicit assumption in the proposal that the "step-up" is a superset that includes all preceding authentication contexts and that it persists. This may not always be the case if the "step-up" is short lived before reverting to the previous authentication context and the authentication methods may not always be a superset. For example a server side liveness biometric check or government ID presentation may be required on top of an MFA authentication. Satisfying the liveness check or government ID presentation can be done independent of the MFA method, and does not imply the MFA method was used. 3. When this "super-set" assumption does not hold it may result in a degraded user experience (user is prompted to re-authenticate on "step-down", extra latency and round trips), increased costs (extra token issuance) or cause a security vulnerability (e.g. only the "step_up" check is performed, the acr and auth_time is updated implying initial checks were performed as well while resetting the auth_time for the initial authentication context (if it took place)). Some ideas on how to address this (there are probably more): 1. Make the assumption explicit and add security considerations to outline the security risks along with implementation guidance on how to deal with the "temporary step-up" uses cases (see Step 6: Option 1-3 below as examples). 2. Don't assume that "step-up" is always a superset of what came before and include authentication context history in the access token to give visibility to the resource server on which authentication contexts were satisfied when and how long ago (e.g. include the latest acr and auth_time values as proposed but also provide an acr_history construct of acr/auth_time tuples that reflect the authentication context history). This "acr_history" property may be optional for those deployments that do operate in a strict superset environment (if it is optional, the security considerations should outline the risks of making this assumption). I am sharing more details on the scenario below, in case it helps to clarify the above observations (also, feel free to poke holes or suggest better options). Scenario Description The user is authenticated using one of a number of authentication methods available (password, FIDO, other MFA etc). For specific high value actions (e.g. a transaction approval, code commit etc), an additional "step-up" spot check needs to be performed on the user identity (e.g. a server side biometric liveness check, present a government issued ID, or some additional MFA options). The validity period of this "spot-check" needs to be short to minimise risk, after which authentication needs to "step-down" to the original authentication context. If the user needs to perform another high value transaction, they need to complete the "step-up" again. This roughly translates into the following steps: 1. User attempts to access "regular resource 1" 2. User is authenticated using an "initial" authentication mechanism (password, FIDO, other MFA) 3. User attempts to perform high value action on "sensitive resource 2" 4. User is prompted for a "step-up" authentication (e.g. server side liveness check/biometric verification, government ID presentation) 5. User authenticates and completes action. 6. User continues to access regular resources as before with no re-authentication for the "initial" authentication method. 7. User attempts to perform another high value action on "sensitive resource 2" 8. User is once again prompted for a "step-up" authentication (e.g. server side liveness check/biometric verification, government ID presentation) 9. User authenticates and completes action. So, ideally we want to be able to perform an "initial" authentication, then force a short-lived "step-up" and then followed by a "step-down" without having the user take any action for the "step-down". So, going through this step-by-step, it looks something like this: Steps 1-2: This is achieved using existing OAuth flows and the authorisation server issues an access token with "acr: initial" and "auth_time: t0". Step 3-5: The resource server responds with "insufficient_user_authentication", "acr_values: step_up" and "max_age: 0", which the client pass back to the authorization server. The authorization server force the step-up authentication and issue the new access token with the requested "acr: step_up" value and a new "auth_time: t1" value. At this point the resource server validate the token and inspect the new "acr: step_up" and "auth_time: t1" values. If the time window falls within the expected range, and the acr value match the expected value, the user can complete the high value action Step 6: At this point the user navigates away from the high value resource that only requires the "acr: step_up" value. The resource server now has one of the following options (there may be more, these are the ones that came to mind as I read the spec): Step 6: Option 1 The resource server treats the "acr: step_up" value as a superset that includes the "acr: initial" value and accepts the "auth_time: t1" as representative of both the "acr: step_up" and the "acr: initial" value. The resource server assess the new "acr" and "auth_time" values for each resource accessed, based on the policies for those resources. The downside of this approach is a potential security vulnerability. If the "acr: step_up" value is not a strict superset, but rather an additional check, the previous authentication context is lost and may introduce a security vulnerability. For example, a user may be unauthenticated and asked to do a liveness check. On completing the liveness check, the new "acr: step_up" value may be set, implying that the user also complied with the "acr: initial" authentication step, even when they did not. Alternatively, the "acr: initial" value may be on the verge of exceeding the validity period, but a "step-up" check may cause the "auth_time" to be updated, implying that the "acr: initial" requirement was satisfied more recently than it really was. Step 6: Option 2 The resource server rejects the "acr: step_up" value and issue another "insufficient_user_authentication", "acr_values" and "max_age". The client presents it to the authorisation server. If the authorization server still have the information on the original "acr: initial" value and "auth_time: t0" it may issue a new token with that information. If the "max_age" window exceeds the time elapsed from when the "auth_time" was issued, or if the authorization server no longer has the previous results cached, it may force a re-authentication to satisfy the "acr_value: initial" requirement and issue a new access token. This has the downside of an extra roundtrip with the Authorization Server in order to retrieve the original authentication context, and may result in additional authentication requests following a "step-up" if the authorization server no longer has a record of the previous authentication cached. In an extreme case, where the Authorisation Server does not keep state, the user will be forced to re-authenticate to satisfy "acr: initial" after every "acr: step_up" interaction. In large scale deployments, it also requires synchronisation of authentication context state across geo-distributed authorisation servers, which drives complexity and costs. Step 6: Option 3 The client can maintain multiple tokens, one for each "acr" value and present those tokens depending on the resources being accessed. This approach pushes responsibility back to the client to handle the complexity of managing the tokens and feels like an anti-pattern to some extent as it is preferable to keep complexity out of the clients. Step 6: Option 4 (not supported in current proposal, for consideration of inclusion) Don't assume that "step-up" is always a superset of previous authentication contexts and include authentication context history in the access token to give visibility to the resource server on which authentication contexts were satisfied when and how long ago (e.g. include the latest acr and auth_time values as proposed but also provide an acr_history construct of acr/auth_time tuples that preceded the "step-up" operation). This avoids unnecessary re-authentication (uesr experience issues, latency), additional roundtrips to the Authorisation Server (costs), simplified state management for the authorization server (cost and complexity) and avoids pushing more complexity to the client. There is still a risk that the resource server misinterprets the acr values or history, but that risk already exists, and having the history enables the resource server to take all the information explicitly into account when applying policies. Step 7-9: The same as steps 3-5. It would be great to hear from others if there are other options/alternatives to consider to refine this valuable proposal for step-up authentication. Cheers Pieter From: OAuth <oauth-boun...@ietf.org> On Behalf Of Filip Skokan Sent: Thursday 21 April 2022 16:04 To: Vittorio Bertocci <vittorio.berto...@auth0.com>; Brian Campbell <bcampb...@pingidentity.com>; Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] Step-up Authentication review Hello Rifaat, Brian, Vittorio, everyone, As a follow up to the last IETF meeting, I've reviewed the step up authentication draft again. Aside from a number of typos and what was shared and discussed at the IETF meeting in person I believe the mechanism could use an AS discovery component. I believe that a call for adoption is in order so that this document may get worked on under the working group process. Best, Filip Skokan On Wed, 20 Apr 2022 at 18:31, Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com<mailto:rifaat.s.i...@gmail.com>> wrote: Gentlemen, During the last IETF meeting, you volunteered to review the step-up authentication draft. https://datatracker.ietf.org/doc/html/draft-bertocci-oauth-step-up-authn-challenge<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-bertocci-oauth-step-up-authn-challenge&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7C862c7d08c589472fb1ad08da23a84fd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861503080864352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Peo4ilfA8TBMal3JotN9LzisCerx0Qznc7%2F5asKVHHM%3D&reserved=0> Can you please review the document and provide your feedback on the mailing list? Thanks, Rifaat
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
