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

[William Denniss <[e-mail]>]

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