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.

Why would the RISC implementation reuse the same iss/aud pair as the OIDC
implementation?

If it didn't, there's no issue! 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.

On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <mscurtescu@google.com>
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 <Michael.Jones@microsoft.com>
> 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:mscurtescu@google.com]
>> *Sent:* Wednesday, March 1, 2017 4:22 PM
>> *To:* Mike Jones <Michael.Jones@microsoft.com>
>> *Cc:* William Denniss <wdenniss@google.com>; Phil Hunt (IDM) <
>> phil.hunt@oracle.com>; ID Events Mailing List <id-event@ietf.org>
>>
>> *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 <Michael.Jones@microsoft.com>
>> 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:wdenniss@google.com]
>> *Sent:* Wednesday, March 1, 2017 4:00 PM
>> *To:* Marius Scurtescu <mscurtescu@google.com>
>> *Cc:* Phil Hunt (IDM) <phil.hunt@oracle.com>; Mike Jones <
>> Michael.Jones@microsoft.com>; ID Events Mailing List <id-event@ietf.org>
>> *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 <mscurtescu@google.com>
>> 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 <wdenniss@google.com>
>> 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
>> Id-event@ietf.org
>> https://www.ietf.org/mailman/listinfo/id-event
>>
>>
>>
>>
>>
>>
>>
>
>