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

[Phil Hunt <[e-mail]>]

This thread here suggests that with “alg”:”none” cert could be modified to make it look like it isn’t at SET and be used as an access token.

If it does not matter, we need to include the conditions where “alg”:”none” is safe to use.  E.g. the assertions are shared in a back-channel not associated with users and secured by mutual TLS so no third party could intercept.


Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>







> On Mar 3, 2017, at 4:48 PM, Mike Jones <[e-mail]> wrote:
> 
> That’s another issue that’s already been well-discussed.  There are plenty of cases in which “alg”: “none” is the right level of integrity protection for JWTs – including SETs.  This is the case when, for instance, the JWT or SET is already integrity protected by the transport – such as TLS.  We should definitely leave the choice of JWT/SET algorithms up to the application – just like the base JWT spec did.
>  
> I understand the urge to “tighten things up” but it’s often the case when we “tighten things up” we’d be imposing restrictions on SETs that would make them a poor match for particular use cases, causing them to not use SETs at all.  The value of SETs is that they define an “events” claim and its usage within JWTs.  Unless there are compelling reasons to go further, we should stop there and declare victory.
>  
>                                                                 -- Mike
>  
> From: Phil Hunt (IDM) [mailto:[e-mail]] 
> Sent: Friday, March 3, 2017 3:34 PM
> To: Brian Campbell <[e-mail]>
> Cc: Vivek Biswas <[e-mail]>; Marius Scurtescu <[e-mail]>; Mike Jones <[e-mail]>; William Denniss <[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)
>  
> Would we want to make signing mandatory to ensure SET differentiation is protected (in addition to the other benefits)?
> 
> Phil
> 
> On Mar 3, 2017, at 2:32 PM, Brian Campbell <[e-mail] <mailto:[e-mail]>> wrote:
> 
> The JWT/JWS header is covered by the signature. 
>  
> On Fri, Mar 3, 2017 at 11:22 AM, Vivek Biswas <[e-mail] <mailto:[e-mail]>> wrote:
> I am not a big fan of defining type within the header field of the JWT since the header field is not signed and decisions can be influenced by doing MIM attacks.
>  
> See article
> https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ <https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/>
> This attack is also known as “"Algorithm choice as an attack vector"
> Similar attack can be done with respect to the “type”.
>  
> If a type is required it should be defined within the body which is signed.
>  
> Regards
> Vivek Biswas, CISSP
> Consulting Member @Security
> Oracle Corporation, San Jose
>  
> From: Marius Scurtescu [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Thursday, March 02, 2017 6:17 PM
> To: Mike Jones
> Cc: William Denniss; Brian Campbell; ID Events Mailing List; Phil Hunt
> 
> Subject: Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: Clarifying use of sub and iss in SET tokens)
>  
> On Thu, Mar 2, 2017 at 6:12 PM, Mike Jones <[e-mail] <mailto:[e-mail]>> wrote:
> It’s not a legal JWT implementation if it doesn’t implement “crit”.  Perhttps://tools.ietf.org/html/rfc7515#section-4.1.11 <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] <mailto:[e-mail]>] 
> Sent: Thursday, March 2, 2017 4:35 PM
> To: Phil Hunt <[e-mail] <mailto:[e-mail]>>
> Cc: Brian Campbell <[e-mail] <mailto:[e-mail]>>; William Denniss <[e-mail] <mailto:[e-mail]>>; Mike Jones <[e-mail] <mailto:[e-mail]>>; ID Events Mailing List <[e-mail] <mailto:[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] <mailto:[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 <http://www.independentid.com/>
> [e-mail] <mailto:[e-mail]>
>  
>  
>  
>  
>  
> 
>  
> On Mar 2, 2017, at 8:03 AM, Phil Hunt <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Interesting!  +1
>  
> Phil
>  
> Oracle Corporation, Identity Cloud Services & Identity Standards
> @independentid
> www.independentid.com <http://www.independentid.com/>
> [e-mail] <mailto:[e-mail]>
>  
>  
>  
>  
>  
> 
>  
> On Mar 2, 2017, at 7:53 AM, Brian Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Not that it makes a difference helping the situation here but "typ" is a JOSE header rather than a JWT claim (seehttps://tools.ietf.org/html/rfc7515#section-4.1.9 <https://tools.ietf.org/html/rfc7515#section-4.1.9> andhttps://tools.ietf.org/html/rfc7516#section-4.1.11 <https://tools.ietf.org/html/rfc7516#section-4.1.11> andhttps://tools.ietf.org/html/rfc7519#section-5.1 <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 <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] <mailto:[e-mail]>> wrote:
>  
>  
> On Wed, Mar 1, 2017 at 5:52 PM, Marius Scurtescu <[e-mail] <mailto:[e-mail]>> wrote:
> On Wed, Mar 1, 2017 at 5:30 PM, William Denniss <[e-mail] <mailto:[e-mail]>> wrote:
>  
> On Wed, Mar 1, 2017 at 5:05 PM, Marius Scurtescu <[e-mail] <mailto:[e-mail]>> wrote:
> On Wed, Mar 1, 2017 at 4:50 PM, William Denniss <[e-mail] <mailto:[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 <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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>] 
> Sent: Wednesday, March 1, 2017 4:22 PM
> To: Mike Jones <[e-mail] <mailto:[e-mail]>>
> Cc: William Denniss <[e-mail] <mailto:[e-mail]>>; Phil Hunt (IDM) <[e-mail] <mailto:[e-mail]>>; ID Events Mailing List <[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>]
> Sent: Wednesday, March 1, 2017 4:00 PM
> To: Marius Scurtescu <[e-mail] <mailto:[e-mail]>>
> Cc: Phil Hunt (IDM) <[e-mail] <mailto:[e-mail]>>; Mike Jones <[e-mail] <mailto:[e-mail]>>; ID Events Mailing List <[e-mail] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
> _______________________________________________
> Id-event mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> _______________________________________________
> Id-event mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> _______________________________________________
> Id-event mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>