[Openid-specs-ab] [Id-event] solution for Id/Access Token confusion and distinct SET issuer
Phil Hunt (IDM)
phil.hunt at oracle.com
Mon Jun 19 21:43:18 UTC 2017
Mike
Cc: openid connect list
[personal hat]
I believe that your position severely limits the value of having a SET spec.
If logout has different parsing rules than the other specs, interop is compromised due to different handling for different security components.
As I said before, within the context of OpenId, I feel backchannel logout is too narrowly defined and many other logout and session events will be needed that are user triggered depending on scenario.
Marius's point is important.
For example we want to let the IDP know a subject has logged out of a specific RP. This is different from a logout command which signals single-logout / SLO at the OP to all RPs. In this case the SET is issued by the RP and not the OP/IDP.
Phil
> On Jun 19, 2017, at 2:27 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>
> Marius, there’s nothing stopping you (or the RISC working group or other profiles) from defining events that can be sent from RPs to IdPs now, without any changes to the SET spec. Specify the claims you want to use, and you’re golden.
>
> But it would be counterproductive to require all other SETs to meet the requirements of your specific profile. There are simpler use cases that can use claims in simpler ways. Trying to make the simple use cases be complex will have the side effect of limiting the adoption of the spec, which wouldn’t be good for anyone.
>
> If successful, SETs will have many different profiles. That’s a sign of success – not a sign of weakness.
>
> -- Mike
>
> From: Marius Scurtescu [mailto:mscurtescu at google.com]
> Sent: Monday, June 19, 2017 11:58 AM
> To: Mike Jones <Michael.Jones at microsoft.com>
> Cc: Yaron Sheffer <yaronf.ietf at gmail.com>; Justin Richer <jricher at mit.edu>; Richard Backman, Annabelle <richanna at amazon.com>; Henk Birkholz <henk.birkholz at sit.fraunhofer.de>; ID Events Mailing List <id-event at ietf.org>; Phil Hunt <phil.hunt at oracle.com>
> Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
>
> On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> I’m sorry to be slow replying to some messages in this thread. I have a lot of other things on my plate, but I will take the time now to reply, because I wholeheartedly disagree with some of the statements below and believe it would be severely harmful to the specification and its adoption to act upon them. Specifically:
>
> I disagree that specific rules should be made for the “sub” claim. Claims usage needs to be up to the application. I know that many others agree with me, because the OpenID Connect working group designed the logout token in http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken (which is also used as an example in https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2) to use the “sub” claim in the normal way. Prohibiting this usage would be a completely unnecessary breaking change – as it’s impossible to confuse a logout token with an ID Token, for reasons already cites in this thread.
> Solving the confusion is one problem. The other problem I keep mentioning is SETs issued by an RP to be sent to an IdP. How are we solving that problem Mike? In this case the top level iss is different from the iss of the sub, a top level sub is not possible.
>
> And I don't want to downplay the confusion problem either. I think it is a real concern and I think a solid solution is important.
>
> The OpenID Working Group designed logout tokens without secevent in mind. I agree we should not recklessly break compatibility, but to me it seems necessary in this case.
>
>
>
> (I agree with the “iss” rules already in place at https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1. No further “iss” rules are needed.)
>
> Further iss ruies are absolutely needed for the RP to IdP case described above.
>
>
>
>
> It’s fine for the “typ” header parameter to be used for some profiles to differentiate between kinds of JWTs. Its use should not be mandated in the SET spec. I would oppose duplicating the “typ” functionality by defining another claim with a duplicative meaning.
> If typ can be use and no other claim is needed, then let's talk about that. I do think SET should mandate it. I don't understand why not. Can you please propose with examples how can typ be used?
>
>
>
>
> I’ll also respond to Annabelle’s assertion that “No other profile of JWT can ever use the "nonce” claim.” This reflects a misunderstanding. It’s the *value* of the nonce that self-secures the JWT – not that any “nonce” claim is present. Any and all JWTs can simultaneously use “nonce” without any risk of conflict, since the nonce value is a cryptographically secure random number.
>
> For SETs I cannot see how the nonce value is useful. That value is not passed back and it cannot be verified. Only the presence of the claim could have some use, hinting at the usage of the JWT, a very weak solution to the confusion problem.
>
>
>
> Will some of you be at the Cloud Identity Summit next week? I’d be glad to have in-person discussions about these topics there.
>
> -- Mike
>
> P.S. Food for thought: Prohibiting the use of “sub” (or any other claim) or forcing it to be located in a non-standard location makes about as much sense as arbitrarily saying that, for a particular profile, the Latin word for subject “subiectum” must be used as the claim name instead of “sub”. Yes, it will completely differentiate this profile from others not spelling the claim name this way, but it would certainly be an impediment to the use of standard JWT libraries and to interoperability.
>
> If we define that sub must be at the event level then it is at a standard location, I don't see what the issue is. The impediment you mention is the actual solution. I don't think that a JWT library that was written for Id Tokens should be used to parse SETs. The library has to be SET aware, in which case the event level iss+sub is not an issue at all.
>
>
>
>
> From: Yaron Sheffer [mailto:yaronf.ietf at gmail.com]
> Sent: Saturday, June 17, 2017 1:45 PM
> To: Justin Richer <jricher at mit.edu>; Marius Scurtescu <mscurtescu at google.com>
> Cc: Richard Backman, Annabelle <richanna at amazon.com>; Mike Jones <Michael.Jones at microsoft.com>; Henk Birkholz <henk.birkholz at sit.fraunhofer.de>; ID Events Mailing List <id-event at ietf.org>; Phil Hunt <phil.hunt at oracle.com>
>
> Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
>
> So to summarize what I'm seeing on this thread:
>
> Everybody agrees with Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET spec.
>
> Almost everybody agrees on a long-term "usage" claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.
>
> Did I miss anything?
>
> By the way, if we do add a "usage" claim, we need to also use it in the SET document before it is published.
>
> Thanks,
>
> Yaron
>
>
> On 15/06/17 22:08, Justin Richer wrote:
> +1 to this as well.
>
> — Justin
>
> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu at google.com> wrote:
>
> +1 to what Annabelle said.
>
> Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.
>
> Marius
>
> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt at oracle.com> wrote:
> +1
>
> Phil
>
> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna at amazon.com> wrote:
>
> Mike,
>
> Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:
> 1. The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.
>
> 2. Any future ID Token distribution method needs to solve this problem again.
>
> 3. No other profile of JWT can ever use the "nonce” claim.
>
> 4. This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.
>
>
> We know from experience that naming collisions and replay attacks are both things that happen. What’s being proposed is a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A “usage-aware” JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.
>
> --
> Annabelle Richard Backman
> Identity Services
>
>
> From: Id-event <id-event-bounces at ietf.org> on behalf of Mike Jones <Michael.Jones at microsoft.com>
> Date: Wednesday, June 14, 2017 at 1:16 PM
> To: Marius Scurtescu <mscurtescu at google.com>
> Cc: "Richard Backman, Annabelle" <richanna at amazon.com>, ID Events Mailing List <id-event at ietf.org>, Henk Birkholz <henk.birkholz at sit.fraunhofer.de>
> Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
>
> You’ve heard of “premature optimization”. I’d characterize the proposals in this thread as “premature pessimation” – making things that can and should be simple complex, without data showing there’s any need to do so.
>
> Mandatory solutions are being proposed in this thread to problems that there’s no evidence that we actually even have. It’s already been established that it’s impossible for a SET to be confused for an ID Token – see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html. If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.
>
> The proposed “solutions”, such as prohibiting the use of “sub” in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex. Yes, then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser. The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures. Keeping it simple is the key to adoption. Standards are only useful if they are actually used.
>
> -- Mike
>
> From: Id-event [mailto:id-event-bounces at ietf.org] On Behalf Of Richard Backman, Annabelle
> Sent: Tuesday, June 13, 2017 5:33 PM
> To: Marius Scurtescu <mscurtescu at google.com>; Henk Birkholz <henk.birkholz at sit.fraunhofer.de>
> Cc: ID Events Mailing List <id-event at ietf.org>
> Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
>
> Echoing Marius’s question: can you explain what you mean by “intend”?
>
> To your first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.
>
> --
> Annabelle Richard Backman
> Identity Services
>
>
> From: Id-event <id-event-bounces at ietf.org> on behalf of Marius Scurtescu <mscurtescu at google.com>
> Date: Tuesday, June 13, 2017 at 11:05 AM
> To: Henk Birkholz <henk.birkholz at sit.fraunhofer.de>
> Cc: ID Events Mailing List <id-event at ietf.org>
> Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
>
> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz at sit.fraunhofer.de> wrote:
> And a 2nd question.
>
> What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"?
>
> "aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)
>
> "scope" is not used by SET.
>
> I don't know what do you mean by "intend" (or intent)?
>
>
>
>
> Henk
>
> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
> Thanks for putting this together!
>
> I think the assumptions inherent in 3.9 are flawed:
>
> ·We can’t guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a “fail on an unrecognized claim” approach to ensure that JWTs from some future spec can’t be mistaken for JWTs from a current spec.
>
> ·It is unrealistic to expect implementers to adhere to the “different keys for different kinds of JWTs” rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.
>
> ·Ditto for “aud” and “iss” claims.
>
> +1 for a “type” or “usage” claim/header parameter.
>
> --
>
> Annabelle Richard Backman
>
> Identity Services
>
> *From: *Id-event <id-event-bounces at ietf.org> on behalf of Dick Hardt <dick.hardt at gmail.com>
> *Date: *Monday, June 12, 2017 at 3:18 PM
> *To: *Marius Scurtescu <mscurtescu at google.com>
> *Cc: *Adam Dawes <adawes at google.com>, "matake, nov" <nov at matake.jp>, ID Events Mailing List <id-event at ietf.org>, "Phil Hunt (IDM)" <phil.hunt at oracle.com>
> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
>
> Agreed. Note that there is still lots of discussion on what should be in 3.9.
>
> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu at google.com <mailto:mscurtescu at google.com>> wrote:
>
> Thanks for the pointer Dick, very good timing :-)
>
> The issue is described by "2.7. Cross-JWT Confusion" and the
> mitigation is in "3.9. Use Mutually Exclusive Validation Rules for
> Different Kinds of JWTs", specifically "Use different sets of
> required claims...", "Use different keys for different kinds of
> JWTs." and "Use different issuers for different kinds of JWTs.".
>
> I still think that a "type" claim would bring a lot of clarity and
> safety.
>
>
> Marius
>
> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt at gmail.com
> <mailto:dick.hardt at gmail.com>> wrote:
>
> Yaron, Mike and I just published an BCP ID for JWT
> http://self-issued.info/?p=1690
>
> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes at google.com
> <mailto:adawes at google.com>> wrote:
>
> I was initially a fan of keeping SETS to be very similar to
> id tokens but I now think this is a better plan.
>
> On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov at matake.jp
> <mailto:nov at matake.jp>> wrote:
>
> +1 especially for "type"
>
> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
> <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>>:
>
> +1
>
> Phil
>
>
> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
> <mscurtescu at google.com
> <mailto:mscurtescu at google.com>> wrote:
> >
> > There were a couple of proposals on how to
> distinguish SETs from Id Tokens and Access Tokens in
> such a way that naive implementations will not
> confuse one for the other and open up security
> vulnerabilities.
> >
> > There is also another important requirement: the
> SET issuer in some cases must be different from the
> "sub" issuer. This is the case of an RP sending SETs
> to an IdP.
> >
> > With these requirements in mind I propose the
> following:
> > - both "sub" and "iss" to be defined at the event
> level
> > - "iss" at event level and at top SET level can
> be different
> > - "iss" and "sub" at event level can be different
> across events in the same SET
> > - "sub" should NOT be present at the top SET
> level (this solves the disambiguation), please note
> "should" and not "must"
> >
> > This solution also allows different profiles that
> define event types to define additional claims
> related to sub (like email or phone_number) and
> since all these claims will be at the event level
> there will be no collisions or ambiguity.
> >
> > Another proposal (which I supported) was to
> define a composite "aud" claim. This is not solving
> the requirement for a distinct SET issuer. Also,
> having the same claim name having different syntax
> in different token types could lead to confusion.
> >
> > And yet another proposal was to introduce a new
> claim for JWTs that defines a "type". This is not
> practical in the short term, and it also is not
> solving the distinct issuer requirement, but I think
> this is something the JWT group should seriously
> consider.
> >
> > Thoughts?
> >
> > Marius
>
> > _______________________________________________
> > Id-event mailing list
> > Id-event at ietf.org <mailto:Id-event at ietf.org>
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org <mailto:Id-event at ietf.org>
> https://www.ietf.org/mailman/listinfo/id-event
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org <mailto:Id-event at ietf.org>
> https://www.ietf.org/mailman/listinfo/id-event
>
> --
> Adam Dawes | Sr. Product Manager |adawes at google.com
> <mailto:adawes at google.com> |+1 650-214-2410
> <tel:(650)%20214-2410>
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org <mailto:Id-event at ietf.org>
> https://www.ietf.org/mailman/listinfo/id-event
>
> --
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
> learn about projects I am working on!
>
>
>
> --
>
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170619/77874b1c/attachment.html>
More information about the Openid-specs-ab
mailing list