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

[Marius Scurtescu <[e-mail]>]

On Thu, Mar 2, 2017 at 6:12 PM, Mike Jones <[e-mail]>
wrote:

> It’s not a legal JWT implementation if it doesn’t implement “crit”.  Per
> https://tools.ietf.org/html/rfc7515#section-4.1.11, “This Header
> Parameter MUST be understood and processed by implementations”.  If you
> know of implementations that don’t support it, we should lobby to get them
> fixed, rather than trying to work around bugs in those implementations.
>

Thanks for clarifying. Then Brian's proposal is definitely viable.

>
>
> Again, doing general-purpose JWT work is not in the scope of this working
> group.  (The OAuth WG owns that.)  Doing SecEvent-specific JWT work is in
> scope.
>

I totally understand that Mike, but to me it looked like there is no good
solution in scope for this working group, so I suggested we escalate.

>
>
>                                                                 -- Mike
>
>
>
> *From:* Marius Scurtescu [mailto:[e-mail]]
> *Sent:* Thursday, March 2, 2017 4:35 PM
> *To:* Phil Hunt <[e-mail]>
> *Cc:* Brian Campbell <[e-mail]>; William Denniss <
> [e-mail]>; Mike Jones <[e-mail]>; ID Events
> Mailing List <[e-mail]>
> *Subject:* Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread:
> Clarifying use of sub and iss in SET tokens)
>
>
>
> 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/
> 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
>
>
>
> _______________________________________________
> 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
>
>
>
>
>