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

"Brock Allen" <brockallen@gmail.com> Sun, 28 February 2016 21:31 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 2DE3B1B2C6E for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 13:31:59 -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 g_3L3jMKi5O4 for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 13:31:57 -0800 (PST)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 4A6B51B2B8C for <OAuth@ietf.org>; Sun, 28 Feb 2016 13:31:57 -0800 (PST)
Received: by mail-pa0-x235.google.com with SMTP id fl4so80149863pad.0 for <OAuth@ietf.org>; Sun, 28 Feb 2016 13:31:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=wdaeUNMYKMw+6Ul2sBIzsUjIwJww6ZDsCB+qclGHnlQ=; b=ZPl0qLCZ1ZXiA/etB8CiW7dMw72E7LuIbkxPR+Z7xsLdG1LJVqIVdxu1F+s+mOv2R3 cNU7F6PgwucKz0KhWGvDRRUXBfUDXwz8w2rYJ23k57f2fzVZAH5GfyN/fHnVlyr9QQhS JolxbtJnEyJcNi1nrbTvV3QJudauiybHBB0FuxZ2jSXhagr1B+OuByh0esvXdDz7K+so 7iPVdBrjMQHtFGQKLH7DWy8a4WcmFn6D/pBZi3Yu461ue0xJBC8zvnpReHnIsl8AfRdd SnTLI+V32mUOKlBTRa4s6mu2xSybubfHE6u6LvTnCxSyDtfp/NRJg6XqCH+Er7qb4vLf 6L3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=wdaeUNMYKMw+6Ul2sBIzsUjIwJww6ZDsCB+qclGHnlQ=; b=XYY1CaLDiLbn5j4ZZLp4rNkQDMw0AFa7sGp2xHne+xkkaA3Xvm9PofjVO38K8Mfnw/ BbAzDd6fdRtNA3z39gQUD8uz+7SFOCIwKTRQDacGZzwMgFTabbNuN7pf+0fzpDv0iCPl 86j1xlqb33n2t7b/Oc5vR+vLckKImiEHy5XFOLJVBWyvBfEQVfFoBdDiNiUPI+OCyrtX llDu/CzAO4SmmrX++YKcDOYKvdTYfjPa4s9oCr7WpV1s90H+6ANLU38R7jyy8dGoNRFb DlIV/yhzf2MrvGNGw+1xkOW7XGMsdgCTSdbYhc4kiRkLN/F4f8maHO6k1OW73DhKkYAm qP6Q==
X-Gm-Message-State: AD7BkJI3KGhIE57m30FKmWMeUduu5iXjru00YEendS32s/sqG7vz1jV9gTQSUvx7biFtYA==
X-Received: by 10.66.234.104 with SMTP id ud8mr17754601pac.143.1456695116911; Sun, 28 Feb 2016 13:31:56 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id v3sm2386158par.17.2016.02.28.13.31.54 for <OAuth@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 13:31:55 -0800 (PST)
From: "Brock Allen" <brockallen@gmail.com>
To: <OAuth@ietf.org>
Date: Sun, 28 Feb 2016 16:31:33 -0500
Message-ID: <003b01d1726f$66036590$320a30b0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01D17245.7D2FA780"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdFyb0yKpLxOPzSXQhyhHtvnfR8zww==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/tdRVSnUxuPiCnxPyA67RjHpcm88>
Subject: [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:31:59 -0000

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