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

[Brian Campbell]

Thanks William and nice to see you pop up on the list again. Your
perspective and feedback is appreciated (and missed a little bit these
days). Attempts to respond to things that seemed to warrant a response are
inline below.

On Sun, May 3, 2020 at 5:54 PM William Denniss  wrote:

> Hi Brian, et. al,
>
> I reviewed the document. Overall I think the concept is clearly
> communicated, both the need, and how it is implemented. It was easy to
> read, and concise. Great work!
>
> Some comments and nits:
>
> § 1:
> (nit) "DPoP" should be defined on first use in the body of the document,
> in my opinion.
>

Yeah, you're probably right. Will make that change.



> § 3:
>
> I don't follow this why the sentence "For confidential clients, refresh
> tokens are bound to the "client_id", which is more flexible than binding it
> to a particular public key." belongs in this explanation of the diagram. Is
> it indicating that DPoP is not required for confidential clients? If the
> sentence was deleted / moved elsewhere in the doc, would it alter the
> meaning of the diagram?
>
> I wonder if the diagram would be simpler with less optionality (e.g.
> public / confidential separated into 2 diagrams, if they behave
> differently), or maybe just kept as 1 simple diagram, with any optionality
> described later. Generally I think these kind of overview diagrams (which
> are extremely helpful, and now I must go add one to my own draft) are best
> if they give an overview of the protocol without trying to document the
> entire specification, or justify why different decisions are made.
>

So the intended intent of the document is that refresh tokens be DPoP bound
only when issued to public clients. RFC6749 already requires that an AS
bind refresh tokens to the client to which they were issued and that
confidential clients (those having established authentication credentials
with the AS) authenticate to the AS when presenting a refresh token. Thus,
refresh tokens issued to confidential clients are already
sender-constrained to the client and its credentials.

Although the binding of refresh tokens only applies to public clients, it
seemed like a relevant enough piece of the overall DPoP picture to warrant
inclusion in the intro. And it doesn't change the overall flow so a
separate diagram would look the same :/

I take your point, however, and can work towards the "simple diagram, with
any optionality described later" type approach. Which, I think might just
end up being some tightening up of the language in the intro and better
explaining and justifying things later in the document.



§ 4.1 figure 2
>
> (nit) When showing a decoded JWT with the signature dropped, I think it's
> a good idea to first present the full encoded JWT. Someone who is new to
> JWT may not realize that this data has a signature (or even that it is
> encoded at all), since it was dropped already, while showing the
> before/after can make this clear. Not essential, I just think it would help
> readers. Having this also sets the scene for later when encoded JWTs are
> used in example request headers.
>

I'm always trying to find the right balance of including enough to be
useful but not too darn much in examples. In this case though I think you
might be right and that first presenting the full encoded JWT would be
useful. But also not overdoing it.


§ 4.1, below figure 2:
>
> Regarding "Note: To keep DPoP simple to implement, only the HTTP method
> and URI
>are signed in DPoP proofs."
>
> I found this confusing as the entire JWT is signed, and the signature
> covers the whole JWT and not just those 2 claims. I get that since the JWT
> only meaningfully contains the HTTP method and URI that the statement is
> effectively true, but I would rephrase. Something along the lines of:
>
> "Of the HTTP headers in the request, only the HTTP method and URI are
> included in the DPoP JWT, and therefore only these 2 headers of the request
> are covered by the DPoP proof"
>

Agree this could be phrased in a better way.




> (nit) I would also drop the "To keep DPoP simple to implement" here, and
> maybe move any discussion about the design trade-offs to the security
> considerations (9.4).
>

Makes sense.


>
> § 5
>
> (nit) Expand "AS" on first use (or better: just say "authorization server"
> and skip the acronym in this case, as "AS" is insider lingo IMO)
>

Will just stick with "authorization server" here and throughout.



> § 5
>
> Regarding "If a refresh token is issued to a public client"...
>
> What about when it's issued to the confidential client? I think when
> specific behavior is documented for one client type, it's probably good to
> at least mention how the other types behave.
>
> I think this could be clarified here. In fact, I wonder if the text I
> highlighted earlier from § 3 might belong here.
>

Yeah, I think some of the more wordy bits from § 3 would be better moved
here. That could keep the intro context more concise and, to your point,
cover 

Re: [OAUTH-WG] May 4th Interim Meeting Material

[Rifaat Shekh-Yusef]

All,

You can find the meeting minutes and the link to the recording on the
following link:
https://datatracker.ietf.org/meeting/interim-2020-oauth-07/materials/minutes-interim-2020-oauth-07-202005041200


Thanks to *Jared Jennings* for taking these notes.

Regards,
 Rifaat


On Mon, May 4, 2020 at 11:38 AM Jared Jennings 
wrote:

> I'll be taking notes here
> https://docs.google.com/document/d/1gVTUzkMFvS-XyrYBiXOqbUnl5zp5nlhZf57oKFY2bzc/edit?usp=sharing
>
> Of course, Rifaat will publish once complete.
>
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> WhatsApp: +1 816.678.4152
>
>
> On Sun, May 3, 2020 at 4:02 PM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> Here is a link to the meeting material for tomorrow's meeting:
>> https://datatracker.ietf.org/meeting/interim-2020-oauth-07/session/oauth
>>
>>
>> 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] DPoP: Threat Model

[Philippe De Ryck]

On 4 May 2020, at 21:44, Daniel Fett  wrote:
> 
> Am 04.05.20 um 21:27 schrieb Philippe De Ryck:
>> 
 (https://beefproject.com ) rather than 
 exfiltrating tokens/proofs.
>>> As a sidenote: BeEF is not really XSS but requires a full browser 
>>> compromise.
>>> 
>> 
>> No, it’s not. The hook for BeEF is a single JS file, containing a wide 
>> variety of attack payloads that can be launched from the command and control 
>> center. You can combine BeEF with Metasploit to leverage an XSS to exploit 
>> browser vulnerabilities and break out.
> I shall stand corrected!
>> 
>> Just keep in mind that once an attacker has an XSS foothold, it is extremely 
>> hard to prevent abuse. The only barrier that cannot be broken (in a secure 
>> browser) is the Same Origin Policy. Keeping tokens and metadata in a 
>> separate environment (e.g., iframe, worker, …) is effective to keep them out 
>> of reach. However, once the app “extracts” data from such a context, the 
>> same problem arises. 
> Compartmentalization within an origin is as old a problem as it is mostly 
> unsolved, indeed. That is why I would not further differentiate in case the 
> browser is online and the client's script is compromised, but instead assume 
> that the attacker can then forge arbitrary requests using the token.
> 
I agree on that assumption. The moment malicious script executes, it’s game 
over, regardless of the specifics on whether a token can be extracted or not. 
Even with isolation, an attacker would be able to trick the isolated context in 
making requests as a confused deputy.

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

Re: [OAUTH-WG] DPoP: Threat Model

[Daniel Fett]

Am 04.05.20 um 21:27 schrieb Philippe De Ryck:
>
>>> (https://beefproject.com ) rather than
>>> exfiltrating tokens/proofs.
>>
>> As a sidenote: BeEF is not really XSS but requires a full browser
>> compromise.
>>
>
> No, it’s not. The hook for BeEF is a single JS file, containing a wide
> variety of attack payloads that can be launched from the command and
> control center. You can combine BeEF with Metasploit to leverage an
> XSS to exploit browser vulnerabilities and break out.
I shall stand corrected!
>
> Just keep in mind that once an attacker has an XSS foothold, it is
> extremely hard to prevent abuse. The only barrier that cannot be
> broken (in a secure browser) is the Same Origin Policy. Keeping tokens
> and metadata in a separate environment (e.g., iframe, worker, …) is
> effective to keep them out of reach. However, once the app “extracts”
> data from such a context, the same problem arises.

Compartmentalization within an origin is as old a problem as it is
mostly unsolved, indeed. That is why I would not further differentiate
in case the browser is online and the client's script is compromised,
but instead assume that the attacker can then forge arbitrary requests
using the token.

-Daniel

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

Re: [OAUTH-WG] DPoP: Threat Model

[Philippe De Ryck]

>> (https://beefproject.com ) rather than 
>> exfiltrating tokens/proofs.
> As a sidenote: BeEF is not really XSS but requires a full browser compromise.
> 

No, it’s not. The hook for BeEF is a single JS file, containing a wide variety 
of attack payloads that can be launched from the command and control center. 
You can combine BeEF with Metasploit to leverage an XSS to exploit browser 
vulnerabilities and break out.

FYI, the name for the attack where the attacker proxies calls through the 
user’s browser is known as Session Riding. 

Just keep in mind that once an attacker has an XSS foothold, it is extremely 
hard to prevent abuse. The only barrier that cannot be broken (in a secure 
browser) is the Same Origin Policy. Keeping tokens and metadata in a separate 
environment (e.g., iframe, worker, …) is effective to keep them out of reach. 
However, once the app “extracts” data from such a context, the same problem 
arises. By rewriting JS functions, the attacker can extract tokens from deep 
within an SDK, as I discuss here: 
https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html 


Kind regards

Philippe
> Thanks for the feedback!
> 
> -Daniel
> 
> 
> 
>> You can protect against exfiltration attacks by e.g. token binding the DPoP 
>> proofs and/or access token, or storing the access token in a HttpOnly cookie 
>> (gasp!). You can protect against exfiltrating post-dated DPoP proofs by 
>> storing the private key in a separate origin loaded in an iframe that you 
>> use postMessage to ask for proof tokens so the attacker is not in control of 
>> those claims. Nothing really protects against an attacker proxying requests 
>> through your browser, so this is purely post-compromise recovery rather than 
>> an actual defence against XSS.
>> 
>> — Neil
>> 
>>> On 4 May 2020, at 18:24, Daniel Fett >> > wrote:
>>> 
>>> Hi all,
>>> 
>>> as mentioned in the WG interim meeting, there are several ideas floating 
>>> around of what DPoP actually does.
>>> 
>>> In an attempt to clarify this, if have unfolded the use cases that I see 
>>> and written them down in the form of attacks that DPoP defends against: 
>>> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html 
>>> 
>>> Can you come up with other attacks? Are the attacks shown relevant?
>>> 
>>> Cheers,
>>> 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

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

Re: [OAUTH-WG] DPoP: Threat Model

[Daniel Fett]

Am 04.05.20 um 19:54 schrieb Neil Madden:
> I mentioned another one in my recent email - BREACH attacks against
> HTTP compression being used to steal access tokens in transit.
Excellent point, I added that one.
>
> There’s a variant of the online XSS attacks in which the attacker just
> proxies requests through the victim’s browser

That was the attack that should have been described under "Online XSS"
in the first place. I somehow got confused along the way. Exfiltration
of precomputed values is definitely /not/ "Online XSS".

> (https://beefproject.com) rather than exfiltrating tokens/proofs.

As a sidenote: BeEF is not really XSS but requires a full browser
compromise.

Thanks for the feedback!

-Daniel


> You can protect against exfiltration attacks by e.g. token binding the
> DPoP proofs and/or access token, or storing the access token in a
> HttpOnly cookie (gasp!). You can protect against exfiltrating
> post-dated DPoP proofs by storing the private key in a separate origin
> loaded in an iframe that you use postMessage to ask for proof tokens
> so the attacker is not in control of those claims. Nothing really
> protects against an attacker proxying requests through your browser,
> so this is purely post-compromise recovery rather than an actual
> defence against XSS.
>
> — Neil
>
>> On 4 May 2020, at 18:24, Daniel Fett > > wrote:
>>
>> Hi all,
>>
>> as mentioned in the WG interim meeting, there are several ideas
>> floating around of what DPoP actually does.
>>
>> In an attempt to clarify this, if have unfolded the use cases that I
>> see and written them down in the form of attacks that DPoP defends
>> against:
>> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html
>>
>> Can you come up with other attacks? Are the attacks shown relevant?
>>
>> Cheers,
>> 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: Threat Model

[Daniel Fett]

Hi Denis,

We discussed these kinds of collusion attacks at great length previously
on this list. My views on them have not changed.

Am 04.05.20 um 20:06 schrieb Denis:
> As soon as a software solution would be available to perform this
> collaborative attack, everybody would be able to use it.

Teamviewer is sufficient and widely available.

-Daniel


> Denis
>
>> Hi all,
>>
>> as mentioned in the WG interim meeting, there are several ideas
>> floating around of what DPoP actually does.
>>
>> In an attempt to clarify this, if have unfolded the use cases that I
>> see and written them down in the form of attacks that DPoP defends
>> against:
>> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html
>>
>> Can you come up with other attacks? Are the attacks shown relevant?
>>
>> Cheers,
>> 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


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

Re: [OAUTH-WG] DPoP: Threat Model

[Denis]

Hi Daniel,

Yes indeed. For another attack, please see my email sent to the list on 
01/05/2020 at 10:47 (Paris time).

The subject was: DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks.

When the JWT does not contain a sufficient number of attributes that 
would allow to identify the user,
the collaborative user can transmit it to anybody else, without the risk 
to be detected by the RS.  E.g. it
only contains the age of the user and a membership to a large group of 
people.


When the JWT contains attributes that uniquely allow to identify the 
collaborative user, then the other client
will be in a position to impersonate the collaborative user. Some users 
may not accept to be impersonated

by anybody and thus will only be collaborative with some trusted friends.

This collaborative attack would be much simpler to accomplish than the 
four types of attacks that have been described.
As soon as a software solution would be available to perform this 
collaborative attack, everybody would be able to use it.


Denis


Hi all,

as mentioned in the WG interim meeting, there are several ideas 
floating around of what DPoP actually does.


In an attempt to clarify this, if have unfolded the use cases that I 
see and written them down in the form of attacks that DPoP defends 
against:

https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

Can you come up with other attacks? Are the attacks shown relevant?

Cheers,
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: Threat Model

[Neil Madden]

I mentioned another one in my recent email - BREACH attacks against HTTP 
compression being used to steal access tokens in transit.

There’s a variant of the online XSS attacks in which the attacker just proxies 
requests through the victim’s browser (https://beefproject.com 
) rather than exfiltrating tokens/proofs. You can 
protect against exfiltration attacks by e.g. token binding the DPoP proofs 
and/or access token, or storing the access token in a HttpOnly cookie (gasp!). 
You can protect against exfiltrating post-dated DPoP proofs by storing the 
private key in a separate origin loaded in an iframe that you use postMessage 
to ask for proof tokens so the attacker is not in control of those claims. 
Nothing really protects against an attacker proxying requests through your 
browser, so this is purely post-compromise recovery rather than an actual 
defence against XSS.

— Neil

> On 4 May 2020, at 18:24, Daniel Fett  wrote:
> 
> Hi all,
> 
> as mentioned in the WG interim meeting, there are several ideas floating 
> around of what DPoP actually does.
> 
> In an attempt to clarify this, if have unfolded the use cases that I see and 
> written them down in the form of attacks that DPoP defends against: 
> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html 
> 
> Can you come up with other attacks? Are the attacks shown relevant?
> 
> Cheers,
> 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

[OAUTH-WG] Mix-Up Revisited

[Daniel Fett]

Hi all,

to make substantiated recommendations for FAPI 2.0, the security
considerations for PAR, and the security BCP, I did another analysis on
the threats that arise from mix-up attacks. I was interested in
particular in two questions:

  * Does PAR help preventing mix-up attacks?
  * Do we need JARM to prevent mix-up attacks?

I wrote down several attack variants and configurations in the following
document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html

The key takeaways are:

 1. The security BCP needs to make clear that per-*AS* redirect URIs are
only sufficient if OAuth Metadata is not used to resolve multiple
issuers. Otherwise, per-*Issuer* redirect URIs or the iss parameter
MUST be used.
 2. PAR-enabled authorization servers can protect the integrity better
and protect against Mix-Up Attacks better if they ONLY accept PAR
requests.
 3. We should emphasize the importance of the iss parameter (or issuer)
in the authorization response. Maybe introduce this parameter in the
security BCP or another document?
 4. Sender-constrained access tokens help against mix-up attacks when
the access token is targeted.
 5. Sender-constraining the authorization code (PAR + PAR-DPoP?) might
be worth looking into.

I would like to hear your thoughts!

-Daniel

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

[OAUTH-WG] DPoP: Threat Model

[Daniel Fett]

Hi all,

as mentioned in the WG interim meeting, there are several ideas floating
around of what DPoP actually does.

In an attempt to clarify this, if have unfolded the use cases that I see
and written them down in the form of attacks that DPoP defends against:
https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

Can you come up with other attacks? Are the attacks shown relevant?

Cheers,
Daniel

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

Re: [OAUTH-WG] May 4th Interim Meeting Material

[Jared Jennings]

I'll be taking notes here
https://docs.google.com/document/d/1gVTUzkMFvS-XyrYBiXOqbUnl5zp5nlhZf57oKFY2bzc/edit?usp=sharing

Of course, Rifaat will publish once complete.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152


On Sun, May 3, 2020 at 4:02 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Here is a link to the meeting material for tomorrow's meeting:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-07/session/oauth
>
> 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] New Version Notification for draft-ietf-oauth-dpop-01.txt

[Neil Madden]

Some review comments:

Section 1:
I think terms like “relatively simple” are subjective and should be left out. I 
don’t think the machinery of JWS signature verification (and associated 
security issues) is necessarily simple at all.

“stronger methods … such as [RFC8705] or [token binding]”
I would dispute that these are actually stronger methods in the context of an 
SPA, putting aside the usability issues. As has been discussed before, TLS is a 
shared context in a web browser - the same TLS connection will be reused for 
all requests, regardless of the origin they come from. The situation is better 
for cert-bound ATs because you need the CORS Access-Control-Allow-Credentials 
to be set to make a cross-origin request with a client certificate, but as I 
describe below there are also other attacks against TLS that don’t apply to 
DPoP (and would be a good reason to adopt DPoP). 

I think this section should also mention mobile use-cases, as IMO the case for 
DPoP is much stronger in those environments. Many of our customers are looking 
for a PoP solution for mobile and have rejected mTLS for various reasons (which 
have previously been discussed on this list, e.g. incompatible middleboxes). 
DPoP is potentially really nice for these environments as they often have a 
nice secure element available to store the private key and are much less 
susceptible to XSS and so on, but may still worry about a malicious RS. IoT 
applications may also be a use-case as requests are often relayed over multiple 
hops and different transport protocols, so TLS cannot be used for end-to-end 
security (although in that case you probably want a full request signing 
approach).

Section 2:
I think the “Main Objective” in section 2 could be improved. The vast majority 
of the mechanisms described in the draft do nothing to address this main 
objective, and are in fact intended to prevent DPoP proof replay which is 
relegated to a “secondary objective” in section 9. Only the “htu” claim really 
has anything at all to do with the main objective. I think some of these 
secondary objectives, especially the anti-replay one, should be brought forward 
to section 2 to better justify what follows.

It has been mentioned several times on this list that an audience restriction 
in the AT would also solve this main objective, and the response has generally 
been that adding audience restrictions is hard in practice - e.g. due to the AS 
not knowing where the AT is intended to be used. I think it would be useful to 
explicitly add some discussion of this, and perhaps a comparison with things 
like resource indicators that presumably could solve at least some of the 
issues with audience restrictions.

I think there *are* significant advantages of DPoP that address real-world 
attacks that cannot be solved in any other way currently. For example, I was 
reading [1] recently about CRIME/BREACH attacks against CSRF tokens and it 
occurred to me that exactly the same kind of attack is a real threat to access 
tokens in a browser and that DPoP is an effective mitigation against it. To 
summarise, these attacks exploit vulnerabilities in TLS when combined with 
compression (either in TLS itself or HTTP compression) and can allow an 
attacker to steal bearer tokens or cookies after observing enough requests with 
the same token (and being able to influence some other content in the same 
request/response). One recommended mitigation is to randomize tokens so that 
they are different on every request, which thwarts the attack. Although DPoP 
doesn’t directly randomize the AT the AT is useless without a DPoP proof and a 
unique “jti” claim ensures that the DPoP proof is randomized and so not 
recoverable through this attack. Given that BREACH is largely unmitigated in 
practice, due to the usefulness of compression, adding a description of this 
attack to the justification would IMO significantly improve the rationale for 
DPoP.

Section 3:
The second bullet point of step (B) isn’t clear - is it implying that refresh 
tokens for confidential clients shouldn’t be DPoP-bound? Must not?

Step (C) implies that only JWT-structured ATs or token introspection are 
supported for communicating the public key. Presumably deployers are free to 
use another secure mechanism if they wish?

The last bullet point about requiring a DPoP proof for refresh tokens is 
ambiguous about what happens in the case of confidential clients if the refresh 
token is not DPoP-bound. Do they not supply a DPoP proof at all (and it reuses 
the original one), or must they supply a new one? Can they supply a *different* 
DPoP proof to e.g. rotate their key pair?

Section 4:
Maybe a forward reference to section 6 when mentioning the DPoP header field, 
as that’s where it is defined.

4.1:
I’m not keen about including the full “jwk” in every DPoP proof. It never 
changes for the life of the AT and adds considerable overhead to the size of 
the proof. If the RS is using token 

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Denis]

Hello Benjamin,

First of all, you don't need to use an aggressive language to state your 
opinion.


Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the 
following title:"IETF Guidelines for Conduct". In particular:


   " Regardless of these individual differences, participants treat
   their colleagues with respect as persons especially
   when it is difficult to agree with them: treat other
   participants as you would like to be treated ".

I wrote:

(...)

    I will go one step further: if the client wants to inspect the 
token and

    if the format of the token is unknown to the client, then the client
will simply stop its further transmission. For some clients, preserving 
their

privacy may be more important than performing an access to a RS.

You responded :

   That may be true, but I agree with Vittorio that this document needs to
   strongly discourage clients from doing so, since they would 
be**_breaking _*

*_a __protocol invariant_ if they do.

If "this may be true", then you should consider that the token 
inspection by a client may be useful and thus should not be prevented.

However, there is no guarantee that it may always be performed.

You are using the wording" _breaking a protocol invariant_". In which 
RFC (related to OAuth) has such a "protocol invariance" been first 
mandated ?


I attempted to find an RFC using the wording "protocol invariant". I 
found RFC 8546 (Wire Image) issued in April 2019 dealing in section 4.1

with the topic " Declaring Protocol Invariants", using the following terms:

Declaring a protocol's invariants represents a promise made by the 
protocol's developers that certain bits in the wire image, and behaviors
   observable in the wire image, will be preserved through the 
specification of all future versions of the protocol.


Using these explanations, I have difficulties to understand how 
preventing the content of a JWT to be inspected by a client may be 
considered
as "a promise made by the protocol's developers that certain bits in the 
wire, and behaviors observable in the wire, will be preserved

through the specification of all future versions of the protocol".

I probably missed something. Would you be able to explain ?

A second point:

As a co-author of RFC 3161 published in August 2001 and of RFC 36268 
published in November 2003 to name a few of the RFCs
to which I contributed, I am not aware of any reference to an ISO 
document made into a RFC. This seems to be a common practice.
When I used the term "refer", I was not asking to place a reference to 
an ISO document in this working draft but to allow everybody in
the WG to have the ability to have a look at its content (and for free). 
Table 3 is simply a quick "reference" to ten privacy principles.


A third point:

RFC 6973 (Privacy Considerations for Internet Protocols) has been 
published in July 2013. Its introduction mentions:


The guidance provided here can and should be used to _assess the privacy 
considerations of protocol_, architectural,

    and operational _specifications_ (...)

   The guidance provided here is meant to help the thought process of 
privacy analysis; it does not provide specific directions

    for how to write a privacy considerations section.

Section 7 (Guidelines) mentions :

   This section provides guidance for document authors in the form of a 
questionnaire about a protocol being designed.
   The questionnaire may be useful at any point in the design process, 
particularly after document authors have developed

   a high-level protocol model as described in [RFC4101].
(...)
However, by carefully considering the answers to each question, document 
authors should be able to produce a comprehensive
   analysis that can serve as the basis for discussion of whether the 
protocol adequately protects against privacy threats.


An important item which is addressed both in ISO 29100 and RFC 6973 in 
section 7.1 is "Data Minimization". RFC 6973 mentions:


a.*Identifiers*.What identifiers does the protocol use for 
distinguishing initiators of communications?
Does the protocol use identifiers that allow different protocol 
interactions to be correlated?
What identifiers could be omitted or be made less identifying while 
still fulfilling the protocol’s goals?


b.*Data*.What information does the protocol expose about individuals, 
their devices, and/or their device usage (other than the identifiers 
discussed in (a))?
 To what extent is this information linked to the identities of the 
individuals?How does the protocol combine personal data with the 
identifiers discussed in (a)?


c.*Observers*.Which information discussed in (a) and (b) is exposed to 
each other protocol entity (i.e., recipients, intermediaries, and enablers)?
Are there ways for protocol implementers to choose to limit the 
information shared with each entity?  µ
Are there operational controls available to limit the information shared 
with each entity?

(...)

Re: [OAUTH-WG] JWT profile and IdentityServer

[Dominick Baier]

Oh - and last thing I forgot to mention.

We had the luxury of designing IdentityServer from the ground up after OIDC
has been released. So it really was fine tuned to be a OIDC + OAuth
implementation. Hence the strong semantics of the sub claim for both the
OIDC and OAuth parts. We think this is right because all of our customers
use both in conjunction.

IOW - you move our cheese ;) But don’t worry about it.

———
Dominick Baier

On 4. May 2020 at 10:55:41, Dominick Baier (dba...@leastprivilege.com)
wrote:

Hey,

No problem - this email was not intended to make you change the document.
Just my conclusions.

OK - let me just set the scene first

* IdentityServer is not a “off the shelf” product or SaaS - it is a
framework. IOW - developers have much greater flexibility and less
constraints to implement custom scenarios. This - as a consequence - allows
doing something “dangerous” - e.g.we cannot enforce how subs or client_id
are generated.

* Every token/identity handling logic in IdentityServer is based on a
simple rule: “if there is a sub - a user is involved, if not - then not”.
Call me old-school - but simplicity wins ;) And this formula has worked
very well for us and our customers. Changing this means we need to re-visit
every place where this logic is applied - so do our customers in both their
STS and resource server implementations. This change is of course doable -
but def. not at this moment in time especially since I am still struggling
if this is the right thing to do or not.

Lastly - I am not sure I understand this comment "not to be enough to
violate 7519”.

The sub claim is OPTIONAL.

https://tools.ietf.org/html/rfc7519#section-4.1.2

And so is aud btw.

So I do not really need to comment on the below scenarios in detail because
they are all a consequence of the above. I could make all these changes,
but they might require a substantial internal change of our logic. So we
decided to not do it. I can only imagine that other STS implementations
come to the same conclusion. And yes I know - you cannot please everybody ;)


Still some comment inline...


thanks
———
Dominick Baier

On 4. May 2020 at 10:20:16, Vittorio Bertocci (vittorio.berto...@auth0.com)
wrote:

Thank you Dominick, very useful!

I’d like to understand more about the security risks you mention. My goal
is not to change your mind on the implementatio, just to make sure I better
understand the general implication.

*>* the user info endpoint needs to do extra checking*

This is an interesting use case. Often the token issued for the userinfo is
formatless, given that it is colocated within the AS, but I can see how
using JWT for your own userinfo might be useful if you don’t particularly
care about token size or you don’t want to handle an internal token
format/reference.


Could you expand on the security risk? Either the sub doesn’t correspond to
a user, or if it does, the AS itself was the issuer hence it had full
control of whether a sub for a user would end up in a token obtained via
client creds grant… the main way I can see this going south would be if the
developer is allowed to place an arbitrary sub value, but in that case the
issue seem larger (eg in a grant including a user, placing the sub of
another user).


We use the JWT. Sub = user ID. OIDC scopes = what data is returned. This
needs slightly updated logic



*>* extension grants that did not use to present users*

Technically we are still not presenting users- the sub is the authenticated
subject, which can be a user or an app. Here I am channeling the consensus
that was reached after quite a few back and forths, see
https://mailarchive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.

That’s fine - not trying to change your mind



But besides the nitpicking. Could you expand on the extension grants you
are thinking of, and how they’d be affected?

Again our internal extension grant logic is based on the existence of the
sub claim after the response data has been generated. If sub is present we
invoke a whole pipeline around user centric claims. Needs to be changed.



*>* token exchange scenarios*

This is another really interesting point. I admit I haven’t studied the RFC
and I might be remembering an older version, but I believe the specs
referred to principals, which aren’t necessarily human; and I remember one
dev from the community describing a scenario where he would have liked to
be able to do OBO with machine identities, and his scenario was reasonable.

Is there anything specific that breaks in your implementation of token
exchange if you have a sub not corresponding to a user?

See above.





>* enforce a collision domain for sub and client_id

If your product allows developers to arbitrarily set values for one or both
of those, I totally see how enforcement would be extra work! I would argue
that in that case perhaps you don’t have to, if the user can set arbitrary
values they can already do things that would break standards (like
assigning 

Re: [OAUTH-WG] JWT profile and IdentityServer

[Dominick Baier]

Hey,

No problem - this email was not intended to make you change the document.
Just my conclusions.

OK - let me just set the scene first

* IdentityServer is not a “off the shelf” product or SaaS - it is a
framework. IOW - developers have much greater flexibility and less
constraints to implement custom scenarios. This - as a consequence - allows
doing something “dangerous” - e.g.we cannot enforce how subs or client_id
are generated.

* Every token/identity handling logic in IdentityServer is based on a
simple rule: “if there is a sub - a user is involved, if not - then not”.
Call me old-school - but simplicity wins ;) And this formula has worked
very well for us and our customers. Changing this means we need to re-visit
every place where this logic is applied - so do our customers in both their
STS and resource server implementations. This change is of course doable -
but def. not at this moment in time especially since I am still struggling
if this is the right thing to do or not.

Lastly - I am not sure I understand this comment "not to be enough to
violate 7519”.

The sub claim is OPTIONAL.

https://tools.ietf.org/html/rfc7519#section-4.1.2

And so is aud btw.

So I do not really need to comment on the below scenarios in detail because
they are all a consequence of the above. I could make all these changes,
but they might require a substantial internal change of our logic. So we
decided to not do it. I can only imagine that other STS implementations
come to the same conclusion. And yes I know - you cannot please everybody ;)


Still some comment inline...


thanks
———
Dominick Baier

On 4. May 2020 at 10:20:16, Vittorio Bertocci (vittorio.berto...@auth0.com)
wrote:

Thank you Dominick, very useful!

I’d like to understand more about the security risks you mention. My goal
is not to change your mind on the implementatio, just to make sure I better
understand the general implication.

*>* the user info endpoint needs to do extra checking*

This is an interesting use case. Often the token issued for the userinfo is
formatless, given that it is colocated within the AS, but I can see how
using JWT for your own userinfo might be useful if you don’t particularly
care about token size or you don’t want to handle an internal token
format/reference.


Could you expand on the security risk? Either the sub doesn’t correspond to
a user, or if it does, the AS itself was the issuer hence it had full
control of whether a sub for a user would end up in a token obtained via
client creds grant… the main way I can see this going south would be if the
developer is allowed to place an arbitrary sub value, but in that case the
issue seem larger (eg in a grant including a user, placing the sub of
another user).


We use the JWT. Sub = user ID. OIDC scopes = what data is returned. This
needs slightly updated logic



*>* extension grants that did not use to present users*

Technically we are still not presenting users- the sub is the authenticated
subject, which can be a user or an app. Here I am channeling the consensus
that was reached after quite a few back and forths, see
https://mailarchive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.

That’s fine - not trying to change your mind



But besides the nitpicking. Could you expand on the extension grants you
are thinking of, and how they’d be affected?

Again our internal extension grant logic is based on the existence of the
sub claim after the response data has been generated. If sub is present we
invoke a whole pipeline around user centric claims. Needs to be changed.



*>* token exchange scenarios*

This is another really interesting point. I admit I haven’t studied the RFC
and I might be remembering an older version, but I believe the specs
referred to principals, which aren’t necessarily human; and I remember one
dev from the community describing a scenario where he would have liked to
be able to do OBO with machine identities, and his scenario was reasonable.

Is there anything specific that breaks in your implementation of token
exchange if you have a sub not corresponding to a user?

See above.





>* enforce a collision domain for sub and client_id

If your product allows developers to arbitrarily set values for one or both
of those, I totally see how enforcement would be extra work! I would argue
that in that case perhaps you don’t have to, if the user can set arbitrary
values they can already do things that would break standards (like
assigning the same sub to two different users) hence in that case you can’t
be responsible for it at product design, it’s kind of up to them.



Note, I know that answering the above might require extra work in
investigating and writing about it, I don’t mean to burden you with it. My
aim here is understanding whether the challenges you identified mostly stem
from the underlying assumption “presence of a sub=>it’s a user”, which is
understandable but was established in the discussions referenced above not
to be enough 

Re: [OAUTH-WG] JWT profile and IdentityServer

[Vittorio Bertocci]

Thank you Dominick, very useful!
I’d like to understand more about the security risks you mention. My goal is 
not to change your mind on the implementatio, just to make sure I better 
understand the general implication.
>* the user info endpoint needs to do extra checking
This is an interesting use case. Often the token issued for the userinfo is 
formatless, given that it is colocated within the AS, but I can see how using 
JWT for your own userinfo might be useful if you don’t particularly care about 
token size or you don’t want to handle an internal token format/reference.
Could you expand on the security risk? Either the sub doesn’t correspond to a 
user, or if it does, the AS itself was the issuer hence it had full control of 
whether a sub for a user would end up in a token obtained via client creds 
grant… the main way I can see this going south would be if the developer is 
allowed to place an arbitrary sub value, but in that case the issue seem larger 
(eg in a grant including a user, placing the sub of another user).

>* extension grants that did not use to present users
Technically we are still not presenting users- the sub is the authenticated 
subject, which can be a user or an app. Here I am channeling the consensus that 
was reached after quite a few back and forths, see 
https://mailarchive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.
But besides the nitpicking. Could you expand on the extension grants you are 
thinking of, and how they’d be affected?
>* token exchange scenarios
This is another really interesting point. I admit I haven’t studied the RFC and 
I might be remembering an older version, but I believe the specs referred to 
principals, which aren’t necessarily human; and I remember one dev from the 
community describing a scenario where he would have liked to be able to do OBO 
with machine identities, and his scenario was reasonable.
Is there anything specific that breaks in your implementation of token exchange 
if you have a sub not corresponding to a user?

>* enforce a collision domain for sub and client_id
If your product allows developers to arbitrarily set values for one or both of 
those, I totally see how enforcement would be extra work! I would argue that in 
that case perhaps you don’t have to, if the user can set arbitrary values they 
can already do things that would break standards (like assigning the same sub 
to two different users) hence in that case you can’t be responsible for it at 
product design, it’s kind of up to them.

Note, I know that answering the above might require extra work in investigating 
and writing about it, I don’t mean to burden you with it. My aim here is 
understanding whether the challenges you identified mostly stem from the 
underlying assumption “presence of a sub=>it’s a user”, which is understandable 
but was established in the discussions referenced above not to be enough to 
violate 7519, or if there are other factors at play that introduce challenges 
when sub is used that way.
Thanks again for putting time in checking this and considering implementing it!
Cheers,
V.

From: Dominick Baier 
Date: Monday, May 4, 2020 at 00:36
To: "oauth@ietf.org" , "vittorio.berto...@auth0.com" 

Subject: JWT profile and IdentityServer

Hey,

Just some notes on applying the JWT profile to IdentityServer

* we emit the at+jwt typ - that’s very useful
* we emit iat in addition to nbf (if we would remove nbf, we would break the 
.NET JWT library from Microsoft - I guess that’s the reason AAD emits it as 
well)
* we have an option to emit scope as a space delimited string (we used a string 
array for historic reasons - also because that’s how the claims plumbing in 
.NET prefers it)

* aud

Audience is optional in IdentityServer if you request scopes that do not have 
an association to a resource. I personally think this is the right way to go. 
You can “force” an audience even for this situation if you absolutely want to

* sub vs client_id

In IdentityServer access tokens that do not have a user present, do not have a 
sub claim - only client_id. If there is a user present, sub ALWAYS represents 
the user.

I was prototyping a setting to emit the sub claim for situation where there is 
no user, which would not be hard to do - but we found out that there are many 
situations where this would need VERY THOROUGH testing of all the various flows 
to not introduce subtle security bugs

* the user info endpoint needs to do extra checking
* extension grants that did not use to present users
* token exchange scenarios
* enforce a collision domain for sub and client_id

This could all be sorted probably if I would have enough time right now - but 
the bottom line is, that this ambiguity and special casing requires careful 
re-writing and I guess this applies to any reasonably complex system that is 
already out there. So I am still not sold that the “dual purpose” claims are 
the best choice. YMMV.

IOW - we will not adopt the sub/client_id 

[OAUTH-WG] JWT profile and IdentityServer

[Dominick Baier]

Hey,

Just some notes on applying the JWT profile to IdentityServer

* we emit the at+jwt typ - that’s very useful
* we emit iat in addition to nbf (if we would remove nbf, we would break
the .NET JWT library from Microsoft - I guess that’s the reason AAD emits
it as well)
* we have an option to emit scope as a space delimited string (we used a
string array for historic reasons - also because that’s how the claims
plumbing in .NET prefers it)

* aud

Audience is optional in IdentityServer if you request scopes that do not
have an association to a resource. I personally think this is the right way
to go. You can “force” an audience even for this situation if you
absolutely want to

* sub vs client_id

In IdentityServer access tokens that do not have a user present, do not
have a sub claim - only client_id. If there is a user present, sub ALWAYS
represents the user.

I was prototyping a setting to emit the sub claim for situation where there
is no user, which would not be hard to do - but we found out that there are
many situations where this would need VERY THOROUGH testing of all the
various flows to not introduce subtle security bugs

* the user info endpoint needs to do extra checking
* extension grants that did not use to present users
* token exchange scenarios
* enforce a collision domain for sub and client_id

This could all be sorted probably if I would have enough time right now -
but the bottom line is, that this ambiguity and special casing requires
careful re-writing and I guess this applies to any reasonably complex
system that is already out there. So I am still not sold that the “dual
purpose” claims are the best choice. YMMV.

IOW - we will not adopt the sub/client_id semantics as proposed by the
document.


My 2c / cheers
———
Dominick Baier
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Benjamin Kaduk]

Hi Denis,

You seem to be continuing to be operating under incorrect assuptions about
how OAuth 2.0 works, and have proceeded to make long chains of reasoning
that, unfortunately, are not based on a solid foundation.  In order to
reduce the amount of frustration amongst all participants, in the future I
strongly suggest that you make sure you have the fundamentals correct
before going into long chains of reasoning.

Furthermore, while you have indeed identified some areas where the current
OAuth ecosystem could be improved, I reiterate that the current document,
defining a token format that is optional to use, is not the place to make
changes to how OAuth works.  I think you do everyone a disservice for
attempting to suggest that this document should do so.

Because there is so much based on a flawed foundation, I will not respond
inline to every point, but do see a few things where further clarification
would be useful.

On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:
> Hello Vittorio,
> 
> Your reply was amazingly fast. Responses are between the lines.
> 
> > Thanks Denis for the thorough commentary.
> >
> > /> The title of this spec./
> >
> > Fixed, thanks!
> >
> 
> > /> The client MUST NOT inspect the content of the access token/
> >
> >
> > This is really a sticky point. I really want to acknowledge your PoV 
> > on this, but at the same time I found this to be one of the biggest 
> > sources of issues
> > in the use of JWT for access tokens hence I feel we really need to 
> > give solid guidance here. Let me expand further on the reasoning 
> > behind it,
> > and perhaps we can get to language that satisfies both PoVs.
> >
> >
> > To me the key point is that clients should not write /code/ that 
> > inspects access tokens. Taking a dependency on the ability to do so is 
> > ignoring fundamental information
> > about the architecture and relationships between OAuth roles, and 
> > suggests an ability of the client to understand the semantic of the 
> > content that cannot be assumed
> > in the general case. I expanded on the details in my former reply to 
> > you on this topic, I would recommend referring to it.
> >
> > Clients violating this simple principle has been one of the most 
> > common sources of production issues I had to deal with in the past few 
> > years, and one of the hardest
> > to remediate given that clients are hard to update and sometimes the 
> > things they relied on were irremediably lost. This is why I am 
> > inclined to put in here strong language.
> >
> > That said: I have nothing against client developers examining a 
> > network trace and drawing conclusions based on the content of what 
> > they see. That doesn’t create any hard
> > dependencies and has no implications in respect to changes in the 
> > solution behavior. However I am not sure how to phrase that in the 
> > specification, given that referring
> > to the client inevitably refers to its code. I am open to suggestions.
> >
> First of all, a "*MUST NOT* "should not be placed in a privacy 
> considerations section, but in the main body of the document.
> The goal of a privacy considerations section is to provide explanations, 
> but not to introduce additional requirements.

That's not actually a requirement.  In many cases it makes sense to avoid
putting normative requirements in the security and/or privacy
considerations sections, but it is very much a thing that is done in many
RFCs, and in some cases it is useful to do so.

> Then after, since this section is about privacy considerations, it is 
> important to refer to an ISO standard that has been published 9 years ago.

Is it?  I don't see much precedent for IETF documents referencing this ISO
standard.  If it's so important you'd think that we'd have been citing it
with regularity.  Since this will be the first or second time, I think you
need to provide some additional justification as to how the topics it
covers fit within the existing IETF BCPs for how we treat security and
privacy considerations before we conclude that it is the appropriate
reference.

> It is ISO 29100 (Information technology — Security techniques — Privacy 
> framework). Most of the ISO standards need to be bought.
> However, there are a few exceptions and this standard can be freely 
> downloaded from the ISO web site, if you accept some conditions,
> using this URL:
> 
> https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
> 
> ISO 29100, even if it is outdated on some aspects (it only deals with 
> two entities), identifies ten principles (See Table 3).
> 
> 1. Consent and choice
> 
> 2. Purpose legitimacy and specification
> 
> 3. Collection limitation
> 
> 4. Data minimization
> 
> 5. Use, retention and disclosure limitation
> 
> 6. Accuracy and quality
> 
> 7. Openness, transparency and notice
> 
> 8. Individual participation and access
> 
> 9. Accountability
> 
> 10. Information security
> 
> 11.