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

Hans Zandbelt <hans.zandbelt@zmartzone.eu> Wed, 06 November 2019 09:46 UTC

Return-Path: <hans.zandbelt@zmartzone.eu>
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 2B6D112022E for <oauth@ietfa.amsl.com>; Wed, 6 Nov 2019 01:46:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXljz-baX5Cx for <oauth@ietfa.amsl.com>; Wed, 6 Nov 2019 01:46:43 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 A1CD61201AA for <oauth@ietf.org>; Wed, 6 Nov 2019 01:46:43 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id t8so33066122qtc.6 for <oauth@ietf.org>; Wed, 06 Nov 2019 01:46:43 -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=j38qzI2pB77D/H0ggXftDZUbpbpTD+8TV+FA9iQz4pM=; b=zVr6RwEOtwk3Zpt2qXnPfiB5rVHqalMLNOoLYwQkJqIXW3N5YUq1c25IElLXgZrsPc O296JNC1xVUOF+MugZ6g9NALTs5sgPdcrA9QsqyIrI/hyA/jAel+NKXrB9AfO9Rz6bYO NqBbNkyMTNKAsqsX7gsRWjaeuZxWhrprJEXMqpyo+KqCOJiPnxCYXhKq0CDjy63Jl7Wz hl3xbMxUeu8nnAacjfEN6vOr56jEwSvmvcQwrNDd4E7qTwZDqytHGce1LsD6hyb+CIb7 RzxrNFb2s3YXl9rgv40VU1VKGlo/HkMPMRX3NIK8/SO2SNTZQcAjd4CgeGr43z1jJbkZ wR6w==
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=j38qzI2pB77D/H0ggXftDZUbpbpTD+8TV+FA9iQz4pM=; b=ZDplgFHKMYQ+RekODvE0HXfRLZHhSijmk4OsiahiZhwFnICq5wHZ0RTLQe5RO7D4+3 U2Mg9RNlrQvypef44EbPUhRAw5tzC9W3htvseIdXEqLXQVNeFeO7K+GYhsA2nl+1/svg bs7RuJtkBpeJ1E/6d2aEUmipZ/4t5F3xNbmqhD3SjLiFKU9pLkK0+9j3ok/gmgDu/SQy QdixKCBE5hV806RNAHlCbQVKTZOnc/mDwQ9+XH6v/KRhYSGJYaJ0Mwz4Ek7oLBciUojY 62KHTZoquXKY84zvFiwJ4z0QstaHTUc5AGK4nv0ywi1n9UA5xT5ianExrXMpHMNBNrSr DqBg==
X-Gm-Message-State: APjAAAUFkhJjVYN0cv19lp4rVzrcVMRXwrsp2uLu8kxFf3VBoUf7tt5X kDBEnmf54DZyHaVq7SVd1xk0fSbMWazM8MNmCAOeuTl0WNUP9g==
X-Google-Smtp-Source: APXvYqwbhzNzsnCuARN2qOkBxTvRifa6GN/xOue1KaIXns1rbaS8xguI2oIQG5/SZWjVtI2FC4Gc1DUNM8vtrdAXz0Y=
X-Received: by 2002:ac8:758e:: with SMTP id s14mr1507128qtq.288.1573033602030; Wed, 06 Nov 2019 01:46:42 -0800 (PST)
MIME-Version: 1.0
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Date: Wed, 6 Nov 2019 09:46:31 +0000
Message-ID: <CA+iA6uh_aToo8hquZAwbAO6M3AMHf6BUnAYo3pf2qYMiP4zqtg@mail.gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011b1a70596aa6dfc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Qa4PumpJyExiaDQmMPZ5inuGOvc>
Subject: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [1/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: Wed, 06 Nov 2019 09:46:46 -0000

Hi,

Please find my feedback on the first 10 pages below.

Hans.

Overall:
- grammar in the first sections: there's a lot of comma-separated sentences
that could/should be reworked by a native speaker
- perhaps readers guidance pointing developers straight to section 3. as
Torsten said on the call would be useful
- as also discussed on the call, perhaps it would be good to spell out how
this BCP relates to the original OAuth 2.0 security considerations in the
RFC(s)

P3 1. Introduction
Usage of OAuth vs. OAuth 2.0 across the document: perhaps explain that in
the remainder OAuth refers to OAuth 2.0.

First bullet:
- CSRF and referrer header are being mentioned without explaining the
abbreviation, context or reference. And btw, it is the “referer” header…
- “defense in depth” -> “in depth defense” ?
Third bullet:
- I believe those higher security use cases were considered from the start,
but they were not acted upon before (e.g. MAC spec was left abandoned).

P4 first paragraph, in the middle:
“This way the same..” -> “In this way the same…”
“serves as a frontend…” -> “serve as a frontend…”
“in a multi-tenancy.” -> “in multi-tenant environment.”

In general there are a lot of sentences broken up by comma’s that could be
rearranged and do without the comma’s.

1.1 the whole section is comprised of comma-split sentences that could be
re-arranged.

2.
In general: shouldn’t the OAuth 2.0 terms be capitalized everywhere e.g.
resource owner -> Resource Owner
authorization server -> Authorization Server
Etc. ?

- “was laid out that described…” -> “was laid out that describes…”
- “at an authorization server (AS)…” -> “at the authorization server (AS)…”

P5:
A1:
- first sentence ends the list with “etc.” but I don’t feel an enumeration
of attacks can be left up to the reader to complete.
- “be achieved through many ways” -> “be achieved in many ways”

A3 and A4 could very conveniently be bundled together, isn’t it, by
specifying “read but not write the authorization request and/or response”.

P6: 2.
The last paragraph of 2. is hand-wavy, almost scaring the implementor but
not giving him the guidance to act properly. I’m not sure this helps,
especially the usage of MUST will make implementers feel uncomfortable
because it does not tell them exactly what they MUST do. Something like “an
implementer SHOULD always consider other attack vectors specific to their
environment” may work better?

3.1
End of first paragraph “It also helps to detect mix-up attacks.” lacks an
explanation or a reference to a section where this is explained. As a
matter of fact I don’t immediately get why this would help to mitigate
mix-up attacks.

P7:
2nd paragraph: I don’t think [I-D.bradley-oauth-jwt-encoded-state] is going
anywhere and – even as a co-author - I’m not sure the reference should be
included here.

Last paragraph of 3.1:
“AS which redirect a request…” -> “ASes which redirect a request…” or “An
AS that redirects a request…”

P8:
3rd paragraph: I guess it was discussed in length but I would like to see
“clients SHOULD NOT use the implicit grant” change into “clients MUST NOT
use the implicit grant”, as done for ROPC further down. This is a security
BCP and implementers complying with it must really not support Implicit any
longer IMHO. It is still an option for implementers to not follow this BCP
and “just” do OAuth 2.0… or implement sender constrained tokens. The SHOULD
gives people a way out and an excuse that we should no longer allow.

P9:
3.3 missing text about not using access tokens for user authentication
(again?) plus reference to oauth.net/articles/authentication, A thing I
still often see in deployments and still a source of confusion for
developers and deployers

-- 
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu