Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 26 November 2015 01:29 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8E11A8835 for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 17:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHVc2rbJLBEs for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 17:29:29 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA241A882E for <oauth@ietf.org>; Wed, 25 Nov 2015 17:29:28 -0800 (PST)
Received: by wmuu63 with SMTP id u63so3412322wmu.0 for <oauth@ietf.org>; Wed, 25 Nov 2015 17:29:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MP4cTtAyIcpAU83ZkL4fERGXBj3sh7zBXeKm8a5yCyA=; b=BVXDCj1AN2S+Fjge0JMLUCQQpWIM1FgJ25jExzYdOG2PLBFybjHcops+6JYQXZGiQg Yu0RamOINYcEa0LWp/jZZNp7M3NOvlKHEs1QqkmPyeBIpVUaExyj1Gi4IWiky5yI0kZl uGG1hrlUnIgxYPZ/jjtZ72+oNH+GcekvltV2PQujsBn9tezsC8fx5w64iZO6EogUHNFt 0qeJRcz6jd3OriFRMZuAgUtc3u0SK5Vm7+VkiKdHIJxRN/qMCyL60bACp23U7+r3TpD7 0X8M7J40wJjh0jCT235KyroMQOc9BkBg89Z6HspPdTlNsWWITt+DaQQOx8Cj6MTpuX5i fU7Q==
MIME-Version: 1.0
X-Received: by 10.28.218.17 with SMTP id r17mr669564wmg.90.1448501367522; Wed, 25 Nov 2015 17:29:27 -0800 (PST)
Received: by 10.28.52.130 with HTTP; Wed, 25 Nov 2015 17:29:27 -0800 (PST)
In-Reply-To: <BY2PR03MB442E173BA04356BAB71FE5AF5050@BY2PR03MB442.namprd03.prod.outlook.com>
References: <CAHbuEH4J5SYVuWe5+OHfCQARuZhOJ6hG=5RqUkh5Ebad_RneAg@mail.gmail.com> <BY2PR03MB442BD8E7C5AFA8D79C79AEAF5050@BY2PR03MB442.namprd03.prod.outlook.com> <CAHbuEH7pJFKH_gJE6aSHCBQZL5eZ9qxyHajzjwz=5v8+LD7ywQ@mail.gmail.com> <BY2PR03MB4422F5F3905D4118D9D540BF5050@BY2PR03MB442.namprd03.prod.outlook.com> <CAHbuEH6x4fxPmho8RbgFLngXGROcDfGhSWkDAAciVkYa7AOXTw@mail.gmail.com> <BY2PR03MB44297DA1D6A4C4F125EBCFCF5050@BY2PR03MB442.namprd03.prod.outlook.com> <F4372014-9338-4EEA-B49A-CA53E73BC6A0@gmail.com> <BY2PR03MB442E173BA04356BAB71FE5AF5050@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Wed, 25 Nov 2015 20:29:27 -0500
Message-ID: <CAHbuEH4_ZQ1d2janMadG_HkiuCgJLL_dBtym4c3usZcYWVPpKg@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/4Ja5BuUwYFuOkUI1qA34ILZaq5I>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2015 01:29:32 -0000

Mike,

On Wed, Nov 25, 2015 at 2:26 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> Hi Kathleen,
>
> For what it's worth, Pete's ballot on JWT - recorded at http://datatracker.ietf.org/doc/rfc7519/ballot/#pete-resnick - consisted entirely of this comment:
>         Others have said all I might say. I do not object to "joots". :-)
>
> There were things in the JOSE specs that Pete, in the end, abstained on, but not JWT.

I'm not going to dig through all of the discuss comments and emails to
find this one as there was huge amounts of overlapping text in each of
the drafts and continuing this type of discussion serves no purpose.

I continued from John's message as that was more productive.

Best regards,
Kathleen

>
> I think we may be talking past each other on the ambiguity that you're referring to.  Let me try again.
>
> In normal uses of JWT, there will be a JWT library (using a JOSE library) and application-specific code that uses the resulting JWTs.  At the JWT library level, yes, stuff that's not understood will be ignored.  There's no ambiguity for JWT implementers on what to do.
>
> But at the application level, it's entirely within the application's rights to reject a JWT that contains things that don't conform to the application's specified use of JWT, including rejecting it because things were included that it didn't expect.  It's the *application* that may choose not to ignore some not-understood or not-anticipated values - not the JWT library.  That's what the second paragraph of http://tools.ietf.org/html/rfc7519#section-4 is talking about and what the equivalent second paragraph of https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-07#section-3.1 is also about.
>
> If you feel that that point needs further clarification in the draft, I'd rather that we do that now, than have you submit a ballot that calls out the ambiguity that you're referring to, when the situation for JWT implementers is actually unambiguous.
>
> How would you like to proceed?
>
>                                 -- Mike
>
> -----Original Message-----
> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
> Sent: Wednesday, November 25, 2015 6:21 AM
> To: Mike Jones <Michael.Jones@microsoft.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession
>
> Hi Mike,
>
> If the working group is okay with the current text, leave it.  What you proposed is exactly the same as what is there.  I'll note this point in my ballot as I think you are leaving ambiguity that is not necessary.
>
> After getting far enough on this, I think it was Pete who discussed this with you and he gave up and remained in disagreement.
>
> Regards,
> Kathleen
>
> Sent from my iPhone
>
>> On Nov 24, 2015, at 10:25 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Rather than elaborating, having looked at the text we're discussing again, I'm going to counter-propose that we instead simplify - sticking only to the point that the paragraph is intending to get across.  Would it work for you to simplify the current text:
>>
>>    "A recipient might not understand the cnf claim, in which case it will typically be ignored. Unless this is acceptable behavior, applications that need the proof-of-possession keys communicated with it to be understood and processed must require that the parts of this specification that they use be implemented."
>>
>> to this simpler text?
>>
>>    "A recipient might not understand the cnf claim.  Applications that need the proof-of-possession keys communicated with it to be understood and processed must require that the parts of this specification that they use be implemented."
>>
>> The "must ignore" topic is already addressed in the second paragraph of 3.1 (and with exactly the semantics as the rest of JWT), and so doesn't have to be re-raised here, as it currently is.  Re-raising it is clearly a point of distraction.
>>
>> For what it's worth, I don't remember any DISCUSSes on this topic (although it's possible that your memory is better than mine on this point).
>>
>>                Best wishes,
>>                -- Mike
>>
>> -----Original Message-----
>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
>> Sent: Tuesday, November 24, 2015 7:14 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] AD review of
>> draft-ietf-oauth-proof-of-possession
>>
>>> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>> Fair question about the use of "typically".  The reason it's there is that this language in JWT [RFC 7519] Section 4 does permit applications to require that JWTs with not-understood claims be rejected, rather than ignored, even though that's not the default behavior:
>>>
>>>   The set of claims that a JWT must contain to be considered valid is
>>>   context dependent and is outside the scope of this specification.
>>>   Specific applications of JWTs will require implementations to
>>>   understand and process some claims in particular ways.  However, in
>>>   the absence of such requirements, all claims that are not understood
>>>   by implementations MUST be ignored.
>>>
>>> So when not understood, "cnf" would typically be ignored, but might not be.
>>
>> I find that confusing and am now thinking this came up in a discuss as well during the review for 7519, didn't it?  Can you elaborate int eh security considerations section a bit more, otherwise this text appears to be conflicting and even with what you intend, it's confusing for implementers and will lead to issues with interoperability.
>>
>> Thanks,
>> Kathleen
>>
>>
>>>
>>>                                -- Mike
>>>
>>> -----Original Message-----
>>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
>>> Sent: Tuesday, November 24, 2015 6:41 PM
>>> To: Mike Jones <Michael.Jones@microsoft.com>
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] AD review of
>>> draft-ietf-oauth-proof-of-possession
>>>
>>> Hi Mike,
>>>
>>> Thanks for the quick turn-around.  Just one more comment on my comments.
>>>
>>>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>> Thanks for your review comments, Kathleen.  Responses are inline below...
>>>>
>>>>> -----Original Message-----
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen
>>>>> Moriarty
>>>>> Sent: Tuesday, November 24, 2015 9:44 AM
>>>>> To: oauth@ietf.org
>>>>> Subject: [OAUTH-WG] AD review of
>>>>> draft-ietf-oauth-proof-of-possession
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thank you all for your work on this draft!  I just have a few questions:
>>>>>
>>>>> 1. Security considerations section says:
>>>>>
>>>>> "All of the normal security issues, especially in relationship to
>>>>>   comparing URIs and dealing with unrecognized values, that are
>>>>>   discussed in JWT [JWT] also apply here."
>>>>>
>>>>> I find that to be odd phrasing that would likely be picked up in
>>>>> subsequent reviews.  Please remove the word "normal" so that all of
>>>>> the security issues discusses in JWT are included.  Are there other
>>>>> 'normal considerations in addition to those in JWT that need to be
>>>>> listed?  The phrasing reads as if that may the case and would be
>>>>> better to include them all or pointers or change the phrasing.
>>>>
>>>> You're right.  I removed this awkward wording.
>>>>
>>>>> 2. Also in the security considerations section,
>>>>>
>>>>>   "A recipient may not understand the newly introduced "cnf" claim and
>>>>>   may consequently treat it as a bearer token."
>>>>>
>>>>> What is the proper handling requirement when an unknown claim is
>>>>> present?  Section 3.1 says:
>>>>>  "When a recipient receives a "cnf" claim with a
>>>>>   member that it does not understand, it MUST ignore that member."
>>>>>
>>>>> Is this why it is treated as a bearer token rather than being
>>>>> rejected?  Is this really the action you want to see with cnf?  Why
>>>>> isn't there an error and a resend as a bearer token so that parties
>>>>> understand (or have an opportunity to understand) that there were issues?
>>>>>
>>>>> Then the following text in the security section says:
>>>>>  "While this is a
>>>>>   legitimate concern, it is outside the scope of this specification,
>>>>>   since demonstration the possession of the key associated with the
>>>>>   "cnf" claim is not covered by this specification. For more
>>>>> details,
>>>>>
>>>>> How is this outside of the scope of this draft?  cnf is defined in
>>>>> this draft, so handling should be covered in this draft.  A pointer
>>>>> to the POP architecture draft is not helpful as it is not defined
>>>>> there, it's covered int his draft.  Should this text just be
>>>>> removed and replaced with more explicit handling information int he body of this draft?
>>>>
>>>> Good catch.  JWT [RFC 7519] Section 4 says that claims that are not understood must be ignored unless otherwise specified by the application.  This allows new claims to be dynamically added without breaking existing applications.  For the same reason, I have incorporated this language about understanding claims from 7519, but having it be about understanding confirmation members.  Ultimately, what features must be implemented are always up to the application, just as with JWT claims.
>>>
>>> The new text in Section 3.1 looks good.  I'm not sure why the word "typically" appears int he new text of the security considerations section though after reading the new text in 3.1.  Wouldn't it just be ignored since 3.1 now says:
>>>
>>>   "However, in the absence of such requirements,
>>>    all confirmation members that are not understood by implementations
>>>    MUST be ignored."
>>>
>>> Thanks,
>>> Kathleen
>>>
>>>
>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>>
>>>>> Best regards,
>>>>> Kathleen
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>                                Thanks again,
>>>>                                -- Mike
>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen



-- 

Best regards,
Kathleen