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

[Hjelm, Bjorn]

As an editorial note, the text referenced (section 5.2.4) by Joseph, "If
FIDO2/WebAuthn support is not available, Channel Initiated Backchannel
Authentication (CIBA) provides an alternative.." should reference "Client
Initiated Backchannel Authentication (CIBA)". This reference is correct in
the other sections of the document.

BR,
Bjorn


On Tue, Oct 25, 2022 at 3:49 AM Joseph Heenan  wrote:

> 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  40microsoft@dmarc.ietf.org> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dkasselman-2Dcross-2Ddevice-2Dsecurity-2D00.txt=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=NMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9p1INnD0=laLdZ6c7CRHmE3mvQ2aDBaT2pwnLrnv5tpBSlWrkhQh12iyjLjJHa81GBcZn8pUc=xGpRQKj7UudEOCRHx2eWl0xhVQ1D5i4SH8sehvDPpCY=
>
> > Status:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dkasselman-2Dcross-2Ddevice-2Dsecurity-2D00.txt=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=NMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9p1INnD0=laLdZ6c7CRHmE3mvQ2aDBaT2pwnLrnv5tpBSlWrkhQh12iyjLjJHa81GBcZn8pUc=xGpRQKj7UudEOCRHx2eWl0xhVQ1D5i4SH8sehvDPpCY=
>
> > Html:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dkasselman-2Dcross-2Ddevice-2Dsecurity-2D00.html=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=NMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9p1INnD0=laLdZ6c7CRHmE3mvQ2aDBaT2pwnLrnv5tpBSlWrkhQh12iyjLjJHa81GBcZn8pUc=Sn0l7u31WG8K0mcGdKvUMraqQsXlGLzj_Ek6bm_qMBs=
>
> > Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dkasselman-2Dcross-2Ddevice-2Dsecurity=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=NMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9p1INnD0=laLdZ6c7CRHmE3mvQ2aDBaT2pwnLrnv5tpBSlWrkhQh12iyjLjJHa81GBcZn8pUc=TIQiF6Tn_sL0gchPWuET0N1NzdX4NNU_br6SWEoc_fc=
>
> >
> >
> > 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
> >
> 

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

[Jaimandeep Singh]

Dear Rifaat,

I respect your decision and wish all the best to the authors and members
going forward.

I would also like to bring to your kind attention that the discussions on
Item No 5 which suggested inclusion of client app parameters in the signal
flow could not be even started. I quote one of the previous emails by
Vittorio dated 13 Oct 2022, in which he has stated

> During the discussion we did inquire on other parameters/aspects that
> would have the same direct applicability but nothing was identified.


I was hoping for some discussions on this aspect given that the authors had
acknowledged the lack of suggestions.

Regards

On Wed, 26 Oct, 2022, 11:01 pm Rifaat Shekh-Yusef, 
wrote:

> Jaimandeep,
>
> With the chair hat on, and as the shepherd for this document, I think that
> the authors addressed your comments in detail, and Warren provided you with
> some valuable responses. I do not see a need for any further discussion at
> this stage.
>
> The next step is the shepherd review, which could start a new discussion
> about this document.
>
> Regards,
>  Rifaat
>
>
> On Tue, Oct 25, 2022 at 2:11 PM Jaimandeep Singh  40nfsu.ac...@dmarc.ietf.org> wrote:
>
>> 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 

[OAUTH-WG] Fine-grained Transactional Authorization (formerly RPC authorization)

[Atul Tulshibagwale]

Hi all,
I've been posting periodically about an initiative that we hope to discuss
during the IETF 115 sessions, which we are now calling Fine-grained
Transactional Authorization (FTA). As a group of about 10-15 people, we
have met a few times online, and arrived at this charter document for the
"work stream" or "working group".

We would love to get comments and feedback about this charter, and
participation in the discussions which we are proposing to have at IETF 115.

Thanks,
Atul
--

Atul Tulshibagwale
CTO, SGNL 
  


Fine-grained Transactional Authorization Working Group Charter.pdf
Description: Adobe PDF document
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Rifaat Shekh-Yusef]

Jaimandeep,

With the chair hat on, and as the shepherd for this document, I think that
the authors addressed your comments in detail, and Warren provided you with
some valuable responses. I do not see a need for any further discussion at
this stage.

The next step is the shepherd review, which could start a new discussion
about this document.

Regards,
 Rifaat


On Tue, Oct 25, 2022 at 2:11 PM Jaimandeep Singh  wrote:

> 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.
>>>
>>>

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

[Donna Chong Nee]

Hi, thanks so much.  Will take my time amending this with some help.

Smart E11

On Thu, 27 Oct 2022, 02:16 Daniel Fett, 
wrote:

> Hi Christian,
>
> thanks for bringing this to our attention! I think the recommendations in
> the PR are very helpful and we will consider adding the text to the
> document.
>
> -Daniel
> Am 25.10.22 um 15:37 schrieb 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
>
> ___
> 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

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

[Pieter Kasselman]

Thanks Joseph, those are good additions, thanks for pointing them out. I have 
opened issues to track both of them.

-Original Message-
From: Joseph Heenan  
Sent: Tuesday, October 25, 2022 11:49 AM
To: Pieter Kasselman 
Cc: oauth@ietf.org; Daniel Fett ; Filip Skokan 

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

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-00.txtdata=05%7C01%7Cpieter.kasselman%40microsoft.com%7C13d136330ec84e82ff1c08dab676965f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638022917712107364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=2qQECauAiHwL5QTl0ijskyr7Rk1OX3%2F8LducJ6HBPoU%3Dreserved=0
> Status: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-00.txtdata=05%7C01%7Cpieter.kasselman%40microsoft.com%7C13d136330ec84e82ff1c08dab676965f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638022917712107364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=2qQECauAiHwL5QTl0ijskyr7Rk1OX3%2F8LducJ6HBPoU%3Dreserved=0
>  
> Html:   
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-00.htmldata=05%7C01%7Cpieter.kasselman%40microsoft.com%7C13d136330ec84e82ff1c08dab676965f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638022917712107364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=IL3OzMJpCQLSLEOxUSBv71egJo%2FAk1TkveMLX2bVGqY%3Dreserved=0
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-kasselman-cross-device-securitydata=05%7C01%7Cpieter.kasselman%40microsoft.com%7C13d136330ec84e82ff1c08dab676965f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638022917712107364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=AAUBzWehBbE32S2tSk4MLghzBqnfyv7h5dVT%2F0xmLWU%3Dreserved=0
> 
> 
> 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
>   

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

[Daniel Fett]

Hi Christian,

thanks for bringing this to our attention! I think the recommendations 
in the PR are very helpful and we will consider adding the text to the 
document.


-Daniel

Am 25.10.22 um 15:37 schrieb 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth