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

[Marius Scurtescu <[e-mail]>]

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