Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

[Sergey Beryozkin <[e-mail]>]

Hi

I've found 'none' to be a useful mechanism for using JWT representations 
as OAuth2 (bearer) tokens where JWT is turned into JWS with a none 
algorithm and then encrypted...

Cheers, Sergey
On 23/10/14 09:58, Nat Sakimura wrote:
> I second John's message. There are many ways to achieve a desired level
> of security and one of the most popular way is to delegate it to the
> transport layer and use 'none' as the alg. If 'none' becomes non-MTI,
> then it may cause a lot of interoperability issues down the road.
>
> Adding to it, JWT can be useful in other context than security as well.
> As interoperability is one of the most important criteria, having 'none'
> as MTI seems to be a reasonable idea to me.
>
> Nat
>
> 2014-10-22 16:44 GMT-05:00 John Bradley <[e-mail]
> <mailto:[e-mail]>>:
>
>      From a JWT perspective a number of applications including connect
>     allow unsecured JWT.
>
>     I guess you are referring to sec 8 of JWT in the OAuth WG.  Some of
>     the threads you mention were in the JOSE WG relating to the JWS spec
>     and if none should be included.
>
>     To some extent the issues are not quite the same for the different
>     specs.
>
>     SAML certainly allows for unsigned documents, those are used in a
>     lot of places.  I imagine that a SAML library that could not process
>     unsigned messages would generally be considered broken.
>     That is not to say that it also needs to also support signed ones
>     and some number of trust models.
>
>     It is the same for JWT as it lives at a similar conceptual level to
>     SAML assertions.
>
>     It is better for interoperability to have all the JWT libs implement
>     "none", so that it can be supported in the many cases it may be used
>     for processing JWT protected by transport or some other mechanism,
>     and reliably reject "none" when signatures are required.
>
>     The JWT spec is not requiring JWS or JWE to implement support for
>     none,  though likely life would be easier if they did support it.
>
>     John B.
>
>
>
>     On Oct 21, 2014, at 1:36 PM, Kathleen Moriarty
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>>
>>
>>     On Tue, Oct 21, 2014 at 9:16 AM, Stephen
>>     Farrell<[e-mail]
>>     <mailto:[e-mail]>>wrote:
>>
>>
>>         Hi Mike,
>>
>>         I've one remaining discuss point and a comment. See below...
>>
>>         On 14/10/14 13:50, Mike Jones wrote:
>>         > The proposed resolutions below have been included in the -28
>>         draft.  Hopefully you'll be able to clear your DISCUSSes on
>>         that basis.
>>         >
>>         > The String Comparison Rules in Section 7.3 have been
>>         expanded to talk about when the application may need
>>         canonicalization rules.
>>         >
>>         >                               Thanks again,
>>         >                               -- Mike
>>         >
>>         >> -----Original Message-----
>>         >> From: OAuth [mailto:[e-mail]
>>         <mailto:[e-mail]>] On Behalf Of Mike Jones
>>         >> Sent: Monday, October 06, 2014 7:20 PM
>>         >> To: Stephen Farrell; The IESG
>>         >> Cc:[e-mail]
>>         <mailto:[e-mail]>; draft-ietf-oauth-json-web-
>>         >>[e-mail]
>>         <mailto:[e-mail]>;[e-mail]
>>         <mailto:[e-mail]>
>>         >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
>>         draft-ietf-oauth-json-
>>         >> web-token-27: (with DISCUSS and COMMENT)
>>         >>
>>         >> Thanks for tracking all of this Stephen.  Responses inline
>>         below...
>>         >>
>>         >>> -----Original Message-----
>>         >>> From: Stephen Farrell [mailto:[e-mail]
>>         <mailto:[e-mail]>]
>>         >>> Sent: Monday, October 06, 2014 2:43 PM
>>         >>> To: Mike Jones; The IESG
>>         >>> Cc:[e-mail]
>>         <mailto:[e-mail]>; draft-ietf-oauth-json-web-
>>         >>>[e-mail]
>>         <mailto:[e-mail]>;[e-mail]
>>         <mailto:[e-mail]>
>>         >>> Subject: Re: Stephen Farrell's Discuss on
>>         draft-ietf-oauth-json-web-token-27:
>>         >>> (with DISCUSS and COMMENT)
>>         >>>
>>         >>>
>>         >>> Hi Mike,
>>         >>>
>>         >>> On 06/10/14 08:54, Mike Jones wrote:
>>         >>>> Thanks for your review, Stephen.  I've added the working
>>         group to
>>         >>>> the thread so they're aware of your comments.
>>         >>>>
>>         >>>>> -----Original Message----- From: Stephen Farrell
>>         >>>>> [mailto:[e-mail]
>>         <mailto:[e-mail]>] Sent: Thursday, October
>>         02, 2014
>>         >>>>> 5:03 AM To: The IESG Cc:[e-mail]
>>         <mailto:[e-mail]>;
>>         >>>>> [e-mail]
>>         <mailto:[e-mail]>Subject: Stephen
>>         >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27:
>>         (with
>>         >>>>> DISCUSS and COMMENT)
>>         >>>>>
>>         >>>>> Stephen Farrell has entered the following ballot
>>         position for
>>         >>>>> draft-ietf-oauth-json-web-token-27: Discuss
>>         >>>>>
>>         >>>>> When responding, please keep the subject line intact and
>>         reply to
>>         >>>>> all email addresses included in the To and CC lines.
>>         (Feel free to
>>         >>>>> cut this introductory paragraph, however.)
>>         >>>>>
>>         >>>>>
>>         >>>>> Please refer to
>>         >>>>>http://www.ietf.org/iesg/statement/discuss-criteria.htmlfor
>>         more
>>         >>>>> information about IESG DISCUSS and COMMENT positions.
>>         >>>>>
>>         >>>>>
>>         >>>>> The document, along with other ballot positions, can be
>>         found
>>         >>>>> here:
>>         >>>>>http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         -------------------------------------------------------------------
>>         >>>>> --
>>         >>>>> -
>>         >>>>>
>>         >>>>>
>>         >>> DISCUSS:
>>         >>>>>
>>         -------------------------------------------------------------------
>>         >>>>> --
>>         >>>>> -
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same
>>         thing I
>>         >>> raised wrt DNS
>>         >>>>> names for another JOSE spec - do you need to say those
>>         SHOULD be
>>         >>>>> [upper|lower]cased when used in these?
>>         >>>>
>>         >>>> I believe that somewhere we should say that if
>>         case-insensitive
>>         >>>> values, such as DNS names, are used when constructing
>>         "kid" values,
>>         >>>> that the application doing so needs to define a
>>         convention on the
>>         >>>> canonical case to use for the case-insensitive portions,
>>         such as
>>         >>>> lowercasing them.
>>         >>>
>>         >>> As that discussion's happening on the key draft, I'll
>>         clear it here
>>         >>> and trust you to fix if a change is the end result.
>>         >>
>>         >> Thanks
>>
>>         np
>>
>>         >>
>>         >>>>> (2) Section 8: Why is "none" MTI? That seems both broken
>>         and going
>>         >>>>> in the oppostite direction from other WGs and so should be
>>         >>>>> explicitly jusified I think. (If a good enough
>>         justification exists
>>         >>>>> that is.)
>>         >>>>
>>         >>>> It is MTI because there are several existing applications
>>         of JWTs in
>>         >>>> which both unsigned and signed representations of the
>>         JWTs are
>>         >>>> requirements.  These include draft-ietf-oauth-token-exchange,
>>         >>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect.  This
>>         is a pretty
>>         >>>> common pattern where you sign something if the recipient
>>         cares who
>>         >>>> made the statements and where you don't have to sign it
>>         either if
>>         >>>> the recipient doesn't care who made the statements
>>         >>>
>>         >>> I don't see how (non-)signers can divine non-verifier's
>>         wishes that
>>         >>> way. (Absent negotiation or a directory.)
>>         >>
>>         >> Sometimes it does occur via negotiation.  For instance, in
>>         some protocols, at
>>         >> registration time, relying parties explicitly tell identity
>>         providers what algorithms
>>         >> are acceptable to them, which may include "none".  No
>>         divination - explicit
>>         >> communication.
>>         >>
>>         >>>> or if it can tell from
>>         >>>> another secured aspect of the application protocol (typically
>>         >>>> through the use of TLS) who made the statements.  In the
>>         TLS case,
>>         >>>> the server authentication step makes a signature step
>>         unnecessary,
>>         >>>> so an Unsecured JWT is fine there.
>>         >>>
>>         >>> That's arguable IMO.
>>         >>
>>         >> I agree that it's application and context-dependent whether
>>         it's OK or not.  The
>>         >> point is that there exist some circumstances in which it is
>>         OK, and this feature is
>>         >> being used in some of those cases.
>>         >>
>>         >>> I think I'll look back over the wg thread and either hold
>>         my nose or
>>         >>
>>         >> This issue was tracked
>>         ashttp://trac.tools.ietf.org/wg/jose/trac/ticket/36.
>>         >> Karen O'Donoghue recorded this conclusion in the tracker
>>         "Note: There was
>>         >> extensive discussion on the mailing list, and the rough
>>         consensus of the working
>>         >> group was to leave "none" in the document."
>>         >>
>>         >> Discussion threads on this topic include:
>>         >> [jose] #36: Algorithm "none" should be
>>         removedhttp://www.ietf.org/mail-
>>         >> archive/web/jose/current/msg02911.html - Began Jul 31,
>>         2013  (91 messages)
>>         >> [jose] Text about applications and
>>         "alg":"none"http://www.ietf.org/mail-
>>         >> archive/web/jose/current/msg03321.html - Began Sep 3, 2013
>>         (5 messages)
>>         >>
>>         >> This issue was a topic of a special working group call on
>>         Aug 19, 2013.  The text
>>         >> discussed in the last thread and published
>>         athttps://tools.ietf.org/html/draft-
>>         >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS
>>         Security
>>         >> Considerations) was the result of the working group's
>>         decisions resulting from all
>>         >> of this discussion.
>>
>>         Thanks for all the pointers above. I read through all the (many!)
>>         Aug 19 mails and most of the `"none" should be removed" thread.
>>
>>         So I do see that there was rough consensus to keep "none" in
>>         the draft and can (with difficulty;-) hold my nose and let that
>>         pass. I do not however, see that there was consensus to make
>>         "none" MTI for this draft. I did see a bit of haggling about
>>         this draft vs. JWS but still do not see why none ought be MTI
>>         here.
>>
>>         >>
>>         >>>>> (3) Section 12: another way to handle privacy is to not include
>>         >>>>> sensitive data - I think you ought mention that as a bit of thought
>>         >>>>> along those lines can be much simpler than putting in place the key
>>         >>>>> management to handle thoughtlessly included PII.
>>         >>>>
>>         >>>> We can include a discussion of that point,
>>         >>>
>>         >>> Great. "Just say no" is workable here:-) I'll clear when we get such text.
>>         >>>
>>         >>>> but sometimes the very
>>         >>>> point of a JWT is to securely deliver PII from a verifiable party to
>>         >>>> an intended party with appropriate rights to receive it.
>>         >>>
>>         >>> Hmm. Its a moot point (so let's not argue it) but I wonder how often
>>         >>> PII is really needed for authorization with oauth. My guess would be
>>         >>> that its needed far less often than its found to be profitable
>>         >>> perhaps, or that carelessness plays a big role in using PII for such purposes.
>>
>>         I've cleared on this as you added this text:
>>
>>         "Of course, including
>>            only necessary privacy-sensitive information in a JWT is
>>         the most
>>            basic means of minimizing any potential privacy issues."
>>
>>         That seems to me like a fairly offputting way to phrase it. I'd
>>         suggest instead:
>>
>>         "Omitting privacy-sensitive information from a JWT is the
>>         simplest way of minimizing privacy issues."
>>
>>
>>     I like this wording suggestion, thanks.
>>
>>
>>         Cheers,
>>         S.
>>
>>         PS: I didn't check the comments.
>>
>>         >>>
>>         >>> S.
>>         >>>
>>         >>>
>>         >>>
>>         >>>>
>>         >>>>>
>>         -------------------------------------------------------------------
>>         >>>>> --
>>         >>>>> -
>>         >>>>>
>>         >>>>>
>>         >>> COMMENT:
>>         >>>>>
>>         -------------------------------------------------------------------
>>         >>>>> --
>>         >>>>> -
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>> - abstract: 2nd sentence isn't needed here, in intro would
>>         be fine.
>>         >>>>
>>         >>>> I don't know - I think it's a big deal that the claims can be
>>         >>>> digitally signed or MACed and/or encrypted.  That's the
>>         reason we
>>         >>>> have JWTs, rather than just JSON.
>>         >>>>
>>         >>>>> - 4.1.7: maybe worth adding that jti+iss being unique
>>         enough is not
>>         >>>>> sufficient and jti alone has to meet that need. In X.509 the
>>         >>>>> issuer/serial has the equivalent property so someone
>>         might assume
>>         >>>>> sequential jti values starting at 0 are ok.
>>         >>>>
>>         >>>> Makes sense to add a warning of some kind along these
>>         lines.  I
>>         >>>> think I know the reasons you say that, but can you expand
>>         on that
>>         >>>> thought a bit before I take a stab on writing this up?  For
>>         >>>> instance, while normally true, I don't think your
>>         observation is
>>         >>>> true if a relying party will only accept tokens from a
>>         single issuer.
>>         >>>>
>>         >>>>> - section 6: yuk
>>         >>>>>
>>         >>>>> - again I think the secdir comments are being handled by
>>         Kathleen
>>         >>>>> and the authors.
>>         >>>>
>>         >>>> Again, this is there because multiple applications asked
>>         for the
>>         >>>> ability to represent content that is optionally signed,
>>         sometimes
>>         >>>> securing it another way, such as with TLS.  JWTs are used
>>         specific
>>         >>>> application protocol contexts - not in isolation.
>>         >>>>
>>         >>>> Thanks again, -- Mike
>>         >>>>
>>         >> _______________________________________________
>>         >> OAuth mailing list
>>         >>[e-mail] <mailto:[e-mail]>
>>         >>https://www.ietf.org/mailman/listinfo/oauth
>>         >
>>
>>
>>
>>
>>     --
>>
>>     Best regards,
>>     Kathleen
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>