Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: Clarifying use of sub and iss in SET tokens)

[Marius Scurtescu <[e-mail]>]

I did not realize that typ is a header. Shouldn't ideally the SET purpose
or "type" be a claim rather?

I doubt that any existing libraries take crit into account. Can anyone
point to a library that does look at crit? With that in mind, crit does not
help much IMO, we might just as well define a type claim.

Marius

On Thu, Mar 2, 2017 at 8:05 AM, Phil Hunt <[e-mail]> wrote:

> PS.  This is another of Yaron’s threads….”Avoiding SETS being confused as
> access tokens”
>
>
> Phil
>
> Oracle Corporation, Identity Cloud Services & Identity Standards
> @independentid
> www.independentid.com
> [e-mail]
>
>
>
>
>
>
>
> On Mar 2, 2017, at 8:03 AM, Phil Hunt <[e-mail]> wrote:
>
> Interesting!  +1
>
> Phil
>
> Oracle Corporation, Identity Cloud Services & Identity Standards
> @independentid
> www.independentid.com
> [e-mail]
>
>
>
>
>
>
>
> On Mar 2, 2017, at 7:53 AM, Brian Campbell <[e-mail]>
> wrote:
>
> Not that it makes a difference helping the situation here but "typ" is a
> JOSE header rather than a JWT claim (see https://tools.ietf.org/html/rf
> c7515#section-4.1.9 and https://tools.ietf.org/html/rfc7516#section-4.1.11
> and https://tools.ietf.org/html/rfc7519#section-5.1).
>
> That got me thinking, however, that maybe the "crit" JOSE header (
> https://tools.ietf.org/html/rfc7515#section-4.1.11) might be useful here.
> Assuming JWT/JOSE implementations support "crit" per spec (they *should*
> but that might be an optimistic assumption) then it could be used to
> address the 'clients already written that don't check for it' problem.
> Something like a new "set" header that gets marked as critical. I.e. as
> just a strawman,
>
>      {
>       "alg":"ES256",
>       "crit":["set"],
>       "set":true
>      }
>
> says that the receiver must understand and process the "set" header, which
> existing OIDC and OAuth JWT consumers wouldn't.
>
> Honestly not sure if that's a good idea or not. But wanted to throw it out
> there.
>
>
>
>
>
> On Wed, Mar 1, 2017 at 7:05 PM, William Denniss <[e-mail]>
> wrote:
>
>>
>>
>> On Wed, Mar 1, 2017 at 5:52 PM, Marius Scurtescu <[e-mail]>
>> wrote:
>>
>>> On Wed, Mar 1, 2017 at 5:30 PM, William Denniss <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> On Wed, Mar 1, 2017 at 5:05 PM, Marius Scurtescu <[e-mail]
>>>> > wrote:
>>>>
>>>>> On Wed, Mar 1, 2017 at 4:50 PM, William Denniss <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> As a concrete example, let's say an RP that supports OIDC decides to
>>>>>>> also implement RISC/SET. When they read the spec and decide on
>>>>>>> implementation they realize that they also have to modify the existing OIDC
>>>>>>> implementation so it does not accept Id Token looking JWTs that have an
>>>>>>> "events" claim. It is very easy to miss this requirement. But more
>>>>>>> important, when the next JWT application is implemented they might have to
>>>>>>> yet again update the existing OIDC implementation, and so forth.
>>>>>>
>>>>>>
>>>>>> Why would the RISC implementation reuse the same iss/aud pair as the
>>>>>> OIDC implementation?
>>>>>>
>>>>>
>>>>> iss naturally would be the same in most cases. I would argue that aud
>>>>> would also naturally be the same, the client id, since that is the intended
>>>>> recipient. Having aud be the URL of the target endpoint for example (the
>>>>> only suggestion I am aware of), is hackish at best. The same endpoint could
>>>>> be shared by multiple clients in some cases. Also, this couples creating
>>>>> the SET with delivery details
>>>>>
>>>>
>>>> Why not change iss for RISC?  https://issuer.google.com/risc for
>>>> example.
>>>>
>>>
>>> Because iss/sub basically forces the iss to be the exact same as in the
>>> Id Token. And separate iss requires separate signing keys.
>>>
>>
>> We'd have to host the keys multiple times, but they *could* still be the
>> same keys, right?
>>
>>
>>>
>>>>>> If it didn't, there's no issue!
>>>>>>
>>>>>
>>>>> There might be no issue for SET, but we are going to run into this
>>>>> problem over and over again.
>>>>>
>>>>>
>>>>>
>>>>>> Isn't this the simplest approach? Given that "typ" isn't mandated by
>>>>>> JWT, I think that this is therefore the implied method for segregating JWTs
>>>>>> by the usage intent.
>>>>>>
>>>>>
>>>>> Not sure what you mean by "this". Replacing typ with unique iss/aud
>>>>> combinations?
>>>>>
>>>>
>>>> Our issue is that we have a common token format JWT, that multiple
>>>> systems will consume which have different concerns.  Reading RFC7519, I
>>>> don't see any way to separate those concerns, other than with iss/aud.
>>>> RFC7519 doesn't say "each spec that uses JWT should use a unique
>>>> combination of claims such at no other spec could accidently interpret it
>>>> as meant for them" (and I'm not convinced this is scalable, or desirable).
>>>> Nor does it require the use of a type claim to achieve the usage
>>>> segregation, and it's too late to add one now.
>>>>
>>>
>>> I totally agree that we have no ideal solution here. Having each
>>> application define its own URN (or some schema) for aud might work, even if
>>> ugly. This is similar to merging typ into aud. Do we have any concrete
>>> proposals here?
>>>
>>
>> Defining a structured aud format could solve this, I agree – like you
>> say, it's merging type into aud in a way that's backwards compatible.
>> Personally I don't mind that approach, but I recall some resistance to it.
>>
>> Some kind of separation based on iss or aud I think is going to be the
>> safest and most scalable solution.
>>
>> Why is it too late to use typ?
>>>
>>
>> Because of all the clients already written that don't check for it.
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> Mike, me providing a bulletproof example is irrelevant I think. I am
>>>>>>> trying to convey a general idea. My point is that having to continuously
>>>>>>> update existing implementations with new validation rules is error prone
>>>>>>> and less likely to happen that having to do one generic update.
>>>>>>>
>>>>>>> Marius
>>>>>>>
>>>>>>> On Wed, Mar 1, 2017 at 4:31 PM, Mike Jones <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>> Except that your example isn’t one in which there’s an actual
>>>>>>>> problem.  For all response_types except for “code”, the ID Token must have
>>>>>>>> a “nonce” claim matching the request in order to be validated.  SETs won’t
>>>>>>>> have this claim.  For response_type=code, the ID Token must be retrieved
>>>>>>>> from the Token Endpoint to be valid.  But SETs aren’t returned as the
>>>>>>>> id_token value from the Token Endpoint.  There isn’t a channel in which an
>>>>>>>> attacker can successfully substitute a SET for an ID Token and have it
>>>>>>>> validate as an ID Token.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Following the advice to also verify that there isn’t an “events”
>>>>>>>> claim in an ID Token provides redundancy and is good hygiene but isn’t
>>>>>>>> actually even necessary to prevent substitution attacks.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                                        -- Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* Marius Scurtescu [mailto:[e-mail]]
>>>>>>>> *Sent:* Wednesday, March 1, 2017 4:22 PM
>>>>>>>> *To:* Mike Jones <[e-mail]>
>>>>>>>> *Cc:* William Denniss <[e-mail]>; Phil Hunt (IDM) <
>>>>>>>> [e-mail]>; ID Events Mailing List <[e-mail]>
>>>>>>>>
>>>>>>>> *Subject:* Re: [Id-event] Thread: Clarifying use of sub and iss in
>>>>>>>> SET tokens
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As a concrete example, let's say an RP that supports OIDC decides
>>>>>>>> to also implement RISC/SET. When they read the spec and decide on
>>>>>>>> implementation they realize that they also have to modify the existing OIDC
>>>>>>>> implementation so it does not accept Id Token looking JWTs that have an
>>>>>>>> "events" claim. It is very easy to miss this requirement. But more
>>>>>>>> important, when the next JWT application is implemented they might have to
>>>>>>>> yet again update the existing OIDC implementation, and so forth.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> One simpler fix would be to modify the OIDC implementation once to
>>>>>>>> look for the correct "typ" claim (assuming one is defined). The security
>>>>>>>> considerations in the SET spec could specify that due to iss/aud overlap it
>>>>>>>> is crucial that typ is validated in all related implementations.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I understand that typ cannot be standardized by the SET spec for
>>>>>>>> other specs (but it could definitely clearly define it for SET), but I
>>>>>>>> think the sooner we do that for all relevant specs the better.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Marius
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 1, 2017 at 4:07 PM, Mike Jones <
>>>>>>>> [e-mail]> wrote:
>>>>>>>>
>>>>>>>> Of course, there is already a “typ” claim.  Its use is optional,
>>>>>>>> since whether it’s needed is application-specific.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Your suggestion that we issue general-purpose JWT guidance about
>>>>>>>> iss/aud namespaces is exactly the kind of thing that’s beyond the scope of
>>>>>>>> this working group, per my just-sent reply to Marius.  Suggesting that
>>>>>>>> applications use the “events” claim to distinguish between SETs and other
>>>>>>>> kinds of JWTs is within the scope of this working group, because it is
>>>>>>>> advice about using SETs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                                        -- Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* William Denniss [mailto:[e-mail]]
>>>>>>>> *Sent:* Wednesday, March 1, 2017 4:00 PM
>>>>>>>> *To:* Marius Scurtescu <[e-mail]>
>>>>>>>> *Cc:* Phil Hunt (IDM) <[e-mail]>; Mike Jones <
>>>>>>>> [e-mail]>; ID Events Mailing List <
>>>>>>>> [e-mail]>
>>>>>>>> *Subject:* Re: [Id-event] Thread: Clarifying use of sub and iss in
>>>>>>>> SET tokens
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If JWT had a "typ" field all along, this entire discussion could be
>>>>>>>> avoided, but it's too late for that now. I believe that this was actually
>>>>>>>> the founding reason behind standardizing SET, introducing the "events"
>>>>>>>> claim. At least, to avoid the 3+ versions of event-on-JWT that were in
>>>>>>>> discussion at the time.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As with all security considerations people can not follow them and
>>>>>>>> have bad things happen.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Doesn't suggesting that unrelated systems not issue tokens sharing
>>>>>>>> the same iss/aud namespace make sense here as a mitigation though?  To me
>>>>>>>> that's better and more scalable than every spec removing some required
>>>>>>>> claim from the other specs (e.g. mandating that people can't use "sub").
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 1, 2017 at 3:54 PM, Marius Scurtescu <
>>>>>>>> [e-mail]> wrote:
>>>>>>>>
>>>>>>>> We also talked about adding another claim that defines the type or
>>>>>>>> purpose of the JWT ("access token", "SET", etc). In a way it is the only
>>>>>>>> sane option, but it is not addressing existing implementations. Asking
>>>>>>>> implementors to "be careful" is asking for trouble IMO, especially because
>>>>>>>> systems evolve by incrementally adding functionality.
>>>>>>>>
>>>>>>>>
>>>>>>>> Marius
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 1, 2017 at 12:44 PM, William Denniss <
>>>>>>>> [e-mail]> wrote:
>>>>>>>>
>>>>>>>> OK so perhaps the "URI" thing is overly restrictive.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I guess the security consideration I'm recommending here is that
>>>>>>>> you shouldn't have multiple systems that issue JWTs with the same iss/aud
>>>>>>>> tuple, except when those systems are tightly coupled (as is the case with
>>>>>>>> Connect & Logout).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If a shared issuer is used, then URI-based namespacing is *one* way
>>>>>>>> to avoid this, but there are others.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm trying to avoid the need for SET to "break" possible use in
>>>>>>>> access tokens (one of the stated goals in the original post) – I think
>>>>>>>> having advice like this can avoid normative language that changes, and
>>>>>>>> overly complicates SET.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Id-event mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Id-event mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/id-event
>>
>>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>
>