Re: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [2/3]

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 19 November 2019 06:34 UTC

Return-Path: <torsten@lodderstedt.net>
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 9F369120875 for <oauth@ietfa.amsl.com>; Mon, 18 Nov 2019 22:34:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 J9HJ8pNc4L3p for <oauth@ietfa.amsl.com>; Mon, 18 Nov 2019 22:34:49 -0800 (PST)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 8B67D120873 for <oauth@ietf.org>; Mon, 18 Nov 2019 22:34:49 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id c13so11649279pfp.5 for <oauth@ietf.org>; Mon, 18 Nov 2019 22:34:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=a3yjV1eELbCPeWrjfN4qw6XYGp6oiFYQN6pdNSzzKA4=; b=GJoKn31GIThCCnVnI3oP8PGAcUEWYLya0atX9m06d7gqN14h106EFu/YzBLqgKzRMH APIfByttWD6Xm4UTUg6TZ425OIJ5n8ptYFNCEt2tLfGxQ64nXREjHh+IKn1nVqOsd3vL kHAvp6bkVU5nNKSIBq/0874H3F/c7+mRhtqqzv5aqo7XRTe6DZTk51jAfFNuePriInNb ZblY9hfhAvHrbwGljUsZpM7kIRFLQ0Dr4G+y0HBfb64hkLi9ibFXXe6ZVEwccXq31MPY +9DWNURwHUDafrTHKTMCHL/CI/l/zVkZ5NQqu83d8t4C09Jg3mhfISIofxkE7ALEq+IH BCzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=a3yjV1eELbCPeWrjfN4qw6XYGp6oiFYQN6pdNSzzKA4=; b=IBrYwZm3BR5z+rioZS8xEX07DAMpyRP6TBmkWhYDIfcjPSYRyC9ouY8sIvUGL+11zk 5daZow5mtrlQqBd18S34ZAXKz9YGzo39IH/dsbsEYdpoKv5FUMd3f5nOdn3xJdSgHWz7 pN+TmRP/xpGyCeQyecBNwzmoAyUfNAyb47VJIxivGIKgh2Aods8KsDKBH+iRgLKIesc0 ZTXXgemiFmU5SiXXKKGrLQvUlvC5ZPdd6AcApQ53bfFvtpSyGomZzYc2wDS7cDh3sBFP wPtO/JVPFYqgib/w3YH7kLmON8J93eMWehna3L9wzAIHQaoX/x+KTe36BeSgekCKuUJh /wiQ==
X-Gm-Message-State: APjAAAXbCY99chM2CF3W3VpJ+rRlPw4j0p6ziGylhlqbjRcV9nP6LxON MW4iVK2rWnrn29O2IsVFJUNVdA==
X-Google-Smtp-Source: APXvYqw20MJfiWDCbG2j/6kxO+BCG04xFr+b/spL+XO7IupjllsjdVQd5xa4TM/QGiTGiYUDShcZaQ==
X-Received: by 2002:a63:c603:: with SMTP id w3mr3644539pgg.151.1574145288585; Mon, 18 Nov 2019 22:34:48 -0800 (PST)
Received: from [192.168.20.19] ([118.200.165.182]) by smtp.gmail.com with ESMTPSA id x13sm24021415pfc.46.2019.11.18.22.34.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 22:34:47 -0800 (PST)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <6CA04551-9F9A-408C-8108-E3644DD2B110@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_6D1DA2A5-E0E6-4C31-9C03-8FC86EDD9ECE"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Tue, 19 Nov 2019 14:34:40 +0800
In-Reply-To: <CA+iA6ujhZub-_Ys-owBDRvueRWuSaotQRqa=o8w0sy7afEzvFw@mail.gmail.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>, Daniel Fett <fett@danielfett.de>
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
References: <CA+iA6ujhZub-_Ys-owBDRvueRWuSaotQRqa=o8w0sy7afEzvFw@mail.gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0XVEKKts9WdQtIjGsGhrgO7Aey8>
Subject: Re: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [2/3]
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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, 19 Nov 2019 06:34:55 -0000

Hi Hans, 

> On 11. Nov 2019, at 17:57, Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
> 
> Hi,
> 
> Please find my feedback on page 11-20 below.
> 
> Hans.
> 
> P14
> 4.2.4 For an RP there should be more explicit text and guidance about having a single dedicated immutatable redirect URI per client that "demultiplexes" access to the protected resource by storing the original location that the user agent was trying to access in the state associated with the authorization request.
> 

Anything different from the guidance given in 3.1?

> P15
> same section 4.2.4, 2nd paragraph: if I'm correct the text about authorization codes being single use only and revoke access tokens on 2nd use is not different from the original RFC is it? If so, why repeat here?

To provide a complete list of measures and to remind the reader of what is already stated in RFC 6749.

The alternative would be to state something like, "beyond the measures given in RFC 6749, the following additional measures further reduce the chances of a successful
   attack:"

> 
> 3rd paragraph: why not a MUST for invalidating state (and randomizing it for that matter) but only a SHOULD?

Because this is a discussion of options not the normative recommendation. Beside this, invalidating state introduces more state at the client, which might cause scalability problems.  

> 
> P16
> 4.3.2 the "postmessage communication" is mentioned here without any context or explanation; I guess this refers to the OIDC session management spec somehow?

It refers to a (non-existing) postMessage-based protocol to pass the code to the RP.

We adopted the second measure with our recommendation towards code&PKCE.

> 
> 4..4 Mixup: I would like to emphasize here that the mixup attack works perfectly fine against two statically configured OPs, to avoid the impression that it is somehow applicable in dynamic scenarios only. 

Changed it 

"Mix-up is an attack on scenarios where an OAuth client interacts with
multiple authorization servers, as is usually the case when dynamic
registration is used or if the client is statically configured to interact with multiple authorization servers."

> 
> P17
> About the description of the mixup attack: as long as the attacker is able to trigger a request (by having the user click a link) and read the query/POST parameters on the A-AS (perhaps from the logs) he can execute a mixup attack by starting from the A-AS rather than the H-AS (as demonstrated in the OAuth 2.0 security workshop in Darmstadt December 2016). Perhaps this can be made more explicit.

I will ask Daniel to take a look into this.

best,
Torsten. 

> 
> -- 
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth