Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP

[Justin Richer <[e-mail]>]

I'd like to point out once again that this would all be solved by 
keeping all the semantics of the event, like the issuer and subject of 
logout, inside the event{} object itself.

*shrug*

  -- Justin


On 7/27/2017 5:19 PM, Phil Hunt 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.
>
> 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>
> [e-mail] <mailto:[e-mail]>
>
>> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> 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?
>>
>> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
>> <[e-mail] <mailto:[e-mail]>> 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&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e= 
>>>
>>>
>>> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum 
>>> <[e-mail] <mailto:[e-mail]>>
>>> wrote:
>>>>
>>>> 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
>>>> <[e-mail] <mailto:[e-mail]>> 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
>>>>>     }
>>>>>
>>>>> 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.
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> 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= 
>>>>>
>>>>>
>>>
>>>
>>>
>>> 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
>> [e-mail] <mailto:[e-mail]>
>> 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= 
>>
>
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose