Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt
Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 10 June 2018 16:33 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 2C76C130E81 for <oauth@ietfa.amsl.com>; Sun, 10 Jun 2018 09:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.221
X-Spam-Level:
X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 rsqKQubD8Vrw for <oauth@ietfa.amsl.com>; Sun, 10 Jun 2018 09:33:51 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AD0130E7C for <oauth@ietf.org>; Sun, 10 Jun 2018 09:33:51 -0700 (PDT)
Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1fS3Hm-0000NG-UO; Sun, 10 Jun 2018 18:33:46 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <8A4E5C43-8A7D-4219-B92C-993BB4F042AB@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_8D4994E1-A1DA-4D4C-AD83-A18EE5AA54BA"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Sun, 10 Jun 2018 18:33:44 +0200
In-Reply-To: <CADFnxGeyFvWinDqq8R6-e8Y+LvxCvcbL+pAWt+xTkUKy2PbXkw@mail.gmail.com>
Cc: oauth@ietf.org
To: Johan Peeters <yo@johanpeeters.com>
References: <CADFnxGeyFvWinDqq8R6-e8Y+LvxCvcbL+pAWt+xTkUKy2PbXkw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AzVKkTug5fvWte039X21avsc-f4>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
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, 10 Jun 2018 16:33:54 -0000
Hi Johan, thanks for your proposal. I’m not sure whether it should go to 3.7.1.4. The reason audience restriction turns up as a subsection of 3.7 is our document is organized by attacks instead of security controls. I could image to add a section on audience/action restriction as sub section of 2. What is the mean reason for restricting access tokens to certain actions? Is it about least privileges? Is it to limit the impact of a token leakage/replay? ... best regards, Torsten. > Am 07.04.2018 um 19:11 schrieb Johan Peeters <yo@johanpeeters.com>: > > Thanks for doing this great work, Torsten. As discussed in a private > email conversation, I think an access token should not only be > explicit about which resource server is the intended consumer > (audience), but also which actions are permitted on the targeted > resources: > > =========3.7.1.4. Action Restricted Access Tokens========= > > An action restriction restricts the action a > particular access token can be used for. The authorization server > associates the access token with a certain action and every > resource server is obliged to verify for every request, whether the > access token sent with that request was meant to be used for that > particular action. If not, the resource server must refuse > to serve the respective request. Action > restrictions limit the impact of a token leakage and prevent a > malicious client to use the token for unintended actions. > > The action attribute in can be expressed as the HTTP verb used to > make the request. > > The client needs to tell the authorization server, for which actions it > will use the access token it is requesting. It should encode > the information in the scope value. > > Action restrictions are essential both to enforce scope > restrictions as established through user dialog and policy decisions > by the authorization server. > > ========================== > > Yo > -- > Johan Peeters > https://www.johanpeeters.com
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Torsten Lodderstedt
- [OAUTH-WG] I-D Action: draft-ietf-oauth-security-… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Joseph Heenan
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Travis Spencer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Jim Manico
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Travis Spencer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Justin Richer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Travis Spencer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Daniel Fett