Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08

John Bradley <ve7jtb@ve7jtb.com> Fri, 18 May 2018 16:20 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BA212D864 for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 09:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
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 T16b6sZ-BzgP for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 09:20:24 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 BFEE212D7F6 for <oauth@ietf.org>; Fri, 18 May 2018 09:20:24 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id v7-v6so3551989pgs.0 for <oauth@ietf.org>; Fri, 18 May 2018 09:20:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=Pn+XuVoIIud0BhSumEbSjN7jATiK0H10AyBqxtv9c2I=; b=rmMToy9DuAV7gPRUOVcu3RHp10CAZzOPQeUzdJybExrnF38AFp5g6BNpbgwQfg9kbr vTIsKqtMYazl0s3w5grHV6Rr31rSlWN/w7+GW3HhUQeHGowLKtZha/F+DQaLRrWy6QMx VOjPtf0Dna2vgFOxmPJ6TPg5209e0n3/kQVojU7ap/LHv4+93AYvBdN6t/Syl2nkHLi9 E1zhvHNTtwm3/Z70EuJLgCpm4jAzbEkBGCXAnGiEQpE5xLvzP+NDLnziVLsHlh4k3G/i 9XhVY3jwOcFVONNZDVXTQuSk2bkhktLWy8s59m61C3X76wMk7rAeGuNM73UOYZ/NCzlJ mGtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=Pn+XuVoIIud0BhSumEbSjN7jATiK0H10AyBqxtv9c2I=; b=MkDPAbyTXIhEjE4S173/YEBrOkTlM6EC05oCAxF0Th2H2tiHjdnBHVazWu3Fsa4Dkz B/sF4qV1uApTa0wqEnm4tZBJLt9Qw4YbXmMDiv4hiqbMUdsYUCSNmfRH3nU/LHcl7i3n e/8jfO6yP2OPJm1Xt5Mx4Kpv4Z7g/MgRGgZEjZLDNHXSk9g6HhlBLYvTi22DjSvfTBNV 7SE+MgEQO5KKGCluHTBxzx5uenH7t1ZeQ+qHz7J1k/ZbEZ2CgDVBJtRLoH6OjF1wlqAo JlHNkGcBW0HhFrOHY9fCXTUA6+LVcwPmnZVyy4ZY9ZwG6nI6TbDqu/DPKbJYoOKc6aBE CCcQ==
X-Gm-Message-State: ALKqPwcaMwC6MX5AOLtbFTwrd27mYhl6l6Mqh1APastXsPB2HviIxHc2 HyZGHC9kQltqE3l9sUbsjOmNYTwd2ZU=
X-Google-Smtp-Source: AB8JxZrEU58h3op6csfKxhBKA/njhmhT7QwaimbVOwsFVrCzUc16ZIpE2RtFHSV3w3tG6BYQUubmLw==
X-Received: by 2002:a63:43c6:: with SMTP id q189-v6mr8238188pga.123.1526660423255; Fri, 18 May 2018 09:20:23 -0700 (PDT)
Received: from MWHPR19MB1085.namprd19.prod.outlook.com ([40.97.141.109]) by smtp.gmail.com with ESMTPSA id i1-v6sm15612310pfi.133.2018.05.18.09.20.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 May 2018 09:20:21 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
To: "oauth@ietf.org" <oauth@ietf.org>, Daniel Fett <daniel.fett@sec.uni-stuttgart.de>
Thread-Topic: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08
Thread-Index: ATNjMGYzEqlKiuPa7h8Olv132yqWfMEXJ2/Z
X-MS-Exchange-MessageSentRepresentingType: 2
Date: Fri, 18 May 2018 16:20:20 +0000
Message-ID: <MWHPR19MB108579B64C94803C25D96CAAFA900@MWHPR19MB1085.namprd19.prod.outlook.com>
References: <e0077693-0c77-fe8e-e603-33dbc38a2b63@sec.uni-stuttgart.de>
In-Reply-To: <e0077693-0c77-fe8e-e603-33dbc38a2b63@sec.uni-stuttgart.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB108579B64C94803C25D96CAAFA900MWHPR19MB1085namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kljn5tsnJ9cIEliyiu3gWaLmmvw>
Subject: Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 18 May 2018 16:20:27 -0000

I am not against having "as" as REQUIRED.

While we are at it should we recommend that rfp be single use?

This draft hangs around as a ID and probably is not read by most people.

We may also want to mention it in security topics if we haven't.

I need to update this in the next couple of weeks to keep it from expiring anyway.

John B.

From: Daniel Fett
Sent: Friday, May 18, 3:46 PM
Subject: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08
To: oauth@ietf.org


Hi all,
Looking at draft-bradley-oauth-jwt-encoded-state-08, I see in Section 2 (https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-08#section-2) that all contents of the JWT that would bind the specific state value to the AS are optional. This means that the following attack is possible (we described this attack in our OAuth paper [0], Section 5.1, albeit very briefly):
Precondition: A client that supports multiple AS (with one being an attacker-controlled AS, let's call it A-AS).
1. An honest user tries to authorize using A-AS, the attacker receives the value of "state" which is bound to the honest user's session with the client.
2. A-AS aborts the authorization (e.g., by redirecting the user back to the client's web site without any parameters).
3. The user starts a new authorization flow with an honest AS (H-AS).
Since the state JWT is not bound to the AS selected by the user, the state value generated in (1.) will likely be valid for the login flow started in (3.). The attacker therefore knows a valid state value and can mount a CSRF attack (which was supposed to be prevented by using state).
Solution: Always bind state to the chosen AS, i.e., make the "as" part of the JWT mandatory
-or- use some other mechanism on the client (if the client is stateful) to invalidate the old state value.

If we agree that this is problematic, I think this should be changed in draft-bradley-oauth-jwt-encoded-state and should at least briefly be discussed in the security topics document (I will be happy to write a section for the latter).
- Daniel
[0] https://sec.uni-stuttgart.de/_media/publications/FettKuestersSchmitz-TR-OAuth-2016.pdf
-- SEC - Institute of Information Security University of Stuttgart Phone +49 711 685 88468 Universitätsstraße 38 - 70569 Stuttgart - Room 2.434