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

Hans Zandbelt <hans.zandbelt@zmartzone.eu> Mon, 11 November 2019 09:57 UTC

Return-Path: <hans.zandbelt@zmartzone.eu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 51BB912080F for <oauth@ietfa.amsl.com>; Mon, 11 Nov 2019 01:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2qKRGB0ErNOK for <oauth@ietfa.amsl.com>; Mon, 11 Nov 2019 01:57:50 -0800 (PST)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 291B4120152 for <oauth@ietf.org>; Mon, 11 Nov 2019 01:57:49 -0800 (PST)
Received: by mail-qk1-x729.google.com with SMTP id e187so10647752qkf.4 for <oauth@ietf.org>; Mon, 11 Nov 2019 01:57:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vI3DlaUymBlaJ0dNRHlWd4qdyc3tEo1ilJN0HUU4CDU=; b=I4F8isvR2UKY0xn3GqgRLEBNNXrB/nMHmiq5AFfNtGJ8krhocyqsNkHRUTWkODCNnE Yjx81v4OWppDQT82RlB1DqUPB4Zt+pb0S9E2w2aaYJD8pqsYqI/zQeRmzcEtW10ynZsS CuSIdNaMReamrWHDo2uVNEEQWIBnjakJbqdLiEqhWp8IQ74/q2SuAojPeNDsK8ny+Hv2 wZmDD3+d1mRq80uk4+mR8nJ9GJ3uCrawE6HhOnqTuKa6yK1zRywe35YmbJc+jQqtaXgG O85lRFPH3OuGh/Ar7l5ZpCaK1gTvM9Slb3WV+CPoi67zKBtS0fdjh5NzR+YXse2cmtfS H6Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vI3DlaUymBlaJ0dNRHlWd4qdyc3tEo1ilJN0HUU4CDU=; b=RRfDny9SIOcIZ+S9buHXqqHKZbTwvWyXHX9nkna3mgWJgX11cT/Ng90P6+JINvGf5v FTOh9Hv6XVkExMaDM1rYCK2UePhsTFGH979uygypmBZMF0ZltENM56venJWuXRrtbFSz 0o9QYF3y58IIrel8HSH4AAqrb/hqI1qOj2kRJPulrI8NddL08mnxU+3Vy2ODhXcxoo9e XlBDhMBpNGTLZC9G4RAHwfbUD2ISOeBiQCw4IuWs4L/DIvkLZrq2S9/rTXPa6Zg85MYS zz8Qe3Cb2C+Mb4t224wMGRLIetqkShjDIRTYVILs8dnOpc7RDZctPsbmn3m11RC67MYb zLJA==
X-Gm-Message-State: APjAAAV4ppmHBboQAEVQGD/gKqh6qdyIDfcXf3itfXuE1/6+gi3AEJnd bVNF3JycRFclhL+xiWfvGdP1c0JDf/bE1DCLJsAkkYgW
X-Google-Smtp-Source: APXvYqzGi3b9Jq877KWuIjVJcGrO9Nn2R+ZgqZvHrW3XkCHh4zgTd2hGGdQhM8CEM5D1bCwpgY526pq7bvwr1lDIT1g=
X-Received: by 2002:a37:84a:: with SMTP id 71mr9301083qki.423.1573466268369; Mon, 11 Nov 2019 01:57:48 -0800 (PST)
MIME-Version: 1.0
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Date: Mon, 11 Nov 2019 10:57:37 +0100
Message-ID: <CA+iA6ujhZub-_Ys-owBDRvueRWuSaotQRqa=o8w0sy7afEzvFw@mail.gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fe161d05970f2939"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gXN1zfxQPIHyMYsrDLkzU4BFYVw>
Subject: [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: Mon, 11 Nov 2019 09:57:53 -0000


Please find my feedback on page 11-20 below.


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.

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?

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

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

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.

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.

ZmartZone IAM - www.zmartzone.eu