Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

[Brian Campbell <[e-mail]>]

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/
rfc7515#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
>
>