Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

Eric Rescorla <ekr@rtfm.com> Fri, 01 June 2018 21:48 UTC

Return-Path: <ekr@rtfm.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 7797212DA1C for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 14:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 dzM3BmtQ6sIS for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 14:48:03 -0700 (PDT)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 BCCDA12DA54 for <oauth@ietf.org>; Fri, 1 Jun 2018 14:48:02 -0700 (PDT)
Received: by mail-ot0-x22a.google.com with SMTP id n1-v6so30928493otf.7 for <oauth@ietf.org>; Fri, 01 Jun 2018 14:48:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I4ZXuuYTlkO6V36B0AGbKVG4q/ciI3RStRNOaHRkcck=; b=VOfGEfGvgN2/CEB9kwgjYg+/xcVqegTvlk3iobAbceheg4WzBykjmSwg70ATTyvknR P8xdFTbzhRIcuPRwNMgRphXap/tMQpycGOFs/SoMHlqUjbjBCeDiyYkJHwbzLnjZdDBY 7CMu1g0xQ3AVurZBkQlPyE/HIlkOek4DPZ8qTRBiAIjyGXDT6I7OqUD+Pt91RwW4Uu14 r+73DC1z71ejY6H1AQ2Mqyyd5QGbBTqMQnKmeAWhAfht0j06Ek+9HgKLo9StjfhxfDz1 yAbkYuFLHIM0A2LzCDRQnRyDqFxOj44sga25/el+uv0MNX6Er6W95v9tCAg6Ll+sd2PQ sMyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I4ZXuuYTlkO6V36B0AGbKVG4q/ciI3RStRNOaHRkcck=; b=YE3Qt64o/7D5MBXGaE0b0AGtO4WK7glIlxylxiUcWgbFD5OoWEo/t7cbk4annoPbhQ Vk4MYecex7dwYGEV1gTWAq9/P0Ex4TSem6Up5k6AMO2NiYiOgrdnZQVGGjDYxbolDlYK 5aZajruVeZg7+Vxh0exh26GIhiDzZpuzsNx4A3YDoVQeE2x2TyOgrhEdeBARNX2JbcEC dTV0iptLFGUTDmXKtmAlOUyzseJpxefG6ecR5hfOaozkKq2xUCKFBRGvcmee8UZ2DuBA 3VXEYfJODigdk8DXe7NrugwfC72VcpyOLqygDgj9I8EojHiDscdB28RaailbMJM7nDDs 45CA==
X-Gm-Message-State: APt69E0Qm8afOPgje9JqJocQ2a1hco3YpFOPJ5m/u4M8lcYl72n1tH+f bUVONW8kVuuOWisvss8gTjV6j1sRIsReHiM0QBlPSw==
X-Google-Smtp-Source: ADUXVKLPexYdslT9B0WZzB1fxgAgBD9pw++OVpD0HHlbZUrI9+MHJTMkxJZChmrdQz8/JbFPMhJkfJcmgiWi872CuJg=
X-Received: by 2002:a9d:2f45:: with SMTP id h63-v6mr2194861otb.371.1527889682018; Fri, 01 Jun 2018 14:48:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 14:47:21 -0700 (PDT)
In-Reply-To: <CA+k3eCRBahGR2N6rUNtZrYASQhjNUU4-_HVCZp_XAKv70zkpTA@mail.gmail.com>
References: <CABcZeBNQaqg3wFuo=w3h4k+bB44pEPnoR-zZYM+AR7YDA=O8Gg@mail.gmail.com> <CA+k3eCRDyn7-1KEVYai8b-G_bLQZGTgiS2VFG9W3NWy2Ttu-nw@mail.gmail.com> <ef06d115-b178-16c3-76ca-4693d273ae41@free.fr> <CA+k3eCTeBqPHTs_vUrFOcEOT3CHJptJN8m3_M3LDYyL=WrL5BA@mail.gmail.com> <CABRXCmxSY75_tSA6uE4jtMMeX4aXOGEzWBLhkKXOOgg9ZUNNuA@mail.gmail.com> <SN6PR00MB03015D1AAF670587060EE199F5910@SN6PR00MB0301.namprd00.prod.outlook.com> <CABRXCmy8WnhSYGSz+wu2NQvz1E2Jr_Jx-=cH=tM_xVT0UaQp6g@mail.gmail.com> <CA+k3eCQdyuFA6FKUg4onMPhQ6VxfcOQ6vLSW_GijLsF+NOBaSg@mail.gmail.com> <CABcZeBNReOvd-FFiEwf-M_zXoiKYTT2pcSGfyjVEYe4E6adMCw@mail.gmail.com> <CA+k3eCRBahGR2N6rUNtZrYASQhjNUU4-_HVCZp_XAKv70zkpTA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 1 Jun 2018 14:47:21 -0700
Message-ID: <CABcZeBOk4haUG_omN-ED_WwpAmY2G5jW2O6MPfhGLojw9bQ2kQ@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Bill Burke <bburke@redhat.com>, Mike Jones <Michael.Jones@microsoft.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c0b770056d9b8943"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6qm9mcFBsK5K7JuATt7JhdSkjx0>
Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 01 Jun 2018 21:48:08 -0000

That would go a long way, I think. Do you think that C's permissions matter
at all? So, say that the resource is accessible to C but not A?

-Ekr




On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

> Hi Eric,
>
> Apologies for my somewhat slow response. I've honestly been unsure of how
> else to try and address the comment/question. But will continue trying...
>
> My expectation would be that access control decisions would be made based
> on the subject of the token itself or on the current actor. And maybe a
> combination of both in some situations (like, for example, the actor is an
> administrator and the token allows admin level access to the stuff the
> token subject would normally have access to).  However, I don't believe
> that nested prior actors would or should be considered in access control
> decisions. The nesting is more just to express what has happened for
> auditing or tracking or the like. To be honest, the nesting was added in
> the draft largely because the structure naturally and easily allowed for it
> and it seemed like it might be useful information to convey in some cases.
>
> So in that A->B->C case (the claims of such a token would, I think, look
> like the JSON below), B *is not* giving C his authority. B is just noted
> in the token as having been involved previously.  While A is identified as
> the subject of the token and C is the current actor.
>
>     {
>       "aud":"... ,"iss":... , "exp":..., etc. etc. ...
>       "sub":"A",
>       "act":
>       {
>         "sub":"C",
>         "act":
>         {
>           "sub":"B"
>         }
>       }
>     }
>
>
> Would some text explicitly saying that only the token subject (top level
> sub and claims) and the party identified by the outermost "act" claim (the
> current actor) are to be considered in access control decisions address
> your concern?
>
>
> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> Hi Brian,
>>
>> To be clear, I'm not opposing Delegation. My concern here is that we have
>> a chain of signed assertions and I'm trying to understand how I as a
>> consumer of those assertions am supposed to evaluate it.
>>
>> I don't think it's sufficient to just say that that the access control
>> rules are local policy, because then the entity generating the signature
>> has no way of knowing how its signature will be used.
>>
>> To go back to the case I gave in my initial e-mail, say we have a chain
>> A->B->C and a resource that A and C could ordinarily not access, but B can.
>> If C has this delegation, can C access the resource? I.e., is B giving C
>> his authority or just passing on A's authority? It seems pretty important
>> for B to know that before he gives the token to C.
>>
>> -Ekr
>>
>>
>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell <
>> bcampbell@pingidentity.com> wrote:
>>
>>> Delegation has been in the document since its inception and throughout
>>> the three and a half years as a working group document.
>>>
>>> From a process point of view, the document is now in AD Evaluation. I
>>> worked through a number of questions and clarifications with Eric (said
>>> AD), however he raised the particular questions that started this thread on
>>> the WG list. And I responded with an attempt at addressing those questions.
>>> That was about a month ago.
>>>
>>> Eric, was my explanation helpful in clarify anything for you? Is there
>>> some text that you'd like to see added? Something else? I'm unsure how to
>>> proceed but would like to move things forward.
>>>
>>>
>>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke <bburke@redhat.com> wrote:
>>>
>>>> This is an honest question: How important is the actor stuff to the
>>>> players involved?  Are people going to use it?  IMO, its an edge case
>>>> and I think more important areas, like external token exchange (realm
>>>> to realm, domain to domain) are being neglected.  I'm quite unfamiliar
>>>> how consensus is reached in this WG or the IETF, so I hope I'm not
>>>> sounding rude.  Just trying to provide some constructive feedback.
>>>>
>>>>
>>>>
>>>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones <
>>>> Michael.Jones@microsoft.com> wrote:
>>>> > Moving the actor claim to a separate specification would only make
>>>> things more complicated for developers.  There already plenty of OAuth
>>>> specs.  Needlessly adding another one will only make related things harder
>>>> to find.
>>>> >
>>>> > Just like in the JWT [RFC 7519] spec itself in which use of all the
>>>> claims is optional, use of the actor claim in this spec.  If you don't need
>>>> it, don't use it.  Just because some won't use it is no better an argument
>>>> for moving it to a different spec than the argument that JWT should have
>>>> defined each of its claims in different specs.  That would have made things
>>>> harder, not easier.
>>>> >
>>>> >                                 -- Mike
>>>> >
>>>> > -----Original Message-----
>>>> > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
>>>> > Sent: Thursday, May 17, 2018 2:11 PM
>>>> > To: Brian Campbell <bcampbell@pingidentity.com>
>>>> > Cc: oauth <oauth@ietf.org>
>>>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang
>>>> e-12.txt
>>>> >
>>>> > My personal opinion is that I'm glad this actor stuff is optional.
>>>> > For one, none of our users have asked for it and really only do
>>>> simple exchanges.  Secondly, the rules for who can exchange what for what
>>>> is controlled and defined within our AS.  Makes things a lot simpler on the
>>>> client.  I kind of wish the actor stuff would be defined in a separate
>>>> specification.  I don't see us implementing it unless users start asking us
>>>> to.
>>>> >
>>>> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <
>>>> bcampbell@pingidentity.com> wrote:
>>>> >> Well, it's already called the "actor claim" so the claimed part is
>>>> >> kind of implied. And "claimed actor claim" is a rather awkward.
>>>> >> Really, all JWT claims are "claimed something" but they don't include
>>>> >> the "claimed" bit in the name. RFC 7519, for example, defines the
>>>> >> subject claim but not the claimed subject claim.
>>>> >>
>>>> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>>> >>>
>>>> >>> Brian,
>>>> >>>
>>>> >>> Eric said: "what is the RP supposed to do when they encounter it?
>>>> >>> This seems kind of under specified".
>>>> >>>
>>>> >>> After reading your explanations below, it looks like the RP can do
>>>> >>> anything he wants with the "actor".
>>>> >>> It is a "claimed actor" and, if we keep the concept, it should be
>>>> >>> called as such. Such a claim cannot be verified.
>>>> >>> A RP could copy and paste that claim in an audit log. No standard
>>>> >>> action related to the content of such a claim can be specified in
>>>> the
>>>> >>> spec. If the content of a "claimed actor" is used by the RP, it
>>>> >>> should be only used as an hint and thus be subject to other
>>>> >>> verifications which are not specified in this specification.
>>>> >>>
>>>> >>> Denis
>>>> >>>
>>>> >>> Eric, I realize you weren't particularly impressed by my prior
>>>> >>> statements about the actor claim but, for lack of knowing what else
>>>> >>> to say, I'm going to kind of repeat what I said about it over in the
>>>> >>> Phabricator tool and add a little color.
>>>> >>>
>>>> >>> The actor claim is intended as a way to express that delegation has
>>>> >>> happened and identify the entities involved. Access control or other
>>>> >>> decisions based on it are at the discretion of the consumer of the
>>>> >>> token based on whatever policy might be in place.
>>>> >>>
>>>> >>> There are JWT claims that have concise processing rules with respect
>>>> >>> to whether or not the JWT can be accepted as valid. Some examples
>>>> are "aud"
>>>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from
>>>> RFC 7519.
>>>> >>> E.g. if the token is expired or was intended for someone or
>>>> something
>>>> >>> else, reject it.
>>>> >>>
>>>> >>> And there are JWT claims that appropriately don't specify such
>>>> >>> processing rules and are solely statements of fact or circumstance.
>>>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At)
>>>> claims are good examples of such.
>>>> >>> There might be application or policy specific rules applied to the
>>>> >>> content of those kinds of claims (e.g. only subjects from a
>>>> >>> particular organization are able to access tenant specific data or,
>>>> >>> less realistic but still possible, disallow access for tokens issued
>>>> >>> outside of regular business
>>>> >>> hours) but that's all outside the scope of a specification's
>>>> >>> definition of the claim.
>>>> >>>
>>>> >>> The actor claim falls into the latter category. It's a way for the
>>>> >>> issuer of the token to tell the consumer of the token what is going
>>>> >>> on. But any action to take (or not) based on that information is at
>>>> >>> the discretion of the token consumer. I honestly don't know it could
>>>> >>> be anything more. And don't think it should be.
>>>> >>>
>>>> >>> There are two main expected uses of the actor claim (that I'm aware
>>>> >>> of
>>>> >>> anyway) that describing here might help. Maybe. One is a human to
>>>> >>> human delegation case like a customer service rep doing something on
>>>> >>> behalf of an end user. The subject would be that user and the actor
>>>> >>> would be the customer service rep. And there wouldn't be any
>>>> chaining
>>>> >>> or nesting of the actor. The other case is so called service
>>>> chaining
>>>> >>> where a system might exchange a token it receives for a new token
>>>> >>> that it can use to call a downstream service. And that service in
>>>> >>> turn might do another exchange to get a new token suitable to call
>>>> >>> yet another downstream service. And again and so on and turtles all
>>>> >>> the way. I'm not necessarily endorsing that level of granularity in
>>>> >>> chaining but it's bound to happen somewhere/sometime. The nested
>>>> >>> actor claim is able to express that all that has happened with the
>>>> >>> top level or outermost one being the system currently using the
>>>> token
>>>> >>> and prior systems being nested.. What actually gets done with that
>>>> >>> information is up to the respective systems involved. There might be
>>>> >>> policy about what system is allowed to call what other system that
>>>> is
>>>> >>> enforced. Or maybe the info is just written to an audit log
>>>> >>> somewhere. Or something else. I don't know. But whatever it is
>>>> application/deployment/policy dependent and not specifiable by a spec.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com>
>>>> wrote:
>>>> >>>>
>>>> >>>> Hi folks,
>>>> >>>>
>>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem
>>>> >>>> generally OK. I do still have one remaining concern, which is about
>>>> >>>> the actor claim. Specifically, what is the RP supposed to do when
>>>> >>>> they encounter it? This seems kind of underspecified.
>>>> >>>>
>>>> >>>> In particular:
>>>> >>>>
>>>> >>>> 1. What facts am I supposed to know here? Merely that everyone in
>>>> >>>>    the chain signed off on the next person in the chain acting as
>>>> them?
>>>> >>>>
>>>> >>>> 2. Am I just supposed to pretend that the person presenting the
>>>> token
>>>> >>>>    is the identity at the top of the chain? Say I have the
>>>> >>>>    delegation A -> B -> C, and there is some resource which
>>>> >>>>    B can access but A and C cannot, should I give access?
>>>> >>>>
>>>> >>>> I think the first question definitely needs an answer. The second
>>>> >>>> question I guess we could make not answer, but it's pretty hard to
>>>> >>>> know how to make a system with this left open..
>>>> >>>>
>>>> >>>> -Ekr
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> OAuth mailing list
>>>> >>>> OAuth@ietf.org
>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>> 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.
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> OAuth mailing list
>>>> >>> OAuth@ietf.org
>>>> >>> https://www.ietf.org/mailman/listinfo/oauth
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> OAuth mailing list
>>>> >>> OAuth@ietf.org
>>>> >>> https://www.ietf.org/mailman/listinfo/oauth
>>>> >>>
>>>> >>
>>>> >>
>>>> >> 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.
>>>> >> _______________________________________________
>>>> >> OAuth mailing list
>>>> >> OAuth@ietf.org
>>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Bill Burke
>>>> > Red Hat
>>>> >
>>>> > _______________________________________________
>>>> > OAuth mailing list
>>>> > OAuth@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>>
>>>
>>>
>>> *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.*
>>
>>
>>
>
> *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.*
>