From nobody Tue Aug 1 03:53:31 2017 Return-Path: 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 A72C7129AF3 for ; Tue, 1 Aug 2017 03:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.418 X-Spam-Level: X-Spam-Status: No, score=-5.418 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_H2=-2.8, 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 FfJEFqqeA61d for ; Tue, 1 Aug 2017 03:53:25 -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 6B100132070 for ; Tue, 1 Aug 2017 03:53:25 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id AF6587803A5 for ; Tue, 1 Aug 2017 12:53:22 +0200 (CEST) To: oauth@ietf.org References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> From: Denis Message-ID: Date: Tue, 1 Aug 2017 12:53:24 +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: Content-Type: multipart/alternative; boundary="------------1543739971E920A25F582D92" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 10:53:30 -0000 This is a multi-part message in MIME format. --------------1543739971E920A25F582D92 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 > > 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) > 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 & > 7522 ) 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 > 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 >> ) >> 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 > > 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: >> >> 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 >>> > 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 >>> 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./ >> >> >> >> /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 > https://www.ietf.org/mailman/listinfo/oauth --------------1543739971E920A25F582D92 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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 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) 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 introspection endpoint (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 & 7522) 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> 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) 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> 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> 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
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.



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
https://www.ietf.org/mailman/listinfo/oauth


--------------1543739971E920A25F582D92-- From nobody Tue Aug 1 09:46:19 2017 Return-Path: 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 A1A4A1321A3 for ; Tue, 1 Aug 2017 09:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-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 HaFMqRHSzJkH for ; Tue, 1 Aug 2017 09:46:13 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 CC229131DF7 for ; Tue, 1 Aug 2017 09:46:12 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id y129so10127094pgy.4 for ; Tue, 01 Aug 2017 09:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=epG0Fisych2339VGHPXgpuHUsIU0sLkkEwwJtM729X8=; b=Hf8d6chWiwT4vaXpZY83GDJ/AoV/Tzm/Ar4A4qDUVZtU+mZL7B4TjQ1g2O9BtrRxNV x6BoXdvyRznQL1CixTVVj9OZMrk5e8kNvfWlOStanhHXwJLW4IUSxmDm05pkEUNGHLCB EG7ayboSo7ULyjI+maPjwl5Iwnp5qIilzdR0g= 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=epG0Fisych2339VGHPXgpuHUsIU0sLkkEwwJtM729X8=; b=GQddJkXD0w2M/YmOWksyAl45dWBAnAiseN8rcMHXkKhPj5xocLUBNfZcaWUGk5yKB2 LI5rxcx9QlqPrk4t0zvaCtAySZS3ziH/UP5tmImwZqZryHoIeI8yt45WDZXpcTxzGkQJ toi/ikfJ58yNM6kMHWLfJB6/zws3pSKIoHa9I7BrPPtp8TrIcxAjwUNd8ngwVG7bD/iU Jpdr+9cMI5p5+lW8QrFRm/cp+45ygvKB1XutNLMi0ayDIpYUZJKXpvKL54eM6ng359bI WLw9TjZF0gLvAjSfUS21CTMCxsQ/aoT/9ZTeSpifYGE5tI56CbSlgnIshMguOmYX7DTK QA2w== X-Gm-Message-State: AIVw110JvOyfO5D9+ShJCcvMf0TDkRH/Jdxz+N1ZQB0mCVMylr6YU5Zj uAkMwYowF1NkLMASkH6zEMpawcROpTqjZFIqcVPhPkI29WQMIeGit/RHVt/GG94YWJ8YEli9PXh AhmxS X-Received: by 10.99.97.69 with SMTP id v66mr5461173pgb.332.1501605972269; Tue, 01 Aug 2017 09:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Tue, 1 Aug 2017 09:45:41 -0700 (PDT) In-Reply-To: References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> From: Brian Campbell Date: Tue, 1 Aug 2017 10:45:41 -0600 Message-ID: To: Denis Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c0cc59c9205580555b3e295" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 16:46:17 -0000 --94eb2c0cc59c9205580555b3e295 Content-Type: text/plain; charset="UTF-8" JWT (which is RFC 7519 not 7515 ) does define the common/major fields of a JWT. But access tokens aren't necessarily JWTs. On Tue, Aug 1, 2017 at 4:53 AM, Denis 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 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) > 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 > introspection endpoint (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 > & 7522 > ) 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 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 >> ) >> 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 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: >>> >>> 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 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 >>>>> 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.* >>> >>> >>> >> >> *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 listOAuth@ietf.orghttps://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.* --94eb2c0cc59c9205580555b3e295 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
JWT (which is RFC 7519 not 7515) does define th= e common/major fields of a JWT. But access tokens aren't necessarily JW= Ts.

On Tue, Aug 1, 2017 at 4:53 AM, Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello Brian,

I don't think that's what I'm saying. Some of th= ese 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.=C2=A0 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.=C2=A0 The text in 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 pri= vacy 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) 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 servic= e 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".<= /font> A given RS is free to trust (or not to trust) <= br> 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 underst= and 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 suc= h 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 introspection endpoint (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 & 7522) 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:j= wt" is defined.=C2=A0

It's difficult to articulate but that's an attempt to explain how things are in the draft today and why.=C2=A0

If we introduce relationships between AS/ST= Ss, 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&q= uot; 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 belie= ve 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> wrote:

So, you're saying the STS has to define a subject_type for each external token the client wants to exchange from?=C2=A0 A type that is potentially proprietary and different between each and every STS?=C2=A0 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.=C2=A0 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?=C2=A0 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.=C2=A0 I still think a "subject_= issuer" and "requested_issuer" are the clearest and simpl= est 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 typica= l OAuth access token issued by the authorization server in question" (see near the end of 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> wrote:

Thanks for replying,

The Introduction of the spec implies that inter-security-domain exchange is supported: "

 A Security Token Service (ST=
S) 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 in=
ternal 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 exter=
nal 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.=C2=A0

Now, on the flip side, if you are converting from an internal token to an external one, the audience parameter is just too undefined.=C2=A0 For example, how could you specify that you want a token for an external client of an external issuer.=C2=A0 Client ids are opaque in OAuth, and issuer id isn't even something that i= s defined at all.=C2=A0 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.=C2=A0=C2=A0 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 <bbu= rke@redhat.com> wrote:
Should probably have a "subject_issue= r" and "actor_issuer" as wel= l as the "requested_issuer" to= o.

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.=C2= =A0 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.=C2=A0 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?=C2=A0 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
https://www= .ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.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.=C2=A0 If you ha= ve 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.=C2= =A0 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.=C2=A0 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/ma=
ilman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c0cc59c9205580555b3e295-- From nobody Tue Aug 1 10:59:12 2017 Return-Path: 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 5501A1321CD for ; Tue, 1 Aug 2017 10:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.991 X-Spam-Level: X-Spam-Status: No, score=-6.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 6-5QU2HXgk7z for ; Tue, 1 Aug 2017 10:59:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 61CDE12009C for ; Tue, 1 Aug 2017 10:59:07 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v71Hx3Kt003994 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 1 Aug 2017 17:59:03 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v71Hx2mi011138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 1 Aug 2017 17:59:02 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v71Hx267030650; Tue, 1 Aug 2017 17:59:02 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Aug 2017 10:59:01 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0C8FCAA0-9F0E-46E3-AD27-19F8C761C309" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 10:59:00 -0700 In-Reply-To: Cc: oauth@ietf.org To: Denis References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 17:59:11 -0000 --Apple-Mail=_0C8FCAA0-9F0E-46E3-AD27-19F8C761C309 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Denis, Why is privacy a concern? OAuth is designed to have the Authorization = Server be the issuer of tokens for a specific set of resource servers. = The AS represents users on the Resource server. It does not represent = users of the client - though they are often the same physical person, = they are often different authenticated subjects. =20 Of course, there are profiles of OAuth which change this relationship, = but the foundational assumption in RFC6749 is the AS is usually = associated with the RS. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 1, 2017, at 3:53 AM, Denis wrote: >=20 > Hello Brian, >=20 >> 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.=20 >>=20 >> 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= = about those parameters attempts to describe that in an intelligible = way. Though there's likely always room for improvement. >=20 > 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. >=20 >> 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.=20 >=20 > RFC 7515 defines the major fields of a JWT.=20 >=20 >> Although Token Introspection (RFC 7662) = 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.=20 >=20 > RFC 7515 defines the "x5c" (X.509 Certificate Chain) Header Parameter = in section 4.1.6: this parameter indicates where the token is from. >=20 >> For an AS/STS to validate an OAuth access token from a different AS, = it is in a similar situation as an RS.=20 > 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)=20 > any AS/STS. >=20 >> 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".=20 >=20 > I believe that I am now starting to understand why you made these = suggestions.=20 >=20 >> There are maybe different ways that could be conveyed but some means = at least would be needed to indicate the access token issuer.=20 >=20 > The "x5c" Header Parameter is such another way. When used, it should = not conflict with any other parameter. >=20 >> Then the receiving AS/STS would have to call the issuing AS's token = introspection endpoint (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 & 7522 = ) 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. =20 >>=20 >> It's difficult to articulate but that's an attempt to explain how = things are in the draft today and why. =20 >=20 > 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. >=20 > 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 ? >=20 > 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". >=20 > The core of problem is well beyond the simple addition of one or two = parameters.=20 >=20 >> 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? >=20 > 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. >=20 > Denis >=20 >> On Sat, Jul 29, 2017 at 8:46 AM, Bill Burke > 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. >>=20 >> 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. >>=20 >>=20 >> 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 = = ) 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. >>>=20 >>> On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke > wrote: >>> Thanks for replying, >>>=20 >>> The Introduction of the spec implies that inter-security-domain = exchange is supported: " >>>=20 >>> 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. >>> " >>>=20 >>> 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 >>>=20 >>> subject_token: >>>=20 >>> subject_token_type: urn:ietf:params:oauth:token-type:access-token >>>=20 >>> There's just no way for the STS to know where the subject_token came = from because the subject_token can be completely opaque. =20 >>>=20 >>> 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. >>>=20 >>> 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? >>>=20 >>> Thanks for replying, >>>=20 >>> Bill >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> 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.=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke > wrote: >>>> Should probably have a "subject_issuer" and "actor_issuer" as well = as the "requested_issuer" too. >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>> On 7/26/17 6:44 PM, Bill Burke wrote: >>>> Hi all, >>>>=20 >>>> I'm looking at Draft 9 of the token-exchange spec. How would one = build a request to: >>>>=20 >>>> * exchange a token issued by a different domain to a client managed = by the authorization server. >>>>=20 >>>> * 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. >>>>=20 >>>> * exchange a token issued by a different issuer for a token of a = different issuer and client. >>>>=20 >>>> 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. >>>>=20 >>>> Thanks, >>>>=20 >>>> Bill >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>> 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. >>>=20 >>>=20 >>>=20 >>> 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. >>=20 >>=20 >>=20 >> 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.=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_0C8FCAA0-9F0E-46E3-AD27-19F8C761C309 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Denis,

Why = is privacy a concern? OAuth is designed to have the Authorization Server = be the issuer of tokens for a specific set of resource servers. =  The AS represents users on the Resource server.  It does not = represent users of the client - though they are often the same physical = person, they are often different authenticated subjects. =  

Of = course, there are profiles of OAuth which change this relationship, but = the foundational assumption in RFC6749 is the AS is usually associated = with the RS.

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Aug 1, 2017, at 3:53 AM, Denis <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 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) 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 introspection endpoint (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 & 7522) 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> 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) 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> 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> 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
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.



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
https://www.ietf.org/=
mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_0C8FCAA0-9F0E-46E3-AD27-19F8C761C309-- From nobody Tue Aug 1 12:54:27 2017 Return-Path: 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 ; 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 ; 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 ; 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 Cc: oauth References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> From: Denis Message-ID: 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: Content-Type: multipart/alternative; boundary="------------D3B96E04931A53A5C853E14E" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:54:25 -0000 This is a multi-part message in MIME format. --------------D3B96E04931A53A5C853E14E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Brian, > JWT (which is RFC 7519 not 7515 > ) 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 > 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 >> >> 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) >> 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 & 7522 >> ) 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 > > 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 >>> ) >>> 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 >>> > 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: >>> >>> 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 >>>> > 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 >>>> 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./ >>> >>> >>> >>> /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 >> 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./ --------------D3B96E04931A53A5C853E14E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Brian,

JWT (which is RFC 7519 not 7515) 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> 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 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) 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 introspection endpoint (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 & 7522) 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> 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) 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> 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> 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
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.



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
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.


--------------D3B96E04931A53A5C853E14E-- From nobody Tue Aug 1 12:56:44 2017 Return-Path: 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 CE483132301 for ; Tue, 1 Aug 2017 12:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 K_lXfnu7ToQc for ; Tue, 1 Aug 2017 12:56:40 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 A40A51322FC for ; Tue, 1 Aug 2017 12:56:39 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id DC2D478039B; Tue, 1 Aug 2017 21:56:35 +0200 (CEST) To: Phil Hunt Cc: oauth@ietf.org References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> From: Denis Message-ID: <43fcb3b7-f0ea-47f3-b0f4-9d0f33df7d7f@free.fr> Date: Tue, 1 Aug 2017 21:56:37 +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: Content-Type: multipart/alternative; boundary="------------1F47AAB59A72D6DF3401CE3E" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:56:43 -0000 This is a multi-part message in MIME format. --------------1F47AAB59A72D6DF3401CE3E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Phil, Originally, with OAuth the AS and the RS were co-located. Many additional RFCs made extensions and this assumption is no more valid. draft-ietf-oauth-token-exchange-09 is now opening a pandora box where an even more complex situation is envisaged (without explicitly stating it) there would be one client, one RS and several AS/STS with relationships between AS/STS from different domains (don't ask me what a domain might mean in this context). See my other post about privacy in the case where a single AS/STS is involved in a transaction. It is under the following topic : How could an IdP create an id token for one audience RP without knowing for which RP ? The topic was raised at the last OAuth Workshop in Zürich by a student from ETH Zürich. In OAuth there is currently no RFC which provides a response to that question. A specification based on OAuth, OpenID Connect, is using the concept of an IdP (Identity Provider). Currently, since there is no standardized way to address this concern, any IdP will be able to act as Big Brother: it will know where the access tokens will be used. So tracking the activities of the clients will be straightforward. Addressing the same question when multiple AS/STS would be involved should only be discussed, once we a solution is defined in the case where a single AS/STS is involved. Before doing this, we would need to define an architecture. 10 years ago, the IETF was only dealing with security considerations. Nowadays, it also has to deal with privacy considerations. Denis > Denis, > > Why is privacy a concern? OAuth is designed to have the Authorization > Server be the issuer of tokens for a specific set of resource servers. > The AS represents users on the Resource server. It does not > represent users of the client - though they are often the same > physical person, they are often different authenticated subjects. > > Of course, there are profiles of OAuth which change this relationship, > but the foundational assumption in RFC6749 is the AS is usually > associated with the RS. > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Aug 1, 2017, at 3:53 AM, Denis > > 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 >>> inhttps://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) >>> 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 (RFC7523 >>> &7522 >>> ) 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 knowsome 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>> >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 ofsection 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>>> >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: >>>> >>>> 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>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 >>>>> 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./ >>>> >>>> >>>> >>>> /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 >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --------------1F47AAB59A72D6DF3401CE3E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Phil,

Originally, with OAuth the AS and the RS were co-located. Many additional RFCs made extensions and this assumption is no more valid.

draft-ietf-oauth-token-exchange-09 is now opening a pandora box where an even more complex situation is envisaged (without explicitly stating it)
there would be one client, one RS and several AS/STS with relationships between AS/STS from different domains (don't ask me what a domain
might mean in this context).

See my other post about privacy in the case where a single AS/STS is involved in a transaction. It is under the following topic :
How could an IdP create an id token for one audience RP without knowing for which RP ?
The topic was raised at the last OAuth Workshop in Zürich by a student from ETH Zürich.

In OAuth there is currently no RFC which provides a response to that question. A specification based on OAuth, OpenID Connect,
is using the concept of an IdP (Identity Provider). Currently, since there is no standardized way to address this concern, any IdP will be able
to act as Big  Brother: it will know where the access tokens will be used. So tracking the activities of the clients will be straightforward.

Addressing the same question when multiple AS/STS would be involved should only be discussed, once we a solution is defined
in the case where a single AS/STS is involved. Before doing this, we would need to define an architecture.

10 years ago, the IETF was only dealing with security considerations. Nowadays, it also has to deal with privacy considerations.

Denis

Denis,

Why is privacy a concern? OAuth is designed to have the Authorization Server be the issuer of tokens for a specific set of resource servers.  The AS represents users on the Resource server.  It does not represent users of the client - though they are often the same physical person, they are often different authenticated subjects.  

Of course, there are profiles of OAuth which change this relationship, but the foundational assumption in RFC6749 is the AS is usually associated with the RS.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
phil.hunt@oracle.com

On Aug 1, 2017, at 3:53 AM, Denis <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 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) 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 introspection endpoint (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 & 7522) 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> 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) 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> 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> 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
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.



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
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------1F47AAB59A72D6DF3401CE3E-- From nobody Tue Aug 1 12:57:48 2017 Return-Path: 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 24EE0131C84 for ; Tue, 1 Aug 2017 12:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-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 cpsHPLBI9zmk for ; Tue, 1 Aug 2017 12:57:42 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 1DECD132309 for ; Tue, 1 Aug 2017 12:57:41 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id o86so8466703pfj.1 for ; Tue, 01 Aug 2017 12:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uRGh2Joj4Su/WiC6NzxIzc9przoED8D1SXa28Jdyirw=; b=PBzAYyeszXxLH0DFfaR6XeITvLNgp3axwANLsJuaecPvK/U3jYIQfIbVhElM8oJt6e 6k4amj+DiHpuUr0RKkcCOVe1vBqPtriit+ZKbclpfkcklvGOfWCqt+LxlE2H3EHTrn85 7sAwEEEUIdgmM76Oy7UnIsuJ1yICJMpW+uNrQ= 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=uRGh2Joj4Su/WiC6NzxIzc9przoED8D1SXa28Jdyirw=; b=OYS4wzU0k9UO8tsvMp7gapRLPXAmB4G7pEvEU+NnTUHfGWEWfJ9xVE/vLqSIW6apuZ gAtuLu7ubjmCeVj8h2sd2jQAakCIZ/T+111J0BQcbkXBnsE5KVb1xyps3JrOLVrAm6Iy 93pr8CZtWgsl58q0PcNvG7e8h+Lnta9/rEbuA47QN+fiCTTVVAOIks/kT1TLNoKz+rWk LuE+UdJyuOrpSScFbe1pjsw/xUusCVvX+Hebem2dcF1oeEQwNKa7jI/9TUKnlSlFeBWB demvIFEwLXiCW63FRW8eSMuVfRuXBL0e3wW9uKK87sJ7QTowR+CCdiOH30Nr5G8YwDBb 2W1g== X-Gm-Message-State: AIVw110AXS5WlQKlBzeHtZ2p5m+hY5E2tHQJhHWpKKZ/T6o0WsOjSX54 JTY1v1wAW0DecM5+Ac0rXMT/oB0BRoqps8iEu9FVL6KD7H2/HIOZqM+9E7HrDtxpKRjpdwlwzJv Bi/S3i4M= X-Received: by 10.84.236.4 with SMTP id q4mr22194473plk.423.1501617460566; Tue, 01 Aug 2017 12:57:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Tue, 1 Aug 2017 12:57:10 -0700 (PDT) In-Reply-To: References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> From: Brian Campbell Date: Tue, 1 Aug 2017 13:57:10 -0600 Message-ID: To: Justin Richer Cc: "" Content-Type: multipart/alternative; boundary="f403045fe2d453783c0555b68ff7" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:57:46 -0000 --f403045fe2d453783c0555b68ff7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Justin. In my original announcement email, I should have given credit to Torsten as he made many of the updates in -03. So complements on improvements as well as blame for issues can be pointed to him as well! Your point about document structure is taken and we will look to make the separation of the client authentication and resource access more clear in future revisions. The document was aiming for something conceptually along those same lines already. But it could be made more clear. This could define a new =E2=80=9Ctoken_type=E2=80=9D but other than having = different token type names in messages, I don't know that a new token_type or HTTP auth scheme that would probably have to come along with it adds value to the use cases here. However, they would very likely make deployment of this stuff much more cumbersome and take longer. Whereas many systems can likely plug in mutual TLS on top of the existing token_type and HTTP auth scheme without major changes. I'm strongly inclined to not introduce a new token_type and more inclined to not do a new HTTP auth scheme. Fair point about breaking out all the registered parameters into their own hanging list items. It is somewhat inconsistent in that regard now. Will look to address that in a future revision. Using just a certificate hash for mTLS sender constrained access tokens was intentional to allow mTLS at the resource to be used as a proof-of-possession method only. It's part of the authorization check at resource access and deliberately not about authentication with the RS. Using the hash simplifies the check at the RS to one consistent way of doing things while allowing for different modes of doing client authentication at the AS. So the lack of parallelism with the client authentication at the token endpoint was very much intentional. Following from that, the need to do mTLS at the token endpoint in order to get mTLS-bound access tokens for an RS was also kind of intentional. Though, as =C2=A74.3 attempts to describe, a public client could do mTLS at the token endpoint with a generated self-singed cert to have an access token bound but not actually authenticate to the token endpoint. You are certainly right that there are other ways an AS could decide on the certificate to bind the access token to. And other ways a cnf claim member could provide for such a binding. But we were aiming to not provide too many options in the doc. So my thinking here was that this draft is about mTLS and so saying how to use mTLS for the AS to do the access token binding seemed like the most appropriate and straightforward approach. It's not so much that mTLS authentication is needed for the client at the token endpoint to allow for bound access tokens. But rather that having mTLS at the token endpoint provides a strong signal of the certificate to which to bind the issued access token. On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer wrote: > Brian, thanks for the update. This is really coming along! > > I think the spec would benefit from a more clear separation of the client > authentication and resource access sections. They=E2=80=99re really almos= t two > different but related specs, but there=E2=80=99s enough overlap that I th= ink that > keeping them in the same document is fine with some structural changes > applied. I think the content is by and large all here, it=E2=80=99s just = jumbled > together. > > To that end, I think there might be three major sections to this document > (not counting the IANA, security, privacy, and other boilerplate bits). A > suggested breakdown: > > 1) Types of mTLS client auth under consideration. This is where the > definition of public key vs. pki comes in, and where the two authenticati= on > methods are defined for both registration and discovery. Some implementor= =E2=80=99s > notes on what kinds of things you need to store here, including the > tls_client_auth_ client metadata extensions. For better or worse, 7591 > defines OAuth=E2=80=99s client model, and not just for dynamic registrati= on. > > 2) How to use mTLS to authenticate a client. This can be a relatively > short section that says use (1) in the context of getting an access token > at the token endpoint. Here is where you point out that you still need to > send client_id and that the association with the cert=E2=80=99s DN and th= e > client_id is done at the AS (there=E2=80=99s existing text for this). > > 3) How to use mTLS to bind an access token. This is a bit more complicate= d > because it=E2=80=99s the RS that needs to know the binding between the to= ken and > the cert=E2=80=99s DN, so that=E2=80=99s where you=E2=80=99d define the = =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate > side effect of spec history means that the =E2=80=9Ccnf=E2=80=9D claim fo= r 7662 also gets > defined here. This is also where you=E2=80=99d put the bits about > mutual_tls_sender_constrained_access_tokens for discovery and > registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D? > > > A few more comments: > > =C2=A72.3 really should break out all registered parameters into their ow= n > hanging list items (even if you break them up into different sections lik= e > suggested above) > > =C2=A73 seems to say that you can only do mTLS-bound access tokens at an = RS if > you do mTLS authentication at the token endpoint. Is that an intentional > restriction? To me these two functions seem to be more orthogonal than th= e > spec is hinting at. Like, I could use private_key_jwt or PKCE or magic to > authenticate at the RS but use mTLS at the RS, for whatever esoteric > reason, like the AS and RS being in different security domains. Still, > functionally, if the client=E2=80=99s registered parameters are enough to= trust for > token issuance, they should be enough to trust for token usage. In other > words, have the RS depend on tls_client_auth_subject_dn etc. instead of > "the same certificate that was used for mutual TLS at the token endpoint"= . > > Along those lines, =C2=A73 also depends entirely on matching a specific > certificate hash instead of validating a certificate (and possibly it=E2= =80=99s > chain) and associated DN. This isn=E2=80=99t in parallel with the client > authentication at the token endpoint, and I=E2=80=99d like to see these c= ome > together. Should we have a third certificate validation method in =C2=A72= for > =E2=80=9Ccertificate hash=E2=80=9D? Or maybe we should have a separate li= st for > =E2=80=9Cresource_server_auth_method=E2=80=9D for the client? > > In any event, it still feels like there are two things that are fighting > for attention in this spec: cert-based authentication of the client at th= e > token endpoint, and cert-based PoP of the token at the resource. > > =E2=80=94 Justin > > On Jul 28, 2017, at 2:33 PM, Brian Campbell > wrote: > > A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with > the changes listed below based on comments and dissuasion in Prague. > > draft-ietf-oauth-mtls-03 > > o Introduced metadata and client registration parameter to publish > and request support for mutual TLS sender constrained access > tokens > o Added description of two methods of binding the cert and client, > PKI and Public Key. > o Indicated that the "tls_client_auth" authentication method is for > the PKI method and introduced "pub_key_tls_client_auth" for the > Public Key method > o Added implementation considerations, mainly regarding TLS stack > configuration and trust chain validation, as well as how to to do > binding of access tokens to a TLS client certificate for public > clients, and considerations around certificate bound access tokens > o Added new section to security considerations on cert spoofing > o Add text suggesting that a new cnf member be defined in the > future, if hash function(s) other than SHA-256 need to be used for > certificate thumbprints > > > > ---------- Forwarded message ---------- > From: > Date: Fri, Jul 28, 2017 at 12:25 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IET= F. > > Title : Mutual TLS Profile for OAuth 2.0 > Authors : Brian Campbell > John Bradley > Nat Sakimura > Torsten Lodderstedt > Filename : draft-ietf-oauth-mtls-03.txt > Pages : 17 > Date : 2017-07-28 > > Abstract: > This document describes Transport Layer Security (TLS) mutual > authentication using X.509 certificates as a mechanism for OAuth > client authentication to the token endpoint as well as for > certificate bound sender constrained access tokens. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --f403045fe2d453783c0555b68ff7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Justin.

In my original annou= ncement email, I should have given credit to Torsten as he made many of the= updates in -03. So complements on improvements as well as blame for issues= can be pointed to him as well!

Your point about document stru= cture is taken and we will look to make the separation of the client authen= tication and resource access more clear in future revisions. The document w= as aiming for something conceptually along those same lines already. But it= could be made more clear.

This could define a new =E2=80= =9Ctoken_type=E2=80=9D but other than having different token type names in = messages, I don't know that a new token_type or HTTP auth scheme that w= ould probably have to come along with it adds value to the use cases here. = However, they would very likely make deployment of this stuff much more cum= bersome and take longer.=C2=A0 Whereas many systems can likely plug in mutu= al TLS on top of the existing token_type and HTTP auth scheme without major= changes. I'm strongly inclined to not introduce a new token_type and m= ore inclined to not do a new HTTP auth scheme.

Fai= r point about breaking out all the registered parameters into their own han= ging list items. It is somewhat inconsistent in that regard now. Will look = to address that in a future revision.

Using just a certificat= e hash for mTLS sender constrained access tokens was intentional to allow m= TLS at the resource to be used as a proof-of-possession method only. It'= ;s part of the authorization check at resource access and deliberately not = about authentication with the RS. Using the hash simplifies the check at th= e RS to one consistent way of doing things while allowing for different mod= es of doing client authentication at the AS. So the lack of parallelism wit= h the client authentication at the token endpoint was very much intentional= . Following from that, the need to do mTLS at the token endpoint in order = to get mTLS-bound access tokens for an RS was also kind of intentional. Tho= ugh, as =C2=A74.3 attempts to describe, a public cl= ient could do mTLS at the token endpoint with a generated self-singed cert = to have an access token bound but not actually authenticate to the token en= dpoint. You are certainly right that there are other ways an AS could decid= e on the certificate to bind the access token to. And other ways a cnf clai= m member could provide for such a binding. But we were aiming to not provid= e too many options in the doc. So my thinking here was that this draft is a= bout mTLS and so saying how to use mTLS for the AS to do the access token b= inding seemed like the most appropriate and straightforward approach. It= 9;s not so much that mTLS authentication is needed for the client at the to= ken endpoint to allow for bound access tokens. But rather that having mTLS = at the token endpoint provides a strong signal of the certificate to which = to bind the issued access token.






On Mo= n, Jul 31, 2017 at 2:18 PM, Justin Richer <jricher@mit.edu> wr= ote:
Brian, thank= s for the update. This is really coming along!

I think t= he spec would benefit from a more clear separation of the client authentica= tion and resource access sections. They=E2=80=99re really almost two differ= ent but related specs, but there=E2=80=99s enough overlap that I think that= keeping them in the same document is fine with some structural changes app= lied. I think the content is by and large all here, it=E2=80=99s just jumbl= ed together.

To that end, I think there might be t= hree major sections to this document (not counting the IANA, security, priv= acy, and other boilerplate bits). A suggested breakdown:

1) Types of mTLS client auth under consideration. This is where the = definition of public key vs. pki comes in, and where the two authentication= methods are defined for both registration and discovery. Some implementor= =E2=80=99s notes on what kinds of things you need to store here, including = the tls_client_auth_ client metadata extensions. For better or worse, 7591 = defines OAuth=E2=80=99s client model, and not just for dynamic registration= .

2) How to use mTLS to authenticate a client. Thi= s can be a relatively short section that says use (1) in the context of get= ting an access token at the token endpoint. Here is where you point out tha= t you still need to send client_id and that the association with the cert= =E2=80=99s DN and the client_id is done at the AS (there=E2=80=99s existing= text for this).

3) How to use mTLS to bind an acc= ess token. This is a bit more complicated because it=E2=80=99s the RS that = needs to know the binding between the token and the cert=E2=80=99s DN, so t= hat=E2=80=99s where you=E2=80=99d define the =E2=80=9Ccnf=E2=80=9D stuff. A= n unfortunate side effect of spec history means that the =E2=80=9Ccnf=E2=80= =9D claim for 7662 also gets defined here. This is also where you=E2=80=99d= put the bits about mutual_tls_sender_constrained_access_tokens for di= scovery and registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D= ?
=C2=A0

A few more comments:

=C2=A72.3 really should break out all registered parameters into th= eir own hanging list items (even if you break them up into different sectio= ns like suggested above)

=C2=A73 seems to say that= you can only do mTLS-bound access tokens at an RS if you do mTLS authentic= ation at the token endpoint. Is that an intentional restriction? To me thes= e two functions seem to be more orthogonal than the spec is hinting at. Lik= e, I could use private_key_jwt or PKCE or magic to authenticate at the RS b= ut use mTLS at the RS, for whatever esoteric reason, like the AS and RS bei= ng in different security domains. Still, functionally, if the client=E2=80= =99s registered parameters are enough to trust for token issuance, they sho= uld be enough to trust for token usage. In other words, have the RS depend = on tls_client_auth_subject_dn etc. instead of "the same certificate th= at was used for mutual TLS at the token endpoint".=C2=A0
Along those lines, =C2=A73 also depends entirely on matching a = specific certificate hash instead of validating a certificate (and possibly= it=E2=80=99s chain) and associated DN. This isn=E2=80=99t in parallel with= the client authentication at the token endpoint, and I=E2=80=99d like to s= ee these come together. Should we have a third certificate validation metho= d in =C2=A72 for =E2=80=9Ccertificate hash=E2=80=9D? Or maybe we should hav= e a separate list for =E2=80=9Cresource_server_auth_method=E2=80=9D for the= client?

In any event, it still feels like there a= re two things that are fighting for attention in this spec: cert-based auth= entication of the client at the token endpoint, and cert-based PoP of the t= oken at the resource.

=C2=A0=E2=80=94 Justin
=

On Jul 28, 2017, at 2:33 PM, Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:

A new draft of &= quot;Mutual TLS Profile for OAuth 2.0" has been published with the cha= nges listed below based on comments and dissuasion in Prague.

= 
   draft-ietf-oauth-mtls-03

   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method =
is for
      the PKI method and introduced "pub_key_tls_client_auth" for=
 the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints


-----= ----- Forwarded message ----------
From: <= /b> <internet-drafts@ietf.org>
Date: Fri, Jul 28, = 2017 at 12:25 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-0= 3.txt
To: i-d= -announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Mutual TLS Profile for OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nat Sakimura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-07-28

Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<= br> =C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for OAu= th
=C2=A0 =C2=A0client authentication to the token endpoint as well as for
=C2=A0 =C2=A0certificate bound sender constrained access tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oaut= h-mtls-03
https://datatracker.ietf.org/doc/= html/draft-ietf-oauth-mtls-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-oauth-mtls-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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 in= tended recipient(s). Any review, use, distribution or disclosure by others = is strictly prohibited.=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.__= _____________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= /blockquote>


=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045fe2d453783c0555b68ff7-- From nobody Tue Aug 1 13:09:27 2017 Return-Path: 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 743B81317CC for ; Tue, 1 Aug 2017 13:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-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 BysbX4RqjikB for ; Tue, 1 Aug 2017 13:09:22 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 42AB0126B71 for ; Tue, 1 Aug 2017 13:09:22 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id l64so12021074pge.5 for ; Tue, 01 Aug 2017 13:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GZjlqOfZ2cikDgbDapQDkuideSoFdPIed+QCXFE2WjA=; b=WgDT9MhlQpUvqI4mVMfVeE8pfWGUr9MXsH7hZPXiUpaxgyKVffwGoWnpAEJWUnW+Kb y3/OaShAXhRSH+SVwTUW3GieYqJIWWQisYfo3KdGC1FfyZUuqU+ad7+xBnufZwSnfrYX rqyrRbGrVPfGCnIZNXTasdnPTE2LHOecEE94c= 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=GZjlqOfZ2cikDgbDapQDkuideSoFdPIed+QCXFE2WjA=; b=EDegWu+Y49p4W/rzFQgEJ83cjQLv0rMImIIhjJzUVrGuDMAFtwvDxt/rmZq8yZ003x BTjBe/Fd53Ycv6BM6dZbrJc0jp+xLZTaOIJqgtf+kCP0tuq7o8N4fSjaLWm2jUsg/bBX dxfWDEC5pISzLAe3IYi7nh6mz7c/xOI9TZJsZQcFPUrOHrgPFbJ2DTdvxynq1nWr+0AT CeeOIFf/Rld/ks7QAj7UfURbPZWIh3iFoCRsYZ85LCVK7yo++nVR2nNIXTD6AHm4F3jG r4Lre2Mitp+pF9DBfHz71fNCgc9aDpKhaHR8mJhTlvPp/gqUm5iFzwpwA1qcOBzj3Xev gmrg== X-Gm-Message-State: AIVw113nSVeX1okvKvXldWjNuzY1XxAhfNkXtulum9fqJDarrQLwaziL VRfarfczTnoOt7JEZyDmvOoMyiWd++yH8bXSzopkSBkuGKHy5XNWAaESeFTyy3ru3ywQN/tlSre /EsN+ X-Received: by 10.99.117.68 with SMTP id f4mr20058768pgn.56.1501618161745; Tue, 01 Aug 2017 13:09:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Tue, 1 Aug 2017 13:08:51 -0700 (PDT) In-Reply-To: References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> From: Brian Campbell Date: Tue, 1 Aug 2017 14:08:51 -0600 Message-ID: To: Denis Cc: oauth Content-Type: multipart/alternative; boundary="f403045cdcc41e9d9e0555b6b9b4" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 20:09:25 -0000 --f403045cdcc41e9d9e0555b6b9b4 Content-Type: text/plain; charset="UTF-8" That access tokens aren't always JWTs means that JWT claims or headers cannot be relied on to figure out the issuer of an arbitrary access token. So it's not viable. That was what I was trying to convey as an answer to the various points and questions you made that were in any way related to the original content of this thread. On Tue, Aug 1, 2017 at 1:54 PM, Denis wrote: > Brian, > > JWT (which is RFC 7519 not 7515 > ) 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 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 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) >> 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 >> introspection endpoint (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 >> & 7522 >> ) 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 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 >>> ) >>> 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 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: >>>> >>>> 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 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 >>>>>> 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.* >>>> >>>> >>>> >>> >>> *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 listOAuth@ietf.orghttps://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.* > > > -- *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.* --f403045cdcc41e9d9e0555b6b9b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --f403043ed1d49a1a7d0555cd0da2-- From nobody Thu Aug 3 03:49:16 2017 Return-Path: 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 99A56131D2C for ; Thu, 3 Aug 2017 03:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Q-Q_HJ32JtfM for ; Thu, 3 Aug 2017 03:49:11 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) (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 444BD131D27 for ; Thu, 3 Aug 2017 03:49:10 -0700 (PDT) Received: from [85.212.1.42] (helo=[10.0.8.4]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ddDge-00013B-8Y; Thu, 03 Aug 2017 12:49:05 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_95AC13F6-387C-43A7-B5FB-911E24E63DFE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 12:48:58 +0200 In-Reply-To: Cc: "" , Brian Campbell To: Justin Richer References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 10:49:16 -0000 --Apple-Mail=_95AC13F6-387C-43A7-B5FB-911E24E63DFE Content-Type: multipart/alternative; boundary="Apple-Mail=_677C0CE5-7696-45ED-937C-409C5E610A85" --Apple-Mail=_677C0CE5-7696-45ED-937C-409C5E610A85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Justin, thanks for reviewing the draft.=20 > Am 01.08.2017 um 21:57 schrieb Brian Campbell = : >=20 > Thanks Justin.=20 >=20 > In my original announcement email, I should have given credit to = Torsten as he made many of the updates in -03. So complements on = improvements as well as blame for issues can be pointed to him as well! >=20 > Your point about document structure is taken and we will look to make = the separation of the client authentication and resource access more = clear in future revisions. The document was aiming for something = conceptually along those same lines already. But it could be made more = clear. >=20 > This could define a new =E2=80=9Ctoken_type=E2=80=9D but other than = having different token type names in messages, I don't know that a new = token_type or HTTP auth scheme that would probably have to come along = with it adds value to the use cases here. However, they would very = likely make deployment of this stuff much more cumbersome and take = longer. Whereas many systems can likely plug in mutual TLS on top of = the existing token_type and HTTP auth scheme without major changes. I'm = strongly inclined to not introduce a new token_type and more inclined to = not do a new HTTP auth scheme.=20 I agree. Although on a conceptual level the sender restricted access = tokens as described in this draft are different, there is no difference = in the HTTP payload. The difference lays completely in the way the TLS = connection is established (which somehow makes the beauty of the = concept). I therefore think introducing a new token type is = inappropriate. But still, the clients needs to treat requests to a RS = using sender constraint access tokens different than requests to a RS = utilizing bearer tokens. I could image the RS may announce its mTLS = support via another metadata parameter = =E2=80=9Emutual_tls_sender_constrained_access_tokens=E2=80=9C in the 401 = response.=20 best regards, Torsten. >=20 > Fair point about breaking out all the registered parameters into their = own hanging list items. It is somewhat inconsistent in that regard now. = Will look to address that in a future revision. >=20 > Using just a certificate hash for mTLS sender constrained access = tokens was intentional to allow mTLS at the resource to be used as a = proof-of-possession method only. It's part of the authorization check at = resource access and deliberately not about authentication with the RS. = Using the hash simplifies the check at the RS to one consistent way of = doing things while allowing for different modes of doing client = authentication at the AS. So the lack of parallelism with the client = authentication at the token endpoint was very much intentional. = Following from that, the need to do mTLS at the token endpoint in order = to get mTLS-bound access tokens for an RS was also kind of intentional. = Though, as =C2=A74.3 = = attempts to describe, a public client could do mTLS at the token = endpoint with a generated self-singed cert to have an access token bound = but not actually authenticate to the token endpoint. You are certainly = right that there are other ways an AS could decide on the certificate to = bind the access token to. And other ways a cnf claim member could = provide for such a binding. But we were aiming to not provide too many = options in the doc. So my thinking here was that this draft is about = mTLS and so saying how to use mTLS for the AS to do the access token = binding seemed like the most appropriate and straightforward approach. = It's not so much that mTLS authentication is needed for the client at = the token endpoint to allow for bound access tokens. But rather that = having mTLS at the token endpoint provides a strong signal of the = certificate to which to bind the issued access token.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer > wrote: > Brian, thanks for the update. This is really coming along! >=20 > I think the spec would benefit from a more clear separation of the = client authentication and resource access sections. They=E2=80=99re = really almost two different but related specs, but there=E2=80=99s = enough overlap that I think that keeping them in the same document is = fine with some structural changes applied. I think the content is by and = large all here, it=E2=80=99s just jumbled together. >=20 > To that end, I think there might be three major sections to this = document (not counting the IANA, security, privacy, and other = boilerplate bits). A suggested breakdown: >=20 > 1) Types of mTLS client auth under consideration. This is where the = definition of public key vs. pki comes in, and where the two = authentication methods are defined for both registration and discovery. = Some implementor=E2=80=99s notes on what kinds of things you need to = store here, including the tls_client_auth_ client metadata extensions. = For better or worse, 7591 defines OAuth=E2=80=99s client model, and not = just for dynamic registration. >=20 > 2) How to use mTLS to authenticate a client. This can be a relatively = short section that says use (1) in the context of getting an access = token at the token endpoint. Here is where you point out that you still = need to send client_id and that the association with the cert=E2=80=99s = DN and the client_id is done at the AS (there=E2=80=99s existing text = for this). >=20 > 3) How to use mTLS to bind an access token. This is a bit more = complicated because it=E2=80=99s the RS that needs to know the binding = between the token and the cert=E2=80=99s DN, so that=E2=80=99s where = you=E2=80=99d define the =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate = side effect of spec history means that the =E2=80=9Ccnf=E2=80=9D claim = for 7662 also gets defined here. This is also where you=E2=80=99d put = the bits about mutual_tls_sender_constrained_access_tokens for discovery = and registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D? > =20 >=20 > A few more comments: >=20 > =C2=A72.3 really should break out all registered parameters into their = own hanging list items (even if you break them up into different = sections like suggested above) >=20 > =C2=A73 seems to say that you can only do mTLS-bound access tokens at = an RS if you do mTLS authentication at the token endpoint. Is that an = intentional restriction? To me these two functions seem to be more = orthogonal than the spec is hinting at. Like, I could use = private_key_jwt or PKCE or magic to authenticate at the RS but use mTLS = at the RS, for whatever esoteric reason, like the AS and RS being in = different security domains. Still, functionally, if the client=E2=80=99s = registered parameters are enough to trust for token issuance, they = should be enough to trust for token usage. In other words, have the RS = depend on tls_client_auth_subject_dn etc. instead of "the same = certificate that was used for mutual TLS at the token endpoint".=20 >=20 > Along those lines, =C2=A73 also depends entirely on matching a = specific certificate hash instead of validating a certificate (and = possibly it=E2=80=99s chain) and associated DN. This isn=E2=80=99t in = parallel with the client authentication at the token endpoint, and I=E2=80= =99d like to see these come together. Should we have a third certificate = validation method in =C2=A72 for =E2=80=9Ccertificate hash=E2=80=9D? Or = maybe we should have a separate list for = =E2=80=9Cresource_server_auth_method=E2=80=9D for the client? >=20 > In any event, it still feels like there are two things that are = fighting for attention in this spec: cert-based authentication of the = client at the token endpoint, and cert-based PoP of the token at the = resource. >=20 > =E2=80=94 Justin >=20 >> On Jul 28, 2017, at 2:33 PM, Brian Campbell = > wrote: >>=20 >> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published = with the changes listed below based on comments and dissuasion in = Prague.=20 >>=20 >> draft-ietf-oauth-mtls-03 = >>=20 >> o Introduced metadata and client registration parameter to = publish >> and request support for mutual TLS sender constrained access >> tokens >> o Added description of two methods of binding the cert and = client, >> PKI and Public Key. >> o Indicated that the "tls_client_auth" authentication method is = for >> the PKI method and introduced "pub_key_tls_client_auth" for the >> Public Key method >> o Added implementation considerations, mainly regarding TLS stack >> configuration and trust chain validation, as well as how to to = do >> binding of access tokens to a TLS client certificate for public >> clients, and considerations around certificate bound access = tokens >> o Added new section to security considerations on cert spoofing >> o Add text suggesting that a new cnf member be defined in the >> future, if hash function(s) other than SHA-256 need to be used = for >> certificate thumbprints >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: > >> Date: Fri, Jul 28, 2017 at 12:25 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >>=20 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Web Authorization Protocol WG of the = IETF. >>=20 >> Title : Mutual TLS Profile for OAuth 2.0 >> Authors : Brian Campbell >> John Bradley >> Nat Sakimura >> Torsten Lodderstedt >> Filename : draft-ietf-oauth-mtls-03.txt >> Pages : 17 >> Date : 2017-07-28 >>=20 >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for OAuth >> client authentication to the token endpoint as well as for >> certificate bound sender constrained access tokens. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 = >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 = >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 = >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> 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 = >=20 >=20 >=20 > 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 --Apple-Mail=_677C0CE5-7696-45ED-937C-409C5E610A85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Justin,

thanks for reviewing the draft. 

Am = 01.08.2017 um 21:57 schrieb Brian Campbell <bcampbell@pingidentity.com>:

Thanks = Justin.

In my original announcement email, = I should have given credit to Torsten as he made many of the updates in = -03. So complements on improvements as well as blame for issues can be = pointed to him as well!

Your point = about document structure is taken and we will look to make the = separation of the client authentication and resource access more clear = in future revisions. The document was aiming for something conceptually = along those same lines already. But it could be made more clear.

This could define a new = =E2=80=9Ctoken_type=E2=80=9D but other than having different token type = names in messages, I don't know that a new token_type or HTTP auth = scheme that would probably have to come along with it adds value to the = use cases here. However, they would very likely make deployment of this = stuff much more cumbersome and take longer.  Whereas many systems = can likely plug in mutual TLS on top of the existing token_type and HTTP = auth scheme without major changes. I'm strongly inclined to not = introduce a new token_type and more inclined to not do a new HTTP auth = scheme.

I agree. Although on a conceptual level the sender = restricted access tokens as described in this draft are different, there = is no difference in the HTTP payload. The difference lays completely in = the way the TLS connection is established (which somehow makes the = beauty of the concept). I therefore think introducing a new token type = is inappropriate. But still, the clients needs to treat requests to a RS = using sender constraint access tokens different than requests to a RS = utilizing bearer tokens. I could image the RS may announce its mTLS = support via another metadata parameter = =E2=80=9Emutual_tls_sender_constrained_access_tokens=E2=80=9C in the 401 = response. 

best = regards,
Torsten.


Fair point about = breaking out all the registered parameters into their own hanging list = items. It is somewhat inconsistent in that regard now. Will look to = address that in a future revision.

Using just a certificate hash for mTLS sender = constrained access tokens was intentional to allow mTLS at the resource = to be used as a proof-of-possession method only. It's part of the = authorization check at resource access and deliberately not about = authentication with the RS. Using the hash simplifies the check at the = RS to one consistent way of doing things while allowing for different = modes of doing client authentication at the AS. So the lack of = parallelism with the client authentication at the token endpoint was = very much intentional. Following from that, the need to do mTLS at the = token endpoint in order to get mTLS-bound access tokens for an RS was = also kind of intentional. Though, as =C2=A74.3 attempts to describe, a = public client could do mTLS at the token endpoint with a generated = self-singed cert to have an access token bound but not actually = authenticate to the token endpoint. You are certainly right that there = are other ways an AS could decide on the certificate to bind the access = token to. And other ways a cnf claim member could provide for such a = binding. But we were aiming to not provide too many options in the doc. = So my thinking here was that this draft is about mTLS and so saying how = to use mTLS for the AS to do the access token binding seemed like the = most appropriate and straightforward approach. It's not so much that = mTLS authentication is needed for the client at the token endpoint to = allow for bound access tokens. But rather that having mTLS at the token = endpoint provides a strong signal of the certificate to which to bind = the issued access token.







On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer = <jricher@mit.edu> wrote:
Brian, thanks for the update. This is really coming = along!

I think the = spec would benefit from a more clear separation of the client = authentication and resource access sections. They=E2=80=99re really = almost two different but related specs, but there=E2=80=99s enough = overlap that I think that keeping them in the same document is fine with = some structural changes applied. I think the content is by and large all = here, it=E2=80=99s just jumbled together.

To that end, I think there might be = three major sections to this document (not counting the IANA, security, = privacy, and other boilerplate bits). A suggested breakdown:

1) Types of mTLS client = auth under consideration. This is where the definition of public key vs. = pki comes in, and where the two authentication methods are defined for = both registration and discovery. Some implementor=E2=80=99s notes on = what kinds of things you need to store here, including the = tls_client_auth_ client metadata extensions. For better or worse, 7591 = defines OAuth=E2=80=99s client model, and not just for dynamic = registration.

2)= How to use mTLS to authenticate a client. This can be a relatively = short section that says use (1) in the context of getting an access = token at the token endpoint. Here is where you point out that you still = need to send client_id and that the association with the cert=E2=80=99s = DN and the client_id is done at the AS (there=E2=80=99s existing text = for this).

3) = How to use mTLS to bind an access token. This is a bit more complicated = because it=E2=80=99s the RS that needs to know the binding between the = token and the cert=E2=80=99s DN, so that=E2=80=99s where you=E2=80=99d = define the =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate side effect of = spec history means that the =E2=80=9Ccnf=E2=80=9D claim for 7662 also = gets defined here. This is also where you=E2=80=99d put the bits about = mutual_tls_sender_constrained_access_tokens for = discovery and registration. Should this be a new =E2=80=9Ctoken_type=E2=80= =9D?
 

A few more comments:

=C2=A72.3 really should break out all = registered parameters into their own hanging list items (even if you = break them up into different sections like suggested above)

=C2=A73 seems to say = that you can only do mTLS-bound access tokens at an RS if you do mTLS = authentication at the token endpoint. Is that an intentional = restriction? To me these two functions seem to be more orthogonal than = the spec is hinting at. Like, I could use private_key_jwt or PKCE or = magic to authenticate at the RS but use mTLS at the RS, for whatever = esoteric reason, like the AS and RS being in different security domains. = Still, functionally, if the client=E2=80=99s registered parameters are = enough to trust for token issuance, they should be enough to trust for = token usage. In other words, have the RS depend on = tls_client_auth_subject_dn etc. instead of "the same certificate that = was used for mutual TLS at the token endpoint". 

Along those lines, =C2=A73= also depends entirely on matching a specific certificate hash instead = of validating a certificate (and possibly it=E2=80=99s chain) and = associated DN. This isn=E2=80=99t in parallel with the client = authentication at the token endpoint, and I=E2=80=99d like to see these = come together. Should we have a third certificate validation method in = =C2=A72 for =E2=80=9Ccertificate hash=E2=80=9D? Or maybe we should have = a separate list for =E2=80=9Cresource_server_auth_method=E2=80=9D for = the client?

In = any event, it still feels like there are two things that are fighting = for attention in this spec: cert-based authentication of the client at = the token endpoint, and cert-based PoP of the token at the = resource.

 =E2=80=94 Justin
On Jul 28, = 2017, at 2:33 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

A= new draft of "Mutual TLS Profile for OAuth 2.0" has been published with = the changes listed below based on comments and dissuasion in Prague. 

   draft-ietf-oauth-mtls-03

   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method is for
      the PKI method and introduced "pub_key_tls_client_auth" for the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jul 28, 2017 at 12:25 PM
Subject: = [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Web Authorization Protocol WG of the = IETF.

        Title          =  : Mutual TLS Profile for OAuth 2.0
        Authors         : = Brian Campbell
                    =       John Bradley
                    =       Nat Sakimura
                    =       Torsten Lodderstedt
        Filename        : = draft-ietf-oauth-mtls-03.txt
        Pages          =  : 17
        Date          =   : 2017-07-28

Abstract:
   This document describes Transport Layer Security (TLS) = mutual
   authentication using X.509 certificates as a mechanism for = OAuth
   client authentication to the token endpoint as well as = for
   certificate bound sender constrained access tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03


Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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



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

That <= font face=3D"Arial">access tokens aren't always JWTs means that JWT cla= ims or headers cannot be relied on to figure out the issuer of an arbitrary= access token. So it's not viable. That was what I was trying to convey= as an answer to the various points and questions you made that were in any= way related to the original content of this thread.

On Tue, = Aug 1, 2017 at 1:54 PM, Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Brian,

JWT (which is RFC 7519 not 7515) does def= ine 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> 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.=C2=A0 Audience is a logical na= me 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.=C2=A0 The text in 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) 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 th= e RS.

RFC 7515 defines the "x5c&qu= ot; (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 Servi= ce (STS) is a service capable of validating and issuing security tokens".
Up to now, the following definition applies: "A Securi= ty 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 Parame= ter 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 introspection endpoint (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 & 7522) 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.=C2=A0

It's difficult to articulate but that's an attempt to explain how things are in the draft today and why.=C2=A0

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 &quo= t;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> wrote:

So, you're saying the STS has to define = a subject_type for each external token the client wants to exchange from?=C2=A0 A type that is potentially proprietary and different between each and every STS?=C2=A0 O= n 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.=C2=A0 1) a proprieta= ry 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?=C2=A0 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.=C2=A0 I still think a "subject_issuer" and "requeste= d_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:a= ccess_token type is an "indicator that the tok= en is a typical OAuth access token issued by the authorization server in question" (see near the end of = 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 <bbu= rke@redhat.com> wrote:

Thanks for replying,

The Introduction of the spec implies that inter-security-domain exchange is supported: " 

 A Security Tok=
en 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 in=
ternal 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 exter=
nal domain?

i.e

subject_token: <opaque-string>

subject_token_type: urn:ietf:params:oauth:token-ty<= wbr>pe:access-token

There's just no way for th= e STS to know where the subject_token came from because the subject_token can be completely opaque.=C2=A0=

Now, on the flip side, if you are converting from an internal token to an external one, the audience parameter is just too undefined.=C2=A0 For example, h= ow could you specify that you want a token for an external client of an external issuer.=C2=A0 Client ids are opaque in OAuth, and issuer id isn't even something tha= t is defined at all.=C2=A0 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.=C2=A0=C2=A0 = If you don't like "issuer&quo= t; 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 <<= a href=3D"mailto:bburke@redhat.com" target=3D"_blank">bburke@redhat.com= > wrote:
Should probably have a "subject_issuer&= quot; and "actor_issue= r" as well as the "requested_issue= r" 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 a= t Draft 9 of the token-exchange spec.=C2=A0 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.=C2=A0 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_i= ssuer" identifier?=C2=A0 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
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


CONFI= DENTIALITY 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.=C2=A0 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.=C2=A0 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.=C2= =A0 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
h=
ttps://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oa= uth



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.=C2=A0 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.




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045cdcc41e9d9e0555b6b9b4-- From nobody Tue Aug 1 13:11:05 2017 Return-Path: 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 5419612778D for ; Tue, 1 Aug 2017 13:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 o9vF0WtZ5sWx for ; Tue, 1 Aug 2017 13:11:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 BADB9126B71 for ; Tue, 1 Aug 2017 13:10:59 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v71KAsuY027564 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 1 Aug 2017 20:10:54 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v71KArOB001290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 1 Aug 2017 20:10:54 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v71KArOB023339; Tue, 1 Aug 2017 20:10:53 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Aug 2017 13:10:52 -0700 From: Phil Hunt Message-Id: <73394F38-606B-45EC-8F6B-5050BE59CD46@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_67244178-0A77-4FB3-A22F-E96FADA3056F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 13:10:51 -0700 In-Reply-To: <43fcb3b7-f0ea-47f3-b0f4-9d0f33df7d7f@free.fr> Cc: oauth@ietf.org To: Denis References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> <43fcb3b7-f0ea-47f3-b0f4-9d0f33df7d7f@free.fr> X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 20:11:04 -0000 --Apple-Mail=_67244178-0A77-4FB3-A22F-E96FADA3056F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 inline... Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 1, 2017, at 12:56 PM, Denis wrote: >=20 > Phil, >=20 > Originally, with OAuth the AS and the RS were co-located. Many = additional RFCs made extensions and this assumption is no more valid. >=20 > draft-ietf-oauth-token-exchange-09 is now opening a pandora box where = an even more complex situation is envisaged (without explicitly stating = it) > there would be one client, one RS and several AS/STS with = relationships between AS/STS from different domains (don't ask me what a = domain=20 > might mean in this context). I don=E2=80=99t think that is true. It allows a resource server to act = on behalf of the user further on down the line. The user context is = already well known. As always, it can be mis-used. Maybe there is an argument for more = guidance? >=20 > See my other post about privacy in the case where a single AS/STS is = involved in a transaction. It is under the following topic : > How could an IdP create an id token for one audience RP without = knowing for which RP ?=20 > The topic was raised at the last OAuth Workshop in Z=C3=BCrich by a = student from ETH Z=C3=BCrich. In OIDC, the audience is *always* the client. If you are grabbing an ID = Token to then relay it to another RP, then you are into a dual-audience = thing which is doable but falls outside the specifications AFAIK. I have seen a lot of bad patterns where mobile clients are getting ID = Tokens and simply passing them on to a resource server. The resource = server cannot validate the audience leading to all sorts of problem. A = better method is the AppAuth pattern. >=20 > In OAuth there is currently no RFC which provides a response to that = question. A specification based on OAuth, OpenID Connect,=20 > is using the concept of an IdP (Identity Provider). Currently, since = there is no standardized way to address this concern, any IdP will be = able=20 > to act as Big Brother: it will know where the access tokens will be = used. So tracking the activities of the clients will be straightforward. So the way forward might be to put forward an individual draft and see = if anyone in the WG wants to work on it in a future charter? > Addressing the same question when multiple AS/STS would be involved = should only be discussed, once we a solution is defined=20 > in the case where a single AS/STS is involved. Before doing this, we = would need to define an architecture.=20 >=20 > 10 years ago, the IETF was only dealing with security considerations. = Nowadays, it also has to deal with privacy considerations. This seems like an argument for new work.=20 >=20 > Denis=20 >=20 >> Denis, >>=20 >> Why is privacy a concern? OAuth is designed to have the Authorization = Server be the issuer of tokens for a specific set of resource servers. = The AS represents users on the Resource server. It does not represent = users of the client - though they are often the same physical person, = they are often different authenticated subjects. =20 >>=20 >> Of course, there are profiles of OAuth which change this = relationship, but the foundational assumption in RFC6749 is the AS is = usually associated with the RS. >>=20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect & Standards >> @independentid >> www.independentid.com = phil.hunt@o= racle.com >>> On Aug 1, 2017, at 3:53 AM, Denis > wrote: >>>=20 >>> Hello Brian, >>>=20 >>>> 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.=20 >>>>=20 >>>> 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= = about those parameters = attempts to describe that in an intelligible way. Though there's likely = always room for improvement. >>>=20 >>> 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. >>>=20 >>>> 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.=20 >>>=20 >>> RFC 7515 defines the major fields of a JWT.=20 >>>=20 >>>> Although Token Introspection (RFC 7662) = = 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.=20 >>>=20 >>> RFC 7515 defines the "x5c" (X.509 Certificate Chain) Header = Parameter in section 4.1.6: this parameter indicates where the token is = from. >>>=20 >>>> For an AS/STS to validate an OAuth access token from a different = AS, it is in a similar situation as an RS.=20 >>> 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)=20 >>> any AS/STS. >>>=20 >>>> 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".=20 >>>=20 >>> I believe that I am now starting to understand why you made these = suggestions.=20 >>>=20 >>>> There are maybe different ways that could be conveyed but some = means at least would be needed to indicate the access token issuer.=20 >>>=20 >>> The "x5c" Header Parameter is such another way. When used, it should = not conflict with any other parameter. >>>=20 >>>> Then the receiving AS/STS would have to call the issuing AS's token = introspection endpoint (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 = & = 7522 = ) = 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. =20 >>>>=20 >>>> It's difficult to articulate but that's an attempt to explain how = things are in the draft today and why. =20 >>>=20 >>> 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. >>>=20 >>> 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 ? >>>=20 >>> 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". >>>=20 >>> The core of problem is well beyond the simple addition of one or two = parameters.=20 >>>=20 >>>> 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? >>>=20 >>> 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. >>>=20 >>> Denis >>>=20 >>>> On Sat, Jul 29, 2017 at 8:46 AM, Bill Burke > 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. >>>>=20 >>>>=20 >>>> 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 = ) 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. >>>>>=20 >>>>> On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke > 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. >>>>> " >>>>>=20 >>>>> 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 >>>>>=20 >>>>> subject_token: >>>>>=20 >>>>> subject_token_type: urn:ietf:params:oauth:token-type:access-token >>>>>=20 >>>>> There's just no way for the STS to know where the subject_token = came from because the subject_token can be completely opaque. =20 >>>>> 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? >>>>>=20 >>>>> Thanks for replying, >>>>>=20 >>>>> Bill >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 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.=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke > wrote: >>>>>> Should probably have a "subject_issuer" and "actor_issuer" as = well as the "requested_issuer" too. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 7/26/17 6:44 PM, Bill Burke wrote: >>>>>> Hi all, >>>>>>=20 >>>>>> I'm looking at Draft 9 of the token-exchange spec. How would one = build a request to: >>>>>>=20 >>>>>> * exchange a token issued by a different domain to a client = managed by the authorization server. >>>>>>=20 >>>>>> * 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. >>>>>>=20 >>>>>> * exchange a token issued by a different issuer for a token of a = different issuer and client. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Bill >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>> 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.=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 --Apple-Mail=_67244178-0A77-4FB3-A22F-E96FADA3056F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 inline...
Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Aug 1, 2017, at 12:56 PM, Denis <denis.ietf@free.fr> = wrote:

=20 =20 =20
Phil,

Originally, with OAuth the AS and the RS were co-located. Many additional RFCs made extensions and this assumption is no more valid.

draft-ietf-oauth-token-exchange-09 is now opening a pandora box where an even more complex situation is envisaged (without explicitly stating it)
there would be one client, one RS and several AS/STS with relationships between AS/STS from different domains (don't ask me what a domain
might mean in this context).

I = don=E2=80=99t think that is true. It allows a resource server to act on = behalf of the user further on down the line.  The user context is = already well known.

As always, it = can be mis-used.  Maybe there is an argument for more guidance?

See my other post about privacy in the case where a single AS/STS is involved in a transaction. It is under the following topic :
How could an IdP create an id = token for one audience RP without knowing for which RP ?
The topic was raised at the last OAuth Workshop in Z=C3=BCrich by = a student from ETH Z=C3=BCrich.

In OIDC, the audience is *always* the client. =  If you are grabbing an ID Token to then relay it to another RP, = then you are into a dual-audience thing which is doable but falls = outside the specifications AFAIK.

I = have seen a lot of bad patterns where mobile clients are getting ID = Tokens and simply passing them on to a resource server.  The = resource server cannot validate the audience leading to all sorts of = problem. A better method is the AppAuth pattern.

In OAuth there is currently no RFC which provides a response to that question. A specification based on OAuth, OpenID Connect,
is using the concept of an IdP (Identity Provider). Currently, since there is no standardized way to address this concern, any IdP will be able
to act as Big  Brother: it will know where the access tokens = will be used. So tracking the activities of the clients will be straightforward.

So the way forward might be to put forward an = individual draft and see if anyone in the WG wants to work on it in a = future charter?

Addressing the same question when multiple AS/STS would be involved should only be discussed, once we a solution is defined =
in the case where a single AS/STS is involved. Before doing this, we would need to define an architecture.

10 years ago, the IETF was only dealing with security considerations. Nowadays, it also has to deal with privacy considerations.

This = seems like an argument for new work. 

Denis

=20 Denis,

Why is privacy a concern? OAuth is designed to = have the Authorization Server be the issuer of tokens for a specific set of resource servers.  The AS represents users on the Resource server.  It does not represent users of the client = - though they are often the same physical person, they are often different authenticated subjects.  

Of course, there are profiles of OAuth which = change this relationship, but the foundational assumption in RFC6749 is the AS is usually associated with the RS.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Aug 1, 2017, at 3:53 AM, Denis <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 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) 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 introspection endpoint (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 & 7522) 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> 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) = 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> 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> 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
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.



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
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



= --Apple-Mail=_67244178-0A77-4FB3-A22F-E96FADA3056F-- From nobody Tue Aug 1 14:45:52 2017 Return-Path: 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 1258E129B40 for ; Tue, 1 Aug 2017 14:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 kps0o02kDKN3 for ; Tue, 1 Aug 2017 14:45:46 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 0AF9F129B43 for ; Tue, 1 Aug 2017 14:45:45 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id t37so17080742qtg.5 for ; Tue, 01 Aug 2017 14:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=uFeaeM/2dm4aPAyy1UM77pAcOqg54NGzs8yqmZ8QgoE=; b=giECjb/7YNu5pQO6OUyAMCvggQ2pcX5bSuaui/v4gruhZlcUYJssfXBeem+QxoH8IM YML+c1BfGGntJ4rB2O33k/QAaGg0luhgacsyFcfPpbWx8mEcaCn87DgzEY5Ze1p7+4lP esHF6CvBxmtmdrGdDB1CNgZvl4b/eHkkpQZ2BHzmQNDlLnFb2YD2Qm/IvjG/owud+7ZT 7mPL+PlM9AWpYVH8TDiAQ34xh8dq1frLxKQvk/wwFmGmDgA8Wqsc5njE1ayT4FLjFWtn Z/8ZmviysKD9qeFmaJDOD13j5qf7nt1iWT9yBpXpLUNvZJ60KEhNBPHgn9ANQyOU+XNt SOQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=uFeaeM/2dm4aPAyy1UM77pAcOqg54NGzs8yqmZ8QgoE=; b=GSbx/wOGpGjtIKAeDXThEYUEn6SdGRSSUU4wps/2mW64UDGfiwUZW6MlxozGUwT+cs /NmOAhE8jCOpekGvqhB0LWkKdVGbvkEJaoHKdMkBqdzm68d3GITJBQ7fiDhW96sZlNtD 4iSsxm3nv/kSaJGtvkOPnOY7NWgg/5ZExl/5iaJ9mXZwsKg/VkwedwRnNR1DtJzBcVJM 9TD1478VDGYTuKkG5etzu1yh66W2WPTkKyqm6AaWpWy/posdW89+dv0NBSUibnkgprt2 vcTjdL5AwZetpBJ+ldP0nJ/jCHsnGkwXkdiZi8zCatUQiauKYmNqQEflg5DzWUhPyuvo eXow== X-Gm-Message-State: AIVw111hUwOCY7DbDZgx+roVUjVa/fkvpCOpOm0QQhNFisHW3oSh8Noq gDyErEM1qev0UPFAu/FP5g== X-Received: by 10.200.53.251 with SMTP id l56mr11439350qtb.82.1501623944564; Tue, 01 Aug 2017 14:45:44 -0700 (PDT) Received: from [192.168.8.102] ([181.201.103.216]) by smtp.gmail.com with ESMTPSA id q4sm8041515qtf.78.2017.08.01.14.45.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 14:45:43 -0700 (PDT) From: John Bradley Message-Id: <188AD0BD-1DBA-46F2-99F6-067DE187B920@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 1 Aug 2017 17:45:40 -0400 In-Reply-To: Cc: Justin Richer , "" To: Brian Campbell References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113ef720d61c590555b81199" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 21:45:50 -0000 --001a113ef720d61c590555b81199 Content-Type: multipart/alternative; boundary="Apple-Mail=_F1731CA0-2F0B-4B77-9D5A-1C819E36AD36" --Apple-Mail=_F1731CA0-2F0B-4B77-9D5A-1C819E36AD36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Brian on the points about the difference between validating = the certificate at the AS for client authentication and the RS. This = was defiantly intentional. =20 Lets face it people do a crap job of validating certificates in general. = While browsers validating TLS certificates is not bad for the most = part, asking developers to do PKIX validation is almost always going to = go wrong in deployment some significant percentage of the time. The idea is to have the AS do all the heavy lifting and allow the RS to = be as dumb as possible. It should not need to check certificate expiry = or other validity. It should do a simple compare and be done with it. = If people want something else fine but we should not add extra options = for edge cases that are likely to go wrong. In the SAML R&E community using bear keys in meta-data rather than CA = certificates is the preferred option to avoid runtime certificate issues = and only validate certificates for meta-data. I personally would be happiest if the AS also just compared a thumbprint = of the cert based on a registered HTTPS JWKS_URI and validate any cert = at that level where things are better understood and OCSP pinning etc is = available. Cutting out the AS validating the cert via PKIX was a bridge to far for = banking due to perceived EU digital signature regulations. However it = is fragile and will cause issues. We struck a balance. The same is true about requiring mutual TLS at the AS. Yes you could do = it other ways, however that requires more complexity passing the cert to = the AS. This is simple and harder to mess up. This is the striped down 80% spec without the chrome hood ornament. = The feeding is that if you want mutual TLS then doing it on all the legs = is not a huge burden. Mobile clients can use it via dynamic registration if there is a real = use case. In general the authors still think that token binding will be the more = mass market consumer option.=20 This is intended to fill the need for people that are forced to use MTLS = by regulation or can=E2=80=99t wait to deploy. It is always tempting to add features, I am perhaps one of worst = perpetrators of that. =20 This we wanted to be simple enough to cover the EU banking use case and = get implemented and deployed in a reasonable amount of time. John B. > On Aug 1, 2017, at 3:57 PM, Brian Campbell = wrote: >=20 > Thanks Justin.=20 >=20 > In my original announcement email, I should have given credit to = Torsten as he made many of the updates in -03. So complements on = improvements as well as blame for issues can be pointed to him as well! >=20 > Your point about document structure is taken and we will look to make = the separation of the client authentication and resource access more = clear in future revisions. The document was aiming for something = conceptually along those same lines already. But it could be made more = clear. >=20 > This could define a new =E2=80=9Ctoken_type=E2=80=9D but other than = having different token type names in messages, I don't know that a new = token_type or HTTP auth scheme that would probably have to come along = with it adds value to the use cases here. However, they would very = likely make deployment of this stuff much more cumbersome and take = longer. Whereas many systems can likely plug in mutual TLS on top of = the existing token_type and HTTP auth scheme without major changes. I'm = strongly inclined to not introduce a new token_type and more inclined to = not do a new HTTP auth scheme.=20 >=20 > Fair point about breaking out all the registered parameters into their = own hanging list items. It is somewhat inconsistent in that regard now. = Will look to address that in a future revision. >=20 > Using just a certificate hash for mTLS sender constrained access = tokens was intentional to allow mTLS at the resource to be used as a = proof-of-possession method only. It's part of the authorization check at = resource access and deliberately not about authentication with the RS. = Using the hash simplifies the check at the RS to one consistent way of = doing things while allowing for different modes of doing client = authentication at the AS. So the lack of parallelism with the client = authentication at the token endpoint was very much intentional. = Following from that, the need to do mTLS at the token endpoint in order = to get mTLS-bound access tokens for an RS was also kind of intentional. = Though, as =C2=A74.3 = = attempts to describe, a public client could do mTLS at the token = endpoint with a generated self-singed cert to have an access token bound = but not actually authenticate to the token endpoint. You are certainly = right that there are other ways an AS could decide on the certificate to = bind the access token to. And other ways a cnf claim member could = provide for such a binding. But we were aiming to not provide too many = options in the doc. So my thinking here was that this draft is about = mTLS and so saying how to use mTLS for the AS to do the access token = binding seemed like the most appropriate and straightforward approach. = It's not so much that mTLS authentication is needed for the client at = the token endpoint to allow for bound access tokens. But rather that = having mTLS at the token endpoint provides a strong signal of the = certificate to which to bind the issued access token.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer > wrote: > Brian, thanks for the update. This is really coming along! >=20 > I think the spec would benefit from a more clear separation of the = client authentication and resource access sections. They=E2=80=99re = really almost two different but related specs, but there=E2=80=99s = enough overlap that I think that keeping them in the same document is = fine with some structural changes applied. I think the content is by and = large all here, it=E2=80=99s just jumbled together. >=20 > To that end, I think there might be three major sections to this = document (not counting the IANA, security, privacy, and other = boilerplate bits). A suggested breakdown: >=20 > 1) Types of mTLS client auth under consideration. This is where the = definition of public key vs. pki comes in, and where the two = authentication methods are defined for both registration and discovery. = Some implementor=E2=80=99s notes on what kinds of things you need to = store here, including the tls_client_auth_ client metadata extensions. = For better or worse, 7591 defines OAuth=E2=80=99s client model, and not = just for dynamic registration. >=20 > 2) How to use mTLS to authenticate a client. This can be a relatively = short section that says use (1) in the context of getting an access = token at the token endpoint. Here is where you point out that you still = need to send client_id and that the association with the cert=E2=80=99s = DN and the client_id is done at the AS (there=E2=80=99s existing text = for this). >=20 > 3) How to use mTLS to bind an access token. This is a bit more = complicated because it=E2=80=99s the RS that needs to know the binding = between the token and the cert=E2=80=99s DN, so that=E2=80=99s where = you=E2=80=99d define the =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate = side effect of spec history means that the =E2=80=9Ccnf=E2=80=9D claim = for 7662 also gets defined here. This is also where you=E2=80=99d put = the bits about mutual_tls_sender_constrained_access_tokens for discovery = and registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D? > =20 >=20 > A few more comments: >=20 > =C2=A72.3 really should break out all registered parameters into their = own hanging list items (even if you break them up into different = sections like suggested above) >=20 > =C2=A73 seems to say that you can only do mTLS-bound access tokens at = an RS if you do mTLS authentication at the token endpoint. Is that an = intentional restriction? To me these two functions seem to be more = orthogonal than the spec is hinting at. Like, I could use = private_key_jwt or PKCE or magic to authenticate at the RS but use mTLS = at the RS, for whatever esoteric reason, like the AS and RS being in = different security domains. Still, functionally, if the client=E2=80=99s = registered parameters are enough to trust for token issuance, they = should be enough to trust for token usage. In other words, have the RS = depend on tls_client_auth_subject_dn etc. instead of "the same = certificate that was used for mutual TLS at the token endpoint".=20 >=20 > Along those lines, =C2=A73 also depends entirely on matching a = specific certificate hash instead of validating a certificate (and = possibly it=E2=80=99s chain) and associated DN. This isn=E2=80=99t in = parallel with the client authentication at the token endpoint, and I=E2=80= =99d like to see these come together. Should we have a third certificate = validation method in =C2=A72 for =E2=80=9Ccertificate hash=E2=80=9D? Or = maybe we should have a separate list for = =E2=80=9Cresource_server_auth_method=E2=80=9D for the client? >=20 > In any event, it still feels like there are two things that are = fighting for attention in this spec: cert-based authentication of the = client at the token endpoint, and cert-based PoP of the token at the = resource. >=20 > =E2=80=94 Justin >=20 >> On Jul 28, 2017, at 2:33 PM, Brian Campbell = > wrote: >>=20 >> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published = with the changes listed below based on comments and dissuasion in = Prague.=20 >>=20 >> draft-ietf-oauth-mtls-03 = >>=20 >> o Introduced metadata and client registration parameter to = publish >> and request support for mutual TLS sender constrained access >> tokens >> o Added description of two methods of binding the cert and = client, >> PKI and Public Key. >> o Indicated that the "tls_client_auth" authentication method is = for >> the PKI method and introduced "pub_key_tls_client_auth" for the >> Public Key method >> o Added implementation considerations, mainly regarding TLS stack >> configuration and trust chain validation, as well as how to to = do >> binding of access tokens to a TLS client certificate for public >> clients, and considerations around certificate bound access = tokens >> o Added new section to security considerations on cert spoofing >> o Add text suggesting that a new cnf member be defined in the >> future, if hash function(s) other than SHA-256 need to be used = for >> certificate thumbprints >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: > >> Date: Fri, Jul 28, 2017 at 12:25 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >>=20 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Web Authorization Protocol WG of the = IETF. >>=20 >> Title : Mutual TLS Profile for OAuth 2.0 >> Authors : Brian Campbell >> John Bradley >> Nat Sakimura >> Torsten Lodderstedt >> Filename : draft-ietf-oauth-mtls-03.txt >> Pages : 17 >> Date : 2017-07-28 >>=20 >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for OAuth >> client authentication to the token endpoint as well as for >> certificate bound sender constrained access tokens. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 = >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 = >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 = >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> 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 = >=20 >=20 >=20 > 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 = --Apple-Mail=_F1731CA0-2F0B-4B77-9D5A-1C819E36AD36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I agree with Brian on the points about the difference between = validating the certificate at the AS for client authentication and the = RS.  This was defiantly intentional.   

Lets face it people do a crap job of = validating certificates in general.  While browsers validating TLS = certificates is not bad for the most part, asking developers to do PKIX = validation is almost always going to go wrong in deployment some = significant percentage of the time.

The idea is to have the AS do all the = heavy lifting and allow the RS to be as dumb as possible.  It = should not need to check certificate expiry or other validity.  It = should do a simple compare and be done with it.   If people want = something else fine but we should not add extra options for edge cases = that are likely to go wrong.

In the SAML R&E community using = bear keys in meta-data rather than CA certificates is the preferred = option to avoid runtime certificate issues and only validate = certificates for meta-data.

I personally would be happiest if the AS also just compared = a thumbprint of the cert based on a registered HTTPS JWKS_URI and = validate any cert at that level where things are better understood and = OCSP pinning etc is available.

Cutting out the AS validating the cert = via PKIX was a bridge to far for banking due to perceived EU digital = signature regulations.  However it is fragile and will cause = issues.

We = struck a balance.

The same is true about requiring mutual TLS at the AS. =  Yes you could do it other ways, however that requires more = complexity passing the cert to the AS.   This is simple and harder = to mess up.

This= is the striped down 80% spec without the chrome hood ornament.   =  The feeding is that if you want mutual TLS then doing it on all = the legs is not a huge burden.

Mobile clients can use it via dynamic = registration if there is a real use case.

In general the authors still think that = token binding will be the more mass market consumer = option. 

This is intended to fill the need for people that are forced = to use MTLS by regulation or can=E2=80=99t wait to deploy.

It is always tempting to = add features,  I am perhaps one of worst perpetrators of that. =   

This we wanted to be simple enough to cover the EU banking = use case and get implemented and deployed in a reasonable amount of = time.

John = B.
On Aug 1, 2017, at 3:57 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Thanks = Justin. 

In my original announcement email, I should = have given credit to Torsten as he made many of the updates in -03. So = complements on improvements as well as blame for issues can be pointed = to him as well!

Your point about = document structure is taken and we will look to make the separation of = the client authentication and resource access more clear in future = revisions. The document was aiming for something conceptually along = those same lines already. But it could be made more clear.

This could define a new = =E2=80=9Ctoken_type=E2=80=9D but other than having different token type = names in messages, I don't know that a new token_type or HTTP auth = scheme that would probably have to come along with it adds value to the = use cases here. However, they would very likely make deployment of this = stuff much more cumbersome and take longer.  Whereas many systems = can likely plug in mutual TLS on top of the existing token_type and HTTP = auth scheme without major changes. I'm strongly inclined to not = introduce a new token_type and more inclined to not do a new HTTP auth = scheme. 

Fair point about = breaking out all the registered parameters into their own hanging list = items. It is somewhat inconsistent in that regard now. Will look to = address that in a future revision.

Using just a certificate hash for mTLS sender = constrained access tokens was intentional to allow mTLS at the resource = to be used as a proof-of-possession method only. It's part of the = authorization check at resource access and deliberately not about = authentication with the RS. Using the hash simplifies the check at the = RS to one consistent way of doing things while allowing for different = modes of doing client authentication at the AS. So the lack of = parallelism with the client authentication at the token endpoint was = very much intentional. Following from that, the need to do mTLS at the = token endpoint in order to get mTLS-bound access tokens for an RS was = also kind of intentional. Though, as =C2=A74.3 attempts to describe, a = public client could do mTLS at the token endpoint with a generated = self-singed cert to have an access token bound but not actually = authenticate to the token endpoint. You are certainly right that there = are other ways an AS could decide on the certificate to bind the access = token to. And other ways a cnf claim member could provide for such a = binding. But we were aiming to not provide too many options in the doc. = So my thinking here was that this draft is about mTLS and so saying how = to use mTLS for the AS to do the access token binding seemed like the = most appropriate and straightforward approach. It's not so much that = mTLS authentication is needed for the client at the token endpoint to = allow for bound access tokens. But rather that having mTLS at the token = endpoint provides a strong signal of the certificate to which to bind = the issued access token. 







On Mon, Jul 31, 2017 at = 2:18 PM, Justin Richer <jricher@mit.edu> wrote:
Brian, thanks for the update. This is really coming = along!

I think the = spec would benefit from a more clear separation of the client = authentication and resource access sections. They=E2=80=99re really = almost two different but related specs, but there=E2=80=99s enough = overlap that I think that keeping them in the same document is fine with = some structural changes applied. I think the content is by and large all = here, it=E2=80=99s just jumbled together.

To that end, I think there might be = three major sections to this document (not counting the IANA, security, = privacy, and other boilerplate bits). A suggested breakdown:

1) Types of mTLS client = auth under consideration. This is where the definition of public key vs. = pki comes in, and where the two authentication methods are defined for = both registration and discovery. Some implementor=E2=80=99s notes on = what kinds of things you need to store here, including the = tls_client_auth_ client metadata extensions. For better or worse, 7591 = defines OAuth=E2=80=99s client model, and not just for dynamic = registration.

2)= How to use mTLS to authenticate a client. This can be a relatively = short section that says use (1) in the context of getting an access = token at the token endpoint. Here is where you point out that you still = need to send client_id and that the association with the cert=E2=80=99s = DN and the client_id is done at the AS (there=E2=80=99s existing text = for this).

3) = How to use mTLS to bind an access token. This is a bit more complicated = because it=E2=80=99s the RS that needs to know the binding between the = token and the cert=E2=80=99s DN, so that=E2=80=99s where you=E2=80=99d = define the =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate side effect of = spec history means that the =E2=80=9Ccnf=E2=80=9D claim for 7662 also = gets defined here. This is also where you=E2=80=99d put the bits about = mutual_tls_sender_constrained_access_tokens for = discovery and registration. Should this be a new =E2=80=9Ctoken_type=E2=80= =9D?
 

A few more comments:

=C2=A72.3 really should break out all = registered parameters into their own hanging list items (even if you = break them up into different sections like suggested above)

=C2=A73 seems to say = that you can only do mTLS-bound access tokens at an RS if you do mTLS = authentication at the token endpoint. Is that an intentional = restriction? To me these two functions seem to be more orthogonal than = the spec is hinting at. Like, I could use private_key_jwt or PKCE or = magic to authenticate at the RS but use mTLS at the RS, for whatever = esoteric reason, like the AS and RS being in different security domains. = Still, functionally, if the client=E2=80=99s registered parameters are = enough to trust for token issuance, they should be enough to trust for = token usage. In other words, have the RS depend on = tls_client_auth_subject_dn etc. instead of "the same certificate that = was used for mutual TLS at the token endpoint". 

Along those lines, =C2=A73= also depends entirely on matching a specific certificate hash instead = of validating a certificate (and possibly it=E2=80=99s chain) and = associated DN. This isn=E2=80=99t in parallel with the client = authentication at the token endpoint, and I=E2=80=99d like to see these = come together. Should we have a third certificate validation method in = =C2=A72 for =E2=80=9Ccertificate hash=E2=80=9D? Or maybe we should have = a separate list for =E2=80=9Cresource_server_auth_method=E2=80=9D for = the client?

In = any event, it still feels like there are two things that are fighting = for attention in this spec: cert-based authentication of the client at = the token endpoint, and cert-based PoP of the token at the = resource.

 =E2=80=94 Justin
On Jul 28, = 2017, at 2:33 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

A= new draft of "Mutual TLS Profile for OAuth 2.0" has been published with = the changes listed below based on comments and dissuasion in = Prague. 

   draft-ietf-oauth-mtls-03

   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method is for
      the PKI method and introduced "pub_key_tls_client_auth" for the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: = Fri, Jul 28, 2017 at 12:25 PM
Subject: [OAUTH-WG] I-D = Action: draft-ietf-oauth-mtls-03.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work = item of the Web Authorization Protocol WG of the IETF.

        Title      =      : Mutual TLS Profile for OAuth 2.0
        Authors      =    : Brian Campbell
        =                   John Bradley
                =           Nat Sakimura
                =           Torsten Lodderstedt
        Filename    =     : draft-ietf-oauth-mtls-03.txt
    =     Pages      =      : 17
        Date      =       : 2017-07-28

Abstract:
   This document describes = Transport Layer Security (TLS) mutual
  =  authentication using X.509 certificates as a mechanism for = OAuth
   client authentication to the token = endpoint as well as for
   certificate bound = sender constrained access tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03


Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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



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

= --Apple-Mail=_F1731CA0-2F0B-4B77-9D5A-1C819E36AD36-- --001a113ef720d61c590555b81199 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIPB4roxjcwV2aVAjg5n3NohBz2Cq rOCKcIJPqXGcD/gOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwMTIxNDU0NVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQA49dtxiPvyMcHy3JJR5GyqOOroKrLRewOaVOJEXrPDr9Vt JC9Zy5oSpASGAW/JrKIti0OPO86Y/j7uqE/rLFQGK/60HRSJWQ8Bk2UVbyWjhDepBFxjEJJ2g5mW EYumQ6sIBvGfKk4OAYfw7H/aBLWFiNWqDBsKFQ4LAduxTRKkTa39B3gz9BjNn+XuHdjxBdXjMN0d l6xjilGXHNUGeN/tXx/iBKkIzAlwWrV1P9pQDyckGylFbkblILW6Rc1PUe1vEALx2j3YkvF7LpGC DpinRytidHhvFrB24ynCqPk9NhGVKt0QlOahnYAxNG24zBMQnPP3oSpgv/TolDYQJ5AX --001a113ef720d61c590555b81199-- From nobody Wed Aug 2 00:54:16 2017 Return-Path: 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 D44D4131C04 for ; Wed, 2 Aug 2017 00:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 suUIgl_pkaR8 for ; Wed, 2 Aug 2017 00:54:12 -0700 (PDT) Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (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 5A83A128D86 for ; Wed, 2 Aug 2017 00:54:12 -0700 (PDT) Received: from [192.168.0.101] ([78.130.190.73]) by :SMTPAUTH: with SMTP id coTLdTb64RabxcoTMd5EuK; Wed, 02 Aug 2017 00:53:41 -0700 To: oauth@ietf.org References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Wed, 2 Aug 2017 10:53:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D8EFDAEBBB0C9D847B45EB9B" Content-Language: en-US X-CMAE-Envelope: MS4wfEtjai5g15jk+qdZPP4HyLo1Sy2PBUFxtIYQAwTGrYJI5UjPktD+kXwUHShNx7cAIyZ1YpjpxNTiy8kilDqeWEzlr6huKSr5eljP7JlDi+zSxzH/0hAA VG366TDymC3BSsNdhdmDeEd4WNxcSVza9ZE1JEzDPv/UEihPajnO+u0M Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 07:54:15 -0000 This is a multi-part message in MIME format. --------------D8EFDAEBBB0C9D847B45EB9B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks everyone for the update! Having a clear distinction between the PKIX vs public key bound methods will help interop, implementers' job, and it also appears good for security. Questions: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.= 3 > where the X.509 certificates are represented using the "x5c" parameter = from [RFC7517 ] For the public key method, is it really necessary for the client to include its certificate in the JWK x5c parameter? This will make implementation harder for developers, and I'm not sure it adds anything in terms of security. Registering the public key parameters seems sufficient to me. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.= 1 > When used in conjunction with a trusted X.509 certificate source, it al= so allows the client to rotate its X.509 certificates without the need to= change its respective authentication data at the authorization server. I don't understand this - "in conjunction with a trusted X.509 certificate source" Thanks, Vladimir On 28/07/17 21:33, Brian Campbell wrote: > A new draft of "Mutual TLS Profile for OAuth 2.0" has been published wi= th > the changes listed below based on comments and dissuasion in Prague. > > draft-ietf-oauth-mtls-03 > > > o Introduced metadata and client registration parameter to publish > and request support for mutual TLS sender constrained access > tokens > o Added description of two methods of binding the cert and client, > PKI and Public Key. > o Indicated that the "tls_client_auth" authentication method is for= > the PKI method and introduced "pub_key_tls_client_auth" for the > Public Key method > o Added implementation considerations, mainly regarding TLS stack > configuration and trust chain validation, as well as how to to do= > binding of access tokens to a TLS client certificate for public > clients, and considerations around certificate bound access token= s > o Added new section to security considerations on cert spoofing > o Add text suggesting that a new cnf member be defined in the > future, if hash function(s) other than SHA-256 need to be used fo= r > certificate thumbprints > > > > ---------- Forwarded message ---------- > From: > Date: Fri, Jul 28, 2017 at 12:25 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the I= ETF. > > Title : Mutual TLS Profile for OAuth 2.0 > Authors : Brian Campbell > John Bradley > Nat Sakimura > Torsten Lodderstedt > Filename : draft-ietf-oauth-mtls-03.txt > Pages : 17 > Date : 2017-07-28 > > Abstract: > This document describes Transport Layer Security (TLS) mutual > authentication using X.509 certificates as a mechanism for OAuth > client authentication to the token endpoint as well as for > certificate bound sender constrained access tokens. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------D8EFDAEBBB0C9D847B45EB9B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks everyone for the update! Having a clear distinction between the PKIX vs public key bound methods will help interop, implementers' job, and it also appears good for security.

Questions:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.3

where the X.509 certificates are represented using the "x5c" parameter from [RFC7517]

For the public key method, is it really necessary for the client to include its certificate in the JWK x5c parameter? This will make implementation harder for developers, and I'm not sure it adds anything in terms of security. Registering the public key parameters seems sufficient to me.


https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.1

When used in conjunction with a trusted X.509 certificate source, it also allows the client to rotate its X.509 certificates without the need to change its respective authentication data at the authorization server.
I don't understand this - "in conjunction with a trusted X.509 certificate source"


Thanks,

Vladimir

On 28/07/17 21:33, Brian Campbell wrote:
A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with
the changes listed below based on comments and dissuasion in Prague.

   draft-ietf-oauth-mtls-03
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>

   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method is for
      the PKI method and introduced "pub_key_tls_client_auth" for the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jul 28, 2017 at 12:25 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : Mutual TLS Profile for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-03.txt
        Pages           : 17
        Date            : 2017-07-28

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for OAuth
   client authentication to the token endpoint as well as for
   certificate bound sender constrained access tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------D8EFDAEBBB0C9D847B45EB9B-- From nobody Wed Aug 2 01:03:14 2017 Return-Path: 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 B746C131CFE for ; Wed, 2 Aug 2017 01:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 W9uLUpO271dE for ; Wed, 2 Aug 2017 01:03:10 -0700 (PDT) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (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 4F3A2131CF2 for ; Wed, 2 Aug 2017 01:03:10 -0700 (PDT) Received: from [192.168.0.101] ([78.130.190.73]) by :SMTPAUTH: with SMTP id coc1d0BJhJOYbcoc2dNQhg; Wed, 02 Aug 2017 01:02:39 -0700 To: oauth@ietf.org References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <4d8af659-bbae-5abc-982c-a42d300bc5f9@connect2id.com> Date: Wed, 2 Aug 2017 11:02:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-CMAE-Envelope: MS4wfI08ZWa6i9APDHeLjETCbjK8X8GJwp51CoVxjotuwVDZ9jgNL2neteBbGt2UMaqu0T8wpbIXNudBsTzimEXKkf/hcs05sfOuV2LyXLNkYHliCIQPw60j V01DdmPlpe4PPn8042U3dToLgq9nUTxHDsGDB72nyxfuQTiJgwkXu1fB Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:03:13 -0000 In terms of structure, I would like to suggest giving PKI bound auth and pub key bound mTLS auth their own sections, instead of having them in one section (2.1 as it is now). The two methods are distinctive enough, and implementers should easily recognise they can implement just one of them. Vladimir On 01/08/17 22:57, Brian Campbell wrote: > Thanks Justin. > > In my original announcement email, I should have given credit to Torste= n as > he made many of the updates in -03. So complements on improvements as w= ell > as blame for issues can be pointed to him as well! > > Your point about document structure is taken and we will look to make t= he > separation of the client authentication and resource access more clear = in > future revisions. The document was aiming for something conceptually al= ong > those same lines already. But it could be made more clear. > > This could define a new =E2=80=9Ctoken_type=E2=80=9D but other than hav= ing different token > type names in messages, I don't know that a new token_type or HTTP auth= > scheme that would probably have to come along with it adds value to the= use > cases here. However, they would very likely make deployment of this stu= ff > much more cumbersome and take longer. Whereas many systems can likely = plug > in mutual TLS on top of the existing token_type and HTTP auth scheme > without major changes. I'm strongly inclined to not introduce a new > token_type and more inclined to not do a new HTTP auth scheme. > > Fair point about breaking out all the registered parameters into their = own > hanging list items. It is somewhat inconsistent in that regard now. Wil= l > look to address that in a future revision. > > Using just a certificate hash for mTLS sender constrained access tokens= was > intentional to allow mTLS at the resource to be used as a > proof-of-possession method only. It's part of the authorization check a= t > resource access and deliberately not about authentication with the RS. > Using the hash simplifies the check at the RS to one consistent way of > doing things while allowing for different modes of doing client > authentication at the AS. So the lack of parallelism with the client > authentication at the token endpoint was very much intentional. Followi= ng > from that, the need to do mTLS at the token endpoint in order to get > mTLS-bound access tokens for an RS was also kind of intentional. Though= , as > =C2=A74.3 > attempts to describe, a public client could do mTLS at the token endpoi= nt > with a generated self-singed cert to have an access token bound but not= > actually authenticate to the token endpoint. You are certainly right th= at > there are other ways an AS could decide on the certificate to bind the > access token to. And other ways a cnf claim member could provide for su= ch a > binding. But we were aiming to not provide too many options in the doc.= So > my thinking here was that this draft is about mTLS and so saying how to= use > mTLS for the AS to do the access token binding seemed like the most > appropriate and straightforward approach. It's not so much that mTLS > authentication is needed for the client at the token endpoint to allow = for > bound access tokens. But rather that having mTLS at the token endpoint > provides a strong signal of the certificate to which to bind the issued= > access token. > > > > > > > > On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer wrote:= > >> Brian, thanks for the update. This is really coming along! >> >> I think the spec would benefit from a more clear separation of the cli= ent >> authentication and resource access sections. They=E2=80=99re really al= most two >> different but related specs, but there=E2=80=99s enough overlap that I= think that >> keeping them in the same document is fine with some structural changes= >> applied. I think the content is by and large all here, it=E2=80=99s ju= st jumbled >> together. >> >> To that end, I think there might be three major sections to this docum= ent >> (not counting the IANA, security, privacy, and other boilerplate bits)= =2E A >> suggested breakdown: >> >> 1) Types of mTLS client auth under consideration. This is where the >> definition of public key vs. pki comes in, and where the two authentic= ation >> methods are defined for both registration and discovery. Some implemen= tor=E2=80=99s >> notes on what kinds of things you need to store here, including the >> tls_client_auth_ client metadata extensions. For better or worse, 7591= >> defines OAuth=E2=80=99s client model, and not just for dynamic registr= ation. >> >> 2) How to use mTLS to authenticate a client. This can be a relatively >> short section that says use (1) in the context of getting an access to= ken >> at the token endpoint. Here is where you point out that you still need= to >> send client_id and that the association with the cert=E2=80=99s DN and= the >> client_id is done at the AS (there=E2=80=99s existing text for this). >> >> 3) How to use mTLS to bind an access token. This is a bit more complic= ated >> because it=E2=80=99s the RS that needs to know the binding between the= token and >> the cert=E2=80=99s DN, so that=E2=80=99s where you=E2=80=99d define th= e =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate >> side effect of spec history means that the =E2=80=9Ccnf=E2=80=9D claim= for 7662 also gets >> defined here. This is also where you=E2=80=99d put the bits about >> mutual_tls_sender_constrained_access_tokens for discovery and >> registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D? >> >> >> A few more comments: >> >> =C2=A72.3 really should break out all registered parameters into their= own >> hanging list items (even if you break them up into different sections = like >> suggested above) >> >> =C2=A73 seems to say that you can only do mTLS-bound access tokens at = an RS if >> you do mTLS authentication at the token endpoint. Is that an intention= al >> restriction? To me these two functions seem to be more orthogonal than= the >> spec is hinting at. Like, I could use private_key_jwt or PKCE or magic= to >> authenticate at the RS but use mTLS at the RS, for whatever esoteric >> reason, like the AS and RS being in different security domains. Still,= >> functionally, if the client=E2=80=99s registered parameters are enough= to trust for >> token issuance, they should be enough to trust for token usage. In oth= er >> words, have the RS depend on tls_client_auth_subject_dn etc. instead o= f >> "the same certificate that was used for mutual TLS at the token endpoi= nt". >> >> Along those lines, =C2=A73 also depends entirely on matching a specifi= c >> certificate hash instead of validating a certificate (and possibly it=E2= =80=99s >> chain) and associated DN. This isn=E2=80=99t in parallel with the clie= nt >> authentication at the token endpoint, and I=E2=80=99d like to see thes= e come >> together. Should we have a third certificate validation method in =C2=A7= 2 for >> =E2=80=9Ccertificate hash=E2=80=9D? Or maybe we should have a separate= list for >> =E2=80=9Cresource_server_auth_method=E2=80=9D for the client? >> >> In any event, it still feels like there are two things that are fighti= ng >> for attention in this spec: cert-based authentication of the client at= the >> token endpoint, and cert-based PoP of the token at the resource. >> >> =E2=80=94 Justin >> >> On Jul 28, 2017, at 2:33 PM, Brian Campbell >> wrote: >> >> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published w= ith >> the changes listed below based on comments and dissuasion in Prague. >> >> draft-ietf-oauth-mtls-03 >> >> o Introduced metadata and client registration parameter to publish= >> and request support for mutual TLS sender constrained access >> tokens >> o Added description of two methods of binding the cert and client,= >> PKI and Public Key. >> o Indicated that the "tls_client_auth" authentication method is fo= r >> the PKI method and introduced "pub_key_tls_client_auth" for the >> Public Key method >> o Added implementation considerations, mainly regarding TLS stack >> configuration and trust chain validation, as well as how to to d= o >> binding of access tokens to a TLS client certificate for public >> clients, and considerations around certificate bound access toke= ns >> o Added new section to security considerations on cert spoofing >> o Add text suggesting that a new cnf member be defined in the >> future, if hash function(s) other than SHA-256 need to be used f= or >> certificate thumbprints >> >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Fri, Jul 28, 2017 at 12:25 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the = IETF. >> >> Title : Mutual TLS Profile for OAuth 2.0 >> Authors : Brian Campbell >> John Bradley >> Nat Sakimura >> Torsten Lodderstedt >> Filename : draft-ietf-oauth-mtls-03.txt >> Pages : 17 >> Date : 2017-07-28 >> >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for OAuth >> client authentication to the token endpoint as well as for >> certificate bound sender constrained access tokens. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 prohibit= ed. >> If you have received this communication in error, please notify the se= nder >> 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 From nobody Wed Aug 2 08:30:29 2017 Return-Path: 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 7C920132131 for ; Wed, 2 Aug 2017 08:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 ZW6eTN0ZrA6m for ; Wed, 2 Aug 2017 08:30:25 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 51A8D13213E for ; Wed, 2 Aug 2017 08:30:25 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id c14so22692696pgn.0 for ; Wed, 02 Aug 2017 08:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6dP6GEfcUTUlQRiKGE8STUBXKV9fOf0VEUoP9qrj10M=; b=anitQirv5OtZeCGMwsys7brRVsdZD8QZn7Z5R2CEH+1fxfdaIKRPGQ02Ksb21ytsos wUJMd5JDZ6CEOPLFUg08IJJLopTFVRSnOTK96t0bFpAK2YL5EEbS0Kw3aRWRkrnQbnb/ pTOlqCm96z3FjBrHcaClP1haBBqYaaMdRyd5c= 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=6dP6GEfcUTUlQRiKGE8STUBXKV9fOf0VEUoP9qrj10M=; b=Clx9kxkArwtRZxy+hiZ4EYFjUPsTtnc5S6pp55IpwnVxWqkjLJGND6OkNKmim/wdhD zyF4iCw/p5ankZm+6beTLkxOqFV3xV3SrgQRtMtEMUMHkidwZHJbPsrUjX6H0FvxCAjF +RwJF5J5OKprO5PkDnJWJRA0ApimMKeak9lAubiomjpfe1RpN+7svylX6tVOjNzcgGer njwt9k9EhEiLqqSP8GGSI68Muee1s2V/e1g34lxT4S0LdEFD9g+m1uKObi7Qj44u1iu7 chjxntzdy4Ou+xkoJ1ErSVTwdB+N9Mz5LY5e2R38Qx+D6Jki6QJ76K4pBJi9RS6yI9OY NAXg== X-Gm-Message-State: AIVw113iY/+niLrY27/c0ETXKElV4NlcdqKCp6mjmmAsdTv3+iAK8NYz YQe0kQ0WA9aZTiL7w4DkIS6rajkXkrKAgbh2Mb7/+lpbrrHBGU82W2JCSk8zEOSCQ9qLVYELg5x 0240K X-Received: by 10.99.2.18 with SMTP id 18mr23702498pgc.42.1501687824766; Wed, 02 Aug 2017 08:30:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Wed, 2 Aug 2017 08:29:54 -0700 (PDT) In-Reply-To: References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> From: Brian Campbell Date: Wed, 2 Aug 2017 09:29:54 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="001a1141c0cc5c09aa0555c6f153" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:30:27 -0000 --001a1141c0cc5c09aa0555c6f153 Content-Type: text/plain; charset="UTF-8" Thanks for the review, Vladimir. The text about which you have questions was written by Torsten (credit or blame where it's due!) but I believe he's out of the office for a bit so I'll try and answer. Your 1st question: I've had the same thought regarding the public key method and using the JWK x5c parameter. A JWK already has the public key, which is sufficient for comparison in the public key method. So x5c is just superfluous here. I believe that's a change that the next revision should have and will look to make it unless someone wants to make a strong case for needing x5c. Your 2nd question: I also found the sentence, "When used in conjunction with a trusted X.509 certificate source, it also allows the client to rotate its X.509 certificates without the need to change its respective authentication data at the authorization server." somewhat difficult to understand when I first read it. The intended meaning relies on content earlier in the same paragraph that says, "As pre-requisite, the client registers a X.509 certificate or *a trusted source for its X.509 certificates (jwks uri as defined in [RFC7591])* with the authorization server." Basically what it's trying to say is that when a client is registered or configured with a jwks_uri, then client key rotation can be done without needing to explicitly update the client config/registration with the AS. Does that explain it? I believe the text could be more straightforward and will endeavor to make it more clear in the next draft update. On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov wrote: > Thanks everyone for the update! Having a clear distinction between the > PKIX vs public key bound methods will help interop, implementers' job, and > it also appears good for security. > > Questions: > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.3 > > where the X.509 certificates are represented using the "x5c" parameter from [RFC7517 ] > > For the public key method, is it really necessary for the client to > include its certificate in the JWK x5c parameter? This will make > implementation harder for developers, and I'm not sure it adds anything in > terms of security. Registering the public key parameters seems sufficient > to me. > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.1 > > When used in conjunction with a trusted X.509 certificate source, it also allows the client to rotate its X.509 certificates without the need to change its respective authentication data at the authorization server. > > I don't understand this - "in conjunction with a trusted X.509 certificate > source" > > > Thanks, > > Vladimir > > On 28/07/17 21:33, Brian Campbell wrote: > > A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with > the changes listed below based on comments and dissuasion in Prague. > > draft-ietf-oauth-mtls-03 > > > o Introduced metadata and client registration parameter to publish > and request support for mutual TLS sender constrained access > tokens > o Added description of two methods of binding the cert and client, > PKI and Public Key. > o Indicated that the "tls_client_auth" authentication method is for > the PKI method and introduced "pub_key_tls_client_auth" for the > Public Key method > o Added implementation considerations, mainly regarding TLS stack > configuration and trust chain validation, as well as how to to do > binding of access tokens to a TLS client certificate for public > clients, and considerations around certificate bound access tokens > o Added new section to security considerations on cert spoofing > o Add text suggesting that a new cnf member be defined in the > future, if hash function(s) other than SHA-256 need to be used for > certificate thumbprints > > > > ---------- Forwarded message ---------- > From: > Date: Fri, Jul 28, 2017 at 12:25 PM > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : Mutual TLS Profile for OAuth 2.0 > Authors : Brian Campbell > John Bradley > Nat Sakimura > Torsten Lodderstedt > Filename : draft-ietf-oauth-mtls-03.txt > Pages : 17 > Date : 2017-07-28 > > Abstract: > This document describes Transport Layer Security (TLS) mutual > authentication using X.509 certificates as a mechanism for OAuth > client authentication to the token endpoint as well as for > certificate bound sender constrained access tokens. > > > The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > > There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 > > A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://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.* --001a1141c0cc5c09aa0555c6f153 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Vladimir.
=C2=A0=
The text about which you have questions was written by Torsten (c= redit or blame where it's due!) but I believe he's out of the offic= e for a bit so I'll try and answer.

Your 1st questio= n:
I've had the same thought regarding the public key method a= nd using the JWK x5c parameter. A JWK already has the public key, which is = sufficient for comparison in the public key method. So x5c is just superflu= ous here. I believe that's a change that the next revision should have = and will look to make it unless someone wants to make a strong case for nee= ding x5c.

Your 2nd question:
I also found the sentence, "Wh= en used in conjunction with a trusted X.509 certificate source, it also all= ows the client to rotate its X.509 certificates without the need to change = its respective authentication data at the authorization server." somew= hat difficult to understand when I first read it. The intended meaning reli= es on content earlier in the same paragraph that says, "As pre-requisi= te, the client registers a X.509 certificate or a trusted source for its= X.509 certificates (jwks uri as defined in [RFC7591]) with the authori= zation server."=C2=A0 Basically what it's trying to say is that wh= en a client is registered or configured with a jwks_uri, then client key ro= tation can be done without needing to explicitly update the client config/r= egistration with the AS. Does that explain it? I believe the text could be = more straightforward and will endeavor to make it more clear in the next dr= aft update.



=C2=A0





On W= ed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <vladimir@connect2id.= com> wrote:
=20 =20 =20

Thanks everyone for the update! Having a clear distinction between the PKIX vs public key bound methods will help interop, implementers' job, and it also appears good for security.

Questions:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth= -mtls-03#section-2.3

where the X.509 certif=
icates are represented using the "x5c" parameter from [RFC7517]

For the public key method, is it really necessary for the client to include its certificate in the JWK x5c parameter? This will make implementation harder for developers, and I'm not sure it adds anything in terms of security. Registering the public key parameters seems sufficient to me.


https://datatracker.ietf.org/doc/html/draft-ietf-oauth= -mtls-03#section-2.1

When used in conjuncti=
on with a trusted X.509 certificate source, it also allows the client to ro=
tate its X.509 certificates without the need to change its respective authe=
ntication data at the authorization server.
I don't understand this - "in conjunction with a trusted X.5= 09 certificate source"


Thanks,

Vladimir

On 28/07/17 21:33,= Brian Campbell wrote:
A new draft of "Mutual TLS Profile for OAu=
th 2.0" has been published with
the changes listed below based on comments and dissuasion in Prague.

   draft-ietf-oauth-mtls-03
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mt=
ls-03>


   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method =
is for
      the PKI method and introduced "pub_key_tls_client_auth" for=
 the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints



---------- Forwarded message ----------
From: <internet-drafts@ietf.org=
>
Date: Fri, Jul 28, 2017 at 12:25 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : Mutual TLS Profile for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-03.txt
        Pages           : 17
        Date            : 2017-07-28

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for OAuth
   client authentication to the token endpoint as well as for
   certificate bound sender constrained access tokens.


The IETF datatracker status page for this draft is:
https://da=
tatracker.ietf.org/doc/draft-ietf-oauth-mtls/

There are also htmlized versions available at:
https://tools=
.ietf.org/html/draft-ietf-oauth-mtls-03
htt=
ps://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03

A diff from the previous version is available at:
https=
://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m=
ailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1141c0cc5c09aa0555c6f153-- From nobody Wed Aug 2 08:42:34 2017 Return-Path: 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 29635131C33 for ; Wed, 2 Aug 2017 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 5jB8TOi9ej8z for ; Wed, 2 Aug 2017 08:42:30 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 3058A124B18 for ; Wed, 2 Aug 2017 08:42:30 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id v77so16992134pgb.3 for ; Wed, 02 Aug 2017 08:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zxxM+GqE4nanp2fm1madTtRNlbNQhrG4n/Blf7sy0HQ=; b=Rl9mSaDUqutwTVGImO8bmyb7HRtNzfa9nm29gXIwjn/YKW6dQNRsS6LoDKR8PefdXH i4Z3PCsmKIpn8BqOBdych4JOLg9opCZT/rBHkZenmkASf/xUTo/odOVi+xF4J770Sjwf F/LVpKqMZHUaH7G8edb0n1sCCS3444ZQ16yuM= 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=zxxM+GqE4nanp2fm1madTtRNlbNQhrG4n/Blf7sy0HQ=; b=f2OAlz+QUWjQ+gEdjl0DC3WOrYYRlyk1bIcyYCvM76O02mu6UthIjyOTk5eclxSrX+ w7JNuszBBhBhHj/h43bSKId98H9Y/Vhf+TxmyesdPVUcG/QVh5HGkzfNA2++E7NP5ouc ZGV8/k5tp/sEZDpw2x1t9sU3iZKlb74DpvGCaAbPXol2RL15wzR1NvM70wL3xmDx+1Vw rWw8VDZRIp7XMQU0BUcPhl4xIulSCWfaW2zBpXdSTHKuu0s9zAkOsh9ymEQp8r3DtXAy nLpZKENJH+3X8g8ca4kY6Rw/VGvePFB/TGqn7ZxFvndIJdF17Cc82pje+xcisOuf7Oxh g7fA== X-Gm-Message-State: AIVw111QTT3+qEynmRrxbKiVD837xNw1CjYmH6cROgnNNymZvrE112ox ouXp6kraoj3o3PtTxxAuBw4ACnQoJSZMaAqGxuG8GdYz50dRHCE3g+rIM/JXkycw8fT5+fv8mgY uASXK X-Received: by 10.99.97.69 with SMTP id v66mr8665227pgb.332.1501688549603; Wed, 02 Aug 2017 08:42:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Wed, 2 Aug 2017 08:41:58 -0700 (PDT) In-Reply-To: <4d8af659-bbae-5abc-982c-a42d300bc5f9@connect2id.com> References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <4d8af659-bbae-5abc-982c-a42d300bc5f9@connect2id.com> From: Brian Campbell Date: Wed, 2 Aug 2017 09:41:58 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c0cc59c9026070555c71c86" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:42:33 -0000 --94eb2c0cc59c9026070555c71c86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A fair suggestion and we'll see what can be done to make the distinction more clear. On Wed, Aug 2, 2017 at 2:02 AM, Vladimir Dzhuvinov wrote: > In terms of structure, I would like to suggest giving PKI bound auth and > pub key bound mTLS auth their own sections, instead of having them in > one section (2.1 as it is now). > > The two methods are distinctive enough, and implementers should easily > recognise they can implement just one of them. > > Vladimir > > > On 01/08/17 22:57, Brian Campbell wrote: > > Thanks Justin. > > > > In my original announcement email, I should have given credit to Torste= n > as > > he made many of the updates in -03. So complements on improvements as > well > > as blame for issues can be pointed to him as well! > > > > Your point about document structure is taken and we will look to make t= he > > separation of the client authentication and resource access more clear = in > > future revisions. The document was aiming for something conceptually > along > > those same lines already. But it could be made more clear. > > > > This could define a new =E2=80=9Ctoken_type=E2=80=9D but other than hav= ing different > token > > type names in messages, I don't know that a new token_type or HTTP auth > > scheme that would probably have to come along with it adds value to the > use > > cases here. However, they would very likely make deployment of this stu= ff > > much more cumbersome and take longer. Whereas many systems can likely > plug > > in mutual TLS on top of the existing token_type and HTTP auth scheme > > without major changes. I'm strongly inclined to not introduce a new > > token_type and more inclined to not do a new HTTP auth scheme. > > > > Fair point about breaking out all the registered parameters into their > own > > hanging list items. It is somewhat inconsistent in that regard now. Wil= l > > look to address that in a future revision. > > > > Using just a certificate hash for mTLS sender constrained access tokens > was > > intentional to allow mTLS at the resource to be used as a > > proof-of-possession method only. It's part of the authorization check a= t > > resource access and deliberately not about authentication with the RS. > > Using the hash simplifies the check at the RS to one consistent way of > > doing things while allowing for different modes of doing client > > authentication at the AS. So the lack of parallelism with the client > > authentication at the token endpoint was very much intentional. Followi= ng > > from that, the need to do mTLS at the token endpoint in order to get > > mTLS-bound access tokens for an RS was also kind of intentional. Though= , > as > > =C2=A74.3 > > attempts to describe, a public client could do mTLS at the token endpoi= nt > > with a generated self-singed cert to have an access token bound but not > > actually authenticate to the token endpoint. You are certainly right th= at > > there are other ways an AS could decide on the certificate to bind the > > access token to. And other ways a cnf claim member could provide for > such a > > binding. But we were aiming to not provide too many options in the doc. > So > > my thinking here was that this draft is about mTLS and so saying how to > use > > mTLS for the AS to do the access token binding seemed like the most > > appropriate and straightforward approach. It's not so much that mTLS > > authentication is needed for the client at the token endpoint to allow > for > > bound access tokens. But rather that having mTLS at the token endpoint > > provides a strong signal of the certificate to which to bind the issued > > access token. > > > > > > > > > > > > > > > > On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer wrote: > > > >> Brian, thanks for the update. This is really coming along! > >> > >> I think the spec would benefit from a more clear separation of the > client > >> authentication and resource access sections. They=E2=80=99re really al= most two > >> different but related specs, but there=E2=80=99s enough overlap that I= think > that > >> keeping them in the same document is fine with some structural changes > >> applied. I think the content is by and large all here, it=E2=80=99s ju= st jumbled > >> together. > >> > >> To that end, I think there might be three major sections to this > document > >> (not counting the IANA, security, privacy, and other boilerplate bits)= . > A > >> suggested breakdown: > >> > >> 1) Types of mTLS client auth under consideration. This is where the > >> definition of public key vs. pki comes in, and where the two > authentication > >> methods are defined for both registration and discovery. Some > implementor=E2=80=99s > >> notes on what kinds of things you need to store here, including the > >> tls_client_auth_ client metadata extensions. For better or worse, 7591 > >> defines OAuth=E2=80=99s client model, and not just for dynamic registr= ation. > >> > >> 2) How to use mTLS to authenticate a client. This can be a relatively > >> short section that says use (1) in the context of getting an access > token > >> at the token endpoint. Here is where you point out that you still need > to > >> send client_id and that the association with the cert=E2=80=99s DN and= the > >> client_id is done at the AS (there=E2=80=99s existing text for this). > >> > >> 3) How to use mTLS to bind an access token. This is a bit more > complicated > >> because it=E2=80=99s the RS that needs to know the binding between the= token and > >> the cert=E2=80=99s DN, so that=E2=80=99s where you=E2=80=99d define th= e =E2=80=9Ccnf=E2=80=9D stuff. An > unfortunate > >> side effect of spec history means that the =E2=80=9Ccnf=E2=80=9D claim= for 7662 also > gets > >> defined here. This is also where you=E2=80=99d put the bits about > >> mutual_tls_sender_constrained_access_tokens for discovery and > >> registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D? > >> > >> > >> A few more comments: > >> > >> =C2=A72.3 really should break out all registered parameters into their= own > >> hanging list items (even if you break them up into different sections > like > >> suggested above) > >> > >> =C2=A73 seems to say that you can only do mTLS-bound access tokens at = an RS > if > >> you do mTLS authentication at the token endpoint. Is that an intention= al > >> restriction? To me these two functions seem to be more orthogonal than > the > >> spec is hinting at. Like, I could use private_key_jwt or PKCE or magic > to > >> authenticate at the RS but use mTLS at the RS, for whatever esoteric > >> reason, like the AS and RS being in different security domains. Still, > >> functionally, if the client=E2=80=99s registered parameters are enough= to trust > for > >> token issuance, they should be enough to trust for token usage. In oth= er > >> words, have the RS depend on tls_client_auth_subject_dn etc. instead o= f > >> "the same certificate that was used for mutual TLS at the token > endpoint". > >> > >> Along those lines, =C2=A73 also depends entirely on matching a specifi= c > >> certificate hash instead of validating a certificate (and possibly it= =E2=80=99s > >> chain) and associated DN. This isn=E2=80=99t in parallel with the clie= nt > >> authentication at the token endpoint, and I=E2=80=99d like to see thes= e come > >> together. Should we have a third certificate validation method in =C2= =A72 for > >> =E2=80=9Ccertificate hash=E2=80=9D? Or maybe we should have a separate= list for > >> =E2=80=9Cresource_server_auth_method=E2=80=9D for the client? > >> > >> In any event, it still feels like there are two things that are fighti= ng > >> for attention in this spec: cert-based authentication of the client at > the > >> token endpoint, and cert-based PoP of the token at the resource. > >> > >> =E2=80=94 Justin > >> > >> On Jul 28, 2017, at 2:33 PM, Brian Campbell > > >> wrote: > >> > >> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published > with > >> the changes listed below based on comments and dissuasion in Prague. > >> > >> draft-ietf-oauth-mtls-03 doc/html/draft-ietf-oauth-mtls-03> > >> > >> o Introduced metadata and client registration parameter to publish > >> and request support for mutual TLS sender constrained access > >> tokens > >> o Added description of two methods of binding the cert and client, > >> PKI and Public Key. > >> o Indicated that the "tls_client_auth" authentication method is fo= r > >> the PKI method and introduced "pub_key_tls_client_auth" for the > >> Public Key method > >> o Added implementation considerations, mainly regarding TLS stack > >> configuration and trust chain validation, as well as how to to d= o > >> binding of access tokens to a TLS client certificate for public > >> clients, and considerations around certificate bound access toke= ns > >> o Added new section to security considerations on cert spoofing > >> o Add text suggesting that a new cnf member be defined in the > >> future, if hash function(s) other than SHA-256 need to be used f= or > >> certificate thumbprints > >> > >> > >> > >> ---------- Forwarded message ---------- > >> From: > >> Date: Fri, Jul 28, 2017 at 12:25 PM > >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt > >> To: i-d-announce@ietf.org > >> Cc: oauth@ietf.org > >> > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Web Authorization Protocol WG of the > IETF. > >> > >> Title : Mutual TLS Profile for OAuth 2.0 > >> Authors : Brian Campbell > >> John Bradley > >> Nat Sakimura > >> Torsten Lodderstedt > >> Filename : draft-ietf-oauth-mtls-03.txt > >> Pages : 17 > >> Date : 2017-07-28 > >> > >> Abstract: > >> This document describes Transport Layer Security (TLS) mutual > >> authentication using X.509 certificates as a mechanism for OAuth > >> client authentication to the token endpoint as well as for > >> certificate bound sender constrained access tokens. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 > >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> 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 > --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --94eb2c0cc59c9026070555c71c86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A fair suggestion and we'll see what can be done to ma= ke the distinction more clear.

On Wed, Aug 2, 2017 at 2:02 AM, Vladimir Dzhuvinov = <vladimir@connect2id.com> wrote:
In terms of structure, I would like to suggest giving PKI bou= nd auth and
pub key bound mTLS auth their own sections, instead of having them in
one section (2.1 as it is now).

The two methods are distinctive enough, and implementers should easily
recognise they can implement just one of them.

Vladimir


On 01/08/17 22:57, Brian Campbell wrote:
> Thanks Justin.
>
> In my original announcement email, I should have given credit to Torst= en as
> he made many of the updates in -03. So complements on improvements as = well
> as blame for issues can be pointed to him as well!
>
> Your point about document structure is taken and we will look to make = the
> separation of the client authentication and resource access more clear= in
> future revisions. The document was aiming for something conceptually a= long
> those same lines already. But it could be made more clear.
>
> This could define a new =E2=80=9Ctoken_type=E2=80=9D but other than ha= ving different token
> type names in messages, I don't know that a new token_type or HTTP= auth
> scheme that would probably have to come along with it adds value to th= e use
> cases here. However, they would very likely make deployment of this st= uff
> much more cumbersome and take longer.=C2=A0 Whereas many systems can l= ikely plug
> in mutual TLS on top of the existing token_type and HTTP auth scheme > without major changes. I'm strongly inclined to not introduce a ne= w
> token_type and more inclined to not do a new HTTP auth scheme.
>
> Fair point about breaking out all the registered parameters into their= own
> hanging list items. It is somewhat inconsistent in that regard now. Wi= ll
> look to address that in a future revision.
>
> Using just a certificate hash for mTLS sender constrained access token= s was
> intentional to allow mTLS at the resource to be used as a
> proof-of-possession method only. It's part of the authorization ch= eck at
> resource access and deliberately not about authentication with the RS.=
> Using the hash simplifies the check at the RS to one consistent way of=
> doing things while allowing for different modes of doing client
> authentication at the AS. So the lack of parallelism with the client > authentication at the token endpoint was very much intentional. Follow= ing
> from that, the need to do mTLS at the token endpoint in order to get > mTLS-bound access tokens for an RS was also kind of intentional. Thoug= h, as
> =C2=A74.3 <https= ://tools.ietf.org/html/draft-ietf-oauth-mtls-03#section-4.3&g= t;
> attempts to describe, a public client could do = mTLS at the token endpoint
> with a generated self-singed cert to have an access token bound but no= t
> actually authenticate to the token endpoint. You are certainly right t= hat
> there are other ways an AS could decide on the certificate to bind the=
> access token to. And other ways a cnf claim member could provide for s= uch a
> binding. But we were aiming to not provide too many options in the doc= . So
> my thinking here was that this draft is about mTLS and so saying how t= o use
> mTLS for the AS to do the access token binding seemed like the most > appropriate and straightforward approach. It's not so much that mT= LS
> authentication is needed for the client at the token endpoint to allow= for
> bound access tokens. But rather that having mTLS at the token endpoint=
> provides a strong signal of the certificate to which to bind the issue= d
> access token.
>
>
>
>
>
>
>
> On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer <jricher@mit.edu> wrote:
>
>> Brian, thanks for the update. This is really coming along!
>>
>> I think the spec would benefit from a more clear separation of the= client
>> authentication and resource access sections. They=E2=80=99re reall= y almost two
>> different but related specs, but there=E2=80=99s enough overlap th= at I think that
>> keeping them in the same document is fine with some structural cha= nges
>> applied. I think the content is by and large all here, it=E2=80=99= s just jumbled
>> together.
>>
>> To that end, I think there might be three major sections to this d= ocument
>> (not counting the IANA, security, privacy, and other boilerplate b= its). A
>> suggested breakdown:
>>
>> 1) Types of mTLS client auth under consideration. This is where th= e
>> definition of public key vs. pki comes in, and where the two authe= ntication
>> methods are defined for both registration and discovery. Some impl= ementor=E2=80=99s
>> notes on what kinds of things you need to store here, including th= e
>> tls_client_auth_ client metadata extensions. For better or worse, = 7591
>> defines OAuth=E2=80=99s client model, and not just for dynamic reg= istration.
>>
>> 2) How to use mTLS to authenticate a client. This can be a relativ= ely
>> short section that says use (1) in the context of getting an acces= s token
>> at the token endpoint. Here is where you point out that you still = need to
>> send client_id and that the association with the cert=E2=80=99s DN= and the
>> client_id is done at the AS (there=E2=80=99s existing text for thi= s).
>>
>> 3) How to use mTLS to bind an access token. This is a bit more com= plicated
>> because it=E2=80=99s the RS that needs to know the binding between= the token and
>> the cert=E2=80=99s DN, so that=E2=80=99s where you=E2=80=99d defin= e the =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate
>> side effect of spec history means that the =E2=80=9Ccnf=E2=80=9D c= laim for 7662 also gets
>> defined here. This is also where you=E2=80=99d put the bits about<= br> >> mutual_tls_sender_constrained_access_tokens for discovery and=
>> registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D? >>
>>
>> A few more comments:
>>
>> =C2=A72.3 really should break out all registered parameters into t= heir own
>> hanging list items (even if you break them up into different secti= ons like
>> suggested above)
>>
>> =C2=A73 seems to say that you can only do mTLS-bound access tokens= at an RS if
>> you do mTLS authentication at the token endpoint. Is that an inten= tional
>> restriction? To me these two functions seem to be more orthogonal = than the
>> spec is hinting at. Like, I could use private_key_jwt or PKCE or m= agic to
>> authenticate at the RS but use mTLS at the RS, for whatever esoter= ic
>> reason, like the AS and RS being in different security domains. St= ill,
>> functionally, if the client=E2=80=99s registered parameters are en= ough to trust for
>> token issuance, they should be enough to trust for token usage. In= other
>> words, have the RS depend on tls_client_auth_subject_dn etc. inste= ad of
>> "the same certificate that was used for mutual TLS at the tok= en endpoint".
>>
>> Along those lines, =C2=A73 also depends entirely on matching a spe= cific
>> certificate hash instead of validating a certificate (and possibly= it=E2=80=99s
>> chain) and associated DN. This isn=E2=80=99t in parallel with the = client
>> authentication at the token endpoint, and I=E2=80=99d like to see = these come
>> together. Should we have a third certificate validation method in = =C2=A72 for
>> =E2=80=9Ccertificate hash=E2=80=9D? Or maybe we should have a sepa= rate list for
>> =E2=80=9Cresource_server_auth_method=E2=80=9D for the client?
>>
>> In any event, it still feels like there are two things that are fi= ghting
>> for attention in this spec: cert-based authentication of the clien= t at the
>> token endpoint, and cert-based PoP of the token at the resource. >>
>>=C2=A0 =E2=80=94 Justin
>>
>> On Jul 28, 2017, at 2:33 PM, Brian Campbell <bcampbell@pingidentity.com>
>> wrote:
>>
>> A new draft of "Mutual TLS Profile for OAuth 2.0" has be= en published with
>> the changes listed below based on comments and dissuasion in Pragu= e.
>>
>>=C2=A0 =C2=A0 draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-i= etf-oauth-mtls-03>
>>
>>=C2=A0 =C2=A0 o=C2=A0 Introduced metadata and client registration p= arameter to publish
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0and request support for mutual TLS sende= r constrained access
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0tokens
>>=C2=A0 =C2=A0 o=C2=A0 Added description of two methods of binding t= he cert and client,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0PKI and Public Key.
>>=C2=A0 =C2=A0 o=C2=A0 Indicated that the "tls_client_auth"= ; authentication method is for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0the PKI method and introduced "pub_= key_tls_client_auth" for the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Public Key method
>>=C2=A0 =C2=A0 o=C2=A0 Added implementation considerations, mainly r= egarding TLS stack
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration and trust chain validation= , as well as how to to do
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0binding of access tokens to a TLS client= certificate for public
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0clients, and considerations around certi= ficate bound access tokens
>>=C2=A0 =C2=A0 o=C2=A0 Added new section to security considerations = on cert spoofing
>>=C2=A0 =C2=A0 o=C2=A0 Add text suggesting that a new cnf member be = defined in the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0future, if hash function(s) other than S= HA-256 need to be used for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0certificate thumbprints
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: <internet-dra= fts@ietf.org>
>> Date: Fri, Jul 28, 2017 at 12:25 PM
>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
>> To: i-d-announce@ietf.org=
>> Cc: oauth@ietf.org
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>> directories.
>> This draft is a work item of the Web Authorization Protocol WG of = the IETF.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Mutual TLS Profile for OAuth 2.0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Brian Campbell
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0John Bradley
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nat Sakimura
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Torsten Lodderstedt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-oauth-mtls-03.txt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 17
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2017-07-28
>>
>> Abstract:
>>=C2=A0 =C2=A0 This document describes Transport Layer Security (TLS= ) mutual
>>=C2=A0 =C2=A0 authentication using X.509 certificates as a mechanis= m for OAuth
>>=C2=A0 =C2=A0 client authentication to the token endpoint as well a= s for
>>=C2=A0 =C2=A0 certificate bound sender constrained access tokens. >>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/do= c/draft-ietf-oauth-mtls/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-= ietf-oauth-mtls-03
>> https://datatracker.ietf.org/= doc/html/draft-ietf-oauth-mtls-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confid= ential and
>> privileged material for the sole use of the inten= ded recipient(s). Any
>> review, use, distribution or disclosure by others is strictly proh= ibited.
>> If you have received this communication in error, please notify th= e sender
>> immediately by e-mail and delete the message and any file attachme= nts 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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c0cc59c9026070555c71c86-- From nobody Wed Aug 2 13:35:47 2017 Return-Path: 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 C984D13216E for ; Wed, 2 Aug 2017 13:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 f6l87ZFwjtZY for ; Wed, 2 Aug 2017 13:35:44 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 97CEE132171 for ; Wed, 2 Aug 2017 13:35:44 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id d124so22399633vkf.2 for ; Wed, 02 Aug 2017 13:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ojsCPYqtFi62oQuBlEEUv2pBjf1fZZb3jlH0g+bOQoI=; b=hJ5TitXTG2w1yeE8pC7J1ieRiKQZD3aNDm4KucfSJWagBrxbRZ8nE7Y3On2QpzHuGA /TaH1Edw7liNaX7H2NKA+O930o7ftQm6zHiq/1DFznextQbyV/tbf1KCyD1HIRofg7/x oo4TOsxRYWegxompEgfT0pJMZ9Uqg5jPrGdr4XHSCGLki3eBaUm1eXxOiJJVyX7hRNf9 sUXwRr2GOv5hWuxvGIiyBNfH8mKcaczElIHlmL3vD5BWeAvaUYmurrMeeaLw8Z73CWr/ UKYmURu9VbGtzOVP6akI4Ln4SZA/QiYtIiWWtePNMNQLZEmAMV2Ysrqb6Q9r0NmmhTLU x0AQ== 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; bh=ojsCPYqtFi62oQuBlEEUv2pBjf1fZZb3jlH0g+bOQoI=; b=KZuHOg4BX3R/beyXfgBWUQOx8/wZd8taqNwgBMyXuPQClYTTqNrwNj6OMOfCWPpgfh 0rRCjGn9x6JnffCIhDUotbi+0jnIINCR3iCfLnZJgY1NM75cYy5QVWI385zHvBbWxlXD gP2t+4QcmCGzQHGF7Yqmhu0HBdR4jbcpI4FcekWZkE2U9HmBpsjyZK1gv7BG0G40Dq1c Syub9oouAkQ45mkJPsJMlwKh2Lql7B3ojlEdJKvG80wGM0bEU4wGn+lL/lbmGD+Wxosx j9QXj+oxnvhA8ykz3T7Ta16F926HYpJtgP4FirWxTvBcSeWKm1vMWVJKNX0Ok44eza2L 54bQ== X-Gm-Message-State: AIVw1137+j0CevTF+gw+s45uqwBEvN7sudr12ApH+MjlCRLTTnmST60W rRf9bnGxQzId7GfPs0QTnwlVJ+SllB7V X-Received: by 10.31.67.19 with SMTP id q19mr16341186vka.115.1501706143418; Wed, 02 Aug 2017 13:35:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.129.66 with HTTP; Wed, 2 Aug 2017 13:35:42 -0700 (PDT) Received: by 10.103.129.66 with HTTP; Wed, 2 Aug 2017 13:35:42 -0700 (PDT) In-Reply-To: References: From: Bone Bizz Date: Wed, 2 Aug 2017 12:35:42 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="001a114db3d63c4dd40555cb3536" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 20:35:46 -0000 --001a114db3d63c4dd40555cb3536 Content-Type: text/plain; charset="UTF-8" Hello, id like to join the mailing list for Android. Thanks alot. --001a114db3d63c4dd40555cb3536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, =C2=A0id like to join the mailing list for Android= .=C2=A0 Thanks alot. =C2=A0
--001a114db3d63c4dd40555cb3536-- From nobody Wed Aug 2 15:47:16 2017 Return-Path: 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 EBD69129AC4 for ; Wed, 2 Aug 2017 15:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 Rjx5UFHw-GlJ for ; Wed, 2 Aug 2017 15:47:12 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 91C9A127735 for ; Wed, 2 Aug 2017 15:47:12 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id c14so26783187pgn.0 for ; Wed, 02 Aug 2017 15:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=Iku15DIsGuyWoulywbN+QNAO6vSAN33rjinkLJh/pgw=; b=EsWv10YusKqXQK1Z6GXVddulcEc5cgDg8QrktltqE2ioPs9gVEDk89NQARnB7kRphS wloLLMs7Tq1FVG3efiWw0aBFo+KuwYCCUNiBeIfGuUhljm465GdkxPnDBWb8GxmPXobP jExbaWdhNyK5DwS76qQqcq8qpptFYnGqrEL/M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Iku15DIsGuyWoulywbN+QNAO6vSAN33rjinkLJh/pgw=; b=V1RbCaYMapoSzHy9WYoIN5/TSXZN5X0nV0DDlBklpdvjS8arT+iAWFvnYaANyJKXF6 h+HNsk14KBiRZcuBiLHsEVk7kc22jqWfdTktk4MKC0kv7P8m56hZ1qDpnj+ks5malqP/ vKGU/fyC6Q1pfAp3w4VSutJM8qPnDyZ+9u48ACmU1Qjt9x2w6mNNX7lOtCVwkde9+zDu NQRbAJbsMZxIUUeSBZkpEwHfVNtmyChVHpsqVK38VIP2wwxJB7UXbsd3d9cmNhxFsRWG 3Do0yAzDrNbjLMqAFHj90nSyBfsY2DOWh96DQbkKpZJ8WYes4CpvIuMc4x5XLs7aThAX Nc6Q== X-Gm-Message-State: AIVw113puI4Va8pVPQeHgGBDKpGvurOUMB6YHt3tcLEiToZTdHGGtgpH z47f6YbyPpKXOnVqHSDe2FxhA2tkq64+Cp6A0rDARVs5cM6u8ZUxrbYN1FhvE/U/aMveUZnWrfw FP1fuzh0= X-Received: by 10.99.103.129 with SMTP id b123mr19927136pgc.14.1501714031770; Wed, 02 Aug 2017 15:47:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Wed, 2 Aug 2017 15:46:41 -0700 (PDT) From: Brian Campbell Date: Wed, 2 Aug 2017 16:46:41 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c0568ce6b22a50555cd0b61" Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 22:47:14 -0000 --94eb2c0568ce6b22a50555cd0b61 Content-Type: text/plain; charset="UTF-8" Not sure of the status at this point (it is expired) but the draft-ietf-oauth-closing-redirectors WG document in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#section-2.3 suggests using the Content Security Policy header to limit the information sent in the referer something like this: Content-Security-Policy: referrer origin; Consistent with the latest draft of https://w3c.github.io/ webappsec-referrer-policy/ and according to Mozilla (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ Content-Security-Policy/referrer) the Content-Security-Policy (CSP) referrer directive is obsolete and deprecated. And it looks like Referrer-Policy should be used instead for that purpose (again see Mozilla: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy). So the draft-ietf-oauth-closing-redirectors document should probably suggest the Referrer-Policy something more like this: Referrer-Policy: strict-origin -- *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.* --94eb2c0568ce6b22a50555cd0b61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not sure of the status at this point (it is expired) = but the draft-ietf-oauth-closing-redirectors WG document in https://w3c.github.io/webappsec-referrer-policy/ and accordi= ng to Mozilla (see https://de= veloper.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-= Policy/referrer) the Content-Security-Policy (CSP) referrer directive is obsolete and =20 deprecated. And it looks like Referrer-Policy should be used instead for that purpose (again see Mozilla: https://deve= loper.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy= ). So the draft-ietf-oauth-closing-redirectors document should probably sug= gest the Referrer-Policy something more like this:

=C2=A0=C2=A0 Refe= rrer-Policy: strict-origin



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c0568ce6b22a50555cd0b61-- From nobody Wed Aug 2 15:47:51 2017 Return-Path: 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 61634126B6E for ; Wed, 2 Aug 2017 15:47:50 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mrBqd2JmsZwu for ; Wed, 2 Aug 2017 15:47:49 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 3206B129B40 for ; Wed, 2 Aug 2017 15:47:49 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id 80so27168358uas.0 for ; Wed, 02 Aug 2017 15:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9SkQ28yxrpmXYHuLIDDvf14xU0WLZzE3fuJqvsGuLXk=; b=llB8MIlIZZaY+uUa3Pkaa64EKlRx2GI6hXBAZ9FBMYtPAE5LKo3kb9A1wiAXbZ6So2 AozjhfNfOFTcW2pMeBg5Sa2yFN7MMZcrpg22uoHYsA6+XBXWZkanUlX6MXpQjhzmQjYk NJorB61Zzn0jZ6bsASA3YgREfPwGjTCc28485NtcjttE/7LHDXbwu8GdXiq2uToMScaa 8nZcGw2bPgAljsz7o4/A8tztlP4pTRzXZixfAs589TQVzSVvo/tNkRiBshhzO8GoNr5j NLMXktK1fY4svWwQl+w3WVSTr2hfJF/X9Ppfc9sO1BONwb0/GGVdETi19ksDG+D3ApbO vHfg== 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=9SkQ28yxrpmXYHuLIDDvf14xU0WLZzE3fuJqvsGuLXk=; b=faJ5g67KQOt1dHrK9KX+1L3K/W2LR42vDl54ieqoTuzDTq20f7IO4PgCO6cK9RQhjY mcX6ItgYcdf9aO2PkmkJ53Cxj3hvyLSKd7gcZ/pwmB3BX+AC0wIqlill45makf5V9mkM 9xn92SjvfaLn2LjgbqltpEwf/V3nDSXf0/CuJS8ZWJ4xBMTt4cFQsk+YSxga5kWKITgg Q1uFuaa4DHjj3mFdwY1UpPqcgJ8XchcLZY9hwTnvzhNhY7L2pgw+cJnP/w8rBfgxBsdC MCsoKul4WFXQLjiKgycPHXpUCpZiwcWZ/hAahUm4r8yCQPYCh1pm5bazshZRKrFzHBP7 VG4Q== X-Gm-Message-State: AIVw113xWH2XEaIwikHl1uoFuyq27sD6jMxmCzx7IWBFB27+Wvm8ITvl oLi/+WU2iiggYz82YDt3R6g9QJJKuA== X-Received: by 10.159.52.79 with SMTP id s15mr18484200uab.157.1501714068411; Wed, 02 Aug 2017 15:47:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.84.70 with HTTP; Wed, 2 Aug 2017 15:47:47 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Wed, 2 Aug 2017 18:47:47 -0400 Message-ID: To: Bone Bizz Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="f403043ed1d49a1a7d0555cd0da2" Archived-At: Subject: Re: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 22:47:50 -0000 --f403043ed1d49a1a7d0555cd0da2 Content-Type: text/plain; charset="UTF-8" Use the following link to subscribe: https://www.ietf.org/mailman/listinfo/oauth Regards, Rifaat On Wednesday, August 2, 2017, Bone Bizz wrote: > Hello, id like to join the mailing list for Android. Thanks alot. > --f403043ed1d49a1a7d0555cd0da2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Use the following link to subscribe:=

Regards,
=C2=A0Rifaat


On We= dnesday, August 2, 2017, Bone Bizz <bonebizz21@gmail.com> wrote:
<= div dir=3D"auto">Hello, =C2=A0id like to join the mailing list for Android.= =C2=A0 Thanks alot. =C2=A0
= --Apple-Mail=_677C0CE5-7696-45ED-937C-409C5E610A85-- --Apple-Mail=_95AC13F6-387C-43A7-B5FB-911E24E63DFE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAx MDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye 12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFb zz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY 17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSR SR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwID AQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPng HgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v Y3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkq hkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9 CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13Ob fpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/Tc TXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmy e3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGw MIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0y NTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3Px A3uZ8LQwCQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcwODAzMTA0ODU5WjAjBgkqhkiG9w0BCQQxFgQUGe0D3ieiFii+g8l0Y6rmz5K3hf4w gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG SIb3DQEBAQUABIIBAElS6cETsbQzaLmLtfaX+KNa6nhTGpsVRBL8tTKHnkkfoedpX8cLKgdEWSq3 cVZYVbL1jUMViDzFBEg0xwMNdWfyOcI+xcEU8+dOo2rcmvK6aVfAeDHM6wlP/SO9zSWL+w+Skh9Y DzJxudAu6eb1NMfnvGfklkuLKrZZhK3rXQvQUh4qJ0w50Ta4yN1OE/CvAiRWTCVd+SeTSTxIY4I5 eeSKt+woHFMDNObzDzkzjl40HRK8BAuad5GvdEkt6bk5USMxi6l0KAJiQ0uIaSALyn+O7UJwnvI4 FCYwzVdXoe15QynWrnjtFWHQ6I6okeHyaE2YFL8jQn1nXmmrzGonEAsAAAAAAAA= --Apple-Mail=_95AC13F6-387C-43A7-B5FB-911E24E63DFE-- From nobody Thu Aug 3 04:51:29 2017 Return-Path: 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 CA7B4129AF6 for ; Thu, 3 Aug 2017 04:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 14PwMpZryT_r for ; Thu, 3 Aug 2017 04:51:25 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) (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 3BF8512700F for ; Thu, 3 Aug 2017 04:51:25 -0700 (PDT) Received: from [85.212.1.42] (helo=[10.0.8.4]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ddEev-0006EM-MD; Thu, 03 Aug 2017 13:51:21 +0200 From: Torsten Lodderstedt Message-Id: <1321FC7E-EA45-4181-BC8F-90086FCA7180@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_AB6584C1-BC36-4EE9-84AD-BBB2F0CA6E4A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 13:51:19 +0200 In-Reply-To: <46E8AB48-2DD1-4C1C-B8FA-0FBADAB7596F@ve7jtb.com> Cc: Denis , oauth To: John Bradley References: <46E8AB48-2DD1-4C1C-B8FA-0FBADAB7596F@ve7jtb.com> X-Mailer: Apple Mail (2.3273) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 11:51:28 -0000 --Apple-Mail=_AB6584C1-BC36-4EE9-84AD-BBB2F0CA6E4A Content-Type: multipart/alternative; boundary="Apple-Mail=_ACA3B866-C01A-485A-81F6-C62356F50180" --Apple-Mail=_ACA3B866-C01A-485A-81F6-C62356F50180 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii +1 > Am 31.07.2017 um 16:01 schrieb John Bradley : > > For access tokens I would like to see a use case for a completely = > decoupled and anonymous RS that is not just a misuse of OAuth for = > Authentication, before trying to add a feature like this. --Apple-Mail=_ACA3B866-C01A-485A-81F6-C62356F50180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1
Am 31.07.2017 um 16:01 schrieb John Bradley <ve7jtb@ve7jtb.com>:

For access tokens I would like = to see a use case for a completely =3D
decoupled and anonymous RS that = is not just a misuse of OAuth for =3D
Authentication, before trying to = add a feature like this.

= --Apple-Mail=_ACA3B866-C01A-485A-81F6-C62356F50180-- --Apple-Mail=_AB6584C1-BC36-4EE9-84AD-BBB2F0CA6E4A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAx MDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye 12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFb zz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY 17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSR SR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwID AQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPng HgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v Y3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkq hkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9 CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13Ob fpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/Tc TXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmy e3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGw MIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0y NTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3Px A3uZ8LQwCQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcwODAzMTE1MTIwWjAjBgkqhkiG9w0BCQQxFgQUnAgt4HRutceelZ03PsX8i4FpLPow gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG SIb3DQEBAQUABIIBADdwbb1RBAWPQrYXiOfiCoLH5nR8BbyHBckZU0JKz9xUDY4Y971uTG/CKYSA FiwPiyavcFwyKbd2ueEZLWBhjccs9llAeynRzIDi6xe6ADJ+3kZQf3tdNG0VP/D0Sskegaxtx9JM BKwY4xIMku8k9+6HJrvid6RtFj9iqxEpovFLeTZgeXRc4sPDp+tnJ/zbZcgZYL79SJXsyCrIT/P5 XbG/huIhRQ97aO3WCmg9HqqkA9iyKtnerQtfrg2hTPbhn3vqANz+GcXZFmQ7UIWcrtYITqg5o2HE ARbLqIfHLtmH7N1bLz/QL8yGz0WUU/uHof87T6mQbyxLcLBba+ZT1acAAAAAAAA= --Apple-Mail=_AB6584C1-BC36-4EE9-84AD-BBB2F0CA6E4A-- From nobody Thu Aug 3 08:21:29 2017 Return-Path: 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 9DBA3132116 for ; Thu, 3 Aug 2017 08:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 2Iz9o3V-DLhI for ; Thu, 3 Aug 2017 08:21:26 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 CD0411274A5 for ; Thu, 3 Aug 2017 08:21:25 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id t128so7538615lff.2 for ; Thu, 03 Aug 2017 08:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zC43HeukJWJAiYrdceuQ+dIwmZO5qaNd3B4HIdxB7jw=; b=Uj2rzPjedW0Ct9BNlOUOrbgpXTrDtJbELnUB0VB+zGZRtwtOIyu9U6RSi99wGqXEfo pSRHKLaO5rAg9sh8pKxxDW9DSXFcj209pLypfqNsgNRXU7xcZpFUax1V4ehYHlGWOQr5 uKmfolPPiWpXHuZzQOq10ipI555yJVzqNdeaBHpH4zLILtLr1GYIgTbKt0H9IPFE5oKl /L8FTXSX67SaQg0jwtKhlFVxhzFk+maXwsjqb3UHWCa1CDZrIEvBUm56vR4aXUNyNfP/ wakCn0yfG3qUejWZDaGxEyy/V2SG19Z9FsGqhqMSt6pn+ZTVaeCHtkE0DHUHac8LCN/r 078A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zC43HeukJWJAiYrdceuQ+dIwmZO5qaNd3B4HIdxB7jw=; b=LVP9W1Ei3+q8jmz83QKK11xMorAAhnPaZ4Kc8r3pR7J7vR1EQDAzwU4NNvPM0+tO69 g+RTkLundjMdS2qe7HE/SZfiW+RHarOjMhybo/vVYtOpZ20wN4uNjX3YqgTLrEcc4kLE rsG900McYGF1rp4/+iuMzQ6w8W5NSbEaNzA1yBkRkKth79mgvJZfTP1hoJ6IIyQjuRc3 WgQOieG8C8Mp05GWRDvIFT/DNJJ+BiQdG2kwVY79do9+s/4lORPZcyXNTIYSrAgxsYaZ WAogrAogpVegzFjkYKmwE7CpWK0pv5hEQ+fdMw/GE0F7zDipxuaa0IT56PMYAV17xsqt 7Lyw== X-Gm-Message-State: AHYfb5jSR6pJB4o5RvfrxYfFomv1DdbqsnqdXviG083DeZ7qRXYzcJul a0a8NUKhXPXEQ1iC X-Received: by 10.25.199.77 with SMTP id x74mr781505lff.196.1501773683663; Thu, 03 Aug 2017 08:21:23 -0700 (PDT) Received: from [192.168.86.103] ([191.115.81.54]) by smtp.gmail.com with ESMTPSA id s68sm3268839lfg.46.2017.08.03.08.21.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 08:21:23 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 11:21:14 -0400 In-Reply-To: Cc: oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1a1b98f9f5120555daee53" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 15:21:29 -0000 --94eb2c1a1b98f9f5120555daee53 Content-Type: multipart/alternative; boundary="Apple-Mail=_14CF77BD-1E2F-49C6-8E97-8DFFA2CB0992" --Apple-Mail=_14CF77BD-1E2F-49C6-8E97-8DFFA2CB0992 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Before I make a change. Do we know if some browsers don=E2=80=99t support Referrer-Policy and = may still need Content-Security-Policy. We could recommend sending both or provide some hint about browser = strings to look for. John B. > On Aug 2, 2017, at 6:46 PM, Brian Campbell = wrote: >=20 > Not sure of the status at this point (it is expired) but the = draft-ietf-oauth-closing-redirectors WG document in = https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#sectio= n-2.3 = suggests using the Content Security Policy header to limit the = information sent in the referer something like this:=20 >=20 > Content-Security-Policy: referrer origin; >=20 > Consistent with the latest draft of = https://w3c.github.io/webappsec-referrer-policy/ = and according to = Mozilla (see = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security= -Policy/referrer = ) the Content-Security-Policy (CSP) referrer directive = is obsolete and deprecated. And it looks like Referrer-Policy should be = used instead for that purpose (again see Mozilla: = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy = ). So the draft-ietf-oauth-closing-redirectors document should probably = suggest the Referrer-Policy something more like this: >=20 > Referrer-Policy: strict-origin=20 >=20 >=20 >=20 > 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 --Apple-Mail=_14CF77BD-1E2F-49C6-8E97-8DFFA2CB0992 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Before I make a change.

Do we know if some browsers don=E2=80=99t= support Referrer-Policy and may still need = Content-Security-Policy.

We could recommend sending both or provide some hint about = browser strings to look for.

John B.

On = Aug 2, 2017, at 6:46 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Not sure of the status at this point (it is = expired) but the draft-ietf-oauth-closing-redirectors WG document in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirector= s-00#section-2.3 suggests using the Content Security Policy header = to limit the information sent in the referer something like this:

  Content-Security-Policy: referrer = origin;

Consistent with the latest draft of = https://w3c.github.io/webappsec-referrer-policy/ and according to Mozilla (see = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/referrer) the Content-Security-Policy (CSP) referrer directive is obsolete and =20= deprecated. And it looks like Referrer-Policy should be used instead for that purpose (again see Mozilla: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy). So the = draft-ietf-oauth-closing-redirectors document should probably suggest = the Referrer-Policy something more like this:

   Referrer-Policy: strict-origin



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

= --Apple-Mail=_14CF77BD-1E2F-49C6-8E97-8DFFA2CB0992-- --94eb2c1a1b98f9f5120555daee53 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIJHVAooLea0JMJuUa11UW7PC3Ors CuX/e6FiPeWoy+mtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwMzE1MjEyNFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQAGgPgRX5gtUjSOQ++lWhcR5MUMklprMOs57iYV23gGFc0X MvO8OUc3YNipa3GDiHabSIDdAuzkHj5t0LrNWU3kkgeg+RkdheRnePxgITMHy2oi1Jjokw781Jmb s4iWrHMIEPW44+K7fimMOksocwZPiDIKGNfzlJLWxFyADSsXqtvDnnFkoJhxBPHh8wz6RrTUAeXd BHruw0zGd6HbTMph0rxtgaXeSF8iXE+LL8pVP8bezyU2d+PGMtyEnxNYrlVV6/lOI76PbKRMud+K 3n00/+Zuj1d+uExxZ9zLv8vLm1srxB2+ic2s0yLiht0k1idt95NIShYaKMDiwS5wDE4Q --94eb2c1a1b98f9f5120555daee53-- From nobody Thu Aug 3 08:35:35 2017 Return-Path: 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 16444132477 for ; Thu, 3 Aug 2017 08:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 hq65Rqb0oXnz for ; Thu, 3 Aug 2017 08:35:32 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 F40C413246D for ; Thu, 3 Aug 2017 08:35:31 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id o85so7683215lff.3 for ; Thu, 03 Aug 2017 08:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eqTmQd1rj7mbXL3OU/27WNKS9UVuLmxNYv6VGgevMlk=; b=SmeJdcrrHFnOZqS5IgIt0ZIl7ll7dJcfM1sTnbcwBp+EfMNXQGSh5Mcwn2DUYt1Xnn L1F2kwIzuj/uPedMpssuxWbc7nerFfBup2px0FtqmikZ/9WJAO0vi2F8WIhw/w0peO1q kBCTONSs0foaLUCXFMD8ZKItxdV1V2rUImpRaNmF/RSruaHBICUK2nQEgBWy3mCt7XWF 7AbWuk8hplL8JrJfpWuwkd8V/6dlZqBY0gCjsWO+B8Ryk3AVue4hhy4480cY4Q6bJLDH c/br1uaqjWmIyQl+/K/km/QHoYXEbIZE96v199eRZONwpELvnmXEZY7J4WT/1HuswOTX iFSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eqTmQd1rj7mbXL3OU/27WNKS9UVuLmxNYv6VGgevMlk=; b=Iq8hZtDITWJ7A++vlHzHIuz9lEH5DZPNEFCwQsEyLJLS/Ap8b9CcQZbTj+KVZ0gMmZ evpIFN2KUKv/IHAvBuzNRxQ8mDBzHJnS9VGWgjaDF6Xlmbl4onvK4671spP989OWfdom /XkB9ywqmo43Exs4vkVMZ5P4OsDVtmX7a1JqWCPRxtv2bmhjStnzUXcrveHFHrVWjsLV 7HmdZQeuYnGcakXQ8qAnAf8xGMyRAc1ueJYnTuj/5vehLGJOWlWRiY9b90CtLHoHdczA uD1Z2qidsZDuPiKO7R2VCcYgT+w3hMQbJIegDZfIK4BctCktVKy3qVES2FX+KRJO+KwJ /awQ== X-Gm-Message-State: AHYfb5hinXoAUrAX1ywE36URRo2rBpRFAnI9dKk6QDum1d+dDi34X8bX E/XP283MIsYJSr9i X-Received: by 10.25.93.70 with SMTP id p6mr786399lfj.139.1501774530002; Thu, 03 Aug 2017 08:35:30 -0700 (PDT) Received: from [192.168.86.103] ([191.115.81.54]) by smtp.gmail.com with ESMTPSA id j71sm1230094lfk.32.2017.08.03.08.35.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 08:35:29 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 11:35:19 -0400 In-Reply-To: Cc: oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045e26406b45240555db21d5" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 15:35:35 -0000 --f403045e26406b45240555db21d5 Content-Type: multipart/alternative; boundary="Apple-Mail=_798213D5-B5DD-47F8-9773-87D0B0EBE1EF" --Apple-Mail=_798213D5-B5DD-47F8-9773-87D0B0EBE1EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian=20 To answer my own question to some extent, this page has support status = for the browsers: http://caniuse.com/#feat=3Dreferrer-policy It looks like only FireFox supports strict-origin. Most of them support origin. Some like IE, Opera Mini and older versions of Android (4) don=E2=80=99t = support Referrer-Policy at all. So I think=20 Referrer-Policy: origin With a note that you still need to use Content-Security-Policy: for IE = and Android (4). There may be some other OEM provided browsers on = Android from Samsung and others that may not have support but they are a = small number in general. John B. > On Aug 2, 2017, at 6:46 PM, Brian Campbell = wrote: >=20 > Not sure of the status at this point (it is expired) but the = draft-ietf-oauth-closing-redirectors WG document in = https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#sectio= n-2.3 = suggests using the Content Security Policy header to limit the = information sent in the referer something like this:=20 >=20 > Content-Security-Policy: referrer origin; >=20 > Consistent with the latest draft of = https://w3c.github.io/webappsec-referrer-policy/ = and according to = Mozilla (see = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security= -Policy/referrer = ) the Content-Security-Policy (CSP) referrer directive = is obsolete and deprecated. And it looks like Referrer-Policy should be = used instead for that purpose (again see Mozilla: = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy = ). So the draft-ietf-oauth-closing-redirectors document should probably = suggest the Referrer-Policy something more like this: >=20 > Referrer-Policy: strict-origin=20 >=20 >=20 >=20 > 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 --Apple-Mail=_798213D5-B5DD-47F8-9773-87D0B0EBE1EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Brian 

To answer my own question to some extent, this page has = support status for the browsers:
http://caniuse.com/#feat=3Dreferrer-policy

It looks like only = FireFox supports strict-origin.

Most of them support origin.

Some like IE, Opera Mini = and older versions of Android (4) don=E2=80=99t support Referrer-Policy = at all.

So I = think 
Referrer-Policy: origin

With a note that you still need to use =  Content-Security-Policy: for IE and Android (4).  There may = be some other OEM provided browsers on Android from Samsung and others = that may not have support but they are a small number in = general.

John = B.


On = Aug 2, 2017, at 6:46 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Not sure of the status at this point (it is = expired) but the draft-ietf-oauth-closing-redirectors WG document in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirector= s-00#section-2.3 suggests using the Content Security Policy header = to limit the information sent in the referer something like this:

  Content-Security-Policy: referrer = origin;

Consistent with the latest draft of = https://w3c.github.io/webappsec-referrer-policy/ and according to Mozilla (see = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/referrer) the Content-Security-Policy (CSP) referrer directive is obsolete and =20= deprecated. And it looks like Referrer-Policy should be used instead for that purpose (again see Mozilla: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy). So the = draft-ietf-oauth-closing-redirectors document should probably suggest = the Referrer-Policy something more like this:

   Referrer-Policy: strict-origin



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

= --Apple-Mail=_798213D5-B5DD-47F8-9773-87D0B0EBE1EF-- --f403045e26406b45240555db21d5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIOZOy7uJB4UP/TpBPtHYbNxvGBLx b0/aS2/PtTmo43A3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwMzE1MzUzMFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQAMyks0ep+6wMNh1daAfxOQzPXy/BKSgZ+ENo4EaXRk7kes /M1dfnLeabytF99P1Jgh9vQMMEKlNwZg7pgqSNH24FpxRNLL8H4OwuHd9GJ6QAcGZBWVIBQBz14g LdpKRdf03AaMp2NgCglBeHTGbG/Z6Mn+SP541ga4/JXp1vVQ0j2XPMIe74rq1Laa7xhy4phQZbHF x8rqBS6XbFjvef5jKAAn1X+i147l0ejAGDHj30cxpl93SNH1aEgEXYKLuNGUbf5PFnVpqSpQ0bJz t024kYZcY3o9rcyHnn4OFYqszHOLLS36SyDD+AJX+ZlNMW/c4NlmUcwn8FAr2jVOdghh --f403045e26406b45240555db21d5-- From nobody Thu Aug 3 09:44:34 2017 Return-Path: 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 E3E2F13256A for ; Thu, 3 Aug 2017 09:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-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 0rAbiX5Khcgv for ; Thu, 3 Aug 2017 09:44:31 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 F15AC13255A for ; Thu, 3 Aug 2017 09:44:30 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id v77so8344499pgb.3 for ; Thu, 03 Aug 2017 09:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rd4fn3qiTB1elGIkQO75J6inst50VRxfgSVOln32lvA=; b=Ka0S+jm12TYBMb/ceI4C/rJZlY3l3dM7J97ZUtNtnyG1JJxeZwP0J2dCFdadzuPrmI HJyAR34q0yAwEE8ZCJgOLUI5TlIbgNzhXR8PIwhlO1tBRRQcRauLuBKdKmACguEQrKSj 28pXTfYKI8tBrzRVmhGoEGLtreqAJR+ZtgUiY= 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=Rd4fn3qiTB1elGIkQO75J6inst50VRxfgSVOln32lvA=; b=T/eB451roW7MOjQZe+2tGUIK21wejcGa6rVAzbwJeH9MyEHfOQrQjhFv/8ZEjtAPXn objgW6Bg2cyIgeQGoy0mJvgQJGN1I8A4TXTf7d8kIbYpyAKZQ2BWJzA3vyWEZTu+NbeY OqaiIVgHtfRN+dgMx6x+UCr1wqdbNTo7ueToKe+WcXCqehFCdrqcXGnVzTqDPPPcbQ76 Jb+kqrBmqEOOdbqtZ5BHtvqkGQqRht6LGM8sLIuZCdpY/H+WQfs5YksEmvcmwNiWZoTv ZSS5lSoXqCnubtTLEnI1QzP7dK8uVBQGK/vdMqna6Nz/Rx7PFa+si82/DdXz4Re1xWZP M/nQ== X-Gm-Message-State: AIVw111BHmOid7qbV2ZSG5liUpR9js7M/lLRvyRn5F+BRa5oMthkupus 5gZKVsszWhCXz3oEh7kIIwQ1jAqDYoCphHnmPlRKvy4pVli1raPjXJfQtr0nUyIlqFhJJugrGwy DNSVpmdM= X-Received: by 10.99.103.129 with SMTP id b123mr2141017pgc.14.1501778670378; Thu, 03 Aug 2017 09:44:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Thu, 3 Aug 2017 09:43:59 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 3 Aug 2017 10:43:59 -0600 Message-ID: To: John Bradley Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c0568ce2e00950555dc1844" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:44:33 -0000 --94eb2c0568ce2e00950555dc1844 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Really all I know is that recent versions of Chrome complain that referrer is an unrecognized Content-Security-Policy directive, which led me to look up the changes and content in my original message. On Thu, Aug 3, 2017 at 9:35 AM, John Bradley wrote: > Brian > > To answer my own question to some extent, this page has support status fo= r > the browsers: > http://caniuse.com/#feat=3Dreferrer-policy > > It looks like only FireFox supports strict-origin. > > Most of them support origin. > > Some like IE, Opera Mini and older versions of Android (4) don=E2=80=99t = support > Referrer-Policy at all. > > So I think > Referrer-Policy: origin > > With a note that you still need to use Content-Security-Policy: for IE > and Android (4). There may be some other OEM provided browsers on Androi= d > from Samsung and others that may not have support but they are a small > number in general. > > John B. > > > On Aug 2, 2017, at 6:46 PM, Brian Campbell > wrote: > > Not sure of the status at this point (it is expired) but the > draft-ietf-oauth-closing-redirectors WG document in > https://tools.ietf.org/html/draft-ietf-oauth-closing- > redirectors-00#section-2.3 suggests using the Content Security Policy > header to limit the information sent in the referer something like this: > > Content-Security-Policy: referrer origin; > > Consistent with the latest draft of https://w3c.github.io/webappse > c-referrer-policy/ and according to Mozilla (see > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co > ntent-Security-Policy/referrer) the Content-Security-Policy (CSP) > referrer directive is obsolete and deprecated. And it looks like > Referrer-Policy should be used instead for that purpose (again see Mozill= a: > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy= ). > So the draft-ietf-oauth-closing-redirectors document should probably > suggest the Referrer-Policy something more like this: > > Referrer-Policy: strict-origin > > > > *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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --94eb2c0568ce2e00950555dc1844 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Really all I know is that recent versions of Chrome compla= in that referrer is an unrecognized Content-Security-Policy directive, whic= h led me to look up the changes and content in my original message.=C2=A0 <= br>

On Thu, = Aug 3, 2017 at 9:35 AM, John Bradley <ve7jtb@ve7jtb.com> wro= te:
B= rian=C2=A0

To answer my own question to some extent, thi= s page has support status for the browsers:

It looks like only Fi= reFox supports strict-origin.

Most of them support= origin.

Some like IE, Opera Mini and older versio= ns of Android (4) don=E2=80=99t support Referrer-Policy at all.
<= br>
So I think=C2=A0
Referrer-Pol= icy: origin

With a note that you still need to use= =C2=A0Content-Security-Policy: for IE and Android (4).=C2=A0 There may be = some other OEM provided browsers on Android from Samsung and others that ma= y not have support but they are a small number in general.

John B.


On Aug 2, 2017, at 6:46 PM, Brian Campbell <bcampbell@ping= identity.com> wrote:

Not sure of the status at this point (it is expired) but the draft-ietf-o= auth-closing-redirectors WG document in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirec= tors-00#section-2.3 suggests using the Content Security Policy header t= o limit the information sent in the referer something like this:

= =C2=A0 Content-Security-Policy: referrer origin;

Consistent with the= latest draft of https://w3c.github.io/webappsec-referrer-policy/<= /a> and according to Mozilla (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co= ntent-Security-Policy/referrer) the Content-Security-Policy (CSP) referrer directive is obsolete and =20 deprecated. And it looks like Referrer-Policy should be used instead for that purpose (again see Mozilla: https://deve= loper.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy= ). So the draft-ietf-oauth-closing-redirectors document should probabl= y suggest the Referrer-Policy something more like this:

=C2=A0=C2=A0= Referrer-Policy: strict-origin



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.=C2=A0 If you have received this communicatio= n in error, please notify the sender immediately by e-mail and delete the m= essage and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing = list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/oauth
=



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c0568ce2e00950555dc1844-- From nobody Thu Aug 3 09:51:40 2017 Return-Path: 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 C512B132003 for ; Thu, 3 Aug 2017 09:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 S05tuzpNb9ci for ; Thu, 3 Aug 2017 09:51:34 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 277F51318A8 for ; Thu, 3 Aug 2017 09:51:34 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id m86so8553055lfi.4 for ; Thu, 03 Aug 2017 09:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ccjks4ND5Cdqo8735ZurXRUsO6eJo2oT5VIcqwnQm3Q=; b=YlgBdL7h3kXC2U2PHpVFVK+pSDMY/bDSBivHp8ypPjET0wPrkqY402sdZ9dSWg89+R 05Uv5zdk8UEiXzKkS4E1DEndGQQazoPUPzYbMJgCmsjavpeUQVHAUUPwinITlPkQJRps 8NyJKCPxVikM55cj3gxqT6LIamSH66APRUaZBSiU5cCcWU9w3WUGg0Dh2BVkIrRkAFcM OmeoLShmV0IOahH06DI8/5bCy3Qlh4CG08WiZkxo3w/85Ozp/jtpy1RoSb1tC3FrmXPU 4hTob5i7WRb/9QZ1iHaJDYiQaOHVDkloIM7qmV477JiyE9e6fttyEs/uijbU1cc3H530 tZvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ccjks4ND5Cdqo8735ZurXRUsO6eJo2oT5VIcqwnQm3Q=; b=nBDS6VNVkQB5h1BnW6X1ECdAPiTvKGO5VlypHJBq48GCBGWt5MS2cg0sZ85pSYuaul v5EXXS0Do8FDIID7UHb/rZRy019VXUdT393Sh0rCwSuHcPOBlQUPUCIQkS3gfvVWzqaf dlwR7fABy+a3je7nSjvLPoy8SGRkgDrgHgq4NF/4n/WQCq2WrVQA1RWpFKiC15S7V5CK H9DvO0tehSC2O9LVqqTZsSxe1huQ5Ybx5LmGeEdR21dZhUfgElvD0R4LaG7MvmUW5nkz XMGjXKgpwHh0i4O1tgV14hFpqKKzxuNN1iQRSTfyE8ocnqK9rvmV5bEyuTFDBjAOz+CL o8oA== X-Gm-Message-State: AHYfb5hNCTON01d4W1oABxiB1GF/UPFFqLjmtyzeh9KbbXKEGDkXbCxb ZhY4plKDsZtCw4l7ecHl4Q== X-Received: by 10.25.27.20 with SMTP id b20mr808299lfb.131.1501779092117; Thu, 03 Aug 2017 09:51:32 -0700 (PDT) Received: from [192.168.86.103] ([191.115.81.54]) by smtp.gmail.com with ESMTPSA id e7sm474218ljb.84.2017.08.03.09.51.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 09:51:31 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 12:51:25 -0400 In-Reply-To: Cc: oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11401d6e56ed1d0555dc31a2" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:51:38 -0000 --001a11401d6e56ed1d0555dc31a2 Content-Type: multipart/alternative; boundary="Apple-Mail=_5E40DEE1-C10C-42F1-82A8-75E8A1D1A1FD" --Apple-Mail=_5E40DEE1-C10C-42F1-82A8-75E8A1D1A1FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No one ever said that browsers are consistent. I think Chrome has supported a subset of the new header for a while but = won=E2=80=99t have full support until Chrome 61 gets out of beta. Is chrome showing a user visible error with the old header? Easiest thing would be to use the new header and deny access to anyone = still using IE:) John B. > On Aug 3, 2017, at 12:43 PM, Brian Campbell = wrote: >=20 > Really all I know is that recent versions of Chrome complain that = referrer is an unrecognized Content-Security-Policy directive, which led = me to look up the changes and content in my original message. =20 >=20 > On Thu, Aug 3, 2017 at 9:35 AM, John Bradley > wrote: > Brian=20 >=20 > To answer my own question to some extent, this page has support status = for the browsers: > http://caniuse.com/#feat=3Dreferrer-policy = >=20 > It looks like only FireFox supports strict-origin. >=20 > Most of them support origin. >=20 > Some like IE, Opera Mini and older versions of Android (4) don=E2=80=99t= support Referrer-Policy at all. >=20 > So I think=20 > Referrer-Policy: origin >=20 > With a note that you still need to use Content-Security-Policy: for = IE and Android (4). There may be some other OEM provided browsers on = Android from Samsung and others that may not have support but they are a = small number in general. >=20 > John B. >=20 >=20 >> On Aug 2, 2017, at 6:46 PM, Brian Campbell = > wrote: >>=20 >> Not sure of the status at this point (it is expired) but the = draft-ietf-oauth-closing-redirectors WG document in = https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#sectio= n-2.3 = suggests using the Content Security Policy header to limit the = information sent in the referer something like this:=20 >>=20 >> Content-Security-Policy: referrer origin; >>=20 >> Consistent with the latest draft of = https://w3c.github.io/webappsec-referrer-policy/ = and according to = Mozilla (see = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security= -Policy/referrer = ) the Content-Security-Policy (CSP) referrer directive = is obsolete and deprecated. And it looks like Referrer-Policy should be = used instead for that purpose (again see Mozilla: = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy = ). So the draft-ietf-oauth-closing-redirectors document should probably = suggest the Referrer-Policy something more like this: >>=20 >> Referrer-Policy: strict-origin=20 >>=20 >>=20 >>=20 >> 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 = >=20 >=20 >=20 > 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. --Apple-Mail=_5E40DEE1-C10C-42F1-82A8-75E8A1D1A1FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 No one ever said that browsers are consistent.

I think Chrome has = supported a subset of the new header for a while but won=E2=80=99t have = full support until Chrome 61 gets out of beta.

Is chrome showing a user visible error = with the old header?

Easiest thing would be to use the new header and deny access = to anyone still using IE:)

John B.


On Aug 3, 2017, at 12:43 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

Really all I know is that recent versions of Chrome complain = that referrer is an unrecognized Content-Security-Policy directive, = which led me to look up the changes and content in my original = message. 

On Thu, Aug 3, 2017 at 9:35 AM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
Brian 

To answer my own question to some = extent, this page has support status for the browsers:
http://caniuse.com/#feat=3Dreferrer-policy

It looks like only FireFox supports = strict-origin.

Most of them support origin.

Some like IE, Opera Mini and older = versions of Android (4) don=E2=80=99t support Referrer-Policy at = all.

So I = think 
Referrer-Policy: origin

With a note that you still need to use =  Content-Security-Policy: for IE and Android (4).  There may = be some other OEM provided browsers on Android from Samsung and others = that may not have support but they are a small number in = general.

John = B.


On Aug 2, 2017, at 6:46 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Not sure of the status at this point (it is = expired) but the draft-ietf-oauth-closing-redirectors WG = document in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#section-2.3 suggests using the Content = Security Policy header to limit the information sent in the referer = something like this:

  = Content-Security-Policy: referrer origin;

Consistent with the latest draft of https://w3c.github.io/webappsec-referrer-policy/ and according to Mozilla (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/referrer) the Content-Security-Policy (CSP) referrer directive is obsolete and =20= deprecated. And it looks like Referrer-Policy should be used instead for that purpose (again see Mozilla: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy). So the draft-ietf-oauth-closing-redirectors document should probably suggest the = Referrer-Policy something more like this:

   Referrer-Policy: strict-origin



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



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.

= --Apple-Mail=_5E40DEE1-C10C-42F1-82A8-75E8A1D1A1FD-- --001a11401d6e56ed1d0555dc31a2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIBGTumwZk3/uPmPaLWdweawx8WyF m/nCmRiAkag3aL9fMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwMzE2NTEzMlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQCjvzlnaE77MFWFvwihyQu2GBJJx2UyIvIFGXMEgm/HMqb2 lNZmwlK/pBUjR57auFD7Ae5X4kkDEMq7TmAMya9AOn9ZIfSyeomAmfqMh3sM4lIUidK+cAqrhtir LaysQ4Hwu3WgFCjeyg2Hg+cB9pPZVylyxOmWQqzPxsMMYkw5mQ2H5ReCHrW//aAKEn276H+f3dkU +Fv94DmEfe6sjM7Si+EjGxL4VNWpVczBNeblsXNpVoriGoUYRAmWe/IqabgKuaDv2nF5CiMDVHta 8CLD7sluLXhDWzTb0HTqK+Tc+uUGklFyeSFjBWvvc8uwpR13g/jyBv+DHQiV6IgyKoMZ --001a11401d6e56ed1d0555dc31a2-- From nobody Thu Aug 3 09:56:04 2017 Return-Path: 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 09312132422 for ; Thu, 3 Aug 2017 09:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-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 vPh28wIswDbf for ; Thu, 3 Aug 2017 09:56:01 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 7672E126BF3 for ; Thu, 3 Aug 2017 09:56:01 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id l64so8405868pge.5 for ; Thu, 03 Aug 2017 09:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7VJHifVsFiipMTT4/HxxQfbJrb5OuqghV9cBwh17hZg=; b=VF6gVN0yjRIIkiWtNoLFAy77UvTWTPLTgqS/0w/kW6/vQfopTJAspG3aLI4J7WFp1Z VYqCeVQ51fKW5uwsgkGMWnhZPUV8lhzSP8bnEZdYZxfj+tWwoFdTu//UbWFC74NM+oYX uDdEVGNwTzuaTA14DyEEMXcFnXRCvyvE7K7cg= 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=7VJHifVsFiipMTT4/HxxQfbJrb5OuqghV9cBwh17hZg=; b=g2u82Utk1zgfzAkU0VHmC9KiVG0Wf+c+vvm+kRwzZtuXBSHayaKx7vsjbTndoAONtk 9G16hsYNQhxin01PfoJxftqnOkIcpLYRoo08t0gBl3MgGOKT1gtu3wz8PTbJqZzB5Fmy sfSqyDMSG83zWfQWC5BMHwEZVMvBGcth1SsWoWd4g7uS894tsa+7GoTebMoEllYHJ9lH J5klk0CQojxwLfnVkHYCWwbDPCSE+Qj2ruUZpmafyfXRfZiFHXPAQRCvlH+zOmx2MhCS /TdzY/vA2HAvFPTMcEOf+gONYyXSDpoQxHMVNqJYn1u/OUqyCfSBJE+aXeeKH3OV5YNL VdLA== X-Gm-Message-State: AIVw112jnI5XqFZo5XFhHI8VMkfcH186zIZGSi9vN3oRUucwqk5oC49t BfuvuOloDuG6yHU8T83yMHlw+plBJzxJNucECTB/0QHnknlePx5NNkRq/0TiU7GF+J5H1qRJPkK HHDu/ X-Received: by 10.84.236.4 with SMTP id q4mr2550901plk.423.1501779361059; Thu, 03 Aug 2017 09:56:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Thu, 3 Aug 2017 09:55:30 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 3 Aug 2017 10:55:30 -0600 Message-ID: To: John Bradley Cc: oauth Content-Type: multipart/alternative; boundary="f403045fe2d458f2330555dc413e" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:56:04 -0000 --f403045fe2d458f2330555dc413e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, Chrome only shows the error message deep inside the developer tools console. On Thu, Aug 3, 2017 at 10:51 AM, John Bradley wrote: > No one ever said that browsers are consistent. > > I think Chrome has supported a subset of the new header for a while but > won=E2=80=99t have full support until Chrome 61 gets out of beta. > > Is chrome showing a user visible error with the old header? > > Easiest thing would be to use the new header and deny access to anyone > still using IE:) > > John B. > > > On Aug 3, 2017, at 12:43 PM, Brian Campbell > wrote: > > Really all I know is that recent versions of Chrome complain that referre= r > is an unrecognized Content-Security-Policy directive, which led me to loo= k > up the changes and content in my original message. > > On Thu, Aug 3, 2017 at 9:35 AM, John Bradley wrote: > >> Brian >> >> To answer my own question to some extent, this page has support status >> for the browsers: >> http://caniuse.com/#feat=3Dreferrer-policy >> >> It looks like only FireFox supports strict-origin. >> >> Most of them support origin. >> >> Some like IE, Opera Mini and older versions of Android (4) don=E2=80=99t= support >> Referrer-Policy at all. >> >> So I think >> Referrer-Policy: origin >> >> With a note that you still need to use Content-Security-Policy: for IE >> and Android (4). There may be some other OEM provided browsers on Andro= id >> from Samsung and others that may not have support but they are a small >> number in general. >> >> John B. >> >> >> On Aug 2, 2017, at 6:46 PM, Brian Campbell >> wrote: >> >> Not sure of the status at this point (it is expired) but the >> draft-ietf-oauth-closing-redirectors WG document in >> https://tools.ietf.org/html/draft-ietf-oauth-closing-redirec >> tors-00#section-2.3 suggests using the Content Security Policy header to >> limit the information sent in the referer something like this: >> >> Content-Security-Policy: referrer origin; >> >> Consistent with the latest draft of https://w3c.github.io/webappse >> c-referrer-policy/ and according to Mozilla (see >> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co >> ntent-Security-Policy/referrer) the Content-Security-Policy (CSP) >> referrer directive is obsolete and deprecated. And it looks like >> Referrer-Policy should be used instead for that purpose (again see Mozil= la: >> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Polic= y). >> So the draft-ietf-oauth-closing-redirectors document should probably >> suggest the Referrer-Policy something more like this: >> >> Referrer-Policy: strict-origin >> >> >> >> *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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --f403045fe2d458f2330555dc413e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, Chrome only shows the error message deep inside the de= veloper tools console.

On Thu, Aug 3, 2017 at 10:51 AM, John Bradley <ve7jtb@ve7= jtb.com> wrote:
No one ever said that browsers are consistent.
I think Chrome has supported a subset of the new header fo= r a while but won=E2=80=99t have full support until Chrome 61 gets out of b= eta.

Is chrome showing a user visible error with t= he old header?

Easiest thing would be to use the n= ew header and deny access to anyone still using IE:)

John B.


<= div>
On Aug 3, 2017, at 12:43 PM, Brian Campb= ell <bca= mpbell@pingidentity.com> wrote:

Really all I know is th= at recent versions of Chrome complain that referrer is an unrecognized Cont= ent-Security-Policy directive, which led me to look up the changes and cont= ent in my original message.=C2=A0

=
On Thu, Aug 3, 2017 at 9:35 AM, John Bradley <v= e7jtb@ve7jtb.com> wrote:
Brian=C2=A0

To answer = my own question to some extent, this page has support status for the browse= rs:
<= br>
It looks like only FireFox supports strict-origin.
=
Most of them support origin.

Some l= ike IE, Opera Mini and older versions of Android (4) don=E2=80=99t support = Referrer-Policy at all.

So I think=C2=A0
Referrer-Policy: origin

Wit= h a note that you still need to use =C2=A0Content-Security-Policy: for IE a= nd Android (4).=C2=A0 There may be some other OEM provided browsers on Andr= oid from Samsung and others that may not have support but they are a small = number in general.

John B.


On Aug 2, 2017, at 6:46 PM= , Brian Campbell <bcampbell@pingidentity.com> wrote:

<= div>
Not s= ure of the status at this point (it is expired) but the draft-ietf-oauth-cl= osing-redirectors WG document in ht= tps://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00= #section-2.3 suggests using the Content Security Policy header to limit= the information sent in the referer something like this:

=C2=A0 Co= ntent-Security-Policy: referrer origin;

Consistent with the latest d= raft of https://w3c.github.io/webappsec-referrer-policy/ and a= ccording to Mozilla (see http= s://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Sec= urity-Policy/referrer) the Content-Security-Policy (CSP) referrer directive is obsolete and =20 deprecated. And it looks like Referrer-Policy should be used instead for that purpose (again see Mozilla: https://deve= loper.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy= ). So the draft-ietf-oauth-closing-redirectors document should probabl= y suggest the Referrer-Policy something more like this:

=C2=A0=C2=A0= Referrer-Policy: strict-origin



CONFIDENTIALITY NOTICE: This email may = contain confidential and privileged material for the sole use of the intend= ed recipient(s). Any review, use, distribution or disclosure by others is s= trictly prohibited.=C2=A0 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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045fe2d458f2330555dc413e-- From nobody Thu Aug 3 09:58:47 2017 Return-Path: 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 B47C012F274 for ; Thu, 3 Aug 2017 09:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 OJjvZJYn2IOS for ; Thu, 3 Aug 2017 09:58:44 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 6AAF9132044 for ; Thu, 3 Aug 2017 09:58:43 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id t128so8680557lff.2 for ; Thu, 03 Aug 2017 09:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jvvvd6YKkX+UuIrQPYkudkFJZQMMaNXhs3OllpitxNg=; b=susAcv7Q/2Hw1VVmWfy2izSrU6/UfpwXvO6SvvW3bzeNWyX0EN/lUsiZ3ap3vgQOw7 Bn4Bm/4skd3f8w10/OrgmwnQmIhpB+0i37c2EUlTuemFN6Un+v1/ZqhrE2et4OWoFwXy Re6lwx1/Jj6VF4p8G3pfcn6ZvCysXYpwj7syWhsKipNm33J8o1LBameW7Yz/QlHQGBOw pNAtZgjBiFTv0XLjuLyr6dui0VuFE/XGHSF2c9B0o2xqGXBI4QoHMAFd1yIV+kLUlfvU x7vZS0jvRORMnFfINRRzLPWfn4suy8NsBPQP2GHmHAkZczh0NCFl/kmsK75v7rBEzZGD Bwyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jvvvd6YKkX+UuIrQPYkudkFJZQMMaNXhs3OllpitxNg=; b=qiE6WuWRdg4pspMflR8d5CUWx/wXRIZjtlLAJ8P7fNpud4YUD8W9VXsGGBuTbz/U5B gKGhxsJGsoGpgwmMReF4DzeOrlaq3bRK1VZ5rNP327Owa62DSYLAp7T9jy7yW3/SiIyO 84nBZShYOGPF8J4LSuiZemDONTd73vILz4e21B5kAVzybbrGJ/KckkIsDvezLKoCOD/s UrGL1V4yaI4y30shcDENVPwGUQh96S+JsCNO3RwCC9Qtt5voTW5tpcM5a33Z3MTaBoR6 UHOr00mFGYDZatQ277uUtonKIrFZr1e7xdgo54TFXcGlzDOdjHbUWHW0iM+1Eqx93eK8 bEsA== X-Gm-Message-State: AIVw110T995KXTeQcc7Yx7dfEDyxYrkDicJS7WGVlA0nq40Bxz1A2gmE TsP5JD1mrpAOMNRsfI9JMg== X-Received: by 10.46.5.136 with SMTP id 130mr866510ljf.86.1501779521550; Thu, 03 Aug 2017 09:58:41 -0700 (PDT) Received: from [192.168.86.103] ([191.115.81.54]) by smtp.gmail.com with ESMTPSA id m12sm6729817lfe.12.2017.08.03.09.58.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 09:58:40 -0700 (PDT) From: John Bradley Message-Id: <066BD9E2-9CD2-4546-96C5-6F49FD9E3F58@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 12:58:38 -0400 In-Reply-To: Cc: oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114a69b2ee177e0555dc4af3" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:58:47 -0000 --001a114a69b2ee177e0555dc4af3 Content-Type: multipart/alternative; boundary="Apple-Mail=_4E479F12-EBBB-44D8-A023-0F11A52A8B2F" --Apple-Mail=_4E479F12-EBBB-44D8-A023-0F11A52A8B2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good, so you could send both to be safe without it breaking. John B. > On Aug 3, 2017, at 12:55 PM, Brian Campbell = wrote: >=20 > No, Chrome only shows the error message deep inside the developer = tools console.=20 >=20 > On Thu, Aug 3, 2017 at 10:51 AM, John Bradley > wrote: > No one ever said that browsers are consistent. >=20 > I think Chrome has supported a subset of the new header for a while = but won=E2=80=99t have full support until Chrome 61 gets out of beta. >=20 > Is chrome showing a user visible error with the old header? >=20 > Easiest thing would be to use the new header and deny access to anyone = still using IE:) >=20 > John B. >=20 >=20 >> On Aug 3, 2017, at 12:43 PM, Brian Campbell = > wrote: >>=20 >> Really all I know is that recent versions of Chrome complain that = referrer is an unrecognized Content-Security-Policy directive, which led = me to look up the changes and content in my original message. =20 >>=20 >> On Thu, Aug 3, 2017 at 9:35 AM, John Bradley > wrote: >> Brian=20 >>=20 >> To answer my own question to some extent, this page has support = status for the browsers: >> http://caniuse.com/#feat=3Dreferrer-policy = >>=20 >> It looks like only FireFox supports strict-origin. >>=20 >> Most of them support origin. >>=20 >> Some like IE, Opera Mini and older versions of Android (4) don=E2=80=99= t support Referrer-Policy at all. >>=20 >> So I think=20 >> Referrer-Policy: origin >>=20 >> With a note that you still need to use Content-Security-Policy: for = IE and Android (4). There may be some other OEM provided browsers on = Android from Samsung and others that may not have support but they are a = small number in general. >>=20 >> John B. >>=20 >>=20 >>> On Aug 2, 2017, at 6:46 PM, Brian Campbell = > wrote: >>>=20 >>> Not sure of the status at this point (it is expired) but the = draft-ietf-oauth-closing-redirectors WG document in = https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#sectio= n-2.3 = suggests using the Content Security Policy header to limit the = information sent in the referer something like this:=20 >>>=20 >>> Content-Security-Policy: referrer origin; >>>=20 >>> Consistent with the latest draft of = https://w3c.github.io/webappsec-referrer-policy/ = and according to = Mozilla (see = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security= -Policy/referrer = ) the Content-Security-Policy (CSP) referrer directive = is obsolete and deprecated. And it looks like Referrer-Policy should be = used instead for that purpose (again see Mozilla: = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy = ). So the draft-ietf-oauth-closing-redirectors document should probably = suggest the Referrer-Policy something more like this: >>>=20 >>> Referrer-Policy: strict-origin=20 >>>=20 >>>=20 >>>=20 >>> 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 = >>=20 >>=20 >>=20 >> 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. >=20 >=20 >=20 > 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. --Apple-Mail=_4E479F12-EBBB-44D8-A023-0F11A52A8B2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good, so you could send both to be safe without it = breaking.

John B.
On = Aug 3, 2017, at 12:55 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

No, Chrome only shows the error message deep inside the = developer tools console.

On Thu, = Aug 3, 2017 at 10:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
No one ever said that browsers = are consistent.

I = think Chrome has supported a subset of the new header for a while but = won=E2=80=99t have full support until Chrome 61 gets out of = beta.

Is = chrome showing a user visible error with the old header?

Easiest thing would be = to use the new header and deny access to anyone still using = IE:)

John = B.


On Aug = 3, 2017, at 12:43 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Really all I know is that recent = versions of Chrome complain that referrer is an unrecognized = Content-Security-Policy directive, which led me to look up the changes = and content in my original message. 

On Thu, = Aug 3, 2017 at 9:35 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Brian 

To answer my own question to some = extent, this page has support status for the browsers:
http://caniuse.com/#feat=3Dreferrer-policy

It looks like only FireFox supports strict-origin.

Most of them support = origin.

Some = like IE, Opera Mini and older versions of Android (4) don=E2=80=99t = support Referrer-Policy at all.

So I think 
Referrer-Policy: = origin

With a = note that you still need to use  Content-Security-Policy: for IE = and Android (4).  There may be some other OEM provided browsers on = Android from Samsung and others that may not have support but they are a = small number in general.

John B.


On Aug 2, 2017, at 6:46 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Not sure of the status at this point (it is expired) but the = draft-ietf-oauth-closing-redirectors WG document in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#section-2.3 suggests using the Content Security = Policy header to limit the information sent in the referer something = like this:

  Content-Security-Policy: = referrer origin;

Consistent with the latest = draft of https://w3c.github.io/webappsec-referrer-policy/ and according to Mozilla (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/referrer) the Content-Security-Policy (CSP) referrer directive is obsolete and =20= deprecated. And it looks like Referrer-Policy should be used instead for that purpose (again see Mozilla: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy). So the draft-ietf-oauth-closing-redirectors document should probably suggest the Referrer-Policy = something more like this:

   = Referrer-Policy: strict-origin



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



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.
= --Apple-Mail=_4E479F12-EBBB-44D8-A023-0F11A52A8B2F-- --001a114a69b2ee177e0555dc4af3 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIHqszh40KLhiIupxBfCADpa9pedY kxw1eGR0hmsrPmfLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwMzE2NTg0MVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQARYJXf0JuT0atHVgyjA54lwi3h4eJIWA7owZWunrR/W0j9 MXdyEk7RNM4qR9Mp3h3j7gMEppt5mek5aMFMgDYjCB/YFfm0+Cel79SniCGW56HARh4WDrof4S+8 M8wqc28uagYM3esWrORo8Hv7uitOXmhD0YZAH8fTnSKJX5bNMVP4qNC+FZnpHgz/zxbl/Kk3eha2 +z2N32nprAr7QLD57X9QE5h3rm8kRH5Kfd1pGPVYZ2ayo7JLu1sLWbU2ARR2lJLIUNEiXZsa5TSr fXkMqfBSrZeyQ6TcCSzdze94IZD5vPHO57iygHoTpyAQ/yN4jVWnh41KqLAnDohJYPuf --001a114a69b2ee177e0555dc4af3-- From nobody Fri Aug 4 06:36:19 2017 Return-Path: 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 C2DBB131FED for ; Fri, 4 Aug 2017 06:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 vMLEJuT6Xiph for ; Fri, 4 Aug 2017 06:36:13 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 7EABC131EB9 for ; Fri, 4 Aug 2017 06:36:12 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9FF4A780371; Fri, 4 Aug 2017 15:36:09 +0200 (CEST) To: Phil Hunt Cc: oauth@ietf.org References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> <43fcb3b7-f0ea-47f3-b0f4-9d0f33df7d7f@free.fr> <73394F38-606B-45EC-8F6B-5050BE59CD46@oracle.com> From: Denis Message-ID: Date: Fri, 4 Aug 2017 15:36:10 +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: <73394F38-606B-45EC-8F6B-5050BE59CD46@oracle.com> Content-Type: multipart/alternative; boundary="------------C7B067C8E125ACA7AC4E65DB" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 13:36:18 -0000 This is a multi-part message in MIME format. --------------C7B067C8E125ACA7AC4E65DB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Phil, My comments are in-line too. > inline... > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Aug 1, 2017, at 12:56 PM, Denis > > wrote: >> >> Phil, >> >> Originally, with OAuth the AS and the RS were co-located. Many >> additional RFCs made extensions and this assumption is no more valid. >> >> draft-ietf-oauth-token-exchange-09 is now opening a pandora box where >> an even more complex situation is envisaged (without explicitly >> stating it) >> there would be one client, one RS and several AS/STS with >> relationships between AS/STS from different domains (don't ask me >> what a domain >> might mean in this context). > > I don’t think that is true. It allows a resource server to act on > behalf of the user further on down the line. The user context is > already well known. The draft is saying on page 4: 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. This means that a token received from one AS/STS will be sent to another AS/STS in order to get a new access token from the second AS/STS. This means several AS/STS with relationships between AS/STS from different "domains" as I wrote. > > As always, it can be mis-used. Maybe there is an argument for more > guidance? >> >> See my other post about privacy in the case where a single AS/STS is >> involved in a transaction. It is under the following topic : >> How could an IdP create an id token for one audience RP without >> knowing for which RP ? >> The topic was raised at the last OAuth Workshop in Zürich by a >> student from ETH Zürich. > > In OIDC, the audience is *always* the client. If you are grabbing an > ID Token to then relay it to another RP, then you are into a > dual-audience thing which is doable but falls outside the > specifications AFAIK. The complex case you are mentioning is fairly different from the basic case I am considering. In the basic case, there is one client, one RP and one AS/STS. This is the case I am considering and for which I believe we need a solution. Up to now, when using JWTs, if a JWT is targeted, it allows the AS/STS to act as Big Brother and there is no other alternative. It is a "*Big Brother by design*" solution instead of a "*Privacy by Design*" solution. > I have seen a lot of bad patterns where mobile clients are getting ID > Tokens and simply passing them on to a resource server. > The resource server cannot validate the audience leading to all sorts > of problem. A better method is the AppAuth pattern. >> >> In OAuth there is currently no RFC which provides a response to that >> question. A specification based on OAuth, OpenID Connect, >> is using the concept of an IdP (Identity Provider). Currently, since >> there is no standardized way to address this concern, any IdP will be >> able >> to act as Big Brother: it will know where the access tokens will be >> used. So tracking the activities of the clients will be straightforward. > > So the way forward might be to put forward an individual draft and see > if anyone in the WG wants to work on it in a future charter? Before writing an individual draft, there needs to be a general agreement within the WG to consider such a work item as valuable. > >> Addressing the same question when multiple AS/STS would be involved >> should only be discussed, once we a solution is defined >> in the case where a single AS/STS is involved. Before doing this, we >> would need to define an architecture. >> >> 10 years ago, the IETF was only dealing with security considerations. >> Nowadays, it also has to deal with privacy considerations. > > This seems like an argument for new work. Indeed. Denis >> >> Denis >> >>> Denis, >>> >>> Why is privacy a concern? OAuth is designed to have the >>> Authorization Server be the issuer of tokens for a specific set of >>> resource servers. The AS represents users on the Resource server. >>> It does not represent users of the client - though they are often >>> the same physical person, they are often different authenticated >>> subjects. >>> >>> Of course, there are profiles of OAuth which change this >>> relationship, but the foundational assumption in RFC6749 is the AS >>> is usually associated with the RS. >>> >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect & Standards >>> @independentid >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>>> On Aug 1, 2017, at 3:53 AM, Denis >>> > 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 >>>>> inhttps://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) >>>>> 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 (RFC7523 >>>>> &7522 >>>>> ) >>>>> 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 knowsome 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>>>> >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 ofsection 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>>>>> >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: >>>>>> >>>>>> 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>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 >>>>>>> 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./ >>>>>> >>>>>> >>>>>> >>>>>> /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 >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> > --------------C7B067C8E125ACA7AC4E65DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Phil,

My comments are in-line too.

inline...
Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
phil.hunt@oracle.com

On Aug 1, 2017, at 12:56 PM, Denis <denis.ietf@free.fr> wrote:

Phil,

Originally, with OAuth the AS and the RS were co-located. Many additional RFCs made extensions and this assumption is no more valid.

draft-ietf-oauth-token-exchange-09 is now opening a pandora box where an even more complex situation is envisaged (without explicitly stating it)
there would be one client, one RS and several AS/STS with relationships between AS/STS from different domains (don't ask me what a domain
might mean in this context).

I don’t think that is true. It allows a resource server to act on behalf of the user further on down the line.  The user context is already well known.

The draft is saying on page 4:

   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. 

This means that a token received from one AS/STS will be sent to another AS/STS in order to get a new access token from the second AS/STS.
This means several AS/STS with relationships between AS/STS from different "domains" as I wrote.


As always, it can be mis-used.  Maybe there is an argument for more guidance?

See my other post about privacy in the case where a single AS/STS is involved in a transaction. It is under the following topic :
How could an IdP create an id token for one audience RP without knowing for which RP ?
The topic was raised at the last OAuth Workshop in Zürich by a student from ETH Zürich.

In OIDC, the audience is *always* the client.  If you are grabbing an ID Token to then relay it to another RP, then you are into a dual-audience thing which is doable but falls outside the specifications AFAIK.

The complex case you are mentioning is fairly different from the basic case I am considering. In the basic case, there is one client, one RP and one AS/STS.
This is the case I am considering and for which I believe we need a solution. Up to now, when using JWTs, if a JWT is targeted, it allows the  AS/STS
to act as Big Brother and there is no other alternative. It is a "Big Brother by design" solution instead of a "Privacy by Design" solution.
I have seen a lot of bad patterns where mobile clients are getting ID Tokens and simply passing them on to a resource server. 
The resource server cannot validate the audience leading to all sorts of problem. A better method is the AppAuth pattern.

In OAuth there is currently no RFC which provides a response to that question. A specification based on OAuth, OpenID Connect,
is using the concept of an IdP (Identity Provider). Currently, since there is no standardized way to address this concern, any IdP will be able
to act as Big  Brother: it will know where the access tokens will be used. So tracking the activities of the clients will be straightforward.

So the way forward might be to put forward an individual draft and see if anyone in the WG wants to work on it in a future charter?

Before writing an individual draft, there needs to be a general agreement within the WG to consider such a work item as valuable.


Addressing the same question when multiple AS/STS would be involved should only be discussed, once we a solution is defined
in the case where a single AS/STS is involved. Before doing this, we would need to define an architecture.

10 years ago, the IETF was only dealing with security considerations. Nowadays, it also has to deal with privacy considerations.

This seems like an argument for new work.

Indeed.

Denis



Denis

Denis,

Why is privacy a concern? OAuth is designed to have the Authorization Server be the issuer of tokens for a specific set of resource servers.  The AS represents users on the Resource server.  It does not represent users of the client - though they are often the same physical person, they are often different authenticated subjects.  

Of course, there are profiles of OAuth which change this relationship, but the foundational assumption in RFC6749 is the AS is usually associated with the RS.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
phil.hunt@oracle.com

On Aug 1, 2017, at 3:53 AM, Denis <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 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) 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 introspection endpoint (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 & 7522) 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> 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) 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> 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> 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
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.



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
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--------------C7B067C8E125ACA7AC4E65DB-- From nobody Fri Aug 4 06:50:01 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06356131CDF; Fri, 4 Aug 2017 06:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-oauth-native-apps@ietf.org, oauth-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, Hannes Tschofenig , Hannes.Tschofenig@gmx.net, oauth@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150185460002.18606.10680937350719175334.idtracker@ietfa.amsl.com> Date: Fri, 04 Aug 2017 06:50:00 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'OAuth 2.0 for Native Apps' to Best Current Practice (draft-ietf-oauth-native-apps-12.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 13:50:00 -0000 The IESG has approved the following document: - 'OAuth 2.0 for Native Apps' (draft-ietf-oauth-native-apps-12.txt) as Best Current Practice This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ Technical Summary OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice. Working Group Summary The OAuth 2.0 authorization framework, documents two approaches for native apps to interact with the authorization endpoint: via an embedded user-agent, or an external user-agent. This document recommends external user-agents like in-app browser tabs as the only secure and usable choice for OAuth. There is solid working group consensus to publish this document. Document Quality Implementations are included in the shepherd report. Personnel Hannes Tschofenig is the document shepherd and the responsible area director is Kathleen Moriarty. From nobody Fri Aug 4 11:13:42 2017 Return-Path: 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 D5FED13202E for ; Fri, 4 Aug 2017 11:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 ySjHTBje186j for ; Fri, 4 Aug 2017 11:13:37 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 88A5313211B for ; Fri, 4 Aug 2017 11:13:37 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id v77so10849785pgb.3 for ; Fri, 04 Aug 2017 11:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ti3w7R2yQz3yGSgTnXTRR39VLzmsKMk1YZWWKDh6fCo=; b=hL1ZEjS5j3XBCHNrEq3+K0jHbc8+6qFb9c43wKcH3UNmrxYwrwiaKlXBFiBKmNIFnS iaF4SKlsN/VTka9H3MQo54iYW02srnOHv89a28e2zyHezSuz2ZTrOq5APkQarMr1oN45 mkuM2wsXWx36otNmpZGXqdKn5eORZRq5Jv9MM= 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=ti3w7R2yQz3yGSgTnXTRR39VLzmsKMk1YZWWKDh6fCo=; b=eus/wIsHsb7PDc0bw9+uZXf8FSROW3jSgh0pQvYCYAD2eHxion3x8qpbiPT+2MGuV8 hwdXF1fw3X928+PHDJgQZ+/y86Peq8teFV6EgryKfr3UTsq+Cd5vi9GGGIoD/3AwmK5l dcIxQkIJBas2duHVEwZaCJo7MBWJj2U1ZDTGh4O5WAhOh6iNL0wHweMXxTQwk2Ee+PiZ VOifEa2J4+dN4kozBhN6PyGvBCuhBBg5dH9Nx3w2ihkWv4Fxk5p7D1wbopb5rEouBNVY yH4+zrEh8fhZtoZxzzENlKDGE021Bo6/6NNUlXJEyd4IF0kanciXQ8wkQZAXggNONPKj LHag== X-Gm-Message-State: AIVw113QACk0uycbI2T7cd/URgn9J4qjqgyLFtn2P38WOrTbNkBQp3LX G+Kgju9V7TrDC6Ll4LsSqF7qc5gtdz3jhKyyhw5rkg7mGzTgdWaUMqSy4EM9UtZp409z/CJ1Nd6 xtKOn X-Received: by 10.99.117.68 with SMTP id f4mr3209096pgn.56.1501870416942; Fri, 04 Aug 2017 11:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Fri, 4 Aug 2017 11:13:06 -0700 (PDT) In-Reply-To: References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> From: Brian Campbell Date: Fri, 4 Aug 2017 12:13:06 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="f403045cdcc4b379520555f1746f" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 18:13:41 -0000 --f403045cdcc4b379520555f1746f Content-Type: text/plain; charset="UTF-8" Just wanted to note that, in an off-list exchange, John has pushed back on the idea to potentially drop mention of using x5c. On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell wrote: > Thanks for the review, Vladimir. > > The text about which you have questions was written by Torsten (credit or > blame where it's due!) but I believe he's out of the office for a bit so > I'll try and answer. > > Your 1st question: > I've had the same thought regarding the public key method and using the > JWK x5c parameter. A JWK already has the public key, which is sufficient > for comparison in the public key method. So x5c is just superfluous here. I > believe that's a change that the next revision should have and will look to > make it unless someone wants to make a strong case for needing x5c. > > Your 2nd question: > I also found the sentence, "When used in conjunction with a trusted X.509 > certificate source, it also allows the client to rotate its X.509 > certificates without the need to change its respective authentication data > at the authorization server." somewhat difficult to understand when I first > read it. The intended meaning relies on content earlier in the same > paragraph that says, "As pre-requisite, the client registers a X.509 > certificate or *a trusted source for its X.509 certificates (jwks uri as > defined in [RFC7591])* with the authorization server." Basically what > it's trying to say is that when a client is registered or configured with a > jwks_uri, then client key rotation can be done without needing to > explicitly update the client config/registration with the AS. Does that > explain it? I believe the text could be more straightforward and will > endeavor to make it more clear in the next draft update. > > > > > > > > > > On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > >> Thanks everyone for the update! Having a clear distinction between the >> PKIX vs public key bound methods will help interop, implementers' job, and >> it also appears good for security. >> >> Questions: >> >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >> 03#section-2.3 >> >> where the X.509 certificates are represented using the "x5c" parameter from [RFC7517 ] >> >> For the public key method, is it really necessary for the client to >> include its certificate in the JWK x5c parameter? This will make >> implementation harder for developers, and I'm not sure it adds anything in >> terms of security. Registering the public key parameters seems sufficient >> to me. >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >> 03#section-2.1 >> >> When used in conjunction with a trusted X.509 certificate source, it also allows the client to rotate its X.509 certificates without the need to change its respective authentication data at the authorization server. >> >> I don't understand this - "in conjunction with a trusted X.509 >> certificate source" >> >> >> Thanks, >> >> Vladimir >> >> On 28/07/17 21:33, Brian Campbell wrote: >> >> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with >> the changes listed below based on comments and dissuasion in Prague. >> >> draft-ietf-oauth-mtls-03 >> >> >> o Introduced metadata and client registration parameter to publish >> and request support for mutual TLS sender constrained access >> tokens >> o Added description of two methods of binding the cert and client, >> PKI and Public Key. >> o Indicated that the "tls_client_auth" authentication method is for >> the PKI method and introduced "pub_key_tls_client_auth" for the >> Public Key method >> o Added implementation considerations, mainly regarding TLS stack >> configuration and trust chain validation, as well as how to to do >> binding of access tokens to a TLS client certificate for public >> clients, and considerations around certificate bound access tokens >> o Added new section to security considerations on cert spoofing >> o Add text suggesting that a new cnf member be defined in the >> future, if hash function(s) other than SHA-256 need to be used for >> certificate thumbprints >> >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Fri, Jul 28, 2017 at 12:25 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the IETF. >> >> Title : Mutual TLS Profile for OAuth 2.0 >> Authors : Brian Campbell >> John Bradley >> Nat Sakimura >> Torsten Lodderstedt >> Filename : draft-ietf-oauth-mtls-03.txt >> Pages : 17 >> Date : 2017-07-28 >> >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for OAuth >> client authentication to the token endpoint as well as for >> certificate bound sender constrained access tokens. >> >> >> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >> >> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 >> >> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://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.* --f403045cdcc4b379520555f1746f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just wanted to note that, in an off-list exchange, John ha= s pushed back on the idea to potentially drop mention of using x5c.

On Wed, Aug 2,= 2017 at 9:29 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:
<= div>
Thanks for the review, Vladimir.
=C2=A0
The text abou= t which you have questions was written by Torsten (credit or blame where it= 's due!) but I believe he's out of the office for a bit so I'll= try and answer.

Your 1st question:
I've ha= d the same thought regarding the public key method and using the JWK x5c pa= rameter. A JWK already has the public key, which is sufficient for comparis= on in the public key method. So x5c is just superfluous here. I believe tha= t's a change that the next revision should have and will look to make i= t unless someone wants to make a strong case for needing x5c.

Your = 2nd question:
I also found the sentence, "When used in conjunction = with a trusted X.509 certificate source, it also allows the client to rotat= e its X.509 certificates without the need to change its respective authenti= cation data at the authorization server." somewhat difficult to unders= tand when I first read it. The intended meaning relies on content earlier i= n the same paragraph that says, "As pre-requisite, the client register= s a X.509 certificate or a trusted source for its X.509 certificates (jw= ks uri as defined in [RFC7591]) with the authorization server."=C2= =A0 Basically what it's trying to say is that when a client is register= ed or configured with a jwks_uri, then client key rotation can be done with= out needing to explicitly update the client config/registration with the AS= . Does that explain it? I believe the text could be more straightforward an= d will endeavor to make it more clear in the next draft update.


=C2=A0





On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <v= ladimir@connect2id.com> wrote:
=20 =20 =20

Thanks everyone for the update! Having a clear distinction between the PKIX vs public key bound methods will help interop, implementers' job, and it also appears good for security.

Questions:

https://datatracker.ietf.org/doc= /html/draft-ietf-oauth-mtls-03#section-2.3

=
where the X.509 certificates are represented using the "x5c" para=
meter from [RFC7517]

For the public key method, is it really necessary for the client to include its certificate in the JWK x5c parameter? This will make implementation harder for developers, and I'm not sure it adds anything in terms of security. Registering the public key parameters seems sufficient to me.


https://datatracker.ietf.org/doc= /html/draft-ietf-oauth-mtls-03#section-2.1

=
When used in conjunction with a trusted X.509 certificate source, it also a=
llows the client to rotate its X.509 certificates without the need to chang=
e its respective authentication data at the authorization server.
I don't understand this - "in conjunction with a trusted X.5= 09 certificate source"


Thanks,

Vladimir

On 28/07/17 21:33, Brian Campbell wrote:
A new draft of "Mutual TLS Profile for OAuth 2.0"=
; has been published with
the changes listed below based on comments and dissuasion in Prague.

   draft-ietf-oauth-mtls-03
<https://datatracker.ietf.org/doc/html/dr=
aft-ietf-oauth-mtls-03>


   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method =
is for
      the PKI method and introduced "pub_key_tls_client_auth" for=
 the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints



---------- Forwarded message ----------
From: <in=
ternet-drafts@ietf.org>
Date: Fri, Jul 28, 2017 at 12:25 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
To: i-d-anno=
unce@ietf.org
Cc: oauth@ietf.org<=
/a>



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : Mutual TLS Profile for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-03.txt
        Pages           : 17
        Date            : 2017-07-28

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for OAuth
   client authentication to the token endpoint as well as for
   certificate bound sender constrained access tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-03
https://datatracker.ietf.org/doc/html/draft-ietf-oa=
uth-mtls-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-=
mtls-03


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ft=
p.ietf.org/internet-drafts/

_______________________________________________
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




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045cdcc4b379520555f1746f-- From nobody Fri Aug 4 12:18:10 2017 Return-Path: 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 BC0CB132012 for ; Fri, 4 Aug 2017 12:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 AIsAfgq2nCRg for ; Fri, 4 Aug 2017 12:18:07 -0700 (PDT) Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (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 5B44A131FFA for ; Fri, 4 Aug 2017 12:18:07 -0700 (PDT) Received: from [192.168.0.101] ([78.130.190.73]) by :SMTPAUTH: with SMTP id di6Idb2Y2PMtZdi6JdStmj; Fri, 04 Aug 2017 12:17:35 -0700 To: Brian Campbell Cc: oauth References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> Date: Fri, 4 Aug 2017 22:17:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060608040006060505070809" X-CMAE-Envelope: MS4wfDlyAD+BscWT4XIhnEjj/4AGCjWGrDqGoyMiFZOefa0L84iFtWZSyycK5tkIteqQ8hj28n9CxA4H39KTQAL4SGvurFUtRmkkYCN6dXkJahjCajcfIDtw YUzCgnoKVLIQPaSsei3wGjmtI5OBiD9zZ5fuMPDCxGWbZ4WyR8j+9o02omom7Ung4F/7XWl3em6p41/I2/e3BLLyMExJj6D1TRE= Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 19:18:10 -0000 This is a cryptographically signed message in MIME format. --------------ms060608040006060505070809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US What are the potential uses of the x5c parameter? Vladimir On 04/08/17 21:13, Brian Campbell wrote: > Just wanted to note that, in an off-list exchange, John has pushed back= on > the idea to potentially drop mention of using x5c. > > On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell > wrote: > >> Thanks for the review, Vladimir. >> >> The text about which you have questions was written by Torsten (credit= or >> blame where it's due!) but I believe he's out of the office for a bit = so >> I'll try and answer. >> >> Your 1st question: >> I've had the same thought regarding the public key method and using th= e >> JWK x5c parameter. A JWK already has the public key, which is sufficie= nt >> for comparison in the public key method. So x5c is just superfluous he= re. I >> believe that's a change that the next revision should have and will lo= ok to >> make it unless someone wants to make a strong case for needing x5c. >> >> Your 2nd question: >> I also found the sentence, "When used in conjunction with a trusted X.= 509 >> certificate source, it also allows the client to rotate its X.509 >> certificates without the need to change its respective authentication = data >> at the authorization server." somewhat difficult to understand when I = first >> read it. The intended meaning relies on content earlier in the same >> paragraph that says, "As pre-requisite, the client registers a X.509 >> certificate or *a trusted source for its X.509 certificates (jwks uri = as >> defined in [RFC7591])* with the authorization server." Basically what= >> it's trying to say is that when a client is registered or configured w= ith a >> jwks_uri, then client key rotation can be done without needing to >> explicitly update the client config/registration with the AS. Does tha= t >> explain it? I believe the text could be more straightforward and will >> endeavor to make it more clear in the next draft update. >> >> >> >> >> >> >> >> >> >> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov < >> vladimir@connect2id.com> wrote: >> >>> Thanks everyone for the update! Having a clear distinction between th= e >>> PKIX vs public key bound methods will help interop, implementers' job= , and >>> it also appears good for security. >>> >>> Questions: >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >>> 03#section-2.3 >>> >>> where the X.509 certificates are represented using the "x5c" paramete= r from [RFC7517 ] >>> >>> For the public key method, is it really necessary for the client to >>> include its certificate in the JWK x5c parameter? This will make >>> implementation harder for developers, and I'm not sure it adds anythi= ng in >>> terms of security. Registering the public key parameters seems suffic= ient >>> to me. >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >>> 03#section-2.1 >>> >>> When used in conjunction with a trusted X.509 certificate source, it = also allows the client to rotate its X.509 certificates without the need = to change its respective authentication data at the authorization server.= >>> >>> I don't understand this - "in conjunction with a trusted X.509 >>> certificate source" >>> >>> >>> Thanks, >>> >>> Vladimir >>> >>> On 28/07/17 21:33, Brian Campbell wrote: >>> >>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published = with >>> the changes listed below based on comments and dissuasion in Prague. >>> >>> draft-ietf-oauth-mtls-03 >>> >>> >>> o Introduced metadata and client registration parameter to publis= h >>> and request support for mutual TLS sender constrained access >>> tokens >>> o Added description of two methods of binding the cert and client= , >>> PKI and Public Key. >>> o Indicated that the "tls_client_auth" authentication method is f= or >>> the PKI method and introduced "pub_key_tls_client_auth" for the= >>> Public Key method >>> o Added implementation considerations, mainly regarding TLS stack= >>> configuration and trust chain validation, as well as how to to = do >>> binding of access tokens to a TLS client certificate for public= >>> clients, and considerations around certificate bound access tok= ens >>> o Added new section to security considerations on cert spoofing >>> o Add text suggesting that a new cnf member be defined in the >>> future, if hash function(s) other than SHA-256 need to be used = for >>> certificate thumbprints >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Fri, Jul 28, 2017 at 12:25 PM >>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >>> To: i-d-announce@ietf.org >>> Cc: oauth@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol WG of the= IETF. >>> >>> Title : Mutual TLS Profile for OAuth 2.0 >>> Authors : Brian Campbell >>> John Bradley >>> Nat Sakimura >>> Torsten Lodderstedt >>> Filename : draft-ietf-oauth-mtls-03.txt >>> Pages : 17 >>> Date : 2017-07-28 >>> >>> Abstract: >>> This document describes Transport Layer Security (TLS) mutual >>> authentication using X.509 certificates as a mechanism for OAuth >>> client authentication to the token endpoint as well as for >>> certificate bound sender constrained access tokens. >>> >>> >>> The IETF datatracker status page for this draft is:https://datatracke= r.ietf.org/doc/draft-ietf-oauth-mtls/ >>> >>> There are also htmlized versions available at:https://tools.ietf.org/= html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-= ietf-oauth-mtls-03 >>> >>> A diff from the previous version is available at:https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf= =2Eorg/internet-drafts/ >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo= /oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> --------------ms060608040006060505070809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MDQxOTE3MzRaMC8GCSqGSIb3DQEJBDEiBCCtKramLlBSO4WNifBxU14kC2G/NLN+ jQk+mFVSIaMk+zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQB0IDjgjyoi WJXqMbDSJDrO2HPbgOKq74NUT/yihk/zJOo96ZrclrKxwi4PR45fLEcOaoLtQFQaxbxWaSip +85vnKU9c1r5k4xeMq6fVVh0OmTSWBdkCpM2YxoPya1khvxT5L/p/ENwIp40NLS9uSDyyaF+ cdocUQUyBlLznczS8HK2/OmMv0QjiTjnFlrNxfGPIlSD4dKu0xBGx0sESRSqwVuJySS+SzlV OOMsH9gsp8m4l7LjET6s8ea3d/lY9PrHLitUFA5JKZUUsa4VQQqdMPOcFtdQKKccxnnbn9ec PWYAKl6ZF2CFWvJNkp1qDi4H4ouNWUySHWZ3uH8C/CFfAAAAAAAA --------------ms060608040006060505070809-- From nobody Fri Aug 4 12:32:58 2017 Return-Path: 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 F2166131FFA for ; Fri, 4 Aug 2017 12:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 ku6C0gKGTB4D for ; Fri, 4 Aug 2017 12:32:53 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 6A442131EB1 for ; Fri, 4 Aug 2017 12:32:53 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id u5so11555730pgn.0 for ; Fri, 04 Aug 2017 12:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EtRL81mNY77KwAwK4Y5iFsyDaZHIOtw+9nb+CcMKFYI=; b=PNUgqd00aZsLWDAjPqEKSmcjM+TiscRrXKdZBWPcCGowlxy1rIIkyrMTe38gKyDof6 qR0OKK5LqcXvgpRiIhVD2UJjsh8Io6ERoLkir8VdPUPptwExpofdnyO9whCit+XaV8RG QGhmjvCNn3jXzA15lz5mraQRJS2R/vC9h9MpQ= 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=EtRL81mNY77KwAwK4Y5iFsyDaZHIOtw+9nb+CcMKFYI=; b=HBjIY1haWaSOms9KoXZaDbklqnNethtGYpTuLtQaolbZWQCgdW8fa7BKLWZhzT5eQe UxeYwPMB7faU7JdUtuUeHNOQhnC3FShZaY6vh9QHULOQlzO667jv+Fqex+2Ed6lcs5WW aHqlAiyzcK++vhRA++EShabo1lIQX3ecPu0axnNkeEZn4bJhudu8lSzH5stoinYt1q5z JmPlUyv572mBZE0BbfptWGHDAL0+I4PjMNmEdOKKWAliHHf/BVEmFNRKArwXd7OzvDbO nsjphkUSM96QWDRuF+12j5biDACHRq7juBpBdAqfvaHTCzQWhrzBSRlNpfRY3tSrQo0E /g+Q== X-Gm-Message-State: AIVw111IhopQu9eL5FAGjcVj2pLh816UrIVo+A6jgDZMMuH9bYpo7DY2 Ui+eJqlyAAC22QdkJqxR0hMFG+iKlLDYKWSNP0Cde1Eby4Dfa5YPQZLEVIlP0IF9zsgDu7p2D8e VdDoQzig= X-Received: by 10.84.210.203 with SMTP id a69mr4013164pli.395.1501875172919; Fri, 04 Aug 2017 12:32:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Fri, 4 Aug 2017 12:32:22 -0700 (PDT) In-Reply-To: <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> From: Brian Campbell Date: Fri, 4 Aug 2017 13:32:22 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c09614c2de59c0555f29091" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 19:32:57 -0000 --94eb2c09614c2de59c0555f29091 Content-Type: text/plain; charset="UTF-8" His argument (best I can articulate anyway) is that there may be difficulties or gotchas in some cases in doing a comparison of the public key from the client cert to the public key from a JWK. Where the comparison or the client cert directly to the cert from x5c in a JWK would be more straightforward and/or less error prone. I don't necessarily agree but wanted to bring the discussion back to the list. On Fri, Aug 4, 2017 at 1:17 PM, Vladimir Dzhuvinov wrote: > What are the potential uses of the x5c parameter? > > Vladimir > > > On 04/08/17 21:13, Brian Campbell wrote: > > Just wanted to note that, in an off-list exchange, John has pushed back > on > > the idea to potentially drop mention of using x5c. > > > > On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell < > bcampbell@pingidentity.com> > > wrote: > > > >> Thanks for the review, Vladimir. > >> > >> The text about which you have questions was written by Torsten (credit > or > >> blame where it's due!) but I believe he's out of the office for a bit so > >> I'll try and answer. > >> > >> Your 1st question: > >> I've had the same thought regarding the public key method and using the > >> JWK x5c parameter. A JWK already has the public key, which is sufficient > >> for comparison in the public key method. So x5c is just superfluous > here. I > >> believe that's a change that the next revision should have and will > look to > >> make it unless someone wants to make a strong case for needing x5c. > >> > >> Your 2nd question: > >> I also found the sentence, "When used in conjunction with a trusted > X.509 > >> certificate source, it also allows the client to rotate its X.509 > >> certificates without the need to change its respective authentication > data > >> at the authorization server." somewhat difficult to understand when I > first > >> read it. The intended meaning relies on content earlier in the same > >> paragraph that says, "As pre-requisite, the client registers a X.509 > >> certificate or *a trusted source for its X.509 certificates (jwks uri as > >> defined in [RFC7591])* with the authorization server." Basically what > >> it's trying to say is that when a client is registered or configured > with a > >> jwks_uri, then client key rotation can be done without needing to > >> explicitly update the client config/registration with the AS. Does that > >> explain it? I believe the text could be more straightforward and will > >> endeavor to make it more clear in the next draft update. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov < > >> vladimir@connect2id.com> wrote: > >> > >>> Thanks everyone for the update! Having a clear distinction between the > >>> PKIX vs public key bound methods will help interop, implementers' job, > and > >>> it also appears good for security. > >>> > >>> Questions: > >>> > >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- > >>> 03#section-2.3 > >>> > >>> where the X.509 certificates are represented using the "x5c" parameter > from [RFC7517 ] > >>> > >>> For the public key method, is it really necessary for the client to > >>> include its certificate in the JWK x5c parameter? This will make > >>> implementation harder for developers, and I'm not sure it adds > anything in > >>> terms of security. Registering the public key parameters seems > sufficient > >>> to me. > >>> > >>> > >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- > >>> 03#section-2.1 > >>> > >>> When used in conjunction with a trusted X.509 certificate source, it > also allows the client to rotate its X.509 certificates without the need to > change its respective authentication data at the authorization server. > >>> > >>> I don't understand this - "in conjunction with a trusted X.509 > >>> certificate source" > >>> > >>> > >>> Thanks, > >>> > >>> Vladimir > >>> > >>> On 28/07/17 21:33, Brian Campbell wrote: > >>> > >>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published > with > >>> the changes listed below based on comments and dissuasion in Prague. > >>> > >>> draft-ietf-oauth-mtls-03 html/draft-ietf-oauth-mtls-03> doc/html/draft-ietf-oauth-mtls-03> > >>> > >>> > >>> o Introduced metadata and client registration parameter to publish > >>> and request support for mutual TLS sender constrained access > >>> tokens > >>> o Added description of two methods of binding the cert and client, > >>> PKI and Public Key. > >>> o Indicated that the "tls_client_auth" authentication method is for > >>> the PKI method and introduced "pub_key_tls_client_auth" for the > >>> Public Key method > >>> o Added implementation considerations, mainly regarding TLS stack > >>> configuration and trust chain validation, as well as how to to do > >>> binding of access tokens to a TLS client certificate for public > >>> clients, and considerations around certificate bound access > tokens > >>> o Added new section to security considerations on cert spoofing > >>> o Add text suggesting that a new cnf member be defined in the > >>> future, if hash function(s) other than SHA-256 need to be used > for > >>> certificate thumbprints > >>> > >>> > >>> > >>> ---------- Forwarded message ---------- > >>> From: > >>> Date: Fri, Jul 28, 2017 at 12:25 PM > >>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt > >>> To: i-d-announce@ietf.org > >>> Cc: oauth@ietf.org > >>> > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> This draft is a work item of the Web Authorization Protocol WG of the > IETF. > >>> > >>> Title : Mutual TLS Profile for OAuth 2.0 > >>> Authors : Brian Campbell > >>> John Bradley > >>> Nat Sakimura > >>> Torsten Lodderstedt > >>> Filename : draft-ietf-oauth-mtls-03.txt > >>> Pages : 17 > >>> Date : 2017-07-28 > >>> > >>> Abstract: > >>> This document describes Transport Layer Security (TLS) mutual > >>> authentication using X.509 certificates as a mechanism for OAuth > >>> client authentication to the token endpoint as well as for > >>> certificate bound sender constrained access tokens. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > >>> > >>> There are also htmlized versions available at:https://tools.ietf.org/ > html/draft-ietf-oauth-mtls-03https://datatracker.ietf. > org/doc/html/draft-ietf-oauth-mtls-03 > >>> > >>> A diff from the previous version is available at:https://www.ietf.org/ > rfcdiff?url2=draft-ietf-oauth-mtls-03 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > submission > >>> until the htmlized version and diff are available at tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> OAuth mailing listOAuth@ietf.orghttps://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.* --94eb2c09614c2de59c0555f29091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
His argument (best I can articulate anyway) is that there = may be difficulties or gotchas in some cases in doing a comparison of the p= ublic key from the client cert to the public key from a JWK. Where the comp= arison or the client cert directly to the cert from x5c in a JWK would be m= ore straightforward and/or less error prone. I don't necessarily agree = but wanted to bring the discussion back to the list.=C2=A0

On Fri, Aug 4, 2017 at = 1:17 PM, Vladimir Dzhuvinov <vladimir@connect2id.com> = wrote:
What are the potential uses of the= x5c parameter?

Vladimir


On 04/08/17 21:13, Brian Campbell wrote:
> Just wanted to note that, in an off-list exchange, John has pushed bac= k on
> the idea to potentially drop mention of using x5c.
>
> On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
>> Thanks for the review, Vladimir.
>>
>> The text about which you have questions was written by Torsten (cr= edit or
>> blame where it's due!) but I believe he's out of the offic= e for a bit so
>> I'll try and answer.
>>
>> Your 1st question:
>> I've had the same thought regarding the public key method and = using the
>> JWK x5c parameter. A JWK already has the public key, which is suff= icient
>> for comparison in the public key method. So x5c is just superfluou= s here. I
>> believe that's a change that the next revision should have and= will look to
>> make it unless someone wants to make a strong case for needing x5c= .
>>
>> Your 2nd question:
>> I also found the sentence, "When used in conjunction with a t= rusted X.509
>> certificate source, it also allows the client to rotate its X.509<= br> >> certificates without the need to change its respective authenticat= ion data
>> at the authorization server." somewhat difficult to understan= d when I first
>> read it. The intended meaning relies on content earlier in the sam= e
>> paragraph that says, "As pre-requisite, the client registers = a X.509
>> certificate or *a trusted source for its X.509 certificates= (jwks uri as
>> defined in [RFC7591])* with the authorization server."=C2=A0 = Basically what
>> it's trying to say is that when a client is r= egistered or configured with a
>> jwks_uri, then client key rotation can be done without needing to<= br> >> explicitly update the client config/registration with the AS. Does= that
>> explain it? I believe the text could be more straightforward and w= ill
>> endeavor to make it more clear in the next draft update.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <
>> vladimir@connect2id.com= > wrote:
>>
>>> Thanks everyone for the update! Having a clear distinction bet= ween the
>>> PKIX vs public key bound methods will help interop, implemente= rs' job, and
>>> it also appears good for security.
>>>
>>> Questions:
>>>
>>> https://datatracker.ietf.or= g/doc/html/draft-ietf-oauth-mtls-
>>> 03#section-2.3
>>>
>>> where the X.509 certificates are represented using the = "x5c" parameter from [RFC7517 <https://dat= atracker.ietf.org/doc/html/rfc7517>]
>>>
>>> For the public key method, is it really necessary for the clie= nt to
>>> include its certificate in the JWK x5c parameter? This will ma= ke
>>> implementation harder for developers, and I'm not sure it = adds anything in
>>> terms of security. Registering the public key parameters seems= sufficient
>>> to me.
>>>
>>>
>>> https://datatracker.ietf.or= g/doc/html/draft-ietf-oauth-mtls-
>>> 03#section-2.1
>>>
>>> When used in conjunction with a trusted X.509 certificate sour= ce, it also allows the client to rotate its X.509 certificates without the = need to change its respective authentication data at the authorization serv= er.
>>>
>>> I don't understand this - "in conjunction with a trus= ted X.509
>>> certificate source"
>>>
>>>
>>> Thanks,
>>>
>>> Vladimir
>>>
>>> On 28/07/17 21:33, Brian Campbell wrote:
>>>
>>> A new draft of "Mutual TLS Profile for OAuth 2.0" ha= s been published with
>>> the changes listed below based on comments and dissuasion in P= rague.
>>>
>>>=C2=A0 =C2=A0 draft-ietf-oauth-mtls-03<https://datatracker.ietf.org/doc/html/draf= t-ietf-oauth-mtls-03> <https= ://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>=
>>>
>>>
>>>=C2=A0 =C2=A0 o=C2=A0 Introduced metadata and client registrati= on parameter to publish
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0and request support for mutual TLS s= ender constrained access
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0tokens
>>>=C2=A0 =C2=A0 o=C2=A0 Added description of two methods of bindi= ng the cert and client,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0PKI and Public Key.
>>>=C2=A0 =C2=A0 o=C2=A0 Indicated that the "tls_client_auth&= quot; authentication method is for
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0the PKI method and introduced "= pub_key_tls_client_auth" for the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Public Key method
>>>=C2=A0 =C2=A0 o=C2=A0 Added implementation considerations, main= ly regarding TLS stack
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration and trust chain valida= tion, as well as how to to do
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0binding of access tokens to a TLS cl= ient certificate for public
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0clients, and considerations around c= ertificate bound access tokens
>>>=C2=A0 =C2=A0 o=C2=A0 Added new section to security considerati= ons on cert spoofing
>>>=C2=A0 =C2=A0 o=C2=A0 Add text suggesting that a new cnf member= be defined in the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0future, if hash function(s) other th= an SHA-256 need to be used for
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0certificate thumbprints
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: <internet-drafts@ietf.org> <internet-drafts@ietf.org>
>>> Date: Fri, Jul 28, 2017 at 12:25 PM
>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >>> To: i-d-announce@ietf= .org
>>> Cc: oauth@ietf.org
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>>> directories.
>>> This draft is a work item of the Web Authorization Protocol WG= of the IETF.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: Mutual TLS Profile for OAuth 2.0
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Brian Campbell
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0John Bradley
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nat Sakimura
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Torsten Lodderstedt
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 = =C2=A0 : draft-ietf-oauth-mtls-03.txt
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: 17
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : 2017-07-28
>>>
>>> Abstract:
>>>=C2=A0 =C2=A0 This document describes Transport Layer Security = (TLS) mutual
>>>=C2=A0 =C2=A0 authentication using X.509 certificates as a mech= anism for OAuth
>>>=C2=A0 =C2=A0 client authentication to the token endpoint as we= ll as for
>>>=C2=A0 =C2=A0 certificate bound sender constrained access token= s.
>>>
>>>
>>> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-m= tls/
>>>
>>> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https:= //datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03
>>>
>>> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-o= auth-mtls-03
>>>
>>>
>>> Please note that it may take a couple of minutes from the time= of submission
>>> until the htmlized version and diff are available at tools.ietf.= org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>>




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c09614c2de59c0555f29091-- From nobody Fri Aug 4 13:16:46 2017 Return-Path: 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 DF7C1120713 for ; Fri, 4 Aug 2017 13:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 2qdk3js7rE75 for ; Fri, 4 Aug 2017 13:16:40 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 D956D131C7C for ; Fri, 4 Aug 2017 13:16:39 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id y129so11853554pgy.4 for ; Fri, 04 Aug 2017 13:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4gVj0AaHIcNlazDPdh4c76wwZlrZCW7/BWnr/6W83uI=; b=IoOoasmU9xU52WS/uTaJqaEKggBBhC6mlclG2mfrHz8UfPQLR478Se84DSVQKSCqMf 5DiK+hZWl5sVgtJm+L83EpfN3UrGPjYStReezmOAzDiet2fEP54i4gACXaWPzT7Unmfl hKxv/rSejAyo0wqd4VClPH36+0wFlPeOxuBjaqPIujy07bp7tUJkSWuPB8FSOgenF+Hp UxPxstmvlN2zpqZ1w/vQFckUD82GjcalHl9XrxMNiQxfuojntvosRztAlkANeYVyWkdE BzBt/kk8trvi1wlXmJNETp9GPH78/pUV54D7gwtqBjRXkJjCWBrXRIrU0dBLwdiLjS7M Tzew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4gVj0AaHIcNlazDPdh4c76wwZlrZCW7/BWnr/6W83uI=; b=hJRX6dCHl1eq8IUromeyPNTmfQXM6evehjWOlmVDPgPnyOk1SNvQTUOfBaAhBZByy0 wJ0FTD8hwh0Accaot/gDHUGrFeM205ry2i7wNLYzC5zJbsapsP1NO/i8k7cTL6GFK4Vm jTPhPWyjFxxbRdurUdIPddmXJbYFVMV5WGOB2RX6zbUy5PfwVPq73RhplcOCMo3zy1im aJOUnvDJZmz49o78SwBMxr8Y1BzURO5q1g0GIl/a016QgRriYU1815oN6JhlV1fEvBB1 1/EQ7kSbvJHtR/fRCMev8ZgWcTqO5RpFqPXgl3THsm/eQI7Zbacedt6Ehm9DUJlNaS96 14xQ== X-Gm-Message-State: AIVw111WIsVxsuigucI06MuqIvu02CNbSCFuYGd2AH+yW0iaPf/VF+fN 5XDlk/4egAJ7gl72HiPcug== X-Received: by 10.84.216.30 with SMTP id m30mr4379200pli.218.1501877798747; Fri, 04 Aug 2017 13:16:38 -0700 (PDT) Received: from [10.25.10.10] (ip-120-48-244-173.california.us.northamericancoax.com. [173.244.48.120]) by smtp.gmail.com with ESMTPSA id n23sm4044486pfh.133.2017.08.04.13.16.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 13:16:37 -0700 (PDT) From: John Bradley Message-Id: <7EBDF15A-E2A7-4409-B2E8-01AF37D1C274@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 4 Aug 2017 16:16:24 -0400 In-Reply-To: <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> Cc: Brian Campbell , oauth To: Vladimir Dzhuvinov References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045cd7a2babc580555f32c60" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:16:45 -0000 --f403045cd7a2babc580555f32c60 Content-Type: multipart/alternative; boundary="Apple-Mail=_3ADC7433-9A6F-4020-9DE8-C1715FBE3E69" --Apple-Mail=_3ADC7433-9A6F-4020-9DE8-C1715FBE3E69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Having the whole certificate to compare may be easier in some = environments that trying to directly compare the public keys. I believe most environments make the cert from TLS available to the app = comparing that to the one retrieved from the x5c element is relatively = strait forward. When comparing keys I worry that that may not be that easy to get from = the TLS/HTTP stack. =20 Some environments will provide SPKI and others like java have methods to = directly manipulate the keys. We should also check on any issues with representation of EC public = keys. =20 While JWA docent allow compressed points RFC 5480 allows them in SPKI. Of the top of my head I don=E2=80=99t know if anyone issues certs in = that format, but they could. =20 If the client receives compressed points from SPKI and uncompressed from = JWK it is possible to compare them but I have a bad feeling people will = get it wrong. =20 There is also a issue with leading zeros that must be present in the JWK = but are not in the SPKI. For the most part comparing the raw keys will work with the three = currently supported named curves.=20 New curves may also introduce new wrinkles. If we were only talking RSA I would definitely ditch x5c. However given that a certificate of some sort must exist to make MTLS = work putting it in the x5c is not asking the world. Getting a app to string compare two blobs seems less likely to go wrong = in deployment than asking apps to do atleast format normalization of the = public keys to compare them. I wish it could be simpler. John B. > On Aug 4, 2017, at 3:17 PM, Vladimir Dzhuvinov = wrote: >=20 > What are the potential uses of the x5c parameter? >=20 > Vladimir >=20 >=20 > On 04/08/17 21:13, Brian Campbell wrote: >> Just wanted to note that, in an off-list exchange, John has pushed = back on >> the idea to potentially drop mention of using x5c. >>=20 >> On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell = >> wrote: >>=20 >>> Thanks for the review, Vladimir. >>>=20 >>> The text about which you have questions was written by Torsten = (credit or >>> blame where it's due!) but I believe he's out of the office for a = bit so >>> I'll try and answer. >>>=20 >>> Your 1st question: >>> I've had the same thought regarding the public key method and using = the >>> JWK x5c parameter. A JWK already has the public key, which is = sufficient >>> for comparison in the public key method. So x5c is just superfluous = here. I >>> believe that's a change that the next revision should have and will = look to >>> make it unless someone wants to make a strong case for needing x5c. >>>=20 >>> Your 2nd question: >>> I also found the sentence, "When used in conjunction with a trusted = X.509 >>> certificate source, it also allows the client to rotate its X.509 >>> certificates without the need to change its respective = authentication data >>> at the authorization server." somewhat difficult to understand when = I first >>> read it. The intended meaning relies on content earlier in the same >>> paragraph that says, "As pre-requisite, the client registers a X.509 >>> certificate or *a trusted source for its X.509 certificates (jwks = uri as >>> defined in [RFC7591])* with the authorization server." Basically = what >>> it's trying to say is that when a client is registered or configured = with a >>> jwks_uri, then client key rotation can be done without needing to >>> explicitly update the client config/registration with the AS. Does = that >>> explain it? I believe the text could be more straightforward and = will >>> endeavor to make it more clear in the next draft update. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov < >>> vladimir@connect2id.com> wrote: >>>=20 >>>> Thanks everyone for the update! Having a clear distinction between = the >>>> PKIX vs public key bound methods will help interop, implementers' = job, and >>>> it also appears good for security. >>>>=20 >>>> Questions: >>>>=20 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >>>> 03#section-2.3 >>>>=20 >>>> where the X.509 certificates are represented using the "x5c" = parameter from [RFC7517 >] >>>>=20 >>>> For the public key method, is it really necessary for the client to >>>> include its certificate in the JWK x5c parameter? This will make >>>> implementation harder for developers, and I'm not sure it adds = anything in >>>> terms of security. Registering the public key parameters seems = sufficient >>>> to me. >>>>=20 >>>>=20 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- = >>>> 03#section-2.1 >>>>=20 >>>> When used in conjunction with a trusted X.509 certificate source, = it also allows the client to rotate its X.509 certificates without the = need to change its respective authentication data at the authorization = server. >>>>=20 >>>> I don't understand this - "in conjunction with a trusted X.509 >>>> certificate source" >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Vladimir >>>>=20 >>>> On 28/07/17 21:33, Brian Campbell wrote: >>>>=20 >>>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been = published with >>>> the changes listed below based on comments and dissuasion in = Prague. >>>>=20 >>>> = draft-ietf-oauth-mtls-03> = > >>>>=20 >>>>=20 >>>> o Introduced metadata and client registration parameter to = publish >>>> and request support for mutual TLS sender constrained access >>>> tokens >>>> o Added description of two methods of binding the cert and = client, >>>> PKI and Public Key. >>>> o Indicated that the "tls_client_auth" authentication method is = for >>>> the PKI method and introduced "pub_key_tls_client_auth" for = the >>>> Public Key method >>>> o Added implementation considerations, mainly regarding TLS = stack >>>> configuration and trust chain validation, as well as how to to = do >>>> binding of access tokens to a TLS client certificate for = public >>>> clients, and considerations around certificate bound access = tokens >>>> o Added new section to security considerations on cert spoofing >>>> o Add text suggesting that a new cnf member be defined in the >>>> future, if hash function(s) other than SHA-256 need to be used = for >>>> certificate thumbprints >>>>=20 >>>>=20 >>>>=20 >>>> ---------- Forwarded message ---------- >>>> From: > = > >>>> Date: Fri, Jul 28, 2017 at 12:25 PM >>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >>>> To: i-d-announce@ietf.org >>>> Cc: oauth@ietf.org >>>>=20 >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Web Authorization Protocol WG of = the IETF. >>>>=20 >>>> Title : Mutual TLS Profile for OAuth 2.0 >>>> Authors : Brian Campbell >>>> John Bradley >>>> Nat Sakimura >>>> Torsten Lodderstedt >>>> Filename : draft-ietf-oauth-mtls-03.txt >>>> Pages : 17 >>>> Date : 2017-07-28 >>>>=20 >>>> Abstract: >>>> This document describes Transport Layer Security (TLS) mutual >>>> authentication using X.509 certificates as a mechanism for OAuth >>>> client authentication to the token endpoint as well as for >>>> certificate bound sender constrained access tokens. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft = is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ = >>>>=20 >>>> There are also htmlized versions available = at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker= .ietf.org/doc/html/draft-ietf-oauth-mtls-03 = >>>>=20 >>>> A diff from the previous version is available = at:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 = >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at tools.ietf.org = . >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP = at:ftp://ftp.ietf.org/internet-drafts/ = >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps = ://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_3ADC7433-9A6F-4020-9DE8-C1715FBE3E69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Having the whole certificate to compare may be easier in some = environments that trying to directly compare the public keys.

I believe most = environments make the cert from TLS available to the app comparing that = to the one retrieved from the x5c element is relatively strait = forward.

When = comparing keys I worry that that may not be that easy to get from the = TLS/HTTP stack.  
Some environments will = provide SPKI and others like java have methods to directly manipulate = the keys.

We = should also check on any issues with representation of EC public keys. =  
While JWA docent allow compressed points RFC = 5480 allows them in SPKI.

Of the top of my head I don=E2=80=99t know if anyone issues = certs in that format, but they could.  

If the client receives compressed = points from SPKI and uncompressed from JWK it is possible to compare = them but I have a bad feeling people will get it wrong. =   

There is also a issue with leading zeros that must be present = in the JWK but are not in the SPKI.

For the most part comparing the raw = keys will work with the three currently supported named = curves. 
New curves may also introduce new = wrinkles.

If = we were only talking RSA I would definitely ditch x5c.

However given that a = certificate of some sort must exist to make MTLS work putting it in the = x5c is not asking the world.

Getting a app to string compare two = blobs seems less likely to go wrong in deployment than asking apps to do = atleast format normalization of the public keys to compare = them.

I wish = it could be simpler.

John B.


On Aug 4, 2017, at 3:17 PM, = Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

What are the potential uses of = the x5c parameter?

Vladimir
On 04/08/17 21:13, Brian Campbell = wrote:
Just wanted to note that, in an off-list exchange, John has = pushed back on
the idea to potentially drop mention of = using x5c.

On Wed, Aug 2, 2017 at 9:29 AM, = Brian Campbell <bcampbell@pingidentity.com>
wrote:

Thanks = for the review, Vladimir.

The text about = which you have questions was written by Torsten (credit or
blame where it's due!) but I believe he's out of the office = for a bit so
I'll try and answer.

Your 1st question:
I've had the same thought = regarding the public key method and using the
JWK x5c = parameter. A JWK already has the public key, which is sufficient
for comparison in the public key method. So x5c is just = superfluous here. I
believe that's a change that the next = revision should have and will look to
make it unless = someone wants to make a strong case for needing x5c.

Your 2nd question:
I also found the sentence, = "When used in conjunction with a trusted X.509
certificate = source, it also allows the client to rotate its X.509
certificates without the need to change its respective = authentication data
at the authorization server." somewhat = difficult to understand when I first
read it. The intended = meaning relies on content earlier in the same
paragraph = that says, "As pre-requisite, the client registers a X.509
certificate or *a trusted source for its X.509 certificates = (jwks uri as
defined in [RFC7591])* with the authorization = server."  Basically what
it's trying to say is that = when a client is registered or configured with a
jwks_uri, = then client key rotation can be done without needing to
explicitly update the client config/registration with the AS. = Does that
explain it? I believe the text could be more = straightforward and will
endeavor to make it more clear in = the next draft update.








On Wed, Aug 2, 2017 at 1:53 AM, Vladimir = Dzhuvinov <
vladimir@connect2id.com> wrote:

Thanks everyone for the = update! Having a clear distinction between the
PKIX vs = public key bound methods will help interop, implementers' job, and
it also appears good for security.

Questions:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
03#section-2.3

where the = X.509 certificates are represented using the "x5c" parameter from = [RFC7517 <https://datatracker.ietf.org/doc/html/rfc7517>]

For the public key method, is it really = necessary for the client to
include its certificate in the = JWK x5c parameter? This will make
implementation harder = for developers, and I'm not sure it adds anything in
terms = of security. Registering the public key parameters seems sufficient
to me.


https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
03#section-2.1

When used in = conjunction with a trusted X.509 certificate source, it also allows the = client to rotate its X.509 certificates without the need to change its = respective authentication data at the authorization server.

I don't understand this - "in conjunction with = a trusted X.509
certificate source"


Thanks,

Vladimir
On 28/07/17 21:33, Brian Campbell wrote:

A new draft of "Mutual TLS Profile for OAuth = 2.0" has been published with
the changes listed below = based on comments and dissuasion in Prague.

  draft-ietf-oauth-mtls-03<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03<= /a>> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03<= /a>>


  o =  Introduced metadata and client registration parameter to = publish
     and request support = for mutual TLS sender constrained access
     tokens
  o  Added description of two methods of = binding the cert and client,
     PKI and Public Key.
  o  Indicated that the "tls_client_auth" = authentication method is for
     the PKI method and introduced = "pub_key_tls_client_auth" for the
     Public Key method
  o  Added implementation considerations, = mainly regarding TLS stack
     configuration and trust chain = validation, as well as how to to do
     binding of access tokens to a = TLS client certificate for public
     clients, and considerations = around certificate bound access tokens
  o =  Added new section to security considerations on cert spoofing
  o  Add text suggesting that a new cnf member = be defined in the
     future, if = hash function(s) other than SHA-256 need to be used for
     certificate thumbprints



---------- = Forwarded message ----------
From: <internet-drafts@ietf.org> <internet-drafts@ietf.org>
Date: Fri, Jul = 28, 2017 at 12:25 PM
Subject: [OAUTH-WG] I-D Action: = draft-ietf-oauth-mtls-03.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New = Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the = Web Authorization Protocol WG of the IETF.

       Title =           : Mutual TLS = Profile for OAuth 2.0
       Authors =         : Brian Campbell
          &nb= sp;            = ;  John Bradley
          &nb= sp;            = ;  Nat Sakimura
          &nb= sp;            = ;  Torsten Lodderstedt
       Filename =        : = draft-ietf-oauth-mtls-03.txt
       Pages =           : 17
       Date =            : = 2017-07-28

Abstract:
  This document describes Transport Layer Security = (TLS) mutual
  authentication using X.509 = certificates as a mechanism for OAuth
  client = authentication to the token endpoint as well as for
  certificate bound sender constrained access = tokens.


The IETF datatracker = status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

There are also htmlized versions available = at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://dat= atracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03

A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03


Please note that it may = take a couple of minutes from the time of submission
until = the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th


_______________________________________________
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

= --Apple-Mail=_3ADC7433-9A6F-4020-9DE8-C1715FBE3E69-- --f403045cd7a2babc580555f32c60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIDkkXABJsOpQ3yieFu1Egz0k9yLx zApwbFug1pQSUIUgMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwNDIwMTYzOVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQCerIW0GeO4pbkW3Y1scNF2FCPWZ5Oze3OJXsJSOA44nd+7 /41mMwaXiIeaYQqAS7rQT5Sdp8rcyXIBZ+7j21poXrkVK6xuDSemC+WVvYIXrsCYm3+QYMQKqmty 6cT4Y7MRin+9mo6NPGjrqvz4zqlwpnFaPYedfmh1ma7vYWqt76L7TmC+cHZleSgiiZl0q0G+F784 QNgsiOcZp/IFzYzSqHgGcPPs+cRAfvU4Hu1fOk3bc/LjY6w1H/CjHz154ctK3foOm3xsmBesJInA MsA6Zysl+IdJw+kmGfxYZiXJSgZwDnRUgyMRok53slXhr8eaZL06vJGuKbIG6EPqkpk8 --f403045cd7a2babc580555f32c60-- From nobody Sat Aug 5 15:31:17 2017 Return-Path: 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 AE4D91201F8 for ; Sat, 5 Aug 2017 15:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 WU7vcXiSsWCC for ; Sat, 5 Aug 2017 15:31:12 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 1082B120721 for ; Sat, 5 Aug 2017 15:31:11 -0700 (PDT) X-AuditID: 12074423-789ff70000001cfd-c7-5986472e3228 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.8C.07421.E2746895; Sat, 5 Aug 2017 18:31:10 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v75MV9rp027975; Sat, 5 Aug 2017 18:31:10 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v75MV6so005385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Aug 2017 18:31:08 -0400 Date: Sat, 5 Aug 2017 17:31:06 -0500 From: Benjamin Kaduk To: Denis Cc: oauth@ietf.org Message-ID: <20170805223106.GD70977@kduck.kaduk.org> References: <43fcb3b7-f0ea-47f3-b0f4-9d0f33df7d7f@free.fr> <73394F38-606B-45EC-8F6B-5050BE59CD46@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixCmqrKvn3hZpsLPByGJ9l53Fybev2ByY PPrXfWb1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxq4dM9kKTrBVfDlk1cA4n7WLkZNDQsBE4v70 A0xdjFwcQgKLmSSaFy9mhnA2MEosnHSRHcK5wiTxc8EroAwHB4uAisS677wg3WxAZkP3ZWYQ W0RATmLVvWtgNrOAkMSHS00sILawgLfEumM/weK8QNs6V66CWnCQRaLr7Ck2iISgxMmZT1gg mrUkbvx7yQSyi1lAWmL5Pw6QMKeAtcTXq+fA5ogKKEvM27eKbQKjwCwk3bOQdM9C6F7AyLyK UTYlt0o3NzEzpzg1Wbc4OTEvL7VI10wvN7NELzWldBMjKETZXZR3ML7s8z7EKMDBqMTDu4Kv LVKINbGsuDL3EKMkB5OSKG/1saZIIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8L361RgrxpiRW VqUW5cOkpDlYlMR5xTUaI4QE0hNLUrNTUwtSi2CyMhwcShK8712B9ggWpaanVqRl5pQgpJk4 OEGG8wANn+gGVMNbXJCYW5yZDpE/xajL0fRhyxcmIZa8/LxUKXHecJBBAiBFGaV5cHNAqUUi e3/NK0ZxoLeEeRNARvEA0xLcpFdAS5iAlrxJBPmguCQRISXVwOgk+cs3731Zi9DUpCsZ2pFd n9j9m1L4vyz7z8llKmWwjUlxr857BZFE84Os057kOPnX2d765eFk+fRHZ6nsknjJBcfcDqgc VLG/YPiM67iaQxGT8edTXlXr3v/5tzTHS/pj5VuziDUhU+7uuHzwsOZsgY5Wg+PZKss/Si77 tkjZd9KT8oSivUosxRmJhlrMRcWJAEzFAB8IAwAA Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 22:31:14 -0000 On Fri, Aug 04, 2017 at 03:36:10PM +0200, Denis wrote: > > Before writing an individual draft, there needs to be a general > agreement within the WG to consider such a work item as valuable. Anyone can write an individual draft at any[1] time. Having thoughts specified in a concrete proposed specification can help people to understand the proposal, help people provide suggested changes, and prevent duplication of effort attempting to describe the same idea in multiple email messages. A side effect of a better understanding of a given proposal may (or may not) be a decision to not adopt it as a WG item, but that risk does not seem like a reason to not write an individual draft. -Ben [1] submission is blacked out for a couple weeks prior to in-person IETF meetings, but that doesn't keep you from writing. From nobody Mon Aug 7 08:17:36 2017 Return-Path: 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 CCDDE13246B for ; Mon, 7 Aug 2017 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zgYCUJoLOezO for ; Mon, 7 Aug 2017 08:17:33 -0700 (PDT) Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (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 62FEE132469 for ; Mon, 7 Aug 2017 08:17:33 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id ejm9dxNdk7cSOejm9dGIBv; Mon, 07 Aug 2017 08:17:02 -0700 To: oauth From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Mon, 7 Aug 2017 18:17:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030403050303040609020203" X-CMAE-Envelope: MS4wfAyzMc3uae6EW/cfWKAOMUIeuohOLbXP/z2a4DWziZsU2l1TdzXz+HQFPfAwlxPzT3BHXnPe/Rj2YzY/ORKNMDhoSHsIRRJqnwK8Qh1+0uFvD9Z0lazB 0zxCJuW6HUskrb+8LP376+auWBSz9ngUs7eQi3FmJWlPlkggBjfiW4nT Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-mtls-03 - auth to other endpoints? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:17:35 -0000 This is a cryptographically signed message in MIME format. --------------ms030403050303040609020203 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US I just noticed that the spec is very explicit on the MTLS auth method being used for the token endpoint, but it could also work with other endpoints, e.g. RFC 7009 (revocation), 7662 (intospection). Were there any talks about that? Vladimir --------------ms030403050303040609020203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MDcxNTE3MDBaMC8GCSqGSIb3DQEJBDEiBCBM7rAZ5fBV5NTconSggOIKGhc+wuZc J2lG3GWyzIGD7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQCjrAu35dP3 675OIZWPw0erWW3bn0PWnSK0F7lj/6Hlb4xREql8n4j4jfQxiR6lQxNE2yQ8oRzIPLRS24Tl /9+eAPxUyGax76+/AQSuTZdid+96Zed2XobvbKUJIhZgtCJjKk7Jz2yCit6+I0BrLQz7P+Wi wzCR4BFi9apwlU4DQu6J6h9WjLAsJ94AIoKT59ArZ+Glrpwgk9Y3279egl9qRMd6mAW5tqq9 Mip5zUTPrDqvuCLkK7XUYOGRvDTNnY612bgXSUY7WdURSMIRd3qX5OQvPT/X/U+kvxFA59Kv 66Q/MAXD9L1ZlIZ3O8zNc2scEjLp1r5DoWHuqS/U2X2lAAAAAAAA --------------ms030403050303040609020203-- From nobody Mon Aug 7 08:39:36 2017 Return-Path: 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 2C01D13261E for ; Mon, 7 Aug 2017 08:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 LBvRd34Gavj7 for ; Mon, 7 Aug 2017 08:39:32 -0700 (PDT) Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) (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 6EAC813261A for ; Mon, 7 Aug 2017 08:39:32 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id ek7NdTKJbXPOMek7Od1p9c; Mon, 07 Aug 2017 08:38:59 -0700 To: John Bradley Cc: Brian Campbell , oauth References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> <7EBDF15A-E2A7-4409-B2E8-01AF37D1C274@ve7jtb.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <6d150831-ab97-09eb-199c-65eb9e0457c7@connect2id.com> Date: Mon, 7 Aug 2017 18:38:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7EBDF15A-E2A7-4409-B2E8-01AF37D1C274@ve7jtb.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020409090402070806020607" X-CMAE-Envelope: MS4wfC7uaEEVnJsNmb/XzE2pVdJ9amDEHTVlFSBxj7xIfwsLgnDt8+lAAt/JfZxm3K5aKi132rGeg8o7++GoQB1UH8FJdBejuhmgizHWlyMvd8l8Ylohftmd 9ZrMIzkcVhbVMXkzZ11ZbgIOLfNld05zL1UmIDwp3CwrWzyGENb8QIz8pRobiul9gtriB4hkKp3r2421JmdxouYy4fDJ+fkmReWawRXVlCYcfHEiHpKNmObB kC6EDncnXCgLaOy3MfvYyQ== Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:39:35 -0000 This is a cryptographically signed message in MIME format. --------------ms020409090402070806020607 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US A while ago, if I'm not mistaken, I glimpsed some report of vulnerabilities caused by incorrect public key comparison. It looks like key comparison merits a section on its own. How about giving the AS the option to check the signature of the submitted client cert, which is better supported? (but will be much more expensive in terms of CPU time than comparison) If an AS registers an x5c with the JWK, is the AS supposed to validate the x5c signature using the JWK public parameter? Any other checks? Thanks, Vladimir On 04/08/17 23:16, John Bradley wrote: > Having the whole certificate to compare may be easier in some environme= nts that trying to directly compare the public keys. > > I believe most environments make the cert from TLS available to the app= comparing that to the one retrieved from the x5c element is relatively s= trait forward. > > When comparing keys I worry that that may not be that easy to get from = the TLS/HTTP stack. =20 > Some environments will provide SPKI and others like java have methods t= o directly manipulate the keys. > > We should also check on any issues with representation of EC public key= s. =20 > While JWA docent allow compressed points RFC 5480 allows them in SPKI. > > Of the top of my head I don=E2=80=99t know if anyone issues certs in th= at format, but they could. =20 > > If the client receives compressed points from SPKI and uncompressed fro= m JWK it is possible to compare them but I have a bad feeling people will= get it wrong. =20 > > There is also a issue with leading zeros that must be present in the JW= K but are not in the SPKI. > > For the most part comparing the raw keys will work with the three curre= ntly supported named curves.=20 > New curves may also introduce new wrinkles. > > If we were only talking RSA I would definitely ditch x5c. > > However given that a certificate of some sort must exist to make MTLS w= ork putting it in the x5c is not asking the world. > > Getting a app to string compare two blobs seems less likely to go wrong= in deployment than asking apps to do atleast format normalization of the= public keys to compare them. > > I wish it could be simpler. > > John B. > > >> On Aug 4, 2017, at 3:17 PM, Vladimir Dzhuvinov wrote: >> >> What are the potential uses of the x5c parameter? >> >> Vladimir >> >> >> On 04/08/17 21:13, Brian Campbell wrote: >>> Just wanted to note that, in an off-list exchange, John has pushed ba= ck on >>> the idea to potentially drop mention of using x5c. >>> >>> On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell >>> wrote: >>> >>>> Thanks for the review, Vladimir. >>>> >>>> The text about which you have questions was written by Torsten (cred= it or >>>> blame where it's due!) but I believe he's out of the office for a bi= t so >>>> I'll try and answer. >>>> >>>> Your 1st question: >>>> I've had the same thought regarding the public key method and using = the >>>> JWK x5c parameter. A JWK already has the public key, which is suffic= ient >>>> for comparison in the public key method. So x5c is just superfluous = here. I >>>> believe that's a change that the next revision should have and will = look to >>>> make it unless someone wants to make a strong case for needing x5c. >>>> >>>> Your 2nd question: >>>> I also found the sentence, "When used in conjunction with a trusted = X.509 >>>> certificate source, it also allows the client to rotate its X.509 >>>> certificates without the need to change its respective authenticatio= n data >>>> at the authorization server." somewhat difficult to understand when = I first >>>> read it. The intended meaning relies on content earlier in the same >>>> paragraph that says, "As pre-requisite, the client registers a X.509= >>>> certificate or *a trusted source for its X.509 certificates (jwks ur= i as >>>> defined in [RFC7591])* with the authorization server." Basically wh= at >>>> it's trying to say is that when a client is registered or configured= with a >>>> jwks_uri, then client key rotation can be done without needing to >>>> explicitly update the client config/registration with the AS. Does t= hat >>>> explain it? I believe the text could be more straightforward and wil= l >>>> endeavor to make it more clear in the next draft update. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov < >>>> vladimir@connect2id.com> wrote: >>>> >>>>> Thanks everyone for the update! Having a clear distinction between = the >>>>> PKIX vs public key bound methods will help interop, implementers' j= ob, and >>>>> it also appears good for security. >>>>> >>>>> Questions: >>>>> >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >>>>> 03#section-2.3 >>>>> >>>>> where the X.509 certificates are represented using the "x5c" parame= ter from [RFC7517 >] >>>>> >>>>> For the public key method, is it really necessary for the client to= >>>>> include its certificate in the JWK x5c parameter? This will make >>>>> implementation harder for developers, and I'm not sure it adds anyt= hing in >>>>> terms of security. Registering the public key parameters seems suff= icient >>>>> to me. >>>>> >>>>> >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >>>>> 03#section-2.1 >>>>> >>>>> When used in conjunction with a trusted X.509 certificate source, i= t also allows the client to rotate its X.509 certificates without the nee= d to change its respective authentication data at the authorization serve= r. >>>>> >>>>> I don't understand this - "in conjunction with a trusted X.509 >>>>> certificate source" >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Vladimir >>>>> >>>>> On 28/07/17 21:33, Brian Campbell wrote: >>>>> >>>>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been publishe= d with >>>>> the changes listed below based on comments and dissuasion in Prague= =2E >>>>> >>>>> draft-ietf-oauth-mtls-03> > >>>>> >>>>> >>>>> o Introduced metadata and client registration parameter to publi= sh >>>>> and request support for mutual TLS sender constrained access >>>>> tokens >>>>> o Added description of two methods of binding the cert and clien= t, >>>>> PKI and Public Key. >>>>> o Indicated that the "tls_client_auth" authentication method is = for >>>>> the PKI method and introduced "pub_key_tls_client_auth" for th= e >>>>> Public Key method >>>>> o Added implementation considerations, mainly regarding TLS stac= k >>>>> configuration and trust chain validation, as well as how to to= do >>>>> binding of access tokens to a TLS client certificate for publi= c >>>>> clients, and considerations around certificate bound access to= kens >>>>> o Added new section to security considerations on cert spoofing >>>>> o Add text suggesting that a new cnf member be defined in the >>>>> future, if hash function(s) other than SHA-256 need to be used= for >>>>> certificate thumbprints >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: > = > >>>>> Date: Fri, Jul 28, 2017 at 12:25 PM >>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >>>>> To: i-d-announce@ietf.org >>>>> Cc: oauth@ietf.org >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Web Authorization Protocol WG of t= he IETF. >>>>> >>>>> Title : Mutual TLS Profile for OAuth 2.0 >>>>> Authors : Brian Campbell >>>>> John Bradley >>>>> Nat Sakimura >>>>> Torsten Lodderstedt >>>>> Filename : draft-ietf-oauth-mtls-03.txt >>>>> Pages : 17 >>>>> Date : 2017-07-28 >>>>> >>>>> Abstract: >>>>> This document describes Transport Layer Security (TLS) mutual >>>>> authentication using X.509 certificates as a mechanism for OAuth >>>>> client authentication to the token endpoint as well as for >>>>> certificate bound sender constrained access tokens. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is:https://datatrac= ker.ietf.org/doc/draft-ietf-oauth-mtls/ >>>>> >>>>> There are also htmlized versions available at:https://tools.ietf.or= g/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draf= t-ietf-oauth-mtls-03 >>>>> >>>>> A diff from the previous version is available at:https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of s= ubmission >>>>> until the htmlized version and diff are available at tools.ietf.org= . >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ie= tf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing listOAuth@ietf.orghttps ://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 --------------ms020409090402070806020607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MDcxNTM4NTdaMC8GCSqGSIb3DQEJBDEiBCDz0pNOUfzER1xES5pEVS/Ru37n/wTz /4xmuMK40yBkdjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQBqdhdvNqby aH3rs54QHjMwaPyh64fzAhqJ26zuFePaSQIJdw2Wkkw0DVDyrNeG8DOb4Fc+Z/Hft2SGR3SZ jcJIl/0K7ijmTnH5dsoJpKig/uP+Zu737Ix1HWvJr4YGtcFgk84OeHvF3sr2I5/wmq1zqf/y nmE9YZhspUi3EkYQn0vc5N0zesYO7ZeOkoUMBrdvhBBaiQ4709EePEecJy/IJRSX+E3Br7AG 6YgH0SjssNkDKHgiZiwT1P7vLHlk7TuLzY/k7+6FA16YylfpbdokDv1IOc6Bk2MOIax03J2z Mt2fQjp5JewDwj0VS5Am2sVAxorMmAAmoL0TiUdPkuNLAAAAAAAA --------------ms020409090402070806020607-- From nobody Mon Aug 7 08:53:49 2017 Return-Path: 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 00F0613226B for ; Mon, 7 Aug 2017 08:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 q5EbwG9SFbLK for ; Mon, 7 Aug 2017 08:53:41 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 2625413239C for ; Mon, 7 Aug 2017 08:53:41 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id d136so4952480qkg.3 for ; Mon, 07 Aug 2017 08:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bjnZyW7D5niifHQRSLVB0JfAAj2tGIo2WPawjqlI7kE=; b=O8KMq+RgxD/OWA1bY1kQ2m2GxvJwXkZzYZePkszz3AFZ3EXLNrGZNpVwRRhK2/o9Sd /jMcW9YKMxI4cD2Y+mYuPKuaMrxqLPKAxvxwdOJFNFewuRjpWfvhtGS3tMy75zUEbYcn 1Pe8hgUO3kpTkDc3T6z+Kl0udHcxBug4qwWguGLkj1+Y/lUy5jIPsJmJUp6VBUKURdt9 We/DVG0Nb1lagLNjKTquao2RVU8rBKzaKE6yAdsVzP8bToAzSIEZdooJmHSvzoq/0T2I 9Jhl6A1Wm14IoS+mP/eErdTrwMueNPfIeEJgI9cNZGAvmtqlMrAdjddk20cL2WeFLaoR K+Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bjnZyW7D5niifHQRSLVB0JfAAj2tGIo2WPawjqlI7kE=; b=NdEqabkGQt+38YZPgwhjbnykKDrBCWljuXrGaskZa+LVpsGnbCaCZtBkQp/E+koP5W w9alH96+fB9N+Dv2EKC2FQsUt/3D3u3RoPprjd96wdvxdnXt+bCNkgyjZFQHUKBnOtXl TjcUETF2jPbe6nfaNf+AeR25gtLZwlnlCXgaL/PO/y12SIk1nM0KFQkFW/SJwE+PkSMc S5smGaEzLL2K2lYxRek1E76EbZDUk3uuBQRhYXMeYhl8uO0K9GOGwBJjKVILN+4+fAks tXhNcUFHRndu2BNoEd8cC7fUCvnHgKTYDVaDKRQbnPhpU9VuYtXQvpGV9Lgo/W0Jgkxn DV0A== X-Gm-Message-State: AHYfb5jodfDmVfYcnyfqTQHocfBkcameewFlIr3VhjZwMn1fqwMV0Fnu Al8hyang841p9jzA X-Received: by 10.55.20.150 with SMTP id 22mr1304128qku.319.1502121218604; Mon, 07 Aug 2017 08:53:38 -0700 (PDT) Received: from johns-mbp.lan ([191.115.204.25]) by smtp.gmail.com with ESMTPSA id b71sm5502967qkj.8.2017.08.07.08.53.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 08:53:37 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 Aug 2017 11:53:32 -0400 In-Reply-To: <6d150831-ab97-09eb-199c-65eb9e0457c7@connect2id.com> Cc: Brian Campbell , oauth To: Vladimir Dzhuvinov References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> <7EBDF15A-E2A7-4409-B2E8-01AF37D1C274@ve7jtb.com> <6d150831-ab97-09eb-199c-65eb9e0457c7@connect2id.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1145e77ac011f105562bd925" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:53:46 -0000 --001a1145e77ac011f105562bd925 Content-Type: multipart/alternative; boundary="Apple-Mail=_038EE4C7-6C72-4E5B-8FEA-14AE2DAA96D5" --Apple-Mail=_038EE4C7-6C72-4E5B-8FEA-14AE2DAA96D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The AS always gets the client cert from the TLS stack. Validating the = certificate cain is something people get wrong all the time. However = that is what the DN names are for. Using those requires validating the = certs. If you use the x5c from the JWKS is is a simple compare of the two = certs. In principal the app doesn't need to validate the cert using = PKIX. The security is provided by checking the server cert protecting = the JWKS endpoint and is dealt with in TLS one hopes. John B. > On Aug 7, 2017, at 11:38 AM, Vladimir Dzhuvinov = wrote: >=20 > A while ago, if I'm not mistaken, I glimpsed some report of > vulnerabilities caused by incorrect public key comparison. >=20 > It looks like key comparison merits a section on its own. >=20 > How about giving the AS the option to check the signature of the > submitted client cert, which is better supported? (but will be much = more > expensive in terms of CPU time than comparison) >=20 > If an AS registers an x5c with the JWK, is the AS supposed to validate > the x5c signature using the JWK public parameter? Any other checks? >=20 > Thanks, >=20 > Vladimir >=20 > On 04/08/17 23:16, John Bradley wrote: >> Having the whole certificate to compare may be easier in some = environments that trying to directly compare the public keys. >>=20 >> I believe most environments make the cert from TLS available to the = app comparing that to the one retrieved from the x5c element is = relatively strait forward. >>=20 >> When comparing keys I worry that that may not be that easy to get = from the TLS/HTTP stack. =20 >> Some environments will provide SPKI and others like java have methods = to directly manipulate the keys. >>=20 >> We should also check on any issues with representation of EC public = keys. =20 >> While JWA docent allow compressed points RFC 5480 allows them in = SPKI. >>=20 >> Of the top of my head I don=E2=80=99t know if anyone issues certs in = that format, but they could. =20 >>=20 >> If the client receives compressed points from SPKI and uncompressed = from JWK it is possible to compare them but I have a bad feeling people = will get it wrong. =20 >>=20 >> There is also a issue with leading zeros that must be present in the = JWK but are not in the SPKI. >>=20 >> For the most part comparing the raw keys will work with the three = currently supported named curves.=20 >> New curves may also introduce new wrinkles. >>=20 >> If we were only talking RSA I would definitely ditch x5c. >>=20 >> However given that a certificate of some sort must exist to make MTLS = work putting it in the x5c is not asking the world. >>=20 >> Getting a app to string compare two blobs seems less likely to go = wrong in deployment than asking apps to do atleast format normalization = of the public keys to compare them. >>=20 >> I wish it could be simpler. >>=20 >> John B. >>=20 >>=20 >>> On Aug 4, 2017, at 3:17 PM, Vladimir Dzhuvinov = wrote: >>>=20 >>> What are the potential uses of the x5c parameter? >>>=20 >>> Vladimir >>>=20 >>>=20 >>> On 04/08/17 21:13, Brian Campbell wrote: >>>> Just wanted to note that, in an off-list exchange, John has pushed = back on >>>> the idea to potentially drop mention of using x5c. >>>>=20 >>>> On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell = >>>> wrote: >>>>=20 >>>>> Thanks for the review, Vladimir. >>>>>=20 >>>>> The text about which you have questions was written by Torsten = (credit or >>>>> blame where it's due!) but I believe he's out of the office for a = bit so >>>>> I'll try and answer. >>>>>=20 >>>>> Your 1st question: >>>>> I've had the same thought regarding the public key method and = using the >>>>> JWK x5c parameter. A JWK already has the public key, which is = sufficient >>>>> for comparison in the public key method. So x5c is just = superfluous here. I >>>>> believe that's a change that the next revision should have and = will look to >>>>> make it unless someone wants to make a strong case for needing = x5c. >>>>>=20 >>>>> Your 2nd question: >>>>> I also found the sentence, "When used in conjunction with a = trusted X.509 >>>>> certificate source, it also allows the client to rotate its X.509 >>>>> certificates without the need to change its respective = authentication data >>>>> at the authorization server." somewhat difficult to understand = when I first >>>>> read it. The intended meaning relies on content earlier in the = same >>>>> paragraph that says, "As pre-requisite, the client registers a = X.509 >>>>> certificate or *a trusted source for its X.509 certificates (jwks = uri as >>>>> defined in [RFC7591])* with the authorization server." Basically = what >>>>> it's trying to say is that when a client is registered or = configured with a >>>>> jwks_uri, then client key rotation can be done without needing to >>>>> explicitly update the client config/registration with the AS. Does = that >>>>> explain it? I believe the text could be more straightforward and = will >>>>> endeavor to make it more clear in the next draft update. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov < >>>>> vladimir@connect2id.com> wrote: >>>>>=20 >>>>>> Thanks everyone for the update! Having a clear distinction = between the >>>>>> PKIX vs public key bound methods will help interop, implementers' = job, and >>>>>> it also appears good for security. >>>>>>=20 >>>>>> Questions: >>>>>>=20 >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >>>>>> 03#section-2.3 >>>>>>=20 >>>>>> where the X.509 certificates are represented using the "x5c" = parameter from [RFC7517 >>] >>>>>>=20 >>>>>> For the public key method, is it really necessary for the client = to >>>>>> include its certificate in the JWK x5c parameter? This will make >>>>>> implementation harder for developers, and I'm not sure it adds = anything in >>>>>> terms of security. Registering the public key parameters seems = sufficient >>>>>> to me. >>>>>>=20 >>>>>>=20 >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- = = > >>>>>> 03#section-2.1 >>>>>>=20 >>>>>> When used in conjunction with a trusted X.509 certificate source, = it also allows the client to rotate its X.509 certificates without the = need to change its respective authentication data at the authorization = server. >>>>>>=20 >>>>>> I don't understand this - "in conjunction with a trusted X.509 >>>>>> certificate source" >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Vladimir >>>>>>=20 >>>>>> On 28/07/17 21:33, Brian Campbell wrote: >>>>>>=20 >>>>>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been = published with >>>>>> the changes listed below based on comments and dissuasion in = Prague. >>>>>>=20 >>>>>> = draft-ietf-oauth-mtls-03 = >> = = >> >>>>>>=20 >>>>>>=20 >>>>>> o Introduced metadata and client registration parameter to = publish >>>>>> and request support for mutual TLS sender constrained access >>>>>> tokens >>>>>> o Added description of two methods of binding the cert and = client, >>>>>> PKI and Public Key. >>>>>> o Indicated that the "tls_client_auth" authentication method is = for >>>>>> the PKI method and introduced "pub_key_tls_client_auth" for = the >>>>>> Public Key method >>>>>> o Added implementation considerations, mainly regarding TLS = stack >>>>>> configuration and trust chain validation, as well as how to = to do >>>>>> binding of access tokens to a TLS client certificate for = public >>>>>> clients, and considerations around certificate bound access = tokens >>>>>> o Added new section to security considerations on cert spoofing >>>>>> o Add text suggesting that a new cnf member be defined in the >>>>>> future, if hash function(s) other than SHA-256 need to be = used for >>>>>> certificate thumbprints >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ---------- Forwarded message ---------- >>>>>> From: = >> = = >> >>>>>> Date: Fri, Jul 28, 2017 at 12:25 PM >>>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >>>>>> To: i-d-announce@ietf.org = > >>>>>> Cc: oauth@ietf.org > >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Web Authorization Protocol WG of = the IETF. >>>>>>=20 >>>>>> Title : Mutual TLS Profile for OAuth 2.0 >>>>>> Authors : Brian Campbell >>>>>> John Bradley >>>>>> Nat Sakimura >>>>>> Torsten Lodderstedt >>>>>> Filename : draft-ietf-oauth-mtls-03.txt >>>>>> Pages : 17 >>>>>> Date : 2017-07-28 >>>>>>=20 >>>>>> Abstract: >>>>>> This document describes Transport Layer Security (TLS) mutual >>>>>> authentication using X.509 certificates as a mechanism for OAuth >>>>>> client authentication to the token endpoint as well as for >>>>>> certificate bound sender constrained access tokens. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft = is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ = = > >>>>>>=20 >>>>>> There are also htmlized versions available = at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker= .ietf.org/doc/html/draft-ietf-oauth-mtls-03 = > >>>>>>=20 >>>>>> A diff from the previous version is available = at:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 = = > >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of = submission >>>>>> until the htmlized version and diff are available at = tools.ietf.org >. >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP = at:ftp://ftp.ietf.org/internet-drafts/ = = > >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing listOAuth@ietf.orghttps = >://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth = = > >>>>>>=20 >>>>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth = = > --Apple-Mail=_038EE4C7-6C72-4E5B-8FEA-14AE2DAA96D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The AS always gets the client cert from the TLS stack.   = Validating the certificate cain is something people get wrong all the = time.   However that is what the DN names are for.  Using = those requires validating the certs.

If you use the x5c from the JWKS is is = a simple compare of the two certs.  In principal the app doesn't = need to validate the cert using PKIX.   The security is provided by = checking the server cert protecting the JWKS endpoint and is dealt with = in TLS one hopes.

John B.

On Aug 7, 2017, at 11:38 AM, = Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

A while ago, if I'm not = mistaken, I glimpsed some report of
vulnerabilities caused by = incorrect public key comparison.

It looks like key comparison merits a section on = its own.

How about giving the AS the = option to check the signature of the
submitted client cert, which is = better supported? (but will be much more
expensive in terms of CPU time = than comparison)

If an AS registers an x5c with = the JWK, is the AS supposed to validate
the x5c signature using the JWK = public parameter? Any other checks?

Thanks,

Vladimir

On 04/08/17 23:16, John Bradley wrote:
Having the whole certificate = to compare may be easier in some environments that trying to directly = compare the public keys.

I believe most = environments make the cert from TLS available to the app comparing that = to the one retrieved from the x5c element is relatively strait = forward.

When comparing keys I worry that = that may not be that easy to get from the TLS/HTTP stack.  
Some environments will provide SPKI and others like java have = methods to directly manipulate the keys.

We = should also check on any issues with representation of EC public keys. =  
While JWA docent allow compressed points RFC 5480 = allows them in SPKI.

Of the top of my head = I don=E2=80=99t know if anyone issues certs in that format, but they = could.  

If the client receives = compressed points from SPKI and uncompressed from JWK it is possible to = compare them but I have a bad feeling people will get it wrong. =   

There is also a issue with = leading zeros that must be present in the JWK but are not in the = SPKI.

For the most part comparing the raw = keys will work with the three currently supported named curves. 
New curves = may also introduce new wrinkles.

If we were = only talking RSA I would definitely ditch x5c.

However given that a certificate of some sort must exist to = make MTLS work putting it in the x5c is not asking the world.

Getting a app to string compare two blobs = seems less likely to go wrong in deployment than asking apps to do = atleast format normalization of the public keys to compare them.

I wish it could be simpler.

John B.


On Aug 4, 2017, at 3:17 PM, Vladimir Dzhuvinov = <vladimir@connect2id.com> wrote:

What are the potential uses of the x5c parameter?

Vladimir


On 04/08/17 21:13, Brian Campbell wrote:
Just wanted to note = that, in an off-list exchange, John has pushed back on
the = idea to potentially drop mention of using x5c.

On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

Thanks = for the review, Vladimir.

The text about = which you have questions was written by Torsten (credit or
blame where it's due!) but I believe he's out of the office = for a bit so
I'll try and answer.

Your 1st question:
I've had the same thought = regarding the public key method and using the
JWK x5c = parameter. A JWK already has the public key, which is sufficient
for comparison in the public key method. So x5c is just = superfluous here. I
believe that's a change that the next = revision should have and will look to
make it unless = someone wants to make a strong case for needing x5c.

Your 2nd question:
I also found the sentence, = "When used in conjunction with a trusted X.509
certificate = source, it also allows the client to rotate its X.509
certificates without the need to change its respective = authentication data
at the authorization server." somewhat = difficult to understand when I first
read it. The intended = meaning relies on content earlier in the same
paragraph = that says, "As pre-requisite, the client registers a X.509
certificate or *a trusted source for its X.509 certificates = (jwks uri as
defined in [RFC7591])* with the authorization = server."  Basically what
it's trying to say is that = when a client is registered or configured with a
jwks_uri, = then client key rotation can be done without needing to
explicitly update the client config/registration with the AS. = Does that
explain it? I believe the text could be more = straightforward and will
endeavor to make it more clear in = the next draft update.








On Wed, Aug 2, 2017 at 1:53 AM, Vladimir = Dzhuvinov <
vladimir@connect2id.com> wrote:

Thanks everyone for the = update! Having a clear distinction between the
PKIX vs = public key bound methods will help interop, implementers' job, and
it also appears good for security.

Questions:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
03#section-2.3

where the = X.509 certificates are represented using the "x5c" parameter from = [RFC7517 <https://datatracker.ietf.org/doc/html/rfc7517<https://datatracker.ietf.org/doc/html/rfc7517>>]

For the public key method, is it really = necessary for the client to
include its certificate in the = JWK x5c parameter? This will make
implementation harder = for developers, and I'm not sure it adds anything in
terms = of security. Registering the public key parameters seems sufficient
to me.


https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls->
03#section-2.1

When = used in conjunction with a trusted X.509 certificate source, it also = allows the client to rotate its X.509 certificates without the need to = change its respective authentication data at the authorization = server.

I don't understand this - "in = conjunction with a trusted X.509
certificate source"


Thanks,

Vladimir

On 28/07/17 21:33, = Brian Campbell wrote:

A new draft of = "Mutual TLS Profile for OAuth 2.0" has been published with
the changes listed below based on comments and dissuasion in = Prague.

 draft-ietf-oauth-mtls-03<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03<= /a> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03<= /a>>> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03<= /a> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03<= /a>>>


 o =  Introduced metadata and client registration parameter to = publish
    and request support for = mutual TLS sender constrained access
    tokens
 o =  Added description of two methods of binding the cert and = client,
    PKI and Public Key.
 o  Indicated that the "tls_client_auth" = authentication method is for
    the = PKI method and introduced "pub_key_tls_client_auth" for the
    Public Key method
 o=  Added implementation considerations, mainly regarding TLS = stack
    configuration and trust = chain validation, as well as how to to do
    binding of access tokens to a TLS = client certificate for public
    clients, and considerations around = certificate bound access tokens
 o  Added new = section to security considerations on cert spoofing
 o =  Add text suggesting that a new cnf member be defined in the
    future, if hash function(s) other = than SHA-256 need to be used for
    certificate thumbprints



---------- = Forwarded message ----------
From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
Date:= Fri, Jul 28, 2017 at 12:25 PM
Subject: [OAUTH-WG] I-D = Action: draft-ietf-oauth-mtls-03.txt
To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
Cc: oauth@ietf.org <mailto:oauth@ietf.org>


A New = Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the = Web Authorization Protocol WG of the IETF.

      Title =           : Mutual TLS = Profile for OAuth 2.0
      Authors =         : Brian Campbell
          &nb= sp;            = ; John Bradley
          &nb= sp;            = ; Nat Sakimura
          &nb= sp;            = ; Torsten Lodderstedt
      Filename =        : = draft-ietf-oauth-mtls-03.txt
      Pages =           : 17
      Date =            : = 2017-07-28

Abstract:
 This= document describes Transport Layer Security (TLS) mutual
 authentication using X.509 certificates as a mechanism = for OAuth
 client authentication to the token = endpoint as well as for
 certificate bound sender = constrained access tokens.


The= IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/>=

There are also htmlized versions available = at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://dat= atracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03<https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://dat= atracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>

A diff from the previous version is available = at:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 <https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03>


Please note that it = may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.

Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>

_______________________________________________
OAuth mailing listOAuth@ietf.orghttps <mailto:listOAuth@ietf.orghttps>://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>



_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

= --Apple-Mail=_038EE4C7-6C72-4E5B-8FEA-14AE2DAA96D5-- --001a1145e77ac011f105562bd925 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEICEMTgptqfOLDf8yx7KogtZVoZ40 LyOWoVYwj2jem62pMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwNzE1NTM0MFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBJeKwMi1+ns3ysmk78nYmJfXxbHezyJ6Nr5RZ77p7K1EdW kcIPfNA5HimXS3u8VyNLXc4sXne+CXog1drHp3ZvPkxUrLd4Ds1+Gq5MBMKSjmjbfkPBNRCiJyt7 8fIErs1TtLSQhbCEKVd9kjIvA4kxjrGtPUJMdOPQgCnQpSgtrgShIItpch5XN8v9wF+vaAEY8Rw/ 20UEj/zQGZto+2sKwaOMYa5RCPxeERbi2tAHK94oN8aKkYTGm75cZaUiIbxyYvc29goNdIvGwZsd 3gK3fSzQMjjie73DqVdBOrJtFn3juguy+MRVJN9PP9ynmZMUwzJi2xRE5gcUnaXYe1Au --001a1145e77ac011f105562bd925-- From nobody Mon Aug 7 09:09:38 2017 Return-Path: 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 ED19A132643 for ; Mon, 7 Aug 2017 09:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 wKnuegbHKLVb for ; Mon, 7 Aug 2017 09:09:35 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 E92EB13263D for ; Mon, 7 Aug 2017 09:09:34 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v77G9PL4015182; Mon, 7 Aug 2017 17:09:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=bNGqGzImWVAijvyiUD3GTgnbzfPRdgL1/hmlHsmRMTo=; b=RT+AJ+r5RMfeDREygOuNCNlpSk7GSbHKdc+M7cV+qnN9oZqa9qkaDgS1X+Hm65ZkB7qn wWIF2pC9zgqAehC/vLwMLyB4C1Sca/M8zoZTCIJdVNO6NAqFMIN+KA5yIejMj46oy7P3 a3cVqUNod/5jC2Z8hSkozbXvHxqAnY7jr6lKnLJw9ziWFkvpSI7rQKwI3alm7VP35Ez5 Ny6OzSTo+vhmPaUZmUYZDh/S2OZJNl0SAuNJaIgUWqN87PEzlXCXmh3vPyV8IA4SK231 CTJ6kcsA50F+BlMPOOwWsOx0LotNzHUSsFAh+gLhRAr/2PAIbXvDwu1jPNSJ/QBOingG Ag== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2c559rukwj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2017 17:09:29 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v77G32Em026187; Mon, 7 Aug 2017 12:09:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2c59bu7dct-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2017 12:09:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 12:09:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 7 Aug 2017 12:09:13 -0400 From: "Salz, Rich" To: Vladimir Dzhuvinov , John Bradley CC: oauth Thread-Topic: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt Thread-Index: AQHTC2SNRGpjcAji5k6h3+CdDiAo06JxdKYAgANSQgCAABIDAIAAEHAAgARpeoD//8UiIA== Date: Mon, 7 Aug 2017 16:09:13 +0000 Message-ID: References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> <7EBDF15A-E2A7-4409-B2E8-01AF37D1C274@ve7jtb.com> <6d150831-ab97-09eb-199c-65eb9e0457c7@connect2id.com> In-Reply-To: <6d150831-ab97-09eb-199c-65eb9e0457c7@connect2id.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708070267 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708070267 Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:09:36 -0000 PiBBIHdoaWxlIGFnbywgaWYgSSdtIG5vdCBtaXN0YWtlbiwgSSBnbGltcHNlZCBzb21lIHJlcG9y dCBvZiB2dWxuZXJhYmlsaXRpZXMNCj4gY2F1c2VkIGJ5IGluY29ycmVjdCBwdWJsaWMga2V5IGNv bXBhcmlzb24uDQoNClRoZXJlIHdhcyBhIHJlY2VudCBpc3N1ZSByYWlzZWQgYnkgSGFubm8gYWJv dXQgaW5jb3JyZWN0IHB1YmxpYy9wcml2YXRlIGtleSBtYXRjaGluZyBsZWFkaW5nIHRvIGluY29y cmVjdCByZXZvY2F0aW9uIG9mIGEgY2VydGlmaWNhdGU7IHdhcyB0aGF0IHdoYXQgeW91IHdlcmUg dGhpbmtpbmcgb2Y/DQo= From nobody Mon Aug 7 09:28:46 2017 Return-Path: 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 9E6841321E6 for ; Mon, 7 Aug 2017 09:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 fTXyrZgxS3wE for ; Mon, 7 Aug 2017 09:28:42 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 AE0B7132598 for ; Mon, 7 Aug 2017 09:28:40 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id p3so5660120qtg.2 for ; Mon, 07 Aug 2017 09:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=aVsC3Lv0G2n7pa+blD0jeW1lPcp9w2hP25no1o1Qo60=; b=b9qszKqS0qTKmyJq1OsiKdXrIpkwJ7qd5A7A60lpqw/KMcNpYTzG+cVwog/NOWYr3g DidKPakwd6MXNLFey2mEQEjKmXX1ORfdssC6HRVel/GKI6qWj9eW1/RsLlvsm2mVUVrB XN7m8HUfxrP0u1+ka23MyYUOOSLr5u3gf3GRU2DHm7dmNy3vfDDmyiaCn0AeLlj3AltM 8pp7hoGJbdu7QL7BPewWzQ74vdwiTLDzXD3ynqwpyRJUc/OadrextkLu+c3HGZR/sEw2 h2rOrdRDskeMczZALZMmKeolbU39ENlqcaeIrCi3N/NBcruFWYdJjegvhmoXfopMTEIJ UKxA== 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 :message-id:references:to; bh=aVsC3Lv0G2n7pa+blD0jeW1lPcp9w2hP25no1o1Qo60=; b=qNqYc1+sXT92XksIBsLYw9deZ7flo7dKqcwnHdqBVWOMMfXMN/YMXi21HhzWmaAk8b cPRKyfz8bJ332Qx2wohBnDVhulpWD1hvg7eA2+eyG3vNWh2E1+bIVBM8WeskUxrHcqWx pJP0OIHe+KF7BQfnPMW6JB0qTAbUXc9X+M4EoxKLGJbiX9O9WgNgKa34xLWCT4tdWxbh mrvWlD/DjHvZXm89O5Xd/xhyNF7k8kVhUuYqu3AJP5FrGup2DAILFIPVlyqNhyHn/6YH ghHVM641UqVYMRxkIUsCzxl55dCMPBuCK42s+WFYG5TL0KcpoM2SSsekMwK5YafMTWJB VRQQ== X-Gm-Message-State: AHYfb5go+DOZjv1PiJsHUecmB02ihVz/lQ1kaFRoZC94UBBG0502bxwY xT7xe57C1wRdaDLbsWuxqg== X-Received: by 10.200.57.36 with SMTP id s33mr1534141qtb.302.1502123319512; Mon, 07 Aug 2017 09:28:39 -0700 (PDT) Received: from johns-mbp.lan ([191.115.204.25]) by smtp.gmail.com with ESMTPSA id f20sm5280881qke.55.2017.08.07.09.28.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 09:28:38 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: John Bradley In-Reply-To: Date: Mon, 7 Aug 2017 12:28:32 -0400 Cc: oauth Message-Id: <5CB52046-8233-4684-961B-C49C6F042F40@ve7jtb.com> References: To: Vladimir Dzhuvinov X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113e6030e451a605562c5671" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03 - auth to other endpoints? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:28:46 -0000 --001a113e6030e451a605562c5671 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Good point, I don=E2=80=99t think we intended it to be exclusive to the = token endpoint. It is another client auth method and should work those = other places as well. I will need to look at the other specs to see = how they incorporate client auth methods. Thanks John B. > On Aug 7, 2017, at 11:17 AM, Vladimir Dzhuvinov = wrote: >=20 > I just noticed that the spec is very explicit on the MTLS auth method > being used for the token endpoint, but it could also work with other > endpoints, e.g. RFC 7009 (revocation), 7662 (intospection). >=20 > Were there any talks about that? >=20 > Vladimir >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --001a113e6030e451a605562c5671 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIMRIxpeYF3FJoJ0UgXtykkddjPAZ UPmS34OJJQ6yYSgWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwNzE2MjgzOVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBRCTrg6QMwdRvDiJWtvoP8UQxwwlZYyT2y9uB4RPO1C/9i jut+xmsigQ6ljB4vTCZNqtjMU9W7EnAgkKjk5QrjxH0BTl2y+/mUhVHN0kbdK6U6z6y7IQE1+LLY WSM6pck+y5f7KFZOnPAujsd+Gmq2Y9FMW7gDhYMkI5ul4o9OZ9nFngn4mUVt3mhPZNL4srbJi8ZJ zhEmP+0J0m3PirdQeMwn1INV+1F4WFTbj3JW58Cgx9AFWVTUVlhD5xCCkSjHG9CdJ2YLCXIA2w+/ ZHE/PXLQmj5KB8UJYq8Wt3zZnKbL3Hx1vwfGq/uwo9u7UBChyeKDc3Hzg8LAJ30VuDMc --001a113e6030e451a605562c5671-- From nobody Mon Aug 7 09:40:02 2017 Return-Path: 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 0B9C0132631 for ; Mon, 7 Aug 2017 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 CE0mQyg4tfRK for ; Mon, 7 Aug 2017 09:39:57 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 699EF13262F for ; Mon, 7 Aug 2017 09:39:57 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id p3so5841254qtg.2 for ; Mon, 07 Aug 2017 09:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KDJMX1vUPC3PuE1Wk8E+g4T9FtlKXzHOzRBCpchXVL8=; b=o1qYHB82PQmMxlhdhYxbXs7OdR/5Lx9j4y9vdiDTYM4uFrwBmrmjxAacvbaMNcH5cb 7scvXykgKT/4yvmzS6TsRbBaTXhAZgmUBvZktRldfUusfGhwnp5LoChVXn8Dilw41oi6 plKXrNRrt+6FR8NH0XRaLlSxk+lMxZgiu4NTr34l9O9g+YR25mLRr3VcACyQmqnFXJ2i nEBxWND6QC1Z/TiN2WhuDq7xBscC2KarWrIjEGq4dKmTiJICj2XScP+A0vIJMNYv9a5i u39x3MNnELq57HxdhkvCsdcWPYfAlf44/PpG7vWV8doG2PXETzv4e0YEQNq4uhFHBCrQ YfVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KDJMX1vUPC3PuE1Wk8E+g4T9FtlKXzHOzRBCpchXVL8=; b=L0dLzPS6zoPgJfPTa2RVHBiKENR8/TiLkzFskmxpUyox1ifcfFWFMF9pXO0ABEHtKd ny/AKq8k+4WNoaXSxB/xMktQv0JqQUt128T23+APsaMH04WHSiPAujWK+vuHFciyg3dg dk6Oscs4y7Weu6LjTkw3pMe6fpbq8Q+4OSDG1yNbrLEehU/w7Q6o1s8XxdynA0wyaDet enode8FaKm0fqxbtbnGW72IkuvamoXXwYauQVwFh0ob2ds/ZW1do40tfg8DPIMPL0RAh yXJKvfSE8Dd6cHgWa1Dw/Cp7MohCwu79VRPjeVwNnk0vGN28VnzubOQFalEePnkPlYG1 Ua+A== X-Gm-Message-State: AHYfb5jKJtT/tT3r5SUNOm+8Hhu/1CsS1CDSpy9TY3za1JiVFpHHGDSe dFoLAZv2ZIdUk4kZmWet5w== X-Received: by 10.200.38.155 with SMTP id 27mr1748817qto.228.1502123996319; Mon, 07 Aug 2017 09:39:56 -0700 (PDT) Received: from johns-mbp.lan ([191.115.204.25]) by smtp.gmail.com with ESMTPSA id q15sm5512640qkl.26.2017.08.07.09.39.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 09:39:55 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 Aug 2017 12:39:50 -0400 In-Reply-To: Cc: oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11404c843b3f2d05562c7f76" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:40:00 -0000 --001a11404c843b3f2d05562c7f76 Content-Type: multipart/alternative; boundary="Apple-Mail=_3E6F44FF-2A20-4E04-ACE7-2D2852E199B2" --Apple-Mail=_3E6F44FF-2A20-4E04-ACE7-2D2852E199B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is being rolled in to the broader security documents Torsten and = others have been working on. It wouldn=E2=80=99t hurt to update this draft to have the correct = referrer policy. Even if it is not progressing, people will still look = at it. I will refresh the draft with the change. Thanks, John B. > On Aug 2, 2017, at 6:46 PM, Brian Campbell = wrote: >=20 > Not sure of the status at this point (it is expired) but the = draft-ietf-oauth-closing-redirectors WG document in = https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#sectio= n-2.3 = suggests using the Content Security Policy header to limit the = information sent in the referer something like this:=20 >=20 > Content-Security-Policy: referrer origin; >=20 > Consistent with the latest draft of = https://w3c.github.io/webappsec-referrer-policy/ = and according to = Mozilla (see = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security= -Policy/referrer = ) the Content-Security-Policy (CSP) referrer directive = is obsolete and deprecated. And it looks like Referrer-Policy should be = used instead for that purpose (again see Mozilla: = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy = ). So the draft-ietf-oauth-closing-redirectors document should probably = suggest the Referrer-Policy something more like this: >=20 > Referrer-Policy: strict-origin=20 >=20 >=20 >=20 > 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 --Apple-Mail=_3E6F44FF-2A20-4E04-ACE7-2D2852E199B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This is being rolled in to the broader security documents = Torsten and others have been working on.

It wouldn=E2=80=99t hurt to update this = draft to have the correct referrer policy. Even if it is not = progressing, people will still look at it.

I will refresh the draft with the = change.

Thanks,

John B.

On = Aug 2, 2017, at 6:46 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Not sure of the status at this point (it is = expired) but the draft-ietf-oauth-closing-redirectors WG document in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirector= s-00#section-2.3 suggests using the Content Security Policy header = to limit the information sent in the referer something like this:

  Content-Security-Policy: referrer = origin;

Consistent with the latest draft of = https://w3c.github.io/webappsec-referrer-policy/ and according to Mozilla (see = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/referrer) the Content-Security-Policy (CSP) referrer directive is obsolete and =20= deprecated. And it looks like Referrer-Policy should be used instead for that purpose (again see Mozilla: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy). So the = draft-ietf-oauth-closing-redirectors document should probably suggest = the Referrer-Policy something more like this:

   Referrer-Policy: strict-origin



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

= --Apple-Mail=_3E6F44FF-2A20-4E04-ACE7-2D2852E199B2-- --001a11404c843b3f2d05562c7f76 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIJ57fVrBBajO5I2+d+Kg6nwqs45w kc/qnSydNd/RwRElMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwNzE2Mzk1NlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQDLP+bnWbpPlwU1bSvRqBWsTqpHleR19uvFCmVbei3syFHh IRTD2reKOtIVzVfHZM7vGzOMH6pzBs/NLHUS+RbedSh6B+VU4UDoh/Fwu1LcJGD/nz/leZC3Sv6b 1sTM9b03eut9t+aIThS7cxQdogA0pMwQUUjCwZpOeTNdPMmqEbJjKXkD+qHdcdYeydiaOZG1aWB0 G9PephVOK2RPExQp5+g+VXigF+QwgBIhIwMEiZxmJjbGy3WjRmYx4JuBVCAaGINK0JagIubBCdl8 syCeTDcykSwzHVEp4p7Wf8jEkbhMWPmpKTBUwYP+2iliTzHBmtiZf9xXvX2+rz6rHiM1 --001a11404c843b3f2d05562c7f76-- From nobody Mon Aug 7 11:40:33 2017 Return-Path: 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 3FD01132455 for ; Mon, 7 Aug 2017 11:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 fKOe0UVoL1TY for ; Mon, 7 Aug 2017 11:40:29 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 B93661324AD for ; Mon, 7 Aug 2017 11:40:28 -0700 (PDT) X-AuditID: 12074423-98dff70000002362-16-5988b41bb925 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id F9.42.09058.B14B8895; Mon, 7 Aug 2017 14:40:27 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v77IeQgS000974; Mon, 7 Aug 2017 14:40:26 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v77IeOns025907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Aug 2017 14:40:25 -0400 From: Justin Richer Message-Id: <0B89EDED-DD66-42A0-A294-471B9EF2D522@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_10D20C43-D3F1-4FA7-9AF0-C73BB0F2418A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 Aug 2017 14:40:23 -0400 In-Reply-To: Cc: "" To: Brian Campbell References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixCmqrCu9pSPSYF23hMXq/zcZLU6+fcXm wOSxZMlPJo+7Ry+yBDBFcdmkpOZklqUW6dslcGUc2fWDueDpdKaKWasvMDYw9r9l7GLk5JAQ MJE4Mu0IcxcjF4eQwGImialr+tkhnA2MEgebPrBAOA+YJFZt+s4O0sImoCoxfU0LE4jNK2Al 8W/mSzYQm1kgSaJ911SgBg6guL5E73OwDcICDhLXZp0FK2cRUJH4suA6WDmnQKDE3Nb9YOXM AuoS7SddQMIiQJ23n86BuqGJSWLv1cksEJfKStyafYl5AiP/LCTbZiFsgwhrSyxb+JoZwtaU 2N+9nAVTXEOi89tE1gWMbKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCQpvd RXkH48s+70OMAhyMSjy8DJkdkUKsiWXFlbmHGCU5mJREeeNXtEUK8SXlp1RmJBZnxBeV5qQW H2KU4GBWEuFV2wRUzpuSWFmVWpQPk5LmYFES5xXXaIwQEkhPLEnNTk0tSC2CycpwcChJ8PJv BmoULEpNT61Iy8wpQUgzcXCCDOcBGq4EUsNbXJCYW5yZDpE/xWjJ8WrC/29MHId+n/jOxHEM RAqx5OXnpUqJ824BuUYApCGjNA9uJihVJbw9bPqKURzoRWFeTpCxPMA0Bzf1FdBCJqCFbxJb QRaWJCKkpBoYJ04MNd+90/79kvLU94U8641UZ8+tnx2qyq9Xcf1Sy2/7zFPPLp2LWFR8o9t0 QW1Zx5QTievO2h2OdBdLOKIUIrW/bO/FO3nb90b6K/Nmh8//8c3SR0i74Hda3/WIoueNb60O XSt/WXwmqqndILlapOpjfsDnRTf0pPdIvFm+UVFd7GHQI0FPJZbijERDLeai4kQAu1hB+jAD AAA= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 18:40:32 -0000 --Apple-Mail=_10D20C43-D3F1-4FA7-9AF0-C73BB0F2418A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the explanation, Brian. I think the draft=E2=80=99s current = structure helped me to erroneously conflate the two aspects of the = document =E2=80=94 in that it sounded like mTLS client authentication = was required for an mTLS-bound (or really, certificate-bound) token. I = see now that this isn=E2=80=99t the case, and the hashing approach makes = more sense to me. Having the text separate these more clearly and = stating that you don=E2=80=99t need the one to do the other (but it = helps) would be a good move. I could see that the document was already = trying to separate the two aspects of the spec, but I think it=E2=80=99s = not quite there yet. =E2=80=94 Justin > On Aug 1, 2017, at 3:57 PM, Brian Campbell = wrote: >=20 > Thanks Justin.=20 >=20 > In my original announcement email, I should have given credit to = Torsten as he made many of the updates in -03. So complements on = improvements as well as blame for issues can be pointed to him as well! >=20 > Your point about document structure is taken and we will look to make = the separation of the client authentication and resource access more = clear in future revisions. The document was aiming for something = conceptually along those same lines already. But it could be made more = clear. >=20 > This could define a new =E2=80=9Ctoken_type=E2=80=9D but other than = having different token type names in messages, I don't know that a new = token_type or HTTP auth scheme that would probably have to come along = with it adds value to the use cases here. However, they would very = likely make deployment of this stuff much more cumbersome and take = longer. Whereas many systems can likely plug in mutual TLS on top of = the existing token_type and HTTP auth scheme without major changes. I'm = strongly inclined to not introduce a new token_type and more inclined to = not do a new HTTP auth scheme.=20 >=20 > Fair point about breaking out all the registered parameters into their = own hanging list items. It is somewhat inconsistent in that regard now. = Will look to address that in a future revision. >=20 > Using just a certificate hash for mTLS sender constrained access = tokens was intentional to allow mTLS at the resource to be used as a = proof-of-possession method only. It's part of the authorization check at = resource access and deliberately not about authentication with the RS. = Using the hash simplifies the check at the RS to one consistent way of = doing things while allowing for different modes of doing client = authentication at the AS. So the lack of parallelism with the client = authentication at the token endpoint was very much intentional. = Following from that, the need to do mTLS at the token endpoint in order = to get mTLS-bound access tokens for an RS was also kind of intentional. = Though, as =C2=A74.3 = = attempts to describe, a public client could do mTLS at the token = endpoint with a generated self-singed cert to have an access token bound = but not actually authenticate to the token endpoint. You are certainly = right that there are other ways an AS could decide on the certificate to = bind the access token to. And other ways a cnf claim member could = provide for such a binding. But we were aiming to not provide too many = options in the doc. So my thinking here was that this draft is about = mTLS and so saying how to use mTLS for the AS to do the access token = binding seemed like the most appropriate and straightforward approach. = It's not so much that mTLS authentication is needed for the client at = the token endpoint to allow for bound access tokens. But rather that = having mTLS at the token endpoint provides a strong signal of the = certificate to which to bind the issued access token.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer > wrote: > Brian, thanks for the update. This is really coming along! >=20 > I think the spec would benefit from a more clear separation of the = client authentication and resource access sections. They=E2=80=99re = really almost two different but related specs, but there=E2=80=99s = enough overlap that I think that keeping them in the same document is = fine with some structural changes applied. I think the content is by and = large all here, it=E2=80=99s just jumbled together. >=20 > To that end, I think there might be three major sections to this = document (not counting the IANA, security, privacy, and other = boilerplate bits). A suggested breakdown: >=20 > 1) Types of mTLS client auth under consideration. This is where the = definition of public key vs. pki comes in, and where the two = authentication methods are defined for both registration and discovery. = Some implementor=E2=80=99s notes on what kinds of things you need to = store here, including the tls_client_auth_ client metadata extensions. = For better or worse, 7591 defines OAuth=E2=80=99s client model, and not = just for dynamic registration. >=20 > 2) How to use mTLS to authenticate a client. This can be a relatively = short section that says use (1) in the context of getting an access = token at the token endpoint. Here is where you point out that you still = need to send client_id and that the association with the cert=E2=80=99s = DN and the client_id is done at the AS (there=E2=80=99s existing text = for this). >=20 > 3) How to use mTLS to bind an access token. This is a bit more = complicated because it=E2=80=99s the RS that needs to know the binding = between the token and the cert=E2=80=99s DN, so that=E2=80=99s where = you=E2=80=99d define the =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate = side effect of spec history means that the =E2=80=9Ccnf=E2=80=9D claim = for 7662 also gets defined here. This is also where you=E2=80=99d put = the bits about mutual_tls_sender_constrained_access_tokens for discovery = and registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D? > =20 >=20 > A few more comments: >=20 > =C2=A72.3 really should break out all registered parameters into their = own hanging list items (even if you break them up into different = sections like suggested above) >=20 > =C2=A73 seems to say that you can only do mTLS-bound access tokens at = an RS if you do mTLS authentication at the token endpoint. Is that an = intentional restriction? To me these two functions seem to be more = orthogonal than the spec is hinting at. Like, I could use = private_key_jwt or PKCE or magic to authenticate at the RS but use mTLS = at the RS, for whatever esoteric reason, like the AS and RS being in = different security domains. Still, functionally, if the client=E2=80=99s = registered parameters are enough to trust for token issuance, they = should be enough to trust for token usage. In other words, have the RS = depend on tls_client_auth_subject_dn etc. instead of "the same = certificate that was used for mutual TLS at the token endpoint".=20 >=20 > Along those lines, =C2=A73 also depends entirely on matching a = specific certificate hash instead of validating a certificate (and = possibly it=E2=80=99s chain) and associated DN. This isn=E2=80=99t in = parallel with the client authentication at the token endpoint, and I=E2=80= =99d like to see these come together. Should we have a third certificate = validation method in =C2=A72 for =E2=80=9Ccertificate hash=E2=80=9D? Or = maybe we should have a separate list for = =E2=80=9Cresource_server_auth_method=E2=80=9D for the client? >=20 > In any event, it still feels like there are two things that are = fighting for attention in this spec: cert-based authentication of the = client at the token endpoint, and cert-based PoP of the token at the = resource. >=20 > =E2=80=94 Justin >=20 >> On Jul 28, 2017, at 2:33 PM, Brian Campbell = > wrote: >>=20 >> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published = with the changes listed below based on comments and dissuasion in = Prague.=20 >>=20 >> draft-ietf-oauth-mtls-03 = >>=20 >> o Introduced metadata and client registration parameter to = publish >> and request support for mutual TLS sender constrained access >> tokens >> o Added description of two methods of binding the cert and = client, >> PKI and Public Key. >> o Indicated that the "tls_client_auth" authentication method is = for >> the PKI method and introduced "pub_key_tls_client_auth" for the >> Public Key method >> o Added implementation considerations, mainly regarding TLS stack >> configuration and trust chain validation, as well as how to to = do >> binding of access tokens to a TLS client certificate for public >> clients, and considerations around certificate bound access = tokens >> o Added new section to security considerations on cert spoofing >> o Add text suggesting that a new cnf member be defined in the >> future, if hash function(s) other than SHA-256 need to be used = for >> certificate thumbprints >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: > >> Date: Fri, Jul 28, 2017 at 12:25 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >>=20 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Web Authorization Protocol WG of the = IETF. >>=20 >> Title : Mutual TLS Profile for OAuth 2.0 >> Authors : Brian Campbell >> John Bradley >> Nat Sakimura >> Torsten Lodderstedt >> Filename : draft-ietf-oauth-mtls-03.txt >> Pages : 17 >> Date : 2017-07-28 >>=20 >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for OAuth >> client authentication to the token endpoint as well as for >> certificate bound sender constrained access tokens. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 = >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 = >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 = >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> 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 = >=20 >=20 >=20 > 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. --Apple-Mail=_10D20C43-D3F1-4FA7-9AF0-C73BB0F2418A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the explanation, Brian. I think the draft=E2=80=99s = current structure helped me to erroneously conflate the two aspects of = the document =E2=80=94 in that it sounded like mTLS client = authentication was required for an mTLS-bound (or really, = certificate-bound) token. I see now that this isn=E2=80=99t the case, = and the hashing approach makes more sense to me. Having the text = separate these more clearly and stating that you don=E2=80=99t need the = one to do the other (but it helps) would be a good move. I could see = that the document was already trying to separate the two aspects of the = spec, but I think it=E2=80=99s not quite there yet.

 =E2=80=94 = Justin

On Aug 1, 2017, at 3:57 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Thanks = Justin. 

In my original announcement email, I should = have given credit to Torsten as he made many of the updates in -03. So = complements on improvements as well as blame for issues can be pointed = to him as well!

Your point about = document structure is taken and we will look to make the separation of = the client authentication and resource access more clear in future = revisions. The document was aiming for something conceptually along = those same lines already. But it could be made more clear.

This could define a new = =E2=80=9Ctoken_type=E2=80=9D but other than having different token type = names in messages, I don't know that a new token_type or HTTP auth = scheme that would probably have to come along with it adds value to the = use cases here. However, they would very likely make deployment of this = stuff much more cumbersome and take longer.  Whereas many systems = can likely plug in mutual TLS on top of the existing token_type and HTTP = auth scheme without major changes. I'm strongly inclined to not = introduce a new token_type and more inclined to not do a new HTTP auth = scheme. 

Fair point about = breaking out all the registered parameters into their own hanging list = items. It is somewhat inconsistent in that regard now. Will look to = address that in a future revision.

Using just a certificate hash for mTLS sender = constrained access tokens was intentional to allow mTLS at the resource = to be used as a proof-of-possession method only. It's part of the = authorization check at resource access and deliberately not about = authentication with the RS. Using the hash simplifies the check at the = RS to one consistent way of doing things while allowing for different = modes of doing client authentication at the AS. So the lack of = parallelism with the client authentication at the token endpoint was = very much intentional. Following from that, the need to do mTLS at the = token endpoint in order to get mTLS-bound access tokens for an RS was = also kind of intentional. Though, as =C2=A74.3 attempts to describe, a = public client could do mTLS at the token endpoint with a generated = self-singed cert to have an access token bound but not actually = authenticate to the token endpoint. You are certainly right that there = are other ways an AS could decide on the certificate to bind the access = token to. And other ways a cnf claim member could provide for such a = binding. But we were aiming to not provide too many options in the doc. = So my thinking here was that this draft is about mTLS and so saying how = to use mTLS for the AS to do the access token binding seemed like the = most appropriate and straightforward approach. It's not so much that = mTLS authentication is needed for the client at the token endpoint to = allow for bound access tokens. But rather that having mTLS at the token = endpoint provides a strong signal of the certificate to which to bind = the issued access token. 







On Mon, Jul 31, 2017 at = 2:18 PM, Justin Richer <jricher@mit.edu> wrote:
Brian, thanks for the update. This is really coming = along!

I think the = spec would benefit from a more clear separation of the client = authentication and resource access sections. They=E2=80=99re really = almost two different but related specs, but there=E2=80=99s enough = overlap that I think that keeping them in the same document is fine with = some structural changes applied. I think the content is by and large all = here, it=E2=80=99s just jumbled together.

To that end, I think there might be = three major sections to this document (not counting the IANA, security, = privacy, and other boilerplate bits). A suggested breakdown:

1) Types of mTLS client = auth under consideration. This is where the definition of public key vs. = pki comes in, and where the two authentication methods are defined for = both registration and discovery. Some implementor=E2=80=99s notes on = what kinds of things you need to store here, including the = tls_client_auth_ client metadata extensions. For better or worse, 7591 = defines OAuth=E2=80=99s client model, and not just for dynamic = registration.

2)= How to use mTLS to authenticate a client. This can be a relatively = short section that says use (1) in the context of getting an access = token at the token endpoint. Here is where you point out that you still = need to send client_id and that the association with the cert=E2=80=99s = DN and the client_id is done at the AS (there=E2=80=99s existing text = for this).

3) = How to use mTLS to bind an access token. This is a bit more complicated = because it=E2=80=99s the RS that needs to know the binding between the = token and the cert=E2=80=99s DN, so that=E2=80=99s where you=E2=80=99d = define the =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate side effect of = spec history means that the =E2=80=9Ccnf=E2=80=9D claim for 7662 also = gets defined here. This is also where you=E2=80=99d put the bits about = mutual_tls_sender_constrained_access_tokens for = discovery and registration. Should this be a new =E2=80=9Ctoken_type=E2=80= =9D?
 

A few more comments:

=C2=A72.3 really should break out all = registered parameters into their own hanging list items (even if you = break them up into different sections like suggested above)

=C2=A73 seems to say = that you can only do mTLS-bound access tokens at an RS if you do mTLS = authentication at the token endpoint. Is that an intentional = restriction? To me these two functions seem to be more orthogonal than = the spec is hinting at. Like, I could use private_key_jwt or PKCE or = magic to authenticate at the RS but use mTLS at the RS, for whatever = esoteric reason, like the AS and RS being in different security domains. = Still, functionally, if the client=E2=80=99s registered parameters are = enough to trust for token issuance, they should be enough to trust for = token usage. In other words, have the RS depend on = tls_client_auth_subject_dn etc. instead of "the same certificate that = was used for mutual TLS at the token endpoint". 

Along those lines, =C2=A73= also depends entirely on matching a specific certificate hash instead = of validating a certificate (and possibly it=E2=80=99s chain) and = associated DN. This isn=E2=80=99t in parallel with the client = authentication at the token endpoint, and I=E2=80=99d like to see these = come together. Should we have a third certificate validation method in = =C2=A72 for =E2=80=9Ccertificate hash=E2=80=9D? Or maybe we should have = a separate list for =E2=80=9Cresource_server_auth_method=E2=80=9D for = the client?

In = any event, it still feels like there are two things that are fighting = for attention in this spec: cert-based authentication of the client at = the token endpoint, and cert-based PoP of the token at the = resource.

 =E2=80=94 Justin
On Jul 28, = 2017, at 2:33 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

A= new draft of "Mutual TLS Profile for OAuth 2.0" has been published with = the changes listed below based on comments and dissuasion in = Prague. 

   draft-ietf-oauth-mtls-03

   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method is for
      the PKI method and introduced "pub_key_tls_client_auth" for the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: = Fri, Jul 28, 2017 at 12:25 PM
Subject: [OAUTH-WG] I-D = Action: draft-ietf-oauth-mtls-03.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work = item of the Web Authorization Protocol WG of the IETF.

        Title        =    : Mutual TLS Profile for OAuth 2.0
  =       Authors         : Brian = Campbell
              =             John Bradley
                =           Nat Sakimura
  =                     =     Torsten Lodderstedt
      =   Filename        : = draft-ietf-oauth-mtls-03.txt
        = Pages           : 17
  =       Date            : = 2017-07-28

Abstract:
  =  This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a = mechanism for OAuth
   client authentication to = the token endpoint as well as for
   certificate = bound sender constrained access tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03


Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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



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.

= --Apple-Mail=_10D20C43-D3F1-4FA7-9AF0-C73BB0F2418A-- From nobody Tue Aug 8 01:15:20 2017 Return-Path: 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 4D1261320CC for ; Tue, 8 Aug 2017 01:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 3ve6AjDXN1Mv for ; Tue, 8 Aug 2017 01:15:16 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5699A1320BE for ; Tue, 8 Aug 2017 01:15:14 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 8 Aug 2017 10:15:09 +0200 Received: from MBX116.d.ethz.ch ([fe80::7118:3565:54c4:260e]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0361.001; Tue, 8 Aug 2017 10:15:11 +0200 From: "Hammann Sven" To: Torsten Lodderstedt , John Bradley CC: oauth Thread-Topic: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ? Thread-Index: AQHTCc6UbmrJK1IDo0eFm7woIaTdJ6Jt1cKAgASSvYCAB8CHAw== Date: Tue, 8 Aug 2017 08:15:10 +0000 Message-ID: <29A97C2C05BF2C448F6970FFCAEA85C0022E199B@MBX116.d.ethz.ch> References: <46E8AB48-2DD1-4C1C-B8FA-0FBADAB7596F@ve7jtb.com>, <1321FC7E-EA45-4181-BC8F-90086FCA7180@lodderstedt.net> In-Reply-To: <1321FC7E-EA45-4181-BC8F-90086FCA7180@lodderstedt.net> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.133.90] Content-Type: multipart/alternative; boundary="_000_29A97C2C05BF2C448F6970FFCAEA85C0022E199BMBX116dethzch_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 08:15:18 -0000 --_000_29A97C2C05BF2C448F6970FFCAEA85C0022E199BMBX116dethzch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I would like to clarify and agree with John Bradley that there is a confusi= on here. In the setting that I was discussing in my presentation, I was looking at O= penID Connect, where we have: An end-user with his user agent (browser) that wishes to log in at an RP se= rvice (and this is what is called client here), using an IdP (or also calle= d OpenID Provider / OP). My concern was about the privacy of the end-user towards the IdP. In the cu= rrent standard, the client_id identifying the RP is sent to the IdP (and pu= t into the "aud" field of the id_token), so the IdP learns at which RP the = end-user wishes to log in with the id_token. --- Denis is describing an OAuth setting with an RP (client) that obtains an ac= cess token from an AS (Authorization Server), and wishes to use this at one= of several resource servers (RS). His concern is about the privacy of the RP (client) towards the AS, since w= ith an "aud" field in the access token, the AS learns at which RS the RP (c= lient) wishes to use the access token. =3D=3D> These are two different scenarios, and separate privacy concerns. I underst= and from John Bradley's comments and Torsten's +1 that you are doubtful if = the second scenario raised by Denis is an actual privacy concern. Thus, I would like to keep these two scenarios separate. There are outstanding issues with my solution to the first scenario, two of= which are: - If we cannot have pairwise subject identifiers when masking the client_id= (RP identifier), we would have a privacy trade-off here - Requesting different scopes (attributes) could potentially allow the IdP = to identify the RP based on these requests If there is still interest in solving the first scenario (IdP does not lear= n RP's identity in OIDC), I may be able to come up with some ideas to solve= these outstanding problems. Kind Regards, Sven ________________________________ From: OAuth [oauth-bounces@ietf.org] on behalf of Torsten Lodderstedt [tors= ten@lodderstedt.net] Sent: Thursday, August 03, 2017 1:51 PM To: John Bradley Cc: oauth Subject: Re: [OAUTH-WG] How could an IdP create an id token for one audienc= e RP without knowing for which RP ? +1 Am 31.07.2017 um 16:01 schrieb John Bradley >: For access tokens I would like to see a use case for a completely =3D decoupled and anonymous RS that is not just a misuse of OAuth for =3D Authentication, before trying to add a feature like this. --_000_29A97C2C05BF2C448F6970FFCAEA85C0022E199BMBX116dethzch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,


I would like to clarify and agree w= ith John Bradley that there is a confusion here.


In the setting that I was discussin= g in my presentation, I was looking at OpenID Connect, where we have:


An end-user with his user agent (br= owser) that wishes to log in at an RP service (and this is what is called c= lient here), using an IdP (or also called OpenID Provider / OP).


My concern was about the privacy of= the end-user towards the IdP. In the current standard, the client_id ident= ifying the RP is sent to the IdP (and put into the "aud" field of the id_token), so the IdP learns at whic= h RP the end-user wishes to log in with the id_token.<= /p>


---


Denis is describing an OAuth settin= g with an RP (client) that obtains an access token from an AS (Authorizatio= n Server), and wishes to use this at one of several resource servers (RS).


His concern is about the privac= y of the RP (client) towards the AS, since with an "aud" field in the access token, the AS learns at which RS th= e RP (client) wishes to use the access token.


=3D=3D>


These are two different scenarios, = and separate privacy concerns. I understand from John Bradley's comments an= d Torsten's +1 that you are doubtful if the second scenario raised by Denis is an actual privacy concern.


Thus, I would like to keep th= ese two scenarios separate.


There are outstanding issues with m= y solution to the first scenario, two of which are:

- If we cannot have pairwise subjec= t identifiers when masking the client_id (RP identifier), we would have a p= rivacy trade-off here

- Requesting different scopes= (attributes) could potentially allow the IdP to identify the RP based on t= hese requests


If there is still interest in solvi= ng the first scenario (IdP does not learn RP's identity in OIDC), I may be = able to come up with some ideas to solve these outstanding problems.


Kind Regards,<= /p>

Sven

From: OAuth [oauth-bounces@ietf.org] on b= ehalf of Torsten Lodderstedt [torsten@lodderstedt.net]
Sent: Thursday, August 03, 2017 1:51 PM
To: John Bradley
Cc: oauth
Subject: Re: [OAUTH-WG] How could an IdP create an id token for one = audience RP without knowing for which RP ?

--_000_29A97C2C05BF2C448F6970FFCAEA85C0022E199BMBX116dethzch_-- From nobody Tue Aug 8 12:42:46 2017 Return-Path: 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 C86731326A7 for ; Tue, 8 Aug 2017 12:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no 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 sIF__vQcbjN1 for ; Tue, 8 Aug 2017 12:42:43 -0700 (PDT) Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) (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 727441326A5 for ; Tue, 8 Aug 2017 12:42:43 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id fAOIdwllOuvgdfAOJdeJA9; Tue, 08 Aug 2017 12:42:12 -0700 To: "Salz, Rich" Cc: oauth References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> <7EBDF15A-E2A7-4409-B2E8-01AF37D1C274@ve7jtb.com> <6d150831-ab97-09eb-199c-65eb9e0457c7@connect2id.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <43ea805b-9366-fbb1-6464-d2bb962e1b1a@connect2id.com> Date: Tue, 8 Aug 2017 22:42:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000206030801000604000700" X-CMAE-Envelope: MS4wfIFTnq66gQAMY0gXOXZhpCl1nlSyEpBEM59Ewe/F5W0cBT3CBQmL4Jajl7QpFFQRaIcNYg+6DO6L6ZSBKpEjngWsCSFpvyX4XANMr+6zYmh4/FOI9LvO om3smtb0jPFRCF8GKHIIC0l0t83l5cKF+VT+jjUuU+sPnrVc46u9jbyHGy5/nAAsL59CmFErVxQ28Xgokvt7ARuiX2Pn/BihnHE= Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 19:42:45 -0000 This is a cryptographically signed message in MIME format. --------------ms000206030801000604000700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 07/08/17 19:09, Salz, Rich wrote: >> A while ago, if I'm not mistaken, I glimpsed some report of vulnerabil= ities >> caused by incorrect public key comparison. > There was a recent issue raised by Hanno about incorrect public/private= key matching leading to incorrect revocation of a certificate; was that = what you were thinking of? Thanks Rich, I was able to find it now. The issue apparently affects public/private key matching, not public/public key matching, so it shouldn't be a concern for mTLS: https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Pr= ivate-Key.html Vladimir --------------ms000206030801000604000700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MDgxOTQyMTBaMC8GCSqGSIb3DQEJBDEiBCAuVxd7uI8kBrAHw0+vorm21G3Kaba3 cop2FMi+71nogjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQAQbcwJczJM pk/YAdYn8ua1HrvD8SfNgoRWKN4EpJbOBKPZay4i72kW3g6lRArHoV6O7eUVR1TbYltyMERS j5BzjviFHgwGMJEFl58VItDfdKwx9Ym7yGOg8en3ungqDQ5WNZ+305/dF/f5YgOPwzEf2AQ/ QV2EOHJVlt5v+nNZVbEKeZUbKMZ70reZGsTU/NXecFdqyfQk88NEsV4oSe8wqAz8hNf7m30P kKO8twio54BpvzF3h5/2/OADI0Az117rZsW2PyP5X7HXKznPQ8zLHpdWgKMRK45gQPBvi3jW VlpzJQVVOlBILYWD3EYAFUgBlOswtoLsbyrP5/Ie4+GlAAAAAAAA --------------ms000206030801000604000700-- From nobody Tue Aug 8 13:15:52 2017 Return-Path: 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 20BD4132A16 for ; Tue, 8 Aug 2017 13:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 GEffWmQr41rL for ; Tue, 8 Aug 2017 13:15:47 -0700 (PDT) Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (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 6237C132A11 for ; Tue, 8 Aug 2017 13:15:47 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id fAuId3xgR7cSOfAuJdILAR; Tue, 08 Aug 2017 13:15:16 -0700 To: John Bradley Cc: Brian Campbell , oauth References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> <7EBDF15A-E2A7-4409-B2E8-01AF37D1C274@ve7jtb.com> <6d150831-ab97-09eb-199c-65eb9e0457c7@connect2id.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <196c1da6-988f-4c01-5926-648a402bdfa0@connect2id.com> Date: Tue, 8 Aug 2017 23:15:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080905070500080900060405" X-CMAE-Envelope: MS4wfL//LCa2FmJ1emsQAlqfTEb3BaceDlCloN8bUaBwcTGIhK5Iq5gwHyEN9ozY3vVXqx4hfvJ0VfhfMLbqXR8hKZfR2vsiwv5t6f7S+EN9nyCASPR+NHAo cLwGmtXg7AiT6IMXn8/6nWVutwnyDuRv5IrXYLUi4j/FDklQrOKbhesneMQgL4kw4BEiMff0l3UChO3mRrZUOODnmyeoK9ZkNh9EZXFUMzbdLl7wKK+zPb69 lViNVD6uJp4vlGBBU2uuKg== Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 20:15:50 -0000 This is a cryptographically signed message in MIME format. --------------ms080905070500080900060405 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 07/08/17 18:53, John Bradley wrote: > The AS always gets the client cert from the TLS stack. Validating the= certificate cain is something people get wrong all the time. However t= hat is what the DN names are for. Using those requires validating the ce= rts. For the self-signed certs (pub_key_tls_client_auth) just the signature needs to be checked, which, in Java at least, is well supported: https://docs.oracle.com/javase/8/docs/api/java/security/cert/Certificate.= html#verify-java.security.PublicKey-java.security.Provider- I agree that with PKI certs (tls_client_auth) chain validation can be tricky. > If you use the x5c from the JWKS is is a simple compare of the two cert= s. In principal the app doesn't need to validate the cert using PKIX. = The security is provided by checking the server cert protecting the JWKS = endpoint and is dealt with in TLS one hopes. My question was actually about client registration, if the AS should perform validation of the x5c when the client JWK gets registered (for pub_key_tls_client_auth). Things that come to mind: 1) that the x5c length is one; 2) that the x5c matches the JWK public key (though for cert string matching that doesn't seem to be necessary). Thanks, Vladimir > John B. > >> On Aug 7, 2017, at 11:38 AM, Vladimir Dzhuvinov wrote: >> >> A while ago, if I'm not mistaken, I glimpsed some report of >> vulnerabilities caused by incorrect public key comparison. >> >> It looks like key comparison merits a section on its own. >> >> How about giving the AS the option to check the signature of the >> submitted client cert, which is better supported? (but will be much mo= re >> expensive in terms of CPU time than comparison) >> >> If an AS registers an x5c with the JWK, is the AS supposed to validate= >> the x5c signature using the JWK public parameter? Any other checks? >> >> Thanks, >> >> Vladimir >> >> On 04/08/17 23:16, John Bradley wrote: >>> Having the whole certificate to compare may be easier in some environ= ments that trying to directly compare the public keys. >>> >>> I believe most environments make the cert from TLS available to the a= pp comparing that to the one retrieved from the x5c element is relatively= strait forward. >>> >>> When comparing keys I worry that that may not be that easy to get fro= m the TLS/HTTP stack. =20 >>> Some environments will provide SPKI and others like java have methods= to directly manipulate the keys. >>> >>> We should also check on any issues with representation of EC public k= eys. =20 >>> While JWA docent allow compressed points RFC 5480 allows them in SPKI= =2E >>> >>> Of the top of my head I don=E2=80=99t know if anyone issues certs in = that format, but they could. =20 >>> >>> If the client receives compressed points from SPKI and uncompressed f= rom JWK it is possible to compare them but I have a bad feeling people wi= ll get it wrong. =20 >>> >>> There is also a issue with leading zeros that must be present in the = JWK but are not in the SPKI. >>> >>> For the most part comparing the raw keys will work with the three cur= rently supported named curves.=20 >>> New curves may also introduce new wrinkles. >>> >>> If we were only talking RSA I would definitely ditch x5c. >>> >>> However given that a certificate of some sort must exist to make MTLS= work putting it in the x5c is not asking the world. >>> >>> Getting a app to string compare two blobs seems less likely to go wro= ng in deployment than asking apps to do atleast format normalization of t= he public keys to compare them. >>> >>> I wish it could be simpler. >>> >>> John B. >>> >>> >>>> On Aug 4, 2017, at 3:17 PM, Vladimir Dzhuvinov wrote: >>>> >>>> What are the potential uses of the x5c parameter? >>>> >>>> Vladimir >>>> >>>> >>>> On 04/08/17 21:13, Brian Campbell wrote: >>>>> Just wanted to note that, in an off-list exchange, John has pushed = back on >>>>> the idea to potentially drop mention of using x5c. >>>>> >>>>> On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell >>>>> wrote: >>>>> >>>>>> Thanks for the review, Vladimir. >>>>>> >>>>>> The text about which you have questions was written by Torsten (cr= edit or >>>>>> blame where it's due!) but I believe he's out of the office for a = bit so >>>>>> I'll try and answer. >>>>>> >>>>>> Your 1st question: >>>>>> I've had the same thought regarding the public key method and usin= g the >>>>>> JWK x5c parameter. A JWK already has the public key, which is suff= icient >>>>>> for comparison in the public key method. So x5c is just superfluou= s here. I >>>>>> believe that's a change that the next revision should have and wil= l look to >>>>>> make it unless someone wants to make a strong case for needing x5c= =2E >>>>>> >>>>>> Your 2nd question: >>>>>> I also found the sentence, "When used in conjunction with a truste= d X.509 >>>>>> certificate source, it also allows the client to rotate its X.509 >>>>>> certificates without the need to change its respective authenticat= ion data >>>>>> at the authorization server." somewhat difficult to understand whe= n I first >>>>>> read it. The intended meaning relies on content earlier in the sam= e >>>>>> paragraph that says, "As pre-requisite, the client registers a X.5= 09 >>>>>> certificate or *a trusted source for its X.509 certificates (jwks = uri as >>>>>> defined in [RFC7591])* with the authorization server." Basically = what >>>>>> it's trying to say is that when a client is registered or configur= ed with a >>>>>> jwks_uri, then client key rotation can be done without needing to >>>>>> explicitly update the client config/registration with the AS. Does= that >>>>>> explain it? I believe the text could be more straightforward and w= ill >>>>>> endeavor to make it more clear in the next draft update. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov < >>>>>> vladimir@connect2id.com> wrote: >>>>>> >>>>>>> Thanks everyone for the update! Having a clear distinction betwee= n the >>>>>>> PKIX vs public key bound methods will help interop, implementers'= job, and >>>>>>> it also appears good for security. >>>>>>> >>>>>>> Questions: >>>>>>> >>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >>>>>>> 03#section-2.3 >>>>>>> >>>>>>> where the X.509 certificates are represented using the "x5c" para= meter from [RFC7517 >>] >>>>>>> >>>>>>> For the public key method, is it really necessary for the client = to >>>>>>> include its certificate in the JWK x5c parameter? This will make >>>>>>> implementation harder for developers, and I'm not sure it adds an= ything in >>>>>>> terms of security. Registering the public key parameters seems su= fficient >>>>>>> to me. >>>>>>> >>>>>>> >>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- > >>>>>>> 03#section-2.1 >>>>>>> >>>>>>> When used in conjunction with a trusted X.509 certificate source,= it also allows the client to rotate its X.509 certificates without the n= eed to change its respective authentication data at the authorization ser= ver. >>>>>>> >>>>>>> I don't understand this - "in conjunction with a trusted X.509 >>>>>>> certificate source" >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> On 28/07/17 21:33, Brian Campbell wrote: >>>>>>> >>>>>>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been publis= hed with >>>>>>> the changes listed below based on comments and dissuasion in Prag= ue. >>>>>>> >>>>>>> draft-ietf-oauth-mtls-03 >>= >> >>>>>>> >>>>>>> >>>>>>> o Introduced metadata and client registration parameter to publ= ish >>>>>>> and request support for mutual TLS sender constrained access >>>>>>> tokens >>>>>>> o Added description of two methods of binding the cert and clie= nt, >>>>>>> PKI and Public Key. >>>>>>> o Indicated that the "tls_client_auth" authentication method is= for >>>>>>> the PKI method and introduced "pub_key_tls_client_auth" for t= he >>>>>>> Public Key method >>>>>>> o Added implementation considerations, mainly regarding TLS sta= ck >>>>>>> configuration and trust chain validation, as well as how to t= o do >>>>>>> binding of access tokens to a TLS client certificate for publ= ic >>>>>>> clients, and considerations around certificate bound access t= okens >>>>>>> o Added new section to security considerations on cert spoofing= >>>>>>> o Add text suggesting that a new cnf member be defined in the >>>>>>> future, if hash function(s) other than SHA-256 need to be use= d for >>>>>>> certificate thumbprints >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: = >> >> >>>>>>> Date: Fri, Jul 28, 2017 at 12:25 PM >>>>>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >>>>>>> To: i-d-announce@ietf.org > >>>>>>> Cc: oauth@ietf.org > >>>>>>> >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Draft= s >>>>>>> directories. >>>>>>> This draft is a work item of the Web Authorization Protocol WG of= the IETF. >>>>>>> >>>>>>> Title : Mutual TLS Profile for OAuth 2.0 >>>>>>> Authors : Brian Campbell >>>>>>> John Bradley >>>>>>> Nat Sakimura >>>>>>> Torsten Lodderstedt >>>>>>> Filename : draft-ietf-oauth-mtls-03.txt >>>>>>> Pages : 17 >>>>>>> Date : 2017-07-28 >>>>>>> >>>>>>> Abstract: >>>>>>> This document describes Transport Layer Security (TLS) mutual >>>>>>> authentication using X.509 certificates as a mechanism for OAuth= >>>>>>> client authentication to the token endpoint as well as for >>>>>>> certificate bound sender constrained access tokens. >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is:https://datatr= acker.ietf.org/doc/draft-ietf-oauth-mtls/ > >>>>>>> >>>>>>> There are also htmlized versions available at:https://tools.ietf.= org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/dr= aft-ietf-oauth-mtls-03 > >>>>>>> >>>>>>> A diff from the previous version is available at:https://www.ietf= =2Eorg/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 > >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of= submission >>>>>>> until the htmlized version and diff are available at tools.ietf.o= rg >. >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.= ietf.org/internet-drafts/ > >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing listOAuth@ietf.orghttps >:/= /www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > > --------------ms080905070500080900060405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MDgyMDE1MTRaMC8GCSqGSIb3DQEJBDEiBCBU+7Vaw+CD7k3TLFTGYiMPqamD0G7f ewf+ZLVqOWyAfjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQCVMZkgj8CZ mMOm8MY+4VlOsM+fMNiDdNVsryAEwMglV/53aW9e0rJiD/BxiCmLDotQ2202Ls4lsgQk2/WO XxRQXRcMMs/vfB+8AFdRA+zzhvHuVCuat3AzqHJumCkeDQRpRM0RmE7AgO+v9moH8+gGgZEG nB5d/EsQsRKdVBSOlC5VvrzYm+pefWPLNlCnWuV79OItwpER0CTfYAJNRTsj8Qw2oSK9LOZb 3hxNl1EfXJWpXcXf/OyCRF5qaKZUgt5ypjI0fN9GbsCkE95bjq3RF0pbqHSbKon17DlGGTL7 5hTJtosyHOMwJgWB+e4OwNz2BZHs7KCYrHOrsQK7fqXbAAAAAAAA --------------ms080905070500080900060405-- From nobody Tue Aug 8 23:19:37 2017 Return-Path: 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 3F23A1243F6 for ; Tue, 8 Aug 2017 23:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 nMQ-KMKsc6PB for ; Tue, 8 Aug 2017 23:19:34 -0700 (PDT) Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) (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 A2732126C23 for ; Tue, 8 Aug 2017 23:19:34 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id fKKcdZkGUJ3l2fKKddGQWv; Tue, 08 Aug 2017 23:19:03 -0700 To: oauth From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <64004971-b5c7-01f7-4e7f-2abca6f7712d@connect2id.com> Date: Wed, 9 Aug 2017 09:19:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040302030904010309000704" X-CMAE-Envelope: MS4wfG+YK13T7aLVqsys3dWPbxFsoDMPw0wkmPzSbqXDlA4K1cXrIwtZRlcGAi3KGMTHijCwiMOa9hjZ4xde4lKCwN96PpJjVnEi+w931iksAXGuA73na/50 AwtAGqHZVKQUMehA70jA8DcsDI1gx8pIilD3q7M+GKdkB23MLAuK4Vab Archived-At: Subject: [OAUTH-WG] JWT BCP: x5c X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 06:19:36 -0000 This is a cryptographically signed message in MIME format. --------------ms040302030904010309000704 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US This is a classic case for the BCP: https://bitbucket.org/connect2id/nimbus-jose-jwt/issues/230/x5c-path-vali= dation Developer expects that checking the signature of a JWT with a given JWK will also validate the x5c of the JWK. How the developer obtained the JWK in the first place is not clear from the ticket. I wonder how such mistakes can be prevented at lib API level. If you know a good approach or example, please let me know. Vladimir --------------ms040302030904010309000704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MDkwNjE5MDJaMC8GCSqGSIb3DQEJBDEiBCDwAiFS/AH/OyVEmnwGF+ueK9Vdcbfv 5yMNq/vGqw4+TTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQCQG2b/BdRn xKpVx7scj54+JaKu+JvSqFGeYVXI3YMGOXn8Of/mAda5UTeVGrQX3MGPCBUjDjszwrapMxfR WzBwKjh0X8ZoPwjheK7JWNR6nzVCOeTRDzyUnDiaTqCxD3i55EIBtGiIrQakypeMq9nkMVdz 8LO1H8MB5LJv+GAGEevLtI306nPEB5onqzaT5mMDDvvffjLW17XsAwZaqh3DT8Ucx4EyCkXb k896wySj3rKoF+5fZ6hhdiJyLYLWx3xh+qq8y3GKpEz2vvye9FHe8iqf7Bfvs3ZNoiJ6gYlX WMNyJCzvJQeOxgO1YIzQCYi1hk2ObKY8u82Zyx31kZ9vAAAAAAAA --------------ms040302030904010309000704-- From nobody Wed Aug 9 00:28:17 2017 Return-Path: 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 23A031276AF for ; Wed, 9 Aug 2017 00:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.32 X-Spam-Level: X-Spam-Status: No, score=0.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZqU45C5GPbx1 for ; Wed, 9 Aug 2017 00:28:15 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 1E07F1275FD for ; Wed, 9 Aug 2017 00:28:15 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 80so25247838uas.0 for ; Wed, 09 Aug 2017 00:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=iTRBSyFzydTpMBWMNiVwbN9pWDZE4nd1nJIdvrK6DXqhNTZJgbKXcMOXAC5XBVHACJ d6Jx9hDisMIBlvsBU1zUfAvznuRQa6l4GZplhvuC+0fxeKeOYyg7qjTCVXz7ltRGNk/l ORXlD0r4v0dQuen6w8wKwscnwk0dATMxFbALi/rTe9VLSl0j2pARZTGQU7pcbvURpSCI 7lW0oGhQy7x8xY+qDWBGS2vrpglAAPlU8AbQzwDdJaNr2WF9qCnFSqa4mFRQchedfL9P UDz7XR1VLRkHk3arSDD0JB7stfWlGvccJuzP93olo1Eg6flGxwLMEwD3nvK01yyBbIjS hm9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=A/ffox1WKrUMVdo8GhsvI8tl8krUELonk1eS/0wSBNE2K/x0ZnUqLNyMQ8r7AzIgZJ woh9VXnAJ439OGLzC0DC5x+KIrKpLvdZBqiqomjfo/noQObdGBVogKXf/DLFF83by3Ab vp0A5zn4iZEPQgKUxewhS/LpIAnQ6JqGMFcxcJCsWP6rXfnKuTbnqf3dr0pi2xKmanvz pciQ3zPBkH9x5ne1lLgER/DQEhqjcHp04n1HxD3vDM6Iftxi2Vaq72ZIu1/GhE7WFTNt tWw/3sFFLQXEdKtNwc2OX8wEvHbgvbiWsDqUdRfriN+rCBNzSXV6WIs543WBpnEGnb7A zuqQ== X-Gm-Message-State: AHYfb5g+dDIIIBP5ymLffswpZoaGmYLTFN9pH9sGfuV6H2+qHhGo8Fli oWL5Snhgd9Wu9d+uGPFyhR3zBF9y9Kdo X-Received: by 10.159.55.206 with SMTP id q72mr4671215uaq.70.1502263694180; Wed, 09 Aug 2017 00:28:14 -0700 (PDT) MIME-Version: 1.0 From: Heng Puthireach Date: Wed, 09 Aug 2017 07:28:03 +0000 Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 07:28:16 -0000 From nobody Fri Aug 11 13:00:37 2017 Return-Path: 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 BC8B8132398 for ; Fri, 11 Aug 2017 13:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iucaC8_ZaGeD for ; Fri, 11 Aug 2017 13:00:33 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 16E13132422 for ; Fri, 11 Aug 2017 13:00:33 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id i66so63560wmg.0 for ; Fri, 11 Aug 2017 13:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=euvR1FHIXYFI4h+NUA2AcWFqQsSKhJABZE2miwUKKSU=; b=qwzfBz7DN2BbvHAeRYQSxJpSANCImSSzNFMpLYj1dk14/InCho0ltD6gdBuC0zn18z z8473YX/FqdEsYiNDoZoR94MlPWf7Jkil+Dn/XzgnmFKEZP7ZeptBUZfnPdHfuQKyJs5 bMsl6GARoqnZJSHmqpM5KAti1FlCCbrbFEn+CbtpUZharm5Ph+uvyHUtOt1/ZqquYKcu LGKoJeY+o/0NqloudVlr7INsG6HDhwtXxrNv0gBMPRRmCD3ylumf+PSYYNk9Iyk4rG16 RPVCRcG9qO0bfwhGevbj4+Itwh3dbX18RzM0eKZMoUJSJKt+ETi6Z8y2BHngSzf8W1xa 7sRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=euvR1FHIXYFI4h+NUA2AcWFqQsSKhJABZE2miwUKKSU=; b=Nj88oEc4LtFyJk16RcZHNbZoaXATYGJriB1u32J/7bjRBw9vsFNE74++Tf3GCDGcs8 08S+mCAuAeA84ZhFY8HKWjN38OYvbfE1AUqLB3eJcj8pdrjL50F41/esU1riU6tnXP+i yIzgQhaZigYBPCATLSbgpGqBRzMWgMe6H7ac2B8xJMt4qVkMdZv2xaGVOxQ0kECbGpWN /kHuNK/Lowpm0ooEJFxZfJ/SRm1BlW2lH9LpSewWK5IN8i7E89QXpuNwmBMbh4Mm4K00 mpF34NqdptcM9X39JtEuivu7Ya9RsmS0XlEFlVcIxeVJj8BwsHxUAW+imJ+JAcEK+r3n c7Pg== X-Gm-Message-State: AHYfb5gi1lozh0Z08NhHg1bXMVkrAxYbbtAxOqcdDK0KxPkDZuEOxqYu WhUEdCxCNyHV84ClkxiBTcm5Ua7EF/6jyE0= X-Received: by 10.80.162.133 with SMTP id 5mr16758765edm.116.1502481631388; Fri, 11 Aug 2017 13:00:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.83 with HTTP; Fri, 11 Aug 2017 13:00:10 -0700 (PDT) From: Josh Mandel Date: Fri, 11 Aug 2017 16:00:10 -0400 Message-ID: To: "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c0d98f2ebaca305567fc301" Archived-At: Subject: [OAUTH-WG] Redirection in authorization code flow: GET vs POST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 20:00:36 -0000 --94eb2c0d98f2ebaca305567fc301 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I've just encountered a server that performs a redirect (back to the client's redirect_uri) via POST instead of GET. This was surprising behavior to me and broke my client implementation =E2=80=94 but citing chap= ter and verse, the server developer pointed out that https://tools.ietf.org/html/rfc6749#section-1.7 says While the examples in this specification show the use of the HTTP 302 > status code, any other method available via the user-agent to accomplish > this redirection is allowed and is considered to be an implementation > detail. Is triggering a POST-based redirect (e.g. with this technique ) to the redirect_url (including url query parameters for state and code) indeed considered a "method available via the user-agent to accomplish this redirection"? In other words, should a well-behaved OAuth client be prepared to receive GETs as well as POSTs to its redirect_uri? If so, what would be the considerations for a server choosing between GET and POST? Best, Josh --94eb2c0d98f2ebaca305567fc301 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

=

While the = examples in this specification show the use of the HTTP 302 status code, an= y other method available via the user-agent to accomplish this redirection = is allowed and is considered to be an implementation detail.

Is triggering a POST-based redirect (e.g. with this te= chnique) to the redirect_url (including url query parameters for state = and code) indeed considered a "method available via the user-agent to = accomplish this redirection"? In other words, should a well-behaved OA= uth client be prepared to receive GETs as well as POSTs to its redirect_uri= ? If so, what would be the considerations for a server choosing between GET= and POST?

Best,

=C2=A0 J= osh
--94eb2c0d98f2ebaca305567fc301-- From nobody Fri Aug 11 13:08:38 2017 Return-Path: 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 E8CA71321D0 for ; Fri, 11 Aug 2017 13:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u519F8YUv5lo for ; Fri, 11 Aug 2017 13:08:34 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 AB5CD126C7A for ; Fri, 11 Aug 2017 13:08:33 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id m85so49349146wma.0 for ; Fri, 11 Aug 2017 13:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Ua56aqfC6uLLikfoG1SFtyi6kg9kN+kPccD1pk4mhrI=; b=PfH1FhuDhp1/XRVV0E6Kc3m61gHfs4JoK+HjhH3r7XONNYxIsmHpCCAmvVN9gYgOMJ JActPkbdD9+ap4gW3TW6e2Oxdy86eGkVUnl5CASgoFJWqrLz8piJGpO3rUdSMwEHvwuK OGH9dS5NIQO3U0Guhz7B6A0BKUmdi9c6RMLsRSbSrIy2kAFd5zecqAVz7LVRvUjRVQ43 fvFXVLyTZwGgNkuvuUPwFlLVChgF7jmPyoevEJheRsPOaPJu2YuAi+SS2GbxDiXonjJ7 UPvkx2xwExDz6m8jAR1+BeRCa7xYaUPwsKfXEjkKlluDQqd/ifCec8IJhF7YMGSWkpwJ lSIQ== 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; bh=Ua56aqfC6uLLikfoG1SFtyi6kg9kN+kPccD1pk4mhrI=; b=AcBvwNrKUlBufoF2bvGnI8F2HkMtn4hAwrDcDSGHzv9wa5wL/Qizs740vVOTsnqVjz N4g3YpRpvvUSsJDJ7kQNsCa++AQhBwlI1mDHnY+TvwiGmw2tkASP/rSAZwflpvSGle/D rzSIyeLJDNi1c46a4IYU8/bJbhrIS+zWDkQMdBrJpWl+eBcIRNZRyH84uV3ZXN7Ozdra x8MsOf+TBqwn0Ugb+L3fXP/Tycf7KEMRUWYJsaGGSkmqFUfDDqm2Nho/82ZWgDXZhcVb MasiI5duDwnu0cjZZ7oLzl4RWD/faSUhlvxwVvXzreitFyMrT/kOauM+JraxvyuZQux+ moGw== X-Gm-Message-State: AHYfb5i1VSfVsg6G2EXVfwyUkBXHjL4/tNVRnW2Cfnmyn+qPokjqhohB 5QKLbDYCpyeRxD1TO1PtQi4/JxJBOdb6RHk= X-Received: by 10.80.186.100 with SMTP id 33mr16082772eds.47.1502482112038; Fri, 11 Aug 2017 13:08:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.83 with HTTP; Fri, 11 Aug 2017 13:08:11 -0700 (PDT) In-Reply-To: References: From: Josh Mandel Date: Fri, 11 Aug 2017 16:08:11 -0400 Message-ID: To: "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary="f403045c4be091cf2c05567fe052" Archived-At: Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 20:08:36 -0000 --f403045c4be091cf2c05567fe052 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fixing my "with this technique" url: it should have been https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 . On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel wrote: > Hi All, > > I've just encountered a server that performs a redirect (back to the > client's redirect_uri) via POST instead of GET. This was surprising > behavior to me and broke my client implementation =E2=80=94 but citing ch= apter and > verse, the server developer pointed out that https://tools.ietf.org/ > html/rfc6749#section-1.7 says > > While the examples in this specification show the use of the HTTP 302 >> status code, any other method available via the user-agent to accomplish >> this redirection is allowed and is considered to be an implementation >> detail. > > > Is triggering a POST-based redirect (e.g. with this technique > ) to > the redirect_url (including url query parameters for state and code) inde= ed > considered a "method available via the user-agent to accomplish this > redirection"? In other words, should a well-behaved OAuth client be > prepared to receive GETs as well as POSTs to its redirect_uri? If so, wha= t > would be the considerations for a server choosing between GET and POST? > > Best, > > Josh > --f403045c4be091cf2c05567fe052 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fixing my "with this technique" url: it should h= ave been https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63= .

On Fr= i, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com> = wrote:
Hi All,

<= /div>
I've just encountered a server that performs a redirect (back= to the client's redirect_uri) via POST instead of GET. This was surpri= sing behavior to me and broke my client implementation =E2=80=94 but citing= chapter and verse, the server developer pointed out that=C2=A0https://t= ools.ietf.org/html/rfc6749#section-1.7 says=C2=A0

While the examples in= this specification show the use of the HTTP 302 status code, any other met= hod available via the user-agent to accomplish this redirection is allowed = and is considered to be an implementation detail.

Is triggering a POST-based redirect (e.g. with = this technique) to the redirect_url (including url query parameters for= state and code) indeed considered a "method available via the user-ag= ent to accomplish this redirection"? In other words, should a well-beh= aved OAuth client be prepared to receive GETs as well as POSTs to its redir= ect_uri? If so, what would be the considerations for a server choosing betw= een GET and POST?

Best,

= =C2=A0 Josh

--f403045c4be091cf2c05567fe052-- From nobody Fri Aug 11 13:17:48 2017 Return-Path: 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 26FD11320E3 for ; Fri, 11 Aug 2017 13:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 QEiAHa60eX2q for ; Fri, 11 Aug 2017 13:17:44 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 E8D0513235E for ; Fri, 11 Aug 2017 13:17:30 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id x3so43155192oia.1 for ; Fri, 11 Aug 2017 13:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IxnxKmFI3Q7iiyztd6mvGegx3dQzug95UGMK4nWtIzE=; b=yCKNzLG2G/BssfH6MbwPsAQEsX2xJoX1WMbdNE08DGC/mTiket+bbQmGBvC39WcvUQ YAFBQ7Gg1Bv/CT/R5k6V7ia2edHIiFHYdeOSJT7uADkjWUbWsfqanCmSE+RGkQJX4VXc 1RGXJc3r7TZSAOjdV7JdqWWYq5YyIPO6o5E556zSJIxpefCz4TWLtlTVLdwiuRChGjlX nemuFmXAJoZ1AEjVSwxVnU/u+/yX/q8uIXah5MGorZqnvzPitszrQxkL/MiefGNEyNVy TLAWlgcbLFtlYNgVxP5syQrAYlExxAMl+8rdvT6VDgwOhNNU8EILaiANhSklhuuUOHie ZtTA== 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=IxnxKmFI3Q7iiyztd6mvGegx3dQzug95UGMK4nWtIzE=; b=Aef8UQsK0u65EKtsx5Me1YEveu7ekC4GpNlaSQnD0t5GYffIz+mh2DnkU94fOS5RY2 qx4BsDBM+rnSY3lRytLbeb3QsEmNJpBdu23RMrChgEqbQzFf1TwElgAh2TfUIDIrcYHX uWKF0nRrA5zJqXNjGkBMeJxyKa4yEI93K3xFpWzS+oOnT21M2WIk4Xugd2OJ3q7VJG6O RRNSjsJhsIoFOvKXLD5u6WVpv2eINGmet+ZpMComcFwSRsl1Yh+pydwmZW92ETKY8xk5 yNGlEr9r0ea6nOhimuuHMl48NItyPI7Ve6M7m5h6zHPXfP5QCLx9bZGgZytNLuWOYmnF AUWA== X-Gm-Message-State: AHYfb5iakya3tW2Oi4U4cnumTR/WUJ1tt5V05IxRpJFP0Cbl6J6cJDHe kts+Tda91pF4I1d7 X-Received: by 10.202.60.133 with SMTP id j127mr18041588oia.7.1502482650264; Fri, 11 Aug 2017 13:17:30 -0700 (PDT) Received: from [10.186.174.249] (mobile-166-172-120-104.mycingular.net. [166.172.120.104]) by smtp.gmail.com with ESMTPSA id k64sm1524999oif.35.2017.08.11.13.17.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 13:17:29 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-203D81B1-DE09-4307-ABDA-D11DA8EBA02D Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Fri, 11 Aug 2017 15:17:28 -0500 Cc: "oauth@ietf.org WG" Content-Transfer-Encoding: 7bit Message-Id: References: To: Josh Mandel Archived-At: Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 20:17:47 -0000 --Apple-Mail-203D81B1-DE09-4307-ABDA-D11DA8EBA02D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would take it a step further. GET's leak parameters even over HTTPS. I adv= ise all GET based OAuth communication to be switched to POST, a much more se= curity centric verb. Aloha, -- Jim Manico > On Aug 11, 2017, at 3:08 PM, Josh Mandel wrote: >=20 > Fixing my "with this technique" url: it should have been https://gist.gith= ub.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 . >=20 >> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel wrote: >> Hi All, >>=20 >> I've just encountered a server that performs a redirect (back to the clie= nt's redirect_uri) via POST instead of GET. This was surprising behavior to m= e and broke my client implementation =E2=80=94 but citing chapter and verse,= the server developer pointed out that https://tools.ietf.org/html/rfc6749#s= ection-1.7 says=20 >>=20 >>> While the examples in this specification show the use of the HTTP 302 st= atus code, any other method available via the user-agent to accomplish this r= edirection is allowed and is considered to be an implementation detail. >>=20 >> Is triggering a POST-based redirect (e.g. with this technique) to the red= irect_url (including url query parameters for state and code) indeed conside= red a "method available via the user-agent to accomplish this redirection"? I= n other words, should a well-behaved OAuth client be prepared to receive GET= s as well as POSTs to its redirect_uri? If so, what would be the considerati= ons for a server choosing between GET and POST? >>=20 >> Best, >>=20 >> Josh >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-203D81B1-DE09-4307-ABDA-D11DA8EBA02D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I would take it a step further. GET's l= eak parameters even over HTTPS. I advise all GET based OAuth communication t= o be switched to POST, a much more security centric verb.

Aloha,
--=
Jim Manico

On Aug 11, 2017, at 3:08 PM, Josh M= andel <jmandel@gmail.com> wro= te:

Fixing my "= with this technique" url: it should have been https://gist.github.com/jmand= el/4704d1efed8578a67a6f9b600ffd0c63 .
On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <j= mandel@gmail.com> wrote:
Hi All,

I've just encountered a server that pe= rforms a redirect (back to the client's redirect_uri) via POST instead of GE= T. This was surprising behavior to me and broke my client implementation =E2= =80=94 but citing chapter and verse, the server developer pointed out that&n= bsp;https://tools.ietf.org/html/rfc6749#section-1.7 says 

While the e= xamples in this specification show the use of the HTTP 302 status code, any o= ther method available via the user-agent to accomplish this redirection is a= llowed and is considered to be an implementation detail.
Is triggering a POST-based redirect (e.g. with this technique) to the redirect_url (including url query parameters f= or state and code) indeed considered a "method available via the user-agent t= o accomplish this redirection"? In other words, should a well-behaved OAuth c= lient be prepared to receive GETs as well as POSTs to its redirect_uri? If s= o, what would be the considerations for a server choosing between GET and PO= ST?

Best,

  Josh

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-203D81B1-DE09-4307-ABDA-D11DA8EBA02D-- From nobody Fri Aug 11 13:19:07 2017 Return-Path: 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 E31DC132031 for ; Fri, 11 Aug 2017 13:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 3Cytn6e4iWK7 for ; Fri, 11 Aug 2017 13:19:03 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 30141131E75 for ; Fri, 11 Aug 2017 13:19:03 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id u139so26313637qka.1 for ; Fri, 11 Aug 2017 13:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=q4BhoEU36nFpPF11KJATGH2pvq/a9jF2c/pWHZGU7iI=; b=akoFA3I9gfQ0l8LqDTT7WkuRuR+sCebz59KM9UjJCEf1AJxGtAf9/uApUVKx/peuVj QxRpNcvawAcVE22ElPrKyZ1Y4EzWCr1ykQ3CUD3huJhKiLqnVJXj1WrCEfyerObnSUFY hp39C6Mz+2BQ6ND7JLrtC6jTrPA2mHaA57jSI0MCB6JuUTGUXogzRd9BFZ9U5ZK5FYcJ g1TqlgJWh+vApViDj5NE7axJuzP7P0P0JDTP7vuMH0GSQ+RR2vtKlYS+n3CnjyZHPoQt R8LOXnX81nX5MqjSNwND8OcV3hIuesQ57p8XoQLfMuZFkUTeve24uunDiUkcAKVr1Zfg ZVSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=q4BhoEU36nFpPF11KJATGH2pvq/a9jF2c/pWHZGU7iI=; b=Q+5G4uB+0V64t6CngRqJE0pNoZeXjeYRr3M4ak7aWzxS9NIPsjYAzujuvIOgR2IDik 8AuRJbESHhoP2fQjL9GuHPq9VBPU4FMvlOhI3g2Ijb5uxNxfd6qlH1m12OQkQdxZFP3O k07aLnxQZbAmCy6o6jzNamWh2GLepCvEjS7ZldDuJFtsywbPakoo44GSQ7+jMmrXxZ9r QCjwh1hPDgpYeAVF6i5FZE6kO5Ow7YgmUVkuh6em8E32QVruZwvgobDReIkRBqmVXQbR ei245qHQ9u7JYMPbgPbHqtVz5DEyslO5aRMMUbg1RuFEwLoVnl4NujSrR8LiA1LxpnwN dQvg== X-Gm-Message-State: AHYfb5hWtBM6zlfCzqVH3TTrPfwUv5GDBMpvGU6jnHg8n5L11ppW1Itz wLuPnvbUI64z4LK8 X-Received: by 10.55.212.2 with SMTP id l2mr14713280qki.3.1502482742021; Fri, 11 Aug 2017 13:19:02 -0700 (PDT) Received: from [192.168.8.101] ([181.201.218.116]) by smtp.gmail.com with ESMTPSA id y9sm1138821qkg.36.2017.08.11.13.18.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 13:19:00 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 11 Aug 2017 16:18:49 -0400 In-Reply-To: Cc: "oauth@ietf.org WG" To: Josh Mandel References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11499ecc2669cb05568006c8" Archived-At: Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 20:19:06 -0000 --001a11499ecc2669cb05568006c8 Content-Type: multipart/alternative; boundary="Apple-Mail=_D3C2FFC2-DDE8-407F-8480-6DE0B4C8C046" --Apple-Mail=_D3C2FFC2-DDE8-407F-8480-6DE0B4C8C046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OpenID Connect formally defined a POST response mode. http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html = The OAuth 2 spec docent preclude it. =20 The safest thing for a client is to accept both. =20 The main advantages of POST is that it docent leak in the referrer, and = can handle larger responses without the browser choking in some cases. Size is more of an issue in Connect where a id_token may be returned in = the front channel and POST allows for the larger response without the = client needing to have JS extract the fragment. That is why Connect defined it and OAuth largely assumes that for code = get is OK. For security GET responses should add headers to prevent referrer from = leaking the code. We are adding advice on that to the Security document that is being = updated now. John B. > On Aug 11, 2017, at 4:08 PM, Josh Mandel wrote: >=20 > Fixing my "with this technique" url: it should have been = https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 = . >=20 > On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel > wrote: > Hi All, >=20 > I've just encountered a server that performs a redirect (back to the = client's redirect_uri) via POST instead of GET. This was surprising = behavior to me and broke my client implementation =E2=80=94 but citing = chapter and verse, the server developer pointed out that = https://tools.ietf.org/html/rfc6749#section-1.7 = says=20 >=20 > While the examples in this specification show the use of the HTTP 302 = status code, any other method available via the user-agent to accomplish = this redirection is allowed and is considered to be an implementation = detail. >=20 > Is triggering a POST-based redirect (e.g. with this technique = ) to = the redirect_url (including url query parameters for state and code) = indeed considered a "method available via the user-agent to accomplish = this redirection"? In other words, should a well-behaved OAuth client be = prepared to receive GETs as well as POSTs to its redirect_uri? If so, = what would be the considerations for a server choosing between GET and = POST? >=20 > Best, >=20 > Josh >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D3C2FFC2-DDE8-407F-8480-6DE0B4C8C046 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OpenID Connect formally defined a POST response mode.

http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.ht= ml

The = OAuth 2 spec docent preclude it.  

The safest thing for a client is to = accept both.  
The main advantages of POST is = that it docent leak in the referrer, and can handle larger responses = without the browser choking in some cases.

Size is more of an issue in Connect = where a id_token may be returned in the front channel and POST allows = for the larger response without the client needing to have JS extract = the fragment.

That is why Connect defined it and OAuth largely assumes that = for code get is OK.
For security GET responses = should add headers to prevent referrer from leaking the code.

We are adding advice on = that to the Security document that is being updated now.

John B.


On = Aug 11, 2017, at 4:08 PM, Josh Mandel <jmandel@gmail.com> = wrote:

Fixing my "with this technique" url: it should = have been https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c6= 3 .

On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com> wrote:
Hi All,

I've just encountered a server that performs a redirect (back = to the client's redirect_uri) via POST instead of GET. This was = surprising behavior to me and broke my client implementation =E2=80=94 = but citing chapter and verse, the server developer pointed out = that https://tools.ietf.org/html/rfc6749#section-1.7 says 

While the examples in this = specification show the use of the HTTP 302 status code, any other method = available via the user-agent to accomplish this redirection is allowed = and is considered to be an implementation detail.

Is triggering a = POST-based redirect (e.g. with this technique) to the redirect_url = (including url query parameters for state and code) indeed considered a = "method available via the user-agent to accomplish this redirection"? In = other words, should a well-behaved OAuth client be prepared to receive = GETs as well as POSTs to its redirect_uri? If so, what would be the = considerations for a server choosing between GET and POST?

Best,

  Josh

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_D3C2FFC2-DDE8-407F-8480-6DE0B4C8C046-- --001a11499ecc2669cb05568006c8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIL/EEXYVnMx27pwmtVpwwO2wkRCQ xb7Q5T4bNOQVkQQJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgxMTIwMTkwMlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBIJ/kecV/ekcKy+or6eC+cM3fJ1f/U7qclC0PmKy45BSAo TfE2XIDwrLyE6nJQyIaLAr65yYucZ05rLkDUaQMC8wKpkM825RfH03xJ9QRFWW3U5VuO4u1i5ku4 HMRseF5dKzlk34MHBM2Ujn6MwYw5QRijSv8MXq3SCo2ji+qB1aXfO7Cvzos2RyqT4jIEemHLeEyQ Q5Q6SfoF5XR7OaRTck6+sUuLF4wT5k0bRoTNo43QyNiiljtDsazLW2qdspIjwBrtCx6fW/nBspk0 nwtbi6BITr7rx2/MXRyTLPKRLHNuT5Ta/56Ge3yrkGZftn0YOXwKG2xjtTscTbQR5SAd --001a11499ecc2669cb05568006c8-- From nobody Sat Aug 12 07:55:11 2017 Return-Path: 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 E5C65132452 for ; Sat, 12 Aug 2017 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 r2JuQJkeC-DP for ; Sat, 12 Aug 2017 07:55:07 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 AF1FD13241F for ; Sat, 12 Aug 2017 07:55:07 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id x3so55019197oia.1 for ; Sat, 12 Aug 2017 07:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=jeVHouVWUeg0DKaX20iVAzEHXrK4Lqcb9eKceC4BYYk=; b=hxHK90Hu5XiykKP2vM/Ueyvc0NcVwOaMhk73CERXrhtg8BcXuhxWMxu+pm1+eCVhAY EWZ18X4wMG1JGsaCh3PxZtBlAiqRHN4D/JkHu2G9lem1MvHwj1heL1Oezr5quz3tBNWF BUGnruyjaof6Lib9FJbC8/uMHvb/eAdJm708Rn/QYin8BVt+Nl+Q/fj8NGKCMAXTa1bb ZePIv9WgjrHiQ3F8x3tAxpTKqAaAcJYV8C1L6Le2reg0rfFV02LkQaX108f6/EQh6QsW hoT+CbaWrEVi5RB0PtXt/Ti8oY5dfsbrJW0DFIyXQ41EjIdKUrsnVooZN++WfuFa/zDo eKIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=jeVHouVWUeg0DKaX20iVAzEHXrK4Lqcb9eKceC4BYYk=; b=n0ooiwvTejc8uIM/v1f0uxDmPEUQxJNbie8dc38Pj+S7MGAgCYvcCt6Q9Y5DsOHiQl 6Cr7ay/BZXJWgJSnULOLCfLvnYETdtrkKJr1uB7P6tOFyANdmSsCeuADdjO7YjxOBTFI WpXebdJs08v7yAliHgOABcy4UCxPeDmVeJ89CsB4wLNAXxD2qcSfEFsF/CMbQAsmvatE yea4yrdCaSN4z9BZ+9oUn8jQUmBxfqd+1T39k8jO/U3f31/eUXMJAdtt8R+BfRm2yUuj i8+hxzEwMRaZ7ZZ+EyZGXQ8wg/RKIXzaISwghCBCv40nv4wejsJ02qEDgiU971EatHpr /1oA== X-Gm-Message-State: AHYfb5guWhkfxpB7fBzE0pFuKRGPa/Am1fAUNr92RbMkQYPfnJa/Oqw6 C39G84yiDtYl3ay32J5Okg== X-Received: by 10.202.205.80 with SMTP id d77mr20827649oig.13.1502549706737; Sat, 12 Aug 2017 07:55:06 -0700 (PDT) Received: from heembo.local ([12.197.53.130]) by smtp.googlemail.com with ESMTPSA id p127sm3816689oic.48.2017.08.12.07.55.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 07:55:05 -0700 (PDT) To: John Bradley , Josh Mandel Cc: "oauth@ietf.org WG" References: From: Jim Manico Message-ID: <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com> Date: Sat, 12 Aug 2017 09:55:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DD191A6389D154D1AAED0C3F" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 14:55:10 -0000 This is a multi-part message in MIME format. --------------DD191A6389D154D1AAED0C3F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit > The _*safest*_ thing for a client is to accept both. I politely (and strongly) disagree with this statement. The safest thing for a client is to only accept POST or other verbs where any kind of sensitive data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, even over HTTPS. Respectfully, Jim On 8/11/17 3:18 PM, John Bradley wrote: > OpenID Connect formally defined a POST response mode. > > http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html > > The OAuth 2 spec docent preclude it. > > The safest thing for a client is to accept both. > The main advantages of POST is that it docent leak in the referrer, > and can handle larger responses without the browser choking in some cases. > > Size is more of an issue in Connect where a id_token may be returned > in the front channel and POST allows for the larger response without > the client needing to have JS extract the fragment. > > That is why Connect defined it and OAuth largely assumes that for code > get is OK. > For security GET responses should add headers to prevent referrer from > leaking the code. > > We are adding advice on that to the Security document that is being > updated now. > > John B. > > >> On Aug 11, 2017, at 4:08 PM, Josh Mandel > > wrote: >> >> Fixing my "with this technique" url: it should have been >> https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 . >> >> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel > > wrote: >> >> Hi All, >> >> I've just encountered a server that performs a redirect (back to >> the client's redirect_uri) via POST instead of GET. This was >> surprising behavior to me and broke my client implementation — >> but citing chapter and verse, the server developer pointed out >> that https://tools.ietf.org/html/rfc6749#section-1.7 >> says >> >> While the examples in this specification show the use of the >> HTTP 302 status code, any other method available via the >> user-agent to accomplish this redirection is allowed and is >> considered to be an implementation detail. >> >> >> Is triggering a POST-based redirect (e.g. with this technique >> ) >> to the redirect_url (including url query parameters for state and >> code) indeed considered a "method available via the user-agent to >> accomplish this redirection"? In other words, should a >> well-behaved OAuth client be prepared to receive GETs as well as >> POSTs to its redirect_uri? If so, what would be the >> considerations for a server choosing between GET and POST? >> >> Best, >> >> Josh >> >> >> _______________________________________________ >> 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 -- Jim Manico Manicode Security https://www.manicode.com --------------DD191A6389D154D1AAED0C3F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

> The safest thing for a client is to accept both. 

I politely (and strongly) disagree with this statement. The safest thing for a client is to only accept POST or other verbs where any kind of sensitive data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, even over HTTPS.

Respectfully,
Jim



On 8/11/17 3:18 PM, John Bradley wrote:
OpenID Connect formally defined a POST response mode.


The OAuth 2 spec docent preclude it.  

The safest thing for a client is to accept both.  
The main advantages of POST is that it docent leak in the referrer, and can handle larger responses without the browser choking in some cases.

Size is more of an issue in Connect where a id_token may be returned in the front channel and POST allows for the larger response without the client needing to have JS extract the fragment.

That is why Connect defined it and OAuth largely assumes that for code get is OK.
For security GET responses should add headers to prevent referrer from leaking the code.

We are adding advice on that to the Security document that is being updated now.

John B.


On Aug 11, 2017, at 4:08 PM, Josh Mandel <jmandel@gmail.com> wrote:

Fixing my "with this technique" url: it should have been https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .

On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com> wrote:
Hi All,

I've just encountered a server that performs a redirect (back to the client's redirect_uri) via POST instead of GET. This was surprising behavior to me and broke my client implementation — but citing chapter and verse, the server developer pointed out that https://tools.ietf.org/html/rfc6749#section-1.7 says 

While the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail.

Is triggering a POST-based redirect (e.g. with this technique) to the redirect_url (including url query parameters for state and code) indeed considered a "method available via the user-agent to accomplish this redirection"? In other words, should a well-behaved OAuth client be prepared to receive GETs as well as POSTs to its redirect_uri? If so, what would be the considerations for a server choosing between GET and POST?

Best,

  Josh

_______________________________________________
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


-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------DD191A6389D154D1AAED0C3F-- From nobody Sat Aug 12 09:43:48 2017 Return-Path: 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 9C01412702E for ; Sat, 12 Aug 2017 09:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 q2rOXTefE2sY for ; Sat, 12 Aug 2017 09:43:43 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 2AA14124B0A for ; Sat, 12 Aug 2017 09:43:43 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id v29so35046417qtv.3 for ; Sat, 12 Aug 2017 09:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GXs4Ap0TdKrH7PQCVKafBGqONZrtmG8AN71P7axHKoY=; b=RQFogGNAZbH3wwRHAzE+OsZP+Dcm2e/KZdaNNkekQgD4TAFC9HZPVvmvN3MCbmE5wQ zrh4aI++f9Y90TOAnj+r4HqZGVjVghkgtV97EBeoblkoZhTdP1tJdnYdWDofNVnU1d1q KBf9vL0hitKfC6Ih9zGEk69mhA03YKsMIYinCxFgg0h+aUKLzuOTjroBZQSBAJ4cqs0V g/ayxUsp7YdpyqSDIuQB4y4AyPZ9mrDnBZj11dGTyXUX+j8+BUtgB89pvcJCGWpENe21 NYYv8uBkYdedpXoffpgJOs92cutBaYPFnsLkyZm06ywt4h30mSrDLvPblL0362Ije5yk Fy6Q== 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=GXs4Ap0TdKrH7PQCVKafBGqONZrtmG8AN71P7axHKoY=; b=orDhXCJP9bACng6j93SHUWETCR0FXqZx0gtAdk3Wi1SYPXGl9qMfWKLXCwg+Cp/2DH AdHsvKf0pGBQML6R8YN0RHrmgf5GxXisv41LWydGmwXK24Y0h0XCGDcBHeS7u8chGetd Hot2M7Oz4GlX9nna1GKC3QwWc5DfHLzVv5j0/TjzF7BkRsC9mFrvVQA21BEL766y5HpK Y/lkdBV8O46J+KnRZwE/xWCytRP4n+IDfeW2JDr3YCSLG24bffEyDw3cAK5H0+47hI+q j62vh4ixMx89zVkON5a248qfNxQylTL/b4cgBkVz1ZyDRJ2lZTdCwhMw+J76Lkv+W4+L FH6w== X-Gm-Message-State: AHYfb5ifKpvHpYveB6GHBzYUGbU6gXekQtzByfM7Tr1F3N8YWYIr/hiJ AtuXGzrElmQnWfK+jvFjzY5uEDsR/8NT X-Received: by 10.200.42.228 with SMTP id c33mr26106950qta.290.1502556222056; Sat, 12 Aug 2017 09:43:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.101.13 with HTTP; Sat, 12 Aug 2017 09:43:40 -0700 (PDT) Received: by 10.140.101.13 with HTTP; Sat, 12 Aug 2017 09:43:40 -0700 (PDT) In-Reply-To: <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com> References: <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com> From: John Bradley Date: Sat, 12 Aug 2017 12:43:40 -0400 Message-ID: To: Jim Manico Cc: IETF oauth WG , jmandel@gmail.com Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113f41bee4b6550556912182" Archived-At: Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 16:43:47 -0000 --001a113f41bee4b6550556912182 Content-Type: multipart/alternative; boundary="001a113f41bedf15670556912196" --001a113f41bedf15670556912196 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From a interoperability perspective accepting both is best. Get is mostly OK with the correct headers to stop referer leakage. Fragment should only be used with real JS clients in the browser and not with servers. That is the general direction of the new security advice. People wanting to use POST should probably follow the connect spec for response mode to be explicit about it. John B. On Aug 12, 2017 10:55, "Jim Manico" wrote: > > The *safest* thing for a client is to accept both. > > I politely (and strongly) disagree with this statement. The safest thing > for a client is to only accept POST or other verbs where any kind of > sensitive data is NOT kept in the URL. Sensitive data in URL's leak like = a > sieve, even over HTTPS. > Respectfully, > Jim > > > > On 8/11/17 3:18 PM, John Bradley wrote: > > OpenID Connect formally defined a POST response mode. > > http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html > > The OAuth 2 spec docent preclude it. > > The safest thing for a client is to accept both. > The main advantages of POST is that it docent leak in the referrer, and > can handle larger responses without the browser choking in some cases. > > Size is more of an issue in Connect where a id_token may be returned in > the front channel and POST allows for the larger response without the > client needing to have JS extract the fragment. > > That is why Connect defined it and OAuth largely assumes that for code ge= t > is OK. > For security GET responses should add headers to prevent referrer from > leaking the code. > > We are adding advice on that to the Security document that is being > updated now. > > John B. > > > On Aug 11, 2017, at 4:08 PM, Josh Mandel wrote: > > Fixing my "with this technique" url: it should have been > https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 . > > On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel wrote: > >> Hi All, >> >> I've just encountered a server that performs a redirect (back to the >> client's redirect_uri) via POST instead of GET. This was surprising >> behavior to me and broke my client implementation =E2=80=94 but citing c= hapter and >> verse, the server developer pointed out that https://tools.ietf.org/ht >> ml/rfc6749#section-1.7 says >> >> While the examples in this specification show the use of the HTTP 302 >>> status code, any other method available via the user-agent to accomplis= h >>> this redirection is allowed and is considered to be an implementation >>> detail. >> >> >> Is triggering a POST-based redirect (e.g. with this technique >> ) >> to the redirect_url (including url query parameters for state and code) >> indeed considered a "method available via the user-agent to accomplish t= his >> redirection"? In other words, should a well-behaved OAuth client be >> prepared to receive GETs as well as POSTs to its redirect_uri? If so, wh= at >> would be the considerations for a server choosing between GET and POST? >> >> Best, >> >> Josh >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > Jim Manico > Manicode Securityhttps://www.manicode.com > > --001a113f41bedf15670556912196 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From a interoperability perspective accepting both is bes= t. =C2=A0=C2=A0

Get is mostly = OK with the correct headers to stop referer leakage. =C2=A0 Fragment should= only be used with real JS clients in the browser and not with servers. =C2= =A0

That is the general = direction of the new security advice. =C2=A0

People wanting to use POST should probably follow the = connect spec for response mode to be explicit about it. =C2=A0

John B.=C2=A0

On Aug 12, 2017 10:55, &quo= t;Jim Manico" <jim@manicode.com= > wrote:
=20 =20 =20

> The safest thing for a client is to accept both.=C2=A0

I politely (and strongly) disagree with this statement. The safest thing for a client is to only accept POST or other verbs where any kind of sensitive data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, even over HTTPS.

Respectfully,
Jim



On 8/11/17 3:18 PM,= John Bradley wrote:
=20 OpenID Connect formally defined a POST response mode.


The OAuth 2 spec docent preclude it. =C2=A0

The safest thing for a client is to accept both. =C2=A0
The main advantages of POST is that it docent leak in the referrer, and can handle larger responses without the browser choking in some cases.

Size is more of an issue in Connect where a id_token may be returned in the front channel and POST allows for the larger response without the client needing to have JS extract the fragment.

That is why Connect defined it and OAuth largely assumes that for code get is OK.
For security GET responses should add headers to prevent referrer from leaking the code.

We are adding advice on that to the Security document that is being updated now.

John B.


On Aug 11, 2017, at 4:08 PM, Josh Mandel <jmandel@gmail.com> wrote:<= /div>
Fixing my "with this technique" url: it should have been https://gist.g= ithub.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .

On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com> wrote:
Hi All,

I've just encountered a server that performs a redirect (back to the client's redirect_uri) via POST instead of GET. This was surprising behavior to me and broke my client implementation =E2=80=94 but citing chapter and ver= se, the server developer pointed out that=C2=A0http= s://tools.ietf.org/html/rfc6749#section-1.7 says=C2=A0

Whi= le the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail.


Best,

=C2=A0 Josh

_______________________________________________
OAuth mailing list
OAuth@iet= f.org
https://= www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/oauth


--=20
Jim Manico
Manicode Security
https://www.manicode.com
--001a113f41bedf15670556912196-- --001a113f41bee4b6550556912182 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIJ1eyJ4c7sQbzeORUG7YxfJw2NN7 iGg9vOT7BQA6TTW7MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgxMjE2NDM0MlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBRXv3IDgojlsV3AOVxowvjmInztOJ96QHGPhEw95CsVxoD rw6nvkTpe13rlHlddL1rgFN3a5pVz2lH8ngpzGHSRulNhpNKs1QVsJb/dZfPSXeA6g7SUz3gO51I c5grUgJ/XDjPwx3J9wNiAcv/9m/yUy9D7J8H83EpVpIoKoRld1B2goofIveNxnKElgcvfdVwJiiB lOmV2wI+zCG5SgSCG3WN8voj+roxSOA1s9TtOwVUSiN9DFY12++TgrakRytzN+oLMcYfaJtU0KDi iJ9js9bDC6GUNCaZv8paRuGqPhs7UZj8tC11P8VJH3id0gIdUylE64JhK2w4uVXURg6g --001a113f41bee4b6550556912182-- From nobody Sat Aug 12 12:00:37 2017 Return-Path: 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 232091321AE for ; Sat, 12 Aug 2017 12:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 zDpUg-zWd-SI for ; Sat, 12 Aug 2017 12:00:28 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 DFF6C132623 for ; Sat, 12 Aug 2017 12:00:25 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id g131so57363230oic.3 for ; Sat, 12 Aug 2017 12:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9InTjmWUbJE2s40s8QsIHy2sJZAsBPzKZGHrP3KLSM0=; b=NxxcKpOtDkr8/dR2S9Sy+iCPUiVgr/1qJGd6ykk39UReC/U+NjZnQHJnya3AK0sET2 kGx833FJ5lKTso5c3Y5f8hQ05x6Q31oKG10lRYV3noZtWQZrg1iHP0e1zUiMWoNS/3ss HOvodb3j8uymkEeIc8Lu8WPqjwFBfVtbHPTGeBjKwQoR3WdL3slfjVd0ZbkW3NbkW+VD uoRdLkxJhqtM9sQ0qIrMskjsuH7A6arTHdslEiFL+PAe5pU4SC2EWMMPxy9dqi/9XT0o omDo6qwPzK5P/iUNugJS3vRAHBf1On8XfgUo/VJB6+sUGrnaAGp/TaxAb47H7uXC9bMH Lnaw== 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=9InTjmWUbJE2s40s8QsIHy2sJZAsBPzKZGHrP3KLSM0=; b=cL95AMOCh+YyNWIwU9KQ37I0MoAKO7tWXXgYXz8rERbqSqLwXncvqVXBtou4eirZHK /V5xxOmcOdmJSE04P3I77zdYLh2Y5VWHAwvGpZ2RpYmDQjT49JKMZ2rTMkqdE1Gx7IWS X+D9qV5Q7jaueO7o1rE07QL4LyIz1NXlQmnPawz7+90W8qo8OAE1HS2+EHcAjIz8jny9 B0v6XJ2lnGdU9zXbyjysz0UrF3O/Erpu3x4sChnLfeEpdXOZqC0ZMt5zLGU6yyzapEHa B1xJ1lMYuYS5EZx41fwqETKorKR9CL16In4bD/acdhA8fL5iu7zQL4pOAGhRxztEVr48 bQDw== X-Gm-Message-State: AHYfb5jgZEQFuxSxENM4ZukKzPVq5gg/MN272NBCz4D2w30VV+t38ra+ X9xHHWfSFtXlgPhjoplYZw== X-Received: by 10.202.7.1 with SMTP id 1mr24730466oih.192.1502564425047; Sat, 12 Aug 2017 12:00:25 -0700 (PDT) Received: from [10.97.108.8] (mobile-107-92-61-161.mycingular.net. [107.92.61.161]) by smtp.gmail.com with ESMTPSA id d203sm3923849oif.56.2017.08.12.12.00.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 12:00:23 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-7E3A6E44-B243-4508-8311-6ED4B29E8D99 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Sat, 12 Aug 2017 14:00:22 -0500 Cc: IETF oauth WG , jmandel@gmail.com Content-Transfer-Encoding: 7bit Message-Id: <4127E319-E8F0-4D87-8D7B-7E5F607AB2BE@manicode.com> References: <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com> To: John Bradley Archived-At: Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 19:00:35 -0000 --Apple-Mail-7E3A6E44-B243-4508-8311-6ED4B29E8D99 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Get is mostly OK with the correct headers to stop referrer leakage. Those work in new-ish browsers only. Referrer is only one GET leakage vector= . > Fragment should only be used with real JS clients in the browser and not w= ith servers. =20 Fragment behavior is very different in modern browsers, which is one reason w= hy many security folks recommend against the implicit grant type. (I'll doub= le check on this one) Respectfully, -- Jim Manico @Manicode > On Aug 12, 2017, at 11:43 AM, John Bradley wrote: >=20 > =46rom a interoperability perspective accepting both is best. =20 >=20 > Get is mostly OK with the correct headers to stop referer leakage. Fragm= ent should only be used with real JS clients in the browser and not with ser= vers. =20 >=20 > That is the general direction of the new security advice. =20 >=20 > People wanting to use POST should probably follow the connect spec for res= ponse mode to be explicit about it. =20 >=20 > John B.=20 >=20 >> On Aug 12, 2017 10:55, "Jim Manico" wrote: >> > The safest thing for a client is to accept both. =20 >> I politely (and strongly) disagree with this statement. The safest thing f= or a client is to only accept POST or other verbs where any kind of sensitiv= e data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, ev= en over HTTPS. >>=20 >> Respectfully, >> Jim >>=20 >>=20 >>> On 8/11/17 3:18 PM, John Bradley wrote: >>> OpenID Connect formally defined a POST response mode. >>>=20 >>> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html >>>=20 >>> The OAuth 2 spec docent preclude it. =20 >>>=20 >>> The safest thing for a client is to accept both. =20 >>> The main advantages of POST is that it docent leak in the referrer, and c= an handle larger responses without the browser choking in some cases. >>>=20 >>> Size is more of an issue in Connect where a id_token may be returned in t= he front channel and POST allows for the larger response without the client n= eeding to have JS extract the fragment. >>>=20 >>> That is why Connect defined it and OAuth largely assumes that for code g= et is OK. >>> For security GET responses should add headers to prevent referrer from l= eaking the code. >>>=20 >>> We are adding advice on that to the Security document that is being upda= ted now. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Aug 11, 2017, at 4:08 PM, Josh Mandel wrote: >>>>=20 >>>> Fixing my "with this technique" url: it should have been https://gist.g= ithub.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 . >>>>=20 >>>>> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel wrote= : >>>>> Hi All, >>>>>=20 >>>>> I've just encountered a server that performs a redirect (back to the c= lient's redirect_uri) via POST instead of GET. This was surprising behavior t= o me and broke my client implementation =E2=80=94 but citing chapter and ver= se, the server developer pointed out that https://tools.ietf.org/html/rfc674= 9#section-1.7 says=20 >>>>>=20 >>>>>> While the examples in this specification show the use of the HTTP 302= status code, any other method available via the user-agent to accomplish th= is redirection is allowed and is considered to be an implementation detail. >>>>>=20 >>>>> Is triggering a POST-based redirect (e.g. with this technique) to the r= edirect_url (including url query parameters for state and code) indeed consi= dered a "method available via the user-agent to accomplish this redirection"= ? In other words, should a well-behaved OAuth client be prepared to receive G= ETs as well as POSTs to its redirect_uri? If so, what would be the considera= tions for a server choosing between GET and POST? >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Josh >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> --=20 >> Jim Manico >> Manicode Security >> https://www.manicode.com --Apple-Mail-7E3A6E44-B243-4508-8311-6ED4B29E8D99 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
> Get is mostly OK with the correct headers to stop re= ferrer leakage.

Those work in new-ish browsers only. Referrer is onl= y one GET leakage vector.

>  Fragment should only be used with real JS clients i= n the browser and not with servers.  

Fragment behavior is very= different in modern browsers, which is one reason why many security folks r= ecommend against the implicit grant type. (I'll double check on this one)

R= espectfully,
--
Jim Manico
@Manicode
=

On Aug 12, 2017, at 11:43 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

=46rom a interoperability perspective ac= cepting both is best.   

Get is mostly OK with the correct headers to stop referer leakage.  = ; Fragment should only be used with real JS clients in the browser and not w= ith servers.  

That i= s the general direction of the new security advice.  

People wanting to use POST should probably= follow the connect spec for response mode to be explicit about it.  

John B. 
<= div class=3D"gmail_extra">
On Aug 12, 2017 10:= 55, "Jim Manico" <jim@manicode.com> wrote:
=20 =20 =20

> The safest thing for a client is to accept both. 

I politely (and strongly) disagree with this statement. The safest thing for a client is to only accept POST or other verbs where any kind of sensitive data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, even over HTTPS.

Respectfully,
Jim



On 8/11/17 3:18 PM, J= ohn Bradley wrote:
=20 OpenID Connect formally defined a POST response mode.


The OAuth 2 spec docent preclude it.  

The safest thing for a client is to accept both.  
The main advantages of POST is that it docent leak in the referrer, and can handle larger responses without the browser choking in some cases.

Size is more of an issue in Connect where a id_token may be returned in the front channel and POST allows for the larger response without the client needing to have JS extract the fragment.

That is why Connect defined it and OAuth largely assumes that for code get is OK.
For security GET responses should add headers to prevent referrer from leaking the code.

We are adding advice on that to the Security document that is being updated now.

John B.


On Aug 11, 2017, at 4:08 PM, Josh Mandel <jmandel@gmail.com> wrote:
Fixing my "with this technique" url: it should have been https://gist.git= hub.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .

On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com> wrote:
Hi All,

I've just encountered a server that performs a redirect (back to the client's redirect_uri) via POST instead of GET. This was surprising behavior to me and broke my client implementation =E2=80=94 but citing chapter and vers= e, the server developer pointed out that https://= tools.ietf.org/html/rfc6749#section-1.7 says 

While t= he examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail.

Is triggering a POST-based redirect (e.g. with this technique)= to the redirect_url (including url query parameters for state and code) indeed considered a "method available via the user-agent to accomplish this redirection"? In other words, should a well-behaved OAuth client be prepared to receive GETs as well as POSTs to its redirect_uri? If so, what would be the considerations for a server choosing between GET and POST?

Best,

  Josh

_______________________________________________
OAuth mailing list
OAuth@ietf= .org
https://www.= ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mail=
man/listinfo/oauth


--=20
Jim Manico
Manicode Security
https://www.manicode.com
= --Apple-Mail-7E3A6E44-B243-4508-8311-6ED4B29E8D99-- From nobody Sun Aug 13 08:01:31 2017 Return-Path: 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 AC28C132703 for ; Sun, 13 Aug 2017 08:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1ImPcYCHWga3 for ; Sun, 13 Aug 2017 08:01:28 -0700 (PDT) Received: from p3plsmtpa08-06.prod.phx3.secureserver.net (p3plsmtpa08-06.prod.phx3.secureserver.net [173.201.193.107]) (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 5A6E91326BA for ; Sun, 13 Aug 2017 08:01:28 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id guNsdSAUvyr7CguNsdMIL1; Sun, 13 Aug 2017 08:00:57 -0700 To: IETF oauth WG From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Sun, 13 Aug 2017 18:00:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020600030605050504090909" X-CMAE-Envelope: MS4wfGNoTWXY9FKGuygWSZtAqPOhalgtrK5pXUrXINLtWyptm4NT2VMz+rsQcLSReMks2zlZrsNQBi760vc+8WXTrKgzJ1/SvZk5sbAeMl2pf/GZEVmIancy bjqxZjltexMZ4TuHafXip1j83nuHoA2uE2DQIGYCUD8WISdMiE1COU51 Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-mtls-03: resource server error code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 15:01:30 -0000 This is a cryptographically signed message in MIME format. --------------ms020600030605050504090909 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello, Implementing mTLS on the RS side raised the following question: What error code should the RS return if the x5t#S256 bound to the access token token doesn't match the hash of the submitted client certificate? Here are the error codes already defined in "bearer token usage": https://tools.ietf.org/html/rfc6750#section-3.1 Thanks, Vladimir --------------ms020600030605050504090909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MTMxNTAwNTVaMC8GCSqGSIb3DQEJBDEiBCBTmHsYtaKZ76oA8JBr+ewIJaRe0hbX wYq2zul+3MComTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQCohg1K0gPR J10IEtuUTxTxPduz6LG3K4b9b9uzH3eupbQyiogiTEx7eVWUg/Mu4aKJr31zane5L4NA+kSa HHpUBz0YdLAPJVuaGotnuYc9AwofGE1wyGUPxj61cfCeGys6jhsaNsTGXKa/7/w6I86tPlBz Da5MxTcbHz121yhJVEktnw95PngUu2kwll5p1SKIgXrsaO2Hal7KoywMF+Gx3FdA0OdCn8oP nR6OKV/55YqwLcAY/HmJKdHtxCaT+wyfWvhswsZHK9GBrECtDhA8Ly4YRkphStHhjCuIAOqs 7fcifSfUgYPA41r9Z/5qWbSNJfcmzFZ94gHlu59DdPJKAAAAAAAA --------------ms020600030605050504090909-- From nobody Sun Aug 13 08:21:07 2017 Return-Path: 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 3747B13241E for ; Sun, 13 Aug 2017 08:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YO3kZpCT9lqI for ; Sun, 13 Aug 2017 08:21:03 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 2AEFC1323AB for ; Sun, 13 Aug 2017 08:21:03 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id 16so41572814qtz.4 for ; Sun, 13 Aug 2017 08:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a5PfnvcWt1Mlbn4UjhBQavyhYq2aHRcXMSG6EWfsW8A=; b=YW9a36r0vgxgw3UaaqFa7bnrXIZ93GsC+ddesVSQppudsX6F3rhxHuWSs80sactJGD 9NOX5VfZGRZ7M5JXlSxn59X2+AtQTrS36pyKdDeOIkVH2SdTWWW1vQI193aAd9PQGP9f bOs7FtU5YBNg16yKCKTMd284PLt6OlPFHUx0Bl3o1gtVnumhfJDtw7KbniJ0E4vQ7ILf SyuqPg9TGKoL2Yd7V0Wpn4cCU1uU2IVFRNmrIA8sJCA0nPg7bA9krapzV6kCIh9TFcfz oeOmAvMs9piVHFVCfon+uMwbZcz4jjUMeZfPy1IwDQgFn5qZp0JwtN9m/tKVDbspYfAQ tRMQ== 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=a5PfnvcWt1Mlbn4UjhBQavyhYq2aHRcXMSG6EWfsW8A=; b=EvEtyyreN2fPvnxqiXbailHjNzULSU4w/QBjalkvPhKLHPnLcfLpx2Wc0xLVeypKVv xEdNFsLWA7XMAqwxUVBdKFY1uM5LH3elEtccCQPSSXYMWRdLITqfZZpI4njmcKcp0D8+ dQijlkcyOu4XL+p3FSLQ5sIOKRHMFn+maeFj+y6KpaC0tVq10mSilKAK8pm6O5uI4hO2 jhye5cVfTucO18j7AJgVwV4ZXrf2Z3/Pb331CGKzvypZDmzhjwvpiesx/bHYVl2+tHdi 6jnNbInj4ZdEye45HTlVOdA0sy/b5MGZDomKbn+ISfy3ocbcKdTZZohSQOTxrkFr0jK3 nLSQ== X-Gm-Message-State: AHYfb5jRD/cDDVH12QS9E0mgK3Mpe3OPLrzA4eoSQFhRPsr+1iPEB46l 1cngxe6LbgVA0IYJ+VH9J3YaP0wowg== X-Received: by 10.200.14.72 with SMTP id j8mr29642362qti.124.1502637662351; Sun, 13 Aug 2017 08:21:02 -0700 (PDT) MIME-Version: 1.0 References: <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com> In-Reply-To: <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com> From: Thomas Broyer Date: Sun, 13 Aug 2017 15:20:49 +0000 Message-ID: To: Jim Manico , John Bradley , Josh Mandel Cc: "oauth@ietf.org WG" Content-Type: multipart/alternative; boundary="089e08225dac1735730556a41846" Archived-At: Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 15:21:06 -0000 --089e08225dac1735730556a41846 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rejecting a GET with code in the URL means that the code is never "used" at the AS, so can still be exchanged for an access token; and rejecting the request does not mean it won't leak. So reject if you like from the user's point of view, but "consume" the code anyway (and then immediately revoke the token, maybe), or you're probably making things worse (if you're worried of leaking 5min one-time codes, particularly when that code cannot be used without a client_secret and/or PKCE code_verifier) Disclaimer: not a security expert here. Le sam. 12 ao=C3=BBt 2017 16:55, Jim Manico a =C3=A9crit= : > > The *safest* thing for a client is to accept both. > > I politely (and strongly) disagree with this statement. The safest thing > for a client is to only accept POST or other verbs where any kind of > sensitive data is NOT kept in the URL. Sensitive data in URL's leak like = a > sieve, even over HTTPS. > Respectfully, > Jim > > > > On 8/11/17 3:18 PM, John Bradley wrote: > > OpenID Connect formally defined a POST response mode. > > http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html > > The OAuth 2 spec docent preclude it. > > The safest thing for a client is to accept both. > The main advantages of POST is that it docent leak in the referrer, and > can handle larger responses without the browser choking in some cases. > > Size is more of an issue in Connect where a id_token may be returned in > the front channel and POST allows for the larger response without the > client needing to have JS extract the fragment. > > That is why Connect defined it and OAuth largely assumes that for code ge= t > is OK. > For security GET responses should add headers to prevent referrer from > leaking the code. > > We are adding advice on that to the Security document that is being > updated now. > > John B. > > > On Aug 11, 2017, at 4:08 PM, Josh Mandel wrote: > > Fixing my "with this technique" url: it should have been > https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 . > > On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel wrote: > >> Hi All, >> >> I've just encountered a server that performs a redirect (back to the >> client's redirect_uri) via POST instead of GET. This was surprising >> behavior to me and broke my client implementation =E2=80=94 but citing c= hapter and >> verse, the server developer pointed out that >> https://tools.ietf.org/html/rfc6749#section-1.7 says >> >> While the examples in this specification show the use of the HTTP 302 >>> status code, any other method available via the user-agent to accomplis= h >>> this redirection is allowed and is considered to be an implementation >>> detail. >> >> >> Is triggering a POST-based redirect (e.g. with this technique >> ) >> to the redirect_url (including url query parameters for state and code) >> indeed considered a "method available via the user-agent to accomplish t= his >> redirection"? In other words, should a well-behaved OAuth client be >> prepared to receive GETs as well as POSTs to its redirect_uri? If so, wh= at >> would be the considerations for a server choosing between GET and POST? >> >> Best, >> >> Josh >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > Jim Manico > Manicode Securityhttps://www.manicode.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e08225dac1735730556a41846 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rejecting a GET with code in the URL means that the code is never &qu= ot;used" at the AS, so can still be exchanged for an access token; and= rejecting the request does not mean it won't leak. So reject if you li= ke from the user's point of view, but "consume" the code anyw= ay (and then immediately revoke the token, maybe), or you're probably m= aking things worse (if you're worried of leaking 5min one-time codes, p= articularly when that code cannot be used without a client_secret and/or PK= CE code_verifier)

Disclaimer: not a security expe= rt here.

Le sam. 12 ao= =C3=BBt 2017 16:55, Jim Manico <jim@manicode.com> a =C3=A9crit=C2=A0:

> The safest thing for a client is to accept both.=C2=A0

I politely (and stro= ngly) disagree with this statement. The safest thing for a client is to only accept POST or other verbs where any kind of sensitive data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, even over HTTPS.

Respectfully,
Jim



On 8/11/17 3:18 PM, John Bradley wrote:
=20 OpenID Connect formally defined a POST response mode.


The OAuth 2 spec docent preclude it. =C2=A0

The safest thing for a client is to accept both. =C2=A0
The main advantages of POST is that it docent leak in the referrer, and can handle larger responses without the browser choking in some cases.

Size is more of an issue in Connect where a id_token may be returned in the front channel and POST allows for the larger response without the client needing to have JS extract the fragment.

That is why Connect defined it and OAuth largely assumes that for code get is OK.
For security GET responses should add headers to prevent referrer from leaking the code.

We are adding advice on that to the Security document that is being updated now.

John B.


On Aug 11, 2017, at 4:08 PM, Josh Mandel <jmandel@gmail.com> wrote:<= /div>
Fixing my "with this technique" url: it should have been https://gist.g= ithub.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .

On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com> wrote:
Hi All,

I've just encountered a server that performs a redirect (back to the client's redirect_uri) via POST instead of GET. This was surprising behavior to me and broke my client implementation =E2=80=94 but citing chapter and ver= se, the server developer pointed out that=C2=A0http= s://tools.ietf.org/html/rfc6749#section-1.7 says=C2=A0

Whi= le the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail.


Best,

=C2=A0 Josh

_______________________________________________
OAuth mailing list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth


--=20
Jim Manico
Manicode Security
https://www.manicode=
.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--089e08225dac1735730556a41846-- From nobody Sun Aug 13 09:37:03 2017 Return-Path: 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 CE4B913254E for ; Sun, 13 Aug 2017 09:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 SS_BASR4dsrN for ; Sun, 13 Aug 2017 09:36:58 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 C2F2D1321B7 for ; Sun, 13 Aug 2017 09:36:58 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id y129so32721485pgy.4 for ; Sun, 13 Aug 2017 09:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=d2+HeUBe1knYr2jLGu+W6Ur2kZOSLbdOWajZeqJRURI=; b=bLM5bBjjTt1aypFx8JIhfMVIe3xwv0yUJ3Y4bR9d0wWnUaMq3SzF6vY9qanlo7cFkh AT/bmIRG1yHfUDaxxEYMpO1VCfUbpc55qVFBHd/5O1zCR9QZxxL12kMqjJm6Z1K9/KGp ZWrrPxXIXt9vxMysNB76krWTP0l3CeG1kGFKqIaZrBqLFn+g0niVpFS0W+94MrEGV0pG YNfB7Ij20qRO74Pd8Vkr47XpbOagDKtNaWw+oUAt7YoRKdrcEaTXTyYPdX3lXOi5Pf8o EfJTOM1O1ShA1mnt1as4fdf3isAgD9cQe/3++rJPVQ/2ytrL2n8MxCV0AO6N+MPksWiY lrWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=d2+HeUBe1knYr2jLGu+W6Ur2kZOSLbdOWajZeqJRURI=; b=PTVOTlQW4vvrUZcomkFun4CdXGiIF2MjZ2vIe0U+kClWHCoA6x9vmv3W+5xIby9PIv hy/Kd2BShBXVxw2w+G8AOVpJormMcRZqhV/LyuOvNJRLdwcfOgA5KhScwCzP1bhrco04 uwWa0flh+WlxcmUNusRcRBB1aLtJzOAWA5jVjyZVNSg1IhsCriJlSaAFrevWelBvMQ+u 9AiMCx7o+0Pd1Zp6KYMsmQEzn+4OoVO3gZpu3NrqScCOYN/3BDwWQSS4BriYas2tgq08 2RK1o7bP1HZvsZq6n1t7OtKG2kYSZ6Ts5869N7c103PMitkmD+D4Tpsd8DchYcTZh0yr ROsw== X-Gm-Message-State: AHYfb5jSNWlzr+BTt2XRGp8pVXXWc0UlUEJgUa+QS11N7P1zHStZyTIa JTvo3ZT2waKZ1STkaXE0VA== X-Received: by 10.84.229.75 with SMTP id d11mr25022991pln.207.1502642218012; Sun, 13 Aug 2017 09:36:58 -0700 (PDT) Received: from heembo.local (zipline.atenlabs.com. [206.251.244.230]) by smtp.googlemail.com with ESMTPSA id k4sm11710979pfk.26.2017.08.13.09.36.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2017 09:36:57 -0700 (PDT) To: Thomas Broyer , John Bradley , Josh Mandel Cc: "oauth@ietf.org WG" References: <41d07f67-bb16-1a82-95cb-00b898a5cba2@manicode.com> From: Jim Manico Message-ID: <24f0dd9a-4102-5dc7-b32c-fcb103f48c88@manicode.com> Date: Sun, 13 Aug 2017 12:36:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA10A36F4BF8C1C43446A646" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 16:37:02 -0000 This is a multi-part message in MIME format. --------------EA10A36F4BF8C1C43446A646 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit > Rejecting a GET with code in the URL means that the code is never "used" at the AS, so can still be exchanged for an access token; and rejecting the request does not mean it won't leak That's a good point Thomas. I still think secure OAuth workflows should totally avoid putting any kind of sensitive data in URI's for any step, including POST /Actions/ that leak like a GET query parameter. > So reject if you like from the user's point of view, but "consume" the code anyway (and then immediately revoke the token, maybe), or you're probably making things worse Interesting point, but I think if the standard reflected this suggestion it would be less likely that implementer will do it. > (if you're worried of leaking 5min one-time codes, particularly when that code cannot be used without a client_secret and/or PKCE code_verifier) Also a good point. This specific step in the workflow might not be at risk as much as other steps, but I see a LOT of folks putting sensitive data in tokens and I'm trying to help avoid that leakage. Thanks for your feedback. Aloha, Jim On 8/13/17 11:20 AM, Thomas Broyer wrote: > Rejecting a GET with code in the URL means that the code is never > "used" at the AS, so can still be exchanged for an access token; and > rejecting the request does not mean it won't leak. So reject if you > like from the user's point of view, but "consume" the code anyway (and > then immediately revoke the token, maybe), or you're probably making > things worse (if you're worried of leaking 5min one-time codes, > particularly when that code cannot be used without a client_secret > and/or PKCE code_verifier) > > Disclaimer: not a security expert here. > > Le sam. 12 août 2017 16:55, Jim Manico > a écrit : > > > The _*safest*_ thing for a client is to accept both. > > I politely (and strongly) disagree with this statement. The safest > thing for a client is to only accept POST or other verbs where any > kind of sensitive data is NOT kept in the URL. Sensitive data in > URL's leak like a sieve, even over HTTPS. > > Respectfully, > Jim > > > > On 8/11/17 3:18 PM, John Bradley wrote: >> OpenID Connect formally defined a POST response mode. >> >> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html >> >> The OAuth 2 spec docent preclude it. >> >> The safest thing for a client is to accept both. >> The main advantages of POST is that it docent leak in the >> referrer, and can handle larger responses without the browser >> choking in some cases. >> >> Size is more of an issue in Connect where a id_token may be >> returned in the front channel and POST allows for the larger >> response without the client needing to have JS extract the fragment. >> >> That is why Connect defined it and OAuth largely assumes that for >> code get is OK. >> For security GET responses should add headers to prevent referrer >> from leaking the code. >> >> We are adding advice on that to the Security document that is >> being updated now. >> >> John B. >> >> >>> On Aug 11, 2017, at 4:08 PM, Josh Mandel >> > wrote: >>> >>> Fixing my "with this technique" url: it should have been >>> https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 . >>> >>> On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel >> > wrote: >>> >>> Hi All, >>> >>> I've just encountered a server that performs a redirect >>> (back to the client's redirect_uri) via POST instead of GET. >>> This was surprising behavior to me and broke my client >>> implementation — but citing chapter and verse, the server >>> developer pointed out >>> that https://tools.ietf.org/html/rfc6749#section-1.7 says >>> >>> While the examples in this specification show the use of >>> the HTTP 302 status code, any other method available via >>> the user-agent to accomplish this redirection is allowed >>> and is considered to be an implementation detail. >>> >>> >>> Is triggering a POST-based redirect (e.g. with this >>> technique >>> ) >>> to the redirect_url (including url query parameters for >>> state and code) indeed considered a "method available via >>> the user-agent to accomplish this redirection"? In other >>> words, should a well-behaved OAuth client be prepared to >>> receive GETs as well as POSTs to its redirect_uri? If so, >>> what would be the considerations for a server choosing >>> between GET and POST? >>> >>> Best, >>> >>> Josh >>> >>> >>> _______________________________________________ >>> 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 > > -- > Jim Manico > Manicode Security > https://www.manicode.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Jim Manico Manicode Security https://www.manicode.com --------------EA10A36F4BF8C1C43446A646 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

> Rejecting a GET with code in the URL means that the code is never "used" at the AS, so can still be exchanged for an access token; and rejecting the request does not mean it won't leak

That's a good point Thomas. I still think secure OAuth workflows should totally avoid putting any kind of sensitive data in URI's for any step, including POST Actions that leak like a GET query parameter.

> So reject if you like from the user's point of view, but "consume" the code anyway (and then immediately revoke the token, maybe), or you're probably making things worse

Interesting point, but I think if the standard reflected this suggestion it would be less likely that implementer will do it.

> (if you're worried of leaking 5min one-time codes, particularly when that code cannot be used without a client_secret and/or PKCE code_verifier)

Also a good point. This specific step in the workflow might not be at risk as much as other steps, but I see a LOT of folks putting sensitive data in tokens and I'm trying to help avoid that leakage.

Thanks for your feedback.

Aloha, Jim


On 8/13/17 11:20 AM, Thomas Broyer wrote:
Rejecting a GET with code in the URL means that the code is never "used" at the AS, so can still be exchanged for an access token; and rejecting the request does not mean it won't leak. So reject if you like from the user's point of view, but "consume" the code anyway (and then immediately revoke the token, maybe), or you're probably making things worse (if you're worried of leaking 5min one-time codes, particularly when that code cannot be used without a client_secret and/or PKCE code_verifier)

Disclaimer: not a security expert here.

Le sam. 12 août 2017 16:55, Jim Manico <jim@manicode.com> a écrit :

> The safest thing for a client is to accept both. 

I politely (and strongly) disagree with this statement. The safest thing for a client is to only accept POST or other verbs where any kind of sensitive data is NOT kept in the URL. Sensitive data in URL's leak like a sieve, even over HTTPS.

Respectfully,
Jim



On 8/11/17 3:18 PM, John Bradley wrote:
OpenID Connect formally defined a POST response mode.


The OAuth 2 spec docent preclude it.  

The safest thing for a client is to accept both.  
The main advantages of POST is that it docent leak in the referrer, and can handle larger responses without the browser choking in some cases.

Size is more of an issue in Connect where a id_token may be returned in the front channel and POST allows for the larger response without the client needing to have JS extract the fragment.

That is why Connect defined it and OAuth largely assumes that for code get is OK.
For security GET responses should add headers to prevent referrer from leaking the code.

We are adding advice on that to the Security document that is being updated now.

John B.


On Aug 11, 2017, at 4:08 PM, Josh Mandel <jmandel@gmail.com> wrote:

Fixing my "with this technique" url: it should have been https://gist.github.com/jmandel/4704d1efed8578a67a6f9b600ffd0c63 .

On Fri, Aug 11, 2017 at 4:00 PM, Josh Mandel <jmandel@gmail.com> wrote:
Hi All,

I've just encountered a server that performs a redirect (back to the client's redirect_uri) via POST instead of GET. This was surprising behavior to me and broke my client implementation — but citing chapter and verse, the server developer pointed out that https://tools.ietf.org/html/rfc6749#section-1.7 says 

While the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail.

Is triggering a POST-based redirect (e.g. with this technique) to the redirect_url (including url query parameters for state and code) indeed considered a "method available via the user-agent to accomplish this redirection"? In other words, should a well-behaved OAuth client be prepared to receive GETs as well as POSTs to its redirect_uri? If so, what would be the considerations for a server choosing between GET and POST?

Best,

  Josh

_______________________________________________
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


-- 
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------EA10A36F4BF8C1C43446A646-- From nobody Wed Aug 23 04:21:03 2017 Return-Path: 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 0254C132223 for ; Wed, 23 Aug 2017 04:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 3tL9cmsByfnR for ; Wed, 23 Aug 2017 04:21:00 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 E9266132392 for ; Wed, 23 Aug 2017 04:20:59 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id g135so6265733iog.1 for ; Wed, 23 Aug 2017 04:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OCL0zJ10sJZAGDPj6SaLR4GOze+BbT0agoXJiXx1fmE=; b=c0MI3CuE5tKpNO9WjqbblBkV4Oox8KGkv1XeXbMRLlfS0bD0en9cSU5wy/qw3Jo15B hFI1e0ZnQBRwlQ3nbfMB4QcgapprHzPJEKsOWtlFEzoF+8eJ6zbhqSZkN1PYlyMNuSE8 Tj4sSGeyMmjQ//cyruHpeUFFbOJpb3wS5p7XA= 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=OCL0zJ10sJZAGDPj6SaLR4GOze+BbT0agoXJiXx1fmE=; b=ukOL0qg8ciURNsS2f+AW6cOlgaLsLlnonKFgYTVNW8GKqxuXeABzoUFkXxJDMCVEQS Kq7aSSCJUVLCEAWpGg2YposV9arNZzlA+BJHd/yPjZej0+nQbnguV1BO3Ekui/XENDhC +I6iT03hyEtvDQWFzonxm9Qk2D8RGc5i33kXMHgYtsKYjOwx5pN0rjUwajg/GaEND4ZY CcKGIJGGeB/h6FQ10ZrxJ43KJH7OYD2mRefCuyajl2b/hhQ5fs0ugfCCxXQWpddZzN1L h4CBHVJdg7wD+o54YCEfzVxJrT65c9Wq37CKLuRO4PHzjDfA1VnFsctTXWiumwbYAlpO 35Lw== X-Gm-Message-State: AHYfb5iiDBUNUU7OSHLF8xjJ43T04WMHPKRgPJhOAf4yyvLc/FbKhoFm oPI86wOAhtu/oNOsecrnRErtn5SEqoHVLmNU0u+6oyCAAjr3WppOSZMcJ4aKltCiXB0p/PDF/tN 9lsFqPpw= X-Received: by 10.107.17.5 with SMTP id z5mr1931216ioi.35.1503487258228; Wed, 23 Aug 2017 04:20:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.29 with HTTP; Wed, 23 Aug 2017 04:20:27 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 23 Aug 2017 05:20:27 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="001a113ed74ef3a3f3055769e768" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: resource server error code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 11:21:02 -0000 --001a113ed74ef3a3f3055769e768 Content-Type: text/plain; charset="UTF-8" "invalid_token" according to the last paragraph of https://tools.ietf.org/html/draft-ietf-oauth-mtls-03#section-3 which says that the RS, 'MUST verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt MUST be rejected with an error per [RFC6750] using an HTTP 401 status code and the "invalid_token" error code.' On Sun, Aug 13, 2017 at 9:00 AM, Vladimir Dzhuvinov wrote: > Hello, > > Implementing mTLS on the RS side raised the following question: > > What error code should the RS return if the x5t#S256 bound to the access > token token doesn't match the hash of the submitted client certificate? > > Here are the error codes already defined in "bearer token usage": > > https://tools.ietf.org/html/rfc6750#section-3.1 > > Thanks, > Vladimir > > > _______________________________________________ > 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.* --001a113ed74ef3a3f3055769e768 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"invalid_token" according to the last paragraph = of https://tools.ietf.org/html/draft-ietf-oauth-mtls-03#section-3 which= says that the RS, 'MUST verify that the certificate matches the certif= icate associated with the access token.=C2=A0 If they do not match, the res= ource access attempt MUST be rejected with an error per [RFC6750] using an = HTTP 401 status code and the "invalid_token" error code.'
=


On = Sun, Aug 13, 2017 at 9:00 AM, Vladimir Dzhuvinov <vladimir@connect2i= d.com> wrote:
Hello,

Implementing mTLS on the RS side raised the following question:

What error code should the RS return if the x5t#S256 bound to the access token token doesn't match the hash of the submitted client certificate?=

Here are the error codes already defined in "bearer token usage":=

https://tools.ietf.org/html/rfc6750#section-3.1<= /a>

Thanks,
Vladimir


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a113ed74ef3a3f3055769e768-- From nobody Wed Aug 23 04:24:06 2017 Return-Path: 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 C365513294F for ; Wed, 23 Aug 2017 04:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 SpxEY5mteM3C for ; Wed, 23 Aug 2017 04:24:03 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 2B7531320CF for ; Wed, 23 Aug 2017 04:15:37 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id x187so8273353ite.1 for ; Wed, 23 Aug 2017 04:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=85VRH04Vzr9bUZ/DW2GF435vJbaTgD0jrhp7y/EDrDA=; b=KRW9Z6QX9ZnzgQ3OiuCFV2CZPXWlIpfHBIFz1Mp/s+8IAOV/5qqDLMbA44Z0Zx/JkH DACwx7n9B1y2L7UVmIO6sBEsBt5bpowyyF6BZzHRHk2AT3dIotr4PKL1DbwpL/tXYtft eOcQoB4Jh2XGcR7Al2ezviWiTVkdyIVN8eFrU= 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=85VRH04Vzr9bUZ/DW2GF435vJbaTgD0jrhp7y/EDrDA=; b=i3bFh7T/R+6uLp2cvnrPTLvaKsi1cNMcXPcCSTjM6bxs9ts/m/jVjBJQbXgxs9IgOV W7FMbQIaMuugYcF1xu+k+kYg7ggsiemjYJj2muqzZdo8JuWnblC4QiY6CxAVnFpqCRXI 39G1BcE2KxdFpE5+8pZZBopweUGizbyrt7sd9AaBv2ZIPiXYb6Edlg7Ah/TAJchECgyi OcMRTIV6VnRQ2NuT/f36CP6e5o5N4dZWG5jvS6qTyJtBg+6H2eR38EvWEyKj+SojzKwZ 1xwRFTMXNQov7S5vX28OtdOGI5BL14bz+m3Sb2B11q3YB7a2hTyTWSCHnVqeJeIgMbsf bnBA== X-Gm-Message-State: AHYfb5j51izsoy6uHHzRJ93wlYtE6u+6xYJa/gy377M9lqbBYLfQ/0dA Z/w753fVgAw0RLiWrCPbx5RFA4OdTEvX6nSswIVUXkETyLSY3KUbkyWemZuToY/BNPjP7lIWONi jU9ma X-Received: by 10.36.118.211 with SMTP id z202mr2928734itb.82.1503486936379; Wed, 23 Aug 2017 04:15:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.29 with HTTP; Wed, 23 Aug 2017 04:15:05 -0700 (PDT) In-Reply-To: <5CB52046-8233-4684-961B-C49C6F042F40@ve7jtb.com> References: <5CB52046-8233-4684-961B-C49C6F042F40@ve7jtb.com> From: Brian Campbell Date: Wed, 23 Aug 2017 05:15:05 -0600 Message-ID: To: John Bradley Cc: Vladimir Dzhuvinov , oauth Content-Type: multipart/alternative; boundary="001a11441236c49760055769d4a0" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03 - auth to other endpoints? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 11:24:05 -0000 --001a11441236c49760055769d4a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, we definitely didn't intend for it to be exclusive to the token endpoint. I think the text kinda came out that way as an artifact of the way some of these specs are layered and when they were written as well as some assumptions on my part that it would be understood that this client authentication could be applicable to the other places OAuth client authentication is used. We will clarify things in the next draft. On Mon, Aug 7, 2017 at 10:28 AM, John Bradley wrote: > Good point, I don=E2=80=99t think we intended it to be exclusive to the = token > endpoint. It is another client auth method and should work those other > places as well. I will need to look at the other specs to see how they > incorporate client auth methods. > > Thanks > John B. > > > On Aug 7, 2017, at 11:17 AM, Vladimir Dzhuvinov > wrote: > > > > I just noticed that the spec is very explicit on the MTLS auth method > > being used for the token endpoint, but it could also work with other > > endpoints, e.g. RFC 7009 (revocation), 7662 (intospection). > > > > Were there any talks about that? > > > > Vladimir > > > > _______________________________________________ > > 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 > > --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --001a11441236c49760055769d4a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, we definitely didn't intend for it to be exclusi= ve to the token endpoint. I think the text kinda came out that way as an ar= tifact of the way some of these specs are layered and when they were writte= n as well as some assumptions on my part that it would be understood that t= his client authentication could be applicable to the other places OAuth cli= ent authentication is used. We will clarify things in the next draft.
<= div class=3D"gmail_extra">
On Mon, Aug 7, 201= 7 at 10:28 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good point,=C2=A0 I don=E2=80=99t think we int= ended it to be exclusive to the token endpoint.=C2=A0 It is another client = auth method and should work those other places as well.=C2=A0 =C2=A0I will = need to look at the other specs to see how they incorporate client auth met= hods.

Thanks
John B.

> On Aug 7, 2017, at 11:17 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> = wrote:
>
> I just noticed that the spec is very explicit on the MTLS auth method<= br> > being used for the token endpoint, but it could also work with other > endpoints, e.g. RFC 7009 (revocation), 7662 (intospection).
>
> Were there any talks about that?
>
> Vladimir
>
> _______________________________________________
> 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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a11441236c49760055769d4a0-- From nobody Wed Aug 23 15:21:51 2017 Return-Path: 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 73F65132A1E for ; Wed, 23 Aug 2017 15:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mJpnHyyjwYw4 for ; Wed, 23 Aug 2017 15:21:49 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 C966D1321C8 for ; Wed, 23 Aug 2017 15:21:48 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id r199so4902109vke.4 for ; Wed, 23 Aug 2017 15:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0DOY7ab+YBjhlgTHkwsAgAaIC3jS7xx4P8U2Oex5x1E=; b=mS4SE+UsjN7lPStcjdLAYuHaCleIoskIrs3cwztlMq/RyKjExdf/9+y2T+GNagm7Ax PbdFlWw5SWpjaugK/ORMRcB+70jQuABlLfRwfvuYjst3wOvT4YTPkCU1Dw0mY+x4Za8I dWDywpnokslUkuytE5ZvP47sL8lc1shwWgNeR6SDEOJgEnorrrcJkXSeKlCoFKRPmNGv 68+cgWmr87vFZedbXIPhsX7rqmLzF+G2c7vkQSYNG6qEkRhqcJq5VVEkaZOzZwoJs7jx RK5Gbv/OJC7asfIllSJoeZSysHHaXR+IEtUvc1wCL9hQmF8rrqZ09gn1B3E3AqMCbIxM LQ2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0DOY7ab+YBjhlgTHkwsAgAaIC3jS7xx4P8U2Oex5x1E=; b=DmsLLr65Oqfns0e0ZG1cTnuB0DRar0xqAg6UIK1kWdTovyWwiooLiuy/mt7hbYvsth BQz/8X5likfe1u9PZgdpEsXw4eBhTyIj8mF8U9C1A8/k7UVO0y1W2lIct8k8IdriU/I+ znkGS50I9lQuizFbbT5ydsQ46ptfSBwm+jpeJFQf3wzta+V1cn+H+BSh+iCzhD9b2EAA /ZIJJwc7PK6R0wGLWwcZgXUc8cUF9QRmmiwCdyIT9OaF0JfQdl/P18Eo86qzjW6gME3P e45lcy0ET05cmi4OR95cgc8EUr8GDp+Jp01B7B9Qes3V0qZPiiL854AOt6NiwGFY43Mj M2WQ== X-Gm-Message-State: AHYfb5hzjd/7S+5CHbhiOKwLeYVnATwyGQxCBuR7yL2hcBiWrmCSNnYf tuRtE6rYgVMBkEonYboAgimAu9gbRw== X-Received: by 10.31.96.149 with SMTP id u143mr3106607vkb.101.1503526907616; Wed, 23 Aug 2017 15:21:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.93.47 with HTTP; Wed, 23 Aug 2017 15:21:47 -0700 (PDT) From: Malla Simhachalam Date: Wed, 23 Aug 2017 15:21:47 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="001a114e5fec3d23b70557732358" Archived-At: Subject: [OAUTH-WG] Obtaining authorized scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 22:21:50 -0000 --001a114e5fec3d23b70557732358 Content-Type: text/plain; charset="UTF-8" Hi, We have an OAuth token revocation specification to revoke consents from an external/relying party with a given token. I am wondering if there's a specification around retrieving granted scopes using a given token for external relying party. thanks Malla --001a114e5fec3d23b70557732358 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We have an OAuth token rev= ocation specification to revoke consents from an external/relying party wit= h a given token. I am wondering if there's a specification around retri= eving granted scopes using a given token for external relying party.
thanks
Malla
--001a114e5fec3d23b70557732358-- From nobody Wed Aug 23 23:38:44 2017 Return-Path: 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 E449D12700F for ; Wed, 23 Aug 2017 23:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9Z5Yfu8vsrnV for ; Wed, 23 Aug 2017 23:38:41 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 3D393126E64 for ; Wed, 23 Aug 2017 23:38:41 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id p10so11187957qte.1 for ; Wed, 23 Aug 2017 23:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AiEidPoX1Qra+7c2dlSSdZArUuukc8Jyv6FkkcitZno=; b=Z/OtMWpmB2H7uJtyBhM4WoM4Whf3wTdi3FwNMZ2nE9MYV+UcH5fCQeIF4eksQtaudT SsW09rFdNULgJI1VNuOU69lLzS6U0qXEfEXQzOe+DlamEB47GuUJCzqbH12jlvbaLbhP HxUN5cCLuGpM/IWU1iaD+pw1li/k62bxamzk6Rjy5OcCzNaHsXyOp18AJ17gWHx4bSHj XDH/kSUbnT6LblLhgm64YL6EreFIFfV4BU9Vl737945UABFEE3+1fyY/rLvsEhyIO58b /wLbbzRM35aPumujKi8p3pBBspNN9cY7ye0uiHyNQSwR6ewGV/v6vdNsjwoDaPkCxAZC aYLg== 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; bh=AiEidPoX1Qra+7c2dlSSdZArUuukc8Jyv6FkkcitZno=; b=tZjqAx9+gn8x5saXnq/TdwIu0Z7psbltXWxN2cjotoU94tawSTjEQi6vUdifj9lxzf 4RHW0QqX7A3TjdL7HoERqQLj46ci6nJU/zGRlGHD8Y7hqoER16UWoaWuOYuBo7Q4jQbl GpO4OkISIMQrV+YZv/lIa5Sf4F5rPykh3Z5sceL1FuUIsPgp4iYctdGt2rDz+FvyGABg xPqDHEE0/a+rVummptZogoLZPQtHSGAgMvCvX0YTgTLBuAeMcrzRU5qu9kvYNsb7G0No /4K9zBsWl9DdAURorGUJrhBBw46etZDWlm9dFvTVme605irTvx2L4OgiA3muzGY5sKPZ dDew== X-Gm-Message-State: AHYfb5hBQ9LCV/Dx1BqWrwuqqw/J9VEBNBjjt0JXKCVaPb9Ip2Axxkjz qImRgxgU/Oc+TcSMp10WqdHtjp+aog== X-Received: by 10.200.40.9 with SMTP id 9mr7226581qtq.325.1503556720345; Wed, 23 Aug 2017 23:38:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Broyer Date: Thu, 24 Aug 2017 06:38:29 +0000 Message-ID: To: Malla Simhachalam , oauth@ietf.org Content-Type: multipart/alternative; boundary="001a1142364837482f05577a148a" Archived-At: Subject: Re: [OAUTH-WG] Obtaining authorized scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 06:38:43 -0000 --001a1142364837482f05577a148a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are you looking for Token Introspection? https://tools.ietf.org/html/rfc7662 On jeu. 24 ao=C3=BBt 2017 00:21 Malla Simhachalam wrote: > Hi, > > We have an OAuth token revocation specification to revoke consents from a= n > external/relying party with a given token. I am wondering if there's a > specification around retrieving granted scopes using a given token for > external relying party. > > thanks > Malla > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1142364837482f05577a148a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Are you looking for Token Introspection?
https://tools.ietf.org/html= /rfc7662


On jeu. 24 ao=C3=BBt 2017 0= 0:21 Malla Simhachalam <ma= llasimhachalam@gmail.com> wrote:
Hi,

We have an OAuth toke= n revocation specification to revoke consents from an external/relying part= y with a given token. I am wondering if there's a specification around = retrieving granted scopes using a given token for external relying party.
thanks
Malla
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a1142364837482f05577a148a-- From nobody Sun Aug 27 00:47:34 2017 Return-Path: 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 077FC132C27 for ; Sun, 27 Aug 2017 00:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 S_3m8eA0l8te for ; Sun, 27 Aug 2017 00:47:31 -0700 (PDT) Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) (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 5BE6D132C03 for ; Sun, 27 Aug 2017 00:47:31 -0700 (PDT) Received: from [192.168.1.80] ([94.68.122.137]) by :SMTPAUTH: with SMTP id lsHadKUI1euGGlsHbdqiMf; Sun, 27 Aug 2017 00:46:59 -0700 To: IETF oauth WG From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <50944e7c-a958-1d59-c68d-77f1c68db05c@connect2id.com> Date: Sun, 27 Aug 2017 10:46:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040001000406010602010706" X-CMAE-Envelope: MS4wfMGo9Qft0sxQdHmHWdR8TxbtOKt5euCIZPX3twaDmvIgnHA0Cu5QCcFAcOiDcxC6gxfaYFcAn7g6NvyGyzpeGQOHdAaDAFhQEBAAds5aTMqtgcrkgi6p r2KrT0Uwy1WHXoQM/b0ERJeHLIeNvVB/Y9GtA2eXdyc2rgrsLoWEUXCA Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-mtls-03: enforcing mutual_tls_sender_constrained_access_tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 07:47:33 -0000 This is a cryptographically signed message in MIME format. --------------ms040001000406010602010706 Content-Type: multipart/alternative; boundary="------------3480D78AD5B90010F5CD669D" Content-Language: en-US This is a multi-part message in MIME format. --------------3480D78AD5B90010F5CD669D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Let's suppose that an OAuth 2.0 client is registered for mutual_tls_sender_constrained_access_tokens=3Dtrue Is it correct that in the presence of this parameter, and regardless of how "token_endpoint_auth_method" is set, the AS must require a client X.509 cert to be passed to the token endpoint? If yes, then what error should the AS return if no client cert is passed with the token request? https://tools.ietf.org/html/rfc6749#section-5.2 Thanks, Vladimir PS: Noticed a typo - "manor" in #section-4.3 --------------3480D78AD5B90010F5CD669D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Let's suppose that an OAuth 2.0 client is registered for 
mutual_tls_sender_constrained_access_tokens=3D=
true
Is it correct that in the presence of this parameter, and regardless of how "token_endpoint_auth_method" is set, the AS must require a client X.509 cert to be passed to the token endpoint? If yes, then what error should the AS return if no client cert is passed with the token request?

https://tools.ietf.org/html/rfc6749#section-5.2

Thanks,

Vladimir

PS: Noticed a typo - "manor" in #section-4.3
--------------3480D78AD5B90010F5CD669D-- --------------ms040001000406010602010706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MjcwNzQ2NTdaMC8GCSqGSIb3DQEJBDEiBCDk2Uk6f5WweaGqPh7nNQNDcGJavjG+ dXu1kUmNr/6kNzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQC7TBp4KlMR Mfo3NQh90rAPxEWhNPwpzMRpQCnjmfZoQcPUC1Ao2bftZC1nfOs5LdmEEs7H2ket/9Q+2aSr U6jXsvZSypZvS/s7f7pOgY+ruNdj89CV1o41c9HiH6yMciM/+G+ShVREYCYrgSI0/4VYRhDi mvh2VUaosFu5n6ZW1wsAo29oi8M8tpTyocsLALIwMg/UBGk5iuDWl2vnchgAmYBW6bk2PqIP DT9zd7jsffrE+Tk0tCGRzE2MtvHwj53QLUvtaHiW7agqEJUApgQ1a5hgeYmAP4lwutxIFmvZ gAsThxC7ZL7sY61euuvrwX/qJmjQNG3EFzzLgsEGOgvPAAAAAAAA --------------ms040001000406010602010706-- From nobody Mon Aug 28 08:54:21 2017 Return-Path: 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 60FD3132027 for ; Mon, 28 Aug 2017 08:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 sV7ECQDxHvBr for ; Mon, 28 Aug 2017 08:54:18 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 843B2126C7A for ; Mon, 28 Aug 2017 08:54:18 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id o132so3665700itc.1 for ; Mon, 28 Aug 2017 08:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0xvqzSo3SPXVXmYWuInLhm6F9M93NjXkkWeu6a6cmdY=; b=mk7xPaZ4IrwKohAJ7SHgYO8zAL1Sc+SOSS+bItM2gkX1xVWcWNzAYXqLJa3/kLH3ZM OTV0/54kQ16In2/2mN9/xQ50lqdCk3jvJ+KqUpyDvRwAcVBRWZDL0rzatpiD8inSYbQa HTWovKq6slS5xXM50rBx2fNZ5afq0SS1wJQ0M= 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=0xvqzSo3SPXVXmYWuInLhm6F9M93NjXkkWeu6a6cmdY=; b=nQ8C4wfoaYasViNvz1TkkBg9JNO5/8LMN2C/yqodEgaQM7MU8iQr00UchyRtoyhAZ4 UOvEJFPHMw27TxmKnhqpzhoPGxAiaLeWd+32c9Kb9Gxq5REJDfnZ0PKrd0yLzJaFTg/7 HDUWRlcCAA6kjAIAg/mN3IdgRSVUhi2gzDAcDRyNwcdd39Cw0D9M+rseVgVDhkwjZGfy 7+pnB/sqEcPgTny/nLF8Es4pNEx0SkhwNwbAM01UI9Nv1sip7JYVvRrxbkS9syVbAoOT sGtVa8sy2GwlkniVg817WlJTgVOYAlOlbhMbeZ5vmTQ3eVYQQ6Fe4bTY7fHSDRbFrJa3 TLHA== X-Gm-Message-State: AHYfb5juyJPeeBtTDfeSwZ8sRNLpEb+9QQe0BMFm53Xy5ZgUFvCIsqgE 26zaqkPQU+Gk48M9KAhRaNaRr6syvUjQH8+xZh1vjGCzk62qVHcCbNXhqpQ4ebk+jNGx2EMRTC+ s20pv X-Received: by 10.36.13.20 with SMTP id 20mr1084223itx.102.1503935657774; Mon, 28 Aug 2017 08:54:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.67.134 with HTTP; Mon, 28 Aug 2017 08:53:47 -0700 (PDT) In-Reply-To: <50944e7c-a958-1d59-c68d-77f1c68db05c@connect2id.com> References: <50944e7c-a958-1d59-c68d-77f1c68db05c@connect2id.com> From: Brian Campbell Date: Mon, 28 Aug 2017 09:53:47 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="001a11441994a5b2cf0557d24e48" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: enforcing mutual_tls_sender_constrained_access_tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 15:54:20 -0000 --001a11441994a5b2cf0557d24e48 Content-Type: text/plain; charset="UTF-8" "invalid_client" is the appropriate error, if the client is configured/registered for MTLS authentication, because it's effectively failed client authentication. I would say that "invalid_request" is probably the appropriate error for a public client with mutual_tls_sender_constrained_access_tokens=true that doesn't provide the TLS client certificate with the token request. There is effectively a missing required parameter in the context of the request. On Sun, Aug 27, 2017 at 1:46 AM, Vladimir Dzhuvinov wrote: > Let's suppose that an OAuth 2.0 client is registered for > > mutual_tls_sender_constrained_access_tokens=true > > > Is it correct that in the presence of this parameter, and regardless of > how "token_endpoint_auth_method" is set, the AS must require a client X.509 > cert to be passed to the token endpoint? If yes, then what error should the > AS return if no client cert is passed with the token request? > > https://tools.ietf.org/html/rfc6749#section-5.2 > > Thanks, > > Vladimir > > PS: Noticed a typo - "manor" in #section-4.3 > > _______________________________________________ > 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.* --001a11441994a5b2cf0557d24e48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"invalid_client" is the appropriate error, if t= he client is configured/registered for MTLS authentication, because it'= s effectively failed client authentication.

I would say that "= invalid_request" is probably the appropriate error for a public client= with mutual_tls_sender_constrained_access_tokens=3Dtrue that doesn= 9;t provide the TLS client certificate with the token request. There is eff= ectively a missing required parameter in the context of the request.=C2=A0 =

On Sun, Aug 2= 7, 2017 at 1:46 AM, Vladimir Dzhuvinov <vladimir@connect2id.com&= gt; wrote:
=20 =20 =20
Let's suppose that an OAuth 2.0 client is registered for 
mutual_=
tls_sender_constrained_access_tokens=3Dtrue
Is it correct that in the presence of this parameter, and regardless of how "token_endpoint_auth_method" is set, the AS must requi= re a client X.509 cert to be passed to the token endpoint? If yes, then what error should the AS return if no client cert is passed with the token request?

https://tools.ietf.org/html/rfc6749#section-5.2

Thanks,

Vladimir

PS: Noticed a typo - "manor" in #section-4.3

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a11441994a5b2cf0557d24e48-- From nobody Mon Aug 28 10:06:21 2017 Return-Path: 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 D5C5413234B for ; Mon, 28 Aug 2017 10:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 reObSJCttw2T for ; Mon, 28 Aug 2017 10:06:14 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 76E2D13218E for ; Mon, 28 Aug 2017 10:06:14 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id s101so3971517ioe.0 for ; Mon, 28 Aug 2017 10:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=WGB95LZO2p6C82cKMflFV/3tJW/6eVViUoh3x53fzyc=; b=cdVfKETr+JyKrF/aBIsM8Il2WyTSSvQHcl0ZoTKSh1A2IRf5+xkctKi+xrQme3CkRF KVp05euYxTYZHw9DMmReFxZx9SLFBC4WfzMACIm8/22QtUFtQitM9Tn5I7YhXChJbaUv wd2L9Is4H4znWhePLamLfVtO+YlzkniGXeSns= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WGB95LZO2p6C82cKMflFV/3tJW/6eVViUoh3x53fzyc=; b=E/G19IseAUR1Brf9pxxEnrD/SGOzpeyiJpwqI8LySq+OPPmKEe2q5o3rRW4uP5sxct 7me/OlEceDrQnXIat6V8jovEQ/xFD/qDf7vspyoRaFfdeISucCUXtx3eLvYpDM086FE3 ExO1Qsp1xpAmMOcmxFHb4hwyDeZECz2G2kgykaJZpWG2zPXjTpNVfhbVl7iPOBWEyQYv 9bacCqoXlDoXr/RUps0pAxuVwdmfw9AooY5Fe7zM+ddaiqsKZ4WsEm3I4Hn/+z/X+msi MA+FZX+tcZ1BiuQzTQcYnP9/9B/IhVe7cCba0K1kcp3lWtwegMkIZ+m5v9pH+DZtwRK8 VwZw== X-Gm-Message-State: AHYfb5isurrht+6TRIRImkR1Gqllmhei6KdGOAAXJRfv7CLedTQfOwUj dc4xKbdAlc4Y5z5ZJ2ciZ4JgAFJ+xIIVpwggaOSjGznjS2ZK0hyXk5R06ulRuyjVwe9eDHR40kY 4p9th5do= X-Received: by 10.107.173.8 with SMTP id w8mr1228948ioe.6.1503939973436; Mon, 28 Aug 2017 10:06:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.67.134 with HTTP; Mon, 28 Aug 2017 10:05:42 -0700 (PDT) From: Brian Campbell Date: Mon, 28 Aug 2017 11:05:42 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a1144a0d8e188b80557d34f69" Archived-At: Subject: [OAUTH-WG] some implementation feedback with the PKI method of OAuth MTLS client authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:06:19 -0000 --001a1144a0d8e188b80557d34f69 Content-Type: text/plain; charset="UTF-8" Some feedback was received recently off-list that pointed out difficulties with implementation around the "tls_client_auth_root_dn" constraint in the PKI method of OAuth MTLS client authentication from draft-ietf-oauth-mtls-03. Basically the feedback was that popular web servers such as Nginx and Apache don't expose sufficient information (easily or in some cases at all) from the client certificate chain to the application to enable proper checking of "tls_client_auth_root_dn". Following from that and some additional reasoning below, I'm proposing that "tls_client_auth_root_dn" be dropped from the draft-ietf-oauth-mtls draft. The original idea behind the "tls_client_auth_root_dn" client metadata parameter came from an MTLS client authentication feature we added to our AS product years ago. The feature provided a way to allow the AS to more tightly constrain trust in a particular context (from an otherwise global list of trust anchors). It was fine as a specific product feature but should have stayed at that. When I added metadata to the OAuth MTLS draft, I added the "tls_client_auth_root_dn" parameter with that AS product feature in mind as something an AS *might* want to be able to do (without thinking thorough it all sufficiently). But having it as a client metadata parameter has wider implications including shifting trust control to the client and requiring ASs to support it. So, after thinking about it some more and also seeing the potential implementation difficulties, I don't believe it's appropriate to have in the specification. The AS should be at liberty to do chain validation with the PKI method however is most appropriate for it. And not be required to support one specific way of doing things implied by "tls_client_auth_root_dn" (which is even infeasible to implement in some environments). -- *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.* --001a1144a0d8e188b80557d34f69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some feedback was received recently off-list th= at pointed out difficulties with implementation around the "tls_client= _auth_root_dn" constraint in the PKI method of OAuth MTLS client authe= ntication from draft-ietf-oauth-mtls-03. Basically the feedback was that p= opular web servers such as Nginx and Apache don't expose sufficient inf= ormation (easily or in some cases at all) from the client certificate chain= to the application to enable proper checking of "tls_client_auth_root= _dn".

Following from that and some additional reasoning = below, I'm proposing that "tls_client_auth_root_dn" be droppe= d from the draft-ietf-oauth-mtls draft.

The original idea beh= ind the "tls_client_auth_root_dn" client metadata parameter came = from an MTLS client authentication feature we added to our AS product years= ago. The feature provided a way to allow the AS to more tightly constrain = trust in a particular context (from an otherwise global list of trust ancho= rs). It was fine as a specific product feature but should have stayed at th= at. When I added metadata to the OAuth MTLS draft, I added the "tls_cl= ient_auth_root_dn" parameter with that AS product feature in mind as s= omething an AS *might* want to be able to do (without thinking thorough it = all sufficiently). But having it as a client metadata parameter has wider i= mplications including shifting trust control to the client and requiring AS= s to support it. So, after thinking about it some more and also seeing the = potential implementation difficulties, I don't believe it's appropr= iate to have in the specification. The AS should be at liberty to do chain = validation with the PKI method however is most appropriate for it. And not = be required to support one specific way of doing things implied by "tl= s_client_auth_root_dn" (which is even infeasible to implement in some = environments).=C2=A0



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1144a0d8e188b80557d34f69-- From nobody Mon Aug 28 11:24:57 2017 Return-Path: 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 89EB313291B for ; Mon, 28 Aug 2017 11:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 flMaK7LO9VAf for ; Mon, 28 Aug 2017 11:24:51 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 B28A3132195 for ; Mon, 28 Aug 2017 11:24:51 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id 63so3700666pgc.2 for ; Mon, 28 Aug 2017 11:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Tg/6lNXLhSn5zNKZMCd0l9zZG28I+R8pou5vQm0ZtO8=; b=O5Gl3+TGGP4Kn7r7OFSZqpPIpWRue+t7fEZJVPeXEOtrzbcoVDgsBr/8R6hp3DIBIj ZzKP9L1PEjpG6e+IDtqB69Br5y2WBLz6kmKZkZDmt64MMQLxLPfM9TtIYx4ADr/xI48g xB7IiGAh3awnheqzWaMF79BASgP8ni8VMHYhoCfNR9WMdbiUZppBYe2xE22LDZ03gzH4 5yQvSayOs4kxOTq7Wzo+nDjMEw1ZLRG5AWNLXrZfy47XwrDuA3PU+IdcaM6GO6p3IBKc S6/XkyKJwDH/Dv5Zs4EJjmYBH4QJ/lqGTRiu/p+XqCYkdeO9I+YNNJwmLWclXEkg0QvJ 5ZAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Tg/6lNXLhSn5zNKZMCd0l9zZG28I+R8pou5vQm0ZtO8=; b=VYy+bP/gbRVSm2Ul+4CEtBedpeavn+9ZHaNvD1dGr/hIpz2XxNqxSG3acD3WJ7m8Cw qT1m8FlQVhUeTSZj6UTCbr1Zhk2FSPjRJ1hEncH1NwfkWPbsIamxH08Cev6XEGmI4yrJ nddxxAOOfS03+x7HPjc1MriZ6Jj7hkeLAXNCqfyZ1rMYcp6AIkzLBqYZ/Nu7XQdLdCmX BFPp/27XoTdcjU55LCjJ66zOyW90t99I3au4Egy8BDcF07ZJ/tRRDGllhY+Lh714D9YC XVhTLwyYCoDTDjlWQGETVDF01BQKFtXxu463nrvAFE3O2KTCvotqsNRlO466Q2lwlsk/ WssA== X-Gm-Message-State: AHYfb5hvhoCkx+Up93c0HhF4HlAXtEaOpOkRGTJDwyV5zx+KlRBV4ZbO SUDr7tNiWGZHgn0b X-Received: by 10.84.253.2 with SMTP id z2mr1851344pll.234.1503944690505; Mon, 28 Aug 2017 11:24:50 -0700 (PDT) Received: from [10.10.14.168] (wsip-24-120-53-90.lv.lv.cox.net. [24.120.53.90]) by smtp.gmail.com with ESMTPSA id x26sm3079235pgc.77.2017.08.28.11.24.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 11:24:49 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 28 Aug 2017 11:24:47 -0700 In-Reply-To: Cc: oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f4030436034a15ba010557d469e9" Archived-At: Subject: Re: [OAUTH-WG] some implementation feedback with the PKI method of OAuth MTLS client authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 18:24:55 -0000 --f4030436034a15ba010557d469e9 Content-Type: multipart/alternative; boundary="Apple-Mail=_8AB2B1E0-D80E-4EB1-B466-57B6C9233178" --Apple-Mail=_8AB2B1E0-D80E-4EB1-B466-57B6C9233178 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Having discussed it with Brian, I agree that removing = =E2=80=9Ctls_client_auth_root=E2=80=9D is the way to go. =20 It would be hard to implement in some cases, and it is up to the AS to = configure the roots it trusts for client authentication. In reality every TLS client auth deployment is likely to have custom = rules about trust. I think this parameter adds confusion rather than = reducing it. John B. On Aug 28, 2017, at 10:05 AM, Brian Campbell = wrote: >=20 > Some feedback was received recently off-list that pointed out = difficulties with implementation around the "tls_client_auth_root_dn" = constraint in the PKI method of OAuth MTLS client authentication from = draft-ietf-oauth-mtls-03. Basically the feedback was that popular web = servers such as Nginx and Apache don't expose sufficient information = (easily or in some cases at all) from the client certificate chain to = the application to enable proper checking of "tls_client_auth_root_dn".=20= >=20 > Following from that and some additional reasoning below, I'm proposing = that "tls_client_auth_root_dn" be dropped from the draft-ietf-oauth-mtls = draft.=20 >=20 > The original idea behind the "tls_client_auth_root_dn" client metadata = parameter came from an MTLS client authentication feature we added to = our AS product years ago. The feature provided a way to allow the AS to = more tightly constrain trust in a particular context (from an otherwise = global list of trust anchors). It was fine as a specific product feature = but should have stayed at that. When I added metadata to the OAuth MTLS = draft, I added the "tls_client_auth_root_dn" parameter with that AS = product feature in mind as something an AS *might* want to be able to do = (without thinking thorough it all sufficiently). But having it as a = client metadata parameter has wider implications including shifting = trust control to the client and requiring ASs to support it. So, after = thinking about it some more and also seeing the potential implementation = difficulties, I don't believe it's appropriate to have in the = specification. The AS should be at liberty to do chain validation with = the PKI method however is most appropriate for it. And not be required = to support one specific way of doing things implied by = "tls_client_auth_root_dn" (which is even infeasible to implement in some = environments). =20 >=20 >=20 >=20 > 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 --Apple-Mail=_8AB2B1E0-D80E-4EB1-B466-57B6C9233178 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Having discussed it with Brian, I agree that removing = =E2=80=9Ctls_client_auth_root=E2=80=9D is the way to go.  
It would be hard to implement in some cases, and it is up to = the AS to configure the roots it trusts for client = authentication.

In reality every TLS client auth deployment is likely to have = custom rules about trust.  I think this parameter adds confusion = rather than reducing it.

John B.


On Aug 28, 2017, at 10:05 AM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

Some feedback was received recently off-list that pointed = out difficulties with implementation around the = "tls_client_auth_root_dn" constraint in the PKI method of OAuth MTLS = client authentication from draft-ietf-oauth-mtls-03. Basically the = feedback was that popular web servers such as Nginx and Apache don't = expose sufficient information (easily or in some cases at all) from the = client certificate chain to the application to enable proper checking of = "tls_client_auth_root_dn".

Following = from that and some additional reasoning below, I'm proposing that = "tls_client_auth_root_dn" be dropped from the draft-ietf-oauth-mtls = draft.

The original idea behind the = "tls_client_auth_root_dn" client metadata parameter came from an MTLS = client authentication feature we added to our AS product years ago. The = feature provided a way to allow the AS to more tightly constrain trust = in a particular context (from an otherwise global list of trust = anchors). It was fine as a specific product feature but should have = stayed at that. When I added metadata to the OAuth MTLS draft, I added = the "tls_client_auth_root_dn" parameter with that AS product feature in = mind as something an AS *might* want to be able to do (without thinking = thorough it all sufficiently). But having it as a client metadata = parameter has wider implications including shifting trust control to the = client and requiring ASs to support it. So, after thinking about it some = more and also seeing the potential implementation difficulties, I don't = believe it's appropriate to have in the specification. The AS should be = at liberty to do chain validation with the PKI method however is most = appropriate for it. And not be required to support one specific way of = doing things implied by "tls_client_auth_root_dn" (which is even = infeasible to implement in some environments). 



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

= --Apple-Mail=_8AB2B1E0-D80E-4EB1-B466-57B6C9233178-- --f4030436034a15ba010557d469e9 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIIY0Lyj2gkndSM7k+PXvHLzFz32n 7BdzO6pR3KQaL2peMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgyODE4MjQ1MVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQAW+PD6ac20mIdEG4bYoeDPBsbYuZwXY3LNKVhiYyIIp41F pc+Sjg82xcXmo+bZYVe2AdrF6t1iz3mPdKMtOCCZh7dLmuwYjoH7atWHJh25153es9x6nBUpp27D 7Z4YGkT1oniIxZCICZyUHLx6mWiKqi2Y57c1W6sslcmAITZkHW4y3gx+zESU0K2NE1f9GoqvC8+0 nt/xxum+k8+uzdN8Iyg0juVjvqjdDQg87ejn8mSWuOPCoJLSk2cmbdkstx0W7QS3Tx0r0aKun3Wv rlU2YvGVFgDHGm+Chn+joFh5C5RSFfXHcZLx1DkJuZZUXEEhYxlVbJVMuoZxZjEb+V7Z --f4030436034a15ba010557d469e9-- From nobody Mon Aug 28 12:33:14 2017 Return-Path: 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 05841126BF0 for ; Mon, 28 Aug 2017 12:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 A7vkV2x7sdsU for ; Mon, 28 Aug 2017 12:33:09 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (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 99F311320BD for ; Mon, 28 Aug 2017 12:33:09 -0700 (PDT) Received: from [212.202.243.194] (helo=[10.1.90.102]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dmPmT-00034t-Iy; Mon, 28 Aug 2017 21:33:05 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-AE754DC0-294D-482F-B4AF-3FF083ED497A; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (14G60) In-Reply-To: Date: Mon, 28 Aug 2017 21:33:05 +0200 Cc: Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: <8AF2F7D2-F0A1-4D24-979C-07CC3BEE5B79@lodderstedt.net> References: To: John Bradley X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] some implementation feedback with the PKI method of OAuth MTLS client authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 19:33:13 -0000 --Apple-Mail-AE754DC0-294D-482F-B4AF-3FF083ED497A Content-Type: multipart/alternative; boundary=Apple-Mail-C94F9A1D-2BA0-4BF2-9344-EDA5283588A8 Content-Transfer-Encoding: 7bit --Apple-Mail-C94F9A1D-2BA0-4BF2-9344-EDA5283588A8 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable +1 for removing tls_client_auth_root > Am 28.08.2017 um 20:24 schrieb John Bradley : >=20 > Having discussed it with Brian, I agree that removing =93tls_client_auth_r= oot=94 is the way to go. =20 > It would be hard to implement in some cases, and it is up to the AS to con= figure the roots it trusts for client authentication. >=20 > In reality every TLS client auth deployment is likely to have custom rules= about trust. I think this parameter adds confusion rather than reducing it= . >=20 > John B. >=20 >=20 >> On Aug 28, 2017, at 10:05 AM, Brian Campbell = wrote: >>=20 >> Some feedback was received recently off-list that pointed out difficultie= s with implementation around the "tls_client_auth_root_dn" constraint in the= PKI method of OAuth MTLS client authentication from draft-ietf-oauth-mtls-0= 3. Basically the feedback was that popular web servers such as Nginx and Apa= che don't expose sufficient information (easily or in some cases at all) fro= m the client certificate chain to the application to enable proper checking o= f "tls_client_auth_root_dn".=20 >>=20 >> Following from that and some additional reasoning below, I'm proposing th= at "tls_client_auth_root_dn" be dropped from the draft-ietf-oauth-mtls draft= .=20 >>=20 >> The original idea behind the "tls_client_auth_root_dn" client metadata pa= rameter came from an MTLS client authentication feature we added to our AS p= roduct years ago. The feature provided a way to allow the AS to more tightly= constrain trust in a particular context (from an otherwise global list of t= rust anchors). It was fine as a specific product feature but should have sta= yed at that. When I added metadata to the OAuth MTLS draft, I added the "tls= _client_auth_root_dn" parameter with that AS product feature in mind as some= thing an AS *might* want to be able to do (without thinking thorough it all s= ufficiently). But having it as a client metadata parameter has wider implica= tions including shifting trust control to the client and requiring ASs to su= pport it. So, after thinking about it some more and also seeing the potentia= l implementation difficulties, I don't believe it's appropriate to have in t= he specification. The AS should be at liberty to do chain validation with th= e PKI method however is most appropriate for it. And not be required to supp= ort one specific way of doing things implied by "tls_client_auth_root_dn" (w= hich is even infeasible to implement in some environments). =20 >>=20 >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you._______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-C94F9A1D-2BA0-4BF2-9344-EDA5283588A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 for removing tls_client_auth_root

Am 28.08.2017 um 20:24 schrieb John Bradley <ve7jtb@ve7jtb.com>:

Having discussed it with Brian, I agree that removing =E2=80=9C= tls_client_auth_root=E2=80=9D is the way to go.  
It wou= ld be hard to implement in some cases, and it is up to the AS to configure t= he roots it trusts for client authentication.

In reality every TLS client auth deployment is l= ikely to have custom rules about trust.  I think this parameter adds co= nfusion rather than reducing it.

<= div class=3D"">John B.


On Aug 28, 2017, at 10:05 AM, Brian Campbe= ll <bcampbell@pi= ngidentity.com> wrote:

Some feedback was received recently off-l= ist that pointed out difficulties with implementation around the "tls_clien= t_auth_root_dn" constraint in the PKI method of OAuth MTLS client authentica= tion from draft-ietf-oauth-mtls-03. Basically the feedback was that popular= web servers such as Nginx and Apache don't expose sufficient information (e= asily or in some cases at all) from the client certificate chain to the appl= ication to enable proper checking of "tls_client_auth_root_dn".

Following from that and some additional reasoning be= low, I'm proposing that "tls_client_auth_root_dn" be dropped from the draft-= ietf-oauth-mtls draft.

The original idea= behind the "tls_client_auth_root_dn" client metadata parameter came from an= MTLS client authentication feature we added to our AS product years ago. Th= e feature provided a way to allow the AS to more tightly constrain trust in a= particular context (from an otherwise global list of trust anchors). It was= fine as a specific product feature but should have stayed at that. When I a= dded metadata to the OAuth MTLS draft, I added the "tls_client_auth_root_dn"= parameter with that AS product feature in mind as something an AS *might* w= ant to be able to do (without thinking thorough it all sufficiently). But ha= ving it as a client metadata parameter has wider implications including shif= ting trust control to the client and requiring ASs to support it. So, after t= hinking about it some more and also seeing the potential implementation diff= iculties, I don't believe it's appropriate to have in the specification. The= AS should be at liberty to do chain validation with the PKI method however i= s most appropriate for it. And not be required to support one specific way o= f doing things implied by "tls_client_auth_root_dn" (which is even infeasibl= e to implement in some environments). 



CONFIDENTIALITY NOTICE: This emai= l may contain confidential and privileged material for the sole use of the i= ntended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.  If you have received this communication in erro= r, please notify the sender immediately by e-mail and delete the message and= any file attachments from your computer. Thank you.______= _________________________________________
OAuth mailing listOAuth@ietf.org=
https= ://www.ietf.org/mailman/listinfo/oauth
=

_______________________________________________
OAuth mailing list
OAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-C94F9A1D-2BA0-4BF2-9344-EDA5283588A8-- --Apple-Mail-AE754DC0-294D-482F-B4AF-3FF083ED497A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkF FZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8 El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9v XloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/ HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB 9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7G Sji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYD VR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYI KwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0B AQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3 pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXo IarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvN VmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7 JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3PxA3uZ8LQw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcwODI4MTkzMzA1WjAjBgkqhkiG9w0BCQQxFgQUfiwmMJoZ+t33cELUbSQjI5hY424wgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEB AQUABIIBAAF0lj3+uoE0Qx1EPjymxpzCn7L1F5yYtdbNxOVjpE1rlOS6yaK4Txd0nor9dJt37SH0 oc5BW2hvv/3ah0OS2nhatv9WchPBT2+Cr6c8Hgu2vqNxj/gh+xdoI8TMrZx+iaOSwkcXPw3EFBZt 3jr6CnDwqvPvdWe34DbOSENl5wpiSt8JxLvUsOyRneMvf1tTO9EAlWwI32Xu3rVTaVe0McXkC8GH 8HvDVnfJlw/HHOinW+ZIupcIEwcIOyS5LSxIEV4U/vLdwPDjoCYkFTlq4kQ6TzrlWD4w/2ZSWX59 YYsOLvinKZo7OoThTKSD+pwhKSBM14k4/HvoaaOkONCTZWYAAAAAAAA= --Apple-Mail-AE754DC0-294D-482F-B4AF-3FF083ED497A-- From nobody Mon Aug 28 17:06:00 2017 Return-Path: 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 9403A124207 for ; Mon, 28 Aug 2017 17:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7KWjbBOJauzM for ; Mon, 28 Aug 2017 17:05:57 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 791E912008A for ; Mon, 28 Aug 2017 17:05:57 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id d81so9765614ioj.4 for ; Mon, 28 Aug 2017 17:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :content-transfer-encoding; bh=k80YvG4MHZoO+CXxrdeq4JHAZv0Xa3md3VMXDxn7kzk=; b=njV99UeRpEuUfOnKpJszJEMrM4cbGydC6VE4KLsIYTcky9lJeX3qD5O1yQhjbK5eL7 ek6GyzTqf6T3TLDeVXxQJfP6k9g6St46zUrLY8ULWqwlh9fiZDyXByxxh6Pl64ICSITs dMAfaM3UMPyv77fZSIIYyBvaOw80XeMibzZvdAEIDcin7NcXm3+UZK8ztqNx50JCVJnI PtuaHENoagasv3orlfl0Gx3/Zfgvm3pankFi1rh2ggjxG5w7m6csCwWe0ZF+pf3J37gU j90M2+rijj+14CRQHlZYT+5vjVYoj/plFqFX6mEet8m0Pa8qLeXAn84UNiPQi9vyZDA+ xtFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:content-transfer-encoding; bh=k80YvG4MHZoO+CXxrdeq4JHAZv0Xa3md3VMXDxn7kzk=; b=A3DNxxZMbIYYE1Rd8NqYWt+zJt5G73hHOiu8kmlgINsRM/9PBxFKHa3MGzTRAiRrkz UQUHJ9zDQvIULxALhef0tlvMz0IUFxygwV0lrfuGwOORjEtfSfQQg7QGRS1j4CZnfvMo fgMKoFWMPVMMiKzJYtuh4Ae3g82i7lGdfB1qoLb4lqJ67cgQrpBtz2tifbkNKYZA6k2S 0vpmA7scFyU7ERYaOEDrHaVsh4vbTyhRY0UhZa3Ypoyj7XDm7a3qqZIxBYrft0jOXZ36 4zysWf18SzkHpWSiQtMm1BtHIFVi/3KWUonPll+BoMU2JAK/6VD9tB8PfLYY2FiyBB5o 1zuA== X-Gm-Message-State: AHYfb5i1LH8G1u8KmGckn8puEton4FS/DswuSRkb+4ngzsyYwAX+2sLp j5FvGEXQHvRTgiszvYvVWwdo0MqolA== X-Received: by 10.107.176.81 with SMTP id z78mr2368665ioe.81.1503965156620; Mon, 28 Aug 2017 17:05:56 -0700 (PDT) Received: from 661309549932 named unknown by gmailapi.google.com with HTTPREST; Mon, 28 Aug 2017 17:05:54 -0700 Received: from 661309549932 named unknown by gmailapi.google.com with HTTPREST; Mon, 28 Aug 2017 17:05:53 -0700 From: Nat Sakimura In-Reply-To: <8AF2F7D2-F0A1-4D24-979C-07CC3BEE5B79@lodderstedt.net> References: <8AF2F7D2-F0A1-4D24-979C-07CC3BEE5B79@lodderstedt.net> MIME-Version: 1.0 Date: Mon, 28 Aug 2017 17:05:54 -0700 Message-ID: To: Torsten Lodderstedt , John Bradley , oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] some implementation feedback with the PKI method of OAuth MTLS client authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 00:05:59 -0000 +1 Sent from Astro for Android On 2017-08-29 at 4:33 AM, Torsten wrote: +1 for removing tls_client_auth_root Am 28.08.2017 um 20:24 schrieb John Bradley : Having discussed it with Brian, I agree that removing =E2=80=9Ctls_client_auth_root=E2=80=9D is the = way to go. It would be hard to implement in some cases, and it is up to the AS to configure the roots it trusts for client authentication. In reality every TLS client auth deployment is likely to have custom rules about trust. =C2=A0I think this parameter adds confusion rather than reducing it. John B. On Aug 28, 2017, at 10:05 AM, Brian Campbell wrote: Some feedback was received recently off-list that pointed out difficulties with implementation around the "tls_client_auth_root_dn" constraint in the PKI method of OAuth MTLS client authentication from draft-ietf-oauth-mtls-03. Basically the feedback was that popular web servers such as Nginx and Apache don't expose sufficient information (easily or in some cases at all) from the client certificate chain to the application to enable proper checking of "tls_client_auth_root_dn". Following from that and some additional reasoning below, I'm proposing that "tls_client_auth_root_dn" be dropped from the draft-ietf-oauth-mtls draft. The original idea behind the "tls_client_auth_root_dn" client metadata parameter came from an MTLS client authentication feature we added to our AS product years ago. The feature provided a way to allow the AS to more tightly constrain trust in a particular context (from an otherwise global list of trust anchors). It was fine as a specific product feature but should have stayed at that. When I added metadata to the OAuth MTLS draft, I added the "tls_client_auth_root_dn" parameter with that AS product feature in mind as something an AS *might* want to be able to do (without thinking thorough it all sufficiently). But having it as a client metadata parameter has wider implications including shifting trust control to the client and requiring ASs to support it. So, after thinking about it some more and also seeing the potential implementation difficulties, I don't believe it's appropriate to have in the specification. The AS should be at liberty to do chain validation with the PKI method however is most appropriate for it. And not be required to support one specific way of doing things implied by "tls_client_auth_root_dn" (which is even infeasible to implement in some environments).=C2=A0 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.=C2=A0 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 From nobody Mon Aug 28 23:53:37 2017 Return-Path: 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 D0205132705 for ; Mon, 28 Aug 2017 23:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 GNVJUMMpyPQS for ; Mon, 28 Aug 2017 23:53:34 -0700 (PDT) Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (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 46717132386 for ; Mon, 28 Aug 2017 23:53:34 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id maOTdTDMqjvvYmaOUd4NmJ; Mon, 28 Aug 2017 23:53:02 -0700 References: <50944e7c-a958-1d59-c68d-77f1c68db05c@connect2id.com> To: IETF oauth WG From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Tue, 29 Aug 2017 09:53:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000003010509090908090102" X-CMAE-Envelope: MS4wfNlKWmlm+nYl5XVzf5J0vHcvIV/XApVz7CVIZR1CrzobADSi0KYq2kwGyaoJuy6GmywqzZPCQCb7wi1j7eLUgewQhpWSq6+X6xN8xBvH6k2/Ydqr242i T+O3TNSwilMttKbACXne20+iUZFmWkNxT5hGrZPD0mZpyuAgyiMxP72w Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: enforcing mutual_tls_sender_constrained_access_tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 06:53:36 -0000 This is a cryptographically signed message in MIME format. --------------ms000003010509090908090102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 28/08/17 18:53, Brian Campbell wrote: > "invalid_client" is the appropriate error, if the client is > configured/registered for MTLS authentication, because it's effectively= > failed client authentication. > > I would say that "invalid_request" is probably the appropriate error fo= r a > public client with mutual_tls_sender_constrained_access_tokens=3Dtrue t= hat > doesn't provide the TLS client certificate with the token request. Ther= e is > effectively a missing required parameter in the context of the request.= Thanks, "invalid_request" does indeed look like the best fit to signal the request is incomplete (missing TLS client cert). Vladimir > On Sun, Aug 27, 2017 at 1:46 AM, Vladimir Dzhuvinov > wrote: >> Let's suppose that an OAuth 2.0 client is registered for >> >> mutual_tls_sender_constrained_access_tokens=3Dtrue >> >> >> Is it correct that in the presence of this parameter, and regardless o= f >> how "token_endpoint_auth_method" is set, the AS must require a client = X.509 >> cert to be passed to the token endpoint? If yes, then what error shoul= d the >> AS return if no client cert is passed with the token request? >> >> https://tools.ietf.org/html/rfc6749#section-5.2 >> >> Thanks, >> >> Vladimir >> >> PS: Noticed a typo - "manor" in #section-4.3 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------ms000003010509090908090102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MjkwNjUzMDFaMC8GCSqGSIb3DQEJBDEiBCCLlUXhiEvlHGdCBai10Q9+GsXhLIs2 tGYGk6/5lrsaBzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQBYP1YUDnbG 71pJPafvXWCFaKlR2vsrZ8Y9WOEKzcS/vMyc5ldKpUeDrLwxKxaEF4ccrR/umtwcZfW5df/L 09UcYSgtGoxVmIPo/AOtFDS8F70H9p+jQrCusXhSXC0aR9it/Kkj/GXoaq+sVhdUvKxcX35R WNhO8WTr+DXBoxkcrj9qxUFBC51/CE4VrA96Lncx2Bkew4yZxvKxp8+gudB46EEJl8/6YrM6 xo2VUEeOWvHI2IwnTsSUmVBWMuP1bhJqAavdjz2AIdUTOMM5AhTjK/ji0SlX9y9S6IgFVQZ3 R2WDgKVYwviNSOpVCumdGvs0HXWfpVIzYm0eU5J/vwK3AAAAAAAA --------------ms000003010509090908090102-- From nobody Tue Aug 29 00:29:29 2017 Return-Path: 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 E2B6613293A for ; Tue, 29 Aug 2017 00:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 bQu4ZEDuSHNq for ; Tue, 29 Aug 2017 00:29:26 -0700 (PDT) Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (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 480C81326DF for ; Tue, 29 Aug 2017 00:29:26 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id maxCdUlF9RZBrmaxCdmOPi; Tue, 29 Aug 2017 00:28:55 -0700 To: IETF oauth WG From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Tue, 29 Aug 2017 10:28:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080901070502090603030108" X-CMAE-Envelope: MS4wfIawBgV7laX1krsP1zNK8zXqEok6s99m5+1wV5fJF+gE2aKZ96uj3nssSW5cWx6RVq5Tnq2ti3bwasrgbzpc/GRwWRollHBVJ2dd7PNcc6wrTUnmnWyk NUmQIYROii90taTugIN3trvlfsvFMpAqmPH8NM5kZHU9YZOrdfuEnVlI Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 07:29:28 -0000 This is a cryptographically signed message in MIME format. --------------ms080901070502090603030108 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Aspects of this were previously discussed, on and off list. According to section 2.3, clients registering for public key bound mTLS auth must register their public keys as JWKs, or client X.509 certificate (as x5c parameter in RSA and EC JWK). In the latter case, are there any security implications if there is mismatch between the registered x5c and the top-level public key JWK parameters? Should the AS perform some sanity checks on the JWK parameter= s? A client could for instance register a JWK where the top-level JWK public key doesn't match the public key in the x5c (as key type, or public key value). Thanks, Vladimir --------------ms080901070502090603030108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MjkwNzI4NTNaMC8GCSqGSIb3DQEJBDEiBCCXNhIs2V577EwfIqQUiyGPgHlrK5iO eaRcpRd8TWFzQTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQAIUdiwoW98 Z174mNoLmOINba5m8t+vTl0/6nU0fr5fo6G13AV4sSFjrNQ3geGe1vCqsMfkLjoD6TbegXA/ 5C0pKtWKmuX7VUBOaDcR6yvIVB0U9O8xnpVOQmyHrFFk2vofAt5d1AZ/E2EQmuaNOnkDmljU G2/Uvs2pDx/ekb8HMUcdYnv8kaU+6t3vZK7lmWvHObvB+lzAoPS/1nQI4vOlCIUq31OLioL2 KXWq9Up6J2FfmwK3so/afPBYHWZ1KaGfrlFj5+xxH7wjTRCr5IGuIkkW8x1iJMgtMU5tDnRz 67wGmu55nphdgrYAcPNrDmn0J3UQ/XMUpLMOzWBwh1dNAAAAAAAA --------------ms080901070502090603030108-- From nobody Tue Aug 29 08:14:40 2017 Return-Path: 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 96C4C132AA5 for ; Tue, 29 Aug 2017 08:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 v8cdtks2P4y5 for ; Tue, 29 Aug 2017 08:14:37 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 E186F132968 for ; Tue, 29 Aug 2017 08:14:36 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id 81so21237318ioj.5 for ; Tue, 29 Aug 2017 08:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6tKu/tc/l4xJs9prCeni14Xi8PHMfEU1V4/ztc8N5hM=; b=h8mF+E2o86nwzquuAO5srcNJ+yiUdGYtqwcvyNtRceDjdYb9ASVp4qeqcIW8MvSDnf +qX4fUAm+Ca22Xy0UMULpx9/OE7VKRMtYpO4adRdLpLklAOJDNDO/3xqXlwvFgbtY5WU FmVCZpEMF+xbKDXZWaKVT4OGeUlMA9HTaZ+sU= 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=6tKu/tc/l4xJs9prCeni14Xi8PHMfEU1V4/ztc8N5hM=; b=HyvNdSFu6w28RbhbYRJUCLiT/y3B9G3URydbeQkripNizWziZs0z410DKjUh/2MRCx g+LQ4I2SzG7s/MSzn9SNRorPfo03EG3gNl40bQare4hZhNdMr5TbS5rQnACBV2Hx5Fl9 2fKMAixMGbbH5N8zmKnz0BXs2yarxwWj3wE4pbb2szgoVIly1UY4s+t5G0nGkkd6w2UQ pekcNEq8XVzdJh8G10UVSEhICGd1EE+/U/vgpZwg/PcEp3gQvMnIDMPWjvOhXhtYDJ1B NMfYoTrxmwtlQS6pJkhRYErzNZZSYeVELUozQYEiB/IlEgRQXkTHWmtwAa8MVBLGaZ6u p5cw== X-Gm-Message-State: AHYfb5jqQrHDi6+/qOg+my0m3OLW8mEhDEkTx6enqTTL2eFhKtnuUOpH L6PAc8R0UzyZ+dD0p48gIuxFvHvwpbWrBTVq2N9OqZggeSeQR2B9+wN5p1Vl+fc16t/4sTFv1x5 ASNyq X-Received: by 10.36.26.16 with SMTP id 16mr2869790iti.83.1504019676099; Tue, 29 Aug 2017 08:14:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.67.134 with HTTP; Tue, 29 Aug 2017 08:14:05 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 29 Aug 2017 09:14:05 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="001a114444d887d6780557e5de0a" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 15:14:39 -0000 --001a114444d887d6780557e5de0a Content-Type: text/plain; charset="UTF-8" Sec 4.7 of RFC 7517 , which defines "x5c" for JWK, says that the "key in the first certificate MUST match the public key represented by other members of the JWK." Thus, how I read it anyway, the check you mention is already a requirement of the JWK layer. On Tue, Aug 29, 2017 at 1:28 AM, Vladimir Dzhuvinov wrote: > Aspects of this were previously discussed, on and off list. > > According to section 2.3, clients registering for public key bound mTLS > auth must register their public keys as JWKs, or client X.509 > certificate (as x5c parameter in RSA and EC JWK). > > In the latter case, are there any security implications if there is > mismatch between the registered x5c and the top-level public key JWK > parameters? Should the AS perform some sanity checks on the JWK parameters? > > A client could for instance register a JWK where the top-level JWK > public key doesn't match the public key in the x5c (as key type, or > public key value). > > Thanks, > > Vladimir > > > _______________________________________________ > 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.* --001a114444d887d6780557e5de0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sec 4.7 of RFC 7517, which defines "x5c" = for JWK, says that the "key in the first certificate MUST match the pu= blic key represented by other members of the JWK." Thus, how I read it= anyway, the check you mention is already a requirement of the JWK layer.

On Tu= e, Aug 29, 2017 at 1:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.= com> wrote:
Aspects of this= were previously discussed, on and off list.

According to section 2.3, clients registering for public key bound mTLS
auth must register their public keys as JWKs, or client X.509
certificate (as x5c parameter in RSA and EC JWK).

In the latter case, are there any security implications if there is
mismatch between the registered x5c and the top-level public key JWK
parameters? Should the AS perform some sanity checks on the JWK parameters?=

A client could for instance register a JWK where the top-level JWK
public key doesn't match the public key in the x5c (as key type, or
public key value).

Thanks,

Vladimir


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a114444d887d6780557e5de0a-- From nobody Tue Aug 29 22:11:09 2017 Return-Path: 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 9AF721321EC for ; Tue, 29 Aug 2017 22:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 3BJ9PHs5XhAD for ; Tue, 29 Aug 2017 22:11:06 -0700 (PDT) Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (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 42C1F1321AE for ; Tue, 29 Aug 2017 22:11:06 -0700 (PDT) Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id mvGsdGxOZE0BdmvGsdnx7Y; Tue, 29 Aug 2017 22:10:35 -0700 To: Brian Campbell Cc: IETF oauth WG References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <8e9eaf64-6859-0674-d586-ab23ab91f086@connect2id.com> Date: Wed, 30 Aug 2017 08:10:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000904030703050102050501" X-CMAE-Envelope: MS4wfD64gwPHFTcsY7f7hrZbQOZNsyjgcoKP4nwGgpdeHmsUzPJuioQeIKkpMpw8VlCZdJbA3Sow0hr+jX3wPJLUDvFhgGYxB1t24YOvkHphHzUScbHbGI7c AoyRCOwR6WH2kAbM5DDTplAvw7xOLMvGvJWeaMIepTZ7KEqiTe9ejLh6e1QG6cZ6dK0JkBWsXb2tK00PqBvt0tkOa0FuqE3rPes= Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 05:11:07 -0000 This is a cryptographically signed message in MIME format. --------------ms000904030703050102050501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 29/08/17 18:14, Brian Campbell wrote: > Sec 4.7 of RFC 7517 , > which defines "x5c" for JWK, says that the "key in the first certificat= e > MUST match the public key represented by other members of the JWK." Thu= s, > how I read it anyway, the check you mention is already a requirement of= the > JWK layer. Thanks Brian, I missed that bit! And just realised that the Nimbus lib doesn't check the x5c pub key when creating / parsing JWKs! I suppose other JOSE libs may have the same omission. A reason to add a note to the MTLS spec perhaps? Vladimir > On Tue, Aug 29, 2017 at 1:28 AM, Vladimir Dzhuvinov > wrote: >> Aspects of this were previously discussed, on and off list. >> >> According to section 2.3, clients registering for public key bound mTL= S >> auth must register their public keys as JWKs, or client X.509 >> certificate (as x5c parameter in RSA and EC JWK). >> >> In the latter case, are there any security implications if there is >> mismatch between the registered x5c and the top-level public key JWK >> parameters? Should the AS perform some sanity checks on the JWK parame= ters? >> >> A client could for instance register a JWK where the top-level JWK >> public key doesn't match the public key in the x5c (as key type, or >> public key value). >> >> Thanks, >> >> Vladimir >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------ms000904030703050102050501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MzAwNTEwMzNaMC8GCSqGSIb3DQEJBDEiBCBLmLFXZ5HRFoOvlmSA/ZXVqIDWfw6b cNc50JzXqxa+qjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQB7EPV8b8Us PECZy+/oWtBHH8hLUsnE6AjffPcJSaw3iJwpoBjCkKZe6HC6h1I0F6Ei8uBEgEIkPuioy3xN yjLYWRN7aD9VOG4FL7ZRaHXky0xJD/6xZ9vCZwA3hpbQSCUMtLo5lfeXac3tzkBk4cg86bnk W2KN466qBQOixACA9cO5JX8CXzmX08foScGez6wSD5G5eUUV1kItfD1dl8OIlDIet1OmnSqX EJ5YFYrHJAesqJuM7NkmhGhACPOfAe0QPXicLjsKduazY3WZPcVED0K+rWQIdvYNfRVxny7E aakDGOFdF8UcVfV9ElY6ViN91DbDBjDVUb88KZywtbXTAAAAAAAA --------------ms000904030703050102050501-- From nobody Wed Aug 30 07:51:42 2017 Return-Path: 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 D49E21326F6 for ; Wed, 30 Aug 2017 07:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 jxQqQi1rcfBx for ; Wed, 30 Aug 2017 07:51:38 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 8A382124B18 for ; Wed, 30 Aug 2017 07:51:38 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id f1so6973064ith.0 for ; Wed, 30 Aug 2017 07:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=98RTRuL3x4+Lt0OmIGfB4CWibem+QspRNWHjYBdIdbs=; b=AMQen9h5w8UFOTDGVcVnWqUrgFmigJRA+P8E50hbdpSoOSYHXRbg932V+BTwNQM7eO CJWER+H3nOMKchW52RaiuKYB3tNhuUMghMQpBJj/fgFDzSFqwfZ6nMleHy2OzfU1t9Lw D/JfbG11Cftau9QJPgNuV+DplYHeh39bijtSE= 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=98RTRuL3x4+Lt0OmIGfB4CWibem+QspRNWHjYBdIdbs=; b=JJKo88Gi2Fua2wVSMMfWW+puCZtGfG5iVXbIRULqvTbQs8JTlVxE5qCoUb1NjHEZzI opcBO9RKoo1xMKNPcd6yK8WjaP/C0ROpy2Io5YHyXDH0OUT1ZnHv6vjugFhq0cBayPTh 4P9sOtRQ0XHmxWSlRQQeBL+NhRJrkXOA9gbmThxnQQLZMTE1elx9bcitk1zjO1wHCIuU 4XZtQ6U1rZ4RZYHfBMPd3IyC8Irz6fnWU9AB8UZkG/vl2VhiQsmj6stg5BJSfR+OLLXg kT6uW4OpapNIBz8OSwYncNFyVFjabRqkBhuv9jDK+UasTKQdWtZS70I+cTEnfZK6wB73 s1Yg== X-Gm-Message-State: AHYfb5gW7XM9Ay62bWrFpr1R9vnlLL0MG/xp+iJ7dgga2OGKUpVYDCP1 YVH6Kqfk7Z3Gjx9EKDSBze259BeRe80v/W977IjQ0z/+xEzPLC4+hy9xlCE763xOYiIt/wXum4A bHVGS X-Received: by 10.36.211.88 with SMTP id n85mr2109376itg.78.1504104697866; Wed, 30 Aug 2017 07:51:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.67.134 with HTTP; Wed, 30 Aug 2017 07:51:07 -0700 (PDT) In-Reply-To: <8e9eaf64-6859-0674-d586-ab23ab91f086@connect2id.com> References: <8e9eaf64-6859-0674-d586-ab23ab91f086@connect2id.com> From: Brian Campbell Date: Wed, 30 Aug 2017 08:51:07 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="001a1145ee8e38ccd70557f9aa1f" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 14:51:41 -0000 --001a1145ee8e38ccd70557f9aa1f Content-Type: text/plain; charset="UTF-8" I suppose a note or reference like that couldn't hurt. I'll look to add something along those lines. Obviously, a spec like this can't restate everything from the specs it builds on. But sometimes a call-out or pointer is useful. On Tue, Aug 29, 2017 at 11:10 PM, Vladimir Dzhuvinov < vladimir@connect2id.com> wrote: > > On 29/08/17 18:14, Brian Campbell wrote: > > Sec 4.7 of RFC 7517 , > > which defines "x5c" for JWK, says that the "key in the first certificate > > MUST match the public key represented by other members of the JWK." Thus, > > how I read it anyway, the check you mention is already a requirement of > the > > JWK layer. > Thanks Brian, I missed that bit! > > And just realised that the Nimbus lib doesn't check the x5c pub key when > creating / parsing JWKs! I suppose other JOSE libs may have the same > omission. A reason to add a note to the MTLS spec perhaps? > > Vladimir > > > On Tue, Aug 29, 2017 at 1:28 AM, Vladimir Dzhuvinov < > vladimir@connect2id.com > >> wrote: > >> Aspects of this were previously discussed, on and off list. > >> > >> According to section 2.3, clients registering for public key bound mTLS > >> auth must register their public keys as JWKs, or client X.509 > >> certificate (as x5c parameter in RSA and EC JWK). > >> > >> In the latter case, are there any security implications if there is > >> mismatch between the registered x5c and the top-level public key JWK > >> parameters? Should the AS perform some sanity checks on the JWK > parameters? > >> > >> A client could for instance register a JWK where the top-level JWK > >> public key doesn't match the public key in the x5c (as key type, or > >> public key value). > >> > >> Thanks, > >> > >> Vladimir > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > > -- > Vladimir Dzhuvinov :: vladimir@connect2id.com > > > -- *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.* --001a1145ee8e38ccd70557f9aa1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I suppose a note or reference like that couldn't hurt.= I'll look to add something along those lines. Obviously, a spec like t= his can't restate everything from the specs it builds on. But sometimes= a call-out or pointer is useful.

=
On Tue, Aug 29, 2017 at 11:10 PM, Vladimir Dzhuv= inov <vladimir@connect2id.com> wrote:

On 29/08/17 18:14, Brian Campbell wrote:
> Sec 4.7 of RFC 7517 <https://tools.ietf.org/h= tml/rfc7517#section-4.7>,
> which defines "x5c" for JWK, says that the = "key in the first certificate
> MUST match the public key represented by other members of the JWK.&quo= t; Thus,
> how I read it anyway, the check you mention is already a requirement o= f the
> JWK layer.
Thanks Brian, I missed that bit!

And just realised that the Nimbus lib doesn't check the x5c pub key whe= n
creating / parsing JWKs! I suppose other JOSE libs may have the same
omission. A reason to add a note to the MTLS spec perhaps?

Vladimir

> On Tue, Aug 29, 2017 at 1:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.com
>> wrote:
>> Aspects of this were previously discussed, on and off list.
>>
>> According to section 2.3, clients registering for public key bound= mTLS
>> auth must register their public keys as JWKs, or client X.509
>> certificate (as x5c parameter in RSA and EC JWK).
>>
>> In the latter case, are there any security implications if there i= s
>> mismatch between the registered x5c and the top-level public key J= WK
>> parameters? Should the AS perform some sanity checks on the JWK pa= rameters?
>>
>> A client could for instance register a JWK where the top-level JWK=
>> public key doesn't match the public key in the x5c (as key typ= e, or
>> public key value).
>>
>> Thanks,
>>
>> Vladimir
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>>

--
Vladimir Dzhuvinov :: vladimir@c= onnect2id.com




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1145ee8e38ccd70557f9aa1f--