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

"Brock Allen" <brockallen@gmail.com> Sun, 28 February 2016 21:50 UTC

Return-Path: <brockallen@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 4B2321A854C for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 13:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 jDFhgM1IWxnK for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 13:50:46 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 0B0431A871C for <OAuth@ietf.org>; Sun, 28 Feb 2016 13:50:45 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id w128so35009603pfb.2 for <OAuth@ietf.org>; Sun, 28 Feb 2016 13:50:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=OYySqBMf/XJO7f8xpz+o0IOrL2kjO7JIZ3Yg9XWUj4M=; b=xoCykQJ0/q2XlR7MBfp8Y3erJMMpLH81G9PC6MyH2j20xjFu+GOAqOL+j+n1g0HwTC 5q244S7Y9VcdCECOE0N6egVpfc9+Mf7aoN06GA1VclUCWwb0RoAdY2mL1qb1NSPlN1S2 L0CyIgiqIcqKLa4gR+BfvyeqiHUlYzCfpNDmeN3cVEqxly30bMkvoI/9kna6uorSwvPV vmEl5lGZQp85v9Ubo7MdVFwoGffkF60YXBVj//8Y3lDEjaREqP05413+LJDgXnDPtOUl heDjpQ/nxA33aIgC3Cw2f3BINEwo9Igka6ykFhEdXjt9uaZSBp1qMaOg7BqGjZy1TGUO vy/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=OYySqBMf/XJO7f8xpz+o0IOrL2kjO7JIZ3Yg9XWUj4M=; b=RqU0p5tIz2vUDdd5CO389u3S5MS+0Mv40J/sayCn6/B/vFcjzey5snsUn5zXVkSu3B v1BPtEASZ70wocJXvpiOO4u9xOP2PGs7JLX5hqwJYXk3Kh+9wqmqErghzFccJm8EDbgb 7Crw5YfovAG0VmKZybl+sdEbFZzmXCkCN0Q/hhGG2py3WgF8SJWLT6wpbg4DqKivR77A kgiMsbar1NyEZ2qzUV5+MWfWAbQlYOcX2MZ1M518ASka98EcOd0si0tERD9shT0KHE5Y IRhZ8ZIoym4gIr1MJvatH/k3YpidjdyiCDQUJZwyBNzVE1Lqsm+j2uM+TjdVvGHKz2PU zlHQ==
X-Gm-Message-State: AD7BkJLNrQhy8XOr6cgNv7o/EUZLksWd63/F7j6IcI7zbw9cBYTAWk1hD9ObyzKXzIvB1w==
X-Received: by 10.98.34.5 with SMTP id i5mr17699314pfi.160.1456696245336; Sun, 28 Feb 2016 13:50:45 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id xu1sm33101340pab.31.2016.02.28.13.50.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 13:50:44 -0800 (PST)
From: "Brock Allen" <brockallen@gmail.com>
To: "'Justin Richer'" <jricher@mit.edu>
References: <003b01d1726f$66036590$320a30b0$@gmail.com> <16802C28-5478-41D5-8596-30C617C89016@mit.edu>
In-Reply-To:
Date: Sun, 28 Feb 2016 16:50:22 -0500
Message-ID: <005401d17272$070325a0$150970e0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01D17248.1E324DC0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFXkD4wUaeZYzbNhPIxfaFoz/BUGADRFDTHoC835bCAAAHpEA==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/X4mHABae3HUNNNgEyFr71wSkCxQ>
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: Sun, 28 Feb 2016 21:50:48 -0000

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>
Cc: '<oauth@ietf.org>' <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