Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

Brian Campbell <bcampbell@pingidentity.com> Thu, 05 September 2019 18:43 UTC

Return-Path: <bcampbell@pingidentity.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 606A412090D for <oauth@ietfa.amsl.com>; Thu, 5 Sep 2019 11:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=pingidentity.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 8Jfjfyru_JPU for <oauth@ietfa.amsl.com>; Thu, 5 Sep 2019 11:43:47 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 D601612011A for <oauth@ietf.org>; Thu, 5 Sep 2019 11:43:46 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id b136so7113508iof.3 for <oauth@ietf.org>; Thu, 05 Sep 2019 11:43:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pHkxI+GwqpYT2PzbsB2qjqESFZCNiX8wprIHxUUXNPU=; b=IAc/OxT5unckV0PNQETcggECohje2MpQpNYITwxfLvKVHvFc0NaTa2zXGzePqckALn Qugx0YTw+p2nfX9kMGGBTLIdtyc63MKKjAzKRVMYaJ/w6jAP7Ui3tIPDCGneMc2QouAF i6NlOnraIlun3wwWeVCyL5zuNyLNKh/eZPOZo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pHkxI+GwqpYT2PzbsB2qjqESFZCNiX8wprIHxUUXNPU=; b=UflTiZEDS0kXh8k6ESv5RbI5fRPOe+ILGxov2ecW0yWfkSRId3FpATbegNLZqYYcti XlsmLpN9VgfrO46zczACGUuQqofdg3ycljhOx9MfgGRUkGYTPkfw/Bp+uo9UUD80Bon0 H2FELtoeXfM6r9aiHMv38qmsOFjp7ZDBuiXZ8+6L+ChrKrhBQxbC/hOUGMfnIbFKOE6H z/jVo/9cLl9qcOzIoL4bRhmScIy0jaJd4p9oxmm/OsHuPL9SfowWuQYWda8Kyxkofja5 ero+xiLl4ddNprKBLGIbuDGigfNmC14hFJENYAoQ5L4huacXj0nyuRZ2wCvcjyYp9Fqk LsrA==
X-Gm-Message-State: APjAAAUm8HzQt4zxzLc0EmIxEaQW9EqI5PwlX+Q1Zkf4gx+GNbKcyBG1 cW7BOaMADsRwxsjusjhpuM+eAVNwBd4LGQjBjxyygsobeCLkcflECafRhQtoeAhQWIQOqa+HFmF UBzj4yGSaDBNNlA==
X-Google-Smtp-Source: APXvYqycpXHT9N7eCaM76zxKH4g3vbGGaXtQNJsMppp+bwe/QtGK8OJ9N693jBK9Tv7RQfpjnuObpXUpwyq2uCwFA40=
X-Received: by 2002:a6b:b494:: with SMTP id d142mr2139293iof.156.1567709026089; Thu, 05 Sep 2019 11:43:46 -0700 (PDT)
MIME-Version: 1.0
References: <156763159047.22689.9306520600745069059.idtracker@ietfa.amsl.com> <CA+k3eCTu91h3X7BjJgjQ6QQU1oWXnRPM3X0EjRbi6ri=a5tSew@mail.gmail.com> <20190904235531.GE78802@kduck.mit.edu> <CA+k3eCQ0bShTn4cbzeP7hs-g+wbfP6JzUsA=xmtjyhaehmAL0Q@mail.gmail.com> <20190905175320.GL78802@kduck.mit.edu>
In-Reply-To: <20190905175320.GL78802@kduck.mit.edu>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 5 Sep 2019 12:43:19 -0600
Message-ID: <CA+k3eCR9x0wHYOfN0qOC0YNMPzJJjC4Ve2ELDEeKi6OKhAEXnA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-oauth-resource-indicators@ietf.org, oauth <oauth@ietf.org>, oauth-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009c989a0591d2b38c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gUtPjSv8Burwaga3O48zdGpuJIY>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
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: Thu, 05 Sep 2019 18:43:49 -0000

thanks and done

On Thu, Sep 5, 2019 at 11:53 AM Benjamin Kaduk <kaduk@mit.edu>; wrote:

> On Wed, Sep 04, 2019 at 06:17:32PM -0600, Brian Campbell wrote:
> > On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk <kaduk@mit.edu>; wrote:
> >
> > > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote:
> > > > Thanks Ben, for the review and non-objectional ballot.
> > > >
> > > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker <
> > > > noreply@ietf.org>; wrote:
> > > >
> > > > > Benjamin Kaduk has entered the following ballot position for
> > > > > draft-ietf-oauth-resource-indicators-05: No Objection
> > > > >
> > > > > Section 3
> > > > >
> > > > >    An access token that is audience restricted to a protected
> resource
> > > > >    that obtains that token legitimately cannot be used to access
> > > > >    resources on behalf of the resource owner at other protected
> > > > >    resources.  The "resource" parameter enables a client to
> indicate
> > > the
> > > > >
> > > > > nit: This sentence has a pretty strange construction.  I think the
> > > > > intent is to say that that a token, legitimately presented to a
> > > > > resource, cannot then be taken by that resource server and
> > > > > illegitimately present it somewhere else for access to other
> resources.
> > > > > But with the current wording we seem to be missing part of the part
> > > > > where some entity obtains the token with intent for illegitimate
> > > access.
> > > > >
> > > >
> > > > Yes, despite the pretty strange construction, you have the correct
> > > intent.
> > > > I'll work on improving that sentence (borrowing heavily from your
> words
> > > > there).
> > > >
> > > >
> > > >
> > > > >    Some servers may host user content or be multi-tenant.  In
> order to
> > > > >    avoid attacks that might confuse a client into sending an access
> > > > >    token to a resource that is user controlled or is owned by a
> > > > >    different tenant, it is important to use a specific resource URI
> > > > >    including a path component.  This will cause any access token
> issued
> > > > >    for accessing the user controlled resource to have an invalid
> > > > >    audience if replayed against the legitimate resource API.
> > > > >
> > > > > I'm not entirely sure what this is trying to say.  What is the
> > > > > "legitimate resource API"?  Why would a token be issued for
> accessing a
> > > > > user-controlled resource if that's something we're trying to avoid
> > > > > having confused clients access?
> > > > >
> > > >
> > > > Um... so on rereading that I might say that it's also "pretty
> strange".
> > > >
> > > > What it was trying to somehow say is similar to the previous nit
> about
> > > > audience-restricted not being usable at the resource for whom the
> weren't
> > > > intended. But saying so in the context of a multi-tenant environment.
> > > > Basically it's trying to say that, in a multi-tenant environment, the
> > > > resource URI and subsequent token audience need to have something
> that
> > > > identifies the tenant so as to prevent the token from being used by
> one
> > > > tenant to illegitimately access resources at a different tenant. I'll
> > > work
> > > > on trying to improve that text to better explain all that.
> > >
> > > Ah, yes, that's a very good point to make.  I'm happy to look at some
> draft
> > > text if you want.
> > >
> >
> > Thanks, here's what I've got now for this and the previous item in sec 3.
> > Suggestions welcome.
> >
> > 3.  Security Considerations
> >
> >    An audience-restricted access token, legitimately presented to a
> >    resource, cannot then be taken by that resource to present it
> >    elsewhere for illegitimate access to other resources.  The "resource"
>
> I think "by that resource and presented elsewhere" probbaly has a more
> parallel flow.
>
> >    parameter enables a client to indicate the protected resources where
> >    the requested access token will be used, which in turn enables the
> >    authorization server to apply the appropriate audience restrictions
> >    to the token.
> >
> >    Some servers may host user content or be multi-tenant.  In order to
> >    avoid attacks where one tenant uses an access token to illegitimately
> >    access resources owned by a different tenant, it is important to use
> >    a specific resource URI including any portion of the URI that
> >    identifies the tenant, such as a path component.  This will allow
> >    access tokens to be audience-restricted in a way that identifies the
> >    tenant and prevent their use, due to an invalid audience, at
> >    resources owned by a different tenant.
>
> But other than the above nit, this all looks really good; thank you!
>
> -Ben
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._