Re: [OAUTH-WG] Step-up Authentication review

Vittorio Bertocci <vittorio.bertocci@auth0.com> Mon, 25 April 2022 17:37 UTC

Return-Path: <vittorio.bertocci@okta.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D672AC1D351B for <oauth@ietfa.amsl.com>; Mon, 25 Apr 2022 10:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.155
X-Spam-Level:
X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=okta.com header.b=YMjN+eX7; dkim=pass (2048-bit key) header.d=auth0.com header.b=bqiZo+wg
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMu-Axn56cbe for <oauth@ietfa.amsl.com>; Mon, 25 Apr 2022 10:37:33 -0700 (PDT)
Received: from mx0a-00553301.pphosted.com (mx0a-00553301.pphosted.com [205.220.164.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00250C1D3513 for <oauth@ietf.org>; Mon, 25 Apr 2022 10:37:32 -0700 (PDT)
Received: from pps.filterd (localhost6.localdomain6 [127.0.0.1]) by mx0b-00553301.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 23PGpM1f014739 for <oauth@ietf.org>; Mon, 25 Apr 2022 10:37:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=okta.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=proofpoint-2020; bh=MquSIhIksAo5fhsXK2xD/uWyanGdu3i/2ENd7tEBsXc=; b=YMjN+eX7T7VVEOhXyD9GY42mUx97tkMkowOC9D/pNqrb/JdB58R2PVEx4ol/WnwrQyuG Ru4g32//tS3cjlfJeFPZJsparBsO77b0/a8xecplKp+mS6xocI6X4rR18+c0zyInnpZi SYV/u8kJkyLCw1qro+R4REc7/0tlc6O+X0P5rb3ks82s2a6VgMihSi8fy7m9oe88VEgd tRBnPBUoQpLCv61out2YvMn8y6I4DNJXIjlE08Ih1+kRgg41QwE5kgYTcw4M6puq7sVH Kq/a9dLxHJdZwRCVRBnm3l9TC7mH3f0ZBBNVLeAW1uGbV7qY3lJyqXrPBpcJi2vjQfPv 7Q==
Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) by mx0b-00553301.pphosted.com (PPS) with ESMTPS id 3fmd3t2xcj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <oauth@ietf.org>; Mon, 25 Apr 2022 10:37:32 -0700
Received: by mail-ua1-f71.google.com with SMTP id c18-20020ab00b92000000b0035ffe6d403fso6688894uak.5 for <oauth@ietf.org>; Mon, 25 Apr 2022 10:37:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=newauth0; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MquSIhIksAo5fhsXK2xD/uWyanGdu3i/2ENd7tEBsXc=; b=bqiZo+wga4my4Qw/Xjo96dNmoy0c1hGC8shdKK8yN2fo5jxzFtmFxVIWyInZWLoDi3 fSQCAnXSCt9mhNPoHMJKOzpb/PP15u1AXVvCvW5bUnn1w8P/5HNWLuz/UV9ownpgXwTb dOvPK4FEQ1073+SRSHzK62tDSHuwSElkmMrosaWmvbw1HMGk1uZ94LaDa2uO8YvzDXvN V7sS9CZ2TeF1zq/eNuykyGJ9Q/PrNgKyy09qBmKoleillveb71J3gtRH/3JSdKk4N7f1 /5hipg/4/IdMLgOO3swICnPD4y3E3wZTF5S7BaWTjLz+QnmG+a328STWoAEREf/hcJnX ipWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MquSIhIksAo5fhsXK2xD/uWyanGdu3i/2ENd7tEBsXc=; b=yxi1mJl7F/rj22OiUoKDGoXWZO7m6ulKhz/Zmxr0h99Y4aVCDQWU0r6J5jRAOhYjCV 6tDzUJ/0khirulzFYsv5aWN2K7Ws+SEQEigqyVAPlQmKtoLGZiP+s325dRNsWGEYzmG/ EtmHVI+iV6EZEQAJj3nHRCQOpJaAqE7E+YSFSgmgSLb5Kr1gYyTeuAYsuVCQ6AXKBzaR n+e9RRnf8zGukUY6TodfO022Azkx+duh2MUfnU0+rqVOg9wzA5wP3YydPBD5t2B8XAwA SxBlnpLIlVBH9UOw/rTkigiglRgxgiYPHPSmVA4zuo3Z9L3PHEHKcVOnrCq09WBj+g8n Wf+w==
X-Gm-Message-State: AOAM533CPRaG7hk1nhCgNfyPNJvmlexU/wwvgKO5aPp9PzbfcCTzWIip 2DQxVLdfFQt8fXdIvzSRH3U/k8wUftxIItB1lw/h+s0Ap3GPh8MdzzG8FZ/tnxqMT444JUpBV7i Lrhjp7k9q0ex4T4WdHzR9
X-Received: by 2002:a67:f850:0:b0:32a:238a:3c33 with SMTP id b16-20020a67f850000000b0032a238a3c33mr5148845vsp.25.1650908250714; Mon, 25 Apr 2022 10:37:30 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJzrOe0DGwTYFmr+9mDtiNDfNXlTtjuM1PE8JTs3L34JjdiyYYUJO97iBiOlZMOUOxPbc18lWrItP92pEdp7Ol4=
X-Received: by 2002:a67:f850:0:b0:32a:238a:3c33 with SMTP id b16-20020a67f850000000b0032a238a3c33mr5148834vsp.25.1650908250390; Mon, 25 Apr 2022 10:37:30 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP8vaZVdNOf31o-=MSV8VVzfJ8NnZ9jfxYTnx7anhraJpA@mail.gmail.com> <CALAqi_83OLuiiK83dXutipAcc2Os=03Lz5L5cw4Cf0NfwPficQ@mail.gmail.com> <AM7PR83MB0452F55F143486F0EAD20D3391F79@AM7PR83MB0452.EURPRD83.prod.outlook.com>
In-Reply-To: <AM7PR83MB0452F55F143486F0EAD20D3391F79@AM7PR83MB0452.EURPRD83.prod.outlook.com>
From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Date: Mon, 25 Apr 2022 10:37:18 -0700
Message-ID: <CAEFJvaoAP99meJ8p9uWSMrm81LMqnsvLcOtrp3aUXJrsPS=17g@mail.gmail.com>
To: Pieter Kasselman <pieter.kasselman@microsoft.com>, Filip Skokan <panva.ip@gmail.com>, oauth <oauth@ietf.org>, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d25b3f05dd7e070e"
X-Gmail-Okta-Auth: Authenticated
X-Gm-Spam: 0
X-Gm-Phishy: 0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-25_10,2022-04-25_03,2022-02-23_01
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/mbj242oTciFno5bXvI8oqyV4Cpg>
Subject: Re: [OAUTH-WG] Step-up Authentication review
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2022 17:47:28 -0000

Pieter, Filip,
Thank you so much for the time you invested in your thorough review, and
your support for the scenario!
We agree on both your main points: discovery is currently
underspecified/untapped, and there should be no assumption of total or even
partial ordering in the authentication levels domain. For the last point,
we didn't think the text made that assumption besides in the spec name
(which is meant to capture the intuition and the terminology commonly used
in literature) hence it's good to have this called out.

Before we get into the meat of the discussion, also given  IIW-OSW-EIC
making the next 3 weeks tricky for email, we would like to make a formal
call for adoption- as Filip says, that will give us the right structure to
identify and apply the refinements the document needs.
Thanks again!

On Fri, Apr 22, 2022 at 1:45 AM Pieter Kasselman <
pieter.kasselman@microsoft.com> wrote:

> *This message originated outside your organization.*
>
> ------------------------------
>
> 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
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bertocci-oauth-step-up-authn-challenge-01.html__;!!PwKahg!4qyNT5rmgf2-hGsGK8kshzvNDoHWPlKsDta6W4ecyH2hTE2YHt7u1wI2TABvYKBxZQwj5oZlg6j2qvQ-czqZ4I4GNpgLUvQgBoj4$>)
> 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-bounces@ietf.org> *On Behalf Of *Filip Skokan
> *Sent:* Thursday 21 April 2022 16:04
> *To:* Vittorio Bertocci <vittorio.bertocci@auth0.com>; Brian Campbell <
> bcampbell@pingidentity.com>; Rifaat Shekh-Yusef <rifaat.s.ietf@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.ietf@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://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!PwKahg!4qyNT5rmgf2-hGsGK8kshzvNDoHWPlKsDta6W4ecyH2hTE2YHt7u1wI2TABvYKBxZQwj5oZlg6j2qvQ-czqZ4I4GNpgLUvMezobL$>
>
>
>
> Can you please review the document and provide your feedback on the
> mailing list?
>
>
>
> Thanks,
>
>  Rifaat
>
>
>
>