Subject: [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP

From: Brian Campbell <[email-masked]>
Date: Thu, 27 Jul 2017 12:49:57 -0600

During the first WG meeting last week
<https://datatracker.ietf.org/doc/minutes-99-oauth/> I asked if use of the
JOSE "crit" (Critical) Header Parameter had been considered as a
recommendation for preventing confusion of one kind of JWT for another.
Time was running short in the meeting so there wasn't much discussion and
it was requested that I take the question to the list. And so here on the
list is that.

Section 3.9
<https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-3.9> of
the JWT BCP draft now recommends explicit typing using the "typ" JWS/JWE
header parameter but does concede that 'the use of explicit typing may not
achieve disambiguation from existing kinds of JWTs, as the validation rules
for existing kinds JWTs often do not use the "typ" header parameter
value.'  And the recommendations for how to use the Type Header Parameter
in JWT <https://tools.ietf.org/html/rfc7519#section-5.1> strongly suggest
that it's not currently being used for any validation.

Alternatively using the JWS/JWE "crit" (Critical) Header Parameter
<https://tools.ietf.org/html/rfc7515#section-4.1.11> to signal the
type/intent/profile/application of a JWT could achieve disambiguation even
in validation of existing kinds of JWTs. The critical header lists other
headers which must be understood and processed by the receiver and that the
JWS/JWE is invalid if those listed aren't understood. So a new type/profile
of JWT that uses the "crit" header would produce JWTs that would be
rejected even by existing applications of JWT validation (that actually
implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction with a
profile/application/type specific header. Or it could provide a bit more of
a framework like defining a registering a new JOSE header "p" (strawman of
p as a very short name for profile) and create a registry for its values. A
JWT header using that approach might look like the following where the
value 1 is registered as some cool new JWT profile/application. The
consumer of such a JWT would have to understand and process the "p" header,
which would mean checking that it had the value expected.

     {
      "alg":"ES256",
      "crit":["p"],
      "p":1
     }

A JOSE compliant JWT validator would reject such a JWT even for an OAuth
access token or OIDC id_token because the "p" header isn't known or
understood but is marked as critical.

To me, that seems like an approach to preventing confusion that has more
teeth than the "typ" header. Which is why I asked about it last week and am
now bringing it to the list.

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

---

From: Nathaniel McCallum <[email-masked]>
Date: Thu, 27 Jul 2017 15:30:56 -0400

What class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just be
ignorant.

On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
<[email-masked]> wrote:
> During the first WG meeting last week I asked if use of the JOSE "crit"
> (Critical) Header Parameter had been considered as a recommendation for
> preventing confusion of one kind of JWT for another. Time was running short
> in the meeting so there wasn't much discussion and it was requested that I
> take the question to the list. And so here on the list is that.
>
> Section 3.9 of the JWT BCP draft now recommends explicit typing using the
> "typ" JWS/JWE header parameter but does concede that 'the use of explicit
> typing may not achieve disambiguation from existing kinds of JWTs, as the
> validation rules for existing kinds JWTs often do not use the "typ" header
> parameter value.'  And the recommendations for how to use the Type Header
> Parameter in JWT strongly suggest that it's not currently being used for any
> validation.
>
> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to signal
> the type/intent/profile/application of a JWT could achieve disambiguation
> even in validation of existing kinds of JWTs. The critical header lists
> other headers which must be understood and processed by the receiver and
> that the JWS/JWE is invalid if those listed aren't understood. So a new
> type/profile of JWT that uses the "crit" header would produce JWTs that
> would be rejected even by existing applications of JWT validation (that
> actually implement "crit" properly anyway).
>
> a framework like defining a registering a new JOSE header "p" (strawman of p
> as a very short name for profile) and create a registry for its values. A
> JWT header using that approach might look like the following where the value
> 1 is registered as some cool new JWT profile/application. The consumer of
> such a JWT would have to understand and process the "p" header, which would
> mean checking that it had the value expected.
>
>      {
>       "alg":"ES256",
>       "crit":["p"],
>       "p":1
>      }
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> computer. Thank you.
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 27 Jul 2017 13:34:16 -0600

The draft describes it in
https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-2.7

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <[email-masked]>
wrote:

> value

---

From: Nathaniel McCallum <[email-masked]>
Date: Thu, 27 Jul 2017 17:00:05 -0400

Even after reading the whole section, I still don't understand the
problem. Yes, a class of attack could exist where an attacker
substitutes a valid JWT from one security context into another
context. But isn't this resolved by audience validation?

---

From: Dick Hardt <[email-masked]>
Date: Thu, 27 Jul 2017 22:17:27 +0100

Only if the audience is different.

On Thu, Jul 27, 2017 at 10:00 PM, Nathaniel McCallum <[email-masked]>
wrote:

> >> > in the meeting so there wasn't much discussion and it was requested
> that
> >> > I
> >> > Parameter in JWT strongly suggest that it's not currently being used
> for
> >> > any
> >> > validation.
> >> >
> >> > profile/application/type specific header. Or it could provide a bit
> more
> >> > of
> >> > a framework like defining a registering a new JOSE header "p"
> (strawman
> >> > of p
> >> > as a very short name for profile) and create a registry for its
> values.
> >> > A
> >> > teeth than the "typ" header. Which is why I asked about it last week
> and
> >> > am
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!

---

From: Phil Hunt <[email-masked]>
Date: Thu, 27 Jul 2017 14:19:48 -0700

We have the use case in SECEVENTS where a logout event (e.g. OIDF backchannel logout) is extremely close to an ID_TOKEN. 

Older relying parties who are do not yet support logout could be tricked into accepting a logout assertion as an ID_TOKEN since they are too similar, and  because a valid ID_TOKEN parser is in theory allowed to ignore claims it does not understand (e.g. “events”) - leading to a possible erroneous acceptance of the logout event AS and ID_TOKEN.

Because of this the issue of distinguishing classes or types of JWTs emerged.

We discussed a number of differentiators like “aud”, “typ”, “crit", etc that would help.  But that really lead to the idea there there should be some best practices in the JWT BCP covering the issue(s).

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <[email-masked]> wrote:
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e= 
>> 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e= 
>>>> 
>> 
>> 
>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=

---

From: Dick Hardt <[email-masked]>
Date: Thu, 27 Jul 2017 22:29:09 +0100

Brian: I did not think that 'crit' processing is required in JWT
https://tools.ietf.org/html/rfc7519

We have two goals:

Preventing new JWT profiles from being confused with older JWTs, which
'typ' solves (as does your proposal of 'crit' and 'p', but requires more
bytes)

Preventing existing JWT implementations from being confused with new JWT
profiles. 'crit' can solve that for JOSE JWTs, but not other JWTs.

On Thu, Jul 27, 2017 at 7:49 PM, Brian Campbell <[email-masked]>
wrote:

> <https://datatracker.ietf.org/doc/minutes-99-oauth/> I asked if use of
> the JOSE "crit" (Critical) Header Parameter had been considered as a
> <https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-3.9>
> of the JWT BCP draft now recommends explicit typing using the "typ" JWS/JWE
> type/intent/profile/application of a JWT could achieve disambiguation
> *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.*

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Jul 2017 17:40:02 -0400

Not that I am against the general desire for JWT not to be confused, but the attack surface for someone to take a sec event from one context and replay it as a id_token to login is very small and if the client is correctly configured would not work as it is now.

The only way you could replay the sec event JWT is via the implicit flow.   The other flows would require a malicious AS and at that point you have bigger problems with a compromised token endpoint.

If you were to create a implicit response with the sec event token that has the correct issuer and aud, connect requires that nonce value from the request be present in the id_token.   This would require that the attacker somehow get the AS to put not only the claim but the correct value from the request into the token.

All in all I think that it is more likely (not 100% I admit) that a client will do that rather than checking the typ or a new crit JWT header parameter.

I am all for a general solution for this but I think the issue with Connect is overstated sometimes.

John B.
 
> On Jul 27, 2017, at 5:19 PM, Phil Hunt <[email-masked]> wrote:
> 
>> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=> 
>>> 
>>> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <[email-masked] <mailto:[email-masked]>>
>>> wrote:
>>>> 
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Nathaniel McCallum <[email-masked]>
Date: Thu, 27 Jul 2017 17:40:33 -0400

Right. And this is precisely what I find strange. We are attempting to
define the differentiation between state transitions without defining
the state transitions themselves.

I want to be clear that I think there is a real need here. But it
seems to me that this need is not well defined. So I'm not against it
in theory. I'm just against ambiguous standards.

On Thu, Jul 27, 2017 at 5:19 PM, Phil Hunt <[email-masked]> wrote:
> We have the use case in SECEVENTS where a logout event (e.g. OIDF
> backchannel logout) is extremely close to an ID_TOKEN.
>
> Older relying parties who are do not yet support logout could be tricked
> into accepting a logout assertion as an ID_TOKEN since they are too similar,
> and  because a valid ID_TOKEN parser is in theory allowed to ignore claims
> it does not understand (e.g. “events”) - leading to a possible erroneous
> acceptance of the logout event AS and ID_TOKEN.
>
> We discussed a number of differentiators like “aud”, “typ”, “crit", etc that
> would help.  But that really lead to the idea there there should be some
> best practices in the JWT BCP covering the issue(s).
>
> Phil
>
> www.independentid.com
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Thu, 27 Jul 2017 15:59:25 -0600

What other JWTs are there?

All JWTs use JWS and/or JWE. So a JWT is a JOSE JWT by definition. JWT
requires 'crit' processing by virtue of using JWS and JWE for signing and
encryption. The extent to which that processing is actually implemented is
a different and fair question but it's normative requirement per spec and
implementations that don't would be non-compliant.

The byte usage actually is pretty similar depending on the the values used
(admittedly because I chose very compact names/values).  Compare to
secevent, for example,

   "crit":["p"],"p":1
   "typ":"secevent+jwt"

On Thu, Jul 27, 2017 at 3:29 PM, Dick Hardt <[email-masked]> wrote:

> On Thu, Jul 27, 2017 at 7:49 PM, Brian Campbell <
> [email-masked]> wrote:
>
>> value.'  And the recommendations for how to use the Type Header
>> Parameter in JWT <https://tools.ietf.org/html/rfc7519#section-5.1>
>> strongly suggest that it's not currently being used for any validation.
>>
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn
> about projects I am working on!
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 27 Jul 2017 16:10:03 -0600

I wouldn't disagree that the issue with Connect is overstated sometimes.
And it's a non-issue with sec event due to the "nonce" claim (as you point
out) as well as the omission of the "exp" claim. Assuming correct
validation anyway.

The BCP draft suggests explicit typing to prevent Cross-JWT Confusion more
generally (not just sec events and id tokens). I was wondering if some use
of "crit" might accomplish the same thing but also cover the case of
existing JWT implementations being confused with new JWT profiles.

On Thu, Jul 27, 2017 at 3:40 PM, John Bradley <[email-masked]> wrote:

> Not that I am against the general desire for JWT not to be confused, but
> the attack surface for someone to take a sec event from one context and
> replay it as a id_token to login is very small and if the client is
> correctly configured would not work as it is now.
>
> The only way you could replay the sec event JWT is via the implicit flow.
>   The other flows would require a malicious AS and at that point you have
> bigger problems with a compromised token endpoint.
>
> If you were to create a implicit response with the sec event token that
> has the correct issuer and aud, connect requires that nonce value from the
> request be present in the id_token.   This would require that the attacker
> somehow get the AS to put not only the claim but the correct value from the
> request into the token.
>
> All in all I think that it is more likely (not 100% I admit) that a client
> will do that rather than checking the typ or a new crit JWT header
> parameter.
>
> into accepting a logout assertion as an ID_TOKEN since they are too
> similar, and  because a valid ID_TOKEN parser is in theory allowed to
> ignore claims it does not understand (e.g. “events”) - leading to a
> possible erroneous acceptance of the logout event AS and ID_TOKEN.
>
> We discussed a number of differentiators like “aud”, “typ”, “crit", etc
> that would help.  But that really lead to the idea there there should be
> some best practices in the JWT BCP covering the issue(s).
>
> Phil
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.
> ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-
> 23section-2D2.7&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
> 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=
> 9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=
>
> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <[email-masked]
> >
> wrote:
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y
> TpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
> 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-
> RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=
>
>
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y
> TpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
> 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-
> RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=
>
>

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Jul 2017 18:23:55 -0400

My only concern with a crit header is that it is potentially another layering violation.

It really should be the application and not JWS/JWE that determines if the content of the JWT is correct at a application layer.

To get your idea to work the application would need to push down to the JWT layer some value/s of p that it was willing to accept.   Without crit the application could just pass along typ or p to the application layer for matching.

I don’t hate the idea but it seems like it is likely to work against having generic JOSE libs separate from JWT. Perhaps that is the reality anyway.

How would you implement it?

John B.

> On Jul 27, 2017, at 6:10 PM, Brian Campbell <[email-masked]> wrote:
> 
> I wouldn't disagree that the issue with Connect is overstated sometimes. And it's a non-issue with sec event due to the "nonce" claim (as you point out) as well as the omission of the "exp" claim. Assuming correct validation anyway. 
> 
> The BCP draft suggests explicit typing to prevent Cross-JWT Confusion more generally (not just sec events and id tokens). I was wondering if some use of "crit" might accomplish the same thing but also cover the case of existing JWT implementations being confused with new JWT profiles. 
> 
> On Thu, Jul 27, 2017 at 3:40 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 27, 2017, at 5:19 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <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.

---

From: Jim Schaad <[email-masked]>
Date: Thu, 27 Jul 2017 15:56:31 -0700

One simple way to implement it would be to have an call which says “I will deal with the following items if they exist”.  This means that all the application needs to do is to say that it will process p and not what values are acceptable.

Jim

From: jose [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, July 27, 2017 3:24 PM
To: Brian Campbell <[email-masked]>
Cc: Nathaniel McCallum <[email-masked]>; oauth <[email-masked]>; [email-masked]; Phil Hunt <[email-masked]>
Subject: Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP

John B.

On Jul 27, 2017, at 6:10 PM, Brian Campbell <[email-masked] <mailto:[email-masked]> > wrote:

On Thu, Jul 27, 2017 at 3:40 PM, John Bradley <[email-masked] <mailto:[email-masked]> > wrote:

John B.

On Jul 27, 2017, at 5:19 PM, Phil Hunt <[email-masked] <mailto:[email-masked]> > wrote:

Phil

@independentid

www.independentid.com <http://www.independentid.com/> 

[email-masked] <mailto:[email-masked]> 

On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <[email-masked] <mailto:[email-masked]> > wrote:

On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
<[email-masked] <mailto:[email-masked]> > wrote:

The draft describes it in
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=> &d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e= 

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <[email-masked] <mailto:[email-masked]> >
wrote:

On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
<[email-masked] <mailto:[email-masked]> > wrote:

During the first WG meeting last week I asked if use of the JOSE "crit"
(Critical) Header Parameter had been considered as a recommendation for
preventing confusion of one kind of JWT for another. Time was running
short
in the meeting so there wasn't much discussion and it was requested that
I
take the question to the list. And so here on the list is that.

Section 3.9 of the JWT BCP draft now recommends explicit typing using
the
"typ" JWS/JWE header parameter but does concede that 'the use of
explicit
typing may not achieve disambiguation from existing kinds of JWTs, as
the
validation rules for existing kinds JWTs often do not use the "typ"
header
parameter value.'  And the recommendations for how to use the Type
Header
Parameter in JWT strongly suggest that it's not currently being used for
any
validation.

Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
signal
the type/intent/profile/application of a JWT could achieve
disambiguation
even in validation of existing kinds of JWTs. The critical header lists
other headers which must be understood and processed by the receiver and
that the JWS/JWE is invalid if those listed aren't understood. So a new
type/profile of JWT that uses the "crit" header would produce JWTs that
would be rejected even by existing applications of JWT validation (that
actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction with a
profile/application/type specific header. Or it could provide a bit more
of
a framework like defining a registering a new JOSE header "p" (strawman
of p
as a very short name for profile) and create a registry for its values.
A
JWT header using that approach might look like the following where the
value
1 is registered as some cool new JWT profile/application. The consumer
of
such a JWT would have to understand and process the "p" header, which
would
mean checking that it had the value expected.

    {
     "alg":"ES256",
     "crit":["p"],
     "p":1
    }

To me, that seems like an approach to preventing confusion that has more
teeth than the "typ" header. Which is why I asked about it last week and
am
now bringing it to the list.

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.
_______________________________________________
jose mailing list
[email-masked] <mailto:[email-masked]> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=> &d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e= 

_______________________________________________
jose mailing list
[email-masked] <mailto:[email-masked]> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=> &d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=eJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=

---

From: Brian Campbell <[email-masked]>
Date: Fri, 28 Jul 2017 06:22:42 -0600

Yeah, I've implemented it in pretty much in the way Jim describes.

In my implementation of JWT validation the application sets things up by
pushing down all the info needed for validation (things like expected
audience & issuer, keys, allowed algorithms, etc.). So I'm probably biased
by that but also telling it that 'p' is okay as a critical header doesn't
feel like any more of a layering violation than anything else.

This example
<https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples#markdown-header-producing-and-consuming-a-signed-jwt>
shows how to use the library for regular JWT validation. This method
<http://static.javadoc.io/org.bitbucket.b_c/jose4j/0.5.6/org/jose4j/jwt/consumer/JwtConsumerBuilder.html#setJwsCustomizer%28org.jose4j.jwt.consumer.JwsCustomizer%29>
would be used to tell the JWT validator/consumer that the 'p' as a critical
header should be accepted. And then the JWT validator/consumer could be
told what value of 'p' is acceptable or required by adding a validator for
it
<http://static.javadoc.io/org.bitbucket.b_c/jose4j/0.5.6/org/jose4j/jwt/consumer/JwtConsumerBuilder.html#registerValidator(org.jose4j.jwt.consumer.Validator)>
or the application code could just look at the headers after and check it
that way. That's how it could be done now with the existing general API. If
the BCP was to formalize something, I'd probably enhance the API with
something specific for it to make it even easier.

On Thu, Jul 27, 2017 at 4:56 PM, Jim Schaad <[email-masked]> wrote:

> One simple way to implement it would be to have an call which says “I will
> deal with the following items if they exist”.  This means that all the
> application needs to do is to say that it will process p and not what
> values are acceptable.
>
>
>
> Jim
>
>
>
>
>
> *From:* jose [mailto:[email-masked]] *On Behalf Of *John Bradley
> *Sent:* Thursday, July 27, 2017 3:24 PM
> *To:* Brian Campbell <[email-masked]>
> *Cc:* Nathaniel McCallum <[email-masked]>; oauth <[email-masked]>;
> [email-masked]; Phil Hunt <[email-masked]>
> *Subject:* Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT
> for another in JWT BCP
>
>
>
> It really should be the application and not JWS/JWE that determines if the
> content of the JWT is correct at a application layer.
>
>
>
> To get your idea to work the application would need to push down to the
> JWT layer some value/s of p that it was willing to accept.   Without crit
> the application could just pass along typ or p to the application layer for
> matching.
>
>
>
> I don’t hate the idea but it seems like it is likely to work against
> having generic JOSE libs separate from JWT. Perhaps that is the reality
> anyway.
>
>
>