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

Justin Richer <jricher@mit.edu> Tue, 24 November 2015 18:48 UTC

Return-Path: <jricher@mit.edu>
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 376601A87A7 for <oauth@ietfa.amsl.com>; Tue, 24 Nov 2015 10:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.786
X-Spam-Level:
X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 ZqnxgPMXeN1d for <oauth@ietfa.amsl.com>; Tue, 24 Nov 2015 10:48:18 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F311A879D for <oauth@ietf.org>; Tue, 24 Nov 2015 10:48:16 -0800 (PST)
X-AuditID: 1209190c-f79c96d00000038e-5a-5654b0ef19a7
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 97.51.00910.FE0B4565; Tue, 24 Nov 2015 13:48:15 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tAOImFcD001033; Tue, 24 Nov 2015 13:48:15 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAOImD1v010222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2015 13:48:14 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CAHbuEH4J5SYVuWe5+OHfCQARuZhOJ6hG=5RqUkh5Ebad_RneAg@mail.gmail.com>
Date: Tue, 24 Nov 2015 13:48:13 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <AAAF97A2-1B52-4254-9093-F79267B30536@mit.edu>
References: <CAHbuEH4J5SYVuWe5+OHfCQARuZhOJ6hG=5RqUkh5Ebad_RneAg@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixG6nrvt+Q0iYwZT7ehYNO/MtTr59xebA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZZz6dYWt4JhUxbXZR9gbGNtEuxg5OSQETCQm 3l7FCmGLSVy4t56ti5GLQ0hgMZPEwS2dTCAJIYGNjBIr70pB2A+ZJNavFQGxmQXUJf7Mu8QM YvMK6Em8unUZbJCwgKfEwjNT2UBsNgFVielrWoDmcHBwCgRK3NsgDBJmAQpPu3eGGSQMMqb9 pAvERG2JZQtfQ020krj1cCkLxNYAiX/fb4FNFBGwkFjT/I0N4mRZid2/HzFNYBScheSgWUgO moVk7AJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSmlmxhBgcspybOD8c1BpUOM AhyMSjy8M4qCw4RYE8uKK3MPMUpyMCmJ8h6bFxImxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3 dBdQjjclsbIqtSgfJiXNwaIkzjv3i2+YkEB6YklqdmpqQWoRTFaGg0NJgrdmPVCjYFFqempF WmZOCUKaiYMTZDgP0PCp60CGFxck5hZnpkPkTzEqSonzKgFTg5AASCKjNA+uF5RYEt4eNn3F KA70ijCvI8gKHmBSgut+BTSYCWjwkZJAkMEliQgpqQZGhmnZ5z//9Fi1/dImAz4LtQtcWmuz J3w8lFqw9tMul4eJWxOCJ6h+0r4bHlV3IKWH1+Pb7XeHsgsvXVjesjXa6tWJzzk7wo+k+35h Fi46Nc9HvF/tbEHUw8UPo+wfl88vCDPg89y4RErL/UMZy1l2FqVvUe17/f7fDXkRmLU1neeM ne3d5SXJSizFGYmGWsxFxYkA6L0UwgcDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/kJVwqdJ1Wjan2auSeIJeTqhor9s>
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: Tue, 24 Nov 2015 18:48:21 -0000

I suggest removal of the reference to bearer tokens in this section, since that seems to suggest that this is what the RS should do in such a case. What’s really going to happen is that an RS is going to get a request with this token and it’s going to have to figure out how to deal with it. If there’s a signature (like in http-message-signing) then it’s going to need to find the key. If it can’t read the key out of the cnf claim then it won’t be able to validate the signature and won’t process the message. If that’s the case then this RS can’t accept this token. 

This has nothing to do with bearer tokens vs. PoP tokens. It’s not really any different from an RS accepting JWT bearer tokens needing to be able to parse or process the JWT bearer token to figure out what it’s good for. Right?

 — Justin

> On Nov 24, 2015, at 12:44 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> 
> 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.
> 
> 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?
> 
> Thanks!
> 
> -- 
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth