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

[Jaimandeep Singh]

Dear Warren,

It is always nice to read your elaborately written views. It helps in
getting perspective.

I have a slightly different take on the subject. What is the client
application going to do with the "acr_values"? Ultimately, it is going to
send these values to the authorization server in order to meet the required
end-user authentication criteria. This is what I am referring to as reverse
flow RS->client_app->AS.

I'm on the fence of calling the "user agent" untrusted.

Here we have to consider client applications that are other than browsers
such as native apps and these apps can surely be called "untrusted". These
native apps will first receive the "acr_values" from the RS and will then
use the "user agent" to pass the values to the authorization server.

I'd ask for at least one practical attack that this RFC enables (not
> necessarily causes).


Well I will start at the abstract level first. Wherever the trust
boundaries are crossed it results in security complications. Here the data
is moving from trusted (RS)->untrusted (client-app)->trusted(AS). Now,
coming to specific examples,

Example 1: OWASP Top10: API8:2019 Injection. Once the client_app presents
the "acr_values" data to the authorization server it has to be sanitized,
otherwise it can result in unintended command execution.

Example 2: OWASP Top 10: API1:2019 Broken Object Level Authorization.  The
client_app will use all possible combinations of "acr_values" to know the
behaviour of the particular authorization endpoint/server.

On Tue, Oct 25, 2022 at 5:23 PM Warren Parad  wrote:

> I'm glad that we can move on from item No 1. Regarding this second one,
> the AS is not required to be involved in this communication, as the RS
> already has the capability to convey to the user agent why the access token
> is denied. It just hasn't been standardized. There are lot's of reasons why
> an access token or the user identity the token is for might not contain the
> necessary authorization to access to the resource. I see here we are only
> codifying that communication rather than opening any holes.
>
> What's the reason for needing to sign data from the RS, the RS might not
> even be a client of the AS, so if theoretically necessary, we would have to
> challenge our suggested implementation. Is there a specific security
> problem you are thinking about?
>
> I'm on the fence of calling the "user agent" untrusted. Sure it is, but
> the browsers have the expectation to expose the requests from the RS to the
> user, if we blindly passed the acr_values from the RS directly to the AS
> then there would be a problem, but signing the values wouldn't change
> anything. In any case the user agent/client application can't be agnostic
> to the acr_values because updating the acr actually does require user
> input. While the user agent the user is using to interact with the RS might
> not be the same one used for the AS in the acr needed value, for instance
> the hypothetical SMS, still there is a user interaction.
>
> I'm not seeing any security issue here, and while exposing data to a
> malicious attacker is always a concern, this is opt-in functionality by the
> RS, so if they are concerned they need not implement the RFC. I'd ask for
> at least one practical attack that this RFC enables (not necessarily
> causes).
>
> On Tue, Oct 25, 2022 at 1:29 PM Jaimandeep Singh <
> jaimandeep.phdc...@nfsu.ac.in> wrote:
>
>> Dear Warren, Brian and Vittorio,
>> My concerns regarding the additional complexity are well addressed by
>> Warren. I am reproducing the same for sake of records in the email archive.
>>
>>> I'd love to see a situation where it is a better at the gateway level.
>>> The problem is that, even if you could, you almost certainly shouldn't,
>>> since doing so couples the gateway to the authorization check/permissions
>>> validation of the service. The gateway now needs to become away of how the
>>> underlying resources work.
>>
>> Even in simple scenarios, this becomes impossible to manage since
>>> understanding the "business logic" is required to know "whether a user
>>> should have access". That means the gateways are doomed from the start.
>>
>> As I mentioned it is possible, doing the check at the component level can
>>> be augmented by a system that manages those permissions, which different
>>> from doing the check at the gateway level. At least this is what we advice
>>> the clients of our CIAM solution.
>>
>>
>> I would like to close the concerns regarding Item No-1 and move on
>> towards Item No 2. I am reproducing the conversation for sake of ease of
>> reference.
>>
>> *Item No 2*: Punching a security hole by requiring AS to act on
>> information provided by the client applications (Reverse Flow).
>> *Follow-up Comments-v2*. Refer Section abstract of draft RFC
>>
>>> This document also codifies a mechanism for a client to request that an
>>> authorization server achieve a specific authentication strength or
>>> freshness when 

[OAUTH-WG] Security Topics | Incorporate in-browser communication security considerations | PR53

[Christian Mainka]

Hi,

we would like to request the inclusion of _in-browser communication 
security considerations_ in the OAuth security topics.


We found that in-browser communications like the postMessage API is 
widely used by Clients and Authorization Servers as an alternative to 
the standardized HTTP redirects.
If these techniques are used insecurely, OAuth token leaks and 
injections are possible.


We publish our results soon at ACM CCS in November 2022.
The paper is accessible [1].

We think that the paragraph about in-browser communications should be 
added to the security topics.
We created a pull request [2] to help developers in understanding the 
risks and best practices of using in-browser communications in OAuth.


We are happy to discuss the idea here or directly in the pull request.

Best regards
Christian

[1]: "DISTINCT: Identity Theft using In-Browser Communications in 
Dual-Window Single Sign-On, https://distinct-sso.com/paper.pdf


[2]: https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/53

--
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security
Chair for Network and Data Security
Ruhr University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
https://nds.rub.de/chair/people/cmainka/
@CheariX

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

I'm glad that we can move on from item No 1. Regarding this second one, the
AS is not required to be involved in this communication, as the RS already
has the capability to convey to the user agent why the access token is
denied. It just hasn't been standardized. There are lot's of reasons why an
access token or the user identity the token is for might not contain the
necessary authorization to access to the resource. I see here we are only
codifying that communication rather than opening any holes.

What's the reason for needing to sign data from the RS, the RS might not
even be a client of the AS, so if theoretically necessary, we would have to
challenge our suggested implementation. Is there a specific security
problem you are thinking about?

I'm on the fence of calling the "user agent" untrusted. Sure it is, but the
browsers have the expectation to expose the requests from the RS to the
user, if we blindly passed the acr_values from the RS directly to the AS
then there would be a problem, but signing the values wouldn't change
anything. In any case the user agent/client application can't be agnostic
to the acr_values because updating the acr actually does require user
input. While the user agent the user is using to interact with the RS might
not be the same one used for the AS in the acr needed value, for instance
the hypothetical SMS, still there is a user interaction.

I'm not seeing any security issue here, and while exposing data to a
malicious attacker is always a concern, this is opt-in functionality by the
RS, so if they are concerned they need not implement the RFC. I'd ask for
at least one practical attack that this RFC enables (not necessarily
causes).

On Tue, Oct 25, 2022 at 1:29 PM Jaimandeep Singh <
jaimandeep.phdc...@nfsu.ac.in> wrote:

> Dear Warren, Brian and Vittorio,
> My concerns regarding the additional complexity are well addressed by
> Warren. I am reproducing the same for sake of records in the email archive.
>
>> I'd love to see a situation where it is a better at the gateway level.
>> The problem is that, even if you could, you almost certainly shouldn't,
>> since doing so couples the gateway to the authorization check/permissions
>> validation of the service. The gateway now needs to become away of how the
>> underlying resources work.
>
> Even in simple scenarios, this becomes impossible to manage since
>> understanding the "business logic" is required to know "whether a user
>> should have access". That means the gateways are doomed from the start.
>
> As I mentioned it is possible, doing the check at the component level can
>> be augmented by a system that manages those permissions, which different
>> from doing the check at the gateway level. At least this is what we advice
>> the clients of our CIAM solution.
>
>
> I would like to close the concerns regarding Item No-1 and move on towards
> Item No 2. I am reproducing the conversation for sake of ease of reference.
>
> *Item No 2*: Punching a security hole by requiring AS to act on
> information provided by the client applications (Reverse Flow).
> *Follow-up Comments-v2*. Refer Section abstract of draft RFC
>
>> This document also codifies a mechanism for a client to request that an
>> authorization server achieve a specific authentication strength or
>> freshness when processing an authorization request.
>
>
> a. In our journey of OAuth 2.0 we are still struggling with security
> issues related to access tokens from AS->clientapp->RS. Now, we are
> introducing a reverse flow, which is likely to introduce numerous other
> vulnerabilities. Whenever the communication crosses the boundaries from
> trusted -> untrusted -> trusted it creates its own set of security
> problems.
> b. Need for signing the values (error_codes) returned by the RS which can
> be verified by the AS. Therefore, we need to look at ways by which the RS
> returns a signed JWT token containing "acr_values" or other such parameters
> which are opaque to the client applications. I also appreciate that signed
> JWT will create its own complexities especially with regards to verifying
> the association between the RS and its public key.
>
>
> On Mon, Oct 24, 2022 at 6:18 PM Jaimandeep Singh <
> jaimandeep.phdc...@nfsu.ac.in> wrote:
>
>> Dear Warren,
>> It seems reasonable to handle items one by one in order to reach
>> convergence. I am taking up Item No1 in this email to achieve convergence
>> and close the same. The previous suggestions can be referenced at part-1
>> ,
>> part-2
>> 
>> and part-3
>> 
>> .
>>
>> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling end user
>> authentication with authorization.
>> *Follow-up Comments-v3*. My original concern was the introduction of
>> tight coupling between end user 

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

[Jaimandeep Singh]

Dear Warren, Brian and Vittorio,
My concerns regarding the additional complexity are well addressed by
Warren. I am reproducing the same for sake of records in the email archive.

> I'd love to see a situation where it is a better at the gateway level. The
> problem is that, even if you could, you almost certainly shouldn't, since
> doing so couples the gateway to the authorization check/permissions
> validation of the service. The gateway now needs to become away of how the
> underlying resources work.

Even in simple scenarios, this becomes impossible to manage since
> understanding the "business logic" is required to know "whether a user
> should have access". That means the gateways are doomed from the start.

As I mentioned it is possible, doing the check at the component level can
> be augmented by a system that manages those permissions, which different
> from doing the check at the gateway level. At least this is what we advice
> the clients of our CIAM solution.


I would like to close the concerns regarding Item No-1 and move on towards
Item No 2. I am reproducing the conversation for sake of ease of reference.

*Item No 2*: Punching a security hole by requiring AS to act on information
provided by the client applications (Reverse Flow).
*Follow-up Comments-v2*. Refer Section abstract of draft RFC

> This document also codifies a mechanism for a client to request that an
> authorization server achieve a specific authentication strength or
> freshness when processing an authorization request.


a. In our journey of OAuth 2.0 we are still struggling with security issues
related to access tokens from AS->clientapp->RS. Now, we are introducing a
reverse flow, which is likely to introduce numerous other vulnerabilities.
Whenever the communication crosses the boundaries from trusted -> untrusted
-> trusted it creates its own set of security problems.
b. Need for signing the values (error_codes) returned by the RS which can
be verified by the AS. Therefore, we need to look at ways by which the RS
returns a signed JWT token containing "acr_values" or other such parameters
which are opaque to the client applications. I also appreciate that signed
JWT will create its own complexities especially with regards to verifying
the association between the RS and its public key.


On Mon, Oct 24, 2022 at 6:18 PM Jaimandeep Singh <
jaimandeep.phdc...@nfsu.ac.in> wrote:

> Dear Warren,
> It seems reasonable to handle items one by one in order to reach
> convergence. I am taking up Item No1 in this email to achieve convergence
> and close the same. The previous suggestions can be referenced at part-1
> ,
> part-2
> 
> and part-3
> 
> .
>
> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling end user
> authentication with authorization.
> *Follow-up Comments-v3*. My original concern was the introduction of
> tight coupling between end user authentication and the OAuth 2.0. It was
> explained by Brian that the draft RFC does not intend to introduce any
> coupling and just provides a channel of signal/information flow between AS
> and RS via client app. It is just that the signal as of now only contains
> data on the end-user authentication. This seems to be a
> reasonable explanation and the point is not pressed further. However, this
> has raised two sub concerns. One is mentioned in Item No5, so I am not
> taking it up here.
>
> The other remaining sub concern is the complexity introduced due to the
> introduction of the new channel. If we look from the higher level of
> abstraction, earlier the events concerned were handled at the
> interface/entry level, now the information about the events is passed on to
> the other components of the system . All the other components may handle
> the events as per their policies and can be out of sync with each other.
>
> Coming back to OAuth 2.0, earlier the authentication complexities were
> handled by AS as per OIDC specs. Now, with the introduction of this
> channel, the authentication event information is being passed on to the RS.
> The requirement/behaviour of RS may not be in sync with the requirements of
> AS. I had given a hypothetical example of one such complexity in my email
> part-3. Just to give another flavour of the complexity I am quoting from
> Section 5 of the draft RFC which acknowledges the existence of loops being
> handled by OIDC specs.
>
> The recommended behavior will help prevent clients getting stuck in a loop
>> where the authorization server keeps returning tokens that the resource
>> server already identified as not meeting its requirements hence known to be
>> rejected as well.
>
>
> If the esteemed members are of the view that the benefits accrued are more
> than the complexity introduced we can close the concern and 

Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

[Joseph Heenan]

Hi Pieter / Daniel / Filip

It’s great to see this document moving forward.

I may have missed it, but it may be worth being move explicit that one solution 
is to avoid using cross-device flows for same-device scenarios? It’s sort of 
obvious, but questions like “well CIBA works for both cross-device and 
same-device, can’t I save myself effort by only implementing CIBA and not 
bothering with standard redirect-based OAuth flows?” are commonly asked.

Also, in this text:

"If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel 
Authentication (CIBA) provides an alternative, provided that the underlying 
devices can receive push notifications.”

It might be best to use a term other than ‘push notifications’ there or 
otherwise rewording this, as there are alternatives. e.g. I think there’s at 
least one CIBA implementation out there that can use email to notify the user 
of an authorization request.

Thanks

Joseph

> On 19 Oct 2022, at 15:55, Pieter Kasselman 
>  wrote:
> 
> Hi All
> 
> Following on from the discussions at IETF 113, the OAuth Security Workshop, 
> Identiverse and IETF 114, Daniel, Filip and I created a draft document 
> capturing some of the attacks that we are seeing on cross device flows, 
> including Device Authorization Grant (aka Device Code Flow). 
> 
> These attacks exploit the unauthenticated channel between devices to trick 
> users into granting authorization by using social engineering techniques to 
> change the context in which authorization is requested. 
> 
> The purpose of the document is to serve as guidance on best practices when 
> designing and implementing scenarios that require cross device flows. We 
> would appreciate any feedback or comments on the document, or any other 
> mitigations or techniques that can be used to mitigate these attacks. Links 
> to the documents are below. We also hope to discuss this at IETF 115 in 
> London in a few weeks' time.
> 
> -
> A new version of I-D, draft-kasselman-cross-device-security-00.txt
> has been successfully submitted by Pieter Kasselman and posted to the IETF 
> repository.
> 
> Name: draft-kasselman-cross-device-security
> Revision: 00
> Title:Cross Device Flows: Security Best Current Practice
> Document date:2022-10-19
> Group:Individual Submission
> Pages:25
> URL: 
> https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.txt
> Status: 
> https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.txt 
> Html:   
> https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kasselman-cross-device-security
> 
> 
> Abstract:
>   This document describes threats against cross-device flows along with
>   near term mitigations, protocol selection guidance and the analytical
>   tools needed to evaluate the effectiveness of these mitigations.  It
>   serves as a security guide to system designers, architects, product
>   managers, security specialists, fraud analysts and engineers
>   implementing cross-device flows.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> ___
> 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