+1
On Thu, Oct 23, 2014 at 10:58 AM, Nat Sakimura <sakim...@gmail.com> 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 <ve7...@ve7jtb.com>:
>> 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 <
>> kathleen.moriarty.i...@gmail.com> wrote:
>>
>>
>>
>> On Tue, Oct 21, 2014 at 9:16 AM, Stephen Farrell <
>> stephen.farr...@cs.tcd.ie> 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:oauth-boun...@ietf.org] On Behalf Of Mike Jones
>>> >> Sent: Monday, October 06, 2014 7:20 PM
>>> >> To: Stephen Farrell; The IESG
>>> >> Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-
>>> >> to...@tools.ietf.org; oauth@ietf.org
>>> >> 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:stephen.farr...@cs.tcd.ie]
>>> >>> Sent: Monday, October 06, 2014 2:43 PM
>>> >>> To: Mike Jones; The IESG
>>> >>> Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-
>>> >>> to...@tools.ietf.org; oauth@ietf.org
>>> >>> 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:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 2014
>>> >>>>> 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org;
>>> >>>>> draft-ietf-oauth-json-web- to...@tools.ietf.org 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.html for 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 as
>>> http://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 removed
>>> http://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 at
>>> https://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
>>> >> OAuth@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>> >
>>>
>>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
