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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 25 November 2015 02:41 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 D05C51ACE03 for <oauth@ietfa.amsl.com>; Tue, 24 Nov 2015 18:41:22 -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 4kNkBM1sYcp0 for <oauth@ietfa.amsl.com>; Tue, 24 Nov 2015 18:41:21 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 DC60C1ACE01 for <oauth@ietf.org>; Tue, 24 Nov 2015 18:41:20 -0800 (PST)
Received: by wmww144 with SMTP id w144so51135182wmw.0 for <oauth@ietf.org>; Tue, 24 Nov 2015 18:41:19 -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=uc1HnEpiRE2o2TlIv8OqiyncBSKBqv/8+jZ7We5dvnc=; b=Ag/NhmiYOkMtMpRa8+VL5cGttnYggQfjuclEhwhdbXRr/qMwa1ARakTYme2dkajCDj 6mm77jCB/Uu1Vwlg9F4eLEgRtbwHVwTtxRnNVH8yqg8XZXbafS/BUTmI8ctra7kz58us UN1kcus9mt1tNqPB88Z+g4U0xGcgfuM+6/dEzsrqesZFYS5kXU/4HlGKtNRcVmrmlinV KosVpYK0nSXViAwY1t+bvXTH8mMqxX2w/GyKLjYaluOsNN8uQyYdQ9Ohm8wm9M5NdTon YMlxdJLoTsw/V88oT6AxuRne9sR2/cc11C2KAZnD3gYArFWAP7vLH+6hRd8F4Vsd/9Bo 8aXA==
MIME-Version: 1.0
X-Received: by 10.28.224.7 with SMTP id x7mr1484236wmg.17.1448419279531; Tue, 24 Nov 2015 18:41:19 -0800 (PST)
Received: by 10.28.52.130 with HTTP; Tue, 24 Nov 2015 18:41:19 -0800 (PST)
In-Reply-To: <BY2PR03MB442BD8E7C5AFA8D79C79AEAF5050@BY2PR03MB442.namprd03.prod.outlook.com>
References: <CAHbuEH4J5SYVuWe5+OHfCQARuZhOJ6hG=5RqUkh5Ebad_RneAg@mail.gmail.com> <BY2PR03MB442BD8E7C5AFA8D79C79AEAF5050@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Tue, 24 Nov 2015 21:41:19 -0500
Message-ID: <CAHbuEH7pJFKH_gJE6aSHCBQZL5eZ9qxyHajzjwz=5v8+LD7ywQ@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/8bctkfRNS14CcbGXuKjHEVwTsG4>
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: Wed, 25 Nov 2015 02:41:23 -0000

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