[OAUTH-WG] Question regarding RFC 8628

[Robache Hervé]

Dear all

We are considering using RFC8628 for a specific use case that is related to the 
version 2 of Payment Service Directive in Europe (PSD2).

The purpose of the work is to provide a decoupled authentication flow for a 
payment Service User (PSU) aiming to grant access to a Third Party Provider 
(TPP) for his/her data hosted by a Bank.
The sequence should be as followed:

-  Nominal flow (as specified by the RFC)

o   The TPP asks the PSU about the Bank identity

o   The TPP posts a Device Access Token Request to the Bank

o   The Bank sends back a Device Access Token response to the TPP

o   The TPP starts to poll the bank for gaining the access token

-  Derived flow

o   The "verification_uri_complete" will not be displayed to the PSU but used 
as an [app link]/[universal link] on a smartphone in order to launch the bank's 
app.

o   The bank's app authenticates the PSU and asks for consent confirmation

-  Back to the nominal flow

o   The TPP gets its access token

Two questions have raised during the work

-  As RFC8628 is supposed to work on separate devices, can the usage be 
extrapolated to separate apps on the same device (i.e. the PSU's smartphone)?

-  One issue of the derived flow is that, after authentication, the PSU 
is still facing the bank's app

o   We would like to go back to the TPP's app as fluently as possible. The use 
of another [app link]/[universal link]could do the job is provided by the TPP. 
We consider adding this uri as an additional parameter to the 
"verification_uri_complete".

o   Is this compliant with RFC8628?

Thanks in advance for your answers.

Hervé Robache


Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, merci de 
le détruire ainsi que toute copie de votre système et d'en avertir 
immédiatement l'expéditeur.
Toute lecture non autorisée, toute utilisation de ce message qui n'est pas 
conforme à sa destination, toute diffusion ou toute publication, totale ou 
partielle, est interdite.
L'Internet ne permettant pas d'assurer l'intégrité de ce message électronique 
susceptible d'altération, STET décline toute responsabilité au titre de ce 
message dans l'hypothèse où il aurait été modifié, déformé ou falsifié.
N'imprimez ce message que si nécessaire, pensez à l'environnement.

This message and any attachments is intended solely for the intended addressees 
and is confidential.
If you receive this message in error, or are not the intended recipient(s), 
please delete it and any copies from your systems and immediately notify the 
sender.
Any unauthorized view, use that does not comply with its purpose, dissemination 
or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may not 
be reliable, STET shall not be liable for the message if modified, changed or 
falsified.
Do not print this message unless it is necessary, please consider the 
environment.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question regarding RFC 8628

[Rob Otto]

Salut Hervé

I wonder if you have looked at all at the OpenID Connect Client-Initiated
BackChannel Authentication (CIBA) flow for this use case? Certainly the
feeling amongst the Open Banking community here in the UK is that  it might
be a better fit for decoupled authentication than the Device Authorisation
Grant. There is even a FAPi (Financial-Grade API) profile of CIBA that is
making its way through the standardisation process - and even has a working
conformance testing suite.

The other option, that could make life easier when it comes to the final
step you mention (switching back to the TPP app from the Bank app) is to
use an app-to-app redirect model under OIDC. Again this is a popular model
for same-device scenarios that's been implemented by many banks here in the
UK.

If you'd like more information on either of these approaches, I'm happy to
share.

Best regards
Rob



On Mon, 18 Nov 2019 at 08:24, Robache Hervé  wrote:

> Dear all
>
>
>
> We are considering using RFC8628 for a specific use case that is related
> to the version 2 of Payment Service Directive in Europe (PSD2).
>
>
>
> The purpose of the work is to provide a decoupled authentication flow for
> a payment Service User (PSU) aiming to grant access to a Third Party
> Provider (TPP) for his/her data hosted by a Bank.
>
> The sequence should be as followed:
>
> -  Nominal flow (as specified by the RFC)
>
> o   The TPP asks the PSU about the Bank identity
>
> o   The TPP posts a Device Access Token Request to the Bank
>
> o   The Bank sends back a Device Access Token response to the TPP
>
> o   The TPP starts to poll the bank for gaining the access token
>
> -  Derived flow
>
> o   The “verification_uri_complete” will not be displayed to the PSU but
> used as an [app link]/[universal link] on a smartphone in order to launch
> the bank’s app.
>
> o   The bank’s app authenticates the PSU and asks for consent confirmation
>
> -  Back to the nominal flow
>
> o   The TPP gets its access token
>
>
>
> Two questions have raised during the work
>
> -  As RFC8628 is supposed to work on separate devices, can the
> usage be extrapolated to separate apps on the same device (i.e. the PSU’s
> smartphone)?
>
> -  One issue of the derived flow is that, after authentication,
> the PSU is still facing the bank’s app
>
> o   We would like to go back to the TPP’s app as fluently as possible.
> The use of another [app link]/[universal link]could do the job is provided
> by the TPP. We consider adding this uri as an additional parameter to the
> “verification_uri_complete”.
>
> o   Is this compliant with RFC8628?
>
>
>
> Thanks in advance for your answers.
>
>
>
> Hervé Robache
>
>
> Ce message et toutes les pièces jointes sont établis à l'intention
> exclusive de ses destinataires et sont confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destiné,
> merci de le détruire ainsi que toute copie de votre système et d'en avertir
> immédiatement l'expéditeur.
> Toute lecture non autorisée, toute utilisation de ce message qui n'est pas
> conforme à sa destination, toute diffusion ou toute publication, totale ou
> partielle, est interdite.
> L'Internet ne permettant pas d'assurer l'intégrité de ce message
> électronique susceptible d'altération, STET décline toute responsabilité au
> titre de ce message dans l'hypothèse où il aurait été modifié, déformé ou
> falsifié.
> N'imprimez ce message que si nécessaire, pensez à l'environnement.
>
> This message and any attachments is intended solely for the intended
> addressees and is confidential.
> If you receive this message in error, or are not the intended
> recipient(s), please delete it and any copies from your systems and
> immediately notify the sender.
> Any unauthorized view, use that does not comply with its purpose,
> dissemination or disclosure, either whole or partial, is prohibited.
> Since the internet cannot guarantee the integrity of this message which
> may not be reliable, STET shall not be liable for the message if modified,
> changed or falsified.
> Do not print this message unless it is necessary, please consider the
> environment.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
[image: Ping Identity]

Rob Otto
EMEA Field CTO/Solutions Architect
roberto...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]

[image:
LinkedIn logo]  [image: twitter
logo]  [image: facebook logo]
 [image: youtube logo]
 [image: Google+ logo]
 [image: Blog logo]

Re: [OAUTH-WG] Question regarding RFC 8628

[Torsten Lodderstedt]

Hi Hervé,

I assume you want to allow the TPP to send the PSU to the bank’s app on the 
same device?

In that case, why don’t you just make the bank’s authorization endpoint URL the 
universal link? If the universal link is defined on the smartphone (since the 
bank’s app is installed), the redirect will open the app. If the app is not 
installed, well, it will open the authorization endpoint in the browser. A very 
robust and simple approach.

There is an excellent article about this topic by Joseph Hernan on openid.net 
https://openid.net/2019/10/21/guest-blog-implementing-app-to-app-authorisation-in-oauth2-openid-connect/.

best regards,
Torsten.

> Am 18.11.2019 um 16:24 schrieb Robache Hervé :
> 
> 
> Dear all
>  
> We are considering using RFC8628 for a specific use case that is related to 
> the version 2 of Payment Service Directive in Europe (PSD2).
>  
> The purpose of the work is to provide a decoupled authentication flow for a 
> payment Service User (PSU) aiming to grant access to a Third Party Provider 
> (TPP) for his/her data hosted by a Bank.
> The sequence should be as followed:
> -  Nominal flow (as specified by the RFC)
> o   The TPP asks the PSU about the Bank identity
> o   The TPP posts a Device Access Token Request to the Bank
> o   The Bank sends back a Device Access Token response to the TPP
> o   The TPP starts to poll the bank for gaining the access token
> -  Derived flow
> o   The “verification_uri_complete” will not be displayed to the PSU but used 
> as an [app link]/[universal link] on a smartphone in order to launch the 
> bank’s app.
> o   The bank’s app authenticates the PSU and asks for consent confirmation
> -  Back to the nominal flow
> o   The TPP gets its access token
>  
> Two questions have raised during the work
> -  As RFC8628 is supposed to work on separate devices, can the usage 
> be extrapolated to separate apps on the same device (i.e. the PSU’s 
> smartphone)?
> -  One issue of the derived flow is that, after authentication, the 
> PSU is still facing the bank’s app
> o   We would like to go back to the TPP’s app as fluently as possible. The 
> use of another [app link]/[universal link]could do the job is provided by the 
> TPP. We consider adding this uri as an additional parameter to the 
> “verification_uri_complete”.
> o   Is this compliant with RFC8628?
>  
> Thanks in advance for your answers.
>  
> Hervé Robache
> 
> 
> Ce message et toutes les pièces jointes sont établis à l'intention exclusive 
> de ses destinataires et sont confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, merci 
> de le détruire ainsi que toute copie de votre système et d'en avertir 
> immédiatement l'expéditeur.
> Toute lecture non autorisée, toute utilisation de ce message qui n'est pas 
> conforme à sa destination, toute diffusion ou toute publication, totale ou 
> partielle, est interdite.
> L'Internet ne permettant pas d'assurer l'intégrité de ce message électronique 
> susceptible d'altération, STET décline toute responsabilité au titre de ce 
> message dans l'hypothèse où il aurait été modifié, déformé ou falsifié.
> N'imprimez ce message que si nécessaire, pensez à l'environnement.
> 
> This message and any attachments is intended solely for the intended 
> addressees and is confidential.
> If you receive this message in error, or are not the intended recipient(s), 
> please delete it and any copies from your systems and immediately notify the 
> sender.
> Any unauthorized view, use that does not comply with its purpose, 
> dissemination or disclosure, either whole or partial, is prohibited.
> Since the internet cannot guarantee the integrity of this message which may 
> not be reliable, STET shall not be liable for the message if modified, 
> changed or falsified.
> Do not print this message unless it is necessary, please consider the 
> environment.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question regarding RFC 8628

[Torsten Lodderstedt]

Hi Hervé,

looping in Joseph.

> On 18. Nov 2019, at 21:17, Robache Hervé  wrote:
> 
> Thanks Torsten
>  
> Yes, we study this flow as well. Actually we consider the two following flows 
> for a mobile-based authentication
>  
> -  DECOUPLED : via a RFC8628-derived or CIBA approach (as suggested 
> by Rob)
> -  REDIRECT : via the flow specified in the OpenId link you gave.
>  
> The main issue encountered so far is to give back the focus on the third 
> party app. Third Parties fear that their app will be kept in the back of the 
> mobile screen.

@Joseph: what’s your take on this concern? 

> This could happen when the TPP app [app link]/[universal link] is not 
> properly registered or forwarded to the bank app.
> -  In the REDIRECT approach this means that the authorization code 
> cannot be forwarded to the TPP
> -  In the DECOUPLED approach it less critical since the TPP polls the 
> bank and eventually gets its token once the PSU has authenticated.

But in the decoupled flow, the PSU first has to enter her PSU ID in order to 
allow the TPP to identity the PSU towards the ASPSP. This is less convenient 
and leaks PII.

best regards,
Torsten. 

>  
> Best regards
>  
> Hervé
>  
> De : Torsten Lodderstedt [mailto:tors...@lodderstedt.net] 
> Envoyé : lundi 18 novembre 2019 11:39
> À : Robache Hervé
> Cc : oauth@ietf.org
> Objet : [OAUTH-WG] Question regarding RFC 8628
>  
> Hi Hervé,
>  
> I assume you want to allow the TPP to send the PSU to the bank’s app on the 
> same device?
>  
> In that case, why don’t you just make the bank’s authorization endpoint URL 
> the universal link? If the universal link is defined on the smartphone (since 
> the bank’s app is installed), the redirect will open the app. If the app is 
> not installed, well, it will open the authorization endpoint in the browser. 
> A very robust and simple approach.
>  
> There is an excellent article about this topic by Joseph Hernan on openid.net 
> https://openid.net/2019/10/21/guest-blog-implementing-app-to-app-authorisation-in-oauth2-openid-connect/.
>  
> best regards,
> Torsten.
> 
> 
> Am 18.11.2019 um 16:24 schrieb Robache Hervé :
> 
>  
> Dear all
>  
> We are considering using RFC8628 for a specific use case that is related to 
> the version 2 of Payment Service Directive in Europe (PSD2).
>  
> The purpose of the work is to provide a decoupled authentication flow for a 
> payment Service User (PSU) aiming to grant access to a Third Party Provider 
> (TPP) for his/her data hosted by a Bank.
> The sequence should be as followed:
> -  Nominal flow (as specified by the RFC)
> o   The TPP asks the PSU about the Bank identity
> o   The TPP posts a Device Access Token Request to the Bank
> o   The Bank sends back a Device Access Token response to the TPP
> o   The TPP starts to poll the bank for gaining the access token
> -  Derived flow
> o   The “verification_uri_complete” will not be displayed to the PSU but used 
> as an [app link]/[universal link] on a smartphone in order to launch the 
> bank’s app.
> o   The bank’s app authenticates the PSU and asks for consent confirmation
> -  Back to the nominal flow
> o   The TPP gets its access token
>  
> Two questions have raised during the work
> -  As RFC8628 is supposed to work on separate devices, can the usage 
> be extrapolated to separate apps on the same device (i.e. the PSU’s 
> smartphone)?
> -  One issue of the derived flow is that, after authentication, the 
> PSU is still facing the bank’s app
> o   We would like to go back to the TPP’s app as fluently as possible. The 
> use of another [app link]/[universal link]could do the job is provided by the 
> TPP. We consider adding this uri as an additional parameter to the 
> “verification_uri_complete”.
> o   Is this compliant with RFC8628?
>  
> Thanks in advance for your answers.
>  
> Hervé Robache
> 
> 
> Ce message et toutes les pièces jointes sont établis à l'intention exclusive 
> de ses destinataires et sont confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, merci 
> de le détruire ainsi que toute copie de votre système et d'en avertir 
> immédiatement l'expéditeur.
> Toute lecture non autorisée, toute utilisation de ce message qui n'est pas 
> conforme à sa destination, toute diffusion ou toute publication, totale ou 
> partielle, est interdite.
> L'Internet ne permettant pas d'assurer l'intégrité de ce message électronique 
> susceptible d'altération, STET décline toute responsabilité au titre de ce 
> message dans l'hypothèse où il aurait été modifié, déformé ou falsifié.
> N'imprimez ce message que si nécessaire, pensez à l'environnement.
> 
> This message and any attachments is intended solely for the intended 
> addressees and is confidential.
> If you receive this message in error, or are not the intended recipient(s), 
> please delete it and any copies from your systems and immediately notify the 
> sen

Re: [OAUTH-WG] Question regarding RFC 8628

[Joseph Heenan]

Hi all,

Thanks, Torsten.

> On 18 Nov 2019, at 13:22, Torsten Lodderstedt  wrote:
> 
> Hi Hervé,
> 
> looping in Joseph.
> 
>> On 18. Nov 2019, at 21:17, Robache Hervé > > wrote:
>> 
>> Thanks Torsten
>> 
>> Yes, we study this flow as well. Actually we consider the two following 
>> flows for a mobile-based authentication
>> 
>> -  DECOUPLED : via a RFC8628-derived or CIBA approach (as suggested 
>> by Rob)
>> -  REDIRECT : via the flow specified in the OpenId link you gave.
>> 
>> The main issue encountered so far is to give back the focus on the third 
>> party app. Third Parties fear that their app will be kept in the back of the 
>> mobile screen.
> 
> @Joseph: what’s your take on this concern? 

In app2app, it really shouldn’t happen - if the device OS has not properly 
registered the universal link, the TPP website would open instead and 
authorization code can still be processed (though admittedly supporting this 
use case may require a bit more care to ensure session mixup attacks can’t 
happen).

> 
>> This could happen when the TPP app [app link]/[universal link] is not 
>> properly registered or forwarded to the bank app.
>> -  In the REDIRECT approach this means that the authorization code 
>> cannot be forwarded to the TPP

I don’t really understand how the ‘app link’ would not be properly registered 
to the bank app. The universal link should be the same URL as for the redirect 
uri on the TPP website. Obviously if the TPP registers their redirect uri 
incorrectly with the bank the flow won’t work, but this applies equally to the 
web based flows, and it’s not the kind of problem you see occur on a production 
system.

The evidence from the UK so far is that drop-off rates (where the user does not 
successfully complete the authentication and return to the third party) are far 
lower for app2app compared to a normal oauth2 browser based redirect flow; I 
can’t put my hand on the actual figures right now but from memory around 5 
times more users successfully completed an app2app flow than the usual web 
flows.

>> -  In the DECOUPLED approach it less critical since the TPP polls 
>> the bank and eventually gets its token once the PSU has authenticated.
> 
> But in the decoupled flow, the PSU first has to enter her PSU ID in order to 
> allow the TPP to identity the PSU towards the ASPSP. This is less convenient 
> and leaks PII.

Not necessarily the PSU ID, but generally something that can be used to 
identify the user. In theory it could be an ephemeral id, though in reality 
there’s all sorts of issues with implementing that, particularly on a ’same 
device’ flow. It’s definitely less convenient, particularly for the first 
TPP<->ASPSP interaction where the TPP will necessarily have to collect more 
info from the user than would be necessary in a redirect based flow.

The user also has to manually switch back to the TPP app at the end of the flow.

My general opinion is that for most use cases where the consumption and 
authentication devices are the same device a decoupled flow should not be used, 
as for that use case app2app presents a far better user experience - both in 
terms of the number of steps and the time taken to successfully complete all 
the steps.

Joseph

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

Re: [OAUTH-WG] Question regarding RFC 8628

[Joseph Heenan]

Hi Hervé

> On 18 Nov 2019, at 14:20, Robache Hervé  wrote:
> 
> Thanks Joseph
>  
> I agree with you. There should be no issue when the URL is registered during 
> the TPP app installation.
>  
> From my perspective, this URL should be passed during the authorization 
> request within the [redirect_uri] field.

Exactly, and that same url should have been pre-registered with the 
authorization server.

>  
> By the way, most of the French banks will use Oauth2 AC and not OpenId 
> Connect. I guess that the sequence diagram is roughly the same, isn’t it?

Correct; pretty much exactly the same as I presume you’d still be using the 
authorization code flow.

The security concerns for app2app are very similar to basic OAuth2 / OpenID 
Connect, and to quickly sum those up for anyone reading this that's not 
familiar with those concerns: it’s very easy to do something that has 
undesirable security properties, and you should follow documents like FAPI-RW 
(an OpenID Connect based standard originally, but now JARM exists and has some 
vendor adoption OpenID Connect is not required) or the OAuth2 security BCP, to 
ensure your implementation is not vulnerable to the known attacks against 
OAuth2.

Cheers

Joseph

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

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

[Torsten Lodderstedt]

> On 17. Nov 2019, at 05:42, Vineet Banga  wrote:
> 
> 
> On Fri, Nov 15, 2019 at 11:51 PM Torsten Lodderstedt 
>  wrote:
> 
> >> On 16. Nov 2019, at 02:07, Vineet Banga 
> >>  wrote:
> >> 
> >> Just one comment/question at the moment:
> > >3.1.1 - Is there any recommendation around leveraging state vs using 
> > >multiple URIs (with exact match) to remember the application state of the 
> > >client? I have seen exploding list of registered redirect URIs, but am not 
> > >aware of any security issues around this usage. But would like to check if 
> > >there are any opinions on this matter..
> 
> >The BCP recommends transaction specific one time use state values for CSRF 
> >prevention. To achieve the same protection level with redirect URI’s and 
> >exact match, one would need to register per transaction redirect URI values. 
> 
> >Do your redirect URIs meet those requirements?
> No. I think the options are using state for purely csrf or using 
> [I-D.bradley-oauth-jwt-encoded-state], which is called our in the BCP. Using 
> encoded jwt can be used to limit the number of redirect uris. 

So you are saying "state" is used for CSRF. Then what is the rational of your 
original question? To move towards application state encoded in redirect URIs?

> 
> 
> 
> 
> 
> > 
> > 
> > On Wed, Nov 6, 2019 at 12:27 AM Hannes Tschofenig 
> >  wrote:
> > Hi all,
> > 
> > this is a working group last call for "OAuth 2.0 Security Best Current 
> > Practice".
> > 
> > Here is the document:
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
> > 
> > Please send you comments to the OAuth mailing list by Nov. 27, 2019.
> > (We use a three week WGLC because of the IETF meeting.)
> > 
> > Ciao
> > Hannes & Rifaat
> > 
> > IMPORTANT NOTICE: The contents of this email and any attachments are 
> > confidential and may also be privileged. If you are not the intended 
> > recipient, please notify the sender immediately and do not disclose the 
> > contents to any other person, use it for any purpose, or store or copy the 
> > information in any medium. Thank you.
> > 
> > ___
> > 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
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [3/3]

[Torsten Lodderstedt]

Hi Hans, 

> On 18. Nov 2019, at 04:11, Hans Zandbelt  wrote:
> 
> Hi,
> 
> Please find my feedback from page 21 onwards below.
> 
> Hans.
> 
> Overall I would argue there's room for a very concise guidance section that 
> says: do this, don't do that, without explanation, just as a reference for 
> developers; the current text provides in depth analysis but that is perhaps 
> not suitable for developers who just want to know what to do (or not to do) 
> and don't really care about the background/reasoning

While section 4 gives the raw security threat analysis, we tried to summarise 
the actionable guidance in section 3. What do you miss there?

> 
> P21
> first bullet
> "the client has bound this data to this particular instance." -> particular 
> instance of what?

This bullet refers to the note above. 

"Note: this check could also detect attempts to inject a code which
   had been obtained from another instance of the same client on another
   device, if certain conditions are fulfilled:"

> 
> 3rd paragraph:
> "call to the tokens endpoint." -> "call to the token endpoint."

Fixed 

> 
> last paragraph could forward point to the next section by adding something 
> like
> "using one of the mechanisms described in the next section."

Incorporated 

> 
> P22
> 3rd paragraph:
> is the token binding guidance still accurate? it seems to be overestimating 
> the adoption 

You mean this statement? 

"Token binding is
  promising as a secure and convenient mechanism (due to its browser
  integration).  As a challenge, it requires broad browser support
  and use with native apps is still under discussion.”

Thanks,
Torsten. 

> 
> -- 
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

[Torsten Lodderstedt]

> Am 19.11.2019 um 13:39 schrieb Vineet Banga :
> 
> Let me restate my original question. I agree with the usage of state for CSRF 
> protection, but it can also be used to capture the application state (as 
> specified in: [I-D.bradley-oauth-jwt-encoded-state]). I am asking if there is 
> any recommendation between using state for both csrf and application state 
> Vs. relying completely on redirect URIs to maintain application state.
> 
> As an OAuth provider, I lean towards avoiding long and dynamic list of 
> redirect URIs. But I do understand that using state for both CSRF protection 
> and application state adds burden on clients/app developers. 

got you, thanks for the clarification.

I would recommend to use PKCE for CSRF prevention and state for representing 
the application state.

best regards,
Torsten.

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [2/3]

[Torsten Lodderstedt]

Hi Hans, 

> On 11. Nov 2019, at 17:57, Hans Zandbelt  wrote:
> 
> Hi,
> 
> Please find my feedback on page 11-20 below.
> 
> Hans.
> 
> P14
> 4.2.4 For an RP there should be more explicit text and guidance about having 
> a single dedicated immutatable redirect URI per client that "demultiplexes" 
> access to the protected resource by storing the original location that the 
> user agent was trying to access in the state associated with the 
> authorization request.
> 

Anything different from the guidance given in 3.1?

> P15
> same section 4.2.4, 2nd paragraph: if I'm correct the text about 
> authorization codes being single use only and revoke access tokens on 2nd use 
> is not different from the original RFC is it? If so, why repeat here?

To provide a complete list of measures and to remind the reader of what is 
already stated in RFC 6749.

The alternative would be to state something like, "beyond the measures given in 
RFC 6749, the following additional measures further reduce the chances of a 
successful
   attack:"

> 
> 3rd paragraph: why not a MUST for invalidating state (and randomizing it for 
> that matter) but only a SHOULD?

Because this is a discussion of options not the normative recommendation. 
Beside this, invalidating state introduces more state at the client, which 
might cause scalability problems.  

> 
> P16
> 4.3.2 the "postmessage communication" is mentioned here without any context 
> or explanation; I guess this refers to the OIDC session management spec 
> somehow?

It refers to a (non-existing) postMessage-based protocol to pass the code to 
the RP.

We adopted the second measure with our recommendation towards code&PKCE.

> 
> 4..4 Mixup: I would like to emphasize here that the mixup attack works 
> perfectly fine against two statically configured OPs, to avoid the impression 
> that it is somehow applicable in dynamic scenarios only. 

Changed it 

"Mix-up is an attack on scenarios where an OAuth client interacts with
multiple authorization servers, as is usually the case when dynamic
registration is used or if the client is statically configured to interact with 
multiple authorization servers."

> 
> P17
> About the description of the mixup attack: as long as the attacker is able to 
> trigger a request (by having the user click a link) and read the query/POST 
> parameters on the A-AS (perhaps from the logs) he can execute a mixup attack 
> by starting from the A-AS rather than the H-AS (as demonstrated in the OAuth 
> 2.0 security workshop in Darmstadt December 2016). Perhaps this can be made 
> more explicit.

I will ask Daniel to take a look into this.

best,
Torsten. 

> 
> -- 
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

[Brian Campbell]

On Thu, Nov 14, 2019 at 7:20 PM Neil Madden 
wrote:

> I can't attend Singapore either in person or remotely due to other
> commitments. I broadly support adoption of this draft, but I have some
> comments/suggestions about it.
>

Thanks Neil. And sorry to hear that you won't be in Singapore. This kind of
stuff is definitely more easily discussed in person (for me anyway). But
I'll try and comment on your comments here as best I can. I also plan to
also mention them in the Wednesday and/or Thursday presentation.


> Section 2 lists the main objective as being to harden against
> compromised/malicious AS or RS, which may attempt to replay captured tokens
> elsewhere. While this is a good idea, a casual reader might wonder why a
> simple audience claim in the access token/introspection response is not
> sufficient to prevent this. Because interactions between the client and RS
> are supposed to be over TLS, is the intended threat model one in which
> these protections have broken down? ("counterfeit" in the description
> suggests this). Or is the motivation that clients want to get a single
> broad-scoped access token (for usability/performance reasons) and use it to
> access multiple resource servers without giving each of them the ability to
> replay the token to the other servers? Or are we thinking of a
> phishing-type vulnerability were a general-purpose client might
> accidentally visit a malicious site which prompts for an access token that
> the client then blindly goes off and gets? (UMA?) It's not clear to me
> which of these scenarios is being considered, so it would be good to
> tighten up this section.
>

It is admittedly a bit loose and I agree it'd be good to tighten it up. But
part of why it's loose is that it tries to offer some protections for all
those scenarios and more such as a general lost/stolen token. It's
effectively trying to provide as many of the same types of
protections/assurances that you'd get with TLS based PoP mechanisms (like
OAuth MTLS or Token binding) to the extent that can be done at the HTTP
application layer. Which can't realistically be exactly the same but can
maybe be kinda close while actually being accessible and implementable
because it's all done at the application layer. There are trade-offs, of
course, and the document writers have endeavored to find a good balance in
the trade-off decisions we've made. But that doesn't mean they are
necessarily the right decisions or are closed to discussion. To the casual
reader I would say that it turns out that getting an appropriate simple
audience claim into an access token isn't nearly as simple as it might
seem. And while it will prevent RS to RS replay (as long as both RSs aren't
legit audiences) it doesn't help with preventing the use of tokens stolen
or leaked by other means (including for refresh tokens issued to public
clients).



> Another potential motivation is for mobile apps. Some customers of ours
> would like to tie access/refresh tokens to private key material generated
> on a secure element in the device, that can only be accessed after local
> biometric authentication (e.g. TouchID/FaceID on iOS). I have suggested
> using mTLS cert-bound tokens for this, but have heard some pushback due to
> the difficulty of configuring support for client certs across diverse
> infrastructure. A simple JWT-based solution like DPoP could fill this need.
>

It's maybe not stated in the draft but this kind of thing is among the
objectives (in my mind anyway).



> My main concerns with the draft though are about efficiency and
> scalability of the proposed approach:
>
> 1. The requirement to use public key signatures, along with the
> anti-replay nonce, means that the RS is required to perform an expensive
> signature verification check on every request. That is not going to scale
> up well. While there are more efficient schemes like Ed25519 now, these are
> still typically an order of magnitude slower than HMAC and the latency and
> CPU overhead is likely to be a non-starter for many APIs (especially when
> you're billed by CPU usage). Public key signatures are also notoriously
> fragile (see e.g. the history of nonce reuse/leakage vulnerabilities in
> ECDSA or
>

Yes, asymmetric is more processing intensive than symmetric. But if you
take away the distributed replay check (see next response), it will scale
out just fine. I'm not so sure latency is a real issue here - while these
operations are an order of magnitude slower we're still talking about times
that are not perceptible to a human. CPU usage/cost is a part of a
trade-off for the simplicity afforded by public/private keys.  And it is
significantly simpler. The design you sketched out is admittedly quite
clever but it's not even in the same ballpark with respect to complexity.
And, as you pointed out, the other suggestion around symmetric keys has
rather different security properties while still adding complexity. Adding
symmetric key support isn't something th