Re: [OAUTH-WG] WGLC for Step-up Authentication

[Vittorio Bertocci <[e-mail]>]

Hi Yusuf,
thanks for your comments.
Before getting to the specific matters you raise: the specification was
submitted as work item and formally adopted by the WG with unambiguous
consensus months ago. We iterated on it on two inperson IETF events,
multiple industry events and on several online discussions also showing
clear interest. We just finished WG last call without identifying
significant issues. And there are already implementations in the wild, as
the problem is real and pressing in the industry. That doesn't mean it will
be useful for everyone, of course, but the evidence for many in the
industry finding this useful is as strong as the IETF process allows.

On the specific questions:
1) If you read the document, you'll see that the specification addresses
precisely the case where the client or the authorization server cannot know
beforehand what the authentication requirements are as they are determined
by the resource on specific circumstances- a common requirement that is
increasingly pervasive as continuous authentication and zero trust gain
popularity and adoption. It is true that this might expose extra info about
the system to an attacker, as mentioned in the security considerations
section, however A) RS can make challenges conditional on received valid
tokens, which eliminates all large scale attacks B) knowing an ACR might
not be particularly actionable without access to the corresponding
credentials, and if those credentials are available they can be tried by
enumeration anyway without the need for a challenge C) equivalent
mechanisms are already available in the standards, see insufficient_scope
and the OIDC claims parameter.
2) This matter was debated at length early on, but the TL;DR is: the
standards already feature general affordances for requesting scopes (via
insufficient_scope) and pretty much anything else (via the claims
parameter). However those methods aren't enjoying widespread adoption,
possibly because their expressive power to describe any requirement makes
it very hard for AS to implement it and very hard for clients and resources
to know what they can rely on.
This specification has been purposefully restricted to one particular use
case for which we have strong evidence there's a need in the wild, and that
is unambiguous enough to implement. During the discussion we did inquire on
other parameters/aspects that would have the same direct applicability but
nothing was identified.

I am happy to dig deeper on any of those aspects. It would be immensely
helpful if you could catch up on the document itself and the discussions
that already occurred so that we can build on the work already done :)
Thanks
V.


On Thu, Oct 13, 2022 at 8:55 AM Yusuf Khan <[e-mail]> wrote:

> *This message originated outside your organization.*
>
> ------------------------------
>
> Hi All,
>
> I have a question here to challenge the need for this document
> specification:
> 1. Here we are trying an attempt to return the information to the client
> to know the acr requirements for a resource on the resource server. I feel
> it will be true for all other parameters where the provided token is
> insufficient to access the resource e.g. scope, consent duration, any other
> user parameter or client app parameter. And this way we are trying to
> reveal the security requirements which are not valid for a
> legitimate client to know as it's already known to them. In other words,
> revealing this information is actually a favor to the attackers rather to a
> legitimate client who already knows the auth requirements for a resource.
>
> 2. If we really want to support it, then why is it limited to only acr and
> max age. It should be open to any kind of deficiency in the presented token
> so that the client gets to know about it and requests authorization from
> the authz server accordingly.
>
> Based on these assumptions, I am not in favor of supporting it unless
> someone clarifies the above 2 points strongly.
>
> Thanks and regards,
> Yusuf
>
> On Wed, Oct 12, 2022 at 1:55 AM Brian Campbell <bcampbell=
> [e-mail]> wrote:
>
>> I don't know offhand a better place or if your specific privacy
>> consideration is already covered. Honestly, with that comment, I was just
>> aiming to keep the scope of this document concise and relevant.
>>
>> On Tue, Oct 11, 2022 at 10:06 AM Denis <[e-mail]> wrote:
>>
>>> Hi Brian,
>>>
>>> I agree with you that "must not" is more appropriate in that context.
>>>
>>> I also agree with you that the "privacy implications of opaque tokens
>>> are inherent to OAuth in general".
>>> However, I have not reviewed all the RFCs and I wonder whether such a
>>> privacy consideration has already been mentioned.
>>>
>>> It would be nice to start to mention it, rather than to continue to omit
>>> it. Do you see a better place to mention it ?
>>>
>>> Denis
>>>
>>> Thanks Denis, I agree the word "cannot" isn't quite right there. I
>>> struggled with trying to find the right wording (more than I probably
>>> should have) attempting to add a note/reminder without getting into
>>> normative sounding language. But I also wanted to make a firm statement.
>>> Words are hard sometimes. Oftentimes! But reading it again today, "cannot"
>>> doesn't work very well. I think changing to "must not" is appropriate. The
>>> privacy implications of opaque tokens are inherent to OAuth in general and
>>> I don't believe this draft is an appropriate place to attempt to give them
>>> treatment.
>>>
>>> On Tue, Oct 11, 2022 at 2:57 AM Denis <[e-mail]> wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> The text states:
>>>>
>>>> Also recall that OAuth 2.0 [RFC6749] assumes access tokens are treated
>>>> as
>>>> opaque by clients. So, during the course of any token caching
>>>> strategy, a client *cannot* inspect the content of the access token to
>>>> determine the associated authentication information or other details.
>>>> The token format might be unreadable to the client or might change at
>>>> any time to become unreadable.
>>>>
>>>> A client *can *inspect the content of the access token.
>>>>
>>>> A better wording  would be:
>>>>
>>>> ...  a client *should not *inspect the content of the access token ...
>>>>
>>>> It would be worthwhile to add a Privacy Considerations section:
>>>>
>>>> 10. Privacy Considerations
>>>>
>>>> Since access tokens are presumed to be opaque to clients, clients (and
>>>> hence users) are not supposed to inspect the content of the access tokens.
>>>> Authorizations Servers are able to disclose more information than
>>>> strictly necessary about the authenticated user without the end user being
>>>> able to know it. Such additional information may endanger the privacy
>>>> of the user.
>>>>
>>>> Denis
>>>>
>>>>
>>>> I've published an -04. It has that very minor change. There was also an
>>>> off-list discussion during WGLC that resulted in thinking it'd be
>>>> worthwhile
>>>> *to add a reminder that access tokens are opaque to clients*. So I
>>>> took that as LC feedback and -04 adds a brief note towards that end.
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/
>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/__;!!PwKahg!_tTTH6a6ZkmSuoSd_s22eU8OkYd8Ge2IpfR9ty2PKQeeRJ-35MoeZaZTLf2NpArZhi8OV7QYIGpX075mLQ$>
>>>>
>>>>
>>>>
>>>> On Mon, Oct 10, 2022 at 1:22 PM Vittorio Bertocci <vittorio=
>>>> [e-mail]> wrote:
>>>>
>>>>> Thanks Dima for the comment. Some thoughts:
>>>>>
>>>>> > (editorial)...
>>>>> Good point. "statically" would characterize the simplest of the
>>>>> scenarios, but in fact any case where the AS is the only arbiter of the
>>>>> authn level works for the point we are trying to make. We'll drop
>>>>> "statically". Thanks!
>>>>>
>>>>> > Apart from...
>>>>> This spec focuses on empowering an RS to communicate its ACR and
>>>>> freshness requirements, regardless of the reasons leading the RS to make
>>>>> that determination: the logic by which that happens is explicitly out of
>>>>> scope, and in many real life cases it might simply be unknowable (eg
>>>>> anomaly detection engines based on ML are often back boxes). The mechanism
>>>>> described here can be used alongside other mechanisms that might require
>>>>> the client to get the user to interact with the AS, as it is the case for
>>>>> insufficient_scope, but those remain distinct cases (eg insufficient _scope
>>>>> might not require any step up but simply explicit user consent, and if it
>>>>> does require a stepup, that's entirely determined by the AS without any
>>>>> communication with client or RS required).
>>>>>
>>>>> On Fri, Oct 7, 2022 at 17:43 Dima Postnikov <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> *This message originated outside your organization.*
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Couple of quick comments from me:
>>>>>>
>>>>>> 1) (Editorial) >In simple API authorization scenarios, an
>>>>>> authorization server will statically determine what authentication technique
>>>>>>
>>>>>> In many scenarios, authorization servers will use *dynamic*
>>>>>> decisioning to determine authentication techniques; it's just not
>>>>>> exposed to the client in a way to make it actionable (which is why this
>>>>>> specification's intent makes perfect sense).
>>>>>>
>>>>>> 2) Apart from authentication level, there might be other reasons why
>>>>>> users might be forced to go through the authorization flow, for example,
>>>>>> insufficient authorization / scopes / claims / etc.
>>>>>>
>>>>>> If there is a mechanism to let the client know, as a practitioner,
>>>>>> i'd rather have the same approach for both authentication and
>>>>>> authorization. There are a range of authorization policy engines in the
>>>>>> market that could return "STEP UP is required" after looking at
>>>>>> authentication, authorisation and many other real-time signals. It's just
>>>>>> not standardized...
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 8, 2022 at 7:30 AM Pieter Kasselman <pieter.kasselman=
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> I am very supportive of this work and have been working through
>>>>>>> different use cases to see whether it can satisfy the requirements that
>>>>>>> arise from them.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> One observation from working through these uses cases is that as
>>>>>>> customers move to Zero Trust architectures, we are seeing customers
>>>>>>> adopting finer grained policy segmentation. Consequently customers are
>>>>>>> planning to deploy segmented access control by data or action sensitivity,
>>>>>>> within a service. This approach to policy design makes it more common for a
>>>>>>> single service to depend on multiple authentication context values or
>>>>>>> combinations of authentication context values.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> An example of this is a policy that has multiple acr values (e.g.
>>>>>>> acr1=password, acr2=FIDO, acr3=selfie check, acr4=trusted network). A
>>>>>>> customer may define a policy that requires different combinations of these
>>>>>>> acr values, for example, a file server may requires password for general
>>>>>>> access (e.g. acr1), FIDO authentication (acr2) or password access and being
>>>>>>> on a trusted network to read sensitive data (acr 2 of (acr1 + acr 4), FIDO
>>>>>>> authentication and password (acr1 + acr2) for accessing editing sensitive
>>>>>>> documents and a real-time selfie check on top of FIDO and presence on a
>>>>>>> trusted network  (acr1 + acr2 + acr3 + acr4) to initiate a sensitive
>>>>>>> workflow (e.g. check-in code). Other variations of this includes database
>>>>>>> access with different types of access requirement for certain rows
>>>>>>> (row-level permissions) or columns (column level permissions) with
>>>>>>> different combinations of acr values.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I was curious if this type of scenario where multiple authentication
>>>>>>> contexts and combinations of contexts are required is something others see
>>>>>>> (or are beginning to see) as well?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Pieter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* OAuth <[e-mail]> *On Behalf Of *Rifaat
>>>>>>> Shekh-Yusef
>>>>>>> *Sent:* Thursday, September 22, 2022 3:02 PM
>>>>>>> *To:* oauth <[e-mail]>
>>>>>>> *Subject:* Re: [OAUTH-WG] WGLC for Step-up Authentication
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Correction:*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please, review the document and provide your feedback on the mailing
>>>>>>> list by *Oct 7th, 2022*.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Sep 22, 2022 at 9:52 AM Rifaat Shekh-Yusef <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is to start a *WG Last Call *for the *Step-up Authentication *
>>>>>>> document:
>>>>>>>
>>>>>>> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-03.html
>>>>>>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-oauth-step-up-authn-challenge-03.html&data=05*7C01*7Cpieter.kasselman*40microsoft.com*7C0078f809101147bc978308da9ca32020*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637994521713812011*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=18sfemyWqYb06PvUA9eTLaq0ccDY14*2F6ETo58JpE*2FJQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PwKahg!537tJQfGj3Z_Yi2waywl1VPGyDs9818JE-M-KNFgPtoB0O26a7ksRvAYrPyzfKKXsMKCVblAomtRXj8$>
>>>>>>>
>>>>>>>
>>>>>>> Please, review the document and provide your feedback on the mailing
>>>>>>> list by *Sep 30th, 2022*.
>>>>>>>
>>>>>>> Regards,
>>>>>>>  Rifaat & Hannes
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!537tJQfGj3Z_Yi2waywl1VPGyDs9818JE-M-KNFgPtoB0O26a7ksRvAYrPyzfKKXsMKCVblAbcE1GME$>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!_tTTH6a6ZkmSuoSd_s22eU8OkYd8Ge2IpfR9ty2PKQeeRJ-35MoeZaZTLf2NpArZhi8OV7QYIGpYS7lhJA$>
>>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!_tTTH6a6ZkmSuoSd_s22eU8OkYd8Ge2IpfR9ty2PKQeeRJ-35MoeZaZTLf2NpArZhi8OV7QYIGpYS7lhJA$>
>>>>>
>>>>
>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>> privileged material for the sole use of the intended recipient(s). Any
>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>> If you have received this communication in error, please notify the sender
>>>> immediately by e-mail and delete the message and any file attachments from
>>>> your computer. Thank you.*
>>>>
>>>> _______________________________________________
>>>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!_tTTH6a6ZkmSuoSd_s22eU8OkYd8Ge2IpfR9ty2PKQeeRJ-35MoeZaZTLf2NpArZhi8OV7QYIGpYS7lhJA$>
>>>>
>>>>
>>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>>>
>>>
>>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*_______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!_tTTH6a6ZkmSuoSd_s22eU8OkYd8Ge2IpfR9ty2PKQeeRJ-35MoeZaZTLf2NpArZhi8OV7QYIGpYS7lhJA$>
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>