[OAUTH-WG] Re: Call for adoption - First Party Apps

[Neil Madden]

I know that apps that accept credentials directly are common place. But the direction of travel has so far been to discourage that: eg deprecating ROPC, requiring use of an external vs embedded user-agent etc. (Sorry, I misremembered: it’s BCP 212 that requires this, not the security BCP — and it has a lot of good rationale for that decision). 3rd party apps follow where first-party apps lead. — NeilOn 10 Sep 2024, at 11:14, Dick Hardt  wrote:NeilUsers input credentials directly into apps all the time in OAuth -- it is at the AS. There are many deployments that use OAuth where the AS and RS are the same party. The objective of this draft (as I understand it) is to provide a simplified OAuth flow for this use case. The BCP does not address this use case.Why would we not want to provide a best practice for deployments where the AS and RS are the same party? We will likely improve the security of those deployments over them making up their own protocol, won't we?/DickOn Tue, Sep 10, 2024 at 10:20 AM Neil Madden <neil.e.mad...@gmail.com> wrote:The draft is motivated by allowing native apps to provide a login journey for OAuth rather than using the browser. This encourages people to input credentials directly into apps, which (a) directly contradicts the advice in the security BCP, and (b) opens up users to significantly more attack vectors (including that the phishing-resistance of FIDO is significantly weakened). We shouldn’t be encouraging this. — NeilOn 5 Sep 2024, at 15:48, Tim Cappalli <tim.cappa...@okta.com> wrote:IMO, we're getting very off topic here. The WebAuthn text is not part of the draft being called for adoption.On Thu, Sep 5, 2024 at 2:15 AM Neil Madden <neil.e.mad...@gmail.com> wrote:On 5 Sep 2024, at 05:45, David Waite <da...@alkaline-solutions.com> wrote:
> 
> 
> 
>> On Sep 4, 2024, at 4:27 PM, Neil Madden <neil.e.mad...@gmail.com> wrote:
>> 
>>> On 4 Sep 2024, at 22:48, Watson Ladd <watsonbl...@gmail.com> wrote:
>>> 
>>> I can always grab the cookie jar off the user browser if I have that
>>> level of access.
>> 
>> USB access is not privileged, but that’s beside the point.
> 
>> 
>> Put another way, the phishing-resistance of WebAuthn only really makes sense in a world of sandboxed apps: web apps, mobile apps. Any spec that encourages the use of OAuth auth flows outside of such sandboxed environments, as this one potentially does, is going to make defending against phishing harder.
> 
> The client is not an identified/authenticated component in the architecture, so there is a user trust required in using a client - that the client actually is an agent acting in the user’s interest rather than acting maliciously.
> 
> Platforms have the ability to provide specific API for these interactions to become a trustworthy client, and to block privileged access (including access to speak directly to hardware) behind audited entitlements to prevent from installed software acting as a malicious client.

Right, this is what I mean by sandboxed.

> 
> Note that some platforms also provide entitlements and heuristics for password manager access - however, as a knowledge-based system the platform cannot really prevent malicious applications from still attempting to manipulate their way to credential phishing.
> 
>> 
>> (I’d also question why first-party apps need a standardised API for this anyway: they can do whatever they like using proprietary APIs already).
> 
> I would struggle to come up with standards-track RFCs which would not be able to instead be accomplished with proprietary APIs. The editors and working groups found value in peer review and in interoperability.

Standards are for promoting interoperability, not for getting free peer review of private APIs. 

> 
> I have seen the pitfalls of a proprietary approach to this and would say peer review is important. My primary concern is whether we can have a clients that authenticate against multiple implementing ASes based solely on this work. Profiling authentication methods like passkey-based authentication would go a long way toward alleviating that concern.
> 
> -DW

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - First Party Apps

[Neil Madden]

The draft is motivated by allowing native apps to provide a login journey for OAuth rather than using the browser. This encourages people to input credentials directly into apps, which (a) directly contradicts the advice in the security BCP, and (b) opens up users to significantly more attack vectors (including that the phishing-resistance of FIDO is significantly weakened). We shouldn’t be encouraging this. — NeilOn 5 Sep 2024, at 15:48, Tim Cappalli  wrote:IMO, we're getting very off topic here. The WebAuthn text is not part of the draft being called for adoption.On Thu, Sep 5, 2024 at 2:15 AM Neil Madden <neil.e.mad...@gmail.com> wrote:On 5 Sep 2024, at 05:45, David Waite <da...@alkaline-solutions.com> wrote:
> 
> 
> 
>> On Sep 4, 2024, at 4:27 PM, Neil Madden <neil.e.mad...@gmail.com> wrote:
>> 
>>> On 4 Sep 2024, at 22:48, Watson Ladd <watsonbl...@gmail.com> wrote:
>>> 
>>> I can always grab the cookie jar off the user browser if I have that
>>> level of access.
>> 
>> USB access is not privileged, but that’s beside the point.
> 
>> 
>> Put another way, the phishing-resistance of WebAuthn only really makes sense in a world of sandboxed apps: web apps, mobile apps. Any spec that encourages the use of OAuth auth flows outside of such sandboxed environments, as this one potentially does, is going to make defending against phishing harder.
> 
> The client is not an identified/authenticated component in the architecture, so there is a user trust required in using a client - that the client actually is an agent acting in the user’s interest rather than acting maliciously.
> 
> Platforms have the ability to provide specific API for these interactions to become a trustworthy client, and to block privileged access (including access to speak directly to hardware) behind audited entitlements to prevent from installed software acting as a malicious client.

Right, this is what I mean by sandboxed.

> 
> Note that some platforms also provide entitlements and heuristics for password manager access - however, as a knowledge-based system the platform cannot really prevent malicious applications from still attempting to manipulate their way to credential phishing.
> 
>> 
>> (I’d also question why first-party apps need a standardised API for this anyway: they can do whatever they like using proprietary APIs already).
> 
> I would struggle to come up with standards-track RFCs which would not be able to instead be accomplished with proprietary APIs. The editors and working groups found value in peer review and in interoperability.

Standards are for promoting interoperability, not for getting free peer review of private APIs. 

> 
> I have seen the pitfalls of a proprietary approach to this and would say peer review is important. My primary concern is whether we can have a clients that authenticate against multiple implementing ASes based solely on this work. Profiling authentication methods like passkey-based authentication would go a long way toward alleviating that concern.
> 
> -DW

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - First Party Apps

[Neil Madden]

On 5 Sep 2024, at 05:45, David Waite  wrote:
> 
> 
> 
>> On Sep 4, 2024, at 4:27 PM, Neil Madden  wrote:
>> 
>>> On 4 Sep 2024, at 22:48, Watson Ladd  wrote:
>>> 
>>> I can always grab the cookie jar off the user browser if I have that
>>> level of access.
>> 
>> USB access is not privileged, but that’s beside the point.
> 
>> 
>> Put another way, the phishing-resistance of WebAuthn only really makes sense 
>> in a world of sandboxed apps: web apps, mobile apps. Any spec that 
>> encourages the use of OAuth auth flows outside of such sandboxed 
>> environments, as this one potentially does, is going to make defending 
>> against phishing harder.
> 
> The client is not an identified/authenticated component in the architecture, 
> so there is a user trust required in using a client - that the client 
> actually is an agent acting in the user’s interest rather than acting 
> maliciously.
> 
> Platforms have the ability to provide specific API for these interactions to 
> become a trustworthy client, and to block privileged access (including access 
> to speak directly to hardware) behind audited entitlements to prevent from 
> installed software acting as a malicious client.

Right, this is what I mean by sandboxed.

> 
> Note that some platforms also provide entitlements and heuristics for 
> password manager access - however, as a knowledge-based system the platform 
> cannot really prevent malicious applications from still attempting to 
> manipulate their way to credential phishing.
> 
>> 
>> (I’d also question why first-party apps need a standardised API for this 
>> anyway: they can do whatever they like using proprietary APIs already).
> 
> I would struggle to come up with standards-track RFCs which would not be able 
> to instead be accomplished with proprietary APIs. The editors and working 
> groups found value in peer review and in interoperability.

Standards are for promoting interoperability, not for getting free peer review 
of private APIs. 

> 
> I have seen the pitfalls of a proprietary approach to this and would say peer 
> review is important. My primary concern is whether we can have a clients that 
> authenticate against multiple implementing ASes based solely on this work. 
> Profiling authentication methods like passkey-based authentication would go a 
> long way toward alleviating that concern.
> 
> -DW

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - First Party Apps

[Neil Madden]

On 4 Sep 2024, at 22:48, Watson Ladd  wrote:
> 
> On Wed, Sep 4, 2024 at 2:46 PM Neil Madden  wrote:
>> 
>> 
>> 
>> On 4 Sep 2024, at 21:31, Tim Cappalli  wrote:
>> 
>> 
>>> 
>>> Thanks, that’s good to know. Does it preserve phishing resistance? Ie the 
>>> app cannot spoof the rpId?
>> 
>> 
>> The WebAuthn client for native apps is the app platform. The app platform, 
>> aka the OS, handles origin binding using existing app to web domain 
>> association methods (Android Asset Links, Apple Associated Domains) . This 
>> is used for both embedded WebViews and native app platform APIs. For System 
>> WebView, the WebAuthn client is the web platform, just like a browser 
>> (WebView details: Android, iOS, macOS).
>> 
>> 
>> I can see how that works for iOS and Android, where apps are sandboxed. But 
>> can’t a macos/Windows/Linux app bypass the “official” WebAuthn API and just 
>> talk CTAP directly to a USB authenticator? (You used to even be able to do 
>> this from the browser: 
>> https://www.yubico.com/support/security-advisories/ysa-2018-02/).
>> 
>> Or is the intent to limit the spec to sandboxed apps? (If so, some kind of 
>> attestation to ensure the app actually is sandboxed seems a good idea).
> 
> I can always grab the cookie jar off the user browser if I have that
> level of access.

USB access is not privileged, but that’s beside the point. 

Put another way, the phishing-resistance of WebAuthn only really makes sense in 
a world of sandboxed apps: web apps, mobile apps. Any spec that encourages the 
use of OAuth auth flows outside of such sandboxed environments, as this one 
potentially does, is going to make defending against phishing harder. 

(I’d also question why first-party apps need a standardised API for this 
anyway: they can do whatever they like using proprietary APIs already). 

— Neil

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: WGLC for SD-JWT

[Neil Madden]

I haven’t read the latest draft in a lot of detail, but I did check over the 
cryptographic details again and everything seems reasonable to me.

One error I noticed in section 5.2.4.1:

"For example, using the digest of the object property Disclosure created above, 
the Issuer could create the following SD-JWT payload to make given_name 
selectively disclosable”

I believe this should say “family_name”, as that is what is in the disclosure 
hash (the given_name is represented directly in the claims).

(Also, where it references “the Disclosure claim created above”, it should 
probably explicitly say “in section 5.2.3”, but even that is still a bit 
confusing as there are two disclosures created in that section and neither 
lists the actual content of the disclosure being hashed).

Other than that, it looks in good shape.

— Neil

> On 3 Sep 2024, at 11:39, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> As per the discussion in Vancouver, this is a WG Last Call for the SD-JWT 
> document.
> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-11.html
>  
> 
> 
> Please, review this document and reply on the mailing list if you have any 
> comments or concerns, by Sep 17th.
> 
> Regards,
>   Rifaat & Hannes
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - First Party Apps

[Neil Madden]

I am a bit skeptical about this one. I’m not convinced we should be 
recommending native UI until/unless we have a really good story around 
authenticating first-party apps. Without such a story, I don’t think this 
should be adopted. Unless I’m mistaken, a native UI also rules out 
WebAuthn/FIDO-based authenticators? We should not be adopting drafts that 
increase phishing risks for the sake of aesthetics.

— Neil

> On 3 Sep 2024, at 11:46, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> As per the discussion in Vancouver, this is a call for adoption for the First 
> Party Apps draft:
> https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/ 
> 
> 
> Please, reply on the mailing list and let us know if you are in favor or 
> against adopting this draft as WG document, by Sep 17th.
> 
> Regards, 
>  Rifaat & Hannes
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Neil Madden]

I support adoption.

> On 3 Sep 2024, at 11:47, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> As per the discussion in Vancouver, this is a call for adoption for the Proof 
> of Issuer Key Authority (PIKA) draft:
> https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/ 
> 
> 
> Please, reply on the mailing list and let us know if you are in favor or 
> against adopting this draft as WG document, by Sep 17th.
> 
> Regards, 
>  Rifaat & Hannes
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Security Bug | Unintended usage of "state" parameter can lead to Header Injection Attacks

[Neil Madden]

On 1 Jul 2024, at 14:31, Chaitanya Reddy  wrote:
> 
> Hi Neil and Filip,
> 
> Thank you so much for the quick revert.
> 
> Neil, in the last statement you mentioned "I would say in this case the onus 
> falls on the client to validate the state value before blindly copying it 
> into the Location header." since the state can contain anything in it.  Yes, 
> I do agree that the client should be the one validating the state. I already 
> informed them of the same. 
> But when i found that another client is vulnerable to open redirection due to 
> this, I realised that instead of multiple clients validating the state value, 
> wouldn't it be better if the Authorization server does this? One fix from 
> google and all the vulnerable clients would already be free from this 
> vulnerability. 

That would be nice, but it would almost certainly be a breaking change from 
Google’s point of view. I’m not really sure how Google *could* validate this in 
any sensible way.

— Neil___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Security Bug | Unintended usage of "state" parameter can lead to Header Injection Attacks

[Neil Madden]

Section 3.1.2.2 of RFC 6749 says:


   The authorization server SHOULD require the client to provide the
   complete redirection URI (the client MAY use the "state" request
   parameter to achieve per-request customization)

So I’d say it is allowed to use the state parameter to hold a URI to redirect 
to after the flow completes. But note also the requirement in section 10.14:


   The authorization server and client MUST sanitize (and validate when
   possible) any value received -- in particular, the value of the
   "state" and "redirect_uri" parameters.

Given that there is almost no restriction on what “state” can contain, I would 
say in this case the onus falls on the client to validate the state value 
before blindly copying it into the Location header. It sounds like those 
clients have an open redirect vulnerability and need to implement some kind of 
allow-list of acceptable URIs.

— Neil

> On 1 Jul 2024, at 05:50, Chaitanya Reddy  
> wrote:
> 
> Hi Team,
> 
> Hope you are doing well!
> 
> I am writing this mail regarding the discussion of usage of state parameter 
> in the OAuth implementation.
> 
> As per the RFC 6749, "An opaque value is used by the client to maintain state 
> between the request and callback. And it should be used to prevent cross-site 
> request forgery". Since it's an opaque value, OAuth implementors usually 
> don't sanitize the value.
> 
> One of the OAuth 2.0 implementors (Google) have defined state as "You can use 
> this parameter for several purposes, such as directing the user to the 
> correct resource in your application, sending nonces, and mitigating 
> cross-site request forgery"
> 
> The issue arries here due to the fact that Google allows the use of state 
> parameter for directing the users to the correct resource. Since the value in 
> RFC is defined as opaque, they are not sanitizing the value for any possible 
> malicious values. I have observed two instances where clients using Google's 
> OAuth service directly use the state parameter value in Location header to 
> redirect the users hence resulting in header injection attacks.
> 
> As per my understanding, this issue arises due to the fact that:
> 1. Google allows state parameter to be used for purpose not defined in RFC.
> 2. Google is not sanitizing the state paramater on their end.
> 3. Client is also not sanitizing the state paramater and directly using it in 
> the Location header.
> 
> I have raised this issue to google via google VRP but after weeks of 
> communication over the ticket, the engineer feels like they are not in 
> disagreement with the spec and have requested me to discuss it further with 
> your team and hence i am reaching out to you.
> 
> Please let me know your thoughts about this.
> 
> Regards,
> Chaitanya Reddy
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: One-time confirmation tokens

[Neil Madden]

On 14 Jun 2024, at 02:48, Dmitry Telegin 
 wrote:
> 
> Let's take the following (very common) scenario:
> * A user logs into the system;
> * They request an operation that might require additional confirmation from 
> the user, at the system's discretion. The most common example would be 
> payment / money transfer, but could also be generating a statement or showing 
> card details or any other sensitive operation;
> * The user is then directed to the AS where they are displayed operation 
> details, optionally pass additional authentication and confirm the operation;
> * The AS issues a one-time credential (let's call it "confirmation token") 
> that can be used to perform that particular operation only;
> * Finally, the user performs the operation.
> 
> Is this case completely covered by the current standards? I believe it is 
> not, and here are my points:
> 1. "Confirmation token" looks very different from access token with regards 
> to its contents, purpose, scope, lifetime and lifecycle. I think it should 
> complement the access token rather than replace it, even temporarily. This is 
> why I believe this case is not covered by Step Up, where the access token is 
> replaced;
>   1a. Step Up assumes upgrading the session's ACR; in the "confirmation" 
> scenario, ACR could remain unchanged;
> 2. No standard way for the RS to signal to the client that the requested 
> operation requires confirmation. That could optionally include 
> server-supplied nonce (similar to DPoP) to help enforce "confirmation 
> token"'s shorter lifetime and one-time use, but it is not clear how to 
> communicate that to the client;
> 3. No standard way for the client to request one-time "confirmation token" 
> from the AS;
> 4. No standard way for the AS to indicate that the returned token is actually 
> "confirmation token" and not a Bearer token;
> 5. No standard way for the RS to tell that the incoming token is actually a 
> "confirmation token" and requires special handling (one-time use, checking 
> against operation parameters etc.)
> 6. On a plus side, RAR can be used to communicate operation details to the AS 
> while initiating "confirmation".
> 
> 3-5 could be probably done with a combination of scopes + RAR. What concerns 
> me most is the lack of complementary token semantics (1) and inability for 
> the RS to signal the confirmation requirement to the client (2), which could 
> include operation details and nonce.
> 
> Please correct me if I'm missing something and we have enough coverage by the 
> standards. But if we don't, would the WG welcome such a document?

You may be interested in my blog post about exactly this topic: 
https://neilmadden.blog/2020/09/09/macaroon-access-tokens-for-oauth-part-2-transactional-auth/
 


However, I think the ship has pretty much sailed on this topic and the world 
(Open Banking etc) has gone with just using RAR for each transaction and 
glossing over the points you make.

— Neil

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Neil Madden]

> On 10 May 2024, at 17:07, Sam Goto  wrote:
> 
> On Fri, May 10, 2024 at 2:41 AM Neil Madden  <mailto:neil.e.mad...@gmail.com>> wrote:
> On 9 May 2024, at 21:58, Watson Ladd  <mailto:watsonbl...@gmail.com>> wrote:
> > 
> > On Thu, May 9, 2024 at 7:24 AM Neil Madden  > <mailto:neil.e.mad...@gmail.com>> wrote:
> >> 
> >> On 9 May 2024, at 00:06, Sam Goto  >> <mailto:g...@google.com>> wrote:
> >> 
> >> [...]
> >>> 
> >>> 
> >>> I guess, flipping this around, we might ask what is the legitimate 
> >>> purpose for which browsers need to access the user’s name, email address 
> >>> (both requires) and other identifying information? I’d have thought an 
> >>> identifier (possibly randomised) and some user-supplied account nickname 
> >>> would be sufficient.
> >> 
> >> 
> >> That's easier to answer: the browser needs name/email/picture to construct 
> >> an account chooser, which is the UX that tested best with users by a far 
> >> margin.
> >> 
> >> Static/unpersonalized permission prompts - example in Safari, example in 
> >> Chrome - perform extremely poorly (in comparison to account choosers), 
> >> although have other benefits too (namely ergonomics and extensibility), so 
> >> Chrome (and others) expose that too in the form of the Storage Access API.
> >> 
> >> 
> >> 
> >> Yeah, that's what I suspected. Did you do research that specifically 
> >> called out email addresses as a must-have?
> > 
> > I'm sort of mystified here by the objection.
> > 
> > What exactly is the alternative where the user agent doesn't have
> > access to all of the data passing through it?
> 
> With auth code flow the data doesn't pass through the user agent at all. With 
> encrypted ID tokens it does, but is not accessible to the UA.
> 
> Neil, just checking, but is it clear to you that the UA doesn't make an 
> imposition on what's passed back to the RP (e.g. ID tokens vs access tokens)? 
> An IdP can return whatever it wants back to RP in the id assertion endpoint 
> <https://fedidcg.github.io/FedCM/#idp-api-id-assertion-endpoint> as a string 
> <https://fedidcg.github.io/FedCM/#dom-identitycredential-token>  (e.g. a 
> Base64 encoded JWT, an access token, a binary blob, a JPEG image, an mp3 
> file, etc), which doesn't get introspected by the UA.
> 
> The only data that does get instrospected by the UA is the result of the 
> accounts endpoint 
> <https://fedidcg.github.io/FedCM/#idp-api-accounts-endpoint>, which is used 
> to construct an account chooser.
>  
> I was assuming we were having a discussion around the accounts endpoint, not 
> the id assertion endpoint.

Yes, that's correct. The accounts endpoint mandates that the IDP expose PII to 
the UA that otherwise needn't be. If you use the auth code flow, other than 
what the user provides to authenticate (under their control), no identity 
information at all is exposed to the user agent. 

(I appreciate such PII _often_ will be exposed by the IDP UI anyway, but it is 
a significant change to make it mandatory).

> 
> > In particular user
> > emails are everywhere in the User Agent. It's in the autofill
> > settings, the webmail interface, every signup form filled out etc,
> > etc.
> 
> Many OAuth flows are not OIDC. There's no guarantee that the AS even has 
> access to any identity information beyond a username.
> 
> > 
> > To be absolutely clear today the information generally appears in big
> > bold text to confirm the user wants to pass it to the RP, and those
> > letters are made to appear on screen through a process the User Agent
> > is very involved in. It also got typed in by the user (or autofilled
> > by the user agent) when signing into the IdPs. Usually there are UI
> > ways to confirm what account you are signed into that depend on
> > similar APIs. And everything the user does is done through the User
> > Agent. Is there some exotic setup that I'm ignoring here?
> > 
> > I'm just very confused as to why this is a problem.
> 
> There's a lot of background assumptions there -- do we want to bake those 
> into the web for all eternity? Yes, email addresses are passed around like 
> candy on the web currently, but I don't think that is a good thing.
> 
> 
> Yeah, I'm in agreement with that. 
> 
> I think the "MUST use email" emphasis on Neil's original point is the key one 
> to me: I am convinced 

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Neil Madden]

On 9 May 2024, at 21:58, Watson Ladd  wrote:
> 
> On Thu, May 9, 2024 at 7:24 AM Neil Madden  wrote:
>> 
>> On 9 May 2024, at 00:06, Sam Goto  wrote:
>> 
>> [...]
>>> 
>>> 
>>> I guess, flipping this around, we might ask what is the legitimate purpose 
>>> for which browsers need to access the user’s name, email address (both 
>>> requires) and other identifying information? I’d have thought an identifier 
>>> (possibly randomised) and some user-supplied account nickname would be 
>>> sufficient.
>> 
>> 
>> That's easier to answer: the browser needs name/email/picture to construct 
>> an account chooser, which is the UX that tested best with users by a far 
>> margin.
>> 
>> Static/unpersonalized permission prompts - example in Safari, example in 
>> Chrome - perform extremely poorly (in comparison to account choosers), 
>> although have other benefits too (namely ergonomics and extensibility), so 
>> Chrome (and others) expose that too in the form of the Storage Access API.
>> 
>> 
>> 
>> Yeah, that's what I suspected. Did you do research that specifically called 
>> out email addresses as a must-have?
> 
> I'm sort of mystified here by the objection.
> 
> What exactly is the alternative where the user agent doesn't have
> access to all of the data passing through it?

With auth code flow the data doesn't pass through the user agent at all. With 
encrypted ID tokens it does, but is not accessible to the UA.

> In particular user
> emails are everywhere in the User Agent. It's in the autofill
> settings, the webmail interface, every signup form filled out etc,
> etc.

Many OAuth flows are not OIDC. There's no guarantee that the AS even has access 
to any identity information beyond a username.

> 
> To be absolutely clear today the information generally appears in big
> bold text to confirm the user wants to pass it to the RP, and those
> letters are made to appear on screen through a process the User Agent
> is very involved in. It also got typed in by the user (or autofilled
> by the user agent) when signing into the IdPs. Usually there are UI
> ways to confirm what account you are signed into that depend on
> similar APIs. And everything the user does is done through the User
> Agent. Is there some exotic setup that I'm ignoring here?
> 
> I'm just very confused as to why this is a problem.

There's a lot of background assumptions there -- do we want to bake those into 
the web for all eternity? Yes, email addresses are passed around like candy on 
the web currently, but I don't think that is a good thing.

As for how this could be an issue, imagine you are giving a presentation/demo 
at work and you go to login to a website (not uncommon) and up pops a box 
asking if you want to login with your xyz.example account (pornhub, grindr, 
whatever) -- revealing some sensitive or embarassing information about you, 
such as your sexual orientation. The idea that it is a perfectly neutral and 
acceptable thing for the browser to make background requests *prior to* consent 
that pull in personal info from all kinds of sources is deeply suspect IMO.

-- Neil
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Neil Madden]

On 9 May 2024, at 00:06, Sam Goto  wrote:
> [...]
> 
> I guess, flipping this around, we might ask what is the legitimate purpose 
> for which browsers need to access the user’s name, email address (both 
> requires) and other identifying information? I’d have thought an identifier 
> (possibly randomised) and some user-supplied account nickname would be 
> sufficient.
> 
> That's easier to answer: the browser needs name/email/picture to construct an 
> account chooser 
> ,
>  which is the UX that tested best with users by a far margin. 
> 
> Static/unpersonalized permission prompts - example 
>  in 
> Safari, example 
> 
>  in Chrome - perform extremely poorly (in comparison to account choosers), 
> although have other benefits too (namely ergonomics and extensibility), so 
> Chrome (and others) expose that too in the form of the Storage Access API 
> .
>  

Yeah, that's what I suspected. Did you do research that specifically called out 
email addresses as a must-have?

PS - although this is an OAuth group, you may also want to look at things like 
Dropbox's Chooser/Saver widgets (https://www.dropbox.com/developers/chooser 
), which provide fine-grained 
permissions to access specific files/folders using a file dialog UX rather than 
a redirect-based flow. I appreciate that may not be your initial focus, but one 
for the "mood board" as it were...

-- Neil___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Neil Madden]

On 8 May 2024, at 22:01, Joseph Heenan  wrote:On 8 May 2024, at 21:43, Sam Goto  wrote:On Wed, May 8, 2024 at 1:34 PM Joseph Heenan <jos...@authlete.com> wrote:Hi NeilOn 8 May 2024, at 18:45, Neil Madden <neil.e.mad...@gmail.com> wrote:On 8 May 2024, at 17:52, Sam Goto <g...@google.com> wrote:On Wed, May 8, 2024 at 7:23 AM Neil Madden <neil.e.mad...@gmail.com> wrote: In particular, the call to the accounts endpoint assumes that the IdP is willing to provide PII about the user to the browser. That seems questionable. Aside from a privacy/security threat model perspective (meaning, the user agent already has visibility over every network request made available to the content area)Sure, but if I use the recommended auth code flow or encrypted ID tokens, then PII is not exposed to the browser. And it’s not just the browser itself in the current proposal, as the token is exposed to _javascript_, of course, so the usual XSS risks. Sam’s response here is fair, but also note that as far as I understand it you can still use the authorization code flow or encrypted id tokens with the FedCM API That's correct: the browser doesn't open the response from the IdP to the RP, so it can, for example, be encrypted.I was assuming that Neil was referring to the fact that the id_assertion_endpoint (which contains the user's IdP's PII accounts) become, suddenly, transparent to the browser.Oh yes, that’s true - but (I think) the data from the id_assertion_endpoint at least isn’t exposed to _javascript_ and isn’t vulnerable to XSS?That depends on whether the IdP correctly enforces the presence of the sec-fetch-dest header. If it doesn’t then yes, it would be vulnerable. Presumably it’s also vulnerable on older/niche browsers that don’t block sec-* headers: caniuse.com reckons > 8% of users globally are using browsers that don’t understand any sec-fetch-* headers. I’m not sure when sec-* was added to the forbidden list.I guess, flipping this around, we might ask what is the legitimate purpose for which browsers need to access the user’s name, email address (both requires) and other identifying information? I’d have thought an identifier (possibly randomised) and some user-supplied account nickname would be sufficient.— Neil___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Neil Madden]

On 8 May 2024, at 21:39, Sam Goto  wrote:On Wed, May 8, 2024 at 1:26 PM Neil Madden <neil.e.mad...@gmail.com> wrote:Looking at these slides again, and at the spec, does this even work to defeat tracking? The browser makes two requests to the IdP prior to getting consent from the user:1. To lookup the accounts of the user (identifying the user)2. To lookup the metadata of the client (identifying the RP). Isn’t it rather trivial for a tracker posing as an IDP to correlate these two requests? The privacy considerations talk about IP addresses and timing ways to correlateThe timing attack is the one that we think we are most vulnerable to at this layer, but we know how to (a) detect it and (b) address it (e.g. by introducing UX friction).IP addresses are also a problem, but we think it will be best addressed at a different layer: For example, in Chrome:https://developers.google.com/privacy-sandbox/protections/ip-protection and Safari:https://support.apple.com/en-gb/guide/iphone/iph499d287c2/17.0/ios/17.0In both cases the TLS connection is end to end, so I guess all user agents need to setup and teardown two independent connections? And make sure the IdP/tracker doesn’t encode tracking information into session resumption tickets?As a user of the Safari method, I also know that I have to turn it off surprisingly frequently. (And some people deliberately turn it off).  , but there are plenty of others.Outside of the timing attack and IP masking, can you expand on what else an attacker could use to track the users?Does this assume that the tracker is trying to track a lot of people at once? Obviously, in the limit, if only a single person pings the endpoints at a certain time then it is obvious that those requests are related. How many near-simultaneous pings of a tracker do you need to ensure a sufficient level of non-correlation? For n simultaneous users the tracker needs to smuggle through log2(n) bits of entropy to be able to precisely correlate the two requests. Another method I can think of is that the tracker responds to the request for the /config endpoint with randomised /accounts and /client-metadata endpoints, such that it can correlate the two calls to those endpoints. Maybe browsers should fetch it multiple times from different IP addresses, geographically distributed?I’m sure I can come up with other methods. Browsers are working towards removing every bit of entropy that can be used for fingerprinting, so I'm curious if anything occurred to you that isn't being actively worked on. For example:https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
— Neil___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Neil Madden]

Looking at these slides again, and at the spec, does this even work to defeat tracking? The browser makes two requests to the IdP prior to getting consent from the user:1. To lookup the accounts of the user (identifying the user)2. To lookup the metadata of the client (identifying the RP). Isn’t it rather trivial for a tracker posing as an IDP to correlate these two requests? The privacy considerations talk about IP addresses and timing ways to correlate, but there are plenty of others.— NeilOn 8 May 2024, at 13:34, Rifaat Shekh-Yusef  wrote:Attached is the slide deck presented during this meeting.The following is a link to the meeting video recording:https://www.youtube.com/watch?v=cngVbSkEYL8Regards, RifaatOn Thu, Apr 25, 2024 at 1:01 PM Rifaat Shekh-Yusef  wrote:








  
  
  
  
  

  

  








  OAuth WG Virtual Interim - FedCMThe Web Authorization Protocol (oauth) WG will hold a virtual interim meetingon 2024-05-07 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).Agenda:FedCM update and discussionhttps://fedidcg.gi   The Web Authorization Protocol (oauth) WG will hold a virtual interim meetingon 2024-05-07 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).Agenda:FedCM update and discussionhttps://fedidcg.github.io/FedCM/Information about remote participation:https://meetings.conf.meetecho.com/interim/?group=06583774-aede-401e-aa29-4ed8f23365b8--A calendar subscription for all oauth meetings is available athttps://datatracker.ietf.org/meeting/upcoming.ics?show=oauthWhenTuesday May 7, 2024 ⋅ 12pm – 1pm (Eastern Time - Toronto)GuestsRifaat Shekh-Yusef - organizeroauth@ietf.orgView all guest infoReply for oauth@ietf.orgYesNoMaybeMore optionsInvitation from Google CalendarYou are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event.Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___OAuth mailing list -- oauth@ietf.orgTo unsubscribe send an email to oauth-le...@ietf.org___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Neil Madden]

On 8 May 2024, at 17:52, Sam Goto  wrote:On Wed, May 8, 2024 at 7:23 AM Neil Madden <neil.e.mad...@gmail.com> wrote:Thanks for these slides and recording. This is a fascinating proposal. I have plenty of potential thoughts and comments to digest, but I guess the most fundamental is that this spec assumes that users and IdPs will be happy for their browser to be a trusted party involved in login flows. Yep, that is, indeed, the privacy and security threat model that we (FedCM specifically, Web Platforms API in general) use: the user agent is a trusted party.I’m sure browser developers do of course view their own products as trustworthy, but not everyone does. Episodes like [1] do provoke some distrust. Especially in corporate environments where users are forced to use a particular user-agent (and may be subject to mitm proxies), this may not be a universally accepted threat model. [1]: https://www.theverge.com/2023/4/25/23697532/microsoft-edge-browser-url-leak-bing-privacy In particular, the call to the accounts endpoint assumes that the IdP is willing to provide PII about the user to the browser. That seems questionable. Aside from a privacy/security threat model perspective (meaning, the user agent already has visibility over every network request made available to the content area)Sure, but if I use the recommended auth code flow or encrypted ID tokens, then PII is not exposed to the browser. And it’s not just the browser itself in the current proposal, as the token is exposed to _javascript_, of course, so the usual XSS risks. , I think that, if you look through the lenses of the design of incentives, this is indeed something that we are still gathering validation. So far, it seems to strike a good balance, but I think you are right in that this introduces an extra game theoretical position that can be questioned.I guess a related question is whether browser vendors are intending for this to become the only game in town for cross-site authentication? If not then those with differing threat models can use other mechanisms. But if the plan is to eventually completely block all other federation protocols then it needs to work for all use cases.  This endpoint also has no CSRF protection, so risks leaking PII more generally (eg to any origin that has been CORS-allowlisted).As far as CSRF goes, we expose a Sec-Fetch-Dest HTTP request, which is a forbidden request header (meaning that it can't be polyfilled in userland).https://fedidcg.github.io/FedCM/#sec-fetch-dest-headerOk, that is good. But it feels like something that IdPs could easily forget to enforce. In general, being one missed security header check away from a PII data leak seems not a fun place to be for an IdP. As another general comment, I'd say that if you want this to be easy for RPs to apply to existing login flows then it needs to be something that is easy to configure/initiate via a reverse proxy. That would suggest HTTP header-based rather than a JS API in my opinion.Yep, that sounds reasonable to me. For the most part, we think of JS APIs and HTTP request are largely isomorphic in the important parts (again, privacy/security wise), and we can expose either/both purely based on ergonomics (as you suggest), so yeah, if this makes it easier for developers, it is easy to make it happen, I think.
— Neil___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Neil Madden]

Thanks for these slides and recording. This is a fascinating proposal. I have 
plenty of potential thoughts and comments to digest, but I guess the most 
fundamental is that this spec assumes that users and IdPs will be happy for 
their browser to be a trusted party involved in login flows. In particular, the 
call to the accounts endpoint assumes that the IdP is willing to provide PII 
about the user to the browser. That seems questionable. This endpoint also has 
no CSRF protection, so risks leaking PII more generally (eg to any origin that 
has been CORS-allowlisted).

As another general comment, I'd say that if you want this to be easy for RPs to 
apply to existing login flows then it needs to be something that is easy to 
configure/initiate via a reverse proxy. That would suggest HTTP header-based 
rather than a JS API in my opinion.

-- Neil

> On 8 May 2024, at 13:33, Rifaat Shekh-Yusef  wrote:
> 
> Attached is the slide deck presented during this meeting.
> 
> The following is a link to the meeting video recording:
> https://www.youtube.com/watch?v=cngVbSkEYL8 
> 
> 
> Regards,
>  Rifaat
> 
> 
> On Thu, Apr 25, 2024 at 1:01 PM Rifaat Shekh-Yusef  > wrote:
>  
> The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting
> on 2024-05-07 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).
> 
> Agenda:
> FedCM update and discussion
> https://fedidcg.github.io/FedCM/
> 
> Information about remote participation:
> https://meetings.conf.meetecho.com/interim/?group=06583774-aede-401e-aa29-4ed8f23365b8
> 
> 
> 
> --
> A calendar subscription for all oauth meetings is available at
> https://datatracker.ietf.org/meeting/upcoming.ics?show=oauth
> When
> Tuesday May 7, 2024 ⋅ 12pm – 1pm (Eastern Time - Toronto)
> Guests
> Rifaat Shekh-Yusef - organizer
> oauth@ietf.org
> View all guest info
> Reply for oauth@ietf.org
> Yes
> No
> Maybe
>  
> More options
> Invitation from Google Calendar
> 
> You are receiving this email because you are an attendee on the event. To 
> stop receiving future updates for this event, decline this event.
> 
> Forwarding this invitation could allow any recipient to send a response to 
> the organizer, be added to the guest list, invite others regardless of their 
> own invitation status, or modify your RSVP. Learn more
> 
>  
>  
> The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting
> on 2024-05-07 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).
> 
> Agenda:
> FedCM update and discussion
> https://fedidcg.github.io/FedCM/ 
> 
> 
> Information about remote participation:
> https://meetings.conf.meetecho.com/interim/?group=06583774-aede-401e-aa29-4ed8f23365b8
>  
> 
> 
> 
> 
> --
> A calendar subscription for all oauth meetings is available at
> https://datatracker.ietf.org/meeting/upcoming.ics?show=oauth 
> 
> When
> Tuesday May 7, 2024 ⋅ 12pm – 1pm (Eastern Time - Toronto)
> Guests
> Rifaat Shekh-Yusef  - organizer
> oauth@ietf.org View all guest info 
> 
> Reply for oauth@ietf.org 
> Yes
>  
> 
>   No
>  
> 
>   Maybe
>  
> 
> More options
>  
> 
> Invitation fr

Re: [OAUTH-WG] Signed JWK Sets

[Neil Madden]

I’m not sure this is an official call for adoption, but I support this draft. Regardless of the discussion in the other thread, I think this draft has clear value and is well designed. A couple of thoughts:Presumably it is infeasible for a client to construct a TLS transcript that looks like a valid JWK Set? Ie because we are reusing the TLS cert signing key, I want to check that this doesn’t open up an issue where an attacker interacting with TLS can trick the server into signing a PIKA of their choosing. I’d like to see a security analysis of that. Are there privacy advantages to using PIKA? It seems like clients not all calling back to the OP to retrieve verification keys would also prevent some tracking? If so, that seems like a good positive to add to the draft. Best wishes,NeilOn 9 Apr 2024, at 20:33, Richard Barnes  wrote:Hi all,Thanks for all the feedback on-list and at IETF 119.  Sharon and I took a second pass at this idea and actually made an Internet-Draft this time:https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/The new draft is focused on "Proofs of Issuer Key Authority".  This new framing is based on a couple of important bits of feedback from Mike Jones, (1) that OpenID Federation had already defined most of what we need, and (2) that it would help to be clear that the real focus here was on replacing HTTPS with JWT as the proof that a key is authoritative for a given issuer.  Given that, we reuse the "historical JWK set" format from OpenID Federation, and of course, focus on the "key authority" issue.Obviously, more feedback is welcome, but especially on whether this would be a good thing for the OAuth WG to work on.Thanks,--RichardOn Sun, Mar 17, 2024 at 1:55 AM Richard Barnes  wrote:Hi all,A few of us have been considering use cases for JWTs related to Verifiable Credentials and container signing, which require better "proof of authority" for JWT signing keys.  Sharon Goldberg and I wrote up a quick specification for how to sign a JWK set, and how you might extend discovery mechanisms to present such a signed JWK set:https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md(Just in GitHub for now; will publish as an I-D when the window reopens tomorrow.)If we could get this functionality added to OAuth / OIDC, it would make these use cases work a lot better.  As a prelude toward proposing working group adoption, it would be great to know if this design seems helpful to other folks as well.  Obviously, happy to answer any questions / comments.Thanks,--Richard

___OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Neil Madden]

> On 12 Apr 2024, at 03:16, Ethan Heilman  wrote:
> 
> 
> Hi Neil,
> 
> I agree that PIKA would not protect against an attacker compromising a JWKS 
> URI via a mis-issued TLS cert.
> 
> I was thinking of a simpler attack where the attacker compromises the server 
> where a JWKS URI is hosted or the JWKS is stored. For instance consider an 
> JWKS which is read from a database. An attacker could use a SQL injection to 
> add their own key to the JWKS. Because such an attacker does not compromise 
> any TLS certificates PIKA would defeat this attack (assuming the verifier 
> required PIKA for that JWT issuer).

It depends how the PIKA is created. If you mean that the database stores the 
signed PIKA, then yes that would prevent the attack. But if the database just 
stores the keys and another process periodically extracts them and signs them 
to create the PIKA (which seems more likely to me), then the attack still 
succeeds. 

> 
> Today, write access to a JWKS is sufficient to comprise the signing authority 
> of a JWT issuer. With PIKA write access to a JWKS may not be sufficient to 
> compromise the signing authority of a JWT issuer.

I’m not sure this is true in many cases. Doesn’t PIKA essentially assume that 
the TLS cert signing key is accessible to whatever process creates the JWK Set? 
So if you have write access to the JWK Set, you often will also have access to 
that private key - either directly, or via some API/HSM call. Not always, but I 
think in many scenarios. 

— Neil

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

Re: [OAUTH-WG] Signed JWK Sets

[Neil Madden]

On 11 Apr 2024, at 01:12, Ethan Heilman  wrote:
> 
> I want to voice my support for this draft: Proof of Issuer Key Authority 
> (PIKA). The ability to reason about the past validity of JWKS is extremely 
> useful for using OIDC in signing CI artifacts and e2e encrypted 
> messaging.This includes what we are building at OpenPubkey 
> (github.com/openpubkey/openpubkey ) 
> and also proposed security improvements to software supply chain systems like 
> SigStore (https://arxiv.org/pdf/2307.08201.pdf 
> ).
> 
> I want to underscore the value of PIKA to increase the security of JWKS URIs 
> and OpenID Connect. Currently if an attacker compromises an OpenID Provider's 
> JWKS URI the attackers can substitute their own public keys and impersonate 
> any user to any relying parties who depend that OpenID Provider. The effects 
> of Google, Microsoft or Okta's JWKS URI being controlled by a malicious party 
> for even a few minutes could be devastating. The widespread deployment of 
> PIKA would remove this risk and require that attackers compromise not only 
> the JWKS URI but also the PIKA signing keys.

I'm still digesting this draft, and generally supportive of it. However, I 
don't think it stops the attack you mention here, which sounds similar to 
threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the 
current OIDC model, an attacker that briefly compromises the jwks_uri of an OP 
(e.g. through a mis-issued TLS cert) can serve a JWK Set containing public keys 
under their own control with a long Cache-Control header. Clients then might 
blindly cache that key set even beyond the time when the certificate is revoked 
and the rightful owner restored.

But I think this attack is basically the same even with PIKA. The attacker in 
this case just uses their mis-issued cert to sign the PIKA and serve that 
instead, perhaps putting a really long "exp" claim in it so that clients cache 
it for a really long time. The only thing that would stop that is if the draft 
insisted that clients regularly perform an OCSP or CRL lookup on the cert in 
the x5c chain to make sure it hasn't been revoked. But that would completely 
negate the benefits of avoiding clients all hitting the OP jwks_uri: we've just 
shifted the burden from the OP to the CA.

Perhaps I'm missing something?

[1]: 
https://docs.google.com/document/u/1/d/e/2PACX-1vQQ-FhNjW0ZhZVTnK1VG_87IBNZKBaJmweYZb1VBRdQCMAWXekqKfxdNl8wL6FWFDJ9pxXxpr66-GZp/pub?utm_source=illuminatedsecurity&utm_medium=email
 

 

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

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Neil Madden]

That section quite clearly says "*access tokens* with identical or narrower 
scope". Not refresh tokens.

-- Neil

> On 21 Feb 2024, at 08:24, Sachin Mamoru  wrote:
> 
> Hi Warren and Neil,
> 
> My basis for asking this is due to the following definition [1],
> 
> Refresh tokens are credentials used to obtain access tokens.  Refresh
>tokens are issued to the client by the authorization server and are
>used to obtain a new access token when the current access token
>becomes invalid or expires, or to obtain additional access tokens
>with identical or narrower scope (access tokens may have a shorter
>lifetime and fewer permissions than authorized by the resource
>owner).  Issuing a refresh token is optional at the discretion of the
>authorization server.  If the authorization server issues a refresh
>token, it is included when issuing an access token (i.e., step (D) in
>Figure 1).
> 
> [1] https://datatracker.ietf.org/doc/html/rfc6749#section-1.5 
> <https://datatracker.ietf.org/doc/html/rfc6749#section-1.5>
> 
> Thanks & Regards,
> Sachin
> 
> On Wed, 21 Feb 2024 at 13:36, Sachin Mamoru  <mailto:sachinmam...@gmail.com>> wrote:
> Hi Warren and Neil,
> 
> Thanks for the valuable input and sorry for mentioning other products, I just 
> wanted to provide an example. 
> So Warren according to you following is the behaviour that spec suggested.
> 
> When we request an access token using 3 scopes (scope1, scope2, scope3).
> 
> Then will receive a refresh token (refresh_token1) with the access token.
> 
> After that will request another access token with refresh_token1 and provide 
> the scope list as scope1 and scope2 (Narrow down scopes).
> 
> Similarly, get another refresh token (refresh_token2) with the access token.
> 
> Now if we request another access token with refresh_token2, we should be able 
> to request scope3 also.
> That means the refresh token will not be narrowed down instead only the 
> access token will get narrowed down.
> 
> So Warren and Neil, if possible can you pinpoint to me the exact place in the 
> spec where it does explicitly say that the refresh token should not be 
> narrowed down based on the given scopes?
> 
> Thanks & Regards,
> Sachin
> 
> On Wed, 21 Feb 2024 at 01:12, Neil Madden  <mailto:neil.e.mad...@gmail.com>> wrote:
> It sounds like they are violating the spec then. On the other hand, the fact 
> that the scope can be "increased back to the original scope" maybe suggests 
> the effective scope of the refresh token is still the same? Either way, the 
> spec is pretty clear, regardless of what some vendor does.
> 
> -- Neil
> 
>> On 20 Feb 2024, at 19:26, Sachin Mamoru > <mailto:sachinmam...@gmail.com>> wrote:
>> 
>> Hi Neil,
>> 
>> Thanks for the clarification.
>> But Curity has a different approach and they implemented it according to the 
>> concept of narrowing down the refresh token scopes.
>> 
>> "The scope was originally read openid profile and after refresh the access 
>> was reduced to read profile (i.e., the access_token now only has read 
>> profile scope and any new tokens obtained using the refresh token 
>> daa38700-ba96-4ef1-8b30-5cb3527aae19 will have the same, reduced scope). 
>> Note that increasing the scope of access cannot be done in this way unless 
>> first reduced and increased back to the original scope."
>> 
>> [1] 
>> https://curity.io/resources/learn/refresh-tokens/#changing-scope-of-access-token-on-refresh
>>  
>> <https://curity.io/resources/learn/refresh-tokens/#changing-scope-of-access-token-on-refresh>
>> 
>> Thanks & Regards,
>> Sachin
>> 
>> On Tue, 20 Feb 2024 at 21:59, Neil Madden > <mailto:neil.e.mad...@gmail.com>> wrote:
>> 
>> 
>>> On 20 Feb 2024, at 11:02, Sachin Mamoru >> <mailto:sachinmam...@gmail.com>> wrote:
>>> 
>>> 
>>> Hi Neil,
>>> 
>>> Does that mean it should be identical to the narrowed scope request or the 
>>> original request scope?
>> 
>> It says it has to be identical to the scope of the existing refresh token in 
>> the request, not the scope specified in the request. So effectively you can 
>> never downscope a refresh token in this way. Whatever scope you specify, any 
>> RT returned must always retain the original scope. 
>> 
>> (There are other ways to downscope a RT, eg ForgeRock’s macaroons allow you 
>> to attenuate the scope if you wish). 
>> 
>> — Neil
>> 
>>> 
>>> On Tue, 20 Feb 2024 at 16:31

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Neil Madden]

On 21 Feb 2024, at 08:06, Sachin Mamoru  wrote:
> 
> Hi Warren and Neil,
> 
> Thanks for the valuable input and sorry for mentioning other products, I just 
> wanted to provide an example. 
> So Warren according to you following is the behaviour that spec suggested.
> 
> When we request an access token using 3 scopes (scope1, scope2, scope3).
> 
> Then will receive a refresh token (refresh_token1) with the access token.
> 
> After that will request another access token with refresh_token1 and provide 
> the scope list as scope1 and scope2 (Narrow down scopes).
> 
> Similarly, get another refresh token (refresh_token2) with the access token.
> 
> Now if we request another access token with refresh_token2, we should be able 
> to request scope3 also.
> That means the refresh token will not be narrowed down instead only the 
> access token will get narrowed down.
> 
> So Warren and Neil, if possible can you pinpoint to me the exact place in the 
> spec where it does explicitly say that the refresh token should not be 
> narrowed down based on the given scopes?

I have already pointed out the exact place in the spec that says this: 
https://www.rfc-editor.org/rfc/rfc6749#section-6 


   If a
   new refresh token is issued, the refresh token scope MUST be
   identical to that of the refresh token included by the client in the
   request.

In your example, refresh_token1 has scope1, scope2, scope3 so therefore 
refresh_token2 must also have those scopes.

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

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Neil Madden]

It sounds like they are violating the spec then. On the other hand, the fact 
that the scope can be "increased back to the original scope" maybe suggests the 
effective scope of the refresh token is still the same? Either way, the spec is 
pretty clear, regardless of what some vendor does.

-- Neil

> On 20 Feb 2024, at 19:26, Sachin Mamoru  wrote:
> 
> Hi Neil,
> 
> Thanks for the clarification.
> But Curity has a different approach and they implemented it according to the 
> concept of narrowing down the refresh token scopes.
> 
> "The scope was originally read openid profile and after refresh the access 
> was reduced to read profile (i.e., the access_token now only has read profile 
> scope and any new tokens obtained using the refresh token 
> daa38700-ba96-4ef1-8b30-5cb3527aae19 will have the same, reduced scope). Note 
> that increasing the scope of access cannot be done in this way unless first 
> reduced and increased back to the original scope."
> 
> [1] 
> https://curity.io/resources/learn/refresh-tokens/#changing-scope-of-access-token-on-refresh
>  
> <https://curity.io/resources/learn/refresh-tokens/#changing-scope-of-access-token-on-refresh>
> 
> Thanks & Regards,
> Sachin
> 
> On Tue, 20 Feb 2024 at 21:59, Neil Madden  <mailto:neil.e.mad...@gmail.com>> wrote:
> 
> 
>> On 20 Feb 2024, at 11:02, Sachin Mamoru > <mailto:sachinmam...@gmail.com>> wrote:
>> 
>> 
>> Hi Neil,
>> 
>> Does that mean it should be identical to the narrowed scope request or the 
>> original request scope?
> 
> It says it has to be identical to the scope of the existing refresh token in 
> the request, not the scope specified in the request. So effectively you can 
> never downscope a refresh token in this way. Whatever scope you specify, any 
> RT returned must always retain the original scope. 
> 
> (There are other ways to downscope a RT, eg ForgeRock’s macaroons allow you 
> to attenuate the scope if you wish). 
> 
> — Neil
> 
>> 
>> On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru > <mailto:sachinmam...@gmail.com>> wrote:
>> 
>> 
>> On Tue, 20 Feb 2024 at 12:23, Neil Madden > <mailto:neil.e.mad...@gmail.com>> wrote:
>> 
>>> On 20 Feb 2024, at 06:44, Sachin Mamoru >> <mailto:sachinmam...@gmail.com>> wrote:
>>> 
>>> 
>>> Hi All,
>>> 
>>> When we request an access token using 3 scopes (scope1, scope2, scope3).
>>> Then will receive a refresh token (refresh_token1) with the access token.
>>> 
>>> After that will request another access token with refresh_token1 and 
>>> provide the scope list as scope1 and scope2 (Narrow down scopes).
>>> Similarly, get another refresh token (refresh_token2) with the access token.
>>> 
>>> Now if we request another access token with refresh_token2, we cannot 
>>> request scope3, instead, we can either request both scope1 and scope2 or 
>>> one of them.
>>> 
>>> But in the specification, didn't able to find anything related to 
>>> narrow-down scopes with refresh token.
>>> 
>>> From Spec
>>> 
>>> 1.5.  Refresh Token - Refresh tokens are issued to the client by the 
>>> authorization server and are used to obtain a new access token when the 
>>> current access token becomes invalid or expires or to obtain additional 
>>> access tokens with identical or narrower scope (access tokens may have a 
>>> shorter lifetime and fewer permissions than authorized by the resource 
>>> owner).
>>> 
>>> 6.  Refreshing an Access Token
>>> The scope of the access request as described by Section 3.3.  The requested 
>>> scope MUST NOT include any scope not originally granted by the resource 
>>> owner, and if omitted is treated as equal to the scope originally granted 
>>> by the resource owner.
>>> 
>>> https://datatracker.ietf.org/doc/html/rfc6749 
>>> <https://datatracker.ietf.org/doc/html/rfc6749>
>>> 
>>> IMO, from a security aspect, the current behaviour is much more secure 
>>> because it is designed to maintain the principle of least privilege, where 
>>> it updates the refresh token authorised scopes based on the requested ones.
>>> 
>>> What should be the correct behaviour?
>>> narrow-down scope refresh token should also be able to request access token 
>>> with original scope list?
>> 
>> Also from section 6:
>> 
>> If a
>>new refresh token is issued, the refresh token scope MUST be
>>

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Neil Madden]

On 20 Feb 2024, at 11:02, Sachin Mamoru  wrote:Hi Neil,Does that mean it should be identical to the narrowed scope request or the original request scope?It says it has to be identical to the scope of the existing refresh token in the request, not the scope specified in the request. So effectively you can never downscope a refresh token in this way. Whatever scope you specify, any RT returned must always retain the original scope. (There are other ways to downscope a RT, eg ForgeRock’s macaroons allow you to attenuate the scope if you wish). — NeilOn Tue, 20 Feb 2024 at 16:31, Sachin Mamoru <sachinmam...@gmail.com> wrote:On Tue, 20 Feb 2024 at 12:23, Neil Madden <neil.e.mad...@gmail.com> wrote:On 20 Feb 2024, at 06:44, Sachin Mamoru <sachinmam...@gmail.com> wrote:Hi All,When we request an access token using 3 scopes (scope1, scope2, scope3).Then will receive a refresh token (refresh_token1) with the access token.After that will request another access token with refresh_token1 and provide the scope list as scope1 and scope2 (Narrow down scopes).Similarly, get another refresh token (refresh_token2) with the access token.Now if we request another access token with refresh_token2, we cannot request scope3, instead, we can either request both scope1 and scope2 or one of them.But in the specification, didn't able to find anything related to narrow-down scopes with refresh token.From Spec1.5.  Refresh Token - Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).6.  Refreshing an Access TokenThe scope of the access request as described by Section 3.3.  The requested scope MUST NOT include any scope not originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner.https://datatracker.ietf.org/doc/html/rfc6749IMO, from a security aspect, the current behaviour is much more secure because it is designed to maintain the principle of least privilege, where it updates the refresh token authorised scopes based on the requested ones.What should be the correct behaviour?narrow-down scope refresh token should also be able to request access token with original scope list?Also from section 6:If a
   new refresh token is issued, the refresh token scope MUST be
   identical to that of the refresh token included by the client in the
   request.— Neil--   Sachin Mamoru  Software Engineer,   WSO2 +94771292681 |  sachinmamoru.me  sachinmam...@gmail.com 
--   Sachin Mamoru  Software Engineer,   WSO2 +94771292681 |  sachinmamoru.me  sachinmam...@gmail.com 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Neil Madden]

> On 20 Feb 2024, at 06:44, Sachin Mamoru  wrote:
> 
> 
> Hi All,
> 
> When we request an access token using 3 scopes (scope1, scope2, scope3).
> Then will receive a refresh token (refresh_token1) with the access token.
> 
> After that will request another access token with refresh_token1 and provide 
> the scope list as scope1 and scope2 (Narrow down scopes).
> Similarly, get another refresh token (refresh_token2) with the access token.
> 
> Now if we request another access token with refresh_token2, we cannot request 
> scope3, instead, we can either request both scope1 and scope2 or one of them.
> 
> But in the specification, didn't able to find anything related to narrow-down 
> scopes with refresh token.
> 
> From Spec
> 
> 1.5.  Refresh Token - Refresh tokens are issued to the client by the 
> authorization server and are used to obtain a new access token when the 
> current access token becomes invalid or expires or to obtain additional 
> access tokens with identical or narrower scope (access tokens may have a 
> shorter lifetime and fewer permissions than authorized by the resource owner).
> 
> 6.  Refreshing an Access Token
> The scope of the access request as described by Section 3.3.  The requested 
> scope MUST NOT include any scope not originally granted by the resource 
> owner, and if omitted is treated as equal to the scope originally granted by 
> the resource owner.
> 
> https://datatracker.ietf.org/doc/html/rfc6749
> 
> IMO, from a security aspect, the current behaviour is much more secure 
> because it is designed to maintain the principle of least privilege, where it 
> updates the refresh token authorised scopes based on the requested ones.
> 
> What should be the correct behaviour?
> narrow-down scope refresh token should also be able to request access token 
> with original scope list?

Also from section 6:

If a
   new refresh token is issued, the refresh token scope MUST be
   identical to that of the refresh token included by the client in the
   request.




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

Re: [OAUTH-WG] client_id in CWT Claims

[Neil Madden]

RFC8693 didn't register anything for CWT at all. Some other document has 
registered scope for CWT and pointed at that RFC as the reference for some 
reason. 

-- Neil

> On 24 Jan 2024, at 18:37, Orie Steele  wrote:
> 
> I'm working on a document that has some similarity to EAT from RATS, in that 
> it is trying to enable JWT and CWT to be used for a use case.
> 
> Is there a reason that RFC8693 registers "scope" and "client_id" for JWT, but 
> only "scope" for CWT ?
> 
> - https://www.iana.org/assignments/jwt/jwt.xhtml 
> 
> - https://www.iana.org/assignments/cwt/cwt.xhtml 
> 
> 
> How can I use "client_id" in CWT ?
> 
> OS
> 
> -- 
> 
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>  
> ___
> 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] Query on correct approach of calculating the "x5t#S256" parameter in the JWKS response

[Neil Madden]

JWS refers to FIPS 180-4 as the definition of SHA-256. That spec defines the 
message digest produced by SHA-256 as a 256-bit binary value, not a hex-encoded 
string. So the "base64url-encoded SHA-256 thumbprint (a.k.a. digest)" is your 
Method 1. Anyone doing Method 2 has a bug.

-- Neil

> On 10 Jan 2024, at 04:10, Thamindu Dilshan Jayawickrama 
>  wrote:
> 
> Hi all,
> 
> I have initiated this mail thread to get your opinion on the correct approach 
> of calculating the "x5t#S256" parameter in the JWKS response. JWS 
> specification [1 
> ] defines the 
> "x5t#S256" parameter as follows.
> 
> """
> The "x5t#S256" (X.509 certificate SHA-256 thumbprint) Header
> Parameter is a base64url-encoded SHA-256 thumbprint (a.k.a. digest)
> of the DER encoding of the X.509 certificate [RFC5280] corresponding
> to the key used to digitally sign the JWS.
> """
> 
> Different parties seem to be using two different methods when calculating 
> this field.
> 
> Method 1:
> 
> 1. Take DER encoding of the certificate which produces a 32 byte array
> 2. Take the base64 url encoding
> 
> In this method, we compute this "x5t#S256" parameter by directly url encoding 
> the 32 byte array without taking the hex string. Example given at appendix A 
> of the MTLS token spec [2 
> ] appears 
> to be following this method.
> 
> Method 2:
> 
> 1. Take DER encoding of the certificate which produces a 32 byte array
> 2. Convert it into a hexadecimal string and transform it into a 64 byte array
> 3. Take the base64 url encoding
> 
> In some places I have seen the following approach is used to obtain a value 
> equal to the "x5t#S256" field.
> 
> 1. Display the certificate with a tool like Keytool Explorer and copy the SHA 
> 256 fingerprint.
> 2. Remove colons (":"s) and convert it to all lowercase. 
> 3. Base64url encode the value.
> 
> This approach requires the above hexifing step (method 2) in order to produce 
> a similar result when computing the "x5t#S256" field.
> 
> Hence I would like to query about the correct approach to follow when 
> calculating the "x5t#S256" parameter. Or can we accept both these forms as 
> correct methods to calculate the mentioned field?
> 
> Thanks in advance.
> 
> [1] https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.8 
> 
> [2] https://datatracker.ietf.org/doc/html/rfc8705#section-appendix.a 
> 
> 
> Best Regards,
> Thamindu Jayawickrama
> 
> ___
> 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] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

> On 7 Nov 2023, at 15:50, Denis  wrote:
> 
> Hi Neil,
> 
>> On 7 Nov 2023, at 13:13, Denis > > wrote:
>>> 
>>> Hi Neil,
>>> 
>>> You wrote:
>>> "Note that unlinkability is explicitly already not a goal for SD-JWT 
>>> according to section 12.4".
>>> This is untrue:
>>> 12.4.  Unlinkability
>>> 
>>> Colluding Issuer/Verifier or Verifier/Verifier pairs could link 
>>> issuance/presentation or two presentation sessions to the same user
>>> on the basis of unique values encoded in the SD-JWT (Issuer signature, 
>>> salts, digests, etc.).
>>> 
>>> To prevent these types of linkability, various methods, including but not 
>>> limited to the following ones can be used:
>>> 
>>> - Use advanced cryptographic schemes, outside the scope of this 
>>> specification.
>>> 
>>> - Issue a batch of SD-JWTs to the Holder to enable the Holder to use a 
>>> unique SD-JWT per Verifier. 
>>>This only helps with Verifier/Verifier unlinkability.
>>> This means using single-use credentials and issuing in advance credentials 
>>> batches, each one with a different holder-public key in it .
>> 
>> The very first sentence of that section clearly states that SD-JWTs can be 
>> linked. The fact that it also mentions other things you can do, 
>> entirely orthogonal to the use of SD-JWT, doesn't contradict that, it rather 
>> reinforces it. (As I've said previously when SD-JWT was first proposed, 
>> if you are willing to issue a batch of credentials then you don't need 
>> SD-JWT at all: just issue normal JWTs with subsets of claims 
>> matching anticipated selective disclosure cases. In all the concrete 
>> use-cases I've seen, this is not a large number of combinations).
> 1) If some people are willing to support the Verifier/Verifier unlinkability 
> property, the document should provide more guidance 
> since a solution that does not use advanced cryptographic schemes is at hand. 
> Otherwise, the fact that the Verifier/Verifier 
> unlinkability property is not supported should be advertised in Section 1.1.  
> "Feature Summary". 
> 
I think that part of it is fine as it is. It states the properties it does 
support up-front and mentions things it doesn’t support in the security/privacy 
considerations. That seems pretty standard practice. I wouldn’t object to the 
authors adding text clarifying that to the summary, but it doesn’t seem 
necessary to me.

> 2) If you just issue normal JWTs with subsets of claims matching anticipated 
> selective disclosure cases, the burden is rather the same for the Holder: 
> it needs to generate a different key pair for every SD-JWT. As soon as a 
> SD-JWT will be used towards a Verifier, it should be discarded 
> so that it cannot be reused towards another Verifier.  This approach might 
> quadruple the number of JWTs to ask in advance.
> 
I’m not sure I follow this logic. You want to issue multiple single-use SD-JWTs 
to ensure unlinkability, but think it’s too much to issue multiple normal JWTs?

Anyway, this is getting somewhat off the point. SD-JWTs as specified contain no 
features to support unlinkability and this is clearly not a goal of the spec. 
The fact that you might want it to be a goal doesn’t make it so.

>> 
>>> 
>>> So, I generally agree with Watson.
>>> 
>>> Currently, the SPICE BoF tentative charter is considering Verifier/Verifier 
>>> unlinkability to be within the charter. 
>>> 
>>> You also wrote:
>>> Allowing an attacker to selectively disclose that a token has expired seems 
>>> problematic to say the least
>>> Why an "attacker" ? This is not problem as soon as a SD-JWT is only used 
>>> once.
>> 
>> The point of these kinds of security constraints (which are indeed mostly 
>> constraints and not claims), is to prevent certain attacks. 
>> Such as restricting the time-window in which a token can be used, so that if 
>> it is stolen there is a limit to how long it can be abused. 
>> The "attacker" here could be a third party that intercepts/phishes the 
>> token, or it could be a malicious Verifier, etc. If these constraints 
>> can be selectively disclosed then they are utterly useless in preventing the 
>> attacks they are designed to stop: time-limited tokens become 
>> unlimited time usage, key-bound tokens become bearer tokens, and single-use 
>> tokens become multiple-use. 
>> To say this is a *spectacularly* bad idea is an understatement. 
> The point is not to use selective disclosure on claims that prevent certain 
> attacks. 
> 
Indeed, which is what I suggested. Watson Ladd suggested this would lead to 
some kind of privacy leak, which you agreed with. I take it now that you don’t 
agree with that, but instead agree with me that there are certain claims that 
shouldn’t be selectively disclosable?

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

On 7 Nov 2023, at 13:13, Denis  wrote:
> 
> Hi Neil,
> 
> You wrote:
> "Note that unlinkability is explicitly already not a goal for SD-JWT 
> according to section 12.4".
> This is untrue:
> 12.4.  Unlinkability
> 
> Colluding Issuer/Verifier or Verifier/Verifier pairs could link 
> issuance/presentation or two presentation sessions to the same user
> on the basis of unique values encoded in the SD-JWT (Issuer signature, salts, 
> digests, etc.).
> 
> To prevent these types of linkability, various methods, including but not 
> limited to the following ones can be used:
> 
> - Use advanced cryptographic schemes, outside the scope of this specification.
> 
> - Issue a batch of SD-JWTs to the Holder to enable the Holder to use a unique 
> SD-JWT per Verifier. 
>This only helps with Verifier/Verifier unlinkability.
> This means using single-use credentials and issuing in advance credentials 
> batches, each one with a different holder-public key in it .

The very first sentence of that section clearly states that SD-JWTs can be 
linked. The fact that it also mentions other things you can do, entirely 
orthogonal to the use of SD-JWT, doesn't contradict that, it rather reinforces 
it. (As I've said previously when SD-JWT was first proposed, if you are willing 
to issue a batch of credentials then you don't need SD-JWT at all: just issue 
normal JWTs with subsets of claims matching anticipated selective disclosure 
cases. In all the concrete use-cases I've seen, this is not a large number of 
combinations).

> 
> So, I generally agree with Watson.
> 
> Currently, the SPICE BoF tentative charter is considering Verifier/Verifier 
> unlinkability to be within the charter. 
> 
> You also wrote:
> Allowing an attacker to selectively disclose that a token has expired seems 
> problematic to say the least
> Why an "attacker" ? This is not problem as soon as a SD-JWT is only used once.

The point of these kinds of security constraints (which are indeed mostly 
constraints and not claims), is to prevent certain attacks. Such as restricting 
the time-window in which a token can be used, so that if it is stolen there is 
a limit to how long it can be abused. The "attacker" here could be a third 
party that intercepts/phishes the token, or it could be a malicious Verifier, 
etc. If these constraints can be selectively disclosed then they are utterly 
useless in preventing the attacks they are designed to stop: time-limited 
tokens become unlimited time usage, key-bound tokens become bearer tokens, and 
single-use tokens become multiple-use. To say this is a *spectacularly* bad 
idea is an understatement. 

-- Neil



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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

> On 6 Nov 2023, at 16:43, Watson Ladd  wrote:
> 
> On Mon, Nov 6, 2023 at 5:46 AM Neil Madden  wrote:
> 
>> 
>> How about the following:
>> 
>> —
>> An Issuer MUST NOT allow any security-critical claim to be selectively 
>> disclosable. The exact list of “security-critical” claims will depend on the 
>> application, and SHOULD be listed by any application-specific profile of 
>> SD-JWT. The following is a list of standard claim names that SHOULD be 
>> considered as security-critical by any SD-JWT Issuer:
>> 
>> * “iss” (Issuer)
>> * “aud” (Audience), although issuers may want to allow individual entries in 
>> the array to be selectively-disclosable
>> * “exp” (Expiration Time)
>> * “nbf” (Not Before)
>> * “iat” (Issued At)
>> * “jti” (JWT ID)
>> 
>> In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively 
>> disclosable.
>> ---
>> 
> 
> I think these fields can have significant unanticipated privacy
> impacts. Expiry and issuance times can have very high entropy.

Can you expand on what you mean? What privacy threat do you envision? Note that 
unlinkability is explicitly already not a goal for SD-JWT according to section 
12.4. 

Allowing an attacker to selectively disclose that a token has expired seems 
problematic to say the least. 

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

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Neil Madden]

Although I think we could add some basic advice, the list of security headers 
to use is still evolving. For example, there were several headers added after 
Spectre to limit cross-site interactions. And then there’s things like the 
“X-XSS-Protection” header, which was best practice to add to responses not too 
long ago but has now been universally removed from browsers as it enabled 
certain content disclosure attacks.

Cookie security attributes are perhaps a bit more stable, but in general we 
probably just want to point people at “living” guidance like OWASP.

— Neil

> On 5 Nov 2023, at 19:28, Dick Hardt  wrote:
> 
> The cookie and header recommendations I am thinking of would be for the AS as 
> well as the client. 
> 
> A number of XSS attacks can be thwarted by a modern browser and the right 
> HTTP headers.
> 
> My question is: Did the authors consider adding cookie and header 
> recommendations, and decided it was too general? 
> 
> Cookie and header best security practices have been around for years -- I'm 
> not suggesting we make anything up -- I'm suggesting we raise awareness. 
> 
> I consider myself to be fairly security aware, and I was not aware of some of 
> the HTTP headers that are best security practice. 
> 
> /Dick
> 
> 
> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki 
> mailto:40parecki@dmarc.ietf.org>> 
> wrote:
>> I don't think it's necessary to say "do the right things with cookies" in 
>> the Security BCP. The Browser Apps BCP has a much deeper discussion of how 
>> different browser-based architectures work with cookies so that seems like a 
>> better place to actually have a real discussion about it.
>> 
>> Also +1 to what Daniel said about not continuing to add little things. Plus 
>> I think it's too late anyway, publication has already been requested for the 
>> Security BCP.
>> 
>> Aaron
>> 
>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett 
>> > > wrote:
>>> I agree with Aaron! 
>>> 
>>> Also we should be very careful about any additions to the Security BCP at 
>>> this point. It is very easy to re-start the "one more thing" loop we've 
>>> been stuck in for the last years. There may be more useful things to say, 
>>> but we should put them on the list for a future second version of the BCP.
>>> 
>>> -Daniel
>>> 
>>> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
 I don't think the Security BCP should incorporate cookie best practices 
 directly in the document. If anything, it sounds like possibly a candidate 
 for inclusion in the Browser Apps BCP. 
 
 There are already some mentions of these cookie properties mentioned in 
 the Browser Apps BCP, though only in reference to specific architectures, 
 not as a general best practice. For example:
 
 https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
 
 Aaron
 
 On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt >>> > wrote:
> Hey
> 
> I was reviewing security on some sites I managed and checked to see if 
> the recommendations were in the BCP.
> 
> I don't see anything around cookies such as httpOnly, sameSite, secure. 
> 
> I saw some HTTP security header suggestions buried in 4.16 
> (X-Frame-Options, CSP), but not for Strict-Transport-Security, 
> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is 
> rather vague.
> 
> I understand these are general web security best practices, and perhaps I 
> missed it, but I think it would be useful to call out that best security 
> practices around cookies and headers should also be followed in Section 
> 2, and either have the best practices included, or direct the reader 
> where to find them.
> 
> /Dick
> 
> ___
> 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
>>> ___
>>> 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
> ___
> 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] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Neil Madden]

Although I think we could add some basic advice, the list of security headers 
to use is still evolving. For example, there were several headers added after 
Spectre to limit cross-site interactions. And then there’s things like the 
“X-XSS-Protection” header, which was best practice to add to responses not too 
long ago but has now been universally removed from browsers as it enabled 
certain content disclosure attacks.

Cookie security attributes are perhaps a bit more stable, but in general we 
probably just want to point people at “living” guidance like OWASP.

— Neil

> On 5 Nov 2023, at 19:28, Dick Hardt  wrote:
> 
> The cookie and header recommendations I am thinking of would be for the AS as 
> well as the client. 
> 
> A number of XSS attacks can be thwarted by a modern browser and the right 
> HTTP headers.
> 
> My question is: Did the authors consider adding cookie and header 
> recommendations, and decided it was too general? 
> 
> Cookie and header best security practices have been around for years -- I'm 
> not suggesting we make anything up -- I'm suggesting we raise awareness. 
> 
> I consider myself to be fairly security aware, and I was not aware of some of 
> the HTTP headers that are best security practice. 
> 
> /Dick
> 
> 
> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki 
> mailto:40parecki@dmarc.ietf.org>> 
> wrote:
>> I don't think it's necessary to say "do the right things with cookies" in 
>> the Security BCP. The Browser Apps BCP has a much deeper discussion of how 
>> different browser-based architectures work with cookies so that seems like a 
>> better place to actually have a real discussion about it.
>> 
>> Also +1 to what Daniel said about not continuing to add little things. Plus 
>> I think it's too late anyway, publication has already been requested for the 
>> Security BCP.
>> 
>> Aaron
>> 
>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett 
>> > > wrote:
>>> I agree with Aaron! 
>>> 
>>> Also we should be very careful about any additions to the Security BCP at 
>>> this point. It is very easy to re-start the "one more thing" loop we've 
>>> been stuck in for the last years. There may be more useful things to say, 
>>> but we should put them on the list for a future second version of the BCP.
>>> 
>>> -Daniel
>>> 
>>> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
 I don't think the Security BCP should incorporate cookie best practices 
 directly in the document. If anything, it sounds like possibly a candidate 
 for inclusion in the Browser Apps BCP. 
 
 There are already some mentions of these cookie properties mentioned in 
 the Browser Apps BCP, though only in reference to specific architectures, 
 not as a general best practice. For example:
 
 https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
 
 Aaron
 
 On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt >>> > wrote:
> Hey
> 
> I was reviewing security on some sites I managed and checked to see if 
> the recommendations were in the BCP.
> 
> I don't see anything around cookies such as httpOnly, sameSite, secure. 
> 
> I saw some HTTP security header suggestions buried in 4.16 
> (X-Frame-Options, CSP), but not for Strict-Transport-Security, 
> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is 
> rather vague.
> 
> I understand these are general web security best practices, and perhaps I 
> missed it, but I think it would be useful to call out that best security 
> practices around cookies and headers should also be followed in Section 
> 2, and either have the best practices included, or direct the reader 
> where to find them.
> 
> /Dick
> 
> ___
> 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
>>> ___
>>> 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
> ___
> 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] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

Hi Brian,

Apologies for the late reply. I *think* we’re closing in on agreement here. 
Comments and some wording suggestions inline below.

> On 27 Oct 2023, at 00:26, Brian Campbell  wrote:
> 
> Thanks Neil!  Appreciate the productive discussion. Some more responses below 
> (while also attempting to snip out and declutter the message).
> 
> On Thu, Oct 26, 2023 at 7:03 AM Neil Madden  <mailto:neil.e.mad...@gmail.com>> wrote:
>> On 25 Oct 2023, at 22:00, Brian Campbell > <mailto:bcampb...@pingidentity.com>> wrote:
> 
>  
>>> 
>>> The draft currently says that second-preimage resistance is needed, which 
>>> prevents a malicious Holder from finding a different Disclosure value that 
>>> results in a digest that's the same as one in the signed credential. 
>>> Protecting against a malicious user effectively forging or modifying 
>>> disclosed claim names/values is the security objective. Second-preimage 
>>> resistance is not as strong as collision resistance but I believe is 
>>> correct and sufficient for the context of use. And a malicious Issuer isn't 
>>> something that's in scope and could do all kinds of other bad things. This 
>>> is the section of the security considerations with that: 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5
>> 
>> Ok, that is a fair enough stance. Without requiring collision resistance 
>> though it does make SD-JWT a slightly weird signature scheme, in that the 
>> issuer is not actually committed to the contents of the token like they 
>> would be for a normal signed JWT. That is a surprising property. For 
>> example, if you store SD-JWTs for audit trail purposes (as some people do 
>> for normal JWTs), the contents are potentially repudiable. Like you say, if 
>> you trust the issuer then maybe that is fine, but it’s a sharp edge that 
>> maybe it would be better to remove? Given that pretty much any hash function 
>> that is likely to be used with SD-JWT will almost certainly be CR anyway. 
> 
> 
> As a compromise of sorts - would you be willing to propose some additional 
> text to go in section 11.5 that (maybe strongly) recommends the hash function 
> be collision resistant?

How about the following?

—
To ensure privacy of claims that are not being selectively disclosed in a given 
presentation, the hash function MUST ensure that it is infeasible to calculate 
the salt and claim name and value (or any portion thereof) that results in a 
particular digest. This implies the hash function MUST be preimage resistant, 
but should also not allow an observer to infer any partial information about 
the undisclosed content. In the terminology of cryptographic commitment 
schemes, the hash function MUST be computationally hiding.

The hash function MUST be second-preimage resistant. For any salt and claim 
value pair, it is infeasible to find a different salt and claim value pair that 
result in the same digest.

The hash function SHOULD also be collision resistant. Although not essential to 
the anticipated uses of SD-JWT, without collision resistance an Issuer may be 
able to find multiple disclosures that have the same hash value. The signature 
over the SD-JWT would not then commit the Issuer to the contents of the JWT, 
which is surprising. Where this is a concern, the collision resistance of the 
hash function SHOULD match the collision resistance of the hash function used 
by the signature scheme. For example, use of the ES512 signature algorithm 
would require a disclosure hash function with at least 256-bit collision 
resistance, such as SHA-512.
—

(I’d like to add an informational reference defining these terms, but I can’t 
find a good one - even the NIST/FIPS standards seem to just take terms like 
“collision resistance” for granted, so maybe we can too?)

> 
> I'm envisioning the resultant 11.5 section saying that the hash function MUST 
> be second-preimage resistant and fully irreversible (as it does/will now with 
> slightly updated wording discussed below) but then also goes on to say that 
> it SHOULD just be collision resistant. I can come up with some text 
> recommending CR too but maybe not with the rationale/explanation as you 
> could. 
> 
>  
>  
>>> Preimage resistance maybe isn’t the term to use there. It’s used in that 
>>> section-11.5 
>>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5>
>>>  along with some text that says that it needs to be “infeasible to 
>>> calculate the salt and claim value that result in a particular digest”.  We 
>>> are trying to say that the hash has to have the property that it can’t be 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

On 25 Oct 2023, at 22:00, Brian Campbell  wrote:Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below. Thanks. Some responses below. On Tue, Oct 24, 2023 at 3:48 AM Neil Madden <neil.e.mad...@gmail.com> wrote:I’ve had a look through this new draft and I have some comments and questions. Some of which are similar to comments I already raised [1], but haven’t been addressed.Are we concerned about Holders and Issuers colluding?With SD-JWT or plain JWT or really any similar signed token construct the Verifier has to trust the Issuer ultimately to act/issue honestly. So colluding Holders and Issuers just isn't part of the threat model. I don't honestly know how that could be different. The Issuer, if malicious, can issue a token with whatever content they want.That’s reasonable.   For example, now that claim names are blinded an Issuer can add the same claim multiple times with different, potentially contradictory, values and then the Holder can selectively release one disclosure to one Verifier and a completely different one to another Verifier. This seems problematic at least, that the “same” credential could be interpreted differently by different parties.A well behaving Holder would reject such a credential based on the verification and processing rules (this one specifically). While malicious Issuers and colluding Holders and Issuers are outside the threat model for the reasons explained above. So this situation is handled as much as it can be (as best I know anyway) in the draft.A more sophisticated version of this “attack” illustrates the need for collision resistance in the hash function, not just preimage resistance as stated in the draft (and already raised by me in [1]). If the hash is not CR then a malicious Issuer can find colliding [salt, key, value] triplets that have the same hash value, give one to the Holder and then later claim that they actually signed the other one. (This is not just theoretical, similar attacks have been used to create fraudulent SSL certificates [2]).The draft currently says that second-preimage resistance is needed, which prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use. And a malicious Issuer isn't something that's in scope and could do all kinds of other bad things. This is the section of the security considerations with that: https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5Ok, that is a fair enough stance. Without requiring collision resistance though it does make SD-JWT a slightly weird signature scheme, in that the issuer is not actually committed to the contents of the token like they would be for a normal signed JWT. That is a surprising property. For example, if you store SD-JWTs for audit trail purposes (as some people do for normal JWTs), the contents are potentially repudiable. Like you say, if you trust the issuer then maybe that is fine, but it’s a sharp edge that maybe it would be better to remove? Given that pretty much any hash function that is likely to be used with SD-JWT will almost certainly be CR anyway.  This also indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms.Yeah, saying something about matching the strength of hash function and signature algorithm would probably be worthwhile. Yes, or just pick SHA-512…Furthermore, preimage resistance is not a sufficient property to ensure confidentiality of withheld claims. Preimage resistance holds if the attacker cannot recover the exact input that produced a given hash value, but it doesn’t preclude the attacker being able to recover partial information about that value. For example, consider the hash function H(x) = SHA-256(x) || x[x.len-10..x.len] (where || is concatenation). This hash function when applied to SD-JWT is preimage resistant (assuming the salt is strong), but leaks the last 10 bytes of the claim value.Preimage resistance maybe isn’t the term to use there. It’s used in that section-11.5 along with some text that says that it needs to be “infeasible to calculate the salt and claim value that result in a particular digest”.  We are trying to say that the hash has to have the property that it can’t be reversed (or even partially reversed, to your point). There’s probably a better way to state that the hash function has to be not at all reversibl

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

I’ve had a look through this new draft and I have some comments and questions. 
Some of which are similar to comments I already raised [1], but haven’t been 
addressed.

Are we concerned about Holders and Issuers colluding? For example, now that 
claim names are blinded an Issuer can add the same claim multiple times with 
different, potentially contradictory, values and then the Holder can 
selectively release one disclosure to one Verifier and a completely different 
one to another Verifier. This seems problematic at least, that the “same” 
credential could be interpreted differently by different parties.

A more sophisticated version of this “attack” illustrates the need for 
collision resistance in the hash function, not just preimage resistance as 
stated in the draft (and already raised by me in [1]). If the hash is not CR 
then a malicious Issuer can find colliding [salt, key, value] triplets that 
have the same hash value, give one to the Holder and then later claim that they 
actually signed the other one. (This is not just theoretical, similar attacks 
have been used to create fraudulent SSL certificates [2]). This also indicates 
that the security strength of the signature scheme is bounded by the collision 
resistance of the hash function - e.g. there’s little point using ES512 with 
SHA-256, for example. Probably the security considerations should suggest 
matching hash functions to signature algorithms.

Furthermore, preimage resistance is not a sufficient property to ensure 
confidentiality of withheld claims. Preimage resistance holds if the attacker 
cannot recover the exact input that produced a given hash value, but it doesn’t 
preclude the attacker being able to recover partial information about that 
value. For example, consider the hash function H(x) = SHA-256(x) || 
x[x.len-10..x.len] (where || is concatenation). This hash function when applied 
to SD-JWT is preimage resistant (assuming the salt is strong), but leaks the 
last 10 bytes of the claim value.

The appropriate security definition for SD-JWT is some form of cryptographic 
commitment scheme [3], with the associated security notions of hiding and 
binding. Honestly, I still think that this WG is not an appropriate venue for 
this kind of novel (in the OAuth world) cryptographic scheme and external 
review by experts would be helpful.

All of this suggests that simply referring the the IANA hash function registry 
is not sufficient, as probably *most* of the entries there are not actually 
suitable for use in SD-JWT for one reason or another.

Some other comments:

The original JWT RFC [4] has this to say about the order of encryption and 
signatures:

   signatures over encrypted text are not considered valid in many
   jurisdictions.

Presumably the same argument holds about signatures over blinded values? That 
should perhaps be noted at least.

The draft repeatedly says that a symmetric signature algorithm (MAC) must not 
be used. Perhaps I’m missing something here, but why not? It doesn’t seem like 
it compromises any of the intended security properties. Use of a symmetric MAC 
may also limit the privacy impacts on users as it provides some measure of 
deniability (similar to that mentioned in section 12.1), as any Verifier in 
possession of the secret key could also have produced any claims that are 
subsequently leaked, allowing the user to deny that they were produced by the 
supposed Issuer. (This deniability property holds even without subsequent 
leaking of old signing keys).

The security considerations about salt entropy should probably reference RFC 
4086 (BCP 106) or something more up to date (maybe RFC 8937 too).

I think section 11.8 about selectively disclosing contraints on the use of a 
SD-JWT is completely inadequate and will almost certainly lead to attacks. 
Requiring Verifiers to hard-wire the set of constraints they enforce is likely 
to be damaging to future evolution of the standard as new security constraints 
are added. It would seem especially problematic to allow selective disclosure 
of a “cnf” claim for example, and yet nothing forbids it and the history of JWT 
usage suggests that anything not forbidden will at some point happen (and even 
some things that are forbidden). I suggest establishing a registry of claims 
that are really usage constraints and forbidding issuers from allowing anything 
in that list to be selectively-disclosed. (There are perhaps some exceptions 
here, e.g. “aud” is a constraint in this sense but it probably _does_ make 
sense for it to be selectively disclosed, but only on a per-array-item basis: 
that way a Holder cannot remove the constraint entirely but can still hide 
other “recipients”).

On a related note, section 11.6 says that to avoid this kind of attack, 
Verifiers MUST NOT take into account whether a Key Binding is present or not to 
decide whether to require Key Binding. This seems to preclude Verifiers that 
can handle different levels of access with di

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

[Neil Madden]

I support adoption. I have questions about the specifics which I'll try to 
write up in the next week or so, but the basic idea seems useful. (The tl;dr of 
my thoughts is: have we learned everything we can do from the *many* iterations 
of similar mechanisms in the PKI space?)

-- Neil

> On 30 Sep 2023, at 13:52, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> This is an official call for adoption for the JWT and CWT Status List draft:
> https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ 
> 
> 
> Please, reply on the mailing list and let us know if you are in favor or 
> against adopting this draft as WG document, by Oct 13th.
> 
> Regards,
>  Rifaat & Hannes
> ___
> 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] Questions on OAuth Protected Resource Metadata

[Neil Madden]

On 21 Sep 2023, at 17:19, Atul Tulshibagwale  wrote:
> 
> Hi all,
> I'm still looking for answers to these two questions 
>  
> regarding the OPRM draft that was recently adopted by the WG:
> If I have a resource server that has multiple endpoints, each of which 
> require different scopes, how should those be handled? For example, in the 
> SSF spec, the SSF Transmitter has a Create Stream endpoint and a Polling 
> endpoint. The scopes required for these are different. How would the client 
> know which scope is to be used with which endpoint?
> Does the spec encourage insecure behavior in the caller by requesting tokens 
> with scopes that they do not understand? I.e. If an authorization server is 
> known to provide valuable tokens with certain scopes, can a malicious 
> resource server trick the client into requesting a more powerful token, which 
> it then uses to access some other service? Since the consent dialog is likely 
> to show two trusted names (i.e. the requesting client and the authorization 
> server), the user would be prone to providing consent, even if the scope 
> looks unnecessarily permissive.
Regarding point 2, if this is a threat then it's already enabled by RFC 6750, 
which defines the `WWW-Authenticate: Bearer scope="..."` challenge header that 
can be used to indicate which scopes a client needs to access a resource. Even 
just misleading documentation for how to access the RS could enable this 
threat. That's not to say that this isn't worth considering (it is), but I 
don't think this draft makes the situation worse than now.

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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Neil Madden]

Right. It’s worth noting that many endpoints already publish similar metadata via OpenAPI (Swagger) API descriptions.NeilOn 27 Aug 2023, at 19:42, Dick Hardt  wrote:For many resources, the information is already disclosed. What is excessive to you might be crucial to others -- and my use case, the disclosure is crucial. Extrapolating your basis for objecting, that another endpoint provides additional attack surface, we would not do ANY new endpoints or functionality since they would all provide more attack surface.On Sat, Aug 26, 2023 at 11:38 PM Jaimandeep Singh  wrote:Hi Dick,My previous emails do not even obliquely refer to security by obscurity. It is about design patterns and excessive information disclosure.RegardsJaimandeep Singh On Sat, 26 Aug, 2023, 8:27 pm Dick Hardt,  wrote:Jaimandeep: Do I understand your objection to adoption is that providing a resource discovery endpoint increases the attack surface as an attacker gains knowledge about the resource?If I understand that correctly, then you are suggesting security through obscurity.As mentioned by Aaron, there is no requirement for a resource to support the resource metadata, and the metadata itself could be protected. Practically though, I believe the argument that security is improved by not having a resource discovery endpoint is false. Most resources have publicly available documentation which will contain the same information, and while the docs are not necessarily machine readable, LLMs can make it pretty accessible. Even if you wanted to keep it secret, if applications that use the resource are readily available, how the applications interact with the resource can be discerned through reverse engineering. I think that a security consideration calling out that a malicious actor more readily has access to the protected resource metadata is an adequate response.For my use case, the protected resource metadata is required for the functionality I plan to implement. The AS has no prior knowledge about the protected resource, and when a request is made, the AS learns about the PR and presents the user with an experience based on the metadata for the user to make a decision to grant access. /DickOn Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh 40nfsu.ac...@dmarc.ietf.org> wrote:Hi Aaron,Thx for your suggestions. I have reviewed the recordings and I would suggest following:1. Design Consideration: The two components of the OAuth 2.0 ecosystem authorization server (step 1) and protected resource server (step 2) may appear independent, but from systems perspective there is a linear dependency between them. Directly engaging with step 2, even in a limited capacity, threatens the established sequence and poses substantial security and architectural implications.2. Information Disclosure: Say I have my HIPPA record stored on a protected resource server, I don't want any app to even know that I have such a resource available with a protected resource server in the first place. The concept of exposing the mere existence of such data raises a glaring concern. Looking at Google, it has a fine-grained authorization strategy that meticulously limits access for its RESTRICTED scopes only to apps that meet certain security benchmarks. Once, the malicious apps come to know of the prized data at the resource server, it will lead to targeted phishing attacks, as was highlighted during the 117 meeting, underscoring the fragility of this approach.3. The Imperative of Gradation and Minimal Exposure: Even if we have to go down this path, there is a definite need to mitigate the perils of overexposure. Instead we can look at gradation strategy, wherein the scopes could be categorized into levels, spanning from generic (Level 0) to tightly controlled (Level 5) access. There is no requirement of secondary URI in this appch. For instance, the sensitive scopes like level 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no need to divulge if a particular resource is present or not and not even the address of the authorization server.ThanksJaimandeep SinghOn Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki 40parecki@dmarc.ietf.org> wrote:Hi Jaimandeep,As with many OAuth extensions, this is not obligatory to implement unless you need the functionality it provides. Many of the concerns you mention are referenced in the security considerations section of the draft already, and we would of course be happy to further expand that section as appropriate. As we presented during the last two IETF meetings, there are many use cases that would benefit from this draft that currently don't have an interoperable solution. I would suggest you review those presentation recordings so better understand the use cases.AaronOn Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh 40nfsu.ac...@dmarc.ietf.org> wrote:I do not support the adoption because of following:1. Increased Attack Surface and Information Disclosure: The p

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Neil Madden]

I support adoption. 

> On 23 Aug 2023, at 20:02, Rifaat Shekh-Yusef  wrote:
> 
> 
> All,
> 
> This is an official call for adoption for the Protected Resource Metadata 
> draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
> 
> Please, reply on the mailing list and let us know if you are in favor of 
> adopting this draft as WG document, by Sep 6th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> 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] RFC 9396 - RAR doubt about examples

[Neil Madden]

> On 2 Jun 2023, at 14:10, Oliva Fernandez, Jorge 
>  wrote:
> 
> Hi,
>  
> Reviewing the just releases RFC there are a couple of examples that seems 
> incorrect or maybe I’m missing something, in section 9.1 and 9.2 appear a 
> field “debtorAccount” outside the “authorization_details” object and in 
> section 9.1 specify:
>  
> “debtorAccount:
> API-specific field containing the debtor account. In the example, this 
> account was not passed in the authorization_details but was selected by the 
> user during the authorization process. The field user_role conveys the role 
> the user has with respect to this particular account. In this case, they are 
> the owner. This data is used for access control at the payment API (the RS).
> ”
>  
> If this “debtorAccount” is the result of an “Enriched Authorization Details“ 
> should not follow what is described in section 7.1 and be returned inside the 
> “authorization_details” Object?

I would tend to agree with you that this looks like an error in the examples, 
or at least is confusing. If the intent of the authorization_detail field is to 
convey exactly what has been authorized, then it seems essential that all 
relevant fields are included in it. Otherwise, it is quite likely that 
downstream security checks may miss this important information. The 
debtorAccount certainly sounds like something that is pretty essential to the 
authorization of the transaction.

-- Neil

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

Re: [OAUTH-WG] redirect uri and portals

[Neil Madden]

On 6 Mar 2023, at 17:10, Yannick Majoros  wrote:
> 
> Hello,
> 
> From my understanding, OAuth 2 as well as 2.1 do not allow for wildcards in 
> redirect_uri . Now, a common requirement for a portal or company-wide 
> website, where multiple applications are deployed, is to be able to login and 
> come back to the page from which the login was triggered.

When you talk about login here, are you talking about OIDC?

> 
> How can this be achieved securely with OAuth?
> 
> Some options:
> 1) passing a parameter, say callback_uri, around from auth request back to 
> redirect from auth server.
> 2) storing some state, e.g. in session storage, and redirect after login
> 3) violating the specifications and just use a redirect uri with a wildcard 
> in the last part (some implementations, like keycloak, allow that)
> 
> 1) and 2) are kind of similar IMO: the application has to validate whatever 
> context comes and redirect to the right page, akin to deep linking
> But then, outside of some extra validation, I'd prefer to have a standard 
> mechanism (less bypassing the restrictions) as redirect uri than to reinvent 
> the wheel for each application, which is what that kind of callback url does. 
> Also, I'm not sure why that extra validation would improve things in 
> practice: if there is a vulnerability in the application routing code leading 
> to some vulnerable redirect, wouldn't it just be duplicated in that 
> validation step?
> 
> So, I'm tempted to go for 3, knowing we would have those mitigations:
> - checking at authorization server whether the redirect is to the same uri 
> the request originally came from
> - PKCE will restrict reuse of the authorization code anyway

I'm not sure PKCE does actually prevent all the issues here. Generally speaking 
the target for the redirect_uri should be a minimal page that just does the 
code exchange. That page should not be loading any content or large JS 
frameworks or adverts/social media integrations, etc. Otherwise the attack 
surface is enormous.

For example, if you are doing an OIDC flow for SSO then you do the code 
exchange on that page and then set a secure/http-only cookie or setup a service 
worker or a BFF or  If every single page in your app is potentially 
responsible for doing this code exchange then a single mistake by any developer 
can completely compromise the security of your site. Have one hardened endpoint 
that does this and performs the app-specific setup and then redirect from there 
using one of the patterns others have pointed out in this thread.

-- Neil

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

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-step-up-authn-challenge-12

[Neil Madden]

Surely "rogue" resource servers already have a lot of ways they can annoy their 
own users? Is this a realistic threat?

-- Neil

> On 2 Mar 2023, at 08:23, Valery Smyslov  wrote:
> 
> Thank you for pointing to the deployment consideration section, I re-read it 
> :-)
> This section is mostly concerned with accidental bad used experience
> caused by incompatible policies. My point is slightly different.
>  
> My point is that since this extension adds the possibility of an additional 
> interactive step
> needed for the client to get access to the resource, this gives rogue 
> resource servers
> a possibility to request this step even if in fact it is not needed, just to 
> annoy user
> (so, it is not due to incompatible policies, it is due to resource servers 
> intentional bad behavior).
> I think it’s worth to mention in the Security Considerations section,
> although I agree that the problem is minor.
>  
> Regards,
> Valery.
>  
>  
>  
> From: Vittorio Bertocci [mailto:vitto...@auth0.com] 
> Sent: Thursday, March 02, 2023 11:00 AM
> To: Valery Smyslov
> Cc: sec...@ietf.org; draft-ietf-oauth-step-up-authn-challenge@ietf.org; 
> last-c...@ietf.org; oauth@ietf.org
> Subject: Re: Secdir last call review of 
> draft-ietf-oauth-step-up-authn-challenge-12
>  
> Thanks for clarifying, I was indeed addressing the comment using DoS in its 
> canonical meaning.
> The possibility of bad user experience is indeed present, and it is more 
> general than just freshness: we do tackle that explicitly in the deployment 
> considerations section. Did you have a chance to read it? Is there anything 
> you would add to what we say there?
> thanks
> V. 
>  
> On Wed, Mar 1, 2023 at 10:34 PM Valery Smyslov  > wrote:
>> This message originated outside your organization.
>> 
>>  
>>  
>> Hi Vittorio,
>>  
>> when I used the term “DoS”, I was not thinking only about real DoS attacks 
>> (on computers), 
>> but also about “DoS”  attacks on humans. Consider the situation when the 
>> resource
>> server doesn’t accept *any* presented token asking for a fresher one. So, 
>> each time the client
>> attempts to get access to the resource, it have to contact the authorization 
>> server which may 
>> require user interaction, which may be very annoying for the user if it 
>> happens constantly.
>> Am I missing something?
>>  
>> Regards,
>> Valery.
>>  
>>  
>> Thank you Valery for the review!
>> The possibility of DOS is interesting. Here's the reasoning we followed when 
>> we opted not to mention it in the security considerations:
>> - The client going back to the AS isn't a new thing introduced by the step 
>> up spec, given that it's the expected behavior for insufficient_scope.
>> - if anything, step up might make it even harder to mount a DOS: the 
>> challenge presented by the client to the AS either results in user 
>> interaction, negating the possibility of using it as a component of a DOS 
>> attack, or results in an error, leaving the client unable to call the API 
>> and get any new challenges
>>  What do you think?
>> Thanks
>> V.
>>  
>> On Wed, Mar 1, 2023 at 2:05 AM Valery Smyslov via Datatracker 
>> mailto:nore...@ietf.org>> wrote:
>>> 
>>>   This message originated outside your organization.
>>> 
>>> 
>>> Reviewer: Valery Smyslov
>>> Review result: Has Issues
>>> 
>>> I have reviewed this document as part of the security directorate's ongoing
>>> effort to review all IETF documents being processed by the IESG.  These
>>> comments were written primarily for the benefit of the security area 
>>> directors.
>>> Document editors and WG chairs should treat these comments just like any 
>>> other
>>> last call comments.
>>> 
>>> The document introduces an extension to the OAuth protocol that allows 
>>> resource
>>> servers to signal to a client that the authentication event associated with 
>>> the 
>>> access token of the current request does not meet its authentication 
>>> requirements 
>>> and specify how to meet them.
>>> 
>>> The document is well written and easy to understand.
>>> 
>>> The Security Considerations section looks comprehensive. However, I think 
>>> that 
>>> one potential issue is not discussed - the possibility of DoS attacks.
>>> The protocol allows the resource server to send the client back to the 
>>> authorization 
>>> server for a "better" authentication token. In my opinion it opens a 
>>> possibility
>>> for rogue resource servers to mount a DoS attack by constantly requesting
>>> a "better" token. In my understanding a client should respect these replies 
>>> and each time should ask the authorization server for a "better" (e.g. 
>>> fresher) token. 
>>> Depending on the authentication mechanism involved this may be annoying for 
>>> the user 
>>> and put an additional load on both the client and the authorization server. 
>>> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oa

Re: [OAUTH-WG] OAUTH for Web Proxy authentication

[Neil Madden]

Right - RFC 6750 doesn't explicitly define how to send an access token with the 
Proxy-Authorization/Proxy-Authenticate headers, but states:

   The Bearer authentication scheme is intended primarily for
   server authentication using the WWW-Authenticate and Authorization
   HTTP headers but does not preclude its use for proxy authentication.

As far as I'm aware you can use it in a straightforward way with those headers 
for proxy auth, the same as for any other HTTP auth scheme (i.e., literally 
just rename the headers in the examples).

I think the sticking point will be how browsers respond to a Proxy-Authenticate 
header with scheme Bearer. I guess not very well, given that they won't know 
where the AS is. You'd need something like UMA's as_uri hint in the challenge 
and then you'd need to get browsers to implement that. 

It's not really clear what OAuth adds to this scenario anyway - there's no 
scope restriction going on, right? These days I guess most proxy usage is a 
single CONNECT and then its just a dumb tunnel for encrypted traffic - unless 
you're doing TLS interception, in which case I think the IETF and browser 
vendors won't be very interested - see e.g. RFC 7258 (Pervasive Monitoring Is 
an Attack).

-- Neil

> On 31 Jan 2023, at 09:47, Warren Parad  
> wrote:
> 
> Markus could you shed some light on how this would be different from the 
> normal OAuth flow between any resource server and the user agent? Proxies 
> today could already start accepting OAuth authorization following the OAuth 
> spec, right?
> 
> On Tue, Jan 31, 2023 at 12:48 AM Markus  > wrote:
> Hi Rifaat,
>  
> Right now a browser uses either basic , NTLM,  Kerberos or Negotiate 
> authentication to a proxy which are all old methods and not anymore 
> appropriate with Microsoft AD moving to Azure AD. Other methods like OAUTH 
> might now be more appropriate assuming enterprises still require proxy based 
> controls at their borders to the Internet.
>  
> Regards
> Markus
>  
> From: Rifaat Shekh-Yusef <>
> Sent: Monday, January 30, 2023 6:12 PM
> To: Markus <>
> Cc: oauth@ietf.org <> ; George Fletcher <>
> Subject: Re: [OAUTH-WG] OAUTH for Web Proxy authentication
>  
> Hi Markus,
>  
> As Goerge mentioned, there is no such document that covers this.
> What use case(s) do you have in mind for this?
>  
> Regards,
> Rifaat
>  
>  
> On Sat, Jan 28, 2023 at 7:50 PM Markus > wrote:
> Thank you.
>  
> Regards
> Markus
> From: George Fletcher <>
> Sent: Saturday, January 28, 2023 1:43 PM
> To: Markus; oauth@ietf.org <>
> Subject: Re: [OAUTH-WG] OAUTH for Web Proxy authentication
>  
> To my knowledge that spec doesn't exist. I'll let others chime in if they 
> have seen a proposal in that regard.
> 
> In regards to which working group, given the core topic is OAuth 
> authorization, I would present it here at a minimum.
> 
> Thanks,
> George
> 
> On 1/22/23 7:06 AM, Markus PlusNet wrote:
>> Dear WG,
>>  
>> I am new to oauth and wonder which WG would be responsible for reviewing 
>> a Spec for Proxy authentication 
>> https://httpwg.org/specs/rfc9110.html#auth.client.proxy 
>>  using oauth or 
>> does that spec already exist ?
>>  
>> Thank you
>> Markus
>>  
>> 
>> 
>> ___
>> 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 
> 
> ___
> 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

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

Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

[Neil Madden]

On 20 Jan 2023, at 18:47, Brian Campbell  wrote:Hi Mark,Thanks for the review and feedback. I am aware of HTTP Structured Fields and certainly see value in it - even using it in some other work in which I'm involved. However, I'm unsure of its fit or utility for this draft. With that said, I've tried to reply more specifically to your comments inline below. On Wed, Jan 18, 2023 at 3:32 PM Mark Nottingham 40mnot@dmarc.ietf.org> wrote:A few things caught my eye in this document:

- Section 4.1 defines the DPoP header field as a JWT, which (as I understand it) is a base64-encoded string. If that's the case, I'd recommend making it a Structured Field Item (see RFC8941 s 3.3) with a fixed type of Byte Sequence (s 3.3.5). That will require changing the syntax to add a prefix and suffix of ":".As Justin pointed out, a JWT is three Base64url encoded segments delimited by the `.` period character, which means it can't be a SF Byte Sequence.  As DW pointed out, a JWT just happens to always start with a letter because the first segment is always encoded JSON, so will always start with 'ey'. So the DPoP header field value does just happen to fit the SF Token syntax, But the SF Token syntax does very little regarding the validity of the JWT. Being quite pedantic here, the JWT header is allowed to have preceding whitespace so it might not always start ‘eY’. That said, to be non-alphabetic the first 6 bits would need to be > 52, which in particular means the msb of the first byte would have to be set - implying a multibyte UTF-8 sequence. JSON only allows space, tab, newline, or carriage return before the opening brace so I think we’re still good. (I don’t think I’ve ever seen a JWT in the wild that didn’t start eY). — Neil___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Informal RFC: DPoP using ECDH + HMAC instead of DSA

[Neil Madden]

Well, you could do all of these things, but additional DH computations have a cost and so they need to be justified. Adding in a server static key provides authentication of the server, which could provide defence in depth against a MITM attack (as you say), but such a MITM attack assumes HTTPS has already been compromised - so this only adds value if the client obtains the server’s static public key over some channel other than TLS. Likewise, including the client static key in the DH computation requires the RS to obtain the client’s static public key from somewhere - something that isn’t required currently. I am actually working on something that is relevant to this discussion, which does indeed provide mutual authentication (and forward secrecy), but it’s not yet ready for publication. (You can get some idea by reading https://neilmadden.blog/2021/04/08/from-kems-to-protocols/ and the previous two articles). However, as Brian says, the OAuth WG has already looked at a similar proposal and rejected it (or rather, not enthusiastically endorsed it). So I think the biggest barriers are not technical but putting in the work to convince people why this is a good idea. As DPoP is there now and mostly good enough, I suspect that will be a hard sell. — NeilOn 6 Jan 2023, at 04:55, Zack Voase  wrote:One potential mitigation is multiple DH, where the server has a static key *and* ephemeral key. Then the shared secret for HMAC becomes:    KDF(DH(client_ephemeral, server_static) || DH(client_ephemeral, server_ephemeral))For the cost of an additional client <-> server interaction (to share the public half of the server ephemeral key), you get these benefits:* Harder for an attacker to pull off a simple MITM because the static server key should be 'well known' (i.e. obtained by the client out of band of the OAuth flow itself)* Harder for an attacker in possession of the server static key to impersonate clients to the server, because they would need the server ephemeral private key (and I'm assuming/hoping that'd be stored elsewhere).You could also replace the OAuth 2.0 'client secret' with a client static key, and then you'd build the shared secret as:    KDF(DH(client_ephemeral, server_static) || DH(client_static, server_ephemeral) || DH(client_ephemeral, server_ephemeral))To me, this just starts to resemble existing protocols for secure messaging with forward secrecy. How far is it worth taking this before we're building OAuth 3.0/'mutual' OAuth? (I'm half joking and half serious)On Thu, Jan 5, 2023, at 15:37, Neil Madden wrote:Right. A key difference between what I proposed and what Zack is proposing, as I understand it, is that in my proposal the server (RS) challenges the client with a fresh ephemeral public key (periodically or once per session, according to server policy). In Zack’s proposal the server has a static public key that is shared between all clients. This is more efficient but has some downsides:Firstly, the use of an ephemeral challenge ensures freshness, which prevents replay attacks. Part of the reason for my proposal was to avoid the need for timestamps, server-side blocklists, nonces, etc. If the RS key pair is static then you don’t get this nice property. Secondly, and more seriously, ECDH with a static key-pair is vulnerable to an attack known as key compromise impersonation (KCI). If the server’s private key is compromised, the attacker can not only impersonate the RS to any client, but can also impersonate any client when talking to the RS. So compromising the RS private key becomes an attractive target, requiring significant investment in countermeasures (HSMs etc). (This attack is not relevant for ECDH-ES normally because it is an attack against authentication and that encryption mode is unauthenticated anyway in its intended use). Cheers,NeilPS - I like K-PoP!On 5 Jan 2023, at 00:20, Brian Campbell  wrote:Hi Zack,For whatever it's worth, HMAC PoP has been discussed in the past (in a few different 
incarnations). Neil Madden put forth the idea of a somewhat similar sounding Diffie-Hellman style 
approach https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/, which I sort of proposed as an option to the WG back when DPoP was being considered for adoption (slide 8 of https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf). But there wasn't much interest at the time https://mailarchive.ietf.org/arch/msg/oauth/X-Fy2R3RqkP5lLDBuR820s3H-uE/ at least compared to working on DPoP w/ signatures. It's an interesting idea though 
and although it got sidelined I'd already started thinking about a name 
for it - KPoP, nominally for something like Key Agreement based Proof-of-Possession.  Of course, Korean pop music already laid claim to the name K-pop so that might not be good for searchability. But I digress

Re: [OAUTH-WG] Informal RFC: DPoP using ECDH + HMAC instead of DSA

[Neil Madden]

Right. A key difference between what I proposed and what Zack is proposing, as I understand it, is that in my proposal the server (RS) challenges the client with a fresh ephemeral public key (periodically or once per session, according to server policy). In Zack’s proposal the server has a static public key that is shared between all clients. This is more efficient but has some downsides:Firstly, the use of an ephemeral challenge ensures freshness, which prevents replay attacks. Part of the reason for my proposal was to avoid the need for timestamps, server-side blocklists, nonces, etc. If the RS key pair is static then you don’t get this nice property. Secondly, and more seriously, ECDH with a static key-pair is vulnerable to an attack known as key compromise impersonation (KCI). If the server’s private key is compromised, the attacker can not only impersonate the RS to any client, but can also impersonate any client when talking to the RS. So compromising the RS private key becomes an attractive target, requiring significant investment in countermeasures (HSMs etc). (This attack is not relevant for ECDH-ES normally because it is an attack against authentication and that encryption mode is unauthenticated anyway in its intended use). Cheers,NeilPS - I like K-PoP!On 5 Jan 2023, at 00:20, Brian Campbell  wrote:Hi Zack,For whatever it's worth, HMAC PoP has been discussed in the past (in a few different 
incarnations). Neil Madden put forth the idea of a somewhat similar sounding Diffie-Hellman style 
approach https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/, which I sort of proposed as an option to the WG back when DPoP was being considered for adoption (slide 8 of https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf). But there wasn't much interest at the time https://mailarchive.ietf.org/arch/msg/oauth/X-Fy2R3RqkP5lLDBuR820s3H-uE/
 at least compared to working on DPoP w/ signatures. It's an interesting idea though 
and although it got sidelined I'd already started thinking about a name 
for it - KPoP, nominally for something like Key Agreement based Proof-of-Possession.  Of course, Korean pop music already laid claim to the name K-pop so that might not be good for searchability. But I digress on names. Anyway, I don't know how useful this rambling is for you but it seemed worthwhile to mention some of the prior ideas and discussion on seemingly similar stuff. On Wed, Jan 4, 2023 at 4:30 PM Zack Voase 40meat...@dmarc.ietf.org> wrote:Hi OAuth list,

Hopefully this is the right place for this message. I wanted to surface an idea for an alternative DPoP approach to the current one based on digital signatures. I'm looking for feedback to determine whether it's worth investigating further or writing up a proper RFC. Is there anything that I'm overlooking about this scheme that would make it insecure, infeasible, or undesirable?

The idea is that rather than proof-of-possession being demonstrated by asymmetric digital signatures attached to each request, it is demonstrated by an HMAC, with the shared secret for the HMAC derived by ECDH-ES[0] between the client and the server. For the purpose of this informal RFC, I'll refer to the existing protocol as DPoP-DSA, and my proposed protocol as DPoP-DH-HMAC.

Similar to DPoP-DSA, the client would need its own asymmetric key pair, and ideally this would be ephemeral (scoped to the life of a single 'session', access token, or refresh token). The server would also need a key pair, but static and well-known (probably published in a JWKS). Optionally, the authorization server and resource server(s) could have distinct keys from each other, and the client would derive the appropriate HMAC secret for the server it's communicating with.

The protocol would look very similar to DPoP-DSA, except that DPoP proofs would be HS256-signed JWTs. I'm not entirely sure what the other JWT header keys should look like, since the JSON Web Algorithms spec only allows specification of ECDH-ES for agreeing on content encryption or wrapping keys, not shared secrets for HMACs. Ideally JWS/JWT syntax could be extended to allow a similar format as in RFC 7518 Appendix C (https://www.rfc-editor.org/rfc/rfc7518.html#appendix-C), but for this kind of application. Furthermore, RFC 7518 recommends the use of Concat KDF for final key derivation from the ECDH-ES agreed key, but Concat KDF is not available in any common Web Crypto API implementations. HKDF, however, is—maybe that should be used instead?

Pros


* HMAC-SHA256 computation is substantially cheaper than EC/RSA signing and verifying. With good (and hopefully secure) caching, the ECDH-ES key agreement algorithm only needs to be done once per access token on each of the client and server. In most cases the one-time cost of secret derivation can be amortized ov

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Neil Madden]

> On 2 Aug 2022, at 21:04, Mike Jones  wrote:
> 
> 
> Neil, you wrote:
> "SD-JWT is not simpler. Anyway, I think I have learnt enough from this 
> thread, we don’t have to keep arguing the same points. I think the claims of 
> combinatorial explosion are somewhat exaggerated and I don’t see compelling 
> evidence of a real world need for selective disclosure in OAuth, so I don’t 
> support this draft."
>  
> Speculatively issuing JWTs with combinations of claims because they might be 
> used in the future might be a fine strawman proposal to score debating points 
> but is hardly a practical engineering solution.

Why would it be speculative? 

>   Whereas SD-JWT meets the needs of JSON-based use cases for selective 
> disclosure using the issuer/holder/verifier pattern, including those for ISO 
> Mobile Driver's Licenses.

As far as I can see mobile driving licenses are the *only* concrete use case 
that has been mentioned so far. Did I miss one?

Given that the goal is to reproduce “the user experience of presenting 
credentials in-person”, let’s look at one. My driving license lists the 
following information:

* a unique driver id (which itself encodes part of my name, dob, and a 
male/female bit)
* full name
* address
* date and country of birth
* license issuer, issued-at and expiry dates
* the categories of vehicle I’m entitled to drive

ISO mobile drivers’ licenses are supposed to be unlinkable so the driver ID is 
out. The expiry and issued-at probably shouldn’t be able to be selectively 
non-disclosed. So that only leaves 5 fields: full name, address, date of birth, 
country of birth, and categories of vehicle. 

So even if you issued a separate JWT for each field, that’s only 5 JWTs. Why is 
that not practical? 

— Neil

>  
> That's why I support adoption.
>  
>    -- Mike
>  
> From: OAuth  On Behalf Of Neil Madden
> Sent: Tuesday, August 2, 2022 2:16 AM
> To: Kristina Yasuda 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT
>  
>  
> On 2 Aug 2022, at 03:20, Kristina Yasuda 
>  wrote:
>  
> I support adoption.
>  
> To add some color. 
>  
> One of the use-cases is a flow where issuance of a user credential 
> (collection of user claims) is decoupled from presentation (where both 
> issuance and presentation of a user credential are done using extensions of 
> OAuth flows). The goal of this decoupling is to avoid “issuer call home”, 
> where the user can send a user credential directly to the RP, without RP 
> needing to contact the Issuer directly.
>  
> So what’s the plan for revocation in this scenario? Something like OCSP 
> Stapling? Short-lived tokens? Either way, the client will need to go back to 
> the issuer regularly.
> 
> 
> So the motivations are not limited to offline scenarios, but are applicable 
> to the scenarios that want to recreate in the online environment, the user 
> experience of presenting credentials in-person.
>  
> I’m not sure why this would be a goal. Presenting credentials in person is 
> subject to many constraints that just don’t apply in the digital world.
> 
> 
>  
> Driver’s Licence just happens to be an example familiar to many, and there is 
> no reason it cannot be a diploma, or an employee card, or a training 
> certificate, etc. But it is worth highlighting that SD-JWT work becomes 
> critical if we are to enable ISO-compliant mobile Driver Licences expressed 
> in JSON to enable online scenarios and make life of the Web developers easier 
> (as opposed processing data encoded as CBOR and signed as a COSE message). 
> Selective disclosure is a requirement in many government issued credentials, 
> while the usage of advanced cryptography is not always encouraged by the 
> national cybersecurity agencies.
>  
> I’m not sure what any of this has to do with OAuth?
>  
>  
> Regarding an approach where issuer issues multiple JWTs of a same type but 
> with different subset of claims, it is not an ideal way to do selective 
> disclosure with JWTs (type as a way to differentiate credential with one data 
> structure/syntax from another). It complicates implementations that try to 
> provide RP-U unlinkability (RPs cannot collude to track the user). The 
> simplest way to achieve unlinkability with JWTs without using advanced 
> cryptography is to issue multiple credentials of the same type but with 
> varying use identifiers and enable pairwise identifiers per RP. Now there are 
> multiple copies of each JWT with subset of claims of the same type. This 
> greatly complicates presentation of these credentials too – since credentials 
> are of the same type, now wallet needs to manage the combination of a subset 
> of claims + pair

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Neil Madden]

> On 2 Aug 2022, at 03:20, Kristina Yasuda 
>  wrote:
> 
> I support adoption.
>  
> To add some color. 
>  
> One of the use-cases is a flow where issuance of a user credential 
> (collection of user claims) is decoupled from presentation (where both 
> issuance and presentation of a user credential are done using extensions of 
> OAuth flows). The goal of this decoupling is to avoid “issuer call home”, 
> where the user can send a user credential directly to the RP, without RP 
> needing to contact the Issuer directly.

So what’s the plan for revocation in this scenario? Something like OCSP 
Stapling? Short-lived tokens? Either way, the client will need to go back to 
the issuer regularly.

> So the motivations are not limited to offline scenarios, but are applicable 
> to the scenarios that want to recreate in the online environment, the user 
> experience of presenting credentials in-person.

I’m not sure why this would be a goal. Presenting credentials in person is 
subject to many constraints that just don’t apply in the digital world.

>  
> Driver’s Licence just happens to be an example familiar to many, and there is 
> no reason it cannot be a diploma, or an employee card, or a training 
> certificate, etc. But it is worth highlighting that SD-JWT work becomes 
> critical if we are to enable ISO-compliant mobile Driver Licences expressed 
> in JSON to enable online scenarios and make life of the Web developers easier 
> (as opposed processing data encoded as CBOR and signed as a COSE message). 
> Selective disclosure is a requirement in many government issued credentials, 
> while the usage of advanced cryptography is not always encouraged by the 
> national cybersecurity agencies.

I’m not sure what any of this has to do with OAuth?
 
>  
> Regarding an approach where issuer issues multiple JWTs of a same type but 
> with different subset of claims, it is not an ideal way to do selective 
> disclosure with JWTs (type as a way to differentiate credential with one data 
> structure/syntax from another). It complicates implementations that try to 
> provide RP-U unlinkability (RPs cannot collude to track the user). The 
> simplest way to achieve unlinkability with JWTs without using advanced 
> cryptography is to issue multiple credentials of the same type but with 
> varying use identifiers and enable pairwise identifiers per RP. Now there are 
> multiple copies of each JWT with subset of claims of the same type. This 
> greatly complicates presentation of these credentials too – since credentials 
> are of the same type, now wallet needs to manage the combination of a subset 
> of claims + pairwise identifier…

The same is needed in SD-JWT - the wallet needs to manage pairwise identifiers 
and which subset of claims to disclose.

>  
> What if the implementation also wants predicates property, where age_over_XX 
> boolean is sent instead of a birthdate string? The simplest way to do 
> predicates with JWTs without using advanced cryptography is to have issuers 
> to issue multiple age_over_xx booleans so that an appropriate one can be 
> selectively disclosed to the RP. How many “JWTs with subset of claims” does 
> the issuer needs to issue to account for all possible age requirements? Note 
> that it’s not just age_over_21 to start gambling, it’s also age_over_65 to 
> get pension benefits. 

Being over 65 also proves that you are over 21.

>  
> Managing the combinatorial explosion of sets of claims in speculatively 
> issued JWTs, many of which will never be used, seems unwieldy, to say the 
> least. "A conventional JWT with a subset of claims" approach could be taken 
> in some implementations, but it should not prevent a simpler, extensible 
> alternative of SD-JWT.

SD-JWT is not simpler. Anyway, I think I have learnt enough from this thread, 
we don’t have to keep arguing the same points. I think the claims of 
combinatorial explosion are somewhat exaggerated and I don’t see compelling 
evidence of a real world need for selective disclosure in OAuth, so I don’t 
support this draft.

>  
>  
> Finally, as Giuseppe pointed out, an option to blind claim names is on the 
> table. As discussed on this list previously, we should analyze privacy 
> properties of the mechanism and decide if we want to mandate it – which can 
> be discussed after the adoption.
>  
> Best,
> Kristina
> 

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

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Neil Madden]

license is 100% digital.
>>>>> 
>>>>> The officer wants to know if you live in the area, or if you are from out 
>>>>> of state. You don't want to tell the police officer your name, you click 
>>>>> some magic buttons on your device, and a QR code pops up. This QR code 
>>>>> contains only:
>>>>> "id_token" with salted fields
>>>>> selective disclosure for: address city + state
>>>>> 
>>>>> The police officer's magic new special SD-JWT device tells them you have 
>>>>> a valid driver's license and that you live in the area. The officer is 
>>>>> either:
>>>>> Okay with that
>>>>> Asks for further disclosure, which you can agree to or risk being 
>>>>> arrested and brought in for questioning.
>>>>> 
>>>>> Hypothetical 2:
>>>>> You live in the US and going out to a bar. Bars in the US are infamous 
>>>>> for carding people. You want to tell them that you are over 21, but don't 
>>>>> want to tell them anything else. So you take out your digital wallet and 
>>>>> show them a QR code that only contains:
>>>>> "id_token" with salted fields
>>>>> selective disclosure for: over 21
>>>>> The bouncer uses their magic new SD-JWT device to verify that 
>>>>> information, and can either say:
>>>>> That's sufficient, come on in
>>>>> I don't believe that is yours, I need to see your picture (including 
>>>>> details), your name as well as another form of identification.
>>>>> 
>>>>> Problem from 2:
>>>>> The bouncer says, I need to know you have been vaccinated against covid 
>>>>> in the last 6 months. Here's where things start to get challenging, did 
>>>>> the issuer have this information available to create a claim that could 
>>>>> be selectively disclosed?
>>>>> 
>>>>> Do we need to maintain a registry of all the allowed claims, or are 
>>>>> countries some how going to be on top of this?
>>>>> 
>>>>> What happens when different countries have different "standard claims"?
>>>>> 
>>>>> 
>>>>> On Mon, Aug 1, 2022 at 1:29 PM David Chadwick 
>>>>>  wrote:
>>>>>> 
>>>>>>> On 01/08/2022 11:55, Neil Madden wrote:
>>>>>>> I agree with many of these points that Jaimandeep Singh raises. 
>>>>>>> 
>>>>>>> It would be good to know exactly what the intended use-cases within 
>>>>>>> OAuth are. In particular, in OAuth it’s normally the case that the 
>>>>>>> client is relatively untrusted and a privacy goal is to avoid revealing 
>>>>>>> information/PII to the client unnecessarily. In SD-JWT it seems that 
>>>>>>> this is turned on its head somewhat and we trust the client (holder) 
>>>>>>> with everything and instead want to keep some information private from 
>>>>>>> the resource servers?
>>>>>>> 
>>>>>>> I think there are also some questions about exactly which claims can be 
>>>>>>> selectively disclosed - e.g., it would be a very bad idea to allow 
>>>>>>> security constraints like “exp”, “aud” or “cnf” to be selectively (not) 
>>>>>>> disclosed. But the problem is that the set of security constraints is 
>>>>>>> not fixed in any way, and new ones may be added by future specs or 
>>>>>>> application-specific ones. So the issuer will need to be careful not to 
>>>>>>> allow such constraints to be selectively disclosed.
>>>>>>> 
>>>>>>> Ultimately, I just don’t find this idea of fine-grained pick ’n’ mix 
>>>>>>> selective disclosure of individual claims to be very compelling 
>>>>>>> compared to the much simpler solution of just issuing multiple JWTs in 
>>>>>>> the first place (with appropriate subsets of claims in them). 
>>>>>> +1. This is exactly what we do
>>>>>> 
>>>>>> David
>>>>>> 
>>>>>>> 
>>>>>>> — Neil
>>>>>>> 
>>>>>>>> On 29 Jul 2022, at 03:15, Jaimandeep Singh 
>&g

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Neil Madden]

I agree with many of these points that Jaimandeep Singh raises. 

It would be good to know exactly what the intended use-cases within OAuth are. 
In particular, in OAuth it’s normally the case that the client is relatively 
untrusted and a privacy goal is to avoid revealing information/PII to the 
client unnecessarily. In SD-JWT it seems that this is turned on its head 
somewhat and we trust the client (holder) with everything and instead want to 
keep some information private from the resource servers?

I think there are also some questions about exactly which claims can be 
selectively disclosed - e.g., it would be a very bad idea to allow security 
constraints like “exp”, “aud” or “cnf” to be selectively (not) disclosed. But 
the problem is that the set of security constraints is not fixed in any way, 
and new ones may be added by future specs or application-specific ones. So the 
issuer will need to be careful not to allow such constraints to be selectively 
disclosed.

Ultimately, I just don’t find this idea of fine-grained pick ’n’ mix selective 
disclosure of individual claims to be very compelling compared to the much 
simpler solution of just issuing multiple JWTs in the first place (with 
appropriate subsets of claims in them). 

— Neil

> On 29 Jul 2022, at 03:15, Jaimandeep Singh 
>  wrote:
> 
> Dear All,
> 1. At the outset I must compliment  Daniel Fett and Kristina Yasudafor and 
> all the contributors for the wonderful work done on SD-JWT.
> 2. However, in my opinion there is no clear motivation for using SD-JWT in 
> the present oAuth 2.0/2.1 ecosystem. We already have JWS and JWE which more 
> or less satisfy the requirements.
> 3. The focus and time of the WG-OAUTH should be more aligned to the work 
> directly impacting the improvements or BCP in the oAuth 2.0/2.1 specs.
> 4. WG-JWP (JSON Web Proofs) may be a more suitable place for the adoption of 
> SD-JWT as they are working on a similar set of problems. They are actively 
> seeking participation in the area of SD-JWT.
> 5. In view of above I am presently not in favour of its adoption in WG-OAUTH. 
> 
> Regards
> Jaimandeep Singh
> 
> On Fri, Jul 29, 2022 at 6:43 AM Brian Campbell 
>  > wrote:
> I support adoption.
> 
> On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef  > wrote:
> All,
> 
> This is a call for adoption for the SD-JWT document
> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/ 
> 
> 
> Please, provide your feedback on the mailing list by August 12th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 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
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> ___
> 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] .well-known/jwks.json and constrained-voucher and RFC7517

[Neil Madden]

> On 12 Jul 2022, at 20:26, Michael Richardson  wrote:
> 
> 
> EXEC-SUM: /.well-known/jwks.json seems in use, but not registered
>  with IANA.   I don't know if it's appropriate for my use.
>  Seems to contain RFC7517 content.

A limitation of the JWKSet format is that it provides no way to designate which 
keys in the set are intended for what function. For example if I have some keys 
I use for signing OIDC id tokens and another set of keys I use for signing 
software updates, there is no way to distinguish them if they are all in a 
single JWKSet (unless those functions use different algorithms). It is 
therefore wise to have distinct JWKSets published on distinct URIs for distinct 
functionality. A single well-known jwks.json is putting all your keys in one 
basket and will inevitably (IMO) lead to problems, maybe even security issues. 

(I have seen some software use the “kid” to indicate purpose, but if you 
support key rotation then you’ll end up with duplicate “kid” values, which 
causes issues in some client software).

— Neil

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

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

[Neil Madden]

> On 28 Jun 2022, at 10:28, Neil Madden  wrote:
> 
> 
>> On 28 Jun 2022, at 08:37, Daniel Fett > <mailto:fett=40danielfett...@dmarc.ietf.org>> wrote:
>> 
>> […]
>> 
>>> 
>>> The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length extension 
>>> attacks is also troubling, even if I can’t see an immediate attack. But 
>>> it’s a weird property that Bob, for example, could make a commitment to 
>>> some extension of one of Alice’s claims without actually knowing her claim 
>>> value.
>> That would mean the Bob would need to be an issuer in this case? 
> 
> Well, that depends on whether the claims are blinded from the issuer too or 
> not? I don’t think the draft specifies this at the moment. I can imagine a 
> privacy-oriented OIDC OP that only stores/sees blinded identity claims for 
> example.

Ah, I’ve just seen in section 5.1.1 that the issuer actually hashes a JSON 
array rather than the raw concatenation of the salt and the claim value, so 
this is not vulnerable to length extension anyway. That section also addresses 
my other comments about entropy and unique salts per claim. I’d still recommend 
using HMAC anyway, for the reasons I added in my last message, but it’s not as 
urgent.

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

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

[Neil Madden]

> On 28 Jun 2022, at 08:37, Daniel Fett  
> wrote:
> 
> […]
> 
>> 
>> The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length extension 
>> attacks is also troubling, even if I can’t see an immediate attack. But it’s 
>> a weird property that Bob, for example, could make a commitment to some 
>> extension of one of Alice’s claims without actually knowing her claim value.
> That would mean the Bob would need to be an issuer in this case? 

Well, that depends on whether the claims are blinded from the issuer too or 
not? I don’t think the draft specifies this at the moment. I can imagine a 
privacy-oriented OIDC OP that only stores/sees blinded identity claims for 
example.

>> 
>> You can address both of these issues by instead using a compactly committing 
>> PRF [1], such as HMAC- i.e., HMAC-HASH(SALT, CLAIM-VALUE) rather than simple 
>> prefix hash.
> Given the advantages, we will consider using an HMAC. 

Great, I think using HMAC just eliminates any concerns, however remote. This 
use of HMAC is also identical to HKDF-Extract, which has quite a lot of 
argument backing it up for being a strong computational extractor, where simple 
hashes are often not (see RFC 5869 and particularly the original paper it links 
to, which discusses these topics in depth).

[…]

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

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

[Neil Madden]

I’m not entirely sure the OAuth WG is a suitable venue for this kind of 
document. It should at least get some review from CFRG, to get feedback on the 
crypto aspects.

I have some initial comments about the cryptography being used. 

Commitments to claim values are of the form HASH(SALT | CLAIM-VALUE), but this 
does not necessarily commit the sender to CLAIM-VALUE. In section 7.4, I think 
you need to say that HASH must be collision resistant - otherwise the user can 
find two (salt, claim-value) pairs that collide and get the issuer to sign one 
and then reveal the other pair to the downstream party.

The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length extension 
attacks is also troubling, even if I can’t see an immediate attack. But it’s a 
weird property that Bob, for example, could make a commitment to some extension 
of one of Alice’s claims without actually knowing her claim value.

You can address both of these issues by instead using a compactly committing 
PRF [1], such as HMAC- i.e., HMAC-HASH(SALT, CLAIM-VALUE) rather than simple 
prefix hash.

It doesn’t seem great to say that you can use any hash algorithm in the IANA 
registry, but then to rule out half of them as being not suitable in the 
security considerations - this list may go out of date as other hash algorithms 
are broken. Is it possible to update the IANA registry with a Recommended Y/N 
column? Also, shake128 and shake256 are not collision-resistant hash functions, 
they are XOFs that can produce any length of output - e.g. shake128 with a 
32-bit output would not be collision-resistant and thus would not be at all 
suitable for this usage. Given these considerations, I might be tempted to 
create a new IANA registry, or perhaps just pick one good hash function. (Or 
maybe just use the same hash algorithm as the signature?)

Also, I don’t think the security considerations currently say anywhere that 
salt values should be distinct for each claim. Obviously that is quite a 
crucial requirement!


[1]: https://link.springer.com/content/pdf/10.1007/978-3-319-63697-9_3.pdf 
 

— Neil

> On 23 Jun 2022, at 17:32, Daniel Fett  
> wrote:
> 
> All,
> 
> Kristina and I would like to bring to your attention a new draft that we have 
> been working on with many others over the past weeks. "Selective Disclosure 
> JWT (SD-JWT)" describes a format for signed JWTs that support selective 
> disclosure (SD-JWT), enabling sharing only a subset of the claims included in 
> the original signed JWT instead of releasing all the claims to every 
> verifier. 
> 
> https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html
>  
> 
> 
> Initial feedback we got was positive and we now would like to hear from the 
> working group with the eventual goal of asking for   working group 
> adoption.
> 
> Issues are tracked in our GitHub repository: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues 
> 
> 
> The approach to selective disclosure described in the document is based on 
> salted hashes. We have discussed and explored other approaches based on 
> encryption as well. If you are interested in following this discussion, we 
> would like to invite you to read this issue: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30 
> 
> 
> One main goal with this work is that the format should be easy to implement, 
> requiring little more than a regular JWT library. Three working 
> implementations show that this goal has been achieved: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations 
> 
>  
> 
> We are looking forward to your feedback!
> 
> -Daniel
> 
> 
> ___
> 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] DPoP JWT claims

[Neil Madden]

Is that actually true? The DPoP spec itself is a case in point: it reuses the 
existing OIDC “nonce” claim but explicitly says that DPoP nonces are not like 
OIDC nonces (section 9):

“ Developers should also take care to not
   confuse DPoP nonces with the OpenID Connect [OpenID.Core] ID Token
   nonce.”

The official IANA registration of “nonce” says:

Value used to associate a Client session with an ID Token

Does this matter? If not, does it matter if some other spec defines a “htm” 
claim with different meaning? 

> On 16 Jun 2022, at 20:50, Dick Hardt  wrote:
> 
> 
> Registering the names provides clarity on use and avoids confusion on the 
> meaning of a claim — ie two specs won’t have conflicting definitions of “htm”
> 
>> On Thu, Jun 16, 2022 at 10:20 AM Warren Parad 
>>  wrote:
>> I think the registration really helps with discovery, especially as an 
>> implementer. When you see or observe these claims in a JWT, you can google 
>> them potentially returning no results. If you know about the IANA registry 
>> you can find them, even if you don't know that the tokens have anything to 
>> do with DPoP.
>> 
>>> On Thu, Jun 16, 2022 at 6:21 PM Neil Madden  
>>> wrote:
>>> The DPoP spec registers the “htm”, “htu”, and “ath” claims [1]. But do 
>>> these claims actually make sense outside of a DPoP proof? Presumably the 
>>> risk of naming collision within a DPoP proof is pretty small, so is there 
>>> any benefit to registering them rather than just using them as private 
>>> claims? 
>>> 
>>> (I guess I could ask the same question about lots of other entries in the 
>>> current registry at IANA, many of which look completely app-specific to me).
>>> 
>>> [1]: 
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#section-12.7 
>>> 
>>> — Neil
>>> ___
>>> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] DPoP JWT claims

[Neil Madden]

The DPoP spec registers the “htm”, “htu”, and “ath” claims [1]. But do these 
claims actually make sense outside of a DPoP proof? Presumably the risk of 
naming collision within a DPoP proof is pretty small, so is there any benefit 
to registering them rather than just using them as private claims? 

(I guess I could ask the same question about lots of other entries in the 
current registry at IANA, many of which look completely app-specific to me).

[1]: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#section-12.7 
 

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

Re: [OAUTH-WG] Call for adoption - Step-up Authentication

[Neil Madden]

I support adoption of this draft. I’m still digesting the details, but it seems 
like a good problem to solve.

— Neil

> On 26 Apr 2022, at 11:46, Rifaat Shekh-Yusef  wrote:
> 
> This is a call for adoption for the Step-up Authentication document
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-step-up-authn-challenge/
>  
> 
> 
> Please, provide your feedback on the mailing list by May 10th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> 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

[OAUTH-WG] Fwd: WGLC for DPoP Document

[Neil Madden]

Forgot to reply to the list:

> I support publication.
> 
> — Neil
> 
>> On 28 Mar 2022, at 13:01, Rifaat Shekh-Yusef > > wrote:
>> 
>> All,
>> 
>> As discussed during the IETF meeting in Vienna last week, this is a WG Last 
>> Call for the DPoP document:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ 
>> 
>> 
>> Please, provide your feedback on the mailing list by April 11th.
>> 
>> Regards,
>>  Rifaat & Hannes
>> 
>> ___
>> 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] Second WGLC for JWK Thumbprint URI document

[Neil Madden]

I also support publication of the new draft (the 01 revision, not the 00 
revision linked to in this WGLC! I assume that’s just a mistake).

— Neil

> On 23 Feb 2022, at 08:59, Vladimir Dzhuvinov  wrote:
> 
> +1 in support for publication.
> 
> The Nimbus JWT lib was recently updated to match the 01 spec with the hash 
> alg in the URN.
> 
> Vladimir Dzhuvinov
> On 21/02/2022 15:12, Rifaat Shekh-Yusef wrote:
>> All,
>> 
>> Mike and Kristina made the necessary changes to address all the great 
>> comments received during the initial WGLC.
>> 
>> This is a second WG Last Call for this document to make sure that the WG has 
>> a chance to review these changes:
>> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html 
>> 
>> 
>> Please, provide your feedback on the mailing list by March 7th.
>> 
>> Regards,
>>  Rifaat & Hannes
>> 
>> 
>> ___
>> 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

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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Neil Madden]

Thanks, these changes address my comments. I am happy with the new draft text.

Cheers,

Neil

> On 15 Feb 2022, at 00:33, Kristina Yasuda 
>  wrote:
> 
> Hi All,
>  
> Thank you very much for the constructive feedback.
> We have tried to address the WGLC comments received to date with the latest 
> draft published 
> athttps://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01
>  
> .
>  
> Following are updates made to the document:
> - Added security considerations about multiple public keys coresponding to 
> the same private key. 
> - Added hash algorithm identifier after the JWK thumbprint URI prefix to make 
> it explicit in a URI which hash algorithm is used.
> - Added reference to a registry for hash algorithm identifiers. 
> - Added SHA-256 as a mandatory to implement hash algorithm to promote 
> interoperability.
>  
> Kindest Regards,
> Kristina 
>  
> From: OAuth  On Behalf Of Rifaat Shekh-Yusef
> Sent: Wednesday, February 2, 2022 4:19 AM
> To: oauth 
> Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>  
> All,
>  
> The JWK Thumbprint URI document is a simple and straightforward specification.
>  
> This is a WG Last Call for this document:
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html 
> 
>  
> Please, provide your feedback on the mailing list by Feb 16th.
>  
> Regards,
>  Rifaat & Hannes
>  
>  
> ___
> 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] [EXTERNAL] Re: WGLC for JWK Thumbprint URI document

[Neil Madden]

Hi Mike,

> On 4 Feb 2022, at 15:30, Mike Jones 
>  wrote:
> 
> 
> Neil, thanks for your review.  First, you wrote:
>  
> > Using a (hash of a) public key as an identifier is an idea that has 
> > historically been subject to various attacks such as unknown key share 
> > attacks, as well as issues due to malleable signature schemes or key 
> > exchange schemes - where the same proof of identity is valid under many 
> > public keys. The security considerations should mention these issues, and 
> > potential suggest countermeasures (eg including the full public key JWK in 
> > the input to be signed etc).
>  
> I’m not all that familiar with the attacks you’re referencing.  Is there I 
> write-up on them that you could refer me and the other working group members 
> to so we can better understand them?  And ideally, could you write up a 
> paragraph or two on them that you’d like us to include in the Security 
> Considerations?

I’ll have a look and see if there is a concise write up somewhere. To give you 
an idea, here are some potential attacks:

Firstly, in ECDSA for example each signature is typically valid for at least 
two public keys, and these keys can be easily recovered from the signature 
itself [1]. So if Alice is using an ECDSA signature as proof of her identity, 
and her identity is a (hash of a) public key, then it is also a valid proof of 
identity for a different identity (different JWK thumbprint). This makes an 
authentication scheme based on this ambiguous, which is not usually a good 
thing.

A similar thing can happen with ECDH-based key exchanges or authenticated 
encryption schemes (like my own ECDH-1PU) with certain elliptic curves. In this 
case you can add “points of small order” to a public key to derive a new public 
key that will produce the same ECDH shared secrets (or even simpler change the 
PK point (x,y) to (x,-y)). The attacker in this case can’t decrypt or tamper 
with a message but they can claim that it came from their public key instead of 
the real originator. Again, this can make the same proof of identity valid for 
two or more identities if you use public keys as identities. 

In both cases these “attacks” can be avoided by including the identities/public 
keys in the input to the signature (or KDF for ECDH). For example, EdDSA 
already does this, and this is a recommended best practice for ECDH (sadly 
missing from JWE). An alternative is to define a canonical public key for each 
given signature and reject non-canonical keys. 

Whether these “attacks” actually lead to a vulnerability or not depends on 
exactly what you are doing. But it is a surprising property that can lead to 
subtle issues as the security considerations of RFC 7748 note [2]:

“ Designers using these curves should be aware that for each public
   key, there are several publicly computable public keys that are
   equivalent to it, i.e., they produce the same shared secrets.  Thus
   using a public key as an identifier and knowledge of a shared secret
   as proof of ownership (without including the public keys in the key
   derivation) might lead to subtle vulnerabilities.”

Adding wording along those lines (generalised to mention signatures too) would 
be good. I’ll come up with some wording. 

Other security issues can arise when a public key hash is informally associated 
with some other kind of identifier without a strong binding between the two. 
For example, the unknown key share attacks described in RFC 8844 [3].

[1]: https://crypto.stackexchange.com/a/60219
[2]: https://datatracker.ietf.org/doc/html/rfc7748#section-7
[3]: https://www.rfc-editor.org/rfc/rfc8844.html

— Neil

>  
> Second, you asked that the hash algorithm be made explicit, as did Vladimir.  
> I’ll consult with Kristina on that today and respond to that suggestion in a 
> subsequent message.
>  
>Thanks again,
>-- Mike
>  
> From: OAuth  On Behalf Of Vladimir Dzhuvinov
> Sent: Thursday, February 3, 2022 11:00 PM
> To: oauth@ietf.org
> Subject: [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>  
> The original JWK thumbprint RFC 7638 essentially describes the method for 
> composing the hash input from a JWK and that the output is base64url encoded. 
> SHA-256 is mentioned, but there is no default implied hash function. This 
> leaves it to applications / other specs to determine.
> 
> https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4
> 
> The URN gives us now a natural possibility to encode the hash function 
> alongside the fact that it's a JWK thumbprint, so let's include it. This will 
> make things more explicit and self-contained.
> 
> What do the authors think about this possibility?
> 
> ~Vladimir
> 
> Vladi

Re: [OAUTH-WG] OAuth 2.1: Missing token?

[Neil Madden]

The example at the end of section 5.2.2 suggests no error_code and just a 
401/WWW-Authenticate header in this case:

 For example, in response to a protected resource request without
   authentication:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: Bearer realm="example"


And the paragraph in section 5.2.3 immediately following the section you quote 
is even more explicit:

   If the request lacks any authentication information (e.g., the client
   was unaware that authentication is necessary or attempted using an
   unsupported authentication method), the resource server SHOULD NOT
   include an error code or other error information.

So, no error_code at all if no access token supplied.

Kind regards,

Neil

> On 4 Feb 2022, at 09:15, Johannes Koch 
>  wrote:
> 
>   EntSec couldn't recognize this email as this is the first time you 
> received an email from this sender johannes.koch=40avenga.com @ dmarc.ietf.org
> 
> Hi there,
> 
> a question about 
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04 
> 
> 5.2.3.  Error Codes
> 
>"invalid_request":  The request is missing a required parameter,
>   includes an unsupported parameter or parameter value, repeats the
>   same parameter, uses more than one method for including an access
>   token, or is otherwise malformed.  The resource server SHOULD
>   respond with the HTTP 400 (Bad Request) status code.
> 
>"invalid_token":  The access token provided is expired, revoked,
>   malformed, or invalid for other reasons.  The resource SHOULD
>   respond with the HTTP 401 (Unauthorized) status code.  The client
>   MAY request a new access token and retry the protected resource
>   request.
> 
> Now, what is the intended error code for the situation where no access token 
> is provided? The description for invalid_token seems to imply that one token 
> was provided.
> As the token may be seen as a required parameter, invalid_request may be 
> appropriate. However, a missing token smells more like HTTP 401 
> (Unauthorized).
> 
> Should this be an additional error code (missing_token)? Or should this case 
> be added to invalid_token?
> 
> -- 
> Johannes Koch
> ___
> 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] WGLC for JWK Thumbprint URI document

[Neil Madden]

The draft doesn’t specify which hash function is being used. I assume it is 
SHA-256, but it should either say that is the only algorithm allowed or perhaps 
encode the hash algorithm into the URI. Otherwise the value is ambiguous. 

Using a (hash of a) public key as an identifier is an idea that has 
historically been subject to various attacks such as unknown key share attacks, 
as well as issues due to malleable signature schemes or key exchange schemes - 
where the same proof of identity is valid under many public keys. The security 
considerations should mention these issues, and potential suggest 
countermeasures (eg including the full public key JWK in the input to be signed 
etc). 

— Neil

> On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef  wrote:
> 
> 
> All,
> 
> The JWK Thumbprint URI document is a simple and straightforward specification.
> 
> This is a WG Last Call for this document:
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
> 
> Please, provide your feedback on the mailing list by Feb 16th.
> 
> Regards,
>  Rifaat & Hannes
> 
> 
> ___
> 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] Proposed changes to RFC 8705 (oauth-mtls)

[Neil Madden]

On 9 Dec 2021, at 20:36, Justin Richer  wrote:
> 
> I disagree with this take. If there are confirmation methods at all, it’s no 
> longer a Bearer token, and pretending that it is doesn’t help anyone. I think 
> combining confirmation methods is interesting, but then you get into a weird 
> space of how to define the combinations, and what to do if one is missing, 
> etc. It opens up a weird space for interop problems. It’s not insurmountable, 
> but I don’t think it’s a trivial as it might look at first.
> 
> Plus, the “backwards compatible” argument is what led to the existing RFC 
> using Bearer again. In my view, this actually opens up the possibility of 
> downgrade attacks against the RS, where a lazy RS doesn’t check the binding 
> because it sees “Bearer” and calls it a day.

I think this actually strongly argues the opposite - it is precisely because 
the scheme is under attacker control that enables such downgrade attacks. So 
relying on the scheme to tell you what kind of PoP checks to apply makes these 
kinds of attacks more likely, not less. I’m suggesting instead that the RS 
decides what checks to enforce based on the “cnf” content in the token - which 
is either signed by the AS or retrieved directly from the AS through 
introspection. On the other hand, the token type is not even defined in the 
recent RFC 9068 for JWT-based ATs. So an attacker could easily change the 
scheme from MTLS to Bearer to see if the RS stops performing checks, but they 
can’t remove a “cnf” claim from the token itself.

In hindsight, “Bearer” might have been better named “AccessToken” or similar, 
but I don’t think the name matters as much as the semantics.


> The thing is, turning off that kind of checking is the kind of problem that 
> fails open, like turning off XML signature validation in a SAML environment. 
> The good assertions still pass, and bad assertions happen to also look fine. 
> I don’t think that’s a good space to be in, and re-using “Bearer” like the 
> existing spec does is a problem for that reason.
> 
> I would personally love to see a bis of this RFC, but because of inertia 
> around existing deployments, I don’t expect it. I think we’d see a lot of 
> confusion around which version of things to use.
> 
>  — Justin
> 
>> On Dec 9, 2021, at 8:52 AM, Neil Madden > <mailto:neil.mad...@forgerock.com>> wrote:
>> 
>> I don’t mind about a new error code, although I think it’s of limited value 
>> - error codes (rather than descriptive error *messages*) imply that the 
>> client may be able to dynamically react to the situation and so something 
>> different. But TLS client certs are usually configured statically, so it 
>> seems highly unlikely that the client could satisfy this requirement on its 
>> own. (Especially without all the other hints that would be missing from the 
>> TLS layer, like trusted CAs, supported signature algorithms, etc).
>> 
>> I am against changing the token type/scheme from Bearer to MTLS.  Mostly 
>> because of backwards compatibility issues - we already have customers that 
>> have deployed mTLS widely, but also because of conceptual issues I have 
>> generally with distinct token_type/schemes:
>> 
>> 1. Whether an access token is mTLS-bound or a pure bearer token is a 
>> property of what the RS enforces, not intrinsic to the token. As far as I am 
>> aware, there is no spec anywhere that says what an RS should do if it 
>> doesn’t understand a particular confirmation method associated with an 
>> access token. So you can easily at present have a situation where an AT is 
>> valid at multiple RSes, some of which understand mTLS-binding and some of 
>> which do not. Indeed, this is very likely (and desirable) when you are in 
>> the process of rolling out stronger security mechanisms on an RS-by-RS 
>> basis. (And what if you later decide to move from mTLS to DPoP?) IMO 
>> requiring that ATs always have one and only one associated PoP mechanism is 
>> a recipe for ossification.
>> 
>> 2. IMO the “token_type” and Authorization scheme should be primarily about 
>> how the AT itself is conveyed to the RS, not about how any associated proof 
>> is. Although “Bearer” is not the most appropriate name, I would rather we 
>> stuck to that one scheme for conveying ATs regardless of whether they are 
>> pure bearer tokens, bound tokens, or whatever. To me, the important part of 
>> “Bearer” is that it tells the RS that it can send this token directly to an 
>> introspection endpoint (or examine it locally) without first performing some 
>> additional processing on it.
>> 
>> 3. I am generally in favour of allowing ATs to have 0, 1, 2 or any number of 
>> confirmation me

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

[Neil Madden]

I don’t mind about a new error code, although I think it’s of limited value - 
error codes (rather than descriptive error *messages*) imply that the client 
may be able to dynamically react to the situation and so something different. 
But TLS client certs are usually configured statically, so it seems highly 
unlikely that the client could satisfy this requirement on its own. (Especially 
without all the other hints that would be missing from the TLS layer, like 
trusted CAs, supported signature algorithms, etc).

I am against changing the token type/scheme from Bearer to MTLS.  Mostly 
because of backwards compatibility issues - we already have customers that have 
deployed mTLS widely, but also because of conceptual issues I have generally 
with distinct token_type/schemes:

1. Whether an access token is mTLS-bound or a pure bearer token is a property 
of what the RS enforces, not intrinsic to the token. As far as I am aware, 
there is no spec anywhere that says what an RS should do if it doesn’t 
understand a particular confirmation method associated with an access token. So 
you can easily at present have a situation where an AT is valid at multiple 
RSes, some of which understand mTLS-binding and some of which do not. Indeed, 
this is very likely (and desirable) when you are in the process of rolling out 
stronger security mechanisms on an RS-by-RS basis. (And what if you later 
decide to move from mTLS to DPoP?) IMO requiring that ATs always have one and 
only one associated PoP mechanism is a recipe for ossification.

2. IMO the “token_type” and Authorization scheme should be primarily about how 
the AT itself is conveyed to the RS, not about how any associated proof is. 
Although “Bearer” is not the most appropriate name, I would rather we stuck to 
that one scheme for conveying ATs regardless of whether they are pure bearer 
tokens, bound tokens, or whatever. To me, the important part of “Bearer” is 
that it tells the RS that it can send this token directly to an introspection 
endpoint (or examine it locally) without first performing some additional 
processing on it.

3. I am generally in favour of allowing ATs to have 0, 1, 2 or any number of 
confirmation methods associated with them. If we want to make it easier for a 
client to figure out which ones an RS supports, I’d rather see this as an 
enhancement to the Bearer WWW-Authentication challenge - e.g. WWW-Authenticate: 
Bearer … supported_cnf_methods=mtls,dpop

Anyway, can of worms well and truly opened…

— Neil

> On 9 Dec 2021, at 13:23, Dmitry Telegin 
>  wrote:
> 
> There following changes to RFC 8705 have been proposed:
> - introduce a new error code (e.g. "invalid_mtls_certificate") to be used 
> when the certificate is required by the AS/RS, but the underlying stack has 
> been misconfigured and the client didn't send one;
> - for bound token use, change Authorization scheme from Bearer to MTLS;
> - for token response returning a bound token, change token_type from Bearer 
> to MTLS
> 
> See discussion: 
> https://mailarchive.ietf.org/arch/msg/oauth/XfeH2q0Rwa2YocsR484xk-8LMqc/ 
> 
> 
> Accepting the changes would imply a new RFC and the obsolescence of the 
> current one. Two questions so far:
> - what's the group's general stance on this, would that be a welcome change?
> - if so, could we also hear from the implementors if there any other issues / 
> suggested changes.
> 
> Dmitry
> Backbase / Keycloak
> 
> ___
> 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] dpop_jkt Authorization Request Parameter

[Neil Madden]

Sadly I couldn’t make the DPoP session, but I’m not convinced the attack 
described in the earlier message really needs to be prevented at all. The 
attack largely hinges on auth codes not being one-time use, which is not a good 
idea, or otherwise on poor network security on the token endpoint. I’m not 
convinced DPoP needs to protect against these things. Is there more to this?

The proposed solutions also seem susceptible to the same problems they attempt 
to solve - if an attacker is somehow able to interrupt the client’s 
(TLS-protected) token request, why are they somehow not able to 
interrupt/modify the (far less protected) redirect to the authorization 
endpoint?

— Neil

> On 30 Nov 2021, at 20:15, Mike Jones 
>  wrote:
> 
> As described during the OAuth Security Workshop session on DPoP, I created a 
> pull request adding the dpop_jkt authorization request parameter to use for 
> binding the authorization code to the client’s DPoP key.  
> Seehttps://github.com/danielfett/draft-dpop/pull/89 
> .
>  
> This is an alternative to https://github.com/danielfett/draft-dpop/pull/86 
> , which achieved this 
> binding using a new DPoP PKCE method.  Using this alternative allows PKCE 
> implementations to be unmodified, while adding DPoP in new code, which may be 
> an advantage in some deployments.
>  
> Please review and comment.  Note that I plan to add more of the attack 
> description written by Pieter Kasselman to the security considerations in a 
> future commit.  This attack description was sent by Pieter yesterday in a 
> message with the subject “Authorization Code Log File Attack (was DPoP 
> Interim Meeting Minutes)”.
>  
>-- Mike
>  
> ___
> 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] New Version Notification for draft-ietf-oauth-dpop-04.txt

[Neil Madden]

I’m by no means a HTTP caching expert (*), but 
https://datatracker.ietf.org/doc/html/rfc7234#section-3 
<https://datatracker.ietf.org/doc/html/rfc7234#section-3> says that the 
non-cacheability of responses to requests with Authorization headers only 
applies to shared caches. So could a user-agent itself cache the response and 
incorrectly return a stale DPoP-Nonce response on a subsequent request? 

But I think you’re right that this only applies, at most, to section 8.1, as 
DPoP only allows the Authorization header for making requests to the RS (unlike 
RFC 6750).

(*) I know a joke about HTTP caching, but I think you’ve already heard it.

— Neil


> On 29 Nov 2021, at 18:03, Brian Campbell  wrote:
> 
> I'm preparing some slides for a DPoP session tomowwo at the OAuth Security 
> Workshop https://barcamps.eu/osw2021/ <https://barcamps.eu/osw2021/> so 
> looking back at some threads like this one trying to compile a list of issues 
> needing attention. The stateful handling of server-supplied nonces is one 
> such topic. I was about to add a topic for Cache-Control but, in 
> doing/thinking about it, I believe that all cases that would use a DPoP-Nonce 
> response header are already not cacheable - response to POST, 401 challenge, 
> response to a request containing an authorization header - so I don't think 
> anything is needed. But let me know if I'm missing something. 
> 
> On Wed, Oct 6, 2021 at 1:54 PM Neil Madden  <mailto:neil.mad...@forgerock.com>> wrote:
> Overall I think thus is good, but I have a few comments/suggestions:
> 
> I think the stateful handling of server-supplied nonces (ie the client reuses 
> the same nonce until the server sends a new one) perhaps needs to be 
> clarified with respect to clients making concurrent requests. Especially 
> clients using multiple access tokens and/or DPoP keys (eg for different 
> users). Is the nonce specific to a particular access token? 
> 
> And we also need to consider a client that is itself a cluster of servers - 
> does such a client need to synchronise nonces across instances? Does the 
> AS/RS need to? (I can imagine this getting quite complex with different 
> requests from different client machines hitting different AS/RS servers). 
> 
> I think probably any use of the DPoP-Nonce response header should also be 
> accompanied by Cache-Control: private (or no-store) and this should be a 
> MUST. I think we’ve also missed that the DPoP header on requests should also 
> have Cache-Control: no-store added, at least when not sending the access 
> token in an Authorization header. 
> 
> It seems slightly odd that the WWW-Authenticate challenge for RS 
> server-supplied nonces isn’t self-contained, but I don’t see anything that 
> says it should be so that is probably ok. (And I can see the consistency 
> argument for using the header). 
> 
> It does seem a shame to pay the cost of a challenge-response roundtrip and 
> not to do a key exchange to speed up subsequent requests, but never mind. 
> 
> — Neil
> 
>> On 6 Oct 2021, at 17:37, Mike Jones 
>> > <mailto:40microsoft@dmarc.ietf.org>> wrote:
>> 
>> 
>> FYI, I wrote about the nonce support at https://self-issued.info/?p=2194 
>> <https://self-issued.info/?p=2194> and 
>> https://twitter.com/selfissued/status/1445789505902899206 
>> <https://twitter.com/selfissued/status/1445789505902899206>.
>> 
>>  
>> 
>>-- Mike
>> 
>>  
>> 
>> From: OAuth mailto:oauth-boun...@ietf.org>> On 
>> Behalf Of Brian Campbell
>> Sent: Monday, October 4, 2021 3:11 PM
>> To: oauth mailto:oauth@ietf.org>>
>> Subject: [OAUTH-WG] Fwd: New Version Notification for 
>> draft-ietf-oauth-dpop-04.txt
>> 
>>  
>> 
>>  
>> 
>> WG,
>> 
>>  
>> 
>> The collective DPoP co-authors are pleased to announce that a new -04 
>> revision of DPoP has been published. The doc history snippet is copied below 
>> for quick/easy reference. The main change here is the addition of an option 
>> for a server-provided nonce in the DPoP proof.
>> 
>> 
>>-04
>>*  Added the option for a server-provided nonce in the DPoP proof.
>>*  Registered the invalid_dpop_proof and use_dpop_nonce error codes.
>>*  Removed fictitious uses of realm from the examples, as they added
>>   no value.
>>*  State that if the introspection response has a token_type, it has
>>   to be DPoP.
>>*  Mention that RFC7235 allows multiple authentication schemes in
>>   WWW-Authenticate with a 401.
>>*  Editorial 

Re: [OAUTH-WG] DPoP and MTLS - friends or foes?

[Neil Madden]

I’m not smart enough to remember in what context I might have said this, but 
I’d hazard a guess it was somehow related to service mesh. 

Generally, we allow both to be specified largely because of our support for 
macaroon access tokens: a proxy could transparently add a mtls binding (for ex) 
to an AT as a macaroon caveat. If it first had to check whether there was some 
other type of binding on it then that would make it more awkward.

So we have an implementation where there can be any number of bindings 
associated with an AT and we loop through the set of keys in the “cnf” object 
and ensure that each one is satisfied. (We also currently reject unrecognised 
confirmation methods, I believe - on the assumption that they are all critical. 
I think the specs are currently silent on what to do with an unrecognised “cnf” 
value). 

Macaroon ATs somewhat break the whole token_type field, as an AT can start off 
as a pure bearer token and later become bound by a caveat.

— Neil 

> On 12 Nov 2021, at 22:00, Brian Campbell 
>  wrote:
> 
> 
> I think Neil commented once somewhere about maybe seeing value in both at the 
> same time. He's smarter than me so I don't like to contradict him. But I've 
> always thought of them as mutually exclusive. And practically/pragmatically I 
> think it really is one or the other.  
> 
>> On Fri, Nov 12, 2021 at 9:39 AM Dmitry Telegin 
>>  wrote:
>> As an implementer of one binding mechanism (DPoP) for the AS (Keycloak) that 
>> already features another (MTLS), I'm running into the question whether we 
>> should allow those two to be used simultaneously (which could be of course 
>> extrapolated to other hypothetical mechanisms). By "simultaneously" I mean 
>> binding a single token using both methods given that the material for both 
>> has been provided with the request.
>> 
>> I guess currently mutual exclusivity is implied. Though in theory the "cnf" 
>> section of the AT could contain both "jkt" and "x5t#S256", the mechanisms 
>> are using different values for "token_type" and authentication scheme 
>> ("DPoP" for DPoP, "Bearer" for MTLS, though the latter might change to 
>> "MTLS" in the future) and we define no mechanism to combine them (could be 
>> "Bearer+DPoP" or "DPoP+MTLS" for example, which would be valid as per RFCs 
>> 7230 and 7235).
>> 
>> I apologize if the question has been asked before; didn't find anything 
>> relevant in the ML. The implementer of MTLS for Keycloak also voted for 
>> mutually exclusive behavior.
>> 
>> - Dmitry
>> Backbase / Keycloak
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 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
> 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] [EXTERNAL] Rotating RTs and grace periods

[Neil Madden]

The grace period is to allow the client to retry if it fails to receive the new 
RT for any reason. For example, the client performs a successful refresh flow 
but loses mobile network signal before receiving the response. The grace period 
allows the client to simply retry the request, whereas without a grace period 
the first request would have invalidated the old RT leaving the client with no 
option but to perform a full authorization flow again to get a new one. 

I’m generally against allowing a grace period at all, but given that it’s a 
common request and some implementations are already allowing this, I’m hoping 
we can find some wording we can all agree on. 

I agree that a grace period is more acceptable if the RT is sender-constrained 
by something like DPoP, but then in that case does RT rotation add anything 
anyway? The current BCP lists these two as either/or rather than defence in 
depth. 

— Neil

> On 2 Nov 2021, at 14:09, Pieter Kasselman  
> wrote:
> 
> 
> Neil
>  
> Is the goal to accommodate network latency or clock drift? It would be 
> helpful to include reasons for why a grace period should be considered if it 
> is allowed.
>  
> Without knowing the reasons for the grace period it is not clear why a grace 
> period is a better solution than just extending the expiry time by a set time 
> (60 seconds in your example) and having the client present the token a little 
> earlier.
>  
> If grace periods are allowed, it may be worth considering adding additional 
> mitigations against replay. For example, a grace period may be allowed if the 
> refresh token is sender constrained with DPoP so there is at least some 
> assurances that the request is originating from the sender (especially if the 
> nonce option is used with DPoP).
>  
> I would worry about adding more complexity and less predictability by adding 
> grace periods though (e.g. by looking at a refresh token, will you be able to 
> tell if it can still be used or not), but your point that implementors may 
> solve for it in other less predictable ways raises a valid point.
>  
> Cheers
>  
> Pieter
>  
> From: OAuth  On Behalf Of Neil Madden
> Sent: Tuesday 2 November 2021 10:29
> To: oauth 
> Subject: [EXTERNAL] [OAUTH-WG] Rotating RTs and grace periods
>  
> Hi all,
>  
> There was a previous discussion on whether to allow a grace period during 
> refresh token rotation, allowing the client to retry a refresh if the 
> response fails to be received due to some transient network issue/timeout 
> [1]. Vittorio mentioned that Auth0 already implement such a grace period. We 
> (ForgeRock) currently do not, but we do periodically receive requests to 
> support this. The current security BCP draft is silent on whether 
> implementing such a grace period is a good idea, but I think we should add 
> some guidance here one way or another.
>  
> My own opinion is that a grace period is not a good idea, and if it is to be 
> supported as an option then it should be kept as short as possible. The 
> reason (as I mentioned in the previous thread) is that it is quite easy for 
> an attacker to observe when a legitimate client performs a refresh flow and 
> so can easily sneak in their own request afterwards within the grace period. 
> There are several reasons why it is easy for an attacker to observe this:
>  
> - RT rotation is primarily intended for public clients, such as mobile apps 
> and SPAs. These clients are geographically distributed across the internet, 
> and so there is a good chance that the attacker is able to observe the 
> network traffic of at least some of these client instances.
> - The refresh flow is typically the only request that the client makes 
> directly to the AS after initial authorization, so despite the traffic being 
> encrypted it is very easy for an observer to determine that the client is 
> performing a refresh whenever it makes any connection to the AS.
> - As well as observing the request itself, an attacker may be able to observe 
> the DNS lookup for the AS hostname instead, which is even more likely to be 
> observable and also in plaintext most of the time.
> - An attacker in a position to steal RTs from e.g. localStorage, is probably 
> also in a good position to either observe when the legitimate client 
> refreshes or to actually force it to refresh early (e.g., by deleting the 
> corresponding AT from the same storage).
>  
> I know some people argue that a grace period is a reasonable trade-off 
> between security and usability. But I think that this kind of attack would be 
> quite easy to carry out in practice for the reasons I suggest above, so I 
> think the security actually degrades extremely quickly if you allow a grace 
> period of any reasonable length. 

[OAUTH-WG] Rotating RTs and grace periods

[Neil Madden]

Hi all,

There was a previous discussion on whether to allow a grace period during 
refresh token rotation, allowing the client to retry a refresh if the response 
fails to be received due to some transient network issue/timeout [1]. Vittorio 
mentioned that Auth0 already implement such a grace period. We (ForgeRock) 
currently do not, but we do periodically receive requests to support this. The 
current security BCP draft is silent on whether implementing such a grace 
period is a good idea, but I think we should add some guidance here one way or 
another.

My own opinion is that a grace period is not a good idea, and if it is to be 
supported as an option then it should be kept as short as possible. The reason 
(as I mentioned in the previous thread) is that it is quite easy for an 
attacker to observe when a legitimate client performs a refresh flow and so can 
easily sneak in their own request afterwards within the grace period. There are 
several reasons why it is easy for an attacker to observe this:

- RT rotation is primarily intended for public clients, such as mobile apps and 
SPAs. These clients are geographically distributed across the internet, and so 
there is a good chance that the attacker is able to observe the network traffic 
of at least some of these client instances.
- The refresh flow is typically the only request that the client makes directly 
to the AS after initial authorization, so despite the traffic being encrypted 
it is very easy for an observer to determine that the client is performing a 
refresh whenever it makes any connection to the AS.
- As well as observing the request itself, an attacker may be able to observe 
the DNS lookup for the AS hostname instead, which is even more likely to be 
observable and also in plaintext most of the time.
- An attacker in a position to steal RTs from e.g. localStorage, is probably 
also in a good position to either observe when the legitimate client refreshes 
or to actually force it to refresh early (e.g., by deleting the corresponding 
AT from the same storage).

I know some people argue that a grace period is a reasonable trade-off between 
security and usability. But I think that this kind of attack would be quite 
easy to carry out in practice for the reasons I suggest above, so I think the 
security actually degrades extremely quickly if you allow a grace period of any 
reasonable length. 

On the other hand, if we discourage this entirely then people may use dubious 
workarounds instead (e.g., one proposal I’ve seen was to use an ID token with 
the JWT Bearer grant, effectively turning the ID Token into an ad-hoc RT with 
much fewer protections).

As a strawman, what would people think of wording like the following:

---
The AS MAY allow the original RT to be replayed for a short grace period to 
allow the client to recover if the response is not received due to a network 
problem or other transient issue. However, implementors should be aware that an 
attacker may be able to easily observe when the legitimate client makes a 
refresh request to the AS and so time their use of a stolen RT to occur within 
the grace period. Any grace period MUST be kept as short as possible, and MUST 
NOT exceed 60 seconds. Clients should prefer sender-constrained refresh tokens 
if recovery from network issues is a priority.
—

(The 60 seconds limit here is based on Auth0’s grace period).

[1]: https://mailarchive.ietf.org/arch/msg/oauth/WXwKxQM2poW7bqOOGGp4POYolFk/ 
 

Kind regards,

Neil

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

Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

[Neil Madden]

I would express a mild preference for “invalid_token” taking priority in this 
case. It seems pointless for the client to generate a new DPoP proof (in 
response to invalid_dpop_proof) if they are then going to get an invalid_token 
on the next request anyway. If they get a new AT they will naturally generate a 
new proof too as the AT hash will no longer match.

— Neil

> On 27 Oct 2021, at 16:20, Brian Campbell 
>  wrote:
> 
> It's really just an implementation choice, I think. 
> 
> On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin 
>  > wrote:
> Any updates on this one? As of -04 we have a clear distinction between 
> "error=invalid_token" and "error=invalid_dpop_proof", so the question could 
> be reworded like this:
> - if DPoP proof is used in combination with access token, and both are 
> invalid, which one of the "invalid_token" and "invalid_dpop_proof" should be 
> signaled?
> 
> Regards,
> Dmitry
> Backbase
> 
> On Fri, Jul 30, 2021 at 6:37 PM Dmitry Telegin  > wrote:
> Hello,
> 
> When DPoP proof is used in conjunction with a token (protected resource 
> access; token refresh), what should be the order of validation of those? The 
> draft doesn't mention this, and it's hard to deduce logically which should 
> come first, since validation is mutual ("ath" DPoP claim vs. "cnf/jkt" token 
> claim) and there is a sort of circular dependency. Are we going to address 
> that in the spec, or intentionally leave as unspecified?
> 
> Background: a developer asked me if it's guaranteed that the protected 
> resource return a 401 in the case of invalid access token; currently, the 
> answer seems to be "implementation specific".
> 
> Regards,
> Dmitry
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 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
> 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] Authorization code reuse and OAuth 2.1

[Neil Madden]

Are we saying that network connections have got significantly worse over the 
last decade that we need to drop a security feature? I have so far never heard 
anyone complain about the one-time use nature of authorization codes. (I hear 
it about refresh tokens, but not auth codes). I don’t think that OAuth 2.1 is 
an appropriate place to be relaxing any security conditions. 

— Neil

> On 16 Oct 2021, at 03:01, Vittorio Bertocci 
>  wrote:
> 
> 
> I see the formal reasoning behind the suggestion, and I agree it would be the 
> safest behavior, but I don’t think it’s a realistic expectation. The end user 
> experience necessary for obtaining a new authorization code (with possible 
> future complications if browsers start to see excess redirects toward a 
> domain as evidence of tracking and strip parameters out) and the complexity 
> of moving execution back from code to front channel as error management IMO 
> makes it very unlikely that developers would pursue that approach (which I 
> have never seen implemented in the wild).
> 
>> On Fri, Oct 15, 2021 at 16:42 Mike Jones 
>>  wrote:
>> As I see it, the retry in case of network failures should happen by 
>> performing a new authorization request – not by trying to reuse an 
>> authorization code – which is indistinguishable from an attack.
>> 
>>  
>> 
>> Let’s not use OAuth 2.1 as an opportunity to sanction behaviors that we 
>> can’t distinguish from attacks.
>> 
>>  
>> 
>> The prohibition on clients reusing an authorization code needs to remain.
>> 
>>  
>> 
>>   -- Mike
>> 
>>  
>> 
>> From: Vittorio Bertocci  
>> Sent: Friday, October 15, 2021 4:19 PM
>> To: Richard Backman, Annabelle 
>> Cc: Mike Jones ; oauth@ietf.org
>> Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1
>> 
>>  
>> 
>> I am a fan of this approach. It feels pretty empty to cast people out of 
>> compliance just because they are handling a realistic circumstance, such as 
>> network failures, that we know about beforehand. 
>> 
>> In addition, this gives us a chance to provide guidance on how to handle the 
>> situation, instead of leaving AS implementers to their own device.
>> 
>>  
>> 
>> On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle 
>>  wrote:
>> 
>> The client MUST NOT use the authorization code more than once.
>> 
>>  
>> 
>> This language makes it impossible to build a fault tolerant, spec compliant 
>> client, as it prohibits retries. We could discuss whether a retry really 
>> constitutes a separate "use", but ultimately it doesn't matter; multiple 
>> presentations of the same code look the same to the AS, whether they are the 
>> result of retries, the client attempting to get multiple sets of tokens, or 
>> an unauthorized party trying to replay the code.
>> 
>>  
>> 
>> I think we can have a fault tolerant, replay-proof implementation, but it 
>> takes some effort:
>> 
>>  
>> 
>> The AS can prevent the authorized client from using one code to get a bunch 
>> of independent refresh and access token pairs by either re-issuing the same 
>> token (effectively making the token request idempotent) or invalidating 
>> previously issued tokens for that code. (Almost but not quite 
>> idempotent…idempotent-adjacent?)
>> The AS can prevent unauthorized parties from replaying snooped codes+PKCE by 
>> requiring stronger client authentication: implement dynamic client 
>> registration and require a replay-resistant client authentication method 
>> like `jwt-bearer`. The AS can enforce one-time use of the client credential 
>> token without breaking fault tolerance, as the client can easily mint a new 
>> one for each retry to the token endpoint.
>>  
>> 
>> Yes, I know, this is way more complex than just a credential-less public 
>> client doing PKCE. Perhaps we can have our cake and eat it too with language 
>> like:
>> 
>>  
>> 
>> The client MUST NOT use the authorization code more than once, unless 
>> retrying a token request that failed for reasons beyond the scope of this 
>> protocol. (e.g., network interruption, server outage) Refer to [Fault 
>> Tolerant Replay Prevention] for guidance.
>> 
>>  
>> 
>> …where Fault Tolerant Replay Prevention is a subsection under Security 
>> Considerations. I don't think this wording is quite right, as the guidance 
>> is really going to be for the AS, not the client, but hopefully it's enough 
>> to get the idea across.
>> 
>>  
>> 
>> —
>> 
>> Annabelle Backman (she/her)
>> 
>> richa...@amazon.com
>> 
>>  
>> 
>>  
>> 
>> 
>> 
>> 
>> On Oct 15, 2021, at 8:27 AM, Mike Jones 
>>  wrote:
>> 
>>  
>> 
>> CAUTION: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you can confirm the sender and know 
>> the content is safe.
>> 
>>  
>> 
>> I agree with Daniel.
>> 
>>  
>> 
>> Also, while we’ve talked about server requirements, I think it’s equally 
>> important that we retain this clie

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

[Neil Madden]

I wasn’t on the call either, so maybe I’m missing something. If you’re using 
PKCE with the “plain” challenge type then both the auth code and the verifier 
are exposed in redirect URI parameters in the user-agent aren’t they? That 
seems a bit risky to drop the one-time use requirement. 

I can’t see anything in the minutes of the meeting describing the difficulty of 
implementing the one-time use req. I seem to see announcements for new 
globally-consistent high-scale cloud database services every day - is this 
really that hard to implement?

— Neil

> On 13 Oct 2021, at 18:41, Aaron Parecki  wrote:
> 
> 
> Warren, I didn't see you on the interim call, so you might be missing some 
> context.
> 
> The issue that was discussed is that using PKCE already provides all the 
> security benefit that is gained by enforcing single-use authorization codes. 
> Therefore, requiring that they are single-use isn't necessary as it doesn't 
> provide any additional benefit.
> 
> If anyone can think of a possible attack by allowing authorization codes to 
> be reused *even with a valid PKCE code verifier* then that would warrant 
> keeping this requirement.
> 
> ---
> Aaron Parecki
> 
> 
>> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad 
>>  wrote:
>> Isn't it better for it to be worded as we want it to be, with the 
>> implication being that of course it might be difficult to do that, but that 
>> AS devs will think long and hard about sometimes not denying the request? 
>> Even with MUST, some AS will still allow reuse of auth codes. Isn't that 
>> better than flat out saying: sure, there's a valid reason
>> 
>> In other words, how do we think about RFCs? Do they exist to be followed to 
>> the letter or not at all? Or do they exist to stipulate this is the way, but 
>> acknowledge that not everyone will build a solution that holds them as law.
>> 
>> Let's look at SHOULD
>>> This word, or the adjective "RECOMMENDED", mean that there may exist valid 
>>> reasons in particular circumstances to ignore a particular item, but the 
>>> full implications must be understood and carefully weighed before choosing 
>>> a different course.
>> 
>> I think recommended here is not sufficient nor are there valid reasons. 
>> "It's too hard" isn't really a valid reason. Isn't it better in this case 
>> for an AS to not be compliant with the RFC, than it is to relax this to 
>> SHOULD and have lots of AS thinking reusing auth codes is a viable solution, 
>> "because they are a special snowflake where SHOULD should apply".
>> 
>> Are we setting the standard or instead attempting to sustain a number of "AS 
>> that are in compliance with the RFC"?
>>  
>> 
>> Warren Parad
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement 
>> Authress.
>> 
>> 
>>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones 
>>>  wrote:
>>> During today’s call, it was asked whether we should drop the OAuth 2.0 
>>> language that:
>>> 
>>>  The client MUST NOT use the authorization code
>>> 
>>>  more than once.  If an authorization code is used more than
>>> 
>>>  once, the authorization server MUST deny the request and SHOULD
>>> 
>>>  revoke (when possible) all tokens previously issued based on
>>> 
>>>  that authorization code.”
>>> 
>>>  
>>> 
>>> The rationale given was that enforcing one-time use is impractical in 
>>> distributed authorization server deployments.
>>> 
>>>  
>>> 
>>> Thinking about this some more, at most, we should relax this to:
>>> 
>>>  The client MUST NOT use the authorization code
>>> 
>>>  more than once.  If an authorization code is used more than
>>> 
>>>  once, the authorization server SHOULD deny the request and SHOULD
>>> 
>>>  revoke (when possible) all tokens previously issued based on
>>> 
>>>  that authorization code.”
>>> 
>>>  
>>> 
>>> In short, it should remain illegal for the client to try to reuse the 
>>> authorization code.  We can relax the MUST to SHOULD in the server 
>>> requirements in recognition of the difficulty of enforcing the MUST.
>>> 
>>>  
>>> 
>>> Code reuse is part of some attack scenarios.  We must not sanction it.
>>> 
>>>  
>>> 
>>>   -- Mike
>>> 
>>>  
>>> 
>>> ___
>>> 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
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Manage My Preferences , Unsubscribe 


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

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Neil Madden]

Canonicalised signature schemes inevitably lead to cryptographic doom, and 
should die with SAML (ha!). For that reason I do not support adoption of this 
draft. 

I also think the arguments for canonicalisation vanish as soon as you want 
end-to-end confidentiality too.

— Neil

> On 6 Oct 2021, at 22:02, Rifaat Shekh-Yusef  wrote:
> 
> 
> All,
> 
> As a followup on the interim meeting today, this is a call for adoption for 
> the OAuth Proof of Possession Tokens with HTTP Message Signature draft as a 
> WG document:
> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
> 
> Please, provide your feedback on the mailing list by October 20th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Manage My Preferences , Unsubscribe 


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

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-04.txt

[Neil Madden]

Overall I think thus is good, but I have a few comments/suggestions:

I think the stateful handling of server-supplied nonces (ie the client reuses 
the same nonce until the server sends a new one) perhaps needs to be clarified 
with respect to clients making concurrent requests. Especially clients using 
multiple access tokens and/or DPoP keys (eg for different users). Is the nonce 
specific to a particular access token? 

And we also need to consider a client that is itself a cluster of servers - 
does such a client need to synchronise nonces across instances? Does the AS/RS 
need to? (I can imagine this getting quite complex with different requests from 
different client machines hitting different AS/RS servers). 

I think probably any use of the DPoP-Nonce response header should also be 
accompanied by Cache-Control: private (or no-store) and this should be a MUST. 
I think we’ve also missed that the DPoP header on requests should also have 
Cache-Control: no-store added, at least when not sending the access token in an 
Authorization header. 

It seems slightly odd that the WWW-Authenticate challenge for RS 
server-supplied nonces isn’t self-contained, but I don’t see anything that says 
it should be so that is probably ok. (And I can see the consistency argument 
for using the header). 

It does seem a shame to pay the cost of a challenge-response roundtrip and not 
to do a key exchange to speed up subsequent requests, but never mind. 

— Neil

> On 6 Oct 2021, at 17:37, Mike Jones 
>  wrote:
> 
> 
> FYI, I wrote about the nonce support at https://self-issued.info/?p=2194 and 
> https://twitter.com/selfissued/status/1445789505902899206.
>  
>-- Mike
>  
> From: OAuth  On Behalf Of Brian Campbell
> Sent: Monday, October 4, 2021 3:11 PM
> To: oauth 
> Subject: [OAUTH-WG] Fwd: New Version Notification for 
> draft-ietf-oauth-dpop-04.txt
>  
>  
> WG,
>  
> The collective DPoP co-authors are pleased to announce that a new -04 
> revision of DPoP has been published. The doc history snippet is copied below 
> for quick/easy reference. The main change here is the addition of an option 
> for a server-provided nonce in the DPoP proof.
> 
>-04
>*  Added the option for a server-provided nonce in the DPoP proof.
>*  Registered the invalid_dpop_proof and use_dpop_nonce error codes.
>*  Removed fictitious uses of realm from the examples, as they added
>   no value.
>*  State that if the introspection response has a token_type, it has
>   to be DPoP.
>*  Mention that RFC7235 allows multiple authentication schemes in
>   WWW-Authenticate with a 401.
>*  Editorial fixes.
> 
> 
> -- Forwarded message -
> From: 
> Date: Mon, Oct 4, 2021 at 4:05 PM
> Subject: New Version Notification for draft-ietf-oauth-dpop-04.txt
> To: ...
> 
> 
> 
> A new version of I-D, draft-ietf-oauth-dpop-04.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
> 
> Name:   draft-ietf-oauth-dpop
> Revision:   04
> Title:  OAuth 2.0 Demonstrating Proof-of-Possession at the 
> Application Layer (DPoP)
> Document date:  2021-10-04
> Group:  oauth
> Pages:  37
> URL:https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> Html:   https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-04
> 
> Abstract:
>This document describes a mechanism for sender-constraining OAuth 2.0
>tokens via a proof-of-possession mechanism on the application level.
>This mechanism allows for the detection of replay attacks with access
>and refresh tokens.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Manage My Preferences , Unsubscribe 


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

Re: [OAUTH-WG] Web apps BCP feedback

[Neil Madden]

> On 26 Sep 2021, at 11:28, Jim Manico  wrote:
> 
> > That’s why cookies should be set with the __Host- prefix. 
> 
> You can also set the domain of a cookie to actually be a host (subdomain). 
> Does that also prevent subdomains from clobbering root directory cookies

No, sadly not. You can set a cookie with domain set to payments.example.com but 
then I can hijack foo.example.com and set my own cookie with domain=example.com 
and the server will be none the wiser. 

Cheers,

Neil
-- 
Manage My Preferences , Unsubscribe 


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

Re: [OAUTH-WG] Web apps BCP feedback

[Neil Madden]

Right, cookie prefixes is one approach - but still has a little way to go on 
browser share [1]. 

In my book (have I mentioned my book? :-)), I show a variant of the 
double-submit cookie pattern in which the anti-CSRF token is a SHA-256 hash of 
the session cookie [2], which prevents the cookie being overridden.

We should probably just defer to the security considerations in rfc6265-bis 
[3], which already discusses some limitations of SameSite and recommends it be 
used as a defence-in-depth alongside traditional defences. 

[1]: https://caniuse.com/?search=cookie%20prefix
[2]: https://livebook.manning.com/book/api-security-in-action/chapter-4/181
[3]: 
https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-08.html#name-samesite-cookies

— Neil

> On 26 Sep 2021, at 07:30, Philippe De Ryck 
>  wrote:
> 
> That’s why cookies should be set with the __Host- prefix. 
> 
> In a carefully-designed API, CORS will function as a CSRF defense, even when 
> the attacker is controlling a subdomain or sibling domain. 
> 
> Overall, I think the first part of 6.1 makes sense, but I don’t think the 
> document should try to draw out such an architecture in 1 or 2 paragraphs at 
> the end of that section.
> 
> Philippe
> 
> —
> Pragmatic Web Security
> Security for developers
> https://pragmaticwebsecurity.com
> 
>> On 26 Sep 2021, at 00:15, Jim Manico  wrote:
>> 
>> Hi Neil! =)
>> 
>> I get your point! 
>> I would suggest this text be written as something along the lines of:
>> 
>> "Additionally, the SameSite cookie attribute can be used to  
>> prevent CSRF attacks but the application and API should  also
>> be written to use anti-CSRF tokens for stateful session-based 
>> applications 
>>   or use of the double-cookie submit pattern for stateless 
>> applications.”'
>> 
>> PS: If an adversary controls a subdomain can't they clobber and over-write 
>> root level cookies anyhow? I do not think CSRF defense will defeat an 
>> adversarial subdomains ability to over-write a cookie and circumvent 
>> double-cookie-submit. 
>> 
>>> On 9/25/21 8:10 AM, Neil Madden wrote:
>>> Technically yes, CSRF refers to cross-site attacks. However, there is a 
>>> class of attacks that are cross-*origin* but not cross-site and which are 
>>> otherwise identical to CSRF. SameSite doesn’t protect against these attacks 
>>> but other traditional CSRF defences *do*. For example, synchronizer tokens 
>>> in hidden form fields or even just requiring a custom header on requests 
>>> both provide some protection against such attacks, as they both use 
>>> mechanisms that are subject to the same origin policy rather than 
>>> same-site. 
>>> 
>>> — Neil
>>> 
>>>>> On 25 Sep 2021, at 18:20, Jim Manico  wrote:
>>>>> 
>>>>  If someone has taken over a subdomain in the ways described, that is not 
>>>> cross site request forgery since the attack is occurring from within your 
>>>> site. It’s more likely XSS that allows for cookie clobbering or similar, 
>>>> or just malicious code injected by the malicious controller of your 
>>>> subdomain. This is not strictly CSRF nor are these problems protected from 
>>>> any other standard form of CSRF defense.
>>>> 
>>>> CSRF is Cross Site attack where the attack is hosted on a different 
>>>> domain. 
>>>> 
>>>> --
>>>> Jim Manico
>>>> 
>>>>>> On Sep 25, 2021, at 1:07 AM, Dominick Baier  
>>>>>> wrote:
>>>>>> 
>>>>> 
>>>>> In 6.1 it says
>>>>> 
>>>>> "Additionally, the SameSite cookie attribute can be used to   
>>>>>  prevent CSRF attacks, or alternatively, the application and API 
>>>>> could
>>>>>  be written to use anti-CSRF tokens.”
>>>>> 
>>>>> “Prevent” is a bit strong.
>>>>> 
>>>>> SameSite only restricts cookies sent across site boundaries Iit does not 
>>>>> prevent CSRF attacks from within a site boundary. Scenarios could be a 
>>>>> compromised sub-domain, like sub-domain takeover or just some vulnerable 
>>>>> application co-located on the same site.
>>>>> 
>>>>> thanks
>>>>> ———
>>>>> Dominick Baier
>>>>> ___
>>>>> 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
>>> 
>>> Manage My Preferences, Unsubscribe
>>> 
>> -- 
>> Jim Manico
>> Manicode Security
>> https://www.manicode.com
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 

-- 
Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe 
<https://preferences.forgerock.com/>

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

Re: [OAUTH-WG] Web apps BCP feedback

[Neil Madden]

Technically yes, CSRF refers to cross-site attacks. However, there is a class 
of attacks that are cross-*origin* but not cross-site and which are otherwise 
identical to CSRF. SameSite doesn’t protect against these attacks but other 
traditional CSRF defences *do*. For example, synchronizer tokens in hidden form 
fields or even just requiring a custom header on requests both provide some 
protection against such attacks, as they both use mechanisms that are subject 
to the same origin policy rather than same-site. 

— Neil

> On 25 Sep 2021, at 18:20, Jim Manico  wrote:
> 
> If someone has taken over a subdomain in the ways described, that is not 
> cross site request forgery since the attack is occurring from within your 
> site. It’s more likely XSS that allows for cookie clobbering or similar, or 
> just malicious code injected by the malicious controller of your subdomain. 
> This is not strictly CSRF nor are these problems protected from any other 
> standard form of CSRF defense.
> 
> CSRF is Cross Site attack where the attack is hosted on a different domain. 
> 
> --
> Jim Manico
> 
>>> On Sep 25, 2021, at 1:07 AM, Dominick Baier  
>>> wrote:
>>> 
>> 
>> In 6.1 it says
>> 
>> "Additionally, the SameSite cookie attribute can be used to  
>> prevent CSRF attacks, or alternatively, the application and API 
>> could
>> be written to use anti-CSRF tokens.”
>> 
>> “Prevent” is a bit strong.
>> 
>> SameSite only restricts cookies sent across site boundaries Iit does not 
>> prevent CSRF attacks from within a site boundary. Scenarios could be a 
>> compromised sub-domain, like sub-domain takeover or just some vulnerable 
>> application co-located on the same site.
>> 
>> thanks
>> ———
>> Dominick Baier
>> ___
>> 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

-- 
Manage My Preferences , Unsubscribe 


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

Re: [OAUTH-WG] DPoP key rotation

[Neil Madden]

On 11 Jun 2021, at 21:20, Brian Campbell 
 wrote:
> 
> Hi Dmitry, 
> 
> This ML is indeed the appropriate place for this kind of thing. You raise a 
> legitimate question, however, the general rough consensus thinking has been 
> that allowing for DPoP key rotation for refresh tokens and public clients 
> (the only case where it's relevant) didn't add enough value to justify the 
> added complexity. It doesn't help with the threat model for in-browser 
> applications. And mobile applications have really good options for key 
> storage - to the point that the kind of event that might compromise a DPoP 
> key would involve a lot more than key rotation to cleanup from.  
> 


I think this is probably true for most current signature schemes [*], but does 
this assumption hold for post-quantum signature algorithms? e.g., I think for 
some hash-based signature schemes like SPHINCS there is a trade-off between 
number of signatures and signature size - so a key that can never be rotated 
may have to have larger signatures to compensate to avoid exceeding usage 
limits. I don’t know enough about the state of the art of post-quantum 
signatures to say if this is a real issue or if those schemes would be 
appropriate for DPoP in the first place, but perhaps we should get an opinion 
from CFRG before baking in this assumption?

[*] There are things like repeating or biased nonces in ECDSA that can leak the 
private key without the storage being compromised, but I think such bugs would 
also require more than key rotation to recover from.

— Neil
-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00

[Neil Madden]

I have also read it and it looks good to me. It might be worth explicitly 
discussing how it relates to the older draft [1] (that we implemented at the 
time). That older draft also included a client_id parameter in the response, so 
it would be good to clarify if that is actually needed to prevent the attack or 
not.

[1]: 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mix-up-mitigation-01 
 

Kind regards,

Neil

> On 15 Apr 2021, at 08:04, Karsten Meyer zu Selhausen 
>  wrote:
> 
> Hi all,
> 
> the latest version of the security BCP references 
> draft-ietf-oauth-iss-auth-resp-00 as a countermeasures to mix-up attacks.
> 
> There have not been any concerns with the first WG draft version so far: 
> https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ 
> 
> I would like to ask the WG if there are any comments on or concerns with the 
> current draft version.
> 
> Otherwise I hope we can move forward with the next steps and hopefully finish 
> the draft before/with the security BCP.
> 
> Best regards,
> Karsten
> 
> -- 
> Karsten Meyer zu Selhausen
> Senior IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web:  https://hackmanit.de  | IT Security Consulting, 
> Penetration Testing, Security Training
> 
> Is your OAuth or OpenID Connect client vulnerable to the severe impacts of 
> mix-up attacks? Learn how to protect your client in our latest blog post on 
> single sign-on:
> https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>  
> 
> 
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
> 
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
> Christian Mainka, Dr. Marcus Niemietz
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: Implementation Status

[Neil Madden]

ForgeRock plan to implement PAR.

— Neil

> On 24 Mar 2021, at 19:53, Hannes Tschofenig  wrote:
> 
> Hi all, 
>  
> I am working on the shepherd writeup and I need information about the 
> implementation status of this specification.
>  
> Can you share whether you are implementing, or planning to implement this 
> specification? If there is open source, please drop a link to the mailing 
> list. If you implement it in your product, please let us know as well.  
>  
> This information helps the steering committee to judge the quality and 
> maturity of the work.
>  
> Ciao
> Hannes
>  
> 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 
> 

-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

Makes sense, thanks. 

> On 18 Mar 2021, at 22:55, Brian Campbell  wrote:
> 
> 
> Thanks Neil. I'll look at incorporating that guidance. Although I think 
> referencing might be more appropriate than incorporating directly. 
> 
>> On Mon, Mar 15, 2021 at 3:44 AM Neil Madden  
>> wrote:
>> There is now a draft from the W3C explicitly addressing Spectre and its 
>> impacts on web security. I think we should aim to incorporate the guidance 
>> for “dynamic subresources” [1], and in particular the first item in the 
>> list, which is recommendations for "Application-internal resources (private 
>> API endpoints …)”. The recommended response headers given are:
>> 
>> Cross-Origin-Resource-Policy: same-origin
>> Content-Security-Policy: sandbox
>> Cross-Origin-Opener-Policy: same-origin
>> Vary: Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site
>> X-Content-Type-Options: nosniff
>> X-Frame-Options: DENY
>> 
>> Cheers,
>> 
>> Neil
>> 
>> [1]: 
>> https://w3c.github.io/webappsec-post-spectre-webdev/#dynamic-subresources 
>> 
>>> On 20 Feb 2021, at 09:07, Neil Madden  wrote:
>>> 
>>> I was mentioning it primarily as another example of the assumption that GET 
>>> requests are safe. However, the draft rfc6265bis [1] does seem concerned 
>>> about this, and mentions  as a possible attack vector. 
>>> This would again potentially pull the access token into the renderer’s 
>>> memory space (until site isolation becomes widespread). 
>>> 
>>> I also have a general dislike of SameSite cookies as a defence against 
>>> CSRF. There are CSRF-like attacks that are not strictly cross-*site* but 
>>> are cross-origin (CORF?). For example, subdomain hijacking is relatively 
>>> common [2] and completely defeats SameSite. As the draft itself says [3]:
>>> 
>>> 
>>> 
>>>"SameSite" cookies offer a robust defense against CSRF attack when
>>>deployed in strict mode, and when supported by the client.  It is,
>>>however, prudent to ensure that this designation is not the extent of
>>>a site's defense against CSRF, as same-site navigations and
>>>submissions can certainly be executed in conjunction with other
>>>attack vectors such as cross-site scripting.
>>> 
>>>Developers are strongly encouraged to deploy the usual server-side
>>>defenses (CSRF tokens, ensuring that "safe" HTTP methods are
>>>idempotent, etc) to mitigate the risk more fully.
>>> 
>>> 
>>> If we recommend SameSite for this, IMO we should do so only with the same 
>>> caveats expressed in the httpbis draft. 
>>> 
>>> [1]: 
>>> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-5.3.7.1
>>> [2]: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers#
>>> [3]: 
>>> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-8.8.1
>>> 
>>> Cheers,
>>> 
>>> Neil
>>> 
>>>>> On 19 Feb 2021, at 23:18, Brian Campbell  
>>>>> wrote:
>>>>> 
>>>> 
>>>> Thanks Neil, 
>>>> Appreciate the insight and recommendations. I think we can incorporate 
>>>> that, more or less, into the next revision. 
>>>> One point to dig into just a bit more, you said that 'SameSite has a 
>>>> "GET-out clause" in the form of “lax”'. As I understand it, such a cookie 
>>>> would still only be sent on a cross-site GET resulting from a top-level  
>>>> navigation. And in the context of the bff-token endpoint, that 
>>>> significantly reduces the ways a cross-site request could be initiated and 
>>>> those ways (pop-up or full page redirection) further limits the likelihood 
>>>> of the malicious party being able to read response data. 
>>>> 
>>>>> On Thu, Feb 18, 2021 at 5:08 AM Neil Madden  
>>>>> wrote:
>>>>> Thanks for following up, Brian. Responses below.
>>>>> 
>>>>>> On 17 Feb 2021, at 22:48, Brian Campbell  
>>>>>> wrote:
>>>>>> 
>>>>>> Always appreciate (and often learn from) your insights, Neil. I'd like 
>>>>>> to dig into the CSRF thing a bit more though to understand better and 
>>>>>> hopefully do the right thing in the draft. 
>>>>>> 
>>>>>> It seems to me that a GET at the bff

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

[Neil Madden]

> On 18 Mar 2021, at 11:33, Rifaat Shekh-Yusef  wrote:
> 
> On Thu, Mar 18, 2021 at 3:45 AM Neil Madden  <mailto:neil.mad...@forgerock.com>> wrote:
> 
> 
>> On 18 Mar 2021, at 05:33, Andrii Deinega > <mailto:andrii.dein...@gmail.com>> wrote:
>> 
>> 
>> The Cache-Control header, even with its strongest directive "no-store", is 
>> pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext 
>> Transfer Protocol: Caching).
>> 
>> This directive is NOT a reliable or sufficient mechanism for ensuring 
>> privacy.  In particular, malicious or compromised caches might not recognize 
>> or obey this directive, and communications networks might be vulnerable to 
>> eavesdropping.
> 
> This quote is about privacy. Your concerns so far have been about replay 
> protection. TLS protects both. 
> 
>> 
>> Regarding TLS, I've mentioned that we don't always have the luxury to see 
>> what is going on with the infrastructure. A bright example would be an AS 
>> implemented as a serverless application and hosted by one of the cloud 
>> providers.
> 
> Right, but (as I’ve said before) the same reasoning applies to a JWT too. The 
> infrastructure could just as easily “terminate JWS” as it currently 
> terminates TLS. As I keep saying, it’s much better to spend your time 
> ensuring end-to-end TLS than end-to-end JWT. 
> 
> That's not always possible. In some enterprises, they will have an inspection 
> middlebox that breaks the end-to-end TLS, e.g., ZScaler.

And if you use encrypted JWTs to work around that you’ll soon have inspection 
middleboxes that break end-to-end JWT. This isn’t a game we can win by adding 
more layers of the same solution.

— Neil
-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

[Neil Madden]

> On 18 Mar 2021, at 05:33, Andrii Deinega  wrote:
> 
> 
> The Cache-Control header, even with its strongest directive "no-store", is 
> pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext 
> Transfer Protocol: Caching).
> 
>> This directive is NOT a reliable or sufficient mechanism for ensuring 
>> privacy.  In particular, malicious or compromised caches might not recognize 
>> or obey this directive, and communications networks might be vulnerable to 
>> eavesdropping.

This quote is about privacy. Your concerns so far have been about replay 
protection. TLS protects both. 

> 
> Regarding TLS, I've mentioned that we don't always have the luxury to see 
> what is going on with the infrastructure. A bright example would be an AS 
> implemented as a serverless application and hosted by one of the cloud 
> providers.

Right, but (as I’ve said before) the same reasoning applies to a JWT too. The 
infrastructure could just as easily “terminate JWS” as it currently terminates 
TLS. As I keep saying, it’s much better to spend your time ensuring end-to-end 
TLS than end-to-end JWT. We should try to avoid writing specs just to work 
around badly configured infrastructure. 

(The counterexample to this is IoT applications, where messages often have to 
traverse protocol-translating proxies. But that’s not the case here).

> 
> As for,
> 
>> Right - so trying to solve this issue by replacing TLS with another 
>> technology that is just as susceptible to the problem is not a real 
>> solution. 
> 
> Following your logic, other RFCs such as 8555 (Automatic Certificate 
> Management Environment) went the wrong way with their mandatory anti-replay 
> built-in mechanism in quite similar circumstances.
> 
> https://tools.ietf.org/html/rfc8555#section-6.5

The only justification of the replay nonce given in RFC8555 is for protection 
of 0RTT early-data (which does not benefit from TLS’s normal replay 
protections). As to why a protocol that can typically tolerate latencies of 
several weeks (for cert renewal) needs 0RTT, you’ll have to ask the authors of 
that RFC. It makes little sense to me. 

— Neil

-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

[Neil Madden]

Right, but PKCE doesn’t stop an attack when the malicious app initiates the 
authorization flow. 

> On 17 Mar 2021, at 08:04, SOMMER, DOMINIK  
> wrote:
> 
> 
> I’d throw in PKCE as a means of assuring that the client who made the user 
> follow the auth flow in the first place, is apparently the only one able to 
> “redeem” the auth code returned to the redirect_uri.
>  
>  
> Von: OAuth  Im Auftrag von Om
> Gesendet: Mittwoch, 17. März 2021 06:17
> An: Neil Madden 
> Cc: Vittorio Bertocci ; oauth 
> ; Warren Parad 
> Betreff: Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token 
> Mediating and session Information Backend For Frontend (TMI BFF)]
>  
> If I read this correctly, 
> https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10 the 2.1 draft 
> already addresses this under best practices.
>  
> On Mon, Mar 15, 2021 at 3:31 PM Neil Madden  wrote:
> I want to come back to this topic as a new thread.
>  
> As I understand things, the difference on Android is that any app can claim 
> to be a generic web browser and so claim to handle all URIs. Whereas on iOS 
> only specifically vetted apps can claim to be web browsers. Is that correct?
>  
> If so, this does seem like a quite large hole in security of OAuth on 
> Android. Should we be considering a new draft recommending alternative 
> measures (such as attestation) on Android? Presumably the same issue is also 
> true on most desktop OS?
>  
> — Neil
> 
> 
> On 23 Feb 2021, at 15:20, George Fletcher  wrote:
>  
> Unfortunately, in the mobile app world this isn't sufficient. On iOS using 
> Universal Links will bind the https redirect_url to your app in a secure way 
> but it doesn't work the same way on Android with App Links. There is still a 
> problem with "mobile app impersonation". If you have an app that you want to 
> ensure is "your" app then the most secure way is to look at "app 
> attestation". This is however, way off topic for this thread :)
> 
> On 2/14/21 9:28 AM, Neil Madden wrote:
> Public clients are implicitly authenticated by their ownership of the 
> registered redirect_uri. This why it’s important to use a redirect_uri for 
> which ownership can be reasonably established, such as HTTPS endpoints with 
> exact URI matching. 
>  
> There are more things that can go wrong with that (see the security BCP), but 
> it can be made reasonably secure. 
>  
> — Neil
>  
> On 14 Feb 2021, at 13:48, Stoycho Sleptsov  wrote:
>  
> 
> I would like to add my reasons about the "Why are developers creating BFF for 
> their frontends to communicate with an AS",
> with the objective to verify if they are valid.
>  
> I need the client app. to be authenticated at the AS (to determine if it is a 
> first-party app., for example).
> If we decide to implement our client as a frontend SPA , then we have no 
> other option except through a BFF, as PKCE does not help for authentication.
>  
> Or is it considered a bad practice to do that?
>  
> Regards,
> Stoycho.
> 
> Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH, Frankfurt 
> am Main, Registereintragung / Registration: Amtsgericht Frankfurt am Main HRB 
> 116409
> Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver Schmitt
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>  
>  
> 
> ForgeRock values your Privacy___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> --
> - Regards,
> Omkar Khair
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

[Neil Madden]

No, it doesn’t mention this attack. The issue is that if the redirect_uri is 
not strongly bound to a legitimate client then a malicious app on the user’s 
device can initiate an OAuth flow and impersonate the legitimate client and 
then intercept the response by claiming to handle the redirect_uri. 

We thought this was solved by using claimed https redirect_uris (Universal 
Links on iOS, AppLinks on Android), as these require the webserver to publish a 
document explicitly granting permission for a particular app to claim part of 
its https address space. But it turns out that Android has a hole in this 
because it allows any app to claim to be a web browser and so handle all URIs. 

(I thought this attack was discussed in the security topics bcp, but I can’t 
see it). 

The 2.1 draft currently requires (MUST) ASes to support private-use URL 
schemes, which makes this problem much worse. IMO private-use URL schemes are 
un-securable and shouldn’t be encouraged let alone mandated. 

— Neil

> On 17 Mar 2021, at 05:17, Om  wrote:
> 
> If I read this correctly, 
> https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10 the 2.1 draft 
> already addresses this under best practices.
> 
>>> On Mon, Mar 15, 2021 at 3:31 PM Neil Madden  
>>> wrote:
>> I want to come back to this topic as a new thread.
>> 
>> As I understand things, the difference on Android is that any app can claim 
>> to be a generic web browser and so claim to handle all URIs. Whereas on iOS 
>> only specifically vetted apps can claim to be web browsers. Is that correct?
>> 
>> If so, this does seem like a quite large hole in security of OAuth on 
>> Android. Should we be considering a new draft recommending alternative 
>> measures (such as attestation) on Android? Presumably the same issue is also 
>> true on most desktop OS?
>> 
>> — Neil
>> 
>>> On 23 Feb 2021, at 15:20, George Fletcher  wrote:
>>> 
>>> Unfortunately, in the mobile app world this isn't sufficient. On iOS using 
>>> Universal Links will bind the https redirect_url to your app in a secure 
>>> way but it doesn't work the same way on Android with App Links. There is 
>>> still a problem with "mobile app impersonation". If you have an app that 
>>> you want to ensure is "your" app then the most secure way is to look at 
>>> "app attestation". This is however, way off topic for this thread :)
>>> 
>>>>> On 2/14/21 9:28 AM, Neil Madden wrote:
>>>> Public clients are implicitly authenticated by their ownership of the 
>>>> registered redirect_uri. This why it’s important to use a redirect_uri for 
>>>> which ownership can be reasonably established, such as HTTPS endpoints 
>>>> with exact URI matching. 
>>>> 
>>>> There are more things that can go wrong with that (see the security BCP), 
>>>> but it can be made reasonably secure. 
>>>> 
>>>> — Neil

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

[Neil Madden]

I want to come back to this topic as a new thread.

As I understand things, the difference on Android is that any app can claim to 
be a generic web browser and so claim to handle all URIs. Whereas on iOS only 
specifically vetted apps can claim to be web browsers. Is that correct?

If so, this does seem like a quite large hole in security of OAuth on Android. 
Should we be considering a new draft recommending alternative measures (such as 
attestation) on Android? Presumably the same issue is also true on most desktop 
OS?

— Neil

> On 23 Feb 2021, at 15:20, George Fletcher  wrote:
> 
> Unfortunately, in the mobile app world this isn't sufficient. On iOS using 
> Universal Links will bind the https redirect_url to your app in a secure way 
> but it doesn't work the same way on Android with App Links. There is still a 
> problem with "mobile app impersonation". If you have an app that you want to 
> ensure is "your" app then the most secure way is to look at "app 
> attestation". This is however, way off topic for this thread :)
> 
> On 2/14/21 9:28 AM, Neil Madden wrote:
>> Public clients are implicitly authenticated by their ownership of the 
>> registered redirect_uri. This why it’s important to use a redirect_uri for 
>> which ownership can be reasonably established, such as HTTPS endpoints with 
>> exact URI matching. 
>> 
>> There are more things that can go wrong with that (see the security BCP), 
>> but it can be made reasonably secure. 
>> 
>> — Neil
>> 
>>> On 14 Feb 2021, at 13:48, Stoycho Sleptsov  
>>> <mailto:stoycho.slept...@gmail.com> wrote:
>>> 
>>> 
>>> I would like to add my reasons about the "Why are developers creating BFF 
>>> for their frontends to communicate with an AS",
>>> with the objective to verify if they are valid.
>>> 
>>> I need the client app. to be authenticated at the AS (to determine if it is 
>>> a first-party app., for example).
>>> If we decide to implement our client as a frontend SPA , then we have no 
>>> other option except through a BFF, as PKCE does not help for authentication.
>>> 
>>> Or is it considered a bad practice to do that?
>>> 
>>> Regards,
>>> Stoycho.
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> <https://www.ietf.org/mailman/listinfo/oauth>
> 


-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

There is now a draft from the W3C explicitly addressing Spectre and its impacts 
on web security. I think we should aim to incorporate the guidance for “dynamic 
subresources” [1], and in particular the first item in the list, which is 
recommendations for "Application-internal resources (private API endpoints …)”. 
The recommended response headers given are:

Cross-Origin-Resource-Policy: same-origin
Content-Security-Policy: sandbox
Cross-Origin-Opener-Policy: same-origin
Vary: Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

Cheers,

Neil

[1]: https://w3c.github.io/webappsec-post-spectre-webdev/#dynamic-subresources 
<https://w3c.github.io/webappsec-post-spectre-webdev/#dynamic-subresources> 

> On 20 Feb 2021, at 09:07, Neil Madden  wrote:
> 
> I was mentioning it primarily as another example of the assumption that GET 
> requests are safe. However, the draft rfc6265bis [1] does seem concerned 
> about this, and mentions  as a possible attack vector. 
> This would again potentially pull the access token into the renderer’s memory 
> space (until site isolation becomes widespread). 
> 
> I also have a general dislike of SameSite cookies as a defence against CSRF. 
> There are CSRF-like attacks that are not strictly cross-*site* but are 
> cross-origin (CORF?). For example, subdomain hijacking is relatively common 
> [2] and completely defeats SameSite. As the draft itself says [3]:
> 
> 
> 
>"SameSite" cookies offer a robust defense against CSRF attack when
>deployed in strict mode, and when supported by the client.  It is,
>however, prudent to ensure that this designation is not the extent of
>a site's defense against CSRF, as same-site navigations and
>submissions can certainly be executed in conjunction with other
>attack vectors such as cross-site scripting.
> 
>Developers are strongly encouraged to deploy the usual server-side
>defenses (CSRF tokens, ensuring that "safe" HTTP methods are
>idempotent, etc) to mitigate the risk more fully.
> 
> 
> If we recommend SameSite for this, IMO we should do so only with the same 
> caveats expressed in the httpbis draft. 
> 
> [1]: 
> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-5.3.7.1 
> <https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-5.3.7.1>
> [2]: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers# 
> <https://www.hackerone.com/blog/Guide-Subdomain-Takeovers#>
> [3]: 
> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-8.8.1 
> <https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-8.8.1>
> 
> Cheers,
> 
> Neil
> 
>> On 19 Feb 2021, at 23:18, Brian Campbell  wrote:
>> 
>> 
>> Thanks Neil, 
>> Appreciate the insight and recommendations. I think we can incorporate that, 
>> more or less, into the next revision. 
>> One point to dig into just a bit more, you said that 'SameSite has a 
>> "GET-out clause" in the form of “lax”'. As I understand it, such a cookie 
>> would still only be sent on a cross-site GET resulting from a top-level  
>> navigation. And in the context of the bff-token endpoint, that significantly 
>> reduces the ways a cross-site request could be initiated and those ways 
>> (pop-up or full page redirection) further limits the likelihood of the 
>> malicious party being able to read response data. 
>> 
>> On Thu, Feb 18, 2021 at 5:08 AM Neil Madden > <mailto:neil.mad...@forgerock.com>> wrote:
>> Thanks for following up, Brian. Responses below.
>> 
>>> On 17 Feb 2021, at 22:48, Brian Campbell >> <mailto:bcampb...@pingidentity.com>> wrote:
>>> 
>>> Always appreciate (and often learn from) your insights, Neil. I'd like to 
>>> dig into the CSRF thing a bit more though to understand better and 
>>> hopefully do the right thing in the draft. 
>>> 
>>> It seems to me that a GET at the bff-token endpoint is "safe" in that it's 
>>> effectively just a read.
>> 
>> Well it’s a read that returns an access token. It’s “safe” in the sense of 
>> side-effects, but we absolutely want to preserve the confidentiality of what 
>> is returned and only allow it to be accessed by authorized clients (the 
>> legitimate frontend). At the moment the only thing keeping that safe is the 
>> JSON content type. For example, imagine a world in which the token-bff 
>> endpoint instead returned the access token as HTML:
>> 
>> abcd
>> 
>> Then as an attacker I can simply embed an iframe on my site that refer

Re: [OAUTH-WG] OAuth mTLS and JWK use/key_ops

[Neil Madden]

> On 8 Mar 2021, at 12:50, Neil Madden  wrote:
> 
> An interesting question was raised by our developers around the 
> interpretation of JWK “use” and “key_ops” constraints when publishing a 
> self-signed certificate for mTLS client authentication. In X.509 the KeyUsage 
> extension distinguishes between keys intended for use for verifying general 
> signatures (digitalSignature) and those used for verifying signatures on 
> certificates (keyCertSign). The JWK spec doesn’t make this distinction, so 
> there is only the generic “use”:”sig” and “key_ops”: [“verify”] indicators. 
> So, is “use”:”sig” (or “key_ops”:[“verify”]) compatible with publishing an 
> X.509 certificate (x5c claim) that asserts KeyUsage keyCertSign?
> 
> It seems plausible that an application might also choose to consume CA 
> certificates from a central certificate management service that publishes 
> them in JWK format on an internal HTTPS endpoint. So this question is 
> potentially broader than just self-signed certs, although that is the only 
> case discussed in RFC 8705.
> 
> In the course of trying to answer this question, I came across 
> https://github.com/openssl/openssl/issues/1418 
> <https://github.com/openssl/openssl/issues/1418> which has links to various 
> relevant RFCs in the discussion. The conclusion appears to be that when 
> processing self-signed certificates the KeyUsage check should be skipped. The 
> reasoning appears to be that we don’t want self-signed certs to assert the 
> keyCertSign bit, because this increases the risk of them being mistaken for 
> genuine CA certs. In fact, the language from RFC 5280 suggests this check 
> should be skipped for any trust anchor, whether self-signed or not.

I have this part backwards - RFC 5280 path validation skips the KeyUsage check 
for the end-entity certificate, not the trust anchor cert. This makes more 
sense. The rest of my comments/questions still apply though.

> 
> RFC 8705 is silent on how to interpret use/key_ops in this case, and RFC 7517 
> doesn’t discuss whether the signature-related use/key_ops are intended to 
> cover certificate signatures or not. RFC 7517 also doesn’t say whether 
> applications are even required to enforce use/key_ops constraints - it seems 
> left to the discretion of the application. (There’s no language like “the 
> application MUST NOT use the key for a use not specified”). In general, RFC 
> 7517 is silent about how constraints on any X.509 certificate interact with 
> constraints specified in the JWK itself.
> 
> My feeling is that “use”:”sig” and “key_ops”:[“verify”] probably shouldn’t 
> imply that the key can be used to verify certificate signatures (danger lies 
> that way), and that when processing a JWK specifically as a self-signed trust 
> anchor we should follow the lead of RFC 5280 and instruct applications to 
> ignore any use/key_ops constraints on the JWK. What do others think? (And how 
> would we go about clarifying this? As an errata?)
> 
> — Neil


-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth mTLS and JWK use/key_ops

[Neil Madden]

An interesting question was raised by our developers around the interpretation 
of JWK “use” and “key_ops” constraints when publishing a self-signed 
certificate for mTLS client authentication. In X.509 the KeyUsage extension 
distinguishes between keys intended for use for verifying general signatures 
(digitalSignature) and those used for verifying signatures on certificates 
(keyCertSign). The JWK spec doesn’t make this distinction, so there is only the 
generic “use”:”sig” and “key_ops”: [“verify”] indicators. So, is “use”:”sig” 
(or “key_ops”:[“verify”]) compatible with publishing an X.509 certificate (x5c 
claim) that asserts KeyUsage keyCertSign?

It seems plausible that an application might also choose to consume CA 
certificates from a central certificate management service that publishes them 
in JWK format on an internal HTTPS endpoint. So this question is potentially 
broader than just self-signed certs, although that is the only case discussed 
in RFC 8705.

In the course of trying to answer this question, I came across 
https://github.com/openssl/openssl/issues/1418 
 which has links to various 
relevant RFCs in the discussion. The conclusion appears to be that when 
processing self-signed certificates the KeyUsage check should be skipped. The 
reasoning appears to be that we don’t want self-signed certs to assert the 
keyCertSign bit, because this increases the risk of them being mistaken for 
genuine CA certs. In fact, the language from RFC 5280 suggests this check 
should be skipped for any trust anchor, whether self-signed or not.

RFC 8705 is silent on how to interpret use/key_ops in this case, and RFC 7517 
doesn’t discuss whether the signature-related use/key_ops are intended to cover 
certificate signatures or not. RFC 7517 also doesn’t say whether applications 
are even required to enforce use/key_ops constraints - it seems left to the 
discretion of the application. (There’s no language like “the application MUST 
NOT use the key for a use not specified”). In general, RFC 7517 is silent about 
how constraints on any X.509 certificate interact with constraints specified in 
the JWK itself.

My feeling is that “use”:”sig” and “key_ops”:[“verify”] probably shouldn’t 
imply that the key can be used to verify certificate signatures (danger lies 
that way), and that when processing a JWK specifically as a self-signed trust 
anchor we should follow the lead of RFC 5280 and instruct applications to 
ignore any use/key_ops constraints on the JWK. What do others think? (And how 
would we go about clarifying this? As an errata?)

— Neil
-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] One-time token login

[Neil Madden]

One option is JWT Bearer grant with “jti” and replay prevention 
(https://tools.ietf.org/html/rfc7523#page-7 ) if your AS supports it. This is 
nice if some other component is generating the emails as it needs no 
coordination with the AS. 

— Neil

> On 2 Mar 2021, at 19:04, Evert Pot  wrote:
> 
> 
> Dear list,
> 
> We have a requirement to let users log in to an application via a code sent 
> by email.
> This code needs to be exchanged for an access/refresh token pair, and should 
> only work once.
> 
> The access/refresh token scope would give limited access to the application. 
> Since we already use the authorization_code flow for other (more sensitive) 
> parts of the application, I would like to re-use the OAuth2 framework for 
> parts of this.
> 
> It doesn't sit right with me to overload the 'code' in authorization_code, so 
> I was considering introducing a new custom grant_type for our application, 
> specific for this purpose.
> It seems that grant_type in the 'token' endpoint would support extension in 
> this manner, by using a uri such as https://vendor.example/email-token
> 
> I'm comfortable implementing this, but curious:
> 
> Is there already some prior art that I'm not aware of? I'd rather not do a 
> custom grant_type if there's something standard I could do.
> Are there any major pitfalls associated with this?
> Evert
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Neil Madden]

On 24 Feb 2021, at 11:39, Bron Gondwana  wrote:
> 
>> 
>> […]
> 
> Let's get down to use cases then, rather than talking in abstracts.
> 
> I'm an end user with a copy of {The Bat email client} and I want to connect 
> it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely popular 
> open standard.  I want to be able to authenticate to each of those services 
> without saving my plaintext passwords on my hard disk where the next {Windows 
> ME} virus will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} 
> will then be exfiltrated from my {Paybuddy} account, leaving me destitute.
> 
> But, {The Bat} doesn't have a trusted client cert from my isp, because who 
> does - so there's no good protocol for me - it's either plaintext auth, or 
> it's some architecture astronaut multi-party nonsense that's massively over 
> specified and doesn't work half the time.  So I write a plain text password 
> on a post-it note which is lying in the dust under my monitor because the 
> glue has gone bad, and I hope I never accidentally click "remember me" when I 
> type it in.
> 
> That's been the reality of the end user experience for very many years.
> 
> NxM means that you can authenticate an arbitrary client against an arbitrary 
> server so long as they are both speaking a known public protocol, without 
> needing to build a trust relationship between the client vendor and the 
> server vendor first.

Does the following meet your needs?

You type your email address into {The Bat} to begin configuration. {The Bat} 
does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}. The 
discovery document reveals that {My ISP} supports open dynamic client 
registration [3][4] so {The Bat} registers and gets issued with a client id and 
client secret. {The Bat} then does a normal OAuth flow to get an access token 
to access your emails from {My ISP}. If you later stop using {The Bat} you can 
go to your page on {My ISP} and revoke its access because it has a unique 
client id.

[1]: https://openid.net/specs/openid-connect-discovery-1_0.html 

[2]: https://tools.ietf.org/html/rfc8414  
[3]: https://openid.net/specs/openid-connect-registration-1_0.html 

[4]: https://tools.ietf.org/html/rfc7591  

> 
> Any "trust relationship" is made through a user both who trusts the client 
> and trusts the server, and it's not transitive over to other users of the 
> same client and the same server.  The client author doesn't need to get a 
> signed "I trust you" from every single server, and the server author doesn't 
> have to go identify every single client.
> 
> That's what NxM means to a user, the ability to use arbitrary clients with 
> arbitrary servers so long as they both implement a documented protocol.  
> Interoperability.

That’s fine for your use-case, but that isn’t everybody’s use-case. Other 
use-cases (such as Open Banking) involve regulatory or policy frameworks in 
which open dynamic client registration is not appropriate. JMAP could have an 
RFC describing the use of OAuth with JMAP that mandates open dynamic client 
registration and discovery.


— Neil


-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

I was mentioning it primarily as another example of the assumption that GET 
requests are safe. However, the draft rfc6265bis [1] does seem concerned about 
this, and mentions  as a possible attack vector. This would 
again potentially pull the access token into the renderer’s memory space (until 
site isolation becomes widespread). 

I also have a general dislike of SameSite cookies as a defence against CSRF. 
There are CSRF-like attacks that are not strictly cross-*site* but are 
cross-origin (CORF?). For example, subdomain hijacking is relatively common [2] 
and completely defeats SameSite. As the draft itself says [3]:



   "SameSite" cookies offer a robust defense against CSRF attack when
   deployed in strict mode, and when supported by the client.  It is,
   however, prudent to ensure that this designation is not the extent of
   a site's defense against CSRF, as same-site navigations and
   submissions can certainly be executed in conjunction with other
   attack vectors such as cross-site scripting.

   Developers are strongly encouraged to deploy the usual server-side
   defenses (CSRF tokens, ensuring that "safe" HTTP methods are
   idempotent, etc) to mitigate the risk more fully.


If we recommend SameSite for this, IMO we should do so only with the same 
caveats expressed in the httpbis draft. 

[1]: 
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-5.3.7.1
[2]: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers#
[3]: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-8.8.1

Cheers,

Neil

> On 19 Feb 2021, at 23:18, Brian Campbell  wrote:
> 
> 
> Thanks Neil, 
> Appreciate the insight and recommendations. I think we can incorporate that, 
> more or less, into the next revision. 
> One point to dig into just a bit more, you said that 'SameSite has a "GET-out 
> clause" in the form of “lax”'. As I understand it, such a cookie would still 
> only be sent on a cross-site GET resulting from a top-level  navigation. And 
> in the context of the bff-token endpoint, that significantly reduces the ways 
> a cross-site request could be initiated and those ways (pop-up or full page 
> redirection) further limits the likelihood of the malicious party being able 
> to read response data. 
> 
>> On Thu, Feb 18, 2021 at 5:08 AM Neil Madden  
>> wrote:
>> Thanks for following up, Brian. Responses below.
>> 
>>> On 17 Feb 2021, at 22:48, Brian Campbell  wrote:
>>> 
>>> Always appreciate (and often learn from) your insights, Neil. I'd like to 
>>> dig into the CSRF thing a bit more though to understand better and 
>>> hopefully do the right thing in the draft. 
>>> 
>>> It seems to me that a GET at the bff-token endpoint is "safe" in that it's 
>>> effectively just a read.
>> 
>> Well it’s a read that returns an access token. It’s “safe” in the sense of 
>> side-effects, but we absolutely want to preserve the confidentiality of what 
>> is returned and only allow it to be accessed by authorized clients (the 
>> legitimate frontend). At the moment the only thing keeping that safe is the 
>> JSON content type. For example, imagine a world in which the token-bff 
>> endpoint instead returned the access token as HTML:
>> 
>> abcd
>> 
>> Then as an attacker I can simply embed an iframe on my site that refers to 
>> your bff-endpoint and then parse the access token out of the DOM. The 
>> browser will happily load that iframe and send along the cookie when it 
>> makes the request. If you have CORS enabled on your site (with 
>> Access-Control-Allow-Credentials) then any of the allowed CORS origins can 
>> directly call the bff-token endpoint and read the access token even in JSON 
>> form. There have also been historical same-origin policy bypasses using 
>> Flash, Adobe Reader, or other plugins (thankfully now largely eliminated), 
>> or by redefining JavaScript prototypes - see 
>> https://haacked.com/archive/2009/06/25/json-hijacking.aspx/ . These are 
>> largely fixed, but I wouldn’t bet on there never being another one.
>> 
>> 
>>> There could be a "cache miss" where the backend attempts to use a refresh 
>>> token it has to get a new access token from the remote AS, which will be 
>>> more resource intensive but doesn't fundamentally alter the state of the 
>>> backend so is still "safe". That in conjunction with your pointing to 
>>> Cross-Origin Read Blocking makes me think your concern isn't so much about 
>>> traditional CSRF used to take some malicious action but rather about 
>>> somehow (speculative side-channel attacks, 

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

> On 18 Feb 2021, at 12:25, Philippe De Ryck 
>  wrote:
> 
>> On 18 Feb 2021, at 13:08, Neil Madden  wrote:
>> 
>> Thanks for following up, Brian. Responses below.
>> 
>>> On 17 Feb 2021, at 22:48, Brian Campbell  wrote:
>>> 
>>> Always appreciate (and often learn from) your insights, Neil. I'd like to 
>>> dig into the CSRF thing a bit more though to understand better and 
>>> hopefully do the right thing in the draft. 
>>> 
>>> It seems to me that a GET at the bff-token endpoint is "safe" in that it's 
>>> effectively just a read. 
>> 
>> Well it’s a read that returns an access token. It’s “safe” in the sense of 
>> side-effects, but we absolutely want to preserve the confidentiality of what 
>> is returned and only allow it to be accessed by authorized clients (the 
>> legitimate frontend). At the moment the only thing keeping that safe is the 
>> JSON content type. For example, imagine a world in which the token-bff 
>> endpoint instead returned the access token as HTML:
>> 
>> abcd
>> 
>> Then as an attacker I can simply embed an iframe on my site that refers to 
>> your bff-endpoint and then parse the access token out of the DOM. The 
>> browser will happily load that iframe and send along the cookie when it 
>> makes the request.
> 
> You are overlooking basic browser security measures like the Same-Origin 
> Policy here. The browser will only allow access to an iframe if it has the 
> same origin as the context accessing the frame. If an attacker embeds this 
> frame in their site, it will be a cross-origin frame, and access will be 
> denied.

Right, HTML was a bad example. But again remember that at this point the 
content is already loaded into the renderer process and so vulnerable to 
Spectre and other side-channel attacks. 

As MDN says 
(https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy):

“To prevent cross-origin reads of a resource, ensure that it is not embeddable. 
It is often necessary to prevent embedding because embedding a resource always 
leaks some information about it.”

My point is that the server is performing essentially no real security checks 
and relying on the user-agent for pretty much all security guarantees. This is 
ok when those mechanisms are robust, but they really aren’t in the case of 
embeddable resources and browser vendors are still trying to close all the 
holes. 

> 
> FYI, simple CORS requests follow the same security pattern (when headers are 
> missing, browsers do not expose the response).

But many sites already return those CORS headers to enable cross-origin 
functionality. On those sites bff-token is completely insecure because 
cross-origin clients can now use that access to get an access token intended 
for the first-party SPA and use it to access other APIs! I can’t emphasise 
enough how much of a security disaster this could be. 

> Preflighted CORS requests cover "new features" (i.e., stuff you traditionally 
> could not do with HTML elements) and ask permission before sending a request. 

But GET requests don’t trigger preflight unless they have custom headers.

> Also, if you're worried about framing, it's much simpler to require the token 
> endpoint to send "X-Frame-Options: DENY" and "Content-Security-Policy: 
> frame-ancestors 'none'" response headers. This denies framing altogether 
> without going into complicated CORS territory.

You’re pretty much entirely missing the point of my message if you think it’s 
about framing specifically. Think of all the possible ways there are to embed 
cross-origin resources: CSS stylesheets, script embedding, images, video, 
audio, fonts, WebGL textures, objects, etc. If a new endpoint requires setting 
15 new CSP policies just to make it not obviously insecure, it’s maybe a clue 
that it’s not a sensible design. 

To say that we’re not comfortable with tokens in localStorage but to then 
expose a simple GET endpoint for retrieving access tokens is IMO not a good 
idea. The SOP protections applied to localStorage are *far* more robust than 
those applied to GET requests. 

— Neil

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

one. Or like even mandating a non-standard header be in the 
> request, "X-Neil-says-beware-CSRF: yuppers" as a strawman. With such a header 
> it could remain a GET. And I kinda like GET because it is really a request 
> for data.  Or perhaps the request should be a POST with built-in CSRF 
> protection by changing it to carry any parameters as JSON in the body with 
> "{}" for the case of no parameters specified?  Or just make it a PUT and call 
> it good? Not sure any of these are good ideas but just trying to hash out the 
> most appropriate thing to do. 

Right, the preference for POST is because it's more likely to trigger CSRF 
defences, which often consider GET/HEAD requests to be “safe”. Even before 
Spectre, there is a whole array of side-channel attacks for extracting 
information from cross-site responses: https://xsleaks.dev 
<https://xsleaks.dev/> . Note that even SameSite has a "GET-out clause" in the 
form of “lax”.

So yes, the real requirement is that the endpoint should have adequate CSRF 
protection. Requiring a special header has had bypasses in the past (again, 
mostly using Flash).

So I think we should recommend the following:

1. The response MUST contain a correct Content-Type: application/json header 
and X-Content-Type-Options: nosniff.
2. The cookie SHOULD be marked as HttpOnly.
3. The endpoint MUST NOT be accessible via CORS.
4. The endpoint SHOULD have adequate CSRF protections in place. At a minimum 
the cookie should be marked as SameSite. 

We could perhaps add an informational reference to 
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
 
<https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html>
 given that there is a changing landscape around cookies at the moment. If the 
browser vendors do eliminate 3rd-party cookies then 1, 3, and 4 become largely 
unnecessary (although 3 might still be a risk due to sub-domain hijacking, and 
1 will always be good practice).

— Neil

> 
> That got a little rambly, sorry. But hopefully it makes some sense. 
> 
> On Sun, Feb 14, 2021 at 1:17 AM Neil Madden  <mailto:neil.mad...@forgerock.com>> wrote:
> 
> The combination of the bff-token endpoint recommending the use of GET 
> requests together with the hint to use cookie-based authentication is likely 
> going to punch a hole in most CSRF defenses, which assume that GETs are safe. 
> The only thing preventing this being exploitable is Cross-Origin Read 
> Blocking 
> (https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md
>  
> <https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md>)
>  due to the JSON content-type. That makes me really nervous. We should at 
> least mandate X-Content-Type-Options: nosniff on that response. I’d feel more 
> comfortable if this was a POST request only. 
> 
> — Neil
> 
> 
> 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.


-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

Do you eliminate the cookies too?

> On 17 Feb 2021, at 19:50, Dominick Baier  wrote:
> 
> 
> Well. Maybe it is at least worth while then to at least mention that you 
> could also take a slightly different approach and eliminate all tokens in the 
> browser - with the respective trade offs.
> 
> ———
> Dominick Baier
> 
>> On 17. February 2021 at 20:46:42, Warren Parad (wpa...@rhosys.ch) wrote:
>> 
>>> While someone will always say “but this doesn’t solve the XSS problem” - 
>>> this is absolutely correct. But when there are no tokens in the browser - 
>>> you can simply eliminate that part of the threat model ;)
>> The point was it doesn't eliminate anything, it just changes the 
>> request/response data that is part of the attack. This doesn't increase 
>> security, as a matter of fact, with regard to the RFC, we shouldn't talk 
>> about security at all, since it has zero impact on it.
>> 
>> It is worth talking about that pattern as one possible solution to 
>> maintaining sessions, but that's it.
>> 
>> 
>> Warren Parad
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement 
>> Authress.
>> 
>> 
>>> On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier  
>>> wrote:
>>> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side and 
>>> the BFF proxies the API calls if necessary. Also the RT management happens 
>>> server-side and is transparent to the SPA.
>>> 
>>> I see that in lots of industries - finance, health, cloud providers
>>> 
>>> While someone will always say “but this doesn’t solve the XSS problem” - 
>>> this is absolutely correct. But when there are no tokens in the browser - 
>>> you can simply eliminate that part of the threat model ;)
>>> 
>>> ———
>>> Dominick Baier
>>> 
 On 17. February 2021 at 18:30:23, Vittorio Bertocci 
 (vittorio.berto...@auth0.com) wrote:
 
 Thanks Dominick,
 
 It is indeed a very simple spec, but as you can see from the discussion so 
 far, it doesn’t appear to be trivial- and there might be some 
 considerations we consider obvious (eg scope escalation) that might not be 
 super clear otherwise.
 
 In terms of the guidance, just to make sure I get the scope right- that 
 means that also code+PKCE+rotating RTs in JS would not be acceptable for 
 your customers?
 
  
 
 From: Dominick Baier 
 Date: Wednesday, February 17, 2021 at 00:27
 To: Brian Campbell , Torsten Lodderstedt 
 
 Cc: Vittorio Bertocci , "oauth@ietf.org" 
 
 Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend 
 For Frontend (TMI BFF)
 
  
 
 Hey, 
 
  
 
 Tbh - I have a bit of a hard time to see why this requires a spec, if that 
 is all you are aiming at. Wouldn’t that be just an extension to the “OAuth 
 for web apps BCP?”.
 
  
 
 All I can add here is - this approach would not work for any of our 
 customer. Because their real motivation is to implement a more and more 
 common security guideline these days - namely: “no JS-accessible tokens in 
 the browser” - but this document doesn’t cover this.
 
  
 
 cheers 
 
 ———
 
 Dominick Baier
 
  
 
 On 16. February 2021 at 22:01:37, Brian Campbell 
 (bcampbell=40pingidentity@dmarc.ietf.org) wrote:
 
  
 
  
 
  
 
 On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt 
  wrote:
 
 Thank you again for the explanation. 
 
 I think your assumption about the overall flow should be described in the 
 draft.
 
  
 
 We did attempt to capture the assumptions in the draft but clearly could 
 have done a better job with it :)
 
  
 
 
 As I understand it now the core contribution of your proposal is to move 
 refresh token management from frontend to backend. Is that correct? 
 
  
 
  Taking that a bit further - the idea is that the backend takes on the 
 responsibilities of being a confidential client (client creds, token 
 acquisition, token management/persistence, etc.) to the external AS(s). 
 And TMI BFF describes a way for that backend to deliver access tokens to 
 its own frontend. 
 
 
 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 
 OAuth@ietf.org 
 https://www.ietf.org/mailman/listinfo/oauth
 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.or

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

Yes, I’ve argued against this distinction for DPoP too. Since the first days of 
HttpOnly attackers learnt to proxy requests through the browser (as you know of 
course). This is not only to bypass the restrictions but it’s also just much 
better for the attacker because it hides their traffic and origin. People are 
online all the time now, so this is at best a mild inconvenience. 

— Neil

> On 15 Feb 2021, at 11:09, Philippe De Ryck 
>  wrote:
> 
> 
>> 
>>> On 15 Feb 2021, at 11:50, Neil Madden  wrote:
>>> 
>>>> On 15 Feb 2021, at 10:26, Philippe De Ryck 
>>>>  wrote:
>>> 
>>>>> On 15 Feb 2021, at 11:14, Neil Madden  wrote:
>>>>> 
>>>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck 
>>>>>>  wrote:
>>>>>> 
>>>>> [...]
>>>>> 
>>>>> Compared to using a worker for handling RTs, I believe the TMI-BFF only 
>>>>> adds a single security benefit: an attacker is no longer able to run a 
>>>>> silent flow to obtain a fresh set of tokens (since the client is now a 
>>>>> confidential client). 
>>>> 
>>>> But they can just call the bff-token endpoint to do the same. If there is 
>>>> a security advantage, IMO it is as a defence in depth against open 
>>>> redirects, unicode normalisation attacks (ie not validating the 
>>>> redirect_uri correctly at the AS), etc. 
>>> 
>>> A Web Worker and the TMI-BFF both encapsulate the RT and only expose the 
>>> (short-lived) AT.
>> 
>> I don’t think this distinction matters at all from a security point of view. 
>> It’s the AT that attackers are after - why bother with a RT if I can just 
>> call the bff-token endpoint to get a new AT every time?
> 
> Getting an AT from the BFF (or a worker) is an “online” attack, which only 
> works as long as the application/malicious code is loaded in the browser of 
> the user. 
> 
> Stealing a working refresh token (e.g., with a silent flow) is an “offline” 
> attack, which gives long-term access (lifetime of the RT), independent of the 
> state of the application in the user’s browser.
> 
> There is a clear distinction, but whether that matters is a different 
> discussion. It depends on how the application used, and how token lifetimes 
> are configured. FWIW, the DPoP threat model makes the same distinction 
> ("Stolen token (XSS)” vs “XSS (Victim is online)”) here: 
> https://danielfett.de/2020/05/04/dpop-attacker-model/
> 
> Philippe
>  
> 

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

> On 15 Feb 2021, at 10:26, Philippe De Ryck 
>  wrote:
> 
> 
> 
>>> On 15 Feb 2021, at 11:14, Neil Madden  wrote:
>>> 
>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck 
>>>>  wrote:
>>>> 
>>> [...]
>>> 
>>> Compared to using a worker for handling RTs, I believe the TMI-BFF only 
>>> adds a single security benefit: an attacker is no longer able to run a 
>>> silent flow to obtain a fresh set of tokens (since the client is now a 
>>> confidential client). 
>> 
>> But they can just call the bff-token endpoint to do the same. If there is a 
>> security advantage, IMO it is as a defence in depth against open redirects, 
>> unicode normalisation attacks (ie not validating the redirect_uri correctly 
>> at the AS), etc. 
> 
> A Web Worker and the TMI-BFF both encapsulate the RT and only expose the 
> (short-lived) AT.

I don’t think this distinction matters at all from a security point of view. 
It’s the AT that attackers are after - why bother with a RT if I can just call 
the bff-token endpoint to get a new AT every time?

> 
> With the worker-based approach, the client is a public client that completes 
> the code exchange without authentication. This allows an attacker to run an 
> independent silent flow in an iframe within the legitimate application. This 
> flow relies on the existing cookie-based session with the AS to obtain an AT 
> and RT, independent of the tokens of the client application. A confidential 
> client does not suffer from this problem (a stolen code cannot be exchanged 
> without client authN, and when done through the BFF, the RT is not exposed). 
> 
> And as you state, there are other benefits as well.
> 
> Philipp
> 
> —
> Pragmatic Web Security
> Security for developers
> https://pragmaticwebsecurity.com/

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

> On 15 Feb 2021, at 08:32, Philippe De Ryck 
>  wrote:
> 
> [...]
> 
> Compared to using a worker for handling RTs, I believe the TMI-BFF only adds 
> a single security benefit: an attacker is no longer able to run a silent flow 
> to obtain a fresh set of tokens (since the client is now a confidential 
> client). 

But they can just call the bff-token endpoint to do the same. If there is a 
security advantage, IMO it is as a defence in depth against open redirects, 
unicode normalisation attacks (ie not validating the redirect_uri correctly at 
the AS), etc. 

— Neil
-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth