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