Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)
Eve Maler <eve@xmlgrrl.com> Fri, 19 July 2019 00:11 UTC
Return-Path: <eve@xmlgrrl.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 EB0FB12011D for <oauth@ietfa.amsl.com>; Thu, 18 Jul 2019 17:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Level:
X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=xmlgrrl-com.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 AkAx_6Vtrwy6 for <oauth@ietfa.amsl.com>; Thu, 18 Jul 2019 17:11:23 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 799AC12011A for <oauth@ietf.org>; Thu, 18 Jul 2019 17:11:21 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id z23so2640278ote.13 for <oauth@ietf.org>; Thu, 18 Jul 2019 17:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xmlgrrl-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CQnPU8twK07nX4SQk7KlHQgf2XzwRpQZbjsXwKev/IY=; b=oTeLuGsZV7qyGT144RxAIC5dvvFLoDtwUXK6Y5dLHDRzQpBYfUeXx8HChjZOPh8uom wCKwyR0qG9qntVM44xrT8U11kc4lTraMMVQwTQDvLZkRhXELGN3i0kfFNp62r8qGha1y D8z+qEulmPOcbA0KKT4YmSjkLf/1uOqfrig6tFhv34pZRqewUJXaRTCZbuayvpRPTOx4 3UU6kqcqfwuFGSs8g8J48NT/MUpacbWd2jxmYGgJ+f+puv4RW26x7FywoJYUH8BiN/v9 AxC6I44CSCBZa4pbMTD4I9FeUfKNU8WzHGm6NVtPTPhNgyD8ipVq6tXtIfl2aykll271 M/hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CQnPU8twK07nX4SQk7KlHQgf2XzwRpQZbjsXwKev/IY=; b=bSrXwXnlg4hdoDbDqHWa+8zqvu5+TyNILGm+kPMUkg13WqzMUGvYhS0l1fzKmPW00U nlUD6hgQ1ic0f++6Ury7aljOacCq+Sa8i/UQfJMuBtvzIpNa9YybjNwMwwgbVamK+QYB r+7LWZVerOj2NNhH/43dv6phYCaWr/4LpNUwcb8wyk4hLcMvpCB2UYmvcSBd8Iay85Ym ht0qbKAeZBNieetl6uZOW7uCqKGbRyjPNytJ6kDR1Bpux1frPv8x9YeqbPkXRPc2ZPrh GdfmtW/hZxAYLTC5S2oZLoqCCS6+cHhOUSQ8Ps3qYiG2jUALG9584pNPc5gohos6K+Bs OZ3w==
X-Gm-Message-State: APjAAAWJYqWWA8z0oQWR1D4485PoAtRmF18OdrdBhbJDRophghRh2cD/ INVM5AU4bQkMuSw5IlnEbwk=
X-Google-Smtp-Source: APXvYqz0YMwZ7VgA+WUyuOmLsZGF7t7Mw83ykcrqnpfpwPJX4xwi3te7lBoUGNIoM5LkbEID+902Cw==
X-Received: by 2002:a05:6830:164e:: with SMTP id h14mr19953617otr.186.1563495080762; Thu, 18 Jul 2019 17:11:20 -0700 (PDT)
Received: from [192.168.168.118] ([47.188.75.171]) by smtp.gmail.com with ESMTPSA id k24sm8991616oic.29.2019.07.18.17.11.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 17:11:20 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-046D78E1-C507-4A0E-9A54-B70FDA67FA2D"
Mime-Version: 1.0 (1.0)
From: Eve Maler <eve@xmlgrrl.com>
X-Mailer: iPad Mail (16F203)
In-Reply-To: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com>
Date: Thu, 18 Jul 2019 19:11:19 -0500
Cc: The IESG <iesg@ietf.org>, oauth@ietf.org, draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <AFBDD61D-4188-42ED-A3B1-77D70F914EDB@xmlgrrl.com>
References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com>
To: Barry Leiba <barryleiba@computer.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Uv76THptrJLwNNCIwoO8QHTH6Lg>
Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (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: Fri, 19 Jul 2019 00:11:26 -0000
Regarding your “higher importance” comment on Section 1.1 about the impersonation semantic below: Eve Maler (sent from my iPad) | cell +1 425 345 6756 > On Jul 18, 2019, at 4:06 PM, Barry Leiba via Datatracker <noreply@ietf.org> wrote: > > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-token-exchange-18: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have comments below, a couple of which might have been DISCUSS except that > there have been enough eyes on this and enough DISCUSSes already, and I trust > the authors and responsible AD to do the right thing. So I’ve divided the > comments between “higher importance” and “purely editorial”. > > Of higher importance: > > — Section 1.1 — > Given the extensive discussion of impersonation here, what strikes me as > missing is pointing out that impersonation here is still controlled, that “A is > B” but only to the extent that’s allowed by the token. First, it might be > limited by number of instances (one transaction only), by time of day (only for > 10 minutes), and by scope (in regard to B’s address book, but not B’s email). > Second, there is accountability: audit information still shows that the token > authorized acting as B. Is that not worth clarifying? I’ve always been troubled by the same thing. A and B are, in fact, distinguishable (contra “A ... is indistinguishable from B in that context”). What i think is meant by impersonation is that A acts in B’s identity context while using the access it has been delegated, rather than its own context — whatever the extent of this access, great or small. > > — Section 8.2 — > RFC 8174 needs to be normative, along with 2119. > > — Section 2.2.2 — > > If the authorization server is unwilling or unable to issue a token > for all the target services indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response. > > I always trip when I read “all” in a context like this. I think you mean > “any”, because you have “a token”. You could arguably make it “tokens” and > leave “all”, but I think changing to “any” is clearer: > > NEW > If the authorization server is unwilling or unable to issue a token > for any target service indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response and no tokens are returned. > END > > The danger with “all” is having a reader interpret the error as only occurring > when the server fails *all* services, and thinking that failing one out of > three still constitutes success. I have seen this be an issue often (not with > OAuth, but in general). If you want to be absolutely clear you could even add > to the end, “A request is successful only when all requested tokens are issued.” > > — Section 5 — > > In addition, both delegation and impersonation introduce unique > security issues. Any time one principal is delegated the rights of > another principal, the potential for abuse is a concern. The use of > the "scope" claim is suggested to mitigate potential for such abuse, > as it restricts the contexts in which the delegated rights can be > exercised. > > I’m ambivalent here: is it worth also mentioning limiting the time a token is > valid and possibly make it a one-time-use token? Or is it that that’s > adequately covered in the other references and shouldn’t be repeated here? > > Also, is it worth referring (not copying) here to the advice in section 2.1 > about the importance of authentication? > > — Section 6 — > Should “TLS” here have a citation and normative reference? > > ===== > > Purely editorial: > > — Section 1 — > > An OAuth resource server, for example, might assume > the role of the client during token exchange in order to trade an > access token, which it received in a protected resource request, for > a new token that is appropriate to include in a call to a backend > service. > > A suggestion: I think this would work better using a restrictive clause, rather > than a non-restrictive one. > > NEW > An OAuth resource server, for example, might assume > the role of the client during token exchange in order to trade an > access token that it received in a protected resource request for > a new token that is appropriate to include in a call to a backend > service. > END > > The scope of this specification is limited to the definition of a > basic request and response protocol for an STS-style token exchange > > There should be hyphens in “request-and-reaponse protocol” (compound modifier). > > — Sections 4.1 and 4.4 — > > Section 4.1 says this: > Consequently, non- > identity claims (e.g., "exp", "nbf", and "aud") are not meaningful > when used within an "act" claim, and therefore must not be used. > > Section 4.4 says this: > Consequently, > claims such as "exp", "nbf", and "aud" are not meaningful when used > within a "may_act" claim, and therefore should not be used. > > I agree that neither of these should be BCP 14 key words, but I still think > that being consistent is important, and I urge you to make them the same: both > “must not be used” or both “should not be used” (or perhaps both “are not > used”). > > (I did not review the appendices.) > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Barry Leiba's No Objection on draft-ie… Barry Leiba via Datatracker
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Benjamin Kaduk
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Barry Leiba
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Eve Maler
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Brian Campbell
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Barry Leiba
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Brian Campbell
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Benjamin Kaduk
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Benjamin Kaduk
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Brian Campbell
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Brian Campbell
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… Barry Leiba
- Re: [OAUTH-WG] Barry Leiba's No Objection on draf… John Bradley