Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

"Manger, James" <James.H.Manger@team.telstra.com> Mon, 29 February 2016 02:39 UTC

Return-Path: <James.H.Manger@team.telstra.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 83BEB1B2A57 for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 18:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no
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 2ts45blmBAbp for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 18:39:35 -0800 (PST)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6491B2A50 for <OAuth@ietf.org>; Sun, 28 Feb 2016 18:39:34 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.22,518,1449493200"; d="scan'208,217"; a="62247624"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 29 Feb 2016 13:39:33 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8089"; a="110692505"
Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbvi.tcif.telstra.com.au with ESMTP; 29 Feb 2016 13:39:32 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([fe80::8dc9:173:3b72:6577%23]) with mapi; Mon, 29 Feb 2016 13:39:32 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Brock Allen <brockallen@gmail.com>, 'Justin Richer' <jricher@mit.edu>
Date: Mon, 29 Feb 2016 13:39:31 +1100
Thread-Topic: [OAUTH-WG] HTTP request signing and repeated query/header keys
Thread-Index: AQFXkD4wUaeZYzbNhPIxfaFoz/BUGADRFDTHAaJuhE4B7FuyY6AS/gDAgAAS31A=
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BBCD3D02F@WSMSG3153V.srv.dir.telstra.com>
References: <003b01d1726f$66036590$320a30b0$@gmail.com> <16802C28-5478-41D5-8596-30C617C89016@mit.edu> <005401d17272$070325a0$150970e0$@gmail.com> <844C70FF-8D41-4D4D-8F9D-F1CAC5D69D9E@mit.edu> <006f01d1728e$f52af250$df80d6f0$@gmail.com>
In-Reply-To: <006f01d1728e$f52af250$df80d6f0$@gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BBCD3D02FWSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/nwD48e3C6LCrnchen55zNK5n2Jw>
Cc: "'<oauth@ietf.org>'" <OAuth@ietf.org>
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
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: Mon, 29 Feb 2016 02:39:38 -0000

Being able to selectively include or exclude individual query string name=value parameters in a signature feels far too dangerous. Always sign them all — with the only exception being the signature itself if transmitted as a query string parameter.
Unfortunately we do need to selectively include or exclude HTTP headers as they are a mix of transport, app-layer, end-to-end, and hop-by-hop items.

Ignoring duplicate query parameter names is a poor design for a fairly generic HTTP signing method. My suggestion would be to do a stable sort on parameter names. That is, sort the names, but preserve the order of values when a name appears multiple times. …hoping that works with almost all frameworks.

--
James Manger

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen
Sent: Monday, 29 February 2016 12:17 PM
To: 'Justin Richer' <jricher@mit.edu>
Cc: '<oauth@ietf.org>' <OAuth@ietf.org>
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

Yea, I’m cool with just saying “duplicate keys won’t work” for my implementation, unless I do some implementation specific thing like sort them by value order or some such (but that would have to be on both sides).

-Brock

From: Justin Richer [mailto:jricher@mit.edu]
Sent: Sunday, February 28, 2016 8:13 PM
To: Brock Allen <brockallen@gmail.com<mailto:brockallen@gmail.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>> <OAuth@ietf.org<mailto:OAuth@ietf.org>>
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

Yeah, that’s the trick — you don’t want to end up replicating the entire HTTP message inside the JWS envelope, because then you end up with a SOAP kind of approach where you’re not really using the outside HTTP constructs to their fullest anymore.

In the end, I don’t think this spec is ever going to be perfectly universal, but if it can hit a majority of use cases with a simple and robust solution, I think we’re in good shape.

 — Justin

On Feb 28, 2016, at 1:50 PM, Brock Allen <brockallen@gmail.com<mailto:brockallen@gmail.com>> wrote:

Now that I’m thinking about this, the only thing that comes to mind is a hash of the value included somehow (which I’m sure you’ve already thought of). That’s obviously more complexity and overhead for all scenarios to support this edge case.

-Brock

From: Brock Allen [mailto:brockallen@gmail.com]
Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin Richer' <jricher@mit.edu<mailto:jricher@mit.edu>>
Cc: '<oauth@ietf.org<mailto:oauth@ietf.org>>' <OAuth@ietf.org<mailto:OAuth@ietf.org>>
Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header keys

Ok, missed that – thanks.

For now in my implementation I’m also ignoring this problem :)

-Brock

From: Justin Richer [mailto:jricher@mit.edu]
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen <brockallen@gmail.com<mailto:brockallen@gmail.com>>
Cc: <oauth@ietf.org<mailto:oauth@ietf.org>> <OAuth@ietf.org<mailto:OAuth@ietf.org>>
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

In §7.5 we currently have:


   The behavior of repeated query parameters or repeated HTTP headers is

   undefined by this specification.  If a header or query parameter is

   repeated on either the outgoing request from the client or the

   incoming request to the protected resource, that query parameter or

   header name MUST NOT be covered by the hash and signature. [[ Note to

   the WG: is this something we need to cover? ]]

Which is to say: Yeah, that’s a problem, probably. We either declare this behavior out of scope and say you can’t use this method with that kind of API (or at least those parameters/headers) or we define a mechanism for handling that. I’m in favor of the former, and removing the text from the generation sections that says repeated parameters are processed with no special handling, making them explicitly out of scope throughout.

I would love to see more feedback from the group about this, especially if someone’s got a clever solution.

 — Justin

On Feb 28, 2016, at 1:31 PM, Brock Allen <brockallen@gmail.com<mailto:brockallen@gmail.com>> wrote:

Given that the client can iterate over the query/headers in any order to generate the concatenated value to hash, I think there’s an issue with query string or header values with repeated keys. I’ll stick with query params for simplicity in my sample.

If a client signs this concatenated query: “a=1&a=2” then the “p” value in the signed JSON object could be this:

"p": [["a", "a"], "blah"]

On the resource server, how do you know which key/value pair to put in which order for verification? Also, given that different server implementations express these incoming parameters in different ways, it seems problematic to be consistent.

Thanks.

-Brock

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth