Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

Denis <denis.ietf@free.fr> Tue, 01 August 2017 19:54 UTC

Return-Path: <denis.ietf@free.fr>
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 AFC55132301 for <oauth@ietfa.amsl.com>; Tue, 1 Aug 2017 12:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 CbUw_AtsAajc for <oauth@ietfa.amsl.com>; Tue, 1 Aug 2017 12:54:21 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 46BBC131C84 for <oauth@ietf.org>; Tue, 1 Aug 2017 12:54:21 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id D54B97802B2; Tue, 1 Aug 2017 21:54:18 +0200 (CEST)
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> <CA+k3eCQCKtBct-iqxJCscad3rkUDUyx-MDbGa0Ysb995wX2BUA@mail.gmail.com> <fa2e98ad-cb95-a142-7989-4bfd422de06b@redhat.com> <CA+k3eCTzTO54xvekYoY=TkL4dxYupg+C6-K9dsduqCS9NLspdg@mail.gmail.com> <dafbf97e-1bf5-6314-85aa-58d4f4f6eab8@redhat.com> <CA+k3eCQPkZ-HXUTEj5m0po8P5=W+M6joBdCKTwMLdO=4gQErvA@mail.gmail.com> <e5b0a1d2-5d9e-fd88-bd15-c14fb627b9cf@free.fr> <CA+k3eCRFcMx-O=QEFZd0A+cD5rQYLY2uYoGJi9=TJbAj2oqVzg@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <b850b6a8-eb94-3882-b88e-e607fca559f3@free.fr>
Date: Tue, 1 Aug 2017 21:54:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CA+k3eCRFcMx-O=QEFZd0A+cD5rQYLY2uYoGJi9=TJbAj2oqVzg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------D3B96E04931A53A5C853E14E"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/yfdv5tk8K_XhW4909wvPgHv0z04>
Subject: Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
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: Tue, 01 Aug 2017 19:54:25 -0000

Brian,

> JWT (which is RFC 7519 <https://tools.ietf.org/html/rfc7519> not 7515 
> <https://tools.ietf.org/html/rfc7515>) does define the common/major 
> fields of a JWT. But access tokens aren't necessarily JWTs.

Beyond this comment, would you be able to answer to the various points 
and questions raised in this email ?

Denis

>
> On Tue, Aug 1, 2017 at 4:53 AM, Denis <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> wrote:
>
>     Hello Brian,
>
>>     I don't think that's what I'm saying. Some of these concepts are
>>     difficult to reason about on a mailing list so I apologize for
>>     any miss or poor communication.
>>
>>     When requesting a token, the resource or audience parameter can
>>     be used to indicate the target service where the client intends
>>     to use the token that it is requesting.  Audience is a logical
>>     name that says where the client wants to use the requested token.
>>     As a a logical name, the parties involved do need to know about
>>     the name. The resource parameter lets the client indicate to the
>>     AS/STS where it intends to use the issued token by providing the
>>     location, typically as an https URL, in the token exchange
>>     request in the same form that will be used to access that
>>     resource (again, an HTTPS URL). And the resource URL or audience
>>     can certinally indicate something that's external. Those
>>     parameters allow the AS/STS to determine where the token is going
>>     to be used (including externally) and produce the the appropriate
>>     token for that target based on configuration and policy.  The
>>     text in
>>     https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1
>>     <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1>
>>     about those parameters attempts to describe that in an
>>     intelligible way. Though there's likely always room for improvement.
>
>     Bear in mind, that they are cases where privacy is a concern, and
>     for these cases the resource or audience parameter *cannot* be
>     used to indicate the target service where the client intends to
>     use the token that it is requesting.
>
>>     In general OAuth, the structure, content, style, etc. of access
>>     tokens is not defined. That stuff has to be agreed on between the
>>     AS and RS.
>
>     RFC 7515 defines the major fields of a JWT.
>
>>     Although Token Introspection (RFC 7662)
>>     <https://tools.ietf.org/html/rfc7662> has since been defined to
>>     give a more standardized option for the RS to query the AS for
>>     status and meta-information about an access token. Even with
>>     introspection, however, an RS effectively can only use access
>>     tokens from one AS because there's nothing standard provided by
>>     OAuth to indicate where the token is from when it's presented to
>>     the RS.
>
>     RFC 7515 defines the "x5c" (X.509 Certificate Chain) Header
>     Parameter in section 4.1.6: this parameter indicates where the
>     token is from.
>
>>     For an AS/STS to validate an OAuth access token from a different
>>     AS, it is in a similar situation as an RS.
>     The key point is coming from the following proposed definition: "A
>     Security Token Service (STS) is a service capable of *validating
>     and* issuing security tokens".
>     Up to now, the following definition applies: "A Security Token
>     Service (STS) is a service capable of issuing security tokens".A
>     given RS is free to trust (or not to trust)
>     any AS/STS.
>
>>     It would need to know the issuer of the access token - this is, I
>>     think, what you've pointed out with suggesting "subject_issuer"
>>     and "actor_issuer".
>
>     I believe that I am now starting to understand why you made these
>     suggestions.
>
>>     There are maybe different ways that could be conveyed but some
>>     means at least would be needed to indicate the access token issuer.
>
>     The "x5c" Header Parameter is such another way. When used, it
>     should not conflict with any other parameter.
>
>>     Then the receiving AS/STS would have to call the issuing AS's
>>     token introspectionendpoint (unless it somehow knew how to
>>     validate an access token from that issuer locally). The
>>     complexity of all that is one reason why token exchange scoped
>>     validation (and issuance) of access tokens to only access tokens
>>     from the AS/STS involved in the exchange (and not directly
>>     supporting OAuth access token to OAuth access token cross-domain
>>     exchanges). Also the assertion based authorization grants (RFC
>>     7523 <https://tools.ietf.org/html/rfc7523> & 7522
>>     <https://tools.ietf.org/html/rfc7522>) are largely intended to
>>     facilitate acquiring an access token from an external AS. The
>>     thinking (fro me anyway) was that token exchange would be used
>>     with a local STS to obtain an assertion suitable to be used at an
>>     external AS with an assertion grant to get an access token from
>>     that AS. That pattern is something that exists today. Cross
>>     domain could also be achieved with JWTs, for which a token type
>>     value of "urn:ietf:params:oauth:token-type:jwt" is defined.
>>
>>     It's difficult to articulate but that's an attempt to explain how
>>     things are in the draft today and why.
>
>     If we introduce relationships between AS/STSs, we are opening a
>     pandora box where trust relationships is a concern and where
>     privacy is also a concern.
>
>     Do we want a local AS/STS to be aware of all the RSs accessed by a
>     client ? Do we want an external AS/STS to be aware of all the RSs
>     accessed by a client ?
>     What would mean a "local" AS/STS versus an "external" AS/STS ? It
>     is from the point of view of the client or of the RS ?
>
>     It is normal that an AS/STS issuing access token knows some
>     attributes related to its clients. Would it be appropriate if
>     another AS/STS would know some attributes from "external" clients
>     and, in addition, where the access tokens will be used ? We need
>     to take care of _not building a system_ where/by construction/
>     "Big Brother would be watching you".
>
>     The core of problem is well beyond the simple addition of one or
>     two parameters.
>
>>     I guess I would have to defer to the larger working group here as
>>     to the question of if token exchange should support exchanges of
>>     an OAuth access token from a different AS for an OAuth access
>>     token issued by the AS/STS doing the exchange?
>
>     In order to progress on this topic, I believe that we first need
>     an architecture paper with a clear description of the trust
>     relationships and an identification of the privacy issues.
>
>     Denis
>
>>     On Sat, Jul 29, 2017 at 8:46 AM, Bill Burke <bburke@redhat.com
>>     <mailto:bburke@redhat.com>> wrote:
>>
>>         So, you're saying the STS has to define a subject_type for
>>         each external token the client wants to exchange from?  A
>>         type that is potentially proprietary and different between
>>         each and every STS?  On the opposite end, when you want to
>>         convert to an external token, the STS either has 3 options
>>         for the client to specify that it wants an external token. 
>>         1) a proprietary response type, 2) a proprietary resource
>>         scheme, 3) a proprietary audience scheme.
>>
>>         Don't you think at minimum, the token-exchange spec should
>>         define a standard way to do OAuth to OAuth cross-domain
>>         exchanges?  Right now cross-domain exchanges are proprietary
>>         and completely up to the target STS on how it wants the
>>         client to formulate a cross-domain exchange.  I still think a
>>         "subject_issuer" and "requested_issuer" are the clearest and
>>         simplest way to enable such an interaction.
>>
>>
>>         On 7/28/17 6:28 PM, Brian Campbell wrote:
>>>         The urn:ietf:params:oauth:token-type:access_token type is an
>>>         "indicator that the token is a typical OAuth access token
>>>         issued by the authorization server in question" (see near
>>>         the end of section 3
>>>         <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-3>)
>>>         so the issuer is the given STS in that case. Cross domain is
>>>         possible by use of other token types that are not opaque to
>>>         the STS where the issuer can be inferred from the token.
>>>
>>>         On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke
>>>         <bburke@redhat.com <mailto:bburke@redhat.com>> wrote:
>>>
>>>             Thanks for replying,
>>>
>>>             The Introduction of the spec implies that
>>>             inter-security-domain exchange is supported: "
>>>
>>>               A Security Token Service (STS) is a service capable of validating and
>>>                 issuing security tokens, which enables clients to obtain appropriate
>>>                 access credentials for resources in heterogeneous environments or
>>>                 across security domains.
>>>             "
>>>
>>>             But with the current API if you want to exchange an external token to an internal one, there is no way for the STS to identify where the subject_token originated.  Are you saying that an STS cannot accept tokens from an external domain?
>>>
>>>             i.e
>>>
>>>             subject_token: <opaque-string>
>>>
>>>             subject_token_type:
>>>             urn:ietf:params:oauth:token-type:access-token
>>>
>>>             There's just no way for the STS to know where the
>>>             subject_token came from because the subject_token can be
>>>             completely opaque.
>>>
>>>             Now, on the flip side, if you are converting from an
>>>             internal token to an external one, the audience
>>>             parameter is just too undefined.  For example, how could
>>>             you specify that you want a token for an external client
>>>             of an external issuer.  Client ids are opaque in OAuth,
>>>             and issuer id isn't even something that is defined at
>>>             all.  In OpenID connect, an issuer id can be any URL.
>>>
>>>             IMO, adding optional "subject_token_issuer" and
>>>             "requested_issuer" parameters only clarifies and
>>>             simplifies the cross-domain case.   If you don't like
>>>             "issuer" maybe "domain" is a better word?
>>>
>>>             Thanks for replying,
>>>
>>>             Bill
>>>
>>>
>>>
>>>
>>>
>>>             On 7/28/17 4:39 PM, Brian Campbell wrote:
>>>>             In general, an instance of an AS/STS can only issue
>>>>             tokens from itself. The audience/resource parameters
>>>>             tell the AS/STS where the requested token will be used,
>>>>             which will influence the audience of the token (and
>>>>             maybe other aspects). But the issuer of the requested
>>>>             token will be the AS/STS that issued it. A cross domain
>>>>             exchange could happen by a client presenting a
>>>>             subject_token from a different domain/issuer (that the
>>>>             AS/STS trusts) and receiving a token issued by that
>>>>             AS/STS suitable for the target domain.
>>>>
>>>>
>>>>
>>>>             On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke
>>>>             <bburke@redhat.com <mailto:bburke@redhat.com>> wrote:
>>>>
>>>>                 Should probably have a "subject_issuer" and
>>>>                 "actor_issuer" as well as the "requested_issuer" too.
>>>>
>>>>                 FYI, I'm actually applying this spec to write a
>>>>                 token exchange service to connect various product
>>>>                 stacks that have different and often proprietary
>>>>                 token formats and architectures.
>>>>
>>>>
>>>>
>>>>                 On 7/26/17 6:44 PM, Bill Burke wrote:
>>>>
>>>>                     Hi all,
>>>>
>>>>                     I'm looking at Draft 9 of the token-exchange
>>>>                     spec.  How would one build a request to:
>>>>
>>>>                     * exchange a token issued by a different domain
>>>>                     to a client managed by the authorization server.
>>>>
>>>>                     * exchange a token issued by the authorization
>>>>                     server (the STS) for a token of a different
>>>>                     issuer and different client.  In other words,
>>>>                     for a token targeted to a specific client in a
>>>>                     different authorization server or realm or
>>>>                     domain or whatever you want to call it.
>>>>
>>>>                     * exchange a token issued by a different issuer
>>>>                     for a token of a different issuer and client.
>>>>
>>>>                     Is the spec missing something like a
>>>>                     "requested_issuer" identifier? Seems that
>>>>                     audience is too opaque of a parameter for the
>>>>                     authz server to determine how to exchange the
>>>>                     token.
>>>>
>>>>                     Thanks,
>>>>
>>>>                     Bill
>>>>
>>>>
>>>>
>>>>                     _______________________________________________
>>>>                     OAuth mailing list
>>>>                     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>                     https://www.ietf.org/mailman/listinfo/oauth
>>>>                     <https://www.ietf.org/mailman/listinfo/oauth>
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 OAuth mailing list
>>>>                 OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>>>                 <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./ 
>>>
>>>
>>>
>>>         /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./
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <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./