From nobody Mon Sep 1 08:37:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA12A1A0921 for ; Mon, 1 Sep 2014 08:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 pKt-qj0S4XDa for ; Mon, 1 Sep 2014 08:37:32 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6911A0B7D for ; Mon, 1 Sep 2014 08:13:54 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id b17so6326340lan.36 for ; Mon, 01 Sep 2014 08:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=00UQNRza5qp2Qx4NGwu7hSia7GDcxYt0p4/rUgMrbAw=; b=HkvfhiVzSqLVyjPqRLqELDqFYSja5t3SjBpmBKoOJDzVZ/Fd4bA4l4lL2t2Zf9LNuf LKKv6bkUZnPTZYRz6Kwq9y6SHJd3afeMgYYF8TJLy/I9FvN3giKhUm6gFvcGO5OmFluQ z8/MUdgy1nKpFYM4QCmUnLIjMNigsAJqFycfb7E9+X22Dc/zL4yJc4fDFHWcUGDtFn/3 wb3zOuUIpdgHMV24dGFPRuiV6tqQDdHcSi18xI4SDRQED2M3r5fr16B8/cARBzQ2xOM6 dKulGtRp1KsbOjyeSsrqLtdXbEC/Mf2gJdxIK1sTAXryf8kvdZnT/Hgr9J1+G23RyGv0 9RPA== MIME-Version: 1.0 X-Received: by 10.152.45.42 with SMTP id j10mr29237188lam.13.1409584433189; Mon, 01 Sep 2014 08:13:53 -0700 (PDT) Received: by 10.112.9.105 with HTTP; Mon, 1 Sep 2014 08:13:53 -0700 (PDT) In-Reply-To: <53FF0F95.9010704@gmx.net> References: <53FF0F95.9010704@gmx.net> Date: Tue, 2 Sep 2014 00:13:53 +0900 Message-ID: From: Nat Sakimura To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c29f566bd98505020273f2 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kVQq_HEkOGpQx5Nonqzea61xz-8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question regarding OAuth SPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 15:37:37 -0000 --001a11c29f566bd98505020273f2 Content-Type: text/plain; charset=UTF-8 Hi. Sorry for a slow reply. Please find my answers inline: 2014-08-28 20:16 GMT+09:00 Hannes Tschofenig : > Hi Nat, Hi John, > > I have been trying to do a detailed review of the OAuth SPOP document > http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > and I ran into a few questions regarding the capabilities of the attacker. > > Is it correct that you assume that the attacker is only able to > intercept the Authorization Response message but not the Authorization > Request message? > Yes. On iOS devices, it seems to be the case that it is always Safari that is invoked via https request message, unless your are using a jail broken device, in which case, you are on your own. Another risk factor is that if the app provides "Open with Chrome" like capability. In this case, an attacker may create an app with the same custom scheme as Chrome, but the app can obviously avoid it by not providing the option. On Android devices, apps can be invoked through explicit intent. It amounts to specifying package name and class name so if attacker succeeds in having the user install malicious "chrome" etc., then the attack would succeed, but that involves deceiving the user to have him install "malicious chrome" at which point, the devices is so screwed and I would like to consider it out of scope. > The security consideration section of the document is a bit fuzzy about > this issue and says: > " > the client MUST make sure that the request channel is adequately protected > " > > It is, however, not clear what request channel you are talking about and > what you mean by adequately protected. > The security consideration can be expanded to include the above. The reason I stopped at what is written now is that the above statement may become obsolete in the future, which is possibly be quite soon. Cheers, Nat > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c29f566bd98505020273f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi.=C2=A0

Sorry for a slow reply. Pleas= e find my answers inline:=C2=A0


2014-08-28 20:16 GMT+09:00 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
Hi Nat, Hi John,

I have been trying to do a detailed review of the OAuth SPOP document
http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
and I ran into a few questions regarding the capabilities of the attacker.<= br>
Is it correct that you assume that the attacker is only able to
intercept the Authorization Response message but not the Authorization
Request message?

Yes.=C2=A0
O= n iOS devices, it seems to be the case that it is always Safari that is inv= oked via https request message, unless your are using a jail broken device,= in which case, you are on your own. Another risk factor is that if the app= provides "Open with Chrome" like capability. In this case, an at= tacker may create an app with the same custom scheme as Chrome, but the app= can obviously avoid it by not providing the option.=C2=A0

On Android devices, apps can be invoked through explici= t intent. It amounts to specifying package name and class name so if attack= er succeeds in having the user install malicious "chrome" etc., t= hen the attack would succeed, but that involves deceiving the user to have = him install "malicious chrome" at which point, the devices is so = screwed and I would like to consider it out of scope.=C2=A0



The security consideration section of the document is a bit fuzzy about
this issue and says:
"
the client MUST make sure that the request channel is adequately protected<= br> "

It is, however, not clear what request channel you are talking about and what you mean by adequately protected.

= The security consideration can be expanded to include the above. The reason= I stopped at what is written now is that the above statement may become ob= solete in the future, which is possibly be quite soon.=C2=A0

Cheers,=C2=A0

Nat=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
Ciao
Hannes


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c29f566bd98505020273f2-- From nobody Tue Sep 2 10:29:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75631A048D for ; Tue, 2 Sep 2014 10:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Gei2wDWG9DX4 for ; Tue, 2 Sep 2014 10:28:59 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACDB1A0468 for ; Tue, 2 Sep 2014 10:28:59 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id pv20so8296180lab.33 for ; Tue, 02 Sep 2014 10:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sShYBjpwtIAxluhKFfqEzJu35IASYIeFh/Oyx0Z/1Nk=; b=WrP+ApUa7PZcu/4EdZXjyiGKOfdc0wbKuaGxyGg9npKm6wg+OPJpIVcgXBvMqVsehz Ha+vtnRHq0pu9Qp53N8ClRIKjMmpZiCDKYj8bw2V0Cn/zo/S46MSpaZtL9ZLPwwThkjr +RfJ6Mn6hybGQuv6KZyWkbOY3GR1FqcxiZJAK6vD7wueJowwcmO1KTaxw4TSj1gqxNC4 NduSyN6t07uaLBkW/P/Tti9jvKBsEMvXZYnnpC+7NCGfz/nLzezJrCDvFagx3YV/DtII LiZc1IsYIjAWBoYX25G+srSWmo1hKjxNCoCQ/8y5Y+p45ViFbBHQjEKTu/AIe77PsZNo CcqQ== MIME-Version: 1.0 X-Received: by 10.112.55.238 with SMTP id v14mr3719831lbp.93.1409678937534; Tue, 02 Sep 2014 10:28:57 -0700 (PDT) Received: by 10.112.9.36 with HTTP; Tue, 2 Sep 2014 10:28:57 -0700 (PDT) In-Reply-To: <54002809.2020101@gmx.net> References: <54002809.2020101@gmx.net> Date: Wed, 3 Sep 2014 02:28:57 +0900 Message-ID: From: Nat Sakimura To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a1133c96651b80d05021874cc Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/s7MBjHNZVEgzt-AZkzuttfhCggU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth SPOP Detailed Review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 17:29:02 -0000 --001a1133c96651b80d05021874cc Content-Type: text/plain; charset=UTF-8 Hi. Thanks for the detailed comments. Here are the responses to the questions raised in [1] [1] http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc 3.1 [Question: Would it make sense to provide some information also in the > Dynamic Client Registration specification? I am a bit unhappy about not > specifying at least one mechanism for learning this information since it is > important for the overall security -- to avoid downgrading attacks.] I would have included it if OAuth has defined a discovery document. n fact, it may be a good starting point to discuss whether we should have a discovery document for OAuth. If the client does the per client registration, then it will not be a public client so spop would not be needed. The clients as a class may register itself, but then each client instance would not know if the server knows that it is using spop, and assuming it without verifying is not very safe. 3.1 [Hannes: Can we make a more explicit reference to a feature in the > OpenID Connect Discovery specification?] It will be an extension to section 3 of OpenID Connect Discovery. This specification may define a JSON name for such a parameter. Then, one can include it in the metadata. A candidate for such name would be: oauth_spop_supported_alg: and the value would be the strings representing supported algorithms. It could be drawn from JWA algs. A simpler alternative would be: oauth_spop_support: and the value would be true or false. However, we have no good place to advertise them as of now. 3.2 [Hannes: Do we really need this flexibility here?] It is there as an extension point. John has a draft that uses aymmetric algo. An early draft had HMAC as well. We could however drop it. I suppose we can add other algorithms later without breaking this one. [Hannes: The term 'front channel' is not defined anywhere.] Will define if this section survives. 3.7 [Hannes: Why is there a SHOULD rather than a MUST?] The server may have other considerations before returning successful response. 5. [Hannes: Which request channel are you talking about? There are two > types of request channels here, namely the Access Token Request/Response > and the Authorization Request / Response channel. What do you mean by > adequately protected here? How likely is it that this can be accomplished? > If it is rather unlikely then it would be better to define a different > transformation algorithm!] This is referring to the authorization request. On iOS as of the time of writing, not Jailbreaking seems to be adequate. For Android, only presenting the intended browser as the options to handle the request seems adequate. Similar considerations would be there per platform. Note: Authors do think that using other algorithms is better. However, it proved to be rather unpopular among the developers that they were in touch with and believe that we do need to provide this "no-transform" capability. For other "corrections", I am still working on to prepare comments as word comments. Most of editorial changes will be accepted. Some proposed technical changes seems to be due to the clauses being unclear, so I will try to propose a clarification rather than just accepting them. Best, Nat 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig : > > Hi John, Hi Nat, > > I went through the document in detail and suggest some changes (most of > them editorial): > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.pdf > > My main concern at the moment are some optional features in the spec > that make it less interoperable, such as the feature discovery, and the > transformation function. The latter might go away depending on your > answer to my question raised at > http://www.ietf.org/mail-archive/web/oauth/current/msg13354.html but the > former requires some specification work. > > Ciao > Hannes > > PS: I agree with James that the title of the document is a bit > misleading when compared with the other work we are doing in the group. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1133c96651b80d05021874cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi. Thanks for the detailed comments.=C2=A0

Here ar= e the responses to the questions raised in [1]

[1] http://= www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc

3.1 [Question: Would it make sense to provide some inf= ormation also in the Dynamic Client Registration specification? I am a bit = unhappy about not specifying at least one mechanism for learning this infor= mation since it is important for the overall security -- to avoid downgradi= ng attacks.]

I would have included it if OAuth has defined a discovery document. n f= act, it may be a good starting point to discuss whether we should have a di= scovery document for OAuth.

If the client does the per c= lient registration, then it will not be a public client so spop would not b= e needed.=C2=A0
The clients as a class may register itself, but then each client insta= nce would not know if the server knows that it is using spop, and assuming = it without verifying is not very safe.=C2=A0

3.1 [Hannes: Can we make a more explicit reference to a feature in the Open= ID Connect Discovery specification?]

It will be an extensio= n to section 3 of OpenID Connect Discovery. This specification may define a= JSON name for such a parameter. Then, one can include it in the metadata.<= br>
A candidate for such name would be:

oauth_spop_supported_alg:
and the value would be the strings representing supported algorithms. = It could be drawn from JWA algs.

A simpler alternative would be:

oauth_spop_support:

and the value would be true or false.
However, we have no good place to advertise them as of now.=C2= =A0

3.2 [Hannes: Do we really need this flexibility here?]

It i= s there as an extension point. John has a draft that uses aymmetric algo. A= n early draft had HMAC as well.

We could however drop it. I suppose = we can add other algorithms later without breaking this one.

[Hannes: The term 'front channel' is not defin= ed anywhere.]

Will define if this section survives.

3.7 [Hann= es: Why is there a SHOULD rather than a MUST?]

The server may have other considerations before returning successful re= sponse.

5. [Hannes: Which request channel are you talking about? There are two type= s of request channels here, namely the Access Token Request/Response and th= e Authorization Request / Response channel. What do you mean by adequately = protected here? How likely is it that this can be accomplished? If it is ra= ther unlikely then it would be better to define a different transformation = algorithm!]

This is referring to the authorization request.

On iOS as of the= time of writing, not Jailbreaking seems to be adequate. For Android, only = presenting the intended browser as the options to handle the request seems = adequate. Similar considerations would be there per platform.

Note: Authors do think that using other algorithms is better. However, = it proved to be rather unpopular among the developers that they were in tou= ch with and believe that we do need to provide this "no-transform"= ; capability.

For other "corrections", I am still working on to prepare com= ments as word comments.=C2=A0
Most of editorial changes will be a= ccepted. Some proposed technical changes seems to be due to the clauses bei= ng unclear, so I will try to propose a clarification rather than just accep= ting them.=C2=A0

Best,=C2=A0

Nat

2014-08= -29 16:13 GMT+09:00 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
>
> Hi John, Hi = Nat,
>
> I went through the document in detail and suggest some changes= (most of
> them editorial):
> http://www.tschofenig.p= riv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc
> http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-= hannes.pdf
>
> My main concern at the moment are some optio= nal features in the spec
> that make it less interoperable, such as the feature discovery, and th= e
> transformation function. The latter might go away depending on yo= ur
> answer to my question raised at
> http://www.ietf.org/ma= il-archive/web/oauth/current/msg13354.html but the
> former requires some specification work.
>
> Ciao
> = Hannes
>
> PS: I agree with James that the title of the documen= t is a bit
> misleading when compared with the other work we are doin= g in the group.
>
>
> _______________________________________________
>= ; OAuth mailing list
> OAuth@ietf.o= rg
> http= s://www.ietf.org/mailman/listinfo/oauth
>



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundat= ion
http://nat.sakimura.org/@_nat_en
--001a1133c96651b80d05021874cc-- From nobody Tue Sep 2 10:38:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9231A001F for ; Tue, 2 Sep 2014 10:38:41 -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, SPF_PASS=-0.001] autolearn=ham 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 Pl_BkSfF73-0 for ; Tue, 2 Sep 2014 10:38:36 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBCE1A0468 for ; Tue, 2 Sep 2014 10:38:35 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so8085667lbv.33 for ; Tue, 02 Sep 2014 10:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dtW7NwPaWYXjfYFIvC896edmAbLA/mUYZnrWka06Wys=; b=E/T6EMOf5fAIAWEv4EbfhhUyTT2tmBX5qASnU9feu54z4AokQTmmBv3eKhkgaMiTbd K5mKQD31YYnW3vaW7HmzfMxoYYpH60tTDop/lIPbZqQ5e3bAFYDJdCUsySSGThXpphyx 3ensvNkeR+WvcrmkmlpCm/VUvnRpqdyISnd41pvPXkwM7u4lr3Ag8Qtkapv2dTmVYArj wpVGbliCeVbi3pKaDVpAtduRpgBcNh/2i2pK6nUJ0+kaezNZDWdQZYjoB26+q4+OJnmu Gei2z+U0Qp2s8Syzm4m0CsKF997ClFIFCvHUy1t68aDjhEz1oD8u49Sg7m9XEVaMZoz+ wrxg== MIME-Version: 1.0 X-Received: by 10.152.25.170 with SMTP id d10mr35576491lag.37.1409679514268; Tue, 02 Sep 2014 10:38:34 -0700 (PDT) Received: by 10.112.9.36 with HTTP; Tue, 2 Sep 2014 10:38:34 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AE5002A@TK5EX14MBXC293.redmond.corp.microsoft.com> References: <53FCE0D7.5010109@gmx.net> <53FDFCFF.8010606@gmx.net> <4E1F6AAD24975D4BA5B16804296739439AE5002A@TK5EX14MBXC293.redmond.corp.microsoft.com> Date: Wed, 3 Sep 2014 02:38:34 +0900 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: multipart/alternative; boundary=089e0158b738b1fa610502189670 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/1laP0_jjzyhZZyQ9Ja6Jd168Hwc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of Possession for the OAuth Authorization Code Grant" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 17:38:41 -0000 --089e0158b738b1fa610502189670 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Responses inline: 2014-08-29 10:00 GMT+09:00 Mike Jones : > Here's some feedback on the document. > > > > First, while I believe that the document is a good first working group > draft and this specification is important, it is not ready for last call, > since there are open issues called out in the document that have not been > discussed by the working group and aspects of the specification are > incomplete. I=E2=80=99ll discuss those below. There are also significan= t > ambiguities in the document at present that could lead to non-interoperab= le > implementations. I believe that it would be more appropriate to bring th= e > document to WGLC once these significant issues (and those that may be > raised by other reviewers) have been addressed. > > > > 2. Terminology =E2=80=93 I would list =E2=80=9Ccode challenge=E2=80=9D b= efore =E2=80=9Ccode verifier=E2=80=9D > both because it is used first and because it=E2=80=99s alphabetically fir= st. > The "code verifier" is listed before "code challenge" as the later uses the former in its definition. > > > 2.1 code verifier =E2=80=93 Is this an octet sequence to be sent as-is (w= ith the > requirement for %-escaping octets representing non-url-safe characters) o= r > as the base64url encoding of the octet sequence? > Previously, it was agreed to be octet sequence and it is to be sent as-is. The clarification will be added. > > > 2.2 code challenge =E2=80=93 Same question as above. Then I would just s= ay that > the code challenge value is a function of the code verifier value and > discuss the possible functions in its own section or subsection. > Same as above. It is an open question whether we want to preserver the extensibility in the transformation at this time. If we decide not, then this spec will be further simplified and this point will become subsumed. > > > NOTE 1: This should be discussed in the section about the transformation > function. Also, say here what criteria people might use to choose functi= on. > > > > NOTE 2: Also fold this into the transformation function section. > > > > 3.2 Client registers its desired code challenge algorithm =E2=80=93 A mea= ns of > registering this algorithm using OAuth Dynamic Client Registration should > be defined. Use of this method should be optional. Any metadata values > defines should be registered in the appropriate registry. > As stated above, if we do not need extensibility, we do not need this section. My sense is that we do not. See my response to Hannes' detailed review. > > > 3.4 Client sends the code challenge =E2=80=93 Is the code challenge octet= sequence > value sent or the base64url encoding of it? > As above. > > > 3.6 Client sends the code and the secret =E2=80=93 Is the code verifier= octet > sequence value sent or the base64url encoding of it? > As above. > > > 4.1 OAuth Parameters Registry =E2=80=93 The change controller should be = =E2=80=9CIESG=E2=80=9D. > Yes. > > > 5. Security Considerations =E2=80=93 The implications of choosing differ= ent kinds > of transformation functions should be discussed. > Will become unnecessary if we throw the extensibility away at this time. > > > I would recommend running the HTML output of xml2rfc through a grammar an= d > spelling checker, as numerous grammar nits would be caught by doing so. > Thanks for the advise. Best, Nat > > > -- Mike > > > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Wednesday, August 27, 2014 8:45 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of > Possession for the OAuth Authorization Code Grant" > > > > Based on the reaction from a few I thought I should add a few words about > this working group last call. > > > > There is no requirement to wait a specific timeframe after a document > became a WG item to issue a working group last call. > > > > In this specific case, the document was around for a while and I didn't > see a reason for not-finishing it as soon as possible. > > > > Additionally, since the document deals with a security vulnerability that > is being exploited today I thought it might make sense to get the attenti= on > from the group to review it. > > > > Finally, it is also a fairly "simple" document (if there is something as > simple in this working group). > > > > Ciao > > Hannes > > > > On 08/26/2014 09:32 PM, Hannes Tschofenig wrote: > > > Hi all, > > > > > > This is a Last Call for comments on the "Symmetric Proof of Possession > > > for the OAuth Authorization Code Grant" specification. > > > > > > The document can be found here: > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > > > > > > Please have your comments in no later than September 9th. > > > > > > Ciao > > > Hannes & Derek > > > > > > > > > > > > _______________________________________________ > > > 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 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e0158b738b1fa610502189670 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Responses inline:=C2=A0

=
2014-08-29 10:00 GMT+09:00 Mike Jones <Michael.Jones@microsoft.com>:

Here's some feedback on the document.

=C2=A0

First, while I believe that the document is a good first working group d= raft and this specification is important, it is not ready for last call, si= nce there are open issues called out in the document that have not been dis= cussed by the working group and aspects of the specification are incomplete.=C2=A0 I=E2= =80=99ll discuss those below.=C2=A0 There are also significant ambiguities = in the document at present that could lead to non-interoperable implementat= ions.=C2=A0 I believe that it would be more appropriate to bring the document to WGLC once these significant issues (and those tha= t may be raised by other reviewers) have been addressed.

=C2=A0

2.=C2=A0 Terminology =E2=80=93 I would list =E2=80=9Ccode challenge=E2= =80=9D before =E2=80=9Ccode verifier=E2=80=9D both because it is used first= and because it=E2=80=99s alphabetically first.

The "code verifier" is listed before "code challenge&q= uot; as the later uses the former in its definition. =C2=A0

=C2=A0

2.1 code verifier =E2=80=93 Is this an octet sequence to be sent as-is (= with the requirement for %-escaping octets representing non-url-safe charac= ters) or as the base64url encoding of the octet sequence?

Previously, it was agreed to be octet sequence and it is to be sent as= -is. The clarification will be added. =C2=A0

=C2=A0

2.2 code challenge =E2=80=93 Same question as above.=C2=A0 Then I would = just say that the code challenge value is a function of the code verifier v= alue and discuss the possible functions in its own section or subsection.

Same as above.=C2=A0
It is an open questi= on whether we want to preserver the extensibility in the transformation at = this time. =C2=A0
If we decide not, then this spec will be furthe= r simplified and this point will become subsumed.=C2=A0

=C2=A0

NOTE 1:=C2=A0 This should be discussed in the section about the transfor= mation function.=C2=A0 Also, say here what criteria people might use to cho= ose function.

=C2=A0

NOTE 2:=C2=A0 Also fold this into the transformation function section.

=C2=A0

3.2 Client registers its desired code challenge algorithm =E2=80=93 A me= ans of registering this algorithm using OAuth Dynamic Client Registration s= hould be defined.=C2=A0 Use of this method should be optional.=C2=A0 Any me= tadata values defines should be registered in the appropriate registry.


As stated above, if we do not need extensibility, we do no= t need this section.=C2=A0
My sense is that we do not. See my res= ponse to Hannes' detailed review.=C2=A0
=C2=A0

=C2=A0

3.4 Client sends the code challenge =E2=80=93 Is the code challenge octe= t sequence value sent or the base64url encoding of it?

As above. =C2=A0

=C2=A0

3.6=C2=A0 Client sends the code and the secret =C2=A0=E2=80=93 Is the co= de verifier octet sequence value sent or the base64url encoding of it?

<= /div>
As above. =C2=A0

=C2=A0

4.1=C2=A0 OAuth Parameters Registry =E2=80=93 The change controller shou= ld be =E2=80=9CIESG=E2=80=9D.

Yes. =C2=A0<= /div>

=C2=A0

5.=C2=A0 Security Considerations =E2=80=93 The implications of choosing = different kinds of transformation functions should be discussed.

<= /div>
Will become unnecessary if we throw the extensibilit= y away at this time. =C2=A0

=C2=A0

I would recommend running the HTML output of xml2rfc through a grammar a= nd spelling checker, as numerous grammar nits would be caught by doing so.<= /p>


Thanks for the advise.=C2= =A0

Best,=C2=A0

Nat=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=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= =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=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=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 -- Mike

=C2=A0

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, August 27, 2014 8:45 AM
To: oauth@ietf.org<= br>
Subject: Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of= Possession for the OAuth Authorization Code Grant"

=

=C2=A0

Based on the reaction from a few I thought I should add a few words abou= t this working group last call.

=C2=A0

There is no requirement to wait a specific timeframe after a document be= came a WG item to issue a working group last call.

=C2=A0

In this specific case, the document was around for a while and I didn= 9;t see a reason for not-finishing it as soon as possible.

=C2=A0

Additionally, since the document deals with a security vulnerability tha= t is being exploited today I thought it might make sense to get the attenti= on from the group to review it.

=C2=A0

Finally, it is also a fairly "simple" document (if there is so= mething as simple in this working group).

=C2=A0

Ciao

Hannes

=C2=A0

On 08/26/2014 09:32 PM, Hannes Tschofenig wrote:

> Hi all,

>

> This is a Last Call for comments on the "Symmetric Proof of Po= ssession

> for the OAuth Authorization Code Grant" specification.<= u>

>

> The document can be found here:

> http://datatracker.ie= tf.org/doc/draft-ietf-oauth-spop/

>

> Please have your comments in no later than September 9th.=

>

> Ciao

> Hannes & Derek

>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org<= /u>

> https://www.ie= tf.org/mailman/listinfo/oauth

>

=C2=A0


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--089e0158b738b1fa610502189670-- From nobody Tue Sep 2 10:50:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BE81A068E for ; Tue, 2 Sep 2014 10:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 m-vug0wFuAYW for ; Tue, 2 Sep 2014 10:50:00 -0700 (PDT) Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879E61A0243 for ; Tue, 2 Sep 2014 10:50:00 -0700 (PDT) Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKVAYDR7YB56cSsLHYFQte6MIzfe4OdQ12@postini.com; Tue, 02 Sep 2014 10:50:00 PDT Received: by mail-ig0-f180.google.com with SMTP id hn18so7683023igb.7 for ; Tue, 02 Sep 2014 10:49:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hPep0joVfvb/EJJsqRIgYeCA5JQ6giOF+6c38TD/umM=; b=Y3IsBIWIZTk4uVbgtPF/PcKtNTfPpQEFB6gPFpC0/Z4d1ZUlbZdYMSbCpF5GPQ6tR9 oiorJPbMc9l3wMCGlvReVEQ7S/fJF6vSs7a7xkvZhmbRIg7fQzqJjmgd2H+Z9SGTpJ+Y LQoFYQzBzsSOe3v4Yq6D6uTC7I+ItnFvovvHj28PqFK3G6EAOzg2UkIeGTgS+M0n9eHJ svFTXsS9NQ9IVzF5JiMF9RBvgUUxk0Qpc4wdQ8NsGHZBUii5v0yz88qoBPGxwAXjhGab 0LMa2c2BDGfQJOg/Mji3493isM3eopGYYRk3Y3LRXPifDjP8X4k0dW+3V7uKxcXfSBdy lUsg== X-Gm-Message-State: ALoCoQk+Adg7PHmBSMcK6dJiHcTRtONjbMklIIOI7SoD/xFjAp1O/gb71TMDSSUHAAxjc1HE6uaOarZ7OwHxAXSFwcx/78PVjPdVrQJMksBAnrGhsTwVPz/1AqYGlcjsmOx4I9D8MwRx X-Received: by 10.42.4.136 with SMTP id 8mr9366245ics.57.1409680199559; Tue, 02 Sep 2014 10:49:59 -0700 (PDT) X-Received: by 10.42.4.136 with SMTP id 8mr9366222ics.57.1409680199274; Tue, 02 Sep 2014 10:49:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.108.135 with HTTP; Tue, 2 Sep 2014 10:49:29 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127C7041D56@WSMSG3153V.srv.dir.telstra.com> References: <53FCE0D7.5010109@gmx.net> <53FDFCFF.8010606@gmx.net> <29CFEF98-9B5F-418D-A799-DD0B536B8090@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E127C7041D56@WSMSG3153V.srv.dir.telstra.com> From: Brian Campbell Date: Tue, 2 Sep 2014 11:49:29 -0600 Message-ID: To: "Manger, James" Content-Type: multipart/alternative; boundary=001a1134476c866ad9050218bf12 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RX4j9gXW5aHqfFSoC3OgGQjReQY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 17:50:03 -0000 --001a1134476c866ad9050218bf12 Content-Type: text/plain; charset=UTF-8 On #1, I know some have pushed for having the transformation options so I don't know if dropping it will work. But, if not removed entirely, the transformation stuff could definitely be deemphasized in favor of what will be the most common case of the client sending a random string value on the authorization request and then sending the same value on the token request. On #2, there are already implementations and deployments of this so I'd request that the parameter names not be changed. On #3, I agree that the title is confusing/misleading. Perhaps, "Request Correlation for the OAuth Authorization Code Grant" or something like that? On #4, on one hand you are right. On the other hand, this is the OAuth WG and this draft is addressing a very specific security issue in OAuth deployments. Having it be OAuth-centric seems right given the circumstances. On Thu, Aug 28, 2014 at 11:03 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > Couple of comments on draft-ietf-oauth-spop-00: > > The draft defines a nice little mechanism to link two requests: one from > app-to-browser-to-server, the other from app-to-server. > > 1. > The spec defines the "bearer token" version of linking the requests: pick > a random value and send it in both requests. The spec repeatedly hints that > other "transformations" are possible (and even mentions one in a note), but > it doesn't define enough to make these other ones interoperable. > I suggest just specifying the bearer version and dropping all the other > text. > If we want another transform standardized later then we write another spec > (which can use its own field names). > > 2. > Linking requests is orthogonal to whether or not the requests include a > field called "code". I suggest changing the labels "code_challenge" and > "code_verifier" to drop the "code" reference. Perhaps replace both with > "session_id" ("sid" for short?). > > 3. > The spec is titled "Symmetric Proof of Possession ..." but defines a > bearer mechanism, which you cannot really classify as proof-of-possession. > Suggestion: change the title. > > 4. > The text is totally OAuth-centric, though the mechanism is not really > limited to this case. It would be much nicer to describe the mechanism more > generically (eg app running on a user's computer wanting to link two > requests made to a server over different channels). The abstract (and the > start of the introduction) should be comprehensible without having to know > what the phrase "OAuth 2.0 public client" means. There would still be some > OAuth-specific sections describing how the mechanism applies to the code > flow (and to register a field in the IANA OAuth registry). > > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1134476c866ad9050218bf12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On #1, I know some have pushed for hav= ing the transformation options so I don't know if dropping it will work= . But, if not removed entirely, the transformation stuff could definitely b= e deemphasized in favor of what will be the most common case of the client = sending a random string value on the authorization request and then sending= the same value on the token request.

On #2, there are already implementations and deployments of this = so I'd request that the parameter names not be changed.

On= #3, I agree that the title is confusing/misleading. Perhaps, "Request= Correlation for the OAuth Authorization Code Grant" or something like= that?

On #4, on one hand you are right. On the other hand, this is the = OAuth WG and this draft is addressing a very specific security issue in OAu= th deployments. Having it be OAuth-centric seems right given the circumstan= ces.




<= div class=3D"gmail_quote">On Thu, Aug 28, 2014 at 11:03 PM, Manger, James <= span dir=3D"ltr"><James.H.Manger@team.telstra.com> wrote:
Couple of comments on dra= ft-ietf-oauth-spop-00:

The draft defines a nice little mechanism to link two requests: one from ap= p-to-browser-to-server, the other from app-to-server.

1.
The spec defines the "bearer token" version of linking the reques= ts: pick a random value and send it in both requests. The spec repeatedly h= ints that other "transformations" are possible (and even mentions= one in a note), but it doesn't define enough to make these other ones = interoperable.
I suggest just specifying the bearer version and dropping all the other tex= t.
If we want another transform standardized later then we write another spec = (which can use its own field names).

2.
Linking requests is orthogonal to whether or not the requests include a fie= ld called "code". I suggest changing the labels "code_challe= nge" and "code_verifier" to drop the "code" refere= nce. Perhaps replace both with "session_id" ("sid" for = short?).

3.
The spec is titled "Symmetric Proof of Possession ..." but define= s a bearer mechanism, which you cannot really classify as proof-of-possessi= on. Suggestion: change the title.

4.
The text is totally OAuth-centric, though the mechanism is not really limit= ed to this case. It would be much nicer to describe the mechanism more gene= rically (eg app running on a user's computer wanting to link two reques= ts made to a server over different channels). The abstract (and the start o= f the introduction) should be comprehensible without having to know what th= e phrase "OAuth 2.0 public client" means. There would still be so= me OAuth-specific sections describing how the mechanism applies to the code= flow (and to register a field in the IANA OAuth registry).


--
James Manger

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

--001a1134476c866ad9050218bf12-- From nobody Tue Sep 2 11:32:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071AA1A0677 for ; Tue, 2 Sep 2014 11:32:29 -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, SPF_PASS=-0.001] autolearn=ham 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 UWiuUjp244SN for ; Tue, 2 Sep 2014 11:32:26 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6191A063E for ; Tue, 2 Sep 2014 11:32:26 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id pn19so8366975lab.32 for ; Tue, 02 Sep 2014 11:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jJ+B5WnnwdRT2va8PAfHlnC6X1U/cvMhrma+Een9mAE=; b=UWTCs/IJAfnRAoBZsCCKGYaAvR4zWvx6j7WbmZBQfgnCfJdGLg4e8tvzCKrx1npPBy ILjj8mtCQJdl2TZPeeAek/fFC/BkisPBviGgrAQshfwC/gJz4b7F65Qwsa+1yGz2A5+i tSQ+EqbHX3XZLR0fWtW1uAWFcLgAQ1+JR4R0eyzJ5fh7Wzs0TF01OXhmRTg9nYKUFnuM TDDio/V/t/0bGrr+u0lzT/YARwRe4LKcYBmKPYoy8SAjnk8E1rocmWsYiaDGwVoD51nt pCqbKo1/nn29yvEwZOgeVUAMR3MTxA6SAFoNzuPgacfeoEP6Y9qXirVipzx3CH1hTW65 pG/w== MIME-Version: 1.0 X-Received: by 10.152.7.212 with SMTP id l20mr36793220laa.7.1409682744444; Tue, 02 Sep 2014 11:32:24 -0700 (PDT) Received: by 10.112.9.36 with HTTP; Tue, 2 Sep 2014 11:32:24 -0700 (PDT) In-Reply-To: References: <53FCE0D7.5010109@gmx.net> <53FDFCFF.8010606@gmx.net> <29CFEF98-9B5F-418D-A799-DD0B536B8090@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E127C7041D56@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 3 Sep 2014 03:32:24 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c34a0a3a8e63050219575d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0j5jviBTS4VrFiAmSJuc4eAinQU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 18:32:29 -0000 --001a11c34a0a3a8e63050219575d Content-Type: text/plain; charset=UTF-8 Hi James and Brian, First, I apologize for taking a long time to respond to James. My responses inline: 2014-09-03 2:49 GMT+09:00 Brian Campbell : > On #1, I know some have pushed for having the transformation options so I > don't know if dropping it will work. But, if not removed entirely, the > transformation stuff could definitely be deemphasized in favor of what will > be the most common case of the client sending a random string value on the > authorization request and then sending the same value on the token request. > Indeed, there have been some lengthy discussions around it, so I have not removed them. However, if the WG feels that it is ok to leave them out, I am fine with it. It would impact the name of the spec though, as it will not be PoP anymore. The justification for using PoP in the name is that in non-degenerate case, it is a PoP. > > On #2, there are already implementations and deployments of this so I'd > request that the parameter names not be changed. > Noted. > > On #3, I agree that the title is confusing/misleading. Perhaps, "Request > Correlation for the OAuth Authorization Code Grant" or something like that? > See #1. > > On #4, on one hand you are right. On the other hand, this is the OAuth WG > and this draft is addressing a very specific security issue in OAuth > deployments. Having it be OAuth-centric seems right given the circumstances. > IMHO, this is a scoping issue. The current draft is scoped to solve a specific problem of OAuth public clients. More generic way can obviously be envisaged, but I am not sure if it is something to be worked on within OAuth WG. Nat > > > > > On Thu, Aug 28, 2014 at 11:03 PM, Manger, James < > James.H.Manger@team.telstra.com> wrote: > >> Couple of comments on draft-ietf-oauth-spop-00: >> >> The draft defines a nice little mechanism to link two requests: one from >> app-to-browser-to-server, the other from app-to-server. >> >> 1. >> The spec defines the "bearer token" version of linking the requests: pick >> a random value and send it in both requests. The spec repeatedly hints that >> other "transformations" are possible (and even mentions one in a note), but >> it doesn't define enough to make these other ones interoperable. >> I suggest just specifying the bearer version and dropping all the other >> text. >> If we want another transform standardized later then we write another >> spec (which can use its own field names). >> >> 2. >> Linking requests is orthogonal to whether or not the requests include a >> field called "code". I suggest changing the labels "code_challenge" and >> "code_verifier" to drop the "code" reference. Perhaps replace both with >> "session_id" ("sid" for short?). >> >> 3. >> The spec is titled "Symmetric Proof of Possession ..." but defines a >> bearer mechanism, which you cannot really classify as proof-of-possession. >> Suggestion: change the title. >> >> 4. >> The text is totally OAuth-centric, though the mechanism is not really >> limited to this case. It would be much nicer to describe the mechanism more >> generically (eg app running on a user's computer wanting to link two >> requests made to a server over different channels). The abstract (and the >> start of the introduction) should be comprehensible without having to know >> what the phrase "OAuth 2.0 public client" means. There would still be some >> OAuth-specific sections describing how the mechanism applies to the code >> flow (and to register a field in the IANA OAuth registry). >> >> >> -- >> James Manger >> >> _______________________________________________ >> 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 > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c34a0a3a8e63050219575d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi James and Brian,=C2=A0

First, I apol= ogize for taking a long time to respond to James.=C2=A0

My responses inline:=C2=A0


2014-09-03 2:49 GMT+09:00 Brian Campbell <bcampbell@pingidentity.= com>:
On #1, I know some have pushed for hav= ing the transformation options so I don't know if dropping it will work= . But, if not removed entirely, the transformation stuff could definitely b= e deemphasized in favor of what will be the most common case of the client = sending a random string value on the authorization request and then sending= the same value on the token request.

Indeed, ther= e have been some lengthy discussions around it, so I have not removed them.= =C2=A0
However, if the WG feels that it is ok to leave them out, = I am fine with it.=C2=A0
It would impact the name of the spec though, as it will not be PoP any= more.=C2=A0
The justification for using PoP in the name is that i= n non-degenerate case, it is a PoP.=C2=A0
=C2=A0

On #2, there are already implementations and deployments of this = so I'd request that the parameter names not be changed.
=

Noted.=C2=A0
=C2=A0<= /div>

On= #3, I agree that the title is confusing/misleading. Perhaps, "Request= Correlation for the OAuth Authorization Code Grant" or something like= that?

See #1.=C2=A0
= =C2=A0

On #4, on one hand you are right. On the other hand, this is the = OAuth WG and this draft is addressing a very specific security issue in OAu= th deployments. Having it be OAuth-centric seems right given the circumstan= ces.

IMHO, this is a scoping issue.= The current draft is scoped to solve a specific problem of OAuth public cl= ients.=C2=A0
More generic way can obviously be envisaged, but I a= m not sure if it is something to be worked on within OAuth WG.=C2=A0

Nat
=C2=A0




On Thu, Aug 28, 2014 at 11= :03 PM, Manger, James <James.H.Manger@team.telstra.com&g= t; wrote:
Couple of comments on dra= ft-ietf-oauth-spop-00:

The draft defines a nice little mechanism to link two requests: one from ap= p-to-browser-to-server, the other from app-to-server.

1.
The spec defines the "bearer token" version of linking the reques= ts: pick a random value and send it in both requests. The spec repeatedly h= ints that other "transformations" are possible (and even mentions= one in a note), but it doesn't define enough to make these other ones = interoperable.
I suggest just specifying the bearer version and dropping all the other tex= t.
If we want another transform standardized later then we write another spec = (which can use its own field names).

2.
Linking requests is orthogonal to whether or not the requests include a fie= ld called "code". I suggest changing the labels "code_challe= nge" and "code_verifier" to drop the "code" refere= nce. Perhaps replace both with "session_id" ("sid" for = short?).

3.
The spec is titled "Symmetric Proof of Possession ..." but define= s a bearer mechanism, which you cannot really classify as proof-of-possessi= on. Suggestion: change the title.

4.
The text is totally OAuth-centric, though the mechanism is not really limit= ed to this case. It would be much nicer to describe the mechanism more gene= rically (eg app running on a user's computer wanting to link two reques= ts made to a server over different channels). The abstract (and the start o= f the introduction) should be comprehensible without having to know what th= e phrase "OAuth 2.0 public client" means. There would still be so= me OAuth-specific sections describing how the mechanism applies to the code= flow (and to register a field in the IANA OAuth registry).


--
James Manger

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


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c34a0a3a8e63050219575d-- From nobody Tue Sep 2 13:17:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939CB1A88BF for ; Tue, 2 Sep 2014 13:17:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 wZVJ9L7b7CQN for ; Tue, 2 Sep 2014 13:17:27 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD31C1A88B2 for ; Tue, 2 Sep 2014 13:17:26 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id s18so8403099lam.6 for ; Tue, 02 Sep 2014 13:17:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zmMERv6C8a9ZHAcXs9qQyhEz6U3vkasWUrE/wY/2Mec=; b=mf+ne4NWi9srT6gC34pyAmrxhyAZSHH04D3mwYV5CRQmDoS9O+e/q3GvJ9rfQYazY/ iJb9bPMVyK+FEi8O8w+y3gZFJNhbYRgCMumVKz6mLXV++qeZnk6vc5NjGJjrTNJgjVu2 b4ogvQYKnArSadeQQbQwE0hyBolgxzRQeblx5+QefQAfq1qXV4Ws9wwFtJwty16KUw0j w1cMCgovRXhkwNd1sIh46DBDvlQd/sb87/OS+c4GeCrvRvIa5Rl0BwDefMjxDhjlVODK pO4eszQuw9lyoCEyZ558gd3uyjhagfLXFxwaAb5qWM0IjGw+42LNUWDGGRlOf6O+s4T8 kmSA== X-Gm-Message-State: ALoCoQnULhxjojvY2k/ISdTGgE87/WXJbplQ/utewxNcmW0pXBElac5wDN115bhShLNqJv/6jDYt X-Received: by 10.152.44.230 with SMTP id h6mr36890945lam.51.1409689044824; Tue, 02 Sep 2014 13:17:24 -0700 (PDT) Received: from [192.168.49.148] (seabed-1-2-ci.cust.versatel.net. [87.213.30.114]) by mx.google.com with ESMTPSA id ls6sm85165lac.2.2014.09.02.13.17.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Sep 2014 13:17:23 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2ACE3505-05B0-462C-A796-285E6FCA1EB3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Tue, 2 Sep 2014 16:17:20 -0400 Message-Id: <614B9BC1-B9E2-4A7C-B540-81B7D9CD96BF@ve7jtb.com> References: <53FCE0D7.5010109@gmx.net> <53FDFCFF.8010606@gmx.net> <29CFEF98-9B5F-418D-A799-DD0B536B8090@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E127C7041D56@WSMSG3153V.srv.dir.telstra.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/diWqV-ADZrjbYVWbAMsxxCuSdyo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:17:32 -0000 --Apple-Mail=_2ACE3505-05B0-462C-A796-285E6FCA1EB3 Content-Type: multipart/alternative; boundary="Apple-Mail=_1C0BD05A-5746-4330-9675-161EAD0EB544" --Apple-Mail=_1C0BD05A-5746-4330-9675-161EAD0EB544 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I don't think the inclusion of a MAC transform to protect the request is = necessary for it to be called proof of possession. The other way to protect the request is with a signed/encrypted request = object. That is heaver weight than the HMAC transform. I may have come up with the trick of sending the hmac in the request and = the key as the proof, so am a bit partial to it. On the other hand I don't know that the incremental value is that much. It may be better to skip that and add a way for a client to specify it's = public key (JWK) as part of it's authorization request to the AS.=20 I see that more as part of the full OAuth PoP spec for access tokens. That way the access tokens would also be bound to the client. =20 That would let us keep SPOP for code as simple as possible. John B. On Sep 2, 2014, at 2:32 PM, Nat Sakimura wrote: > Hi James and Brian,=20 >=20 > First, I apologize for taking a long time to respond to James.=20 >=20 > My responses inline:=20 >=20 >=20 > 2014-09-03 2:49 GMT+09:00 Brian Campbell : > On #1, I know some have pushed for having the transformation options = so I don't know if dropping it will work. But, if not removed entirely, = the transformation stuff could definitely be deemphasized in favor of = what will be the most common case of the client sending a random string = value on the authorization request and then sending the same value on = the token request. >=20 > Indeed, there have been some lengthy discussions around it, so I have = not removed them.=20 > However, if the WG feels that it is ok to leave them out, I am fine = with it.=20 > It would impact the name of the spec though, as it will not be PoP = anymore.=20 > The justification for using PoP in the name is that in non-degenerate = case, it is a PoP.=20 > =20 >=20 > On #2, there are already implementations and deployments of this so = I'd request that the parameter names not be changed. >=20 > Noted.=20 > =20 >=20 > On #3, I agree that the title is confusing/misleading. Perhaps, = "Request Correlation for the OAuth Authorization Code Grant" or = something like that? >=20 > See #1.=20 > =20 >=20 > On #4, on one hand you are right. On the other hand, this is the OAuth = WG and this draft is addressing a very specific security issue in OAuth = deployments. Having it be OAuth-centric seems right given the = circumstances. >=20 > IMHO, this is a scoping issue. The current draft is scoped to solve a = specific problem of OAuth public clients.=20 > More generic way can obviously be envisaged, but I am not sure if it = is something to be worked on within OAuth WG.=20 >=20 > Nat > =20 >=20 >=20 >=20 >=20 > On Thu, Aug 28, 2014 at 11:03 PM, Manger, James = wrote: > Couple of comments on draft-ietf-oauth-spop-00: >=20 > The draft defines a nice little mechanism to link two requests: one = from app-to-browser-to-server, the other from app-to-server. >=20 > 1. > The spec defines the "bearer token" version of linking the requests: = pick a random value and send it in both requests. The spec repeatedly = hints that other "transformations" are possible (and even mentions one = in a note), but it doesn't define enough to make these other ones = interoperable. > I suggest just specifying the bearer version and dropping all the = other text. > If we want another transform standardized later then we write another = spec (which can use its own field names). >=20 > 2. > Linking requests is orthogonal to whether or not the requests include = a field called "code". I suggest changing the labels "code_challenge" = and "code_verifier" to drop the "code" reference. Perhaps replace both = with "session_id" ("sid" for short?). >=20 > 3. > The spec is titled "Symmetric Proof of Possession ..." but defines a = bearer mechanism, which you cannot really classify as = proof-of-possession. Suggestion: change the title. >=20 > 4. > The text is totally OAuth-centric, though the mechanism is not really = limited to this case. It would be much nicer to describe the mechanism = more generically (eg app running on a user's computer wanting to link = two requests made to a server over different channels). The abstract = (and the start of the introduction) should be comprehensible without = having to know what the phrase "OAuth 2.0 public client" means. There = would still be some OAuth-specific sections describing how the mechanism = applies to the code flow (and to register a field in the IANA OAuth = registry). >=20 >=20 > -- > James Manger >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://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 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1C0BD05A-5746-4330-9675-161EAD0EB544 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = don't think the inclusion of a MAC transform to protect the request is = necessary for it to be called proof of = possession.

The other way to protect the request is = with a signed/encrypted request object.  That is heaver weight than = the HMAC transform.

I may have come up with the = trick of sending the hmac in the request and the key as the proof, so am = a bit partial to it.

On the other hand I don't = know that the incremental value is that = much.

It may be better to skip that and add a = way for a client to specify it's public key (JWK) as part of it's = authorization request to the AS. 

I see = that more as part of the full OAuth PoP spec for access = tokens.

That way the access tokens would also = be bound to the client.   

That would = let us keep SPOP for code as simple as = possible.

John B.
On Sep 2, 2014, = at 2:32 PM, Nat Sakimura <sakimura@gmail.com> = wrote:

Hi James and Brian, 

First, I = apologize for taking a long time to respond to = James. 

My responses inline: 


2014-09-03 2:49 = GMT+09:00 Brian Campbell <bcampbell@pingidentity.com>:
On #1, I = know some have pushed for having the transformation options so I don't = know if dropping it will work. But, if not removed entirely, the = transformation stuff could definitely be deemphasized in favor of what = will be the most common case of the client sending a random string value = on the authorization request and then sending the same value on the = token request.

Indeed, there = have been some lengthy discussions around it, so I have not removed = them. 
However, if the WG feels that it is ok to leave = them out, I am fine with it. 
It would impact the name of = the spec though, as it will not be PoP anymore. 
The = justification for using PoP in the name is that in non-degenerate case, = it is a PoP. 
 

On #2, there are = already implementations and deployments of this so I'd request that the = parameter names not be = changed.

Noted. 
=  

On #3, I agree that the title is = confusing/misleading. Perhaps, "Request Correlation for the OAuth = Authorization Code Grant" or something like = that?

See = #1. 
 

On #4, on one hand = you are right. On the other hand, this is the OAuth WG and this draft is = addressing a very specific security issue in OAuth deployments. Having = it be OAuth-centric seems right given the = circumstances.

IMHO, this is a = scoping issue. The current draft is scoped to solve a specific problem = of OAuth public clients. 
More generic way can obviously = be envisaged, but I am not sure if it is something to be worked on = within OAuth = WG. 

Nat
 




On Thu, Aug 28, = 2014 at 11:03 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:
Couple of comments on = draft-ietf-oauth-spop-00:

The draft defines a nice little = mechanism to link two requests: one from app-to-browser-to-server, the = other from app-to-server.

1.
The spec defines the "bearer = token" version of linking the requests: pick a random value and send it = in both requests. The spec repeatedly hints that other "transformations" = are possible (and even mentions one in a note), but it doesn't define = enough to make these other ones interoperable.
I suggest just = specifying the bearer version and dropping all the other text.
If we = want another transform standardized later then we write another spec = (which can use its own field names).

2.
Linking requests is = orthogonal to whether or not the requests include a field called "code". = I suggest changing the labels "code_challenge" and "code_verifier" to = drop the "code" reference. Perhaps replace both with "session_id" ("sid" = for short?).

3.
The spec is titled "Symmetric Proof of = Possession ..." but defines a bearer mechanism, which you cannot really = classify as proof-of-possession. Suggestion: change the = title.

4.
The text is totally OAuth-centric, though the = mechanism is not really limited to this case. It would be much nicer to = describe the mechanism more generically (eg app running on a user's = computer wanting to link two requests made to a server over different = channels). The abstract (and the start of the introduction) should be = comprehensible without having to know what the phrase "OAuth 2.0 public = client" means. There would still be some OAuth-specific sections = describing how the mechanism applies to the code flow (and to register a = field in the IANA OAuth registry).


--
James = Manger

_______________________________________________
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

<= /blockquote>



-- 
Nat Sakimura = (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
= --Apple-Mail=_1C0BD05A-5746-4330-9675-161EAD0EB544-- --Apple-Mail=_2ACE3505-05B0-462C-A796-285E6FCA1EB3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MDIyMDE3MjBaMCMGCSqGSIb3DQEJBDEWBBT8dH6ai+AHxNznxgEZyi0a 0fc4MjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBX4hRP53XUwi9TrEpx3GTuazOJ4KB+zeeCoqqlZLe5iz/2RLL4M2YQ HzK2e6Zr1qRzVxwCRz40iqD4hjfIqXLGR3jyrwDDaF5ZXA8C6zrw/2KoUNt2ljpUq0DcdAZHzUfN 7eiWPNawmfgdI+r+Rf2KRdBAL+Tw2ZlueSVPnoEBgYeaIvVMcZZEaBDc3ZHBHG8qFw6tMpi8/VuU 5ZxXg7JtITi5SiUyN/k5idIgOhncQPYpiolgLxpw/RtFo57YBEtipVlGOVn4dQcTdR40wGUTTYbp tEky69gyi9iz7lZJm53wvFFS0Sr1LglzjtsBfR48z4NGhSaQsnkVIOfpnxXbAAAAAAAA --Apple-Mail=_2ACE3505-05B0-462C-A796-285E6FCA1EB3-- From nobody Tue Sep 2 18:13:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E8F1A892A for ; Tue, 2 Sep 2014 18:13:38 -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, SPF_PASS=-0.001] autolearn=ham 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 zTnL958p1-zj for ; Tue, 2 Sep 2014 18:13:35 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B9A1A0072 for ; Tue, 2 Sep 2014 18:13:34 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id s7so297921lbd.12 for ; Tue, 02 Sep 2014 18:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kgS865VQQWYTmTyNpGjlIL5wNyei2R3v1N2M349Pp9w=; b=CqlVh1aui79z14aa6EYfPi6KS2Usqsvwj5S6ZbG3uQMLvsgbEKNy/jPiJ2MfFO+i8s epl70ns6VUoraWXZygDciGh3RctJF2Sqw4I8aEaTe1nsTHVXi+JAYeR43r4JSoBcYAKP yJVcvoJ3VvrNTJGAIvL1Us20o/9zbn6hIuhSXIxX4s7jOA5+zHgcgaEnqsQ7anzh/JSa IskQFrtvihfrh/Ac5N7sPA170nveXm4ciWrrjZ5f/GGUDuzVNYvRIT7fGsrYXeIY6vy3 9cSWMSM//jXHvmFeAKwgNdj5TKWpUaHDv6KHX0sfwPUuZaptvL87vFrdTYJZ1vuC3NNe ZBEg== MIME-Version: 1.0 X-Received: by 10.152.121.37 with SMTP id lh5mr38418024lab.43.1409706812591; Tue, 02 Sep 2014 18:13:32 -0700 (PDT) Received: by 10.112.9.36 with HTTP; Tue, 2 Sep 2014 18:13:32 -0700 (PDT) In-Reply-To: <614B9BC1-B9E2-4A7C-B540-81B7D9CD96BF@ve7jtb.com> References: <53FCE0D7.5010109@gmx.net> <53FDFCFF.8010606@gmx.net> <29CFEF98-9B5F-418D-A799-DD0B536B8090@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E127C7041D56@WSMSG3153V.srv.dir.telstra.com> <614B9BC1-B9E2-4A7C-B540-81B7D9CD96BF@ve7jtb.com> Date: Wed, 3 Sep 2014 10:13:32 +0900 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=089e0122797ccd56c205021ef1f9 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/z3AFy63umPjmqZlIHSU5xfaC1_w Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 01:13:38 -0000 --089e0122797ccd56c205021ef1f9 Content-Type: text/plain; charset=UTF-8 I support the use of public key. As I remember, our discussion started there. I still believe this is something that is needed to be standardized. However, for spop use case, we have determined that is overkill and best left for another draft. It looks like there is a strong support in the thread to droop the transform. I have not heard any strong desire to keep the extensibility. If any of you do, please voice it now. Otherwise, I will drop the transform related clauses from the next rev. Nat 2014-09-03 5:17 GMT+09:00 John Bradley : > I don't think the inclusion of a MAC transform to protect the request is > necessary for it to be called proof of possession. > > The other way to protect the request is with a signed/encrypted request > object. That is heaver weight than the HMAC transform. > > I may have come up with the trick of sending the hmac in the request and > the key as the proof, so am a bit partial to it. > > On the other hand I don't know that the incremental value is that much. > > It may be better to skip that and add a way for a client to specify it's > public key (JWK) as part of it's authorization request to the AS. > > I see that more as part of the full OAuth PoP spec for access tokens. > > That way the access tokens would also be bound to the client. > > That would let us keep SPOP for code as simple as possible. > > John B. > > On Sep 2, 2014, at 2:32 PM, Nat Sakimura wrote: > > Hi James and Brian, > > First, I apologize for taking a long time to respond to James. > > My responses inline: > > > 2014-09-03 2:49 GMT+09:00 Brian Campbell : > >> On #1, I know some have pushed for having the transformation options so I >> don't know if dropping it will work. But, if not removed entirely, the >> transformation stuff could definitely be deemphasized in favor of what will >> be the most common case of the client sending a random string value on the >> authorization request and then sending the same value on the token request. >> > > Indeed, there have been some lengthy discussions around it, so I have not > removed them. > However, if the WG feels that it is ok to leave them out, I am fine with > it. > It would impact the name of the spec though, as it will not be PoP > anymore. > The justification for using PoP in the name is that in non-degenerate > case, it is a PoP. > > >> >> On #2, there are already implementations and deployments of this so I'd >> request that the parameter names not be changed. >> > > Noted. > > >> >> On #3, I agree that the title is confusing/misleading. Perhaps, "Request >> Correlation for the OAuth Authorization Code Grant" or something like that? >> > > See #1. > > >> >> On #4, on one hand you are right. On the other hand, this is the OAuth WG >> and this draft is addressing a very specific security issue in OAuth >> deployments. Having it be OAuth-centric seems right given the circumstances. >> > > IMHO, this is a scoping issue. The current draft is scoped to solve a > specific problem of OAuth public clients. > More generic way can obviously be envisaged, but I am not sure if it is > something to be worked on within OAuth WG. > > Nat > > >> >> >> >> >> On Thu, Aug 28, 2014 at 11:03 PM, Manger, James < >> James.H.Manger@team.telstra.com> wrote: >> >>> Couple of comments on draft-ietf-oauth-spop-00: >>> >>> The draft defines a nice little mechanism to link two requests: one from >>> app-to-browser-to-server, the other from app-to-server. >>> >>> 1. >>> The spec defines the "bearer token" version of linking the requests: >>> pick a random value and send it in both requests. The spec repeatedly hints >>> that other "transformations" are possible (and even mentions one in a >>> note), but it doesn't define enough to make these other ones interoperable. >>> I suggest just specifying the bearer version and dropping all the other >>> text. >>> If we want another transform standardized later then we write another >>> spec (which can use its own field names). >>> >>> 2. >>> Linking requests is orthogonal to whether or not the requests include a >>> field called "code". I suggest changing the labels "code_challenge" and >>> "code_verifier" to drop the "code" reference. Perhaps replace both with >>> "session_id" ("sid" for short?). >>> >>> 3. >>> The spec is titled "Symmetric Proof of Possession ..." but defines a >>> bearer mechanism, which you cannot really classify as proof-of-possession. >>> Suggestion: change the title. >>> >>> 4. >>> The text is totally OAuth-centric, though the mechanism is not really >>> limited to this case. It would be much nicer to describe the mechanism more >>> generically (eg app running on a user's computer wanting to link two >>> requests made to a server over different channels). The abstract (and the >>> start of the introduction) should be comprehensible without having to know >>> what the phrase "OAuth 2.0 public client" means. There would still be some >>> OAuth-specific sections describing how the mechanism applies to the code >>> flow (and to register a field in the IANA OAuth registry). >>> >>> >>> -- >>> James Manger >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e0122797ccd56c205021ef1f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the use of public key. As I remember, our discus= sion started there.=C2=A0
I still believe this is something that is nee= ded to be standardized.=C2=A0

However, for spop use = case, we have determined that is overkill and best left for another draft.= =C2=A0

It looks like there is a strong support in the thread t= o droop the transform.=C2=A0
I have not heard any strong desire t= o keep the extensibility.=C2=A0

If any of you do, = please voice it now.=C2=A0
Otherwise, I will drop the transform related clauses from the next rev= .=C2=A0

Nat


2014-09-03 5:17 GMT+09:00 John Bra= dley <ve7jtb@ve7jtb.com>:
I don= 9;t think the inclusion of a MAC transform to protect the request is necess= ary for it to be called proof of possession.

The other way to protect the request is with a signed/encryp= ted request object. =C2=A0That is heaver weight than the HMAC transform.

I may have come up with the trick of sending the hma= c in the request and the key as the proof, so am a bit partial to it.

On the other hand I don't know that the incremental= value is that much.

It may be better to skip that= and add a way for a client to specify it's public key (JWK) as part of= it's authorization request to the AS.=C2=A0

I see that more as part of the full OAuth PoP spec for = access tokens.

That way the access tokens would al= so be bound to the client. =C2=A0=C2=A0

That would= let us keep SPOP for code as simple as possible.

John B.

On Sep 2, 2= 014, at 2:32 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Hi James and Brian,=C2=A0

First, I apol= ogize for taking a long time to respond to James.=C2=A0

My responses inline:=C2=A0


2014-09-03 2:49 GMT+09:00 Brian Campbell=C2=A0<bcamp= bell@pingidentity.com>:
On #1, I know some have pushed for having the transformati= on options so I don't know if dropping it will work. But, if not remove= d entirely, the transformation stuff could definitely be deemphasized in fa= vor of what will be the most common case of the client sending a random str= ing value on the authorization request and then sending the same value on t= he token request.

Indeed, there have been some lengthy= discussions around it, so I have not removed them.=C2=A0
However= , if the WG feels that it is ok to leave them out, I am fine with it.=C2=A0=
It would impact the name of the spec though, as it will not be PoP any= more.=C2=A0
The justification for using PoP in the name is that i= n non-degenerate case, it is a PoP.=C2=A0
=C2=A0

On #2, there are already implementations an= d deployments of this so I'd request that the parameter names not be ch= anged.

Noted.=C2=A0
=C2= =A0

On #3, I agree that the ti= tle is confusing/misleading. Perhaps, "Request Correlation for the OAu= th Authorization Code Grant" or something like that?

See #1.=C2=A0
=C2=A0
=

On #4, on one hand you are right. On the ot= her hand, this is the OAuth WG and this draft is addressing a very specific= security issue in OAuth deployments. Having it be OAuth-centric seems righ= t given the circumstances.

IMHO, this is a scoping issue. The c= urrent draft is scoped to solve a specific problem of OAuth public clients.= =C2=A0
More generic way can obviously be envisaged, but I am not = sure if it is something to be worked on within OAuth WG.=C2=A0

Nat
=C2=A0




On Thu, Aug 28, 2014 at 11:03 PM, Manger, James=C2= =A0<James.H.Manger@team.telstra.com>=C2=A0wrote:
Couple of comments on draft-ietf-oauth-spop-00:

The= draft defines a nice little mechanism to link two requests: one from app-t= o-browser-to-server, the other from app-to-server.

1.
The spec defines the "bearer token" version of linking = the requests: pick a random value and send it in both requests. The spec re= peatedly hints that other "transformations" are possible (and eve= n mentions one in a note), but it doesn't define enough to make these o= ther ones interoperable.
I suggest just specifying the bearer version and dropping all the other tex= t.
If we want another transform standardized later then we write another= spec (which can use its own field names).

2.
Linking requests is= orthogonal to whether or not the requests include a field called "cod= e". I suggest changing the labels "code_challenge" and "= ;code_verifier" to drop the "code" reference. Perhaps replac= e both with "session_id" ("sid" for short?).

3.
The spec is titled "Symmetric Proof of Possession ..." = but defines a bearer mechanism, which you cannot really classify as proof-o= f-possession. Suggestion: change the title.

4.
The text is totall= y OAuth-centric, though the mechanism is not really limited to this case. I= t would be much nicer to describe the mechanism more generically (eg app ru= nning on a user's computer wanting to link two requests made to a serve= r over different channels). The abstract (and the start of the introduction= ) should be comprehensible without having to know what the phrase "OAu= th 2.0 public client" means. There would still be some OAuth-specific = sections describing how the mechanism applies to the code flow (and to regi= ster a field in the IANA OAuth registry).


--
James Manger

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


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




--=C2=A0<= /span>
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth = mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dnat)
Chairman, Open= ID Foundation
htt= p://nat.sakimura.org/
@_nat_en
--089e0122797ccd56c205021ef1f9-- From nobody Tue Sep 2 18:46:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16F01A8949; Tue, 2 Sep 2014 18:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 U-8TTVAHSPwq; Tue, 2 Sep 2014 18:46:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953571A894A; Tue, 2 Sep 2014 18:46:03 -0700 (PDT) Received: from BLUPR03CA007.namprd03.prod.outlook.com (10.255.124.24) by BY2PR03MB621.namprd03.prod.outlook.com (10.255.93.43) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 01:46:00 +0000 Received: from BL2FFO11FD010.protection.gbl (207.46.163.210) by BLUPR03CA007.outlook.office365.com (10.255.124.24) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Wed, 3 Sep 2014 01:45:59 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Wed, 3 Sep 2014 01:45:59 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.122]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Wed, 3 Sep 2014 01:45:49 +0000 From: Mike Jones To: Tom Taylor , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , Gen Art Thread-Topic: Last Call Review of draft-ietf-oauth-json-web-token-25 Thread-Index: AQHPv0z0jG6qUdtWVkC2NMgTF7uzG5vussTg Date: Wed, 3 Sep 2014 01:45:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AE76189@TK5EX14MBXC294.redmond.corp.microsoft.com> References: <53F95E44.2030307@gmail.com> In-Reply-To: <53F95E44.2030307@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(377454003)(479174003)(13464003)(199003)(189002)(51914003)(83072002)(85852003)(77982001)(86362001)(107046002)(19580405001)(106466001)(83322001)(19580395003)(81342001)(81156004)(106116001)(97756001)(15202345003)(6806004)(99396002)(44976005)(85306004)(4396001)(2656002)(23726002)(21056001)(90102001)(79102001)(76482001)(87936001)(55846006)(230783001)(92566001)(92726001)(50466002)(74502001)(77096002)(31966008)(86612001)(46406003)(50986999)(76176999)(54356999)(95666004)(46102001)(81542001)(15975445006)(47776003)(20776003)(64706001)(69596002)(97736001)(84676001)(74662001)(68736004)(33656002)(66066001)(80022001)(26826002)(104016003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB621; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 032334F434 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Bgjcx6BrkmkayunJUvjgb4Devag Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call Review of draft-ietf-oauth-json-web-token-25 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 01:46:06 -0000 Thanks for the review, Tom. I've cc'ed the OAuth working group so that the= y're aware of the contents of your review. -- Mike -----Original Message----- From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]=20 Sent: Saturday, August 23, 2014 8:39 PM To: draft-ietf-oauth-json-web-token.all@tools.ietf.org; Gen Art Subject: Last Call Review of draft-ietf-oauth-json-web-token-25 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-oauth-json-web-token-25 Reviewer: Tom Taylor Review Date: 23/08/2014 IETF LC End Date: 3/09/2014 IESG Telechat date: TBD Summary: This draft is good to go. IDNits complains about the non-use of RF= C 4648 (normative) but this is the Base64 specification invoked by "base64u= rl". I did not re-verify the examples (done by the Document Shepherd). Major issues: Minor issues: Nits/editorial comments: From nobody Wed Sep 3 00:58:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302C41A007E for ; Wed, 3 Sep 2014 00:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Va83R3dKQVB0 for ; Wed, 3 Sep 2014 00:58:00 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A791A0073 for ; Wed, 3 Sep 2014 00:57:39 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id et14so16914734pad.2 for ; Wed, 03 Sep 2014 00:57:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=QBVG8hrb9lOs6EAH7iCQ7cRZKerbrx6GDBYR12RuvIo=; b=QcnCBBOljawb29RrxZpCPYFIbKPgm4Lb6QejW2K75bungXNHZ97RVhA32iSrMj/Y5Q WvfjCLteCPrVFK5+TL+Q8zfeHpZ2T09QKU2TV4U/8AoJwyiHr+Is3odd9HkeJWsLVdg0 hyHne3joo2dlkmugU+kh1tW6SkqmvM7cPjV5v/SM2zIJwYAw47Y8RiFoLO+HGibJ3ffy aqP/IBAlpePkkw/rYlmhYQ3vCIoTJKNDJyDryX0Zamn3wHsJVYdzjGMZ+S39rR7sLjRo VFOMy5cDI3rf0uj9tgk4aGlZrghl0slDbM8gSm+XwrNlOTrBo9tZyXQptcCaFChru3Zj zSVQ== X-Gm-Message-State: ALoCoQlaYT+8m84f4RCnm/AN5Im5lG5ofSoXAvmyXEVhivDp+/9oNljYGKnCwVp809bzSs3/o+3G X-Received: by 10.66.196.65 with SMTP id ik1mr3148236pac.154.1409731055974; Wed, 03 Sep 2014 00:57:35 -0700 (PDT) Received: from [10.0.1.23] (c-71-195-233-26.hsd1.ut.comcast.net. [71.195.233.26]) by mx.google.com with ESMTPSA id pm1sm8310382pdb.58.2014.09.03.00.57.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 00:57:34 -0700 (PDT) Message-ID: <5406C9EB.1020701@jive.com> Date: Wed, 03 Sep 2014 01:57:31 -0600 From: Eduardo Gueiros User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: oauth@ietf.org, draft-ietf-oauth-spop@tools.ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gSS3WJGWp3BwrUO-MkwWiHUBOCw Subject: [OAUTH-WG] Review draft-ietf-oauth-spop-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 07:58:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Review of draft-ietf-oauth-spop-00 Gentleman, here are some notes on the OAuth SPOP Draft. Review Summary A few grammar errors, no major flaws, some suggestions that could possibly make some passages clearer. Some questions as well. Also, providing a flow diagram would help clarify some of the interactions. Abstract > The OAuth 2.0 public client utilizing authorization code grant is > susceptible to the code interception attack. Suggestion for clearer reading: OAuth 2.0 public clients utilizing Authorization Code Grant (RFC 6749 - - 4.1) are susceptible to an interception attack. Introduction Suggestion for clearer reading: > Public clients in OAuth 2.0 [RFC6749] is susceptible to the "code" > interception attack. The "code" interception attack is an attack > that a malicious client intercepts the "code" returned from the > authorization endpoint and uses it to obtain the access token. Public clients utilizing OAuth 2.0 are susceptible to authorization code interception attack. A malicious client intercepts the authorization code returned from the authorization endpoint and uses it to obtain the access token. Suggestion for clearer reading: > This is especially true on some smartphone platform in which the "code" is > returned to a redirect URI with a custom scheme as there can be > multiple apps that can register the same scheme. This is especially true on smartphones applications where the authorization code can be returned through custom URL Schemes where the same scheme can be registered by multiple applications. Insert article before ‘dynamic’ > To mitigate this attack, this extension utilizes dynamically > created cryptographically random key called 'code verifier'. To mitigate this attack, this extension utilizes a dynamically created cryptographically random key called 'code verifier'. Missing commas for context > The code verifier is created for every authorization request and > its transformed value called code challenge is sent to the > authorization server to obtain the authorization code. The code verifier is created for every authorization request and its transformed value, called code challenge, is sent to the authorization server to obtain the authorization code. 2 Terminology 2.1 Question Random String: What constitutes ‘big enough entropy’? Shouldn’t minimum length be specified (e.g. 32 characters)? 3 Protocol 3.1 Question This paragraph states that the client must, through some mechanism, verify if the server supports this specification. Shouldn’t this mechanism be part of OAuth and therefore have an specification document on how to implement and perform the aforementioned verification? Suggestion: Change MUST to SHOULD > The client that wishes to use this specification MUST stop > proceeding if the server does not support this extension. I think a client can use this mechanism to implement a more secure transaction, but by verifying it, the client can be configured to continue performing the regular authorization grant if it chooses so. Hence, SHOULD instead of MUST. 3.3 Question Goes with question on 2.1, why less than 128 bytes? Suggestion > string of length less than 128 bytes string of length no less than 128 bytes Eduardo Gueiros Software Developer | Jive.com Jive Communications, Inc | egueiros at jive.com -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJUBsnrAAoJEInLDRowktwYn6sH+wUGGCimGSRaSfy4LeN9ug9e VN5R/N4eWhEKl5iydMZskeMovYsH4PhEP19m56mWGhRn53CxMB5dlHkTw56JX4mS qnPu96Ot6HoCzzCVj8PtGyAZUwWFyd57Ff7uUuSQaVghhIfLXzggFfciiErJpV5H wwQo+eFp98fx6uGEeCr4Olr6PsJ8Ajn5SnaCA/dPr7YWAUrnpSb55NCB4twtp4y6 36EqjcuvafudTEuYJOoGqYJppfpcZ+Da6uKZNRTahkN1ivv1C+PdNRWkfHbB47mu IF4u3b6tDhiymPNFjCABZ6gB5ZbXmUbVrkhVKwJpf/87/fiaScGmZG+6rRZLP5s= =XQSw -----END PGP SIGNATURE----- From nobody Wed Sep 3 08:44:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2811A0ACE for ; Wed, 3 Sep 2014 08:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 xpznUz5t2458 for ; Wed, 3 Sep 2014 08:44:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05C41A0B01 for ; Wed, 3 Sep 2014 08:43:20 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 15:43:18 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 15:43:18 +0000 From: Antonio Sanso To: "oauth@ietf.org" Thread-Topic: open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5A== Date: Wed, 3 Sep 2014 15:43:17 +0000 Message-ID: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(199003)(189002)(19617315012)(90102001)(16601075003)(85306004)(74662001)(77982001)(92566001)(95666004)(79102001)(83322001)(83072002)(85852003)(46102001)(99396002)(15202345003)(64706001)(110136001)(92726001)(15395725005)(33656002)(66066001)(21056001)(107886001)(105586002)(54356999)(36756003)(86362001)(74502001)(2351001)(31966008)(15975445006)(82746002)(16236675004)(106356001)(2656002)(229853001)(83716003)(4396001)(50986999)(76482001)(106116001)(81542001)(101416001)(19580395003)(80022001)(20776003)(77096002)(87936001)(107046002)(2501002)(99286002)(81342001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB206; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_756EEB2589E844459DA05522787D51ABadobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gIuIrxeXudRBg8L6RYGDElxrc4s Subject: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 15:44:08 -0000 --_000_756EEB2589E844459DA05522787D51ABadobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable hi *, IMHO providers that strictly follow rfc6749 are vulnerable to open redirect= . Let me explain, reading [0] If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, per Appendix B: Now let=92s assume this. I am registering a new client to the victim.com provider= . I register redirect uri attacker.com. According to [0] if I pass e.g. the wrong scope I am redirected back to att= acker.com. Namely I prepare a url that is in this form: http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com and this is works as an open redirector. Of course in the positive case if all the parameters are fine this doesn=92= t apply since the resource owner MUST approve the app via the consent scree= n (at least once). A solution would be to return error 400 rather than redirect to the redirec= t URI (as some provider e.g. Google do) WDYT? regards antonio [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 --_000_756EEB2589E844459DA05522787D51ABadobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2B37062EAB7DEB44BD5E2492D8F5E283@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open red= irect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or m=
ismatching
   redirection URI, or if the client identifier is missing or invalid,
   the authorization server SHOULD inform the resource owner of the
   error and MUST NOT automatically redirect the user-agent to the
   invalid redirection URI.

   If the resource owner denies the access request or if the request
   fails for reasons other than a missing or invalid redirection URI,
   the authorization server informs the client by adding the following
   parameters to the query component of the redirection URI using the
   "application/x-www-form-urlencoded" format, per Appendix B:
Now let=92s assume this.
I am registering a new client to the vic= tim.com provider. 
I register redirect uri attacker.com.
Namely I prepare a url that is in this form:


and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this doe= sn=92t apply since the resource owner MUST approve the app via the consent = screen (at least once).

A solution would be to return error 400 rather than redirect to the re= direct URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] ht= tps://tools.ietf.org/html/rfc6749#section-4.1.2.1 --_000_756EEB2589E844459DA05522787D51ABadobecom_-- From nobody Wed Sep 3 09:10:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2341A0AE0 for ; Wed, 3 Sep 2014 09:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 633ZTvqo1VrW for ; Wed, 3 Sep 2014 09:10:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 9FFD01A0691 for ; Wed, 3 Sep 2014 09:10:26 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s83GAORt029460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 3 Sep 2014 12:10:25 -0400 Received: from [10.10.63.182] (vpn-63-182.rdu2.redhat.com [10.10.63.182]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s83GAOIq011217 for ; Wed, 3 Sep 2014 12:10:24 -0400 Message-ID: <54073D6F.6070203@redhat.com> Date: Wed, 03 Sep 2014 12:10:23 -0400 From: Bill Burke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> In-Reply-To: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9TsflOES3dgs4lMkmpZBIjp7_jE Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:10:29 -0000 I don't understand. The redirect uri has to be valid in order for a redirect to happen. The spec explicitly states this. On 9/3/2014 11:43 AM, Antonio Sanso wrote: > hi *, > > IMHO providers that strictly follow rfc6749 are vulnerable to open redirect. > Let me explain, reading [0] > > If the request fails due to a missing, invalid, or mismatching > redirection URI, or if the client identifier is missing or invalid, > the authorization server SHOULD inform the resource owner of the > error and MUST NOT automatically redirect the user-agent to the > invalid redirection URI. > > If the resource owner denies the access request or if the request > fails for reasons other than a missing or invalid redirection URI, > the authorization server informs the client by adding the following > parameters to the query component of the redirection URI using the > "application/x-www-form-urlencoded" format, perAppendix B : > > Now let’s assume this. > I am registering a new client to the victim.com > provider. > I register redirect uri attacker.com . > > According to [0] if I pass e.g. the wrong scope I am redirected back to > attacker.com . > Namely I prepare a url that is in this form: > > http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com > > and this is works as an open redirector. > Of course in the positive case if all the parameters are fine this > doesn’t apply since the resource owner MUST approve the app via the > consent screen (at least once). > > A solution would be to return error 400 rather than redirect to the > redirect URI (as some provider e.g. Google do) > > WDYT? > > regards > > antonio > > [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From nobody Wed Sep 3 09:15:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638C81A0691 for ; Wed, 3 Sep 2014 09:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Qu-gshIpDyZG for ; Wed, 3 Sep 2014 09:15:00 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC291A035D for ; Wed, 3 Sep 2014 09:14:47 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z11so9939845lbi.36 for ; Wed, 03 Sep 2014 09:14:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=lzdkii9xkglVp70+/WKBU9uCjxYzS14HJomEkJ3oOTs=; b=huwRqgBS6TTiQKw7/4G+mUXnY+sRy9i7CTijFVjWLneLvtggUvTDNsUTcXgzfpUqK/ UQfO7U2z9F6UHO+IIdVdk1ZQ2kMpNaCNFyBlrbSsIWTeGYvWl9qbG5gaJARSU9zSuVZx sSHkrhXLGk+7ZK0a9PuFjAISAwWabsEk5nOoMsr2lF9bKGqjjjKsk6JcB5S+99IDR7qu +u/5M7OO0pdX5Q+tu9J7kIOn4Bq47CJZTM2/6HY7zhiEB3OFchyI90qcbmR8XaiwmHVp 8LYq8xScKFgZGX6xknHrZuKc4gUHP5AyG3cbFFVk2Cl99vwTG2Lzldg86sWEjbg7bOUL 2wTw== X-Gm-Message-State: ALoCoQkYHYHKa14u/J4tSf9eb4AspZ6RKxWDLAG8qtqoleYq0fdaX5vIdUv06eRjn/T+IGY/twOa X-Received: by 10.152.23.6 with SMTP id i6mr42540885laf.39.1409760885595; Wed, 03 Sep 2014 09:14:45 -0700 (PDT) Received: from [192.168.49.148] (seabed-1-2-ci.cust.versatel.net. [87.213.30.114]) by mx.google.com with ESMTPSA id js10sm1319158lab.23.2014.09.03.09.14.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 09:14:44 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5C192E00-5CEB-4032-AA7D-FAA6CA654F84"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <54073D6F.6070203@redhat.com> Date: Wed, 3 Sep 2014 12:14:37 -0400 Message-Id: <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> To: Bill Burke X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zzMA7GV7h0lEEli4OMBta4j3LLI Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:15:04 -0000 --Apple-Mail=_5C192E00-5CEB-4032-AA7D-FAA6CA654F84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In the example the redirect_uri is vlid for the attacker. The issue is that the AS may be allowing client registrations with = arbitrary redirect_uri. In the spec it is unspecified how a AS validates that a client controls = the redirect_uri it is registering. I think that if anything it may be the registration step that needs the = security consideration. John B. On Sep 3, 2014, at 12:10 PM, Bill Burke wrote: > I don't understand. The redirect uri has to be valid in order for a = redirect to happen. The spec explicitly states this. >=20 > On 9/3/2014 11:43 AM, Antonio Sanso wrote: >> hi *, >>=20 >> IMHO providers that strictly follow rfc6749 are vulnerable to open = redirect. >> Let me explain, reading [0] >>=20 >> If the request fails due to a missing, invalid, or mismatching >> redirection URI, or if the client identifier is missing or = invalid, >> the authorization server SHOULD inform the resource owner of the >> error and MUST NOT automatically redirect the user-agent to the >> invalid redirection URI. >>=20 >> If the resource owner denies the access request or if the request >> fails for reasons other than a missing or invalid redirection URI, >> the authorization server informs the client by adding the = following >> parameters to the query component of the redirection URI using the >> "application/x-www-form-urlencoded" format, perAppendix B = : >>=20 >> Now let=92s assume this. >> I am registering a new client to the victim.com >> provider. >> I register redirect uri attacker.com . >>=20 >> According to [0] if I pass e.g. the wrong scope I am redirected back = to >> attacker.com . >> Namely I prepare a url that is in this form: >>=20 >> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>=20 >> and this is works as an open redirector. >> Of course in the positive case if all the parameters are fine this >> doesn=92t apply since the resource owner MUST approve the app via the >> consent screen (at least once). >>=20 >> A solution would be to return error 400 rather than redirect to the >> redirect URI (as some provider e.g. Google do) >>=20 >> WDYT? >>=20 >> regards >>=20 >> antonio >>=20 >> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > --=20 > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5C192E00-5CEB-4032-AA7D-FAA6CA654F84 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MDMxNjE0MzdaMCMGCSqGSIb3DQEJBDEWBBQmX93SqUPHC7vzWPHtLCN9 /o+c1jCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCl/MfkSSanFLFALqW4b93asq1Koug639bL+y9ZFsdeBcEBzk53+lbp nd3YylEDrNwEqfPyi0T1JAEjdYMSFJ4tzixQpg1x6fG9dZJMLGtxrXW6MVAgAUC5GILKdfiaI1Tc sbuwjIRVRfJhg9cZkZpVpVh4LOemzV4MSARlvuGqi3X9ufT5hfRDmAUXIrAy+dtNDCLnIC/20Ain +OemRiZl6Sde61jhFCuIm3YPoy3HGz6psUP9/QP3xxT0u14ynChae2+gRz6T40hqJ6O/DpoKz3Zt D7QEN8xzJdKTSuu/s49infu/AiVOkczO6BH8h7mZeHYmlckfzH83v94xaHTjAAAAAAAA --Apple-Mail=_5C192E00-5CEB-4032-AA7D-FAA6CA654F84-- From nobody Wed Sep 3 09:19:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96AA1A0013 for ; Wed, 3 Sep 2014 09:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 COB4WY_dH6Np for ; Wed, 3 Sep 2014 09:19:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4B01A000E for ; Wed, 3 Sep 2014 09:19:12 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Wed, 3 Sep 2014 16:19:03 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 16:19:03 +0000 From: Antonio Sanso To: Bill Burke Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAACaIA= Date: Wed, 3 Sep 2014 16:19:03 +0000 Message-ID: <62B0432E-9DAB-4F08-B615-405E5F5D1839@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> In-Reply-To: <54073D6F.6070203@redhat.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(199003)(24454002)(189002)(479174003)(377454003)(46102001)(107046002)(105586002)(15202345003)(106116001)(19580395003)(83716003)(90102001)(74502001)(77982001)(36756003)(79102001)(2656002)(21056001)(4396001)(83322001)(587094003)(16601075003)(85852003)(15395725005)(19580405001)(87936001)(76482001)(101416001)(64706001)(16236675004)(80022001)(50986999)(82746002)(99286002)(76176999)(20776003)(81342001)(19617315012)(92566001)(92726001)(86362001)(81542001)(33656002)(31966008)(83072002)(106356001)(77096002)(15975445006)(74662001)(85306004)(54356999)(99396002)(95666004)(110136001)(66066001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_62B0432E9DAB4F08B615405E5F5D1839adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uWWA7nKq8JD5j-ZbSYJT_h8PKHM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:19:15 -0000 --_000_62B0432E9DAB4F08B615405E5F5D1839adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Sep 3, 2014, at 6:10 PM, Bill Burke > wrote: I don't understand. The redirect uri has to be valid in order for a redire= ct to happen. The spec explicitly states this. the redirect uri is indeed valid. The wrong parameter is the scope. So if the attacker is the person that registers the app and register as red= irect uri attacker.com he can redirect anybody to atta= cker.com levering the provider website uri=85 On 9/3/2014 11:43 AM, Antonio Sanso wrote: hi *, IMHO providers that strictly follow rfc6749 are vulnerable to open redirect= . Let me explain, reading [0] If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, perAppendix B : Now let=92s assume this. I am registering a new client to the victim.com > provider. I register redirect uri attacker.com >. According to [0] if I pass e.g. the wrong scope I am redirected back to attacker.com >. Namely I prepare a url that is in this form: http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com and this is works as an open redirector. Of course in the positive case if all the parameters are fine this doesn=92t apply since the resource owner MUST approve the app via the consent screen (at least once). A solution would be to return error 400 rather than redirect to the redirect URI (as some provider e.g. Google do) WDYT? regards antonio [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_62B0432E9DAB4F08B615405E5F5D1839adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <523F0C2C6713844C92B75D3C5AD52BB6@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On Sep 3, 2014, at 6:10 PM, Bill Burke <bburke@redhat.com> wrote:

I don't understand.  The redirect uri has to be valid in order for a r= edirect to happen.  The spec explicitly states this.

the redirect uri is indeed valid. The wrong parameter is the scope.

So if the attacker is the person that registers the app and register a= s redirect uri attacker.com he can redirect anybody to= attacker.com levering the provider website uri=85



On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open redirect= .
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
   redirection URI, or if the client identifier is missing o= r invalid,
   the authorization server SHOULD inform the resource owner= of the
   error and MUST NOT automatically redirect the user-agent = to the
   invalid redirection URI.

   If the resource owner denies the access request or if the= request
   fails for reasons other than a missing or invalid redirec= tion URI,
   the authorization server informs the client by adding the= following
   parameters to the query component of the redirection URI = using the
   "application/x-www-form-urlencoded" format, per= Appendix B  <https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let=92s assume this.
I am registering a new client to the&= nbsp;victim.com <http://= victim.com>
provider.
I register redirect uri <= a href=3D"http://attacker.com/">attacker.com <http://attacke= r.com>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com <http://attack= er.com>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=3Dcode&a= mp;client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&= ;redirect_uri=3Dhttp://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn=92t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6= 749#section-4.1.2.1


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


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com<= br>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_62B0432E9DAB4F08B615405E5F5D1839adobecom_-- From nobody Wed Sep 3 09:46:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133651A0004 for ; Wed, 3 Sep 2014 09:46: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 pN0AWJT9dOoT for ; Wed, 3 Sep 2014 09:46:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF421A01A9 for ; Wed, 3 Sep 2014 09:46:38 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 16:46:35 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 16:46:35 +0000 From: Antonio Sanso To: John Bradley Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogA== Date: Wed, 3 Sep 2014 16:46:35 +0000 Message-ID: <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> In-Reply-To: <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(51444003)(189002)(479174003)(377454003)(199003)(46102001)(101416001)(81342001)(74662001)(87936001)(19617315012)(99286002)(90102001)(110136001)(76482001)(19580405001)(74502001)(105586002)(106356001)(92566001)(106116001)(54356999)(86362001)(64706001)(95666004)(107046002)(20776003)(81542001)(16601075003)(85306004)(16236675004)(50986999)(2656002)(83716003)(99396002)(82746002)(4396001)(15202345003)(92726001)(19580395003)(15975445006)(77096002)(76176999)(85852003)(15395725005)(21056001)(80022001)(83072002)(83322001)(31966008)(33656002)(79102001)(77982001)(66066001)(587094003)(36756003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_58148F80C2DD45C58D6FCED74A90AA75adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QpL3Y3sVQqzNSwzT39d7__hniMY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:46:45 -0000 --_000_58148F80C2DD45C58D6FCED74A90AA75adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable hi John, On Sep 3, 2014, at 6:14 PM, John Bradley > wrote: In the example the redirect_uri is vlid for the attacker. The issue is that the AS may be allowing client registrations with arbitrar= y redirect_uri. In the spec it is unspecified how a AS validates that a client controls the= redirect_uri it is registering. I think that if anything it may be the registration step that needs the sec= urity consideration. (this is the first time :p) but I do disagree with you. It would be pretty = unpractical to block this at registration time=85. IMHO the best approach is the one taken from Google, namely returning 400 w= ith the cause of the error.. 400. That=92s an error. Error: invalid_scope Some requested scopes were invalid. {invalid=3D[l]} said that I hope you all agree this is an issue in the spec so far=85. regards antonio John B. On Sep 3, 2014, at 12:10 PM, Bill Burke > wrote: I don't understand. The redirect uri has to be valid in order for a redire= ct to happen. The spec explicitly states this. On 9/3/2014 11:43 AM, Antonio Sanso wrote: hi *, IMHO providers that strictly follow rfc6749 are vulnerable to open redirect= . Let me explain, reading [0] If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, perAppendix B : Now let=92s assume this. I am registering a new client to the victim.com provider. I register redirect uri attacker.com . According to [0] if I pass e.g. the wrong scope I am redirected back to attacker.com . Namely I prepare a url that is in this form: http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com and this is works as an open redirector. Of course in the positive case if all the parameters are fine this doesn=92t apply since the resource owner MUST approve the app via the consent screen (at least once). A solution would be to return error 400 rather than redirect to the redirect URI (as some provider e.g. Google do) WDYT? regards antonio [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ 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 --_000_58148F80C2DD45C58D6FCED74A90AA75adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5F184136BA2E174E84B65A64C798F90F@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

In the example the redirect_uri is vlid for the a= ttacker.

The issue is that the AS may be allowing client registrations with arbitrar= y redirect_uri.

In the spec it is unspecified how a AS validates that a client controls the= redirect_uri it is registering.

I think that if anything it may be the registration step that needs the sec= urity consideration.

(this is the first time :p) but I do disagree with you. It would be pr= etty unpractical to block this at registration time=85.
IMHO the best approach is the one taken from Google, namely returning = 400 with the cause of the error..

400. That= =92s an error.

Error: invalid_scope

Some requested scopes were invalid. {invalid=3D[l]}

said that I hope you all agree this is an issue in the spec so far=85.=

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <bburke@redhat.com> wrote:

I don't understand.  The redirect uri has to= be valid in order for a redirect to happen.  The spec explicitly stat= es this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open redirect= .
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
  redirection URI, or if the client identifier is missing or inva= lid,
  the authorization server SHOULD inform the resource owner of th= e
  error and MUST NOT automatically redirect the user-agent to the=
  invalid redirection URI.

  If the resource owner denies the access request or if the reque= st
  fails for reasons other than a missing or invalid redirection U= RI,
  the authorization server informs the client by adding the follo= wing
  parameters to the query component of the redirection URI using = the
  "application/x-www-form-urlencoded" format, perAppend= ix B  <h= ttps://tools.ietf.org/html/rfc6749#appendix-B>:

Now let=92s assume this.
I am registering a new client to the victim.c= om <http://victim.com>
provider.
I register redirect uri attacker.com &l= t;http://attacker.com>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com <http://attacker.com>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=3Dcode&a= mp;client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&= ;redirect_uri=3Dhttp://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn=92t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
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

--_000_58148F80C2DD45C58D6FCED74A90AA75adobecom_-- From nobody Wed Sep 3 09:51:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1661A00AB for ; Wed, 3 Sep 2014 09:51:40 -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 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 Bu9rFHNrJ-Ys for ; Wed, 3 Sep 2014 09:51:38 -0700 (PDT) Received: from na3sys009aog137.obsmtp.com (na3sys009aog137.obsmtp.com [74.125.149.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84CD1A02E1 for ; Wed, 3 Sep 2014 09:51:30 -0700 (PDT) Received: from mail-wi0-f170.google.com ([209.85.212.170]) (using TLSv1) by na3sys009aob137.postini.com ([74.125.148.12]) with SMTP ID DSNKVAdHEgGk6UG9HDSCWkqOaKHOaulm97Fd@postini.com; Wed, 03 Sep 2014 09:51:30 PDT Received: by mail-wi0-f170.google.com with SMTP id cc10so6195139wib.1 for ; Wed, 03 Sep 2014 09:51:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Eqv4exsBtRPOgDwNmKhmujegPERKVYJGMqzwsHb2nXo=; b=ktfKixEHtr4A1qpq/0Xc0imjhvj3oWvDpuW3bbjs9LCWcUrhknExbd+QvwBXUt6mZk +ny9yfyLEWzncGRowi6p9cVe0TcAL5QzVtFOaYr5u7vnnQK9GRY0DxpAwtQSbmsPtY7f hDnsvoYczkSUrf97iyhUDT11C1GSXgT8k+mujgWvPeR4G/DKGZMmVTWZ/tdaz3zOIWe+ z1elLdcFZdQPQggGEmW9ORd0ahtsAqQ9vnHh243X5MnR+wumkms0AQWz5ZGE6ZRVO7Yo FM7/1jjNju/nwRzfx0xCmCv8uJTkmGW46+0SsmEXxeMQyibzzQeJY6X6l9yvwQjc1jTt xTMA== X-Gm-Message-State: ALoCoQma5j+yobJBYdTBJR9CiC4vnklu9DcIosELRkiuzF+tdg1QDsaHCD7mr+F+h2RVu+NXTDpfH7F3nolljvOWR+WgSpkjd4wl/Qpt/7ZAKSDQnfNEr8aytIo3k5aR1Nzq4b+CEzYp X-Received: by 10.194.184.101 with SMTP id et5mr49398119wjc.14.1409763089257; Wed, 03 Sep 2014 09:51:29 -0700 (PDT) X-Received: by 10.194.184.101 with SMTP id et5mr49397963wjc.14.1409763088169; Wed, 03 Sep 2014 09:51:28 -0700 (PDT) Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id ju1sm16654052wjc.1.2014.09.03.09.51.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 09:51:27 -0700 (PDT) Message-ID: <5407470B.2010904@pingidentity.com> Date: Wed, 03 Sep 2014 18:51:23 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Antonio Sanso , John Bradley References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> In-Reply-To: <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kUVL5XKqbK2m-CHDq-MicOUlqv0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:51:41 -0000 Let me try and approach this from a different angle: why would you call it an open redirect when an invalid scope is provided and call it correct protocol behavior (hopefully) when a valid scope is provided? Hans. On 9/3/14, 6:46 PM, Antonio Sanso wrote: > hi John, > On Sep 3, 2014, at 6:14 PM, John Bradley > wrote: > >> In the example the redirect_uri is vlid for the attacker. >> >> The issue is that the AS may be allowing client registrations with >> arbitrary redirect_uri. >> >> In the spec it is unspecified how a AS validates that a client >> controls the redirect_uri it is registering. >> >> I think that if anything it may be the registration step that needs >> the security consideration. > > (this is the first time :p) but I do disagree with you. It would be > pretty unpractical to block this at registration time…. > IMHO the best approach is the one taken from Google, namely returning > 400 with the cause of the error.. > > *400.* That’s an error. > > *Error: invalid_scope* > > Some requested scopes were invalid. {invalid=[l]} > > said that I hope you all agree this is an issue in the spec so far…. > > regards > > antonio > >> >> John B. >> >> On Sep 3, 2014, at 12:10 PM, Bill Burke > > wrote: >> >>> I don't understand. The redirect uri has to be valid in order for a >>> redirect to happen. The spec explicitly states this. >>> >>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>> hi *, >>>> >>>> IMHO providers that strictly follow rfc6749 are vulnerable to open >>>> redirect. >>>> Let me explain, reading [0] >>>> >>>> If the request fails due to a missing, invalid, or mismatching >>>> redirection URI, or if the client identifier is missing or invalid, >>>> the authorization server SHOULD inform the resource owner of the >>>> error and MUST NOT automatically redirect the user-agent to the >>>> invalid redirection URI. >>>> >>>> If the resource owner denies the access request or if the request >>>> fails for reasons other than a missing or invalid redirection URI, >>>> the authorization server informs the client by adding the following >>>> parameters to the query component of the redirection URI using the >>>> "application/x-www-form-urlencoded" format, perAppendix B >>>> : >>>> >>>> Now let’s assume this. >>>> I am registering a new client to the victim.com >>>> >>>> provider. >>>> I register redirect uri attacker.com >>>> . >>>> >>>> According to [0] if I pass e.g. the wrong scope I am redirected back to >>>> attacker.com . >>>> Namely I prepare a url that is in this form: >>>> >>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>> >>>> and this is works as an open redirector. >>>> Of course in the positive case if all the parameters are fine this >>>> doesn’t apply since the resource owner MUST approve the app via the >>>> consent screen (at least once). >>>> >>>> A solution would be to return error 400 rather than redirect to the >>>> redirect URI (as some provider e.g. Google do) >>>> >>>> WDYT? >>>> >>>> regards >>>> >>>> antonio >>>> >>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Wed Sep 3 09:56:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804011A0362 for ; Wed, 3 Sep 2014 09:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 fNZqQyKuojRC for ; Wed, 3 Sep 2014 09:56:16 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EFB1A0368 for ; Wed, 3 Sep 2014 09:56:15 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 16:56:13 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 16:56:13 +0000 From: Antonio Sanso To: Hans Zandbelt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQA= Date: Wed, 3 Sep 2014 16:56:12 +0000 Message-ID: <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> In-Reply-To: <5407470B.2010904@pingidentity.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199003)(479174003)(24454002)(51444003)(189002)(66066001)(33656002)(50986999)(79102001)(19580395003)(81542001)(99396002)(83322001)(76482001)(16236675004)(31966008)(19580405001)(19617315012)(46102001)(4396001)(82746002)(20776003)(83072002)(99286002)(15202345003)(110136001)(107046002)(106116001)(2656002)(106356001)(83716003)(74662001)(15975445006)(105586002)(90102001)(587094003)(92566001)(16601075003)(77096002)(85306004)(92726001)(21056001)(77982001)(36756003)(87936001)(85852003)(76176999)(101416001)(64706001)(15395725005)(93886004)(74502001)(86362001)(54356999)(95666004)(80022001)(81342001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2505562926A9478DAE7A3C295E3166EEadobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LB_ueVXqmia04tz0T7gH1wl7KFM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:56:23 -0000 --_000_2505562926A9478DAE7A3C295E3166EEadobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > wrote: Let me try and approach this from a different angle: why would you call it = an open redirect when an invalid scope is provided and call it correct prot= ocol behavior (hopefully) when a valid scope is provided? as specified below in the positive case (namely when the correct scope is p= rovided) the resource owner MUST approve the app via the consent screen (at= least once). Hans. On 9/3/14, 6:46 PM, Antonio Sanso wrote: hi John, On Sep 3, 2014, at 6:14 PM, John Bradley > wrote: In the example the redirect_uri is vlid for the attacker. The issue is that the AS may be allowing client registrations with arbitrary redirect_uri. In the spec it is unspecified how a AS validates that a client controls the redirect_uri it is registering. I think that if anything it may be the registration step that needs the security consideration. (this is the first time :p) but I do disagree with you. It would be pretty unpractical to block this at registration time=85. IMHO the best approach is the one taken from Google, namely returning 400 with the cause of the error.. *400.* That=92s an error. *Error: invalid_scope* Some requested scopes were invalid. {invalid=3D[l]} said that I hope you all agree this is an issue in the spec so far=85. regards antonio John B. On Sep 3, 2014, at 12:10 PM, Bill Burke > wrote: I don't understand. The redirect uri has to be valid in order for a redirect to happen. The spec explicitly states this. On 9/3/2014 11:43 AM, Antonio Sanso wrote: hi *, IMHO providers that strictly follow rfc6749 are vulnerable to open redirect. Let me explain, reading [0] If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, perAppendix B : Now let=92s assume this. I am registering a new client to the victim.com > > provider. I register redirect uri attacker.com > >. According to [0] if I pass e.g. the wrong scope I am redirected back to attacker.com > >. Namely I prepare a url that is in this form: http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com and this is works as an open redirector. Of course in the positive case if all the parameters are fine this doesn=92t apply since the resource owner MUST approve the app via the consent screen (at least once). A solution would be to return error 400 rather than redirect to the redirect URI (as some provider e.g. Google do) WDYT? regards antonio [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identi= ty --_000_2505562926A9478DAE7A3C295E3166EEadobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

Let me try and approach this from a different angle: why would you call it = an open redirect when an invalid scope is provided and call it correct prot= ocol behavior (hopefully) when a valid scope is provided?

as specified below in the positive case (namely when the correct scope= is provided) the resource owner MUST approve the app via the consent scree= n (at least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com
<mailto:ve7jtb@ve7jtb.com>&g= t; wrote:

In the example the redirect_uri is vlid for the a= ttacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time=85.
IMHO the best approach is the one taken from Google, namely returning
400 with the cause of the error..

*400.* That=92s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=3D[l]}

said that I hope you all agree this is an issue in the spec so far=85.

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com>&g= t; wrote:

I don't understand.  The redirect uri has to= be valid in order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
 redirection URI, or if the client identifier is missing or invalid,  the authorization server SHOULD inform the resource owner of the
 error and MUST NOT automatically redirect the user-agent to the
 invalid redirection URI.

 If the resource owner denies the access request or if the request
 fails for reasons other than a missing or invalid redirection URI,  the authorization server informs the client by adding the following  parameters to the query component of the redirection URI using the  "application/x-www-form-urlencoded" format, perAppendix B <https://tool= s.ietf.org/html/rfc6749#appendix-B>:

Now let=92s assume this.
I am registering a new client to the&= nbsp;victim.com <http://= victim.com>
<http://victim.com>
provider.
I register redirect uri <= a href=3D"http://attacker.com/">attacker.com <http://attacke= r.com>
<http://attacker.com>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com <http://attack= er.com> <http://attacker.com= >.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=3Dcode&a= mp;client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&= ;redirect_uri=3Dhttp://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn=92t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OA= uth@ietf.org>
https://www.ietf.or= g/mailman/listinfo/oauth



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


-- 
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity

--_000_2505562926A9478DAE7A3C295E3166EEadobecom_-- From nobody Wed Sep 3 10:11:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4530F1A0359 for ; Wed, 3 Sep 2014 10:11:03 -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 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 bT9NUfVZOpy4 for ; Wed, 3 Sep 2014 10:10:56 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA17A1A0391 for ; Wed, 3 Sep 2014 10:10:22 -0700 (PDT) Received: from mail-wg0-f41.google.com ([74.125.82.41]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKVAdLfmeBBHkpev+Pzsp7NBMJDmKw7Bih@postini.com; Wed, 03 Sep 2014 10:10:23 PDT Received: by mail-wg0-f41.google.com with SMTP id l18so8761504wgh.0 for ; Wed, 03 Sep 2014 10:10:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3Fwm73udAtn9i/h2uZTHVpl5xX1YYdQDDGRio/UxA7Q=; b=IePIIV/qRM1pwypElpIz8lJjMMcF7v4okZ73L1VmN/0Yb31ct/Gkp9Y40YyAlyu0KS cY8bW1dSc0aR+vW1HxzdTHd9Lk0x6BlRImCooZL4cUUaQZTJaKq6DBFzqtSmsvQDvPMP Gn4/Uq3jqIewha9z8TMk02j2C0hOy7fDMquBnLU7O9SDi9Iopdv6Cp6gXvfC8y25vDIE bjpotOtxyb14wiafQNPBlnDLjwr3yGgB4C8xxgv4UuQjVDNQkDg35QNEhTAMH98oKpEG PjwMMiAvfOAAHw8jMjy2ISEJ8CXj8rG7uqcqAlzyRgWtM5d8F4T/zJS9pF7LJ3y4uHaK 3r8A== X-Gm-Message-State: ALoCoQnaapWinK6BrBXNxXlIsU5mdE3rvYPn6kui0DgQRIS51WJn7Wh+OaDp7l4ooWw6f7ll381RD4ypPzBezqhA0UyuLajWUCUNuTeTT3BcCrezK9Fjv65x947IH65IJ8lm6RCRbyXO X-Received: by 10.181.13.116 with SMTP id ex20mr37651178wid.31.1409764221172; Wed, 03 Sep 2014 10:10:21 -0700 (PDT) X-Received: by 10.181.13.116 with SMTP id ex20mr37651146wid.31.1409764220984; Wed, 03 Sep 2014 10:10:20 -0700 (PDT) Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id ew1sm16626795wjb.31.2014.09.03.10.10.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 10:10:20 -0700 (PDT) Message-ID: <54074B7A.7080907@pingidentity.com> Date: Wed, 03 Sep 2014 19:10:18 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Antonio Sanso References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> In-Reply-To: <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OD0QPc_8yVyGe7OgfsX7mcs8ROY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 17:11:06 -0000 Is your concern clients that were registered using dynamic client registration? Otherwise the positive case is returning a response to a valid URL that belongs to a client that was registered explicitly by the resource owner and the negative case is returning an error to that same URL. I fail to see the open redirect. Hans. On 9/3/14, 6:56 PM, Antonio Sanso wrote: > > On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > wrote: > >> Let me try and approach this from a different angle: why would you >> call it an open redirect when an invalid scope is provided and call it >> correct protocol behavior (hopefully) when a valid scope is provided? > > as specified below in the positive case (namely when the correct scope > is provided) the resource owner MUST approve the app via the consent > screen (at least once). > > >> >> Hans. >> >> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>> hi John, >>> On Sep 3, 2014, at 6:14 PM, John Bradley >> >>> > wrote: >>> >>>> In the example the redirect_uri is vlid for the attacker. >>>> >>>> The issue is that the AS may be allowing client registrations with >>>> arbitrary redirect_uri. >>>> >>>> In the spec it is unspecified how a AS validates that a client >>>> controls the redirect_uri it is registering. >>>> >>>> I think that if anything it may be the registration step that needs >>>> the security consideration. >>> >>> (this is the first time :p) but I do disagree with you. It would be >>> pretty unpractical to block this at registration time…. >>> IMHO the best approach is the one taken from Google, namely returning >>> 400 with the cause of the error.. >>> >>> *400.* That’s an error. >>> >>> *Error: invalid_scope* >>> >>> Some requested scopes were invalid. {invalid=[l]} >>> >>> said that I hope you all agree this is an issue in the spec so far…. >>> >>> regards >>> >>> antonio >>> >>>> >>>> John B. >>>> >>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>> >>>> > wrote: >>>> >>>>> I don't understand. The redirect uri has to be valid in order for a >>>>> redirect to happen. The spec explicitly states this. >>>>> >>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>> hi *, >>>>>> >>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to open >>>>>> redirect. >>>>>> Let me explain, reading [0] >>>>>> >>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>> redirection URI, or if the client identifier is missing or invalid, >>>>>> the authorization server SHOULD inform the resource owner of the >>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>> invalid redirection URI. >>>>>> >>>>>> If the resource owner denies the access request or if the request >>>>>> fails for reasons other than a missing or invalid redirection URI, >>>>>> the authorization server informs the client by adding the following >>>>>> parameters to the query component of the redirection URI using the >>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>> : >>>>>> >>>>>> Now let’s assume this. >>>>>> I am registering a new client to thevictim.com >>>>>> > >>>>>> > >>>>>> provider. >>>>>> I register redirect uriattacker.com >>>>>> > >>>>>> >. >>>>>> >>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>> back to >>>>>> attacker.com >>>>> > >. >>>>>> Namely I prepare a url that is in this form: >>>>>> >>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>> >>>>>> and this is works as an open redirector. >>>>>> Of course in the positive case if all the parameters are fine this >>>>>> doesn’t apply since the resource owner MUST approve the app via the >>>>>> consent screen (at least once). >>>>>> >>>>>> A solution would be to return error 400 rather than redirect to the >>>>>> redirect URI (as some provider e.g. Google do) >>>>>> >>>>>> WDYT? >>>>>> >>>>>> regards >>>>>> >>>>>> antonio >>>>>> >>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping >> Identity > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Wed Sep 3 10:16:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27AD1A0397 for ; Wed, 3 Sep 2014 10:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EIXpJrP1Qc9o for ; Wed, 3 Sep 2014 10:15:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53871A03AB for ; Wed, 3 Sep 2014 10:14:27 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 17:14:19 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 17:14:18 +0000 From: Antonio Sanso To: Hans Zandbelt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkA Date: Wed, 3 Sep 2014 17:14:18 +0000 Message-ID: <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> In-Reply-To: <54074B7A.7080907@pingidentity.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(51444003)(51704005)(189002)(479174003)(377454003)(199003)(46102001)(101416001)(74662001)(87936001)(99286002)(81342001)(90102001)(93886004)(110136001)(76482001)(19580405001)(74502001)(105586002)(106356001)(92566001)(106116001)(54356999)(86362001)(64706001)(107046002)(20776003)(95666004)(81542001)(16601075003)(85306004)(50986999)(2656002)(83716003)(99396002)(82746002)(4396001)(15202345003)(92726001)(19580395003)(15975445006)(77096002)(76176999)(85852003)(15395725005)(21056001)(80022001)(83072002)(83322001)(31966008)(33656002)(79102001)(77982001)(66066001)(587094003)(36756003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/MFdjkT8GjIy4im6OgzURqOgw2JM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 17:15:42 -0000 On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrot= e: > Is your concern clients that were registered using dynamic client registr= ation? yes >=20 > Otherwise the positive case is returning a response to a valid URL that b= elongs to a client that was registered explicitly by the resource owner well AFAIK the resource owner doesn=92t register clients=85 > and the negative case is returning an error to that same URL. the difference is the consent screen=85 in the positive case you need to ap= prove an app.. for the error case no approval is needed,,, >=20 > I fail to see the open redirect. why? >=20 > Hans. >=20 > On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>=20 >> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > > wrote: >>=20 >>> Let me try and approach this from a different angle: why would you >>> call it an open redirect when an invalid scope is provided and call it >>> correct protocol behavior (hopefully) when a valid scope is provided? >>=20 >> as specified below in the positive case (namely when the correct scope >> is provided) the resource owner MUST approve the app via the consent >> screen (at least once). >>=20 >>=20 >>>=20 >>> Hans. >>>=20 >>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>> hi John, >>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>> >>>> > wrote: >>>>=20 >>>>> In the example the redirect_uri is vlid for the attacker. >>>>>=20 >>>>> The issue is that the AS may be allowing client registrations with >>>>> arbitrary redirect_uri. >>>>>=20 >>>>> In the spec it is unspecified how a AS validates that a client >>>>> controls the redirect_uri it is registering. >>>>>=20 >>>>> I think that if anything it may be the registration step that needs >>>>> the security consideration. >>>>=20 >>>> (this is the first time :p) but I do disagree with you. It would be >>>> pretty unpractical to block this at registration time=85. >>>> IMHO the best approach is the one taken from Google, namely returning >>>> 400 with the cause of the error.. >>>>=20 >>>> *400.* That=92s an error. >>>>=20 >>>> *Error: invalid_scope* >>>>=20 >>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>=20 >>>> said that I hope you all agree this is an issue in the spec so far=85. >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>> >>>>> > wrote: >>>>>=20 >>>>>> I don't understand. The redirect uri has to be valid in order for a >>>>>> redirect to happen. The spec explicitly states this. >>>>>>=20 >>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>> hi *, >>>>>>>=20 >>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to open >>>>>>> redirect. >>>>>>> Let me explain, reading [0] >>>>>>>=20 >>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>> redirection URI, or if the client identifier is missing or invalid, >>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>> invalid redirection URI. >>>>>>>=20 >>>>>>> If the resource owner denies the access request or if the request >>>>>>> fails for reasons other than a missing or invalid redirection URI, >>>>>>> the authorization server informs the client by adding the following >>>>>>> parameters to the query component of the redirection URI using the >>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>> : >>>>>>>=20 >>>>>>> Now let=92s assume this. >>>>>>> I am registering a new client to thevictim.com >>>>>>> > >>>>>>> > >>>>>>> provider. >>>>>>> I register redirect uriattacker.com >>>>>>> > >>>>>>> >. >>>>>>>=20 >>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>> back to >>>>>>> attacker.com >>>>>> > = >. >>>>>>> Namely I prepare a url that is in this form: >>>>>>>=20 >>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88Fi= tX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attack= er.com >>>>>>>=20 >>>>>>> and this is works as an open redirector. >>>>>>> Of course in the positive case if all the parameters are fine this >>>>>>> doesn=92t apply since the resource owner MUST approve the app via t= he >>>>>>> consent screen (at least once). >>>>>>>=20 >>>>>>> A solution would be to return error 400 rather than redirect to the >>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>=20 >>>>>>> WDYT? >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Bill Burke >>>>>> JBoss, a division of Red Hat >>>>>> http://bill.burkecentral.com >>>>>>=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 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> -- >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping >>> Identity >>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity From nobody Wed Sep 3 10:40:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96BB1A03BF for ; Wed, 3 Sep 2014 10:40:50 -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 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 fUyemKkV_nz9 for ; Wed, 3 Sep 2014 10:40:43 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370DB1A03AD for ; Wed, 3 Sep 2014 10:40:43 -0700 (PDT) Received: from mail-we0-f175.google.com ([74.125.82.175]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKVAdSmo5OpnI2ZOL7bgSuydOqA0eCCCDY@postini.com; Wed, 03 Sep 2014 10:40:43 PDT Received: by mail-we0-f175.google.com with SMTP id k48so8958133wev.20 for ; Wed, 03 Sep 2014 10:40:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LfCP6f/aBHOYpuf+ILAo7jbRyKjd1ib/nz3sGrUReqg=; b=f8TY4ZaQnTGHgEcBkbsq24UaskQ9DXXX2lGpGWHuSXh6EdTZHdr6UO8W4s/N7IleUN /BcuKdazFg7hHMjyZw/96TRf5ApNaejo4UaJJvGiWcFLeJdmnxMHPkqMnPVRP8HtNtyf W9wO1+w9dqDx3igmvOUCBUwu7888oBVgFgDenHvtfN16ppzFSygpbK+j6WHjBmyjrW7E aGHfeX/j85f1AFqvRr0B7/RhO/OdqrA8UZwig8RPAGfhellUxugMft8VL6hC1sgqG4Ai mkOshYh8+20GKuw5y6esZPYMKOQk2SowXwMCaJFfmeoM9TVCmUXVhqyIol1RBit3rFrX 43lA== X-Gm-Message-State: ALoCoQna/Q3wlf0uQe+BvCTCei+6XItGZgDbwdw5zTUVgKaQzRExZ40I4ROU50up/KMPXwKMjfWN9TEG5pB+ypehLtcvXYsW8lM47RxyTCsO61+anTEzP2AtcOx0bgk9mHbi3t8qLc2a X-Received: by 10.180.14.101 with SMTP id o5mr16415483wic.25.1409766041415; Wed, 03 Sep 2014 10:40:41 -0700 (PDT) X-Received: by 10.180.14.101 with SMTP id o5mr16415347wic.25.1409766040340; Wed, 03 Sep 2014 10:40:40 -0700 (PDT) Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id xt6sm16767812wjc.14.2014.09.03.10.40.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 10:40:39 -0700 (PDT) Message-ID: <54075296.9090007@pingidentity.com> Date: Wed, 03 Sep 2014 19:40:38 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Antonio Sanso References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> In-Reply-To: <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OwDzfki2-AC4dyFZxfDoKi_0cR8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 17:40:51 -0000 On 9/3/14, 7:14 PM, Antonio Sanso wrote: > > On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote: > >> Is your concern clients that were registered using dynamic client registration? > > yes I think your issue is then with the trust model of dynamic client registration; that is left out of scope of the dynreg spec (and the concept is not even part of the core spec), but unless you want everything to be open (which typically would not be the case), then it would involve approval somewhere in the process before the client is registered. Without dynamic client registration that approval is admin based or resource owner based, depending on use case. >> Otherwise the positive case is returning a response to a valid URL that belongs to a client that was registered explicitly by the resource owner > > well AFAIK the resource owner doesn’t register clients… roles can collapse in use cases especially when using dynamic client registration >> and the negative case is returning an error to that same URL. > > the difference is the consent screen… in the positive case you need to approve an app.. for the error case no approval is needed,,, > >> >> I fail to see the open redirect. > > why? because the client and thus the fixed URL are explicitly approved at some point Hans. > >> >> Hans. >> >> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>> >>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >> > wrote: >>> >>>> Let me try and approach this from a different angle: why would you >>>> call it an open redirect when an invalid scope is provided and call it >>>> correct protocol behavior (hopefully) when a valid scope is provided? >>> >>> as specified below in the positive case (namely when the correct scope >>> is provided) the resource owner MUST approve the app via the consent >>> screen (at least once). >>> >>> >>>> >>>> Hans. >>>> >>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>> hi John, >>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>> >>>>> > wrote: >>>>> >>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>> >>>>>> The issue is that the AS may be allowing client registrations with >>>>>> arbitrary redirect_uri. >>>>>> >>>>>> In the spec it is unspecified how a AS validates that a client >>>>>> controls the redirect_uri it is registering. >>>>>> >>>>>> I think that if anything it may be the registration step that needs >>>>>> the security consideration. >>>>> >>>>> (this is the first time :p) but I do disagree with you. It would be >>>>> pretty unpractical to block this at registration time…. >>>>> IMHO the best approach is the one taken from Google, namely returning >>>>> 400 with the cause of the error.. >>>>> >>>>> *400.* That’s an error. >>>>> >>>>> *Error: invalid_scope* >>>>> >>>>> Some requested scopes were invalid. {invalid=[l]} >>>>> >>>>> said that I hope you all agree this is an issue in the spec so far…. >>>>> >>>>> regards >>>>> >>>>> antonio >>>>> >>>>>> >>>>>> John B. >>>>>> >>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>> >>>>>> > wrote: >>>>>> >>>>>>> I don't understand. The redirect uri has to be valid in order for a >>>>>>> redirect to happen. The spec explicitly states this. >>>>>>> >>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>> hi *, >>>>>>>> >>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to open >>>>>>>> redirect. >>>>>>>> Let me explain, reading [0] >>>>>>>> >>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>> redirection URI, or if the client identifier is missing or invalid, >>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>> invalid redirection URI. >>>>>>>> >>>>>>>> If the resource owner denies the access request or if the request >>>>>>>> fails for reasons other than a missing or invalid redirection URI, >>>>>>>> the authorization server informs the client by adding the following >>>>>>>> parameters to the query component of the redirection URI using the >>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>> : >>>>>>>> >>>>>>>> Now let’s assume this. >>>>>>>> I am registering a new client to thevictim.com >>>>>>>> > >>>>>>>> > >>>>>>>> provider. >>>>>>>> I register redirect uriattacker.com >>>>>>>> > >>>>>>>> >. >>>>>>>> >>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>> back to >>>>>>>> attacker.com >>>>>>> > >. >>>>>>>> Namely I prepare a url that is in this form: >>>>>>>> >>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>> >>>>>>>> and this is works as an open redirector. >>>>>>>> Of course in the positive case if all the parameters are fine this >>>>>>>> doesn’t apply since the resource owner MUST approve the app via the >>>>>>>> consent screen (at least once). >>>>>>>> >>>>>>>> A solution would be to return error 400 rather than redirect to the >>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>> >>>>>>>> WDYT? >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> antonio >>>>>>>> >>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Bill Burke >>>>>>> JBoss, a division of Red Hat >>>>>>> http://bill.burkecentral.com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping >>>> Identity >>> >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Wed Sep 3 10:52:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB12A1A042D for ; Wed, 3 Sep 2014 10:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 T6LVxakWcnd4 for ; Wed, 3 Sep 2014 10:52:48 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B481A03C0 for ; Wed, 3 Sep 2014 10:52:32 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so6308569wiv.0 for ; Wed, 03 Sep 2014 10:52:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=hS0eELgW664pYTQ6BdlqT9v84CVtgoh6Yu5OqX03fUw=; b=QHoipcT28iQk8p/WOQd+oyd23ljnWgEBSZAHw5ptmA8aJf9x3LtxjbDrVBSRX7u2nO i235i7gmx/iAaGhOlZ+suLUQ7lOHBOfSBM12gI7dpH9v+oNJBSqGLa2Uw/QDdNxG0Im/ YnVDM8x9xz/GlKBGBu//PuxcDqN5xoCz+vYYLK/bH7fQ9McNdC48xmbSzPaH79AyzN7q foOItz372uxoTiTiPBIraS0Bjdq+pumm7QASQBujqgzQlVFT6Knip94GTJQLNBRcwolh c+xyit400NQ/TXjWgfijeOB16NLtExrRua+tFN8/uTUrELV8POt4ec4smYAiffFD6bRz 7aoA== X-Gm-Message-State: ALoCoQmbCTAYqhbZR1bKJMw6RkWzC4t3fisbKwP/9b/lTvOkLe2Z+1NZO1+GdfygzCtcYU4Rpm1P X-Received: by 10.194.173.234 with SMTP id bn10mr25701777wjc.81.1409766750944; Wed, 03 Sep 2014 10:52:30 -0700 (PDT) Received: from [10.103.63.214] ([188.207.69.117]) by mx.google.com with ESMTPSA id s1sm5870860wiw.6.2014.09.03.10.52.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 10:52:29 -0700 (PDT) References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> Mime-Version: 1.0 (1.0) In-Reply-To: <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-A5EC6E5B-842C-4872-9924-099E50C92F5C; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Wed, 3 Sep 2014 19:52:25 +0200 To: Antonio Sanso Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8yWjLMZ0M-JUuXMo1LKCrluRowQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 17:52:50 -0000 --Apple-Mail-A5EC6E5B-842C-4872-9924-099E50C92F5C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree that the error case where there is no UI is the problem, as it can b= e used inside a Iframe.=20 However error responses are generally useful. =20 OAuth core is silent on how redirect_uri are registered and if they are veri= fied.=20 Dynamic registration should warn about OAuth errors to redirect_uri from unt= rusted clients. =20 For other registration methods we should update the RFC.=20 John B.=20 Sent from my iPhone > On Sep 3, 2014, at 7:14 PM, Antonio Sanso wrote: >=20 >=20 >> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wr= ote: >>=20 >> Is your concern clients that were registered using dynamic client registr= ation? >=20 > yes >=20 >>=20 >> Otherwise the positive case is returning a response to a valid URL that b= elongs to a client that was registered explicitly by the resource owner >=20 > well AFAIK the resource owner doesn=E2=80=99t register clients=E2=80=A6 >=20 >=20 >> and the negative case is returning an error to that same URL. >=20 > the difference is the consent screen=E2=80=A6 in the positive case you nee= d to approve an app.. for the error case no approval is needed,,, >=20 >>=20 >> I fail to see the open redirect. >=20 > why? >=20 >>=20 >> Hans. >>=20 >>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>=20 >>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >> > wrote: >>>=20 >>>> Let me try and approach this from a different angle: why would you >>>> call it an open redirect when an invalid scope is provided and call it >>>> correct protocol behavior (hopefully) when a valid scope is provided? >>>=20 >>> as specified below in the positive case (namely when the correct scope >>> is provided) the resource owner MUST approve the app via the consent >>> screen (at least once). >>>=20 >>>=20 >>>>=20 >>>> Hans. >>>>=20 >>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>> hi John, >>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>> >>>>> > wrote: >>>>>=20 >>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>=20 >>>>>> The issue is that the AS may be allowing client registrations with >>>>>> arbitrary redirect_uri. >>>>>>=20 >>>>>> In the spec it is unspecified how a AS validates that a client >>>>>> controls the redirect_uri it is registering. >>>>>>=20 >>>>>> I think that if anything it may be the registration step that needs >>>>>> the security consideration. >>>>>=20 >>>>> (this is the first time :p) but I do disagree with you. It would be >>>>> pretty unpractical to block this at registration time=E2=80=A6. >>>>> IMHO the best approach is the one taken from Google, namely returning >>>>> 400 with the cause of the error.. >>>>>=20 >>>>> *400.* That=E2=80=99s an error. >>>>>=20 >>>>> *Error: invalid_scope* >>>>>=20 >>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>=20 >>>>> said that I hope you all agree this is an issue in the spec so far=E2=80= =A6. >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>> >>>>>> > wrote: >>>>>>=20 >>>>>>> I don't understand. The redirect uri has to be valid in order for a= >>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>=20 >>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>> hi *, >>>>>>>>=20 >>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to open >>>>>>>> redirect. >>>>>>>> Let me explain, reading [0] >>>>>>>>=20 >>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>> redirection URI, or if the client identifier is missing or invalid,= >>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>> invalid redirection URI. >>>>>>>>=20 >>>>>>>> If the resource owner denies the access request or if the request >>>>>>>> fails for reasons other than a missing or invalid redirection URI, >>>>>>>> the authorization server informs the client by adding the following= >>>>>>>> parameters to the query component of the redirection URI using the >>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>> : >>>>>>>>=20 >>>>>>>> Now let=E2=80=99s assume this. >>>>>>>> I am registering a new client to thevictim.com >>>>>>>> > >>>>>>>> > >>>>>>>> provider. >>>>>>>> I register redirect uriattacker.com >>>>>>>> > >>>>>>>> >. >>>>>>>>=20 >>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>> back to >>>>>>>> attacker.com >>>>>>> > = >. >>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>=20 >>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88Fi= tX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacke= r.com >>>>>>>>=20 >>>>>>>> and this is works as an open redirector. >>>>>>>> Of course in the positive case if all the parameters are fine this >>>>>>>> doesn=E2=80=99t apply since the resource owner MUST approve the app= via the >>>>>>>> consent screen (at least once). >>>>>>>>=20 >>>>>>>> A solution would be to return error 400 rather than redirect to the= >>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>=20 >>>>>>>> WDYT? >>>>>>>>=20 >>>>>>>> regards >>>>>>>>=20 >>>>>>>> antonio >>>>>>>>=20 >>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> -- >>>>>>> Bill Burke >>>>>>> JBoss, a division of Red Hat >>>>>>> http://bill.burkecentral.com >>>>>>>=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 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping >>>> Identity >>=20 >> --=20 >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity >=20 --Apple-Mail-A5EC6E5B-842C-4872-9924-099E50C92F5C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwOTAzMTc1MjI2WjAjBgkqhkiG9w0BCQQxFgQU7QCJHydakFVGnlJd NQvGXNPSlB0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEABsdpQmx40f8MbO23qoOZiFqxqEvYW/ItEQr2e42+E4WJ35NN 0gMW2l+SlKXmqPEdC5+AULkOeg8uIGfDZRihHDW0YJk1VtYHAwolesrtR2u4i9GHJ/KKwmRXnOdI QT/8ADHoGkPNSPQCEXbtl01lNOe8wnts0daxiB6SmRaFv2AFTOlidDjKwFr85V5XcGw3F3cHTBMO /XS9LSldJiOLslCfVY7IuBjci0NA1HQOyNAdLfijvowmGYWbYr97ZKzNVpd+gvr9OKNWDSKjQsJL ioCGiSVEbW027LC5V2+toLioYuLsYunsAfWfThcYqLRFg+0gUgCRAJk1kxR8BNvYUAAAAAAAAA== --Apple-Mail-A5EC6E5B-842C-4872-9924-099E50C92F5C-- From nobody Wed Sep 3 10:54:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9739C1A0416 for ; Wed, 3 Sep 2014 10:54:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PrzBmXkMYwVT for ; Wed, 3 Sep 2014 10:54:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6031A0369 for ; Wed, 3 Sep 2014 10:54:05 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Wed, 3 Sep 2014 17:54:03 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 17:54:02 +0000 From: Antonio Sanso To: Hans Zandbelt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AA== Date: Wed, 3 Sep 2014 17:54:02 +0000 Message-ID: <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> In-Reply-To: <54075296.9090007@pingidentity.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(199003)(24454002)(189002)(51444003)(479174003)(377454003)(46102001)(107046002)(106116001)(19580395003)(83716003)(15202345003)(90102001)(74502001)(77982001)(105586002)(36756003)(79102001)(2656002)(21056001)(4396001)(93886004)(83322001)(587094003)(16601075003)(85852003)(15395725005)(19580405001)(87936001)(76482001)(101416001)(64706001)(16236675004)(80022001)(50986999)(82746002)(99286002)(76176999)(20776003)(81342001)(19617315012)(92566001)(92726001)(86362001)(81542001)(33656002)(31966008)(106356001)(83072002)(77096002)(15975445006)(74662001)(85306004)(54356999)(99396002)(95666004)(110136001)(66066001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_848F15BD894D48C6B901B5565BDE4C08adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iGll1TT_QE5nP7uSzC9jCLouVgw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 17:54:09 -0000 --_000_848F15BD894D48C6B901B5565BDE4C08adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Well, I do not know if this is only dynamic registration... let=92s talk about real use cases, namely e.g. Google , Facebook , etc.. is= that dynamic client registration? I do not know=85 :) Said that what the other guys think? :) Would this deserve some =93spec adjustment=94 ? I mean there is a reason if= Google is by choice =93violating=94 the spec right? (I assume to avoid ope= n redirect=85) But other implementers do follow the spec hence they have this open redirec= tor=85 and this is not nice IMHO... On Sep 3, 2014, at 7:40 PM, Hans Zandbelt > wrote: On 9/3/14, 7:14 PM, Antonio Sanso wrote: On Sep 3, 2014, at 7:10 PM, Hans Zandbelt > wrote: Is your concern clients that were registered using dynamic client registrat= ion? yes I think your issue is then with the trust model of dynamic client registrat= ion; that is left out of scope of the dynreg spec (and the concept is not e= ven part of the core spec), but unless you want everything to be open (whic= h typically would not be the case), then it would involve approval somewher= e in the process before the client is registered. Without dynamic client re= gistration that approval is admin based or resource owner based, depending = on use case. Otherwise the positive case is returning a response to a valid URL that bel= ongs to a client that was registered explicitly by the resource owner well AFAIK the resource owner doesn=92t register clients=85 roles can collapse in use cases especially when using dynamic client regist= ration and the negative case is returning an error to that same URL. the difference is the consent screen=85 in the positive case you need to ap= prove an app.. for the error case no approval is needed,,, I fail to see the open redirect. why? because the client and thus the fixed URL are explicitly approved at some p= oint Hans. Hans. On 9/3/14, 6:56 PM, Antonio Sanso wrote: On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > wrote: Let me try and approach this from a different angle: why would you call it an open redirect when an invalid scope is provided and call it correct protocol behavior (hopefully) when a valid scope is provided? as specified below in the positive case (namely when the correct scope is provided) the resource owner MUST approve the app via the consent screen (at least once). Hans. On 9/3/14, 6:46 PM, Antonio Sanso wrote: hi John, On Sep 3, 2014, at 6:14 PM, John Bradley > wrote: In the example the redirect_uri is vlid for the attacker. The issue is that the AS may be allowing client registrations with arbitrary redirect_uri. In the spec it is unspecified how a AS validates that a client controls the redirect_uri it is registering. I think that if anything it may be the registration step that needs the security consideration. (this is the first time :p) but I do disagree with you. It would be pretty unpractical to block this at registration time=85. IMHO the best approach is the one taken from Google, namely returning 400 with the cause of the error.. *400.* That=92s an error. *Error: invalid_scope* Some requested scopes were invalid. {invalid=3D[l]} said that I hope you all agree this is an issue in the spec so far=85. regards antonio John B. On Sep 3, 2014, at 12:10 PM, Bill Burke > wrote: I don't understand. The redirect uri has to be valid in order for a redirect to happen. The spec explicitly states this. On 9/3/2014 11:43 AM, Antonio Sanso wrote: hi *, IMHO providers that strictly follow rfc6749 are vulnerable to open redirect. Let me explain, reading [0] If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, perAppendix B : Now let=92s assume this. I am registering a new client to thevictim.com > > provider. I register redirect uriattacker.com > >. According to [0] if I pass e.g. the wrong scope I am redirected back to attacker.com > >. Namely I prepare a url that is in this form: http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com and this is works as an open redirector. Of course in the positive case if all the parameters are fine this doesn=92t apply since the resource owner MUST approve the app via the consent screen (at least once). A solution would be to return error 400 rather than redirect to the redirect URI (as some provider e.g. Google do) WDYT? regards antonio [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identi= ty -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identi= ty --_000_848F15BD894D48C6B901B5565BDE4C08adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Well,
I do not know if this is only dynamic registration...
let=92s talk about real use cases, namely e.g. Google , Facebook , etc= .. is that dynamic client registration? I do not know=85 :)

Said that what the other guys think?  :) 
Would this deserve some =93spec adjustment=94 ? I mean there is a reas= on if Google is by choice =93violating=94 the spec right? (I assume to avoi= d open redirect=85)
But other implementers do follow the spec hence they have this open re= director=85 and this is not nice IMHO...



On 9/3/14, 7:14 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

Is your concern clients that were registered usin= g dynamic client registration?

yes

I think your issue is then with the trust model of dynamic client registrat= ion; that is left out of scope of the dynreg spec (and the concept is not e= ven part of the core spec), but unless you want everything to be open (whic= h typically would not be the case), then it would involve approval somewhere in the process before the client = is registered. Without dynamic client registration that approval is admin b= ased or resource owner based, depending on use case.

Otherwise the positive case is returning a respon= se to a valid URL that belongs to a client that was registered explicitly b= y the resource owner

well AFAIK the resource owner doesn=92t register clients=85

roles can collapse in use cases especially when using dynamic client regist= ration

and the negative case is returning an error to th= at same URL.

the difference is the consent screen=85 in the positive case you need to ap= prove an app.. for the error case no approval is needed,,,


I fail to see the open redirect.

why?

because the client and thus the fixed URL are explicitly approved at some p= oint

Hans.



Hans.

On 9/3/14, 6:56 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <hzandbelt@pingidentity.com
<mailto:hzandbelt@pingiden= tity.com>> wrote:

Let me try and approach this from a different ang= le: why would you
call it an open redirect when an invalid scope is provided and call it
correct protocol behavior (hopefully) when a valid scope is provided?

as specified below in the positive case (namely when the correct scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com
<mailto:ve7jtb@ve7jtb.com> <mailto:ve7jtb@ve7jtb.com>&g= t; wrote:

In the example the redirect_uri is vlid for the a= ttacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time=85.
IMHO the best approach is the one taken from Google, namely returning
400 with the cause of the error..

*400.* That=92s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=3D[l]}

said that I hope you all agree this is an issue in the spec so far=85.

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com> <mailto:bburke@redhat.com>&g= t; wrote:

I don't understand.  The redirect uri has to= be valid in order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tool= s.ietf.org/html/rfc6749#appendix-B>:

Now let=92s assume this.
I am registering a new client to thevictim= .com
<http://victim.com/><http://victim.com <http://victim.com/>>
<http://victim.com <http://victim.com/>>
provider.
I register redirect uriattacker.com<= br> <http://attacker.com/><http://attacker.com <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected
back to
attacker.com <http://attacker.com/><= http://attacker.com
<http://attacker.com/>> <<= a href=3D"http://attacker.com">http://attacker.com <http://attacker.com/>>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=3Dcode&a= mp;client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&= ;redirect_uri=3Dhttp://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn=92t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

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



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


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com <mailto:hzandbelt@pingid= entity.com>| Ping
Identity


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


-- 
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity

--_000_848F15BD894D48C6B901B5565BDE4C08adobecom_-- From nobody Wed Sep 3 11:43:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE51A04F8 for ; Wed, 3 Sep 2014 11:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=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 bDkUuKBfj6Rb for ; Wed, 3 Sep 2014 11:43:10 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2557A1A0484 for ; Wed, 3 Sep 2014 11:43:10 -0700 (PDT) Received: from mail-wg0-f47.google.com ([74.125.82.47]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKVAdhLxG81OyFnbDuT3AbUEJ8gpDoAill@postini.com; Wed, 03 Sep 2014 11:43:10 PDT Received: by mail-wg0-f47.google.com with SMTP id z12so8814327wgg.18 for ; Wed, 03 Sep 2014 11:42:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7tovfFuIDwsgsMmy9TNAVIc52maQwTdbhGJTzlqxFZ4=; b=WuGI3X4/2D9RfMQwBEARcobqwJEPRMRHw3xc9WWgvLo+XXVuWyxVaT0hLv4OfDKrst e8MqL6hSPJPKQG8OVrckNoKNdmuYCheSvfv3EkKVPFTW0jKRasSCYovtKrTSgHuj88Cz NK+0+IKaBH6UuIRL3W3JnalRPOLGrm1HNavenYVIsE51M9ol1PKpl5eTVzXHJ3mxvTWq E+Y4jTpf1aHr12lJtazKs0luRW+/7q5hwYM6l6tYOgCyXkSbhCmMVMFuclsLW1pNnw9T Qc1io7PamqnfNlSP5Do+TbTlIJRix1LGBqs3XklQJDs4kyS6UB/G+P99WJUcCcRCpWBo N+Aw== X-Gm-Message-State: ALoCoQn0fNZPRGyJx9hCDo9j5q9DIWgJjwdaXj1kU5CbdehMyDO8WpvbVuUjUf7k1xjRIamjaK48omy2pGNQosF6Wadf3TR8K55tOuU8niv03t05EOXRBAxIGDNS6ddJIExe23LUbUv/ X-Received: by 10.180.78.201 with SMTP id d9mr613380wix.12.1409769760810; Wed, 03 Sep 2014 11:42:40 -0700 (PDT) X-Received: by 10.180.78.201 with SMTP id d9mr613358wix.12.1409769760611; Wed, 03 Sep 2014 11:42:40 -0700 (PDT) Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id gk17sm5988721wic.16.2014.09.03.11.42.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 11:42:39 -0700 (PDT) Message-ID: <5407611D.6090405@pingidentity.com> Date: Wed, 03 Sep 2014 20:42:37 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Bradley , Antonio Sanso References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> In-Reply-To: <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GLE3YfPTgmkvXKdLdJ4zSRuTkoo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 18:43:12 -0000 fine, you're talking security considerations about untrusted clients; that's a different use case than the protocol flaw reason why Google would not do rfc6749 as written Hans. On 9/3/14, 7:52 PM, John Bradley wrote: > I agree that the error case where there is no UI is the problem, as it can be used inside a Iframe. > > However error responses are generally useful. > > OAuth core is silent on how redirect_uri are registered and if they are verified. > > Dynamic registration should warn about OAuth errors to redirect_uri from untrusted clients. > > For other registration methods we should update the RFC. > > John B. > > > > > Sent from my iPhone > >> On Sep 3, 2014, at 7:14 PM, Antonio Sanso wrote: >> >> >>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote: >>> >>> Is your concern clients that were registered using dynamic client registration? >> >> yes >> >>> >>> Otherwise the positive case is returning a response to a valid URL that belongs to a client that was registered explicitly by the resource owner >> >> well AFAIK the resource owner doesn’t register clients… >> >> >>> and the negative case is returning an error to that same URL. >> >> the difference is the consent screen… in the positive case you need to approve an app.. for the error case no approval is needed,,, >> >>> >>> I fail to see the open redirect. >> >> why? >> >>> >>> Hans. >>> >>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>> >>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>> > wrote: >>>> >>>>> Let me try and approach this from a different angle: why would you >>>>> call it an open redirect when an invalid scope is provided and call it >>>>> correct protocol behavior (hopefully) when a valid scope is provided? >>>> >>>> as specified below in the positive case (namely when the correct scope >>>> is provided) the resource owner MUST approve the app via the consent >>>> screen (at least once). >>>> >>>> >>>>> >>>>> Hans. >>>>> >>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>> hi John, >>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>> >>>>>> > wrote: >>>>>> >>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>> >>>>>>> The issue is that the AS may be allowing client registrations with >>>>>>> arbitrary redirect_uri. >>>>>>> >>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>> controls the redirect_uri it is registering. >>>>>>> >>>>>>> I think that if anything it may be the registration step that needs >>>>>>> the security consideration. >>>>>> >>>>>> (this is the first time :p) but I do disagree with you. It would be >>>>>> pretty unpractical to block this at registration time…. >>>>>> IMHO the best approach is the one taken from Google, namely returning >>>>>> 400 with the cause of the error.. >>>>>> >>>>>> *400.* That’s an error. >>>>>> >>>>>> *Error: invalid_scope* >>>>>> >>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>> >>>>>> said that I hope you all agree this is an issue in the spec so far…. >>>>>> >>>>>> regards >>>>>> >>>>>> antonio >>>>>> >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>> >>>>>>> > wrote: >>>>>>> >>>>>>>> I don't understand. The redirect uri has to be valid in order for a >>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>> >>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>> hi *, >>>>>>>>> >>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to open >>>>>>>>> redirect. >>>>>>>>> Let me explain, reading [0] >>>>>>>>> >>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>> redirection URI, or if the client identifier is missing or invalid, >>>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>> invalid redirection URI. >>>>>>>>> >>>>>>>>> If the resource owner denies the access request or if the request >>>>>>>>> fails for reasons other than a missing or invalid redirection URI, >>>>>>>>> the authorization server informs the client by adding the following >>>>>>>>> parameters to the query component of the redirection URI using the >>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>> : >>>>>>>>> >>>>>>>>> Now let’s assume this. >>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>> > >>>>>>>>> > >>>>>>>>> provider. >>>>>>>>> I register redirect uriattacker.com >>>>>>>>> > >>>>>>>>> >. >>>>>>>>> >>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>> back to >>>>>>>>> attacker.com >>>>>>>> > >. >>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>> >>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>> >>>>>>>>> and this is works as an open redirector. >>>>>>>>> Of course in the positive case if all the parameters are fine this >>>>>>>>> doesn’t apply since the resource owner MUST approve the app via the >>>>>>>>> consent screen (at least once). >>>>>>>>> >>>>>>>>> A solution would be to return error 400 rather than redirect to the >>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>> >>>>>>>>> WDYT? >>>>>>>>> >>>>>>>>> regards >>>>>>>>> >>>>>>>>> antonio >>>>>>>>> >>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> -- >>>>>>>> Bill Burke >>>>>>>> JBoss, a division of Red Hat >>>>>>>> http://bill.burkecentral.com >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping >>>>> Identity >>> >>> -- >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >> -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Wed Sep 3 12:24:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED4A1A6F33 for ; Wed, 3 Sep 2014 12:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 ut-urZeu-7yl for ; Wed, 3 Sep 2014 12:23:50 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B5F1A6F1D for ; Wed, 3 Sep 2014 12:23:49 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s83JNjMr010162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Sep 2014 19:23:47 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83JNi5c007895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2014 19:23:44 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83JNhHI006258; Wed, 3 Sep 2014 19:23:43 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Sep 2014 12:23:43 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <5407611D.6090405@pingidentity.com> Date: Wed, 3 Sep 2014 12:23:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> <5407611D.6090405@pingidentity.com> To: Hans Zandbelt X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JNM2OH1UvjhWAL2jU9QRAcJMbu0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:24:00 -0000 I do not believe this is a flaw specific to 6749. The flaw if any is = within HTTP itself (RFC7230). Covert redirect is a well known problem. = There are extensive recommendations that prevent this covered in 6749 = and 6819. There is no protocol fix that OAuth can make since it is a trait or = feature of HTTP. Instead we=92ve made security recommendations which are the appropriate = response to this issue. Further we published 6819 that provides further = guidance. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 3, 2014, at 11:42 AM, Hans Zandbelt = wrote: > fine, you're talking security considerations about untrusted clients; = that's a different use case than the protocol flaw reason why Google = would not do rfc6749 as written >=20 > Hans. >=20 > On 9/3/14, 7:52 PM, John Bradley wrote: >> I agree that the error case where there is no UI is the problem, as = it can be used inside a Iframe. >>=20 >> However error responses are generally useful. >>=20 >> OAuth core is silent on how redirect_uri are registered and if they = are verified. >>=20 >> Dynamic registration should warn about OAuth errors to redirect_uri = from untrusted clients. >>=20 >> For other registration methods we should update the RFC. >>=20 >> John B. >>=20 >>=20 >>=20 >>=20 >> Sent from my iPhone >>=20 >>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso wrote: >>>=20 >>>=20 >>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt = wrote: >>>>=20 >>>> Is your concern clients that were registered using dynamic client = registration? >>>=20 >>> yes >>>=20 >>>>=20 >>>> Otherwise the positive case is returning a response to a valid URL = that belongs to a client that was registered explicitly by the resource = owner >>>=20 >>> well AFAIK the resource owner doesn=92t register clients=85 >>>=20 >>>=20 >>>> and the negative case is returning an error to that same URL. >>>=20 >>> the difference is the consent screen=85 in the positive case you = need to approve an app.. for the error case no approval is needed,,, >>>=20 >>>>=20 >>>> I fail to see the open redirect. >>>=20 >>> why? >>>=20 >>>>=20 >>>> Hans. >>>>=20 >>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>=20 >>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt = >>>> > wrote: >>>>>=20 >>>>>> Let me try and approach this from a different angle: why would = you >>>>>> call it an open redirect when an invalid scope is provided and = call it >>>>>> correct protocol behavior (hopefully) when a valid scope is = provided? >>>>>=20 >>>>> as specified below in the positive case (namely when the correct = scope >>>>> is provided) the resource owner MUST approve the app via the = consent >>>>> screen (at least once). >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>> hi John, >>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>> >>>>>>> > wrote: >>>>>>>=20 >>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>=20 >>>>>>>> The issue is that the AS may be allowing client registrations = with >>>>>>>> arbitrary redirect_uri. >>>>>>>>=20 >>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>> controls the redirect_uri it is registering. >>>>>>>>=20 >>>>>>>> I think that if anything it may be the registration step that = needs >>>>>>>> the security consideration. >>>>>>>=20 >>>>>>> (this is the first time :p) but I do disagree with you. It would = be >>>>>>> pretty unpractical to block this at registration time=85. >>>>>>> IMHO the best approach is the one taken from Google, namely = returning >>>>>>> 400 with the cause of the error.. >>>>>>>=20 >>>>>>> *400.* That=92s an error. >>>>>>>=20 >>>>>>> *Error: invalid_scope* >>>>>>>=20 >>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>=20 >>>>>>> said that I hope you all agree this is an issue in the spec so = far=85. >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>> >>>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> I don't understand. The redirect uri has to be valid in order = for a >>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>=20 >>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>> hi *, >>>>>>>>>>=20 >>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to = open >>>>>>>>>> redirect. >>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>=20 >>>>>>>>>> If the request fails due to a missing, invalid, or = mismatching >>>>>>>>>> redirection URI, or if the client identifier is missing or = invalid, >>>>>>>>>> the authorization server SHOULD inform the resource owner of = the >>>>>>>>>> error and MUST NOT automatically redirect the user-agent to = the >>>>>>>>>> invalid redirection URI. >>>>>>>>>>=20 >>>>>>>>>> If the resource owner denies the access request or if the = request >>>>>>>>>> fails for reasons other than a missing or invalid redirection = URI, >>>>>>>>>> the authorization server informs the client by adding the = following >>>>>>>>>> parameters to the query component of the redirection URI = using the >>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>> : >>>>>>>>>>=20 >>>>>>>>>> Now let=92s assume this. >>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> provider. >>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>> > >>>>>>>>>> >. >>>>>>>>>>=20 >>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am = redirected >>>>>>>>>> back to >>>>>>>>>> attacker.com >>>>>>>>> > >. >>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>=20 >>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>=20 >>>>>>>>>> and this is works as an open redirector. >>>>>>>>>> Of course in the positive case if all the parameters are fine = this >>>>>>>>>> doesn=92t apply since the resource owner MUST approve the app = via the >>>>>>>>>> consent screen (at least once). >>>>>>>>>>=20 >>>>>>>>>> A solution would be to return error 400 rather than redirect = to the >>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>=20 >>>>>>>>>> WDYT? >>>>>>>>>>=20 >>>>>>>>>> regards >>>>>>>>>>=20 >>>>>>>>>> antonio >>>>>>>>>>=20 >>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Bill Burke >>>>>>>>> JBoss, a division of Red Hat >>>>>>>>> http://bill.burkecentral.com >>>>>>>>>=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 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | = Ping >>>>>> Identity >>>>=20 >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping Identity >>>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Sep 3 12:33:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393681A6F98 for ; Wed, 3 Sep 2014 12:33:21 -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, SPF_PASS=-0.001] autolearn=ham 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 a9mToOiSrjRS for ; Wed, 3 Sep 2014 12:33:18 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F801A6F92 for ; Wed, 3 Sep 2014 12:33:17 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ty20so10392930lab.2 for ; Wed, 03 Sep 2014 12:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lFREBQt8LU/ZEL4/Xxtr/9Ds8hTAca1NbOS4obRJ0Os=; b=vFqJyCoWCNqxcbqkabn40UKMj0ZOhz9wsl5drmZCShpQDRrqi0vQ7A2785auIl4MUY NhE7rCIhml45m9OaZ7xTo3y7xd9yVRJFKDwudeD3Oe1s3mFLtn7pZ3Uti+oQfmixkFLW dJ1hRwkS8d5+iXv1QtigYhktRlk3/QzkK+tf71/ksU8//joJgLHfqIX/VFm2/E7VHYh6 +oSdBOp86h3kiSlv4qNnKuz0cTE2PTUPNgJQXCi9My/AZkuJ+ojWjmGbmR8lMIea7eTl /1ST0VsjeDfv1DkpHb2VR7y5fWQRFZ/UOEYP2ai4ScvE6HEof8NTifEPgzp/+wpsVOdq r0ww== MIME-Version: 1.0 X-Received: by 10.112.14.199 with SMTP id r7mr41534530lbc.58.1409772795486; Wed, 03 Sep 2014 12:33:15 -0700 (PDT) Received: by 10.112.181.36 with HTTP; Wed, 3 Sep 2014 12:33:15 -0700 (PDT) In-Reply-To: <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> <5407611D.6090405@pingidentity.com> <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> Date: Thu, 4 Sep 2014 04:33:15 +0900 Message-ID: From: Takahiko Kawasaki To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11332feeb0687f05022e4ebc Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6EhHhogDd9pqs5ZrUo0_BdnY5cE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:33:21 -0000 --001a11332feeb0687f05022e4ebc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the point is that the registered redirect URI is evil, meaning that the person who registered the client application is evil. I don't think the spec can take any countermeasure against this case. If the registered redirect URI is evil, the issue happens even in the case where the scope is valid and consent from the end-user has been obtained. That is, an attacker would prepare an HTML page at http://attacker.com which says "Sorry, an error occurred. Please re-authorize this application." and has a login form that mimics the login form of victim.com= . IMHO, all we can do is to educate people like "Be cautious when you are requested to login again." Best Regards, Takahiko Kawasaki 2014-09-04 4:23 GMT+09:00 Phil Hunt : > I do not believe this is a flaw specific to 6749. The flaw if any is > within HTTP itself (RFC7230). Covert redirect is a well known problem. > There are extensive recommendations that prevent this covered in 6749 and > 6819. > > There is no protocol fix that OAuth can make since it is a trait or > feature of HTTP. > > Instead we=E2=80=99ve made security recommendations which are the appropr= iate > response to this issue. Further we published 6819 that provides further > guidance. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Sep 3, 2014, at 11:42 AM, Hans Zandbelt > wrote: > > > fine, you're talking security considerations about untrusted clients; > that's a different use case than the protocol flaw reason why Google woul= d > not do rfc6749 as written > > > > Hans. > > > > On 9/3/14, 7:52 PM, John Bradley wrote: > >> I agree that the error case where there is no UI is the problem, as it > can be used inside a Iframe. > >> > >> However error responses are generally useful. > >> > >> OAuth core is silent on how redirect_uri are registered and if they ar= e > verified. > >> > >> Dynamic registration should warn about OAuth errors to redirect_uri > from untrusted clients. > >> > >> For other registration methods we should update the RFC. > >> > >> John B. > >> > >> > >> > >> > >> Sent from my iPhone > >> > >>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso wrote: > >>> > >>> > >>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt > wrote: > >>>> > >>>> Is your concern clients that were registered using dynamic client > registration? > >>> > >>> yes > >>> > >>>> > >>>> Otherwise the positive case is returning a response to a valid URL > that belongs to a client that was registered explicitly by the resource > owner > >>> > >>> well AFAIK the resource owner doesn=E2=80=99t register clients=E2=80= =A6 > >>> > >>> > >>>> and the negative case is returning an error to that same URL. > >>> > >>> the difference is the consent screen=E2=80=A6 in the positive case yo= u need to > approve an app.. for the error case no approval is needed,,, > >>> > >>>> > >>>> I fail to see the open redirect. > >>> > >>> why? > >>> > >>>> > >>>> Hans. > >>>> > >>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: > >>>>> > >>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt < > hzandbelt@pingidentity.com > >>>>> > wrote: > >>>>> > >>>>>> Let me try and approach this from a different angle: why would you > >>>>>> call it an open redirect when an invalid scope is provided and cal= l > it > >>>>>> correct protocol behavior (hopefully) when a valid scope is > provided? > >>>>> > >>>>> as specified below in the positive case (namely when the correct > scope > >>>>> is provided) the resource owner MUST approve the app via the consen= t > >>>>> screen (at least once). > >>>>> > >>>>> > >>>>>> > >>>>>> Hans. > >>>>>> > >>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: > >>>>>>> hi John, > >>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>> > >>>>>>> > wrote: > >>>>>>> > >>>>>>>> In the example the redirect_uri is vlid for the attacker. > >>>>>>>> > >>>>>>>> The issue is that the AS may be allowing client registrations wi= th > >>>>>>>> arbitrary redirect_uri. > >>>>>>>> > >>>>>>>> In the spec it is unspecified how a AS validates that a client > >>>>>>>> controls the redirect_uri it is registering. > >>>>>>>> > >>>>>>>> I think that if anything it may be the registration step that > needs > >>>>>>>> the security consideration. > >>>>>>> > >>>>>>> (this is the first time :p) but I do disagree with you. It would = be > >>>>>>> pretty unpractical to block this at registration time=E2=80=A6. > >>>>>>> IMHO the best approach is the one taken from Google, namely > returning > >>>>>>> 400 with the cause of the error.. > >>>>>>> > >>>>>>> *400.* That=E2=80=99s an error. > >>>>>>> > >>>>>>> *Error: invalid_scope* > >>>>>>> > >>>>>>> Some requested scopes were invalid. {invalid=3D[l]} > >>>>>>> > >>>>>>> said that I hope you all agree this is an issue in the spec so > far=E2=80=A6. > >>>>>>> > >>>>>>> regards > >>>>>>> > >>>>>>> antonio > >>>>>>> > >>>>>>>> > >>>>>>>> John B. > >>>>>>>> > >>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>> > >>>>>>>> > wrote: > >>>>>>>> > >>>>>>>>> I don't understand. The redirect uri has to be valid in order > for a > >>>>>>>>> redirect to happen. The spec explicitly states this. > >>>>>>>>> > >>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: > >>>>>>>>>> hi *, > >>>>>>>>>> > >>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to > open > >>>>>>>>>> redirect. > >>>>>>>>>> Let me explain, reading [0] > >>>>>>>>>> > >>>>>>>>>> If the request fails due to a missing, invalid, or mismatching > >>>>>>>>>> redirection URI, or if the client identifier is missing or > invalid, > >>>>>>>>>> the authorization server SHOULD inform the resource owner of t= he > >>>>>>>>>> error and MUST NOT automatically redirect the user-agent to th= e > >>>>>>>>>> invalid redirection URI. > >>>>>>>>>> > >>>>>>>>>> If the resource owner denies the access request or if the > request > >>>>>>>>>> fails for reasons other than a missing or invalid redirection > URI, > >>>>>>>>>> the authorization server informs the client by adding the > following > >>>>>>>>>> parameters to the query component of the redirection URI using > the > >>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B > >>>>>>>>>> : > >>>>>>>>>> > >>>>>>>>>> Now let=E2=80=99s assume this. > >>>>>>>>>> I am registering a new client to thevictim.com > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> provider. > >>>>>>>>>> I register redirect uriattacker.com > >>>>>>>>>> http://attacker.com/>> > >>>>>>>>>> >. > >>>>>>>>>> > >>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirecte= d > >>>>>>>>>> back to > >>>>>>>>>> attacker.com >>>>>>>>>> > http://attacker.com/>>. > >>>>>>>>>> Namely I prepare a url that is in this form: > >>>>>>>>>> > >>>>>>>>>> > http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298= KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com > >>>>>>>>>> > >>>>>>>>>> and this is works as an open redirector. > >>>>>>>>>> Of course in the positive case if all the parameters are fine > this > >>>>>>>>>> doesn=E2=80=99t apply since the resource owner MUST approve th= e app via > the > >>>>>>>>>> consent screen (at least once). > >>>>>>>>>> > >>>>>>>>>> A solution would be to return error 400 rather than redirect t= o > the > >>>>>>>>>> redirect URI (as some provider e.g. Google do) > >>>>>>>>>> > >>>>>>>>>> WDYT? > >>>>>>>>>> > >>>>>>>>>> regards > >>>>>>>>>> > >>>>>>>>>> antonio > >>>>>>>>>> > >>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> OAuth mailing list > >>>>>>>>>> OAuth@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Bill Burke > >>>>>>>>> JBoss, a division of Red Hat > >>>>>>>>> http://bill.burkecentral.com > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>> > >>>>>> -- > >>>>>> Hans Zandbelt | Sr. Technical Architect > >>>>>> hzandbelt@pingidentity.com | > Ping > >>>>>> Identity > >>>> > >>>> -- > >>>> Hans Zandbelt | Sr. Technical Architect > >>>> hzandbelt@pingidentity.com | Ping Identity > >>> > > > > -- > > Hans Zandbelt | Sr. Technical Architect > > hzandbelt@pingidentity.com | Ping Identity > > > > _______________________________________________ > > 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 > --001a11332feeb0687f05022e4ebc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2014-09-04 4:23 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:
I do not believe this is a flaw specific to 6749. The flaw if any is within= HTTP itself (RFC7230). Covert redirect is a well known problem. There are = extensive recommendations that prevent this covered in 6749 and 6819.

There is no protocol fix that OAuth can make since it is a trait or feature= of HTTP.

Instead we=E2=80=99ve made security recommendations which are the appropria= te response to this issue. Further we published 6819 that provides further = guidance.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.com



On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

> fine, you're talking security considerations about untrusted clien= ts; that's a different use case than the protocol flaw reason why Googl= e would not do rfc6749 as written
>
> Hans.
>
> On 9/3/14, 7:52 PM, John Bradley wrote:
>> I agree that the error case where there is no UI is the problem, a= s it can be used inside a Iframe.
>>
>> However error responses are generally useful.
>>
>> OAuth core is silent on how redirect_uri are registered and if the= y are verified.
>>
>> Dynamic registration should warn about OAuth errors to redirect_ur= i from untrusted clients.
>>
>> For other registration methods we should update the RFC.
>>
>> John B.
>>
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso <asanso@adobe.com> wrote:
>>>
>>>
>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:=
>>>>
>>>> Is your concern clients that were registered using dynamic= client registration?
>>>
>>> yes
>>>
>>>>
>>>> Otherwise the positive case is returning a response to a v= alid URL that belongs to a client that was registered explicitly by the res= ource owner
>>>
>>> well AFAIK the resource owner doesn=E2=80=99t register clients= =E2=80=A6
>>>
>>>
>>>> and the negative case is returning an error to that same U= RL.
>>>
>>> the difference is the consent screen=E2=80=A6 in the positive = case you need to approve an app.. for the error case no approval is needed,= ,,
>>>
>>>>
>>>> I fail to see the open redirect.
>>>
>>> why?
>>>
>>>>
>>>> Hans.
>>>>
>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>>>>>
>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <hzandbelt@pingidentity.com
>>>>> <mailto:hzandbelt@pingidentity.com>> wrote:
>>>>>
>>>>>> Let me try and approach this from a different angl= e: why would you
>>>>>> call it an open redirect when an invalid scope is = provided and call it
>>>>>> correct protocol behavior (hopefully) when a valid= scope is provided?
>>>>>
>>>>> as specified below in the positive case (namely when t= he correct scope
>>>>> is provided) the resource owner MUST approve the app v= ia the consent
>>>>> screen (at least once).
>>>>>
>>>>>
>>>>>>
>>>>>> Hans.
>>>>>>
>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>>>>>>> hi John,
>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley <<= a href=3D"mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com
>>>>>>> <mailto:ve7jtb@ve7jtb.com>
>>>>>>> <mailto:ve7jtb@ve7jtb.com>> wrote:
>>>>>>>
>>>>>>>> In the example the redirect_uri is vlid fo= r the attacker.
>>>>>>>>
>>>>>>>> The issue is that the AS may be allowing c= lient registrations with
>>>>>>>> arbitrary redirect_uri.
>>>>>>>>
>>>>>>>> In the spec it is unspecified how a AS val= idates that a client
>>>>>>>> controls the redirect_uri it is registerin= g.
>>>>>>>>
>>>>>>>> I think that if anything it may be the reg= istration step that needs
>>>>>>>> the security consideration.
>>>>>>>
>>>>>>> (this is the first time :p) but I do disagree = with you. It would be
>>>>>>> pretty unpractical to block this at registrati= on time=E2=80=A6.
>>>>>>> IMHO the best approach is the one taken from G= oogle, namely returning
>>>>>>> 400 with the cause of the error..
>>>>>>>
>>>>>>> *400.* That=E2=80=99s an error.
>>>>>>>
>>>>>>> *Error: invalid_scope*
>>>>>>>
>>>>>>> Some requested scopes were invalid. {invalid= =3D[l]}
>>>>>>>
>>>>>>> said that I hope you all agree this is an issu= e in the spec so far=E2=80=A6.
>>>>>>>
>>>>>>> regards
>>>>>>>
>>>>>>> antonio
>>>>>>>
>>>>>>>>
>>>>>>>> John B.
>>>>>>>>
>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke &l= t;bburke@redhat.com
>>>>>>>> <mailto:bburke@redhat.com>
>>>>>>>> <mailto:bburke@redhat.com>> wrote:
>>>>>>>>
>>>>>>>>> I don't understand.=C2=A0 The redi= rect uri has to be valid in order for a
>>>>>>>>> redirect to happen.=C2=A0 The spec exp= licitly states this.
>>>>>>>>>
>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sans= o wrote:
>>>>>>>>>> hi *,
>>>>>>>>>>
>>>>>>>>>> IMHO providers that strictly follo= w rfc6749 are vulnerable to open
>>>>>>>>>> redirect.
>>>>>>>>>> Let me explain, reading [0]
>>>>>>>>>>
>>>>>>>>>> If the request fails due to a miss= ing, invalid, or mismatching
>>>>>>>>>> redirection URI, or if the client = identifier is missing or invalid,
>>>>>>>>>> the authorization server SHOULD in= form the resource owner of the
>>>>>>>>>> error and MUST NOT automatically r= edirect the user-agent to the
>>>>>>>>>> invalid redirection URI.
>>>>>>>>>>
>>>>>>>>>> If the resource owner denies the a= ccess request or if the request
>>>>>>>>>> fails for reasons other than a mis= sing or invalid redirection URI,
>>>>>>>>>> the authorization server informs t= he client by adding the following
>>>>>>>>>> parameters to the query component = of the redirection URI using the
>>>>>>>>>> "application/x-www-form-urlen= coded" format, perAppendix B
>>>>>>>>>> <https://tools.ietf.org/html/= rfc6749#appendix-B>:
>>>>>>>>>>
>>>>>>>>>> Now let=E2=80=99s assume this.
>>>>>>>>>> I am registering a new client to <= a href=3D"http://thevictim.com" target=3D"_blank">thevictim.com
>>>>>>>>>> <http://victim.com/><http://victim.com <http://victim.com/>>
>>>>>>>>>> <http://victim.com <http://victim.com/>>
>>>>>>>>>> provider.
>>>>>>>>>> I register redirect uriattacker.com
>>>>>>>>>> <http://attacker.com/><http://attacker.com <http://attacker.com/>>
>>>>>>>>>> <http://attacker.com <http://attacker.com/>>.
>>>>>>>>>>
>>>>>>>>>> According to [0] if I pass e.g. th= e wrong scope I am redirected
>>>>>>>>>> back to
>>>>>>>>>> attacker.com <http://attacker.com/><http://attacker.com
>>>>>>>>>> <http://attacker.com/>> <http://attacker.com <http://attacker.com/>>.
>>>>>>>>>> Namely I prepare a url that is in = this form:
>>>>>>>>>>
>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc8= 8FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dht= tp://attacker.com
>>>>>>>>>>
>>>>>>>>>> and this is works as an open redir= ector.
>>>>>>>>>> Of course in the positive case if = all the parameters are fine this
>>>>>>>>>> doesn=E2=80=99t apply since the re= source owner MUST approve the app via the
>>>>>>>>>> consent screen (at least once). >>>>>>>>>>
>>>>>>>>>> A solution would be to return erro= r 400 rather than redirect to the
>>>>>>>>>> redirect URI (as some provider e.g= . Google do)
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>>
>>>>>>>>>> regards
>>>>>>>>>>
>>>>>>>>>> antonio
>>>>>>>>>>
>>>>>>>>>> [0] https://tools.ietf.org/= html/rfc6749#section-4.1.2.1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> __________________________________= _____________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> = OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAut= h@ietf.org <mailto:OAuth@ietf.org<= /a>>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ie= tf.org <mailto:OAuth@ietf.org&= gt;<mailto:OAuth@ietf.org>
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth=
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.o= rg <mailto:OAuth@ietf.org><= br> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth=
>>>>>>
>>>>>> --
>>>>>> Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | Sr. Technical Architect
>>>>>> hzan= dbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com>| Ping
>>>>>> Identity
>>>>
>>>> --
>>>> Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | Sr. Technical Architect
>>>> hzandbelt@pi= ngidentity.com | Ping Identity
>>>
>
> --
> Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sr. Te= chnical Architect
> hzandbelt@pingidentity.c= om | Ping Identity
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--001a11332feeb0687f05022e4ebc-- From nobody Wed Sep 3 12:36:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAF51A065B for ; Wed, 3 Sep 2014 12:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 7fwRuyVQI0GF for ; Wed, 3 Sep 2014 12:36:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9D31A0659 for ; Wed, 3 Sep 2014 12:36:50 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 19:36:48 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 19:36:47 +0000 From: Antonio Sanso To: Phil Hunt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAKq4CAAA4HgIAAC3mAgAADpYA= Date: Wed, 3 Sep 2014 19:36:47 +0000 Message-ID: <7320F0A5-86FA-42CB-8C6D-00EBDDF1A48C@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> <5407611D.6090405@pingidentity.com> <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> In-Reply-To: <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(377454003)(189002)(479174003)(24454002)(51444003)(51704005)(15395725005)(21056001)(85852003)(76176999)(83072002)(80022001)(83716003)(99396002)(50986999)(2656002)(77096002)(15975445006)(15202345003)(4396001)(82746002)(19580395003)(92726001)(36756003)(15974865002)(33656002)(83322001)(31966008)(587094003)(79102001)(66066001)(77982001)(93886004)(110136001)(90102001)(105586002)(19580405001)(76482001)(74502001)(101416001)(46102001)(87936001)(99286002)(81342001)(74662001)(16601075003)(81542001)(85306004)(86362001)(54356999)(106356001)(106116001)(92566001)(20776003)(95666004)(64706001)(107046002)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4k747LFpYN-IzBwOIaEn-DwjiL0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:36:52 -0000 hi Phil, can you point out the relative paragraph that covers this specific case in = RFC6819? On Sep 3, 2014, at 9:23 PM, Phil Hunt wrote: > I do not believe this is a flaw specific to 6749. The flaw if any is with= in HTTP itself (RFC7230). Covert redirect is a well known problem. There ar= e extensive recommendations that prevent this covered in 6749 and 6819. >=20 > There is no protocol fix that OAuth can make since it is a trait or featu= re of HTTP. >=20 > Instead we=92ve made security recommendations which are the appropriate r= esponse to this issue. Further we published 6819 that provides further guid= ance. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Sep 3, 2014, at 11:42 AM, Hans Zandbelt w= rote: >=20 >> fine, you're talking security considerations about untrusted clients; th= at's a different use case than the protocol flaw reason why Google would no= t do rfc6749 as written >>=20 >> Hans. >>=20 >> On 9/3/14, 7:52 PM, John Bradley wrote: >>> I agree that the error case where there is no UI is the problem, as it = can be used inside a Iframe. >>>=20 >>> However error responses are generally useful. >>>=20 >>> OAuth core is silent on how redirect_uri are registered and if they are= verified. >>>=20 >>> Dynamic registration should warn about OAuth errors to redirect_uri fro= m untrusted clients. >>>=20 >>> For other registration methods we should update the RFC. >>>=20 >>> John B. >>>=20 >>>=20 >>>=20 >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso wrote: >>>>=20 >>>>=20 >>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote: >>>>>=20 >>>>> Is your concern clients that were registered using dynamic client reg= istration? >>>>=20 >>>> yes >>>>=20 >>>>>=20 >>>>> Otherwise the positive case is returning a response to a valid URL th= at belongs to a client that was registered explicitly by the resource owner >>>>=20 >>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>=20 >>>>=20 >>>>> and the negative case is returning an error to that same URL. >>>>=20 >>>> the difference is the consent screen=85 in the positive case you need = to approve an app.. for the error case no approval is needed,,, >>>>=20 >>>>>=20 >>>>> I fail to see the open redirect. >>>>=20 >>>> why? >>>>=20 >>>>>=20 >>>>> Hans. >>>>>=20 >>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>=20 >>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>> > wrote: >>>>>>=20 >>>>>>> Let me try and approach this from a different angle: why would you >>>>>>> call it an open redirect when an invalid scope is provided and call= it >>>>>>> correct protocol behavior (hopefully) when a valid scope is provide= d? >>>>>>=20 >>>>>> as specified below in the positive case (namely when the correct sco= pe >>>>>> is provided) the resource owner MUST approve the app via the consent >>>>>> screen (at least once). >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>> hi John, >>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>> >>>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>=20 >>>>>>>>> The issue is that the AS may be allowing client registrations wit= h >>>>>>>>> arbitrary redirect_uri. >>>>>>>>>=20 >>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>=20 >>>>>>>>> I think that if anything it may be the registration step that nee= ds >>>>>>>>> the security consideration. >>>>>>>>=20 >>>>>>>> (this is the first time :p) but I do disagree with you. It would b= e >>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>> IMHO the best approach is the one taken from Google, namely return= ing >>>>>>>> 400 with the cause of the error.. >>>>>>>>=20 >>>>>>>> *400.* That=92s an error. >>>>>>>>=20 >>>>>>>> *Error: invalid_scope* >>>>>>>>=20 >>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>=20 >>>>>>>> said that I hope you all agree this is an issue in the spec so far= =85. >>>>>>>>=20 >>>>>>>> regards >>>>>>>>=20 >>>>>>>> antonio >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> I don't understand. The redirect uri has to be valid in order f= or a >>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>=20 >>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>> hi *, >>>>>>>>>>>=20 >>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to o= pen >>>>>>>>>>> redirect. >>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>=20 >>>>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>>>> redirection URI, or if the client identifier is missing or inva= lid, >>>>>>>>>>> the authorization server SHOULD inform the resource owner of th= e >>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>=20 >>>>>>>>>>> If the resource owner denies the access request or if the reque= st >>>>>>>>>>> fails for reasons other than a missing or invalid redirection U= RI, >>>>>>>>>>> the authorization server informs the client by adding the follo= wing >>>>>>>>>>> parameters to the query component of the redirection URI using = the >>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>> : >>>>>>>>>>>=20 >>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> provider. >>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>> > >>>>>>>>>>> >. >>>>>>>>>>>=20 >>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>>>> back to >>>>>>>>>>> attacker.com >>>>>>>>>> > >. >>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>=20 >>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc= 88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://at= tacker.com >>>>>>>>>>>=20 >>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>> Of course in the positive case if all the parameters are fine t= his >>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the app v= ia the >>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>=20 >>>>>>>>>>> A solution would be to return error 400 rather than redirect to= the >>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>=20 >>>>>>>>>>> WDYT? >>>>>>>>>>>=20 >>>>>>>>>>> regards >>>>>>>>>>>=20 >>>>>>>>>>> antonio >>>>>>>>>>>=20 >>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Bill Burke >>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>=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 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Pin= g >>>>>>> Identity >>>>>=20 >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>=20 >>=20 >> --=20 >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Wed Sep 3 12:37:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D0B1A6F61 for ; Wed, 3 Sep 2014 12:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 sICpONyhGV95 for ; Wed, 3 Sep 2014 12:37:17 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EAC1A6F02 for ; Wed, 3 Sep 2014 12:37:17 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s83JbEXH026230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Sep 2014 19:37:15 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83JbDNq011942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Sep 2014 19:37:14 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83JbDeh011926; Wed, 3 Sep 2014 19:37:13 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Sep 2014 12:37:12 -0700 References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> <5407611D.6090405@pingidentity.com> <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-AC71532D-5FCE-4550-A406-9AC11855A260 Content-Transfer-Encoding: 7bit Message-Id: <5FD4C253-1050-4F73-871E-3897707F1DAA@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Wed, 3 Sep 2014 12:37:09 -0700 To: Takahiko Kawasaki X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qgGu1QJXcURr2_aKd9-S05KmJrg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:37:21 -0000 --Apple-Mail-AC71532D-5FCE-4550-A406-9AC11855A260 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable One improvement we made in dyn reg was the introduction of software statemen= ts. This can be used to force all mobile clients claiming to be a particular= client to register the same redirect uri.=20 This closes the door on a large number of cases.=20 Phil > On Sep 3, 2014, at 12:33, Takahiko Kawasaki wrote: >=20 > I think the point is that the registered redirect URI is evil, meaning tha= t the person who registered the client application is evil. I don't think th= e spec can take any countermeasure against this case. >=20 > If the registered redirect URI is evil, the issue happens even in the case= where the scope is valid and consent from the end-user has been obtained. T= hat is, an attacker would prepare an HTML page at http://attacker.com which s= ays "Sorry, an error occurred. Please re-authorize this application." and ha= s a login form that mimics the login form of victim.com. >=20 > IMHO, all we can do is to educate people like "Be cautious when you are re= quested to login again." >=20 > Best Regards, > Takahiko Kawasaki >=20 >=20 > 2014-09-04 4:23 GMT+09:00 Phil Hunt : >> I do not believe this is a flaw specific to 6749. The flaw if any is with= in HTTP itself (RFC7230). Covert redirect is a well known problem. There are= extensive recommendations that prevent this covered in 6749 and 6819. >>=20 >> There is no protocol fix that OAuth can make since it is a trait or featu= re of HTTP. >>=20 >> Instead we=E2=80=99ve made security recommendations which are the appropr= iate response to this issue. Further we published 6819 that provides further= guidance. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt w= rote: >>=20 >> > fine, you're talking security considerations about untrusted clients; t= hat's a different use case than the protocol flaw reason why Google would no= t do rfc6749 as written >> > >> > Hans. >> > >> > On 9/3/14, 7:52 PM, John Bradley wrote: >> >> I agree that the error case where there is no UI is the problem, as it= can be used inside a Iframe. >> >> >> >> However error responses are generally useful. >> >> >> >> OAuth core is silent on how redirect_uri are registered and if they ar= e verified. >> >> >> >> Dynamic registration should warn about OAuth errors to redirect_uri fr= om untrusted clients. >> >> >> >> For other registration methods we should update the RFC. >> >> >> >> John B. >> >> >> >> >> >> >> >> >> >> Sent from my iPhone >> >> >> >>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso wrote: >> >>> >> >>> >> >>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote: >> >>>> >> >>>> Is your concern clients that were registered using dynamic client re= gistration? >> >>> >> >>> yes >> >>> >> >>>> >> >>>> Otherwise the positive case is returning a response to a valid URL t= hat belongs to a client that was registered explicitly by the resource owner= >> >>> >> >>> well AFAIK the resource owner doesn=E2=80=99t register clients=E2=80=A6= >> >>> >> >>> >> >>>> and the negative case is returning an error to that same URL. >> >>> >> >>> the difference is the consent screen=E2=80=A6 in the positive case yo= u need to approve an app.. for the error case no approval is needed,,, >> >>> >> >>>> >> >>>> I fail to see the open redirect. >> >>> >> >>> why? >> >>> >> >>>> >> >>>> Hans. >> >>>> >> >>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >> >>>>> >> >>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > >>>>> > wrote: >> >>>>> >> >>>>>> Let me try and approach this from a different angle: why would you= >> >>>>>> call it an open redirect when an invalid scope is provided and cal= l it >> >>>>>> correct protocol behavior (hopefully) when a valid scope is provid= ed? >> >>>>> >> >>>>> as specified below in the positive case (namely when the correct sc= ope >> >>>>> is provided) the resource owner MUST approve the app via the consen= t >> >>>>> screen (at least once). >> >>>>> >> >>>>> >> >>>>>> >> >>>>>> Hans. >> >>>>>> >> >>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >> >>>>>>> hi John, >> >>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley > >>>>>>> >> >>>>>>> > wrote: >> >>>>>>> >> >>>>>>>> In the example the redirect_uri is vlid for the attacker. >> >>>>>>>> >> >>>>>>>> The issue is that the AS may be allowing client registrations wi= th >> >>>>>>>> arbitrary redirect_uri. >> >>>>>>>> >> >>>>>>>> In the spec it is unspecified how a AS validates that a client >> >>>>>>>> controls the redirect_uri it is registering. >> >>>>>>>> >> >>>>>>>> I think that if anything it may be the registration step that ne= eds >> >>>>>>>> the security consideration. >> >>>>>>> >> >>>>>>> (this is the first time :p) but I do disagree with you. It would b= e >> >>>>>>> pretty unpractical to block this at registration time=E2=80=A6. >> >>>>>>> IMHO the best approach is the one taken from Google, namely retur= ning >> >>>>>>> 400 with the cause of the error.. >> >>>>>>> >> >>>>>>> *400.* That=E2=80=99s an error. >> >>>>>>> >> >>>>>>> *Error: invalid_scope* >> >>>>>>> >> >>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >> >>>>>>> >> >>>>>>> said that I hope you all agree this is an issue in the spec so fa= r=E2=80=A6. >> >>>>>>> >> >>>>>>> regards >> >>>>>>> >> >>>>>>> antonio >> >>>>>>> >> >>>>>>>> >> >>>>>>>> John B. >> >>>>>>>> >> >>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke > >>>>>>>> >> >>>>>>>> > wrote: >> >>>>>>>> >> >>>>>>>>> I don't understand. The redirect uri has to be valid in order f= or a >> >>>>>>>>> redirect to happen. The spec explicitly states this. >> >>>>>>>>> >> >>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >> >>>>>>>>>> hi *, >> >>>>>>>>>> >> >>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to o= pen >> >>>>>>>>>> redirect. >> >>>>>>>>>> Let me explain, reading [0] >> >>>>>>>>>> >> >>>>>>>>>> If the request fails due to a missing, invalid, or mismatching= >> >>>>>>>>>> redirection URI, or if the client identifier is missing or inv= alid, >> >>>>>>>>>> the authorization server SHOULD inform the resource owner of t= he >> >>>>>>>>>> error and MUST NOT automatically redirect the user-agent to th= e >> >>>>>>>>>> invalid redirection URI. >> >>>>>>>>>> >> >>>>>>>>>> If the resource owner denies the access request or if the requ= est >> >>>>>>>>>> fails for reasons other than a missing or invalid redirection U= RI, >> >>>>>>>>>> the authorization server informs the client by adding the foll= owing >> >>>>>>>>>> parameters to the query component of the redirection URI using= the >> >>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >> >>>>>>>>>> : >> >>>>>>>>>> >> >>>>>>>>>> Now let=E2=80=99s assume this. >> >>>>>>>>>> I am registering a new client to thevictim.com >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> provider. >> >>>>>>>>>> I register redirect uriattacker.com >> >>>>>>>>>> > >> >>>>>>>>>> >. >> >>>>>>>>>> >> >>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirecte= d >> >>>>>>>>>> back to >> >>>>>>>>>> attacker.com > >>>>>>>>>> > >. >> >>>>>>>>>> Namely I prepare a url that is in this form: >> >>>>>>>>>> >> >>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3Db= c88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://at= tacker.com >> >>>>>>>>>> >> >>>>>>>>>> and this is works as an open redirector. >> >>>>>>>>>> Of course in the positive case if all the parameters are fine t= his >> >>>>>>>>>> doesn=E2=80=99t apply since the resource owner MUST approve th= e app via the >> >>>>>>>>>> consent screen (at least once). >> >>>>>>>>>> >> >>>>>>>>>> A solution would be to return error 400 rather than redirect t= o the >> >>>>>>>>>> redirect URI (as some provider e.g. Google do) >> >>>>>>>>>> >> >>>>>>>>>> WDYT? >> >>>>>>>>>> >> >>>>>>>>>> regards >> >>>>>>>>>> >> >>>>>>>>>> antonio >> >>>>>>>>>> >> >>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> OAuth mailing list >> >>>>>>>>>> OAuth@ietf.org >> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> Bill Burke >> >>>>>>>>> JBoss, a division of Red Hat >> >>>>>>>>> http://bill.burkecentral.com >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> 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 >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> OAuth mailing list >> >>>>>>> OAuth@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>>>> >> >>>>>> -- >> >>>>>> Hans Zandbelt | Sr. Technical Architect >> >>>>>> hzandbelt@pingidentity.com | Pi= ng >> >>>>>> Identity >> >>>> >> >>>> -- >> >>>> Hans Zandbelt | Sr. Technical Architect >> >>>> hzandbelt@pingidentity.com | Ping Identity >> >>> >> > >> > -- >> > Hans Zandbelt | Sr. Technical Architect >> > hzandbelt@pingidentity.com | Ping Identity >> > >> > _______________________________________________ >> > 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 --Apple-Mail-AC71532D-5FCE-4550-A406-9AC11855A260 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
One improvement we made in dyn reg was= the introduction of software statements. This can be used to force all mobi= le clients claiming to be a particular client to register the same redirect u= ri. 

This closes the door on a large number of= cases. 

Phil

On Sep 3, 2014, at 12:33, Takahiko K= awasaki <daru.tk@gmail.com> w= rote:

I think t= he point is that the registered redirect URI is evil, meaning that the perso= n who registered the client application is evil. I don't think the spec can t= ake any countermeasure against this case.

If the registered redirect URI is evil, the issue happens even in the ca= se where the scope is valid and consent from the end-user has been obtained.= That is, an attacker would prepare an HTML page at http://attacker.com which says "Sorry, an error occurred. Please= re-authorize this application." and has a login form that mimics the login f= orm of victim.com.

IMHO, all we can do is to educate people like "Be cautious when you are r= equested to login again."

Best Regards,
Takahiko Kawasaki


2014-09-04 4:23 GMT+09:00 Phil Hunt <phil.hunt@oracle.com>:=
I do not believe this is a flaw specific to 6749. The flaw if any is within H= TTP itself (RFC7230). Covert redirect is a well known problem. There are ext= ensive recommendations that prevent this covered in 6749 and 6819.

There is no protocol fix that OAuth can make since it is a trait or feature o= f HTTP.

Instead we=E2=80=99ve made security recommendations which are the appropriat= e response to this issue. Further we published 6819 that provides further gu= idance.

Phil

@independentid
www.independentid= .com
phil.hunt@oracle.com



On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

> fine, you're talking security considerations about untrusted clients; t= hat's a different use case than the protocol flaw reason why Google would no= t do rfc6749 as written
>
> Hans.
>
> On 9/3/14, 7:52 PM, John Bradley wrote:
>> I agree that the error case where there is no UI is the problem, as= it can be used inside a Iframe.
>>
>> However error responses are generally useful.
>>
>> OAuth core is silent on how redirect_uri are registered and if they= are verified.
>>
>> Dynamic registration should warn about OAuth errors to redirect_uri= from untrusted clients.
>>
>> For other registration methods we should update the RFC.
>>
>> John B.
>>
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso <asanso@adobe.com> wrote:
>>>
>>>
>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote: >>>>
>>>> Is your concern clients that were registered using dynamic c= lient registration?
>>>
>>> yes
>>>
>>>>
>>>> Otherwise the positive case is returning a response to a va= lid URL that belongs to a client that was registered explicitly by the resou= rce owner
>>>
>>> well AFAIK the resource owner doesn=E2=80=99t register clients=E2= =80=A6
>>>
>>>
>>>> and the negative case is returning an error to that same UR= L.
>>>
>>> the difference is the consent screen=E2=80=A6 in the positive c= ase you need to approve an app.. for the error case no approval is needed,,,=
>>>
>>>>
>>>> I fail to see the open redirect.
>>>
>>> why?
>>>
>>>>
>>>> Hans.
>>>>
>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>>>>>
>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <hzandbelt@pingidentity.com
>>>>> <mailto:hzandbelt@pingidentity.com>> wrote:
>>>>>
>>>>>> Let me try and approach this from a different angle= : why would you
>>>>>> call it an open redirect when an invalid scope is p= rovided and call it
>>>>>> correct protocol behavior (hopefully) when a valid s= cope is provided?
>>>>>
>>>>> as specified below in the positive case (namely when th= e correct scope
>>>>> is provided) the resource owner MUST approve the app vi= a the consent
>>>>> screen (at least once).
>>>>>
>>>>>
>>>>>>
>>>>>> Hans.
>>>>>>
>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>>>>>>> hi John,
>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com
>>>>>>> <mailto:ve7jtb@ve7jtb.com>
>>>>>>> <mailto:ve7jtb@ve7jtb.com>> wrote:
>>>>>>>
>>>>>>>> In the example the redirect_uri is vlid for= the attacker.
>>>>>>>>
>>>>>>>> The issue is that the AS may be allowing cl= ient registrations with
>>>>>>>> arbitrary redirect_uri.
>>>>>>>>
>>>>>>>> In the spec it is unspecified how a AS vali= dates that a client
>>>>>>>> controls the redirect_uri it is registering= .
>>>>>>>>
>>>>>>>> I think that if anything it may be the regi= stration step that needs
>>>>>>>> the security consideration.
>>>>>>>
>>>>>>> (this is the first time :p) but I do disagree w= ith you. It would be
>>>>>>> pretty unpractical to block this at registratio= n time=E2=80=A6.
>>>>>>> IMHO the best approach is the one taken from Go= ogle, namely returning
>>>>>>> 400 with the cause of the error..
>>>>>>>
>>>>>>> *400.* That=E2=80=99s an error.
>>>>>>>
>>>>>>> *Error: invalid_scope*
>>>>>>>
>>>>>>> Some requested scopes were invalid. {invalid=3D= [l]}
>>>>>>>
>>>>>>> said that I hope you all agree this is an issue= in the spec so far=E2=80=A6.
>>>>>>>
>>>>>>> regards
>>>>>>>
>>>>>>> antonio
>>>>>>>
>>>>>>>>
>>>>>>>> John B.
>>>>>>>>
>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke <= ;bburke@redhat.com
>>>>>>>> <mailto:bburke@redhat.com>
>>>>>>>> <mailto:bburke@redhat.com>> wrote:
>>>>>>>>
>>>>>>>>> I don't understand.  The redirect u= ri has to be valid in order for a
>>>>>>>>> redirect to happen.  The spec expl= icitly states this.
>>>>>>>>>
>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso= wrote:
>>>>>>>>>> hi *,
>>>>>>>>>>
>>>>>>>>>> IMHO providers that strictly follow= rfc6749 are vulnerable to open
>>>>>>>>>> redirect.
>>>>>>>>>> Let me explain, reading [0]
>>>>>>>>>>
>>>>>>>>>> If the request fails due to a missi= ng, invalid, or mismatching
>>>>>>>>>> redirection URI, or if the client i= dentifier is missing or invalid,
>>>>>>>>>> the authorization server SHOULD inf= orm the resource owner of the
>>>>>>>>>> error and MUST NOT automatically re= direct the user-agent to the
>>>>>>>>>> invalid redirection URI.
>>>>>>>>>>
>>>>>>>>>> If the resource owner denies the ac= cess request or if the request
>>>>>>>>>> fails for reasons other than a miss= ing or invalid redirection URI,
>>>>>>>>>> the authorization server informs th= e client by adding the following
>>>>>>>>>> parameters to the query component o= f the redirection URI using the
>>>>>>>>>> "application/x-www-form-urlencoded"= format, perAppendix B
>>>>>>>>>> <https://tools.ietf.org/html/rf= c6749#appendix-B>:
>>>>>>>>>>
>>>>>>>>>> Now let=E2=80=99s assume this.
>>>>>>>>>> I am registering a new client to thevictim.com
>>>>>>>>>> <http://victim.com/><http://victim.com <http://victim.com/>>
>>>>>>>>>> <http://victim.com <http://victim.com/>>
>>>>>>>>>> provider.
>>>>>>>>>> I register redirect uriattacker.com
>>>>>>>>>> <http://attacker.com/><http://attacker.com <http://attacker.com/>>
>>>>>>>>>> <http://attacker.com <http://attacker.com/>>.
>>>>>>>>>>
>>>>>>>>>> According to [0] if I pass e.g. the= wrong scope I am redirected
>>>>>>>>>> back to
>>>>>>>>>> attacker.com <http://attacker.com/><http://attacker.com
>>>>>>>>>> <http://attacker.com/>> <http://attacker.com <http://attacker.com/>>.
>>>>>>>>>> Namely I prepare a url that is in t= his form:
>>>>>>>>>>
>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88Fit= X1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://= attacker.com
>>>>>>>>>>
>>>>>>>>>> and this is works as an open redire= ctor.
>>>>>>>>>> Of course in the positive case if a= ll the parameters are fine this
>>>>>>>>>> doesn=E2=80=99t apply since the res= ource owner MUST approve the app via the
>>>>>>>>>> consent screen (at least once).
= >>>>>>>>>>
>>>>>>>>>> A solution would be to return error= 400 rather than redirect to the
>>>>>>>>>> redirect URI (as some provider e.g.= Google do)
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>>
>>>>>>>>>> regards
>>>>>>>>>>
>>>>>>>>>> antonio
>>>>>>>>>>
>>>>>>>>>> [0] https://tools.ietf.org/ht= ml/rfc6749#section-4.1.2.1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ___________________________________= ____________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> O= Auth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo= /oauth
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>
>>>>>>>>> _______________________________________= ________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth= @ietf.org <mailto:OAuth@ietf.org>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oau= th
>>>>>>>>
>>>>>>>> ___________________________________________= ____
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@iet= f.org <mailto:OAuth@ietf.org>= ;<mailto:OAuth@ietf.org>
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________=
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.or= g <mailto:OAuth@ietf.org> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>
>>>>>> --
>>>>>> Hans Zandbelt          &nb= sp;   | Sr. Technical Architect
>>>>>> hzand= belt@pingidentity.com <mailto:hzandbelt@pingidentity.com>| Ping
>>>>>> Identity
>>>>
>>>> --
>>>> Hans Zandbelt            &nbs= p; | Sr. Technical Architect
>>>> hzandbelt@pin= gidentity.com | Ping Identity
>>>
>
> --
> Hans Zandbelt              | Sr. Tec= hnical Architect
> hzandbelt@pingidentity.co= m | Ping Identity
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

= --Apple-Mail-AC71532D-5FCE-4550-A406-9AC11855A260-- From nobody Wed Sep 3 12:48:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAFC1A6F79 for ; Wed, 3 Sep 2014 12:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 o-JPxvby8xvF for ; Wed, 3 Sep 2014 12:48:04 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DEA41A0AE4 for ; Wed, 3 Sep 2014 12:48:04 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s83Jm1pi007177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Sep 2014 19:48:02 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83Jm0IY009895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2014 19:48:00 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s83JlxZT007000; Wed, 3 Sep 2014 19:47:59 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Sep 2014 12:47:59 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <7320F0A5-86FA-42CB-8C6D-00EBDDF1A48C@adobe.com> Date: Wed, 3 Sep 2014 12:47:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <41169177-EDF1-4577-8860-B0DE2CDF5C0C@oracle.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> <5407611D.6090405@pingidentity.com> <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> <7320F0A5-86FA-42CB-8C6D-00EBDDF1A48C@adobe.com> To: Antonio Sanso X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/K-JWXfravP-DtYpnj3v4GVtPHXw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:48:07 -0000 in RFC6810, see section 3.5 and 4.1.5.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 3, 2014, at 12:36 PM, Antonio Sanso wrote: > hi Phil, > can you point out the relative paragraph that covers this specific = case in RFC6819? > On Sep 3, 2014, at 9:23 PM, Phil Hunt wrote: >=20 >> I do not believe this is a flaw specific to 6749. The flaw if any is = within HTTP itself (RFC7230). Covert redirect is a well known problem. = There are extensive recommendations that prevent this covered in 6749 = and 6819. >>=20 >> There is no protocol fix that OAuth can make since it is a trait or = feature of HTTP. >>=20 >> Instead we=92ve made security recommendations which are the = appropriate response to this issue. Further we published 6819 that = provides further guidance. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt = wrote: >>=20 >>> fine, you're talking security considerations about untrusted = clients; that's a different use case than the protocol flaw reason why = Google would not do rfc6749 as written >>>=20 >>> Hans. >>>=20 >>> On 9/3/14, 7:52 PM, John Bradley wrote: >>>> I agree that the error case where there is no UI is the problem, as = it can be used inside a Iframe. >>>>=20 >>>> However error responses are generally useful. >>>>=20 >>>> OAuth core is silent on how redirect_uri are registered and if they = are verified. >>>>=20 >>>> Dynamic registration should warn about OAuth errors to redirect_uri = from untrusted clients. >>>>=20 >>>> For other registration methods we should update the RFC. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso = wrote: >>>>>=20 >>>>>=20 >>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt = wrote: >>>>>>=20 >>>>>> Is your concern clients that were registered using dynamic client = registration? >>>>>=20 >>>>> yes >>>>>=20 >>>>>>=20 >>>>>> Otherwise the positive case is returning a response to a valid = URL that belongs to a client that was registered explicitly by the = resource owner >>>>>=20 >>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>=20 >>>>>=20 >>>>>> and the negative case is returning an error to that same URL. >>>>>=20 >>>>> the difference is the consent screen=85 in the positive case you = need to approve an app.. for the error case no approval is needed,,, >>>>>=20 >>>>>>=20 >>>>>> I fail to see the open redirect. >>>>>=20 >>>>> why? >>>>>=20 >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>=20 >>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt = >>>>>> > wrote: >>>>>>>=20 >>>>>>>> Let me try and approach this from a different angle: why would = you >>>>>>>> call it an open redirect when an invalid scope is provided and = call it >>>>>>>> correct protocol behavior (hopefully) when a valid scope is = provided? >>>>>>>=20 >>>>>>> as specified below in the positive case (namely when the correct = scope >>>>>>> is provided) the resource owner MUST approve the app via the = consent >>>>>>> screen (at least once). >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hans. >>>>>>>>=20 >>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>> hi John, >>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>=20 >>>>>>>>>> The issue is that the AS may be allowing client registrations = with >>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>=20 >>>>>>>>>> In the spec it is unspecified how a AS validates that a = client >>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>=20 >>>>>>>>>> I think that if anything it may be the registration step that = needs >>>>>>>>>> the security consideration. >>>>>>>>>=20 >>>>>>>>> (this is the first time :p) but I do disagree with you. It = would be >>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>> IMHO the best approach is the one taken from Google, namely = returning >>>>>>>>> 400 with the cause of the error.. >>>>>>>>>=20 >>>>>>>>> *400.* That=92s an error. >>>>>>>>>=20 >>>>>>>>> *Error: invalid_scope* >>>>>>>>>=20 >>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>=20 >>>>>>>>> said that I hope you all agree this is an issue in the spec so = far=85. >>>>>>>>>=20 >>>>>>>>> regards >>>>>>>>>=20 >>>>>>>>> antonio >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> John B. >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> I don't understand. The redirect uri has to be valid in = order for a >>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>=20 >>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>> hi *, >>>>>>>>>>>>=20 >>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable = to open >>>>>>>>>>>> redirect. >>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>=20 >>>>>>>>>>>> If the request fails due to a missing, invalid, or = mismatching >>>>>>>>>>>> redirection URI, or if the client identifier is missing or = invalid, >>>>>>>>>>>> the authorization server SHOULD inform the resource owner = of the >>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to = the >>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>=20 >>>>>>>>>>>> If the resource owner denies the access request or if the = request >>>>>>>>>>>> fails for reasons other than a missing or invalid = redirection URI, >>>>>>>>>>>> the authorization server informs the client by adding the = following >>>>>>>>>>>> parameters to the query component of the redirection URI = using the >>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>> : >>>>>>>>>>>>=20 >>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> provider. >>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>> > >>>>>>>>>>>> >. >>>>>>>>>>>>=20 >>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am = redirected >>>>>>>>>>>> back to >>>>>>>>>>>> attacker.com >>>>>>>>>>> > >. >>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>=20 >>>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>>=20 >>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>> Of course in the positive case if all the parameters are = fine this >>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the = app via the >>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>=20 >>>>>>>>>>>> A solution would be to return error 400 rather than = redirect to the >>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>=20 >>>>>>>>>>>> WDYT? >>>>>>>>>>>>=20 >>>>>>>>>>>> regards >>>>>>>>>>>>=20 >>>>>>>>>>>> antonio >>>>>>>>>>>>=20 >>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Bill Burke >>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>=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 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | = Ping >>>>>>>> Identity >>>>>>=20 >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>=20 >>>=20 >>> --=20 >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From nobody Wed Sep 3 12:49:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9C11A6F91 for ; Wed, 3 Sep 2014 12:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 u6cmKCuCwl_k for ; Wed, 3 Sep 2014 12:49:24 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360D81A6F98 for ; Wed, 3 Sep 2014 12:49:10 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s83Jn5Cr021491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Sep 2014 19:49:06 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83Jn402024551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2014 19:49:05 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s83Jn4pu012044; Wed, 3 Sep 2014 19:49:04 GMT Received: from [192.168.1.197] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Sep 2014 12:49:04 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <41169177-EDF1-4577-8860-B0DE2CDF5C0C@oracle.com> Date: Wed, 3 Sep 2014 12:49:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> <5407611D.6090405@pingidentity.com> <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> <7320F0A5-86FA-42CB-8C6D-00EBDDF1A48C@adobe.com> <41169177-EDF1-4577-8860-B0DE2CDF5C0C@oracle.com> To: Antonio Sanso X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tQgNjio9SLYIopWD3GjYOIROkVE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:49:34 -0000 ooops,, that 6819 not 6810 Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 3, 2014, at 12:47 PM, Phil Hunt wrote: > in RFC6810, see section 3.5 and 4.1.5.=20 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Sep 3, 2014, at 12:36 PM, Antonio Sanso wrote: >=20 >> hi Phil, >> can you point out the relative paragraph that covers this specific = case in RFC6819? >> On Sep 3, 2014, at 9:23 PM, Phil Hunt wrote: >>=20 >>> I do not believe this is a flaw specific to 6749. The flaw if any is = within HTTP itself (RFC7230). Covert redirect is a well known problem. = There are extensive recommendations that prevent this covered in 6749 = and 6819. >>>=20 >>> There is no protocol fix that OAuth can make since it is a trait or = feature of HTTP. >>>=20 >>> Instead we=92ve made security recommendations which are the = appropriate response to this issue. Further we published 6819 that = provides further guidance. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt = wrote: >>>=20 >>>> fine, you're talking security considerations about untrusted = clients; that's a different use case than the protocol flaw reason why = Google would not do rfc6749 as written >>>>=20 >>>> Hans. >>>>=20 >>>> On 9/3/14, 7:52 PM, John Bradley wrote: >>>>> I agree that the error case where there is no UI is the problem, = as it can be used inside a Iframe. >>>>>=20 >>>>> However error responses are generally useful. >>>>>=20 >>>>> OAuth core is silent on how redirect_uri are registered and if = they are verified. >>>>>=20 >>>>> Dynamic registration should warn about OAuth errors to = redirect_uri from untrusted clients. >>>>>=20 >>>>> For other registration methods we should update the RFC. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso = wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt = wrote: >>>>>>>=20 >>>>>>> Is your concern clients that were registered using dynamic = client registration? >>>>>>=20 >>>>>> yes >>>>>>=20 >>>>>>>=20 >>>>>>> Otherwise the positive case is returning a response to a valid = URL that belongs to a client that was registered explicitly by the = resource owner >>>>>>=20 >>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>=20 >>>>>>=20 >>>>>>> and the negative case is returning an error to that same URL. >>>>>>=20 >>>>>> the difference is the consent screen=85 in the positive case you = need to approve an app.. for the error case no approval is needed,,, >>>>>>=20 >>>>>>>=20 >>>>>>> I fail to see the open redirect. >>>>>>=20 >>>>>> why? >>>>>>=20 >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt = >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> Let me try and approach this from a different angle: why would = you >>>>>>>>> call it an open redirect when an invalid scope is provided and = call it >>>>>>>>> correct protocol behavior (hopefully) when a valid scope is = provided? >>>>>>>>=20 >>>>>>>> as specified below in the positive case (namely when the = correct scope >>>>>>>> is provided) the resource owner MUST approve the app via the = consent >>>>>>>> screen (at least once). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>> hi John, >>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>=20 >>>>>>>>>>> The issue is that the AS may be allowing client = registrations with >>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>=20 >>>>>>>>>>> In the spec it is unspecified how a AS validates that a = client >>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>=20 >>>>>>>>>>> I think that if anything it may be the registration step = that needs >>>>>>>>>>> the security consideration. >>>>>>>>>>=20 >>>>>>>>>> (this is the first time :p) but I do disagree with you. It = would be >>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>> IMHO the best approach is the one taken from Google, namely = returning >>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>=20 >>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>=20 >>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>=20 >>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>=20 >>>>>>>>>> said that I hope you all agree this is an issue in the spec = so far=85. >>>>>>>>>>=20 >>>>>>>>>> regards >>>>>>>>>>=20 >>>>>>>>>> antonio >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> John B. >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I don't understand. The redirect uri has to be valid in = order for a >>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>> hi *, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable = to open >>>>>>>>>>>>> redirect. >>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If the request fails due to a missing, invalid, or = mismatching >>>>>>>>>>>>> redirection URI, or if the client identifier is missing or = invalid, >>>>>>>>>>>>> the authorization server SHOULD inform the resource owner = of the >>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent = to the >>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If the resource owner denies the access request or if the = request >>>>>>>>>>>>> fails for reasons other than a missing or invalid = redirection URI, >>>>>>>>>>>>> the authorization server informs the client by adding the = following >>>>>>>>>>>>> parameters to the query component of the redirection URI = using the >>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>> : >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> provider. >>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>> > >>>>>>>>>>>>> >. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am = redirected >>>>>>>>>>>>> back to >>>>>>>>>>>>> attacker.com >>>>>>>>>>>> > >. >>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>>>=20 >>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>> Of course in the positive case if all the parameters are = fine this >>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the = app via the >>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A solution would be to return error 400 rather than = redirect to the >>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> regards >>>>>>>>>>>>>=20 >>>>>>>>>>>>> antonio >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Bill Burke >>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>=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 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com = | Ping >>>>>>>>> Identity >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>=20 >>>>=20 >>>> --=20 >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping Identity >>>>=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 From nobody Wed Sep 3 12:52:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862931A6F92 for ; Wed, 3 Sep 2014 12:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 sKokrn87LEtP for ; Wed, 3 Sep 2014 12:52:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6241A6EFC for ; Wed, 3 Sep 2014 12:52:42 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 19:52:40 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 19:52:40 +0000 From: Antonio Sanso To: Takahiko Kawasaki Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAKq4CAAA4HgIAAC3mAgAACrYCAAAVpgA== Date: Wed, 3 Sep 2014 19:52:40 +0000 Message-ID: <1ADACEBA-AF95-42B3-A2C2-687AA7CDD193@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> <5407611D.6090405@pingidentity.com> <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> In-Reply-To: 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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(377424004)(51444003)(51704005)(189002)(479174003)(377454003)(199003)(46102001)(101416001)(74662001)(99286002)(19617315012)(87936001)(81342001)(93886004)(110136001)(90102001)(76482001)(19580405001)(74502001)(105586002)(106116001)(106356001)(92566001)(54356999)(14971765001)(86362001)(64706001)(107046002)(20776003)(95666004)(85306004)(81542001)(16601075003)(16236675004)(2656002)(50986999)(83716003)(99396002)(82746002)(4396001)(15202345003)(92726001)(19580395003)(15975445006)(77096002)(76176999)(85852003)(15395725005)(21056001)(80022001)(83072002)(83322001)(31966008)(33656002)(79102001)(77982001)(66066001)(587094003)(36756003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_1ADACEBAAF9542B3A2C2687AA7CDD193adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gYg-qu1sytrNdlzAxmsNF28vM8c Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:52:45 -0000 --_000_1ADACEBAAF9542B3A2C2687AA7CDD193adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable hi Takahiko On Sep 3, 2014, at 9:33 PM, Takahiko Kawasaki > wrote: I think the point is that the registered redirect URI is evil, meaning that= the person who registered the client application is evil. I don't think th= e spec can take any countermeasure against this case. If the registered redirect URI is evil, the issue happens even in the case = where the scope is valid and consent from the end-user has been obtained. well in this case the consent screen is there =85. in the case I pointed ou= t the redirect happens automatically That is, an attacker would prepare an HTML page at http://attacker.com which says "Sorry, an error occurred. Please re-authorize= this application." and has a login form that mimics the login form of vict= im.com. IMHO, all we can do is to educate people like "Be cautious when you are req= uested to login again.=94 this is another case different from a normal open redirect IMHO Best Regards, Takahiko Kawasaki 2014-09-04 4:23 GMT+09:00 Phil Hunt >: I do not believe this is a flaw specific to 6749. The flaw if any is within= HTTP itself (RFC7230). Covert redirect is a well known problem. There are = extensive recommendations that prevent this covered in 6749 and 6819. There is no protocol fix that OAuth can make since it is a trait or feature= of HTTP. Instead we=92ve made security recommendations which are the appropriate res= ponse to this issue. Further we published 6819 that provides further guidan= ce. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 3, 2014, at 11:42 AM, Hans Zandbelt > wrote: > fine, you're talking security considerations about untrusted clients; tha= t's a different use case than the protocol flaw reason why Google would not= do rfc6749 as written > > Hans. > > On 9/3/14, 7:52 PM, John Bradley wrote: >> I agree that the error case where there is no UI is the problem, as it c= an be used inside a Iframe. >> >> However error responses are generally useful. >> >> OAuth core is silent on how redirect_uri are registered and if they are = verified. >> >> Dynamic registration should warn about OAuth errors to redirect_uri from= untrusted clients. >> >> For other registration methods we should update the RFC. >> >> John B. >> >> >> >> >> Sent from my iPhone >> >>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso > wrote: >>> >>> >>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt > wrote: >>>> >>>> Is your concern clients that were registered using dynamic client regi= stration? >>> >>> yes >>> >>>> >>>> Otherwise the positive case is returning a response to a valid URL tha= t belongs to a client that was registered explicitly by the resource owner >>> >>> well AFAIK the resource owner doesn=92t register clients=85 >>> >>> >>>> and the negative case is returning an error to that same URL. >>> >>> the difference is the consent screen=85 in the positive case you need t= o approve an app.. for the error case no approval is needed,,, >>> >>>> >>>> I fail to see the open redirect. >>> >>> why? >>> >>>> >>>> Hans. >>>> >>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>> >>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>> = >> wrote: >>>>> >>>>>> Let me try and approach this from a different angle: why would you >>>>>> call it an open redirect when an invalid scope is provided and call = it >>>>>> correct protocol behavior (hopefully) when a valid scope is provided= ? >>>>> >>>>> as specified below in the positive case (namely when the correct scop= e >>>>> is provided) the resource owner MUST approve the app via the consent >>>>> screen (at least once). >>>>> >>>>> >>>>>> >>>>>> Hans. >>>>>> >>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>> hi John, >>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>> > >>>>>>> >> wrote: >>>>>>> >>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>> >>>>>>>> The issue is that the AS may be allowing client registrations with >>>>>>>> arbitrary redirect_uri. >>>>>>>> >>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>> controls the redirect_uri it is registering. >>>>>>>> >>>>>>>> I think that if anything it may be the registration step that need= s >>>>>>>> the security consideration. >>>>>>> >>>>>>> (this is the first time :p) but I do disagree with you. It would be >>>>>>> pretty unpractical to block this at registration time=85. >>>>>>> IMHO the best approach is the one taken from Google, namely returni= ng >>>>>>> 400 with the cause of the error.. >>>>>>> >>>>>>> *400.* That=92s an error. >>>>>>> >>>>>>> *Error: invalid_scope* >>>>>>> >>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>> >>>>>>> said that I hope you all agree this is an issue in the spec so far= =85. >>>>>>> >>>>>>> regards >>>>>>> >>>>>>> antonio >>>>>>> >>>>>>>> >>>>>>>> John B. >>>>>>>> >>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>> > >>>>>>>> >> wrote: >>>>>>>> >>>>>>>>> I don't understand. The redirect uri has to be valid in order fo= r a >>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>> >>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>> hi *, >>>>>>>>>> >>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to op= en >>>>>>>>>> redirect. >>>>>>>>>> Let me explain, reading [0] >>>>>>>>>> >>>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>>> redirection URI, or if the client identifier is missing or inval= id, >>>>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>>> invalid redirection URI. >>>>>>>>>> >>>>>>>>>> If the resource owner denies the access request or if the reques= t >>>>>>>>>> fails for reasons other than a missing or invalid redirection UR= I, >>>>>>>>>> the authorization server informs the client by adding the follow= ing >>>>>>>>>> parameters to the query component of the redirection URI using t= he >>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> Now let=92s assume this. >>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> provider. >>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>> = > >>>>>>>>>> >. >>>>>>>>>> >>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>>> back to >>>>>>>>>> attacker.com >>>>>>>>>> > >. >>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>> >>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc8= 8FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://att= acker.com >>>>>>>>>> >>>>>>>>>> and this is works as an open redirector. >>>>>>>>>> Of course in the positive case if all the parameters are fine th= is >>>>>>>>>> doesn=92t apply since the resource owner MUST approve the app vi= a the >>>>>>>>>> consent screen (at least once). >>>>>>>>>> >>>>>>>>>> A solution would be to return error 400 rather than redirect to = the >>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>> >>>>>>>>>> WDYT? >>>>>>>>>> >>>>>>>>>> regards >>>>>>>>>> >>>>>>>>>> antonio >>>>>>>>>> >>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Bill Burke >>>>>>>>> JBoss, a division of Red Hat >>>>>>>>> http://bill.burkecentral.com >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com >| Ping >>>>>> Identity >>>> >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping I= dentity >>> > > -- > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Iden= tity > > _______________________________________________ > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_1ADACEBAAF9542B3A2C2687AA7CDD193adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable hi Takahiko

On Sep 3, 2014, at 9:33 PM, Takahiko Kawasaki <daru.tk@gmail.com> wrote:

I think the point is that the registered redirect URI is e= vil, meaning that the person who registered the client application is evil.= I don't think the spec can take any countermeasure against this case.

If the registered redirect URI is evil, the issue happens even in the case = where the scope is valid and consent from the end-user has been obtained.

well in this case the consent screen is there =85. in the case I point= ed out the redirect happens automatically

That is, an attacker would prepare an HTML page at http://attacker.com which says "Sorry, an error occurred. Please r= e-authorize this application." and has a login form that mimics the lo= gin form of victim.com.

IMHO, all we can do is to educate people like "Be cautious when you ar= e requested to login again.=94

this is another case different from a normal open redirect IMHO


Best Regards,
Takahiko Kawasaki


2014-09-04 4:23 GMT+09:00 Phil Hunt <phi= l.hunt@oracle.com>:
I do not believe this is a flaw specific to 6749. The flaw if any is within= HTTP itself (RFC7230). Covert redirect is a well known problem. There are = extensive recommendations that prevent this covered in 6749 and 6819.

There is no protocol fix that OAuth can make since it is a trait or feature= of HTTP.

Instead we=92ve made security recommendations which are the appropriate res= ponse to this issue. Further we published 6819 that provides further guidan= ce.

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.com



On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

> fine, you're talking security considerations about untrusted clients; = that's a different use case than the protocol flaw reason why Google would = not do rfc6749 as written
>
> Hans.
>
> On 9/3/14, 7:52 PM, John Bradley wrote:
>> I agree that the error case where there is no UI is the problem, a= s it can be used inside a Iframe.
>>
>> However error responses are generally useful.
>>
>> OAuth core is silent on how redirect_uri are registered and if the= y are verified.
>>
>> Dynamic registration should warn about OAuth errors to redirect_ur= i from untrusted clients.
>>
>> For other registration methods we should update the RFC.
>>
>> John B.
>>
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso <asanso@adobe.com> wrote:
>>>
>>>
>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:=
>>>>
>>>> Is your concern clients that were registered using dynamic= client registration?
>>>
>>> yes
>>>
>>>>
>>>> Otherwise the positive case is returning a response to a v= alid URL that belongs to a client that was registered explicitly by the res= ource owner
>>>
>>> well AFAIK the resource owner doesn=92t register clients=85 >>>
>>>
>>>> and the negative case is returning an error to that same U= RL.
>>>
>>> the difference is the consent screen=85 in the positive case y= ou need to approve an app.. for the error case no approval is needed,,,
>>>
>>>>
>>>> I fail to see the open redirect.
>>>
>>> why?
>>>
>>>>
>>>> Hans.
>>>>
>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>>>>>
>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <hzandbelt@pingidentity.com
>>>>> <mailto:hzandbelt@pingidentity.com>> wrote:
>>>>>
>>>>>> Let me try and approach this from a different angl= e: why would you
>>>>>> call it an open redirect when an invalid scope is = provided and call it
>>>>>> correct protocol behavior (hopefully) when a valid= scope is provided?
>>>>>
>>>>> as specified below in the positive case (namely when t= he correct scope
>>>>> is provided) the resource owner MUST approve the app v= ia the consent
>>>>> screen (at least once).
>>>>>
>>>>>
>>>>>>
>>>>>> Hans.
>>>>>>
>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>>>>>>> hi John,
>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley <<= a href=3D"mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com
>>>>>>> <mailto:ve7jtb@ve7jtb.com>
>>>>>>> <mailto:ve7jtb@ve7jtb.com>> wrote:
>>>>>>>
>>>>>>>> In the example the redirect_uri is vlid fo= r the attacker.
>>>>>>>>
>>>>>>>> The issue is that the AS may be allowing c= lient registrations with
>>>>>>>> arbitrary redirect_uri.
>>>>>>>>
>>>>>>>> In the spec it is unspecified how a AS val= idates that a client
>>>>>>>> controls the redirect_uri it is registerin= g.
>>>>>>>>
>>>>>>>> I think that if anything it may be the reg= istration step that needs
>>>>>>>> the security consideration.
>>>>>>>
>>>>>>> (this is the first time :p) but I do disagree = with you. It would be
>>>>>>> pretty unpractical to block this at registrati= on time=85.
>>>>>>> IMHO the best approach is the one taken from G= oogle, namely returning
>>>>>>> 400 with the cause of the error..
>>>>>>>
>>>>>>> *400.* That=92s an error.
>>>>>>>
>>>>>>> *Error: invalid_scope*
>>>>>>>
>>>>>>> Some requested scopes were invalid. {invalid= =3D[l]}
>>>>>>>
>>>>>>> said that I hope you all agree this is an issu= e in the spec so far=85.
>>>>>>>
>>>>>>> regards
>>>>>>>
>>>>>>> antonio
>>>>>>>
>>>>>>>>
>>>>>>>> John B.
>>>>>>>>
>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke &l= t;bburke@redhat.com
>>>>>>>> <mailto:bburke@redhat.com>
>>>>>>>> <mailto:bburke@redhat.com>> wrote:
>>>>>>>>
>>>>>>>>> I don't understand.  The redirect= uri has to be valid in order for a
>>>>>>>>> redirect to happen.  The spec exp= licitly states this.
>>>>>>>>>
>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sans= o wrote:
>>>>>>>>>> hi *,
>>>>>>>>>>
>>>>>>>>>> IMHO providers that strictly follo= w rfc6749 are vulnerable to open
>>>>>>>>>> redirect.
>>>>>>>>>> Let me explain, reading [0]
>>>>>>>>>>
>>>>>>>>>> If the request fails due to a miss= ing, invalid, or mismatching
>>>>>>>>>> redirection URI, or if the client = identifier is missing or invalid,
>>>>>>>>>> the authorization server SHOULD in= form the resource owner of the
>>>>>>>>>> error and MUST NOT automatically r= edirect the user-agent to the
>>>>>>>>>> invalid redirection URI.
>>>>>>>>>>
>>>>>>>>>> If the resource owner denies the a= ccess request or if the request
>>>>>>>>>> fails for reasons other than a mis= sing or invalid redirection URI,
>>>>>>>>>> the authorization server informs t= he client by adding the following
>>>>>>>>>> parameters to the query component = of the redirection URI using the
>>>>>>>>>> "application/x-www-form-urlen= coded" format, perAppendix B
>>>>>>>>>> <https://tools.ietf.org/html/= rfc6749#appendix-B>:
>>>>>>>>>>
>>>>>>>>>> Now let=92s assume this.
>>>>>>>>>> I am registering a new client to <= a href=3D"http://thevictim.com/" target=3D"_blank"> thevictim.com
>>>>>>>>>> <http://victim.com/><http://victim.com <http://victim.com/>>
>>>>>>>>>> <http://victim.com <http://victim.com/>>
>>>>>>>>>> provider.
>>>>>>>>>> I register redirect uriattacker.com
>>>>>>>>>> <http://attacker.com/><http://attacker.com <http://attacker.com/>>
>>>>>>>>>> <http://attacker.com <http://attacker.com/>>.
>>>>>>>>>>
>>>>>>>>>> According to [0] if I pass e.g. th= e wrong scope I am redirected
>>>>>>>>>> back to
>>>>>>>>>> attacker.com <http://attacker.com/><http://attacker.com
>>>>>>>>>> <http://attacker.com/>> <http://attacker.com <http://attacker.com/>>.
>>>>>>>>>> Namely I prepare a url that is in = this form:
>>>>>>>>>>
>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX12= 98KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://at= tacker.com
>>>>>>>>>>
>>>>>>>>>> and this is works as an open redir= ector.
>>>>>>>>>> Of course in the positive case if = all the parameters are fine this
>>>>>>>>>> doesn=92t apply since the resource= owner MUST approve the app via the
>>>>>>>>>> consent screen (at least once). >>>>>>>>>>
>>>>>>>>>> A solution would be to return erro= r 400 rather than redirect to the
>>>>>>>>>> redirect URI (as some provider e.g= . Google do)
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>>
>>>>>>>>>> regards
>>>>>>>>>>
>>>>>>>>>> antonio
>>>>>>>>>>
>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> __________________________________= _____________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> = OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAut= h@ietf.org <mailto:OAuth@ietf.org<= /a>>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ie= tf.org <mailto:OAuth@ietf.org&= gt;<mailto:OAuth@ietf.org>
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth=
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.o= rg <mailto:OAuth@ietf.org><= br> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth=
>>>>>>
>>>>>> --
>>>>>> Hans Zandbelt          &n= bsp;   | Sr. Technical Architect
>>>>>> hzan= dbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com>| Ping
>>>>>> Identity
>>>>
>>>> --
>>>> Hans Zandbelt            &nb= sp; | Sr. Technical Architect
>>>> hzandbelt@pi= ngidentity.com | Ping Identity
>>>
>
> --
> Hans Zandbelt              | Sr. Te= chnical Architect
> hzandbelt@pingidentity.c= om | Ping Identity
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
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/oauth

--_000_1ADACEBAAF9542B3A2C2687AA7CDD193adobecom_-- From nobody Wed Sep 3 12:59:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030C21A6F01 for ; Wed, 3 Sep 2014 12:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 FJETJDlPTWBq for ; Wed, 3 Sep 2014 12:59:00 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3640A1A6EE9 for ; Wed, 3 Sep 2014 12:59:00 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Wed, 3 Sep 2014 19:58:58 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 19:58:58 +0000 From: Antonio Sanso To: Phil Hunt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAKq4CAAA4HgIAAC3mAgAADpYCAAAMiAIAAAE8AgAACwIA= Date: Wed, 3 Sep 2014 19:58:58 +0000 Message-ID: <6D7EE84E-26A1-4567-A68C-704269161DC5@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> <5407611D.6090405@pingidentity.com> <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> <7320F0A5-86FA-42CB-8C6D-00EBDDF1A48C@adobe.com> <41169177-EDF1-4577-8860-B0DE2CDF5C0C@oracle.com> In-Reply-To: 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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(24454002)(189002)(51704005)(51444003)(479174003)(377454003)(46102001)(107046002)(106116001)(15974865002)(19580395003)(83716003)(15202345003)(90102001)(74502001)(77982001)(105586002)(36756003)(79102001)(2656002)(21056001)(4396001)(93886004)(83322001)(85852003)(16601075003)(587094003)(15395725005)(19580405001)(87936001)(76482001)(101416001)(99286002)(64706001)(50986999)(82746002)(76176999)(20776003)(80022001)(81342001)(92566001)(92726001)(86362001)(81542001)(33656002)(31966008)(83072002)(106356001)(74662001)(77096002)(15975445006)(85306004)(54356999)(99396002)(95666004)(110136001)(66066001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/khjk1iIAnB99GWCeK9pEMCZIp3w Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:59:02 -0000 thanks Phil for pointing the sections out but reading them I still think th= e case I brought up is still a different one :) On Sep 3, 2014, at 9:49 PM, Phil Hunt wrote: > ooops,, that 6819 not 6810 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Sep 3, 2014, at 12:47 PM, Phil Hunt wrote: >=20 >> in RFC6810, see section 3.5 and 4.1.5.=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Sep 3, 2014, at 12:36 PM, Antonio Sanso wrote: >>=20 >>> hi Phil, >>> can you point out the relative paragraph that covers this specific case= in RFC6819? >>> On Sep 3, 2014, at 9:23 PM, Phil Hunt wrote: >>>=20 >>>> I do not believe this is a flaw specific to 6749. The flaw if any is w= ithin HTTP itself (RFC7230). Covert redirect is a well known problem. There= are extensive recommendations that prevent this covered in 6749 and 6819. >>>>=20 >>>> There is no protocol fix that OAuth can make since it is a trait or fe= ature of HTTP. >>>>=20 >>>> Instead we=92ve made security recommendations which are the appropriat= e response to this issue. Further we published 6819 that provides further g= uidance. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt wrote: >>>>=20 >>>>> fine, you're talking security considerations about untrusted clients;= that's a different use case than the protocol flaw reason why Google would= not do rfc6749 as written >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> On 9/3/14, 7:52 PM, John Bradley wrote: >>>>>> I agree that the error case where there is no UI is the problem, as = it can be used inside a Iframe. >>>>>>=20 >>>>>> However error responses are generally useful. >>>>>>=20 >>>>>> OAuth core is silent on how redirect_uri are registered and if they = are verified. >>>>>>=20 >>>>>> Dynamic registration should warn about OAuth errors to redirect_uri = from untrusted clients. >>>>>>=20 >>>>>> For other registration methods we should update the RFC. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt wrote: >>>>>>>>=20 >>>>>>>> Is your concern clients that were registered using dynamic client = registration? >>>>>>>=20 >>>>>>> yes >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Otherwise the positive case is returning a response to a valid URL= that belongs to a client that was registered explicitly by the resource ow= ner >>>>>>>=20 >>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>=20 >>>>>>>=20 >>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>=20 >>>>>>> the difference is the consent screen=85 in the positive case you ne= ed to approve an app.. for the error case no approval is needed,,, >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I fail to see the open redirect. >>>>>>>=20 >>>>>>> why? >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hans. >>>>>>>>=20 >>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> Let me try and approach this from a different angle: why would y= ou >>>>>>>>>> call it an open redirect when an invalid scope is provided and c= all it >>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is prov= ided? >>>>>>>>>=20 >>>>>>>>> as specified below in the positive case (namely when the correct = scope >>>>>>>>> is provided) the resource owner MUST approve the app via the cons= ent >>>>>>>>> screen (at least once). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hans. >>>>>>>>>>=20 >>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>> hi John, >>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>=20 >>>>>>>>>>>> The issue is that the AS may be allowing client registrations = with >>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>=20 >>>>>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think that if anything it may be the registration step that = needs >>>>>>>>>>>> the security consideration. >>>>>>>>>>>=20 >>>>>>>>>>> (this is the first time :p) but I do disagree with you. It woul= d be >>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>> IMHO the best approach is the one taken from Google, namely ret= urning >>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>=20 >>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>=20 >>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>=20 >>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>=20 >>>>>>>>>>> said that I hope you all agree this is an issue in the spec so = far=85. >>>>>>>>>>>=20 >>>>>>>>>>> regards >>>>>>>>>>>=20 >>>>>>>>>>> antonio >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> John B. >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in orde= r for a >>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable t= o open >>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatchi= ng >>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or i= nvalid, >>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner of= the >>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to = the >>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> If the resource owner denies the access request or if the re= quest >>>>>>>>>>>>>> fails for reasons other than a missing or invalid redirectio= n URI, >>>>>>>>>>>>>> the authorization server informs the client by adding the fo= llowing >>>>>>>>>>>>>> parameters to the query component of the redirection URI usi= ng the >>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>> : >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> provider. >>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirec= ted >>>>>>>>>>>>>> back to >>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>> > >. >>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id= =3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp= ://attacker.com >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>> Of course in the positive case if all the parameters are fin= e this >>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the ap= p via the >>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A solution would be to return error 400 rather than redirect= to the >>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> regards >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>=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 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com | = Ping >>>>>>>>>> Identity >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>=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 From nobody Wed Sep 3 22:26:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64921A063F for ; Wed, 3 Sep 2014 22:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 5TZLGXsTJcZN for ; Wed, 3 Sep 2014 22:26:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AEA11A0601 for ; Wed, 3 Sep 2014 22:26:07 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 4 Sep 2014 05:26:04 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.144]) with mapi id 15.00.1015.018; Thu, 4 Sep 2014 05:26:04 +0000 From: Antonio Sanso To: Hans Zandbelt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0A Date: Thu, 4 Sep 2014 05:26:03 +0000 Message-ID: <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> In-Reply-To: <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(479174003)(377454003)(199003)(46102001)(87936001)(19617315012)(101416001)(74662001)(99286002)(81342001)(76482001)(90102001)(93886004)(110136001)(74502001)(19580405001)(105586002)(106116001)(95666004)(92566001)(106356001)(20776003)(107046002)(81542001)(64706001)(54356999)(16601075003)(16236675004)(86362001)(85306004)(50986999)(83716003)(99396002)(82746002)(4396001)(15202345003)(19580395003)(92726001)(77096002)(15975445006)(76176999)(85852003)(15395725005)(21056001)(80022001)(83072002)(31966008)(33656002)(83322001)(2656002)(587094003)(79102001)(66066001)(77982001)(36756003)(104396001)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_05C25C09598C4D7FA07AC93DEC17D10Badobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YIDBnkWdBEkib0nohrQUUpzbIHI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 05:26:10 -0000 --_000_05C25C09598C4D7FA07AC93DEC17D10Badobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable hi again *, after thinking a bit further IMHO an alternative for the untrusted clients = can also be to always present the consent screen (at least once) before any= redirect. Namely all providers I have seen show the consent screen if all the request= parameters are correct and if the user accepts the redirect happens. If one of the parameter (with the exclusion of the client id and redirect = uri that are handled differently as for spec) is wrong though the redirect = happens without the consent screen being shown.. WDYT? regards antonio On Sep 3, 2014, at 7:54 PM, Antonio Sanso > wrote: Well, I do not know if this is only dynamic registration... let=92s talk about real use cases, namely e.g. Google , Facebook , etc.. is= that dynamic client registration? I do not know=85 :) Said that what the other guys think? :) Would this deserve some =93spec adjustment=94 ? I mean there is a reason if= Google is by choice =93violating=94 the spec right? (I assume to avoid ope= n redirect=85) But other implementers do follow the spec hence they have this open redirec= tor=85 and this is not nice IMHO... On Sep 3, 2014, at 7:40 PM, Hans Zandbelt > wrote: On 9/3/14, 7:14 PM, Antonio Sanso wrote: On Sep 3, 2014, at 7:10 PM, Hans Zandbelt > wrote: Is your concern clients that were registered using dynamic client registrat= ion? yes I think your issue is then with the trust model of dynamic client registrat= ion; that is left out of scope of the dynreg spec (and the concept is not e= ven part of the core spec), but unless you want everything to be open (whic= h typically would not be the case), then it would involve approval somewher= e in the process before the client is registered. Without dynamic client re= gistration that approval is admin based or resource owner based, depending = on use case. Otherwise the positive case is returning a response to a valid URL that bel= ongs to a client that was registered explicitly by the resource owner well AFAIK the resource owner doesn=92t register clients=85 roles can collapse in use cases especially when using dynamic client regist= ration and the negative case is returning an error to that same URL. the difference is the consent screen=85 in the positive case you need to ap= prove an app.. for the error case no approval is needed,,, I fail to see the open redirect. why? because the client and thus the fixed URL are explicitly approved at some p= oint Hans. Hans. On 9/3/14, 6:56 PM, Antonio Sanso wrote: On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > wrote: Let me try and approach this from a different angle: why would you call it an open redirect when an invalid scope is provided and call it correct protocol behavior (hopefully) when a valid scope is provided? as specified below in the positive case (namely when the correct scope is provided) the resource owner MUST approve the app via the consent screen (at least once). Hans. On 9/3/14, 6:46 PM, Antonio Sanso wrote: hi John, On Sep 3, 2014, at 6:14 PM, John Bradley > wrote: In the example the redirect_uri is vlid for the attacker. The issue is that the AS may be allowing client registrations with arbitrary redirect_uri. In the spec it is unspecified how a AS validates that a client controls the redirect_uri it is registering. I think that if anything it may be the registration step that needs the security consideration. (this is the first time :p) but I do disagree with you. It would be pretty unpractical to block this at registration time=85. IMHO the best approach is the one taken from Google, namely returning 400 with the cause of the error.. *400.* That=92s an error. *Error: invalid_scope* Some requested scopes were invalid. {invalid=3D[l]} said that I hope you all agree this is an issue in the spec so far=85. regards antonio John B. On Sep 3, 2014, at 12:10 PM, Bill Burke > wrote: I don't understand. The redirect uri has to be valid in order for a redirect to happen. The spec explicitly states this. On 9/3/2014 11:43 AM, Antonio Sanso wrote: hi *, IMHO providers that strictly follow rfc6749 are vulnerable to open redirect. Let me explain, reading [0] If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, perAppendix B : Now let=92s assume this. I am registering a new client to thevictim.com > > provider. I register redirect uriattacker.com > >. According to [0] if I pass e.g. the wrong scope I am redirected back to attacker.com > >. Namely I prepare a url that is in this form: http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com and this is works as an open redirector. Of course in the positive case if all the parameters are fine this doesn=92t apply since the resource owner MUST approve the app via the consent screen (at least once). A solution would be to return error 400 rather than redirect to the redirect URI (as some provider e.g. Google do) WDYT? regards antonio [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identi= ty -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identi= ty --_000_05C25C09598C4D7FA07AC93DEC17D10Badobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7BA6168ADA632F46AFF617CB575D664D@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable hi again *,

after thinking a bit further IMHO an alternative for the untrusted cli= ents can also be to always present the consent screen (at least once) befor= e any redirect.
Namely all providers I have seen show the consent screen if all the re= quest parameters are correct and if the user accepts the redirect happens.<= /div>
If one of the parameter  (with the exclusion of the client id and= redirect uri that are handled differently as for spec) is wrong though the= redirect happens without the consent screen being shown..

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso <asanso@adobe.com> wrote:

Well,
I do not know if this is only dynamic registration...
let=92s talk about real use cases, namely e.g. Google , Facebook , etc= .. is that dynamic client registration? I do not know=85 :)

Said that what the other guys think?  :) 
Would this deserve some =93spec adjustment=94 ? I mean there is a reas= on if Google is by choice =93violating=94 the spec right? (I assume to avoi= d open redirect=85)
But other implementers do follow the spec hence they have this open re= director=85 and this is not nice IMHO...


On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

On 9/3/14, 7:14 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

Is your concern clients that were registered usin= g dynamic client registration?

yes

I think your issue is then with the trust model of dynamic client registrat= ion; that is left out of scope of the dynreg spec (and the concept is not e= ven part of the core spec), but unless you want everything to be open (whic= h typically would not be the case), then it would involve approval somewhere in the process before the client = is registered. Without dynamic client registration that approval is admin b= ased or resource owner based, depending on use case.

Otherwise the positive case is returning a respon= se to a valid URL that belongs to a client that was registered explicitly b= y the resource owner

well AFAIK the resource owner doesn=92t register clients=85

roles can collapse in use cases especially when using dynamic client regist= ration

and the negative case is returning an error to th= at same URL.

the difference is the consent screen=85 in the positive case you need to ap= prove an app.. for the error case no approval is needed,,,


I fail to see the open redirect.

why?

because the client and thus the fixed URL are explicitly approved at some p= oint

Hans.



Hans.

On 9/3/14, 6:56 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <hzandbelt@pingidentity.com
<mailto:hzandbelt@pingiden= tity.com>> wrote:

Let me try and approach this from a different ang= le: why would you
call it an open redirect when an invalid scope is provided and call it
correct protocol behavior (hopefully) when a valid scope is provided?

as specified below in the positive case (namely when the correct scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com
<mailto:ve7jtb@ve7jtb.com> <mailto:ve7jtb@ve7jtb.com>&g= t; wrote:

In the example the redirect_uri is vlid for the a= ttacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time=85.
IMHO the best approach is the one taken from Google, namely returning
400 with the cause of the error..

*400.* That=92s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=3D[l]}

said that I hope you all agree this is an issue in the spec so far=85.

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com> <mailto:bburke@redhat.com>&g= t; wrote:

I don't understand.  The redirect uri has to= be valid in order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tool= s.ietf.org/html/rfc6749#appendix-B>:

Now let=92s assume this.
I am registering a new client to thevicti= m.com
<http://victim.com/><http://victim.com <http://victim.com/>>
<http://victim.com <http://victim.com/>>
provider.
I register redirect uriattacker.com=
<http://attacker.com/><http://attacker.com <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected
back to
attacker.com <http://attacker.com/><http://attacker.com
<http://attacker.com/>> <<= a href=3D"http://attacker.com/">http://attacker.com <http://attacker.com/>>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=3Dcode&a= mp;client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&= ;redirect_uri=3Dhttp://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn=92t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https:/= /tools.ietf.org/html/rfc6749#section-4.1.2.1


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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com<= br>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.or= g/mailman/listinfo/oauth

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



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


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com <mailto:hzandbelt@pingid= entity.com>| Ping
Identity


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


-- 
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


--_000_05C25C09598C4D7FA07AC93DEC17D10Badobecom_-- From nobody Wed Sep 3 22:57:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F4F1A0680 for ; Wed, 3 Sep 2014 22:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 gcHUASem_Unm for ; Wed, 3 Sep 2014 22:57:29 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C531A0697 for ; Wed, 3 Sep 2014 22:57:28 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gl10so10973322lab.24 for ; Wed, 03 Sep 2014 22:57:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=+hiE2LhozS54gADdYQ8GWlyQ0kwLXtrpbYk7GAO8bQs=; b=ln76hADd83Msr9oRNEGIhjB9oTwX5VvMUBz29RfHlsshrUE/+SsltfMUvjFL14vMH0 CCtTqjS75VxlsOakvE0Aes6F0vESIRiiLoiZa9xGlO9gGup0jsUDxnbnXlVSqJVdFIYn itgl9c9VeXZrH6YYz0A8a99EglhfCbzlS+8AadqLfxfee2EunK9qywkw0s4tvipGdElQ kk/XfvLW4kxB18KWp8+4HoD2c7Z2OwerhMFUUBRVL8Oq1Enjj0EVF7vqdXqK2TQn3DUj a73QRDcONwtRWK0oG9lgcMapLAHe0n3H9d7OthTkbXm5oRL86zus0u/HZxatHyeIlqyS oYMA== X-Gm-Message-State: ALoCoQkKsGi6s9/yEdE9fsH1RazDmeIrEXtCT7s3mYNA8+ynuIdCFV7XOVbPjHyDcKZwPyibTUjn X-Received: by 10.112.28.8 with SMTP id x8mr1975917lbg.104.1409810246885; Wed, 03 Sep 2014 22:57:26 -0700 (PDT) Received: from [192.168.49.148] (seabed-1-2-ci.cust.versatel.net. [87.213.30.114]) by mx.google.com with ESMTPSA id ld9sm1766172lac.24.2014.09.03.22.57.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 22:57:25 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C9A396E1-02F0-43C9-8C68-F1C2C8E76232"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> Date: Thu, 4 Sep 2014 01:57:04 -0400 Message-Id: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> To: Antonio Sanso X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/sHszR3sXymkHp3YR6vtcUmswNvQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 05:57:33 -0000 --Apple-Mail=_C9A396E1-02F0-43C9-8C68-F1C2C8E76232 Content-Type: multipart/alternative; boundary="Apple-Mail=_513BA612-099B-4FF1-B3A0-662EAEABB097" --Apple-Mail=_513BA612-099B-4FF1-B3A0-662EAEABB097 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think that is probably reasonable advice. =20 Presenting a dialog to the user also has the beneficial side effect of = removing the original referrer from being seen by the party hosting the = redirect_uri. =20 It is allowing dynamic parameters to be passed in the referrer that is = the largest security issue in my opinion. That is how the AS might be = used as a redirector to attack itself. John B. On Sep 4, 2014, at 1:26 AM, Antonio Sanso wrote: > hi again *, >=20 > after thinking a bit further IMHO an alternative for the untrusted = clients can also be to always present the consent screen (at least once) = before any redirect. > Namely all providers I have seen show the consent screen if all the = request parameters are correct and if the user accepts the redirect = happens. > If one of the parameter (with the exclusion of the client id and = redirect uri that are handled differently as for spec) is wrong though = the redirect happens without the consent screen being shown.. >=20 > WDYT? >=20 > regards >=20 > antonio >=20 > On Sep 3, 2014, at 7:54 PM, Antonio Sanso wrote: >=20 >> Well, >> I do not know if this is only dynamic registration... >> let=92s talk about real use cases, namely e.g. Google , Facebook , = etc.. is that dynamic client registration? I do not know=85 :) >>=20 >> Said that what the other guys think? :)=20 >> Would this deserve some =93spec adjustment=94 ? I mean there is a = reason if Google is by choice =93violating=94 the spec right? (I assume = to avoid open redirect=85) >> But other implementers do follow the spec hence they have this open = redirector=85 and this is not nice IMHO... >>=20 >>=20 >> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt = wrote: >>=20 >>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>=20 >>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt = wrote: >>>>=20 >>>>> Is your concern clients that were registered using dynamic client = registration? >>>>=20 >>>> yes >>>=20 >>> I think your issue is then with the trust model of dynamic client = registration; that is left out of scope of the dynreg spec (and the = concept is not even part of the core spec), but unless you want = everything to be open (which typically would not be the case), then it = would involve approval somewhere in the process before the client is = registered. Without dynamic client registration that approval is admin = based or resource owner based, depending on use case. >>>=20 >>>>> Otherwise the positive case is returning a response to a valid URL = that belongs to a client that was registered explicitly by the resource = owner >>>>=20 >>>> well AFAIK the resource owner doesn=92t register clients=85 >>>=20 >>> roles can collapse in use cases especially when using dynamic client = registration >>>=20 >>>>> and the negative case is returning an error to that same URL. >>>>=20 >>>> the difference is the consent screen=85 in the positive case you = need to approve an app.. for the error case no approval is needed,,, >>>>=20 >>>>>=20 >>>>> I fail to see the open redirect. >>>>=20 >>>> why? >>>=20 >>> because the client and thus the fixed URL are explicitly approved at = some point >>>=20 >>> Hans. >>>=20 >>>>=20 >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>=20 >>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt = >>>>> > wrote: >>>>>>=20 >>>>>>> Let me try and approach this from a different angle: why would = you >>>>>>> call it an open redirect when an invalid scope is provided and = call it >>>>>>> correct protocol behavior (hopefully) when a valid scope is = provided? >>>>>>=20 >>>>>> as specified below in the positive case (namely when the correct = scope >>>>>> is provided) the resource owner MUST approve the app via the = consent >>>>>> screen (at least once). >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>> hi John, >>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>> >>>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>=20 >>>>>>>>> The issue is that the AS may be allowing client registrations = with >>>>>>>>> arbitrary redirect_uri. >>>>>>>>>=20 >>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>=20 >>>>>>>>> I think that if anything it may be the registration step that = needs >>>>>>>>> the security consideration. >>>>>>>>=20 >>>>>>>> (this is the first time :p) but I do disagree with you. It = would be >>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>> IMHO the best approach is the one taken from Google, namely = returning >>>>>>>> 400 with the cause of the error.. >>>>>>>>=20 >>>>>>>> *400.* That=92s an error. >>>>>>>>=20 >>>>>>>> *Error: invalid_scope* >>>>>>>>=20 >>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>=20 >>>>>>>> said that I hope you all agree this is an issue in the spec so = far=85. >>>>>>>>=20 >>>>>>>> regards >>>>>>>>=20 >>>>>>>> antonio >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> I don't understand. The redirect uri has to be valid in = order for a >>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>=20 >>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>> hi *, >>>>>>>>>>>=20 >>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable = to open >>>>>>>>>>> redirect. >>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>=20 >>>>>>>>>>> If the request fails due to a missing, invalid, or = mismatching >>>>>>>>>>> redirection URI, or if the client identifier is missing or = invalid, >>>>>>>>>>> the authorization server SHOULD inform the resource owner of = the >>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to = the >>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>=20 >>>>>>>>>>> If the resource owner denies the access request or if the = request >>>>>>>>>>> fails for reasons other than a missing or invalid = redirection URI, >>>>>>>>>>> the authorization server informs the client by adding the = following >>>>>>>>>>> parameters to the query component of the redirection URI = using the >>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>> : >>>>>>>>>>>=20 >>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> provider. >>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>> > >>>>>>>>>>> >. >>>>>>>>>>>=20 >>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am = redirected >>>>>>>>>>> back to >>>>>>>>>>> attacker.com >>>>>>>>>> > >. >>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>=20 >>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>=20 >>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>> Of course in the positive case if all the parameters are = fine this >>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the = app via the >>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>=20 >>>>>>>>>>> A solution would be to return error 400 rather than redirect = to the >>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>=20 >>>>>>>>>>> WDYT? >>>>>>>>>>>=20 >>>>>>>>>>> regards >>>>>>>>>>>=20 >>>>>>>>>>> antonio >>>>>>>>>>>=20 >>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Bill Burke >>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>=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 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | = Ping >>>>>>> Identity >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>=20 >>>=20 >>> --=20 >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>=20 >=20 --Apple-Mail=_513BA612-099B-4FF1-B3A0-662EAEABB097 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think that is probably reasonable advice. =  

Presenting a dialog to the user also has the = beneficial side effect of removing the original referrer from being seen = by the party hosting the redirect_uri.  
It is allowing = dynamic parameters to be passed in the referrer that is the largest = security issue in my opinion.   That is how the AS might be used as = a redirector to attack itself.

John = B.


hi again *,

after thinking a bit further IMHO an alternative for the untrusted = clients can also be to always present the consent screen (at least once) = before any redirect.
Namely all providers I have seen show the consent screen if all the = request parameters are correct and if the user accepts the redirect = happens.
If one of the parameter  (with the exclusion of the client id = and redirect uri that are handled differently as for spec) is wrong = though the redirect happens without the consent screen being = shown..

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso <asanso@adobe.com> wrote:

Well,
I do not know if this is only dynamic registration...
let=92s talk about real use cases, namely e.g. Google , Facebook , = etc.. is that dynamic client registration? I do not know=85 :)

Said that what the other guys think?  :) 
Would this deserve some =93spec adjustment=94 ? I mean there is a = reason if Google is by choice =93violating=94 the spec right? (I assume = to avoid open redirect=85)
But other implementers do follow the spec hence they have this open = redirector=85 and this is not nice IMHO...


On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <hzandbelt@pingidentity.com&= gt; wrote:

On 9/3/14, 7:14 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandbelt@pingidentity.com&= gt; wrote:

Is your concern clients that were registered = using dynamic client registration?

yes

I think your issue is then with the trust model of dynamic client = registration; that is left out of scope of the dynreg spec (and the = concept is not even part of the core spec), but unless you want = everything to be open (which typically would not be the case), then it would involve approval somewhere in the process before the = client is registered. Without dynamic client registration that approval = is admin based or resource owner based, depending on use case.

Otherwise the positive case is returning a = response to a valid URL that belongs to a client that was registered = explicitly by the resource owner

well AFAIK the resource owner doesn=92t register clients=85

roles can collapse in use cases especially when using dynamic client = registration

and the negative case is returning an error to = that same URL.

the difference is the consent screen=85 in the positive case you need to = approve an app.. for the error case no approval is needed,,,


I fail to see the open redirect.

why?

because the client and thus the fixed URL are explicitly approved at = some point

Hans.



Hans.

On 9/3/14, 6:56 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <hzandbelt@pingidentity.com<= br> <mailto:hzandbelt@pingidentity.c= om>> wrote:

Let me try and approach this from a different = angle: why would you
call it an open redirect when an invalid scope is provided and call = it
correct protocol behavior (hopefully) when a valid scope is = provided?

as specified below in the positive case (namely when the correct = scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com
<mailto:ve7jtb@ve7jtb.com>
<mailto:ve7jtb@ve7jtb.com>> = wrote:

In the example the redirect_uri is vlid for = the attacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time=85.
IMHO the best approach is the one taken from Google, namely = returning
400 with the cause of the error..

*400.* That=92s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=3D[l]}

said that I hope you all agree this is an issue in the spec so far=85.
=
regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com>
<mailto:bburke@redhat.com>> = wrote:

I don't understand.  The redirect uri has = to be valid in order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tools.ietf= .org/html/rfc6749#appendix-B>:

Now let=92s assume this.
I am registering a new client to thevictim.com
<http://victim.com/><http://victim.com <http://victim.com/>>
<http://victim.com <http://victim.com/>>
provider.
I register redirect uriattacker.com
<http://attacker.com/><http://attacker.com <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected
back to
attacker.com <http://attacker.com/><http://attacker.com
<http://attacker.com/>> = <http://attacker.com <http://attacker.com/>>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=3Dcode&= client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&r= edirect_uri=3Dhttp://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn=92t apply since the resource owner MUST approve the app via = the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools= .ietf.org/html/rfc6749#section-4.1.2.1


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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/= mailman/listinfo/oauth

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



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


--
Hans Zandbelt =             &n= bsp;| Sr. Technical Architect
hzandbelt@pingidentity.com = <mailto:hzandbelt@pingidentity.c= om>| Ping
Identity


--
Hans Zandbelt =             &n= bsp;| Sr. Technical Architect
hzandbelt@pingidentity.com = | Ping Identity


-- 
Hans Zandbelt =             &n= bsp;| Sr. Technical Architect
hzandbelt@pingidentity.com<= span class=3D"Apple-converted-space"> | Ping Identity



= --Apple-Mail=_513BA612-099B-4FF1-B3A0-662EAEABB097-- --Apple-Mail=_C9A396E1-02F0-43C9-8C68-F1C2C8E76232 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MDQwNTU3MDVaMCMGCSqGSIb3DQEJBDEWBBRzJvhw2s0Rekxcp5YNxoX4 mVOYOzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBmb0aCSVjCmrH+GMkRRQFpo6ERSB39xA9ilbH/eRh8+bViWdgnXzhO Uc+IoCG5ob6fOoBXPRTSebzWmSjEBTWtLWPkzPuYVY/AvV3/OObploPJmUJ4BhMW5SC67qGDmgGA d96Al6jNjT8SyVnkhjUbZinjZDTK8BKv7PQMqEtufVRF1AoR42zxVYWNbqwnYQb3zZv/yxHXMJUL Ii0fzyZp5d+zLN0IApXUH0liDmX9LyyVdEzJNg1xIm3I9TwcnT2No9pvt9gw0W408GixJrVcJAU4 0f6Ze/Ta9E50WR9VepVh+zvpuD5dxnykl3ZUTdEajVra1/L5JrAkpCL0ug2OAAAAAAAA --Apple-Mail=_C9A396E1-02F0-43C9-8C68-F1C2C8E76232-- From nobody Thu Sep 4 00:04:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD3D1A6EF6 for ; Thu, 4 Sep 2014 00:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 oS9xf_7lgBXq for ; Thu, 4 Sep 2014 00:04:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4C1A6EEE for ; Thu, 4 Sep 2014 00:04:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4B67E1F0674; Thu, 4 Sep 2014 03:04:12 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2BEFC1F02AB; Thu, 4 Sep 2014 03:04:12 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.110]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Thu, 4 Sep 2014 03:04:11 -0400 From: "Richer, Justin P." To: Antonio Sanso Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5Jvv1xSAgAABLoCAAAjvgIAAAVeAgAABWQCAAAPwAIAAAR4AgAAHXACAAAO+AIAAwVmAgAAbioA= Date: Thu, 4 Sep 2014 07:04:11 +0000 Message-ID: <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> In-Reply-To: <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.7.60] Content-Type: multipart/alternative; boundary="_000_255386B579A14CD790E6F3F6E23F51F8mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fbSj-EfTmpJaGORchO9liIHFxYg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 07:04:23 -0000 --_000_255386B579A14CD790E6F3F6E23F51F8mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think this advice isn't a bad idea, though it's of course up to the AS wh= at an "untrusted" client really is. In practice, this is something that was= registered by a non-sysadmin type person, either a dynamically registered = client or something available through self-service registration of some typ= e. It's also reasonable that a client, even dynamically registered, would b= e considered "trusted" if enough time has passed and enough users have used= it without things blowing up. -- Justin On Sep 4, 2014, at 1:26 AM, Antonio Sanso > wrote: hi again *, after thinking a bit further IMHO an alternative for the untrusted clients = can also be to always present the consent screen (at least once) before any= redirect. Namely all providers I have seen show the consent screen if all the request= parameters are correct and if the user accepts the redirect happens. If one of the parameter (with the exclusion of the client id and redirect = uri that are handled differently as for spec) is wrong though the redirect = happens without the consent screen being shown.. WDYT? regards antonio On Sep 3, 2014, at 7:54 PM, Antonio Sanso > wrote: Well, I do not know if this is only dynamic registration... let=92s talk about real use cases, namely e.g. Google , Facebook , etc.. is= that dynamic client registration? I do not know=85 :) Said that what the other guys think? :) Would this deserve some =93spec adjustment=94 ? I mean there is a reason if= Google is by choice =93violating=94 the spec right? (I assume to avoid ope= n redirect=85) But other implementers do follow the spec hence they have this open redirec= tor=85 and this is not nice IMHO... On Sep 3, 2014, at 7:40 PM, Hans Zandbelt > wrote: On 9/3/14, 7:14 PM, Antonio Sanso wrote: On Sep 3, 2014, at 7:10 PM, Hans Zandbelt > wrote: Is your concern clients that were registered using dynamic client registrat= ion? yes I think your issue is then with the trust model of dynamic client registrat= ion; that is left out of scope of the dynreg spec (and the concept is not e= ven part of the core spec), but unless you want everything to be open (whic= h typically would not be the case), then it would involve approval somewher= e in the process before the client is registered. Without dynamic client re= gistration that approval is admin based or resource owner based, depending = on use case. Otherwise the positive case is returning a response to a valid URL that bel= ongs to a client that was registered explicitly by the resource owner well AFAIK the resource owner doesn=92t register clients=85 roles can collapse in use cases especially when using dynamic client regist= ration and the negative case is returning an error to that same URL. the difference is the consent screen=85 in the positive case you need to ap= prove an app.. for the error case no approval is needed,,, I fail to see the open redirect. why? because the client and thus the fixed URL are explicitly approved at some p= oint Hans. Hans. On 9/3/14, 6:56 PM, Antonio Sanso wrote: On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > wrote: Let me try and approach this from a different angle: why would you call it an open redirect when an invalid scope is provided and call it correct protocol behavior (hopefully) when a valid scope is provided? as specified below in the positive case (namely when the correct scope is provided) the resource owner MUST approve the app via the consent screen (at least once). Hans. On 9/3/14, 6:46 PM, Antonio Sanso wrote: hi John, On Sep 3, 2014, at 6:14 PM, John Bradley > wrote: In the example the redirect_uri is vlid for the attacker. The issue is that the AS may be allowing client registrations with arbitrary redirect_uri. In the spec it is unspecified how a AS validates that a client controls the redirect_uri it is registering. I think that if anything it may be the registration step that needs the security consideration. (this is the first time :p) but I do disagree with you. It would be pretty unpractical to block this at registration time=85. IMHO the best approach is the one taken from Google, namely returning 400 with the cause of the error.. *400.* That=92s an error. *Error: invalid_scope* Some requested scopes were invalid. {invalid=3D[l]} said that I hope you all agree this is an issue in the spec so far=85. regards antonio John B. On Sep 3, 2014, at 12:10 PM, Bill Burke > wrote: I don't understand. The redirect uri has to be valid in order for a redirect to happen. The spec explicitly states this. On 9/3/2014 11:43 AM, Antonio Sanso wrote: hi *, IMHO providers that strictly follow rfc6749 are vulnerable to open redirect. Let me explain, reading [0] If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, perAppendix B : Now let=92s assume this. I am registering a new client to thevictim.com > > provider. I register redirect uriattacker.com > >. According to [0] if I pass e.g. the wrong scope I am redirected back to attacker.com > >. Namely I prepare a url that is in this form: http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com and this is works as an open redirector. Of course in the positive case if all the parameters are fine this doesn=92t apply since the resource owner MUST approve the app via the consent screen (at least once). A solution would be to return error 400 rather than redirect to the redirect URI (as some provider e.g. Google do) WDYT? regards antonio [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identi= ty -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identi= ty _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_255386B579A14CD790E6F3F6E23F51F8mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <737E2638C12FF7488697D5E700320CAE@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I think this advice isn't a bad idea, though it's of course up to the AS wh= at an "untrusted" client really is. In practice, this is somethin= g that was registered by a non-sysadmin type person, either a dynamically r= egistered client or something available through self-service registration of some type. It's also reasonable that a client= , even dynamically registered, would be considered "trusted" if e= nough time has passed and enough users have used it without things blowing = up.

 -- Justin

On Sep 4, 2014, at 1:26 AM, Antonio Sanso <asanso@adobe.com> wrote:

hi again *,

after thinking a bit further IMHO an alternative for the untrusted cli= ents can also be to always present the consent screen (at least once) befor= e any redirect.
Namely all providers I have seen show the consent screen if all the re= quest parameters are correct and if the user accepts the redirect happens.<= /div>
If one of the parameter  (with the exclusion of the client id and= redirect uri that are handled differently as for spec) is wrong though the= redirect happens without the consent screen being shown..

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso <asanso@adobe.com> wrote:

Well,
I do not know if this is only dynamic registration...
let=92s talk about real use cases, namely e.g. Google , Facebook , etc= .. is that dynamic client registration? I do not know=85 :)

Said that what the other guys think?  :) 
Would this deserve some =93spec adjustment=94 ? I mean there is a reas= on if Google is by choice =93violating=94 the spec right? (I assume to avoi= d open redirect=85)
But other implementers do follow the spec hence they have this open re= director=85 and this is not nice IMHO...


On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

On 9/3/14, 7:14 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

Is your concern clients that were registered usin= g dynamic client registration?

yes

I think your issue is then with the trust model of dynamic client registrat= ion; that is left out of scope of the dynreg spec (and the concept is not e= ven part of the core spec), but unless you want everything to be open (whic= h typically would not be the case), then it would involve approval somewhere in the process before the client = is registered. Without dynamic client registration that approval is admin b= ased or resource owner based, depending on use case.

Otherwise the positive case is returning a respon= se to a valid URL that belongs to a client that was registered explicitly b= y the resource owner

well AFAIK the resource owner doesn=92t register clients=85

roles can collapse in use cases especially when using dynamic client regist= ration

and the negative case is returning an error to th= at same URL.

the difference is the consent screen=85 in the positive case you need to ap= prove an app.. for the error case no approval is needed,,,


I fail to see the open redirect.

why?

because the client and thus the fixed URL are explicitly approved at some p= oint

Hans.



Hans.

On 9/3/14, 6:56 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <hzandbelt@pingidentity.com
<mailto:hzandbelt@pingiden= tity.com>> wrote:

Let me try and approach this from a different ang= le: why would you
call it an open redirect when an invalid scope is provided and call it
correct protocol behavior (hopefully) when a valid scope is provided?

as specified below in the positive case (namely when the correct scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com
<mailto:ve7jtb@ve7jtb.com> <mailto:ve7jtb@ve7jtb.com>&g= t; wrote:

In the example the redirect_uri is vlid for the a= ttacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time=85.
IMHO the best approach is the one taken from Google, namely returning
400 with the cause of the error..

*400.* That=92s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=3D[l]}

said that I hope you all agree this is an issue in the spec so far=85.

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com> <mailto:bburke@redhat.com>&g= t; wrote:

I don't understand.  The redirect uri has to= be valid in order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tool= s.ietf.org/html/rfc6749#appendix-B>:

Now let=92s assume this.
I am registering a new client to thevicti= m.com
<http://victim.com/><http://victim.com <http://victim.com/>>
<http://victim.com <http://victim.com/>>
provider.
I register redirect uriattacker.com=
<http://attacker.com/><http://attacker.com <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected
back to
attacker.com <http://attacker.com/><http://attacker.com
<http://attacker.com/>> <<= a href=3D"http://attacker.com/">http://attacker.com <http://attacker.com/>>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=3Dcode&a= mp;client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&= ;redirect_uri=3Dhttp://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn=92t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https:/= /tools.ietf.org/html/rfc6749#section-4.1.2.1


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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com<= br>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.or= g/mailman/listinfo/oauth

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



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


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com <mailto:hzandbelt@pingid= entity.com>| Ping
Identity


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


-- 
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


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

--_000_255386B579A14CD790E6F3F6E23F51F8mitreorg_-- From nobody Thu Sep 4 00:47:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7688E1A6EF9 for ; Thu, 4 Sep 2014 00:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=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 nbsZXtbdh7yE for ; Thu, 4 Sep 2014 00:47:13 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1191A6EEE for ; Thu, 4 Sep 2014 00:47:13 -0700 (PDT) Received: from mail-we0-f182.google.com ([74.125.82.182]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKVAgZABJYy+5q3ngJsVvi06+aBN1g3BUA@postini.com; Thu, 04 Sep 2014 00:47:13 PDT Received: by mail-we0-f182.google.com with SMTP id w62so9771595wes.41 for ; Thu, 04 Sep 2014 00:47:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U4P1iBsbDflM7m9TtgUjt1CF3sfZ5szG/o25ppk/Le0=; b=WArYTrS3UeH95aLv4EFZ8ylMYppsEtmrR/Pg2iGpgahYI27Qlc6YJEHUuzoti+BtPX NY/2yQMpl9d9ig9ROAYHAl+P+QTx87LD45hmHAkxZef5u6BLpUpOpLqNUpfUYSD+Ya7e /gziRxbXv9o+K3X9VNKqO4bLTROYh+UfXI8fNSL1OHZDavWTts4NzYlm8vzkTjXWsnP8 1/pAU5vey5jQ+vTm9Sc5v/kxpTG2aPvXMUj+Q6lnUF9aQEJBv9jyugncDn1P4/uo2oIN L2eujW8znMZSGJgqkNrTNf2hjRA39XqPsedSEFeYZHhRAHPxlso0Dv3P5kWJYgto5UcF pYag== X-Gm-Message-State: ALoCoQnyZW9VWUDtCI+utBEe/tOZ0l21GnASUsrIOsPwRxDtHLmjOouaBWQqYz3OCGZHb8T5YhXXSE8as8ZFUj/W8ru3mUAvV0LGP/NaC6YtIFRx9fOemqvg8dq9pZvtlNKg83QipPnp X-Received: by 10.194.77.35 with SMTP id p3mr3845371wjw.56.1409816831694; Thu, 04 Sep 2014 00:47:11 -0700 (PDT) X-Received: by 10.194.77.35 with SMTP id p3mr3845349wjw.56.1409816831574; Thu, 04 Sep 2014 00:47:11 -0700 (PDT) Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id gh1sm444361wib.18.2014.09.04.00.47.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 00:47:10 -0700 (PDT) Message-ID: <540818FD.1010202@pingidentity.com> Date: Thu, 04 Sep 2014 09:47:09 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Richer, Justin P." , Antonio Sanso References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> In-Reply-To: <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/VOn8KBkREJc2CTynNri5Xp7yxy0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 07:47:15 -0000 Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy. IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients. Hans. On 9/4/14, 9:04 AM, Richer, Justin P. wrote: > I think this advice isn't a bad idea, though it's of course up to the AS > what an "untrusted" client really is. In practice, this is something > that was registered by a non-sysadmin type person, either a dynamically > registered client or something available through self-service > registration of some type. It's also reasonable that a client, even > dynamically registered, would be considered "trusted" if enough time has > passed and enough users have used it without things blowing up. > > -- Justin > > On Sep 4, 2014, at 1:26 AM, Antonio Sanso > wrote: > >> hi again *, >> >> after thinking a bit further IMHO an alternative for the untrusted >> clients can also be to always present the consent screen (at least >> once) before any redirect. >> Namely all providers I have seen show the consent screen if all the >> request parameters are correct and if the user accepts the redirect >> happens. >> If one of the parameter (with the exclusion of the client id and >> redirect uri that are handled differently as for spec) is wrong though >> the redirect happens without the consent screen being shown.. >> >> WDYT? >> >> regards >> >> antonio >> >> On Sep 3, 2014, at 7:54 PM, Antonio Sanso > > wrote: >> >>> Well, >>> I do not know if this is only dynamic registration... >>> let’s talk about real use cases, namely e.g. Google , Facebook , >>> etc.. is that dynamic client registration? I do not know… :) >>> >>> Said that what the other guys think? :) >>> Would this deserve some “spec adjustment” ? I mean there is a reason >>> if Google is by choice “violating” the spec right? (I assume to avoid >>> open redirect…) >>> But other implementers do follow the spec hence they have this open >>> redirector… and this is not nice IMHO... >>> >>> >>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >> > wrote: >>> >>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>> >>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>> > wrote: >>>>> >>>>>> Is your concern clients that were registered using dynamic client >>>>>> registration? >>>>> >>>>> yes >>>> >>>> I think your issue is then with the trust model of dynamic client >>>> registration; that is left out of scope of the dynreg spec (and the >>>> concept is not even part of the core spec), but unless you want >>>> everything to be open (which typically would not be the case), then >>>> it would involve approval somewhere in the process before the client >>>> is registered. Without dynamic client registration that approval is >>>> admin based or resource owner based, depending on use case. >>>> >>>>>> Otherwise the positive case is returning a response to a valid URL >>>>>> that belongs to a client that was registered explicitly by the >>>>>> resource owner >>>>> >>>>> well AFAIK the resource owner doesn’t register clients… >>>> >>>> roles can collapse in use cases especially when using dynamic client >>>> registration >>>> >>>>>> and the negative case is returning an error to that same URL. >>>>> >>>>> the difference is the consent screen… in the positive case you need >>>>> to approve an app.. for the error case no approval is needed,,, >>>>> >>>>>> >>>>>> I fail to see the open redirect. >>>>> >>>>> why? >>>> >>>> because the client and thus the fixed URL are explicitly approved at >>>> some point >>>> >>>> Hans. >>>> >>>>> >>>>>> >>>>>> Hans. >>>>>> >>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>> >>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>> >>>>>>> > wrote: >>>>>>> >>>>>>>> Let me try and approach this from a different angle: why would you >>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>> call it >>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>> provided? >>>>>>> >>>>>>> as specified below in the positive case (namely when the correct >>>>>>> scope >>>>>>> is provided) the resource owner MUST approve the app via the consent >>>>>>> screen (at least once). >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Hans. >>>>>>>> >>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>> hi John, >>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>> >>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>> >>>>>>>>>> The issue is that the AS may be allowing client registrations with >>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>> >>>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>> >>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>> needs >>>>>>>>>> the security consideration. >>>>>>>>> >>>>>>>>> (this is the first time :p) but I do disagree with you. It would be >>>>>>>>> pretty unpractical to block this at registration time…. >>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>> returning >>>>>>>>> 400 with the cause of the error.. >>>>>>>>> >>>>>>>>> *400.* That’s an error. >>>>>>>>> >>>>>>>>> *Error: invalid_scope* >>>>>>>>> >>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>>>>> >>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>> far…. >>>>>>>>> >>>>>>>>> regards >>>>>>>>> >>>>>>>>> antonio >>>>>>>>> >>>>>>>>>> >>>>>>>>>> John B. >>>>>>>>>> >>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>> order for a >>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>> >>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>> hi *, >>>>>>>>>>>> >>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>> to open >>>>>>>>>>>> redirect. >>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>> >>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>> invalid, >>>>>>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>> >>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>> request >>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>> redirection URI, >>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>> following >>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>> using the >>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> Now let’s assume this. >>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> provider. >>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> >. >>>>>>>>>>>> >>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>>>>> back to >>>>>>>>>>>> attacker.com >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>> >. >>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>> >>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>>>>> >>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>> fine this >>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the app >>>>>>>>>>>> via the >>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>> >>>>>>>>>>>> A solution would be to return error 400 rather than redirect >>>>>>>>>>>> to the >>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>> >>>>>>>>>>>> WDYT? >>>>>>>>>>>> >>>>>>>>>>>> regards >>>>>>>>>>>> >>>>>>>>>>>> antonio >>>>>>>>>>>> >>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Bill Burke >>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com >>>>>>>> | Ping >>>>>>>> Identity >>>>>>> >>>>>> >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | >>>>>> Ping Identity >>>>> >>>> >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping >>>> Identity >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Thu Sep 4 00:50:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4E61A6F30 for ; Thu, 4 Sep 2014 00:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 5GquW1NgL3m5 for ; Thu, 4 Sep 2014 00:50:48 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBB41A6F2C for ; Thu, 4 Sep 2014 00:50:47 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Thu, 4 Sep 2014 07:50:38 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.144]) with mapi id 15.00.1015.018; Thu, 4 Sep 2014 07:50:38 +0000 From: Antonio Sanso To: Hans Zandbelt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwA Date: Thu, 4 Sep 2014 07:50:37 +0000 Message-ID: <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> In-Reply-To: <540818FD.1010202@pingidentity.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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(189002)(199003)(51704005)(24454002)(479174003)(51444003)(2656002)(15975445006)(95666004)(64706001)(19580405001)(19580395003)(82746002)(83322001)(21056001)(99286002)(36756003)(587094003)(90102001)(83716003)(66066001)(74662001)(81342001)(4396001)(101416001)(20776003)(33656002)(85306004)(105586002)(93886004)(107046002)(15395725005)(99396002)(31966008)(76482001)(50986999)(77096002)(92566001)(79102001)(92726001)(76176999)(106356001)(86362001)(106116001)(54356999)(74502001)(80022001)(16601075003)(15202345003)(110136001)(46102001)(87936001)(77982001)(81542001)(83072002)(85852003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LyaF7fuW-6MvPP1XoydJsC4Oc8w Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 07:50:50 -0000 Hi Hans, I really fail to see how this can be addressed at registration time for cas= es where registration is unrestricted (namely all the big Providers) regards antonio On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrot= e: > Classifying like this must also mean that consent should not be stored un= til the client is considered (admin) trusted, and admin policy would interf= ere with user policy. >=20 > IMHO the security consideration would apply only to dynamically registere= d clients where registration is unrestricted; any other form would involve = some form of admin/user approval at registration time, overcoming the conce= rn at authorization time: there's no auto-redirect flow possible for unknow= n clients. >=20 > Hans. >=20 > On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >> I think this advice isn't a bad idea, though it's of course up to the AS >> what an "untrusted" client really is. In practice, this is something >> that was registered by a non-sysadmin type person, either a dynamically >> registered client or something available through self-service >> registration of some type. It's also reasonable that a client, even >> dynamically registered, would be considered "trusted" if enough time has >> passed and enough users have used it without things blowing up. >>=20 >> -- Justin >>=20 >> On Sep 4, 2014, at 1:26 AM, Antonio Sanso > > wrote: >>=20 >>> hi again *, >>>=20 >>> after thinking a bit further IMHO an alternative for the untrusted >>> clients can also be to always present the consent screen (at least >>> once) before any redirect. >>> Namely all providers I have seen show the consent screen if all the >>> request parameters are correct and if the user accepts the redirect >>> happens. >>> If one of the parameter (with the exclusion of the client id and >>> redirect uri that are handled differently as for spec) is wrong though >>> the redirect happens without the consent screen being shown.. >>>=20 >>> WDYT? >>>=20 >>> regards >>>=20 >>> antonio >>>=20 >>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >> > wrote: >>>=20 >>>> Well, >>>> I do not know if this is only dynamic registration... >>>> let=92s talk about real use cases, namely e.g. Google , Facebook , >>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>=20 >>>> Said that what the other guys think? :) >>>> Would this deserve some =93spec adjustment=94 ? I mean there is a reas= on >>>> if Google is by choice =93violating=94 the spec right? (I assume to av= oid >>>> open redirect=85) >>>> But other implementers do follow the spec hence they have this open >>>> redirector=85 and this is not nice IMHO... >>>>=20 >>>>=20 >>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>> > wrote: >>>>=20 >>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>=20 >>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>> > wro= te: >>>>>>=20 >>>>>>> Is your concern clients that were registered using dynamic client >>>>>>> registration? >>>>>>=20 >>>>>> yes >>>>>=20 >>>>> I think your issue is then with the trust model of dynamic client >>>>> registration; that is left out of scope of the dynreg spec (and the >>>>> concept is not even part of the core spec), but unless you want >>>>> everything to be open (which typically would not be the case), then >>>>> it would involve approval somewhere in the process before the client >>>>> is registered. Without dynamic client registration that approval is >>>>> admin based or resource owner based, depending on use case. >>>>>=20 >>>>>>> Otherwise the positive case is returning a response to a valid URL >>>>>>> that belongs to a client that was registered explicitly by the >>>>>>> resource owner >>>>>>=20 >>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>=20 >>>>> roles can collapse in use cases especially when using dynamic client >>>>> registration >>>>>=20 >>>>>>> and the negative case is returning an error to that same URL. >>>>>>=20 >>>>>> the difference is the consent screen=85 in the positive case you nee= d >>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>=20 >>>>>>>=20 >>>>>>> I fail to see the open redirect. >>>>>>=20 >>>>>> why? >>>>>=20 >>>>> because the client and thus the fixed URL are explicitly approved at >>>>> some point >>>>>=20 >>>>> Hans. >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>> >>>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> Let me try and approach this from a different angle: why would yo= u >>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>> call it >>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>> provided? >>>>>>>>=20 >>>>>>>> as specified below in the positive case (namely when the correct >>>>>>>> scope >>>>>>>> is provided) the resource owner MUST approve the app via the conse= nt >>>>>>>> screen (at least once). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>> hi John, >>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>=20 >>>>>>>>>>> The issue is that the AS may be allowing client registrations w= ith >>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>=20 >>>>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>=20 >>>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>>> needs >>>>>>>>>>> the security consideration. >>>>>>>>>>=20 >>>>>>>>>> (this is the first time :p) but I do disagree with you. It would= be >>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>> returning >>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>=20 >>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>=20 >>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>=20 >>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>=20 >>>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>>> far=85. >>>>>>>>>>=20 >>>>>>>>>> regards >>>>>>>>>>=20 >>>>>>>>>> antonio >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> John B. >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>> order for a >>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>> hi *, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>> to open >>>>>>>>>>>>> redirect. >>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatchin= g >>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>> invalid, >>>>>>>>>>>>> the authorization server SHOULD inform the resource owner of = the >>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to t= he >>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>> request >>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>> following >>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>> using the >>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>> : >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> provider. >>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirect= ed >>>>>>>>>>>>> back to >>>>>>>>>>>>> attacker.com >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>> >. >>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3D= bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://= attacker.com >>>>>>>>>>>>>=20 >>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>> fine this >>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the app >>>>>>>>>>>>> via the >>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A solution would be to return error 400 rather than redirect >>>>>>>>>>>>> to the >>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> regards >>>>>>>>>>>>>=20 >>>>>>>>>>>>> antonio >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Bill Burke >>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>=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 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>> | Ping >>>>>>>>> Identity >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | >>>>>>> Ping Identity >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping >>>>> Identity >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity From nobody Thu Sep 4 01:58:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1531A00AA for ; Thu, 4 Sep 2014 01:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=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 YQIQ_ILgkxyS for ; Thu, 4 Sep 2014 01:58:29 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC3B1A008B for ; Thu, 4 Sep 2014 01:58:29 -0700 (PDT) Received: from mail-wg0-f49.google.com ([74.125.82.49]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKVAgptKrVMw7AsBmDv6IcaXnX02nL1RB5@postini.com; Thu, 04 Sep 2014 01:58:29 PDT Received: by mail-wg0-f49.google.com with SMTP id y10so9724062wgg.8 for ; Thu, 04 Sep 2014 01:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aoIWiys9v78a5JUr14fxM5Z0SJMDjkytMcRbFuoAZj4=; b=iOSvpM+Ns9zaYvG66fD4ZZl6XLDTI4/47ekWezNk9OdFmdHdIPg2AlRCqUoabHf9h6 MINqhXxuQrog0vS/U4HxXbZtVWGBjw9DLDF40UVDMgKKvxY6orz2BYmS9EUWpqNCqx9A MrivhmSY6v/HpuQv4y5ZnvWIBv3Dgb0dVY5ZjrmCEcs7qNRkQH/t0AECLs8BGTHQ3Cw3 kW5oRN/pdI774wqC4BNk8Len71h1j8fkdZ3kVjWi+Cv19WqdL94rqiuDaQB2ZkQRiOSg OvHGRl2OzpFu3z5NY5iuj/uwdj1UdsxC+YgiuVAf7afkJzRbYajLG47GLvOm6rnPTSib bYLg== X-Gm-Message-State: ALoCoQkQFHol5pXS3xjAwPG0kS0kO4+DlGcp6FIYDAi5+xKsD1FUFZ7z4Hi512xe8DfdEGn4SsoqpGWo66hk0UFn7q9uM/XlN4F3bHULoDbWDXvRvzPPUYqg7qUm4bQfjh65HhohYie5 X-Received: by 10.180.85.136 with SMTP id h8mr3951934wiz.67.1409821107576; Thu, 04 Sep 2014 01:58:27 -0700 (PDT) X-Received: by 10.180.85.136 with SMTP id h8mr3951914wiz.67.1409821107412; Thu, 04 Sep 2014 01:58:27 -0700 (PDT) Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id z5sm642528wib.20.2014.09.04.01.58.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 01:58:26 -0700 (PDT) Message-ID: <540829AF.9030804@pingidentity.com> Date: Thu, 04 Sep 2014 10:58:23 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Antonio Sanso References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> In-Reply-To: <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DXHzUShhsMoUjFNk2CHm4FndJmo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 08:58:31 -0000 Agreed, I see you point about the big providers using exactly the unrestricted flow for which the trust model (by definition) is out of scope of the spec. This may be the reason for the implemented behavior indeed and a security consideration is a good idea for other deployments; there's not much more that can be done. But Google also provides explicit registration for API clients (which is where my mind was): https://developers.google.com/accounts/docs/OAuth2 (step 1) and they would not need to deviate from the spec for that, nor would the spec need to change Hans. On 9/4/14, 9:50 AM, Antonio Sanso wrote: > Hi Hans, > > I really fail to see how this can be addressed at registration time for cases where registration is unrestricted (namely all the big Providers) > > regards > > antonio > > On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: > >> Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy. >> >> IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients. >> >> Hans. >> >> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>> I think this advice isn't a bad idea, though it's of course up to the AS >>> what an "untrusted" client really is. In practice, this is something >>> that was registered by a non-sysadmin type person, either a dynamically >>> registered client or something available through self-service >>> registration of some type. It's also reasonable that a client, even >>> dynamically registered, would be considered "trusted" if enough time has >>> passed and enough users have used it without things blowing up. >>> >>> -- Justin >>> >>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >> > wrote: >>> >>>> hi again *, >>>> >>>> after thinking a bit further IMHO an alternative for the untrusted >>>> clients can also be to always present the consent screen (at least >>>> once) before any redirect. >>>> Namely all providers I have seen show the consent screen if all the >>>> request parameters are correct and if the user accepts the redirect >>>> happens. >>>> If one of the parameter (with the exclusion of the client id and >>>> redirect uri that are handled differently as for spec) is wrong though >>>> the redirect happens without the consent screen being shown.. >>>> >>>> WDYT? >>>> >>>> regards >>>> >>>> antonio >>>> >>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>> > wrote: >>>> >>>>> Well, >>>>> I do not know if this is only dynamic registration... >>>>> let’s talk about real use cases, namely e.g. Google , Facebook , >>>>> etc.. is that dynamic client registration? I do not know… :) >>>>> >>>>> Said that what the other guys think? :) >>>>> Would this deserve some “spec adjustment” ? I mean there is a reason >>>>> if Google is by choice “violating” the spec right? (I assume to avoid >>>>> open redirect…) >>>>> But other implementers do follow the spec hence they have this open >>>>> redirector… and this is not nice IMHO... >>>>> >>>>> >>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>> > wrote: >>>>> >>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>> >>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>> > wrote: >>>>>>> >>>>>>>> Is your concern clients that were registered using dynamic client >>>>>>>> registration? >>>>>>> >>>>>>> yes >>>>>> >>>>>> I think your issue is then with the trust model of dynamic client >>>>>> registration; that is left out of scope of the dynreg spec (and the >>>>>> concept is not even part of the core spec), but unless you want >>>>>> everything to be open (which typically would not be the case), then >>>>>> it would involve approval somewhere in the process before the client >>>>>> is registered. Without dynamic client registration that approval is >>>>>> admin based or resource owner based, depending on use case. >>>>>> >>>>>>>> Otherwise the positive case is returning a response to a valid URL >>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>> resource owner >>>>>>> >>>>>>> well AFAIK the resource owner doesn’t register clients… >>>>>> >>>>>> roles can collapse in use cases especially when using dynamic client >>>>>> registration >>>>>> >>>>>>>> and the negative case is returning an error to that same URL. >>>>>>> >>>>>>> the difference is the consent screen… in the positive case you need >>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>> >>>>>>>> >>>>>>>> I fail to see the open redirect. >>>>>>> >>>>>>> why? >>>>>> >>>>>> because the client and thus the fixed URL are explicitly approved at >>>>>> some point >>>>>> >>>>>> Hans. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Hans. >>>>>>>> >>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>> >>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Let me try and approach this from a different angle: why would you >>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>> call it >>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>> provided? >>>>>>>>> >>>>>>>>> as specified below in the positive case (namely when the correct >>>>>>>>> scope >>>>>>>>> is provided) the resource owner MUST approve the app via the consent >>>>>>>>> screen (at least once). >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hans. >>>>>>>>>> >>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>> hi John, >>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>> >>>>>>>>>>>> The issue is that the AS may be allowing client registrations with >>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>> >>>>>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>> >>>>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>>>> needs >>>>>>>>>>>> the security consideration. >>>>>>>>>>> >>>>>>>>>>> (this is the first time :p) but I do disagree with you. It would be >>>>>>>>>>> pretty unpractical to block this at registration time…. >>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>> returning >>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>> >>>>>>>>>>> *400.* That’s an error. >>>>>>>>>>> >>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>> >>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>>>>>>> >>>>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>>>> far…. >>>>>>>>>>> >>>>>>>>>>> regards >>>>>>>>>>> >>>>>>>>>>> antonio >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> John B. >>>>>>>>>>>> >>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>> order for a >>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>> >>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>> to open >>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>> request >>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>> following >>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>> using the >>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>> : >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now let’s assume this. >>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> provider. >>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> >. >>>>>>>>>>>>>> >>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>>>>>>> back to >>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>> >. >>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>> fine this >>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the app >>>>>>>>>>>>>> via the >>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>> >>>>>>>>>>>>>> A solution would be to return error 400 rather than redirect >>>>>>>>>>>>>> to the >>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>> >>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>> >>>>>>>>>>>>>> regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>> >>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>> | Ping >>>>>>>>>> Identity >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | >>>>>>>> Ping Identity >>>>>>> >>>>>> >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping >>>>>> Identity >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Thu Sep 4 04:44:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E511A870E for ; Thu, 4 Sep 2014 04:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 MtN78oW5ymwd for ; Thu, 4 Sep 2014 04:44:40 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482B91A8705 for ; Thu, 4 Sep 2014 04:44:40 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 4 Sep 2014 11:44:38 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.144]) with mapi id 15.00.1015.018; Thu, 4 Sep 2014 11:44:38 +0000 From: Antonio Sanso To: Hans Zandbelt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgAAS64CAAC5/AA== Date: Thu, 4 Sep 2014 11:44:37 +0000 Message-ID: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <540829AF.9030804@pingidentity.com> In-Reply-To: <540829AF.9030804@pingidentity.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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(479174003)(199003)(24454002)(51444003)(189002)(51704005)(74662001)(16601075003)(90102001)(587094003)(92726001)(21056001)(85306004)(83322001)(77982001)(92566001)(93886004)(79102001)(15395725005)(46102001)(110136001)(15202345003)(99396002)(83072002)(85852003)(19580405001)(64706001)(16799955002)(66066001)(33656002)(36756003)(105586002)(54356999)(74502001)(86362001)(76176999)(31966008)(15975445006)(82746002)(106356001)(2656002)(50986999)(83716003)(4396001)(106116001)(80022001)(76482001)(101416001)(20776003)(81542001)(95666004)(87936001)(107046002)(19580395003)(77096002)(99286002)(81342001)(104396001)(16940595002)(387795003)(235135003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB206; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <4DD3EDABA78CDB43BB55E014C3FD59C3@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xiZ73TW513hTSh_r6pLqAEHfn7A Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:44:42 -0000 hi Hans On Sep 4, 2014, at 10:58 AM, Hans Zandbelt wro= te: > Agreed, I see you point about the big providers using exactly the unrestr= icted flow for which the trust model (by definition) is out of scope of the= spec. This may be the reason for the implemented behavior indeed and a sec= urity consideration is a good idea for other deployments; there's not much = more that can be done. >=20 > But Google also provides explicit registration for API clients (which is = where my mind was): > https://developers.google.com/accounts/docs/OAuth2 (step 1) > and they would not need to deviate from the spec for that, nor would the = spec need to change I do really struggle to understand your point here :) (at least the "nor wo= uld the spec need to change part" :)). Probably I need to explain myself better. Since Google is =93safe=94 (due the =93deviation=94 from the spec) I would = take Google as example here (I could point out open redirector in the wild = to proof my point but I will not do=85) Let=92s start from scratch=85 If Google would have something like http://www.google.com?goto=3Dattacker.c= om this is without any doubt an open redirector=85 see also OWASP 10 [0]. Now if Google would have implemented the spec rfc6749 verbatim something li= ke=20 https://accounts.google.com/o/oauth2/auth?response_type=3Dcode&client_id=3D= 788732372078.apps.googleusercontent.com&scope=3DWRONG_SCOPE&redirect_uri=3D= http://attacker.com would have redirect to http://attacker.com. So why this is not an open redirect ? :) Now maybe we are saying the same thing but I felt like better explain my po= int :) regards antonio [0] https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_a= nd_Forwards >=20 > Hans. >=20 > On 9/4/14, 9:50 AM, Antonio Sanso wrote: >> Hi Hans, >>=20 >> I really fail to see how this can be addressed at registration time for = cases where registration is unrestricted (namely all the big Providers) >>=20 >> regards >>=20 >> antonio >>=20 >> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt w= rote: >>=20 >>> Classifying like this must also mean that consent should not be stored = until the client is considered (admin) trusted, and admin policy would inte= rfere with user policy. >>>=20 >>> IMHO the security consideration would apply only to dynamically registe= red clients where registration is unrestricted; any other form would involv= e some form of admin/user approval at registration time, overcoming the con= cern at authorization time: there's no auto-redirect flow possible for unkn= own clients. >>>=20 >>> Hans. >>>=20 >>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>> I think this advice isn't a bad idea, though it's of course up to the = AS >>>> what an "untrusted" client really is. In practice, this is something >>>> that was registered by a non-sysadmin type person, either a dynamicall= y >>>> registered client or something available through self-service >>>> registration of some type. It's also reasonable that a client, even >>>> dynamically registered, would be considered "trusted" if enough time h= as >>>> passed and enough users have used it without things blowing up. >>>>=20 >>>> -- Justin >>>>=20 >>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>> > wrote: >>>>=20 >>>>> hi again *, >>>>>=20 >>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>> clients can also be to always present the consent screen (at least >>>>> once) before any redirect. >>>>> Namely all providers I have seen show the consent screen if all the >>>>> request parameters are correct and if the user accepts the redirect >>>>> happens. >>>>> If one of the parameter (with the exclusion of the client id and >>>>> redirect uri that are handled differently as for spec) is wrong thoug= h >>>>> the redirect happens without the consent screen being shown.. >>>>>=20 >>>>> WDYT? >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>> > wrote: >>>>>=20 >>>>>> Well, >>>>>> I do not know if this is only dynamic registration... >>>>>> let=92s talk about real use cases, namely e.g. Google , Facebook , >>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>=20 >>>>>> Said that what the other guys think? :) >>>>>> Would this deserve some =93spec adjustment=94 ? I mean there is a re= ason >>>>>> if Google is by choice =93violating=94 the spec right? (I assume to = avoid >>>>>> open redirect=85) >>>>>> But other implementers do follow the spec hence they have this open >>>>>> redirector=85 and this is not nice IMHO... >>>>>>=20 >>>>>>=20 >>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>> > wrote: >>>>>>=20 >>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>> > w= rote: >>>>>>>>=20 >>>>>>>>> Is your concern clients that were registered using dynamic client >>>>>>>>> registration? >>>>>>>>=20 >>>>>>>> yes >>>>>>>=20 >>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>> registration; that is left out of scope of the dynreg spec (and the >>>>>>> concept is not even part of the core spec), but unless you want >>>>>>> everything to be open (which typically would not be the case), then >>>>>>> it would involve approval somewhere in the process before the clien= t >>>>>>> is registered. Without dynamic client registration that approval is >>>>>>> admin based or resource owner based, depending on use case. >>>>>>>=20 >>>>>>>>> Otherwise the positive case is returning a response to a valid UR= L >>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>> resource owner >>>>>>>>=20 >>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>=20 >>>>>>> roles can collapse in use cases especially when using dynamic clien= t >>>>>>> registration >>>>>>>=20 >>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>=20 >>>>>>>> the difference is the consent screen=85 in the positive case you n= eed >>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I fail to see the open redirect. >>>>>>>>=20 >>>>>>>> why? >>>>>>>=20 >>>>>>> because the client and thus the fixed URL are explicitly approved a= t >>>>>>> some point >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> Let me try and approach this from a different angle: why would = you >>>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>>> call it >>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>> provided? >>>>>>>>>>=20 >>>>>>>>>> as specified below in the positive case (namely when the correct >>>>>>>>>> scope >>>>>>>>>> is provided) the resource owner MUST approve the app via the con= sent >>>>>>>>>> screen (at least once). >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>> hi John, >>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The issue is that the AS may be allowing client registrations= with >>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a clien= t >>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>>>>> needs >>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>=20 >>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It wou= ld be >>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>> returning >>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>=20 >>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>=20 >>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>=20 >>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>=20 >>>>>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>>>>> far=85. >>>>>>>>>>>>=20 >>>>>>>>>>>> regards >>>>>>>>>>>>=20 >>>>>>>>>>>> antonio >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> John B. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>> order for a >>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatch= ing >>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner o= f the >>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to= the >>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>> request >>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redire= cted >>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >. >>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id= =3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp= ://attacker.com >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the a= pp >>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> A solution would be to return error 400 rather than redirec= t >>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>=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 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>> | Ping >>>>>>>>>>> Identity >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>> Ping Identity >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Pin= g >>>>>>> Identity >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> -- >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity From frizzthecat@googlemail.com Thu Sep 4 02:30:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A671A0203 for ; Thu, 4 Sep 2014 02:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 3sK_Ah_kbpmo for ; Thu, 4 Sep 2014 02:30:11 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D7B1A0970 for ; Thu, 4 Sep 2014 02:30:09 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id m19so6940287oag.25 for ; Thu, 04 Sep 2014 02:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Vz5m1MChFFJsJiw3W1JP+sCqTIkygqMS69ervTkJxGU=; b=ppYgpjQBBg3neBxtLKa2b4t2OvXjvf11tVxB3DKFirnGKZAyUJsX3bEaVDNwid7Rko YYLCKEbC10CzW5fv8fIu6GgKCOq4Jun/h7GVIik8/3As48CphmapVuq9sZKCLjcpDbyl OFK1jeIntw6swNPXUgCJ3VyaR0G9ixwt6kXBCdmZysHvpfxnXF0ix2H2q+8uMnvAJyTh SJAjponKpioEdtstx4TqiNjz42FQPal9aNcbA9YqatjBACUBRTvSPX8LlOPgasFP9JfR mw1EmJU1UxxY1C9fAVFbviu6R4A49XTlopvHw0jwdjF/9zTvjsdYjaKsAMwIt0Qqorig y+gg== MIME-Version: 1.0 X-Received: by 10.60.65.35 with SMTP id u3mr3245877oes.35.1409823008470; Thu, 04 Sep 2014 02:30:08 -0700 (PDT) Received: by 10.76.106.147 with HTTP; Thu, 4 Sep 2014 02:30:08 -0700 (PDT) Date: Thu, 4 Sep 2014 11:30:08 +0200 Message-ID: From: Frizz To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11c257589dbb27050239ffc3 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/t8IQbxHdEZyjYSPFK830DH_0G-8 X-Mailman-Approved-At: Thu, 04 Sep 2014 04:49:35 -0700 Subject: [OAUTH-WG] Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 09:32:28 -0000 --001a11c257589dbb27050239ffc3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello there, I have a question regarding Authentication: The following two scenarios, are they typical use cases for OAuth? Or OpenId-Connect? Or something completely different? Flow (A) would be like this: (1) Client calls Business Logic Server (2) Server detects there=E2=80=99s no Access Token in HTTP headers (3) Server redirects to *some* Authentication Server (4) Authentication Server challenges Client for Username/Password (5) Client (now with valid Access Token) is redirected to Business Logic Server and completes operation Flow (B) would look like this: (1) Client directly calls Authentication Server (kinda explicit Login call) with Username/Password and gets an Access Token in return (2) Client uses this Access Token for all calls to the Business Logic Serve= r cheers, Frizz --001a11c257589dbb27050239ffc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello there,

I have a question regarding Authentica= tion:

The following two scenarios, are they typical use cases for OA= uth? Or OpenId-Connect? Or something completely different?

Flow (A) = would be like this:
(1) Client calls Business Logic Server
(2) Server detects there=E2=80=99= s no Access Token in HTTP headers
(3) Server redirects to *some* Authent= ication Server
(4) Authentication Server challenges Client for Username/= Password
(5) Client (now with valid Access Token) is redirected to Business Logic Se= rver and completes operation

Flow (B) would look like this:
(1) C= lient directly calls Authentication Server (kinda explicit Login call) with= Username/Password and gets an Access Token in return
(2) Client uses this Access Token for all calls to the Business Logic Serve= r

cheers,
Frizz
--001a11c257589dbb27050239ffc3-- From nobody Thu Sep 4 04:58:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372981A875A for ; Thu, 4 Sep 2014 04:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=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 H1h3hXVjRcXs for ; Thu, 4 Sep 2014 04:58:34 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97641A87E6 for ; Thu, 4 Sep 2014 04:58:30 -0700 (PDT) Received: from mail-wi0-f170.google.com ([209.85.212.170]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKVAhT5kEkQvbiW3QZxNfJTyXCEjwMxig7@postini.com; Thu, 04 Sep 2014 04:58:31 PDT Received: by mail-wi0-f170.google.com with SMTP id cc10so7447812wib.5 for ; Thu, 04 Sep 2014 04:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vBAhKSlIFJwh9LsBR97iXfjdeml19PZevOLREr2DJ38=; b=hMnZrOoELDqDUMDli//Ysdi7h7hPTFWA6btLI6xNsVpSuKYZn/1G8HAItf/zynlk8U jtnGCDnKnAQO5g3qQjT22mumk8yk2QbrNaM5GunVueYNTddnAvRzkmLWgrnWPtpKS1Uj MK2IyiI3slaVM+AsuJR4lMNMZR00mvA/a9VIrMqFhdAj3fyJauNi0Sm5suo2gkYOpR26 lslzNYzmcso4rwYI7v59+MzurCV3P0alQUm575eKmajrKqQwG+vKtmlieaBaMdxOeWJ1 yj3tozCUCnx6HS9U9RKeL3AoSSXtoKFkSRihazcRBpzCt5f5gc5/J0D3JFiwf6Bw609+ X7Kw== X-Gm-Message-State: ALoCoQl7l/IWA53HJkEIh6i579MrmgbAyfgrsRx3IEECvEtqnBWJ6gjhVUfM3NhhNjRLA69CV8z58F1ncFAYr6PxXcGzaxWLRPaNrEI1bfivRHM0Buiai+0Fcmnz47xQdhHHIv7iWhwb X-Received: by 10.180.9.37 with SMTP id w5mr5102343wia.39.1409831907257; Thu, 04 Sep 2014 04:58:27 -0700 (PDT) X-Received: by 10.180.9.37 with SMTP id w5mr5102327wia.39.1409831907139; Thu, 04 Sep 2014 04:58:27 -0700 (PDT) Received: from [192.168.10.102] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id mv14sm1152689wic.20.2014.09.04.04.58.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 04:58:26 -0700 (PDT) Message-ID: <540853E1.3090102@pingidentity.com> Date: Thu, 04 Sep 2014 13:58:25 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Antonio Sanso References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <540829AF.9030804@pingidentity.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pVFMoDf6eBaW6FAdO3douqsHPdo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:58:36 -0000 yes, you are right about the unrestricted client use case; I just got caught by the fact that you were talking about *unrestricted* client registration all the time (standards-based or not) which deserves extra caution whereas Google (and the spec) also provides *restricted* client registration the deviation or caution is not needed Hans. On 9/4/14, 1:44 PM, Antonio Sanso wrote: > hi Hans > > On Sep 4, 2014, at 10:58 AM, Hans Zandbelt wrote: > >> Agreed, I see you point about the big providers using exactly the unrestricted flow for which the trust model (by definition) is out of scope of the spec. This may be the reason for the implemented behavior indeed and a security consideration is a good idea for other deployments; there's not much more that can be done. >> >> But Google also provides explicit registration for API clients (which is where my mind was): >> https://developers.google.com/accounts/docs/OAuth2 (step 1) >> and they would not need to deviate from the spec for that, nor would the spec need to change > > I do really struggle to understand your point here :) (at least the "nor would the spec need to change part" :)). > > Probably I need to explain myself better. > Since Google is “safe” (due the “deviation” from the spec) I would take Google as example here (I could point out open redirector in the wild to proof my point but I will not do…) > > Let’s start from scratch… > > If Google would have something like http://www.google.com?goto=attacker.com this is without any doubt an open redirector… see also OWASP 10 [0]. > > Now if Google would have implemented the spec rfc6749 verbatim something like > > https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com > > would have redirect to http://attacker.com. > > So why this is not an open redirect ? :) > > Now maybe we are saying the same thing but I felt like better explain my point :) > > regards > > antonio > > [0] https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards > > >> >> Hans. >> >> On 9/4/14, 9:50 AM, Antonio Sanso wrote: >>> Hi Hans, >>> >>> I really fail to see how this can be addressed at registration time for cases where registration is unrestricted (namely all the big Providers) >>> >>> regards >>> >>> antonio >>> >>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>> >>>> Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy. >>>> >>>> IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients. >>>> >>>> Hans. >>>> >>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>> I think this advice isn't a bad idea, though it's of course up to the AS >>>>> what an "untrusted" client really is. In practice, this is something >>>>> that was registered by a non-sysadmin type person, either a dynamically >>>>> registered client or something available through self-service >>>>> registration of some type. It's also reasonable that a client, even >>>>> dynamically registered, would be considered "trusted" if enough time has >>>>> passed and enough users have used it without things blowing up. >>>>> >>>>> -- Justin >>>>> >>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>> > wrote: >>>>> >>>>>> hi again *, >>>>>> >>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>> clients can also be to always present the consent screen (at least >>>>>> once) before any redirect. >>>>>> Namely all providers I have seen show the consent screen if all the >>>>>> request parameters are correct and if the user accepts the redirect >>>>>> happens. >>>>>> If one of the parameter (with the exclusion of the client id and >>>>>> redirect uri that are handled differently as for spec) is wrong though >>>>>> the redirect happens without the consent screen being shown.. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> regards >>>>>> >>>>>> antonio >>>>>> >>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>> > wrote: >>>>>> >>>>>>> Well, >>>>>>> I do not know if this is only dynamic registration... >>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook , >>>>>>> etc.. is that dynamic client registration? I do not know… :) >>>>>>> >>>>>>> Said that what the other guys think? :) >>>>>>> Would this deserve some “spec adjustment” ? I mean there is a reason >>>>>>> if Google is by choice “violating” the spec right? (I assume to avoid >>>>>>> open redirect…) >>>>>>> But other implementers do follow the spec hence they have this open >>>>>>> redirector… and this is not nice IMHO... >>>>>>> >>>>>>> >>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>> > wrote: >>>>>>> >>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>> >>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Is your concern clients that were registered using dynamic client >>>>>>>>>> registration? >>>>>>>>> >>>>>>>>> yes >>>>>>>> >>>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>>> registration; that is left out of scope of the dynreg spec (and the >>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>> everything to be open (which typically would not be the case), then >>>>>>>> it would involve approval somewhere in the process before the client >>>>>>>> is registered. Without dynamic client registration that approval is >>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>> >>>>>>>>>> Otherwise the positive case is returning a response to a valid URL >>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>> resource owner >>>>>>>>> >>>>>>>>> well AFAIK the resource owner doesn’t register clients… >>>>>>>> >>>>>>>> roles can collapse in use cases especially when using dynamic client >>>>>>>> registration >>>>>>>> >>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>> >>>>>>>>> the difference is the consent screen… in the positive case you need >>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I fail to see the open redirect. >>>>>>>>> >>>>>>>>> why? >>>>>>>> >>>>>>>> because the client and thus the fixed URL are explicitly approved at >>>>>>>> some point >>>>>>>> >>>>>>>> Hans. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hans. >>>>>>>>>> >>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>> >>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Let me try and approach this from a different angle: why would you >>>>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>>>> call it >>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>> provided? >>>>>>>>>>> >>>>>>>>>>> as specified below in the positive case (namely when the correct >>>>>>>>>>> scope >>>>>>>>>>> is provided) the resource owner MUST approve the app via the consent >>>>>>>>>>> screen (at least once). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hans. >>>>>>>>>>>> >>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>> hi John, >>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The issue is that the AS may be allowing client registrations with >>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>>>>>> needs >>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>> >>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It would be >>>>>>>>>>>>> pretty unpractical to block this at registration time…. >>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>> returning >>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>> >>>>>>>>>>>>> *400.* That’s an error. >>>>>>>>>>>>> >>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>> >>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>>>>>>>>> >>>>>>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>>>>>> far…. >>>>>>>>>>>>> >>>>>>>>>>>>> regards >>>>>>>>>>>>> >>>>>>>>>>>>> antonio >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> John B. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Now let’s assume this. >>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the app >>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A solution would be to return error 400 rather than redirect >>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>> | Ping >>>>>>>>>>>> Identity >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>> Ping Identity >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>> Identity >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping Identity >>> >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Thu Sep 4 05:10:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE461A8892 for ; Thu, 4 Sep 2014 05:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=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 ntcSPzydfZmq for ; Thu, 4 Sep 2014 05:10:34 -0700 (PDT) Received: from na3sys009aog136.obsmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757E31A0111 for ; Thu, 4 Sep 2014 05:09:29 -0700 (PDT) Received: from mail-wi0-f173.google.com ([209.85.212.173]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKVAhWeAAC6nrxxQm3ptkXXUl+Wcu7UIg4@postini.com; Thu, 04 Sep 2014 05:09:29 PDT Received: by mail-wi0-f173.google.com with SMTP id cc10so952245wib.6 for ; Thu, 04 Sep 2014 05:09:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5RZbxxC8UBMlmVwhKMODYORei752rdfhWWqDWh4iQ8E=; b=cWTlMXhsDjYZE4IjaFIo1Vc4J/oi0tHvL2rAiEVR3Olt1mHh8McY1dffjWIz+x4+bv 72cxvH5U2KpPkRKc7umadeXQp48COPBNTB1eGgfhuwcIkG4TSchM33GdKUyKxTrN+OWE RqzlXRscuy6bxJO+LIuLqs0qBC5Swhg/8TM5ZKeaZk+9JoQL6QjVs5X2xFvTdsC0mb2E HQhcPPfRfTaaJva1yvJm9hDovuG1bQtbLMEId00bq0r1kTcN4yAV83TGwiDQadzB43Dp 4OMAmuBHVcQAbuJugy/tSmAnh8Fd0M/nxrFiwhUJ/esm8xgQT4GwG2u0w3k5712KY7nd xbPQ== X-Gm-Message-State: ALoCoQkqIgRYdDeNLnrrHViYyu0KhHuTZGDChnNy2d8Ua2W5DrDF7FZbW39WiujTkq4b1ss2sCGnimDGPJA/QMiym8YIwvmzWumLZEto08Z3usJ/dApvzJ/yv7KF7SQSVwpIClsJ6mzI X-Received: by 10.194.238.195 with SMTP id vm3mr5277730wjc.91.1409832567863; Thu, 04 Sep 2014 05:09:27 -0700 (PDT) X-Received: by 10.194.238.195 with SMTP id vm3mr5277683wjc.91.1409832567520; Thu, 04 Sep 2014 05:09:27 -0700 (PDT) Received: from [192.168.10.102] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id p1sm19226721wjy.22.2014.09.04.05.09.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 05:09:26 -0700 (PDT) Message-ID: <54085675.3060507@pingidentity.com> Date: Thu, 04 Sep 2014 14:09:25 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Antonio Sanso References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <540829AF.9030804@pingidentity.com> <540853E1.3090102@pingidentity.com> In-Reply-To: <540853E1.3090102@pingidentity.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/B1cZCj2ZNN73RKghBdMKM52HU7E Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:10:36 -0000 Maybe just to clarify my point: where did the client_id in the example that you gave come from? Hans. On 9/4/14, 1:58 PM, Hans Zandbelt wrote: > yes, you are right about the unrestricted client use case; I just got > caught by the fact that you were talking about *unrestricted* client > registration all the time (standards-based or not) which deserves extra > caution whereas Google (and the spec) also provides *restricted* client > registration the deviation or caution is not needed > > Hans. > > On 9/4/14, 1:44 PM, Antonio Sanso wrote: >> hi Hans >> >> On Sep 4, 2014, at 10:58 AM, Hans Zandbelt >> wrote: >> >>> Agreed, I see you point about the big providers using exactly the >>> unrestricted flow for which the trust model (by definition) is out of >>> scope of the spec. This may be the reason for the implemented >>> behavior indeed and a security consideration is a good idea for other >>> deployments; there's not much more that can be done. >>> >>> But Google also provides explicit registration for API clients (which >>> is where my mind was): >>> https://developers.google.com/accounts/docs/OAuth2 (step 1) >>> and they would not need to deviate from the spec for that, nor would >>> the spec need to change >> >> I do really struggle to understand your point here :) (at least the >> "nor would the spec need to change part" :)). >> >> Probably I need to explain myself better. >> Since Google is “safe” (due the “deviation” from the spec) I would >> take Google as example here (I could point out open redirector in the >> wild to proof my point but I will not do…) >> >> Let’s start from scratch… >> >> If Google would have something like >> http://www.google.com?goto=attacker.com this is without any doubt an >> open redirector… see also OWASP 10 [0]. >> >> Now if Google would have implemented the spec rfc6749 verbatim >> something like >> >> https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >> >> >> would have redirect to http://attacker.com. >> >> So why this is not an open redirect ? :) >> >> Now maybe we are saying the same thing but I felt like better explain >> my point :) >> >> regards >> >> antonio >> >> [0] >> https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards >> >> >> >>> >>> Hans. >>> >>> On 9/4/14, 9:50 AM, Antonio Sanso wrote: >>>> Hi Hans, >>>> >>>> I really fail to see how this can be addressed at registration time >>>> for cases where registration is unrestricted (namely all the big >>>> Providers) >>>> >>>> regards >>>> >>>> antonio >>>> >>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt >>>> wrote: >>>> >>>>> Classifying like this must also mean that consent should not be >>>>> stored until the client is considered (admin) trusted, and admin >>>>> policy would interfere with user policy. >>>>> >>>>> IMHO the security consideration would apply only to dynamically >>>>> registered clients where registration is unrestricted; any other >>>>> form would involve some form of admin/user approval at registration >>>>> time, overcoming the concern at authorization time: there's no >>>>> auto-redirect flow possible for unknown clients. >>>>> >>>>> Hans. >>>>> >>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>> I think this advice isn't a bad idea, though it's of course up to >>>>>> the AS >>>>>> what an "untrusted" client really is. In practice, this is something >>>>>> that was registered by a non-sysadmin type person, either a >>>>>> dynamically >>>>>> registered client or something available through self-service >>>>>> registration of some type. It's also reasonable that a client, even >>>>>> dynamically registered, would be considered "trusted" if enough >>>>>> time has >>>>>> passed and enough users have used it without things blowing up. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>> > wrote: >>>>>> >>>>>>> hi again *, >>>>>>> >>>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>>> clients can also be to always present the consent screen (at least >>>>>>> once) before any redirect. >>>>>>> Namely all providers I have seen show the consent screen if all the >>>>>>> request parameters are correct and if the user accepts the redirect >>>>>>> happens. >>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>> redirect uri that are handled differently as for spec) is wrong >>>>>>> though >>>>>>> the redirect happens without the consent screen being shown.. >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> regards >>>>>>> >>>>>>> antonio >>>>>>> >>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>> > wrote: >>>>>>> >>>>>>>> Well, >>>>>>>> I do not know if this is only dynamic registration... >>>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook , >>>>>>>> etc.. is that dynamic client registration? I do not know… :) >>>>>>>> >>>>>>>> Said that what the other guys think? :) >>>>>>>> Would this deserve some “spec adjustment” ? I mean there is a >>>>>>>> reason >>>>>>>> if Google is by choice “violating” the spec right? (I assume to >>>>>>>> avoid >>>>>>>> open redirect…) >>>>>>>> But other implementers do follow the spec hence they have this open >>>>>>>> redirector… and this is not nice IMHO... >>>>>>>> >>>>>>>> >>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>> >>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Is your concern clients that were registered using dynamic >>>>>>>>>>> client >>>>>>>>>>> registration? >>>>>>>>>> >>>>>>>>>> yes >>>>>>>>> >>>>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>>>> registration; that is left out of scope of the dynreg spec (and >>>>>>>>> the >>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>> everything to be open (which typically would not be the case), >>>>>>>>> then >>>>>>>>> it would involve approval somewhere in the process before the >>>>>>>>> client >>>>>>>>> is registered. Without dynamic client registration that >>>>>>>>> approval is >>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>> >>>>>>>>>>> Otherwise the positive case is returning a response to a >>>>>>>>>>> valid URL >>>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>>> resource owner >>>>>>>>>> >>>>>>>>>> well AFAIK the resource owner doesn’t register clients… >>>>>>>>> >>>>>>>>> roles can collapse in use cases especially when using dynamic >>>>>>>>> client >>>>>>>>> registration >>>>>>>>> >>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>> >>>>>>>>>> the difference is the consent screen… in the positive case you >>>>>>>>>> need >>>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>> >>>>>>>>>> why? >>>>>>>>> >>>>>>>>> because the client and thus the fixed URL are explicitly >>>>>>>>> approved at >>>>>>>>> some point >>>>>>>>> >>>>>>>>> Hans. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hans. >>>>>>>>>>> >>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Let me try and approach this from a different angle: why >>>>>>>>>>>>> would you >>>>>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>>>>> call it >>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>> provided? >>>>>>>>>>>> >>>>>>>>>>>> as specified below in the positive case (namely when the >>>>>>>>>>>> correct >>>>>>>>>>>> scope >>>>>>>>>>>> is provided) the resource owner MUST approve the app via the >>>>>>>>>>>> consent >>>>>>>>>>>> screen (at least once). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hans. >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The issue is that the AS may be allowing client >>>>>>>>>>>>>>> registrations with >>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a >>>>>>>>>>>>>>> client >>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think that if anything it may be the registration step >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>> >>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It >>>>>>>>>>>>>> would be >>>>>>>>>>>>>> pretty unpractical to block this at registration time…. >>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>>> returning >>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>> >>>>>>>>>>>>>> *400.* That’s an error. >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>>>>>>>>>> >>>>>>>>>>>>>> said that I hope you all agree this is an issue in the >>>>>>>>>>>>>> spec so >>>>>>>>>>>>>> far…. >>>>>>>>>>>>>> >>>>>>>>>>>>>> regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or >>>>>>>>>>>>>>>>> mismatching >>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource >>>>>>>>>>>>>>>>> owner of the >>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the >>>>>>>>>>>>>>>>> user-agent to the >>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Now let’s assume this. >>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am >>>>>>>>>>>>>>>>> redirected >>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the >>>>>>>>>>>>>>>>> app >>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than >>>>>>>>>>>>>>>>> redirect >>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>> | Ping >>>>>>>>>>>>> Identity >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>> Ping Identity >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>> Ping >>>>>>>>> Identity >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>> >>> >>> -- >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >> > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Thu Sep 4 05:15:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84841A0111 for ; Thu, 4 Sep 2014 05:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 IAJbjgtzqHoy for ; Thu, 4 Sep 2014 05:15:12 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E371B1A8783 for ; Thu, 4 Sep 2014 05:15:11 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id u56so10208978wes.2 for ; Thu, 04 Sep 2014 05:15:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6XvioMyL4wWBGaQX8M2r49eYIzXUmkl04mbJ5nvFS8c=; b=SfCcyRHOvG3csEPcjgX7gOo2jnyVkzupkJo8r2r3qNrptrfT6b+v5B4qglcKxBIYFT 4e+gRYarUtgOGWV6qM04ZJcEczpdl1bfnGEIJBBA/ZKZZIL6PjUWHBcEu+S+RzB5SQyj K50+oujjeQh2oVZgu8tdiKAG46yIxZRz+9y0jmqj6eTxXRJ3+W6bof+Kla/+usGSygVO 2ZXBCFIYQVvd9cYkIVHJY8O5mQNADk1+BfpHsXFIyKVF3tktnNRAeKGpG5hZp7k3ziEO cUW0FK0hzTfpAa6MYBaN6+aUkF2JWtjZ2BOu1qSY4zKbItA9d0Yek5GSDpLRDUcGZ1XW 8mgw== X-Gm-Message-State: ALoCoQlJ+vcgay3hzn4G0lC6S72eHnkJIuS1to5DDMHaVTXjLJxjglyVq7c0vH957ZYZoxA9W/g1 X-Received: by 10.194.63.241 with SMTP id j17mr5525100wjs.115.1409832910497; Thu, 04 Sep 2014 05:15:10 -0700 (PDT) Received: from host-101-0.eduroamers.nl (host-101-0.eduroamers.nl. [145.96.0.101]) by mx.google.com with ESMTPSA id q3sm1208922wia.14.2014.09.04.05.15.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 05:15:09 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_16FD7181-95A1-4833-81D1-213C7077FD8D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Thu, 4 Sep 2014 14:15:07 +0200 Message-Id: <91233751-10CD-4882-99AC-DF2B2B3FF888@ve7jtb.com> References: To: Frizz X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TOjfM4U4eIgljNB9QvXukyKH1kw Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:15:18 -0000 --Apple-Mail=_16FD7181-95A1-4833-81D1-213C7077FD8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Inline On Sep 4, 2014, at 11:30 AM, Frizz wrote: > Hello there, >=20 > I have a question regarding Authentication: >=20 > The following two scenarios, are they typical use cases for OAuth? Or = OpenId-Connect? Or something completely different? >=20 > Flow (A) would be like this: > (1) Client calls Business Logic Server > (2) Server detects there=92s no Access Token in HTTP headers > (3) Server redirects to *some* Authentication Server > (4) Authentication Server challenges Client for Username/Password > (5) Client (now with valid Access Token) is redirected to Business = Logic Server and completes operation In 3 the RS returns an error that includes the required scopes. http://tools.ietf.org/html/rfc6750#section-3 The location of the AS is not included by default. The UMA spec uses = that but OAuth 2 doesn't typically. The majority of deployed OAuth clients are hard coded to a AS or in the = openID Connect case discovery is used to determine the AS. Typically the client would not start at the resource. In 4 the AS is challenging the user for username/password via a web form = in in the code and implicit flows. In 5 the users browser is redirected back to the client with a token or = code. In 6 the client access the resource. >=20 > Flow (B) would look like this: > (1) Client directly calls Authentication Server (kinda explicit Login = call) with Username/Password and gets an Access Token in return > (2) Client uses this Access Token for all calls to the Business Logic = Server >=20 This is the Resource owner password credentials grant or client = credentials flow.=20 http://tools.ietf.org/html/rfc6749#section-4.3 Regards John B. > cheers, > Frizz > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_16FD7181-95A1-4833-81D1-213C7077FD8D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MDQxMjE1MDhaMCMGCSqGSIb3DQEJBDEWBBRKUIXmU2zz/J8/MyCydZof to2rzjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQA63TBZB40SiZP/J1GEVARTO3TuJVd0bRw2vj8hm7lqti8JLdf+2amo pl5gRKpN6iZtsFCDeDxWRqsRsh2Hhv0xVzF0cdSwUX4hLAbnFhq9QN6WVnLDFt2pgd3TvJiVTU/C 4pY55hSL8/Bdjw0AcJAGPF9dZafAJESQxxs4LBl7nowfvG/i9Xwbcs1mV7SEBbt1QKu5HSDql+dy nv1bKUJoE10Cx1zwstqEEUclCtsG8b/h8bC/yCkTbo4Ctoul88gp7os/nZOBKd3zM6jOWb0lyLlP Kr5M5aH0XmW9Vp5OW26kWah4VLjdVf1yAwBZdTZjpvtTsvhvxcU9QYn61wKRAAAAAAAA --Apple-Mail=_16FD7181-95A1-4833-81D1-213C7077FD8D-- From nobody Thu Sep 4 05:15:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFAD1A0111 for ; Thu, 4 Sep 2014 05:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 kAkH8Bh8Dcg3 for ; Thu, 4 Sep 2014 05:15:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 13D9F1A87D8 for ; Thu, 4 Sep 2014 05:15:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9F9341F06D8; Thu, 4 Sep 2014 08:15:12 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8A3DA1F06CC; Thu, 4 Sep 2014 08:15:12 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.110]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Thu, 4 Sep 2014 08:15:12 -0400 From: "Richer, Justin P." To: Frizz Thread-Topic: [OAUTH-WG] Authentication Thread-Index: AQHPyDZP6u2hYPiMQEiBU1fP94VKZpvxJoCA Date: Thu, 4 Sep 2014 12:15:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.5.90] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9532C1B83EE3B34A8765FC5705792FFD@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/r3OM1Hv9pB5fAb9K746lHyl7EVM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:15:19 -0000 Neither of these are authentication (they don't tell the client or business= logic server who the user is or if they're still there), they're authoriza= tion and they're both well within the scope of OAuth.=20 The first one is a redirect flow, that actually works (in OAuth) like this: 1) Clients calls business logic server (in OAuth, the Protected Resource) 2) Server detects no access token, sends an error response to the client 3) Client needs to send the user in a browser to the Authorization Server 4) Authorization server prompts the user (not the client) to authenticate a= nd authorize the client 5) Authorization server redirects back to the client with either the token = (if you're doing implicit flow, inside of a browser) or something the clien= t can use to get a token (authorization code flow) 6) Client gets the token and calls the business logic server with said toke= n In your second scenario, you're really doing the Resource Owner Password fl= ow defined in OAuth. This is generally a bad idea because it exposes the cl= ient to the user's credentials and limits you to username/password. The flo= w is defined mostly as a way to help bridge legacy applications into the OA= uth world. If you actually do want authentication (i.e., the client knowing who the us= er is) on top of this authorized call to the business logic service, then y= ou'll need an identity API, which is what OpenID Connect provides in a well= -defined well-used standard.=20 -- Justin On Sep 4, 2014, at 5:30 AM, Frizz wrote: > Hello there, >=20 > I have a question regarding Authentication: >=20 > The following two scenarios, are they typical use cases for OAuth? Or Ope= nId-Connect? Or something completely different? >=20 > Flow (A) would be like this: > (1) Client calls Business Logic Server > (2) Server detects there=92s no Access Token in HTTP headers > (3) Server redirects to *some* Authentication Server > (4) Authentication Server challenges Client for Username/Password > (5) Client (now with valid Access Token) is redirected to Business Logic = Server and completes operation >=20 > Flow (B) would look like this: > (1) Client directly calls Authentication Server (kinda explicit Login cal= l) with Username/Password and gets an Access Token in return > (2) Client uses this Access Token for all calls to the Business Logic Ser= ver >=20 > cheers, > Frizz > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Sep 4 05:21:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8281A8867 for ; Thu, 4 Sep 2014 05:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 7NnaAAQWUxTD for ; Thu, 4 Sep 2014 05:20:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D951A8877 for ; Thu, 4 Sep 2014 05:20:39 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 4 Sep 2014 12:20:36 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.144]) with mapi id 15.00.1015.018; Thu, 4 Sep 2014 12:20:36 +0000 From: Antonio Sanso To: Hans Zandbelt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgAAS64CAAC5/AIAAA86AgAADE4CAAAMtgA== Date: Thu, 4 Sep 2014 12:20:36 +0000 Message-ID: <12E45043-BF67-468B-8B9F-2AB24A4D083F@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <540829AF.9030804@pingidentity.com> <540853E1.3090102@pingidentity.com> <54085675.3060507@pingidentity.com> In-Reply-To: <54085675.3060507@pingidentity.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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(51444003)(189002)(479174003)(199003)(377454003)(24454002)(105586002)(90102001)(587094003)(15975445006)(106356001)(15202345003)(2656002)(83716003)(74662001)(110136001)(107046002)(106116001)(74502001)(93886004)(77096002)(86362001)(15395725005)(54356999)(95666004)(81342001)(80022001)(85852003)(92566001)(101416001)(87936001)(85306004)(16601075003)(76176999)(77982001)(21056001)(36756003)(64706001)(76482001)(92726001)(99286002)(16236675004)(33656002)(79102001)(50986999)(66066001)(99396002)(83322001)(19580395003)(81542001)(16799955002)(19617315012)(19580405001)(4396001)(83072002)(46102001)(82746002)(20776003)(31966008)(104396001)(16940595002)(235135003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_12E45043BF67468B8B9F2AB24A4D083Fadobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ACVIMCCaZf7PHG2NXcYgaPlZugw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:20:57 -0000 --_000_12E45043BF67468B8B9F2AB24A4D083Fadobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I registered via the Google Developers Console [0] :) [0] https://console.developers.google.com/project On Sep 4, 2014, at 2:09 PM, Hans Zandbelt > wrote: Maybe just to clarify my point: where did the client_id in the example that= you gave come from? Hans. On 9/4/14, 1:58 PM, Hans Zandbelt wrote: yes, you are right about the unrestricted client use case; I just got caught by the fact that you were talking about *unrestricted* client registration all the time (standards-based or not) which deserves extra caution whereas Google (and the spec) also provides *restricted* client registration the deviation or caution is not needed Hans. On 9/4/14, 1:44 PM, Antonio Sanso wrote: hi Hans On Sep 4, 2014, at 10:58 AM, Hans Zandbelt > wrote: Agreed, I see you point about the big providers using exactly the unrestricted flow for which the trust model (by definition) is out of scope of the spec. This may be the reason for the implemented behavior indeed and a security consideration is a good idea for other deployments; there's not much more that can be done. But Google also provides explicit registration for API clients (which is where my mind was): https://developers.google.com/accounts/docs/OAuth2 (step 1) and they would not need to deviate from the spec for that, nor would the spec need to change I do really struggle to understand your point here :) (at least the "nor would the spec need to change part" :)). Probably I need to explain myself better. Since Google is =93safe=94 (due the =93deviation=94 from the spec) I would take Google as example here (I could point out open redirector in the wild to proof my point but I will not do=85) Let=92s start from scratch=85 If Google would have something like http://www.google.com?goto=3Dattacker.com this is without any doubt an open redirector=85 see also OWASP 10 [0]. Now if Google would have implemented the spec rfc6749 verbatim something like https://accounts.google.com/o/oauth2/auth?response_type=3Dcode&client_id=3D= 788732372078.apps.googleusercontent.com&scope=3DWRONG_SCOPE&redirect_uri=3D= http://attacker.com would have redirect to http://attacker.com. So why this is not an open redirect ? :) Now maybe we are saying the same thing but I felt like better explain my point :) regards antonio [0] https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_F= orwards Hans. On 9/4/14, 9:50 AM, Antonio Sanso wrote: Hi Hans, I really fail to see how this can be addressed at registration time for cases where registration is unrestricted (namely all the big Providers) regards antonio On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy. IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients. Hans. On 9/4/14, 9:04 AM, Richer, Justin P. wrote: I think this advice isn't a bad idea, though it's of course up to the AS what an "untrusted" client really is. In practice, this is something that was registered by a non-sysadmin type person, either a dynamically registered client or something available through self-service registration of some type. It's also reasonable that a client, even dynamically registered, would be considered "trusted" if enough time has passed and enough users have used it without things blowing up. -- Justin On Sep 4, 2014, at 1:26 AM, Antonio Sanso > wrote: hi again *, after thinking a bit further IMHO an alternative for the untrusted clients can also be to always present the consent screen (at least once) before any redirect. Namely all providers I have seen show the consent screen if all the request parameters are correct and if the user accepts the redirect happens. If one of the parameter (with the exclusion of the client id and redirect uri that are handled differently as for spec) is wrong though the redirect happens without the consent screen being shown.. WDYT? regards antonio On Sep 3, 2014, at 7:54 PM, Antonio Sanso > wrote: Well, I do not know if this is only dynamic registration... let=92s talk about real use cases, namely e.g. Google , Facebook , etc.. is that dynamic client registration? I do not know=85 :) Said that what the other guys think? :) Would this deserve some =93spec adjustment=94 ? I mean there is a reason if Google is by choice =93violating=94 the spec right? (I assume to avoid open redirect=85) But other implementers do follow the spec hence they have this open redirector=85 and this is not nice IMHO... On Sep 3, 2014, at 7:40 PM, Hans Zandbelt > wrote: On 9/3/14, 7:14 PM, Antonio Sanso wrote: On Sep 3, 2014, at 7:10 PM, Hans Zandbelt > wrote: Is your concern clients that were registered using dynamic client registration? yes I think your issue is then with the trust model of dynamic client registration; that is left out of scope of the dynreg spec (and the concept is not even part of the core spec), but unless you want everything to be open (which typically would not be the case), then it would involve approval somewhere in the process before the client is registered. Without dynamic client registration that approval is admin based or resource owner based, depending on use case. Otherwise the positive case is returning a response to a valid URL that belongs to a client that was registered explicitly by the resource owner well AFAIK the resource owner doesn=92t register clients=85 roles can collapse in use cases especially when using dynamic client registration and the negative case is returning an error to that same URL. the difference is the consent screen=85 in the positive case you need to approve an app.. for the error case no approval is needed,,, I fail to see the open redirect. why? because the client and thus the fixed URL are explicitly approved at some point Hans. Hans. On 9/3/14, 6:56 PM, Antonio Sanso wrote: On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > wrote: Let me try and approach this from a different angle: why would you call it an open redirect when an invalid scope is provided and call it correct protocol behavior (hopefully) when a valid scope is provided? as specified below in the positive case (namely when the correct scope is provided) the resource owner MUST approve the app via the consent screen (at least once). Hans. On 9/3/14, 6:46 PM, Antonio Sanso wrote: hi John, On Sep 3, 2014, at 6:14 PM, John Bradley > wrote: In the example the redirect_uri is vlid for the attacker. The issue is that the AS may be allowing client registrations with arbitrary redirect_uri. In the spec it is unspecified how a AS validates that a client controls the redirect_uri it is registering. I think that if anything it may be the registration step that needs the security consideration. (this is the first time :p) but I do disagree with you. It would be pretty unpractical to block this at registration time=85. IMHO the best approach is the one taken from Google, namely returning 400 with the cause of the error.. *400.* That=92s an error. *Error: invalid_scope* Some requested scopes were invalid. {invalid=3D[l]} said that I hope you all agree this is an issue in the spec so far=85. regards antonio John B. On Sep 3, 2014, at 12:10 PM, Bill Burke > wrote: I don't understand. The redirect uri has to be valid in order for a redirect to happen. The spec explicitly states this. On 9/3/2014 11:43 AM, Antonio Sanso wrote: hi *, IMHO providers that strictly follow rfc6749 are vulnerable to open redirect. Let me explain, reading [0] If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, perAppendix B : Now let=92s assume this. I am registering a new client to thevictim.com > > provider. I register redirect uriattacker.com > >. According to [0] if I pass e.g. the wrong scope I am redirected back to attacker.com > >. Namely I prepare a url that is in this form: http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com and this is works as an open redirector. Of course in the positive case if all the parameters are fine this doesn=92t apply since the resource owner MUST approve the app via the consent screen (at least once). A solution would be to return error 400 rather than redirect to the redirect URI (as some provider e.g. Google do) WDYT? regards antonio [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identi= ty --_000_12E45043BF67468B8B9F2AB24A4D083Fadobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I registered via the Google Developers Console [0]  :)

[0] htt= ps://console.developers.google.com/project
On Sep 4, 2014, at 2:09 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

Maybe just to clarify my point: where did the cli= ent_id in the example that you gave come from?

Hans.

On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
yes, you are right about the unrestricted client = use case; I just got
caught by the fact that you were talking about *unrestricted* client
registration all the time (standards-based or not) which deserves extra
caution whereas Google (and the spec) also provides *restricted* client
registration the deviation or caution is not needed

Hans.

On 9/4/14, 1:44 PM, Antonio Sanso wrote:
hi Hans

On Sep 4, 2014, at 10:58 AM, Hans Zandbelt
<hzandbelt@pingidentity.co= m> wrote:

Agreed, I see you point about the big providers u= sing exactly the
unrestricted flow for which the trust model (by definition) is out of
scope of the spec. This may be the reason for the implemented
behavior indeed and a security consideration is a good idea for other
deployments; there's not much more that can be done.

But Google also provides explicit registration for API clients (which
is where my mind was):
https://deve= lopers.google.com/accounts/docs/OAuth2 (step 1)
and they would not need to deviate from the spec for that, nor would
the spec need to change

I do really struggle to understand your point here :) (at least the
"nor would the spec need to change part" :)).

Probably I need to explain myself better.
Since Google is =93safe=94 (due the =93deviation=94 from the spec) I would<= br> take Google as example here (I could point out open redirector in the
wild to proof my point but I will not do=85)

Let=92s start from scratch=85

If Google would have something like
http://www.google.com= ?goto=3Dattacker.com this is without any doubt an
open redirector=85 see  also OWASP 10 [0].

Now if Google would have implemented the spec rfc6749 verbatim
something like

https://accounts.google.com/o/o= auth2/auth?response_type=3Dcode&client_id=3D788732372078.apps.googleuse= rcontent.com&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com=


would have redirect to http://attacker.com.

So why this is not an open redirect ? :)

Now maybe we are saying the same thing but I felt like better explain
my point :)

regards

antonio

[0]
https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_F= orwards




Hans.

On 9/4/14, 9:50 AM, Antonio Sanso wrote:
Hi Hans,

I really fail to see how this can be addressed at registration time
for cases where registration is unrestricted (namely all the big
Providers)

regards

antonio

On Sep 4, 2014, at 9:47 AM, Hans Zandbelt
<hzandbelt@pingidentity.com> wrote:

Classifying like this must also mean that consent= should not be
stored until the client is considered (admin) trusted, and admin
policy would interfere with user policy.

IMHO the security consideration would apply only to dynamically
registered clients where registration is unrestricted; any other
form would involve some form of admin/user approval at registration
time, overcoming the concern at authorization time: there's no
auto-redirect flow possible for unknown clients.

Hans.

On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
I think this advice isn't a bad idea, though it's= of course up to
the AS
what an "untrusted" client really is. In practice, this is someth= ing
that was registered by a non-sysadmin type person, either a
dynamically
registered client or something available through self-service
registration of some type. It's also reasonable that a client, even
dynamically registered, would be considered "trusted" if enough time has
passed and enough users have used it without things blowing up.

 -- Justin

On Sep 4, 2014, at 1:26 AM, Antonio Sanso <asanso@adobe.com
<mailto:asanso@adobe.com>> wrote:

hi again *,

after thinking a bit further IMHO an alternative for the untrusted
clients can also be to always present the consent screen (at least
once) before any redirect.
Namely all providers I have seen show the consent screen if all the
request parameters are correct and if the user accepts the redirect
happens.
If one of the parameter  (with the exclusion of the client id and
redirect uri that are handled differently as for spec) is wrong
though
the redirect happens without the consent screen being shown..

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso <asanso@adobe.com
<mailto:asanso@adobe.com>> wrote:

Well,
I do not know if this is only dynamic registration...
let=92s talk about real use cases, namely e.g. Google , Facebook ,
etc.. is that dynamic client registration? I do not know=85 :)

Said that what the other guys think?  :)
Would this deserve some =93spec adjustment=94 ? I mean there is a
reason
if Google is by choice =93violating=94 the spec right? (I assume to
avoid
open redirect=85)
But other implementers do follow the spec hence they have this open
redirector=85 and this is not nice IMHO...


On Sep 3, 2014, at 7:40 PM, Hans Zandbelt
<hzandbelt@pingidentity.com
<mailto:hzandbelt@pingidentity.com>> wrote:

On 9/3/14, 7:14 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
<hzandbelt@pingidentity.com
<mailto:hzandbelt@pingidentity.com>> wrote:

Is your concern clients that were registered usin= g dynamic
client
registration?

yes

I think your issue is then with the trust model of dynamic client
registration; that is left out of scope of the dynreg spec (and
the
concept is not even part of the core spec), but unless you want
everything to be open (which typically would not be the case),
then
it would involve approval somewhere in the process before the
client
is registered. Without dynamic client registration that
approval is
admin based or resource owner based, depending on use case.

Otherwise the positive case is returning a respon= se to a
valid URL
that belongs to a client that was registered explicitly by the
resource owner

well AFAIK the resource owner doesn=92t register clients=85

roles can collapse in use cases especially when using dynamic
client
registration

and the negative case is returning an error to th= at same URL.

the difference is the consent screen=85 in the positive case you
need
to approve an app.. for the error case no approval is needed,,,


I fail to see the open redirect.

why?

because the client and thus the fixed URL are explicitly
approved at
some point

Hans.



Hans.

On 9/3/14, 6:56 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt
<hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com> <mailto:hzandbelt@pingidentity.com>> wrote:

Let me try and approach this from a different ang= le: why
would you
call it an open redirect when an invalid scope is provided and
call it
correct protocol behavior (hopefully) when a valid scope is
provided?

as specified below in the positive case (namely when the
correct
scope
is provided) the resource owner MUST approve the app via the
consent
screen (at least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com
<mailto:ve7jtb@ve7jtb.com>
<mailto:ve7jtb@ve7jtb.com>
<mailto:ve7jtb@ve7jtb.com>> wrote:

In the example the redirect_uri is vlid for the a= ttacker.

The issue is that the AS may be allowing client
registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a
client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step
that
needs
the security consideration.

(this is the first time :p) but I do disagree with you. It
would be
pretty unpractical to block this at registration time=85.
IMHO the best approach is the one taken from Google, namely
returning
400 with the cause of the error..

*400.* That=92s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=3D[l]}

said that I hope you all agree this is an issue in the
spec so
far=85.

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com>
<mailto:bburke@redhat.com>
<mailto:bburke@redhat.com>> wrote:

I don't understand.  The redirect uri has to= be valid in
order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable
to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or
mismatching
redirection URI, or if the client identifier is missing or
invalid,
the authorization server SHOULD inform the resource
owner of the
error and MUST NOT automatically redirect the
user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the
request
fails for reasons other than a missing or invalid
redirection URI,
the authorization server informs the client by adding the
following
parameters to the query component of the redirection URI
using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let=92s assume this.
I am registering a new client to thevictim.com
<http://thevictim.com/>
<http://victim.com/><http://victim.com
<http://victim.com/>
<http://victim.com/>>
<http://victim.com <http://victim.com/>
<http://victim.com/>>
provider.
I register redirect uriattacker.com
<http://uriattacker.com/>
<http://attacker.com/><http://attacker.com
<http://attacker.com/> <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>
<http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am
redirected
back to
attacker.com <http://attacker.com/>
<http://attacker.com/><http://attacker.com
<http://attacker.com/>
<http://attacker.com/>> <http://attacker.com
<http://attacker.com/> <http://attacker.com/>>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX12= 98KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://at= tacker.com


and this is works as an open redirector.
Of course in the positive case if all the parameters are
fine this
doesn=92t apply since the resource owner MUST approve the
app
via the
consent screen (at least once).

A solution would be to return error 400 rather than
redirect
to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
<http://bill.burkecentral.com/>

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

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



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


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com>
<mailto:hzandbelt@pingidentity.com>| Ping
Identity


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com> |
Ping Identity


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com>|
Ping
Identity


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


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity



--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity

--_000_12E45043BF67468B8B9F2AB24A4D083Fadobecom_-- From nobody Thu Sep 4 05:22:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93B31A8863 for ; Thu, 4 Sep 2014 05:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 j1-lyLFgWLhC for ; Thu, 4 Sep 2014 05:22:08 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF30F1A8853 for ; Thu, 4 Sep 2014 05:22:07 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id x48so10226316wes.12 for ; Thu, 04 Sep 2014 05:22:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=tw15PK5jVEY34koKPQs7JG51/e9AfC42lCP1SJUqfM0=; b=S7ih1y0muGImj0cIB9sTA7kPNF6YFj5ZBgADRzbPBg/r8e/YHwvNc8Plu8wlX1hyZW UxlUMu1oLlzJ+BYTdUSL3bbIgp4I+IxDbExGdylk47O0IHq8eAdqhawYnHjTEkCHEcnH 4CihzB7bYos5m8WlmoIomE8n1QdiGaIg/FX4JIkahCUOuwbkSZHG0iG9FyTHvIkA7k0M 6absBw+6ipJp8+NaDT/BpJrXFbujMoSD22XnYZcd9L8yx2KdLLOAcKFG1Q90dpkq7I7Z nFwMqFA3qT836PqoQxUfjEs5GmIMAFYIqOMpT1qNZPiSdrEsvp8NysxWrFyhyIYJ97Vb p/aA== X-Gm-Message-State: ALoCoQnIXmOkkYM4hjint2o4rXSF0EU66Yjx5/n6wEJmYdKNrtfNE8skKPVjQBcRh12S40mEu3pM X-Received: by 10.180.11.193 with SMTP id s1mr5113613wib.49.1409833326353; Thu, 04 Sep 2014 05:22:06 -0700 (PDT) Received: from host-101-0.eduroamers.nl (host-101-0.eduroamers.nl. [145.96.0.101]) by mx.google.com with ESMTPSA id xa6sm19269897wjc.19.2014.09.04.05.22.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 05:22:05 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_86C3155F-D1D9-472A-B115-D7B19F5773B0"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <54085675.3060507@pingidentity.com> Date: Thu, 4 Sep 2014 14:22:03 +0200 Message-Id: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <540829AF.9030804@pingidentity.com> <540853E1.3090102@pingidentity.com> <54085675.3060507@pingidentity.com> To: Hans Zandbelt X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kMbSg3YCgZvA7I0G0gqgaqQBkrs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:22:10 -0000 --Apple-Mail=_86C3155F-D1D9-472A-B115-D7B19F5773B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Registration requiring a valid email address is not sufficient to stop a = "bad" person from registering a client that appears to be perfectly = legitimate but is later used as a redirect. So it is a bit slippery to differentiate good from bad. In general clearing the referrer and fragment from incoming requests is = a good practice on redirects to prevent leakage of information across = the redirect. The other concern is using the redirect as part of a phishing attack to = make the target site look more legitimate. That is a more complicated problem unless you validate every client by = looking at them to make sure they are not bad in some way. John B. On Sep 4, 2014, at 2:09 PM, Hans Zandbelt = wrote: > Maybe just to clarify my point: where did the client_id in the example = that you gave come from? >=20 > Hans. >=20 > On 9/4/14, 1:58 PM, Hans Zandbelt wrote: >> yes, you are right about the unrestricted client use case; I just got >> caught by the fact that you were talking about *unrestricted* client >> registration all the time (standards-based or not) which deserves = extra >> caution whereas Google (and the spec) also provides *restricted* = client >> registration the deviation or caution is not needed >>=20 >> Hans. >>=20 >> On 9/4/14, 1:44 PM, Antonio Sanso wrote: >>> hi Hans >>>=20 >>> On Sep 4, 2014, at 10:58 AM, Hans Zandbelt >>> wrote: >>>=20 >>>> Agreed, I see you point about the big providers using exactly the >>>> unrestricted flow for which the trust model (by definition) is out = of >>>> scope of the spec. This may be the reason for the implemented >>>> behavior indeed and a security consideration is a good idea for = other >>>> deployments; there's not much more that can be done. >>>>=20 >>>> But Google also provides explicit registration for API clients = (which >>>> is where my mind was): >>>> https://developers.google.com/accounts/docs/OAuth2 (step 1) >>>> and they would not need to deviate from the spec for that, nor = would >>>> the spec need to change >>>=20 >>> I do really struggle to understand your point here :) (at least the >>> "nor would the spec need to change part" :)). >>>=20 >>> Probably I need to explain myself better. >>> Since Google is =93safe=94 (due the =93deviation=94 from the spec) I = would >>> take Google as example here (I could point out open redirector in = the >>> wild to proof my point but I will not do=85) >>>=20 >>> Let=92s start from scratch=85 >>>=20 >>> If Google would have something like >>> http://www.google.com?goto=3Dattacker.com this is without any doubt = an >>> open redirector=85 see also OWASP 10 [0]. >>>=20 >>> Now if Google would have implemented the spec rfc6749 verbatim >>> something like >>>=20 >>> = https://accounts.google.com/o/oauth2/auth?response_type=3Dcode&client_id=3D= 788732372078.apps.googleusercontent.com&scope=3DWRONG_SCOPE&redirect_uri=3D= http://attacker.com >>>=20 >>>=20 >>> would have redirect to http://attacker.com. >>>=20 >>> So why this is not an open redirect ? :) >>>=20 >>> Now maybe we are saying the same thing but I felt like better = explain >>> my point :) >>>=20 >>> regards >>>=20 >>> antonio >>>=20 >>> [0] >>> = https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_= Forwards >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Hans. >>>>=20 >>>> On 9/4/14, 9:50 AM, Antonio Sanso wrote: >>>>> Hi Hans, >>>>>=20 >>>>> I really fail to see how this can be addressed at registration = time >>>>> for cases where registration is unrestricted (namely all the big >>>>> Providers) >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt >>>>> wrote: >>>>>=20 >>>>>> Classifying like this must also mean that consent should not be >>>>>> stored until the client is considered (admin) trusted, and admin >>>>>> policy would interfere with user policy. >>>>>>=20 >>>>>> IMHO the security consideration would apply only to dynamically >>>>>> registered clients where registration is unrestricted; any other >>>>>> form would involve some form of admin/user approval at = registration >>>>>> time, overcoming the concern at authorization time: there's no >>>>>> auto-redirect flow possible for unknown clients. >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>> I think this advice isn't a bad idea, though it's of course up = to >>>>>>> the AS >>>>>>> what an "untrusted" client really is. In practice, this is = something >>>>>>> that was registered by a non-sysadmin type person, either a >>>>>>> dynamically >>>>>>> registered client or something available through self-service >>>>>>> registration of some type. It's also reasonable that a client, = even >>>>>>> dynamically registered, would be considered "trusted" if enough >>>>>>> time has >>>>>>> passed and enough users have used it without things blowing up. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>> > wrote: >>>>>>>=20 >>>>>>>> hi again *, >>>>>>>>=20 >>>>>>>> after thinking a bit further IMHO an alternative for the = untrusted >>>>>>>> clients can also be to always present the consent screen (at = least >>>>>>>> once) before any redirect. >>>>>>>> Namely all providers I have seen show the consent screen if all = the >>>>>>>> request parameters are correct and if the user accepts the = redirect >>>>>>>> happens. >>>>>>>> If one of the parameter (with the exclusion of the client id = and >>>>>>>> redirect uri that are handled differently as for spec) is wrong >>>>>>>> though >>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>=20 >>>>>>>> WDYT? >>>>>>>>=20 >>>>>>>> regards >>>>>>>>=20 >>>>>>>> antonio >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> Well, >>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>> let=92s talk about real use cases, namely e.g. Google , = Facebook , >>>>>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>>>>=20 >>>>>>>>> Said that what the other guys think? :) >>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there = is a >>>>>>>>> reason >>>>>>>>> if Google is by choice =93violating=94 the spec right? (I = assume to >>>>>>>>> avoid >>>>>>>>> open redirect=85) >>>>>>>>> But other implementers do follow the spec hence they have this = open >>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Is your concern clients that were registered using dynamic >>>>>>>>>>>> client >>>>>>>>>>>> registration? >>>>>>>>>>>=20 >>>>>>>>>>> yes >>>>>>>>>>=20 >>>>>>>>>> I think your issue is then with the trust model of dynamic = client >>>>>>>>>> registration; that is left out of scope of the dynreg spec = (and >>>>>>>>>> the >>>>>>>>>> concept is not even part of the core spec), but unless you = want >>>>>>>>>> everything to be open (which typically would not be the = case), >>>>>>>>>> then >>>>>>>>>> it would involve approval somewhere in the process before the >>>>>>>>>> client >>>>>>>>>> is registered. Without dynamic client registration that >>>>>>>>>> approval is >>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>=20 >>>>>>>>>>>> Otherwise the positive case is returning a response to a >>>>>>>>>>>> valid URL >>>>>>>>>>>> that belongs to a client that was registered explicitly by = the >>>>>>>>>>>> resource owner >>>>>>>>>>>=20 >>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>>=20 >>>>>>>>>> roles can collapse in use cases especially when using dynamic >>>>>>>>>> client >>>>>>>>>> registration >>>>>>>>>>=20 >>>>>>>>>>>> and the negative case is returning an error to that same = URL. >>>>>>>>>>>=20 >>>>>>>>>>> the difference is the consent screen=85 in the positive case = you >>>>>>>>>>> need >>>>>>>>>>> to approve an app.. for the error case no approval is = needed,,, >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>=20 >>>>>>>>>>> why? >>>>>>>>>>=20 >>>>>>>>>> because the client and thus the fixed URL are explicitly >>>>>>>>>> approved at >>>>>>>>>> some point >>>>>>>>>>=20 >>>>>>>>>> Hans. >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hans. >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>> >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Let me try and approach this from a different angle: why >>>>>>>>>>>>>> would you >>>>>>>>>>>>>> call it an open redirect when an invalid scope is = provided and >>>>>>>>>>>>>> call it >>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope = is >>>>>>>>>>>>>> provided? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> as specified below in the positive case (namely when the >>>>>>>>>>>>> correct >>>>>>>>>>>>> scope >>>>>>>>>>>>> is provided) the resource owner MUST approve the app via = the >>>>>>>>>>>>> consent >>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley = >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the = attacker. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The issue is that the AS may be allowing client >>>>>>>>>>>>>>>> registrations with >>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a >>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I think that if anything it may be the registration = step >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. = It >>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, = namely >>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the >>>>>>>>>>>>>>> spec so >>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke = >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid = in >>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are = vulnerable >>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or >>>>>>>>>>>>>>>>>> mismatching >>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is = missing or >>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource >>>>>>>>>>>>>>>>>> owner of the >>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the >>>>>>>>>>>>>>>>>> user-agent to the >>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if = the >>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>> the authorization server informs the client by adding = the >>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>> parameters to the query component of the redirection = URI >>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, = perAppendix B >>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am >>>>>>>>>>>>>>>>>> redirected >>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters = are >>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve = the >>>>>>>>>>>>>>>>>> app >>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than >>>>>>>>>>>>>>>>>> redirect >>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> [0] = https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>> hzandbelt@pingidentity.com = >>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>> Identity >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>>> Ping Identity >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>> Ping >>>>>>>>>> Identity >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>=20 >>>>=20 >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping Identity >>>=20 >>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_86C3155F-D1D9-472A-B115-D7B19F5773B0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MDQxMjIyMDNaMCMGCSqGSIb3DQEJBDEWBBSCyZY0Y9Za6UgIkrD7t+eB qtkpKDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBo/7T40sPBE63OST7op7rxuUMiM97tRlq6z28L/OZdWOJxWCoajMk8 EnTQOv4vNgCB4vXWlQ8HLzCxQuMzc9ldC5ypfhilqvpstE9Odv+0/Ag8h+S1VbP2uDb7V1k2a5ME DKV6geAvw9IA7ZoIiD0s9UYabCtK9HFlkJ0m6Y0hhncXrKPoq6FsVLZu2FM3ePtXUrdPmTp2ceIX sZHnjzTPr/Xg0gB+l2EL/bolzpK/kwjrMusB4aVhcv68AChG+6RrG5a492dQx1ncu5d55AHQA/q8 MSnj0m9qikkAh21jeV0sRWVfc4PRctp8sP5Qo4jjF5VFkgW+8yaaYFVo9knjAAAAAAAA --Apple-Mail=_86C3155F-D1D9-472A-B115-D7B19F5773B0-- From nobody Thu Sep 4 05:28:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87C51A8854 for ; Thu, 4 Sep 2014 05:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 s2vPKUzsK82n for ; Thu, 4 Sep 2014 05:28:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D5E1A884C for ; Thu, 4 Sep 2014 05:28:22 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 4 Sep 2014 12:28:13 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.144]) with mapi id 15.00.1015.018; Thu, 4 Sep 2014 12:28:13 +0000 From: Antonio Sanso To: John Bradley Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgAAS64CAAC5/AIAAA86AgAADE4CAAAOIgIAAAceA Date: Thu, 4 Sep 2014 12:28:12 +0000 Message-ID: <1F5FCE81-FA5B-4D04-9526-42A5ECD484F1@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <540829AF.9030804@pingidentity.com> <540853E1.3090102@pingidentity.com> <54085675.3060507@pingidentity.com> In-Reply-To: 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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(51704005)(479174003)(199003)(24454002)(51444003)(189002)(99396002)(66066001)(50986999)(79102001)(16799955002)(83322001)(81542001)(19580395003)(33656002)(31966008)(19580405001)(4396001)(82746002)(20776003)(46102001)(83072002)(15202345003)(106356001)(106116001)(107046002)(2656002)(110136001)(83716003)(74662001)(15975445006)(105586002)(90102001)(587094003)(16601075003)(76176999)(101416001)(87936001)(92566001)(85852003)(85306004)(76482001)(99286002)(92726001)(36756003)(64706001)(77982001)(21056001)(15395725005)(74502001)(93886004)(86362001)(77096002)(81342001)(80022001)(54356999)(95666004)(104396001)(16940595002)(387795003)(235135003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Lka5ru6_AUWy1Pbel_5ZmRK4ncE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:28:25 -0000 On Sep 4, 2014, at 2:22 PM, John Bradley wrote: > Registration requiring a valid email address is not sufficient to stop a = "bad" person from registering a client that appears to be perfectly legitim= ate but is later used as a redirect. totally agree! >=20 > So it is a bit slippery to differentiate good from bad. >=20 > In general clearing the referrer and fragment from incoming requests is a= good practice on redirects to prevent leakage of information across the re= direct. +1 >=20 > The other concern is using the redirect as part of a phishing attack to m= ake the target site look more legitimate. > That is a more complicated problem unless you validate every client by lo= oking at them to make sure they are not bad in some way. and here it comes the "error 400" or the "always show the consent screen= =94 approach regards antonio >=20 > John B. >=20 >=20 > On Sep 4, 2014, at 2:09 PM, Hans Zandbelt wr= ote: >=20 >> Maybe just to clarify my point: where did the client_id in the example t= hat you gave come from? >>=20 >> Hans. >>=20 >> On 9/4/14, 1:58 PM, Hans Zandbelt wrote: >>> yes, you are right about the unrestricted client use case; I just got >>> caught by the fact that you were talking about *unrestricted* client >>> registration all the time (standards-based or not) which deserves extra >>> caution whereas Google (and the spec) also provides *restricted* client >>> registration the deviation or caution is not needed >>>=20 >>> Hans. >>>=20 >>> On 9/4/14, 1:44 PM, Antonio Sanso wrote: >>>> hi Hans >>>>=20 >>>> On Sep 4, 2014, at 10:58 AM, Hans Zandbelt >>>> wrote: >>>>=20 >>>>> Agreed, I see you point about the big providers using exactly the >>>>> unrestricted flow for which the trust model (by definition) is out of >>>>> scope of the spec. This may be the reason for the implemented >>>>> behavior indeed and a security consideration is a good idea for other >>>>> deployments; there's not much more that can be done. >>>>>=20 >>>>> But Google also provides explicit registration for API clients (which >>>>> is where my mind was): >>>>> https://developers.google.com/accounts/docs/OAuth2 (step 1) >>>>> and they would not need to deviate from the spec for that, nor would >>>>> the spec need to change >>>>=20 >>>> I do really struggle to understand your point here :) (at least the >>>> "nor would the spec need to change part" :)). >>>>=20 >>>> Probably I need to explain myself better. >>>> Since Google is =93safe=94 (due the =93deviation=94 from the spec) I w= ould >>>> take Google as example here (I could point out open redirector in the >>>> wild to proof my point but I will not do=85) >>>>=20 >>>> Let=92s start from scratch=85 >>>>=20 >>>> If Google would have something like >>>> http://www.google.com?goto=3Dattacker.com this is without any doubt an >>>> open redirector=85 see also OWASP 10 [0]. >>>>=20 >>>> Now if Google would have implemented the spec rfc6749 verbatim >>>> something like >>>>=20 >>>> https://accounts.google.com/o/oauth2/auth?response_type=3Dcode&client_= id=3D788732372078.apps.googleusercontent.com&scope=3DWRONG_SCOPE&redirect_u= ri=3Dhttp://attacker.com >>>>=20 >>>>=20 >>>> would have redirect to http://attacker.com. >>>>=20 >>>> So why this is not an open redirect ? :) >>>>=20 >>>> Now maybe we are saying the same thing but I felt like better explain >>>> my point :) >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>> [0] >>>> https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_= and_Forwards >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> On 9/4/14, 9:50 AM, Antonio Sanso wrote: >>>>>> Hi Hans, >>>>>>=20 >>>>>> I really fail to see how this can be addressed at registration time >>>>>> for cases where registration is unrestricted (namely all the big >>>>>> Providers) >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> antonio >>>>>>=20 >>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt >>>>>> wrote: >>>>>>=20 >>>>>>> Classifying like this must also mean that consent should not be >>>>>>> stored until the client is considered (admin) trusted, and admin >>>>>>> policy would interfere with user policy. >>>>>>>=20 >>>>>>> IMHO the security consideration would apply only to dynamically >>>>>>> registered clients where registration is unrestricted; any other >>>>>>> form would involve some form of admin/user approval at registration >>>>>>> time, overcoming the concern at authorization time: there's no >>>>>>> auto-redirect flow possible for unknown clients. >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>> I think this advice isn't a bad idea, though it's of course up to >>>>>>>> the AS >>>>>>>> what an "untrusted" client really is. In practice, this is somethi= ng >>>>>>>> that was registered by a non-sysadmin type person, either a >>>>>>>> dynamically >>>>>>>> registered client or something available through self-service >>>>>>>> registration of some type. It's also reasonable that a client, eve= n >>>>>>>> dynamically registered, would be considered "trusted" if enough >>>>>>>> time has >>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> hi again *, >>>>>>>>>=20 >>>>>>>>> after thinking a bit further IMHO an alternative for the untruste= d >>>>>>>>> clients can also be to always present the consent screen (at leas= t >>>>>>>>> once) before any redirect. >>>>>>>>> Namely all providers I have seen show the consent screen if all t= he >>>>>>>>> request parameters are correct and if the user accepts the redire= ct >>>>>>>>> happens. >>>>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>>>> redirect uri that are handled differently as for spec) is wrong >>>>>>>>> though >>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>=20 >>>>>>>>> WDYT? >>>>>>>>>=20 >>>>>>>>> regards >>>>>>>>>=20 >>>>>>>>> antonio >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> Well, >>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , Facebook= , >>>>>>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>>>>>=20 >>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there is = a >>>>>>>>>> reason >>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I assume= to >>>>>>>>>> avoid >>>>>>>>>> open redirect=85) >>>>>>>>>> But other implementers do follow the spec hence they have this o= pen >>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Is your concern clients that were registered using dynamic >>>>>>>>>>>>> client >>>>>>>>>>>>> registration? >>>>>>>>>>>>=20 >>>>>>>>>>>> yes >>>>>>>>>>>=20 >>>>>>>>>>> I think your issue is then with the trust model of dynamic clie= nt >>>>>>>>>>> registration; that is left out of scope of the dynreg spec (and >>>>>>>>>>> the >>>>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>>>> everything to be open (which typically would not be the case), >>>>>>>>>>> then >>>>>>>>>>> it would involve approval somewhere in the process before the >>>>>>>>>>> client >>>>>>>>>>> is registered. Without dynamic client registration that >>>>>>>>>>> approval is >>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>=20 >>>>>>>>>>>>> Otherwise the positive case is returning a response to a >>>>>>>>>>>>> valid URL >>>>>>>>>>>>> that belongs to a client that was registered explicitly by th= e >>>>>>>>>>>>> resource owner >>>>>>>>>>>>=20 >>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>>>=20 >>>>>>>>>>> roles can collapse in use cases especially when using dynamic >>>>>>>>>>> client >>>>>>>>>>> registration >>>>>>>>>>>=20 >>>>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>>>=20 >>>>>>>>>>>> the difference is the consent screen=85 in the positive case y= ou >>>>>>>>>>>> need >>>>>>>>>>>> to approve an app.. for the error case no approval is needed,,= , >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>=20 >>>>>>>>>>>> why? >>>>>>>>>>>=20 >>>>>>>>>>> because the client and thus the fixed URL are explicitly >>>>>>>>>>> approved at >>>>>>>>>>> some point >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hans. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Let me try and approach this from a different angle: why >>>>>>>>>>>>>>> would you >>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provided = and >>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> as specified below in the positive case (namely when the >>>>>>>>>>>>>> correct >>>>>>>>>>>>>> scope >>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via the >>>>>>>>>>>>>> consent >>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client >>>>>>>>>>>>>>>>> registrations with >>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a >>>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I think that if anything it may be the registration step >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It >>>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namel= y >>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the >>>>>>>>>>>>>>>> spec so >>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnera= ble >>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or >>>>>>>>>>>>>>>>>>> mismatching >>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing= or >>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource >>>>>>>>>>>>>>>>>>> owner of the >>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the >>>>>>>>>>>>>>>>>>> user-agent to the >>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if t= he >>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding t= he >>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection UR= I >>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix= B >>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am >>>>>>>>>>>>>>>>>>> redirected >>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client= _id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dh= ttp://attacker.com >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters ar= e >>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve t= he >>>>>>>>>>>>>>>>>>> app >>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than >>>>>>>>>>>>>>>>>>> redirect >>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>> Ping >>>>>>>>>>> Identity >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>=20 >>>=20 >>=20 >> --=20 >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Thu Sep 4 05:29:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4E1A886D for ; Thu, 4 Sep 2014 05:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=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 nfBRVw1veSDK for ; Thu, 4 Sep 2014 05:29:14 -0700 (PDT) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328E51A8861 for ; Thu, 4 Sep 2014 05:29:14 -0700 (PDT) Received: from mail-wg0-f47.google.com ([74.125.82.47]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKVAhbGf5iCjHp/BrWW/VYLoeucBeZXkP8@postini.com; Thu, 04 Sep 2014 05:29:14 PDT Received: by mail-wg0-f47.google.com with SMTP id z12so9900112wgg.6 for ; Thu, 04 Sep 2014 05:29:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=i6oE4UCAaM8ap5CpZZbBCGPqkpgXpFUa8zEoGERbfhs=; b=O9Is5cK/VJmkJV/dJ57ahuReVcxpc3svtp9JnzmSCsvclIpYgV0SJLSrJArS3kctYg o0z/mRP7oGRjCxKDXf8NwAwWgvrRQtgr/0IROOlMvWSKV6FAB3QX3qJ48nDBS64KGcfo JHQOOw8UaoiGSgFPij1/C+1a89cnFd4+NHf6nts5JmLK15XpoREKw41wUOnuB1Gu9r5t hOHBdsMmobqCXDjnFE8Nk/MjDZhA5HLuM6slN1Smyr1Mmc2bIJ8IX683TmzmY6g0hD5k zLjHYaPTe6iXyXIPCooz/kRCqDP3DhRG/x8GJWm6MOPTu5XDQqGisRHF3rTJHNRXG3XA o9DA== X-Gm-Message-State: ALoCoQliobY6/2tXGJ14uPAhEsbrXGjpFCy/0aPZVlgem92k/s8ZRzojCbGfqtq11NieIrIUQ2iZMLZjho/+5YfJDS2Y6aWD8Pl79AdmlSdBejt0cGvTgfpDlcpwkqfyp8w0s+afDR8C X-Received: by 10.194.174.4 with SMTP id bo4mr5565580wjc.84.1409833752693; Thu, 04 Sep 2014 05:29:12 -0700 (PDT) X-Received: by 10.194.174.4 with SMTP id bo4mr5565547wjc.84.1409833752414; Thu, 04 Sep 2014 05:29:12 -0700 (PDT) Received: from [192.168.10.102] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id bg10sm19212321wjc.47.2014.09.04.05.29.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 05:29:11 -0700 (PDT) Message-ID: <54085B16.5000001@pingidentity.com> Date: Thu, 04 Sep 2014 14:29:10 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Bradley References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <540829AF.9030804@pingidentity.com> <540853E1.3090102@pingidentity.com> <54085675.3060507@pingidentity.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hsW-oSixSKahGiEu-P02smlwQ5o Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:29:17 -0000 exactly, but my point would be that the attacker needs to have an relationship/account with the OP; this is where the approval is and I agree with Antonio/you that that is tricky for consumer ASs and deserves a warning Hans. On 9/4/14, 2:22 PM, John Bradley wrote: > Registration requiring a valid email address is not sufficient to stop a "bad" person from registering a client that appears to be perfectly legitimate but is later used as a redirect. > > So it is a bit slippery to differentiate good from bad. > > In general clearing the referrer and fragment from incoming requests is a good practice on redirects to prevent leakage of information across the redirect. > > The other concern is using the redirect as part of a phishing attack to make the target site look more legitimate. > That is a more complicated problem unless you validate every client by looking at them to make sure they are not bad in some way. > > John B. > > > On Sep 4, 2014, at 2:09 PM, Hans Zandbelt wrote: > >> Maybe just to clarify my point: where did the client_id in the example that you gave come from? >> >> Hans. >> >> On 9/4/14, 1:58 PM, Hans Zandbelt wrote: >>> yes, you are right about the unrestricted client use case; I just got >>> caught by the fact that you were talking about *unrestricted* client >>> registration all the time (standards-based or not) which deserves extra >>> caution whereas Google (and the spec) also provides *restricted* client >>> registration the deviation or caution is not needed >>> >>> Hans. >>> >>> On 9/4/14, 1:44 PM, Antonio Sanso wrote: >>>> hi Hans >>>> >>>> On Sep 4, 2014, at 10:58 AM, Hans Zandbelt >>>> wrote: >>>> >>>>> Agreed, I see you point about the big providers using exactly the >>>>> unrestricted flow for which the trust model (by definition) is out of >>>>> scope of the spec. This may be the reason for the implemented >>>>> behavior indeed and a security consideration is a good idea for other >>>>> deployments; there's not much more that can be done. >>>>> >>>>> But Google also provides explicit registration for API clients (which >>>>> is where my mind was): >>>>> https://developers.google.com/accounts/docs/OAuth2 (step 1) >>>>> and they would not need to deviate from the spec for that, nor would >>>>> the spec need to change >>>> >>>> I do really struggle to understand your point here :) (at least the >>>> "nor would the spec need to change part" :)). >>>> >>>> Probably I need to explain myself better. >>>> Since Google is “safe” (due the “deviation” from the spec) I would >>>> take Google as example here (I could point out open redirector in the >>>> wild to proof my point but I will not do…) >>>> >>>> Let’s start from scratch… >>>> >>>> If Google would have something like >>>> http://www.google.com?goto=attacker.com this is without any doubt an >>>> open redirector… see also OWASP 10 [0]. >>>> >>>> Now if Google would have implemented the spec rfc6749 verbatim >>>> something like >>>> >>>> https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>> >>>> >>>> would have redirect to http://attacker.com. >>>> >>>> So why this is not an open redirect ? :) >>>> >>>> Now maybe we are saying the same thing but I felt like better explain >>>> my point :) >>>> >>>> regards >>>> >>>> antonio >>>> >>>> [0] >>>> https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards >>>> >>>> >>>> >>>>> >>>>> Hans. >>>>> >>>>> On 9/4/14, 9:50 AM, Antonio Sanso wrote: >>>>>> Hi Hans, >>>>>> >>>>>> I really fail to see how this can be addressed at registration time >>>>>> for cases where registration is unrestricted (namely all the big >>>>>> Providers) >>>>>> >>>>>> regards >>>>>> >>>>>> antonio >>>>>> >>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt >>>>>> wrote: >>>>>> >>>>>>> Classifying like this must also mean that consent should not be >>>>>>> stored until the client is considered (admin) trusted, and admin >>>>>>> policy would interfere with user policy. >>>>>>> >>>>>>> IMHO the security consideration would apply only to dynamically >>>>>>> registered clients where registration is unrestricted; any other >>>>>>> form would involve some form of admin/user approval at registration >>>>>>> time, overcoming the concern at authorization time: there's no >>>>>>> auto-redirect flow possible for unknown clients. >>>>>>> >>>>>>> Hans. >>>>>>> >>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>> I think this advice isn't a bad idea, though it's of course up to >>>>>>>> the AS >>>>>>>> what an "untrusted" client really is. In practice, this is something >>>>>>>> that was registered by a non-sysadmin type person, either a >>>>>>>> dynamically >>>>>>>> registered client or something available through self-service >>>>>>>> registration of some type. It's also reasonable that a client, even >>>>>>>> dynamically registered, would be considered "trusted" if enough >>>>>>>> time has >>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>> > wrote: >>>>>>>> >>>>>>>>> hi again *, >>>>>>>>> >>>>>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>>>>> clients can also be to always present the consent screen (at least >>>>>>>>> once) before any redirect. >>>>>>>>> Namely all providers I have seen show the consent screen if all the >>>>>>>>> request parameters are correct and if the user accepts the redirect >>>>>>>>> happens. >>>>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>>>> redirect uri that are handled differently as for spec) is wrong >>>>>>>>> though >>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>> >>>>>>>>> WDYT? >>>>>>>>> >>>>>>>>> regards >>>>>>>>> >>>>>>>>> antonio >>>>>>>>> >>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Well, >>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook , >>>>>>>>>> etc.. is that dynamic client registration? I do not know… :) >>>>>>>>>> >>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>> Would this deserve some “spec adjustment” ? I mean there is a >>>>>>>>>> reason >>>>>>>>>> if Google is by choice “violating” the spec right? (I assume to >>>>>>>>>> avoid >>>>>>>>>> open redirect…) >>>>>>>>>> But other implementers do follow the spec hence they have this open >>>>>>>>>> redirector… and this is not nice IMHO... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Is your concern clients that were registered using dynamic >>>>>>>>>>>>> client >>>>>>>>>>>>> registration? >>>>>>>>>>>> >>>>>>>>>>>> yes >>>>>>>>>>> >>>>>>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>>>>>> registration; that is left out of scope of the dynreg spec (and >>>>>>>>>>> the >>>>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>>>> everything to be open (which typically would not be the case), >>>>>>>>>>> then >>>>>>>>>>> it would involve approval somewhere in the process before the >>>>>>>>>>> client >>>>>>>>>>> is registered. Without dynamic client registration that >>>>>>>>>>> approval is >>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>> >>>>>>>>>>>>> Otherwise the positive case is returning a response to a >>>>>>>>>>>>> valid URL >>>>>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>>>>> resource owner >>>>>>>>>>>> >>>>>>>>>>>> well AFAIK the resource owner doesn’t register clients… >>>>>>>>>>> >>>>>>>>>>> roles can collapse in use cases especially when using dynamic >>>>>>>>>>> client >>>>>>>>>>> registration >>>>>>>>>>> >>>>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>>> >>>>>>>>>>>> the difference is the consent screen… in the positive case you >>>>>>>>>>>> need >>>>>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>> >>>>>>>>>>>> why? >>>>>>>>>>> >>>>>>>>>>> because the client and thus the fixed URL are explicitly >>>>>>>>>>> approved at >>>>>>>>>>> some point >>>>>>>>>>> >>>>>>>>>>> Hans. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hans. >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Let me try and approach this from a different angle: why >>>>>>>>>>>>>>> would you >>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>> >>>>>>>>>>>>>> as specified below in the positive case (namely when the >>>>>>>>>>>>>> correct >>>>>>>>>>>>>> scope >>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via the >>>>>>>>>>>>>> consent >>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client >>>>>>>>>>>>>>>>> registrations with >>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a >>>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think that if anything it may be the registration step >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It >>>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>>> pretty unpractical to block this at registration time…. >>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *400.* That’s an error. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the >>>>>>>>>>>>>>>> spec so >>>>>>>>>>>>>>>> far…. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or >>>>>>>>>>>>>>>>>>> mismatching >>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource >>>>>>>>>>>>>>>>>>> owner of the >>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the >>>>>>>>>>>>>>>>>>> user-agent to the >>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Now let’s assume this. >>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am >>>>>>>>>>>>>>>>>>> redirected >>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the >>>>>>>>>>>>>>>>>>> app >>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than >>>>>>>>>>>>>>>>>>> redirect >>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>> Ping Identity >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>> Ping >>>>>>>>>>> Identity >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>> >>>>> >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>> >>> >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Thu Sep 4 05:44:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C427E1A887B for ; Thu, 4 Sep 2014 05:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 P4IGamsJJdeP for ; Thu, 4 Sep 2014 05:44:09 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4ED1A8868 for ; Thu, 4 Sep 2014 05:44:08 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id z12so9895280wgg.18 for ; Thu, 04 Sep 2014 05:44:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=750DEiQeq1NmMqbIsRH6i2aUZv5SOxKjJ4pIfGRNDBU=; b=CSLwKWlv+b63kD0gMotWxaNWFPDCfh443TegNNiqBFxdTtDixwZpnypzpwCkQy8esn py/yke0gbh25AzGndTU41I98jog5d/b05xYVCpPOSXFZpgiskhv75PIGNYVqXvoIW6Rf tTnCuxzTMMnTD7AonF6hoBE8HaptdJhAU25rhua0nVcuTlaySfMR0ez3bXLPd+aUnu6B IruIVgnOU67vPH/8EijVZmos5+BrHDKGE0RWnD5YqUgzySyTyt0SQPJnWiNhHyqj4Qu2 Z4Sd0v6Vqp2l4Fi7aOiHYb34yvH6SHW4A1CD86GC1z9V62fpI9Tuusop/4YB59X9C2El W+0g== X-Gm-Message-State: ALoCoQnpqQVYLBDvCQH+a6tpflToXFy88VgSlhDsgRbD1yXBfR/MzpAO7fnl5hYko8zgRh/UZ8Pl X-Received: by 10.194.202.231 with SMTP id kl7mr5579424wjc.134.1409834647229; Thu, 04 Sep 2014 05:44:07 -0700 (PDT) Received: from host-101-0.eduroamers.nl (host-101-0.eduroamers.nl. [145.96.0.101]) by mx.google.com with ESMTPSA id cw6sm19335748wjb.18.2014.09.04.05.44.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 05:44:06 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2488B34F-2095-4836-AB01-A04F1CEE3831"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <54085B16.5000001@pingidentity.com> Date: Thu, 4 Sep 2014 14:44:04 +0200 Message-Id: <0D64CB33-1ED1-4780-8BBD-1DADB80DE24B@ve7jtb.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <540829AF.9030804@pingidentity.com> <540853E1.3090102@pingidentity.com> <54085675.3060507@pingidentity.com> <54085B16.5000001@pingidentity.com> To: Hans Zandbelt X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qKkp_EdOIdwTk0_BQ5wMjxL2eOQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:44:12 -0000 --Apple-Mail=_2488B34F-2095-4836-AB01-A04F1CEE3831 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In a enterprise case likely there is some trusted relationship. In the Web 2.0 API economy case there is a tension between providers = wanting the maximum number of users and validating the developer = registering the client. Often having a email someplace is sufficient to register a client. That = is not a particularly high bar if you are someone intent on hacking or = phishing. Each AS is going to have some different policy regarding the vetting of = clients/developers. So AS need to take appropriate precautions based on there policies. John B. On Sep 4, 2014, at 2:29 PM, Hans Zandbelt = wrote: > exactly, but my point would be that the attacker needs to have an = relationship/account with the OP; this is where the approval is and I = agree with Antonio/you that that is tricky for consumer ASs and deserves = a warning >=20 > Hans. >=20 > On 9/4/14, 2:22 PM, John Bradley wrote: >> Registration requiring a valid email address is not sufficient to = stop a "bad" person from registering a client that appears to be = perfectly legitimate but is later used as a redirect. >>=20 >> So it is a bit slippery to differentiate good from bad. >>=20 >> In general clearing the referrer and fragment from incoming requests = is a good practice on redirects to prevent leakage of information across = the redirect. >>=20 >> The other concern is using the redirect as part of a phishing attack = to make the target site look more legitimate. >> That is a more complicated problem unless you validate every client = by looking at them to make sure they are not bad in some way. >>=20 >> John B. >>=20 >>=20 >> On Sep 4, 2014, at 2:09 PM, Hans Zandbelt = wrote: >>=20 >>> Maybe just to clarify my point: where did the client_id in the = example that you gave come from? >>>=20 >>> Hans. >>>=20 >>> On 9/4/14, 1:58 PM, Hans Zandbelt wrote: >>>> yes, you are right about the unrestricted client use case; I just = got >>>> caught by the fact that you were talking about *unrestricted* = client >>>> registration all the time (standards-based or not) which deserves = extra >>>> caution whereas Google (and the spec) also provides *restricted* = client >>>> registration the deviation or caution is not needed >>>>=20 >>>> Hans. >>>>=20 >>>> On 9/4/14, 1:44 PM, Antonio Sanso wrote: >>>>> hi Hans >>>>>=20 >>>>> On Sep 4, 2014, at 10:58 AM, Hans Zandbelt >>>>> wrote: >>>>>=20 >>>>>> Agreed, I see you point about the big providers using exactly the >>>>>> unrestricted flow for which the trust model (by definition) is = out of >>>>>> scope of the spec. This may be the reason for the implemented >>>>>> behavior indeed and a security consideration is a good idea for = other >>>>>> deployments; there's not much more that can be done. >>>>>>=20 >>>>>> But Google also provides explicit registration for API clients = (which >>>>>> is where my mind was): >>>>>> https://developers.google.com/accounts/docs/OAuth2 (step 1) >>>>>> and they would not need to deviate from the spec for that, nor = would >>>>>> the spec need to change >>>>>=20 >>>>> I do really struggle to understand your point here :) (at least = the >>>>> "nor would the spec need to change part" :)). >>>>>=20 >>>>> Probably I need to explain myself better. >>>>> Since Google is =93safe=94 (due the =93deviation=94 from the spec) = I would >>>>> take Google as example here (I could point out open redirector in = the >>>>> wild to proof my point but I will not do=85) >>>>>=20 >>>>> Let=92s start from scratch=85 >>>>>=20 >>>>> If Google would have something like >>>>> http://www.google.com?goto=3Dattacker.com this is without any = doubt an >>>>> open redirector=85 see also OWASP 10 [0]. >>>>>=20 >>>>> Now if Google would have implemented the spec rfc6749 verbatim >>>>> something like >>>>>=20 >>>>> = https://accounts.google.com/o/oauth2/auth?response_type=3Dcode&client_id=3D= 788732372078.apps.googleusercontent.com&scope=3DWRONG_SCOPE&redirect_uri=3D= http://attacker.com >>>>>=20 >>>>>=20 >>>>> would have redirect to http://attacker.com. >>>>>=20 >>>>> So why this is not an open redirect ? :) >>>>>=20 >>>>> Now maybe we are saying the same thing but I felt like better = explain >>>>> my point :) >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>> [0] >>>>> = https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_= Forwards >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>> On 9/4/14, 9:50 AM, Antonio Sanso wrote: >>>>>>> Hi Hans, >>>>>>>=20 >>>>>>> I really fail to see how this can be addressed at registration = time >>>>>>> for cases where registration is unrestricted (namely all the big >>>>>>> Providers) >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Classifying like this must also mean that consent should not be >>>>>>>> stored until the client is considered (admin) trusted, and = admin >>>>>>>> policy would interfere with user policy. >>>>>>>>=20 >>>>>>>> IMHO the security consideration would apply only to dynamically >>>>>>>> registered clients where registration is unrestricted; any = other >>>>>>>> form would involve some form of admin/user approval at = registration >>>>>>>> time, overcoming the concern at authorization time: there's no >>>>>>>> auto-redirect flow possible for unknown clients. >>>>>>>>=20 >>>>>>>> Hans. >>>>>>>>=20 >>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>> I think this advice isn't a bad idea, though it's of course up = to >>>>>>>>> the AS >>>>>>>>> what an "untrusted" client really is. In practice, this is = something >>>>>>>>> that was registered by a non-sysadmin type person, either a >>>>>>>>> dynamically >>>>>>>>> registered client or something available through self-service >>>>>>>>> registration of some type. It's also reasonable that a client, = even >>>>>>>>> dynamically registered, would be considered "trusted" if = enough >>>>>>>>> time has >>>>>>>>> passed and enough users have used it without things blowing = up. >>>>>>>>>=20 >>>>>>>>> -- Justin >>>>>>>>>=20 >>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> hi again *, >>>>>>>>>>=20 >>>>>>>>>> after thinking a bit further IMHO an alternative for the = untrusted >>>>>>>>>> clients can also be to always present the consent screen (at = least >>>>>>>>>> once) before any redirect. >>>>>>>>>> Namely all providers I have seen show the consent screen if = all the >>>>>>>>>> request parameters are correct and if the user accepts the = redirect >>>>>>>>>> happens. >>>>>>>>>> If one of the parameter (with the exclusion of the client id = and >>>>>>>>>> redirect uri that are handled differently as for spec) is = wrong >>>>>>>>>> though >>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>=20 >>>>>>>>>> WDYT? >>>>>>>>>>=20 >>>>>>>>>> regards >>>>>>>>>>=20 >>>>>>>>>> antonio >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> Well, >>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , = Facebook , >>>>>>>>>>> etc.. is that dynamic client registration? I do not know=85 = :) >>>>>>>>>>>=20 >>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there = is a >>>>>>>>>>> reason >>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I = assume to >>>>>>>>>>> avoid >>>>>>>>>>> open redirect=85) >>>>>>>>>>> But other implementers do follow the spec hence they have = this open >>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Is your concern clients that were registered using = dynamic >>>>>>>>>>>>>> client >>>>>>>>>>>>>> registration? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> yes >>>>>>>>>>>>=20 >>>>>>>>>>>> I think your issue is then with the trust model of dynamic = client >>>>>>>>>>>> registration; that is left out of scope of the dynreg spec = (and >>>>>>>>>>>> the >>>>>>>>>>>> concept is not even part of the core spec), but unless you = want >>>>>>>>>>>> everything to be open (which typically would not be the = case), >>>>>>>>>>>> then >>>>>>>>>>>> it would involve approval somewhere in the process before = the >>>>>>>>>>>> client >>>>>>>>>>>> is registered. Without dynamic client registration that >>>>>>>>>>>> approval is >>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>=20 >>>>>>>>>>>>>> Otherwise the positive case is returning a response to a >>>>>>>>>>>>>> valid URL >>>>>>>>>>>>>> that belongs to a client that was registered explicitly = by the >>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>=20 >>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>>>>=20 >>>>>>>>>>>> roles can collapse in use cases especially when using = dynamic >>>>>>>>>>>> client >>>>>>>>>>>> registration >>>>>>>>>>>>=20 >>>>>>>>>>>>>> and the negative case is returning an error to that same = URL. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> the difference is the consent screen=85 in the positive = case you >>>>>>>>>>>>> need >>>>>>>>>>>>> to approve an app.. for the error case no approval is = needed,,, >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> why? >>>>>>>>>>>>=20 >>>>>>>>>>>> because the client and thus the fixed URL are explicitly >>>>>>>>>>>> approved at >>>>>>>>>>>> some point >>>>>>>>>>>>=20 >>>>>>>>>>>> Hans. >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Let me try and approach this from a different angle: = why >>>>>>>>>>>>>>>> would you >>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is = provided and >>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid = scope is >>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> as specified below in the positive case (namely when the >>>>>>>>>>>>>>> correct >>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via = the >>>>>>>>>>>>>>> consent >>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley = >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the = attacker. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client >>>>>>>>>>>>>>>>>> registrations with >>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that = a >>>>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I think that if anything it may be the registration = step >>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with = you. It >>>>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>>>> pretty unpractical to block this at registration = time=85. >>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, = namely >>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the >>>>>>>>>>>>>>>>> spec so >>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke = >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be = valid in >>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states = this. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are = vulnerable >>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or >>>>>>>>>>>>>>>>>>>> mismatching >>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is = missing or >>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource >>>>>>>>>>>>>>>>>>>> owner of the >>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the >>>>>>>>>>>>>>>>>>>> user-agent to the >>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or = if the >>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>> the authorization server informs the client by = adding the >>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>> parameters to the query component of the = redirection URI >>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, = perAppendix B >>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I = am >>>>>>>>>>>>>>>>>>>> redirected >>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the = parameters are >>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST = approve the >>>>>>>>>>>>>>>>>>>> app >>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than >>>>>>>>>>>>>>>>>>>> redirect >>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> [0] = https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com = >>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>>> Ping >>>>>>>>>>>> Identity >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>=20 >>>>=20 >>>=20 >>> -- >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity --Apple-Mail=_2488B34F-2095-4836-AB01-A04F1CEE3831 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MDQxMjQ0MDRaMCMGCSqGSIb3DQEJBDEWBBRppXeDOf49JPUkvsglw7HB UwB0ljCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCdld2fRiYkPiBq3QI1y7AHMMQMAUsQMKvLNuvq9kM2by2T0Dtk+Obs YT2csutK9FpWMcyvGXzt0Hg5SOauAGuqWODktD+wP3icanFFvK4JoSNnH15rkAoyk7ylKWSCdsJh rrpEhtCFqhHCiJ8O7iYbm1yfIVHmBVwVTImFUXg2lnMu7O633yVvUYG4uFjG0xvpKOzk/bC3y8on y/jBBusmgJUbYPbMQ38Uk9MvahzmS3ldo8TYsS2MyvzE/+badxIzi74qNVRxpJBVS8826sdkTn+W 4a5KG5VnRAtVvTmOK6ctapreHGo1J0HUz2/K2/5wH5pNshVo4JhfMLs/yPReAAAAAAAA --Apple-Mail=_2488B34F-2095-4836-AB01-A04F1CEE3831-- From nobody Thu Sep 4 05:52:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8421A88A2 for ; Thu, 4 Sep 2014 05:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.115 X-Spam-Level: X-Spam-Status: No, score=-5.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hH2m2c_YaBYU for ; Thu, 4 Sep 2014 05:52:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 8679C1A88A5 for ; Thu, 4 Sep 2014 05:52:37 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s84CqaZb024872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 4 Sep 2014 08:52:37 -0400 Received: from [10.10.51.191] (vpn-51-191.rdu2.redhat.com [10.10.51.191]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s84CqZea007793 for ; Thu, 4 Sep 2014 08:52:36 -0400 Message-ID: <54086090.8080703@redhat.com> Date: Thu, 04 Sep 2014 08:52:32 -0400 From: Bill Burke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> In-Reply-To: <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-g-zDCn3aW-4Qx5sSaEEioUSWts Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:52:51 -0000 FWIW, Antonio convinced me and I'm going to change this in our IDM project. Thanks Antonio. What convinced me was that the user is probably expecting a login screen. Since there is this expectation, it might make it a little easier for the attacker to convince the user that a spoofed login screen is real. I know this issue can only happen with unrestricted registration, but, IMO, this proposed change doesn't really have much of an effect on usability and is even backward compatible with the current RFC. Wouldn't it better though to never do a redirect on an invalid request and just display an error page? On 9/4/2014 3:50 AM, Antonio Sanso wrote: > Hi Hans, > > I really fail to see how this can be addressed at registration time for cases where registration is unrestricted (namely all the big Providers) > > regards > > antonio > > On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: > >> Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy. >> >> IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients. >> >> Hans. >> >> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>> I think this advice isn't a bad idea, though it's of course up to the AS >>> what an "untrusted" client really is. In practice, this is something >>> that was registered by a non-sysadmin type person, either a dynamically >>> registered client or something available through self-service >>> registration of some type. It's also reasonable that a client, even >>> dynamically registered, would be considered "trusted" if enough time has >>> passed and enough users have used it without things blowing up. >>> >>> -- Justin >>> >>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >> > wrote: >>> >>>> hi again *, >>>> >>>> after thinking a bit further IMHO an alternative for the untrusted >>>> clients can also be to always present the consent screen (at least >>>> once) before any redirect. >>>> Namely all providers I have seen show the consent screen if all the >>>> request parameters are correct and if the user accepts the redirect >>>> happens. >>>> If one of the parameter (with the exclusion of the client id and >>>> redirect uri that are handled differently as for spec) is wrong though >>>> the redirect happens without the consent screen being shown.. >>>> >>>> WDYT? >>>> >>>> regards >>>> >>>> antonio >>>> >>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>> > wrote: >>>> >>>>> Well, >>>>> I do not know if this is only dynamic registration... >>>>> let’s talk about real use cases, namely e.g. Google , Facebook , >>>>> etc.. is that dynamic client registration? I do not know… :) >>>>> >>>>> Said that what the other guys think? :) >>>>> Would this deserve some “spec adjustment” ? I mean there is a reason >>>>> if Google is by choice “violating” the spec right? (I assume to avoid >>>>> open redirect…) >>>>> But other implementers do follow the spec hence they have this open >>>>> redirector… and this is not nice IMHO... >>>>> >>>>> >>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>> > wrote: >>>>> >>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>> >>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>> > wrote: >>>>>>> >>>>>>>> Is your concern clients that were registered using dynamic client >>>>>>>> registration? >>>>>>> >>>>>>> yes >>>>>> >>>>>> I think your issue is then with the trust model of dynamic client >>>>>> registration; that is left out of scope of the dynreg spec (and the >>>>>> concept is not even part of the core spec), but unless you want >>>>>> everything to be open (which typically would not be the case), then >>>>>> it would involve approval somewhere in the process before the client >>>>>> is registered. Without dynamic client registration that approval is >>>>>> admin based or resource owner based, depending on use case. >>>>>> >>>>>>>> Otherwise the positive case is returning a response to a valid URL >>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>> resource owner >>>>>>> >>>>>>> well AFAIK the resource owner doesn’t register clients… >>>>>> >>>>>> roles can collapse in use cases especially when using dynamic client >>>>>> registration >>>>>> >>>>>>>> and the negative case is returning an error to that same URL. >>>>>>> >>>>>>> the difference is the consent screen… in the positive case you need >>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>> >>>>>>>> >>>>>>>> I fail to see the open redirect. >>>>>>> >>>>>>> why? >>>>>> >>>>>> because the client and thus the fixed URL are explicitly approved at >>>>>> some point >>>>>> >>>>>> Hans. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Hans. >>>>>>>> >>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>> >>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Let me try and approach this from a different angle: why would you >>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>> call it >>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>> provided? >>>>>>>>> >>>>>>>>> as specified below in the positive case (namely when the correct >>>>>>>>> scope >>>>>>>>> is provided) the resource owner MUST approve the app via the consent >>>>>>>>> screen (at least once). >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hans. >>>>>>>>>> >>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>> hi John, >>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>> >>>>>>>>>>>> The issue is that the AS may be allowing client registrations with >>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>> >>>>>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>> >>>>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>>>> needs >>>>>>>>>>>> the security consideration. >>>>>>>>>>> >>>>>>>>>>> (this is the first time :p) but I do disagree with you. It would be >>>>>>>>>>> pretty unpractical to block this at registration time…. >>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>> returning >>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>> >>>>>>>>>>> *400.* That’s an error. >>>>>>>>>>> >>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>> >>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>>>>>>> >>>>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>>>> far…. >>>>>>>>>>> >>>>>>>>>>> regards >>>>>>>>>>> >>>>>>>>>>> antonio >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> John B. >>>>>>>>>>>> >>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>> order for a >>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>> >>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>> to open >>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>> request >>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>> following >>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>> using the >>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>> : >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now let’s assume this. >>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> provider. >>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> >. >>>>>>>>>>>>>> >>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>>>>>>> back to >>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>> >. >>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>> fine this >>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the app >>>>>>>>>>>>>> via the >>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>> >>>>>>>>>>>>>> A solution would be to return error 400 rather than redirect >>>>>>>>>>>>>> to the >>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>> >>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>> >>>>>>>>>>>>>> regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>> >>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>> | Ping >>>>>>>>>> Identity >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | >>>>>>>> Ping Identity >>>>>>> >>>>>> >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping >>>>>> Identity >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From nobody Thu Sep 4 06:01:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875AA1A88A6 for ; Thu, 4 Sep 2014 06:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 PNHPE5UXH92d for ; Thu, 4 Sep 2014 06:01:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788BB1A889C for ; Thu, 4 Sep 2014 06:01:13 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 4 Sep 2014 13:01:10 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.144]) with mapi id 15.00.1015.018; Thu, 4 Sep 2014 13:01:10 +0000 From: Antonio Sanso To: Bill Burke Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AA== Date: Thu, 4 Sep 2014 13:01:09 +0000 Message-ID: <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> In-Reply-To: <54086090.8080703@redhat.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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(199003)(479174003)(189002)(24454002)(51444003)(51704005)(21056001)(80022001)(85852003)(76176999)(15395725005)(83072002)(31966008)(15202345003)(4396001)(82746002)(99396002)(83716003)(15975445006)(19580395003)(77096002)(92726001)(36756003)(79102001)(83322001)(587094003)(77982001)(33656002)(66066001)(2656002)(93886004)(110136001)(90102001)(76482001)(105586002)(19580405001)(74502001)(101416001)(46102001)(87936001)(99286002)(81342001)(74662001)(50986999)(16601075003)(85306004)(86362001)(106356001)(106116001)(92566001)(95666004)(81542001)(54356999)(64706001)(20776003)(107046002)(104396001)(387795003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <348A04363BC79648A64DC84785078072@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SNHtm3uPIKD0f-naKPlVuZBgauM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 13:01:15 -0000 hi Bill=20 On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: > FWIW, Antonio convinced me and I'm going to change this in our IDM projec= t. Thanks Antonio. What convinced me was that the user is probably expect= ing a login screen. Since there is this expectation, it might make it a li= ttle easier for the attacker to convince the user that a spoofed login scre= en is real. I know this issue can only happen with unrestricted registrati= on, but, IMO, this proposed change doesn't really have much of an effect on= usability and is even backward compatible with the current RFC. >=20 > Wouldn't it better though to never do a redirect on an invalid request an= d just display an error page? thanks for sharing your thoughts :). Display an error 400 is what Google do= es :) regards antonio >=20 > On 9/4/2014 3:50 AM, Antonio Sanso wrote: >> Hi Hans, >>=20 >> I really fail to see how this can be addressed at registration time for = cases where registration is unrestricted (namely all the big Providers) >>=20 >> regards >>=20 >> antonio >>=20 >> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt w= rote: >>=20 >>> Classifying like this must also mean that consent should not be stored = until the client is considered (admin) trusted, and admin policy would inte= rfere with user policy. >>>=20 >>> IMHO the security consideration would apply only to dynamically registe= red clients where registration is unrestricted; any other form would involv= e some form of admin/user approval at registration time, overcoming the con= cern at authorization time: there's no auto-redirect flow possible for unkn= own clients. >>>=20 >>> Hans. >>>=20 >>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>> I think this advice isn't a bad idea, though it's of course up to the = AS >>>> what an "untrusted" client really is. In practice, this is something >>>> that was registered by a non-sysadmin type person, either a dynamicall= y >>>> registered client or something available through self-service >>>> registration of some type. It's also reasonable that a client, even >>>> dynamically registered, would be considered "trusted" if enough time h= as >>>> passed and enough users have used it without things blowing up. >>>>=20 >>>> -- Justin >>>>=20 >>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>> > wrote: >>>>=20 >>>>> hi again *, >>>>>=20 >>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>> clients can also be to always present the consent screen (at least >>>>> once) before any redirect. >>>>> Namely all providers I have seen show the consent screen if all the >>>>> request parameters are correct and if the user accepts the redirect >>>>> happens. >>>>> If one of the parameter (with the exclusion of the client id and >>>>> redirect uri that are handled differently as for spec) is wrong thoug= h >>>>> the redirect happens without the consent screen being shown.. >>>>>=20 >>>>> WDYT? >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>> > wrote: >>>>>=20 >>>>>> Well, >>>>>> I do not know if this is only dynamic registration... >>>>>> let=92s talk about real use cases, namely e.g. Google , Facebook , >>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>=20 >>>>>> Said that what the other guys think? :) >>>>>> Would this deserve some =93spec adjustment=94 ? I mean there is a re= ason >>>>>> if Google is by choice =93violating=94 the spec right? (I assume to = avoid >>>>>> open redirect=85) >>>>>> But other implementers do follow the spec hence they have this open >>>>>> redirector=85 and this is not nice IMHO... >>>>>>=20 >>>>>>=20 >>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>> > wrote: >>>>>>=20 >>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>> > w= rote: >>>>>>>>=20 >>>>>>>>> Is your concern clients that were registered using dynamic client >>>>>>>>> registration? >>>>>>>>=20 >>>>>>>> yes >>>>>>>=20 >>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>> registration; that is left out of scope of the dynreg spec (and the >>>>>>> concept is not even part of the core spec), but unless you want >>>>>>> everything to be open (which typically would not be the case), then >>>>>>> it would involve approval somewhere in the process before the clien= t >>>>>>> is registered. Without dynamic client registration that approval is >>>>>>> admin based or resource owner based, depending on use case. >>>>>>>=20 >>>>>>>>> Otherwise the positive case is returning a response to a valid UR= L >>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>> resource owner >>>>>>>>=20 >>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>=20 >>>>>>> roles can collapse in use cases especially when using dynamic clien= t >>>>>>> registration >>>>>>>=20 >>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>=20 >>>>>>>> the difference is the consent screen=85 in the positive case you n= eed >>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I fail to see the open redirect. >>>>>>>>=20 >>>>>>>> why? >>>>>>>=20 >>>>>>> because the client and thus the fixed URL are explicitly approved a= t >>>>>>> some point >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> Let me try and approach this from a different angle: why would = you >>>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>>> call it >>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>> provided? >>>>>>>>>>=20 >>>>>>>>>> as specified below in the positive case (namely when the correct >>>>>>>>>> scope >>>>>>>>>> is provided) the resource owner MUST approve the app via the con= sent >>>>>>>>>> screen (at least once). >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>> hi John, >>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The issue is that the AS may be allowing client registrations= with >>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a clien= t >>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>>>>> needs >>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>=20 >>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It wou= ld be >>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>> returning >>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>=20 >>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>=20 >>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>=20 >>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>=20 >>>>>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>>>>> far=85. >>>>>>>>>>>>=20 >>>>>>>>>>>> regards >>>>>>>>>>>>=20 >>>>>>>>>>>> antonio >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> John B. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>> order for a >>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatch= ing >>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner o= f the >>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to= the >>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>> request >>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redire= cted >>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >. >>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id= =3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp= ://attacker.com >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the a= pp >>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> A solution would be to return error 400 rather than redirec= t >>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>=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 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>> | Ping >>>>>>>>>>> Identity >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>> Ping Identity >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Pin= g >>>>>>> Identity >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> -- >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > --=20 > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Sep 4 06:15:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18031A88A0 for ; Thu, 4 Sep 2014 06:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=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 aJGlXcb2fiD0 for ; Thu, 4 Sep 2014 06:15:36 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED72B1A887F for ; Thu, 4 Sep 2014 06:15:21 -0700 (PDT) Received: from mail-we0-f175.google.com ([74.125.82.175]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKVAhl6d4YtK0S78jg16JiVWYQ/Mbi37qr@postini.com; Thu, 04 Sep 2014 06:15:22 PDT Received: by mail-we0-f175.google.com with SMTP id k48so10184778wev.20 for ; Thu, 04 Sep 2014 06:15:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kz1SSEwdORRSm36CiV96K7V5CZy/i/IfWA86RPXMQ7c=; b=nKBVqzcCMX35XtCzZVxa6hTb4Jk7kXsZuG7BZt2osKHJgMTdfGFIMqpIGYrLwdu6lr hoidSp826WeoDXvys3+OkG9XGYyLYfZgP5HCeHFYMz/9nticul/ZRQtBC9JpOKE9IOfG shQpVp74XqNcPG8sd8R8THsdrPSKEQDUDziPmnTUCx7LwxI3MGkVPiQNrmU4tP5lBiqk +w1ePvCJQ+mLC5xLjhEro+oV4MKIJb7xS1SjaC+zBEbfc1wwOV/0YPTx+fjkWHwwm/QD SoAsFlr4/nwb52se47D7JnjQZwZ9hlNap/jKq+qed6l4ZSP8yvdD6HaXT9xPwtTd5qiD bbSQ== X-Gm-Message-State: ALoCoQmRWtFeDG+JLOtfB26mHhvqNCl5yiaCYtpQnf3cGRpknHCM6qAr/UUToWVf9xpe4OGLnL/gCnU1/6SrD4iOtpvvV8UXNLoC+heoABAlbvVZ3zuR1deDlGyD9m4hp98M+6Bw0K8u X-Received: by 10.194.6.101 with SMTP id z5mr6064017wjz.79.1409836520426; Thu, 04 Sep 2014 06:15:20 -0700 (PDT) X-Received: by 10.194.6.101 with SMTP id z5mr6063919wjz.79.1409836519693; Thu, 04 Sep 2014 06:15:19 -0700 (PDT) Received: from [192.168.10.102] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id u7sm1394421wif.7.2014.09.04.06.15.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 06:15:18 -0700 (PDT) Message-ID: <540865E5.5010808@pingidentity.com> Date: Thu, 04 Sep 2014 15:15:17 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Antonio Sanso , Bill Burke References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> In-Reply-To: <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/X33MYfXJ2d39xtmeYusmid7VaT0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 13:15:37 -0000 I am convinced about the issue in the use case Antonio provided but I hope not to close the door on returning errors to known and trusted clients. Not sure anymore if that's possible though because the distinction can't be "registered"... Hans. On 9/4/14, 3:01 PM, Antonio Sanso wrote: > hi Bill > On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: > >> FWIW, Antonio convinced me and I'm going to change this in our IDM project. Thanks Antonio. What convinced me was that the user is probably expecting a login screen. Since there is this expectation, it might make it a little easier for the attacker to convince the user that a spoofed login screen is real. I know this issue can only happen with unrestricted registration, but, IMO, this proposed change doesn't really have much of an effect on usability and is even backward compatible with the current RFC. >> >> Wouldn't it better though to never do a redirect on an invalid request and just display an error page? > > thanks for sharing your thoughts :). Display an error 400 is what Google does :) > > regards > > antonio > >> >> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>> Hi Hans, >>> >>> I really fail to see how this can be addressed at registration time for cases where registration is unrestricted (namely all the big Providers) >>> >>> regards >>> >>> antonio >>> >>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>> >>>> Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy. >>>> >>>> IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients. >>>> >>>> Hans. >>>> >>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>> I think this advice isn't a bad idea, though it's of course up to the AS >>>>> what an "untrusted" client really is. In practice, this is something >>>>> that was registered by a non-sysadmin type person, either a dynamically >>>>> registered client or something available through self-service >>>>> registration of some type. It's also reasonable that a client, even >>>>> dynamically registered, would be considered "trusted" if enough time has >>>>> passed and enough users have used it without things blowing up. >>>>> >>>>> -- Justin >>>>> >>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>> > wrote: >>>>> >>>>>> hi again *, >>>>>> >>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>> clients can also be to always present the consent screen (at least >>>>>> once) before any redirect. >>>>>> Namely all providers I have seen show the consent screen if all the >>>>>> request parameters are correct and if the user accepts the redirect >>>>>> happens. >>>>>> If one of the parameter (with the exclusion of the client id and >>>>>> redirect uri that are handled differently as for spec) is wrong though >>>>>> the redirect happens without the consent screen being shown.. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> regards >>>>>> >>>>>> antonio >>>>>> >>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>> > wrote: >>>>>> >>>>>>> Well, >>>>>>> I do not know if this is only dynamic registration... >>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook , >>>>>>> etc.. is that dynamic client registration? I do not know… :) >>>>>>> >>>>>>> Said that what the other guys think? :) >>>>>>> Would this deserve some “spec adjustment” ? I mean there is a reason >>>>>>> if Google is by choice “violating” the spec right? (I assume to avoid >>>>>>> open redirect…) >>>>>>> But other implementers do follow the spec hence they have this open >>>>>>> redirector… and this is not nice IMHO... >>>>>>> >>>>>>> >>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>> > wrote: >>>>>>> >>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>> >>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Is your concern clients that were registered using dynamic client >>>>>>>>>> registration? >>>>>>>>> >>>>>>>>> yes >>>>>>>> >>>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>>> registration; that is left out of scope of the dynreg spec (and the >>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>> everything to be open (which typically would not be the case), then >>>>>>>> it would involve approval somewhere in the process before the client >>>>>>>> is registered. Without dynamic client registration that approval is >>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>> >>>>>>>>>> Otherwise the positive case is returning a response to a valid URL >>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>> resource owner >>>>>>>>> >>>>>>>>> well AFAIK the resource owner doesn’t register clients… >>>>>>>> >>>>>>>> roles can collapse in use cases especially when using dynamic client >>>>>>>> registration >>>>>>>> >>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>> >>>>>>>>> the difference is the consent screen… in the positive case you need >>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I fail to see the open redirect. >>>>>>>>> >>>>>>>>> why? >>>>>>>> >>>>>>>> because the client and thus the fixed URL are explicitly approved at >>>>>>>> some point >>>>>>>> >>>>>>>> Hans. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hans. >>>>>>>>>> >>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>> >>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Let me try and approach this from a different angle: why would you >>>>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>>>> call it >>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>> provided? >>>>>>>>>>> >>>>>>>>>>> as specified below in the positive case (namely when the correct >>>>>>>>>>> scope >>>>>>>>>>> is provided) the resource owner MUST approve the app via the consent >>>>>>>>>>> screen (at least once). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hans. >>>>>>>>>>>> >>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>> hi John, >>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The issue is that the AS may be allowing client registrations with >>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>>>>>> needs >>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>> >>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It would be >>>>>>>>>>>>> pretty unpractical to block this at registration time…. >>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>> returning >>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>> >>>>>>>>>>>>> *400.* That’s an error. >>>>>>>>>>>>> >>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>> >>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>>>>>>>>> >>>>>>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>>>>>> far…. >>>>>>>>>>>>> >>>>>>>>>>>>> regards >>>>>>>>>>>>> >>>>>>>>>>>>> antonio >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> John B. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Now let’s assume this. >>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the app >>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A solution would be to return error 400 rather than redirect >>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>> | Ping >>>>>>>>>>>> Identity >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>> Ping Identity >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>> Identity >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping Identity >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> _______________________________________________ >> 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 > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Thu Sep 4 06:33:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73081A88B7 for ; Thu, 4 Sep 2014 06:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 a1ua7lWeNi5N for ; Thu, 4 Sep 2014 06:32:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8066C1A88A0 for ; Thu, 4 Sep 2014 06:32:57 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Thu, 4 Sep 2014 13:32:54 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.144]) with mapi id 15.00.1015.018; Thu, 4 Sep 2014 13:32:54 +0000 From: Antonio Sanso To: Hans Zandbelt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgAAE/IA= Date: Thu, 4 Sep 2014 13:32:53 +0000 Message-ID: <987B1009-0FFF-482F-B26A-4B0C74801F9B@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> In-Reply-To: <540865E5.5010808@pingidentity.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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51444003)(199003)(189002)(377454003)(479174003)(24454002)(51704005)(92726001)(76176999)(86362001)(106356001)(92566001)(79102001)(54356999)(74502001)(106116001)(50986999)(77096002)(81542001)(87936001)(110136001)(46102001)(85852003)(77982001)(83072002)(15202345003)(80022001)(16601075003)(19580405001)(82746002)(21056001)(83322001)(19580395003)(95666004)(64706001)(36756003)(99286002)(2656002)(15975445006)(15395725005)(107046002)(99396002)(31966008)(76482001)(4396001)(101416001)(83716003)(587094003)(90102001)(74662001)(66066001)(93886004)(105586002)(81342001)(20776003)(33656002)(85306004)(104396001)(387795003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <46ABA13CB96F0A499E983A0E3AAE0C0B@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2AzKUJn7QCxYi20xAx4hWvxgXZ8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 13:33:00 -0000 hi Hans On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrot= e: > I am convinced about the issue in the use case Antonio provided but I hop= e not to close the door on returning errors to known and trusted clients. N= ot sure anymore if that's possible though because the distinction can't be = "registered"=85 an alternative is to show always the consent screen (at least once if the c= lient id/redirect_uri is valid and accept the app) even if the scope or any= other parameter is not valid before to redirect to the redirect uri. regards antonio >=20 > Hans. >=20 > On 9/4/14, 3:01 PM, Antonio Sanso wrote: >> hi Bill >> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>=20 >>> FWIW, Antonio convinced me and I'm going to change this in our IDM proj= ect. Thanks Antonio. What convinced me was that the user is probably expe= cting a login screen. Since there is this expectation, it might make it a = little easier for the attacker to convince the user that a spoofed login sc= reen is real. I know this issue can only happen with unrestricted registra= tion, but, IMO, this proposed change doesn't really have much of an effect = on usability and is even backward compatible with the current RFC. >>>=20 >>> Wouldn't it better though to never do a redirect on an invalid request = and just display an error page? >>=20 >> thanks for sharing your thoughts :). Display an error 400 is what Google= does :) >>=20 >> regards >>=20 >> antonio >>=20 >>>=20 >>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>> Hi Hans, >>>>=20 >>>> I really fail to see how this can be addressed at registration time fo= r cases where registration is unrestricted (namely all the big Providers) >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt = wrote: >>>>=20 >>>>> Classifying like this must also mean that consent should not be store= d until the client is considered (admin) trusted, and admin policy would in= terfere with user policy. >>>>>=20 >>>>> IMHO the security consideration would apply only to dynamically regis= tered clients where registration is unrestricted; any other form would invo= lve some form of admin/user approval at registration time, overcoming the c= oncern at authorization time: there's no auto-redirect flow possible for un= known clients. >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>> I think this advice isn't a bad idea, though it's of course up to th= e AS >>>>>> what an "untrusted" client really is. In practice, this is something >>>>>> that was registered by a non-sysadmin type person, either a dynamica= lly >>>>>> registered client or something available through self-service >>>>>> registration of some type. It's also reasonable that a client, even >>>>>> dynamically registered, would be considered "trusted" if enough time= has >>>>>> passed and enough users have used it without things blowing up. >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>> > wrote: >>>>>>=20 >>>>>>> hi again *, >>>>>>>=20 >>>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>>> clients can also be to always present the consent screen (at least >>>>>>> once) before any redirect. >>>>>>> Namely all providers I have seen show the consent screen if all the >>>>>>> request parameters are correct and if the user accepts the redirect >>>>>>> happens. >>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>> redirect uri that are handled differently as for spec) is wrong tho= ugh >>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>=20 >>>>>>> WDYT? >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>> > wrote: >>>>>>>=20 >>>>>>>> Well, >>>>>>>> I do not know if this is only dynamic registration... >>>>>>>> let=92s talk about real use cases, namely e.g. Google , Facebook , >>>>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>>>=20 >>>>>>>> Said that what the other guys think? :) >>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there is a = reason >>>>>>>> if Google is by choice =93violating=94 the spec right? (I assume t= o avoid >>>>>>>> open redirect=85) >>>>>>>> But other implementers do follow the spec hence they have this ope= n >>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>> >= wrote: >>>>>>>>>>=20 >>>>>>>>>>> Is your concern clients that were registered using dynamic clie= nt >>>>>>>>>>> registration? >>>>>>>>>>=20 >>>>>>>>>> yes >>>>>>>>>=20 >>>>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>>>> registration; that is left out of scope of the dynreg spec (and t= he >>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>> everything to be open (which typically would not be the case), th= en >>>>>>>>> it would involve approval somewhere in the process before the cli= ent >>>>>>>>> is registered. Without dynamic client registration that approval = is >>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>=20 >>>>>>>>>>> Otherwise the positive case is returning a response to a valid = URL >>>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>>> resource owner >>>>>>>>>>=20 >>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>=20 >>>>>>>>> roles can collapse in use cases especially when using dynamic cli= ent >>>>>>>>> registration >>>>>>>>>=20 >>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>=20 >>>>>>>>>> the difference is the consent screen=85 in the positive case you= need >>>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>=20 >>>>>>>>>> why? >>>>>>>>>=20 >>>>>>>>> because the client and thus the fixed URL are explicitly approved= at >>>>>>>>> some point >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Let me try and approach this from a different angle: why woul= d you >>>>>>>>>>>>> call it an open redirect when an invalid scope is provided an= d >>>>>>>>>>>>> call it >>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>> provided? >>>>>>>>>>>>=20 >>>>>>>>>>>> as specified below in the positive case (namely when the corre= ct >>>>>>>>>>>> scope >>>>>>>>>>>> is provided) the resource owner MUST approve the app via the c= onsent >>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hans. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The issue is that the AS may be allowing client registratio= ns with >>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a cli= ent >>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think that if anything it may be the registration step th= at >>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It w= ould be >>>>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>>> returning >>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> said that I hope you all agree this is an issue in the spec = so >>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> regards >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerabl= e >>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismat= ching >>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing o= r >>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner= of the >>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent = to the >>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redi= rected >>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_i= d=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhtt= p://attacker.com >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the= app >>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than redir= ect >>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>> | Ping >>>>>>>>>>>>> Identity >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>> Ping Identity >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | P= ing >>>>>>>>> Identity >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>>=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 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity From nobody Thu Sep 4 06:42:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9341A88B6 for ; Thu, 4 Sep 2014 06:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 5Gl_p7sU-uci for ; Thu, 4 Sep 2014 06:42:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 90B9F1A88AD for ; Thu, 4 Sep 2014 06:42:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3D22A1F0756; Thu, 4 Sep 2014 09:42:31 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2ACD21F0755; Thu, 4 Sep 2014 09:42:31 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.110]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Thu, 4 Sep 2014 09:42:30 -0400 From: "Richer, Justin P." To: Hans Zandbelt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5Jvv1xSAgAABLoCAAAjvgIAAAVeAgAABWQCAAAPwAIAAAR4AgAAHXACAAAO+AIAAwVmAgAAbioCAAB5GVYAARVeAgAAD84CAAAe7gA== Date: Thu, 4 Sep 2014 13:42:30 +0000 Message-ID: <573DA6A5-316A-46C5-85A4-FB46B3311CEA@mitre.org> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> In-Reply-To: <540865E5.5010808@pingidentity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.8.45] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2264085A28577B47A6194B67E119CCC1@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6fjOxSUH84s7kKoNnFMQDwIgH_c Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 13:42:34 -0000 The distinction can be made, and it's AS policy. Sometimes (like in our cas= e) the AS distinguishes between client registered by an administrator vs. a= n end user vs. something dynamic (no user involved). And in the latter case= s, the AS can still figure out how long something's been registered and how= it's been used in the past (no user complaints across a large number of us= ers) to make something more or less trusted over time. But it's still up to= the AS, and it would be helpful to have some guidance on this in the secur= ity considerations. We might want to add it to the DynReg spec because that= exacerbates the issue a bit. -- Justin On Sep 4, 2014, at 9:15 AM, Hans Zandbelt wrot= e: > I am convinced about the issue in the use case Antonio provided but I hop= e not to close the door on returning errors to known and trusted clients. N= ot sure anymore if that's possible though because the distinction can't be = "registered"... >=20 > Hans. >=20 > On 9/4/14, 3:01 PM, Antonio Sanso wrote: >> hi Bill >> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>=20 >>> FWIW, Antonio convinced me and I'm going to change this in our IDM proj= ect. Thanks Antonio. What convinced me was that the user is probably expe= cting a login screen. Since there is this expectation, it might make it a = little easier for the attacker to convince the user that a spoofed login sc= reen is real. I know this issue can only happen with unrestricted registra= tion, but, IMO, this proposed change doesn't really have much of an effect = on usability and is even backward compatible with the current RFC. >>>=20 >>> Wouldn't it better though to never do a redirect on an invalid request = and just display an error page? >>=20 >> thanks for sharing your thoughts :). Display an error 400 is what Google= does :) >>=20 >> regards >>=20 >> antonio >>=20 >>>=20 >>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>> Hi Hans, >>>>=20 >>>> I really fail to see how this can be addressed at registration time fo= r cases where registration is unrestricted (namely all the big Providers) >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt = wrote: >>>>=20 >>>>> Classifying like this must also mean that consent should not be store= d until the client is considered (admin) trusted, and admin policy would in= terfere with user policy. >>>>>=20 >>>>> IMHO the security consideration would apply only to dynamically regis= tered clients where registration is unrestricted; any other form would invo= lve some form of admin/user approval at registration time, overcoming the c= oncern at authorization time: there's no auto-redirect flow possible for un= known clients. >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>> I think this advice isn't a bad idea, though it's of course up to th= e AS >>>>>> what an "untrusted" client really is. In practice, this is something >>>>>> that was registered by a non-sysadmin type person, either a dynamica= lly >>>>>> registered client or something available through self-service >>>>>> registration of some type. It's also reasonable that a client, even >>>>>> dynamically registered, would be considered "trusted" if enough time= has >>>>>> passed and enough users have used it without things blowing up. >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>> > wrote: >>>>>>=20 >>>>>>> hi again *, >>>>>>>=20 >>>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>>> clients can also be to always present the consent screen (at least >>>>>>> once) before any redirect. >>>>>>> Namely all providers I have seen show the consent screen if all the >>>>>>> request parameters are correct and if the user accepts the redirect >>>>>>> happens. >>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>> redirect uri that are handled differently as for spec) is wrong tho= ugh >>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>=20 >>>>>>> WDYT? >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>> > wrote: >>>>>>>=20 >>>>>>>> Well, >>>>>>>> I do not know if this is only dynamic registration... >>>>>>>> let=92s talk about real use cases, namely e.g. Google , Facebook , >>>>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>>>=20 >>>>>>>> Said that what the other guys think? :) >>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there is a = reason >>>>>>>> if Google is by choice =93violating=94 the spec right? (I assume t= o avoid >>>>>>>> open redirect=85) >>>>>>>> But other implementers do follow the spec hence they have this ope= n >>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>> >= wrote: >>>>>>>>>>=20 >>>>>>>>>>> Is your concern clients that were registered using dynamic clie= nt >>>>>>>>>>> registration? >>>>>>>>>>=20 >>>>>>>>>> yes >>>>>>>>>=20 >>>>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>>>> registration; that is left out of scope of the dynreg spec (and t= he >>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>> everything to be open (which typically would not be the case), th= en >>>>>>>>> it would involve approval somewhere in the process before the cli= ent >>>>>>>>> is registered. Without dynamic client registration that approval = is >>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>=20 >>>>>>>>>>> Otherwise the positive case is returning a response to a valid = URL >>>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>>> resource owner >>>>>>>>>>=20 >>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>=20 >>>>>>>>> roles can collapse in use cases especially when using dynamic cli= ent >>>>>>>>> registration >>>>>>>>>=20 >>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>=20 >>>>>>>>>> the difference is the consent screen=85 in the positive case you= need >>>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>=20 >>>>>>>>>> why? >>>>>>>>>=20 >>>>>>>>> because the client and thus the fixed URL are explicitly approved= at >>>>>>>>> some point >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Let me try and approach this from a different angle: why woul= d you >>>>>>>>>>>>> call it an open redirect when an invalid scope is provided an= d >>>>>>>>>>>>> call it >>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>> provided? >>>>>>>>>>>>=20 >>>>>>>>>>>> as specified below in the positive case (namely when the corre= ct >>>>>>>>>>>> scope >>>>>>>>>>>> is provided) the resource owner MUST approve the app via the c= onsent >>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hans. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The issue is that the AS may be allowing client registratio= ns with >>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a cli= ent >>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think that if anything it may be the registration step th= at >>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It w= ould be >>>>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>>> returning >>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> said that I hope you all agree this is an issue in the spec = so >>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> regards >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerabl= e >>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismat= ching >>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing o= r >>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner= of the >>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent = to the >>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redi= rected >>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_i= d=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhtt= p://attacker.com >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the= app >>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than redir= ect >>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>> | Ping >>>>>>>>>>>>> Identity >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>> Ping Identity >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | P= ing >>>>>>>>> Identity >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>>=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 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Sep 4 08:43:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D841A8983 for ; Thu, 4 Sep 2014 08:43:18 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 8x06CxCq4ClV for ; Thu, 4 Sep 2014 08:43:11 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1680A1A892B for ; Thu, 4 Sep 2014 08:43:10 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w61so10458534wes.39 for ; Thu, 04 Sep 2014 08:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YL2fS8hID9qCEYuwngpkszhxG44yuid2v/9WGzrayeE=; b=0OtqPp0ILHknKUCgWtj6Cg1JDA1tb1lRvPThV/kYSOPXMBQCY/RUD0mhjQuY+qXXEH hWHm1D8qRGafw8Ns2ouz+xfPKYZS/IsGg1umqKFhXkwLFvpurwIrodhDss4qTVR4gQvz KEusDmVFysE4IjIJ3wz5W/OnLGj70dEY6yhGoJC952Gagj2s17LyJfsRQ6qUp9YWEwAr NDVhfgvgMhxdvjifF9akoj3gRF/pXLKbH1msC49NHQgPeWssALOHAcbbKhNl1mkDiZAC YXpdyuUfAA/csfcIDi02CSbKj8pBd4/N1l9DlH690G1MDnauJHFvh2ofnJGlmRtR80rQ xrkg== X-Received: by 10.180.86.33 with SMTP id m1mr6638888wiz.11.1409845389459; Thu, 04 Sep 2014 08:43:09 -0700 (PDT) Received: from [192.168.2.7] ([109.255.231.6]) by mx.google.com with ESMTPSA id hi4sm19752347wjb.46.2014.09.04.08.43.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Sep 2014 08:43:08 -0700 (PDT) Message-ID: <54088888.7000502@gmail.com> Date: Thu, 04 Sep 2014 16:43:04 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KIgPsQQk5_VA-VTRycBlohPgYZE Subject: Re: [OAUTH-WG] Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:43:19 -0000 Hi Justin On 04/09/14 13:15, Richer, Justin P. wrote: > Neither of these are authentication (they don't tell the client or business logic server who the user is or if they're still there), they're authorization and they're both well within the scope of OAuth. > > The first one is a redirect flow, that actually works (in OAuth) like this: > > 1) Clients calls business logic server (in OAuth, the Protected Resource) > 2) Server detects no access token, sends an error response to the client > 3) Client needs to send the user in a browser to the Authorization Server > 4) Authorization server prompts the user (not the client) to authenticate and authorize the client > 5) Authorization server redirects back to the client with either the token (if you're doing implicit flow, inside of a browser) or something the client can use to get a token (authorization code flow) > 6) Client gets the token and calls the business logic server with said token > > In your second scenario, you're really doing the Resource Owner Password flow defined in OAuth. This is generally a bad idea because it exposes the client to the user's credentials and limits you to username/password. The flow is defined mostly as a way to help bridge legacy applications into the OAuth world. That was a client credentials, right ? And in the client credentials case a (legacy) client can effectively authenticate using whatever credentials it has Thanks, Sergey > > > If you actually do want authentication (i.e., the client knowing who the user is) on top of this authorized call to the business logic service, then you'll need an identity API, which is what OpenID Connect provides in a well-defined well-used standard. > > -- Justin > > > On Sep 4, 2014, at 5:30 AM, Frizz wrote: > >> Hello there, >> >> I have a question regarding Authentication: >> >> The following two scenarios, are they typical use cases for OAuth? Or OpenId-Connect? Or something completely different? >> >> Flow (A) would be like this: >> (1) Client calls Business Logic Server >> (2) Server detects there’s no Access Token in HTTP headers >> (3) Server redirects to *some* Authentication Server >> (4) Authentication Server challenges Client for Username/Password >> (5) Client (now with valid Access Token) is redirected to Business Logic Server and completes operation >> >> Flow (B) would look like this: >> (1) Client directly calls Authentication Server (kinda explicit Login call) with Username/Password and gets an Access Token in return >> (2) Client uses this Access Token for all calls to the Business Logic Server >> >> cheers, >> Frizz >> _______________________________________________ >> 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 Thu Sep 4 09:36:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CE01A039A for ; Thu, 4 Sep 2014 09:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 gkzuzR0aN8xD for ; Thu, 4 Sep 2014 09:36:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 93DDC1A02FE for ; Thu, 4 Sep 2014 09:36:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1A8041F070C; Thu, 4 Sep 2014 12:36:52 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0591E1F06E4; Thu, 4 Sep 2014 12:36:52 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.110]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Thu, 4 Sep 2014 12:36:51 -0400 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] Authentication Thread-Index: AQHPyDZP6u2hYPiMQEiBU1fP94VKZpvxJoCAgAA59gCAAA8nAA== Date: Thu, 4 Sep 2014 16:36:50 +0000 Message-ID: <6B318A12-8FFD-4A8D-A2A6-B7C77195395A@mitre.org> References: <54088888.7000502@gmail.com> In-Reply-To: <54088888.7000502@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.52.195] Content-Type: text/plain; charset="Windows-1252" Content-ID: <263AE02FA64EDB4B8939CDD318A42C8B@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CMVutc3JVTivG2QCxzxP2Q6C9DY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 16:36:54 -0000 As John points out, that could be either resource owner or client credentia= ls flow, depending on the use case. -- Justin On Sep 4, 2014, at 11:43 AM, Sergey Beryozkin wrote: > Hi Justin >=20 >=20 > On 04/09/14 13:15, Richer, Justin P. wrote: >> Neither of these are authentication (they don't tell the client or busin= ess logic server who the user is or if they're still there), they're author= ization and they're both well within the scope of OAuth. >>=20 >> The first one is a redirect flow, that actually works (in OAuth) like th= is: >>=20 >> 1) Clients calls business logic server (in OAuth, the Protected Resource= ) >> 2) Server detects no access token, sends an error response to the client >> 3) Client needs to send the user in a browser to the Authorization Serve= r >> 4) Authorization server prompts the user (not the client) to authenticat= e and authorize the client >> 5) Authorization server redirects back to the client with either the tok= en (if you're doing implicit flow, inside of a browser) or something the cl= ient can use to get a token (authorization code flow) >> 6) Client gets the token and calls the business logic server with said t= oken >>=20 >> In your second scenario, you're really doing the Resource Owner Password= flow defined in OAuth. This is generally a bad idea because it exposes the= client to the user's credentials and limits you to username/password. The = flow is defined mostly as a way to help bridge legacy applications into the= OAuth world. >=20 > That was a client credentials, right ? And in the client credentials case= a (legacy) client can effectively authenticate using whatever credentials = it has >=20 > Thanks, Sergey >=20 >>=20 >>=20 >> If you actually do want authentication (i.e., the client knowing who the= user is) on top of this authorized call to the business logic service, the= n you'll need an identity API, which is what OpenID Connect provides in a w= ell-defined well-used standard. >>=20 >> -- Justin >>=20 >>=20 >> On Sep 4, 2014, at 5:30 AM, Frizz wrote: >>=20 >>> Hello there, >>>=20 >>> I have a question regarding Authentication: >>>=20 >>> The following two scenarios, are they typical use cases for OAuth? Or O= penId-Connect? Or something completely different? >>>=20 >>> Flow (A) would be like this: >>> (1) Client calls Business Logic Server >>> (2) Server detects there=92s no Access Token in HTTP headers >>> (3) Server redirects to *some* Authentication Server >>> (4) Authentication Server challenges Client for Username/Password >>> (5) Client (now with valid Access Token) is redirected to Business Logi= c Server and completes operation >>>=20 >>> Flow (B) would look like this: >>> (1) Client directly calls Authentication Server (kinda explicit Login c= all) with Username/Password and gets an Access Token in return >>> (2) Client uses this Access Token for all calls to the Business Logic S= erver >>>=20 >>> cheers, >>> Frizz >>> _______________________________________________ >>> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Sep 5 17:29:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A31A06A3; Fri, 5 Sep 2014 17:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 qm1_Z9VZUVeT; Fri, 5 Sep 2014 17:29:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:781]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ECAE1A0670; Fri, 5 Sep 2014 17:29:00 -0700 (PDT) Received: from CH1PR03CA006.namprd03.prod.outlook.com (10.255.156.151) by BN1PR0301MB0723.namprd03.prod.outlook.com (25.160.78.142) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Sat, 6 Sep 2014 00:28:36 +0000 Received: from BY2FFO11FD022.protection.gbl (10.255.156.132) by CH1PR03CA006.outlook.office365.com (10.255.156.151) with Microsoft SMTP Server (TLS) id 15.0.1019.16 via Frontend Transport; Sat, 6 Sep 2014 00:28:36 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Sat, 6 Sep 2014 00:28:35 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Sat, 6 Sep 2014 00:28:22 +0000 From: Mike Jones To: Warren Kumari , "secdir@ietf.org" , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" Thread-Topic: Review of: draft-ietf-oauth-json-web-token Thread-Index: AQHPxjXHxo1AOZ59oEC2WFnyXP3ehZvzMhKQ Date: Sat, 6 Sep 2014 00:28:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AE9DB28@TK5EX14MBXC292.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AE9DB28TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019017)(438002)(189002)(377454003)(199003)(43784003)(51914003)(13464003)(51444003)(46102001)(64706001)(20776003)(81542001)(81342001)(2501002)(16236675004)(15395725005)(106466001)(86362001)(81156004)(92566001)(106116001)(2201001)(92726001)(512874002)(54356999)(77982001)(99396002)(79102001)(44976005)(50986999)(97736003)(76482001)(19580405001)(76176999)(6806004)(19580395003)(85306004)(55846006)(71186001)(68736004)(80022001)(19300405004)(83322001)(66066001)(69596002)(33656002)(31966008)(4396001)(26826002)(77096002)(90102001)(230783001)(95666004)(19617315012)(104016003)(19625215002)(74502001)(74662001)(84676001)(84326002)(85806002)(15202345003)(107046002)(86612001)(21056001)(2656002)(87936001)(15975445006)(85852003)(83072002)(372894003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0723; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03264AEA72 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DY0g7Q4Sdx17HGNEpBVKp-yIGI0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 00:29:04 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AE9DB28TK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgdXNlZnVsIHJldmlldywgV2FycmVuLiAgSeKAmW0gY2PigJlpbmcgdGhl IHdvcmtpbmcgZ3JvdXAgc28gdGhleeKAmXJlIGF3YXJlIG9mIHRoZSBjb250ZW50cyBvZiB5b3Vy IHJldmlldy4gIFJlcGxpZXMgaW5saW5lIGJlbG934oCmDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogV2FycmVuIEt1bWFyaSBbbWFpbHRvOndhcnJlbkBrdW1hcmkubmV0 XQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTQgMzo0MCBQTQ0KVG86IHNlY2RpckBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi5hbGxAdG9vbHMuaWV0Zi5v cmcNClN1YmplY3Q6IFJldmlldyBvZjogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbg0K DQoNCg0KQmUgeWUgbm90IGFmcmFpZCAtLSBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJl dmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhl c2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhl IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJz IHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2Fs bCBjb21tZW50cy4NCg0KDQoNCkRpc2NsYWltZXI6IEkga25vdyBuZXh0IHRvIG5vdGhpbmcgYWJv dXQgSk9TRS4gSW4gcmVhZGluZyB0aGlzIGRvY3VtZW50IEkgYWxzbyB3ZW50IG9mZiBhbmQgcmVh ZCBzb21lIG90aGVyIEpPU0Ugd29yayAvIFdHIGRvY3VtZW50cy4NCg0KVGhlIG1haW4gdGhpbmcg dGhhdCBJIGxlYXJudCB3YXMgdGhhdCB0aGVtIHRoYXIgSk9TRSBmb2xrIHN1cmUgZG8gbGlrZSB0 aGVpciBhY3Jvbnltcy4uIDotKSBNeSB1bmZhbWlsaWFyaXR5IHdpdGggSk9TRSBtZWFucyB0aGF0 LCB1bmxpa2Ugd2hhdCB0aGUgYWJvdmUgYm9pbGVycGxhdGUgc2F5cywgeW91IHNob3VsZCB0cmVh dCB0aGVzZSBsZXNzIHNlcmlvdXNseSB0aGFuIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMh DQoNCg0KDQpTdW1tYXJ5Og0KDQpOZWVkcyBzb21lIHdvcmssIG5vdGhpbmcgbWFqb3IuDQoNCg0K DQpOb3RlczoNCg0KSW4gYSBudW1iZXIgb2YgcGxhY2VzIHRoZSBkb2N1bWVudCBzYXlzIHRoaW5n cyBsaWtlOiAiSWYgYW55IG9mIHRoZSBsaXN0ZWQgc3RlcHMgZmFpbHMgdGhlbiB0aGUgSldUIE1V U1QgYmUgcmVqZWN0ZWQgZm9yIHByb2Nlc3NpbmcuIiAtIGRvZXMgaXQgYWN0dWFsbHkgKm1lYW4q IHRvIHJlamVjdCBhIEpXVD8gV2hhdCBzaG91bGQgYW4gYXBwbGljYXRpb24gZG8gd2hlbiBpdCBy ZWplY3RzIGEgSlRXICh5ZXMsIEkgcmVhbGl6ZSB0aGF0IHRoaXMgaXMgc29tZXdoYXQgYXBwbGlj YXRpb24gc3BlY2lmaWMsIGJ1dCBhIGdlbmVyYWwgIkV4cGxvZGUsIGtpbGxpbmcgZXZlcnlib2R5 IGluc2lkZSIgdnMgIlNpbXBseSBwcmV0ZW5kIHlvdSBkaWRuJ3Qgbm90aWNlIHRoaXMiIHdvdWxk IGJlIGhlbHBmdWwpLg0KDQoNCg0KQXMgeW91IHBvaW50IG91dCwgd2hhdCBpdCBtZWFucyB0byBy ZWplY3QgdGhlIEpXUyBpcyBhY3R1YWxseSBhcHBsaWNhdGlvbiBzcGVjaWZpYywgc28gaXTigJlz IG5vdCBjbGVhciB3aGF0IGVsc2UgdG8gc2F5IGluIHRoaXMgcmVnYXJkIGluIHRoZSBzcGVjaWZp Y2F0aW9uLiAgSSBzdXBwb3NlIHRoYXQgd2UgY291bGQgc2F5IHRoYXQgaXQgbXVzdCBiZSByZWpl Y3RlZCBieSB0aGUgYXBwbGljYXRpb24gYW5kIGxlYXZlIGl0IGF0IHRoYXQuICBXb3VsZCB0aGF0 IHdvcmsgZm9yIHlvdT8NCg0KDQoNCkknbSBhIGxpdHRsZSBjb25mdXNlZCBieSBzb21ldGhpbmcg aW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gKFNlY3Rpb24gMik6DQoNClBsYWludGV4dCBKV1QN Cg0KQSBKV1Qgd2hvc2UgQ2xhaW1zIGFyZSBub3QgaW50ZWdyaXR5IHByb3RlY3RlZCBvciBlbmNy eXB0ZWQuDQoNCg0KDQpUaGUgdGVybSBwbGFpbnRleHQgdG8gbWUgbWVhbnMgc29tZXRoaW5nIGxp a2UgImlzIHJlYWRhYmxlIHdpdGhvdXQgZGVjcnlwdGluZyAvIG11Y2ggZGVjb2RpbmciIChzb21l dGhpbmcgbGlrZSwgaWYgeW91IGNhdCB0aGUgZmlsZSB0byBhIHRlcm1pbmFsLCB5b3Ugd2lsbCBz ZWUgdGhlIGluZm9ybWF0aW9uKS4gSW50ZWdyaXR5IHByb3RlY3RpbmcgYSBzdHJpbmcgZG9lc24n dCBtYWtlIGl0IG5vdCBlYXNpbHkgcmVhZGFibGUuIElmIHRoaXMgZG9jdW1lbnQgLyBKT1NFIHVz ZXMgInBsYWludGV4dCIgZGlmZmVyZW50bHkgKGFuZCBhIHF1aWNrIHNraW0gZGlkbid0IGZpbmQg YW55dGhpbmcgYWJvdXQNCg0KdGhpcykgaXQgbWlnaHQgYmUgZ29vZCB0byBjbGFyaWZ5LiBTZWN0 aW9uIDYgKmRvZXMqIGRpc2N1c3MgcGxhaW50ZXh0IEpXVHMsIGJ1dCBkb2Vzbid0IHJlYWxseSBj bGFyaWZ5IHRoZSAoSU1PKSB1bnVzdWFsIG1lYW5pbmcgb2YgdGhlIHRlcm0gInBsYWludGV4dCIg aGVyZS4NCg0KDQoNCknigJl2ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIHRoZSBvdGhlciBkb2N1bWVu dCBlZGl0b3JzIGFuZCB3ZSBhZ3JlZSB3aXRoIHlvdSB0aGF0IOKAnHBsYWludGV4dOKAnSBpcyBu b3QgdGhlIG1vc3QgaW50dWl0aXZlIHdvcmRpbmcgY2hvaWNlIGluIHRoaXMgY29udGV4dC4gIFBv c3NpYmxlIGFsdGVybmF0aXZlIHRlcm1zIGFyZSDigJxVbnNlY3VyZWQgSldU4oCdIG9yIOKAnFVu c2lnbmVkIEpXVOKAnS4gIEkgdGhpbmsgdGhhdCDigJxVbnNlY3VyZWQgSldU4oCdIGlzIHByb2Jh Ymx5IHRoZSBwcmVmZXJyZWQgdGVybSwgc2luY2UgSldUcyB0aGF0IGFyZSBKV0VzIGFyZSBhbHNv IHVuc2lnbmVkLCBidXQgdGhleSBhcmUgc2VjdXJlZC4gIFdvcmtpbmcgZ3JvdXAg4oCTIGFyZSB5 b3UgT0sgd2l0aCB0aGlzIHBvc3NpYmxlIHRlcm1pbm9sb2d5IGNoYW5nZT8gIChOb3RlIHRoYXQg dGhlIHBhcmFsbGVsIGNoYW5nZSDigJxQbGFpbnRleHQgSldT4oCdIC0+IOKAnFVuc2VjdXJlZCBK V1PigJ0gd291bGQgYWxzbyBiZSBtYWRlIGluIHRoZSBKV1Mgc3BlYy4pDQoNCg0KDQpNQUNlZCBk b2VzIG5vdCBzZWVtIHRvIGJlIGEgd2VsbCBrbm93biB0ZXJtIC0gc3VycHJpc2luZ2x5IGVub3Vn aCBldmVuIE1BQyBkb2Vzbid0IGhhdmUgYW4gYXN0ZXJpc2sgYXQgaHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvcmZjLXN0eWxlLWd1aWRlL2FiYnJldi5leHBhbnNpb24udHh0DQoNCg0KDQpEbyB5 b3UgaGF2ZSBhbm90aGVyIHN1Z2dlc3Rpb24gdG8gcmVwbGFjZSDigJxNQUNlZOKAnSBhbmQg4oCc TUFDaW5n4oCdLCBvdGhlciB0aGFuIHZlcmJvc2UgZm9ybXVsYXRpb25zIGxpa2Ug4oCcdGhhdCBo YXZlIGEgTUFDIGFwcGxpZWQgdG8gdGhlbeKAnT8gIEdpdmVuIHRoYXQgaW4gRW5nbGlzaCB1c2Fn ZSBpdOKAmXMgY29tbW9uIHRvIOKAnHZlcmIgYSBub3Vu4oCdIChlLmcuLCB1c2FnZSBvZiB0aGUg dmVyYiDigJxHb29nbGXigJ0pLCBJIGRvbuKAmXQgdGhpbmsgdGhlcmXigJlzIGFjdHVhbGx5IGFu eSBhbWJpZ3VpdHkgYXMgdG8gdGhlIGludGVuZGVkIG1lYW5pbmcuDQoNCg0KDQpTZWN0aW9uIDQ6 DQoNCiIuLi4gIHJlY2lwaWVudHMgTVVTVCBlaXRoZXIgcmVqZWN0IEpXVHMgd2l0aCBkdXBsaWNh dGUgIENsYWltIE5hbWVzIG9yIHVzZSBhIEpTT04gcGFyc2VyIHRoYXQgcmV0dXJucyBvbmx5IHRo ZSBsZXhpY2FsbHkgbGFzdCAgZHVwbGljYXRlIG1lbWJlciBuYW1lLi4uIg0KDQoNCg0KVGhpcyBz b21ld2hhdCBtYWRlIG1lIGl0Y2ggLSBzb21lIGltcGxlbWVudGF0aW9ucyB3aWxsIHJlamVjdCBh IGdpdmVuIEpXVCwgc29tZSB3aWxsIGFjY2VwdCBpdCAtLSBJIGtub3cgdmVyeSBsaXR0bGUgYWJv dXQgcGFyc2luZyBKU09OLCBidXQgY291bGQgeW91IHN1Z2dlc3Qgd2hpY2ggYW4gaW1wbGVtZW50 YXRpb24gc2hvdWxkIHByZWZlcj8gQ2FuIEkgaW5zdHJ1Y3Qgc3RhbmRhcmQgcGFyc2VycyB0byBk byBYIGluIHRoaXMgY2FzZT8NCg0KDQoNCkkgdW5kZXJzdGFuZCB0aGUgaXRjaHkgZmVlbGluZy4g 4pi6DQoNCg0KDQpVbmZvcnR1bmF0ZWx5LCB0aGUgaW50ZW50aW9uYWwgbGF4bmVzcyBpbiB0aGUg c3BlYyBpbiB0aGlzIHJlZ2FyZCBpcyBhIHJlZmxlY3Rpb24gb2YgdGhlIHNlbWFudGljcyBvZiB0 aGUgYWN0dWFsIEpTT04gc3BlY2lmaWNhdGlvbnMgYW5kIGltcGxlbWVudGF0aW9ucy4gIEZvciBp bnN0YW5jZSwgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE1OSNzZWN0aW9uLTQgc2F5 czoNCg0KDQogICBBbiBvYmplY3Qgd2hvc2UgbmFtZXMgYXJlIGFsbCB1bmlxdWUgaXMgaW50ZXJv cGVyYWJsZSBpbiB0aGUgc2Vuc2UNCiAgIHRoYXQgYWxsIHNvZnR3YXJlIGltcGxlbWVudGF0aW9u cyByZWNlaXZpbmcgdGhhdCBvYmplY3Qgd2lsbCBhZ3JlZSBvbg0KICAgdGhlIG5hbWUtdmFsdWUg bWFwcGluZ3MuICBXaGVuIHRoZSBuYW1lcyB3aXRoaW4gYW4gb2JqZWN0IGFyZSBub3QNCiAgIHVu aXF1ZSwgdGhlIGJlaGF2aW9yIG9mIHNvZnR3YXJlIHRoYXQgcmVjZWl2ZXMgc3VjaCBhbiBvYmpl Y3QgaXMNCiAgIHVucHJlZGljdGFibGUuICBNYW55IGltcGxlbWVudGF0aW9ucyByZXBvcnQgdGhl IGxhc3QgbmFtZS92YWx1ZSBwYWlyDQogICBvbmx5LiAgT3RoZXIgaW1wbGVtZW50YXRpb25zIHJl cG9ydCBhbiBlcnJvciBvciBmYWlsIHRvIHBhcnNlIHRoZQ0KICAgb2JqZWN0LCBhbmQgc29tZSBp bXBsZW1lbnRhdGlvbnMgcmVwb3J0IGFsbCBvZiB0aGUgbmFtZS92YWx1ZSBwYWlycywNCiAgIGlu Y2x1ZGluZyBkdXBsaWNhdGVzLg0KDQoNCg0KVGhpcyB0b3BpYyBoYXMgYmVlbiBoZWF2aWx5IGRp c2N1c3NlZCBieSB0aGUgd29ya2luZyBncm91cCwgYW5kIHdoaWxlIHRoZSBzcGVjcyB1c2VkIHRv IGp1c3Qgc2F5IHRoYXQgb2JqZWN0cyB3aXRoIGR1cGxpY2F0ZSBtZW1iZXIgbmFtZXMgTVVTVCBi ZSByZWplY3RlZCwgd29ya2luZyBncm91cCBtZW1iZXJzLCBpbmNsdWRpbmcgVGltIEJyYXkgKHRo ZSBlZGl0b3Igb2YgdGhlIEpTT04gc3BlYyksIHByZXZhaWxlZCBvbiB1cyB0byB3ZWFrZW4gdGhp cyBzbyB0aGF0IHBhcnNlcnMgdGhhdCBpbXBsZW1lbnQgdGhlIEVDTUFzY3JpcHQgYmVoYXZpb3Ig b2YgcmV0dXJuaW5nIG9ubHkgdGhlIGxhc3QgbWVtYmVyIG5hbWUgbWF5IGJlIGxlZ2FsbHkgdXNl ZC4gIChUaGUgYXJndW1lbnQgd2FzIG1hZGUgdGhhdCB0aGVyZSB3YXMgbW9yZSBzZWN1cml0eSBk b3duc2lkZSBpbiBlZmZlY3RpdmVseSByZXF1aXJpbmcgcGVvcGxlIHRvIHdyaXRlIGFuZCBkZWJ1 ZyB0aGVpciBvd24gc3RyaWN0IHBhcnNlcnMgdGhhbiBpbiB1c2luZyBsYXhlciwgYnV0IHdlbGwt c3VwcG9ydGVkIGFuZCBkZWJ1Z2dlZCBwYXJzZXJzLikNCg0KDQoNCkhvd2V2ZXIsIHdlIGFsc28g aW50ZW50aW9uYWxseSByZXF1aXJlIHRoYXQgcHJvZHVjZXJzIHVzZSBvbmx5IG9uZSBpbnN0YW5j ZSBvZiBlYWNoIG1lbWJlciBuYW1lLCBzbyB0aGF0IGxlZ2FsbHkgcHJvZHVjZWQgb2JqZWN0cyB3 aWxsIG5ldmVyIGV4ZXJjaXNlIHRoZSBhbWJpZ3VpdGllcyB0aGF0IGFyZSBwcmVzZW50IGluIHJl YWwgSlNPTiBwYXJzZXJzLiAgVGhhdCBzZWVtZWQgdG8gYmUgdGhlIG1vc3QgcHJhY3RpY2FsIHNv bHV0aW9uIHRvIHRoZSB3b3JraW5nIGdyb3VwLg0KDQoNCg0KU2VjdGlvbiA0LjEuNC4gImV4cCIg KEV4cGlyYXRpb24gVGltZSkgQ2xhaW0gKGFuZCBvdGhlciB0aW1lIGJhc2VkIENsYWltczoNCg0K V2hhdCBzaG91bGQgbXkgYmVoYXZpb3IgYmUgaWYgSSBzaW1wbHkgZG9uJ3Qga25vdyB3aGF0IHRo ZSB0aW1lIGlzPw0KDQooSSdtIGp1c3QgYSBkdW1iIGRldmljZSwgYW5kIG15IFJUQyBpcyBjbGFp bWluZyBpdCBpcyBKYW4xc3QsIDE5NzApIC0gSSdtIGFzc3VtaW5nIEkgbXVzdCBub3QgcHJvY2Vz cyB0aGlzIEpXVD8gRG9lcyB0aGlzIGNyZWF0ZSBib290c3RyYXBwaW5nIGlzc3Vlcz8NCg0KDQoN ClRoZSB1c2Ugb2YgYWxsIGNsYWltcyBpcyBvcHRpb25hbC4gIEl04oCZcyB1cCB0byBhcHBsaWNh dGlvbnMgd2hpY2ggb25lcyBtYWtlIHNlbnNlIGZvciB0aGVtIHRvIHVzZS4gIEluIHVzZSBjYXNl cyBpbiB3aGljaCBwYXJ0aWNpcGFudHMgZG9u4oCZdCBrbm93IHRoZSB0aW1lLCBlaXRoZXIgdGhp cyBjbGFpbSB3b3VsZCBub3QgYmUgdXNlZCBieSB0aGUgYXBwbGljYXRpb24gb3IgdGhlIGFwcGxp Y2F0aW9uIHdvdWxkIG5lZWQgdG8gZGVmaW5lIGFwcGxpY2F0aW9uLXNwZWNpZmljIGJlaGF2aW9y cyBmb3Igd2hhdCB0byBkbyBpbiB0aG9zZSBjYXNlcy4NCg0KDQoNCjUuMy4gUmVwbGljYXRpbmcg Q2xhaW1zIGFzIEhlYWRlciBQYXJhbWV0ZXJzIFRoaXMgc2VjdGlvbiBzY2FyZXMgbWUsIGFuZCBJ IGhvcGUgSSdtIHNpbXBseSBub3QgdW5kZXJzdGFuZGluZyB3aGF0IGlzIGJlaW5nIHByb3Bvc2Vk LiBJZiB5b3Ugc2VuZCB0aGUgdW5lbmNyeXB0ZWQgdmVyc2lvbiBvZiBzb21lIGVuY3J5cHRlZCBD bGFpbXMgc29tZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBtYWtlIGltcG9ydGFudCBzZWN1cml0eSBk ZWNpc2lvbnMgYmFzZWQgdXBvbiB0aG9zZSB1bmVuY3J5cHRlZCBjbGFpbXMsIGV2ZW4gaWYgeW91 IHRlbGwgdGhlbSBpbiBhIHNlcmlvdXMgdm9pY2Ugbm90IHRvLiBodHRwOi8veGtjZC5jb20vMTE4 MS8NCg0KDQoNCkZvciB3aGF0IGl04oCZcyB3b3J0aCwgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhp cyBhcm9zZSB3YXMgd2hlbiBhcHBsaWNhdGlvbiB1c2VkIGludGVybWVkaWF0ZSBzb2Z0d2FyZSB0 aGF0IGluc3BlY3RlZCB0aGUgYXVkaWVuY2Ugb2YgYW4gZW5jcnlwdGVkIEpXVCBpbiBvcmRlciB0 byByb3V0ZSBpdCB0byB0aGUgY29ycmVjdCByZWNpcGllbnQuICBPbmx5IHRoZSByZWNpcGllbnQg aGFzIHRoZSBrZXkgdG8gZGVjcnlwdCB0aGUgSldUIGFuZCBsb29rIGF0IHRoZSBlbmNyeXB0ZWQg YXVkaWVuY2UgdmFsdWUuICBCdXQgYnkgcGxhY2luZyBhbiB1bmVuY3J5cHRlZCBjb3B5IG9mIHRo ZSBhdWRpZW5jZSBpbiB0aGUgaGVhZGVyLCB0aGUgcm91dGluZyBzb2Z0d2FyZSBjb3VsZCBpbnNw ZWN0IGl0IGFuZCByb3V0ZSBpdCBjb3JyZWN0bHkuICBUaGlzIHNlZW1lZCB0byB0aGUgd29ya2lu ZyBncm91cCBsaWtlIGEgbGVnaXRpbWF0ZSB1c2UgY2FzZSwgYW5kIHNvIHdlIGRlY2lkZWQgdG8g c3VwcG9ydCBpdC4gIFRoaXMgZmVhdHVyZSB3YXMgcHJvcG9zZWQgYW5kIGRpc2N1c3NlZCBpbiB0 aGlzIHRocmVhZDogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1 cnJlbnQvbXNnMTEzMTUuaHRtbC4NCg0KDQoNCkFsc28sIHRoZSBTSE9VTEQgaW4gIklmIHN1Y2gg cmVwbGljYXRlZCBDbGFpbXMgYXJlIHByZXNlbnQsIHRoZSBhcHBsaWNhdGlvbiByZWNlaXZpbmcg dGhlbSBTSE9VTEQgdmVyaWZ5IHRoYXQgdGhlaXIgdmFsdWVzIGFyZSBpZGVudGljYWwsIC4uLiIg LSB3aHkgaXMgdGhpcyBub3QgYSBNVVNUPyBBbmQgaWYgYW4gYXBwbGljYXRpb24gKmRvZXMqIGNv bXBhcmUgdGhlbSBhbmQgdGhleSBhcmUgbm90IGlkZW50aWNhbCwgd2hhdCBzaG91bGQgaXQgZG8/ ICBQZXJoYXBzIGEgbXVjaCBzdHJvbmdlciBqdXN0aWZpY2F0aW9uIGZvciBjYXJyeWluZyAyIGNv cGllcyBvZiB0aGUgZGF0YSBpcyBpbiBvcmRlci4NCg0KDQoNClRoZSB0ZXh0IHJpZ2h0IGFmdGVy IHRoaXMgaW4gdGhlIHNwZWMgYWxyZWFkeSBhbnN3ZXJzIHRoaXMgcXVlc3Rpb246IOKAnHVubGVz cyB0aGUgYXBwbGljYXRpb24gZGVmaW5lcyBvdGhlciBzcGVjaWZpYyBwcm9jZXNzaW5nIHJ1bGVz IGZvciB0aGVzZSBDbGFpbXPigJ0uICBJdOKAmXMgYSDigJxTSE9VTETigJ0gYmVjYXVzZSBhcHBs aWNhdGlvbnMgbWlnaHQgbmVlZCB0byBkbyB0aGlzLg0KDQoNCg0KRWRpdG9yaWFsOg0KDQpUaGUg aW50cm8gaXMgYWxtb3N0IGlkZW50aWNhbCB0byB0aGUgYWJzdHJhY3QuIE1ha2luZyB0aGUgYWJz dHJhY3QgbW9yZSBhYnN0cmFjdCwgb3IgdGhlIGludHJvIG1vcmUgaW50cm9kdWN0b3J5IChJIGhh dmUgbm8gaWRlYSB3aGF0IG1hbnkgb2YgdGhlIGFjcm9ueW1zIHdlcmUhKSB3b3VsZCBiZSBuaWNl LiBTb21ldGhpbmcgc2hvcnQgZXhwbGFpbmluZyB3aGF0IGEgSldUIGlzLCB3aHkgSSdkIGxpa2Ug b25lLHdoYXQgdGhleSBnZXQgdXNlZCBmb3IsIHdoeSBJIHNob3VsZCBrZWVwIHJlYWRpbmcgdGhp cyBkb2N1bWVudCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgLSBiYXNpY2FsbHkgYSBiYWNrZ3JvdW5k IHR5cGUgc2VjdGlvbi4uLg0KDQoNCg0KU3BlY2lmaWMgd29yZGluZyBzdWdnZXN0aW9ucyB3b3Vs ZCBiZSB3ZWxjb21lZC4gIEFzIGZvciBub3Qga25vd2luZyB3aGF0IHRoZSBhY3JvbnltcyBhcmUs IEnigJltIHRvbGQgdGhhdCB0aGUgc3R5bGUgZ3VpZGVzIGRvbuKAmXQgYWxsb3cgcmVmZXJlbmNl cyB0byBiZSBwdXQgaW4gdGhlIGFic3RyYWN0LiAgT3RoZXJ3aXNlLCBmb3IgaW5zdGFuY2UsIHRo ZXJlIHdvdWxkIGJlIGEgcmVmZXJlbmNlIHRoZXJlIHRvIFJGQyA3MTU5IHNvIHBlb3BsZSB3aG8g ZG9u4oCZdCBrbm93IHdoYXQgSlNPTiBpcyBrbm93IHdoZXJlIHRvIGxvb2sgdG8gZ28gZmluZCBv dXQuDQoNCg0KDQpOaXRzOg0KDQpBYnN0cmFjdA0KDQpPOiBpcyBhIGNvbXBhY3QgVVJMLXNhZmUg bWVhbnMNCg0KUDogaXMgYSBjb21wYWN0LCBVUkwtc2FmZSBtZWFucw0KDQoNCg0KVGhhbmtzDQoN Cg0KDQozLiAgSlNPTiBXZWIgVG9rZW4gKEpXVCkgT3ZlcnZpZXcNCg0KTzogVGhlIGNvbnRlbnRz IG9mIHRoZSBKT1NFIEhlYWRlciBkZXNjcmliZQ0KDQpQOiBTcGVsbCBvdXQgSk9TRTsgZmlyc3Qg dXNlIGluIGRvY3VtZW50IGFzIGZhciBhcyBJIGNvdWxkIHNlZQ0KDQoNCg0KQWN0dWFsbHksIHRo ZSBmaXJzdCB1c2Ugb2YgdGhlIHRlcm0g4oCcSk9TRSBIZWFkZXLigJ0gaXMgaW4gU2VjdGlvbiAy IChUZXJtaW5vbG9neSksIHdoZXJlIGl0IGlzIGluY29ycG9yYXRlZCBpbnRvIHRoaXMgc3BlY2lm aWNhdGlvbiBieSByZWZlcmVuY2UuDQoNCjUuMiAiY3R5IiAoQ29udGVudCBUeXBlKSBIZWFkZXIg UGFyYW1ldGVyDQoNCk86IG5vcm1hbCBjYXNlIHdoZXJlIG5lc3RlZCBzaWduaW5nDQoNClA6IG5v cm1hbCBjYXNlIGluIHdoaWNoIG5lc3RlZCBzaWduaW5nDQoNCg0KDQpUaGFua3MNCg0KDQoNCjgu ICBJbXBsZW1lbnRhdGlvbiBSZXF1aXJlbWVudHMNCg0KTzogRm9yIGluc3RhbmNlLCBhbiBhcHBs aWNhdGlvbiBtaWdodCByZXF1aXJlIHN1cHBvcnQNCg0KICAgZm9yIGVuY3J5cHRlZCBKV1RzIGFu ZCBOZXN0ZWQgSldUczsgYW5vdGhlciBtaWdodCByZXF1aXJlIHN1cHBvcnQNCg0KUDogRm9yIGlu c3RhbmNlLCBvbmUgYXBwbGljYXRpb24gbWlnaHQgcmVxdWlyZSBzdXBwb3J0IFsuLi5dLCB3aGls ZSBhbm90aGVyIG1pZ2h0IHJlcXVpcmUgc3VwcG9ydCBbLi4uXQ0KDQoNCg0KVGhhbmtzDQoNCg0K DQoxMS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KTzogVGhlIGVudGlyZSBsaXN0IG9mIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YNCg0KICAgdGhpcyBk b2N1bWVudCwgYnV0IHNvbWUgc2lnbmlmaWNhbnQgY29uc2lkZXJhdGlvbnMgYXJlIGxpc3RlZCBo ZXJlLg0KDQpQOiBUaGUgZW50aXJlIGxpc3Qgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMg YmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpSOiBBIGZldyBvZiB0aGUgY29u c2lkZXJhdGlvbnMgYXJlIGFscmVhZHkgbGlzdGVkIGFib3ZlOyB3ZSBkb24ndCBuZWVkIHRvIHJl c3RhdGUgdGhhdCB0aGV5IGFyZSBsaXN0ZWQgaGVyZSAtLSBhbmQgaWYgd2UgZG8sIHRoZSBhc3N1 bXB0aW9uIGlzIHRoYXQgc2FpZCBsaXN0IHdvdWxkIGZvbGxvdywgbm90IGJlIGFib3ZlLg0KDQoN Cg0KU2V2ZXJhbCByZXZpZXdlcnMgaGF2ZSBvYmplY3RlZCB0byB0aGlzIHNlbnRlbmNlLiAgSXRz IHJlbW92YWwgaXMgcGxhbm5lZC4NCg0KDQoNCjExLjIgU2lnbmluZyBhbmQgRW5jcnlwdGlvbiBP cmRlcg0KDQpPOiBXaGlsZSBzeW50YWN0aWNhbGx5LCB0aGUgc2lnbmluZyBhbmQgZW5jcnlwdGlv biBvcGVyYXRpb25zIGZvciBOZXN0ZWQNCg0KICAgSldUcyBtYXkgYmUgYXBwbGllZCBpbiBhbnkg b3JkZXIsDQoNClA6IFdoaWxlIHN5bnRhY3RpY2FsbHkgdGhlIHNpZ25pbmcgYW5kIGVuY3J5cHRp b24gb3BlcmF0aW9ucyBmb3IgTmVzdGVkDQoNCiAgIEpXVHMgbWF5IGJlIGFwcGxpZWQgaW4gYW55 IG9yZGVyLA0KDQoNCg0KVGhhbmtzDQoNCg0KDQotLQ0KDQpJIGRvbid0IHRoaW5rIHRoZSBleGVj dXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFkIGlkZWEgaW4gdGhl IGZpcnN0IHBsYWNlLg0KDQpUaGlzIGlzIGxpa2UgcHV0dGluZyByYWJpZCB3ZWFzZWxzIGluIHlv dXIgcGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nIHJlZ3JldCBhdCBoYXZpbmcgY2hvc2VuIHRo b3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQgdGhhdCBwYWlyIG9mIHBhbnRzLg0KDQog ICAtLS1tYWYNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWdhaW4sIFdhcnJlbiwNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739439AE9DB28TK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5U ZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VGhh bmtzIGZvciB0aGUgdXNlZnVsIHJldmlldywgV2FycmVuLiZuYnNwOyBJ4oCZbSBjY+KAmWluZyB0 aGUgd29ya2luZyBncm91cCBzbyB0aGV54oCZcmUgYXdhcmUgb2YgdGhlIGNvbnRlbnRzIG9mIHlv dXIgcmV2aWV3LiZuYnNwOyBSZXBsaWVzIGlubGluZSBiZWxvd+KApjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFdhcnJlbiBLdW1hcmkgW21haWx0 bzp3YXJyZW5Aa3VtYXJpLm5ldF0gPGJyPg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDEsIDIw MTQgMzo0MCBQTTxicj4NClRvOiBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtanNv bi13ZWItdG9rZW4uYWxsQHRvb2xzLmlldGYub3JnPGJyPg0KU3ViamVjdDogUmV2aWV3IG9mOiBk cmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZSB5ZSBu b3QgYWZyYWlkIC0tIEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhl IHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1l bnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0 eSBhcmVhDQogZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMg c2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxs IGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EaXNjbGFpbWVyOiBJIGtu b3cgbmV4dCB0byBub3RoaW5nIGFib3V0IEpPU0UuIEluIHJlYWRpbmcgdGhpcyBkb2N1bWVudCBJ IGFsc28gd2VudCBvZmYgYW5kIHJlYWQgc29tZSBvdGhlciBKT1NFIHdvcmsgLyBXRyBkb2N1bWVu dHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgbWFpbiB0aGlu ZyB0aGF0IEkgbGVhcm50IHdhcyB0aGF0IHRoZW0gdGhhciBKT1NFIGZvbGsgc3VyZSBkbyBsaWtl IHRoZWlyIGFjcm9ueW1zLi4gOi0pIE15IHVuZmFtaWxpYXJpdHkgd2l0aCBKT1NFIG1lYW5zIHRo YXQsIHVubGlrZSB3aGF0IHRoZSBhYm92ZSBib2lsZXJwbGF0ZSBzYXlzLCB5b3Ugc2hvdWxkIHRy ZWF0IHRoZXNlIGxlc3Mgc2VyaW91c2x5IHRoYW4gYW55IG90aGVyIGxhc3QgY2FsbA0KIGNvbW1l bnRzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdW1tYXJ5OjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TmVlZHMgc29tZSB3b3JrLCBub3RoaW5nIG1ham9y LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ob3Rlczo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkluIGEgbnVtYmVyIG9mIHBsYWNlcyB0aGUgZG9jdW1lbnQg c2F5cyB0aGluZ3MgbGlrZTogJnF1b3Q7SWYgYW55IG9mIHRoZSBsaXN0ZWQgc3RlcHMgZmFpbHMg dGhlbiB0aGUgSldUIE1VU1QgYmUgcmVqZWN0ZWQgZm9yIHByb2Nlc3NpbmcuJnF1b3Q7IC0gZG9l cyBpdCBhY3R1YWxseSAqbWVhbiogdG8gcmVqZWN0IGEgSldUPyBXaGF0IHNob3VsZCBhbiBhcHBs aWNhdGlvbiBkbyB3aGVuIGl0IHJlamVjdHMgYSBKVFcgKHllcywNCiBJIHJlYWxpemUgdGhhdCB0 aGlzIGlzIHNvbWV3aGF0IGFwcGxpY2F0aW9uIHNwZWNpZmljLCBidXQgYSBnZW5lcmFsICZxdW90 O0V4cGxvZGUsIGtpbGxpbmcgZXZlcnlib2R5IGluc2lkZSZxdW90OyB2cyAmcXVvdDtTaW1wbHkg cHJldGVuZCB5b3UgZGlkbid0IG5vdGljZSB0aGlzJnF1b3Q7IHdvdWxkIGJlIGhlbHBmdWwpLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+ QXMgeW91IHBvaW50IG91dCwgd2hhdCBpdCBtZWFucyB0byByZWplY3QgdGhlIEpXUyBpcyBhY3R1 YWxseSBhcHBsaWNhdGlvbiBzcGVjaWZpYywgc28gaXTigJlzIG5vdCBjbGVhciB3aGF0IGVsc2Ug dG8gc2F5IGluIHRoaXMgcmVnYXJkIGluIHRoZSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBJIHN1cHBv c2UgdGhhdCB3ZSBjb3VsZCBzYXkgdGhhdCBpdCBtdXN0IGJlIHJlamVjdGVkDQogYnkgdGhlIGFw cGxpY2F0aW9uIGFuZCBsZWF2ZSBpdCBhdCB0aGF0LiZuYnNwOyBXb3VsZCB0aGF0IHdvcmsgZm9y IHlvdT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkknbSBhIGxpdHRsZSBj b25mdXNlZCBieSBzb21ldGhpbmcgaW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gKFNlY3Rpb24g Mik6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QbGFpbnRleHQgSldU PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BIEpXVCB3aG9zZSBDbGFp bXMgYXJlIG5vdCBpbnRlZ3JpdHkgcHJvdGVjdGVkIG9yIGVuY3J5cHRlZC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+VGhlIHRlcm0gcGxhaW50ZXh0IHRvIG1lIG1lYW5zIHNvbWV0aGlu ZyBsaWtlICZxdW90O2lzIHJlYWRhYmxlIHdpdGhvdXQgZGVjcnlwdGluZyAvIG11Y2ggZGVjb2Rp bmcmcXVvdDsgKHNvbWV0aGluZyBsaWtlLCBpZiB5b3UgY2F0IHRoZSBmaWxlIHRvIGEgdGVybWlu YWwsIHlvdSB3aWxsIHNlZSB0aGUgaW5mb3JtYXRpb24pLiBJbnRlZ3JpdHkgcHJvdGVjdGluZyBh IHN0cmluZyBkb2Vzbid0IG1ha2UgaXQgbm90IGVhc2lseQ0KIHJlYWRhYmxlLiBJZiB0aGlzIGRv Y3VtZW50IC8gSk9TRSB1c2VzICZxdW90O3BsYWludGV4dCZxdW90OyBkaWZmZXJlbnRseSAoYW5k IGEgcXVpY2sgc2tpbSBkaWRuJ3QgZmluZCBhbnl0aGluZyBhYm91dDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+dGhpcykgaXQgbWlnaHQgYmUgZ29vZCB0byBjbGFyaWZ5 LiBTZWN0aW9uIDYgKmRvZXMqIGRpc2N1c3MgcGxhaW50ZXh0IEpXVHMsIGJ1dCBkb2Vzbid0IHJl YWxseSBjbGFyaWZ5IHRoZSAoSU1PKSB1bnVzdWFsIG1lYW5pbmcgb2YgdGhlIHRlcm0gJnF1b3Q7 cGxhaW50ZXh0JnF1b3Q7IGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAi PknigJl2ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIHRoZSBvdGhlciBkb2N1bWVudCBlZGl0b3JzIGFu ZCB3ZSBhZ3JlZSB3aXRoIHlvdSB0aGF0IOKAnHBsYWludGV4dOKAnSBpcyBub3QgdGhlIG1vc3Qg aW50dWl0aXZlIHdvcmRpbmcgY2hvaWNlIGluIHRoaXMgY29udGV4dC4mbmJzcDsgUG9zc2libGUg YWx0ZXJuYXRpdmUgdGVybXMgYXJlIOKAnFVuc2VjdXJlZCBKV1TigJ0gb3Ig4oCcVW5zaWduZWQN CiBKV1TigJ0uJm5ic3A7IEkgdGhpbmsgdGhhdCDigJxVbnNlY3VyZWQgSldU4oCdIGlzIHByb2Jh Ymx5IHRoZSBwcmVmZXJyZWQgdGVybSwgc2luY2UgSldUcyB0aGF0IGFyZSBKV0VzIGFyZSBhbHNv IHVuc2lnbmVkLCBidXQgdGhleSBhcmUgc2VjdXJlZC4mbmJzcDsgV29ya2luZyBncm91cCDigJMg YXJlIHlvdSBPSyB3aXRoIHRoaXMgcG9zc2libGUgdGVybWlub2xvZ3kgY2hhbmdlPyZuYnNwOyAo Tm90ZSB0aGF0IHRoZSBwYXJhbGxlbCBjaGFuZ2Ug4oCcUGxhaW50ZXh0IEpXU+KAnSAtJmd0OyDi gJxVbnNlY3VyZWQNCiBKV1PigJ0gd291bGQgYWxzbyBiZSBtYWRlIGluIHRoZSBKV1Mgc3BlYy4p PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPk1BQ2VkIGRvZXMgbm90IHNlZW0gdG8gYmUgYSB3ZWxsIGtub3duIHRl cm0gLSBzdXJwcmlzaW5nbHkgZW5vdWdoIGV2ZW4gTUFDIGRvZXNuJ3QgaGF2ZSBhbiBhc3Rlcmlz ayBhdA0KPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLXN0eWxlLWd1aWRl L2FiYnJldi5leHBhbnNpb24udHh0Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLXN0eWxlLWd1 aWRlL2FiYnJldi5leHBhbnNpb24udHh0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+RG8geW91IGhhdmUgYW5vdGhlciBzdWdnZXN0aW9uIHRvIHJlcGxhY2Ug 4oCcTUFDZWTigJ0gYW5kIOKAnE1BQ2luZ+KAnSwgb3RoZXIgdGhhbiB2ZXJib3NlIGZvcm11bGF0 aW9ucyBsaWtlIOKAnHRoYXQgaGF2ZSBhIE1BQyBhcHBsaWVkIHRvIHRoZW3igJ0/Jm5ic3A7IEdp dmVuIHRoYXQgaW4gRW5nbGlzaCB1c2FnZSBpdOKAmXMgY29tbW9uIHRvIOKAnHZlcmIgYSBub3Vu 4oCdIChlLmcuLCB1c2FnZQ0KIG9mIHRoZSB2ZXJiIOKAnEdvb2dsZeKAnSksIEkgZG9u4oCZdCB0 aGluayB0aGVyZeKAmXMgYWN0dWFsbHkgYW55IGFtYmlndWl0eSBhcyB0byB0aGUgaW50ZW5kZWQg bWVhbmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VjdGlvbiA0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7Li4uJm5ic3A7IHJlY2lwaWVudHMgTVVTVCBlaXRoZXIg cmVqZWN0IEpXVHMgd2l0aCBkdXBsaWNhdGUmbmJzcDsgQ2xhaW0gTmFtZXMgb3IgdXNlIGEgSlNP TiBwYXJzZXIgdGhhdCByZXR1cm5zIG9ubHkgdGhlIGxleGljYWxseSBsYXN0Jm5ic3A7IGR1cGxp Y2F0ZSBtZW1iZXIgbmFtZS4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5U aGlzIHNvbWV3aGF0IG1hZGUgbWUgaXRjaCAtIHNvbWUgaW1wbGVtZW50YXRpb25zIHdpbGwgcmVq ZWN0IGEgZ2l2ZW4gSldULCBzb21lIHdpbGwgYWNjZXB0IGl0IC0tIEkga25vdyB2ZXJ5IGxpdHRs ZSBhYm91dCBwYXJzaW5nIEpTT04sIGJ1dCBjb3VsZCB5b3Ugc3VnZ2VzdCB3aGljaCBhbiBpbXBs ZW1lbnRhdGlvbiBzaG91bGQgcHJlZmVyPyBDYW4gSSBpbnN0cnVjdCBzdGFuZGFyZCBwYXJzZXJz IHRvDQogZG8gWCBpbiB0aGlzIGNhc2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcw QzAiPkkgdW5kZXJzdGFuZCB0aGUgaXRjaHkgZmVlbGluZy4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMwMDcwQzAiPko8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBD MCI+VW5mb3J0dW5hdGVseSwgdGhlIGludGVudGlvbmFsIGxheG5lc3MgaW4gdGhlIHNwZWMgaW4g dGhpcyByZWdhcmQgaXMgYSByZWZsZWN0aW9uIG9mIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGFjdHVh bCBKU09OIHNwZWNpZmljYXRpb25zIGFuZCBpbXBsZW1lbnRhdGlvbnMuJm5ic3A7IEZvciBpbnN0 YW5jZSwNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxNTkjc2VjdGlv bi00Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTU5I3NlY3Rpb24tNDwvYT4gc2F5 czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQW4gb2JqZWN0IHdob3NlIG5hbWVzIGFyZSBhbGwgdW5p cXVlIGlzIGludGVyb3BlcmFibGUgaW4gdGhlIHNlbnNlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhhdCBhbGwgc29mdHdhcmUgaW1wbGVtZW50 YXRpb25zIHJlY2VpdmluZyB0aGF0IG9iamVjdCB3aWxsIGFncmVlIG9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIG5hbWUtdmFsdWUgbWFw cGluZ3MuJm5ic3A7IFdoZW4gdGhlIG5hbWVzIHdpdGhpbiBhbiBvYmplY3QgYXJlIG5vdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHVuaXF1ZSwg dGhlIGJlaGF2aW9yIG9mIHNvZnR3YXJlIHRoYXQgcmVjZWl2ZXMgc3VjaCBhbiBvYmplY3QgaXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB1bnBy ZWRpY3RhYmxlLiZuYnNwOyBNYW55IGltcGxlbWVudGF0aW9ucyByZXBvcnQgdGhlIGxhc3QgbmFt ZS92YWx1ZSBwYWlyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgb25seS4mbmJzcDsgT3RoZXIgaW1wbGVtZW50YXRpb25zIHJlcG9ydCBhbiBlcnJv ciBvciBmYWlsIHRvIHBhcnNlIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IG9iamVjdCwgYW5kIHNvbWUgaW1wbGVtZW50YXRpb25zIHJlcG9y dCBhbGwgb2YgdGhlIG5hbWUvdmFsdWUgcGFpcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW5jbHVkaW5nIGR1cGxpY2F0ZXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGlzIHRvcGljIGhhcyBiZWVuIGhl YXZpbHkgZGlzY3Vzc2VkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCBhbmQgd2hpbGUgdGhlIHNwZWNz IHVzZWQgdG8ganVzdCBzYXkgdGhhdCBvYmplY3RzIHdpdGggZHVwbGljYXRlIG1lbWJlciBuYW1l cyBNVVNUIGJlIHJlamVjdGVkLCB3b3JraW5nIGdyb3VwIG1lbWJlcnMsIGluY2x1ZGluZyBUaW0g QnJheSAodGhlIGVkaXRvcg0KIG9mIHRoZSBKU09OIHNwZWMpLCBwcmV2YWlsZWQgb24gdXMgdG8g d2Vha2VuIHRoaXMgc28gdGhhdCBwYXJzZXJzIHRoYXQgaW1wbGVtZW50IHRoZSBFQ01Bc2NyaXB0 IGJlaGF2aW9yIG9mIHJldHVybmluZyBvbmx5IHRoZSBsYXN0IG1lbWJlciBuYW1lIG1heSBiZSBs ZWdhbGx5IHVzZWQuJm5ic3A7IChUaGUgYXJndW1lbnQgd2FzIG1hZGUgdGhhdCB0aGVyZSB3YXMg bW9yZSBzZWN1cml0eSBkb3duc2lkZSBpbiBlZmZlY3RpdmVseSByZXF1aXJpbmcgcGVvcGxlDQog dG8gd3JpdGUgYW5kIGRlYnVnIHRoZWlyIG93biBzdHJpY3QgcGFyc2VycyB0aGFuIGluIHVzaW5n IGxheGVyLCBidXQgd2VsbC1zdXBwb3J0ZWQgYW5kIGRlYnVnZ2VkIHBhcnNlcnMuKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+SG93ZXZlciwgd2UgYWxzbyBpbnRl bnRpb25hbGx5IHJlcXVpcmUgdGhhdCBwcm9kdWNlcnMgdXNlIG9ubHkgb25lIGluc3RhbmNlIG9m IGVhY2ggbWVtYmVyIG5hbWUsIHNvIHRoYXQgbGVnYWxseSBwcm9kdWNlZCBvYmplY3RzIHdpbGwg bmV2ZXIgZXhlcmNpc2UgdGhlIGFtYmlndWl0aWVzIHRoYXQgYXJlIHByZXNlbnQgaW4gcmVhbCBK U09OIHBhcnNlcnMuJm5ic3A7DQogVGhhdCBzZWVtZWQgdG8gYmUgdGhlIG1vc3QgcHJhY3RpY2Fs IHNvbHV0aW9uIHRvIHRoZSB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VjdGlvbiA0LjEu NC4gJnF1b3Q7ZXhwJnF1b3Q7IChFeHBpcmF0aW9uIFRpbWUpIENsYWltIChhbmQgb3RoZXIgdGlt ZSBiYXNlZCBDbGFpbXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5X aGF0IHNob3VsZCBteSBiZWhhdmlvciBiZSBpZiBJIHNpbXBseSBkb24ndCBrbm93IHdoYXQgdGhl IHRpbWUgaXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oSSdtIGp1 c3QgYSBkdW1iIGRldmljZSwgYW5kIG15IFJUQyBpcyBjbGFpbWluZyBpdCBpcyBKYW4xc3QsIDE5 NzApIC0gSSdtIGFzc3VtaW5nIEkgbXVzdCBub3QgcHJvY2VzcyB0aGlzIEpXVD8gRG9lcyB0aGlz IGNyZWF0ZSBib290c3RyYXBwaW5nIGlzc3Vlcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzAwNzBDMCI+VGhlIHVzZSBvZiBhbGwgY2xhaW1zIGlzIG9wdGlvbmFsLiAmbmJzcDtJdOKAmXMg dXAgdG8gYXBwbGljYXRpb25zIHdoaWNoIG9uZXMgbWFrZSBzZW5zZSBmb3IgdGhlbSB0byB1c2Uu Jm5ic3A7IEluIHVzZSBjYXNlcyBpbiB3aGljaCBwYXJ0aWNpcGFudHMgZG9u4oCZdCBrbm93IHRo ZSB0aW1lLCBlaXRoZXIgdGhpcyBjbGFpbSB3b3VsZCBub3QgYmUgdXNlZCBieSB0aGUgYXBwbGlj YXRpb24NCiBvciB0aGUgYXBwbGljYXRpb24gd291bGQgbmVlZCB0byBkZWZpbmUgYXBwbGljYXRp b24tc3BlY2lmaWMgYmVoYXZpb3JzIGZvciB3aGF0IHRvIGRvIGluIHRob3NlIGNhc2VzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij41LjMuIFJlcGxpY2F0aW5nIENsYWltcyBhcyBIZWFkZXIgUGFyYW1ldGVycyBU aGlzIHNlY3Rpb24gc2NhcmVzIG1lLCBhbmQgSSBob3BlIEknbSBzaW1wbHkgbm90IHVuZGVyc3Rh bmRpbmcgd2hhdCBpcyBiZWluZyBwcm9wb3NlZC4gSWYgeW91IHNlbmQgdGhlIHVuZW5jcnlwdGVk IHZlcnNpb24gb2Ygc29tZSBlbmNyeXB0ZWQgQ2xhaW1zIHNvbWUgaW1wbGVtZW50YXRpb25zIHdp bGwgbWFrZSBpbXBvcnRhbnQNCiBzZWN1cml0eSBkZWNpc2lvbnMgYmFzZWQgdXBvbiB0aG9zZSB1 bmVuY3J5cHRlZCBjbGFpbXMsIGV2ZW4gaWYgeW91IHRlbGwgdGhlbSBpbiBhIHNlcmlvdXMgdm9p Y2Ugbm90IHRvLg0KPGEgaHJlZj0iaHR0cDovL3hrY2QuY29tLzExODEvIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3hrY2QuY29tLzEx ODEvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Rm9yIHdo YXQgaXTigJlzIHdvcnRoLCB0aGUgY29udGV4dCBpbiB3aGljaCB0aGlzIGFyb3NlIHdhcyB3aGVu IGFwcGxpY2F0aW9uIHVzZWQgaW50ZXJtZWRpYXRlIHNvZnR3YXJlIHRoYXQgaW5zcGVjdGVkIHRo ZSBhdWRpZW5jZSBvZiBhbiBlbmNyeXB0ZWQgSldUIGluIG9yZGVyIHRvIHJvdXRlIGl0IHRvIHRo ZSBjb3JyZWN0IHJlY2lwaWVudC4mbmJzcDsgT25seSB0aGUNCiByZWNpcGllbnQgaGFzIHRoZSBr ZXkgdG8gZGVjcnlwdCB0aGUgSldUIGFuZCBsb29rIGF0IHRoZSBlbmNyeXB0ZWQgYXVkaWVuY2Ug dmFsdWUuJm5ic3A7IEJ1dCBieSBwbGFjaW5nIGFuIHVuZW5jcnlwdGVkIGNvcHkgb2YgdGhlIGF1 ZGllbmNlIGluIHRoZSBoZWFkZXIsIHRoZSByb3V0aW5nIHNvZnR3YXJlIGNvdWxkIGluc3BlY3Qg aXQgYW5kIHJvdXRlIGl0IGNvcnJlY3RseS4mbmJzcDsgVGhpcyBzZWVtZWQgdG8gdGhlIHdvcmtp bmcgZ3JvdXAgbGlrZSBhIGxlZ2l0aW1hdGUNCiB1c2UgY2FzZSwgYW5kIHNvIHdlIGRlY2lkZWQg dG8gc3VwcG9ydCBpdC4mbmJzcDsgVGhpcyBmZWF0dXJlIHdhcyBwcm9wb3NlZCBhbmQgZGlzY3Vz c2VkIGluIHRoaXMgdGhyZWFkOg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTEzMTUuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTEzMTUuaHRtbDwvYT4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkFsc28sIHRoZSBTSE9VTEQgaW4gJnF1b3Q7SWYgc3VjaCByZXBsaWNhdGVkIENs YWltcyBhcmUgcHJlc2VudCwgdGhlIGFwcGxpY2F0aW9uIHJlY2VpdmluZyB0aGVtIFNIT1VMRCB2 ZXJpZnkgdGhhdCB0aGVpciB2YWx1ZXMgYXJlIGlkZW50aWNhbCwgLi4uJnF1b3Q7IC0gd2h5IGlz IHRoaXMgbm90IGEgTVVTVD8gQW5kIGlmIGFuIGFwcGxpY2F0aW9uICpkb2VzKiBjb21wYXJlIHRo ZW0gYW5kIHRoZXkgYXJlIG5vdCBpZGVudGljYWwsDQogd2hhdCBzaG91bGQgaXQgZG8/Jm5ic3A7 IFBlcmhhcHMgYSBtdWNoIHN0cm9uZ2VyIGp1c3RpZmljYXRpb24gZm9yIGNhcnJ5aW5nIDIgY29w aWVzIG9mIHRoZSBkYXRhIGlzIGluIG9yZGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDA3MEMwIj5UaGUgdGV4dCByaWdodCBhZnRlciB0aGlzIGluIHRoZSBzcGVjIGFscmVhZHkgYW5z d2VycyB0aGlzIHF1ZXN0aW9uOiDigJx1bmxlc3MgdGhlIGFwcGxpY2F0aW9uIGRlZmluZXMgb3Ro ZXIgc3BlY2lmaWMgcHJvY2Vzc2luZyBydWxlcyBmb3IgdGhlc2UgQ2xhaW1z4oCdLiZuYnNwOyBJ dOKAmXMgYSDigJxTSE9VTETigJ0gYmVjYXVzZSBhcHBsaWNhdGlvbnMgbWlnaHQgbmVlZCB0byBk bw0KIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkVkaXRvcmlhbDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlRoZSBpbnRybyBpcyBhbG1vc3QgaWRlbnRpY2FsIHRvIHRoZSBh YnN0cmFjdC4gTWFraW5nIHRoZSBhYnN0cmFjdCBtb3JlIGFic3RyYWN0LCBvciB0aGUgaW50cm8g bW9yZSBpbnRyb2R1Y3RvcnkgKEkgaGF2ZSBubyBpZGVhIHdoYXQgbWFueSBvZiB0aGUgYWNyb255 bXMgd2VyZSEpIHdvdWxkIGJlIG5pY2UuIFNvbWV0aGluZyBzaG9ydCBleHBsYWluaW5nIHdoYXQg YSBKV1QgaXMsIHdoeSBJJ2QgbGlrZSBvbmUsd2hhdA0KIHRoZXkgZ2V0IHVzZWQgZm9yLCB3aHkg SSBzaG91bGQga2VlcCByZWFkaW5nIHRoaXMgZG9jdW1lbnQgd291bGQgYmUgdmVyeSBoZWxwZnVs IC0gYmFzaWNhbGx5IGEgYmFja2dyb3VuZCB0eXBlIHNlY3Rpb24uLi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwNzBDMCI+U3BlY2lmaWMgd29yZGluZyBzdWdnZXN0aW9ucyB3b3VsZCBi ZSB3ZWxjb21lZC4mbmJzcDsgQXMgZm9yIG5vdCBrbm93aW5nIHdoYXQgdGhlIGFjcm9ueW1zIGFy ZSwgSeKAmW0gdG9sZCB0aGF0IHRoZSBzdHlsZSBndWlkZXMgZG9u4oCZdCBhbGxvdyByZWZlcmVu Y2VzIHRvIGJlIHB1dCBpbiB0aGUgYWJzdHJhY3QuJm5ic3A7IE90aGVyd2lzZSwgZm9yIGluc3Rh bmNlLCB0aGVyZSB3b3VsZA0KIGJlIGEgcmVmZXJlbmNlIHRoZXJlIHRvIFJGQyA3MTU5IHNvIHBl b3BsZSB3aG8gZG9u4oCZdCBrbm93IHdoYXQgSlNPTiBpcyBrbm93IHdoZXJlIHRvIGxvb2sgdG8g Z28gZmluZCBvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5pdHM6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5BYnN0cmFjdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+TzogaXMgYSBjb21wYWN0IFVSTC1zYWZlIG1lYW5zPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QOiBpcyBhIGNvbXBhY3QsIFVSTC1zYWZlIG1lYW5zPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4z LiZuYnNwOyBKU09OIFdlYiBUb2tlbiAoSldUKSBPdmVydmlldzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+TzogVGhlIGNvbnRlbnRzIG9mIHRoZSBKT1NFIEhlYWRlciBk ZXNjcmliZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UDogU3BlbGwg b3V0IEpPU0U7IGZpcnN0IHVzZSBpbiBkb2N1bWVudCBhcyBmYXIgYXMgSSBjb3VsZCBzZWU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+QWN0dWFsbHksIHRoZSBmaXJzdCB1c2Ug b2YgdGhlIHRlcm0g4oCcSk9TRSBIZWFkZXLigJ0gaXMgaW4gU2VjdGlvbiAyIChUZXJtaW5vbG9n eSksIHdoZXJlIGl0IGlzIGluY29ycG9yYXRlZCBpbnRvIHRoaXMgc3BlY2lmaWNhdGlvbiBieSBy ZWZlcmVuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjUuMiAmcXVvdDtjdHkmcXVvdDsgKENvbnRlbnQgVHlwZSkgSGVh ZGVyIFBhcmFtZXRlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Tzog bm9ybWFsIGNhc2Ugd2hlcmUgbmVzdGVkIHNpZ25pbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlA6IG5vcm1hbCBjYXNlIGluIHdoaWNoIG5lc3RlZCBzaWduaW5nPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij44 LiZuYnNwOyBJbXBsZW1lbnRhdGlvbiBSZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPk86IEZvciBpbnN0YW5jZSwgYW4gYXBwbGljYXRpb24gbWlnaHQg cmVxdWlyZSBzdXBwb3J0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgZm9yIGVuY3J5cHRlZCBKV1RzIGFuZCBOZXN0ZWQgSldUczsgYW5vdGhlciBt aWdodCByZXF1aXJlIHN1cHBvcnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlA6IEZvciBpbnN0YW5jZSwgb25lIGFwcGxpY2F0aW9uIG1pZ2h0IHJlcXVpcmUgc3VwcG9y dCBbLi4uXSwgd2hpbGUgYW5vdGhlciBtaWdodCByZXF1aXJlIHN1cHBvcnQgWy4uLl08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3 MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjExLiBT ZWN1cml0eSBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+TzogVGhlIGVudGlyZSBsaXN0IG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzIGJl eW9uZCB0aGUgc2NvcGUgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyB0aGlzIGRvY3VtZW50LCBidXQgc29tZSBzaWduaWZpY2FudCBjb25zaWRl cmF0aW9ucyBhcmUgbGlzdGVkIGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5QOiBUaGUgZW50aXJlIGxpc3Qgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMg YmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+UjogQSBmZXcgb2YgdGhlIGNvbnNpZGVyYXRpb25zIGFyZSBhbHJl YWR5IGxpc3RlZCBhYm92ZTsgd2UgZG9uJ3QgbmVlZCB0byByZXN0YXRlIHRoYXQgdGhleSBhcmUg bGlzdGVkIGhlcmUgLS0gYW5kIGlmIHdlIGRvLCB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHNhaWQg bGlzdCB3b3VsZCBmb2xsb3csIG5vdCBiZSBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+U2V2ZXJhbCByZXZpZXdlcnMgaGF2ZSBvYmplY3RlZCB0byB0aGlzIHNlbnRl bmNlLiZuYnNwOyBJdHMgcmVtb3ZhbCBpcyBwbGFubmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xMS4yIFNp Z25pbmcgYW5kIEVuY3J5cHRpb24gT3JkZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPk86IFdoaWxlIHN5bnRhY3RpY2FsbHksIHRoZSBzaWduaW5nIGFuZCBlbmNyeXB0 aW9uIG9wZXJhdGlvbnMgZm9yIE5lc3RlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEpXVHMgbWF5IGJlIGFwcGxpZWQgaW4gYW55IG9yZGVyLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UDogV2hpbGUgc3ludGFjdGlj YWxseSB0aGUgc2lnbmluZyBhbmQgZW5jcnlwdGlvbiBvcGVyYXRpb25zIGZvciBOZXN0ZWQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBKV1RzIG1h eSBiZSBhcHBsaWVkIGluIGFueSBvcmRlciw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAw NzBDMCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5JIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hl biBpdCB3YXMgb2J2aW91c2x5IGEgYmFkIGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFi aWQgd2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdyZXQgYXQg aGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFp ciBvZiBwYW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyAtLS1tYWY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhZ2FpbiwgV2FycmVuLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439AE9DB28TK5EX14MBXC292r_-- From nobody Mon Sep 8 09:10:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCE11A88AA for ; Mon, 8 Sep 2014 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 fIsUG6JTFxuL for ; Mon, 8 Sep 2014 09:10:52 -0700 (PDT) Received: from na6sys009bog034.obsmtp.com (na6sys009bog034.obsmtp.com [74.125.150.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA0E1A88A7 for ; Mon, 8 Sep 2014 09:10:52 -0700 (PDT) Received: from mail-ig0-f171.google.com ([209.85.213.171]) (using TLSv1) by na6sys009bob034.postini.com ([74.125.148.12]) with SMTP ID DSNKVA3VCmTloa80NgfVgvlI0VnVZtjycCg9@postini.com; Mon, 08 Sep 2014 09:10:52 PDT Received: by mail-ig0-f171.google.com with SMTP id l13so2999269iga.4 for ; Mon, 08 Sep 2014 09:10:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=uuv/49iVYSChMtiBCB0n6CimZAflL9W7lSDBtbzd4+I=; b=Z8RTYQVtA0w8sErLn4OuhTnGJp4/LpuIdFqop8wRvCiRTwNty/jS5NaSWi9mCN14Cg qSPcBpi0AOlUBRb6nv1BJ4UQb6XA4Wlfm/Y/OVQrPbmKl/PmBvI9q45wELnw3be3NkPn 1uc1oeioDAt8sIeZ5VV2DmB5qymWxeXkE3fGF1EUb7qI1a331oFLqfciwyXoAzYFtg0l hRoVX2VHDClIKEGN96EizXUxij1qWaSHOOTaNDHNX1TKs7uLG2+nEA/7u2aDZlP1Nrx7 yOuNDziY7d+VFUMtLZWEr2DTZ0Z4fmVoq8ZcN6NIyEx3qlKOUWj5/HP7UiZVCtFQ8JAt 6omQ== X-Gm-Message-State: ALoCoQm5koM49bHAdox0XuYljiMG8qiSSn8Qao3MfSBolS2h2GReeELuN+oRiVlakdqu6lzzq/c0g7UBdGj+54QGE2EZmTiGjlfS5BqObQHAEtETghkfU/uZ1gIViSzVRFUvJkpZIhvK X-Received: by 10.42.4.136 with SMTP id 8mr9009668ics.57.1410192650264; Mon, 08 Sep 2014 09:10:50 -0700 (PDT) X-Received: by 10.42.4.136 with SMTP id 8mr9009655ics.57.1410192650158; Mon, 08 Sep 2014 09:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Mon, 8 Sep 2014 09:10:19 -0700 (PDT) From: Brian Campbell Date: Mon, 8 Sep 2014 10:10:19 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a1134476cfa619c0502900fd8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/grGwdh_3kBWThnAwwJaETNbghSI Cc: "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , Warren Kumari , "oauth@ietf.org" , "jose@ietf.org" , "secdir@ietf.org" Subject: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:10:54 -0000 --001a1134476cfa619c0502900fd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA. I agree that "plaintext=E2=80=9D is not the most intuitive wording choice a= nd that "unsecured" might better convey what's going on with the "none" JWS algorithm. Mike mentioned that, if this change is made in JWT, there are parallel changes in JWS. But note that there are also such changes in JWA (more than in JWS actually). On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones wrote: > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Monday, September 01, 2014 3:40 PM > To: secdir@ietf.org; draft-ietf-oauth-json-web-token.all@tools.ietf.org > Subject: Review of: draft-ietf-oauth-json-web-token > > I'm a little confused by something in the Terminology section (Section 2)= : > > Plaintext JWT > > A JWT whose Claims are not integrity protected or encrypted. > > The term plaintext to me means something like "is readable without > decrypting / much decoding" (something like, if you cat the file to a > terminal, you will see the information). Integrity protecting a string > doesn't make it not easily readable. If this document / JOSE uses > "plaintext" differently (and a quick skim didn't find anything about > > this) it might be good to clarify. Section 6 *does* discuss plaintext > JWTs, but doesn't really clarify the (IMO) unusual meaning of the term > "plaintext" here. > > > > I=E2=80=99ve discussed this with the other document editors and we agree = with you > that =E2=80=9Cplaintext=E2=80=9D is not the most intuitive wording choice= in this context. > Possible alternative terms are =E2=80=9CUnsecured JWT=E2=80=9D or =E2=80= =9CUnsigned JWT=E2=80=9D. I think > that =E2=80=9CUnsecured JWT=E2=80=9D is probably the preferred term, sinc= e JWTs that are > JWEs are also unsigned, but they are secured. Working group =E2=80=93 ar= e you OK > with this possible terminology change? (Note that the parallel change > =E2=80=9CPlaintext JWS=E2=80=9D -> =E2=80=9CUnsecured JWS=E2=80=9D would = also be made in the JWS spec.) > > > --001a1134476cfa619c0502900fd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
cc'ing JOSE on a minor JWT review comment that might i= mpact JWS/JWA.

I agree that "plaintext=E2=80=9D is not th= e most intuitive wording choice and that "unsecured" might better= convey what's going on with the "none" JWS algorithm.
Mike mentioned that, if this change is made in JWT, there are = parallel changes in JWS. But note that there are also such changes in JWA (= more than in JWS actually).
<= br>
On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

-----Original Message-----
From: Warren Kumari [mailto:warren@kumari.net]
Sent: Monday, September 01, 2014 3:40 PM
To: secdir@ietf.org; draft-ietf-oauth-json-web-token.all@tools.ietf.org
Subject: Review of: draft-ietf-oauth-json-web-token

I'm a little confused by something in the Terminology section (Secti= on 2):

Plaintext JWT

A JWT whose Claims are not integrity protected or encrypted.

The term plaintext to me means something like "is readable without = decrypting / much decoding" (something like, if you cat the file to a = terminal, you will see the information). Integrity protecting a string does= n't make it not easily readable. If this document / JOSE uses "plaintext" differently (= and a quick skim didn't find anything about

this) it might be good to clarify. Section 6 *does* discuss plaintext JW= Ts, but doesn't really clarify the (IMO) unusual meaning of the term &q= uot;plaintext" here.

=C2=A0

I=E2=80=99ve discussed this with th= e other document editors and we agree with you that =E2=80=9Cplaintext=E2= =80=9D is not the most intuitive wording choice in this context.=C2=A0 Poss= ible alternative terms are =E2=80=9CUnsecured JWT=E2=80=9D or =E2=80=9CUnsi= gned JWT=E2=80=9D.=C2=A0 I think that =E2=80=9CUnsecured JWT=E2=80=9D is probab= ly the preferred term, since JWTs that are JWEs are also unsigned, but they= are secured.=C2=A0 Working group =E2=80=93 are you OK with this possible t= erminology change?=C2=A0 (Note that the parallel change =E2=80=9CPlaintext = JWS=E2=80=9D -> =E2=80=9CUnsecured JWS=E2=80=9D would also be made in the JWS spec.)

=C2=A0

--001a1134476cfa619c0502900fd8-- From nobody Wed Sep 10 01:57:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170B31A06B1 for ; Wed, 10 Sep 2014 01:57:28 -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, SPF_PASS=-0.001] autolearn=ham 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 DTfjhF2PKKy3 for ; Wed, 10 Sep 2014 01:57:26 -0700 (PDT) Received: from mail-lb0-x244.google.com (mail-lb0-x244.google.com [IPv6:2a00:1450:4010:c04::244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B801A06A8 for ; Wed, 10 Sep 2014 01:57:26 -0700 (PDT) Received: by mail-lb0-f196.google.com with SMTP id 10so3490262lbg.7 for ; Wed, 10 Sep 2014 01:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=P+/L1dofhZ0Y55ZokIUSIhBIUgbWAPigqyt1z/cUZBA=; b=R4oA0pmFH5ycK6pPK7ZteKnqne4LLGCyjGLgVOpBCSGVYNNZN+1/6zehmazY1kXs1S 20/fFElPF6S5Jg7DYT/LFyjJynX+2JRuFLeyxS3BFp3Z6i3GT0lmdpjusfPsFSOhBJKC uOqFNmHhI8K49BZ62CtGcY1rdq9Y5ohYaFdVrGS/cM3JPLzmnLBtC7vDQDKRzwrBJpZG Yt8JKEzeZlbumzcLZOAsaLqpRvLa53ViimQZV57eQ97ATFNRlC7ppUEW/ZGiTw5gPnK0 8zPXELzSJ03o9byA6Ni5DazQRUJI7TetRkxBjqYI9GZCkUFXM0dmH2oQ+6iSOZJG+lqI iOFA== MIME-Version: 1.0 X-Received: by 10.112.61.68 with SMTP id n4mr1587145lbr.91.1410339444774; Wed, 10 Sep 2014 01:57:24 -0700 (PDT) Received: by 10.112.134.105 with HTTP; Wed, 10 Sep 2014 01:57:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Sep 2014 14:27:24 +0530 Message-ID: From: Rex Albert To: oauth@ietf.org Content-Type: multipart/alternative; boundary=e89a8f839eef9e5e370502b23d9c Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DxrcUjkbg6Wg8rqoB0ksIIz22KU Subject: [OAUTH-WG] Fwd: Is OAUTHV2-HTTP_MAC dead? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 08:57:28 -0000 --e89a8f839eef9e5e370502b23d9c Content-Type: text/plain; charset=UTF-8 Hi, We are looking at implementing OAUTHV2-HTTP-MAC whose draft is in an expired state.( http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05) Is it dead or is it going to be a standard anytime? or are we going to implement at our own risk? or is there a better standard/draft ( alive ) which might supersede this draft ? thank you for your time. I am a newbie to the IETF draft process and kindly excuse my naivety. -rex --e89a8f839eef9e5e370502b23d9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Hi,We are looking at implementing OAUTHV2-HTTP-MAC whose draft is in an expi= red state.(=C2=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05= )=C2=A0=C2=A0Is it dead or is it going to be a standard anytime? or are we = going to implement at our own risk? or is there a better standard/draft ( a= live ) which might supersede this draft ?=C2=A0

thank you for your time.
I am a newbie to the= IETF draft process and kindly excuse my naivety.=C2=A0
-rex

--e89a8f839eef9e5e370502b23d9c-- From nobody Wed Sep 10 02:49:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8CE1A06CF for ; Wed, 10 Sep 2014 02:49:47 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 OHRExe0LIzhx for ; Wed, 10 Sep 2014 02:49:46 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795CE1A06CA for ; Wed, 10 Sep 2014 02:49:46 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id q5so5902983wiv.6 for ; Wed, 10 Sep 2014 02:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=NY6UeJBoFfXx+wZGGryRSKp2Jxqu1vLdUdy+P4EnRPU=; b=0/IA1u04JebLeUXdMFBDrxM1eSZXJZWp06mq/b3Ggvqyq1bL5TIjIYeRl9h6RscDFW kiDsM/HSZuOF+J6NMyDsj3uXbKn9sZBmAjrZhhqnuSzHcdzet/hY5rMHaOOZ6obHrFXc d8c1hwNPENetQ0LwPdQseOsyBcE2Zm1Tz+zhNtIfE8j1EZc6LVt42bQvmodH/Eka9k+7 MWxWX93NbGBB0nQbVUdbPGl10AmLKMEacgMkYeg31haFnt6XLUVbSogeijkjFcLWMEPt ZJzuPJP3I+LFgq0Qwhfu2SBYlSCCugXwd7bZii6+HPB4ALdPNGMhehuFFrGzh5KT7Svk XrOg== X-Received: by 10.180.73.6 with SMTP id h6mr35576028wiv.65.1410342585152; Wed, 10 Sep 2014 02:49:45 -0700 (PDT) Received: from [192.168.2.7] ([109.255.231.6]) by mx.google.com with ESMTPSA id xs2sm703977wjb.25.2014.09.10.02.49.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Sep 2014 02:49:44 -0700 (PDT) Message-ID: <54101EB7.1000502@gmail.com> Date: Wed, 10 Sep 2014 10:49:43 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9LJxGFi8qIfvAoemxmnT5-mwtPU Subject: Re: [OAUTH-WG] Fwd: Is OAUTHV2-HTTP_MAC dead? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 09:49:48 -0000 Hi On 10/09/14 09:57, Rex Albert wrote: > > > Hi, > We are looking at implementing OAUTHV2-HTTP-MAC whose draft is in an > expired > state.(http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05) Is > it dead or is it going to be a standard anytime? or are we going to > implement at our own risk? or is there a better standard/draft ( alive ) > which might supersede this draft ? It's not going to be revived. Does not mean though one can not use the idea for implementing custom OAuth2 token schemes, IMHO it was a very simple and effective 'PoP' approach, and it is easy to document and support. FYI, we support a Hawk scheme (not part of OAuth2 work at all, kind of 'draft-ietf-oauth-v2-http-mac-06') as an access token scheme in our project. As far as I understand new proof-of-possession documents the group is working upon will offer the alternative standard solutions. Cheers, Sergey > > thank you for your time. > I am a newbie to the IETF draft process and kindly excuse my naivety. > -rex > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From rexandalbert@gmail.com Wed Sep 10 01:00:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA99B1A0680 for ; Wed, 10 Sep 2014 01:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 b0a2ogtSAxg6 for ; Wed, 10 Sep 2014 01:00:07 -0700 (PDT) Received: from mail-la0-x242.google.com (mail-la0-x242.google.com [IPv6:2a00:1450:4010:c03::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F511A0677 for ; Wed, 10 Sep 2014 01:00:06 -0700 (PDT) Received: by mail-la0-f66.google.com with SMTP id s18so2280916lam.1 for ; Wed, 10 Sep 2014 01:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UNKuKQ7iqOlzVA64Aq73awOTLmxUNvx8ZvIPlqT9dcU=; b=GB0MtFUlSkCs8Ig8KkdpbYW2IxUVMhPwUkmBHff0S+rRFhXZKgUj4zEl/1GmoOZ67E a4qf53+hUsTHCbshQ6j1jZd55BZ3vYBkSx5foSTXoF1QXtIeTfWYXvdWbDhPovuRjQek Fco/zLAEPhw1jl0fszr8Dtksjs3BdTiZzekbm5iNO+HB1KHYqiBePiZeaNAcMTXLJT3h otcT0S0j9J76oKfkKmliChky1lKZAIkeThWQV6KDIJsfVjmjI2ph9iGn5ZH09sFRlVUa Yojm9mSVm53oyN37vA5oTcBFVf0s64CVwWjPX43W2cCcdZO5dVRJ+PhJgvZdWcc5vlvB enBg== MIME-Version: 1.0 X-Received: by 10.112.217.2 with SMTP id ou2mr953929lbc.101.1410336005091; Wed, 10 Sep 2014 01:00:05 -0700 (PDT) Received: by 10.112.134.105 with HTTP; Wed, 10 Sep 2014 01:00:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Sep 2014 13:30:05 +0530 Message-ID: From: Rex Albert To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a1134840898f5a90502b17002 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TSN6-EhgR3I4YmkmFNxzJEVH8n8 X-Mailman-Approved-At: Wed, 10 Sep 2014 07:03:25 -0700 Subject: [OAUTH-WG] Fwd: Is OAUTHV2-HTTP_MAC dead? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 08:53:46 -0000 --001a1134840898f5a90502b17002 Content-Type: text/plain; charset=UTF-8 Hi, We are looking at implementing OAUTHV2-HTTP-MAC whose draft is in an expired state.( http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05) Is it dead or is it going to be a standard anytime? or are we going to implement at our own risk? or is there a better standard/draft ( alive ) which might supersede this draft ? thank you for your time. I am a newbie to the IETF draft process and kindly excuse my naivety. -rex --001a1134840898f5a90502b17002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



Hi= ,
We are looking at implementing OAUTHV2-HTTP-MAC whose draft is in an = expired state.(=C2=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05= )=C2=A0=C2=A0Is it dead or is it going to be a standard anytime? or are= we going to implement at our own risk? or is there a better standard/draft= ( alive ) which might supersede this draft ?=C2=A0

thank you for your time.
I am a newbie to the= IETF draft process and kindly excuse my naivety.=C2=A0
-rex

--001a1134840898f5a90502b17002-- From nobody Wed Sep 10 08:57:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A111A8769 for ; Wed, 10 Sep 2014 08:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 HpaaCbuZaxdM for ; Wed, 10 Sep 2014 08:56:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EB01A8757 for ; Wed, 10 Sep 2014 08:56:59 -0700 (PDT) Received: from [192.168.10.160] ([167.220.25.81]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LyVpm-1YObcf0I2o-015mel; Wed, 10 Sep 2014 17:56:55 +0200 Message-ID: <541074C3.3030400@gmx.net> Date: Wed, 10 Sep 2014 17:56:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: oauth@ietf.org, rexandalbert@gmail.com References: <54101EB7.1000502@gmail.com> In-Reply-To: <54101EB7.1000502@gmail.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8QELamf2i6esMQMsLAhrNwqDbPBOKKl3l" X-Provags-ID: V03:K0:bFhlSgynvBXwXmvy951EG8J/Up6g+fbmALW/uemIrjAJrbHZs7E HAzklZfzpLJXWcSQ1kIPjR8+CsfXtH2/cl1CSpT3ejgryf/3A+ZvkwuBzxU88C7VeoWKD9O iXEv90Q1OFJj9YuSLw6Ssj4MHw5YjckqZb1byviEPn7Rx9Z4bN2DPMTzwQlwvmNRrX7fmTx lirssTrou2UEMYe4oTHFw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8SKzfVH4n4gkHww_qfxTBw6zhig Subject: Re: [OAUTH-WG] Fwd: Is OAUTHV2-HTTP_MAC dead? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 15:57:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8QELamf2i6esMQMsLAhrNwqDbPBOKKl3l Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rex, the document has been superseded by the PoP work (which was subsequently split into various other documents).= That, however, does not mean that the content is dead. The mechanism for the authorization server to convey the symmetric key to the client is now documented in . The high level description / overview is now documented in . The actual mechanism for the client to apply the key to the request to the resource server is now documented in . While < draft-ietf-oauth-signed-http-request> today is different to the mechanism described in it also has to be said that it is the weakest document in the entire document set at the moment. So, there is still a chance to incorporate your design requirements into the appropriate parts of the work since the work is still in progress. It would be good to know what your requirements/interests are. Ciao Hannes On 09/10/2014 11:49 AM, Sergey Beryozkin wrote: > Hi > On 10/09/14 09:57, Rex Albert wrote: >> >> >> Hi, >> We are looking at implementing OAUTHV2-HTTP-MAC whose draft is in an >> expired >> state.(http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05) Is= >> it dead or is it going to be a standard anytime? or are we going to >> implement at our own risk? or is there a better standard/draft ( alive= ) >> which might supersede this draft ? >=20 > It's not going to be revived. Does not mean though one can not use the > idea for implementing custom OAuth2 token schemes, IMHO it was a very > simple and effective 'PoP' approach, and it is easy to document and > support. FYI, we support a Hawk scheme (not part of OAuth2 work at all,= > kind of 'draft-ietf-oauth-v2-http-mac-06') as an access token scheme in= > our project. >=20 > As far as I understand new proof-of-possession documents the group is > working upon will offer the alternative standard solutions. >=20 > Cheers, Sergey >=20 >> >> thank you for your time. >> I am a newbie to the IETF draft process and kindly excuse my naivety. >> -rex >> >> >> >> _______________________________________________ >> 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 --8QELamf2i6esMQMsLAhrNwqDbPBOKKl3l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEHTEAAoJEGhJURNOOiAtodcIAJ/FEhrnbMWTReGR/IFcdbLM IilxahQevCYu+FOuFcyebLNli/9Tbq8qApE0EJ0scR5rCnSBAMYG3DEc3XALTaNv OvUnUWHmnsMfam3UjgrxLre0vTp3vhWmR3SdPBNkNWIOAoncwEAkVmXCDf0SIMYp JGoOxVYuoOSpyg+wdjNWg8zhmCN1sVBvjzf5UNMv10yuGfF4TpzMXdI7mUTJrosR pAa3ea+bIpUdaBsvOnjqWBCKe51Bk0EKli9s+1fECrLNv5SbuLgNs+6LSgAvnf02 vPpBPMWXDkSM8SJNxDHb0eu55zoUJuOuUI4FxrqRbY9dSNF2QPX7L1iLOy6z5Xc= =DnBQ -----END PGP SIGNATURE----- --8QELamf2i6esMQMsLAhrNwqDbPBOKKl3l-- From nobody Wed Sep 10 16:50:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191621A0409 for ; Wed, 10 Sep 2014 16:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 zvQJ_mPOH2QI for ; Wed, 10 Sep 2014 16:50:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD061A03F8 for ; Wed, 10 Sep 2014 16:50:13 -0700 (PDT) Received: from [192.168.10.161] ([167.220.25.81]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LkgAG-1Y21oc2MkO-00aYxt for ; Thu, 11 Sep 2014 01:50:11 +0200 Message-ID: <5410E3AF.3030806@gmx.net> Date: Thu, 11 Sep 2014 01:50:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xWAMg9bsfLabAd3kmuA66UQDVAFwINgUi" X-Provags-ID: V03:K0:SZjVVhtDm3mGPXayZAU4h7jtI/LN3U+k8cG7El7vYKokYPZkxjk sAVtKzuHiUZc16RnytQ+gCbCStN2UyNQrNT4Bealp/Qc7tJ/zrJnm32KJU05FjYvRl0rI/g iUqYEGjqfF8VglXuB0NNBSgruNPgt5tq5tO2t7AuEs97RVIh/7htpOG8D+pw2UCtl7w+P7f ES8Hu9w6hKaGASVzsTSbg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5SzyRx-OlOhMUkI8hKZVV9JCT88 Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:50:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xWAMg9bsfLabAd3kmuA66UQDVAFwINgUi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, in response to the discussions at the last IETF meeting the authors of the "Dynamic Client Registration Management Protocol" http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have changed the document type to "Experimental". We need to make a decision about the next steps for the document and we see the following options: a) Publish it as an experimental RFC b) Remove it from the working group and ask an AD to shepherd it c) Remove it from the working group and let the authors publish it via the independent submission track. In any case it would be nice to let folks play around with it and then, after some time, come back to determine whether there is enough interest to produce a standard. Please let us know what you think! Ciao Hannes & Derek --xWAMg9bsfLabAd3kmuA66UQDVAFwINgUi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEOOvAAoJEGhJURNOOiAtR0wH/Aqw7CtkRlD6Eazxx6fD2XNo 6EGh2B+LMV5aFK4/EW/WEjVlNWm4b+dnXC6MTxAXEWOaTAbdhTfkVFQww+6/Uklu qsAO1qwE7Ra2HGsCbIG+nREd17e2UgJOT2K/R5+Zi5NB96BJeghkAWUNU4mDgfoz F5ISVyg0qE9T3lJIYIWPjCyRKEXjaHLm+OyEto4392+tGCagkYMnAsnxyS/3yfia H7PYqbGSKnifvmrlYmq/uAi8+9tXYWqloockocsiwR27ywdT+F1hd8zXqjuTwP96 U1j0FRccpgzd3++BaII3Nvls8ZfSYTl6FVuYajLeMgoXDhxtbZn/epbcwapoRWc= =iZtg -----END PGP SIGNATURE----- --xWAMg9bsfLabAd3kmuA66UQDVAFwINgUi-- From nobody Wed Sep 10 16:50:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB8D1A0438 for ; Wed, 10 Sep 2014 16:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 uHceJtU2Sl8g for ; Wed, 10 Sep 2014 16:50:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2A21A0408 for ; Wed, 10 Sep 2014 16:50:22 -0700 (PDT) Received: from [192.168.10.161] ([167.220.25.81]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MEFIm-1XYSHL3aBM-00FWcR for ; Thu, 11 Sep 2014 01:50:20 +0200 Message-ID: <5410E3B9.2080208@gmx.net> Date: Thu, 11 Sep 2014 01:50:17 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MK0mTxIANjEg2nB5BjdQfsgJbUeXwvc85" X-Provags-ID: V03:K0:R/sBlmylc7mAAhTl3Kj0Z366IjjjEfuc9ki9lrcPNAA+2BBNCJZ YlObo4SObMEhK48H5iVK2aWKdY+c+99BPdT/1Xcr93NZPC1QhaVuGan3A7aGF8dQko8M8qr firzW6z9o+fdWUIhSsi7Sa+GSg8m0veC9Ls4Y8+qM1GeCsNjEB8Npaja8uYNUYv73TgdMaz aYJ3fHRFJ1gMx7BNY4ocA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/duDaux1DSY_Ae4cdBy2TZb4IHbc Subject: [OAUTH-WG] Dynamic Client Registration Sent to the IESG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 23:50:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MK0mTxIANjEg2nB5BjdQfsgJbUeXwvc85 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I have just sent the Dynamic Client Registration document to the IESG. The final shepherd write-up for the document can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/= Ciao Hannes --MK0mTxIANjEg2nB5BjdQfsgJbUeXwvc85 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEOO5AAoJEGhJURNOOiAttkoH/A1hp2uWJQ45ckq69sL0RysK NcizR2T8/EBET2zWqapjWQcYGAF7bXhuES8/LS1Tu+ZbMZCrDxgFuDeza6PAFBtP 1f1dYVxDLjzdMLCiu7ekjZioh52/NBJ6WYgnpIeW+U+b9Kf8ng1iN1SnlizXBZTI VKAeNZKdAZSoksAlXs66QxI8wFX6SjLjiheZkoud4bTmlvjbm6cjZ0FsK6dQvXp/ Bw0w/FqjsBfWqScmfxfNr5gZi4vGm2djYQyWhxpThLQbgfUMRm+Y/tdRmtoEi+bi Ao+H0j3QdrjjPG7wNL0Ql9oVNyE7Xqk1EH/By+R3m+HYyqQ5+HXZUhWlmTKPPbc= =qI2m -----END PGP SIGNATURE----- --MK0mTxIANjEg2nB5BjdQfsgJbUeXwvc85-- From nobody Wed Sep 10 17:05:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DC91A0432 for ; Wed, 10 Sep 2014 17:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 D8e4E-Bw31TO for ; Wed, 10 Sep 2014 17:04:58 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6951A03EE for ; Wed, 10 Sep 2014 17:04:57 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-b9-5410e728bbde Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 35.09.13180.827E0145; Wed, 10 Sep 2014 20:04:56 -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 s8B04u6s027542; Wed, 10 Sep 2014 20:04:56 -0400 Received: from [192.168.128.57] (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 s8B04sfd015777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Sep 2014 20:04:55 -0400 Message-ID: <5410E722.3070504@mit.edu> Date: Wed, 10 Sep 2014 20:04:50 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <5410E3AF.3030806@gmx.net> In-Reply-To: <5410E3AF.3030806@gmx.net> Content-Type: multipart/alternative; boundary="------------050100050005070108040002" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hRV1tV4LhBicHqKkcXSnfdYLU6+fcXm wOSxeNN+No8lS34yBTBFcdmkpOZklqUW6dslcGVsOjOZteCdVMWZ342sDYzvRLsYOTkkBEwk Vp+bxgZhi0lcuLceyObiEBKYzSSx6cljZpCEkMBGRok1k0MgEreZJO50r2QFSfAKqEnMfHue sYuRg4NFQFVi80llkDAbkDl9TQsTiC0qECVx51I/VLmgxMmZT1hAbBGBWIlLf0+AxYUFwiRW H+hlgtilJrH/cAtYDaeAusTOE5PBbGagmuvvPjBPYOSfhWTULCSpWUBXMAtYS3zbXQQRlpfY /nYOM4StLbGq9ywTsvgCRrZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6uZkleqkppZsYQUHN 7qK8g/HPQaVDjAIcjEo8vDuq+EOEWBPLiitzDzFKcjApifIueCIQIsSXlJ9SmZFYnBFfVJqT WnyIUYKDWUmEN+EBUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYI3 8hlQo2BRanpqRVpmTglCmomDE2Q4D9BwHZAa3uKCxNzizHSI/ClGXY51nd/6mYRY8vLzUqXE ee1BigRAijJK8+DmwJLRK0ZxoLeEeTVAqniAiQxu0iugJUxASw4a84MsKUlESEk1MHL5ZMou 7Nwi6lVetcaC83rTxT29PGnHzxbpivzz8dsSqnSsgrdqlVt//O2ty8//LwyZ9yhQ7dexOb4a RRJ7trEd2fPsqcYiPvkrVbxWVztmpjM1HnRZYnpFyezhpTUeZ6dMD+kI5Xl7tmZeqR1P4tRJ ZjXZ5dafVS2rj64KDzo/w+rkfLmSf0osxRmJhlrMRcWJAFmEERchAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/sQz3jG3U99qbPzLUZ40dkStoXU8 Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:05:02 -0000 This is a multi-part message in MIME format. --------------050100050005070108040002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit a) Publish it as experimental. There was reasonable support for this in both Toronto and London. -- Justin On 9/10/2014 7:50 PM, Hannes Tschofenig wrote: > Hi all, > > in response to the discussions at the last IETF meeting the authors of > the "Dynamic Client Registration Management Protocol" > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have > changed the document type to "Experimental". > > We need to make a decision about the next steps for the document and we > see the following options: > > a) Publish it as an experimental RFC > > b) Remove it from the working group and ask an AD to shepherd it > > c) Remove it from the working group and let the authors publish it via > the independent submission track. > > In any case it would be nice to let folks play around with it and then, > after some time, come back to determine whether there is enough interest > to produce a standard. > > Please let us know what you think! > > Ciao > Hannes & Derek > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050100050005070108040002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
a) Publish it as experimental. There was reasonable support for this in both Toronto and London.

 -- Justin

On 9/10/2014 7:50 PM, Hannes Tschofenig wrote:
Hi all,

in response to the discussions at the last IETF meeting the authors of
the "Dynamic Client Registration Management Protocol"
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have
changed the document type to "Experimental".

We need to make a decision about the next steps for the document and we
see the following options:

a) Publish it as an experimental RFC

b) Remove it from the working group and ask an AD to shepherd it

c) Remove it from the working group and let the authors publish it via
the independent submission track.

In any case it would be nice to let folks play around with it and then,
after some time, come back to determine whether there is enough interest
to produce a standard.

Please let us know what you think!

Ciao
Hannes & Derek






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

--------------050100050005070108040002-- From nobody Wed Sep 10 17:08:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4721A043D for ; Wed, 10 Sep 2014 17:08:41 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ZZ5YIAh1o81t for ; Wed, 10 Sep 2014 17:08:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:796]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2765A1A0426 for ; Wed, 10 Sep 2014 17:08:38 -0700 (PDT) Received: from BL2PR03CA012.namprd03.prod.outlook.com (10.255.109.29) by CY1PR0301MB0619.namprd03.prod.outlook.com (25.160.142.26) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Thu, 11 Sep 2014 00:08:15 +0000 Received: from BL2FFO11FD010.protection.gbl (207.46.163.207) by BL2PR03CA012.outlook.office365.com (10.255.109.29) with Microsoft SMTP Server (TLS) id 15.0.1019.16 via Frontend Transport; Thu, 11 Sep 2014 00:08:14 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Thu, 11 Sep 2014 00:08:14 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0195.002; Thu, 11 Sep 2014 00:07:51 +0000 From: Mike Jones To: Justin Richer , Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? Thread-Index: AQHPzVQXMo7NUx4JPEWFlt6NStEsLJv7Dd5A Date: Thu, 11 Sep 2014 00:07:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AEB872D@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <5410E3AF.3030806@gmx.net> <5410E722.3070504@mit.edu> In-Reply-To: <5410E722.3070504@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AEB872DTK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(60444003)(24454002)(199003)(479174003)(53754006)(76104003)(377454003)(83072002)(79102001)(83322001)(69596002)(512954002)(19625215002)(2171001)(85852003)(87936001)(77982001)(81542001)(26826002)(68736004)(74662001)(99396002)(15202345003)(64706001)(31966008)(74502001)(2501002)(4396001)(81342001)(97736003)(33656002)(21056001)(90102001)(84326002)(2656002)(85306004)(71186001)(106466001)(80022001)(66066001)(84676001)(46102001)(107886001)(76482001)(15975445006)(92566001)(107046002)(104016003)(106116001)(86362001)(77096002)(95666004)(50986999)(19617315012)(81156004)(85806002)(20776003)(19580405001)(19580395003)(92726001)(86612001)(16236675004)(76176999)(55846006)(44976005)(54356999)(19300405004)(6806004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0619; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03319F6FEF Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Abh6O45ZtqU4Y09U-XbLuwwKllc Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:08:42 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AEB872DTK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 This gets it off the working group's plate and lets us gather data about wh= ether this useful or not and whether it's right or whether changes are need= ed, based on actual usage experience. From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, September 10, 2014 5:05 PM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Ne= xt Steps? a) Publish it as experimental. There was reasonable support for this in bot= h Toronto and London. -- Justin On 9/10/2014 7:50 PM, Hannes Tschofenig wrote: Hi all, in response to the discussions at the last IETF meeting the authors of the "Dynamic Client Registration Management Protocol" http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have changed the document type to "Experimental". We need to make a decision about the next steps for the document and we see the following options: a) Publish it as an experimental RFC b) Remove it from the working group and ask an AD to shepherd it c) Remove it from the working group and let the authors publish it via the independent submission track. In any case it would be nice to let folks play around with it and then, after some time, come back to determine whether there is enough interest to produce a standard. Please let us know what you think! Ciao Hannes & Derek _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739439AEB872DTK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

This gets it off the work= ing group’s plate and lets us gather data about whether this useful o= r not and whether it’s right or whether changes are needed, based on actual usage experience.

 <= /p>

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, September 10, 2014 5:05 PM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Proto= col: Next Steps?

 

a) Publish it as experimental. There was reasonable = support for this in both Toronto and London.

 -- Justin

On 9/10/2014 7:50 PM, Hannes Tschofenig wrote:

Hi all,
 
in response to the discussions at the last IETF meeting the authors of=

the "Dynamic Client Registration Management Protocol"
http://too=
ls.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have=

changed th=
e document type to "Experimental".
 
We need to make a decision about the next steps for the document and w=
e
see the following options:
 
a) Publish it as an experimental RFC
 
b) Remove it from the working group and ask an AD to shepherd it<=
/o:p>
 
c) Remove it from the working group and let the authors publish it via=

the independent submission track.
 
In any case it would be nice to let folks play around with it and then=
,
after some time, come back to determine whether there is enough intere=
st
to produce a standard.
 
Please let us know what you think!
 
Ciao
Hannes & Derek
 
 
 




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

 

--_000_4E1F6AAD24975D4BA5B16804296739439AEB872DTK5EX14MBXC292r_-- From nobody Wed Sep 10 17:22:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905821A0272 for ; Wed, 10 Sep 2014 17:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, SPF_PASS=-0.001] autolearn=ham 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 ICNZY4bCu5aU for ; Wed, 10 Sep 2014 17:22:13 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50ADE1A0119 for ; Wed, 10 Sep 2014 17:22:13 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cm18so17986977qab.2 for ; Wed, 10 Sep 2014 17:22:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=ZIgNdFSRg3mggzhsVBWy9C4ZNbXPYVcf/ErqXoIRtok=; b=TM+vcyEoSdGAw8sBdJtpp0N7A1wKMTtgyqtZBozbb9olS92Y7zVTjHEtlIDZeIgnY6 /KDaZH4dTb/PhnHPDDPp51eWUZWYjJWZS9w85p+5fKLfh67PSJ7m0b9WbTHmEUo5aJwV LZT3GJD8FIpR3GDInDeWEBBTQ+dQr2+XxQeSNiX0ENBpX39gEHtlKkd0PklN5Zj0dboG kKsw1yt1xO3Xy4NNHc/yoEFPtoXMmJWS1HR4Ct7klG7ERN61f79sAXZWzbcuX7A2pN5l pdWuH9llvjQ2naRP1J0cq+iAGkTVQY5b+MDYJAHxUnybKRb1bciO8RVuzNy2gDqVE8jR hbzg== X-Gm-Message-State: ALoCoQlb4OaG9EpSdFWaDY2vLMd1i52Q2qEtpVg1+D+t/t+sKlQ03tUANWa25Aa5roIjQdJ+8bNu X-Received: by 10.224.64.201 with SMTP id f9mr67771140qai.64.1410394932267; Wed, 10 Sep 2014 17:22:12 -0700 (PDT) Received: from [192.168.1.39] (186-79-107-60.baf.movistar.cl. [186.79.107.60]) by mx.google.com with ESMTPSA id 95sm13597994qgm.18.2014.09.10.17.22.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 17:22:09 -0700 (PDT) References: <5410E3AF.3030806@gmx.net> <5410E722.3070504@mit.edu> <4E1F6AAD24975D4BA5B16804296739439AEB872D@TK5EX14MBXC292.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AEB872D@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-E816ADE3-B9E1-48E8-AEBB-2F27BC92FADA; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <9E84E470-90EB-4734-B091-C32A373EA1DC@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Wed, 10 Sep 2014 21:22:06 -0300 To: Mike Jones Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_xN-hlkak2dJX5vZrpb3MCacsno Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:22:15 -0000 --Apple-Mail-E816ADE3-B9E1-48E8-AEBB-2F27BC92FADA Content-Type: multipart/alternative; boundary=Apple-Mail-F2196318-5929-4621-A6D3-D3D461B6E7B1 Content-Transfer-Encoding: 7bit --Apple-Mail-F2196318-5929-4621-A6D3-D3D461B6E7B1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Sent from my iPhone > On Sep 10, 2014, at 9:07 PM, Mike Jones wrot= e: >=20 > +1 > =20 > This gets it off the working group=E2=80=99s plate and lets us gather data= about whether this useful or not and whether it=E2=80=99s right or whether c= hanges are needed, based on actual usage experience. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer > Sent: Wednesday, September 10, 2014 5:05 PM > To: Hannes Tschofenig; oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: N= ext Steps? > =20 > a) Publish it as experimental. There was reasonable support for this in bo= th Toronto and London. >=20 > -- Justin >=20 > On 9/10/2014 7:50 PM, Hannes Tschofenig wrote: > Hi all, > =20 > in response to the discussions at the last IETF meeting the authors of > the "Dynamic Client Registration Management Protocol" > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have > changed the document type to "Experimental". > =20 > We need to make a decision about the next steps for the document and we > see the following options: > =20 > a) Publish it as an experimental RFC > =20 > b) Remove it from the working group and ask an AD to shepherd it > =20 > c) Remove it from the working group and let the authors publish it via > the independent submission track. > =20 > In any case it would be nice to let folks play around with it and then, > after some time, come back to determine whether there is enough interest > to produce a standard. > =20 > Please let us know what you think! > =20 > Ciao > Hannes & Derek > =20 > =20 > =20 >=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 --Apple-Mail-F2196318-5929-4621-A6D3-D3D461B6E7B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Sent from my iPhone

On Sep 10, 2014, at 9:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=

+1

 

This gets it off the workin= g group=E2=80=99s plate and lets us gather data about whether this useful or= not and whether it=E2=80=99s right or whether changes are needed, based on actual usage experience.

 

From: OAuth [mailt= o:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, September 10, 2014 5:05 PM
To: Hannes Tschofenig; oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protoc= ol: Next Steps?

 

a) Publish it as experimental. There was reasonable s= upport for this in both Toronto and London.

 -- Justin

On 9/10/2014 7:50 PM, Hannes Tschofenig wrote:

Hi all,
 
in response to the discussions at the last IETF meeting the authors of<=
o:p>
the "Dynamic Client Registration Management Protocol"
http://tools=
.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have
changed the d=
ocument type to "Experimental".
 
We need to make a decision about the next steps for the document and we=

see the following options:
 
a) Publish it as an experimental RFC
 
b) Remove it from the working group and ask an AD to shepherd it
 
c) Remove it from the working group and let the authors publish it via<=
o:p>
the independent submission track.
 
In any case it would be nice to let folks play around with it and then,=

after some time, come back to determine whether there is enough interes=
t
to produce a standard.
 
Please let us know what you think!
 
Ciao
Hannes & Derek
 
 
 




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

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-F2196318-5929-4621-A6D3-D3D461B6E7B1-- --Apple-Mail-E816ADE3-B9E1-48E8-AEBB-2F27BC92FADA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwOTExMDAyMjA3WjAjBgkqhkiG9w0BCQQxFgQUYeXDsqFCwwaVkYDZ qiul+4xSIhcwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAVTcl0/gXit4FyS5l8bHjJUFu8KSweHxMkiK4dU0NcMQwzfJO TJMLR0ej3r7QdSjitQd4QUZv/qLwcWZEwdMdOiNjAEVoeP/oyg6txDYAGV25IhpEunECGAieocz9 Z3hKb3bR1f4vdZHFgMjYz92JLFbaZAp9rrW+VjQ6y5XJLuel0oXQqO5zMvEGRjLPS5pTdI30aanp Fa8NBzf+OyhdRxw56EM/GnBNTYezwX3/daaCO7FR1YVf2hGvG/Hx2A7ohufWFpo2218oxH6zaVJm Y1B/mctPYxR3kk3GWpdL2XwjbNRm/7LhCFnmm02e8+gZB2Cd1rePYC6v9GA7SBhgjAAAAAAAAA== --Apple-Mail-E816ADE3-B9E1-48E8-AEBB-2F27BC92FADA-- From nobody Wed Sep 10 22:10:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3151A03E9 for ; Wed, 10 Sep 2014 22:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 oeCTkGgtzZ_h for ; Wed, 10 Sep 2014 22:10:11 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A171A007C for ; Wed, 10 Sep 2014 22:10:09 -0700 (PDT) Received: from [91.2.95.1] (helo=[192.168.71.100]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1XRwdy-0005KJ-T9; Thu, 11 Sep 2014 07:10:07 +0200 Date: Thu, 11 Sep 2014 07:10:04 +0200 Message-ID: Importance: normal From: Torsten Lodderstedt To: John Bradley , Mike Jones MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_559816724808220" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OZ2Gp3LKMxOlvbmJo9kGOGnVeEk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 05:10:14 -0000 ----_com.android.email_559816724808220 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 KzEKCjxkaXY+LS0tLS0tLS0gVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0IC0tLS0tLS0tPC9kaXY+ PGRpdj5Wb246IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+IDwvZGl2PjxkaXY+RGF0 dW06MTEuMDkuMjAxNCAgMDI6MjIgIChHTVQrMDE6MDApIDwvZGl2PjxkaXY+QW46IE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gPC9kaXY+PGRpdj5DYzogb2F1dGhAaWV0 Zi5vcmcgPC9kaXY+PGRpdj5CZXRyZWZmOiBSZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBS ZWdpc3RyYXRpb24gTWFuYWdlbWVudCBQcm90b2NvbDogTmV4dCBTdGVwcz8gPC9kaXY+PGRpdj4K PC9kaXY+KzEKClNlbnQgZnJvbSBteSBpUGhvbmUKCk9uIFNlcCAxMCwgMjAxNCwgYXQgOTowNyBQ TSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToKCisxCiAK VGhpcyBnZXRzIGl0IG9mZiB0aGUgd29ya2luZyBncm91cOKAmXMgcGxhdGUgYW5kIGxldHMgdXMg Z2F0aGVyIGRhdGEgYWJvdXQgd2hldGhlciB0aGlzIHVzZWZ1bCBvciBub3QgYW5kIHdoZXRoZXIg aXTigJlzIHJpZ2h0IG9yIHdoZXRoZXIgY2hhbmdlcyBhcmUgbmVlZGVkLCBiYXNlZCBvbiBhY3R1 YWwgdXNhZ2UgZXhwZXJpZW5jZS4KIApGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyClNlbnQ6IFdlZG5lc2RheSwgU2Vw dGVtYmVyIDEwLCAyMDE0IDU6MDUgUE0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnOyBvYXV0aEBpZXRm Lm9yZwpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24g TWFuYWdlbWVudCBQcm90b2NvbDogTmV4dCBTdGVwcz8KIAphKSBQdWJsaXNoIGl0IGFzIGV4cGVy aW1lbnRhbC4gVGhlcmUgd2FzIHJlYXNvbmFibGUgc3VwcG9ydCBmb3IgdGhpcyBpbiBib3RoIFRv cm9udG8gYW5kIExvbmRvbi4KCiAtLSBKdXN0aW4KCk9uIDkvMTAvMjAxNCA3OjUwIFBNLCBIYW5u ZXMgVHNjaG9mZW5pZyB3cm90ZToKSGkgYWxsLAogCmluIHJlc3BvbnNlIHRvIHRoZSBkaXNjdXNz aW9ucyBhdCB0aGUgbGFzdCBJRVRGIG1lZXRpbmcgdGhlIGF1dGhvcnMgb2YKdGhlICJEeW5hbWlj IENsaWVudCBSZWdpc3RyYXRpb24gTWFuYWdlbWVudCBQcm90b2NvbCIKaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLW1hbmFnZW1lbnQtMDUgaGF2ZQpj aGFuZ2VkIHRoZSBkb2N1bWVudCB0eXBlIHRvICJFeHBlcmltZW50YWwiLgogCldlIG5lZWQgdG8g bWFrZSBhIGRlY2lzaW9uIGFib3V0IHRoZSBuZXh0IHN0ZXBzIGZvciB0aGUgZG9jdW1lbnQgYW5k IHdlCnNlZSB0aGUgZm9sbG93aW5nIG9wdGlvbnM6CiAKYSkgUHVibGlzaCBpdCBhcyBhbiBleHBl cmltZW50YWwgUkZDCiAKYikgUmVtb3ZlIGl0IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgYW5kIGFz ayBhbiBBRCB0byBzaGVwaGVyZCBpdAogCmMpIFJlbW92ZSBpdCBmcm9tIHRoZSB3b3JraW5nIGdy b3VwIGFuZCBsZXQgdGhlIGF1dGhvcnMgcHVibGlzaCBpdCB2aWEKdGhlIGluZGVwZW5kZW50IHN1 Ym1pc3Npb24gdHJhY2suCiAKSW4gYW55IGNhc2UgaXQgd291bGQgYmUgbmljZSB0byBsZXQgZm9s a3MgcGxheSBhcm91bmQgd2l0aCBpdCBhbmQgdGhlbiwKYWZ0ZXIgc29tZSB0aW1lLCBjb21lIGJh Y2sgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlcmUgaXMgZW5vdWdoIGludGVyZXN0CnRvIHByb2R1 Y2UgYSBzdGFuZGFyZC4KIApQbGVhc2UgbGV0IHVzIGtub3cgd2hhdCB5b3UgdGhpbmshCiAKQ2lh bwpIYW5uZXMgJiBEZXJlawogCiAKIAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpPQXV0aCBtYWlsaW5nIGxpc3QKT0F1dGhAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAogCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk9BdXRoIG1haWxpbmcgbGlzdApPQXV0aEBp ZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCg== ----_com.android.email_559816724808220 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+KzE8YnI+PGJyPjxkaXY+LS0tLS0t LS0gVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0IC0tLS0tLS0tPC9kaXY+PGRpdj5Wb246IEpvaG4g QnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+IDwvZGl2PjxkaXY+RGF0dW06MTEuMDkuMjAxNCAg MDI6MjIgIChHTVQrMDE6MDApIDwvZGl2PjxkaXY+QW46IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT4gPC9kaXY+PGRpdj5DYzogb2F1dGhAaWV0Zi5vcmcgPC9kaXY+PGRp dj5CZXRyZWZmOiBSZTogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gTWFu YWdlbWVudCBQcm90b2NvbDogTmV4dCBTdGVwcz8gPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4r MTxicj48YnI+U2VudCBmcm9tIG15IGlQaG9uZTwvZGl2PjxkaXY+PGJyPk9uIFNlcCAxMCwgMjAx NCwgYXQgOTowNyBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3Jv dGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PgoKPG1ldGEgaHR0 cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNj aWkiPgo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChm aWx0ZXJlZCBtZWRpdW0pIj4KPHN0eWxlPjwhLS0KLyogRm9udCBEZWZpbml0aW9ucyAqLwpAZm9u dC1mYWNlCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsKCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOwoJcGFub3Nl LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLwpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBpbjsKCW1hcmdpbi1i b3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiOwoJY29sb3I6YmxhY2s7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1ZTsKCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30KcHJlCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOwoJbWFyZ2luOjBpbjsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZv bnQtc2l6ZToxMC4wcHQ7Cglmb250LWZhbWlseToiQ291cmllciBOZXciOwoJY29sb3I6YmxhY2s7 fQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOwoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsKCWZvbnQtZmFtaWx5OkNvbnNvbGFzOwoJY29sb3I6YmxhY2s7fQpz cGFuLkVtYWlsU3R5bGUxOQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5OwoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsKCWNvbG9yOiMxRjQ5N0Q7fQouTXNvQ2hwRGVm YXVsdAoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5OwoJZm9udC1zaXplOjEwLjBwdDt9CkBw YWdlIFdvcmRTZWN0aW9uMQoJe3NpemU6OC41aW4gMTEuMGluOwoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30KZGl2LldvcmRTZWN0aW9uMQoJe3BhZ2U6V29yZFNlY3Rpb24xO30KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4KCgo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KzE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGdldHMgaXQgb2Zm IHRoZSB3b3JraW5nIGdyb3Vw4oCZcyBwbGF0ZSBhbmQgbGV0cyB1cyBnYXRoZXIgZGF0YSBhYm91 dCB3aGV0aGVyIHRoaXMgdXNlZnVsIG9yIG5vdCBhbmQgd2hldGhlciBpdOKAmXMgcmlnaHQgb3Ig d2hldGhlciBjaGFuZ2VzIGFyZSBuZWVkZWQsIGJhc2VkCiBvbiBhY3R1YWwgdXNhZ2UgZXhwZXJp ZW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+CjxkaXY+CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBP QXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnPC9hPl0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gUmljaGVy PGJyPgo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTQgNTowNSBQTTxi cj4KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRI LVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gTWFuYWdlbWVudCBQcm90b2NvbDogTmV4 dCBTdGVwcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PmEpIFB1Ymxpc2ggaXQgYXMgZXhwZXJpbWVudGFsLiBUaGVyZSB3YXMgcmVhc29uYWJsZSBzdXBw b3J0IGZvciB0aGlzIGluIGJvdGggVG9yb250byBhbmQgTG9uZG9uLjxicj4KPGJyPgombmJzcDst LSBKdXN0aW48YnI+Cjxicj4KT24gOS8xMC8yMDE0IDc6NTAgUE0sIEhhbm5lcyBUc2Nob2Zlbmln IHdyb3RlOjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+CjxwcmU+SGkgYWxsLDxvOnA+PC9vOnA+PC9w cmU+CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4KPHByZT5pbiByZXNwb25zZSB0byB0aGUg ZGlzY3Vzc2lvbnMgYXQgdGhlIGxhc3QgSUVURiBtZWV0aW5nIHRoZSBhdXRob3JzIG9mPG86cD48 L286cD48L3ByZT4KPHByZT50aGUgIkR5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBNYW5hZ2Vt ZW50IFByb3RvY29sPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC1keW4tcmVnLW1hbmFnZW1lbnQtMDVoYXZlY2hhbmdlZHRoZWRvY3VtZW50dHlwZXRv Ij4iPG86cD48L286cD48L2E+PC9wcmU+CjxwcmU+PHNwYW4gY2xhc3M9Ik1zb0h5cGVybGluayI+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1keW4t cmVnLW1hbmFnZW1lbnQtMDVoYXZlY2hhbmdlZHRoZWRvY3VtZW50dHlwZXRvIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctbWFuYWdlbWVudC0wNSBo YXZlPG86cD48L286cD48L2E+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIGNsYXNzPSJNc29IeXBl cmxpbmsiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtZHluLXJlZy1tYW5hZ2VtZW50LTA1aGF2ZWNoYW5nZWR0aGVkb2N1bWVudHR5cGV0byI+Y2hh bmdlZCB0aGUgZG9jdW1lbnQgdHlwZSB0byAiPC9hPjwvc3Bhbj5FeHBlcmltZW50YWwiLjxvOnA+ PC9vOnA+PC9wcmU+CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4KPHByZT5XZSBuZWVkIHRv IG1ha2UgYSBkZWNpc2lvbiBhYm91dCB0aGUgbmV4dCBzdGVwcyBmb3IgdGhlIGRvY3VtZW50IGFu ZCB3ZTxvOnA+PC9vOnA+PC9wcmU+CjxwcmU+c2VlIHRoZSBmb2xsb3dpbmcgb3B0aW9uczo8bzpw PjwvbzpwPjwvcHJlPgo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+CjxwcmU+YSkgUHVibGlz aCBpdCBhcyBhbiBleHBlcmltZW50YWwgUkZDPG86cD48L286cD48L3ByZT4KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPgo8cHJlPmIpIFJlbW92ZSBpdCBmcm9tIHRoZSB3b3JraW5nIGdyb3Vw IGFuZCBhc2sgYW4gQUQgdG8gc2hlcGhlcmQgaXQ8bzpwPjwvbzpwPjwvcHJlPgo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+CjxwcmU+YykgUmVtb3ZlIGl0IGZyb20gdGhlIHdvcmtpbmcgZ3Jv dXAgYW5kIGxldCB0aGUgYXV0aG9ycyBwdWJsaXNoIGl0IHZpYTxvOnA+PC9vOnA+PC9wcmU+Cjxw cmU+dGhlIGluZGVwZW5kZW50IHN1Ym1pc3Npb24gdHJhY2suPG86cD48L286cD48L3ByZT4KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPgo8cHJlPkluIGFueSBjYXNlIGl0IHdvdWxkIGJlIG5p Y2UgdG8gbGV0IGZvbGtzIHBsYXkgYXJvdW5kIHdpdGggaXQgYW5kIHRoZW4sPG86cD48L286cD48 L3ByZT4KPHByZT5hZnRlciBzb21lIHRpbWUsIGNvbWUgYmFjayB0byBkZXRlcm1pbmUgd2hldGhl ciB0aGVyZSBpcyBlbm91Z2ggaW50ZXJlc3Q8bzpwPjwvbzpwPjwvcHJlPgo8cHJlPnRvIHByb2R1 Y2UgYSBzdGFuZGFyZC48bzpwPjwvbzpwPjwvcHJlPgo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+CjxwcmU+UGxlYXNlIGxldCB1cyBrbm93IHdoYXQgeW91IHRoaW5rITxvOnA+PC9vOnA+PC9w cmU+CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4KPHByZT5DaWFvPG86cD48L286cD48L3By ZT4KPHByZT5IYW5uZXMgJmFtcDsgRGVyZWs8bzpwPjwvbzpwPjwvcHJlPgo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+Cjxicj4KPGJyPgo8bzpw PjwvbzpwPjwvcD4KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxvOnA+PC9vOnA+PC9wcmU+CjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286 cD48L3ByZT4KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+CjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4KCgo8L2Rpdj48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+T0F1dGggbWFp bGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci Pk9BdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Jv ZHk+ ----_com.android.email_559816724808220-- From nobody Thu Sep 11 01:16:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D701A065F for ; Thu, 11 Sep 2014 01:16:02 -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, SPF_PASS=-0.001] autolearn=ham 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 kUYsveDaSP0a for ; Thu, 11 Sep 2014 01:15:59 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342681A0656 for ; Thu, 11 Sep 2014 01:15:59 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ge10so1850100lab.13 for ; Thu, 11 Sep 2014 01:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=i7ak4pJBfzZruTE8O8/IkeT4xmajyPvhc3jft1KTaNA=; b=geHpBkEzgRSMX7Pdx3enr1Ciu1HPrdeSU11GJF+3rfmzRB6DxqyV0o2rMZPACmfINX WQOhCHSjEF/gzhRyunTNRw8tk9Xf1HL5KIsvhZYm0NDIFmv0sBUnAXl7qZLWhzFj4hae Tw5zbyd5XtDLU97fd58CE2gY5KU7wDpMxlFRSqu65T7YL7nls70Hzvdl4Jgs9+oYmfWR bRf/WG3XJikVzwzqUOd089oGiR/7NdyeWqMxgp0yWZPx00zjeUspG+5YbG5x1/B2a6/v jPZolc3GChioy8JPw7c3v2RitDMIUhgsNiWoHHCZTnWpydgdm2RzZI5arPZBDWqo4OuF axxQ== MIME-Version: 1.0 X-Received: by 10.152.87.170 with SMTP id az10mr23797117lab.20.1410423357561; Thu, 11 Sep 2014 01:15:57 -0700 (PDT) Received: by 10.112.134.105 with HTTP; Thu, 11 Sep 2014 01:15:57 -0700 (PDT) In-Reply-To: <541074C3.3030400@gmx.net> References: <54101EB7.1000502@gmail.com> <541074C3.3030400@gmx.net> Date: Thu, 11 Sep 2014 13:45:57 +0530 Message-ID: From: Rex Albert To: Hannes Tschofenig , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11c223b635deb70502c5c7ca Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/i1H3gPd5scc-eSJ3q3BVgAHGTJk Subject: Re: [OAUTH-WG] Fwd: Is OAUTHV2-HTTP_MAC dead? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 08:16:02 -0000 --001a11c223b635deb70502c5c7ca Content-Type: text/plain; charset=UTF-8 Hi Hannes, thank you very much for the response and it is very useful to have such detailed information. thank you again for that. I am now reading about PoP and it is very interesting and also seeing HTTP signature as well. Our requirement in short - to achieve seamless authentication and authorization among HTTP - REST based web services within a protected network with a secure channel for communication, without human intervention and without compromise on the time taken to process each request. Kindly let me know if you need further details . thanks again -rex On Wed, Sep 10, 2014 at 9:26 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Rex, > > the document has been superseded by > the PoP work (which was subsequently split into various other documents). > > That, however, does not mean that the content is dead. The mechanism for > the authorization server to convey the symmetric key to the client is > now documented in . The high > level description / overview is now documented in > . The actual mechanism for the client > to apply the key to the request to the resource server is now documented > in . > > While < draft-ietf-oauth-signed-http-request> today is different to the > mechanism described in it also has to > be said that it is the weakest document in the entire document set at > the moment. > > So, there is still a chance to incorporate your design requirements into > the appropriate parts of the work since the work is still in progress. > > It would be good to know what your requirements/interests are. > > Ciao > Hannes > > > On 09/10/2014 11:49 AM, Sergey Beryozkin wrote: > > Hi > > On 10/09/14 09:57, Rex Albert wrote: > >> > >> > >> Hi, > >> We are looking at implementing OAUTHV2-HTTP-MAC whose draft is in an > >> expired > >> state.(http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05) Is > >> it dead or is it going to be a standard anytime? or are we going to > >> implement at our own risk? or is there a better standard/draft ( alive ) > >> which might supersede this draft ? > > > > It's not going to be revived. Does not mean though one can not use the > > idea for implementing custom OAuth2 token schemes, IMHO it was a very > > simple and effective 'PoP' approach, and it is easy to document and > > support. FYI, we support a Hawk scheme (not part of OAuth2 work at all, > > kind of 'draft-ietf-oauth-v2-http-mac-06') as an access token scheme in > > our project. > > > > As far as I understand new proof-of-possession documents the group is > > working upon will offer the alternative standard solutions. > > > > Cheers, Sergey > > > >> > >> thank you for your time. > >> I am a newbie to the IETF draft process and kindly excuse my naivety. > >> -rex > >> > >> > >> > >> _______________________________________________ > >> 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 > > --001a11c223b635deb70502c5c7ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hannes,
thank you very much for the response and it= is very useful to have such detailed information. thank you again for that= .=C2=A0
I am now reading about PoP and it is very interesting and= also seeing HTTP signature as well.=C2=A0
Our requirement in sho= rt - to achieve seamless authentication and authorization among HTTP - REST= based web services within a protected network with a secure channel for co= mmunication, without human intervention and without compromise on the time = taken to process each request.=C2=A0
Kindly let me know if you ne= ed further details .=C2=A0
thanks again
-rex

On Wed, Sep 10, = 2014 at 9:26 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net&= gt; wrote:
Hi Rex,

the document <draft-ietf-oauth-v2-http-mac-05> has been superseded by=
the PoP work (which was subsequently split into various other documents).
That, however, does not mean that the content is dead. The mechanism for the authorization server to convey the symmetric key to the client is
now documented in <draft-ietf-oauth-pop-key-distribution>. The high level description / overview is now documented in
<draft-ietf-oauth-pop-architecture>. The actual mechanism for the cli= ent
to apply the key to the request to the resource server is now documented in <draft-ietf-oauth-signed-http-request>.

While < draft-ietf-oauth-signed-http-request> today is different to t= he
mechanism described in <draft-ietf-oauth-v2-http-mac-05> it also has = to
be said that it is the weakest document in the entire document set at
the moment.

So, there is still a chance to incorporate your design requirements into the appropriate parts of the work since the work is still in progress.

It would be good to know what your requirements/interests are.

Ciao
Hannes


On 09/10/2014 11:49 AM, Sergey Beryozkin wrote:
> Hi
> On 10/09/14 09:57, Rex Albert wrote:
>>
>>
>> Hi,
>> We are looking at implementing OAUTHV2-HTTP-MAC whose draft is in = an
>> expired
>> state.(http://tools.ietf.org/html/draft-ietf-oauth-v= 2-http-mac-05)=C2=A0 Is
>> it dead or is it going to be a standard anytime? or are we going t= o
>> implement at our own risk? or is there a better standard/draft ( a= live )
>> which might supersede this draft ?
>
> It's not going to be revived. Does not mean though one can not use= the
> idea for implementing custom OAuth2 token schemes, IMHO it was a very<= br> > simple and effective 'PoP' approach, and it is easy to documen= t and
> support. FYI, we support a Hawk scheme (not part of OAuth2 work at all= ,
> kind of 'draft-ietf-oauth-v2-http-mac-06') as an access token = scheme in
> our project.
>
> As far as I understand new proof-of-possession documents the group is<= br> > working upon will offer the alternative standard solutions.
>
> Cheers, Sergey
>
>>
>> thank you for your time.
>> I am a newbie to the IETF draft process and kindly excuse my naive= ty.
>> -rex
>>
>>
>>
>> _______________________________________________
>> 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


--001a11c223b635deb70502c5c7ca-- From nobody Thu Sep 11 03:44:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F56B1A8924 for ; Thu, 11 Sep 2014 03:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 luXIK4fqWj0D for ; Thu, 11 Sep 2014 03:44:26 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E6C1A06D3 for ; Thu, 11 Sep 2014 03:44:25 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-36-54117d0806b4 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 30.B3.18723.80D71145; Thu, 11 Sep 2014 06:44:24 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s8BAiNn4025855; Thu, 11 Sep 2014 06:44:24 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (oc11exedge4.exchange.mit.edu [18.9.3.27]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id s8BAiMnh010863; Thu, 11 Sep 2014 06:44:22 -0400 Received: from OC11EXHUB8.exchange.mit.edu (18.9.3.20) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Sep 2014 06:43:34 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.70]) by OC11EXHUB8.exchange.mit.edu ([18.9.3.20]) with mapi id 14.03.0158.001; Thu, 11 Sep 2014 06:44:22 -0400 From: Thomas Hardjono To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? Thread-Index: AQHPzX6lBDerJUtOUkCRxbL0Pfhs+pv7v7O0 Date: Thu, 11 Sep 2014 10:44:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B4E250844403472EA8C12C92999A38EBmitedu_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIJsWRmVeSWpSXmKPExsUixCmqrctRKxhiMLlJ1WLvtE8sFiffvmKz eHXsKYvF6rt/2RxYPJYs+cnkcaynn9Wjdcdfdo/btzeyBLBEcdmkpOZklqUW6dslcGVsnTyF taA3vOLOxafMDYznfLoYOTkkBEwkph1exAZhi0lcuLceyObiEBKYzSRxeNU/JgjnAKPE5y1T mCGc44wSZ85dZwZpERLYxiixr4MVwl7JKLG3RRvEZhPQkGj70csOYosIGEq0T1wI1sws0Moo 8WVPFxNIQlggTKLl0yEmiKJwiYXvnrJC2EYSk/ccBWrg4GARUJVoW20AEuYVsJI4OvkZI8Qu N4m3jRvBzuYUcJeYvq8T7B5GoBe+n1oDNpJZQFzi1pP5TBCvCUosmr2HGebNf7seskHUxEl0 LLjJAjFfUOLkzCcsExjFZyFpn4WkbBaSMoi4gcT7c/OZIWxtiWULX0PZ+hIbv5xlRBZfwMi+ ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdcLzezRC81pXQTIyi22V1UdjA2H1I6xCjAwajEw1vB IhgixJpYVlyZe4hRkoNJSZRXogooxJeUn1KZkVicEV9UmpNafIhRgoNZSYS3tBAox5uSWFmV WpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwetSA9QoWJSanlqRlplTgpBm4uAE Gc4DNJwTpIa3uCAxtzgzHSJ/ilGXY13nt34mIZa8/LxUKXHeE9VARQIgRRmleXBzYCn5FaM4 0FvCvH4go3iA6Rxu0iugJUxASw4a84MsKUlESEk1MCrvjxIuWv62SlRbxl7T+i43m+jTdn/5 z3o32We5aG7QTvRVXOLqN9PwXvmx9YnH+SYbpTzV2zj7v5jt63SWCy+ndKTzX3t0ehWD/dKb 337v15WTeGtcUjqfp2pGxcXrbU5aLTbqrBYubMr5D2z/czkH7Qwqz4wWqgqYMWXeJgmbL2mm ovkflFiKMxINtZiLihMBZQ2rvqQDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/v0wI2mobD6KjA9R5j5nY-zD4akw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 10:44:28 -0000 --_000_B4E250844403472EA8C12C92999A38EBmitedu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 /thomas/ _______________________________________ On Sep 11, 2014, at 1:10, "Torsten Lodderstedt" > wrote: +1 -------- Urspr=FCngliche Nachricht -------- Von: John Bradley Datum:11.09.2014 02:22 (GMT+01:00) An: Mike Jones Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Ne= xt Steps? +1 Sent from my iPhone On Sep 10, 2014, at 9:07 PM, Mike Jones > wrote: +1 This gets it off the working group=92s plate and lets us gather data about = whether this useful or not and whether it=92s right or whether changes are = needed, based on actual usage experience. From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, September 10, 2014 5:05 PM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Ne= xt Steps? a) Publish it as experimental. There was reasonable support for this in bot= h Toronto and London. -- Justin On 9/10/2014 7:50 PM, Hannes Tschofenig wrote: Hi all, in response to the discussions at the last IETF meeting the authors of the "Dynamic Client Registration Management Protocol" http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have changed the document type to "Experimental". We need to make a decision about the next steps for the document and we see the following options: a) Publish it as an experimental RFC b) Remove it from the working group and ask an AD to shepherd it c) Remove it from the working group and let the authors publish it via the independent submission track. In any case it would be nice to let folks play around with it and then, after some time, come back to determine whether there is enough interest to produce a standard. Please let us know what you think! Ciao Hannes & Derek _______________________________________________ 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B4E250844403472EA8C12C92999A38EBmitedu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1


/thomas/
_______________________________________

On Sep 11, 2014, at 1:10, "Torsten Lodderstedt" <torsten@lodderstedt.net> wrote:

+1

-------- Urspr=FCngliche Nachricht --------
Von: John Bradley
Datum:11.09.2014 02:22 (GMT+01:00)
An: Mike Jones
Betreff: Re: [OAUTH-WG] Dynamic Client Registration Management Protoco= l: Next Steps?

+1

Sent from my iPhone

On Sep 10, 2014, at 9:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

+1<= /p>

 <= /p>

This gets it off the work= ing group=92s plate and lets us gather data about whether this useful or no= t and whether it=92s right or whether changes are needed, based on actual usage experience.

 <= /p>

From: OAuth [= mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, September 10, 2014 5:05 PM
To: Hannes Tschofenig; oauth@ietf.= org
Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Proto= col: Next Steps?

 

a) Publish it as experimental. There was reasonable = support for this in both Toronto and London.

 -- Justin

On 9/10/2014 7:50 PM, Hannes Tschofenig wrote:

Hi all,
 
in response to the discussions at the last IETF meeting the authors of=

the "Dynamic Client Registration Management Protocol"
http://too=
ls.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have=

changed th=
e document type to "Experimental".
 
We need to make a decision about the next steps for the document and w=
e
see the following options:
 
a) Publish it as an experimental RFC
 
b) Remove it from the working group and ask an AD to shepherd it<=
/o:p>
 
c) Remove it from the working group and let the authors publish it via=

the independent submission track.
 
In any case it would be nice to let folks play around with it and then=
,
after some time, come back to determine whether there is enough intere=
st
to produce a standard.
 
Please let us know what you think!
 
Ciao
Hannes & Derek
 
 
 




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

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
--_000_B4E250844403472EA8C12C92999A38EBmitedu_-- From nobody Thu Sep 11 07:36:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EBC1A6F2D for ; Thu, 11 Sep 2014 07:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zVyoElOU9GQy for ; Thu, 11 Sep 2014 07:36:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0567F1A00C3 for ; Thu, 11 Sep 2014 07:36:09 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB311.namprd03.prod.outlook.com (10.141.48.26) with Microsoft SMTP Server (TLS) id 15.0.1029.10; Thu, 11 Sep 2014 14:36:08 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.1029.000; Thu, 11 Sep 2014 14:36:08 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? Thread-Index: AQHPzVH8gvp2WWtHD0WKO/N3OpU515v8AGmQ Date: Thu, 11 Sep 2014 14:36:07 +0000 Message-ID: References: <5410E3AF.3030806@gmx.net> In-Reply-To: <5410E3AF.3030806@gmx.net> 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: [2001:4898:e008:1::5ed] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03319F6FEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(60444003)(76104003)(377454003)(13464003)(199003)(53754006)(189002)(64706001)(80022001)(15202345003)(46102001)(85306004)(74502001)(21056001)(20776003)(2656002)(15975445006)(2501002)(108616004)(107046002)(107886001)(81542001)(95666004)(74316001)(74662001)(101416001)(99286002)(31966008)(85852003)(76576001)(83072002)(99396002)(106116001)(19580395003)(33646002)(86612001)(92566001)(50986999)(76176999)(54356999)(86362001)(4396001)(19580405001)(79102001)(97736003)(83322001)(106356001)(76482001)(87936001)(90102001)(105586002)(77982001)(24736002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB311; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/u31fRfL9IlY4zDcgDsH3kUdK76Q Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 14:36:12 -0000 SXMgImV4cGVyaW1lbnRhbCIgdGhlIGNvcnJlY3QgY2xhc3NpZmljYXRpb24/IE1heWJlICJpbmZv cm1hdGlvbmFsIiBpcyBtb3JlIGFwcHJvcHJpYXRlIGFzIGJvdGggb2YgdGhlc2Ugd2VyZSBkaXNj dXNzZWQuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT0F1dGggW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcN ClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE0IDQ6NTAgUE0NClRvOiBvYXV0aEBp ZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdHXSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24g TWFuYWdlbWVudCBQcm90b2NvbDogTmV4dCBTdGVwcz8NCg0KSGkgYWxsLA0KDQppbiByZXNwb25z ZSB0byB0aGUgZGlzY3Vzc2lvbnMgYXQgdGhlIGxhc3QgSUVURiBtZWV0aW5nIHRoZSBhdXRob3Jz IG9mIHRoZSAiRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIE1hbmFnZW1lbnQgUHJvdG9jb2wi DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctbWFu YWdlbWVudC0wNSBoYXZlIGNoYW5nZWQgdGhlIGRvY3VtZW50IHR5cGUgdG8gIkV4cGVyaW1lbnRh bCIuDQoNCldlIG5lZWQgdG8gbWFrZSBhIGRlY2lzaW9uIGFib3V0IHRoZSBuZXh0IHN0ZXBzIGZv ciB0aGUgZG9jdW1lbnQgYW5kIHdlIHNlZSB0aGUgZm9sbG93aW5nIG9wdGlvbnM6DQoNCmEpIFB1 Ymxpc2ggaXQgYXMgYW4gZXhwZXJpbWVudGFsIFJGQw0KDQpiKSBSZW1vdmUgaXQgZnJvbSB0aGUg d29ya2luZyBncm91cCBhbmQgYXNrIGFuIEFEIHRvIHNoZXBoZXJkIGl0DQoNCmMpIFJlbW92ZSBp dCBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIGFuZCBsZXQgdGhlIGF1dGhvcnMgcHVibGlzaCBpdCB2 aWEgdGhlIGluZGVwZW5kZW50IHN1Ym1pc3Npb24gdHJhY2suDQoNCkluIGFueSBjYXNlIGl0IHdv dWxkIGJlIG5pY2UgdG8gbGV0IGZvbGtzIHBsYXkgYXJvdW5kIHdpdGggaXQgYW5kIHRoZW4sIGFm dGVyIHNvbWUgdGltZSwgY29tZSBiYWNrIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZXJlIGlzIGVu b3VnaCBpbnRlcmVzdCB0byBwcm9kdWNlIGEgc3RhbmRhcmQuDQoNClBsZWFzZSBsZXQgdXMga25v dyB3aGF0IHlvdSB0aGluayENCg0KQ2lhbw0KSGFubmVzICYgRGVyZWsNCg0KDQoNCg== From nobody Thu Sep 11 08:01:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830A31A6F7E for ; Thu, 11 Sep 2014 08:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham 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 SDeU1CH6bcI8 for ; Thu, 11 Sep 2014 08:01:11 -0700 (PDT) Received: from smtptsrv1.mitre.org (smtptsrv1.mitre.org [192.52.194.77]) by ietfa.amsl.com (Postfix) with ESMTP id 02B781A00BB for ; Thu, 11 Sep 2014 08:01:11 -0700 (PDT) Received: from smtptsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 913B1C50A75; Thu, 11 Sep 2014 11:01:10 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtptsrv1.mitre.org (Postfix) with ESMTP id 749B4C50930; Thu, 11 Sep 2014 11:01:10 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.225]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 11:01:10 -0400 From: "Richer, Justin P." To: Anthony Nadalin Thread-Topic: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? Thread-Index: AQHPzc2/q7TBpPSJVUaj/5AAy9WFo5v8SeEA Date: Thu, 11 Sep 2014 15:01:08 +0000 Message-ID: <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> References: <5410E3AF.3030806@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.23] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8eSB0D95kr3pdbP105ci2k-kWGY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 15:01:15 -0000 According to the guidelines here: https://www.ietf.org/iesg/informational-vs-experimental.html And the discussion in Toronto, it's clearly experimental. -- Justin On Sep 11, 2014, at 10:36 AM, Anthony Nadalin wrote= : > Is "experimental" the correct classification? Maybe "informational" is mo= re appropriate as both of these were discussed.=20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Wednesday, September 10, 2014 4:50 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next= Steps? >=20 > Hi all, >=20 > in response to the discussions at the last IETF meeting the authors of th= e "Dynamic Client Registration Management Protocol" > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have ch= anged the document type to "Experimental". >=20 > We need to make a decision about the next steps for the document and we s= ee the following options: >=20 > a) Publish it as an experimental RFC >=20 > b) Remove it from the working group and ask an AD to shepherd it >=20 > c) Remove it from the working group and let the authors publish it via th= e independent submission track. >=20 > In any case it would be nice to let folks play around with it and then, a= fter some time, come back to determine whether there is enough interest to = produce a standard. >=20 > Please let us know what you think! >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Sep 11 08:47:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3E11A8940 for ; Thu, 11 Sep 2014 08:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 plX2MO1k6DsZ for ; Thu, 11 Sep 2014 08:46:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2701A0410 for ; Thu, 11 Sep 2014 08:46:56 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB310.namprd03.prod.outlook.com (10.141.48.25) with Microsoft SMTP Server (TLS) id 15.0.1029.10; Thu, 11 Sep 2014 15:46:54 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.1029.000; Thu, 11 Sep 2014 15:46:54 +0000 From: Anthony Nadalin To: "Richer, Justin P." Thread-Topic: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? Thread-Index: AQHPzdE7aUCBC9qBx0SVb2+u2Fyahpv8Eyfg Date: Thu, 11 Sep 2014 15:46:54 +0000 Message-ID: <65e89d62893d4a669784da7688efde60@BLUPR03MB309.namprd03.prod.outlook.com> References: <5410E3AF.3030806@gmx.net> <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> In-Reply-To: <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> 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: [2001:4898:e008:1::5ed] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03319F6FEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(24454002)(51704005)(60444003)(189002)(13464003)(53754006)(199003)(377454003)(74316001)(90102001)(105586002)(80022001)(20776003)(85306004)(50986999)(76176999)(54356999)(76576001)(46102001)(21056001)(15202345003)(15975445006)(85852003)(83072002)(76482001)(87936001)(101416001)(81542001)(86612001)(86362001)(64706001)(2656002)(97736003)(92566001)(110136001)(107046002)(83322001)(106116001)(19580405001)(19580395003)(81342001)(106356001)(99396002)(74502001)(74662001)(95666004)(108616004)(4396001)(99286002)(33646002)(79102001)(77982001)(31966008)(24736002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB310; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AqAAea_z6MLh7zhDRVOiXPVDEO4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 15:46:59 -0000 I don't see it that way as the guidelines not clear and we should revisit t= his since there was no conclusion in Toronto.=20 -----Original Message----- From: Richer, Justin P. [mailto:jricher@mitre.org]=20 Sent: Thursday, September 11, 2014 8:01 AM To: Anthony Nadalin Cc: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Ne= xt Steps? According to the guidelines here: https://www.ietf.org/iesg/informational-vs-experimental.html And the discussion in Toronto, it's clearly experimental. -- Justin On Sep 11, 2014, at 10:36 AM, Anthony Nadalin wrote= : > Is "experimental" the correct classification? Maybe "informational" is mo= re appropriate as both of these were discussed.=20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Wednesday, September 10, 2014 4:50 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next= Steps? >=20 > Hi all, >=20 > in response to the discussions at the last IETF meeting the authors of th= e "Dynamic Client Registration Management Protocol" > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have ch= anged the document type to "Experimental". >=20 > We need to make a decision about the next steps for the document and we s= ee the following options: >=20 > a) Publish it as an experimental RFC >=20 > b) Remove it from the working group and ask an AD to shepherd it >=20 > c) Remove it from the working group and let the authors publish it via th= e independent submission track. >=20 > In any case it would be nice to let folks play around with it and then, a= fter some time, come back to determine whether there is enough interest to = produce a standard. >=20 > Please let us know what you think! >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Sep 11 08:55:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326381A895F for ; Thu, 11 Sep 2014 08:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 cjH7zDLTmdSd for ; Thu, 11 Sep 2014 08:55:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282F11A6FDB for ; Thu, 11 Sep 2014 08:55:33 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8BFtV6R000548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Sep 2014 15:55:32 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8BFtUB9009994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2014 15:55:31 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8BFtUsU017897; Thu, 11 Sep 2014 15:55:30 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Sep 2014 08:55:29 -0700 References: <5410E3AF.3030806@gmx.net> <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Thu, 11 Sep 2014 08:55:25 -0700 To: "Richer, Justin P." X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fvldGZRL1ANyXbTlD6_GsWVevvE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 15:55:35 -0000 Interesting. The definitions in that don't correspond with what ADs and othe= r groups are doing.=20 I heard httpbis using experimental as a placeholder for a draft that didn't h= ave full consensus to bring back later.=20 That was the feel I had in Toronto-that we weren't done but it was time to p= ublish something.=20 Reading the actual definition i would say neither fits. Ugh.=20 Phil > On Sep 11, 2014, at 8:01, "Richer, Justin P." wrote: >=20 > According to the guidelines here: >=20 > https://www.ietf.org/iesg/informational-vs-experimental.html >=20 > And the discussion in Toronto, it's clearly experimental. >=20 > -- Justin >=20 >> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin wro= te: >>=20 >> Is "experimental" the correct classification? Maybe "informational" is mo= re appropriate as both of these were discussed.=20 >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g >> Sent: Wednesday, September 10, 2014 4:50 PM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next= Steps? >>=20 >> Hi all, >>=20 >> in response to the discussions at the last IETF meeting the authors of th= e "Dynamic Client Registration Management Protocol" >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have ch= anged the document type to "Experimental". >>=20 >> We need to make a decision about the next steps for the document and we s= ee the following options: >>=20 >> a) Publish it as an experimental RFC >>=20 >> b) Remove it from the working group and ask an AD to shepherd it >>=20 >> c) Remove it from the working group and let the authors publish it via th= e independent submission track. >>=20 >> In any case it would be nice to let folks play around with it and then, a= fter some time, come back to determine whether there is enough interest to p= roduce a standard. >>=20 >> Please let us know what you think! >>=20 >> Ciao >> Hannes & Derek >>=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 From nobody Thu Sep 11 09:02:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6831A898F for ; Thu, 11 Sep 2014 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 olYJE6Tze7ye for ; Thu, 11 Sep 2014 09:02:18 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C322C1A895F for ; Thu, 11 Sep 2014 09:02:17 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id j107so7794665qga.32 for ; Thu, 11 Sep 2014 09:02:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=V+0B6zNKY0etms/qdIIZew53vdEvr8uYeilwsyh7XII=; b=lMRzr+nqlPnUEnkgk6xu5DlwV1PgSxQEmSf/fM/x1oo2Zhq+LNYznN6ce50Owu9m/E KDGOH+gz4lZ/ybrbMX9ikKk+FEyT5GwkKp4Nt8hzddxEJYnUv6IaX7ioQns55MgfqlEt EikUQrLpq4YjhzYxIP5NRbMU3X7vklF/kTDZfC6UIDlMWzuB+izkFCO8IpJpvEpchB05 t8HY+foANW1n1UGiNNBCp+klIrGuZ9F1rJ395J+OAfaypPKPZP9F9Ef19B4IXTK1hTnk 1Ug0kw4gbw4jZknZIrfyCZfaqSvwn4TvBIquTIXtEt7xtqj7nqm+NzKlTaqmaw2mU7hz 11dw== X-Gm-Message-State: ALoCoQlDWS6zN8OldpT6JCSMk9j0c5WrVuBgSUulUhX7/DA9gHFakuEBfX8g1bBCY8ju3GX1KJVN X-Received: by 10.229.65.135 with SMTP id j7mr2940497qci.22.1410451336389; Thu, 11 Sep 2014 09:02:16 -0700 (PDT) Received: from [192.168.1.37] (186-106-172-214.baf.movistar.cl. [186.106.172.214]) by mx.google.com with ESMTPSA id h2sm899354qah.35.2014.09.11.09.02.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 09:02:15 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5D2C334C-B0CB-4D95-B011-12B53C31F1C5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Thu, 11 Sep 2014 13:02:08 -0300 Message-Id: <3AD141D9-5673-4945-9DC9-E95D7D35EF33@ve7jtb.com> References: <5410E3AF.3030806@gmx.net> <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> To: Phil Hunt X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SgalUgfthFWZEI1iJ1ZeOr-S3uI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:02:20 -0000 --Apple-Mail=_5D2C334C-B0CB-4D95-B011-12B53C31F1C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think this fits. =95 If the IETF may publish something based on this on the = standards track once we know how well this one works, it's Experimental. = This is the typical case of not being able to decide which protocol is = "better" before we have experience of dealing with them from a stable = specification. Case in point: "PGM Reliable Transport Protocol = Specification" (RFC 3208) If we publish something it may or may not look like the current spec but = getting some experience with the current spec will inform that decision.=20= John B. On Sep 11, 2014, at 12:55 PM, Phil Hunt wrote: > Interesting. The definitions in that don't correspond with what ADs = and other groups are doing.=20 >=20 > I heard httpbis using experimental as a placeholder for a draft that = didn't have full consensus to bring back later.=20 >=20 > That was the feel I had in Toronto-that we weren't done but it was = time to publish something.=20 >=20 > Reading the actual definition i would say neither fits. Ugh.=20 >=20 > Phil >=20 >> On Sep 11, 2014, at 8:01, "Richer, Justin P." = wrote: >>=20 >> According to the guidelines here: >>=20 >> https://www.ietf.org/iesg/informational-vs-experimental.html >>=20 >> And the discussion in Toronto, it's clearly experimental. >>=20 >> -- Justin >>=20 >>> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin = wrote: >>>=20 >>> Is "experimental" the correct classification? Maybe "informational" = is more appropriate as both of these were discussed.=20 >>>=20 >>> -----Original Message----- >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig >>> Sent: Wednesday, September 10, 2014 4:50 PM >>> To: oauth@ietf.org >>> Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: = Next Steps? >>>=20 >>> Hi all, >>>=20 >>> in response to the discussions at the last IETF meeting the authors = of the "Dynamic Client Registration Management Protocol" >>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 = have changed the document type to "Experimental". >>>=20 >>> We need to make a decision about the next steps for the document and = we see the following options: >>>=20 >>> a) Publish it as an experimental RFC >>>=20 >>> b) Remove it from the working group and ask an AD to shepherd it >>>=20 >>> c) Remove it from the working group and let the authors publish it = via the independent submission track. >>>=20 >>> In any case it would be nice to let folks play around with it and = then, after some time, come back to determine whether there is enough = interest to produce a standard. >>>=20 >>> Please let us know what you think! >>>=20 >>> Ciao >>> Hannes & Derek >>>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5D2C334C-B0CB-4D95-B011-12B53C31F1C5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MTExNjAyMDhaMCMGCSqGSIb3DQEJBDEWBBRiWvXUsLEXh2BWQhDlfj3D 9uDQcjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQABTf+EFm5eu9DQCaHHqnd21YwGqadTzeguI3jB/FGmhtBJmQtKrKDF tJCxhiyJIswOWDblS/PRrCus1hxq/GRGM1vVhvb9O1n62DwygTDx3ZHj7fKGnSs9qLJsffNUe8cA 7BQATqTyZCH4wAlyQOHA/20UNSkGhssILm+A8XWBF+zOumJiyvtpW+SGfZPJC9M7meckFepZ1cg8 yvE7k1Ku7cTo7vxuyxK1JT5yUegpFlU+qylqKwOhUtGlmJZkvvcD8Nn7ylaVfZ3xckUhTT02UTtA QsZ34bK0iv5WxltJdWkMAoFwpKQFpkSpyN/iVz/i/E9xZ37FGILHodRTzeMmAAAAAAAA --Apple-Mail=_5D2C334C-B0CB-4D95-B011-12B53C31F1C5-- From nobody Thu Sep 11 09:03:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BF51A6FDD for ; Thu, 11 Sep 2014 09:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham 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 HhRUoMD864om for ; Thu, 11 Sep 2014 09:03:37 -0700 (PDT) Received: from smtptsrv1.mitre.org (smtptsrv1.mitre.org [192.52.194.77]) by ietfa.amsl.com (Postfix) with ESMTP id F0F9C1A0410 for ; Thu, 11 Sep 2014 09:03:36 -0700 (PDT) Received: from smtptsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 816DCC506BC; Thu, 11 Sep 2014 12:03:36 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtptsrv1.mitre.org (Postfix) with ESMTP id 5FB55C50923; Thu, 11 Sep 2014 12:03:36 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.225]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 12:03:36 -0400 From: "Richer, Justin P." To: John Bradley Thread-Topic: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? Thread-Index: AQHPzc2/q7TBpPSJVUaj/5AAy9WFo5v8SeEAgAAPK4CAAAHgAIAAAGcA Date: Thu, 11 Sep 2014 16:03:35 +0000 Message-ID: References: <5410E3AF.3030806@gmx.net> <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> <3AD141D9-5673-4945-9DC9-E95D7D35EF33@ve7jtb.com> In-Reply-To: <3AD141D9-5673-4945-9DC9-E95D7D35EF33@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.23] Content-Type: text/plain; charset="Windows-1252" Content-ID: <09E8F1923C8587489D8C33B1AC01ADC8@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/UJcG0yqfzI1zA2U_wlxAQHlEntk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:03:39 -0000 +1=20 That was the key line that I took from the guidelines as well and this was = my understanding of the discussion in Toronto. -- Justin On Sep 11, 2014, at 12:02 PM, John Bradley wrote: > I think this fits. >=20 > =95 If the IETF may publish something based on this on the standards tra= ck once we know how well this one works, it's Experimental. This is the typ= ical case of not being able to decide which protocol is "better" before we = have experience of dealing with them from a stable specification. Case in p= oint: "PGM Reliable Transport Protocol Specification" (RFC 3208) >=20 > If we publish something it may or may not look like the current spec but = getting some experience with the current spec will inform that decision.=20 >=20 > John B. > On Sep 11, 2014, at 12:55 PM, Phil Hunt wrote: >=20 >> Interesting. The definitions in that don't correspond with what ADs and = other groups are doing.=20 >>=20 >> I heard httpbis using experimental as a placeholder for a draft that did= n't have full consensus to bring back later.=20 >>=20 >> That was the feel I had in Toronto-that we weren't done but it was time = to publish something.=20 >>=20 >> Reading the actual definition i would say neither fits. Ugh.=20 >>=20 >> Phil >>=20 >>> On Sep 11, 2014, at 8:01, "Richer, Justin P." wrote= : >>>=20 >>> According to the guidelines here: >>>=20 >>> https://www.ietf.org/iesg/informational-vs-experimental.html >>>=20 >>> And the discussion in Toronto, it's clearly experimental. >>>=20 >>> -- Justin >>>=20 >>>> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin = wrote: >>>>=20 >>>> Is "experimental" the correct classification? Maybe "informational" is= more appropriate as both of these were discussed.=20 >>>>=20 >>>> -----Original Message----- >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschof= enig >>>> Sent: Wednesday, September 10, 2014 4:50 PM >>>> To: oauth@ietf.org >>>> Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: N= ext Steps? >>>>=20 >>>> Hi all, >>>>=20 >>>> in response to the discussions at the last IETF meeting the authors of= the "Dynamic Client Registration Management Protocol" >>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have= changed the document type to "Experimental". >>>>=20 >>>> We need to make a decision about the next steps for the document and w= e see the following options: >>>>=20 >>>> a) Publish it as an experimental RFC >>>>=20 >>>> b) Remove it from the working group and ask an AD to shepherd it >>>>=20 >>>> c) Remove it from the working group and let the authors publish it via= the independent submission track. >>>>=20 >>>> In any case it would be nice to let folks play around with it and then= , after some time, come back to determine whether there is enough interest = to produce a standard. >>>>=20 >>>> Please let us know what you think! >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Thu Sep 11 09:07:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988391A0410 for ; Thu, 11 Sep 2014 09:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 ZlUwRlS_vbGD for ; Thu, 11 Sep 2014 09:07:40 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7531A89AE for ; Thu, 11 Sep 2014 09:07:27 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8BG7QVX019345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Sep 2014 16:07:27 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8BG7OIW017092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2014 16:07:25 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8BG7OYe022151; Thu, 11 Sep 2014 16:07:24 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Sep 2014 09:07:24 -0700 References: <5410E3AF.3030806@gmx.net> <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> <3AD141D9-5673-4945-9DC9-E95D7D35EF33@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <597105CD-0F67-437B-89E7-EE9BC3DDB910@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Thu, 11 Sep 2014 09:07:22 -0700 To: "Richer, Justin P." X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/aUQTgSesjI2Y-ZiGLHeWQgcFhK0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:07:45 -0000 +1. Experimental seems best here.=20 Phil > On Sep 11, 2014, at 9:03, "Richer, Justin P." wrote: >=20 > +1=20 >=20 > That was the key line that I took from the guidelines as well and this was= my understanding of the discussion in Toronto. >=20 > -- Justin >=20 >> On Sep 11, 2014, at 12:02 PM, John Bradley wrote: >>=20 >> I think this fits. >>=20 >> =E2=80=A2 If the IETF may publish something based on this on the stand= ards track once we know how well this one works, it's Experimental. This is t= he typical case of not being able to decide which protocol is "better" befor= e we have experience of dealing with them from a stable specification. Case i= n point: "PGM Reliable Transport Protocol Specification" (RFC 3208) >>=20 >> If we publish something it may or may not look like the current spec but g= etting some experience with the current spec will inform that decision.=20 >>=20 >> John B. >>> On Sep 11, 2014, at 12:55 PM, Phil Hunt wrote: >>>=20 >>> Interesting. The definitions in that don't correspond with what ADs and o= ther groups are doing.=20 >>>=20 >>> I heard httpbis using experimental as a placeholder for a draft that did= n't have full consensus to bring back later.=20 >>>=20 >>> That was the feel I had in Toronto-that we weren't done but it was time t= o publish something.=20 >>>=20 >>> Reading the actual definition i would say neither fits. Ugh.=20 >>>=20 >>> Phil >>>=20 >>>> On Sep 11, 2014, at 8:01, "Richer, Justin P." wrote= : >>>>=20 >>>> According to the guidelines here: >>>>=20 >>>> https://www.ietf.org/iesg/informational-vs-experimental.html >>>>=20 >>>> And the discussion in Toronto, it's clearly experimental. >>>>=20 >>>> -- Justin >>>>=20 >>>>> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin w= rote: >>>>>=20 >>>>> Is "experimental" the correct classification? Maybe "informational" is= more appropriate as both of these were discussed.=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschof= enig >>>>> Sent: Wednesday, September 10, 2014 4:50 PM >>>>> To: oauth@ietf.org >>>>> Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: N= ext Steps? >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> in response to the discussions at the last IETF meeting the authors of= the "Dynamic Client Registration Management Protocol" >>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have= changed the document type to "Experimental". >>>>>=20 >>>>> We need to make a decision about the next steps for the document and w= e see the following options: >>>>>=20 >>>>> a) Publish it as an experimental RFC >>>>>=20 >>>>> b) Remove it from the working group and ask an AD to shepherd it >>>>>=20 >>>>> c) Remove it from the working group and let the authors publish it via= the independent submission track. >>>>>=20 >>>>> In any case it would be nice to let folks play around with it and then= , after some time, come back to determine whether there is enough interest t= o produce a standard. >>>>>=20 >>>>> Please let us know what you think! >>>>>=20 >>>>> Ciao >>>>> Hannes & Derek >>>>>=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 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Thu Sep 11 14:23:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1041A0295 for ; Thu, 11 Sep 2014 14:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 1tKP1e8Oi2Ml for ; Thu, 11 Sep 2014 14:23:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AFAE1A02EC for ; Thu, 11 Sep 2014 14:22:36 -0700 (PDT) Received: from [192.168.10.163] ([167.220.25.81]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MUILK-1Xs8hm2CcE-00Qxy2; Thu, 11 Sep 2014 23:22:33 +0200 Message-ID: <54121291.8010106@gmx.net> Date: Thu, 11 Sep 2014 23:22:25 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Richer, Justin P." , John Bradley References: <5410E3AF.3030806@gmx.net> <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> <3AD141D9-5673-4945-9DC9-E95D7D35EF33@ve7jtb.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nnFD7JnfbVFO6sviQiPqtojdi8uiVnfvL" X-Provags-ID: V03:K0:BoxJfpXhZXz8bY4fbVnPW4InHBzIka6ww5MzMDLbex1n3pKhxIX rSp1ZmX0VPHnwpqCcBoQS21GPnuwb38mDuUi6QxLOK4Tth5s+74n0GekfMGdX00a4EJ2FC5 veFuqNrOXBbZbVpnhjd/TAz4mHgnDXgbmy8MIx9xGZlY3qZkckcY7W1o7pCBOrH7lBHV6zg 0JBmCt7O7Gt3T+E5duDBA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Kj-2eqQzEG8fmvav7eFs6Tl7hSQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 21:23:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nnFD7JnfbVFO6sviQiPqtojdi8uiVnfvL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I also looked at https://www.ietf.org/iesg/informational-vs-experimental.html and I got the impression that an Experimental RFC would be the right category. Ciao Hannes On 09/11/2014 06:03 PM, Richer, Justin P. wrote: > +1=20 >=20 > That was the key line that I took from the guidelines as well and this = was my understanding of the discussion in Toronto. >=20 > -- Justin >=20 > On Sep 11, 2014, at 12:02 PM, John Bradley wrote: >=20 >> I think this fits. >> >> =95 If the IETF may publish something based on this on the standards = track once we know how well this one works, it's Experimental. This is th= e typical case of not being able to decide which protocol is "better" bef= ore we have experience of dealing with them from a stable specification. = Case in point: "PGM Reliable Transport Protocol Specification" (RFC 3208)= >> >> If we publish something it may or may not look like the current spec b= ut getting some experience with the current spec will inform that decisio= n.=20 >> >> John B. >> On Sep 11, 2014, at 12:55 PM, Phil Hunt wrote: >> >>> Interesting. The definitions in that don't correspond with what ADs a= nd other groups are doing.=20 >>> >>> I heard httpbis using experimental as a placeholder for a draft that = didn't have full consensus to bring back later.=20 >>> >>> That was the feel I had in Toronto-that we weren't done but it was ti= me to publish something.=20 >>> >>> Reading the actual definition i would say neither fits. Ugh.=20 >>> >>> Phil >>> >>>> On Sep 11, 2014, at 8:01, "Richer, Justin P." wr= ote: >>>> >>>> According to the guidelines here: >>>> >>>> https://www.ietf.org/iesg/informational-vs-experimental.html >>>> >>>> And the discussion in Toronto, it's clearly experimental. >>>> >>>> -- Justin >>>> >>>>> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin wrote: >>>>> >>>>> Is "experimental" the correct classification? Maybe "informational"= is more appropriate as both of these were discussed.=20 >>>>> >>>>> -----Original Message----- >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tsc= hofenig >>>>> Sent: Wednesday, September 10, 2014 4:50 PM >>>>> To: oauth@ietf.org >>>>> Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol= : Next Steps? >>>>> >>>>> Hi all, >>>>> >>>>> in response to the discussions at the last IETF meeting the authors= of the "Dynamic Client Registration Management Protocol" >>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 h= ave changed the document type to "Experimental". >>>>> >>>>> We need to make a decision about the next steps for the document an= d we see the following options: >>>>> >>>>> a) Publish it as an experimental RFC >>>>> >>>>> b) Remove it from the working group and ask an AD to shepherd it >>>>> >>>>> c) Remove it from the working group and let the authors publish it = via the independent submission track. >>>>> >>>>> In any case it would be nice to let folks play around with it and t= hen, after some time, come back to determine whether there is enough inte= rest to produce a standard. >>>>> >>>>> Please let us know what you think! >>>>> >>>>> Ciao >>>>> Hannes & Derek >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 --nnFD7JnfbVFO6sviQiPqtojdi8uiVnfvL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEhKSAAoJEGhJURNOOiAtWnkIAIdfjbxfBDPw4AUUfSNsf4MJ WzdpJxA4Qn8mJbM9CDumvxGxpJwPH9O/+nL9Q6ZXaG3AP9outiSATQY2YYNbMLo7 oiAKaGwEh5HIwFxED05yNp+KDzrypH57qOGxiJze+jRS7ORw3Zz5l2r+OAa4/QHq jFp+3HYBJrLG2UHGKyQdFVJO5YsyrzPOVocQr8c9Enyhwa1P4v3xBZ6TtzkdGrfo VPmgC5a68mVlYeFss1G6P7axcbNinS4IHULBwrfco6HD7IcsOi017ErYAoZRv5YA ItHdAiNonUIxj2IszToVEh+w0PrcVCiM9ZYUHkTtzTVxi6CWZTSQ/o2mPw8t6+g= =sm+r -----END PGP SIGNATURE----- --nnFD7JnfbVFO6sviQiPqtojdi8uiVnfvL-- From nobody Thu Sep 11 14:38:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F81F1A0295 for ; Thu, 11 Sep 2014 14:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 uJ9QQ0mOKS1b for ; Thu, 11 Sep 2014 14:38:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2271A02A2 for ; Thu, 11 Sep 2014 14:38:36 -0700 (PDT) Received: from [192.168.10.163] ([167.220.25.81]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LanoO-1YCZW53V16-00kRaT; Thu, 11 Sep 2014 23:38:34 +0200 Message-ID: <54121656.7090901@gmx.net> Date: Thu, 11 Sep 2014 23:38:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Rex Albert , oauth@ietf.org References: <54101EB7.1000502@gmail.com> <541074C3.3030400@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="R5sAWBn55AL4Sk810GjgAqwwBAGmGVkpu" X-Provags-ID: V03:K0:YRLWWYU8N8EXsi0wdvVdY+5ghmvEbTUsYOLvdTAZOQVNq5hgOw5 6yvlo2Gm4VGtrnE+0iNx4h12WoxJ8yGnNQDIXoi20sd4DoKG69Ht6YRXOYRTj6FESjVbcqb dY4cq+PRpaEEaJDvwXh/XVrym0W/Hdd/g299WLAV53REmGQYeGxCkf+YINA/Is5RYdgIp+N m/W4LTb+Y19Gmbiwmkmmw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ly6jWn78QJ1Jvmd22sloikyLdXU Subject: Re: [OAUTH-WG] Fwd: Is OAUTHV2-HTTP_MAC dead? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 21:38:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R5sAWBn55AL4Sk810GjgAqwwBAGmGVkpu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rex, On 09/11/2014 10:15 AM, Rex Albert wrote: > Hi Hannes, > thank you very much for the response and it is very useful to have such= > detailed information. thank you again for that.=20 > I am now reading about PoP and it is very interesting and also seeing > HTTP signature as well.=20 Thanks for looking at the document. Please provide comments, if you run into questions or bugs. > Our requirement in short - to achieve seamless authentication and > authorization among HTTP - REST based web services within a protected > network with a secure channel for communication, without human > intervention and without compromise on the time taken to process each > request.=20 I think we are getting there. > Kindly let me know if you need further details .=20 Particuarly for the HTTP signature approach we need input since it is still not close to getting finalized. It would also be great if you also have some possibility to provide implementation feedback. > thanks again > -rex >=20 Ciao Hannes > On Wed, Sep 10, 2014 at 9:26 PM, Hannes Tschofenig > > wrote: >=20 > Hi Rex, >=20 > the document has been superseded = by > the PoP work (which was subsequently split into various other > documents). >=20 > That, however, does not mean that the content is dead. The mechanis= m for > the authorization server to convey the symmetric key to the client = is > now documented in . The high= > level description / overview is now documented in > . The actual mechanism for the c= lient > to apply the key to the request to the resource server is now docum= ented > in . >=20 > While < draft-ietf-oauth-signed-http-request> today is different to= the > mechanism described in it also ha= s to > be said that it is the weakest document in the entire document set = at > the moment. >=20 > So, there is still a chance to incorporate your design requirements= into > the appropriate parts of the work since the work is still in progre= ss. >=20 > It would be good to know what your requirements/interests are. >=20 > Ciao > Hannes >=20 >=20 > On 09/10/2014 11:49 AM, Sergey Beryozkin wrote: > > Hi > > On 10/09/14 09:57, Rex Albert wrote: > >> > >> > >> Hi, > >> We are looking at implementing OAUTHV2-HTTP-MAC whose draft is i= n an > >> expired > >> > state.(http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05) = Is > >> it dead or is it going to be a standard anytime? or are we going= to > >> implement at our own risk? or is there a better standard/draft (= > alive ) > >> which might supersede this draft ? > > > > It's not going to be revived. Does not mean though one can not us= e the > > idea for implementing custom OAuth2 token schemes, IMHO it was a = very > > simple and effective 'PoP' approach, and it is easy to document a= nd > > support. FYI, we support a Hawk scheme (not part of OAuth2 work a= t > all, > > kind of 'draft-ietf-oauth-v2-http-mac-06') as an access token > scheme in > > our project. > > > > As far as I understand new proof-of-possession documents the grou= p is > > working upon will offer the alternative standard solutions. > > > > Cheers, Sergey > > > >> > >> thank you for your time. > >> I am a newbie to the IETF draft process and kindly excuse my nai= vety. > >> -rex > >> > >> > >> > >> _______________________________________________ > >> 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 >=20 --R5sAWBn55AL4Sk810GjgAqwwBAGmGVkpu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEhZWAAoJEGhJURNOOiAtX1AH/jdyZIUdiogzT2sCWD9wcMfe 3lPfTWdFO0bTpUSU+RA7HLqMAQBbPb1/Ig/IBmyqYtqWwZ2ScBS9+IAL400SH8l1 qTLmhl9c0CkfYIL6HGxZmIfNRZjG2SNDhZGK14UqK0WSwyC4QHUN+M/Yj0bsvRot 2G7bYeVc3sP6CPgryLEzp66Sr7D481ib2UkwAnyPVDOLpD3D6tWNb1mxNaMHX+Fz 2MMDk6Hy+PsFmcdSpXqas3kC/jgSt+z/L3CikTieL7ScHgjYZks9pFIKn67KJVMg DiwkkzacpAKiiII1WBtPekDtFFHUxexxc4/Adahs70/W5mPW1zraKyVdW0JCoXc= =wWyb -----END PGP SIGNATURE----- --R5sAWBn55AL4Sk810GjgAqwwBAGmGVkpu-- From nobody Thu Sep 11 15:20:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177821A017A for ; Thu, 11 Sep 2014 15:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 RwlUCwSL8QjX for ; Thu, 11 Sep 2014 15:20:17 -0700 (PDT) Received: from na6sys009bog009.obsmtp.com (na6sys009bog009.obsmtp.com [74.125.150.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660A51A0172 for ; Thu, 11 Sep 2014 15:20:17 -0700 (PDT) Received: from mail-ie0-f171.google.com ([209.85.223.171]) (using TLSv1) by na6sys009bob009.postini.com ([74.125.148.12]) with SMTP ID DSNKVBIgIBGy7FjdjhRcS5UKcfiY6fAl90H7@postini.com; Thu, 11 Sep 2014 15:20:17 PDT Received: by mail-ie0-f171.google.com with SMTP id y20so4087850ier.30 for ; Thu, 11 Sep 2014 15:20:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=nUtGSdfPDmLgyEiRJJSa3oJWOZI1Q5GL0LBcY314tiU=; b=OFfDBa0EfL5NDCS61+u/Xp+atZf7CML0Ng8h98T9U7/bF8YoUiY+KnjJDg5RkjtzLA pdMIQ2d4Ews8tVc4shitImlFsYCU3996Hm2rDF5O4Dvb70beJ3oCI/0hGHq4Hav063rA 5L/am2vdJ/68bO+fXP6WGseWwqVnZ8DnEIbS4g3mxCAEWlIAEEVKkilD5pUjQeb0QZf/ zzbiVdVaWEs22lB5brUqAWRbq+hQ4Y1rq8e3ySK04QejSk6klREwfsCJuJmjRvYDZu9y puSt4opqGshG7mni9ihszmD3XZ+9sAb9PQ1XeFRePctT+5JsyB6loIiSEtD729hFoRFe pLow== X-Gm-Message-State: ALoCoQksIKbJGYvtEtS+diz2UFxXtq9Ze7zqB1CiRUQ1FZm5RlV9ia1uXVHCRLB/h6acCX//XVtmhYWg6xyRULQJHVQtitz82Kk4oiL6c1slfd6070ljJPbh2hu2/lvpt7lh2bU378dN X-Received: by 10.51.17.66 with SMTP id gc2mr6635984igd.40.1410474016137; Thu, 11 Sep 2014 15:20:16 -0700 (PDT) X-Received: by 10.51.17.66 with SMTP id gc2mr6635968igd.40.1410474015984; Thu, 11 Sep 2014 15:20:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 11 Sep 2014 15:19:45 -0700 (PDT) From: Brian Campbell Date: Thu, 11 Sep 2014 16:19:45 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a1135f3a4b0c2e30502d19285 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Pl6yvVMcjzm4f_C7t8vlKY2ewRo Cc: "oauth@ietf.org" Subject: [OAUTH-WG] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:20:21 -0000 --001a1135f3a4b0c2e30502d19285 Content-Type: text/plain; charset=UTF-8 Why does expiration only apply to the client secret[1]? If there's a need for the AS to set an expiration, isn't it broader than that and apply to the whole client or the client id? If there's a need to signal an expiration time on the client secret, doesn't it follow that the client's JSON Web Key Set (the jwks parameter) might also need to be expired? And what about strictly implicit clients or other public clients, is there no case that an AS would want to expire them? I realize I've asked this before (more than once) but I've never gotten an answer. To me, whats in this draft that's on its way to the IESG is awkward and/or incomplete. I believe that either the client_secret_expires_at should be removed from draft-ietf-oauth-dyn-reg or it should be changed to something that isn't specific to the client secret - something like client_expires_at or client_id_expires_at. [1] client_secret_expires_at in https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1 On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > I have just sent the Dynamic Client Registration document to the IESG. > The final shepherd write-up for the document can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/ > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1135f3a4b0c2e30502d19285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Why does expiration only apply to the client sec= ret[1]? If there's a need for the AS to set an expiration, isn't it= broader than that and apply to the whole client or the client id? If there= 's a need to signal an expiration time on the client secret, doesn'= t it follow that the client's JSON Web Key Set (the jwks parameter) mig= ht also need to be expired? And what about strictly implicit clients or oth= er public clients, is there no case that an AS would want to expire them?
I realize I've asked this before (more than once) but I'= ;ve never gotten an answer. To me, whats in this draft that's on its wa= y to the IESG is awkward and/or incomplete.

I believe that ei= ther the client_secret_expires_at should be removed from draft-ietf-oauth-d= yn-reg or it should be changed to something that isn't specific to the = client secret - something like client_expires_at or client_id_expires_at.
[1] client_secret_expires_at in https://tools.ietf.org/html/draf= t-ietf-oauth-dyn-reg-20#section-4.1

On Wed, Sep 10, 2014 at 5:50 PM, Hannes= Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

I have just sent the Dynamic Client Registration document to the IESG.
The final shepherd write-up for the document can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oau= th-dyn-reg/shepherdwriteup/

Ciao
Hannes


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


--001a1135f3a4b0c2e30502d19285-- From nobody Thu Sep 11 15:22:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3621A017A for ; Thu, 11 Sep 2014 15:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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_enM9phghij for ; Thu, 11 Sep 2014 15:22:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAA41A0172 for ; Thu, 11 Sep 2014 15:22:50 -0700 (PDT) Received: from [192.168.10.163] ([167.220.25.81]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MgsVY-1XfUS01TrE-00M2mq for ; Fri, 12 Sep 2014 00:22:48 +0200 Message-ID: <541220B5.2000801@gmx.net> Date: Fri, 12 Sep 2014 00:22:45 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MhFdO1qfWpPMGAUpBURsERshh3o4lT1KT" X-Provags-ID: V03:K0:V+h0HTF54IX/EyyTQQ/xpOLYQ2QnNeohybgCAcr3wAPh7auxjy3 8K6SwNXaymWR8fPilNZjRiHjjdDT8cUDmwiwOmsNVeI+c4GEUBUm2vouBS7SnW93alhBIoy 4GvLk2LEpfXsae7Fp4tGu4ZqV3uYPM924MH5B6VUxqMbffeWBFPp2AJlE2O61zVu1N3SQhc ZGsOWM3sOXJJU3equnatA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/B7eC9me1AC-mSv1p3Ek0KmSTf-A Subject: [OAUTH-WG] Fwd: IPR Disclosure: Nokia Corporation's Statement about IPR related to RFC 6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:22:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MhFdO1qfWpPMGAUpBURsERshh3o4lT1KT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, in private messages I have gotten questions about this IPR announcement received in March 2014 and the potential implications on the core OAuth 2.0 protocol. I was thinking about putting it on the agenda for the next IETF meeting. The feedback I am hoping to get is whether there is a concern about this IPR from those who have products and services based on OAuth. I want to know whether you see problems or not. If you have problems, maybe there are ways to engineer around it. Ciao Hannes PS: If someone has time to review the state of the art in 2009 I would also like to chat with you. -------- Forwarded Message -------- Subject: IPR Disclosure: Nokia Corporation's Statement about IPR related to RFC 6749 Date: Fri, 28 Mar 2014 07:33:05 -0700 From: IETF Secretariat To: dick.hardt@gmail.com CC: stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org Dear Dick Hardt: An IPR disclosure that pertains to your RFC entitled "The OAuth 2.0 Authorization Framework" (RFC6749) was submitted to the IETF Secretariat = on 2014-03-28 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2336/). The title of the I= PR disclosure is "Nokia Corporation's Statement about IPR related to RFC 6749.""); The IETF Secretariat --MhFdO1qfWpPMGAUpBURsERshh3o4lT1KT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEiC1AAoJEGhJURNOOiAtPUYIAJBiANsbpqu9cNy1jjbH9yAj DHsltisDQZ81dnZiTzU1Fwz5MhfjzDXV+fyTavWt2Cunh7Lgf+L6mQaqdh8d8gqM rIdLGe2DTYEy5mP2Kh7LA/PMc5aJAoqSn8RTxYnzhKUf+rfL3FCPGbFap2XAYeA3 ncj5zajuFg9zPcL6Cb5B3fsa6D4DhrGimQbP3xUjNmTT2Ws9AXwc9jujpyHAgrsb R7+YJ/6wA2FWpmKtTeqUfQkOtw5mdb0BdiLbodkh/afbSwSD2y3njMk/0O/SYp2l BUJ19MVYIbGqoLMPe0XfKyDQ36rGeqIPlLziQ0TL9S4R0zjI1LREAFZwwiO4s3g= =cz83 -----END PGP SIGNATURE----- --MhFdO1qfWpPMGAUpBURsERshh3o4lT1KT-- From nobody Thu Sep 11 15:27:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEC41A017A for ; Thu, 11 Sep 2014 15:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 hmc20GIIJySd for ; Thu, 11 Sep 2014 15:27:00 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB0F1A0172 for ; Thu, 11 Sep 2014 15:26:59 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id f51so9580640qge.17 for ; Thu, 11 Sep 2014 15:26:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wwEm5Ex0ku1ShJmSvcgNOkXJ69uUCu0JVS+tIAaX7yw=; b=Fu5ipidI95CtCOa16opkFMCNvFIya63D4r0BD55fKv1hw+uDP1GqzDHdC2XU0PS8b6 453kxdo0NlYEsbNHGwSZHSFixQFRZ6w0lAFxmVITd0S7cu5yWdhk7f0W+X9SLUikEgd6 KROQ6ZeZstuOOR3zD5L302Q5yE6LtqH9D7NUjw6k/uwNXNVPOLzyHrOFaOORm1gkKhKx Lv0ydoJoaDFIdyJsbThpyXR8mPZmEI2kJo3zUPqDG+qbIbNfhYapJaC9xY6T4rvgk0Ns beeibPrHlOxAqStdUGJ1Q9B7l8Jzpgs+Jm3ECeeMllUbFFUraqN5UG3x2uWFgRARf7H3 XyIg== X-Gm-Message-State: ALoCoQkbXGA6YHT2rNR/U7M87pxWBYv9tnUBA31lEFtC9q7J+1CzrmbvpRP4QQ2vkqV93IDBlPiJ X-Received: by 10.224.46.67 with SMTP id i3mr6380533qaf.90.1410474418161; Thu, 11 Sep 2014 15:26:58 -0700 (PDT) Received: from [192.168.1.37] (186-106-172-214.baf.movistar.cl. [186.106.172.214]) by mx.google.com with ESMTPSA id k52sm1633609qge.42.2014.09.11.15.26.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 15:26:57 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6D30A4A6-CE23-4BEE-9FDC-1C193C124FB2"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <541220B5.2000801@gmx.net> Date: Thu, 11 Sep 2014 19:26:53 -0300 Message-Id: References: <541220B5.2000801@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JAyMsAVxYrHlrzvAuv5Anop0bH8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: IPR Disclosure: Nokia Corporation's Statement about IPR related to RFC 6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:27:02 -0000 --Apple-Mail=_6D30A4A6-CE23-4BEE-9FDC-1C193C124FB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Some large number of us would be roasted by our legal departments if we = looked at a patent. Discussing the specifics of patents is not appropriate for a WG meeting. Someone from the IETF should look at the issue but not me. John B. On Sep 11, 2014, at 7:22 PM, Hannes Tschofenig = wrote: > Hi all, >=20 > in private messages I have gotten questions about this IPR = announcement > received in March 2014 and the potential implications on the core = OAuth > 2.0 protocol. I was thinking about putting it on the agenda for the = next > IETF meeting. >=20 > The feedback I am hoping to get is whether there is a concern about = this > IPR from those who have products and services based on OAuth. >=20 > I want to know whether you see problems or not. If you have problems, > maybe there are ways to engineer around it. >=20 > Ciao > Hannes >=20 > PS: If someone has time to review the state of the art in 2009 I would > also like to chat with you. >=20 > -------- Forwarded Message -------- > Subject: IPR Disclosure: Nokia Corporation's Statement about IPR = related > to RFC 6749 > Date: Fri, 28 Mar 2014 07:33:05 -0700 > From: IETF Secretariat > To: dick.hardt@gmail.com > CC: stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, > Hannes.Tschofenig@gmx.net, derek@ihtfp.com, oauth@ietf.org, > ipr-announce@ietf.org >=20 >=20 > Dear Dick Hardt: >=20 > An IPR disclosure that pertains to your RFC entitled "The OAuth 2.0 > Authorization Framework" (RFC6749) was submitted to the IETF = Secretariat on > 2014-03-28 and has been posted on the "IETF Page of Intellectual > Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/2336/). The title of = the IPR > disclosure is "Nokia Corporation's Statement about IPR related to RFC > 6749.""); >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6D30A4A6-CE23-4BEE-9FDC-1C193C124FB2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MTEyMjI2NTNaMCMGCSqGSIb3DQEJBDEWBBSaKG5eySx+0k5nTrujgz5L AtfZxDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBfiRAUI68KLpMYUuOg1SCsdgXdeZTrcfn9ULQE2Rvm7cjaNjhnnKJN U0UXtCvXDqNMKfiFpgaVSP4c1bPgbbv5zpIk3+RKP7EGEsT+t8aunvHtnS8fX1EKkWOhdGS3XQhK Sbec7Fq2oGlPSLx7OvqWoGqeXlk72Njnxaj5Lptb0pBReRe2d74+HWXk4aE9SypTLPPpE/tIKFsj +m5yJ1mvUWqBIoGRv8YPBErdsnxZk5VW0CdgpgslrOzYWl/QJQ8PHvvPzNFD2q2pRquNAi3JpESE TD5gSj8rrq/H3o9QGMfHV1bduTrZpomW3RXoZ8f/pdCA9akGcEe/SHhhaCvMAAAAAAAA --Apple-Mail=_6D30A4A6-CE23-4BEE-9FDC-1C193C124FB2-- From nobody Thu Sep 11 15:27:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21AD1A02E3 for ; Thu, 11 Sep 2014 15:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 loZGV7G8LxWz for ; Thu, 11 Sep 2014 15:27:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:796]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1B61A0199 for ; Thu, 11 Sep 2014 15:27:14 -0700 (PDT) Received: from BY2PR03CA061.namprd03.prod.outlook.com (10.141.249.34) by BY1PR0301MB1206.namprd03.prod.outlook.com (25.161.203.155) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Thu, 11 Sep 2014 22:26:50 +0000 Received: from BN1BFFO11FD033.protection.gbl (2a01:111:f400:7c10::1:167) by BY2PR03CA061.outlook.office365.com (2a01:111:e400:2c5d::34) with Microsoft SMTP Server (TLS) id 15.0.1024.12 via Frontend Transport; Thu, 11 Sep 2014 22:26:50 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD033.mail.protection.outlook.com (10.58.144.96) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Thu, 11 Sep 2014 22:26:50 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0195.002; Thu, 11 Sep 2014 22:26:13 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Fwd: IPR Disclosure: Nokia Corporation's Statement about IPR related to RFC 6749 Thread-Index: AQHPzg7z496/msaOBUyJjvRNYp8A2Jv8geYA Date: Thu, 11 Sep 2014 22:26:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AEBCE57@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <541220B5.2000801@gmx.net> In-Reply-To: <541220B5.2000801@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(377424004)(377454003)(53754006)(13464003)(2473001)(199003)(104016003)(44976005)(92726001)(83322001)(99396002)(92566001)(81542001)(80022001)(86362001)(83072002)(54356999)(46102001)(6806004)(50986999)(85306004)(19580395003)(107886001)(26826002)(19580405001)(64706001)(107046002)(106116001)(76176999)(85806002)(81342001)(85852003)(81156004)(106466001)(86612001)(97736003)(23676002)(79102001)(15975445006)(21056001)(84676001)(2656002)(76482001)(55846006)(74502001)(50466002)(77096002)(47776003)(20776003)(2501002)(87936001)(77982001)(4396001)(95666004)(68736004)(66066001)(90102001)(33656002)(69596002)(31966008)(74662001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1206; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03319F6FEF Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3sR78Wyds7BBGt2SMbRWgvFqz3A Subject: Re: [OAUTH-WG] Fwd: IPR Disclosure: Nokia Corporation's Statement about IPR related to RFC 6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:27:17 -0000 WW91IHNob3VsZCBub3QgYnJpbmcgdGhpcyB0byB0aGUgd29ya2luZyBncm91cCwgb3RoZXIgdGhh biBtYWtpbmcgcGVvcGxlIGF3YXJlIHRoYXQgdGhlIGRpc2Nsb3N1cmUgZXhpc3RzICh3aGljaCB5 b3UndmUgYWxyZWFkeSBkb25lKS4gIEkga25vdyB0aGF0IEkgd2lsbCBsZWF2ZSB0aGUgcm9vbSBp ZiB0aGUgY29udGVudHMgb2YgYSBwYXRlbnQgYXJlIGRpc2N1c3NlZCBhbmQgSSB3aWxsIGVuY291 cmFnZSBvdGhlcnMgdG8gbGlrZXdpc2UgZG8gc28uDQoNCkVuZ2luZWVycyBzaG91bGQgbm90IGV2 YWx1YXRlIHBhdGVudHMuICBJZiBhIHBlcnNvbiB3YW50cyBhIGxlZ2FsIG9waW5pb24gb24gdGhl IGRpc2Nsb3N1cmUsIHRoZXkgc2hvdWxkIHByaXZhdGVseSBjb25zdWx0IHRoZWlyIGxlZ2FsIGNv dW5zZWwuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5u ZXMgVHNjaG9mZW5pZw0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxMSwgMjAxNCAzOjIzIFBN DQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gRndkOiBJUFIgRGlzY2xv c3VyZTogTm9raWEgQ29ycG9yYXRpb24ncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8g UkZDIDY3NDkNCg0KSGkgYWxsLA0KDQppbiBwcml2YXRlIG1lc3NhZ2VzIEkgaGF2ZSBnb3R0ZW4g cXVlc3Rpb25zIGFib3V0IHRoaXMgSVBSIGFubm91bmNlbWVudCByZWNlaXZlZCBpbiBNYXJjaCAy MDE0IGFuZCB0aGUgcG90ZW50aWFsIGltcGxpY2F0aW9ucyBvbiB0aGUgY29yZSBPQXV0aA0KMi4w IHByb3RvY29sLiBJIHdhcyB0aGlua2luZyBhYm91dCBwdXR0aW5nIGl0IG9uIHRoZSBhZ2VuZGEg Zm9yIHRoZSBuZXh0IElFVEYgbWVldGluZy4NCg0KVGhlIGZlZWRiYWNrIEkgYW0gaG9waW5nIHRv IGdldCBpcyB3aGV0aGVyIHRoZXJlIGlzIGEgY29uY2VybiBhYm91dCB0aGlzIElQUiBmcm9tIHRo b3NlIHdobyBoYXZlIHByb2R1Y3RzIGFuZCBzZXJ2aWNlcyBiYXNlZCBvbiBPQXV0aC4NCg0KSSB3 YW50IHRvIGtub3cgd2hldGhlciB5b3Ugc2VlIHByb2JsZW1zIG9yIG5vdC4gSWYgeW91IGhhdmUg cHJvYmxlbXMsIG1heWJlIHRoZXJlIGFyZSB3YXlzIHRvIGVuZ2luZWVyIGFyb3VuZCBpdC4NCg0K Q2lhbw0KSGFubmVzDQoNClBTOiBJZiBzb21lb25lIGhhcyB0aW1lIHRvIHJldmlldyB0aGUgc3Rh dGUgb2YgdGhlIGFydCBpbiAyMDA5IEkgd291bGQgYWxzbyBsaWtlIHRvIGNoYXQgd2l0aCB5b3Uu DQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0OiBJUFIgRGlz Y2xvc3VyZTogTm9raWEgQ29ycG9yYXRpb24ncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQg dG8gUkZDIDY3NDkNCkRhdGU6IEZyaSwgMjggTWFyIDIwMTQgMDc6MzM6MDUgLTA3MDANCkZyb206 IElFVEYgU2VjcmV0YXJpYXQgPGlldGYtaXByQGlldGYub3JnPg0KVG86IGRpY2suaGFyZHRAZ21h aWwuY29tDQpDQzogc3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSwgS2F0aGxlZW4uTW9yaWFydHku aWV0ZkBnbWFpbC5jb20sIEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQsIGRlcmVrQGlodGZwLmNv bSwgb2F1dGhAaWV0Zi5vcmcsIGlwci1hbm5vdW5jZUBpZXRmLm9yZw0KDQoNCkRlYXIgRGljayBI YXJkdDoNCg0KIEFuIElQUiBkaXNjbG9zdXJlIHRoYXQgcGVydGFpbnMgdG8geW91ciBSRkMgZW50 aXRsZWQgIlRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsiIChSRkM2NzQ5KSB3 YXMgc3VibWl0dGVkIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IG9uDQoyMDE0LTAzLTI4IGFuZCBo YXMgYmVlbiBwb3N0ZWQgb24gdGhlICJJRVRGIFBhZ2Ugb2YgSW50ZWxsZWN0dWFsIFByb3BlcnR5 IFJpZ2h0cyBEaXNjbG9zdXJlcyIgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIz MzYvKS4gVGhlIHRpdGxlIG9mIHRoZSBJUFIgZGlzY2xvc3VyZSBpcyAiTm9raWEgQ29ycG9yYXRp b24ncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8gUkZDIDY3NDkuIiIpOw0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KDQoNCg== From nobody Thu Sep 11 15:30:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E761A015F for ; Thu, 11 Sep 2014 15:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 bYtib3J_rn8l for ; Thu, 11 Sep 2014 15:30:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB851A00C3 for ; Thu, 11 Sep 2014 15:30:33 -0700 (PDT) Received: from [192.168.10.163] ([167.220.25.81]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lbi2Z-1YCEt52e4Z-00lGb2; Fri, 12 Sep 2014 00:30:29 +0200 Message-ID: <54122280.1030609@gmx.net> Date: Fri, 12 Sep 2014 00:30:24 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3A4AwKTPLOphfB6jnlM7ieKusaB9CBsr2" X-Provags-ID: V03:K0:tKQ0qwmVeLLJIaV90yGay5bKurgSf69U9eV3KRGBunDEgiUxwH4 uoFUIKqLouhb8o0abXIo2/oxj3yKut/I+79/quxsUjYacm9J1RYyg7UR7QLfcD8o/1OCv+T dHbY53BdGVYiV+DVuoPj8UuUR5FYinnHDEY0oPB6un4ZS0c726mmgk4LffTWOgpq2lEYgG+ 52MnNwUdIjOKnDieWR2pA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fVhzT8VBwYq-CQkcGhUmEdetA9o Cc: Derek Atkins Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:30:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3A4AwKTPLOphfB6jnlM7ieKusaB9CBsr2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, at the last IETF meeting Mike gave a presentation about the draft-hunt-oauth-v2-user-a4c and the conclusion following the discussion was to discuss the problems that happen when OAuth gets used for authentication. The goal of this effort is to document the problems in an informational document. Conference calls could start in about 2 weeks and we would like to know who would be interested to participate in such a discussion. Please drop us a private mail so that we can find suitable dates/times. Ciao Hannes & Derek --3A4AwKTPLOphfB6jnlM7ieKusaB9CBsr2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEiKBAAoJEGhJURNOOiAt02oH/RM3PyoDLR+QHSJiYg0v/lqQ Y4e1UEAu/Vt9pOvFYNIQ4cdsMa4Oqfh2qpdIO3QBU39vaeMStwlo2cDLQl4+zy3R EgVOGcnVlXBG1ti2ptQRRVt35vzdY7jujj9SVogOYfAKi1WJH3ttP2xKXri0hanq fXcj/QIzdpvs40THixMXcwuCiYuVqD+ur+zMI/QuEPDZMnjDprB89zNVRLOBSpCA 4r2Ncx1G2kD5SIZnm/2wlDH/KXdHNCQ/JxcYJwNJH4RrZzdr6igPFTEV7wiv+l10 fp3UmB8IqLTdxL1W2zdFGcwxuk7Mwduar9jp3ddR/R7PTebkLhrczjP66/DlbXY= =Y00B -----END PGP SIGNATURE----- --3A4AwKTPLOphfB6jnlM7ieKusaB9CBsr2-- From nobody Thu Sep 11 15:32:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FEB1A015F for ; Thu, 11 Sep 2014 15:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ws_1VdfNHmoP for ; Thu, 11 Sep 2014 15:32:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE3A1A00C3 for ; Thu, 11 Sep 2014 15:32:08 -0700 (PDT) Received: from BLUPR03MB312.namprd03.prod.outlook.com (10.141.48.28) by BLUPR03MB118.namprd03.prod.outlook.com (10.255.212.19) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Thu, 11 Sep 2014 22:32:07 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB312.namprd03.prod.outlook.com (10.141.48.28) with Microsoft SMTP Server (TLS) id 15.0.1029.10; Thu, 11 Sep 2014 22:32:06 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.1029.000; Thu, 11 Sep 2014 22:32:06 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth & Authentication: What can go wrong? Thread-Index: AQHPzhAGVAFX2NZHi0+Yhg3sPv9VXZv8hDaQ Date: Thu, 11 Sep 2014 22:32:05 +0000 Message-ID: <1a2eb1cb9138414c83c258a73f92e413@BLUPR03MB309.namprd03.prod.outlook.com> References: <54122280.1030609@gmx.net> In-Reply-To: <54122280.1030609@gmx.net> 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: [167.220.26.50] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 03319F6FEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(53754006)(13464003)(199003)(2501002)(86362001)(77982001)(20776003)(33646002)(74316001)(85852003)(92566001)(76482001)(21056001)(87936001)(97736003)(64706001)(66066001)(80022001)(95666004)(83322001)(108616004)(76576001)(81542001)(74662001)(74502001)(31966008)(46102001)(105586002)(2656002)(106356001)(85306004)(107046002)(99396002)(86612001)(76176999)(79102001)(4396001)(90102001)(83072002)(54356999)(50986999)(19580395003)(99286002)(19580405001)(81342001)(106116001)(101416001)(24736002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB312; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ZOHdkfwLjcC-g40bQXmj73eFteo Cc: Derek Atkins Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:32:10 -0000 QWRkIG1lDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0K U2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxMSwgMjAxNCAzOjMwIFBNDQpUbzogb2F1dGhAaWV0 Zi5vcmcNCkNjOiBEZXJlayBBdGtpbnMNClN1YmplY3Q6IFtPQVVUSC1XR10gT0F1dGggJiBBdXRo ZW50aWNhdGlvbjogV2hhdCBjYW4gZ28gd3Jvbmc/DQoNCkhpIGFsbCwNCg0KYXQgdGhlIGxhc3Qg SUVURiBtZWV0aW5nIE1pa2UgZ2F2ZSBhIHByZXNlbnRhdGlvbiBhYm91dCB0aGUgZHJhZnQtaHVu dC1vYXV0aC12Mi11c2VyLWE0YyBhbmQgdGhlIGNvbmNsdXNpb24gZm9sbG93aW5nIHRoZSBkaXNj dXNzaW9uIHdhcyB0byBkaXNjdXNzIHRoZSBwcm9ibGVtcyB0aGF0IGhhcHBlbiB3aGVuIE9BdXRo IGdldHMgdXNlZCBmb3IgYXV0aGVudGljYXRpb24uDQoNClRoZSBnb2FsIG9mIHRoaXMgZWZmb3J0 IGlzIHRvIGRvY3VtZW50IHRoZSBwcm9ibGVtcyBpbiBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50 Lg0KDQpDb25mZXJlbmNlIGNhbGxzIGNvdWxkIHN0YXJ0IGluIGFib3V0IDIgd2Vla3MgYW5kIHdl IHdvdWxkIGxpa2UgdG8ga25vdyB3aG8gd291bGQgYmUgaW50ZXJlc3RlZCB0byBwYXJ0aWNpcGF0 ZSBpbiBzdWNoIGEgZGlzY3Vzc2lvbi4NCg0KUGxlYXNlIGRyb3AgdXMgYSBwcml2YXRlIG1haWwg c28gdGhhdCB3ZSBjYW4gZmluZCBzdWl0YWJsZSBkYXRlcy90aW1lcy4NCg0KQ2lhbw0KSGFubmVz ICYgRGVyZWsNCg0K From nobody Thu Sep 11 15:32:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574441A019B for ; Thu, 11 Sep 2014 15:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 N06WENPtpceL for ; Thu, 11 Sep 2014 15:32:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827371A017D for ; Thu, 11 Sep 2014 15:32:17 -0700 (PDT) Received: from [192.168.10.163] ([167.220.25.81]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M6O1v-1YGl880vKV-00yNHJ; Fri, 12 Sep 2014 00:32:15 +0200 Message-ID: <541222EB.3050300@gmx.net> Date: Fri, 12 Sep 2014 00:32:11 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mike Jones , "oauth@ietf.org" References: <541220B5.2000801@gmx.net> <4E1F6AAD24975D4BA5B16804296739439AEBCE57@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AEBCE57@TK5EX14MBXC292.redmond.corp.microsoft.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PhP57Q0hsruC2ENCk0T9Qk4JhVW0SItMq" X-Provags-ID: V03:K0:CL7z5KiU3FQWNVfxUe5C4nmVe61DEkuRo62CfALFUR/wHnT0Uqy A9iIM8oB5Ehg7nptoNifAUOZ0GNfqLpejxNQzXSbXX/rJqyjHYnw8r5AhJGw4QQPM1RqPCU hpy90TGGnNQzFB34H39nuzXstrh1B8oaDOzpovTc5HBJl0dyCxymmkQDyVUaccxCE+fAxbp RP/nv6cUf7gIJi6Cz+dSA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_YMjBM3JkkIwEsExTCXQ9ixR3Mk Subject: Re: [OAUTH-WG] Fwd: IPR Disclosure: Nokia Corporation's Statement about IPR related to RFC 6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:32:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PhP57Q0hsruC2ENCk0T9Qk4JhVW0SItMq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike, as I wrote in my mail below, I am looking for feedback whether the IPR is a concern to companies. I am not asking for a patent assessment. Ciao Hannes On 09/12/2014 12:26 AM, Mike Jones wrote: > You should not bring this to the working group, other than making peopl= e aware that the disclosure exists (which you've already done). I know t= hat I will leave the room if the contents of a patent are discussed and I= will encourage others to likewise do so. >=20 > Engineers should not evaluate patents. If a person wants a legal opini= on on the disclosure, they should privately consult their legal counsel. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofe= nig > Sent: Thursday, September 11, 2014 3:23 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Fwd: IPR Disclosure: Nokia Corporation's Statement = about IPR related to RFC 6749 >=20 > Hi all, >=20 > in private messages I have gotten questions about this IPR announcement= received in March 2014 and the potential implications on the core OAuth > 2.0 protocol. I was thinking about putting it on the agenda for the nex= t IETF meeting. >=20 > The feedback I am hoping to get is whether there is a concern about thi= s IPR from those who have products and services based on OAuth. >=20 > I want to know whether you see problems or not. If you have problems, m= aybe there are ways to engineer around it. >=20 > Ciao > Hannes >=20 > PS: If someone has time to review the state of the art in 2009 I would = also like to chat with you. >=20 > -------- Forwarded Message -------- > Subject: IPR Disclosure: Nokia Corporation's Statement about IPR relate= d to RFC 6749 > Date: Fri, 28 Mar 2014 07:33:05 -0700 > From: IETF Secretariat > To: dick.hardt@gmail.com > CC: stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes= =2ETschofenig@gmx.net, derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf= =2Eorg >=20 >=20 > Dear Dick Hardt: >=20 > An IPR disclosure that pertains to your RFC entitled "The OAuth 2.0 Au= thorization Framework" (RFC6749) was submitted to the IETF Secretariat on= > 2014-03-28 and has been posted on the "IETF Page of Intellectual Proper= ty Rights Disclosures" (https://datatracker.ietf.org/ipr/2336/). The titl= e of the IPR disclosure is "Nokia Corporation's Statement about IPR relat= ed to RFC 6749.""); >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 --PhP57Q0hsruC2ENCk0T9Qk4JhVW0SItMq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEiLrAAoJEGhJURNOOiAtiL8H/RJSZdXuhJ13+Fp+CmoE3Aza ypM94TlM0EyNMf1zIN2W6DHOaV5VAAlOPLnNXkKTTt2T1oM2fsmGDsZnrJxSXEGG F1sHqjlPikot+N4d+ZgWW+PzW6pA1pzA7bcP2267+jp/0kRyXAHnSMg5XdhqTM2K iAEh7Q6iGF01MnXRJ97gvcJAaQJCgEhr0kzNE3x8yh0FgEgtq0nRa1gofhHGNe7g FKXs/anS5Zlt5As2ZlYnXcJ58Ez55Pn4pest/w7wuKiXJqlfv7J6+WiXWcyE7yzR MlPGYWp8txQXzeRj6fahpRNfpIkon9HeG3SOl08walRbL0J5sTMy1BibRQMRX7o= =n0EY -----END PGP SIGNATURE----- --PhP57Q0hsruC2ENCk0T9Qk4JhVW0SItMq-- From nobody Thu Sep 11 15:38:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FD71A0184 for ; Thu, 11 Sep 2014 15:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 70KUrPlmeWhe for ; Thu, 11 Sep 2014 15:38:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663BA1A0199 for ; Thu, 11 Sep 2014 15:38:46 -0700 (PDT) Received: from [192.168.10.163] ([167.220.25.81]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MUCTO-1Xs5qg0FPO-00QyMw; Fri, 12 Sep 2014 00:38:44 +0200 Message-ID: <54122470.2030209@gmx.net> Date: Fri, 12 Sep 2014 00:38:40 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John Bradley References: <541220B5.2000801@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fdlLUtRLbaFvkkkKqaWc4oEUL1OD9DEag" X-Provags-ID: V03:K0:Kio74hDItAojXOWIYE/FRkhwDp/fwets+2QTZ8QfDk+d50XlRdl QC9OEM4fZwcT8eutRF5GRo63R+EJMdImAF0xrs7ipDNjt0Ek1K3CnTRYEmiyBRqXpWY4nqo IevhGCjfgiWxvphaczfVNz/OwpWJotd0mDTY+7dBxEgPcXjwv+ny2yFqj/xiT52YwvFKrl+ Xx1k/OTgev3t7MeF1PGJA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_ms3qEFYX5456gTxLimBZKVk0ZU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fwd: IPR Disclosure: Nokia Corporation's Statement about IPR related to RFC 6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:38:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fdlLUtRLbaFvkkkKqaWc4oEUL1OD9DEag Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi John, don't misunderstand me: I am not planning to use our valuable OAuth WG time to go through the claims and to discuss them. Instead, I would like to point your attention to this IPR, to evaluate it within your company (with whatever fancy process you have), and to tell me at the upcoming IETF meeting whether there are concerns. Other IPR announcements have arrived before we finished the work on them and so it was a bit easier to take actions. We had that case a few times in the group. So far, there have not been concerns with any of the IPR declarations and we just continued our work as planned. Ciao Hannes On 09/12/2014 12:26 AM, John Bradley wrote: > Some large number of us would be roasted by our legal departments if we= looked at a patent. >=20 > Discussing the specifics of patents is not appropriate for a WG meeting= =2E >=20 > Someone from the IETF should look at the issue but not me. >=20 > John B. >=20 > On Sep 11, 2014, at 7:22 PM, Hannes Tschofenig wrote: >=20 >> Hi all, >> >> in private messages I have gotten questions about this IPR announcemen= t >> received in March 2014 and the potential implications on the core OAut= h >> 2.0 protocol. I was thinking about putting it on the agenda for the ne= xt >> IETF meeting. >> >> The feedback I am hoping to get is whether there is a concern about th= is >> IPR from those who have products and services based on OAuth. >> >> I want to know whether you see problems or not. If you have problems, >> maybe there are ways to engineer around it. >> >> Ciao >> Hannes >> >> PS: If someone has time to review the state of the art in 2009 I would= >> also like to chat with you. >> >> -------- Forwarded Message -------- >> Subject: IPR Disclosure: Nokia Corporation's Statement about IPR relat= ed >> to RFC 6749 >> Date: Fri, 28 Mar 2014 07:33:05 -0700 >> From: IETF Secretariat >> To: dick.hardt@gmail.com >> CC: stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, >> Hannes.Tschofenig@gmx.net, derek@ihtfp.com, oauth@ietf.org, >> ipr-announce@ietf.org >> >> >> Dear Dick Hardt: >> >> An IPR disclosure that pertains to your RFC entitled "The OAuth 2.0 >> Authorization Framework" (RFC6749) was submitted to the IETF Secretari= at on >> 2014-03-28 and has been posted on the "IETF Page of Intellectual >> Property Rights >> Disclosures" (https://datatracker.ietf.org/ipr/2336/). The title of th= e IPR >> disclosure is "Nokia Corporation's Statement about IPR related to RFC >> 6749.""); >> >> The IETF Secretariat >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --fdlLUtRLbaFvkkkKqaWc4oEUL1OD9DEag Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEiRxAAoJEGhJURNOOiAt9T4H+weFuOVtSa8rxHYBj11tDGWO LRNhKJHg4/G4vjDD4yblmp7wXXfb25eyjW576GRxMSYOwOUpgfyWWQZ0C18l46Ro e6P1E+Z2JGZZOsNxrR2uTH9snM6QfGAbrF6sUIfAc9FmvONnTN0Rg6WIL/zLe7hr FHRibEJVwan0k3I7hceVgU67LKhZ6EysRtjnijmUC4GDbhPLteF94IUPkOCZ6hfW qs70tLeLt1JuYsf9NdyJFHUg4d4RmeoSBwtg2mgK7yGmoeF8oKOnqmIiEDAMZvqX mZf+o/ZC/Byx1ok1PGH64ij77Om1fr4Vhl5LWKSNDXllMchmPRo/6ik1VNJGFaY= =ZCE5 -----END PGP SIGNATURE----- --fdlLUtRLbaFvkkkKqaWc4oEUL1OD9DEag-- From nobody Thu Sep 11 15:50:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423271A01EB for ; Thu, 11 Sep 2014 15:50:00 -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, SPF_PASS=-0.001] autolearn=ham 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 fPFAfmlAWFXH for ; Thu, 11 Sep 2014 15:49:58 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683F21A01E1 for ; Thu, 11 Sep 2014 15:49:58 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id el20so3796728lab.19 for ; Thu, 11 Sep 2014 15:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TyQHyBdbgw7HrCWEwi238wrReyNSCJr9PkdOrlASUdE=; b=k9whMixWDU8y0pM4UvWYnhuEf+8oo4ePWt62VjLrVR2imbXmasbMgIuzDJXycCnXvU ektmMwoxIO86jJ/BAa1j4X4eFD0GV78AxJnQHn8R+wnpx5kLUV4Rm6EwLJuVvDltuO+O Fy38KQDDHGekw6ZRYJxP2/2WmJHB3QgpbOpgL5L4qwSrvJGqAOx32/jVPROlZnVK+QX+ NpWKaahav/4q+28OMjmv48UwW57J5K7K4eEyjwgfTp3StDlCRCIfBB5AZEMO0xJ/ywbu eVn1qDc39R0pyY8LFY1Oe4F4HAPjjuwxWqbUoqLEIpInFjO4W7DVpcfNlOzHZvk8H1GV RIAw== MIME-Version: 1.0 X-Received: by 10.112.114.227 with SMTP id jj3mr4276005lbb.39.1410475796726; Thu, 11 Sep 2014 15:49:56 -0700 (PDT) Received: by 10.112.1.231 with HTTP; Thu, 11 Sep 2014 15:49:56 -0700 (PDT) In-Reply-To: <1a2eb1cb9138414c83c258a73f92e413@BLUPR03MB309.namprd03.prod.outlook.com> References: <54122280.1030609@gmx.net> <1a2eb1cb9138414c83c258a73f92e413@BLUPR03MB309.namprd03.prod.outlook.com> Date: Fri, 12 Sep 2014 07:49:56 +0900 Message-ID: From: Nat Sakimura To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a1135ed58d410dc0502d1fc9f Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6FRKd8kreqUCBR3vALL39lS-D9w Cc: Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:50:00 -0000 --001a1135ed58d410dc0502d1fc9f Content-Type: text/plain; charset=UTF-8 Add me, too. 2014-09-12 7:32 GMT+09:00 Anthony Nadalin : > Add me > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, September 11, 2014 3:30 PM > To: oauth@ietf.org > Cc: Derek Atkins > Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong? > > Hi all, > > at the last IETF meeting Mike gave a presentation about the > draft-hunt-oauth-v2-user-a4c and the conclusion following the discussion > was to discuss the problems that happen when OAuth gets used for > authentication. > > The goal of this effort is to document the problems in an informational > document. > > Conference calls could start in about 2 weeks and we would like to know > who would be interested to participate in such a discussion. > > Please drop us a private mail so that we can find suitable dates/times. > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1135ed58d410dc0502d1fc9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Add me, too.=C2=A0

2014-09-12 7:32 GMT+09:00 Anthony Nadalin <ton= ynad@microsoft.com>:
Add me=

-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To: oauth@ietf.org
Cc: Derek Atkins
Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong?

Hi all,

at the last IETF meeting Mike gave a presentation about the draft-hunt-oaut= h-v2-user-a4c and the conclusion following the discussion was to discuss th= e problems that happen when OAuth gets used for authentication.

The goal of this effort is to document the problems in an informational doc= ument.

Conference calls could start in about 2 weeks and we would like to know who= would be interested to participate in such a discussion.

Please drop us a private mail so that we can find suitable dates/times.

Ciao
Hannes & Derek

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



--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a1135ed58d410dc0502d1fc9f-- From nobody Thu Sep 11 16:00:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C881A020A for ; Thu, 11 Sep 2014 16:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 jaCCG9jH743u for ; Thu, 11 Sep 2014 16:00:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D7E1A0205 for ; Thu, 11 Sep 2014 16:00:33 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8BN0TSg004907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Sep 2014 23:00:30 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8BN0SNB025778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Sep 2014 23:00:29 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8BN0SOS025765; Thu, 11 Sep 2014 23:00:28 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Sep 2014 16:00:28 -0700 References: <54122280.1030609@gmx.net> <1a2eb1cb9138414c83c258a73f92e413@BLUPR03MB309.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-E8AB7288-6D26-4E8E-B38D-5597B87C9AA4 Content-Transfer-Encoding: 7bit Message-Id: <69A89CF1-9A1A-4F3A-8768-8FD176E53BEE@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Thu, 11 Sep 2014 16:00:27 -0700 To: Nat Sakimura X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QCoO2JGAC4uOXgpAAp9GuXYQp5Y Cc: Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 23:00:35 -0000 --Apple-Mail-E8AB7288-6D26-4E8E-B38D-5597B87C9AA4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Me too.=20 Phil > On Sep 11, 2014, at 15:49, Nat Sakimura wrote: >=20 > Add me, too.=20 >=20 > 2014-09-12 7:32 GMT+09:00 Anthony Nadalin : >> Add me >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g >> Sent: Thursday, September 11, 2014 3:30 PM >> To: oauth@ietf.org >> Cc: Derek Atkins >> Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong? >>=20 >> Hi all, >>=20 >> at the last IETF meeting Mike gave a presentation about the draft-hunt-oa= uth-v2-user-a4c and the conclusion following the discussion was to discuss t= he problems that happen when OAuth gets used for authentication. >>=20 >> The goal of this effort is to document the problems in an informational d= ocument. >>=20 >> Conference calls could start in about 2 weeks and we would like to know w= ho would be interested to participate in such a discussion. >>=20 >> Please drop us a private mail so that we can find suitable dates/times. >>=20 >> Ciao >> Hannes & Derek >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-E8AB7288-6D26-4E8E-B38D-5597B87C9AA4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Me too. 

Phil

On Sep 11, 2014, at 15:49, Nat Sakimura <sakimura@gmail.com> wrote:

Add me, too. 

2014-09-12 7:32 GMT+09:00 Anthony Nadalin <tonynad@microsoft.com>:
Add me

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To: oauth@ietf.org
Cc: Derek Atkins
Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong?

Hi all,

at the last IETF meeting Mike gave a presentation about the draft-hunt-oauth-v2-user-a4c and the conclusion following the discussion was to discuss the problems that happen when OAuth gets used for authentication.

The goal of this effort is to document the problems in an informational document.

Conference calls could start in about 2 weeks and we would like to know who would be interested to participate in such a discussion.

Please drop us a private mail so that we can find suitable dates/times.

Ciao
Hannes & Derek

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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--Apple-Mail-E8AB7288-6D26-4E8E-B38D-5597B87C9AA4-- From nobody Thu Sep 11 16:15:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0E11A02A3 for ; Thu, 11 Sep 2014 16:15:55 -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, SPF_PASS=-0.001] autolearn=ham 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 5qnjSra4OKU2 for ; Thu, 11 Sep 2014 16:15:53 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DD31A01E8 for ; Thu, 11 Sep 2014 16:15:52 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id pv20so3333312lab.36 for ; Thu, 11 Sep 2014 16:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5EvBa9y8W9IzkxkZ4aujnu0qddNKe8a/MsLKshU9hdk=; b=Vy9NYqEKcClCbw39rVCxyUoFx6v8N2iwAl/PVv7tFdI7vkLnH6BDZlhDImpQXFG5E2 ZMhW95IjT5BNDJpLvfRqlxuBZmCPCkhqwrP+uoq6am5DDAEG0/6EaPEhPblHDJXthW9r 28Z1I4W7dhmEPqpUZri4w81pMHOI9BLWm+xqxCqNbxsCMWNY4htKDgmrjo35VYzoKuRu 94slu4755Pc3fKvmhTlLPU3dkZ1c11aMOr13JSihsAkQpOUSkEhfZa0q0k1Z+M4pOl/h KFEqIjrvlJYwly+ujf7aK2RuyTTR2vIwZ8wYfpTRHqB+Vs0vS5i/agjJHm85QLl0C3kc dIPQ== MIME-Version: 1.0 X-Received: by 10.152.20.1 with SMTP id j1mr4530603lae.57.1410477351259; Thu, 11 Sep 2014 16:15:51 -0700 (PDT) Received: by 10.25.148.143 with HTTP; Thu, 11 Sep 2014 16:15:51 -0700 (PDT) Received: by 10.25.148.143 with HTTP; Thu, 11 Sep 2014 16:15:51 -0700 (PDT) In-Reply-To: <597105CD-0F67-437B-89E7-EE9BC3DDB910@oracle.com> References: <5410E3AF.3030806@gmx.net> <9E856DCC-79F4-421B-A6EB-1438115843CB@mitre.org> <3AD141D9-5673-4945-9DC9-E95D7D35EF33@ve7jtb.com> <597105CD-0F67-437B-89E7-EE9BC3DDB910@oracle.com> Date: Fri, 12 Sep 2014 01:15:51 +0200 Message-ID: From: Maciej Machulak To: Phil Hunt Content-Type: multipart/alternative; boundary=089e013d1d4c7c549e0502d2590d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/i7yqu2wCOrDsfUBgPMTIyG4xf68 Cc: oauth WG Subject: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 23:15:56 -0000 --089e013d1d4c7c549e0502d2590d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 --=20 Cheers, Maciej (sent from my tablet) On Sep 11, 2014 5:07 PM, "Phil Hunt" wrote: > +1. Experimental seems best here. > > Phil > > > On Sep 11, 2014, at 9:03, "Richer, Justin P." wrote= : > > > > +1 > > > > That was the key line that I took from the guidelines as well and this > was my understanding of the discussion in Toronto. > > > > -- Justin > > > >> On Sep 11, 2014, at 12:02 PM, John Bradley wrote: > >> > >> I think this fits. > >> > >> =E2=80=A2 If the IETF may publish something based on this on the st= andards > track once we know how well this one works, it's Experimental. This is th= e > typical case of not being able to decide which protocol is "better" befor= e > we have experience of dealing with them from a stable specification. Case > in point: "PGM Reliable Transport Protocol Specification" (RFC 3208) > >> > >> If we publish something it may or may not look like the current spec > but getting some experience with the current spec will inform that decisi= on. > >> > >> John B. > >>> On Sep 11, 2014, at 12:55 PM, Phil Hunt wrote: > >>> > >>> Interesting. The definitions in that don't correspond with what ADs > and other groups are doing. > >>> > >>> I heard httpbis using experimental as a placeholder for a draft that > didn't have full consensus to bring back later. > >>> > >>> That was the feel I had in Toronto-that we weren't done but it was > time to publish something. > >>> > >>> Reading the actual definition i would say neither fits. Ugh. > >>> > >>> Phil > >>> > >>>> On Sep 11, 2014, at 8:01, "Richer, Justin P." > wrote: > >>>> > >>>> According to the guidelines here: > >>>> > >>>> https://www.ietf.org/iesg/informational-vs-experimental.html > >>>> > >>>> And the discussion in Toronto, it's clearly experimental. > >>>> > >>>> -- Justin > >>>> > >>>>> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin > wrote: > >>>>> > >>>>> Is "experimental" the correct classification? Maybe "informational" > is more appropriate as both of these were discussed. > >>>>> > >>>>> -----Original Message----- > >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > >>>>> Sent: Wednesday, September 10, 2014 4:50 PM > >>>>> To: oauth@ietf.org > >>>>> Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol= : > Next Steps? > >>>>> > >>>>> Hi all, > >>>>> > >>>>> in response to the discussions at the last IETF meeting the authors > of the "Dynamic Client Registration Management Protocol" > >>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 > have changed the document type to "Experimental". > >>>>> > >>>>> We need to make a decision about the next steps for the document an= d > we see the following options: > >>>>> > >>>>> a) Publish it as an experimental RFC > >>>>> > >>>>> b) Remove it from the working group and ask an AD to shepherd it > >>>>> > >>>>> c) Remove it from the working group and let the authors publish it > via the independent submission track. > >>>>> > >>>>> In any case it would be nice to let folks play around with it and > then, after some time, come back to determine whether there is enough > interest to produce a standard. > >>>>> > >>>>> Please let us know what you think! > >>>>> > >>>>> Ciao > >>>>> Hannes & Derek > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >>> _______________________________________________ > >>> 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 > --089e013d1d4c7c549e0502d2590d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1

--
Cheers, Maciej (sent from my tablet)

On Sep 11, 2014 5:07 PM, "Phil Hunt" &= lt;phil.hunt@oracle.com> wro= te:
+1. Experimental= seems best here.

Phil

> On Sep 11, 2014, at 9:03, "Richer, Justin P." <jricher@mitre.org> wrote:
>
> +1
>
> That was the key line that I took from the guidelines as well and this= was my understanding of the discussion in Toronto.
>
> -- Justin
>
>> On Sep 11, 2014, at 12:02 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>
>> I think this fits.
>>
>>=C2=A0 =C2=A0 =E2=80=A2 If the IETF may publish something based on = this on the standards track once we know how well this one works, it's = Experimental. This is the typical case of not being able to decide which pr= otocol is "better" before we have experience of dealing with them= from a stable specification. Case in point: "PGM Reliable Transport P= rotocol Specification" (RFC 3208)
>>
>> If we publish something it may or may not look like the current sp= ec but getting some experience with the current spec will inform that decis= ion.
>>
>> John B.
>>> On Sep 11, 2014, at 12:55 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>>
>>> Interesting. The definitions in that don't correspond with= what ADs and other groups are doing.
>>>
>>> I heard httpbis using experimental as a placeholder for a draf= t that didn't have full consensus to bring back later.
>>>
>>> That was the feel I had in Toronto-that we weren't done bu= t it was time to publish something.
>>>
>>> Reading the actual definition i would say neither fits. Ugh. >>>
>>> Phil
>>>
>>>> On Sep 11, 2014, at 8:01, "Richer, Justin P." &l= t;jricher@mitre.org> wrote:
>>>>
>>>> According to the guidelines here:
>>>>
>>>> https://www.ietf.org/iesg/informational-vs= -experimental.html
>>>>
>>>> And the discussion in Toronto, it's clearly experiment= al.
>>>>
>>>> -- Justin
>>>>
>>>>> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin <tonynad@microsoft.com> wrote: >>>>>
>>>>> Is "experimental" the correct classification= ? Maybe "informational" is more appropriate as both of these were= discussed.
>>>>>
>>>>> -----Original Message-----
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>>>>> Sent: Wednesday, September 10, 2014 4:50 PM
>>>>> To: oauth@ietf.org
>>>>> Subject: [OAUTH-WG] Dynamic Client Registration Manage= ment Protocol: Next Steps?
>>>>>
>>>>> Hi all,
>>>>>
>>>>> in response to the discussions at the last IETF meetin= g the authors of the "Dynamic Client Registration Management Protocol&= quot;
>>>>> http://tools.ietf.org/html/draft-= ietf-oauth-dyn-reg-management-05 have changed the document type to &quo= t;Experimental".
>>>>>
>>>>> We need to make a decision about the next steps for th= e document and we see the following options:
>>>>>
>>>>> a) Publish it as an experimental RFC
>>>>>
>>>>> b) Remove it from the working group and ask an AD to s= hepherd it
>>>>>
>>>>> c) Remove it from the working group and let the author= s publish it via the independent submission track.
>>>>>
>>>>> In any case it would be nice to let folks play around = with it and then, after some time, come back to determine whether there is = enough interest to produce a standard.
>>>>>
>>>>> Please let us know what you think!
>>>>>
>>>>> Ciao
>>>>> Hannes & Derek
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--089e013d1d4c7c549e0502d2590d-- From nobody Thu Sep 11 16:31:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DC71A0176 for ; Thu, 11 Sep 2014 16:30:59 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 XQm1_fgNwxwb for ; Thu, 11 Sep 2014 16:30:57 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9231A0164 for ; Thu, 11 Sep 2014 16:30:57 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id a108so8099939qge.14 for ; Thu, 11 Sep 2014 16:30:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=VxJ461wNlArWHfetUsD5rW+aSZ+O312dYJRXJKFvcWk=; b=VIA8VImyCqKtn3/HoRxSqSWK/Ra4P+gWLdJR6PahqwbThcNnULTuOPnoGK0KqbdgCf UxgfO97cq9MVsd8gvgd91eWtG0HIyvhImHGNBC+H63g0TeJIDOHv79NcmdDfmPP/vSQX gLSj7F5jbsC97j8KiK/e8L3ANjPwMN79hPiv6ryKMCI7PovTy1idLClJhV5r5rIDsTvI bFDPx1CZ/yc5ys/YlH4/eVg7FNPy9nZUEHGXbZnkC+yApYWHn/nnYnb+PqpD/EAmJBFG Qxe2jPe5zHrf3l+5cdiQ9+IxVxROQEjLJjcSd/ps9H1oVieB/roPoe5yu1b5O+GkjMFT 2MXQ== X-Gm-Message-State: ALoCoQkb61dPLqXjNsM/bXaWooaZSes8lOIIqV2uVJtycQLW9RbY+DDYYXrFg1z2ShIhsJGpl0XN X-Received: by 10.224.131.7 with SMTP id v7mr3434904qas.5.1410478255987; Thu, 11 Sep 2014 16:30:55 -0700 (PDT) Received: from [10.236.53.63] ([201.220.243.15]) by mx.google.com with ESMTPSA id x6sm1771259qas.27.2014.09.11.16.30.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 16:30:54 -0700 (PDT) References: <54122280.1030609@gmx.net> <1a2eb1cb9138414c83c258a73f92e413@BLUPR03MB309.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-A9896C7B-9325-4011-9DFF-92BF8D80F023; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <38674129-C06F-4C72-86A1-A942E7D71325@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Thu, 11 Sep 2014 20:30:50 -0300 To: Nat Sakimura Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/cgLlug6uqAc6akAWv8odBEBhurY Cc: Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 23:30:59 -0000 --Apple-Mail-A9896C7B-9325-4011-9DFF-92BF8D80F023 Content-Type: multipart/alternative; boundary=Apple-Mail-CCCCA25C-3B16-49E4-A512-CC371AE787A3 Content-Transfer-Encoding: 7bit --Apple-Mail-CCCCA25C-3B16-49E4-A512-CC371AE787A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable And me=20 Sent from my iPhone > On Sep 11, 2014, at 7:49 PM, Nat Sakimura wrote: >=20 > Add me, too.=20 >=20 > 2014-09-12 7:32 GMT+09:00 Anthony Nadalin : >> Add me >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g >> Sent: Thursday, September 11, 2014 3:30 PM >> To: oauth@ietf.org >> Cc: Derek Atkins >> Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong? >>=20 >> Hi all, >>=20 >> at the last IETF meeting Mike gave a presentation about the draft-hunt-oa= uth-v2-user-a4c and the conclusion following the discussion was to discuss t= he problems that happen when OAuth gets used for authentication. >>=20 >> The goal of this effort is to document the problems in an informational d= ocument. >>=20 >> Conference calls could start in about 2 weeks and we would like to know w= ho would be interested to participate in such a discussion. >>=20 >> Please drop us a private mail so that we can find suitable dates/times. >>=20 >> Ciao >> Hannes & Derek >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-CCCCA25C-3B16-49E4-A512-CC371AE787A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
And me 

Sent from my iPhone

On Sep 11, 2014, at 7:49 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Add me, too. 

2014-09-12 7:32 GMT+09:00 Anthony Nadalin <tonynad@microsoft.com>:
Add me

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To: oauth@ietf.org
Cc: Derek Atkins
Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong?

Hi all,

at the last IETF meeting Mike gave a presentation about the draft-hunt-oauth-v2-user-a4c and the conclusion following the discussion was to discuss the problems that happen when OAuth gets used for authentication.

The goal of this effort is to document the problems in an informational document.

Conference calls could start in about 2 weeks and we would like to know who would be interested to participate in such a discussion.

Please drop us a private mail so that we can find suitable dates/times.

Ciao
Hannes & Derek

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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--Apple-Mail-CCCCA25C-3B16-49E4-A512-CC371AE787A3-- --Apple-Mail-A9896C7B-9325-4011-9DFF-92BF8D80F023 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwOTExMjMzMDUxWjAjBgkqhkiG9w0BCQQxFgQURLQjWfhL5UEYvGib JasDkpMg/JIwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAAkUxQZyvG+yQ2OETpBwxrz5yYGSUXrEpmq8bLxjf+G5u9loA EiZ7QhBBVoB9R6faNWjInAje8wlTtJmDAsysR2AKGomIopU/b2Mkt7FiDU8hnONhYzmsDM+GcBjr ouIA+1uJd7NfIJf6PPOtDfxdXX50985k3SscZJRdEpLW0t2YUizn92o+RV3XGK0EvHJAMjx6zeXd U1W1pUf0ksrap9wBKGBKZ+W5bLDI45x/EIdfLOq0qisip35Ch+s92gkiBCfK1Fn0kc71y52El4UR gM7fSNViY0IZ+4xzqZPZHI2PP5Y8M4+9wDLU1loIr+waXhHRVTRblQUYAizrLXJ/NAAAAAAAAA== --Apple-Mail-A9896C7B-9325-4011-9DFF-92BF8D80F023-- From nobody Thu Sep 11 18:01:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0CA1A0306 for ; Thu, 11 Sep 2014 18:01:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 cLSIuJV1RqZD for ; Thu, 11 Sep 2014 18:01:22 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4181A0263 for ; Thu, 11 Sep 2014 18:01:21 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id ey11so24825pad.34 for ; Thu, 11 Sep 2014 18:01:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version:content-type; bh=PB736wQSXEPSpxN8LRdbbc/ddIL0dMRg15KmW77vDjg=; b=aNx6sUYDO0ocfFTIyMQ6lkYmOsLY1q/4InyzAMgxRKHevyEucIMyhNPOyAU2xT6WuM G9pkD+q6A2BteyYLLNdhVHp3pQEBmnoK9rDeDPcbopbyX9ZdJV8gXassk6fhtCVOvVGI dWWPX+fOIJZQpL9nqOqbL1szT+Rk2vyCUPU119KEbrYLOzdsXyJseo13Bm2lWsHgTUgX yk3R/VBNZZTMMMKm3J6qoWfVRX0nG8RTHw8QRj3KGql7n5TbamcRT2VFtfU6j6dFJZfv XripYqXpTmLbGxr2+Bu25QIqgE/Ab0r26tgHyvg1DHIQgG6m7k3wFWOqXfiAIw2CJ1oX Xilw== X-Gm-Message-State: ALoCoQkKTVEfA5qAFgPZ/c0CQsZhFBcQcBremooZHUqEB9SwH+GEwEM6LX/Xv6TjCFeIVNV0pvaD X-Received: by 10.66.123.75 with SMTP id ly11mr6579484pab.82.1410483681526; Thu, 11 Sep 2014 18:01:21 -0700 (PDT) Received: from [10.0.0.77] (CPE-121-216-191-149.lnse2.ken.bigpond.net.au. [121.216.191.149]) by mx.google.com with ESMTPSA id j13sm2174748pbq.42.2014.09.11.18.01.18 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Sep 2014 18:01:20 -0700 (PDT) From: "Gil Kirkpatrick" To: "John Bradley" , "Nat Sakimura" Date: Fri, 12 Sep 2014 01:00:58 +0000 Message-Id: In-Reply-To: <38674129-C06F-4C72-86A1-A942E7D71325@ve7jtb.com> User-Agent: eM_Client/6.0.20648.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBF002DDE6-9A46-4BCC-92C1-ACBE197B4ADC" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KhntZBdkodrYIPbpWvIJbSgUOPA Cc: Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Gil Kirkpatrick List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 01:01:24 -0000 --------=_MBF002DDE6-9A46-4BCC-92C1-ACBE197B4ADC Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 for me. ------ Original Message ------ From: "John Bradley" To: "Nat Sakimura" Cc: "Derek Atkins" ; "oauth@ietf.org" Sent: 12/09/2014 9:30:50 AM Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? >And me > >Sent from my iPhone > >On Sep 11, 2014, at 7:49 PM, Nat Sakimura wrote: > >>Add me, too. >> >>2014-09-12 7:32 GMT+09:00 Anthony Nadalin : >>>Add me >>> >>>-----Original Message----- >>>From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes=20 >>>Tschofenig >>>Sent: Thursday, September 11, 2014 3:30 PM >>>To: oauth@ietf.org >>>Cc: Derek Atkins >>>Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong? >>> >>>Hi all, >>> >>>at the last IETF meeting Mike gave a presentation about the=20 >>>draft-hunt-oauth-v2-user-a4c and the conclusion following the=20 >>>discussion was to discuss the problems that happen when OAuth gets=20 >>>used for authentication. >>> >>>The goal of this effort is to document the problems in an=20 >>>informational document. >>> >>>Conference calls could start in about 2 weeks and we would like to=20 >>>know who would be interested to participate in such a discussion. >>> >>>Please drop us a private mail so that we can find suitable=20 >>>dates/times. >>> >>>Ciao >>>Hannes & Derek >>> >>>_______________________________________________ >>>OAuth mailing list >>>OAuth@ietf.org >>>https://www.ietf.org/mailman/listinfo/oauth >> >> >> >>-- >>Nat Sakimura (=3Dnat) >>Chairman, OpenID Foundation >>http://nat.sakimura.org/ >>@_nat_en >>_______________________________________________ >>OAuth mailing list >>OAuth@ietf.org >>https://www.ietf.org/mailman/listinfo/oauth --------=_MBF002DDE6-9A46-4BCC-92C1-ACBE197B4ADC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 for me.
 
------ Original Message ------
From: "John Bradley" <ve7jtb@v= e7jtb.com>
To: "Nat Sakimura" <sakimura@= gmail.com>
Cc: "Derek Atkins" <derek@ihtfp.= com>; "oauth@ietf.org" <oauth@i= etf.org>
Sent: 12/09/2014 9:30:50 AM
Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong?=
 
And me 

Sent from my iPhone

On Sep 11, 2014, at 7:49 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Add me, too. 

2014-09-12 7:32 GMT+09:00 Anthony Nadalin <tonynad@microsoft.c= om>:
Add me

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Beha= lf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To= : oauth@ietf.org
Cc: Derek Atkins<= BR>Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong?
Hi all,

at the last IETF meeting Mike gave a presentation about= the draft-hunt-oauth-v2-user-a4c and the conclusion following the discussi= on was to discuss the problems that happen when OAuth gets used for authent= ication.

The goal of this effort is to document the problems in an= informational document.

Conference calls could start in about 2 = weeks and we would like to know who would be interested to participate in= such a discussion.

Please drop us a private mail so that we can = find suitable dates/times.

Ciao
Hannes & Derek

<= /DIV>_______________________________________________
OAuth mailing list<= BR>OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth



--
Nat Sakimura (=3Dnat)=20
Chairman, OpenID Foundation
ht= tp://nat.sakimura.org/
@_nat_en
_______________________________________________
= OAuth mailing list
OAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= /BLOCKQUOTE>
--------=_MBF002DDE6-9A46-4BCC-92C1-ACBE197B4ADC-- From nobody Thu Sep 11 23:50:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EEA1A065E for ; Thu, 11 Sep 2014 23:50:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PVe-ARLzftHb for ; Thu, 11 Sep 2014 23:49:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0067.outbound.protection.outlook.com [207.46.100.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED611A0481 for ; Thu, 11 Sep 2014 23:49:59 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 12 Sep 2014 06:49:57 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.227]) with mapi id 15.00.1024.012; Fri, 12 Sep 2014 06:49:56 +0000 From: Antonio Sanso To: Gil Kirkpatrick Thread-Topic: [OAUTH-WG] OAuth & Authentication: What can go wrong? Thread-Index: AQHPzhAmMHQIk99MzUygvz3fbiy7mZv8hE2AgAAE/ACAAAtuAIAAGS8AgABhmAA= Date: Fri, 12 Sep 2014 06:49:56 +0000 Message-ID: References: In-Reply-To: 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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377424004)(189002)(53754006)(13464003)(479174003)(24454002)(199003)(377454003)(15202345003)(106116001)(16236675004)(106356001)(19617315012)(77096002)(105586002)(90102001)(50986999)(76176999)(54356999)(87936001)(36756003)(85306004)(101416001)(99396002)(95666004)(99286002)(77982001)(15975445006)(79102001)(82746002)(76482001)(33656002)(4396001)(110136001)(19580395003)(83322001)(19580405001)(80022001)(66066001)(20776003)(21056001)(86362001)(64706001)(46102001)(81342001)(92566001)(81542001)(92726001)(97736003)(2656002)(85852003)(83072002)(74662001)(74502001)(107046002)(31966008)(83716003)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CCB56177EA8F41D4A21E9A10EF27E977adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/282s7ujBS2MNyb9WVcGGpo7L33c Cc: Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 06:50:02 -0000 --_000_CCB56177EA8F41D4A21E9A10EF27E977adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I would like to attend as well =85 regards antonio On Sep 12, 2014, at 3:00 AM, Gil Kirkpatrick > wrote: +1 for me. ------ Original Message ------ From: "John Bradley" > To: "Nat Sakimura" > Cc: "Derek Atkins" >; "oauth@ietf.o= rg" > Sent: 12/09/2014 9:30:50 AM Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? And me Sent from my iPhone On Sep 11, 2014, at 7:49 PM, Nat Sakimura > wrote: Add me, too. 2014-09-12 7:32 GMT+09:00 Anthony Nadalin >: Add me -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of Hannes Tschofenig Sent: Thursday, September 11, 2014 3:30 PM To: oauth@ietf.org Cc: Derek Atkins Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong? Hi all, at the last IETF meeting Mike gave a presentation about the draft-hunt-oaut= h-v2-user-a4c and the conclusion following the discussion was to discuss th= e problems that happen when OAuth gets used for authentication. The goal of this effort is to document the problems in an informational doc= ument. Conference calls could start in about 2 weeks and we would like to know who= would be interested to participate in such a discussion. Please drop us a private mail so that we can find suitable dates/times. Ciao Hannes & Derek _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ 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 --_000_CCB56177EA8F41D4A21E9A10EF27E977adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I would like to attend as well =85 

regards

antonio

On Sep 12, 2014, at 3:00 AM, Gil Kirkpatrick <gil.kirkpatrick@viewds.com> wrote:

+1 for me.
 
------ Original Message ------
From: "John Bradley" <ve7jtb@ve7jtb.com>
To: "Nat Sakimura" <sakimura@gmail.com>
Cc: "Derek Atkins" <de= rek@ihtfp.com>; "oauth@ietf.o= rg" <oauth@ietf.org>
Sent: 12/09/2014 9:30:50 AM
Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong?=
 
And me 

Sent from my iPhone

On Sep 11, 2014, at 7:49 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Add me, too. 

2014-09-12 7:32 GMT+09:00 Anthony Nadalin <tonynad@microsoft.com>:
Add me

-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To: oauth@ietf.org
Cc: Derek Atkins
Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong?

Hi all,

at the last IETF meeting Mike gave a presentation about the draft-hunt-oaut= h-v2-user-a4c and the conclusion following the discussion was to discuss th= e problems that happen when OAuth gets used for authentication.

The goal of this effort is to document the problems in an informational doc= ument.

Conference calls could start in about 2 weeks and we would like to know who= would be interested to participate in such a discussion.

Please drop us a private mail so that we can find suitable dates/times.

Ciao
Hannes & Derek

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



-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_CCB56177EA8F41D4A21E9A10EF27E977adobecom_-- From nobody Thu Sep 11 23:50:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA411A064F for ; Thu, 11 Sep 2014 23:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 JQ-xtshM-UE1 for ; Thu, 11 Sep 2014 23:50:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7C41A0584 for ; Thu, 11 Sep 2014 23:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13957; q=dns/txt; s=iport; t=1410504653; x=1411714253; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OIaf4lACs9ZUMuno5RnNN4Q9rfwcXkZq271gznX8YjY=; b=a6MsBoOX6qkmEzjRJUkBt5hH7gY6G7YNhBPLV+TBxJbhhlESRI5JdKL7 Y/g33V+TgcSW8ZbW8APXP84aZeUItRtR9BwlE0xvDT4jrUnGEhnfCOnbh rbfI1USA+zNmffH+Ogcvn0rFxvc66CiJpDefYInKpSLkcnubp3Q6Kb8tK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFALaWElStJV2Y/2dsb2JhbABggkdGU1cExm+BXwEJh04BgQ0WeIQDAQEBBAEBASo7BgsMBAIBCA4DBAEBCx0HIQYLFAkIAgQBDQUIiCYDEQ23DA2GfgEXjSCBXAEBHi0EBgEGA4MmgR0FhQyKKYFuKIQ1hHORDoY9g2FsgQ85gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,511,1406592000"; d="scan'208,217";a="354643907" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 12 Sep 2014 06:50:51 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8C6opcl003190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 06:50:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 01:50:51 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Antonio Sanso , Gil Kirkpatrick Thread-Topic: [OAUTH-WG] OAuth & Authentication: What can go wrong? Thread-Index: AQHPzhALLE/wPPZ6HkaBxbovIenGypv82B+AgAAE/ACAAAtuAIAAGS8AgABhgAD//6xeoA== Date: Fri, 12 Sep 2014 06:50:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2832813F@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.127.220] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2832813Fxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SvjPLafit3UWoWsp37KeJ3v2W7s Cc: Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 06:50:55 -0000 --_000_913383AAA69FF945B8F946018B75898A2832813Fxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And me. -Tiru From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Antonio Sanso Sent: Friday, September 12, 2014 12:20 PM To: Gil Kirkpatrick Cc: Derek Atkins; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? I would like to attend as well ... regards antonio On Sep 12, 2014, at 3:00 AM, Gil Kirkpatrick > wrote: +1 for me. ------ Original Message ------ From: "John Bradley" > To: "Nat Sakimura" > Cc: "Derek Atkins" >; "oauth@ietf.o= rg" > Sent: 12/09/2014 9:30:50 AM Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? And me Sent from my iPhone On Sep 11, 2014, at 7:49 PM, Nat Sakimura > wrote: Add me, too. 2014-09-12 7:32 GMT+09:00 Anthony Nadalin >: Add me -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of Hannes Tschofenig Sent: Thursday, September 11, 2014 3:30 PM To: oauth@ietf.org Cc: Derek Atkins Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong? Hi all, at the last IETF meeting Mike gave a presentation about the draft-hunt-oaut= h-v2-user-a4c and the conclusion following the discussion was to discuss th= e problems that happen when OAuth gets used for authentication. The goal of this effort is to document the problems in an informational doc= ument. Conference calls could start in about 2 weeks and we would like to know who= would be interested to participate in such a discussion. Please drop us a private mail so that we can find suitable dates/times. Ciao Hannes & Derek _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ 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 --_000_913383AAA69FF945B8F946018B75898A2832813Fxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And me.=

 <= /p>

-Tiru

 <= /p>

From: OAuth [m= ailto:oauth-bounces@ietf.org] On Behalf Of Antonio Sanso
Sent: Friday, September 12, 2014 12:20 PM
To: Gil Kirkpatrick
Cc: Derek Atkins; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wron= g?

 

I would like to attend as well … 

 

regards

 

antonio

 

On Sep 12, 2014, at 3:00 AM, Gil Kirkpatrick <gil.kirkpatrick@viewds.com&g= t; wrote:



+1 for me.

 

------ Original Message ------

From: "John Bradley" <ve7jtb@ve7jtb.com>

To: "Nat Sakimura" <sakimura@gmail.com>

Cc: "Derek Atkins" <derek@ihtfp.com>; "oauth@ietf.org" <oauth@iet= f.org>

Sent: 12/09/2014 9:30:50 AM

Subject: Re: [OAUTH-WG] OAuth & Authentication: Wha= t can go wrong?

 

And me 

Sent from my iPhone


On Sep 11, 2014, at 7:49 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Add me, too. 

 

2014-09-12 7:32 GMT+09:00 Anthony Nadalin <tonynad@microsoft.com>:

Add me


-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 11, 2014 3:30 PM
To: oauth@ietf.org
Cc: Derek Atkins
Subject: [OAUTH-WG] OAuth & Authentication: What can go wrong?

Hi all,

at the last IETF meeting Mike gave a presentation about the draft-hunt-oaut= h-v2-user-a4c and the conclusion following the discussion was to discuss th= e problems that happen when OAuth gets used for authentication.

The goal of this effort is to document the problems in an informational doc= ument.

Conference calls could start in about 2 weeks and we would like to know who= would be interested to participate in such a discussion.

Please drop us a private mail so that we can find suitable dates/times.

Ciao
Hannes & Derek

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



 

--  Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

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

 

--_000_913383AAA69FF945B8F946018B75898A2832813Fxmbrcdx10ciscoc_-- From nobody Fri Sep 12 00:05:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536611A0662 for ; Fri, 12 Sep 2014 00:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 fSg1OEGMsnJr for ; Fri, 12 Sep 2014 00:05:52 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6184B1A0574 for ; Fri, 12 Sep 2014 00:05:51 -0700 (PDT) Received: from [88.128.80.141] (helo=[10.227.187.73]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1XSKvS-0000pA-0s; Fri, 12 Sep 2014 09:05:46 +0200 Date: Fri, 12 Sep 2014 09:05:41 +0200 Message-ID: Importance: normal From: Torsten Lodderstedt To: "Tirumaleswar Reddy (tireddy)" , Antonio Sanso , Gil Kirkpatrick MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_865368721331240" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uLvyrvWhmriDFBGidKcZKTLLr-4 Cc: Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Authentication: What can go wrong? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 07:05:54 -0000 ----_com.android.email_865368721331240 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 bWUgdG9vCgo8ZGl2Pi0tLS0tLS0tIFVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodCAtLS0tLS0tLTwv ZGl2PjxkaXY+Vm9uOiAiVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSIgPHRpcmVkZHlAY2lz Y28uY29tPiA8L2Rpdj48ZGl2PkRhdHVtOjEyLjA5LjIwMTQgIDA4OjUwICAoR01UKzAxOjAwKSA8 L2Rpdj48ZGl2PkFuOiBBbnRvbmlvIFNhbnNvIDxhc2Fuc29AYWRvYmUuY29tPiwgR2lsIEtpcmtw YXRyaWNrIDxnaWwua2lya3BhdHJpY2tAdmlld2RzLmNvbT4gPC9kaXY+PGRpdj5DYzogRGVyZWsg QXRraW5zIDxkZXJla0BpaHRmcC5jb20+LCBvYXV0aEBpZXRmLm9yZyA8L2Rpdj48ZGl2PkJldHJl ZmY6IFJlOiBbT0FVVEgtV0ddIE9BdXRoICYgQXV0aGVudGljYXRpb246IFdoYXQgY2FuIGdvIHdy b25nPyA8L2Rpdj48ZGl2Pgo8L2Rpdj5BbmQgbWUuCiAKLVRpcnUKIApGcm9tOiBPQXV0aCBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbnRvbmlvIFNhbnNvClNl bnQ6IEZyaWRheSwgU2VwdGVtYmVyIDEyLCAyMDE0IDEyOjIwIFBNClRvOiBHaWwgS2lya3BhdHJp Y2sKQ2M6IERlcmVrIEF0a2luczsgb2F1dGhAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFtPQVVUSC1X R10gT0F1dGggJiBBdXRoZW50aWNhdGlvbjogV2hhdCBjYW4gZ28gd3Jvbmc/CiAKSSB3b3VsZCBs aWtlIHRvIGF0dGVuZCBhcyB3ZWxsIOKApiAKIApyZWdhcmRzCiAKYW50b25pbwogCk9uIFNlcCAx MiwgMjAxNCwgYXQgMzowMCBBTSwgR2lsIEtpcmtwYXRyaWNrIDxnaWwua2lya3BhdHJpY2tAdmll d2RzLmNvbT4gd3JvdGU6CgoKKzEgZm9yIG1lLgogCi0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tLQpGcm9tOiAiSm9obiBCcmFkbGV5IiA8dmU3anRiQHZlN2p0Yi5jb20+ClRvOiAiTmF0IFNh a2ltdXJhIiA8c2FraW11cmFAZ21haWwuY29tPgpDYzogIkRlcmVrIEF0a2lucyIgPGRlcmVrQGlo dGZwLmNvbT47ICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPgpTZW50OiAxMi8wOS8y MDE0IDk6MzA6NTAgQU0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggJiBBdXRoZW50aWNh dGlvbjogV2hhdCBjYW4gZ28gd3Jvbmc/CiAKQW5kIG1lIAoKU2VudCBmcm9tIG15IGlQaG9uZQoK T24gU2VwIDExLCAyMDE0LCBhdCA3OjQ5IFBNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWls LmNvbT4gd3JvdGU6CgpBZGQgbWUsIHRvby4gCiAKMjAxNC0wOS0xMiA3OjMyIEdNVCswOTowMCBB bnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT46CkFkZCBtZQoKLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcKU2VudDogVGh1cnNkYXksIFNlcHRl bWJlciAxMSwgMjAxNCAzOjMwIFBNClRvOiBvYXV0aEBpZXRmLm9yZwpDYzogRGVyZWsgQXRraW5z ClN1YmplY3Q6IFtPQVVUSC1XR10gT0F1dGggJiBBdXRoZW50aWNhdGlvbjogV2hhdCBjYW4gZ28g d3Jvbmc/CgpIaSBhbGwsCgphdCB0aGUgbGFzdCBJRVRGIG1lZXRpbmcgTWlrZSBnYXZlIGEgcHJl c2VudGF0aW9uIGFib3V0IHRoZSBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjIGFuZCB0aGUg Y29uY2x1c2lvbiBmb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gd2FzIHRvIGRpc2N1c3MgdGhlIHBy b2JsZW1zIHRoYXQgaGFwcGVuIHdoZW4gT0F1dGggZ2V0cyB1c2VkIGZvciBhdXRoZW50aWNhdGlv bi4KClRoZSBnb2FsIG9mIHRoaXMgZWZmb3J0IGlzIHRvIGRvY3VtZW50IHRoZSBwcm9ibGVtcyBp biBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LgoKQ29uZmVyZW5jZSBjYWxscyBjb3VsZCBzdGFy dCBpbiBhYm91dCAyIHdlZWtzIGFuZCB3ZSB3b3VsZCBsaWtlIHRvIGtub3cgd2hvIHdvdWxkIGJl IGludGVyZXN0ZWQgdG8gcGFydGljaXBhdGUgaW4gc3VjaCBhIGRpc2N1c3Npb24uCgpQbGVhc2Ug ZHJvcCB1cyBhIHByaXZhdGUgbWFpbCBzbyB0aGF0IHdlIGNhbiBmaW5kIHN1aXRhYmxlIGRhdGVz L3RpbWVzLgoKQ2lhbwpIYW5uZXMgJiBEZXJlawoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KT0F1dGggbWFpbGluZyBsaXN0Ck9BdXRoQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKCgogCi0tIApOYXQgU2Fr aW11cmEgKD1uYXQpCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbgpodHRwOi8vbmF0LnNha2lt dXJhLm9yZy8KQF9uYXRfZW4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KT0F1dGggbWFpbGluZyBsaXN0Ck9BdXRoQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KT0F1dGggbWFpbGluZyBsaXN0Ck9BdXRoQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKIA== ----_com.android.email_865368721331240 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+bWUgdG9vPGJyPjxicj48ZGl2Pi0t LS0tLS0tIFVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodCAtLS0tLS0tLTwvZGl2PjxkaXY+Vm9uOiAi VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSIgPHRpcmVkZHlAY2lzY28uY29tPiA8L2Rpdj48 ZGl2PkRhdHVtOjEyLjA5LjIwMTQgIDA4OjUwICAoR01UKzAxOjAwKSA8L2Rpdj48ZGl2PkFuOiBB bnRvbmlvIFNhbnNvIDxhc2Fuc29AYWRvYmUuY29tPiwgR2lsIEtpcmtwYXRyaWNrIDxnaWwua2ly a3BhdHJpY2tAdmlld2RzLmNvbT4gPC9kaXY+PGRpdj5DYzogRGVyZWsgQXRraW5zIDxkZXJla0Bp aHRmcC5jb20+LCBvYXV0aEBpZXRmLm9yZyA8L2Rpdj48ZGl2PkJldHJlZmY6IFJlOiBbT0FVVEgt V0ddIE9BdXRoICYgQXV0aGVudGljYXRpb246IFdoYXQgY2FuIGdvIHdyb25nPyA8L2Rpdj48ZGl2 Pjxicj48L2Rpdj4KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBtZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4KPGRpdj4KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGgg W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFudG9u aW8gU2Fuc288YnI+CjxiPlNlbnQ6PC9iPiBGcmlkYXksIFNlcHRlbWJlciAxMiwgMjAxNCAxMjoy MCBQTTxicj4KPGI+VG86PC9iPiBHaWwgS2lya3BhdHJpY2s8YnI+CjxiPkNjOjwvYj4gRGVyZWsg QXRraW5zOyBvYXV0aEBpZXRmLm9yZzxicj4KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0dd IE9BdXRoICZhbXA7IEF1dGhlbnRpY2F0aW9uOiBXaGF0IGNhbiBnbyB3cm9uZz88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbGlrZSB0byBhdHRlbmQg YXMgd2VsbCDigKYmbmJzcDsgPG86cD48L286cD48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+cmVnYXJkczxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5hbnRvbmlvPG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxkaXY+CjxkaXY+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFNlcCAxMiwgMjAxNCwgYXQgMzowMCBBTSwgR2lsIEtpcmtwYXRyaWNr ICZsdDs8YSBocmVmPSJtYWlsdG86Z2lsLmtpcmtwYXRyaWNrQHZpZXdkcy5jb20iPmdpbC5raXJr cGF0cmlja0B2aWV3ZHMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+CjwvZGl2Pgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+Cjxicj4KPG86cD48L286cD48L3A+CjxkaXY+CjxkaXY+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4rMSBmb3IgbWUuPG86cD48L286cD48 L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTogIkpvaG4gQnJhZGxleSIgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3 anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4K PC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbzogIk5hdCBT YWtpbXVyYSIgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJh QGdtYWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPGRpdj4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNjOiAiRGVyZWsgQXRraW5zIiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRlcmVrQGlodGZwLmNvbSI+ZGVyZWtAaWh0ZnAuY29tPC9hPiZndDs7ICI8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiIgJmx0Ozxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5TZW50OiAxMi8wOS8yMDE0IDk6MzA6NTAgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDog UmU6IFtPQVVUSC1XR10gT0F1dGggJmFtcDsgQXV0aGVudGljYXRpb246IFdoYXQgY2FuIGdvIHdy b25nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2 IGlkPSI0OWI5ZDI4ZDA2M2U0MGFjYjg1NDMyNDYwOTY3Zjk0NSI+CjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gOC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6Mi4yNXB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5BbmQgbWUmbmJzcDs8YnI+Cjxicj4KU2VudCBmcm9tIG15IGlQaG9u ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4KT24gU2VwIDEx LCAyMDE0LCBhdCA3OjQ5IFBNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtp bXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gOC4wcHQ7bWFy Z2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFk ZCBtZSwgdG9vLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMDE0LTA5LTEyIDc6MzIg R01UKzA5OjAwIEFudGhvbnkgTmFkYWxpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNv bSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDs6PG86cD48L286cD48L3NwYW4+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWRkIG1lPG86cD48L286cD48L3NwYW4+ PC9wPgo8ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy PgpGcm9tOiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2No b2ZlbmlnPGJyPgpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDExLCAyMDE0IDM6MzAgUE08YnI+ ClRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4KQ2M6IERl cmVrIEF0a2luczxicj4KU3ViamVjdDogW09BVVRILVdHXSBPQXV0aCAmYW1wOyBBdXRoZW50aWNh dGlvbjogV2hhdCBjYW4gZ28gd3Jvbmc/PGJyPgo8YnI+CkhpIGFsbCw8YnI+Cjxicj4KYXQgdGhl IGxhc3QgSUVURiBtZWV0aW5nIE1pa2UgZ2F2ZSBhIHByZXNlbnRhdGlvbiBhYm91dCB0aGUgZHJh ZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0YyBhbmQgdGhlIGNvbmNsdXNpb24gZm9sbG93aW5nIHRo ZSBkaXNjdXNzaW9uIHdhcyB0byBkaXNjdXNzIHRoZSBwcm9ibGVtcyB0aGF0IGhhcHBlbiB3aGVu IE9BdXRoIGdldHMgdXNlZCBmb3IgYXV0aGVudGljYXRpb24uPGJyPgo8YnI+ClRoZSBnb2FsIG9m IHRoaXMgZWZmb3J0IGlzIHRvIGRvY3VtZW50IHRoZSBwcm9ibGVtcyBpbiBhbiBpbmZvcm1hdGlv bmFsIGRvY3VtZW50Ljxicj4KPGJyPgpDb25mZXJlbmNlIGNhbGxzIGNvdWxkIHN0YXJ0IGluIGFi b3V0IDIgd2Vla3MgYW5kIHdlIHdvdWxkIGxpa2UgdG8ga25vdyB3aG8gd291bGQgYmUgaW50ZXJl c3RlZCB0byBwYXJ0aWNpcGF0ZSBpbiBzdWNoIGEgZGlzY3Vzc2lvbi48YnI+Cjxicj4KUGxlYXNl IGRyb3AgdXMgYSBwcml2YXRlIG1haWwgc28gdGhhdCB3ZSBjYW4gZmluZCBzdWl0YWJsZSBkYXRl cy90aW1lcy48YnI+Cjxicj4KQ2lhbzxicj4KSGFubmVzICZhbXA7IERlcmVrPG86cD48L286cD48 L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KT0F1 dGggbWFpbGluZyBsaXN0PGJyPgo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRo QGlldGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGJyPgo8YnIgY2xlYXI9ImFsbCI+CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4K PGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+Ck5hdCBT YWtpbXVyYSAoPW5hdCkgPG86cD48L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPgo8YSBo cmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwv YT48YnI+CkBfbmF0X2VuPG86cD48L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjwvYmxv Y2txdW90ZT4KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA4LjBwdDttYXJnaW4tbGVmdDozLjc1 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vn b2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+CjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPgo8L2Jsb2NrcXVvdGU+CjwvYmxvY2txdW90ZT4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4KT0F1dGggbWFpbGluZyBsaXN0PGJyPgo8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4K PC9kaXY+CgoKPC9ib2R5Pg== ----_com.android.email_865368721331240-- From nobody Fri Sep 12 07:08:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2D01A086B for ; Fri, 12 Sep 2014 07:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham 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 Kc5aJ9jmMeGK for ; Fri, 12 Sep 2014 07:08:22 -0700 (PDT) Received: from smtptsrv1.mitre.org (smtptsrv1.mitre.org [192.52.194.77]) by ietfa.amsl.com (Postfix) with ESMTP id C234C1A06B3 for ; Fri, 12 Sep 2014 07:08:15 -0700 (PDT) Received: from smtptsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6F950C506EF; Fri, 12 Sep 2014 10:08:15 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtptsrv1.mitre.org (Postfix) with ESMTP id 4BEC0C506D3; Fri, 12 Sep 2014 10:08:15 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.225]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Fri, 12 Sep 2014 10:08:15 -0400 From: "Richer, Justin P." To: Brian Campbell Thread-Topic: [OAUTH-WG] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG) Thread-Index: AQHPzg6X9kZOMRod4EKxZmg/Jhd6GJv9zO0A Date: Fri, 12 Sep 2014 14:08:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.23] Content-Type: multipart/alternative; boundary="_000_AC1D34BF6EDD4EFEA0FDAE4C2B43B2D4mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Uzdvamk3vsd99evnqetaLFCFHuo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 14:08:25 -0000 --_000_AC1D34BF6EDD4EFEA0FDAE4C2B43B2D4mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It used to be simply "expires_at" but after discussion on the list it was c= hanged to "client_secret_expires_at", since the client's secret is the most= likely part to expire and need to be refreshed. Of course this refresh mak= es the most sense if you're implementing the management spec where you can = actually do something other than re-register, but it's still handy for the = client to know that its server-issued credentials won't be good anymore at = a certain point. Since the JWKS is provided by the client and not by the server, the server = doesn't really need to tell the client when it expires. The parameter is not passed back if there is no client_secret, such as a pu= blic or implicit client. There's text in the security considerations about = expiring those kinds of clients* but after discussion on the list it was de= cided that it's too specific to a server policy to try to signal. Plus, nob= ody seems to do that today. Client secrets *do* expire in some setups, but = client IDs don't, in my personal experience. -- Justin * And I just noticed that this paragraph still mentions the "delete action"= , so we need to clean that part up in the next revision. On Sep 11, 2014, at 6:19 PM, Brian Campbell > wrote: Why does expiration only apply to the client secret[1]? If there's a need f= or the AS to set an expiration, isn't it broader than that and apply to the= whole client or the client id? If there's a need to signal an expiration t= ime on the client secret, doesn't it follow that the client's JSON Web Key = Set (the jwks parameter) might also need to be expired? And what about stri= ctly implicit clients or other public clients, is there no case that an AS = would want to expire them? I realize I've asked this before (more than once) but I've never gotten an = answer. To me, whats in this draft that's on its way to the IESG is awkward= and/or incomplete. I believe that either the client_secret_expires_at should be removed from d= raft-ietf-oauth-dyn-reg or it should be changed to something that isn't spe= cific to the client secret - something like client_expires_at or client_id_= expires_at. [1] client_secret_expires_at in https://tools.ietf.org/html/draft-ietf-oaut= h-dyn-reg-20#section-4.1 On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig > wrote: Hi all, I have just sent the Dynamic Client Registration document to the IESG. The final shepherd write-up for the document can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/ Ciao Hannes _______________________________________________ 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 --_000_AC1D34BF6EDD4EFEA0FDAE4C2B43B2D4mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <4CC71658E97CC149BDA9C61625C7081A@imc.mitre.org> Content-Transfer-Encoding: quoted-printable It used to be simply "expires_at" but after discussion on the lis= t it was changed to "client_secret_expires_at", since the client'= s secret is the most likely part to expire and need to be refreshed. Of cou= rse this refresh makes the most sense if you're implementing the management spec where you can actually do something other than re-regi= ster, but it's still handy for the client to know that its server-issued cr= edentials won't be good anymore at a certain point.

Since the JWKS is provided by the client and not by the server, the se= rver doesn't really need to tell the client when it expires. 

The parameter is not passed back if there is no client_secret, such as= a public or implicit client. There's text in the security considerations a= bout expiring those kinds of clients* but after discussion on the list it w= as decided that it's too specific to a server policy to try to signal. Plus, nobody seems to do that today. = Client secrets *do* expire in some setups, but client IDs don't, in my pers= onal experience. 

 -- Justin


* And I just noticed that this paragraph still mentions the "dele= te action", so we need to clean that part up in the next revision.

On Sep 11, 2014, at 6:19 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Why does expiration only apply to the client secret[1]? If there's a n= eed for the AS to set an expiration, isn't it broader than that and apply t= o the whole client or the client id? If there's a need to signal an expirat= ion time on the client secret, doesn't it follow that the client's JSON Web Key Set (the jwks parameter) might al= so need to be expired? And what about strictly implicit clients or other pu= blic clients, is there no case that an AS would want to expire them?

I realize I've asked this before (more than once) but I've never gotten an = answer. To me, whats in this draft that's on its way to the IESG is awkward= and/or incomplete.

I believe that either the client_secret_expires_at should be removed from d= raft-ietf-oauth-dyn-reg or it should be changed to something that isn't spe= cific to the client secret - something like client_expires_at or client_id_= expires_at.

[1] client_secret_expires_at in https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1

On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofen= ig <hannes.t= schofenig@gmx.net> wrote:
Hi all,

I have just sent the Dynamic Client Registration document to the IESG.
The final shepherd write-up for the document can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oau= th-dyn-reg/shepherdwriteup/

Ciao
Hannes


_______________________________________________
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/oauth

--_000_AC1D34BF6EDD4EFEA0FDAE4C2B43B2D4mitreorg_-- From nobody Fri Sep 12 08:32:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56621A6F6D for ; Fri, 12 Sep 2014 08:32:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 OfDcQd1PMxk9 for ; Fri, 12 Sep 2014 08:32:18 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F9D1A6F17 for ; Fri, 12 Sep 2014 08:32:18 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id n8so887529qaq.40 for ; Fri, 12 Sep 2014 08:32:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Wf5dT3wXexyZ1xLtEjPjaBRDjNFtk+nPgV3nbrdR9Rk=; b=LhxReRuPzoTy0lomsW2Ek0AEom7yTKBmVK2ojgM2N7O29o3rjhfjc9R9FrSdzmy1YW /YoE31obNqDhpMRlpUa/MtU2z8FhRSFvGmYH5XOucKVVukFZzSh524mtAB/eyEMjQyI0 945bE2q2pzRLCL0SrHQnpscX7j6y3ag+2J80sXBUIBTc+Lduc45N4TSzRlCsnND4UF9a 579QfGutiq+NnX7R4IYSHCmAZcBJEuEKy/JFn29Spt6eaXWDolDC05hDOlVp3o7H6r1j 34q61kDRapqvpBmpibPG1ZIT2/CC2hHvUsEW7euRw6RmYdF6+7iXSGN4dpNMnHLkIUZt fLpQ== X-Gm-Message-State: ALoCoQk0BX8mqq/XptPDbHR23uBTDhkf/iD9CB9PZvpC2Y/OjzA+3GpH6Gq7JiCJPvmxT/NqhDOJ X-Received: by 10.140.30.227 with SMTP id d90mr3913469qgd.55.1410535935088; Fri, 12 Sep 2014 08:32:15 -0700 (PDT) Received: from [192.168.1.37] (181-163-122-71.baf.movistar.cl. [181.163.122.71]) by mx.google.com with ESMTPSA id i17sm3199389qay.47.2014.09.12.08.32.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 08:32:14 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_58F1FC55-DB71-4CC6-98EB-192036AB68F0"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Fri, 12 Sep 2014 12:32:02 -0300 Message-Id: References: To: "Justin P. Richer" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/XeZCeDEaBj6sUxyvZ6iLWiT5Hzs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 15:32:21 -0000 --Apple-Mail=_58F1FC55-DB71-4CC6-98EB-192036AB68F0 Content-Type: multipart/alternative; boundary="Apple-Mail=_75A04DC1-C5AD-4F72-8B0C-6C77972A0383" --Apple-Mail=_75A04DC1-C5AD-4F72-8B0C-6C77972A0383 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes the JWKS expiry is logically controlled by the client. If it is = going to roll those keys it should be using a jwks_uri if there is no = management API to push a new JWKS. In general symmetric client secrets create key management problems. My = preference is to move to asymmetric keys. John B. On Sep 12, 2014, at 11:08 AM, Richer, Justin P. = wrote: > It used to be simply "expires_at" but after discussion on the list it = was changed to "client_secret_expires_at", since the client's secret is = the most likely part to expire and need to be refreshed. Of course this = refresh makes the most sense if you're implementing the management spec = where you can actually do something other than re-register, but it's = still handy for the client to know that its server-issued credentials = won't be good anymore at a certain point. >=20 > Since the JWKS is provided by the client and not by the server, the = server doesn't really need to tell the client when it expires.=20 >=20 > The parameter is not passed back if there is no client_secret, such as = a public or implicit client. There's text in the security considerations = about expiring those kinds of clients* but after discussion on the list = it was decided that it's too specific to a server policy to try to = signal. Plus, nobody seems to do that today. Client secrets *do* expire = in some setups, but client IDs don't, in my personal experience.=20 >=20 > -- Justin >=20 >=20 > * And I just noticed that this paragraph still mentions the "delete = action", so we need to clean that part up in the next revision. >=20 > On Sep 11, 2014, at 6:19 PM, Brian Campbell = wrote: >=20 >> Why does expiration only apply to the client secret[1]? If there's a = need for the AS to set an expiration, isn't it broader than that and = apply to the whole client or the client id? If there's a need to signal = an expiration time on the client secret, doesn't it follow that the = client's JSON Web Key Set (the jwks parameter) might also need to be = expired? And what about strictly implicit clients or other public = clients, is there no case that an AS would want to expire them? >>=20 >> I realize I've asked this before (more than once) but I've never = gotten an answer. To me, whats in this draft that's on its way to the = IESG is awkward and/or incomplete.=20 >>=20 >> I believe that either the client_secret_expires_at should be removed = from draft-ietf-oauth-dyn-reg or it should be changed to something that = isn't specific to the client secret - something like client_expires_at = or client_id_expires_at. >>=20 >> [1] client_secret_expires_at in = https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1 >>=20 >> On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig = wrote: >> Hi all, >>=20 >> I have just sent the Dynamic Client Registration document to the = IESG. >> The final shepherd write-up for the document can be found here: >> = http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/ >>=20 >> Ciao >> Hannes >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=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=_75A04DC1-C5AD-4F72-8B0C-6C77972A0383 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Yes the JWKS expiry is logically controlled by the client.  If it is going to roll those keys it should be using a jwks_uri if there is no management API to push a new JWKS.

In general symmetric client secrets create key management problems.  My preference is to move to asymmetric keys.

John B.



On Sep 12, 2014, at 11:08 AM, Richer, Justin P. <jricher@mitre.org> wrote:

It used to be simply "expires_at" but after discussion on the list it was changed to "client_secret_expires_at", since the client's secret is the most likely part to expire and need to be refreshed. Of course this refresh makes the most sense if you're implementing the management spec where you can actually do something other than re-register, but it's still handy for the client to know that its server-issued credentials won't be good anymore at a certain point.

Since the JWKS is provided by the client and not by the server, the server doesn't really need to tell the client when it expires. 

The parameter is not passed back if there is no client_secret, such as a public or implicit client. There's text in the security considerations about expiring those kinds of clients* but after discussion on the list it was decided that it's too specific to a server policy to try to signal. Plus, nobody seems to do that today. Client secrets *do* expire in some setups, but client IDs don't, in my personal experience. 

 -- Justin


* And I just noticed that this paragraph still mentions the "delete action", so we need to clean that part up in the next revision.

On Sep 11, 2014, at 6:19 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Why does expiration only apply to the client secret[1]? If there's a need for the AS to set an expiration, isn't it broader than that and apply to the whole client or the client id? If there's a need to signal an expiration time on the client secret, doesn't it follow that the client's JSON Web Key Set (the jwks parameter) might also need to be expired? And what about strictly implicit clients or other public clients, is there no case that an AS would want to expire them?

I realize I've asked this before (more than once) but I've never gotten an answer. To me, whats in this draft that's on its way to the IESG is awkward and/or incomplete.

I believe that either the client_secret_expires_at should be removed from draft-ietf-oauth-dyn-reg or it should be changed to something that isn't specific to the client secret - something like client_expires_at or client_id_expires_at.

[1] client_secret_expires_at in https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1

On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

I have just sent the Dynamic Client Registration document to the IESG.
The final shepherd write-up for the document can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/

Ciao
Hannes


_______________________________________________
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

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

--Apple-Mail=_75A04DC1-C5AD-4F72-8B0C-6C77972A0383-- --Apple-Mail=_58F1FC55-DB71-4CC6-98EB-192036AB68F0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MTIxNTMyMDJaMCMGCSqGSIb3DQEJBDEWBBStAkT/oadaeD2RRarfI2pZ 6t/0njCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBANnmrYqbbO0FQb6uqULAo8eWbd7URtO6QDBMWA6YtkqxQvSOvVSdV hFX+KOOF7SqIt+16XwNBl6AxDjCEBxFAUj4kh7aKcv0yxbNbeRbIKA55QHCMTExutohJaQ5dUUXJ 04WggV+iNqERavP1W0fjlwzmc/wNzcaCuXnuzAdlOGw+5sXGuh3Kds+Uln5ZPiCM/1f7ZkDTDVpO 0Taws8rD/8PKAB6ukYi8Ev7eo04j+O/f2jGB26pZqUYFMl3JXQYPpXI728F1DE2B6HqGSk6BmhFj KQoNS4jGWPfrvJeqXi+yT/WxOR3sIucMf7ILdlmTUIYrsalSMSQcWtpjloR6AAAAAAAA --Apple-Mail=_58F1FC55-DB71-4CC6-98EB-192036AB68F0-- From nobody Fri Sep 12 09:53:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146701A6FC8 for ; Fri, 12 Sep 2014 09:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 5GrK1NzJ2vup for ; Fri, 12 Sep 2014 09:53:47 -0700 (PDT) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43391A073C for ; Fri, 12 Sep 2014 09:53:46 -0700 (PDT) Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKVBMlGgOpWbqzKC+x13xnD2QRVoqRwAmT@postini.com; Fri, 12 Sep 2014 09:53:46 PDT Received: by mail-ig0-f177.google.com with SMTP id h15so858052igd.4 for ; Fri, 12 Sep 2014 09:53:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nfYrfrhZIwu7AuntLZXPrT5WyDm8WCDjeMs4kUrRWiI=; b=NlodgewTyCXwcCUEbxgfmAteeaQyo5R4xxDwMdq7TdzqyNeL/cPTd9HsoUoccFdiBN aOJizzIZyOeghake9ipHc3TzoaSz5+qQ8Q2oZDeY94j/QFpFynRTrVq08oW8k7HGvryI 0X4cniNbwVRtlS/KFRyD5CAstVBqTJwp4q06+rrKMR3zbKxRz9HGhdGco706D4loH2qQ v8qI+Wd0zCjTDywYUZzFwco+o2rbAlLTX1cIw4AzaRnA5hhE3zw0ICB2xnIlgAG0qK1S HbEsmQZk6sVfdC8GOzOsEVgYR2pHMQ5WX5533BeJANMxr1tpf0XVgwOuvAY9P9H5azk8 yUOQ== X-Gm-Message-State: ALoCoQmNrbNbm4PCCZPJgwaZrhGccp/ss2CZHEWXBzxg8lOZpLPIK6XlE3+wZNqiZD8A8DtnX3wQgTly4isIKCOCyM0GP5EC27IjfWR76/FMRU5wFV87vIhy4BlyWpKmIygbvQtglID+ X-Received: by 10.50.111.80 with SMTP id ig16mr3762544igb.43.1410540826154; Fri, 12 Sep 2014 09:53:46 -0700 (PDT) X-Received: by 10.50.111.80 with SMTP id ig16mr3762531igb.43.1410540826023; Fri, 12 Sep 2014 09:53:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Fri, 12 Sep 2014 09:53:15 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 12 Sep 2014 10:53:15 -0600 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=089e014944a4e074bc0502e1203a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JKMaEHms5N8lAYiRJSc4gfgwq14 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] client_secret_expires_at redux again (was Re: Dynamic Client Registration Sent to the IESG) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 16:53:50 -0000 --089e014944a4e074bc0502e1203a Content-Type: text/plain; charset=UTF-8 Okay, I see 'Changed "expires_at" to "client_secret_expires_at" and "issued_at" to "client_id_issued_at" for greater clarity.' in the document history for -11 (full 'management' was in the draft back then). But to me, it doesn't improve clarity. And it seems limiting. But I seem to be in the minority of people that think that or care. And I'm not sure I even care. So I'll drop it. On Fri, Sep 12, 2014 at 8:08 AM, Richer, Justin P. wrote: > It used to be simply "expires_at" but after discussion on the list it was > changed to "client_secret_expires_at", since the client's secret is the > most likely part to expire and need to be refreshed. Of course this refresh > makes the most sense if you're implementing the management spec where you > can actually do something other than re-register, but it's still handy for > the client to know that its server-issued credentials won't be good anymore > at a certain point. > > Since the JWKS is provided by the client and not by the server, the > server doesn't really need to tell the client when it expires. > > The parameter is not passed back if there is no client_secret, such as a > public or implicit client. There's text in the security considerations > about expiring those kinds of clients* but after discussion on the list it > was decided that it's too specific to a server policy to try to signal. > Plus, nobody seems to do that today. Client secrets *do* expire in some > setups, but client IDs don't, in my personal experience. > > -- Justin > > > * And I just noticed that this paragraph still mentions the "delete > action", so we need to clean that part up in the next revision. > > On Sep 11, 2014, at 6:19 PM, Brian Campbell > wrote: > > Why does expiration only apply to the client secret[1]? If there's a > need for the AS to set an expiration, isn't it broader than that and apply > to the whole client or the client id? If there's a need to signal an > expiration time on the client secret, doesn't it follow that the client's > JSON Web Key Set (the jwks parameter) might also need to be expired? And > what about strictly implicit clients or other public clients, is there no > case that an AS would want to expire them? > > I realize I've asked this before (more than once) but I've never gotten > an answer. To me, whats in this draft that's on its way to the IESG is > awkward and/or incomplete. > > I believe that either the client_secret_expires_at should be removed from > draft-ietf-oauth-dyn-reg or it should be changed to something that isn't > specific to the client secret - something like client_expires_at or > client_id_expires_at. > > [1] client_secret_expires_at in > https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1 > > On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi all, >> >> I have just sent the Dynamic Client Registration document to the IESG. >> The final shepherd write-up for the document can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/shepherdwriteup/ >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> 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 > > > --089e014944a4e074bc0502e1203a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Okay, I see 'Changed "expires_at" to &q= uot;client_secret_expires_at" and "issued_at" to "client_id_issued_at" for greater clarity.' in the d= ocument history for -11 (full 'management' was in the draft back th= en).

But to me, it doesn't improve clarity. And it s= eems limiting. But I seem to be in the minority of people that think that o= r care. And I'm not sure I even care. So I'll drop it.

On Fri, Sep 12= , 2014 at 8:08 AM, Richer, Justin P. <jricher@mitre.org> wro= te:
It used to be simply "expires_at" but after discussion on the lis= t it was changed to "client_secret_expires_at", since the client&= #39;s secret is the most likely part to expire and need to be refreshed. Of= course this refresh makes the most sense if you're implementing the management spec where you can actually do something other than re-regi= ster, but it's still handy for the client to know that its server-issue= d credentials won't be good anymore at a certain point.

Since the JWKS is provided by the client and not by the server, the se= rver doesn't really need to tell the client when it expires.=C2=A0

The parameter is not passed back if there is no client_secret, such as= a public or implicit client. There's text in the security consideratio= ns about expiring those kinds of clients* but after discussion on the list = it was decided that it's too specific to a server policy to try to signal. Plus, nobody seems to do that today. = Client secrets *do* expire in some setups, but client IDs don't, in my = personal experience.=C2=A0

=C2=A0-- Justin


* And I just noticed that this paragraph still mentions the "dele= te action", so we need to clean that part up in the next revision.

On Sep 11, 2014, at 6:19 PM, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:

Why does expiration only apply to the client secret[1]? If there's= a need for the AS to set an expiration, isn't it broader than that and= apply to the whole client or the client id? If there's a need to signa= l an expiration time on the client secret, doesn't it follow that the client's JSON Web Key Set (the jwks parameter) migh= t also need to be expired? And what about strictly implicit clients or othe= r public clients, is there no case that an AS would want to expire them?
I realize I've asked this before (more than once) but I've never go= tten an answer. To me, whats in this draft that's on its way to the IES= G is awkward and/or incomplete.

I believe that either the client_secret_expires_at should be removed from d= raft-ietf-oauth-dyn-reg or it should be changed to something that isn't= specific to the client secret - something like client_expires_at or client= _id_expires_at.

[1] client_secret_expires_at in https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20#section-4.1

On Wed, Sep 10, 2014 at 5:50 PM, Hannes Tschofen= ig <hannes.t= schofenig@gmx.net> wrote:
Hi all,

I have just sent the Dynamic Client Registration document to the IESG.
The final shepherd write-up for the document can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oau= th-dyn-reg/shepherdwriteup/

Ciao
Hannes


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


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


--089e014944a4e074bc0502e1203a-- From nobody Mon Sep 15 10:11:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893F31A88AC; Mon, 15 Sep 2014 10:11:01 -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] autolearn=ham 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 cRy_nUWIllLE; Mon, 15 Sep 2014 10:10:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4089C1A6F22; Mon, 15 Sep 2014 09:35:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140915163541.12012.68350.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 09:35:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/L6OfMDw7q2qvSfNhxNXlzcOIxJs Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:11:01 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Sep 15 10:16:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F131A6F81; Mon, 15 Sep 2014 10:16:35 -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] autolearn=ham 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 5lZGCHzxMQKi; Mon, 15 Sep 2014 10:16:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B281A8A7A; Mon, 15 Sep 2014 09:39:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140915163931.21606.17095.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 09:39:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Te6Fv6hvLTSLLtDkWUZLWQe7Nh8 Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:16:35 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Sep 15 10:18:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFA51A8A3B; Mon, 15 Sep 2014 10:18:26 -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] autolearn=ham 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 sQTZ7mmg6TnC; Mon, 15 Sep 2014 10:18:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FA31A8F38; Mon, 15 Sep 2014 09:40:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140915164024.26449.2034.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 09:40:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zAoK2MVVXCBaCuL1VreH_-qNuhI Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:18:26 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Sep 15 12:16:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663331A0B75 for ; Mon, 15 Sep 2014 12:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 BYmirIIl-aKN for ; Mon, 15 Sep 2014 12:16:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0086.outbound.protection.outlook.com [65.55.169.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC981A6F81 for ; Mon, 15 Sep 2014 12:10:23 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 15 Sep 2014 19:10:20 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.125]) with mapi id 15.00.1024.012; Mon, 15 Sep 2014 19:10:20 +0000 From: Antonio Sanso To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgBGs+4A= Date: Mon, 15 Sep 2014 19:10:20 +0000 Message-ID: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> In-Reply-To: <540865E5.5010808@pingidentity.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03355EE97E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51444003)(199003)(189002)(479174003)(377454003)(52604005)(51704005)(24454002)(76482001)(97736003)(74662001)(77982001)(83072002)(33656002)(16601075003)(15202345003)(2501002)(19580405001)(80022001)(64706001)(76176999)(46102001)(74502001)(54356999)(87936001)(101416001)(83322001)(99396002)(50986999)(4396001)(19580395003)(79102001)(81342001)(85852003)(21056001)(81542001)(86362001)(92726001)(95666004)(99286002)(83716003)(2656002)(15975445006)(106356001)(106116001)(105586002)(587094003)(77096002)(36756003)(82746002)(66066001)(20776003)(107046002)(15395725005)(2351001)(85306004)(90102001)(93886004)(110136001)(104396001)(387795003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB206; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Ae4t2Ynd8S409hs8I0r_L4X5elI Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:16:12 -0000 hi *, my understanding is that there is a rough consensus that if an OAuth Provid= er follows rfc6749 verbatim will end up having an open redirector. My next question would be now, is there anything we can do to raise some aw= areness about this issue? regards antonio On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrot= e: > I am convinced about the issue in the use case Antonio provided but I hop= e not to close the door on returning errors to known and trusted clients. N= ot sure anymore if that's possible though because the distinction can't be = "registered"... >=20 > Hans. >=20 > On 9/4/14, 3:01 PM, Antonio Sanso wrote: >> hi Bill >> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>=20 >>> FWIW, Antonio convinced me and I'm going to change this in our IDM proj= ect. Thanks Antonio. What convinced me was that the user is probably expe= cting a login screen. Since there is this expectation, it might make it a = little easier for the attacker to convince the user that a spoofed login sc= reen is real. I know this issue can only happen with unrestricted registra= tion, but, IMO, this proposed change doesn't really have much of an effect = on usability and is even backward compatible with the current RFC. >>>=20 >>> Wouldn't it better though to never do a redirect on an invalid request = and just display an error page? >>=20 >> thanks for sharing your thoughts :). Display an error 400 is what Google= does :) >>=20 >> regards >>=20 >> antonio >>=20 >>>=20 >>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>> Hi Hans, >>>>=20 >>>> I really fail to see how this can be addressed at registration time fo= r cases where registration is unrestricted (namely all the big Providers) >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt = wrote: >>>>=20 >>>>> Classifying like this must also mean that consent should not be store= d until the client is considered (admin) trusted, and admin policy would in= terfere with user policy. >>>>>=20 >>>>> IMHO the security consideration would apply only to dynamically regis= tered clients where registration is unrestricted; any other form would invo= lve some form of admin/user approval at registration time, overcoming the c= oncern at authorization time: there's no auto-redirect flow possible for un= known clients. >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>> I think this advice isn't a bad idea, though it's of course up to th= e AS >>>>>> what an "untrusted" client really is. In practice, this is something >>>>>> that was registered by a non-sysadmin type person, either a dynamica= lly >>>>>> registered client or something available through self-service >>>>>> registration of some type. It's also reasonable that a client, even >>>>>> dynamically registered, would be considered "trusted" if enough time= has >>>>>> passed and enough users have used it without things blowing up. >>>>>>=20 >>>>>> -- Justin >>>>>>=20 >>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>> > wrote: >>>>>>=20 >>>>>>> hi again *, >>>>>>>=20 >>>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>>> clients can also be to always present the consent screen (at least >>>>>>> once) before any redirect. >>>>>>> Namely all providers I have seen show the consent screen if all the >>>>>>> request parameters are correct and if the user accepts the redirect >>>>>>> happens. >>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>> redirect uri that are handled differently as for spec) is wrong tho= ugh >>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>=20 >>>>>>> WDYT? >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>> > wrote: >>>>>>>=20 >>>>>>>> Well, >>>>>>>> I do not know if this is only dynamic registration... >>>>>>>> let=92s talk about real use cases, namely e.g. Google , Facebook , >>>>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>>>=20 >>>>>>>> Said that what the other guys think? :) >>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there is a = reason >>>>>>>> if Google is by choice =93violating=94 the spec right? (I assume t= o avoid >>>>>>>> open redirect=85) >>>>>>>> But other implementers do follow the spec hence they have this ope= n >>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>> >= wrote: >>>>>>>>>>=20 >>>>>>>>>>> Is your concern clients that were registered using dynamic clie= nt >>>>>>>>>>> registration? >>>>>>>>>>=20 >>>>>>>>>> yes >>>>>>>>>=20 >>>>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>>>> registration; that is left out of scope of the dynreg spec (and t= he >>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>> everything to be open (which typically would not be the case), th= en >>>>>>>>> it would involve approval somewhere in the process before the cli= ent >>>>>>>>> is registered. Without dynamic client registration that approval = is >>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>=20 >>>>>>>>>>> Otherwise the positive case is returning a response to a valid = URL >>>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>>> resource owner >>>>>>>>>>=20 >>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>=20 >>>>>>>>> roles can collapse in use cases especially when using dynamic cli= ent >>>>>>>>> registration >>>>>>>>>=20 >>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>=20 >>>>>>>>>> the difference is the consent screen=85 in the positive case you= need >>>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>=20 >>>>>>>>>> why? >>>>>>>>>=20 >>>>>>>>> because the client and thus the fixed URL are explicitly approved= at >>>>>>>>> some point >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Let me try and approach this from a different angle: why woul= d you >>>>>>>>>>>>> call it an open redirect when an invalid scope is provided an= d >>>>>>>>>>>>> call it >>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>> provided? >>>>>>>>>>>>=20 >>>>>>>>>>>> as specified below in the positive case (namely when the corre= ct >>>>>>>>>>>> scope >>>>>>>>>>>> is provided) the resource owner MUST approve the app via the c= onsent >>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hans. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The issue is that the AS may be allowing client registratio= ns with >>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a cli= ent >>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think that if anything it may be the registration step th= at >>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It w= ould be >>>>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>>> returning >>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> said that I hope you all agree this is an issue in the spec = so >>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> regards >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerabl= e >>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismat= ching >>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing o= r >>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner= of the >>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent = to the >>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redi= rected >>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_i= d=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhtt= p://attacker.com >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the= app >>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than redir= ect >>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>> | Ping >>>>>>>>>>>>> Identity >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>> Ping Identity >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | P= ing >>>>>>>>> Identity >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>>=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 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity From nobody Mon Sep 15 12:41:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2D71A6F9C for ; Mon, 15 Sep 2014 12:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 SE_W15bzya_D for ; Mon, 15 Sep 2014 12:41:25 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BC41A6F92 for ; Mon, 15 Sep 2014 12:41:24 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8FJfMLe005987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Sep 2014 19:41:23 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FJfL9k024589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Sep 2014 19:41:22 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FJfKUs013328; Mon, 15 Sep 2014 19:41:21 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Sep 2014 12:41:20 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Mon, 15 Sep 2014 12:41:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> To: Antonio Sanso X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Kw8zRIYoFK81pQUKFiNVouba52s Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:41:28 -0000 Simply not true. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote: > hi *, >=20 > my understanding is that there is a rough consensus that if an OAuth = Provider follows rfc6749 verbatim will end up having an open redirector. > My next question would be now, is there anything we can do to raise = some awareness about this issue? >=20 > regards >=20 > antonio >=20 > On Sep 4, 2014, at 3:15 PM, Hans Zandbelt = wrote: >=20 >> I am convinced about the issue in the use case Antonio provided but I = hope not to close the door on returning errors to known and trusted = clients. Not sure anymore if that's possible though because the = distinction can't be "registered"... >>=20 >> Hans. >>=20 >> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>> hi Bill >>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>>=20 >>>> FWIW, Antonio convinced me and I'm going to change this in our IDM = project. Thanks Antonio. What convinced me was that the user is = probably expecting a login screen. Since there is this expectation, it = might make it a little easier for the attacker to convince the user that = a spoofed login screen is real. I know this issue can only happen with = unrestricted registration, but, IMO, this proposed change doesn't really = have much of an effect on usability and is even backward compatible with = the current RFC. >>>>=20 >>>> Wouldn't it better though to never do a redirect on an invalid = request and just display an error page? >>>=20 >>> thanks for sharing your thoughts :). Display an error 400 is what = Google does :) >>>=20 >>> regards >>>=20 >>> antonio >>>=20 >>>>=20 >>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>> Hi Hans, >>>>>=20 >>>>> I really fail to see how this can be addressed at registration = time for cases where registration is unrestricted (namely all the big = Providers) >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt = wrote: >>>>>=20 >>>>>> Classifying like this must also mean that consent should not be = stored until the client is considered (admin) trusted, and admin policy = would interfere with user policy. >>>>>>=20 >>>>>> IMHO the security consideration would apply only to dynamically = registered clients where registration is unrestricted; any other form = would involve some form of admin/user approval at registration time, = overcoming the concern at authorization time: there's no auto-redirect = flow possible for unknown clients. >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>> I think this advice isn't a bad idea, though it's of course up = to the AS >>>>>>> what an "untrusted" client really is. In practice, this is = something >>>>>>> that was registered by a non-sysadmin type person, either a = dynamically >>>>>>> registered client or something available through self-service >>>>>>> registration of some type. It's also reasonable that a client, = even >>>>>>> dynamically registered, would be considered "trusted" if enough = time has >>>>>>> passed and enough users have used it without things blowing up. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>> > wrote: >>>>>>>=20 >>>>>>>> hi again *, >>>>>>>>=20 >>>>>>>> after thinking a bit further IMHO an alternative for the = untrusted >>>>>>>> clients can also be to always present the consent screen (at = least >>>>>>>> once) before any redirect. >>>>>>>> Namely all providers I have seen show the consent screen if all = the >>>>>>>> request parameters are correct and if the user accepts the = redirect >>>>>>>> happens. >>>>>>>> If one of the parameter (with the exclusion of the client id = and >>>>>>>> redirect uri that are handled differently as for spec) is wrong = though >>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>=20 >>>>>>>> WDYT? >>>>>>>>=20 >>>>>>>> regards >>>>>>>>=20 >>>>>>>> antonio >>>>>>>>=20 >>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> Well, >>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>> let=92s talk about real use cases, namely e.g. Google , = Facebook , >>>>>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>>>>=20 >>>>>>>>> Said that what the other guys think? :) >>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there = is a reason >>>>>>>>> if Google is by choice =93violating=94 the spec right? (I = assume to avoid >>>>>>>>> open redirect=85) >>>>>>>>> But other implementers do follow the spec hence they have this = open >>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt = >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Is your concern clients that were registered using dynamic = client >>>>>>>>>>>> registration? >>>>>>>>>>>=20 >>>>>>>>>>> yes >>>>>>>>>>=20 >>>>>>>>>> I think your issue is then with the trust model of dynamic = client >>>>>>>>>> registration; that is left out of scope of the dynreg spec = (and the >>>>>>>>>> concept is not even part of the core spec), but unless you = want >>>>>>>>>> everything to be open (which typically would not be the = case), then >>>>>>>>>> it would involve approval somewhere in the process before the = client >>>>>>>>>> is registered. Without dynamic client registration that = approval is >>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>=20 >>>>>>>>>>>> Otherwise the positive case is returning a response to a = valid URL >>>>>>>>>>>> that belongs to a client that was registered explicitly by = the >>>>>>>>>>>> resource owner >>>>>>>>>>>=20 >>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>>=20 >>>>>>>>>> roles can collapse in use cases especially when using dynamic = client >>>>>>>>>> registration >>>>>>>>>>=20 >>>>>>>>>>>> and the negative case is returning an error to that same = URL. >>>>>>>>>>>=20 >>>>>>>>>>> the difference is the consent screen=85 in the positive case = you need >>>>>>>>>>> to approve an app.. for the error case no approval is = needed,,, >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>=20 >>>>>>>>>>> why? >>>>>>>>>>=20 >>>>>>>>>> because the client and thus the fixed URL are explicitly = approved at >>>>>>>>>> some point >>>>>>>>>>=20 >>>>>>>>>> Hans. >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Hans. >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>> >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Let me try and approach this from a different angle: why = would you >>>>>>>>>>>>>> call it an open redirect when an invalid scope is = provided and >>>>>>>>>>>>>> call it >>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope = is >>>>>>>>>>>>>> provided? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> as specified below in the positive case (namely when the = correct >>>>>>>>>>>>> scope >>>>>>>>>>>>> is provided) the resource owner MUST approve the app via = the consent >>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley = >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the = attacker. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The issue is that the AS may be allowing client = registrations with >>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a = client >>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I think that if anything it may be the registration = step that >>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. = It would be >>>>>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, = namely >>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the = spec so >>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke = >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid = in >>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are = vulnerable >>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or = mismatching >>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is = missing or >>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource = owner of the >>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the = user-agent to the >>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if = the >>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>> the authorization server informs the client by adding = the >>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>> parameters to the query component of the redirection = URI >>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, = perAppendix B >>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> = > >>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>> I register redirect uriattacker.com = >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am = redirected >>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters = are >>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve = the app >>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than = redirect >>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> [0] = https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>> http://bill.burkecentral.com = >>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>> OAuth@ietf.org = >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>> hzandbelt@pingidentity.com = >>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>> Identity >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>>> Ping Identity >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com = | Ping >>>>>>>>>> Identity >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>>=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 >> --=20 >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Sep 15 12:50:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDA31A6FA7 for ; Mon, 15 Sep 2014 12:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Hx5psO_GG4nC for ; Mon, 15 Sep 2014 12:50:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0053.outbound.protection.outlook.com [65.55.169.53]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542F01A6F57 for ; Mon, 15 Sep 2014 12:50:20 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 15 Sep 2014 19:50:17 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.125]) with mapi id 15.00.1024.012; Mon, 15 Sep 2014 19:50:17 +0000 From: Antonio Sanso To: Phil Hunt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgBGs+4CAAAiDgIAAAqiA Date: Mon, 15 Sep 2014 19:50:16 +0000 Message-ID: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> In-Reply-To: <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03355EE97E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(52604005)(189002)(51704005)(199003)(24454002)(377454003)(51444003)(479174003)(86362001)(80022001)(15202345003)(19580405001)(79102001)(19580395003)(76176999)(99286002)(15395725005)(95666004)(83322001)(106116001)(66066001)(81542001)(105586002)(99396002)(46102001)(33656002)(50986999)(77982001)(2656002)(76482001)(97736003)(101416001)(15975445006)(54356999)(20776003)(83072002)(4396001)(107046002)(81342001)(64706001)(15974865002)(83716003)(90102001)(85852003)(93886004)(92726001)(87936001)(74502001)(85306004)(74662001)(106356001)(77096002)(16601075003)(587094003)(36756003)(82746002)(110136001)(21056001)(104396001)(387795003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <2B0E2985D8CB4346ACC32F2AB1F9C97A@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/erFuBf1EoJY0FiqrspAiMfA13Bw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:50:23 -0000 On Sep 15, 2014, at 9:41 PM, Phil Hunt wrote: hi Phil > Simply not true. why do you think so ? regards antonio >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote: >=20 >> hi *, >>=20 >> my understanding is that there is a rough consensus that if an OAuth Pro= vider follows rfc6749 verbatim will end up having an open redirector. >> My next question would be now, is there anything we can do to raise some= awareness about this issue? >>=20 >> regards >>=20 >> antonio >>=20 >> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt w= rote: >>=20 >>> I am convinced about the issue in the use case Antonio provided but I h= ope not to close the door on returning errors to known and trusted clients.= Not sure anymore if that's possible though because the distinction can't b= e "registered"... >>>=20 >>> Hans. >>>=20 >>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>> hi Bill >>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>>>=20 >>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM pr= oject. Thanks Antonio. What convinced me was that the user is probably ex= pecting a login screen. Since there is this expectation, it might make it = a little easier for the attacker to convince the user that a spoofed login = screen is real. I know this issue can only happen with unrestricted regist= ration, but, IMO, this proposed change doesn't really have much of an effec= t on usability and is even backward compatible with the current RFC. >>>>>=20 >>>>> Wouldn't it better though to never do a redirect on an invalid reques= t and just display an error page? >>>>=20 >>>> thanks for sharing your thoughts :). Display an error 400 is what Goog= le does :) >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>>>=20 >>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>> Hi Hans, >>>>>>=20 >>>>>> I really fail to see how this can be addressed at registration time = for cases where registration is unrestricted (namely all the big Providers) >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> antonio >>>>>>=20 >>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>=20 >>>>>>> Classifying like this must also mean that consent should not be sto= red until the client is considered (admin) trusted, and admin policy would = interfere with user policy. >>>>>>>=20 >>>>>>> IMHO the security consideration would apply only to dynamically reg= istered clients where registration is unrestricted; any other form would in= volve some form of admin/user approval at registration time, overcoming the= concern at authorization time: there's no auto-redirect flow possible for = unknown clients. >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>> I think this advice isn't a bad idea, though it's of course up to = the AS >>>>>>>> what an "untrusted" client really is. In practice, this is somethi= ng >>>>>>>> that was registered by a non-sysadmin type person, either a dynami= cally >>>>>>>> registered client or something available through self-service >>>>>>>> registration of some type. It's also reasonable that a client, eve= n >>>>>>>> dynamically registered, would be considered "trusted" if enough ti= me has >>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> hi again *, >>>>>>>>>=20 >>>>>>>>> after thinking a bit further IMHO an alternative for the untruste= d >>>>>>>>> clients can also be to always present the consent screen (at leas= t >>>>>>>>> once) before any redirect. >>>>>>>>> Namely all providers I have seen show the consent screen if all t= he >>>>>>>>> request parameters are correct and if the user accepts the redire= ct >>>>>>>>> happens. >>>>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>>>> redirect uri that are handled differently as for spec) is wrong t= hough >>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>=20 >>>>>>>>> WDYT? >>>>>>>>>=20 >>>>>>>>> regards >>>>>>>>>=20 >>>>>>>>> antonio >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> Well, >>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , Facebook= , >>>>>>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>>>>>=20 >>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there is = a reason >>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I assume= to avoid >>>>>>>>>> open redirect=85) >>>>>>>>>> But other implementers do follow the spec hence they have this o= pen >>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Is your concern clients that were registered using dynamic cl= ient >>>>>>>>>>>>> registration? >>>>>>>>>>>>=20 >>>>>>>>>>>> yes >>>>>>>>>>>=20 >>>>>>>>>>> I think your issue is then with the trust model of dynamic clie= nt >>>>>>>>>>> registration; that is left out of scope of the dynreg spec (and= the >>>>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>>>> everything to be open (which typically would not be the case), = then >>>>>>>>>>> it would involve approval somewhere in the process before the c= lient >>>>>>>>>>> is registered. Without dynamic client registration that approva= l is >>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>=20 >>>>>>>>>>>>> Otherwise the positive case is returning a response to a vali= d URL >>>>>>>>>>>>> that belongs to a client that was registered explicitly by th= e >>>>>>>>>>>>> resource owner >>>>>>>>>>>>=20 >>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>>>=20 >>>>>>>>>>> roles can collapse in use cases especially when using dynamic c= lient >>>>>>>>>>> registration >>>>>>>>>>>=20 >>>>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>>>=20 >>>>>>>>>>>> the difference is the consent screen=85 in the positive case y= ou need >>>>>>>>>>>> to approve an app.. for the error case no approval is needed,,= , >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>=20 >>>>>>>>>>>> why? >>>>>>>>>>>=20 >>>>>>>>>>> because the client and thus the fixed URL are explicitly approv= ed at >>>>>>>>>>> some point >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hans. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Let me try and approach this from a different angle: why wo= uld you >>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provided = and >>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> as specified below in the positive case (namely when the cor= rect >>>>>>>>>>>>>> scope >>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via the= consent >>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client registrat= ions with >>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a c= lient >>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I think that if anything it may be the registration step = that >>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It= would be >>>>>>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namel= y >>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the spe= c so >>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnera= ble >>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mism= atching >>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing= or >>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource own= er of the >>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agen= t to the >>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if t= he >>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding t= he >>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection UR= I >>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix= B >>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am re= directed >>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client= _id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dh= ttp://attacker.com >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters ar= e >>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve t= he app >>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than red= irect >>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com |= Ping >>>>>>>>>>> Identity >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>>=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 >>> --=20 >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Mon Sep 15 13:01:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F331A6FBF for ; Mon, 15 Sep 2014 13:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 2oWCFNmW_skF for ; Mon, 15 Sep 2014 13:01:08 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8ABE1A6FA7 for ; Mon, 15 Sep 2014 13:01:07 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j5so4501155qga.36 for ; Mon, 15 Sep 2014 13:01:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=5WwJWg2YHQcSpKwExdH8kQ9bN83xCJHbGga85Q98WW0=; b=DGWmihvUq+mqjpw1MtI4hrvreVYDWFsDqa4S+68+h6kfHUGNymH5YDV3EbrkiSYR8J mvNPEQtajMlBhVovhgbofcDkWJ6VaA2wUooK+bEUdgiNc6vmcZ3hPUfDMQgnW5vZLvqQ dRYbBTrkFCCOCmR5Dp64GPNWbq9zU6a0bfPGNUr4QBv6WGV7dpzbL8psozpJqcEtARlt D8ltky55k7olaFlFUfqcrvmF/G4db9yiNGZgazYAJ89ujJh9km5K/i9twYJSjMP43qsj 5LvP5DVau4pJufzkL9dGKWXV08olkHXn/apPCfSZzCRLdvhaEJE9enNc4qcIBLRaHp6J 6NYw== X-Gm-Message-State: ALoCoQkS1Rw2VzisT75dIfe8KqF8O/8iIbEqv6ufaQv14u9fCqs6SOFy8KEzb8nYW6A2P64pFTXD X-Received: by 10.140.84.231 with SMTP id l94mr41622526qgd.84.1410811265166; Mon, 15 Sep 2014 13:01:05 -0700 (PDT) Received: from [10.133.128.69] ([201.220.242.40]) by mx.google.com with ESMTPSA id i1sm10300853qaz.28.2014.09.15.13.01.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 13:01:04 -0700 (PDT) References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-228AD3E7-BD7B-4506-962A-13172E36B235; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Mon, 15 Sep 2014 17:00:54 -0300 To: Phil Hunt Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Ih-Ne5TTioihN5wALwDfqAa6rOg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:01:15 -0000 --Apple-Mail-228AD3E7-BD7B-4506-962A-13172E36B235 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There may be a problem with semantics in this discussion.=20 There is a redirect performed by athe authorization endpoint to a fixed uri t= hat is pre registered with the authorization server without user prompting.=20= That probably doesn't fit the strict definition of a open redirector.=20 It may however create similar security issues in situations with relatively o= pen registration of clients.=20 The largest issues are that the browser might leak information across the re= direct in the fragment or referrer. That has been used in attacks against Fa= cebook in the past.=20 This is no where near the end of the world, however we need to look at the s= ecurity considerations and see if we can provide better advice to implemento= rs. In some cases returning a error to the browser may be best. =20 I don't think we need to go so far as not returning any error to the client u= nder any circumstance.=20 John B.=20 Sent from my iPhone > On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: >=20 > Simply not true. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote: >>=20 >> hi *, >>=20 >> my understanding is that there is a rough consensus that if an OAuth Prov= ider follows rfc6749 verbatim will end up having an open redirector. >> My next question would be now, is there anything we can do to raise some a= wareness about this issue? >>=20 >> regards >>=20 >> antonio >>=20 >>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt w= rote: >>>=20 >>> I am convinced about the issue in the use case Antonio provided but I ho= pe not to close the door on returning errors to known and trusted clients. N= ot sure anymore if that's possible though because the distinction can't be "= registered"... >>>=20 >>> Hans. >>>=20 >>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>> hi Bill >>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>>>>=20 >>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM pro= ject. Thanks Antonio. What convinced me was that the user is probably expe= cting a login screen. Since there is this expectation, it might make it a l= ittle easier for the attacker to convince the user that a spoofed login scre= en is real. I know this issue can only happen with unrestricted registratio= n, but, IMO, this proposed change doesn't really have much of an effect on u= sability and is even backward compatible with the current RFC. >>>>>=20 >>>>> Wouldn't it better though to never do a redirect on an invalid request= and just display an error page? >>>>=20 >>>> thanks for sharing your thoughts :). Display an error 400 is what Googl= e does :) >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>>>=20 >>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>> Hi Hans, >>>>>>=20 >>>>>> I really fail to see how this can be addressed at registration time f= or cases where registration is unrestricted (namely all the big Providers) >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> antonio >>>>>>=20 >>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>>=20 >>>>>>> Classifying like this must also mean that consent should not be stor= ed until the client is considered (admin) trusted, and admin policy would in= terfere with user policy. >>>>>>>=20 >>>>>>> IMHO the security consideration would apply only to dynamically regi= stered clients where registration is unrestricted; any other form would invo= lve some form of admin/user approval at registration time, overcoming the co= ncern at authorization time: there's no auto-redirect flow possible for unkn= own clients. >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>> I think this advice isn't a bad idea, though it's of course up to t= he AS >>>>>>>> what an "untrusted" client really is. In practice, this is somethin= g >>>>>>>> that was registered by a non-sysadmin type person, either a dynamic= ally >>>>>>>> registered client or something available through self-service >>>>>>>> registration of some type. It's also reasonable that a client, even= >>>>>>>> dynamically registered, would be considered "trusted" if enough tim= e has >>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> hi again *, >>>>>>>>>=20 >>>>>>>>> after thinking a bit further IMHO an alternative for the untrusted= >>>>>>>>> clients can also be to always present the consent screen (at least= >>>>>>>>> once) before any redirect. >>>>>>>>> Namely all providers I have seen show the consent screen if all th= e >>>>>>>>> request parameters are correct and if the user accepts the redirec= t >>>>>>>>> happens. >>>>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>>>> redirect uri that are handled differently as for spec) is wrong th= ough >>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>=20 >>>>>>>>> WDYT? >>>>>>>>>=20 >>>>>>>>> regards >>>>>>>>>=20 >>>>>>>>> antonio >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> Well, >>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>> let=E2=80=99s talk about real use cases, namely e.g. Google , Fac= ebook , >>>>>>>>>> etc.. is that dynamic client registration? I do not know=E2=80=A6= :) >>>>>>>>>>=20 >>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>> Would this deserve some =E2=80=9Cspec adjustment=E2=80=9D ? I mea= n there is a reason >>>>>>>>>> if Google is by choice =E2=80=9Cviolating=E2=80=9D the spec right= ? (I assume to avoid >>>>>>>>>> open redirect=E2=80=A6) >>>>>>>>>> But other implementers do follow the spec hence they have this op= en >>>>>>>>>> redirector=E2=80=A6 and this is not nice IMHO... >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>> = > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Is your concern clients that were registered using dynamic cli= ent >>>>>>>>>>>>> registration? >>>>>>>>>>>>=20 >>>>>>>>>>>> yes >>>>>>>>>>>=20 >>>>>>>>>>> I think your issue is then with the trust model of dynamic clien= t >>>>>>>>>>> registration; that is left out of scope of the dynreg spec (and t= he >>>>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>>>> everything to be open (which typically would not be the case), t= hen >>>>>>>>>>> it would involve approval somewhere in the process before the cl= ient >>>>>>>>>>> is registered. Without dynamic client registration that approval= is >>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>=20 >>>>>>>>>>>>> Otherwise the positive case is returning a response to a valid= URL >>>>>>>>>>>>> that belongs to a client that was registered explicitly by the= >>>>>>>>>>>>> resource owner >>>>>>>>>>>>=20 >>>>>>>>>>>> well AFAIK the resource owner doesn=E2=80=99t register clients=E2= =80=A6 >>>>>>>>>>>=20 >>>>>>>>>>> roles can collapse in use cases especially when using dynamic cl= ient >>>>>>>>>>> registration >>>>>>>>>>>=20 >>>>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>>>=20 >>>>>>>>>>>> the difference is the consent screen=E2=80=A6 in the positive c= ase you need >>>>>>>>>>>> to approve an app.. for the error case no approval is needed,,,= >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>=20 >>>>>>>>>>>> why? >>>>>>>>>>>=20 >>>>>>>>>>> because the client and thus the fixed URL are explicitly approve= d at >>>>>>>>>>> some point >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hans. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Let me try and approach this from a different angle: why wou= ld you >>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provided a= nd >>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> as specified below in the positive case (namely when the corr= ect >>>>>>>>>>>>>> scope >>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via the c= onsent >>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client registrati= ons with >>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a cl= ient >>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I think that if anything it may be the registration step t= hat >>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It w= ould be >>>>>>>>>>>>>>>> pretty unpractical to block this at registration time=E2=80= =A6. >>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely= >>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *400.* That=E2=80=99s an error. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the spec= so >>>>>>>>>>>>>>>> far=E2=80=A6. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerab= le >>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or misma= tching >>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing o= r >>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owne= r of the >>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent= to the >>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if th= e >>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding th= e >>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI= >>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B= >>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Now let=E2=80=99s assume this. >>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am red= irected >>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_= id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhtt= p://attacker.com >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are= >>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>> doesn=E2=80=99t apply since the resource owner MUST appr= ove the app >>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than redi= rect >>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>>>> Ping Identity >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com | P= ing >>>>>>>>>>> Identity >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>>=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 >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>=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-228AD3E7-BD7B-4506-962A-13172E36B235 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwOTE1MjAwMDU1WjAjBgkqhkiG9w0BCQQxFgQUZg72PI2g9hWKBZl4 kkChIxFofBgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEABkUFe5FnzX03T1l/7YweFK8AS4mL79TLLxQ9NMdwbDw6a9nf QECdo5yBoBJCJVwmSqX5dTolSKxoI8pIXN3rNn2FqVxXpy1DFl5LoZDNuj5+4xqqCRY88rtZt54D NN2eYaaUxUZ/JDTDGCtIDeXBt1AVoE0PS3VNW7hO7y0ypZfq+Fxn5z8nYGDPxErAZpob+RjXt1ay ulOc6Kk3lpjjHZwpNXOT4wYSHmh4aY3eyB2pkll8SMW8IjxvEu/eRRuwt7uoQlC0qIowvCMJnG9l FN/Ux43mDJ1yL1jRKjbX0dUwbob89JL6pFbVnzfZ4ocrqOn5e5CuHYNgDDmwrEZC3QAAAAAAAA== --Apple-Mail-228AD3E7-BD7B-4506-962A-13172E36B235-- From nobody Mon Sep 15 13:43:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296741A871E for ; Mon, 15 Sep 2014 13:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 3Oh_OQD_Ph2p for ; Mon, 15 Sep 2014 13:43:35 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810451A8710 for ; Mon, 15 Sep 2014 13:43:24 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8FKhJ1T017507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Sep 2014 20:43:20 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s8FKhJJv023682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Sep 2014 20:43:19 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FKhISd015646; Mon, 15 Sep 2014 20:43:18 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Sep 2014 13:43:18 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> Date: Mon, 15 Sep 2014 13:43:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8pscwh8Q2ds7Lchko94mBcK5FI0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:43:39 -0000 If a server accepts a URL from a client to be used as a redirect that = the server doesn=92t recognize or is not registered, that is an open = redirect. The specification does no allow open-redirects, it considers this a = mis-configuration. Take a look at sections 3.1.2.2 and 10.15 of RFC6749. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 15, 2014, at 1:00 PM, John Bradley wrote: > There may be a problem with semantics in this discussion.=20 >=20 > There is a redirect performed by athe authorization endpoint to a = fixed uri that is pre registered with the authorization server without = user prompting.=20 >=20 > That probably doesn't fit the strict definition of a open redirector.=20= >=20 > It may however create similar security issues in situations with = relatively open registration of clients.=20 >=20 > The largest issues are that the browser might leak information across = the redirect in the fragment or referrer. That has been used in attacks = against Facebook in the past.=20 >=20 > This is no where near the end of the world, however we need to look = at the security considerations and see if we can provide better advice = to implementors. In some cases returning a error to the browser may be = best. =20 >=20 > I don't think we need to go so far as not returning any error to the = client under any circumstance.=20 >=20 > John B.=20 >=20 > Sent from my iPhone >=20 >> On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: >>=20 >> Simply not true. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso = wrote: >>>=20 >>> hi *, >>>=20 >>> my understanding is that there is a rough consensus that if an OAuth = Provider follows rfc6749 verbatim will end up having an open redirector. >>> My next question would be now, is there anything we can do to raise = some awareness about this issue? >>>=20 >>> regards >>>=20 >>> antonio >>>=20 >>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt = wrote: >>>>=20 >>>> I am convinced about the issue in the use case Antonio provided but = I hope not to close the door on returning errors to known and trusted = clients. Not sure anymore if that's possible though because the = distinction can't be "registered"... >>>>=20 >>>> Hans. >>>>=20 >>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>> hi Bill >>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>>>>>=20 >>>>>> FWIW, Antonio convinced me and I'm going to change this in our = IDM project. Thanks Antonio. What convinced me was that the user is = probably expecting a login screen. Since there is this expectation, it = might make it a little easier for the attacker to convince the user that = a spoofed login screen is real. I know this issue can only happen with = unrestricted registration, but, IMO, this proposed change doesn't really = have much of an effect on usability and is even backward compatible with = the current RFC. >>>>>>=20 >>>>>> Wouldn't it better though to never do a redirect on an invalid = request and just display an error page? >>>>>=20 >>>>> thanks for sharing your thoughts :). Display an error 400 is what = Google does :) >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>>>=20 >>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>> Hi Hans, >>>>>>>=20 >>>>>>> I really fail to see how this can be addressed at registration = time for cases where registration is unrestricted (namely all the big = Providers) >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt = wrote: >>>>>>>>=20 >>>>>>>> Classifying like this must also mean that consent should not be = stored until the client is considered (admin) trusted, and admin policy = would interfere with user policy. >>>>>>>>=20 >>>>>>>> IMHO the security consideration would apply only to dynamically = registered clients where registration is unrestricted; any other form = would involve some form of admin/user approval at registration time, = overcoming the concern at authorization time: there's no auto-redirect = flow possible for unknown clients. >>>>>>>>=20 >>>>>>>> Hans. >>>>>>>>=20 >>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>> I think this advice isn't a bad idea, though it's of course up = to the AS >>>>>>>>> what an "untrusted" client really is. In practice, this is = something >>>>>>>>> that was registered by a non-sysadmin type person, either a = dynamically >>>>>>>>> registered client or something available through self-service >>>>>>>>> registration of some type. It's also reasonable that a client, = even >>>>>>>>> dynamically registered, would be considered "trusted" if = enough time has >>>>>>>>> passed and enough users have used it without things blowing = up. >>>>>>>>>=20 >>>>>>>>> -- Justin >>>>>>>>>=20 >>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> hi again *, >>>>>>>>>>=20 >>>>>>>>>> after thinking a bit further IMHO an alternative for the = untrusted >>>>>>>>>> clients can also be to always present the consent screen (at = least >>>>>>>>>> once) before any redirect. >>>>>>>>>> Namely all providers I have seen show the consent screen if = all the >>>>>>>>>> request parameters are correct and if the user accepts the = redirect >>>>>>>>>> happens. >>>>>>>>>> If one of the parameter (with the exclusion of the client id = and >>>>>>>>>> redirect uri that are handled differently as for spec) is = wrong though >>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>=20 >>>>>>>>>> WDYT? >>>>>>>>>>=20 >>>>>>>>>> regards >>>>>>>>>>=20 >>>>>>>>>> antonio >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> Well, >>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , = Facebook , >>>>>>>>>>> etc.. is that dynamic client registration? I do not know=85 = :) >>>>>>>>>>>=20 >>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there = is a reason >>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I = assume to avoid >>>>>>>>>>> open redirect=85) >>>>>>>>>>> But other implementers do follow the spec hence they have = this open >>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt = >>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Is your concern clients that were registered using = dynamic client >>>>>>>>>>>>>> registration? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> yes >>>>>>>>>>>>=20 >>>>>>>>>>>> I think your issue is then with the trust model of dynamic = client >>>>>>>>>>>> registration; that is left out of scope of the dynreg spec = (and the >>>>>>>>>>>> concept is not even part of the core spec), but unless you = want >>>>>>>>>>>> everything to be open (which typically would not be the = case), then >>>>>>>>>>>> it would involve approval somewhere in the process before = the client >>>>>>>>>>>> is registered. Without dynamic client registration that = approval is >>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>=20 >>>>>>>>>>>>>> Otherwise the positive case is returning a response to a = valid URL >>>>>>>>>>>>>> that belongs to a client that was registered explicitly = by the >>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>=20 >>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>>>>=20 >>>>>>>>>>>> roles can collapse in use cases especially when using = dynamic client >>>>>>>>>>>> registration >>>>>>>>>>>>=20 >>>>>>>>>>>>>> and the negative case is returning an error to that same = URL. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> the difference is the consent screen=85 in the positive = case you need >>>>>>>>>>>>> to approve an app.. for the error case no approval is = needed,,, >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> why? >>>>>>>>>>>>=20 >>>>>>>>>>>> because the client and thus the fixed URL are explicitly = approved at >>>>>>>>>>>> some point >>>>>>>>>>>>=20 >>>>>>>>>>>> Hans. >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Let me try and approach this from a different angle: = why would you >>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is = provided and >>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid = scope is >>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> as specified below in the positive case (namely when the = correct >>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via = the consent >>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley = >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the = attacker. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client = registrations with >>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that = a client >>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I think that if anything it may be the registration = step that >>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with = you. It would be >>>>>>>>>>>>>>>>> pretty unpractical to block this at registration = time=85. >>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, = namely >>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the = spec so >>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke = >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be = valid in >>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states = this. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are = vulnerable >>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or = mismatching >>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is = missing or >>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource = owner of the >>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the = user-agent to the >>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or = if the >>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>> the authorization server informs the client by = adding the >>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>> parameters to the query component of the = redirection URI >>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, = perAppendix B >>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> = > >>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com = >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I = am redirected >>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the = parameters are >>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST = approve the app >>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than = redirect >>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> [0] = https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com = >>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org = >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com = >>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>> hzandbelt@pingidentity.com = | Ping >>>>>>>>>>>> Identity >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> -- >>>>>> Bill Burke >>>>>> JBoss, a division of Red Hat >>>>>> http://bill.burkecentral.com >>>>>>=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 >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping Identity >>>=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 From nobody Mon Sep 15 13:49:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BE61A874A for ; Mon, 15 Sep 2014 13:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 ylKXDYXXJ5SN for ; Mon, 15 Sep 2014 13:49:52 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019361A026E for ; Mon, 15 Sep 2014 13:49:29 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id f51so4715670qge.31 for ; Mon, 15 Sep 2014 13:49:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=QKL2r5/WhoXZTjFqrc7+k6pgXq3qshDlN5U+gm7iHa8=; b=iKy+9CxiKg0plGTt/KSg1C4+wj5d18ggOjzkI5PazE4riX1d3MJoufo3SPuEEjZYlb JrYVyknQC6/WNdANlZsLTb42ci6ZEK6gmGmENjrLKBsIJjL5LCpiocI6B1wTLK4IKqVl 3d34kHjakBc8eS2AzSlk1GTNHpxc32vg7dOF2g58e7QxEfgeKdYqijCPoBvUuOH6eEhd MIJ3H6wybrSuAherxM+R9OHwNw8B4m2tFYCr39v+nmByYnPCdiV6QJHhEwNj1+jAdCuw q0+eDYraHKdbb26mUkUZkI1ipvB47c33aGaOxoI5Ot2rrX1mEyDMOUwyb6ZSUdLwjBBl ZpWg== X-Gm-Message-State: ALoCoQnOsTtjoeHUZH+Xtdx5LCbLjkKRP2171ccbh3ZyZ1O7Ym0ooM4WEKkjIgOBwBEjVJCLaGzs X-Received: by 10.224.15.201 with SMTP id l9mr34352442qaa.27.1410814167261; Mon, 15 Sep 2014 13:49:27 -0700 (PDT) Received: from [172.20.10.11] ([201.220.242.40]) by mx.google.com with ESMTPSA id 8sm10401163qab.12.2014.09.15.13.49.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 13:49:26 -0700 (PDT) References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-C38B72A9-B094-4EFE-BA71-8C751E00F3AA; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: John Bradley Date: Mon, 15 Sep 2014 17:48:22 -0300 To: Phil Hunt Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3d1fcXB76zsi5x_bdb8-CTIcfSQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:49:55 -0000 --Apple-Mail-C38B72A9-B094-4EFE-BA71-8C751E00F3AA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, but a redirect to a registered redirect_uri may still leak information i= n the referrer or fragment.=20 That is the point Antonio is trying to make.=20 It is not a open redirect but might be used as part of an attack on someone.= =20 John B.=20 Sent from my iPhone > On Sep 15, 2014, at 5:43 PM, Phil Hunt wrote: >=20 > If a server accepts a URL from a client to be used as a redirect that the s= erver doesn=E2=80=99t recognize or is not registered, that is an open redire= ct. >=20 > The specification does no allow open-redirects, it considers this a mis-co= nfiguration. >=20 > Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >>=20 >> There may be a problem with semantics in this discussion.=20 >>=20 >> There is a redirect performed by athe authorization endpoint to a fixed u= ri that is pre registered with the authorization server without user prompti= ng.=20 >>=20 >> That probably doesn't fit the strict definition of a open redirector.=20 >>=20 >> It may however create similar security issues in situations with relative= ly open registration of clients.=20 >>=20 >> The largest issues are that the browser might leak information across the= redirect in the fragment or referrer. That has been used in attacks agains= t Facebook in the past.=20 >>=20 >> This is no where near the end of the world, however we need to look at t= he security considerations and see if we can provide better advice to implem= entors. In some cases returning a error to the browser may be best. =20 >>=20 >> I don't think we need to go so far as not returning any error to the clie= nt under any circumstance.=20 >>=20 >> John B.=20 >>=20 >> Sent from my iPhone >>=20 >>> On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: >>>=20 >>> Simply not true. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote: >>>>=20 >>>> hi *, >>>>=20 >>>> my understanding is that there is a rough consensus that if an OAuth Pr= ovider follows rfc6749 verbatim will end up having an open redirector. >>>> My next question would be now, is there anything we can do to raise som= e awareness about this issue? >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt = wrote: >>>>>=20 >>>>> I am convinced about the issue in the use case Antonio provided but I h= ope not to close the door on returning errors to known and trusted clients. N= ot sure anymore if that's possible though because the distinction can't be "= registered"... >>>>>=20 >>>>> Hans. >>>>>=20 >>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>> hi Bill >>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>>>>>>=20 >>>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM p= roject. Thanks Antonio. What convinced me was that the user is probably ex= pecting a login screen. Since there is this expectation, it might make it a= little easier for the attacker to convince the user that a spoofed login sc= reen is real. I know this issue can only happen with unrestricted registrat= ion, but, IMO, this proposed change doesn't really have much of an effect on= usability and is even backward compatible with the current RFC. >>>>>>>=20 >>>>>>> Wouldn't it better though to never do a redirect on an invalid reque= st and just display an error page? >>>>>>=20 >>>>>> thanks for sharing your thoughts :). Display an error 400 is what Goo= gle does :) >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> antonio >>>>>>=20 >>>>>>>=20 >>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>> Hi Hans, >>>>>>>>=20 >>>>>>>> I really fail to see how this can be addressed at registration time= for cases where registration is unrestricted (namely all the big Providers)= >>>>>>>>=20 >>>>>>>> regards >>>>>>>>=20 >>>>>>>> antonio >>>>>>>>=20 >>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>>>>=20 >>>>>>>>> Classifying like this must also mean that consent should not be st= ored until the client is considered (admin) trusted, and admin policy would i= nterfere with user policy. >>>>>>>>>=20 >>>>>>>>> IMHO the security consideration would apply only to dynamically re= gistered clients where registration is unrestricted; any other form would in= volve some form of admin/user approval at registration time, overcoming the c= oncern at authorization time: there's no auto-redirect flow possible for unk= nown clients. >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>> I think this advice isn't a bad idea, though it's of course up to= the AS >>>>>>>>>> what an "untrusted" client really is. In practice, this is someth= ing >>>>>>>>>> that was registered by a non-sysadmin type person, either a dynam= ically >>>>>>>>>> registered client or something available through self-service >>>>>>>>>> registration of some type. It's also reasonable that a client, ev= en >>>>>>>>>> dynamically registered, would be considered "trusted" if enough t= ime has >>>>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> hi again *, >>>>>>>>>>>=20 >>>>>>>>>>> after thinking a bit further IMHO an alternative for the untrust= ed >>>>>>>>>>> clients can also be to always present the consent screen (at lea= st >>>>>>>>>>> once) before any redirect. >>>>>>>>>>> Namely all providers I have seen show the consent screen if all t= he >>>>>>>>>>> request parameters are correct and if the user accepts the redir= ect >>>>>>>>>>> happens. >>>>>>>>>>> If one of the parameter (with the exclusion of the client id an= d >>>>>>>>>>> redirect uri that are handled differently as for spec) is wrong t= hough >>>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>>=20 >>>>>>>>>>> WDYT? >>>>>>>>>>>=20 >>>>>>>>>>> regards >>>>>>>>>>>=20 >>>>>>>>>>> antonio >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Well, >>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>> let=E2=80=99s talk about real use cases, namely e.g. Google , Fa= cebook , >>>>>>>>>>>> etc.. is that dynamic client registration? I do not know=E2=80=A6= :) >>>>>>>>>>>>=20 >>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>> Would this deserve some =E2=80=9Cspec adjustment=E2=80=9D ? I m= ean there is a reason >>>>>>>>>>>> if Google is by choice =E2=80=9Cviolating=E2=80=9D the spec rig= ht? (I assume to avoid >>>>>>>>>>>> open redirect=E2=80=A6) >>>>>>>>>>>> But other implementers do follow the spec hence they have this o= pen >>>>>>>>>>>> redirector=E2=80=A6 and this is not nice IMHO... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Is your concern clients that were registered using dynamic c= lient >>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> yes >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I think your issue is then with the trust model of dynamic cli= ent >>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec (an= d the >>>>>>>>>>>>> concept is not even part of the core spec), but unless you wan= t >>>>>>>>>>>>> everything to be open (which typically would not be the case),= then >>>>>>>>>>>>> it would involve approval somewhere in the process before the c= lient >>>>>>>>>>>>> is registered. Without dynamic client registration that approv= al is >>>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Otherwise the positive case is returning a response to a val= id URL >>>>>>>>>>>>>>> that belongs to a client that was registered explicitly by t= he >>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> well AFAIK the resource owner doesn=E2=80=99t register client= s=E2=80=A6 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> roles can collapse in use cases especially when using dynamic c= lient >>>>>>>>>>>>> registration >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> and the negative case is returning an error to that same URL= . >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> the difference is the consent screen=E2=80=A6 in the positive= case you need >>>>>>>>>>>>>> to approve an app.. for the error case no approval is needed,= ,, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> why? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> because the client and thus the fixed URL are explicitly appro= ved at >>>>>>>>>>>>> some point >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hans. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: why w= ould you >>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provided= and >>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope i= s >>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> as specified below in the positive case (namely when the co= rrect >>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via th= e consent >>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker= . >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client registra= tions with >>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a c= lient >>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration step= that >>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. I= t would be >>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time=E2=80= =A6. >>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, name= ly >>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> *400.* That=E2=80=99s an error. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the sp= ec so >>>>>>>>>>>>>>>>>> far=E2=80=A6. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in= >>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulner= able >>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mis= matching >>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missin= g or >>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource ow= ner of the >>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-age= nt to the >>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if t= he >>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding t= he >>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection U= RI >>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendi= x B >>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Now let=E2=80=99s assume this. >>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am r= edirected >>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&clien= t_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dh= ttp://attacker.com >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters a= re >>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>> doesn=E2=80=99t apply since the resource owner MUST ap= prove the app >>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than re= direct >>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.= 1 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com = | Ping >>>>>>>>>>>>> Identity >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> -- >>>>>>> Bill Burke >>>>>>> JBoss, a division of Red Hat >>>>>>> http://bill.burkecentral.com >>>>>>>=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 >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>=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 --Apple-Mail-C38B72A9-B094-4EFE-BA71-8C751E00F3AA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQwOTE1MjA0ODIzWjAjBgkqhkiG9w0BCQQxFgQUZyO2ORf9umj4/v5f IGBDbEVu5WMwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAD6krH5tsP4oGOYy2ONwLVoZZ9N/2hrShLJdPDOZbIoHv1SBP jAvLMBod2gBWIHuYCCEjhyx6XMooUUDkspM+2ggtqpoU5+ZOOgp9U6H3l6sqn3AQqC1w8GXM67ez epP04OxWFMs2DCEP6El+1tTGG/zOph6LR29rBuCnlPRX78PzSIOVKfZCw8X3tZi2+ARAHHcQGNBF KSfIf6IedLcLWsyhF5J6z0ZCtxHQMrzoNDirbGXu7x7ctCM3Oan3DebsnTRL9g/pim6572pQgKQH qYgOOpVQNPP4u+FsmqU/v1f8Wcan8y4s/mAV4tT0YuQ2LXywci33dxsOVoheEAAfvQAAAAAAAA== --Apple-Mail-C38B72A9-B094-4EFE-BA71-8C751E00F3AA-- From nobody Mon Sep 15 13:52:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4288F1A8752 for ; Mon, 15 Sep 2014 13:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 qY9arol5ccTE for ; Mon, 15 Sep 2014 13:52:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0054.outbound.protection.outlook.com [65.55.169.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5389C1A874D for ; Mon, 15 Sep 2014 13:52:29 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 15 Sep 2014 20:52:25 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.125]) with mapi id 15.00.1024.012; Mon, 15 Sep 2014 20:52:25 +0000 From: Antonio Sanso To: Phil Hunt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgBGs+4CAAAiDgIAABXsAgAAL1wCAAAKvgA== Date: Mon, 15 Sep 2014 20:52:24 +0000 Message-ID: <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> In-Reply-To: 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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03355EE97E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(51444003)(52604005)(51704005)(479174003)(199003)(24454002)(377454003)(77096002)(33656002)(106116001)(76482001)(99286002)(77982001)(15975445006)(15202345003)(83322001)(79102001)(82746002)(4396001)(105586002)(106356001)(99396002)(93886004)(85306004)(95666004)(101416001)(110136001)(19580395003)(15395725005)(36756003)(76176999)(19580405001)(87936001)(86362001)(74662001)(64706001)(92726001)(21056001)(97736003)(81542001)(66066001)(81342001)(46102001)(20776003)(2656002)(80022001)(15974865002)(16601075003)(85852003)(54356999)(50986999)(83072002)(83716003)(587094003)(107046002)(90102001)(74502001)(104396001)(387795003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <64CC4253688CEA43B9A1F4D950F5A440@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/N4G4FFT5OlA-j6XFZoLNSO14V18 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:52:34 -0000 The problem is that a malicious client can register a malicious redirect ur= i and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as= previously discussed) regards antonio On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: > If a server accepts a URL from a client to be used as a redirect that the= server doesn=92t recognize or is not registered, that is an open redirect. >=20 > The specification does no allow open-redirects, it considers this a mis-c= onfiguration. >=20 > Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >=20 >> There may be a problem with semantics in this discussion.=20 >>=20 >> There is a redirect performed by athe authorization endpoint to a fixed = uri that is pre registered with the authorization server without user promp= ting.=20 >>=20 >> That probably doesn't fit the strict definition of a open redirector.=20 >>=20 >> It may however create similar security issues in situations with relativ= ely open registration of clients.=20 >>=20 >> The largest issues are that the browser might leak information across th= e redirect in the fragment or referrer. That has been used in attacks agai= nst Facebook in the past.=20 >>=20 >> This is no where near the end of the world, however we need to look at = the security considerations and see if we can provide better advice to impl= ementors. In some cases returning a error to the browser may be best. =20 >>=20 >> I don't think we need to go so far as not returning any error to the cli= ent under any circumstance.=20 >>=20 >> John B.=20 >>=20 >> Sent from my iPhone >>=20 >>> On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: >>>=20 >>> Simply not true. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote: >>>>=20 >>>> hi *, >>>>=20 >>>> my understanding is that there is a rough consensus that if an OAuth P= rovider follows rfc6749 verbatim will end up having an open redirector. >>>> My next question would be now, is there anything we can do to raise so= me awareness about this issue? >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrote: >>>>>=20 >>>>> I am convinced about the issue in the use case Antonio provided but I= hope not to close the door on returning errors to known and trusted client= s. Not sure anymore if that's possible though because the distinction can't= be "registered"... >>>>>=20 >>>>> Hans. >>>>>=20 >>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>> hi Bill >>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>>>>>>=20 >>>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM = project. Thanks Antonio. What convinced me was that the user is probably = expecting a login screen. Since there is this expectation, it might make i= t a little easier for the attacker to convince the user that a spoofed logi= n screen is real. I know this issue can only happen with unrestricted regi= stration, but, IMO, this proposed change doesn't really have much of an eff= ect on usability and is even backward compatible with the current RFC. >>>>>>>=20 >>>>>>> Wouldn't it better though to never do a redirect on an invalid requ= est and just display an error page? >>>>>>=20 >>>>>> thanks for sharing your thoughts :). Display an error 400 is what Go= ogle does :) >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> antonio >>>>>>=20 >>>>>>>=20 >>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>> Hi Hans, >>>>>>>>=20 >>>>>>>> I really fail to see how this can be addressed at registration tim= e for cases where registration is unrestricted (namely all the big Provider= s) >>>>>>>>=20 >>>>>>>> regards >>>>>>>>=20 >>>>>>>> antonio >>>>>>>>=20 >>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>>>>=20 >>>>>>>>> Classifying like this must also mean that consent should not be s= tored until the client is considered (admin) trusted, and admin policy woul= d interfere with user policy. >>>>>>>>>=20 >>>>>>>>> IMHO the security consideration would apply only to dynamically r= egistered clients where registration is unrestricted; any other form would = involve some form of admin/user approval at registration time, overcoming t= he concern at authorization time: there's no auto-redirect flow possible fo= r unknown clients. >>>>>>>>>=20 >>>>>>>>> Hans. >>>>>>>>>=20 >>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>> I think this advice isn't a bad idea, though it's of course up t= o the AS >>>>>>>>>> what an "untrusted" client really is. In practice, this is somet= hing >>>>>>>>>> that was registered by a non-sysadmin type person, either a dyna= mically >>>>>>>>>> registered client or something available through self-service >>>>>>>>>> registration of some type. It's also reasonable that a client, e= ven >>>>>>>>>> dynamically registered, would be considered "trusted" if enough = time has >>>>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> hi again *, >>>>>>>>>>>=20 >>>>>>>>>>> after thinking a bit further IMHO an alternative for the untrus= ted >>>>>>>>>>> clients can also be to always present the consent screen (at le= ast >>>>>>>>>>> once) before any redirect. >>>>>>>>>>> Namely all providers I have seen show the consent screen if all= the >>>>>>>>>>> request parameters are correct and if the user accepts the redi= rect >>>>>>>>>>> happens. >>>>>>>>>>> If one of the parameter (with the exclusion of the client id a= nd >>>>>>>>>>> redirect uri that are handled differently as for spec) is wrong= though >>>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>>=20 >>>>>>>>>>> WDYT? >>>>>>>>>>>=20 >>>>>>>>>>> regards >>>>>>>>>>>=20 >>>>>>>>>>> antonio >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Well, >>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , Facebo= ok , >>>>>>>>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>>>>>>>=20 >>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there i= s a reason >>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I assu= me to avoid >>>>>>>>>>>> open redirect=85) >>>>>>>>>>>> But other implementers do follow the spec hence they have this= open >>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Is your concern clients that were registered using dynamic = client >>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> yes >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I think your issue is then with the trust model of dynamic cl= ient >>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec (a= nd the >>>>>>>>>>>>> concept is not even part of the core spec), but unless you wa= nt >>>>>>>>>>>>> everything to be open (which typically would not be the case)= , then >>>>>>>>>>>>> it would involve approval somewhere in the process before the= client >>>>>>>>>>>>> is registered. Without dynamic client registration that appro= val is >>>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Otherwise the positive case is returning a response to a va= lid URL >>>>>>>>>>>>>>> that belongs to a client that was registered explicitly by = the >>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> roles can collapse in use cases especially when using dynamic= client >>>>>>>>>>>>> registration >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> and the negative case is returning an error to that same UR= L. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> the difference is the consent screen=85 in the positive case= you need >>>>>>>>>>>>>> to approve an app.. for the error case no approval is needed= ,,, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> why? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> because the client and thus the fixed URL are explicitly appr= oved at >>>>>>>>>>>>> some point >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hans. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: why = would you >>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provide= d and >>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope = is >>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> as specified below in the positive case (namely when the c= orrect >>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via t= he consent >>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacke= r. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client registr= ations with >>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a= client >>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration ste= p that >>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. = It would be >>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time=85= . >>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, nam= ely >>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the s= pec so >>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid = in >>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulne= rable >>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mi= smatching >>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missi= ng or >>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource o= wner of the >>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-ag= ent to the >>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if= the >>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding= the >>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection = URI >>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppend= ix B >>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am = redirected >>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&clie= nt_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri= =3Dhttp://attacker.com >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters = are >>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve= the app >>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than r= edirect >>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2= .1 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>>>>>>> Identity >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> -- >>>>>>> Bill Burke >>>>>>> JBoss, a division of Red Hat >>>>>>> http://bill.burkecentral.com >>>>>>>=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 >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>=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 From nobody Mon Sep 15 14:09:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8C81A873C for ; Mon, 15 Sep 2014 14:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 FuHKj1mt9ZJC for ; Mon, 15 Sep 2014 14:08:52 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B453B1A875D for ; Mon, 15 Sep 2014 14:08:37 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8FL8Xx4013206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Sep 2014 21:08:34 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FL8OLD011446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2014 21:08:28 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FL8MEe011394; Mon, 15 Sep 2014 21:08:23 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Sep 2014 14:08:19 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> Date: Mon, 15 Sep 2014 14:08:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9CE06872-7B8C-4272-8D48-DCC02881CEA3@oracle.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> To: Antonio Sanso X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tKX1IdIuP8uX4r2758go6UqEcB0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:08:57 -0000 I=92m not sure I understand why this is an OAuth protocol problem? If you are starting with a false client with a false registration, = everything down stream is likely invalid.=20 This seems like a registration curation (whitelisting) problem. This is a bit like saying, how can I prove that the application on this = jail-broken phone is legitimate? Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 15, 2014, at 1:52 PM, Antonio Sanso wrote: > The problem is that a malicious client can register a malicious = redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 = does the rest (as previously discussed) >=20 > regards >=20 > antonio >=20 > On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: >=20 >> If a server accepts a URL from a client to be used as a redirect that = the server doesn=92t recognize or is not registered, that is an open = redirect. >>=20 >> The specification does no allow open-redirects, it considers this a = mis-configuration. >>=20 >> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >>=20 >>> There may be a problem with semantics in this discussion.=20 >>>=20 >>> There is a redirect performed by athe authorization endpoint to a = fixed uri that is pre registered with the authorization server without = user prompting.=20 >>>=20 >>> That probably doesn't fit the strict definition of a open = redirector.=20 >>>=20 >>> It may however create similar security issues in situations with = relatively open registration of clients.=20 >>>=20 >>> The largest issues are that the browser might leak information = across the redirect in the fragment or referrer. That has been used in = attacks against Facebook in the past.=20 >>>=20 >>> This is no where near the end of the world, however we need to look = at the security considerations and see if we can provide better advice = to implementors. In some cases returning a error to the browser may be = best. =20 >>>=20 >>> I don't think we need to go so far as not returning any error to the = client under any circumstance.=20 >>>=20 >>> John B.=20 >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt = wrote: >>>>=20 >>>> Simply not true. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso = wrote: >>>>>=20 >>>>> hi *, >>>>>=20 >>>>> my understanding is that there is a rough consensus that if an = OAuth Provider follows rfc6749 verbatim will end up having an open = redirector. >>>>> My next question would be now, is there anything we can do to = raise some awareness about this issue? >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt = wrote: >>>>>>=20 >>>>>> I am convinced about the issue in the use case Antonio provided = but I hope not to close the door on returning errors to known and = trusted clients. Not sure anymore if that's possible though because the = distinction can't be "registered"... >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>> hi Bill >>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke = wrote: >>>>>>>>=20 >>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our = IDM project. Thanks Antonio. What convinced me was that the user is = probably expecting a login screen. Since there is this expectation, it = might make it a little easier for the attacker to convince the user that = a spoofed login screen is real. I know this issue can only happen with = unrestricted registration, but, IMO, this proposed change doesn't really = have much of an effect on usability and is even backward compatible with = the current RFC. >>>>>>>>=20 >>>>>>>> Wouldn't it better though to never do a redirect on an invalid = request and just display an error page? >>>>>>>=20 >>>>>>> thanks for sharing your thoughts :). Display an error 400 is = what Google does :) >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>> Hi Hans, >>>>>>>>>=20 >>>>>>>>> I really fail to see how this can be addressed at registration = time for cases where registration is unrestricted (namely all the big = Providers) >>>>>>>>>=20 >>>>>>>>> regards >>>>>>>>>=20 >>>>>>>>> antonio >>>>>>>>>=20 >>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt = wrote: >>>>>>>>>>=20 >>>>>>>>>> Classifying like this must also mean that consent should not = be stored until the client is considered (admin) trusted, and admin = policy would interfere with user policy. >>>>>>>>>>=20 >>>>>>>>>> IMHO the security consideration would apply only to = dynamically registered clients where registration is unrestricted; any = other form would involve some form of admin/user approval at = registration time, overcoming the concern at authorization time: there's = no auto-redirect flow possible for unknown clients. >>>>>>>>>>=20 >>>>>>>>>> Hans. >>>>>>>>>>=20 >>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>> I think this advice isn't a bad idea, though it's of course = up to the AS >>>>>>>>>>> what an "untrusted" client really is. In practice, this is = something >>>>>>>>>>> that was registered by a non-sysadmin type person, either a = dynamically >>>>>>>>>>> registered client or something available through = self-service >>>>>>>>>>> registration of some type. It's also reasonable that a = client, even >>>>>>>>>>> dynamically registered, would be considered "trusted" if = enough time has >>>>>>>>>>> passed and enough users have used it without things blowing = up. >>>>>>>>>>>=20 >>>>>>>>>>> -- Justin >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> hi again *, >>>>>>>>>>>>=20 >>>>>>>>>>>> after thinking a bit further IMHO an alternative for the = untrusted >>>>>>>>>>>> clients can also be to always present the consent screen = (at least >>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>> Namely all providers I have seen show the consent screen if = all the >>>>>>>>>>>> request parameters are correct and if the user accepts the = redirect >>>>>>>>>>>> happens. >>>>>>>>>>>> If one of the parameter (with the exclusion of the client = id and >>>>>>>>>>>> redirect uri that are handled differently as for spec) is = wrong though >>>>>>>>>>>> the redirect happens without the consent screen being = shown.. >>>>>>>>>>>>=20 >>>>>>>>>>>> WDYT? >>>>>>>>>>>>=20 >>>>>>>>>>>> regards >>>>>>>>>>>>=20 >>>>>>>>>>>> antonio >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Well, >>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , = Facebook , >>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know=85 = :) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean = there is a reason >>>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I = assume to avoid >>>>>>>>>>>>> open redirect=85) >>>>>>>>>>>>> But other implementers do follow the spec hence they have = this open >>>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt = >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Is your concern clients that were registered using = dynamic client >>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think your issue is then with the trust model of = dynamic client >>>>>>>>>>>>>> registration; that is left out of scope of the dynreg = spec (and the >>>>>>>>>>>>>> concept is not even part of the core spec), but unless = you want >>>>>>>>>>>>>> everything to be open (which typically would not be the = case), then >>>>>>>>>>>>>> it would involve approval somewhere in the process before = the client >>>>>>>>>>>>>> is registered. Without dynamic client registration that = approval is >>>>>>>>>>>>>> admin based or resource owner based, depending on use = case. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to = a valid URL >>>>>>>>>>>>>>>> that belongs to a client that was registered explicitly = by the >>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register = clients=85 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> roles can collapse in use cases especially when using = dynamic client >>>>>>>>>>>>>> registration >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> and the negative case is returning an error to that = same URL. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> the difference is the consent screen=85 in the positive = case you need >>>>>>>>>>>>>>> to approve an app.. for the error case no approval is = needed,,, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly = approved at >>>>>>>>>>>>>> some point >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: = why would you >>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is = provided and >>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid = scope is >>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> as specified below in the positive case (namely when = the correct >>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app = via the consent >>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley = >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the = attacker. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client = registrations with >>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates = that a client >>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration = step that >>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with = you. It would be >>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration = time=85. >>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, = namely >>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in = the spec so >>>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke = >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be = valid in >>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states = this. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are = vulnerable >>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, = or mismatching >>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is = missing or >>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the = resource owner of the >>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the = user-agent to the >>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request = or if the >>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by = adding the >>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the = redirection URI >>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, = perAppendix B >>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> = > >>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com = >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I = am redirected >>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the = parameters are >>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST = approve the app >>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather = than redirect >>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> [0] = https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com = >>>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>> OAuth@ietf.org = >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com = >>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>> hzandbelt@pingidentity.com = | Ping >>>>>>>>>>>>>> Identity >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Bill Burke >>>>>>>> JBoss, a division of Red Hat >>>>>>>> http://bill.burkecentral.com >>>>>>>>=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 >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>=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 From nobody Mon Sep 15 14:12:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9731A1A8745 for ; Mon, 15 Sep 2014 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 76Ozbq4XUuhB for ; Mon, 15 Sep 2014 14:12:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0099.outbound.protection.outlook.com [65.55.169.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB591A877C for ; Mon, 15 Sep 2014 14:11:58 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 15 Sep 2014 21:11:56 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.125]) with mapi id 15.00.1024.012; Mon, 15 Sep 2014 21:11:56 +0000 From: Antonio Sanso To: Phil Hunt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgBGs+4CAAAiDgIAABXsAgAAL1wCAAAKvgIAABE6AgAABJgA= Date: Mon, 15 Sep 2014 21:11:56 +0000 Message-ID: <10793893-1B2B-4317-8B09-C055145865F1@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> <9CE06872-7B8C-4272-8D48-DCC02881CEA3@oracle.com> In-Reply-To: <9CE06872-7B8C-4272-8D48-DCC02881CEA3@oracle.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: [178.83.47.250] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03355EE97E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174003)(199003)(51444003)(377454003)(51704005)(52604005)(189002)(2656002)(101416001)(80022001)(81542001)(19580405001)(74502001)(106356001)(4396001)(15974865002)(15202345003)(19580395003)(36756003)(33656002)(93886004)(81342001)(83322001)(97736003)(74662001)(85306004)(110136001)(107046002)(99286002)(21056001)(105586002)(15395725005)(86362001)(95666004)(16601075003)(83072002)(77096002)(85852003)(76482001)(83716003)(87936001)(66066001)(99396002)(76176999)(46102001)(587094003)(79102001)(50986999)(20776003)(64706001)(54356999)(77982001)(92726001)(106116001)(90102001)(15975445006)(82746002)(104396001)(579004)(387795003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <94C1C762F86063479A1835B86F0C2423@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_u-8MPM0KWN0XjCEIZLanIxhiCg Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:12:21 -0000 On Sep 15, 2014, at 11:08 PM, Phil Hunt wrote: > I=92m not sure I understand why this is an OAuth protocol problem? >=20 > If you are starting with a false client with a false registration, everyt= hing down stream is likely invalid.=20 registration is not false. But the client can be a malicious one=85.=20 >=20 > This seems like a registration curation (whitelisting) problem. there is not way a whitelist can cover all the malicious uris.. regards antonio >=20 > This is a bit like saying, how can I prove that the application on this j= ail-broken phone is legitimate? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Sep 15, 2014, at 1:52 PM, Antonio Sanso wrote: >=20 >> The problem is that a malicious client can register a malicious redirect= uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest = (as previously discussed) >>=20 >> regards >>=20 >> antonio >>=20 >> On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: >>=20 >>> If a server accepts a URL from a client to be used as a redirect that t= he server doesn=92t recognize or is not registered, that is an open redirec= t. >>>=20 >>> The specification does no allow open-redirects, it considers this a mis= -configuration. >>>=20 >>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >>>=20 >>>> There may be a problem with semantics in this discussion.=20 >>>>=20 >>>> There is a redirect performed by athe authorization endpoint to a fixe= d uri that is pre registered with the authorization server without user pro= mpting.=20 >>>>=20 >>>> That probably doesn't fit the strict definition of a open redirector.= =20 >>>>=20 >>>> It may however create similar security issues in situations with relat= ively open registration of clients.=20 >>>>=20 >>>> The largest issues are that the browser might leak information across = the redirect in the fragment or referrer. That has been used in attacks ag= ainst Facebook in the past.=20 >>>>=20 >>>> This is no where near the end of the world, however we need to look a= t the security considerations and see if we can provide better advice to im= plementors. In some cases returning a error to the browser may be best. =20 >>>>=20 >>>> I don't think we need to go so far as not returning any error to the c= lient under any circumstance.=20 >>>>=20 >>>> John B.=20 >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: >>>>>=20 >>>>> Simply not true. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote= : >>>>>>=20 >>>>>> hi *, >>>>>>=20 >>>>>> my understanding is that there is a rough consensus that if an OAuth= Provider follows rfc6749 verbatim will end up having an open redirector. >>>>>> My next question would be now, is there anything we can do to raise = some awareness about this issue? >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> antonio >>>>>>=20 >>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrote: >>>>>>>=20 >>>>>>> I am convinced about the issue in the use case Antonio provided but= I hope not to close the door on returning errors to known and trusted clie= nts. Not sure anymore if that's possible though because the distinction can= 't be "registered"... >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>>> hi Bill >>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>>>>>>>>=20 >>>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our ID= M project. Thanks Antonio. What convinced me was that the user is probabl= y expecting a login screen. Since there is this expectation, it might make= it a little easier for the attacker to convince the user that a spoofed lo= gin screen is real. I know this issue can only happen with unrestricted re= gistration, but, IMO, this proposed change doesn't really have much of an e= ffect on usability and is even backward compatible with the current RFC. >>>>>>>>>=20 >>>>>>>>> Wouldn't it better though to never do a redirect on an invalid re= quest and just display an error page? >>>>>>>>=20 >>>>>>>> thanks for sharing your thoughts :). Display an error 400 is what = Google does :) >>>>>>>>=20 >>>>>>>> regards >>>>>>>>=20 >>>>>>>> antonio >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>>> Hi Hans, >>>>>>>>>>=20 >>>>>>>>>> I really fail to see how this can be addressed at registration t= ime for cases where registration is unrestricted (namely all the big Provid= ers) >>>>>>>>>>=20 >>>>>>>>>> regards >>>>>>>>>>=20 >>>>>>>>>> antonio >>>>>>>>>>=20 >>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Classifying like this must also mean that consent should not be= stored until the client is considered (admin) trusted, and admin policy wo= uld interfere with user policy. >>>>>>>>>>>=20 >>>>>>>>>>> IMHO the security consideration would apply only to dynamically= registered clients where registration is unrestricted; any other form woul= d involve some form of admin/user approval at registration time, overcoming= the concern at authorization time: there's no auto-redirect flow possible = for unknown clients. >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>>> I think this advice isn't a bad idea, though it's of course up= to the AS >>>>>>>>>>>> what an "untrusted" client really is. In practice, this is som= ething >>>>>>>>>>>> that was registered by a non-sysadmin type person, either a dy= namically >>>>>>>>>>>> registered client or something available through self-service >>>>>>>>>>>> registration of some type. It's also reasonable that a client,= even >>>>>>>>>>>> dynamically registered, would be considered "trusted" if enoug= h time has >>>>>>>>>>>> passed and enough users have used it without things blowing up= . >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Justin >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> hi again *, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> after thinking a bit further IMHO an alternative for the untr= usted >>>>>>>>>>>>> clients can also be to always present the consent screen (at = least >>>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>>> Namely all providers I have seen show the consent screen if a= ll the >>>>>>>>>>>>> request parameters are correct and if the user accepts the re= direct >>>>>>>>>>>>> happens. >>>>>>>>>>>>> If one of the parameter (with the exclusion of the client id= and >>>>>>>>>>>>> redirect uri that are handled differently as for spec) is wro= ng though >>>>>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> regards >>>>>>>>>>>>>=20 >>>>>>>>>>>>> antonio >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Well, >>>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , Face= book , >>>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know=85 = :) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there= is a reason >>>>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I as= sume to avoid >>>>>>>>>>>>>> open redirect=85) >>>>>>>>>>>>>> But other implementers do follow the spec hence they have th= is open >>>>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Is your concern clients that were registered using dynami= c client >>>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think your issue is then with the trust model of dynamic = client >>>>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec = (and the >>>>>>>>>>>>>>> concept is not even part of the core spec), but unless you = want >>>>>>>>>>>>>>> everything to be open (which typically would not be the cas= e), then >>>>>>>>>>>>>>> it would involve approval somewhere in the process before t= he client >>>>>>>>>>>>>>> is registered. Without dynamic client registration that app= roval is >>>>>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to a = valid URL >>>>>>>>>>>>>>>>> that belongs to a client that was registered explicitly b= y the >>>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients= =85 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> roles can collapse in use cases especially when using dynam= ic client >>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> and the negative case is returning an error to that same = URL. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> the difference is the consent screen=85 in the positive ca= se you need >>>>>>>>>>>>>>>> to approve an app.. for the error case no approval is need= ed,,, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly ap= proved at >>>>>>>>>>>>>>> some point >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: wh= y would you >>>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provi= ded and >>>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scop= e is >>>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> as specified below in the positive case (namely when the= correct >>>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via= the consent >>>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attac= ker. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client regis= trations with >>>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that= a client >>>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration s= tep that >>>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you= . It would be >>>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time= =85. >>>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, n= amely >>>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the= spec so >>>>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be vali= d in >>>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this= . >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vul= nerable >>>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or = mismatching >>>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is mis= sing or >>>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource= owner of the >>>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-= agent to the >>>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or = if the >>>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by addi= ng the >>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirectio= n URI >>>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppe= ndix B >>>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I a= m redirected >>>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&cl= ient_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri= =3Dhttp://attacker.com >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameter= s are >>>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST appro= ve the app >>>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than= redirect >>>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1= .2.1 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Bill Burke >>>>>>>>> JBoss, a division of Red Hat >>>>>>>>> http://bill.burkecentral.com >>>>>>>>>=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 >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>=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 >=20 From nobody Mon Sep 15 14:15:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23661A8761 for ; Mon, 15 Sep 2014 14:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RP_MATCHES_RCVD=-1.652] autolearn=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 8xQn2-EM5gOR for ; Mon, 15 Sep 2014 14:15:34 -0700 (PDT) Received: from smtptsrv1.mitre.org (smtptsrv1.mitre.org [192.52.194.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7397B1A874F for ; Mon, 15 Sep 2014 14:15:34 -0700 (PDT) Received: from smtptsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F0669C50CCE; Mon, 15 Sep 2014 17:15:33 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtptsrv1.mitre.org (Postfix) with ESMTP id CAA2DC50CC7; Mon, 15 Sep 2014 17:15:33 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Mon, 15 Sep 2014 17:15:33 -0400 From: "Richer, Justin P." To: Antonio Sanso Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgBGs+4CAAEuRgIAABXsAgAAL1wCAAAKNAIAABnWA Date: Mon, 15 Sep 2014 21:15:32 +0000 Message-ID: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> In-Reply-To: <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.23] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kke6rB9yRWh80gIb4BZ-UJ0ylBM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:15:38 -0000 As we discussed before: This isn't really an open redirection in the classi= cal sense since nothing gets leaked and the URI is tied back to a known (al= beit malicious) client registration. And I thought the clear solution was t= o have an AS not automatically redirect to an untrusted client in error con= ditions, where "untrusted" is defined by the AS with guidance. If anything = this is a security considerations addendum. -- Justin On Sep 15, 2014, at 4:52 PM, Antonio Sanso wrote: > The problem is that a malicious client can register a malicious redirect = uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (= as previously discussed) >=20 > regards >=20 > antonio >=20 > On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: >=20 >> If a server accepts a URL from a client to be used as a redirect that th= e server doesn=92t recognize or is not registered, that is an open redirect= . >>=20 >> The specification does no allow open-redirects, it considers this a mis-= configuration. >>=20 >> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >>=20 >>> There may be a problem with semantics in this discussion.=20 >>>=20 >>> There is a redirect performed by athe authorization endpoint to a fixed= uri that is pre registered with the authorization server without user prom= pting.=20 >>>=20 >>> That probably doesn't fit the strict definition of a open redirector.=20 >>>=20 >>> It may however create similar security issues in situations with relati= vely open registration of clients.=20 >>>=20 >>> The largest issues are that the browser might leak information across t= he redirect in the fragment or referrer. That has been used in attacks aga= inst Facebook in the past.=20 >>>=20 >>> This is no where near the end of the world, however we need to look at= the security considerations and see if we can provide better advice to imp= lementors. In some cases returning a error to the browser may be best. =20 >>>=20 >>> I don't think we need to go so far as not returning any error to the cl= ient under any circumstance.=20 >>>=20 >>> John B.=20 >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: >>>>=20 >>>> Simply not true. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote: >>>>>=20 >>>>> hi *, >>>>>=20 >>>>> my understanding is that there is a rough consensus that if an OAuth = Provider follows rfc6749 verbatim will end up having an open redirector. >>>>> My next question would be now, is there anything we can do to raise s= ome awareness about this issue? >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrote: >>>>>>=20 >>>>>> I am convinced about the issue in the use case Antonio provided but = I hope not to close the door on returning errors to known and trusted clien= ts. Not sure anymore if that's possible though because the distinction can'= t be "registered"... >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>> hi Bill >>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>>>>>>>=20 >>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM= project. Thanks Antonio. What convinced me was that the user is probably= expecting a login screen. Since there is this expectation, it might make = it a little easier for the attacker to convince the user that a spoofed log= in screen is real. I know this issue can only happen with unrestricted reg= istration, but, IMO, this proposed change doesn't really have much of an ef= fect on usability and is even backward compatible with the current RFC. >>>>>>>>=20 >>>>>>>> Wouldn't it better though to never do a redirect on an invalid req= uest and just display an error page? >>>>>>>=20 >>>>>>> thanks for sharing your thoughts :). Display an error 400 is what G= oogle does :) >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>> Hi Hans, >>>>>>>>>=20 >>>>>>>>> I really fail to see how this can be addressed at registration ti= me for cases where registration is unrestricted (namely all the big Provide= rs) >>>>>>>>>=20 >>>>>>>>> regards >>>>>>>>>=20 >>>>>>>>> antonio >>>>>>>>>=20 >>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>>>>>=20 >>>>>>>>>> Classifying like this must also mean that consent should not be = stored until the client is considered (admin) trusted, and admin policy wou= ld interfere with user policy. >>>>>>>>>>=20 >>>>>>>>>> IMHO the security consideration would apply only to dynamically = registered clients where registration is unrestricted; any other form would= involve some form of admin/user approval at registration time, overcoming = the concern at authorization time: there's no auto-redirect flow possible f= or unknown clients. >>>>>>>>>>=20 >>>>>>>>>> Hans. >>>>>>>>>>=20 >>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>> I think this advice isn't a bad idea, though it's of course up = to the AS >>>>>>>>>>> what an "untrusted" client really is. In practice, this is some= thing >>>>>>>>>>> that was registered by a non-sysadmin type person, either a dyn= amically >>>>>>>>>>> registered client or something available through self-service >>>>>>>>>>> registration of some type. It's also reasonable that a client, = even >>>>>>>>>>> dynamically registered, would be considered "trusted" if enough= time has >>>>>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>>>>=20 >>>>>>>>>>> -- Justin >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> hi again *, >>>>>>>>>>>>=20 >>>>>>>>>>>> after thinking a bit further IMHO an alternative for the untru= sted >>>>>>>>>>>> clients can also be to always present the consent screen (at l= east >>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>> Namely all providers I have seen show the consent screen if al= l the >>>>>>>>>>>> request parameters are correct and if the user accepts the red= irect >>>>>>>>>>>> happens. >>>>>>>>>>>> If one of the parameter (with the exclusion of the client id = and >>>>>>>>>>>> redirect uri that are handled differently as for spec) is wron= g though >>>>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>>>=20 >>>>>>>>>>>> WDYT? >>>>>>>>>>>>=20 >>>>>>>>>>>> regards >>>>>>>>>>>>=20 >>>>>>>>>>>> antonio >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Well, >>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , Faceb= ook , >>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know=85 := ) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there = is a reason >>>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I ass= ume to avoid >>>>>>>>>>>>> open redirect=85) >>>>>>>>>>>>> But other implementers do follow the spec hence they have thi= s open >>>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Is your concern clients that were registered using dynamic= client >>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think your issue is then with the trust model of dynamic c= lient >>>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec (= and the >>>>>>>>>>>>>> concept is not even part of the core spec), but unless you w= ant >>>>>>>>>>>>>> everything to be open (which typically would not be the case= ), then >>>>>>>>>>>>>> it would involve approval somewhere in the process before th= e client >>>>>>>>>>>>>> is registered. Without dynamic client registration that appr= oval is >>>>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to a v= alid URL >>>>>>>>>>>>>>>> that belongs to a client that was registered explicitly by= the >>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> roles can collapse in use cases especially when using dynami= c client >>>>>>>>>>>>>> registration >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> and the negative case is returning an error to that same U= RL. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> the difference is the consent screen=85 in the positive cas= e you need >>>>>>>>>>>>>>> to approve an app.. for the error case no approval is neede= d,,, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly app= roved at >>>>>>>>>>>>>> some point >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: why= would you >>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provid= ed and >>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope= is >>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> as specified below in the positive case (namely when the = correct >>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via = the consent >>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attack= er. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client regist= rations with >>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that = a client >>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration st= ep that >>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you.= It would be >>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time= =85. >>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, na= mely >>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the = spec so >>>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid= in >>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vuln= erable >>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or m= ismatching >>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is miss= ing or >>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource = owner of the >>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-a= gent to the >>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or i= f the >>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by addin= g the >>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection= URI >>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppen= dix B >>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am= redirected >>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&cli= ent_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri= =3Dhttp://attacker.com >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters= are >>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approv= e the app >>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than = redirect >>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.= 2.1 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>>>>>>>> Identity >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Bill Burke >>>>>>>> JBoss, a division of Red Hat >>>>>>>> http://bill.burkecentral.com >>>>>>>>=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 >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Sep 15 14:22:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7FF1A8798 for ; Mon, 15 Sep 2014 14:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 ierNs-uo_BEE for ; Mon, 15 Sep 2014 14:22:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D631A8791 for ; Mon, 15 Sep 2014 14:22:01 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8FLLwUC028357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Sep 2014 21:21:59 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FLLvpg014365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2014 21:21:58 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s8FLLtNs029598; Mon, 15 Sep 2014 21:21:56 GMT Received: from [192.168.1.197] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Sep 2014 14:21:54 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <10793893-1B2B-4317-8B09-C055145865F1@adobe.com> Date: Mon, 15 Sep 2014 14:21:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com! > <9CE06872-7B8C-4272-8D48-DCC02881CEA3@oracle.com> <10793893-1B2B-4317-8B09-C055145865F1@adobe.com> To: Antonio Sanso X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TxfPmvemdqcuOw3s1_CCU0oI_cQ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:22:19 -0000 So, let=92s say you have a client that has =93obtained=94 a client Id = from a legit registered client. How does the malicious client exploit = the previously registered URL if the server only redirects to that URL? Are you referring to the case Nat Sakimura previously raised where = mobile app stores do not enforce custom URL registrations? Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 15, 2014, at 2:11 PM, Antonio Sanso wrote: >=20 > On Sep 15, 2014, at 11:08 PM, Phil Hunt wrote: >=20 >> I=92m not sure I understand why this is an OAuth protocol problem? >>=20 >> If you are starting with a false client with a false registration, = everything down stream is likely invalid.=20 >=20 > registration is not false. But the client can be a malicious one=85.=20= >=20 >=20 >>=20 >> This seems like a registration curation (whitelisting) problem. >=20 > there is not way a whitelist can cover all the malicious uris.. >=20 > regards >=20 > antonio >=20 >>=20 >> This is a bit like saying, how can I prove that the application on = this jail-broken phone is legitimate? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Sep 15, 2014, at 1:52 PM, Antonio Sanso wrote: >>=20 >>> The problem is that a malicious client can register a malicious = redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 = does the rest (as previously discussed) >>>=20 >>> regards >>>=20 >>> antonio >>>=20 >>> On Sep 15, 2014, at 10:43 PM, Phil Hunt = wrote: >>>=20 >>>> If a server accepts a URL from a client to be used as a redirect = that the server doesn=92t recognize or is not registered, that is an = open redirect. >>>>=20 >>>> The specification does no allow open-redirects, it considers this a = mis-configuration. >>>>=20 >>>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 15, 2014, at 1:00 PM, John Bradley = wrote: >>>>=20 >>>>> There may be a problem with semantics in this discussion.=20 >>>>>=20 >>>>> There is a redirect performed by athe authorization endpoint to a = fixed uri that is pre registered with the authorization server without = user prompting.=20 >>>>>=20 >>>>> That probably doesn't fit the strict definition of a open = redirector.=20 >>>>>=20 >>>>> It may however create similar security issues in situations with = relatively open registration of clients.=20 >>>>>=20 >>>>> The largest issues are that the browser might leak information = across the redirect in the fragment or referrer. That has been used in = attacks against Facebook in the past.=20 >>>>>=20 >>>>> This is no where near the end of the world, however we need to = look at the security considerations and see if we can provide better = advice to implementors. In some cases returning a error to the browser = may be best. =20 >>>>>=20 >>>>> I don't think we need to go so far as not returning any error to = the client under any circumstance.=20 >>>>>=20 >>>>> John B.=20 >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt = wrote: >>>>>>=20 >>>>>> Simply not true. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso = wrote: >>>>>>>=20 >>>>>>> hi *, >>>>>>>=20 >>>>>>> my understanding is that there is a rough consensus that if an = OAuth Provider follows rfc6749 verbatim will end up having an open = redirector. >>>>>>> My next question would be now, is there anything we can do to = raise some awareness about this issue? >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt = wrote: >>>>>>>>=20 >>>>>>>> I am convinced about the issue in the use case Antonio provided = but I hope not to close the door on returning errors to known and = trusted clients. Not sure anymore if that's possible though because the = distinction can't be "registered"... >>>>>>>>=20 >>>>>>>> Hans. >>>>>>>>=20 >>>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>>>> hi Bill >>>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke = wrote: >>>>>>>>>>=20 >>>>>>>>>> FWIW, Antonio convinced me and I'm going to change this in = our IDM project. Thanks Antonio. What convinced me was that the user = is probably expecting a login screen. Since there is this expectation, = it might make it a little easier for the attacker to convince the user = that a spoofed login screen is real. I know this issue can only happen = with unrestricted registration, but, IMO, this proposed change doesn't = really have much of an effect on usability and is even backward = compatible with the current RFC. >>>>>>>>>>=20 >>>>>>>>>> Wouldn't it better though to never do a redirect on an = invalid request and just display an error page? >>>>>>>>>=20 >>>>>>>>> thanks for sharing your thoughts :). Display an error 400 is = what Google does :) >>>>>>>>>=20 >>>>>>>>> regards >>>>>>>>>=20 >>>>>>>>> antonio >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>>>> Hi Hans, >>>>>>>>>>>=20 >>>>>>>>>>> I really fail to see how this can be addressed at = registration time for cases where registration is unrestricted (namely = all the big Providers) >>>>>>>>>>>=20 >>>>>>>>>>> regards >>>>>>>>>>>=20 >>>>>>>>>>> antonio >>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Classifying like this must also mean that consent should = not be stored until the client is considered (admin) trusted, and admin = policy would interfere with user policy. >>>>>>>>>>>>=20 >>>>>>>>>>>> IMHO the security consideration would apply only to = dynamically registered clients where registration is unrestricted; any = other form would involve some form of admin/user approval at = registration time, overcoming the concern at authorization time: there's = no auto-redirect flow possible for unknown clients. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hans. >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>>>> I think this advice isn't a bad idea, though it's of = course up to the AS >>>>>>>>>>>>> what an "untrusted" client really is. In practice, this is = something >>>>>>>>>>>>> that was registered by a non-sysadmin type person, either = a dynamically >>>>>>>>>>>>> registered client or something available through = self-service >>>>>>>>>>>>> registration of some type. It's also reasonable that a = client, even >>>>>>>>>>>>> dynamically registered, would be considered "trusted" if = enough time has >>>>>>>>>>>>> passed and enough users have used it without things = blowing up. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- Justin >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso = >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> hi again *, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> after thinking a bit further IMHO an alternative for the = untrusted >>>>>>>>>>>>>> clients can also be to always present the consent screen = (at least >>>>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>>>> Namely all providers I have seen show the consent screen = if all the >>>>>>>>>>>>>> request parameters are correct and if the user accepts = the redirect >>>>>>>>>>>>>> happens. >>>>>>>>>>>>>> If one of the parameter (with the exclusion of the = client id and >>>>>>>>>>>>>> redirect uri that are handled differently as for spec) is = wrong though >>>>>>>>>>>>>> the redirect happens without the consent screen being = shown.. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> regards >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso = >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Well, >>>>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , = Facebook , >>>>>>>>>>>>>>> etc.. is that dynamic client registration? I do not = know=85 :) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean = there is a reason >>>>>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? = (I assume to avoid >>>>>>>>>>>>>>> open redirect=85) >>>>>>>>>>>>>>> But other implementers do follow the spec hence they = have this open >>>>>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt = >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Is your concern clients that were registered using = dynamic client >>>>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I think your issue is then with the trust model of = dynamic client >>>>>>>>>>>>>>>> registration; that is left out of scope of the dynreg = spec (and the >>>>>>>>>>>>>>>> concept is not even part of the core spec), but unless = you want >>>>>>>>>>>>>>>> everything to be open (which typically would not be the = case), then >>>>>>>>>>>>>>>> it would involve approval somewhere in the process = before the client >>>>>>>>>>>>>>>> is registered. Without dynamic client registration that = approval is >>>>>>>>>>>>>>>> admin based or resource owner based, depending on use = case. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Otherwise the positive case is returning a response = to a valid URL >>>>>>>>>>>>>>>>>> that belongs to a client that was registered = explicitly by the >>>>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register = clients=85 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> roles can collapse in use cases especially when using = dynamic client >>>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> and the negative case is returning an error to that = same URL. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> the difference is the consent screen=85 in the = positive case you need >>>>>>>>>>>>>>>>> to approve an app.. for the error case no approval is = needed,,, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> because the client and thus the fixed URL are = explicitly approved at >>>>>>>>>>>>>>>> some point >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Let me try and approach this from a different = angle: why would you >>>>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is = provided and >>>>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid = scope is >>>>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> as specified below in the positive case (namely when = the correct >>>>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app = via the consent >>>>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley = >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the = attacker. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client = registrations with >>>>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates = that a client >>>>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> I think that if anything it may be the = registration step that >>>>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with = you. It would be >>>>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration = time=85. >>>>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from = Google, namely >>>>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in = the spec so >>>>>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke = >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be = valid in >>>>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states = this. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are = vulnerable >>>>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, = or mismatching >>>>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is = missing or >>>>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the = resource owner of the >>>>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the = user-agent to the >>>>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request = or if the >>>>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or = invalid >>>>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by = adding the >>>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the = redirection URI >>>>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, = perAppendix B >>>>>>>>>>>>>>>>>>>>>>>> = : >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> = > >>>>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com = >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope = I am redirected >>>>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the = parameters are >>>>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST = approve the app >>>>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather = than redirect >>>>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> [0] = https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com = >>>>>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org = >>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical = Architect >>>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com = >>>>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com = | Ping >>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Bill Burke >>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>=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 >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>=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 >>=20 >=20 From nobody Mon Sep 15 14:57:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349CA1A87CD for ; Mon, 15 Sep 2014 14:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 hNq9rPJvlcin for ; Mon, 15 Sep 2014 14:56:56 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908391A87AE for ; Mon, 15 Sep 2014 14:56:56 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id i17so5081206qcy.31 for ; Mon, 15 Sep 2014 14:56:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=3RcpblnJakJBdNIMgo/wqIBTBfilA07CPUxW5EGzp84=; b=bgJLshkgIe9sMicM/lqUwdDuxpPKtowyX7rYZzHxnFIWsyAreAkRMwZ2QYSwxba+Xz AkLn0M3q4IowT3cENXCFi9SAa5Ui5a9s6dj0rYuW1q4GFqdawsSVy/e3oGy4ak7vcXYZ /3UBvVtIGc5GVmu0Vxwuief4TNhIfbdiHXTh2LRIA62p2VPLuixxxt5DpFb70eJ/+4vJ E/dTwq3GFSmqQMwCB1+FxmXXzRpQlWeEZVBW9CYWkgppOlYl87Hujx40x09qO3NbJ8dK 7RETWbqlhc4maCilmtSig/gR336NV1jg5NhI0j27QLY7bWlTeVoJs4ArqL117tfM8BdF mP+w== X-Gm-Message-State: ALoCoQmGCdZypDgARnPus0IPas+XH0mJwJQwKsQhju934mkKYKvw5tIVjxlm5aunbZW+YoX77Fqx X-Received: by 10.140.93.43 with SMTP id c40mr37142646qge.10.1410818215506; Mon, 15 Sep 2014 14:56:55 -0700 (PDT) Received: from [192.168.0.90] ([186.67.38.12]) by mx.google.com with ESMTPSA id o6sm10506488qag.40.2014.09.15.14.56.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 14:56:54 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_71F69E6C-9E66-4380-9F82-B82D5217ED20"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Mon, 15 Sep 2014 18:56:32 -0300 Message-Id: <29F9628D-EBD4-4C32-BD8B-4FC520ADAED0@ve7jtb.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> To: "Justin P. Richer" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pfltORkioBII4oHRhTgmwq0pc6k Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:57:00 -0000 --Apple-Mail=_71F69E6C-9E66-4380-9F82-B82D5217ED20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Something might get leaked by the browser, the fragment may be leaked by = the browser if the redirect URI doesn't contain a fragment in some = browsers. A simple security consideration might be to add a fragment to the = redirect_uri in the error case. The other way that information may leak is via the referrer. If there = is only one redirect by the AS the URI that was sent to the AS including = all the parameters would still be available to the target. A simple fix is to redirect to a intermediate page before redirecting to = the registered client, this clears the referrer. It is true that nothing is leaked in the redirect_uri itself but there = are side channels in the browser that need to be considered. The fixes are quite simple implementation issues and don't break = anything. Yes if the client is trusted then this is probably unnecessary but = wouldn't hurt anything. John B. PS for OAuth this would really only be exploitable if exact redirect_uri = matching is not happening. =20 As I am a inherently bad person, I could hypothetically use this to = attack a AS that is doing domain level pattern matching of redirect URI = and has a public client in the same domain as the AS. I should also note that domains using pattern matching are also = vulnerable if they allow other sorts of user hosted content like blog = posts that pull in images and leak the referrer. So we do probably need to provide some advice. John B. On Sep 15, 2014, at 6:15 PM, Richer, Justin P. = wrote: > As we discussed before: This isn't really an open redirection in the = classical sense since nothing gets leaked and the URI is tied back to a = known (albeit malicious) client registration. And I thought the clear = solution was to have an AS not automatically redirect to an untrusted = client in error conditions, where "untrusted" is defined by the AS with = guidance. If anything this is a security considerations addendum. >=20 > -- Justin >=20 > On Sep 15, 2014, at 4:52 PM, Antonio Sanso wrote: >=20 >> The problem is that a malicious client can register a malicious = redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 = does the rest (as previously discussed) >>=20 >> regards >>=20 >> antonio >>=20 >> On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: >>=20 >>> If a server accepts a URL from a client to be used as a redirect = that the server doesn=92t recognize or is not registered, that is an = open redirect. >>>=20 >>> The specification does no allow open-redirects, it considers this a = mis-configuration. >>>=20 >>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >>>=20 >>>> There may be a problem with semantics in this discussion.=20 >>>>=20 >>>> There is a redirect performed by athe authorization endpoint to a = fixed uri that is pre registered with the authorization server without = user prompting.=20 >>>>=20 >>>> That probably doesn't fit the strict definition of a open = redirector.=20 >>>>=20 >>>> It may however create similar security issues in situations with = relatively open registration of clients.=20 >>>>=20 >>>> The largest issues are that the browser might leak information = across the redirect in the fragment or referrer. That has been used in = attacks against Facebook in the past.=20 >>>>=20 >>>> This is no where near the end of the world, however we need to = look at the security considerations and see if we can provide better = advice to implementors. In some cases returning a error to the browser = may be best. =20 >>>>=20 >>>> I don't think we need to go so far as not returning any error to = the client under any circumstance.=20 >>>>=20 >>>> John B.=20 >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt = wrote: >>>>>=20 >>>>> Simply not true. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso = wrote: >>>>>>=20 >>>>>> hi *, >>>>>>=20 >>>>>> my understanding is that there is a rough consensus that if an = OAuth Provider follows rfc6749 verbatim will end up having an open = redirector. >>>>>> My next question would be now, is there anything we can do to = raise some awareness about this issue? >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> antonio >>>>>>=20 >>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt = wrote: >>>>>>>=20 >>>>>>> I am convinced about the issue in the use case Antonio provided = but I hope not to close the door on returning errors to known and = trusted clients. Not sure anymore if that's possible though because the = distinction can't be "registered"... >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>>> hi Bill >>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke = wrote: >>>>>>>>>=20 >>>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our = IDM project. Thanks Antonio. What convinced me was that the user is = probably expecting a login screen. Since there is this expectation, it = might make it a little easier for the attacker to convince the user that = a spoofed login screen is real. I know this issue can only happen with = unrestricted registration, but, IMO, this proposed change doesn't really = have much of an effect on usability and is even backward compatible with = the current RFC. >>>>>>>>>=20 >>>>>>>>> Wouldn't it better though to never do a redirect on an invalid = request and just display an error page? >>>>>>>>=20 >>>>>>>> thanks for sharing your thoughts :). Display an error 400 is = what Google does :) >>>>>>>>=20 >>>>>>>> regards >>>>>>>>=20 >>>>>>>> antonio >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>>> Hi Hans, >>>>>>>>>>=20 >>>>>>>>>> I really fail to see how this can be addressed at = registration time for cases where registration is unrestricted (namely = all the big Providers) >>>>>>>>>>=20 >>>>>>>>>> regards >>>>>>>>>>=20 >>>>>>>>>> antonio >>>>>>>>>>=20 >>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Classifying like this must also mean that consent should not = be stored until the client is considered (admin) trusted, and admin = policy would interfere with user policy. >>>>>>>>>>>=20 >>>>>>>>>>> IMHO the security consideration would apply only to = dynamically registered clients where registration is unrestricted; any = other form would involve some form of admin/user approval at = registration time, overcoming the concern at authorization time: there's = no auto-redirect flow possible for unknown clients. >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>>> I think this advice isn't a bad idea, though it's of course = up to the AS >>>>>>>>>>>> what an "untrusted" client really is. In practice, this is = something >>>>>>>>>>>> that was registered by a non-sysadmin type person, either a = dynamically >>>>>>>>>>>> registered client or something available through = self-service >>>>>>>>>>>> registration of some type. It's also reasonable that a = client, even >>>>>>>>>>>> dynamically registered, would be considered "trusted" if = enough time has >>>>>>>>>>>> passed and enough users have used it without things blowing = up. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Justin >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>>> > wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> hi again *, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> after thinking a bit further IMHO an alternative for the = untrusted >>>>>>>>>>>>> clients can also be to always present the consent screen = (at least >>>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>>> Namely all providers I have seen show the consent screen = if all the >>>>>>>>>>>>> request parameters are correct and if the user accepts the = redirect >>>>>>>>>>>>> happens. >>>>>>>>>>>>> If one of the parameter (with the exclusion of the client = id and >>>>>>>>>>>>> redirect uri that are handled differently as for spec) is = wrong though >>>>>>>>>>>>> the redirect happens without the consent screen being = shown.. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> regards >>>>>>>>>>>>>=20 >>>>>>>>>>>>> antonio >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso = >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Well, >>>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , = Facebook , >>>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know=85= :) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean = there is a reason >>>>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I = assume to avoid >>>>>>>>>>>>>> open redirect=85) >>>>>>>>>>>>>> But other implementers do follow the spec hence they have = this open >>>>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt = >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Is your concern clients that were registered using = dynamic client >>>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think your issue is then with the trust model of = dynamic client >>>>>>>>>>>>>>> registration; that is left out of scope of the dynreg = spec (and the >>>>>>>>>>>>>>> concept is not even part of the core spec), but unless = you want >>>>>>>>>>>>>>> everything to be open (which typically would not be the = case), then >>>>>>>>>>>>>>> it would involve approval somewhere in the process = before the client >>>>>>>>>>>>>>> is registered. Without dynamic client registration that = approval is >>>>>>>>>>>>>>> admin based or resource owner based, depending on use = case. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to = a valid URL >>>>>>>>>>>>>>>>> that belongs to a client that was registered = explicitly by the >>>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register = clients=85 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> roles can collapse in use cases especially when using = dynamic client >>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> and the negative case is returning an error to that = same URL. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> the difference is the consent screen=85 in the positive = case you need >>>>>>>>>>>>>>>> to approve an app.. for the error case no approval is = needed,,, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly = approved at >>>>>>>>>>>>>>> some point >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: = why would you >>>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is = provided and >>>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid = scope is >>>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> as specified below in the positive case (namely when = the correct >>>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app = via the consent >>>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley = >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the = attacker. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client = registrations with >>>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates = that a client >>>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> I think that if anything it may be the = registration step that >>>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with = you. It would be >>>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration = time=85. >>>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from = Google, namely >>>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in = the spec so >>>>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke = >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be = valid in >>>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states = this. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are = vulnerable >>>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, = or mismatching >>>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is = missing or >>>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the = resource owner of the >>>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the = user-agent to the >>>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request = or if the >>>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or = invalid >>>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by = adding the >>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the = redirection URI >>>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, = perAppendix B >>>>>>>>>>>>>>>>>>>>>>> = : >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> = > >>>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com = >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope = I am redirected >>>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> = http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298K= Pj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com= >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the = parameters are >>>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST = approve the app >>>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather = than redirect >>>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> [0] = https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com = >>>>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>> OAuth@ietf.org = >>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com = >>>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com = | >>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandbelt@pingidentity.com = | Ping >>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Bill Burke >>>>>>>>> JBoss, a division of Red Hat >>>>>>>>> http://bill.burkecentral.com >>>>>>>>>=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 >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>=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 >> _______________________________________________ >> 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=_71F69E6C-9E66-4380-9F82-B82D5217ED20 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MTUyMTU2MzNaMCMGCSqGSIb3DQEJBDEWBBTOSqhkX1EIrQnFBBhftV6S ws9C7jCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCjvWuhq6z4HgLsM6Owo/iPaKYnB+PSY8NuAc9ucppL5tZpRzSB+HVL AYlY2EsfJFvvi4I1t8Yq8DCqhKWHi43ur2ONKn0jRzenxUEYNZwbVGorcMzLx7Cxt4HwpX6H6jo7 6Iv3emAlj4n3JTrarGQETDVTkK6gkBEH+ku1x+N/+hkEe/6Q1DhkHhoSjKRC6peOitaIun6aC0FK PGyf3sHacqXr9y0Lb9PDaAje6WSYaa2TAs4y2l5yjvkKLlIsRoE52dU2ScL/RIxL0v0PNqgZAdCE Cv345kCnYfxz9HOjX4fPLgTnJzizTK9bq8iFuNsPk0sNOtDJmCU/uLQbqM0IAAAAAAAA --Apple-Mail=_71F69E6C-9E66-4380-9F82-B82D5217ED20-- From nobody Mon Sep 15 22:44:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326891A02D0 for ; Mon, 15 Sep 2014 22:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 pJYuFGU0Vhzo for ; Mon, 15 Sep 2014 22:44:44 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E121A02C1 for ; Mon, 15 Sep 2014 22:44:43 -0700 (PDT) Received: from [80.187.109.132] (helo=[10.24.70.244]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1XTlZ8-0006Vn-BG; Tue, 16 Sep 2014 07:44:39 +0200 Date: Tue, 16 Sep 2014 07:44:35 +0200 Message-ID: <5nofjvf5jjbcqjdv9bmdgdg0.1410846275737@email.android.com> Importance: normal From: Torsten Lodderstedt To: "Richer, Justin P." , Antonio Sanso MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_17908325804640" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TQhXUw3fCtCRJdxfD-OWhIxdGsI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 05:44:51 -0000 ----_com.android.email_17908325804640 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB0aGluayBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFkZGVuZHVtIG1ha2VzIHNlbnNlLgoK cmVnYXJkcyzCoApUb3JzdGVuLsKgCgo8ZGl2Pi0tLS0tLS0tIFVyc3Byw7xuZ2xpY2hlIE5hY2hy aWNodCAtLS0tLS0tLTwvZGl2PjxkaXY+Vm9uOiAiUmljaGVyLCBKdXN0aW4gUC4iIDxqcmljaGVy QG1pdHJlLm9yZz4gPC9kaXY+PGRpdj5EYXR1bToxNS4wOS4yMDE0ICAyMzoxNSAgKEdNVCswMTow MCkgPC9kaXY+PGRpdj5BbjogQW50b25pbyBTYW5zbyA8YXNhbnNvQGFkb2JlLmNvbT4gPC9kaXY+ PGRpdj5DYzogb2F1dGhAaWV0Zi5vcmcgPC9kaXY+PGRpdj5CZXRyZWZmOiBSZTogW09BVVRILVdH XSBvcGVuIHJlZGlyZWN0IGluIHJmYzY3NDkgPC9kaXY+PGRpdj4KPC9kaXY+QXMgd2UgZGlzY3Vz c2VkIGJlZm9yZTogVGhpcyBpc24ndCByZWFsbHkgYW4gb3BlbiByZWRpcmVjdGlvbiBpbiB0aGUg Y2xhc3NpY2FsIHNlbnNlIHNpbmNlIG5vdGhpbmcgZ2V0cyBsZWFrZWQgYW5kIHRoZSBVUkkgaXMg dGllZCBiYWNrIHRvIGEga25vd24gKGFsYmVpdCBtYWxpY2lvdXMpIGNsaWVudCByZWdpc3RyYXRp b24uIEFuZCBJIHRob3VnaHQgdGhlIGNsZWFyIHNvbHV0aW9uIHdhcyB0byBoYXZlIGFuIEFTIG5v dCBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRvIGFuIHVudHJ1c3RlZCBjbGllbnQgaW4gZXJyb3Ig Y29uZGl0aW9ucywgd2hlcmUgInVudHJ1c3RlZCIgaXMgZGVmaW5lZCBieSB0aGUgQVMgd2l0aCBn dWlkYW5jZS4gSWYgYW55dGhpbmcgdGhpcyBpcyBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFk ZGVuZHVtLgoKLS0gSnVzdGluCgpPbiBTZXAgMTUsIDIwMTQsIGF0IDQ6NTIgUE0sIEFudG9uaW8g U2Fuc28gPGFzYW5zb0BhZG9iZS5jb20+IHdyb3RlOgoKPiBUaGUgcHJvYmxlbSBpcyB0aGF0IGEg bWFsaWNpb3VzIGNsaWVudCBjYW4gcmVnaXN0ZXIgYSBtYWxpY2lvdXMgcmVkaXJlY3QgdXJpIGFu ZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTQuMS4yLjEgZG9l cyB0aGUgcmVzdCAoYXMgcHJldmlvdXNseSBkaXNjdXNzZWQpCj4gCj4gcmVnYXJkcwo+IAo+IGFu dG9uaW8KPiAKPiBPbiBTZXAgMTUsIDIwMTQsIGF0IDEwOjQzIFBNLCBQaGlsIEh1bnQgPHBoaWwu aHVudEBvcmFjbGUuY29tPiB3cm90ZToKPiAKPj4gSWYgYSBzZXJ2ZXIgYWNjZXB0cyBhIFVSTCBm cm9tIGEgY2xpZW50IHRvIGJlIHVzZWQgYXMgYSByZWRpcmVjdCB0aGF0IHRoZSBzZXJ2ZXIgZG9l c27igJl0IHJlY29nbml6ZSBvciBpcyBub3QgcmVnaXN0ZXJlZCwgdGhhdCBpcyBhbiBvcGVuIHJl ZGlyZWN0Lgo+PiAKPj4gVGhlIHNwZWNpZmljYXRpb24gZG9lcyBubyBhbGxvdyBvcGVuLXJlZGly ZWN0cywgaXQgY29uc2lkZXJzIHRoaXMgYSBtaXMtY29uZmlndXJhdGlvbi4KPj4gCj4+IFRha2Ug YSBsb29rIGF0IHNlY3Rpb25zIDMuMS4yLjIgYW5kIDEwLjE1IG9mIFJGQzY3NDkuCj4+IAo+PiBQ aGlsCj4+IAo+PiBAaW5kZXBlbmRlbnRpZAo+PiB3d3cuaW5kZXBlbmRlbnRpZC5jb20KPj4gcGhp bC5odW50QG9yYWNsZS5jb20KPj4gCj4+IAo+PiAKPj4gT24gU2VwIDE1LCAyMDE0LCBhdCAxOjAw IFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPiB3cm90ZToKPj4gCj4+PiBUaGVy ZSBtYXkgYmUgYSBwcm9ibGVtIHdpdGggc2VtYW50aWNzIGluIHRoaXMgZGlzY3Vzc2lvbi4gCj4+ PiAKPj4+IFRoZXJlIGlzIGEgcmVkaXJlY3QgcGVyZm9ybWVkIGJ5IGF0aGUgYXV0aG9yaXphdGlv biBlbmRwb2ludCB0byBhIGZpeGVkIHVyaSB0aGF0IGlzIHByZSByZWdpc3RlcmVkIHdpdGggdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIHdpdGhvdXQgdXNlciBwcm9tcHRpbmcuIAo+Pj4gCj4+PiBU aGF0IHByb2JhYmx5IGRvZXNuJ3QgZml0IHRoZSBzdHJpY3QgZGVmaW5pdGlvbiBvZiBhIG9wZW4g cmVkaXJlY3Rvci4gCj4+PiAKPj4+IEl0IG1heSBob3dldmVyIGNyZWF0ZSBzaW1pbGFyIHNlY3Vy aXR5IGlzc3VlcyBpbiBzaXR1YXRpb25zIHdpdGggcmVsYXRpdmVseSBvcGVuIHJlZ2lzdHJhdGlv biBvZiBjbGllbnRzLiAKPj4+IAo+Pj4gVGhlIGxhcmdlc3QgaXNzdWVzIGFyZSB0aGF0IHRoZSBi cm93c2VyIG1pZ2h0IGxlYWsgaW5mb3JtYXRpb24gYWNyb3NzIHRoZSByZWRpcmVjdCBpbiB0aGUg ZnJhZ21lbnQgb3IgcmVmZXJyZXIuICBUaGF0IGhhcyBiZWVuIHVzZWQgaW4gYXR0YWNrcyBhZ2Fp bnN0IEZhY2Vib29rIGluIHRoZSBwYXN0LiAKPj4+IAo+Pj4gVGhpcyBpcyBubyB3aGVyZSBuZWFy IHRoZSBlbmQgb2YgdGhlIHdvcmxkLCAgaG93ZXZlciB3ZSBuZWVkIHRvIGxvb2sgYXQgdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGFuZCBzZWUgaWYgd2UgY2FuIHByb3ZpZGUgYmV0dGVyIGFk dmljZSB0byBpbXBsZW1lbnRvcnMuICBJbiBzb21lIGNhc2VzIHJldHVybmluZyBhIGVycm9yIHRv IHRoZSBicm93c2VyIG1heSBiZSBiZXN0LiAgCj4+PiAKPj4+IEkgZG9uJ3QgdGhpbmsgd2UgbmVl ZCB0byBnbyBzbyBmYXIgYXMgbm90IHJldHVybmluZyBhbnkgZXJyb3IgdG8gdGhlIGNsaWVudCB1 bmRlciBhbnkgY2lyY3Vtc3RhbmNlLiAKPj4+IAo+Pj4gSm9obiBCLiAKPj4+IAo+Pj4gU2VudCBm cm9tIG15IGlQaG9uZQo+Pj4gCj4+Pj4gT24gU2VwIDE1LCAyMDE0LCBhdCA0OjQxIFBNLCBQaGls IEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPiB3cm90ZToKPj4+PiAKPj4+PiBTaW1wbHkgbm90 IHRydWUuCj4+Pj4gCj4+Pj4gUGhpbAo+Pj4+IAo+Pj4+IEBpbmRlcGVuZGVudGlkCj4+Pj4gd3d3 LmluZGVwZW5kZW50aWQuY29tCj4+Pj4gcGhpbC5odW50QG9yYWNsZS5jb20KPj4+PiAKPj4+PiAK Pj4+PiAKPj4+Pj4gT24gU2VwIDE1LCAyMDE0LCBhdCAxMjoxMCBQTSwgQW50b25pbyBTYW5zbyA8 YXNhbnNvQGFkb2JlLmNvbT4gd3JvdGU6Cj4+Pj4+IAo+Pj4+PiBoaSAqLAo+Pj4+PiAKPj4+Pj4g bXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZXJlIGlzIGEgcm91Z2ggY29uc2Vuc3VzIHRoYXQg aWYgYW4gT0F1dGggUHJvdmlkZXIgZm9sbG93cyByZmM2NzQ5IHZlcmJhdGltIHdpbGwgZW5kIHVw IGhhdmluZyBhbiBvcGVuIHJlZGlyZWN0b3IuCj4+Pj4+IE15IG5leHQgcXVlc3Rpb24gd291bGQg YmUgbm93LCBpcyB0aGVyZSBhbnl0aGluZyB3ZSBjYW4gZG8gdG8gcmFpc2Ugc29tZSBhd2FyZW5l c3MgYWJvdXQgdGhpcyBpc3N1ZT8KPj4+Pj4gCj4+Pj4+IHJlZ2FyZHMKPj4+Pj4gCj4+Pj4+IGFu dG9uaW8KPj4+Pj4gCj4+Pj4+PiBPbiBTZXAgNCwgMjAxNCwgYXQgMzoxNSBQTSwgSGFucyBaYW5k YmVsdCA8aHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb20+IHdyb3RlOgo+Pj4+Pj4gCj4+Pj4+PiBJ IGFtIGNvbnZpbmNlZCBhYm91dCB0aGUgaXNzdWUgaW4gdGhlIHVzZSBjYXNlIEFudG9uaW8gcHJv dmlkZWQgYnV0IEkgaG9wZSBub3QgdG8gY2xvc2UgdGhlIGRvb3Igb24gcmV0dXJuaW5nIGVycm9y cyB0byBrbm93biBhbmQgdHJ1c3RlZCBjbGllbnRzLiBOb3Qgc3VyZSBhbnltb3JlIGlmIHRoYXQn cyBwb3NzaWJsZSB0aG91Z2ggYmVjYXVzZSB0aGUgZGlzdGluY3Rpb24gY2FuJ3QgYmUgInJlZ2lz dGVyZWQiLi4uCj4+Pj4+PiAKPj4+Pj4+IEhhbnMuCj4+Pj4+PiAKPj4+Pj4+PiBPbiA5LzQvMTQs IDM6MDEgUE0sIEFudG9uaW8gU2Fuc28gd3JvdGU6Cj4+Pj4+Pj4gaGkgQmlsbAo+Pj4+Pj4+PiBP biBTZXAgNCwgMjAxNCwgYXQgMjo1MiBQTSwgQmlsbCBCdXJrZSA8YmJ1cmtlQHJlZGhhdC5jb20+ IHdyb3RlOgo+Pj4+Pj4+PiAKPj4+Pj4+Pj4gRldJVywgQW50b25pbyBjb252aW5jZWQgbWUgYW5k IEknbSBnb2luZyB0byBjaGFuZ2UgdGhpcyBpbiBvdXIgSURNIHByb2plY3QuICBUaGFua3MgQW50 b25pby4gIFdoYXQgY29udmluY2VkIG1lIHdhcyB0aGF0IHRoZSB1c2VyIGlzIHByb2JhYmx5IGV4 cGVjdGluZyBhIGxvZ2luIHNjcmVlbi4gIFNpbmNlIHRoZXJlIGlzIHRoaXMgZXhwZWN0YXRpb24s IGl0IG1pZ2h0IG1ha2UgaXQgYSBsaXR0bGUgZWFzaWVyIGZvciB0aGUgYXR0YWNrZXIgdG8gY29u dmluY2UgdGhlIHVzZXIgdGhhdCBhIHNwb29mZWQgbG9naW4gc2NyZWVuIGlzIHJlYWwuICBJIGtu b3cgdGhpcyBpc3N1ZSBjYW4gb25seSBoYXBwZW4gd2l0aCB1bnJlc3RyaWN0ZWQgcmVnaXN0cmF0 aW9uLCBidXQsIElNTywgdGhpcyBwcm9wb3NlZCBjaGFuZ2UgZG9lc24ndCByZWFsbHkgaGF2ZSBt dWNoIG9mIGFuIGVmZmVjdCBvbiB1c2FiaWxpdHkgYW5kIGlzIGV2ZW4gYmFja3dhcmQgY29tcGF0 aWJsZSB3aXRoIHRoZSBjdXJyZW50IFJGQy4KPj4+Pj4+Pj4gCj4+Pj4+Pj4+IFdvdWxkbid0IGl0 IGJldHRlciB0aG91Z2ggdG8gbmV2ZXIgZG8gYSByZWRpcmVjdCBvbiBhbiBpbnZhbGlkIHJlcXVl c3QgYW5kIGp1c3QgZGlzcGxheSBhbiBlcnJvciBwYWdlPwo+Pj4+Pj4+IAo+Pj4+Pj4+IHRoYW5r cyBmb3Igc2hhcmluZyB5b3VyIHRob3VnaHRzIDopLiBEaXNwbGF5IGFuIGVycm9yIDQwMCBpcyB3 aGF0IEdvb2dsZSBkb2VzIDopCj4+Pj4+Pj4gCj4+Pj4+Pj4gcmVnYXJkcwo+Pj4+Pj4+IAo+Pj4+ Pj4+IGFudG9uaW8KPj4+Pj4+PiAKPj4+Pj4+Pj4gCj4+Pj4+Pj4+PiBPbiA5LzQvMjAxNCAzOjUw IEFNLCBBbnRvbmlvIFNhbnNvIHdyb3RlOgo+Pj4+Pj4+Pj4gSGkgSGFucywKPj4+Pj4+Pj4+IAo+ Pj4+Pj4+Pj4gSSByZWFsbHkgZmFpbCB0byBzZWUgaG93IHRoaXMgY2FuIGJlIGFkZHJlc3NlZCBh dCByZWdpc3RyYXRpb24gdGltZSBmb3IgY2FzZXMgd2hlcmUgcmVnaXN0cmF0aW9uIGlzIHVucmVz dHJpY3RlZCAobmFtZWx5IGFsbCB0aGUgYmlnIFByb3ZpZGVycykKPj4+Pj4+Pj4+IAo+Pj4+Pj4+ Pj4gcmVnYXJkcwo+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+PiBhbnRvbmlvCj4+Pj4+Pj4+PiAKPj4+Pj4+ Pj4+PiBPbiBTZXAgNCwgMjAxNCwgYXQgOTo0NyBBTSwgSGFucyBaYW5kYmVsdCA8aHphbmRiZWx0 QHBpbmdpZGVudGl0eS5jb20+IHdyb3RlOgo+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+IENsYXNzaWZ5 aW5nIGxpa2UgdGhpcyBtdXN0IGFsc28gbWVhbiB0aGF0IGNvbnNlbnQgc2hvdWxkIG5vdCBiZSBz dG9yZWQgdW50aWwgdGhlIGNsaWVudCBpcyBjb25zaWRlcmVkIChhZG1pbikgdHJ1c3RlZCwgYW5k IGFkbWluIHBvbGljeSB3b3VsZCBpbnRlcmZlcmUgd2l0aCB1c2VyIHBvbGljeS4KPj4+Pj4+Pj4+ PiAKPj4+Pj4+Pj4+PiBJTUhPIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHdvdWxkIGFwcGx5 IG9ubHkgdG8gZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCBjbGllbnRzIHdoZXJlIHJlZ2lzdHJhdGlv biBpcyB1bnJlc3RyaWN0ZWQ7IGFueSBvdGhlciBmb3JtIHdvdWxkIGludm9sdmUgc29tZSBmb3Jt IG9mIGFkbWluL3VzZXIgYXBwcm92YWwgYXQgcmVnaXN0cmF0aW9uIHRpbWUsIG92ZXJjb21pbmcg dGhlIGNvbmNlcm4gYXQgYXV0aG9yaXphdGlvbiB0aW1lOiB0aGVyZSdzIG5vIGF1dG8tcmVkaXJl Y3QgZmxvdyBwb3NzaWJsZSBmb3IgdW5rbm93biBjbGllbnRzLgo+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+ Pj4+IEhhbnMuCj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+IE9uIDkvNC8xNCwgOTowNCBBTSwgUmlj aGVyLCBKdXN0aW4gUC4gd3JvdGU6Cj4+Pj4+Pj4+Pj4+IEkgdGhpbmsgdGhpcyBhZHZpY2UgaXNu J3QgYSBiYWQgaWRlYSwgdGhvdWdoIGl0J3Mgb2YgY291cnNlIHVwIHRvIHRoZSBBUwo+Pj4+Pj4+ Pj4+PiB3aGF0IGFuICJ1bnRydXN0ZWQiIGNsaWVudCByZWFsbHkgaXMuIEluIHByYWN0aWNlLCB0 aGlzIGlzIHNvbWV0aGluZwo+Pj4+Pj4+Pj4+PiB0aGF0IHdhcyByZWdpc3RlcmVkIGJ5IGEgbm9u LXN5c2FkbWluIHR5cGUgcGVyc29uLCBlaXRoZXIgYSBkeW5hbWljYWxseQo+Pj4+Pj4+Pj4+PiBy ZWdpc3RlcmVkIGNsaWVudCBvciBzb21ldGhpbmcgYXZhaWxhYmxlIHRocm91Z2ggc2VsZi1zZXJ2 aWNlCj4+Pj4+Pj4+Pj4+IHJlZ2lzdHJhdGlvbiBvZiBzb21lIHR5cGUuIEl0J3MgYWxzbyByZWFz b25hYmxlIHRoYXQgYSBjbGllbnQsIGV2ZW4KPj4+Pj4+Pj4+Pj4gZHluYW1pY2FsbHkgcmVnaXN0 ZXJlZCwgd291bGQgYmUgY29uc2lkZXJlZCAidHJ1c3RlZCIgaWYgZW5vdWdoIHRpbWUgaGFzCj4+ Pj4+Pj4+Pj4+IHBhc3NlZCBhbmQgZW5vdWdoIHVzZXJzIGhhdmUgdXNlZCBpdCB3aXRob3V0IHRo aW5ncyBibG93aW5nIHVwLgo+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4gLS0gSnVzdGluCj4+Pj4+ Pj4+Pj4+IAo+Pj4+Pj4+Pj4+PiBPbiBTZXAgNCwgMjAxNCwgYXQgMToyNiBBTSwgQW50b25pbyBT YW5zbyA8YXNhbnNvQGFkb2JlLmNvbQo+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmFzYW5zb0BhZG9iZS5j b20+PiB3cm90ZToKPj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+PiBoaSBhZ2FpbiAqLAo+Pj4+Pj4+ Pj4+Pj4gCj4+Pj4+Pj4+Pj4+PiBhZnRlciB0aGlua2luZyBhIGJpdCBmdXJ0aGVyIElNSE8gYW4g YWx0ZXJuYXRpdmUgZm9yIHRoZSB1bnRydXN0ZWQKPj4+Pj4+Pj4+Pj4+IGNsaWVudHMgY2FuIGFs c28gYmUgdG8gYWx3YXlzIHByZXNlbnQgdGhlIGNvbnNlbnQgc2NyZWVuIChhdCBsZWFzdAo+Pj4+ Pj4+Pj4+Pj4gb25jZSkgYmVmb3JlIGFueSByZWRpcmVjdC4KPj4+Pj4+Pj4+Pj4+IE5hbWVseSBh bGwgcHJvdmlkZXJzIEkgaGF2ZSBzZWVuIHNob3cgdGhlIGNvbnNlbnQgc2NyZWVuIGlmIGFsbCB0 aGUKPj4+Pj4+Pj4+Pj4+IHJlcXVlc3QgcGFyYW1ldGVycyBhcmUgY29ycmVjdCBhbmQgaWYgdGhl IHVzZXIgYWNjZXB0cyB0aGUgcmVkaXJlY3QKPj4+Pj4+Pj4+Pj4+IGhhcHBlbnMuCj4+Pj4+Pj4+ Pj4+PiBJZiBvbmUgb2YgdGhlIHBhcmFtZXRlciAgKHdpdGggdGhlIGV4Y2x1c2lvbiBvZiB0aGUg Y2xpZW50IGlkIGFuZAo+Pj4+Pj4+Pj4+Pj4gcmVkaXJlY3QgdXJpIHRoYXQgYXJlIGhhbmRsZWQg ZGlmZmVyZW50bHkgYXMgZm9yIHNwZWMpIGlzIHdyb25nIHRob3VnaAo+Pj4+Pj4+Pj4+Pj4gdGhl IHJlZGlyZWN0IGhhcHBlbnMgd2l0aG91dCB0aGUgY29uc2VudCBzY3JlZW4gYmVpbmcgc2hvd24u Lgo+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+PiBXRFlUPwo+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+ Pj4+PiByZWdhcmRzCj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+IGFudG9uaW8KPj4+Pj4+Pj4+ Pj4+IAo+Pj4+Pj4+Pj4+Pj4gT24gU2VwIDMsIDIwMTQsIGF0IDc6NTQgUE0sIEFudG9uaW8gU2Fu c28gPGFzYW5zb0BhZG9iZS5jb20KPj4+Pj4+Pj4+Pj4+IDxtYWlsdG86YXNhbnNvQGFkb2JlLmNv bT4+IHdyb3RlOgo+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4gV2VsbCwKPj4+Pj4+Pj4+Pj4+ PiBJIGRvIG5vdCBrbm93IGlmIHRoaXMgaXMgb25seSBkeW5hbWljIHJlZ2lzdHJhdGlvbi4uLgo+ Pj4+Pj4+Pj4+Pj4+IGxldOKAmXMgdGFsayBhYm91dCByZWFsIHVzZSBjYXNlcywgbmFtZWx5IGUu Zy4gR29vZ2xlICwgRmFjZWJvb2sgLAo+Pj4+Pj4+Pj4+Pj4+IGV0Yy4uIGlzIHRoYXQgZHluYW1p YyBjbGllbnQgcmVnaXN0cmF0aW9uPyBJIGRvIG5vdCBrbm934oCmIDopCj4+Pj4+Pj4+Pj4+Pj4g Cj4+Pj4+Pj4+Pj4+Pj4gU2FpZCB0aGF0IHdoYXQgdGhlIG90aGVyIGd1eXMgdGhpbms/ICA6KQo+ Pj4+Pj4+Pj4+Pj4+IFdvdWxkIHRoaXMgZGVzZXJ2ZSBzb21lIOKAnHNwZWMgYWRqdXN0bWVudOKA nSA/IEkgbWVhbiB0aGVyZSBpcyBhIHJlYXNvbgo+Pj4+Pj4+Pj4+Pj4+IGlmIEdvb2dsZSBpcyBi eSBjaG9pY2Ug4oCcdmlvbGF0aW5n4oCdIHRoZSBzcGVjIHJpZ2h0PyAoSSBhc3N1bWUgdG8gYXZv aWQKPj4+Pj4+Pj4+Pj4+PiBvcGVuIHJlZGlyZWN04oCmKQo+Pj4+Pj4+Pj4+Pj4+IEJ1dCBvdGhl ciBpbXBsZW1lbnRlcnMgZG8gZm9sbG93IHRoZSBzcGVjIGhlbmNlIHRoZXkgaGF2ZSB0aGlzIG9w ZW4KPj4+Pj4+Pj4+Pj4+PiByZWRpcmVjdG9y4oCmIGFuZCB0aGlzIGlzIG5vdCBuaWNlIElNSE8u Li4KPj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+PiBPbiBTZXAgMywg MjAxNCwgYXQgNzo0MCBQTSwgSGFucyBaYW5kYmVsdCA8aHphbmRiZWx0QHBpbmdpZGVudGl0eS5j b20KPj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tPj4gd3Jv dGU6Cj4+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+PiBPbiA5LzMvMTQsIDc6MTQgUE0sIEFu dG9uaW8gU2Fuc28gd3JvdGU6Cj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+IE9uIFNl cCAzLCAyMDE0LCBhdCA3OjEwIFBNLCBIYW5zIFphbmRiZWx0Cj4+Pj4+Pj4+Pj4+Pj4+PiA8aHph bmRiZWx0QHBpbmdpZGVudGl0eS5jb20gPG1haWx0bzpoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNv bT4+IHdyb3RlOgo+Pj4+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+Pj4gSXMgeW91ciBjb25j ZXJuIGNsaWVudHMgdGhhdCB3ZXJlIHJlZ2lzdGVyZWQgdXNpbmcgZHluYW1pYyBjbGllbnQKPj4+ Pj4+Pj4+Pj4+Pj4+PiByZWdpc3RyYXRpb24/Cj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+ Pj4+IHllcwo+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4gSSB0aGluayB5b3VyIGlzc3Vl IGlzIHRoZW4gd2l0aCB0aGUgdHJ1c3QgbW9kZWwgb2YgZHluYW1pYyBjbGllbnQKPj4+Pj4+Pj4+ Pj4+Pj4gcmVnaXN0cmF0aW9uOyB0aGF0IGlzIGxlZnQgb3V0IG9mIHNjb3BlIG9mIHRoZSBkeW5y ZWcgc3BlYyAoYW5kIHRoZQo+Pj4+Pj4+Pj4+Pj4+PiBjb25jZXB0IGlzIG5vdCBldmVuIHBhcnQg b2YgdGhlIGNvcmUgc3BlYyksIGJ1dCB1bmxlc3MgeW91IHdhbnQKPj4+Pj4+Pj4+Pj4+Pj4gZXZl cnl0aGluZyB0byBiZSBvcGVuICh3aGljaCB0eXBpY2FsbHkgd291bGQgbm90IGJlIHRoZSBjYXNl KSwgdGhlbgo+Pj4+Pj4+Pj4+Pj4+PiBpdCB3b3VsZCBpbnZvbHZlIGFwcHJvdmFsIHNvbWV3aGVy ZSBpbiB0aGUgcHJvY2VzcyBiZWZvcmUgdGhlIGNsaWVudAo+Pj4+Pj4+Pj4+Pj4+PiBpcyByZWdp c3RlcmVkLiBXaXRob3V0IGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiB0aGF0IGFwcHJvdmFs IGlzCj4+Pj4+Pj4+Pj4+Pj4+IGFkbWluIGJhc2VkIG9yIHJlc291cmNlIG93bmVyIGJhc2VkLCBk ZXBlbmRpbmcgb24gdXNlIGNhc2UuCj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+IE90 aGVyd2lzZSB0aGUgcG9zaXRpdmUgY2FzZSBpcyByZXR1cm5pbmcgYSByZXNwb25zZSB0byBhIHZh bGlkIFVSTAo+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoYXQgYmVsb25ncyB0byBhIGNsaWVudCB0aGF0IHdh cyByZWdpc3RlcmVkIGV4cGxpY2l0bHkgYnkgdGhlCj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmVzb3VyY2Ug b3duZXIKPj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4gd2VsbCBBRkFJSyB0aGUgcmVz b3VyY2Ugb3duZXIgZG9lc27igJl0IHJlZ2lzdGVyIGNsaWVudHPigKYKPj4+Pj4+Pj4+Pj4+Pj4g Cj4+Pj4+Pj4+Pj4+Pj4+IHJvbGVzIGNhbiBjb2xsYXBzZSBpbiB1c2UgY2FzZXMgZXNwZWNpYWxs eSB3aGVuIHVzaW5nIGR5bmFtaWMgY2xpZW50Cj4+Pj4+Pj4+Pj4+Pj4+IHJlZ2lzdHJhdGlvbgo+ Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+PiBhbmQgdGhlIG5lZ2F0aXZlIGNhc2UgaXMg cmV0dXJuaW5nIGFuIGVycm9yIHRvIHRoYXQgc2FtZSBVUkwuCj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+ Pj4+Pj4+Pj4+Pj4+IHRoZSBkaWZmZXJlbmNlIGlzIHRoZSBjb25zZW50IHNjcmVlbuKApiBpbiB0 aGUgcG9zaXRpdmUgY2FzZSB5b3UgbmVlZAo+Pj4+Pj4+Pj4+Pj4+Pj4gdG8gYXBwcm92ZSBhbiBh cHAuLiBmb3IgdGhlIGVycm9yIGNhc2Ugbm8gYXBwcm92YWwgaXMgbmVlZGVkLCwsCj4+Pj4+Pj4+ Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+PiBJIGZhaWwgdG8gc2Vl IHRoZSBvcGVuIHJlZGlyZWN0Lgo+Pj4+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+PiB3aHk/ Cj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+PiBiZWNhdXNlIHRoZSBjbGllbnQgYW5kIHRo dXMgdGhlIGZpeGVkIFVSTCBhcmUgZXhwbGljaXRseSBhcHByb3ZlZCBhdAo+Pj4+Pj4+Pj4+Pj4+ PiBzb21lIHBvaW50Cj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+PiBIYW5zLgo+Pj4+Pj4+ Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+ Pj4+IEhhbnMuCj4+Pj4+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIDkvMy8xNCwg Njo1NiBQTSwgQW50b25pbyBTYW5zbyB3cm90ZToKPj4+Pj4+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IE9uIFNlcCAzLCAyMDE0LCBhdCA2OjUxIFBNLCBIYW5zIFphbmRiZWx0Cj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IDxoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNvbSA8bWFpbHRvOmh6YW5kYmVs dEBwaW5naWRlbnRpdHkuY29tPgo+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmh6YW5kYmVsdEBw aW5naWRlbnRpdHkuY29tPj4gd3JvdGU6Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gTGV0IG1lIHRyeSBhbmQgYXBwcm9hY2ggdGhpcyBmcm9tIGEgZGlmZmVyZW50IGFuZ2xl OiB3aHkgd291bGQgeW91Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjYWxsIGl0IGFuIG9wZW4gcmVkaXJl Y3Qgd2hlbiBhbiBpbnZhbGlkIHNjb3BlIGlzIHByb3ZpZGVkIGFuZAo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gY2FsbCBpdAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29ycmVjdCBwcm90b2NvbCBiZWhhdmlvciAo aG9wZWZ1bGx5KSB3aGVuIGEgdmFsaWQgc2NvcGUgaXMKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHByb3Zp ZGVkPwo+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4gYXMgc3BlY2lmaWVkIGJl bG93IGluIHRoZSBwb3NpdGl2ZSBjYXNlIChuYW1lbHkgd2hlbiB0aGUgY29ycmVjdAo+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBzY29wZQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBpcyBwcm92aWRlZCkgdGhlIHJlc291 cmNlIG93bmVyIE1VU1QgYXBwcm92ZSB0aGUgYXBwIHZpYSB0aGUgY29uc2VudAo+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBzY3JlZW4gKGF0IGxlYXN0IG9uY2UpLgo+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+ Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhhbnMu Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBPbiA5LzMvMTQsIDY6NDYg UE0sIEFudG9uaW8gU2Fuc28gd3JvdGU6Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaGkgSm9obiwKPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBPbiBTZXAgMywgMjAxNCwgYXQgNjoxNCBQTSwgSm9obiBCcmFkbGV5 IDx2ZTdqdGJAdmU3anRiLmNvbQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86dmU3anRiQHZl N2p0Yi5jb20+Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6Cj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEluIHRoZSBleGFtcGxlIHRo ZSByZWRpcmVjdF91cmkgaXMgdmxpZCBmb3IgdGhlIGF0dGFja2VyLgo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIGlzc3VlIGlzIHRoYXQgdGhlIEFTIG1heSBi ZSBhbGxvd2luZyBjbGllbnQgcmVnaXN0cmF0aW9ucyB3aXRoCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IGFyYml0cmFyeSByZWRpcmVjdF91cmkuCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBJbiB0aGUgc3BlYyBpdCBpcyB1bnNwZWNpZmllZCBob3cgYSBBUyB2YWxpZGF0 ZXMgdGhhdCBhIGNsaWVudAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjb250cm9scyB0aGUgcmVkaXJl Y3RfdXJpIGl0IGlzIHJlZ2lzdGVyaW5nLgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gSSB0aGluayB0aGF0IGlmIGFueXRoaW5nIGl0IG1heSBiZSB0aGUgcmVnaXN0 cmF0aW9uIHN0ZXAgdGhhdAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBuZWVkcwo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbi4KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAK Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAodGhpcyBpcyB0aGUgZmlyc3QgdGltZSA6cCkgYnV0IEkgZG8g ZGlzYWdyZWUgd2l0aCB5b3UuIEl0IHdvdWxkIGJlCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcHJldHR5 IHVucHJhY3RpY2FsIHRvIGJsb2NrIHRoaXMgYXQgcmVnaXN0cmF0aW9uIHRpbWXigKYuCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gSU1ITyB0aGUgYmVzdCBhcHByb2FjaCBpcyB0aGUgb25lIHRha2VuIGZy b20gR29vZ2xlLCBuYW1lbHkKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZXR1cm5pbmcKPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiA0MDAgd2l0aCB0aGUgY2F1c2Ugb2YgdGhlIGVycm9yLi4KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAqNDAwLiogVGhhdOKAmXMgYW4gZXJyb3IuCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKkVycm9yOiBpbnZhbGlkX3Nj b3BlKgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNvbWUgcmVxdWVz dGVkIHNjb3BlcyB3ZXJlIGludmFsaWQuIHtpbnZhbGlkPVtsXX0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzYWlkIHRoYXQgSSBob3BlIHlvdSBhbGwgYWdyZWUgdGhp cyBpcyBhbiBpc3N1ZSBpbiB0aGUgc3BlYyBzbwo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGZhcuKApi4K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZWdhcmRzCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYW50b25pbwo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSm9obiBCLgo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gU2VwIDMsIDIwMTQs IGF0IDEyOjEwIFBNLCBCaWxsIEJ1cmtlIDxiYnVya2VAcmVkaGF0LmNvbQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiA8bWFpbHRvOmJidXJrZUByZWRoYXQuY29tPgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8 bWFpbHRvOmJidXJrZUByZWRoYXQuY29tPgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmJi dXJrZUByZWRoYXQuY29tPj4gd3JvdGU6Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gSSBkb24ndCB1bmRlcnN0YW5kLiAgVGhlIHJlZGlyZWN0IHVyaSBoYXMgdG8g YmUgdmFsaWQgaW4KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG9yZGVyIGZvciBhCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiByZWRpcmVjdCB0byBoYXBwZW4uICBUaGUgc3BlYyBleHBsaWNpdGx5IHN0YXRl cyB0aGlzLgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24g OS8zLzIwMTQgMTE6NDMgQU0sIEFudG9uaW8gU2Fuc28gd3JvdGU6Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gaGkgKiwKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBJTUhPIHByb3ZpZGVycyB0aGF0IHN0cmljdGx5IGZvbGxvdyByZmM2NzQ5IGFyZSB2dWxuZXJh YmxlCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdG8gb3Blbgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHJlZGlyZWN0Lgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IExldCBtZSBleHBsYWluLCByZWFkaW5n IFswXQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IElmIHRo ZSByZXF1ZXN0IGZhaWxzIGR1ZSB0byBhIG1pc3NpbmcsIGludmFsaWQsIG9yIG1pc21hdGNoaW5n Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmVkaXJlY3Rpb24gVVJJLCBvciBpZiB0aGUgY2xpZW50 IGlkZW50aWZpZXIgaXMgbWlzc2luZyBvcgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGludmFsaWQs Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBp bmZvcm0gdGhlIHJlc291cmNlIG93bmVyIG9mIHRoZQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGVy cm9yIGFuZCBNVVNUIE5PVCBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRoZSB1c2VyLWFnZW50IHRv IHRoZQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLgo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IElmIHRoZSByZXNvdXJj ZSBvd25lciBkZW5pZXMgdGhlIGFjY2VzcyByZXF1ZXN0IG9yIGlmIHRoZQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IHJlcXVlc3QKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBmYWlscyBmb3IgcmVhc29u cyBvdGhlciB0aGFuIGEgbWlzc2luZyBvciBpbnZhbGlkCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g cmVkaXJlY3Rpb24gVVJJLAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBpbmZvcm1zIHRoZSBjbGllbnQgYnkgYWRkaW5nIHRoZQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IGZvbGxvd2luZwo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHBhcmFtZXRlcnMgdG8gdGhl IHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gdXNpbmcgdGhlCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gImFwcGxpY2F0aW9uL3gtd3d3 LWZvcm0tdXJsZW5jb2RlZCIgZm9ybWF0LCBwZXJBcHBlbmRpeCBCCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I2FwcGVuZGl4LUI+Ogo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE5vdyBsZXTigJlz IGFzc3VtZSB0aGlzLgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgYW0gcmVnaXN0ZXJpbmcgYSBu ZXcgY2xpZW50IHRvIHRoZXZpY3RpbS5jb20KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8aHR0cDov L3RoZXZpY3RpbS5jb20vPgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxodHRwOi8vdmljdGltLmNv bS8+PGh0dHA6Ly92aWN0aW0uY29tIDxodHRwOi8vdmljdGltLmNvbS8+Cj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gPGh0dHA6Ly92aWN0aW0uY29tLz4+Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPGh0 dHA6Ly92aWN0aW0uY29tIDxodHRwOi8vdmljdGltLmNvbS8+IDxodHRwOi8vdmljdGltLmNvbS8+ Pgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHByb3ZpZGVyLgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IEkgcmVnaXN0ZXIgcmVkaXJlY3QgdXJpYXR0YWNrZXIuY29tIDxodHRwOi8vdXJpYXR0YWNrZXIu Y29tLz4KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8aHR0cDovL2F0dGFja2VyLmNvbS8+PGh0dHA6 Ly9hdHRhY2tlci5jb20KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8aHR0cDovL2F0dGFja2VyLmNv bS8+IDxodHRwOi8vYXR0YWNrZXIuY29tLz4+Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPGh0dHA6 Ly9hdHRhY2tlci5jb20gPGh0dHA6Ly9hdHRhY2tlci5jb20vPgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IDxodHRwOi8vYXR0YWNrZXIuY29tLz4+Lgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEFjY29yZGluZyB0byBbMF0gaWYgSSBwYXNzIGUuZy4gdGhlIHdy b25nIHNjb3BlIEkgYW0gcmVkaXJlY3RlZAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJhY2sgdG8K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBhdHRhY2tlci5jb20gPGh0dHA6Ly9hdHRhY2tlci5jb20v Pgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxodHRwOi8vYXR0YWNrZXIuY29tLz48aHR0cDovL2F0 dGFja2VyLmNvbQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxodHRwOi8vYXR0YWNrZXIuY29tLz4K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8aHR0cDovL2F0dGFja2VyLmNvbS8+PiA8aHR0cDovL2F0 dGFja2VyLmNvbQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxodHRwOi8vYXR0YWNrZXIuY29tLz4g PGh0dHA6Ly9hdHRhY2tlci5jb20vPj4uCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gTmFtZWx5IEkg cHJlcGFyZSBhIHVybCB0aGF0IGlzIGluIHRoaXMgZm9ybToKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBodHRwOi8vdmljdGltLmNvbS9hdXRob3JpemU/cmVz cG9uc2VfdHlwZT1jb2RlJmNsaWVudF9pZD1iYzg4Rml0WDEyOThLUGoyV1MyNTlCQk1hOV9LQ2ZM MyZzY29wZT1XUk9OR19TQ09QRSZyZWRpcmVjdF91cmk9aHR0cDovL2F0dGFja2VyLmNvbQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFuZCB0aGlzIGlzIHdv cmtzIGFzIGFuIG9wZW4gcmVkaXJlY3Rvci4KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBPZiBjb3Vy c2UgaW4gdGhlIHBvc2l0aXZlIGNhc2UgaWYgYWxsIHRoZSBwYXJhbWV0ZXJzIGFyZQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IGZpbmUgdGhpcwo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRvZXNu4oCZ dCBhcHBseSBzaW5jZSB0aGUgcmVzb3VyY2Ugb3duZXIgTVVTVCBhcHByb3ZlIHRoZSBhcHAKPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB2aWEgdGhlCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29uc2Vu dCBzY3JlZW4gKGF0IGxlYXN0IG9uY2UpLgo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IEEgc29sdXRpb24gd291bGQgYmUgdG8gcmV0dXJuIGVycm9yIDQwMCBy YXRoZXIgdGhhbiByZWRpcmVjdAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRvIHRoZQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IHJlZGlyZWN0IFVSSSAoYXMgc29tZSBwcm92aWRlciBlLmcuIEdvb2ds ZSBkbykKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBXRFlU Pwo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlZ2FyZHMK Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBhbnRvbmlvCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gWzBdIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tNC4xLjIuMQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g T0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IC0tCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBCaWxsIEJ1cmtlCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBKQm9zcywgYSBkaXZpc2lvbiBv ZiBSZWQgSGF0Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBodHRwOi8vYmlsbC5idXJrZWNlbnRyYWwu Y29tIDxodHRwOi8vYmlsbC5idXJrZWNlbnRyYWwuY29tLz4KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGlldGYub3JnPgo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOk9BdXRoQGlldGYub3JnPjxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9B dXRoIG1haWxpbmcgbGlzdAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9BdXRoQGlldGYub3JnIDxtYWls dG86T0F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAtLQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSGFu cyBaYW5kYmVsdCAgICAgICAgICAgICAgfCBTci4gVGVjaG5pY2FsIEFyY2hpdGVjdAo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gaHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb20gPG1haWx0bzpoemFuZGJlbHRA cGluZ2lkZW50aXR5LmNvbT4KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86aHphbmRiZWx0QHBp bmdpZGVudGl0eS5jb20+fCBQaW5nCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJZGVudGl0eQo+Pj4+Pj4+ Pj4+Pj4+Pj4+IAo+Pj4+Pj4+Pj4+Pj4+Pj4+IC0tCj4+Pj4+Pj4+Pj4+Pj4+Pj4gSGFucyBaYW5k YmVsdCAgICAgICAgICAgfCBTci4gVGVjaG5pY2FsIEFyY2hpdGVjdAo+Pj4+Pj4+Pj4+Pj4+Pj4+ IGh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tIDxtYWlsdG86aHphbmRiZWx0QHBpbmdpZGVudGl0 eS5jb20+IHwKPj4+Pj4+Pj4+Pj4+Pj4+PiBQaW5nIElkZW50aXR5Cj4+Pj4+Pj4+Pj4+Pj4+IAo+ Pj4+Pj4+Pj4+Pj4+PiAtLQo+Pj4+Pj4+Pj4+Pj4+PiBIYW5zIFphbmRiZWx0ICAgICAgICAgICAg ICB8IFNyLiBUZWNobmljYWwgQXJjaGl0ZWN0Cj4+Pj4+Pj4+Pj4+Pj4+IGh6YW5kYmVsdEBwaW5n aWRlbnRpdHkuY29tIDxtYWlsdG86aHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb20+fCBQaW5nCj4+ Pj4+Pj4+Pj4+Pj4+IElkZW50aXR5Cj4+Pj4+Pj4+Pj4+PiAKPj4+Pj4+Pj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+Pj4+Pj4+PiBPQXV0 aCBtYWlsaW5nIGxpc3QKPj4+Pj4+Pj4+Pj4+IE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+Cj4+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoCj4+Pj4+Pj4+Pj4gCj4+Pj4+Pj4+Pj4gLS0KPj4+Pj4+Pj4+PiBIYW5zIFphbmRi ZWx0ICAgICAgICAgICAgICB8IFNyLiBUZWNobmljYWwgQXJjaGl0ZWN0Cj4+Pj4+Pj4+Pj4gaHph bmRiZWx0QHBpbmdpZGVudGl0eS5jb20gfCBQaW5nIElkZW50aXR5Cj4+Pj4+Pj4+PiAKPj4+Pj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+ Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4+Pj4+IAo+ Pj4+Pj4+PiAtLQo+Pj4+Pj4+PiBCaWxsIEJ1cmtlCj4+Pj4+Pj4+IEpCb3NzLCBhIGRpdmlzaW9u IG9mIFJlZCBIYXQKPj4+Pj4+Pj4gaHR0cDovL2JpbGwuYnVya2VjZW50cmFsLmNvbQo+Pj4+Pj4+ PiAKPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPj4+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+IE9BdXRoQGlldGYub3JnCj4+ Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPj4+Pj4+ PiAKPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Pj4gCj4+ Pj4+PiAtLSAKPj4+Pj4+IEhhbnMgWmFuZGJlbHQgICAgICAgICAgICAgIHwgU3IuIFRlY2huaWNh bCBBcmNoaXRlY3QKPj4+Pj4+IGh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tIHwgUGluZyBJZGVu dGl0eQo+Pj4+PiAKPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+IE9BdXRoQGlldGYub3JnCj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPj4+PiAKPj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+IE9B dXRoIG1haWxpbmcgbGlzdAo+Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+PiAKPiAKPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE9BdXRoIG1haWxpbmcgbGlzdAo+IE9BdXRo QGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KT0F1dGggbWFp bGluZyBsaXN0Ck9BdXRoQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgK ----_com.android.email_17908325804640 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+SSB0aGluayBhIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGFkZGVuZHVtIG1ha2VzIHNlbnNlLjxkaXY+PGJyPjwvZGl2PjxkaXY+cmVn YXJkcywmbmJzcDs8L2Rpdj48ZGl2PlRvcnN0ZW4uJm5ic3A7PC9kaXY+PGJyPjxicj48ZGl2Pi0t LS0tLS0tIFVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodCAtLS0tLS0tLTwvZGl2PjxkaXY+Vm9uOiAi UmljaGVyLCBKdXN0aW4gUC4iIDxqcmljaGVyQG1pdHJlLm9yZz4gPC9kaXY+PGRpdj5EYXR1bTox NS4wOS4yMDE0ICAyMzoxNSAgKEdNVCswMTowMCkgPC9kaXY+PGRpdj5BbjogQW50b25pbyBTYW5z byA8YXNhbnNvQGFkb2JlLmNvbT4gPC9kaXY+PGRpdj5DYzogb2F1dGhAaWV0Zi5vcmcgPC9kaXY+ PGRpdj5CZXRyZWZmOiBSZTogW09BVVRILVdHXSBvcGVuIHJlZGlyZWN0IGluIHJmYzY3NDkgPC9k aXY+PGRpdj48YnI+PC9kaXY+QXMgd2UgZGlzY3Vzc2VkIGJlZm9yZTogVGhpcyBpc24ndCByZWFs bHkgYW4gb3BlbiByZWRpcmVjdGlvbiBpbiB0aGUgY2xhc3NpY2FsIHNlbnNlIHNpbmNlIG5vdGhp bmcgZ2V0cyBsZWFrZWQgYW5kIHRoZSBVUkkgaXMgdGllZCBiYWNrIHRvIGEga25vd24gKGFsYmVp dCBtYWxpY2lvdXMpIGNsaWVudCByZWdpc3RyYXRpb24uIEFuZCBJIHRob3VnaHQgdGhlIGNsZWFy IHNvbHV0aW9uIHdhcyB0byBoYXZlIGFuIEFTIG5vdCBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRv IGFuIHVudHJ1c3RlZCBjbGllbnQgaW4gZXJyb3IgY29uZGl0aW9ucywgd2hlcmUgInVudHJ1c3Rl ZCIgaXMgZGVmaW5lZCBieSB0aGUgQVMgd2l0aCBndWlkYW5jZS4gSWYgYW55dGhpbmcgdGhpcyBp cyBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFkZGVuZHVtLjxicj48YnI+IC0tIEp1c3Rpbjxi cj48YnI+T24gU2VwIDE1LCAyMDE0LCBhdCA0OjUyIFBNLCBBbnRvbmlvIFNhbnNvICZsdDthc2Fu c29AYWRvYmUuY29tJmd0OyB3cm90ZTo8YnI+PGJyPiZndDsgVGhlIHByb2JsZW0gaXMgdGhhdCBh IG1hbGljaW91cyBjbGllbnQgY2FuIHJlZ2lzdGVyIGEgbWFsaWNpb3VzIHJlZGlyZWN0IHVyaSBh bmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjEuMi4xIGRv ZXMgdGhlIHJlc3QgKGFzIHByZXZpb3VzbHkgZGlzY3Vzc2VkKTxicj4mZ3Q7IDxicj4mZ3Q7IHJl Z2FyZHM8YnI+Jmd0OyA8YnI+Jmd0OyBhbnRvbmlvPGJyPiZndDsgPGJyPiZndDsgT24gU2VwIDE1 LCAyMDE0LCBhdCAxMDo0MyBQTSwgUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZn dDsgd3JvdGU6PGJyPiZndDsgPGJyPiZndDsmZ3Q7IElmIGEgc2VydmVyIGFjY2VwdHMgYSBVUkwg ZnJvbSBhIGNsaWVudCB0byBiZSB1c2VkIGFzIGEgcmVkaXJlY3QgdGhhdCB0aGUgc2VydmVyIGRv ZXNu4oCZdCByZWNvZ25pemUgb3IgaXMgbm90IHJlZ2lzdGVyZWQsIHRoYXQgaXMgYW4gb3BlbiBy ZWRpcmVjdC48YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IFRoZSBzcGVjaWZpY2F0aW9uIGRvZXMg bm8gYWxsb3cgb3Blbi1yZWRpcmVjdHMsIGl0IGNvbnNpZGVycyB0aGlzIGEgbWlzLWNvbmZpZ3Vy YXRpb24uPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBUYWtlIGEgbG9vayBhdCBzZWN0aW9ucyAz LjEuMi4yIGFuZCAxMC4xNSBvZiBSRkM2NzQ5Ljxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgUGhp bDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgQGluZGVwZW5kZW50aWQ8YnI+Jmd0OyZndDsgd3d3 LmluZGVwZW5kZW50aWQuY29tPGJyPiZndDsmZ3Q7IHBoaWwuaHVudEBvcmFjbGUuY29tPGJyPiZn dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IE9uIFNlcCAxNSwg MjAxNCwgYXQgMTowMCBQTSwgSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDsg d3JvdGU6PGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgVGhlcmUgbWF5IGJlIGEgcHJvYmxl bSB3aXRoIHNlbWFudGljcyBpbiB0aGlzIGRpc2N1c3Npb24uIDxicj4mZ3Q7Jmd0OyZndDsgPGJy PiZndDsmZ3Q7Jmd0OyBUaGVyZSBpcyBhIHJlZGlyZWN0IHBlcmZvcm1lZCBieSBhdGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQgdG8gYSBmaXhlZCB1cmkgdGhhdCBpcyBwcmUgcmVnaXN0ZXJlZCB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aXRob3V0IHVzZXIgcHJvbXB0aW5nLiA8YnI+ Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgVGhhdCBwcm9iYWJseSBkb2Vzbid0IGZpdCB0 aGUgc3RyaWN0IGRlZmluaXRpb24gb2YgYSBvcGVuIHJlZGlyZWN0b3IuIDxicj4mZ3Q7Jmd0OyZn dDsgPGJyPiZndDsmZ3Q7Jmd0OyBJdCBtYXkgaG93ZXZlciBjcmVhdGUgc2ltaWxhciBzZWN1cml0 eSBpc3N1ZXMgaW4gc2l0dWF0aW9ucyB3aXRoIHJlbGF0aXZlbHkgb3BlbiByZWdpc3RyYXRpb24g b2YgY2xpZW50cy4gPGJyPiZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7IFRoZSBsYXJnZXN0 IGlzc3VlcyBhcmUgdGhhdCB0aGUgYnJvd3NlciBtaWdodCBsZWFrIGluZm9ybWF0aW9uIGFjcm9z cyB0aGUgcmVkaXJlY3QgaW4gdGhlIGZyYWdtZW50IG9yIHJlZmVycmVyLiZuYnNwOyBUaGF0IGhh cyBiZWVuIHVzZWQgaW4gYXR0YWNrcyBhZ2FpbnN0IEZhY2Vib29rIGluIHRoZSBwYXN0LiA8YnI+ Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgVGhpcyBpcyBubyB3aGVyZSBuZWFyIHRoZSBl bmQgb2YgdGhlIHdvcmxkLCZuYnNwOyBob3dldmVyIHdlIG5lZWQgdG8gbG9vayBhdCB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgYW5kIHNlZSBpZiB3ZSBjYW4gcHJvdmlkZSBiZXR0ZXIgYWR2 aWNlIHRvIGltcGxlbWVudG9ycy4mbmJzcDsgSW4gc29tZSBjYXNlcyByZXR1cm5pbmcgYSBlcnJv ciB0byB0aGUgYnJvd3NlciBtYXkgYmUgYmVzdC4mbmJzcDsgPGJyPiZndDsmZ3Q7Jmd0OyA8YnI+ Jmd0OyZndDsmZ3Q7IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBnbyBzbyBmYXIgYXMgbm90IHJl dHVybmluZyBhbnkgZXJyb3IgdG8gdGhlIGNsaWVudCB1bmRlciBhbnkgY2lyY3Vtc3RhbmNlLiA8 YnI+Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsgSm9obiBCLiA8YnI+Jmd0OyZndDsmZ3Q7 IDxicj4mZ3Q7Jmd0OyZndDsgU2VudCBmcm9tIG15IGlQaG9uZTxicj4mZ3Q7Jmd0OyZndDsgPGJy PiZndDsmZ3Q7Jmd0OyZndDsgT24gU2VwIDE1LCAyMDE0LCBhdCA0OjQxIFBNLCBQaGlsIEh1bnQg Jmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0OyB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBTaW1wbHkgbm90IHRydWUuPGJyPiZndDsmZ3Q7Jmd0OyZndDsg PGJyPiZndDsmZ3Q7Jmd0OyZndDsgUGhpbDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7IEBpbmRlcGVuZGVudGlkPGJyPiZndDsmZ3Q7Jmd0OyZndDsgd3d3LmluZGVwZW5k ZW50aWQuY29tPGJyPiZndDsmZ3Q7Jmd0OyZndDsgcGhpbC5odW50QG9yYWNsZS5jb208YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gU2VwIDE1LCAyMDE0LCBhdCAxMjoxMCBQTSwgQW50 b25pbyBTYW5zbyAmbHQ7YXNhbnNvQGFkb2JlLmNvbSZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBoaSAqLDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0 IHRoZXJlIGlzIGEgcm91Z2ggY29uc2Vuc3VzIHRoYXQgaWYgYW4gT0F1dGggUHJvdmlkZXIgZm9s bG93cyByZmM2NzQ5IHZlcmJhdGltIHdpbGwgZW5kIHVwIGhhdmluZyBhbiBvcGVuIHJlZGlyZWN0 b3IuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE15IG5leHQgcXVlc3Rpb24gd291bGQgYmUgbm93 LCBpcyB0aGVyZSBhbnl0aGluZyB3ZSBjYW4gZG8gdG8gcmFpc2Ugc29tZSBhd2FyZW5lc3MgYWJv dXQgdGhpcyBpc3N1ZT88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHJlZ2FyZHM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGFudG9uaW88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBPbiBTZXAgNCwgMjAxNCwgYXQgMzoxNSBQTSwgSGFucyBaYW5kYmVsdCAmbHQ7 aHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb20mZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGFtIGNvbnZpbmNlZCBhYm91 dCB0aGUgaXNzdWUgaW4gdGhlIHVzZSBjYXNlIEFudG9uaW8gcHJvdmlkZWQgYnV0IEkgaG9wZSBu b3QgdG8gY2xvc2UgdGhlIGRvb3Igb24gcmV0dXJuaW5nIGVycm9ycyB0byBrbm93biBhbmQgdHJ1 c3RlZCBjbGllbnRzLiBOb3Qgc3VyZSBhbnltb3JlIGlmIHRoYXQncyBwb3NzaWJsZSB0aG91Z2gg YmVjYXVzZSB0aGUgZGlzdGluY3Rpb24gY2FuJ3QgYmUgInJlZ2lzdGVyZWQiLi4uPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhhbnMuPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBPbiA5LzQvMTQsIDM6MDEgUE0sIEFudG9uaW8gU2Fuc28gd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgaGkgQmlsbDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBPbiBTZXAgNCwgMjAxNCwgYXQgMjo1MiBQTSwgQmlsbCBCdXJrZSAmbHQ7YmJ1cmtlQHJl ZGhhdC5jb20mZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRldJVywgQW50b25pbyBjb252aW5j ZWQgbWUgYW5kIEknbSBnb2luZyB0byBjaGFuZ2UgdGhpcyBpbiBvdXIgSURNIHByb2plY3QuJm5i c3A7IFRoYW5rcyBBbnRvbmlvLiZuYnNwOyBXaGF0IGNvbnZpbmNlZCBtZSB3YXMgdGhhdCB0aGUg dXNlciBpcyBwcm9iYWJseSBleHBlY3RpbmcgYSBsb2dpbiBzY3JlZW4uJm5ic3A7IFNpbmNlIHRo ZXJlIGlzIHRoaXMgZXhwZWN0YXRpb24sIGl0IG1pZ2h0IG1ha2UgaXQgYSBsaXR0bGUgZWFzaWVy IGZvciB0aGUgYXR0YWNrZXIgdG8gY29udmluY2UgdGhlIHVzZXIgdGhhdCBhIHNwb29mZWQgbG9n aW4gc2NyZWVuIGlzIHJlYWwuJm5ic3A7IEkga25vdyB0aGlzIGlzc3VlIGNhbiBvbmx5IGhhcHBl biB3aXRoIHVucmVzdHJpY3RlZCByZWdpc3RyYXRpb24sIGJ1dCwgSU1PLCB0aGlzIHByb3Bvc2Vk IGNoYW5nZSBkb2Vzbid0IHJlYWxseSBoYXZlIG11Y2ggb2YgYW4gZWZmZWN0IG9uIHVzYWJpbGl0 eSBhbmQgaXMgZXZlbiBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggdGhlIGN1cnJlbnQgUkZDLjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgV291bGRuJ3QgaXQgYmV0dGVyIHRob3VnaCB0byBuZXZlciBkbyBhIHJl ZGlyZWN0IG9uIGFuIGludmFsaWQgcmVxdWVzdCBhbmQganVzdCBkaXNwbGF5IGFuIGVycm9yIHBh Z2U/PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgdGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMgOikuIERpc3BsYXkg YW4gZXJyb3IgNDAwIGlzIHdoYXQgR29vZ2xlIGRvZXMgOik8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdhcmRzPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYW50b25pbzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE9uIDkvNC8yMDE0IDM6NTAgQU0sIEFudG9uaW8gU2Fuc28gd3JvdGU6PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBIYW5zLDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBJIHJlYWxseSBmYWlsIHRvIHNlZSBob3cgdGhpcyBjYW4gYmUgYWRkcmVzc2VkIGF0 IHJlZ2lzdHJhdGlvbiB0aW1lIGZvciBjYXNlcyB3aGVyZSByZWdpc3RyYXRpb24gaXMgdW5yZXN0 cmljdGVkIChuYW1lbHkgYWxsIHRoZSBiaWcgUHJvdmlkZXJzKTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyByZWdhcmRzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFudG9uaW88YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIFNlcCA0LCAyMDE0LCBhdCA5OjQ3IEFNLCBIYW5zIFphbmRiZWx0 ICZsdDtoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNvbSZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgQ2xhc3NpZnlpbmcgbGlrZSB0aGlzIG11c3QgYWxzbyBtZWFuIHRo YXQgY29uc2VudCBzaG91bGQgbm90IGJlIHN0b3JlZCB1bnRpbCB0aGUgY2xpZW50IGlzIGNvbnNp ZGVyZWQgKGFkbWluKSB0cnVzdGVkLCBhbmQgYWRtaW4gcG9saWN5IHdvdWxkIGludGVyZmVyZSB3 aXRoIHVzZXIgcG9saWN5Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElNSE8gdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gd291bGQgYXBwbHkgb25seSB0byBkeW5hbWljYWxseSBy ZWdpc3RlcmVkIGNsaWVudHMgd2hlcmUgcmVnaXN0cmF0aW9uIGlzIHVucmVzdHJpY3RlZDsgYW55 IG90aGVyIGZvcm0gd291bGQgaW52b2x2ZSBzb21lIGZvcm0gb2YgYWRtaW4vdXNlciBhcHByb3Zh bCBhdCByZWdpc3RyYXRpb24gdGltZSwgb3ZlcmNvbWluZyB0aGUgY29uY2VybiBhdCBhdXRob3Jp emF0aW9uIHRpbWU6IHRoZXJlJ3Mgbm8gYXV0by1yZWRpcmVjdCBmbG93IHBvc3NpYmxlIGZvciB1 bmtub3duIGNsaWVudHMuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGFucy48YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gOS80LzE0LCA5OjA0IEFNLCBSaWNo ZXIsIEp1c3RpbiBQLiB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSSB0aGluayB0aGlzIGFkdmljZSBpc24ndCBhIGJhZCBpZGVhLCB0aG91Z2gg aXQncyBvZiBjb3Vyc2UgdXAgdG8gdGhlIEFTPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoYXQgYW4gInVudHJ1c3RlZCIgY2xpZW50IHJlYWxseSBpcy4g SW4gcHJhY3RpY2UsIHRoaXMgaXMgc29tZXRoaW5nPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgd2FzIHJlZ2lzdGVyZWQgYnkgYSBub24tc3lzYWRt aW4gdHlwZSBwZXJzb24sIGVpdGhlciBhIGR5bmFtaWNhbGx5PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZ2lzdGVyZWQgY2xpZW50IG9yIHNvbWV0aGlu ZyBhdmFpbGFibGUgdGhyb3VnaCBzZWxmLXNlcnZpY2U8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVnaXN0cmF0aW9uIG9mIHNvbWUgdHlwZS4gSXQncyBh bHNvIHJlYXNvbmFibGUgdGhhdCBhIGNsaWVudCwgZXZlbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkeW5hbWljYWxseSByZWdpc3RlcmVkLCB3b3VsZCBi ZSBjb25zaWRlcmVkICJ0cnVzdGVkIiBpZiBlbm91Z2ggdGltZSBoYXM8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFzc2VkIGFuZCBlbm91Z2ggdXNlcnMg aGF2ZSB1c2VkIGl0IHdpdGhvdXQgdGhpbmdzIGJsb3dpbmcgdXAuPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLSBKdXN0aW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIFNlcCA0LCAyMDE0LCBhdCAxOjI2IEFNLCBBbnRvbmlvIFNhbnNv ICZsdDthc2Fuc29AYWRvYmUuY29tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICZsdDttYWlsdG86YXNhbnNvQGFkb2JlLmNvbSZndDsmZ3Q7IHdyb3RlOjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhpIGFnYWluICosPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFmdGVyIHRoaW5r aW5nIGEgYml0IGZ1cnRoZXIgSU1ITyBhbiBhbHRlcm5hdGl2ZSBmb3IgdGhlIHVudHJ1c3RlZDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2xpZW50 cyBjYW4gYWxzbyBiZSB0byBhbHdheXMgcHJlc2VudCB0aGUgY29uc2VudCBzY3JlZW4gKGF0IGxl YXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBv bmNlKSBiZWZvcmUgYW55IHJlZGlyZWN0Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTmFtZWx5IGFsbCBwcm92aWRlcnMgSSBoYXZlIHNlZW4gc2hv dyB0aGUgY29uc2VudCBzY3JlZW4gaWYgYWxsIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWVzdCBwYXJhbWV0ZXJzIGFyZSBjb3JyZWN0 IGFuZCBpZiB0aGUgdXNlciBhY2NlcHRzIHRoZSByZWRpcmVjdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaGFwcGVucy48YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIG9uZSBvZiB0aGUgcGFyYW1l dGVyJm5ic3A7ICh3aXRoIHRoZSBleGNsdXNpb24gb2YgdGhlIGNsaWVudCBpZCBhbmQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZGlyZWN0IHVy aSB0aGF0IGFyZSBoYW5kbGVkIGRpZmZlcmVudGx5IGFzIGZvciBzcGVjKSBpcyB3cm9uZyB0aG91 Z2g8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRo ZSByZWRpcmVjdCBoYXBwZW5zIHdpdGhvdXQgdGhlIGNvbnNlbnQgc2NyZWVuIGJlaW5nIHNob3du Li48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV0RZVD88 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVnYXJkczxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbnRvbmlvPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIFNlcCAzLCAy MDE0LCBhdCA3OjU0IFBNLCBBbnRvbmlvIFNhbnNvICZsdDthc2Fuc29AYWRvYmUuY29tPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7bWFpbHRv OmFzYW5zb0BhZG9iZS5jb20mZ3Q7Jmd0OyB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdlbGwsPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBkbyBub3Qga25vdyBpZiB0aGlzIGlz IG9ubHkgZHluYW1pYyByZWdpc3RyYXRpb24uLi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsZXTigJlzIHRhbGsgYWJvdXQgcmVhbCB1c2Ug Y2FzZXMsIG5hbWVseSBlLmcuIEdvb2dsZSAsIEZhY2Vib29rICw8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBldGMuLiBpcyB0aGF0IGR5bmFt aWMgY2xpZW50IHJlZ2lzdHJhdGlvbj8gSSBkbyBub3Qga25vd+KApiA6KTxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNhaWQgdGhhdCB3aGF0 IHRoZSBvdGhlciBndXlzIHRoaW5rPyZuYnNwOyA6KTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdvdWxkIHRoaXMgZGVzZXJ2ZSBzb21lIOKA nHNwZWMgYWRqdXN0bWVudOKAnSA/IEkgbWVhbiB0aGVyZSBpcyBhIHJlYXNvbjxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlmIEdvb2dsZSBp cyBieSBjaG9pY2Ug4oCcdmlvbGF0aW5n4oCdIHRoZSBzcGVjIHJpZ2h0PyAoSSBhc3N1bWUgdG8g YXZvaWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBvcGVuIHJlZGlyZWN04oCmKTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCBvdGhlciBpbXBsZW1lbnRlcnMgZG8gZm9sbG93IHRo ZSBzcGVjIGhlbmNlIHRoZXkgaGF2ZSB0aGlzIG9wZW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWRpcmVjdG9y4oCmIGFuZCB0aGlzIGlz IG5vdCBuaWNlIElNSE8uLi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBTZXAgMywgMjAxNCwgYXQgNzo0MCBQTSwgSGFucyBaYW5kYmVs dCAmbHQ7aHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb208YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOmh6YW5kYmVsdEBwaW5n aWRlbnRpdHkuY29tJmd0OyZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiA5LzMvMTQsIDc6MTQgUE0sIEFu dG9uaW8gU2Fuc28gd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIFNlcCAzLCAyMDE0LCBhdCA3OjEw IFBNLCBIYW5zIFphbmRiZWx0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7aHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb20g Jmx0O21haWx0bzpoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNvbSZndDsmZ3Q7IHdyb3RlOjxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSXMgeW91ciBjb25jZXJuIGNsaWVudHMgdGhhdCB3ZXJlIHJlZ2lzdGVy ZWQgdXNpbmcgZHluYW1pYyBjbGllbnQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdpc3RyYXRpb24/PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHllczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSSB0aGluayB5b3VyIGlzc3VlIGlzIHRoZW4gd2l0aCB0aGUgdHJ1 c3QgbW9kZWwgb2YgZHluYW1pYyBjbGllbnQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVnaXN0cmF0aW9uOyB0aGF0IGlzIGxlZnQg b3V0IG9mIHNjb3BlIG9mIHRoZSBkeW5yZWcgc3BlYyAoYW5kIHRoZTxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25jZXB0IGlzIG5v dCBldmVuIHBhcnQgb2YgdGhlIGNvcmUgc3BlYyksIGJ1dCB1bmxlc3MgeW91IHdhbnQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXZl cnl0aGluZyB0byBiZSBvcGVuICh3aGljaCB0eXBpY2FsbHkgd291bGQgbm90IGJlIHRoZSBjYXNl KSwgdGhlbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBpdCB3b3VsZCBpbnZvbHZlIGFwcHJvdmFsIHNvbWV3aGVyZSBpbiB0aGUgcHJv Y2VzcyBiZWZvcmUgdGhlIGNsaWVudDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyByZWdpc3RlcmVkLiBXaXRob3V0IGR5bmFtaWMg Y2xpZW50IHJlZ2lzdHJhdGlvbiB0aGF0IGFwcHJvdmFsIGlzPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFkbWluIGJhc2VkIG9yIHJl c291cmNlIG93bmVyIGJhc2VkLCBkZXBlbmRpbmcgb24gdXNlIGNhc2UuPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IE90aGVyd2lzZSB0aGUgcG9zaXRpdmUgY2FzZSBpcyByZXR1cm5pbmcgYSByZXNwb25zZSB0byBh IHZhbGlkIFVSTDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgYmVsb25ncyB0byBhIGNsaWVudCB0aGF0IHdhcyBy ZWdpc3RlcmVkIGV4cGxpY2l0bHkgYnkgdGhlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVzb3VyY2Ugb3duZXI8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgd2VsbCBBRkFJSyB0aGUgcmVzb3VyY2Ugb3duZXIgZG9lc27igJl0IHJlZ2lz dGVyIGNsaWVudHPigKY8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJvbGVzIGNhbiBjb2xsYXBzZSBpbiB1c2UgY2FzZXMgZXNw ZWNpYWxseSB3aGVuIHVzaW5nIGR5bmFtaWMgY2xpZW50PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZ2lzdHJhdGlvbjxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBhbmQgdGhlIG5lZ2F0aXZlIGNhc2UgaXMgcmV0dXJuaW5nIGFuIGVycm9yIHRvIHRo YXQgc2FtZSBVUkwuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBkaWZmZXJlbmNlIGlzIHRoZSBjb25zZW50 IHNjcmVlbuKApiBpbiB0aGUgcG9zaXRpdmUgY2FzZSB5b3UgbmVlZDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gYXBwcm92 ZSBhbiBhcHAuLiBmb3IgdGhlIGVycm9yIGNhc2Ugbm8gYXBwcm92YWwgaXMgbmVlZGVkLCwsPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGZhaWwgdG8gc2VlIHRoZSBvcGVuIHJlZGly ZWN0Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aHk/PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZWNhdXNlIHRoZSBjbGllbnQgYW5kIHRo dXMgdGhlIGZpeGVkIFVSTCBhcmUgZXhwbGljaXRseSBhcHByb3ZlZCBhdDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb21lIHBvaW50 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBIYW5zLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhhbnMuPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDkvMy8xNCwgNjo1NiBQTSwgQW50b25pbyBTYW5z byB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIFNlcCAzLCAyMDE0LCBh dCA2OjUxIFBNLCBIYW5zIFphbmRiZWx0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtoemFuZGJlbHRAcGlu Z2lkZW50aXR5LmNvbSAmbHQ7bWFpbHRvOmh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tJmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOmh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tJmd0OyZn dDsgd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTGV0IG1lIHRyeSBh bmQgYXBwcm9hY2ggdGhpcyBmcm9tIGEgZGlmZmVyZW50IGFuZ2xlOiB3aHkgd291bGQgeW91PGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBjYWxsIGl0IGFuIG9wZW4gcmVkaXJlY3Qgd2hlbiBhbiBpbnZhbGlk IHNjb3BlIGlzIHByb3ZpZGVkIGFuZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2FsbCBpdDxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgY29ycmVjdCBwcm90b2NvbCBiZWhhdmlvciAoaG9wZWZ1bGx5KSB3aGVuIGEg dmFsaWQgc2NvcGUgaXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3ZpZGVkPzxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYXMgc3BlY2lmaWVkIGJlbG93IGluIHRoZSBwb3NpdGl2ZSBjYXNl IChuYW1lbHkgd2hlbiB0aGUgY29ycmVjdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzY29wZTxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpcyBwcm92aWRlZCkgdGhlIHJlc291cmNlIG93bmVyIE1VU1QgYXBwcm92ZSB0aGUgYXBw IHZpYSB0aGUgY29uc2VudDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzY3JlZW4gKGF0IGxlYXN0IG9uY2UpLjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEhhbnMuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBPbiA5LzMvMTQsIDY6NDYgUE0sIEFudG9uaW8gU2Fuc28gd3JvdGU6PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgaGkgSm9obiw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBTZXAgMywgMjAx NCwgYXQgNjoxNCBQTSwgSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbTxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICZsdDttYWlsdG86dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJmx0O21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSZndDs8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tJmd0OyZndDsgd3JvdGU6 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEluIHRo ZSBleGFtcGxlIHRoZSByZWRpcmVjdF91cmkgaXMgdmxpZCBmb3IgdGhlIGF0dGFja2VyLjxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGlz c3VlIGlzIHRoYXQgdGhlIEFTIG1heSBiZSBhbGxvd2luZyBjbGllbnQgcmVnaXN0cmF0aW9ucyB3 aXRoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyYml0cmFyeSByZWRpcmVjdF91cmkuPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiB0 aGUgc3BlYyBpdCBpcyB1bnNwZWNpZmllZCBob3cgYSBBUyB2YWxpZGF0ZXMgdGhhdCBhIGNsaWVu dDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb250cm9scyB0aGUgcmVkaXJlY3RfdXJpIGl0 IGlzIHJlZ2lzdGVyaW5nLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSSB0aGluayB0aGF0IGlmIGFueXRoaW5nIGl0IG1heSBiZSB0aGUgcmVn aXN0cmF0aW9uIHN0ZXAgdGhhdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZWVkczxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbi48YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAodGhpcyBpcyB0aGUgZmly c3QgdGltZSA6cCkgYnV0IEkgZG8gZGlzYWdyZWUgd2l0aCB5b3UuIEl0IHdvdWxkIGJlPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgcHJldHR5IHVucHJhY3RpY2FsIHRvIGJsb2NrIHRoaXMgYXQgcmVn aXN0cmF0aW9uIHRpbWXigKYuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSU1ITyB0aGUgYmVzdCBh cHByb2FjaCBpcyB0aGUgb25lIHRha2VuIGZyb20gR29vZ2xlLCBuYW1lbHk8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyByZXR1cm5pbmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA0MDAgd2l0aCB0aGUg Y2F1c2Ugb2YgdGhlIGVycm9yLi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAqNDAwLiogVGhhdOKAmXMgYW4gZXJyb3IuPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkVycm9yOiBpbnZhbGlkX3Njb3BlKjxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNvbWUgcmVxdWVzdGVkIHNj b3BlcyB3ZXJlIGludmFsaWQuIHtpbnZhbGlkPVtsXX08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzYWlkIHRoYXQgSSBob3BlIHlvdSBhbGwgYWdyZWUgdGhp cyBpcyBhbiBpc3N1ZSBpbiB0aGUgc3BlYyBzbzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZhcuKA pi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdhcmRz PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW50b25pbzxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSm9obiBCLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gU2VwIDMsIDIwMTQsIGF0IDEyOjEwIFBNLCBC aWxsIEJ1cmtlICZsdDtiYnVya2VAcmVkaGF0LmNvbTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAmbHQ7bWFpbHRvOmJidXJrZUByZWRoYXQuY29tJmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmbHQ7bWFpbHRvOmJidXJrZUByZWRoYXQuY29tJmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmbHQ7bWFpbHRvOmJidXJrZUByZWRoYXQuY29tJmd0OyZndDsgd3JvdGU6PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBk b24ndCB1bmRlcnN0YW5kLiZuYnNwOyBUaGUgcmVkaXJlY3QgdXJpIGhhcyB0byBiZSB2YWxpZCBp bjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3JkZXIgZm9yIGE8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZGlyZWN0IHRvIGhhcHBlbi4mbmJzcDsgVGhlIHNwZWMgZXhw bGljaXRseSBzdGF0ZXMgdGhpcy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDkvMy8yMDE0IDExOjQzIEFNLCBBbnRv bmlvIFNhbnNvIHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhpICos PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSU1ITyBwcm92aWRlcnMgdGhhdCBzdHJpY3RseSBmb2xsb3cgcmZjNjc0 OSBhcmUgdnVsbmVyYWJsZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIG9w ZW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWRpcmVjdC48YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBMZXQgbWUgZXhwbGFpbiwgcmVhZGluZyBbMF08YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBJZiB0aGUgcmVxdWVzdCBmYWlscyBkdWUgdG8gYSBtaXNzaW5nLCBpbnZhbGlk LCBvciBtaXNtYXRjaGluZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZGly ZWN0aW9uIFVSSSwgb3IgaWYgdGhlIGNsaWVudCBpZGVudGlmaWVyIGlzIG1pc3Npbmcgb3I8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnZhbGlkLDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaW5mb3Jt IHRoZSByZXNvdXJjZSBvd25lciBvZiB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBlcnJvciBhbmQgTVVTVCBOT1QgYXV0b21hdGljYWxseSByZWRpcmVjdCB0aGUgdXNlci1h Z2VudCB0byB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnZhbGlkIHJl ZGlyZWN0aW9uIFVSSS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgcmVzb3VyY2Ugb3duZXIgZGVuaWVz IHRoZSBhY2Nlc3MgcmVxdWVzdCBvciBpZiB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyByZXF1ZXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZmFpbHMg Zm9yIHJlYXNvbnMgb3RoZXIgdGhhbiBhIG1pc3Npbmcgb3IgaW52YWxpZDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZGlyZWN0aW9uIFVSSSw8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5mb3JtcyB0aGUgY2xp ZW50IGJ5IGFkZGluZyB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb2xs b3dpbmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXJhbWV0ZXJzIHRvIHRo ZSBxdWVyeSBjb21wb25lbnQgb2YgdGhlIHJlZGlyZWN0aW9uIFVSSTxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVzaW5nIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7ICJhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQiIGZvcm1hdCwgcGVyQXBw ZW5kaXggQjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNhcHBlbmRpeC1CJmd0Ozo8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBO b3cgbGV04oCZcyBhc3N1bWUgdGhpcy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJIGFtIHJlZ2lzdGVyaW5nIGEgbmV3IGNsaWVudCB0byB0aGV2aWN0aW0uY29tPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O2h0dHA6Ly90aGV2aWN0aW0uY29tLyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7aHR0cDovL3ZpY3RpbS5jb20v Jmd0OyZsdDtodHRwOi8vdmljdGltLmNvbSAmbHQ7aHR0cDovL3ZpY3RpbS5jb20vJmd0Ozxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtodHRwOi8vdmljdGltLmNvbS8mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtodHRwOi8vdmljdGlt LmNvbSAmbHQ7aHR0cDovL3ZpY3RpbS5jb20vJmd0OyAmbHQ7aHR0cDovL3ZpY3RpbS5jb20vJmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm92aWRlci48YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIHJlZ2lzdGVyIHJlZGlyZWN0IHVyaWF0dGFj a2VyLmNvbSAmbHQ7aHR0cDovL3VyaWF0dGFja2VyLmNvbS8mZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O2h0dHA6Ly9hdHRhY2tlci5jb20vJmd0OyZsdDtodHRwOi8v YXR0YWNrZXIuY29tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O2h0dHA6 Ly9hdHRhY2tlci5jb20vJmd0OyAmbHQ7aHR0cDovL2F0dGFja2VyLmNvbS8mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtodHRwOi8vYXR0YWNrZXIuY29tICZs dDtodHRwOi8vYXR0YWNrZXIuY29tLyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmbHQ7aHR0cDovL2F0dGFja2VyLmNvbS8mZ3Q7Jmd0Oy48YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBY2Nv cmRpbmcgdG8gWzBdIGlmIEkgcGFzcyBlLmcuIHRoZSB3cm9uZyBzY29wZSBJIGFtIHJlZGlyZWN0 ZWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiYWNrIHRvPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXR0YWNrZXIuY29tICZsdDtodHRwOi8vYXR0YWNrZXIu Y29tLyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7aHR0cDovL2F0 dGFja2VyLmNvbS8mZ3Q7Jmx0O2h0dHA6Ly9hdHRhY2tlci5jb208YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7aHR0cDovL2F0dGFja2VyLmNvbS8mZ3Q7PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O2h0dHA6Ly9hdHRhY2tlci5jb20vJmd0OyZndDsg Jmx0O2h0dHA6Ly9hdHRhY2tlci5jb208YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAmbHQ7aHR0cDovL2F0dGFja2VyLmNvbS8mZ3Q7ICZsdDtodHRwOi8vYXR0YWNrZXIuY29tLyZn dDsmZ3Q7Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5hbWVseSBJIHByZXBh cmUgYSB1cmwgdGhhdCBpcyBpbiB0aGlzIGZvcm06PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cDovL3ZpY3Rp bS5jb20vYXV0aG9yaXplP3Jlc3BvbnNlX3R5cGU9Y29kZSZhbXA7Y2xpZW50X2lkPWJjODhGaXRY MTI5OEtQajJXUzI1OUJCTWE5X0tDZkwzJmFtcDtzY29wZT1XUk9OR19TQ09QRSZhbXA7cmVkaXJl Y3RfdXJpPWh0dHA6Ly9hdHRhY2tlci5jb208YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgdGhpcyBpcyB3b3Jr cyBhcyBhbiBvcGVuIHJlZGlyZWN0b3IuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgT2YgY291cnNlIGluIHRoZSBwb3NpdGl2ZSBjYXNlIGlmIGFsbCB0aGUgcGFyYW1ldGVycyBh cmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmaW5lIHRoaXM8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzbuKAmXQgYXBwbHkgc2luY2UgdGhlIHJlc291 cmNlIG93bmVyIE1VU1QgYXBwcm92ZSB0aGUgYXBwPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdmlhIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnNl bnQgc2NyZWVuIChhdCBsZWFzdCBvbmNlKS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBIHNvbHV0aW9uIHdvdWxk IGJlIHRvIHJldHVybiBlcnJvciA0MDAgcmF0aGVyIHRoYW4gcmVkaXJlY3Q8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyByZWRpcmVjdCBVUkkgKGFzIHNvbWUgcHJvdmlkZXIgZS5nLiBHb29nbGUgZG8pPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgV0RZVD88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdhcmRzPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW50 b25pbzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFswXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0 OSNzZWN0aW9uLTQuMS4yLjE8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoQGlldGYub3JnICZsdDttYWls dG86T0F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLTxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmlsbCBCdXJrZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSkJvc3MsIGEgZGl2aXNpb24gb2YgUmVkIEhhdDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgaHR0cDovL2JpbGwuYnVya2VjZW50cmFsLmNvbSAmbHQ7aHR0cDovL2Jp bGwuYnVya2VjZW50cmFsLmNvbS8mZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoQGlldGYu b3JnICZsdDttYWlsdG86T0F1dGhAaWV0Zi5vcmcmZ3Q7ICZsdDttYWlsdG86T0F1dGhAaWV0Zi5v cmcmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGhAaWV0Zi5vcmcgJmx0O21haWx0bzpP QXV0aEBpZXRmLm9yZyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O21haWx0bzpP QXV0aEBpZXRmLm9yZyZndDsmbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aEBpZXRmLm9yZyAm bHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0OyAmbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0 Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS08YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEhhbnMgWmFuZGJlbHQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBTci4g VGVjaG5pY2FsIEFyY2hpdGVjdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHphbmRiZWx0QHBpbmdpZGVu dGl0eS5jb20gJmx0O21haWx0bzpoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNvbSZndDs8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICZsdDttYWlsdG86aHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb20mZ3Q7fCBQ aW5nPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZGVudGl0eTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0t PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSGFucyBaYW5kYmVsdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFNyLiBUZWNo bmljYWwgQXJjaGl0ZWN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb20gJmx0 O21haWx0bzpoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNvbSZndDsgfDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBpbmcg SWRlbnRpdHk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IC0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhhbnMgWmFuZGJlbHQmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCBTci4gVGVjaG5pY2FsIEFyY2hpdGVjdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNvbSAm bHQ7bWFpbHRvOmh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tJmd0O3wgUGluZzxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZGVudGl0 eTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aEBp ZXRmLm9yZyAmbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGFucyBaYW5kYmVsdCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IFNyLiBUZWNobmljYWwgQXJjaGl0ZWN0PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHphbmRiZWx0QHBpbmdpZGVudGl0eS5j b20gfCBQaW5nIElkZW50aXR5PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBCaWxsIEJ1cmtlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEpCb3NzLCBh IGRpdmlzaW9uIG9mIFJlZCBIYXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg aHR0cDovL2JpbGwuYnVya2VjZW50cmFsLmNvbTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLSA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhhbnMgWmFuZGJlbHQmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCBTci4gVGVjaG5pY2FsIEFyY2hpdGVjdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb20gfCBQaW5nIElkZW50aXR5PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0OyZn dDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsgT0F1dGhAaWV0Zi5vcmc8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJy PiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+T0F1dGhAaWV0Zi5vcmc8YnI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj48L2JvZHk+ ----_com.android.email_17908325804640-- From nobody Tue Sep 16 00:52:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E341A0097 for ; Tue, 16 Sep 2014 00:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=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 qjE1toaI_d93 for ; Tue, 16 Sep 2014 00:52:49 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F44F1A0645 for ; Tue, 16 Sep 2014 00:52:41 -0700 (PDT) Received: from mail-wi0-f172.google.com ([209.85.212.172]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKVBfsQ2erCmfQktMsqWO460r4uTTbero2@postini.com; Tue, 16 Sep 2014 00:52:41 PDT Received: by mail-wi0-f172.google.com with SMTP id e4so5650095wiv.11 for ; Tue, 16 Sep 2014 00:52:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hI6CUkknqe00XX8ErKf6iTa6N5ex1Cep5vUlOYD7k8U=; b=a46wsEXPNxEasNJqP7ptcDq8nw67viwtR5ja1BP+Cy6CHJZUwFzsv1WZlEd5W8zt/y ls2HIXpDd5ydlJJJa0zkRgzbKcVElRkwgMDO7VHYdVJUBBgu9NaagBkt1IxwDaqz8loK i5FxSz9O2vI0XKrBKwJXf4NsnioWdqPsQE3kRNIO5QwvuNJym0t+BBP2C3gidtf65BVq s0sVIK5k/MZ6G2f2BkDN77eecHKBGmT3Gnw1VL2VIQp/7FXu9An4dq0YUYn5jmHhjYH+ MqS4VUVODkn93F/QpSQlhvGpXQdVUJqoRJr4Nb2yvnEErUfWYbXUx+/4RtRyn4PfmXFr EFKQ== X-Gm-Message-State: ALoCoQmewmv0CGHTN0t4Ga7YQm7PBSdDK6bkC8uHi5DGc5K+PuUJT6NatJvMrAvdbA69os/vm6X6mrTpWgnUXorsv6ZVcILqAYXiMvwhsJb/FuMQ23xB4iLscovsTqVN2NP/IS9b//tR X-Received: by 10.180.11.234 with SMTP id t10mr29436253wib.49.1410853954090; Tue, 16 Sep 2014 00:52:34 -0700 (PDT) X-Received: by 10.180.11.234 with SMTP id t10mr29436237wib.49.1410853953956; Tue, 16 Sep 2014 00:52:33 -0700 (PDT) Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by mx.google.com with ESMTPSA id gm2sm913005wib.15.2014.09.16.00.52.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Sep 2014 00:52:32 -0700 (PDT) Message-ID: <5417EC3D.8060601@pingidentity.com> Date: Tue, 16 Sep 2014 09:52:29 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Torsten Lodderstedt , "Richer, Justin P." , Antonio Sanso References: <5nofjvf5jjbcqjdv9bmdgdg0.1410846275737@email.android.com> In-Reply-To: <5nofjvf5jjbcqjdv9bmdgdg0.1410846275737@email.android.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iQPFY5IbJbeyJyULaJAID8-n9oE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 07:52:52 -0000 +1, Antonio and John convinced me that this is not limited to a registration curation problem although that is where the problems starts as Phil points out (and as much as I'd like it to stay there). There are and will be consumer OPs (like Google) that have no means to do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security consideration for OPs that have no policy in place to allow only trusted clients to register would be a good thing. The advice for those OPs would be to not send errors back to untrusted clients or do it only after explicit user interaction. Hans. On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote: > I think a security considerations addendum makes sense. > > regards, > Torsten. > > > -------- Ursprüngliche Nachricht -------- > Von: "Richer, Justin P." > Datum:15.09.2014 23:15 (GMT+01:00) > An: Antonio Sanso > Cc: oauth@ietf.org > Betreff: Re: [OAUTH-WG] open redirect in rfc6749 > > As we discussed before: This isn't really an open redirection in the > classical sense since nothing gets leaked and the URI is tied back to a > known (albeit malicious) client registration. And I thought the clear > solution was to have an AS not automatically redirect to an untrusted > client in error conditions, where "untrusted" is defined by the AS with > guidance. If anything this is a security considerations addendum. > > -- Justin > > On Sep 15, 2014, at 4:52 PM, Antonio Sanso wrote: > > > The problem is that a malicious client can register a malicious > redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 > does the rest (as previously discussed) > > > > regards > > > > antonio > > > > On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: > > > >> If a server accepts a URL from a client to be used as a redirect > that the server doesn’t recognize or is not registered, that is an open > redirect. > >> > >> The specification does no allow open-redirects, it considers this a > mis-configuration. > >> > >> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. > >> > >> Phil > >> > >> @independentid > >> www.independentid.com > >> phil.hunt@oracle.com > >> > >> > >> > >> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: > >> > >>> There may be a problem with semantics in this discussion. > >>> > >>> There is a redirect performed by athe authorization endpoint to a > fixed uri that is pre registered with the authorization server without > user prompting. > >>> > >>> That probably doesn't fit the strict definition of a open redirector. > >>> > >>> It may however create similar security issues in situations with > relatively open registration of clients. > >>> > >>> The largest issues are that the browser might leak information > across the redirect in the fragment or referrer. That has been used in > attacks against Facebook in the past. > >>> > >>> This is no where near the end of the world, however we need to > look at the security considerations and see if we can provide better > advice to implementors. In some cases returning a error to the browser > may be best. > >>> > >>> I don't think we need to go so far as not returning any error to > the client under any circumstance. > >>> > >>> John B. > >>> > >>> Sent from my iPhone > >>> > >>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: > >>>> > >>>> Simply not true. > >>>> > >>>> Phil > >>>> > >>>> @independentid > >>>> www.independentid.com > >>>> phil.hunt@oracle.com > >>>> > >>>> > >>>> > >>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote: > >>>>> > >>>>> hi *, > >>>>> > >>>>> my understanding is that there is a rough consensus that if an > OAuth Provider follows rfc6749 verbatim will end up having an open > redirector. > >>>>> My next question would be now, is there anything we can do to > raise some awareness about this issue? > >>>>> > >>>>> regards > >>>>> > >>>>> antonio > >>>>> > >>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt > wrote: > >>>>>> > >>>>>> I am convinced about the issue in the use case Antonio provided > but I hope not to close the door on returning errors to known and > trusted clients. Not sure anymore if that's possible though because the > distinction can't be "registered"... > >>>>>> > >>>>>> Hans. > >>>>>> > >>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: > >>>>>>> hi Bill > >>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: > >>>>>>>> > >>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our > IDM project. Thanks Antonio. What convinced me was that the user is > probably expecting a login screen. Since there is this expectation, it > might make it a little easier for the attacker to convince the user that > a spoofed login screen is real. I know this issue can only happen with > unrestricted registration, but, IMO, this proposed change doesn't really > have much of an effect on usability and is even backward compatible with > the current RFC. > >>>>>>>> > >>>>>>>> Wouldn't it better though to never do a redirect on an invalid > request and just display an error page? > >>>>>>> > >>>>>>> thanks for sharing your thoughts :). Display an error 400 is > what Google does :) > >>>>>>> > >>>>>>> regards > >>>>>>> > >>>>>>> antonio > >>>>>>> > >>>>>>>> > >>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: > >>>>>>>>> Hi Hans, > >>>>>>>>> > >>>>>>>>> I really fail to see how this can be addressed at > registration time for cases where registration is unrestricted (namely > all the big Providers) > >>>>>>>>> > >>>>>>>>> regards > >>>>>>>>> > >>>>>>>>> antonio > >>>>>>>>> > >>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt > wrote: > >>>>>>>>>> > >>>>>>>>>> Classifying like this must also mean that consent should not > be stored until the client is considered (admin) trusted, and admin > policy would interfere with user policy. > >>>>>>>>>> > >>>>>>>>>> IMHO the security consideration would apply only to > dynamically registered clients where registration is unrestricted; any > other form would involve some form of admin/user approval at > registration time, overcoming the concern at authorization time: there's > no auto-redirect flow possible for unknown clients. > >>>>>>>>>> > >>>>>>>>>> Hans. > >>>>>>>>>> > >>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: > >>>>>>>>>>> I think this advice isn't a bad idea, though it's of course > up to the AS > >>>>>>>>>>> what an "untrusted" client really is. In practice, this is > something > >>>>>>>>>>> that was registered by a non-sysadmin type person, either a > dynamically > >>>>>>>>>>> registered client or something available through self-service > >>>>>>>>>>> registration of some type. It's also reasonable that a > client, even > >>>>>>>>>>> dynamically registered, would be considered "trusted" if > enough time has > >>>>>>>>>>> passed and enough users have used it without things blowing up. > >>>>>>>>>>> > >>>>>>>>>>> -- Justin > >>>>>>>>>>> > >>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>>> > wrote: > >>>>>>>>>>> > >>>>>>>>>>>> hi again *, > >>>>>>>>>>>> > >>>>>>>>>>>> after thinking a bit further IMHO an alternative for the > untrusted > >>>>>>>>>>>> clients can also be to always present the consent screen > (at least > >>>>>>>>>>>> once) before any redirect. > >>>>>>>>>>>> Namely all providers I have seen show the consent screen > if all the > >>>>>>>>>>>> request parameters are correct and if the user accepts the > redirect > >>>>>>>>>>>> happens. > >>>>>>>>>>>> If one of the parameter (with the exclusion of the client > id and > >>>>>>>>>>>> redirect uri that are handled differently as for spec) is > wrong though > >>>>>>>>>>>> the redirect happens without the consent screen being shown.. > >>>>>>>>>>>> > >>>>>>>>>>>> WDYT? > >>>>>>>>>>>> > >>>>>>>>>>>> regards > >>>>>>>>>>>> > >>>>>>>>>>>> antonio > >>>>>>>>>>>> > >>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>>>> > wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Well, > >>>>>>>>>>>>> I do not know if this is only dynamic registration... > >>>>>>>>>>>>> let’s talk about real use cases, namely e.g. Google , > Facebook , > >>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know… :) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Said that what the other guys think? :) > >>>>>>>>>>>>> Would this deserve some “spec adjustment” ? I mean there > is a reason > >>>>>>>>>>>>> if Google is by choice “violating” the spec right? (I > assume to avoid > >>>>>>>>>>>>> open redirect…) > >>>>>>>>>>>>> But other implementers do follow the spec hence they have > this open > >>>>>>>>>>>>> redirector… and this is not nice IMHO... > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt > >>>>>>>>>>>>> > wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt > >>>>>>>>>>>>>>> > wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Is your concern clients that were registered using > dynamic client > >>>>>>>>>>>>>>>> registration? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> yes > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I think your issue is then with the trust model of > dynamic client > >>>>>>>>>>>>>> registration; that is left out of scope of the dynreg > spec (and the > >>>>>>>>>>>>>> concept is not even part of the core spec), but unless > you want > >>>>>>>>>>>>>> everything to be open (which typically would not be the > case), then > >>>>>>>>>>>>>> it would involve approval somewhere in the process > before the client > >>>>>>>>>>>>>> is registered. Without dynamic client registration that > approval is > >>>>>>>>>>>>>> admin based or resource owner based, depending on use case. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to > a valid URL > >>>>>>>>>>>>>>>> that belongs to a client that was registered > explicitly by the > >>>>>>>>>>>>>>>> resource owner > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> well AFAIK the resource owner doesn’t register clients… > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> roles can collapse in use cases especially when using > dynamic client > >>>>>>>>>>>>>> registration > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> and the negative case is returning an error to that > same URL. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> the difference is the consent screen… in the positive > case you need > >>>>>>>>>>>>>>> to approve an app.. for the error case no approval is > needed,,, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I fail to see the open redirect. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> why? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly > approved at > >>>>>>>>>>>>>> some point > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hans. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hans. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: > why would you > >>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is > provided and > >>>>>>>>>>>>>>>>>> call it > >>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid > scope is > >>>>>>>>>>>>>>>>>> provided? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> as specified below in the positive case (namely when > the correct > >>>>>>>>>>>>>>>>> scope > >>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app > via the consent > >>>>>>>>>>>>>>>>> screen (at least once). > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Hans. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: > >>>>>>>>>>>>>>>>>>> hi John, > >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the > attacker. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client > registrations with > >>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates > that a client > >>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I think that if anything it may be the > registration step that > >>>>>>>>>>>>>>>>>>>> needs > >>>>>>>>>>>>>>>>>>>> the security consideration. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with > you. It would be > >>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time…. > >>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from > Google, namely > >>>>>>>>>>>>>>>>>>> returning > >>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> *400.* That’s an error. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> *Error: invalid_scope* > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in > the spec so > >>>>>>>>>>>>>>>>>>> far…. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> regards > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> antonio > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> John B. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be > valid in > >>>>>>>>>>>>>>>>>>>>> order for a > >>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: > >>>>>>>>>>>>>>>>>>>>>> hi *, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are > vulnerable > >>>>>>>>>>>>>>>>>>>>>> to open > >>>>>>>>>>>>>>>>>>>>>> redirect. > >>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, > or mismatching > >>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is > missing or > >>>>>>>>>>>>>>>>>>>>>> invalid, > >>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the > resource owner of the > >>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the > user-agent to the > >>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request > or if the > >>>>>>>>>>>>>>>>>>>>>> request > >>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid > >>>>>>>>>>>>>>>>>>>>>> redirection URI, > >>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by > adding the > >>>>>>>>>>>>>>>>>>>>>> following > >>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the > redirection URI > >>>>>>>>>>>>>>>>>>>>>> using the > >>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, > perAppendix B > >>>>>>>>>>>>>>>>>>>>>> : > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Now let’s assume this. > >>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> provider. > >>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com > > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope > I am redirected > >>>>>>>>>>>>>>>>>>>>>> back to > >>>>>>>>>>>>>>>>>>>>>> attacker.com > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >. > >>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. > >>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the > parameters are > >>>>>>>>>>>>>>>>>>>>>> fine this > >>>>>>>>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST > approve the app > >>>>>>>>>>>>>>>>>>>>>> via the > >>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather > than redirect > >>>>>>>>>>>>>>>>>>>>>> to the > >>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> WDYT? > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> regards > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> antonio > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> [0] > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>>>>>>>> OAuth mailing list > >>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org > >>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>> Bill Burke > >>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat > >>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com > > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>>>>>> OAuth mailing list > >>>>>>>>>>>>>>>>>>> OAuth@ietf.org > > >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect > >>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com > > >>>>>>>>>>>>>>>>>> | Ping > >>>>>>>>>>>>>>>>>> Identity > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect > >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com > | > >>>>>>>>>>>>>>>> Ping Identity > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect > >>>>>>>>>>>>>> hzandbelt@pingidentity.com > | Ping > >>>>>>>>>>>>>> Identity > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> OAuth mailing list > >>>>>>>>>>>> OAuth@ietf.org > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect > >>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> OAuth mailing list > >>>>>>>>> OAuth@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Bill Burke > >>>>>>>> JBoss, a division of Red Hat > >>>>>>>> http://bill.burkecentral.com > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>> > >>>>>> -- > >>>>>> Hans Zandbelt | Sr. Technical Architect > >>>>>> hzandbelt@pingidentity.com | Ping Identity > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> > > > > _______________________________________________ > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Tue Sep 16 01:45:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095821A000A for ; Tue, 16 Sep 2014 01:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 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, FRT_ADOBE2=2.455, SPF_PASS=-0.001] autolearn=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 O16ww8Y0JgPk for ; Tue, 16 Sep 2014 01:44:58 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A061A00FB for ; Tue, 16 Sep 2014 01:44:57 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so5043931wgg.21 for ; Tue, 16 Sep 2014 01:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VrfGwfezGuVok4vcohMndfII9ihM0h3F/FQW12LG1jc=; b=hmmsVptKzM9KTx/lcRMBl0u3VH0sBJbjnMFuGVb81FQTZHni/PUdLIOo/eTslTis8f 6Wrdi+OUnBTbqLqiKwVi7LhE3fykujdoxTBtB9JHk3eltmyv7BMQuAxAM7qlMW1jmvNR ISiGfwiLqtsRtInzMSUGpwSu1cTm13TGBIJC4x/sUhMfIjSqumut7O4vRcIt6HpVcVry KTDu1mcFpb0o9Y5M/gi4CETQ6GxqIhNj/Ndwyq8HcAXVwYkEJBL2UgypTBwgJEK8aas4 1WcwBGoEPltJTt60DkSZKMwJksvlnMDoAtr9WzOEKJidI+aXQOGjc+rnfKMxhLOBQVyw qZSw== X-Received: by 10.194.78.4 with SMTP id x4mr40905314wjw.44.1410857096484; Tue, 16 Sep 2014 01:44:56 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id ub19sm1077191wib.9.2014.09.16.01.44.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Sep 2014 01:44:55 -0700 (PDT) Message-ID: <5417F886.4030801@gmail.com> Date: Tue, 16 Sep 2014 09:44:54 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Hans Zandbelt References: <5nofjvf5jjbcqjdv9bmdgdg0.1410846275737@email.android.com> <5417EC3D.8060601@pingidentity.com> <5417F820.8000804@gmail.com> In-Reply-To: <5417F820.8000804@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zt0GlcWcI0U1hAdDNoMCEtUcFC0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 08:45:02 -0000 Hi I wonder, when we have a situation where any client, the malicious clients, or good clients, all of them can easily register and provide bad redirect URIs, intentionally or unintentionally, then does it imply there's serious a weakness present somewhere else, in the registration process for example ? Should the client registrations be validated ? Sergey > > On 16/09/14 08:52, Hans Zandbelt wrote: >> +1, Antonio and John convinced me that this is not limited to a >> registration curation problem although that is where the problems starts >> as Phil points out (and as much as I'd like it to stay there). >> >> There are and will be consumer OPs (like Google) that have no means to >> do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security >> consideration for OPs that have no policy in place to allow only trusted >> clients to register would be a good thing. >> >> The advice for those OPs would be to not send errors back to untrusted >> clients or do it only after explicit user interaction. >> >> Hans. >> >> On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote: >>> I think a security considerations addendum makes sense. >>> >>> regards, >>> Torsten. >>> >>> >>> -------- Ursprüngliche Nachricht -------- >>> Von: "Richer, Justin P." >>> Datum:15.09.2014 23:15 (GMT+01:00) >>> An: Antonio Sanso >>> Cc: oauth@ietf.org >>> Betreff: Re: [OAUTH-WG] open redirect in rfc6749 >>> >>> As we discussed before: This isn't really an open redirection in the >>> classical sense since nothing gets leaked and the URI is tied back to a >>> known (albeit malicious) client registration. And I thought the clear >>> solution was to have an AS not automatically redirect to an untrusted >>> client in error conditions, where "untrusted" is defined by the AS with >>> guidance. If anything this is a security considerations addendum. >>> >>> -- Justin >>> >>> On Sep 15, 2014, at 4:52 PM, Antonio Sanso wrote: >>> >>> > The problem is that a malicious client can register a malicious >>> redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>> does the rest (as previously discussed) >>> > >>> > regards >>> > >>> > antonio >>> > >>> > On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: >>> > >>> >> If a server accepts a URL from a client to be used as a redirect >>> that the server doesn’t recognize or is not registered, that is an open >>> redirect. >>> >> >>> >> The specification does no allow open-redirects, it considers this a >>> mis-configuration. >>> >> >>> >> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>> >> >>> >> Phil >>> >> >>> >> @independentid >>> >> www.independentid.com >>> >> phil.hunt@oracle.com >>> >> >>> >> >>> >> >>> >> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >>> >> >>> >>> There may be a problem with semantics in this discussion. >>> >>> >>> >>> There is a redirect performed by athe authorization endpoint to a >>> fixed uri that is pre registered with the authorization server without >>> user prompting. >>> >>> >>> >>> That probably doesn't fit the strict definition of a open >>> redirector. >>> >>> >>> >>> It may however create similar security issues in situations with >>> relatively open registration of clients. >>> >>> >>> >>> The largest issues are that the browser might leak information >>> across the redirect in the fragment or referrer. That has been used in >>> attacks against Facebook in the past. >>> >>> >>> >>> This is no where near the end of the world, however we need to >>> look at the security considerations and see if we can provide better >>> advice to implementors. In some cases returning a error to the browser >>> may be best. >>> >>> >>> >>> I don't think we need to go so far as not returning any error to >>> the client under any circumstance. >>> >>> >>> >>> John B. >>> >>> >>> >>> Sent from my iPhone >>> >>> >>> >>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt >>> wrote: >>> >>>> >>> >>>> Simply not true. >>> >>>> >>> >>>> Phil >>> >>>> >>> >>>> @independentid >>> >>>> www.independentid.com >>> >>>> phil.hunt@oracle.com >>> >>>> >>> >>>> >>> >>>> >>> >>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso >>> wrote: >>> >>>>> >>> >>>>> hi *, >>> >>>>> >>> >>>>> my understanding is that there is a rough consensus that if an >>> OAuth Provider follows rfc6749 verbatim will end up having an open >>> redirector. >>> >>>>> My next question would be now, is there anything we can do to >>> raise some awareness about this issue? >>> >>>>> >>> >>>>> regards >>> >>>>> >>> >>>>> antonio >>> >>>>> >>> >>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt >>> wrote: >>> >>>>>> >>> >>>>>> I am convinced about the issue in the use case Antonio provided >>> but I hope not to close the door on returning errors to known and >>> trusted clients. Not sure anymore if that's possible though because the >>> distinction can't be "registered"... >>> >>>>>> >>> >>>>>> Hans. >>> >>>>>> >>> >>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>> >>>>>>> hi Bill >>> >>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke >>> wrote: >>> >>>>>>>> >>> >>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our >>> IDM project. Thanks Antonio. What convinced me was that the user is >>> probably expecting a login screen. Since there is this expectation, it >>> might make it a little easier for the attacker to convince the user that >>> a spoofed login screen is real. I know this issue can only happen with >>> unrestricted registration, but, IMO, this proposed change doesn't really >>> have much of an effect on usability and is even backward compatible with >>> the current RFC. >>> >>>>>>>> >>> >>>>>>>> Wouldn't it better though to never do a redirect on an invalid >>> request and just display an error page? >>> >>>>>>> >>> >>>>>>> thanks for sharing your thoughts :). Display an error 400 is >>> what Google does :) >>> >>>>>>> >>> >>>>>>> regards >>> >>>>>>> >>> >>>>>>> antonio >>> >>>>>>> >>> >>>>>>>> >>> >>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>> >>>>>>>>> Hi Hans, >>> >>>>>>>>> >>> >>>>>>>>> I really fail to see how this can be addressed at >>> registration time for cases where registration is unrestricted (namely >>> all the big Providers) >>> >>>>>>>>> >>> >>>>>>>>> regards >>> >>>>>>>>> >>> >>>>>>>>> antonio >>> >>>>>>>>> >>> >>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt >>> wrote: >>> >>>>>>>>>> >>> >>>>>>>>>> Classifying like this must also mean that consent should not >>> be stored until the client is considered (admin) trusted, and admin >>> policy would interfere with user policy. >>> >>>>>>>>>> >>> >>>>>>>>>> IMHO the security consideration would apply only to >>> dynamically registered clients where registration is unrestricted; any >>> other form would involve some form of admin/user approval at >>> registration time, overcoming the concern at authorization time: there's >>> no auto-redirect flow possible for unknown clients. >>> >>>>>>>>>> >>> >>>>>>>>>> Hans. >>> >>>>>>>>>> >>> >>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>> >>>>>>>>>>> I think this advice isn't a bad idea, though it's of course >>> up to the AS >>> >>>>>>>>>>> what an "untrusted" client really is. In practice, this is >>> something >>> >>>>>>>>>>> that was registered by a non-sysadmin type person, either a >>> dynamically >>> >>>>>>>>>>> registered client or something available through >>> self-service >>> >>>>>>>>>>> registration of some type. It's also reasonable that a >>> client, even >>> >>>>>>>>>>> dynamically registered, would be considered "trusted" if >>> enough time has >>> >>>>>>>>>>> passed and enough users have used it without things >>> blowing up. >>> >>>>>>>>>>> >>> >>>>>>>>>>> -- Justin >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >> >>>>>>>>>>> > wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>>> hi again *, >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> after thinking a bit further IMHO an alternative for the >>> untrusted >>> >>>>>>>>>>>> clients can also be to always present the consent screen >>> (at least >>> >>>>>>>>>>>> once) before any redirect. >>> >>>>>>>>>>>> Namely all providers I have seen show the consent screen >>> if all the >>> >>>>>>>>>>>> request parameters are correct and if the user accepts the >>> redirect >>> >>>>>>>>>>>> happens. >>> >>>>>>>>>>>> If one of the parameter (with the exclusion of the client >>> id and >>> >>>>>>>>>>>> redirect uri that are handled differently as for spec) is >>> wrong though >>> >>>>>>>>>>>> the redirect happens without the consent screen being >>> shown.. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> WDYT? >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> regards >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> antonio >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>> >> >>>>>>>>>>>> > wrote: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>>> Well, >>> >>>>>>>>>>>>> I do not know if this is only dynamic registration... >>> >>>>>>>>>>>>> let’s talk about real use cases, namely e.g. Google , >>> Facebook , >>> >>>>>>>>>>>>> etc.. is that dynamic client registration? I do not >>> know… :) >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Said that what the other guys think? :) >>> >>>>>>>>>>>>> Would this deserve some “spec adjustment” ? I mean there >>> is a reason >>> >>>>>>>>>>>>> if Google is by choice “violating” the spec right? (I >>> assume to avoid >>> >>>>>>>>>>>>> open redirect…) >>> >>>>>>>>>>>>> But other implementers do follow the spec hence they have >>> this open >>> >>>>>>>>>>>>> redirector… and this is not nice IMHO... >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>> >> >>>>>>>>>>>>> > wrote: >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>> >>>>>>>>>>>>>>> >> > wrote: >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> Is your concern clients that were registered using >>> dynamic client >>> >>>>>>>>>>>>>>>> registration? >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> yes >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> I think your issue is then with the trust model of >>> dynamic client >>> >>>>>>>>>>>>>> registration; that is left out of scope of the dynreg >>> spec (and the >>> >>>>>>>>>>>>>> concept is not even part of the core spec), but unless >>> you want >>> >>>>>>>>>>>>>> everything to be open (which typically would not be the >>> case), then >>> >>>>>>>>>>>>>> it would involve approval somewhere in the process >>> before the client >>> >>>>>>>>>>>>>> is registered. Without dynamic client registration that >>> approval is >>> >>>>>>>>>>>>>> admin based or resource owner based, depending on use >>> case. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to >>> a valid URL >>> >>>>>>>>>>>>>>>> that belongs to a client that was registered >>> explicitly by the >>> >>>>>>>>>>>>>>>> resource owner >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> well AFAIK the resource owner doesn’t register clients… >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> roles can collapse in use cases especially when using >>> dynamic client >>> >>>>>>>>>>>>>> registration >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> and the negative case is returning an error to that >>> same URL. >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> the difference is the consent screen… in the positive >>> case you need >>> >>>>>>>>>>>>>>> to approve an app.. for the error case no approval is >>> needed,,, >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> I fail to see the open redirect. >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> why? >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly >>> approved at >>> >>>>>>>>>>>>>> some point >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Hans. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> Hans. >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>> >>>>>>>>>>>>>>>>> >> >>> >>>>>>>>>>>>>>>>> > wrote: >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: >>> why would you >>> >>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is >>> provided and >>> >>>>>>>>>>>>>>>>>> call it >>> >>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid >>> scope is >>> >>>>>>>>>>>>>>>>>> provided? >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> as specified below in the positive case (namely when >>> the correct >>> >>>>>>>>>>>>>>>>> scope >>> >>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app >>> via the consent >>> >>>>>>>>>>>>>>>>> screen (at least once). >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> Hans. >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>> >>>>>>>>>>>>>>>>>>> hi John, >>> >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>> >> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> > wrote: >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the >>> attacker. >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client >>> registrations with >>> >>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates >>> that a client >>> >>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> I think that if anything it may be the >>> registration step that >>> >>>>>>>>>>>>>>>>>>>> needs >>> >>>>>>>>>>>>>>>>>>>> the security consideration. >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with >>> you. It would be >>> >>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration >>> time…. >>> >>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from >>> Google, namely >>> >>>>>>>>>>>>>>>>>>> returning >>> >>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> *400.* That’s an error. >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in >>> the spec so >>> >>>>>>>>>>>>>>>>>>> far…. >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> regards >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> antonio >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> John B. >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>> > wrote: >>> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be >>> valid in >>> >>>>>>>>>>>>>>>>>>>>> order for a >>> >>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states >>> this. >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>> >>>>>>>>>>>>>>>>>>>>>> hi *, >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are >>> vulnerable >>> >>>>>>>>>>>>>>>>>>>>>> to open >>> >>>>>>>>>>>>>>>>>>>>>> redirect. >>> >>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, >>> or mismatching >>> >>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is >>> missing or >>> >>>>>>>>>>>>>>>>>>>>>> invalid, >>> >>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the >>> resource owner of the >>> >>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the >>> user-agent to the >>> >>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request >>> or if the >>> >>>>>>>>>>>>>>>>>>>>>> request >>> >>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or >>> invalid >>> >>>>>>>>>>>>>>>>>>>>>> redirection URI, >>> >>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by >>> adding the >>> >>>>>>>>>>>>>>>>>>>>>> following >>> >>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the >>> redirection URI >>> >>>>>>>>>>>>>>>>>>>>>> using the >>> >>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, >>> perAppendix B >>> >>>>>>>>>>>>>>>>>>>>>> >>> : >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> Now let’s assume this. >>> >>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> >> >>> >>>>>>>>>>>>>>>>>>>>>> > >>> >>>>>>>>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>>>>>>>> provider. >>> >>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>> >>> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> > >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> >. >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope >>> I am redirected >>> >>>>>>>>>>>>>>>>>>>>>> back to >>> >>>>>>>>>>>>>>>>>>>>>> attacker.com >>> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>>>>>>> >. >>> >>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> >>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>> >>> >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>> >>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the >>> parameters are >>> >>>>>>>>>>>>>>>>>>>>>> fine this >>> >>>>>>>>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST >>> approve the app >>> >>>>>>>>>>>>>>>>>>>>>> via the >>> >>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather >>> than redirect >>> >>>>>>>>>>>>>>>>>>>>>> to the >>> >>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> WDYT? >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> regards >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> antonio >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> [0] >>> https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>>>>>>>>> Bill Burke >>> >>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>> >>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>> >>> >>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>>>>>>>>>>> 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 >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>> >>> >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>> >>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>> >>> >>>>>>>>>>>>>>>>>> | Ping >>> >>>>>>>>>>>>>>>>>> Identity >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>> >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>> | >>> >>>>>>>>>>>>>>>> Ping Identity >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>> >>>>>>>>>>>>>> hzandbelt@pingidentity.com >>> | Ping >>> >>>>>>>>>>>>>> Identity >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>>> OAuth mailing list >>> >>>>>>>>>>>> OAuth@ietf.org >>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>>>> >>> >>>>>>>>>> -- >>> >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>> >>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>> >>>>>>>>> >>> >>>>>>>>> _______________________________________________ >>> >>>>>>>>> OAuth mailing list >>> >>>>>>>>> OAuth@ietf.org >>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>>>>>> >>> >>>>>>>> -- >>> >>>>>>>> Bill Burke >>> >>>>>>>> JBoss, a division of Red Hat >>> >>>>>>>> http://bill.burkecentral.com >>> >>>>>>>> >>> >>>>>>>> _______________________________________________ >>> >>>>>>>> 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 >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Hans Zandbelt | Sr. Technical Architect >>> >>>>>> hzandbelt@pingidentity.com | Ping Identity >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> 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 >>> >> >>> > >>> > _______________________________________________ >>> > 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 >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com From nobody Tue Sep 16 01:53:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034E21A01E8 for ; Tue, 16 Sep 2014 01:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 nRjbtQteXzyR for ; Tue, 16 Sep 2014 01:53:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0614.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:614]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE20A1A0428 for ; Tue, 16 Sep 2014 01:52:47 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Tue, 16 Sep 2014 08:52:24 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.112]) with mapi id 15.00.1024.012; Tue, 16 Sep 2014 08:52:24 +0000 From: Antonio Sanso To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHP0YNSkKtdFG+ezkuqdvp/CtER9pwDckILgAAB8QA= Date: Tue, 16 Sep 2014 08:52:23 +0000 Message-ID: <4DE5DA70-605F-42CD-A698-9AF930890393@adobe.com> References: <5nofjvf5jjbcqjdv9bmdgdg0.1410846275737@email.android.com> <5417EC3D.8060601@pingidentity.com> <5417F820.8000804@gmail.com> <5417F886.4030801@gmail.com> In-Reply-To: <5417F886.4030801@gmail.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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(51444003)(24454002)(377454003)(52604005)(479174003)(51704005)(199003)(189002)(587094003)(90102001)(87936001)(105586002)(110136001)(106356001)(107046002)(2656002)(101416001)(83072002)(83716003)(54356999)(15395725005)(85306004)(31966008)(19580405001)(36756003)(77982003)(74662003)(80022003)(81542003)(79102003)(81342003)(46102003)(74502003)(19580395003)(64706001)(85852003)(66066001)(93886004)(83322001)(97736003)(76176999)(20776003)(92726001)(76482001)(92566001)(86362001)(50986999)(106116001)(82746002)(99396002)(15202345003)(4396001)(99286002)(16236675004)(77096002)(15975445006)(33656002)(21056001)(95666004)(19617315012)(16601075003)(104396001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_4DE5DA70605F42CDA6989AF930890393adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AJqpttwsaQPu7dn7YLD-KHw4PWA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 08:53:33 -0000 --_000_4DE5DA70605F42CDA6989AF930890393adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable hi Sergey On Sep 16, 2014, at 10:44 AM, Sergey Beryozkin > wrote: Hi I wonder, when we have a situation where any client, the malicious clients, or good clients, all of them can easily register and provide bad redirect URIs, intentionally or unintentionally, then does it imply there's serious a weakness present somewhere else, in the registration process for example ? Should the client registrations be validated ? as previously discussed is pretty fought to filter bad redirect uri special= ly for big OPs like Facebook/Google et al where all you need to have in ord= er to create a new OAuth client is an email address (the registration proce= ss is self-service). Justin proposed some mitigation though=85 (namely a client can gain =91repu= tation=92 with time) regards antonio Sergey On 16/09/14 08:52, Hans Zandbelt wrote: +1, Antonio and John convinced me that this is not limited to a registration curation problem although that is where the problems starts as Phil points out (and as much as I'd like it to stay there). There are and will be consumer OPs (like Google) that have no means to do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security consideration for OPs that have no policy in place to allow only trusted clients to register would be a good thing. The advice for those OPs would be to not send errors back to untrusted clients or do it only after explicit user interaction. Hans. On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote: I think a security considerations addendum makes sense. regards, Torsten. -------- Urspr=FCngliche Nachricht -------- Von: "Richer, Justin P." Datum:15.09.2014 23:15 (GMT+01:00) An: Antonio Sanso Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] open redirect in rfc6749 As we discussed before: This isn't really an open redirection in the classical sense since nothing gets leaked and the URI is tied back to a known (albeit malicious) client registration. And I thought the clear solution was to have an AS not automatically redirect to an untrusted client in error conditions, where "untrusted" is defined by the AS with guidance. If anything this is a security considerations addendum. -- Justin On Sep 15, 2014, at 4:52 PM, Antonio Sanso > wrote: > The problem is that a malicious client can register a malicious redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as previously discussed) > > regards > > antonio > > On Sep 15, 2014, at 10:43 PM, Phil Hunt > wrote: > >> If a server accepts a URL from a client to be used as a redirect that the server doesn=92t recognize or is not registered, that is an open redirect. >> >> The specification does no allow open-redirects, it considers this a mis-configuration. >> >> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Sep 15, 2014, at 1:00 PM, John Bradley > wrote: >> >>> There may be a problem with semantics in this discussion. >>> >>> There is a redirect performed by athe authorization endpoint to a fixed uri that is pre registered with the authorization server without user prompting. >>> >>> That probably doesn't fit the strict definition of a open redirector. >>> >>> It may however create similar security issues in situations with relatively open registration of clients. >>> >>> The largest issues are that the browser might leak information across the redirect in the fragment or referrer. That has been used in attacks against Facebook in the past. >>> >>> This is no where near the end of the world, however we need to look at the security considerations and see if we can provide better advice to implementors. In some cases returning a error to the browser may be best. >>> >>> I don't think we need to go so far as not returning any error to the client under any circumstance. >>> >>> John B. >>> >>> Sent from my iPhone >>> >>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt > wrote: >>>> >>>> Simply not true. >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso > wrote: >>>>> >>>>> hi *, >>>>> >>>>> my understanding is that there is a rough consensus that if an OAuth Provider follows rfc6749 verbatim will end up having an open redirector. >>>>> My next question would be now, is there anything we can do to raise some awareness about this issue? >>>>> >>>>> regards >>>>> >>>>> antonio >>>>> >>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt > wrote: >>>>>> >>>>>> I am convinced about the issue in the use case Antonio provided but I hope not to close the door on returning errors to known and trusted clients. Not sure anymore if that's possible though because the distinction can't be "registered"... >>>>>> >>>>>> Hans. >>>>>> >>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>> hi Bill >>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke > wrote: >>>>>>>> >>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM project. Thanks Antonio. What convinced me was that the user is probably expecting a login screen. Since there is this expectation, it might make it a little easier for the attacker to convince the user that a spoofed login screen is real. I know this issue can only happen with unrestricted registration, but, IMO, this proposed change doesn't really have much of an effect on usability and is even backward compatible with the current RFC. >>>>>>>> >>>>>>>> Wouldn't it better though to never do a redirect on an invalid request and just display an error page? >>>>>>> >>>>>>> thanks for sharing your thoughts :). Display an error 400 is what Google does :) >>>>>>> >>>>>>> regards >>>>>>> >>>>>>> antonio >>>>>>> >>>>>>>> >>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>> Hi Hans, >>>>>>>>> >>>>>>>>> I really fail to see how this can be addressed at registration time for cases where registration is unrestricted (namely all the big Providers) >>>>>>>>> >>>>>>>>> regards >>>>>>>>> >>>>>>>>> antonio >>>>>>>>> >>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt > wrote: >>>>>>>>>> >>>>>>>>>> Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy. >>>>>>>>>> >>>>>>>>>> IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients. >>>>>>>>>> >>>>>>>>>> Hans. >>>>>>>>>> >>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>> I think this advice isn't a bad idea, though it's of course up to the AS >>>>>>>>>>> what an "untrusted" client really is. In practice, this is something >>>>>>>>>>> that was registered by a non-sysadmin type person, either a dynamically >>>>>>>>>>> registered client or something available through self-service >>>>>>>>>>> registration of some type. It's also reasonable that a client, even >>>>>>>>>>> dynamically registered, would be considered "trusted" if enough time has >>>>>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> hi again *, >>>>>>>>>>>> >>>>>>>>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>>>>>>>> clients can also be to always present the consent screen (at least >>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>> Namely all providers I have seen show the consent screen if all the >>>>>>>>>>>> request parameters are correct and if the user accepts the redirect >>>>>>>>>>>> happens. >>>>>>>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>>>>>>> redirect uri that are handled differently as for spec) is wrong though >>>>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>>> >>>>>>>>>>>> WDYT? >>>>>>>>>>>> >>>>>>>>>>>> regards >>>>>>>>>>>> >>>>>>>>>>>> antonio >>>>>>>>>>>> >>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Well, >>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , Facebook , >>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know=85 :) >>>>>>>>>>>>> >>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean there is a reason >>>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I assume to avoid >>>>>>>>>>>>> open redirect=85) >>>>>>>>>>>>> But other implementers do follow the spec hence they have this open >>>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is your concern clients that were registered using dynamic client >>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> yes >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec (and the >>>>>>>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>>>>>>> everything to be open (which typically would not be the case), then >>>>>>>>>>>>>> it would involve approval somewhere in the process before the client >>>>>>>>>>>>>> is registered. Without dynamic client registration that approval is >>>>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to a valid URL >>>>>>>>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients=85 >>>>>>>>>>>>>> >>>>>>>>>>>>>> roles can collapse in use cases especially when using dynamic client >>>>>>>>>>>>>> registration >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the difference is the consent screen=85 in the positive case you need >>>>>>>>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> why? >>>>>>>>>>>>>> >>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly approved at >>>>>>>>>>>>>> some point >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: why would you >>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> as specified below in the positive case (namely when the correct >>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via the consent >>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client registrations with >>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It would be >>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time=85. >>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST approve the app >>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than redirect >>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>>>>>>>> Identity >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> -- >>>>>>>> Bill Burke >>>>>>>> JBoss, a division of Red Hat >>>>>>>> http://bill.burkecentral.com >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > _______________________________________________ > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4DE5DA70605F42CDA6989AF930890393adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3E93F552A2D6C44D8CF4502CAD0D8D89@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable hi Sergey

On Sep 16, 2014, at 10:44 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:

Hi

I wonder, when we have a situation where any client, the malicious
clients, or good clients, all of them can easily register and provide
bad redirect URIs, intentionally or unintentionally, then does it imply
there's serious a weakness present somewhere else, in the
registration process for example ? Should the client registrations be
validated ?

as previously discussed is pretty fought to filter bad redirect uri sp= ecially for big OPs like Facebook/Google et al where all you need to have i= n order to create a new OAuth client is an email address (the registration = process is self-service).

Justin proposed some mitigation though=85 (namely a client can gain = =91reputation=92 with time)

regards

antonio


Sergey

On 16/09/14 08:52, Hans Zandbelt wrote:
+1, Antonio and John convinced me that this i= s not limited to a
registration curation problem although that is where the problems starts as Phil points out (and as much as I'd like it to stay there).

There are and will be consumer OPs (like Google) that have no means to
do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security consideration for OPs that have no policy in place to allow only trusted clients to register would be a good thing.

The advice for those OPs would be to not send errors back to untrusted
clients or do it only after explicit user interaction.

Hans.

On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote:
I think a security considerations addendum makes = sense.

regards,
Torsten.


-------- Urspr=FCngliche Nachricht --------
Von: "Richer, Justin P."
Datum:15.09.2014 23:15 (GMT+01:00)
An: Antonio Sanso
Cc: oauth@ietf.org
Betreff: Re: [OAUTH-WG] open redirect in rfc6749

As we discussed before: This isn't really an open redirection in the
classical sense since nothing gets leaked and the URI is tied back to a
known (albeit malicious) client registration. And I thought the clear
solution was to have an AS not automatically redirect to an untrusted
client in error conditions, where "untrusted" is defined by the A= S with
guidance. If anything this is a security considerations addendum.

-- Justin

On Sep 15, 2014, at 4:52 PM, Antonio Sanso <asanso@adobe.com> wrote:

> The problem is that a malicious client can register a malicious
redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1
does the rest (as previously discussed)
>
> regards
>
> antonio
>
> On Sep 15, 2014, at 10:43 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>
>> If a server accepts a URL from a client to be used as a redirect that the server doesn=92t recognize or is not registered, that is an open redirect.
>>
>> The specification does no allow open-redirects, it considers this = a
mis-configuration.
>>
>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com=
>> phil.hunt@oracle.com >>
>>
>>
>> On Sep 15, 2014, at 1:00 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>
>>> There may be a problem with semantics in this discussion.
>>>
>>> There is a redirect performed by athe authorization endpoint t= o a
fixed uri that is pre registered with the authorization server without
user prompting.
>>>
>>> That probably doesn't fit the strict definition of a open
redirector.
>>>
>>> It may however create similar security issues in situations wi= th
relatively open registration of clients.
>>>
>>> The largest issues are that the browser might leak information=
across the redirect in the fragment or referrer.  That has been used i= n
attacks against Facebook in the past.
>>>
>>> This is no where near the end of the world,  however we n= eed to
look at the security considerations and see if we can provide better
advice to implementors.  In some cases returning a error to the browse= r
may be best.
>>>
>>> I don't think we need to go so far as not returning any error = to
the client under any circumstance.
>>>
>>> John B.
>>>
>>> Sent from my iPhone
>>>
>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt <phil.hunt@oracle.com>
wrote:
>>>>
>>>> Simply not true.
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid= .com
>>>> phil.hunt@oracle.c= om
>>>>
>>>>
>>>>
>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso <asanso@adobe.com>
wrote:
>>>>>
>>>>> hi *,
>>>>>
>>>>> my understanding is that there is a rough consensus th= at if an
OAuth Provider follows rfc6749 verbatim will end up having an open
redirector.
>>>>> My next question would be now, is there anything we ca= n do to
raise some awareness about this issue?
>>>>>
>>>>> regards
>>>>>
>>>>> antonio
>>>>>
>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt
<hzandbelt@pingidentity.co= m> wrote:
>>>>>>
>>>>>> I am convinced about the issue in the use case Ant= onio provided
but I hope not to close the door on returning errors to known and
trusted clients. Not sure anymore if that's possible though because the
distinction can't be "registered"...
>>>>>>
>>>>>> Hans.
>>>>>>
>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote:
>>>>>>> hi Bill
>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke <= ;bburke@redhat.com>
wrote:
>>>>>>>>
>>>>>>>> FWIW, Antonio convinced me and I'm going t= o change this in our
IDM project.  Thanks Antonio.  What convinced me was that the use= r is
probably expecting a login screen.  Since there is this expectation, i= t
might make it a little easier for the attacker to convince the user that a spoofed login screen is real.  I know this issue can only happen wit= h
unrestricted registration, but, IMO, this proposed change doesn't really have much of an effect on usability and is even backward compatible with the current RFC.
>>>>>>>>
>>>>>>>> Wouldn't it better though to never do a re= direct on an invalid
request and just display an error page?
>>>>>>>
>>>>>>> thanks for sharing your thoughts :). Display a= n error 400 is
what Google does :)
>>>>>>>
>>>>>>> regards
>>>>>>>
>>>>>>> antonio
>>>>>>>
>>>>>>>>
>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wro= te:
>>>>>>>>> Hi Hans,
>>>>>>>>>
>>>>>>>>> I really fail to see how this can be a= ddressed at
registration time for cases where registration is unrestricted (namely
all the big Providers)
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>>
>>>>>>>>> antonio
>>>>>>>>>
>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Z= andbelt
<hzandbelt@pingidentity.co= m> wrote:
>>>>>>>>>>
>>>>>>>>>> Classifying like this must also me= an that consent should not
be stored until the client is considered (admin) trusted, and admin
policy would interfere with user policy.
>>>>>>>>>>
>>>>>>>>>> IMHO the security consideration wo= uld apply only to
dynamically registered clients where registration is unrestricted; any
other form would involve some form of admin/user approval at
registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients.
>>>>>>>>>>
>>>>>>>>>> Hans.
>>>>>>>>>>
>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Ju= stin P. wrote:
>>>>>>>>>>> I think this advice isn't a ba= d idea, though it's of course
up to the AS
>>>>>>>>>>> what an "untrusted" = client really is. In practice, this is
something
>>>>>>>>>>> that was registered by a non-s= ysadmin type person, either a
dynamically
>>>>>>>>>>> registered client or something= available through
self-service
>>>>>>>>>>> registration of some type. It'= s also reasonable that a
client, even
>>>>>>>>>>> dynamically registered, would = be considered "trusted" if
enough time has
>>>>>>>>>>> passed and enough users have u= sed it without things
blowing up.
>>>>>>>>>>>
>>>>>>>>>>> -- Justin
>>>>>>>>>>>
>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, An= tonio Sanso <asanso@adobe.com >>>>>>>>>>> <mailto:asanso@adobe.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> hi again *,
>>>>>>>>>>>>
>>>>>>>>>>>> after thinking a bit furth= er IMHO an alternative for the
untrusted
>>>>>>>>>>>> clients can also be to alw= ays present the consent screen
(at least
>>>>>>>>>>>> once) before any redirect.=
>>>>>>>>>>>> Namely all providers I hav= e seen show the consent screen
if all the
>>>>>>>>>>>> request parameters are cor= rect and if the user accepts the
redirect
>>>>>>>>>>>> happens.
>>>>>>>>>>>> If one of the parameter &n= bsp;(with the exclusion of the client
id and
>>>>>>>>>>>> redirect uri that are hand= led differently as for spec) is
wrong though
>>>>>>>>>>>> the redirect happens witho= ut the consent screen being
shown..
>>>>>>>>>>>>
>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>
>>>>>>>>>>>> regards
>>>>>>>>>>>>
>>>>>>>>>>>> antonio
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM= , Antonio Sanso
<asanso@adobe.com
>>>>>>>>>>>> <mailto:asanso@adobe.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Well,
>>>>>>>>>>>>> I do not know if this = is only dynamic registration...
>>>>>>>>>>>>> let=92s talk about rea= l use cases, namely e.g. Google ,
Facebook ,
>>>>>>>>>>>>> etc.. is that dynamic = client registration? I do not
know=85 :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Said that what the oth= er guys think?  :)
>>>>>>>>>>>>> Would this deserve som= e =93spec adjustment=94 ? I mean there
is a reason
>>>>>>>>>>>>> if Google is by choice= =93violating=94 the spec right? (I
assume to avoid
>>>>>>>>>>>>> open redirect=85)
>>>>>>>>>>>>> But other implementers= do follow the spec hence they have
this open
>>>>>>>>>>>>> redirector=85 and this= is not nice IMHO...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sep 3, 2014, at 7:4= 0 PM, Hans Zandbelt
<hzandbelt@pingidentity.co= m
>>>>>>>>>>>>> <mailto:hzandbelt@pingidentity.com>> w= rote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/3/14, 7:1= 4 PM, Antonio Sanso wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sep 3, 2014= , at 7:10 PM, Hans Zandbelt
>>>>>>>>>>>>>>> <hzandbelt@pingidentity.com
<mailto:hzandbelt@pingiden= tity.com>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is your co= ncern clients that were registered using
dynamic client
>>>>>>>>>>>>>>>> registrati= on?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think your issue= is then with the trust model of
dynamic client
>>>>>>>>>>>>>> registration; that= is left out of scope of the dynreg
spec (and the
>>>>>>>>>>>>>> concept is not eve= n part of the core spec), but unless
you want
>>>>>>>>>>>>>> everything to be o= pen (which typically would not be the
case), then
>>>>>>>>>>>>>> it would involve a= pproval somewhere in the process
before the client
>>>>>>>>>>>>>> is registered. Wit= hout dynamic client registration that
approval is
>>>>>>>>>>>>>> admin based or res= ource owner based, depending on use
case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Otherwise = the positive case is returning a response to
a valid URL
>>>>>>>>>>>>>>>> that belon= gs to a client that was registered
explicitly by the
>>>>>>>>>>>>>>>> resource o= wner
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> well AFAIK the= resource owner doesn=92t register clients=85
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> roles can collapse= in use cases especially when using
dynamic client
>>>>>>>>>>>>>> registration
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and the ne= gative case is returning an error to that
same URL.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the difference= is the consent screen=85 in the positive
case you need
>>>>>>>>>>>>>>> to approve an = app.. for the error case no approval is
needed,,,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I fail to = see the open redirect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> why?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> because the client= and thus the fixed URL are explicitly
approved at
>>>>>>>>>>>>>> some point
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hans.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hans.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/3= /14, 6:56 PM, Antonio Sanso wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sep= 3, 2014, at 6:51 PM, Hans Zandbelt
>>>>>>>>>>>>>>>>> <hzandbelt@pingidentity.com<= br> <mailto:hzandbelt@pingiden= tity.com>
>>>>>>>>>>>>>>>>> <mailto:hzandbelt@pingidentity.c= om>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Le= t me try and approach this from a different angle:
why would you
>>>>>>>>>>>>>>>>>> ca= ll it an open redirect when an invalid scope is
provided and
>>>>>>>>>>>>>>>>>> ca= ll it
>>>>>>>>>>>>>>>>>> co= rrect protocol behavior (hopefully) when a valid
scope is
>>>>>>>>>>>>>>>>>> pr= ovided?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> as spe= cified below in the positive case (namely when
the correct
>>>>>>>>>>>>>>>>> scope<= br> >>>>>>>>>>>>>>>>> is pro= vided) the resource owner MUST approve the app
via the consent
>>>>>>>>>>>>>>>>> screen= (at least once).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Ha= ns.
>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>= ; On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>>>>>>>>>>>>>>>>>>>= ; hi John,
>>>>>>>>>>>>>>>>>>>= ; On Sep 3, 2014, at 6:14 PM, John Bradley
<ve7jtb@ve7jtb.com
>>>>>>>>>>>>>>>>>>>= ; <mailto:ve7jtb@ve7jtb.com>=
>>>>>>>>>>>>>>>>>>>= ; <mailto:ve7jtb@ve7jtb.com>=
>>>>>>>>>>>>>>>>>>>= ; <mailto:ve7jtb@ve7jtb.com>= > wrote:
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ;> In the example the redirect_uri is vlid for the
attacker.
>>>>>>>>>>>>>>>>>>>= ;>
>>>>>>>>>>>>>>>>>>>= ;> The issue is that the AS may be allowing client
registrations with
>>>>>>>>>>>>>>>>>>>= ;> arbitrary redirect_uri.
>>>>>>>>>>>>>>>>>>>= ;>
>>>>>>>>>>>>>>>>>>>= ;> In the spec it is unspecified how a AS validates
that a client
>>>>>>>>>>>>>>>>>>>= ;> controls the redirect_uri it is registering.
>>>>>>>>>>>>>>>>>>>= ;>
>>>>>>>>>>>>>>>>>>>= ;> I think that if anything it may be the
registration step that
>>>>>>>>>>>>>>>>>>>= ;> needs
>>>>>>>>>>>>>>>>>>>= ;> the security consideration.
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ; (this is the first time :p) but I do disagree with
you. It would be
>>>>>>>>>>>>>>>>>>>= ; pretty unpractical to block this at registration
time=85.
>>>>>>>>>>>>>>>>>>>= ; IMHO the best approach is the one taken from
Google, namely
>>>>>>>>>>>>>>>>>>>= ; returning
>>>>>>>>>>>>>>>>>>>= ; 400 with the cause of the error..
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ; *400.* That=92s an error.
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ; *Error: invalid_scope*
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ; Some requested scopes were invalid. {invalid=3D[l]}
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ; said that I hope you all agree this is an issue in
the spec so
>>>>>>>>>>>>>>>>>>>= ; far=85.
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ; regards
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ; antonio
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ;>
>>>>>>>>>>>>>>>>>>>= ;> John B.
>>>>>>>>>>>>>>>>>>>= ;>
>>>>>>>>>>>>>>>>>>>= ;> On Sep 3, 2014, at 12:10 PM, Bill Burke
<bburke@redhat.com
>>>>>>>>>>>>>>>>>>>= ;> <mailto:bburke@redhat.com= >
>>>>>>>>>>>>>>>>>>>= ;> <mailto:bburke@redhat.com= >
>>>>>>>>>>>>>>>>>>>= ;> <mailto:bburke@redhat.com= >> wrote:
>>>>>>>>>>>>>>>>>>>= ;>
>>>>>>>>>>>>>>>>>>>= ;>> I don't understand.  The redirect uri has to be
valid in
>>>>>>>>>>>>>>>>>>>= ;>> order for a
>>>>>>>>>>>>>>>>>>>= ;>> redirect to happen.  The spec explicitly states
this.
>>>>>>>>>>>>>>>>>>>= ;>>
>>>>>>>>>>>>>>>>>>>= ;>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote:
>>>>>>>>>>>>>>>>>>>= ;>>> hi *,
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> IMHO providers that strictly follow rfc6749 are
vulnerable
>>>>>>>>>>>>>>>>>>>= ;>>> to open
>>>>>>>>>>>>>>>>>>>= ;>>> redirect.
>>>>>>>>>>>>>>>>>>>= ;>>> Let me explain, reading [0]
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> If the request fails due to a missing, invalid,
or mismatching
>>>>>>>>>>>>>>>>>>>= ;>>> redirection URI, or if the client identifier is
missing or
>>>>>>>>>>>>>>>>>>>= ;>>> invalid,
>>>>>>>>>>>>>>>>>>>= ;>>> the authorization server SHOULD inform the
resource owner of the
>>>>>>>>>>>>>>>>>>>= ;>>> error and MUST NOT automatically redirect the
user-agent to the
>>>>>>>>>>>>>>>>>>>= ;>>> invalid redirection URI.
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> If the resource owner denies the access request
or if the
>>>>>>>>>>>>>>>>>>>= ;>>> request
>>>>>>>>>>>>>>>>>>>= ;>>> fails for reasons other than a missing or
invalid
>>>>>>>>>>>>>>>>>>>= ;>>> redirection URI,
>>>>>>>>>>>>>>>>>>>= ;>>> the authorization server informs the client by
adding the
>>>>>>>>>>>>>>>>>>>= ;>>> following
>>>>>>>>>>>>>>>>>>>= ;>>> parameters to the query component of the
redirection URI
>>>>>>>>>>>>>>>>>>>= ;>>> using the
>>>>>>>>>>>>>>>>>>>= ;>>> "application/x-www-form-urlencoded" format,
perAppendix B
>>>>>>>>>>>>>>>>>>>= ;>>>
<https://tool= s.ietf.org/html/rfc6749#appendix-B>:
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> Now let=92s assume this.
>>>>>>>>>>>>>>>>>>>= ;>>> I am registering a new client to thevictim.com
>>>>>>>>>>>>>>>>>>>= ;>>> <http://thevictim.com/>
>>>>>>>>>>>>>>>>>>>= ;>>> <http://victim.com/>= <http://victim.com
<http://victim.com/>
>>>>>>>>>>>>>>>>>>>= ;>>> <http://victim.com/>= >
>>>>>>>>>>>>>>>>>>>= ;>>> <http://victim.com <<= a href=3D"http://victim.com/">http://victim.com/>
<http://victim.com/>>
>>>>>>>>>>>>>>>>>>>= ;>>> provider.
>>>>>>>>>>>>>>>>>>>= ;>>> I register redirect uriatt= acker.com
<http://uriattacker.com/>
>>>>>>>>>>>>>>>>>>>= ;>>> <http://attacker.com/= ><http://attacker.com
>>>>>>>>>>>>>>>>>>>= ;>>> <http://attacker.com/= > <http://attacker.com/>><= br> >>>>>>>>>>>>>>>>>>>= ;>>> <http://attacker.com &= lt;http://attacker.com/>
>>>>>>>>>>>>>>>>>>>= ;>>> <http://attacker.com/= >>.
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> According to [0] if I pass e.g. the wrong scope
I am redirected
>>>>>>>>>>>>>>>>>>>= ;>>> back to
>>>>>>>>>>>>>>>>>>>= ;>>> attacker.com <http://attacker.com/>
>>>>>>>>>>>>>>>>>>>= ;>>> <http://attacker.com/= ><http://attacker.com
>>>>>>>>>>>>>>>>>>>= ;>>> <http://attacker.com/= >
>>>>>>>>>>>>>>>>>>>= ;>>> <http://attacker.com/= >> <http://attacker.com
>>>>>>>>>>>>>>>>>>>= ;>>> <http://attacker.com/= > <http://attacker.com/>>.=
>>>>>>>>>>>>>>>>>>>= ;>>> Namely I prepare a url that is in this form:
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>>
http://victim.com/authorize?response_type=3Dcode&a= mp;client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&= ;redirect_uri=3Dhttp://attacker.com


>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> and this is works as an open redirector.
>>>>>>>>>>>>>>>>>>>= ;>>> Of course in the positive case if all the
parameters are
>>>>>>>>>>>>>>>>>>>= ;>>> fine this
>>>>>>>>>>>>>>>>>>>= ;>>> doesn=92t apply since the resource owner MUST
approve the app
>>>>>>>>>>>>>>>>>>>= ;>>> via the
>>>>>>>>>>>>>>>>>>>= ;>>> consent screen (at least once).
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> A solution would be to return error 400 rather
than redirect
>>>>>>>>>>>>>>>>>>>= ;>>> to the
>>>>>>>>>>>>>>>>>>>= ;>>> redirect URI (as some provider e.g. Google do)
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> WDYT?
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> regards
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> antonio
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> [0]
https://tools.ietf.org/html/rfc6749#section-4.1.2.1
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>>
>>>>>>>>>>>>>>>>>>>= ;>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>= ;>>> OAuth mailing list
>>>>>>>>>>>>>>>>>>>= ;>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>>>>>>>>>>>>>>= ;>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>>>>= ;>>
>>>>>>>>>>>>>>>>>>>= ;>> --
>>>>>>>>>>>>>>>>>>>= ;>> Bill Burke
>>>>>>>>>>>>>>>>>>>= ;>> JBoss, a division of Red Hat
>>>>>>>>>>>>>>>>>>>= ;>> http://bill.burkecentral.com
<http://bill.burkecentral.com/>
>>>>>>>>>>>>>>>>>>>= ;>>
>>>>>>>>>>>>>>>>>>>= ;>> _______________________________________________
>>>>>>>>>>>>>>>>>>>= ;>> OAuth mailing list
>>>>>>>>>>>>>>>>>>>= ;>> OAuth@ietf.org <mailto:OAuth@ietf.org>
<mailto:OAuth@ietf.org>
>>>>>>>>>>>>>>>>>>>= ;>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>>>>= ;>
>>>>>>>>>>>>>>>>>>>= ;> _______________________________________________
>>>>>>>>>>>>>>>>>>>= ;> OAuth mailing list
>>>>>>>>>>>>>>>>>>>= ;> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>>>>>>>>>>>>>>= ;> <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org>
>>>>>>>>>>>>>>>>>>>= ;> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ;
>>>>>>>>>>>>>>>>>>>= ; _______________________________________________
>>>>>>>>>>>>>>>>>>>= ; OAuth mailing list
>>>>>>>>>>>>>>>>>>>= ; OAuth@ietf.org <mailto:OAuth@ietf.org>
<mailto:OAuth@ietf.org>
>>>>>>>>>>>>>>>>>>>= ; https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> --=
>>>>>>>>>>>>>>>>>> Ha= ns Zandbelt           &nb= sp;  | Sr. Technical Architect
>>>>>>>>>>>>>>>>>> hz= andbelt@pingidentity.com
<mailto:hzandbelt@pingidentity.com>
>>>>>>>>>>>>>>>>>> &l= t;mailto:hzandbelt@pingidentity.com>| Ping
>>>>>>>>>>>>>>>>>> Id= entity
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Hans Zandb= elt             = ; | Sr. Technical Architect
>>>>>>>>>>>>>>>> hzandbelt@= pingidentity.com
<mailto:hzandbelt@pingidentity.com> |
>>>>>>>>>>>>>>>> Ping Ident= ity
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Hans Zandbelt &nbs= p;            |= Sr. Technical Architect
>>>>>>>>>>>>>> hzandbelt@pingiden= tity.com
<mailto:hzandbelt@pingidentity.com>| Ping
>>>>>>>>>>>>>> Identity
>>>>>>>>>>>>
>>>>>>>>>>>> __________________________= _____________________
>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>> OAuth@ietf.org <mailto:= OAuth@ietf.org>
>>>>>>>>>>>> https://www.ietf.org/mailm= an/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Hans Zandbelt    &n= bsp;         | Sr. Technical A= rchitect
>>>>>>>>>> hzandbelt@pingidentity.com | Ping = Identity
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/= oauth
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bill Burke
>>>>>>>> JBoss, a division of Red Hat
>>>>>>>> http://bill.burkecentral.com
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oaut= h
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>
>>>>>> --
>>>>>> Hans Zandbelt       =        | Sr. Technical Architect
>>>>>> hzandbelt@pingidentity.com | Ping Identity
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>
> _______________________________________________
> 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


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





-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

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

--_000_4DE5DA70605F42CDA6989AF930890393adobecom_-- From nobody Tue Sep 16 02:02:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E5D1A0455 for ; Tue, 16 Sep 2014 02:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 AcraLrY7nVv1 for ; Tue, 16 Sep 2014 02:01:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0694.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::694]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF90B1A02D9 for ; Tue, 16 Sep 2014 02:01:47 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Tue, 16 Sep 2014 09:01:24 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.112]) with mapi id 15.00.1024.012; Tue, 16 Sep 2014 09:01:23 +0000 From: Antonio Sanso To: Phil Hunt Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgBGs+4CAAAiDgIAABXsAgAAL1wCAAAKvgIAABE6AgAABJgCAAAKlAIAAw5sA Date: Tue, 16 Sep 2014 09:01:23 +0000 Message-ID: <3F605B05-F123-43AA-88CF-ACFC596E3D63@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com! > <9CE06872-7B8C-4272-8D48-DCC02881CEA3@oracle.com> <10793893-1B2B-4317-8B09-C055145865F1@adobe.com> In-Reply-To: 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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(52604005)(189002)(199003)(24454002)(479174003)(51444003)(377454003)(83716003)(101416001)(66066001)(92726001)(54356999)(82746002)(87936001)(99396002)(587094003)(15975445006)(77982003)(74662003)(80022003)(81542003)(79102003)(106116001)(81342003)(46102003)(74502003)(90102001)(50986999)(19617315012)(19580405001)(76176999)(16236675004)(2656002)(106356001)(83322001)(99286002)(21056001)(97736003)(105586002)(15395725005)(110136001)(31966008)(33656002)(20776003)(16601075003)(19580395003)(83072002)(85852003)(77096002)(4396001)(76482001)(92566001)(95666004)(64706001)(85306004)(93886004)(36756003)(15202345003)(86362001)(107046002)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_3F605B05F12343AA88CFACFC596E3D63adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/k96TSVHeUdYHsEpFBN0x1oh9lJw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 09:02:00 -0000 --_000_3F605B05F12343AA88CFACFC596E3D63adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable hi Phil. On Sep 15, 2014, at 11:21 PM, Phil Hunt > wrote: So, let=92s say you have a client that has =93obtained=94 a client Id from = a legit registered client. How does the malicious client exploit the previ= ously registered URL if the server only redirects to that URL? These are the steps: - the malicious client can registers a malicious url (attacker.com) - the malicious client builds a malicious request to the AS (victim.com) that looks like http://victim.com/authorize?response_type= =3Dcode&client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&re= direct_uri=3Dhttp://attacker.com as per https://tools.ietf.org/html/rfc6749#section-4.1.2.1 the user is redi= rected to http://attacker.com (since the wrong parameter is the scope ) regards antonio Are you referring to the case Nat Sakimura previously raised where mobile a= pp stores do not enforce custom URL registrations? Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 15, 2014, at 2:11 PM, Antonio Sanso wrote: On Sep 15, 2014, at 11:08 PM, Phil Hunt wrote: I=92m not sure I understand why this is an OAuth protocol problem? If you are starting with a false client with a false registration, everythi= ng down stream is likely invalid. registration is not false. But the client can be a malicious one=85. This seems like a registration curation (whitelisting) problem. there is not way a whitelist can cover all the malicious uris.. regards antonio This is a bit like saying, how can I prove that the application on this jai= l-broken phone is legitimate? Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 15, 2014, at 1:52 PM, Antonio Sanso wrote: The problem is that a malicious client can register a malicious redirect ur= i and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as= previously discussed) regards antonio On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: If a server accepts a URL from a client to be used as a redirect that the s= erver doesn=92t recognize or is not registered, that is an open redirect. The specification does no allow open-redirects, it considers this a mis-con= figuration. Take a look at sections 3.1.2.2 and 10.15 of RFC6749. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 15, 2014, at 1:00 PM, John Bradley wrote: There may be a problem with semantics in this discussion. There is a redirect performed by athe authorization endpoint to a fixed uri= that is pre registered with the authorization server without user promptin= g. That probably doesn't fit the strict definition of a open redirector. It may however create similar security issues in situations with relatively= open registration of clients. The largest issues are that the browser might leak information across the r= edirect in the fragment or referrer. That has been used in attacks against= Facebook in the past. This is no where near the end of the world, however we need to look at the= security considerations and see if we can provide better advice to impleme= ntors. In some cases returning a error to the browser may be best. I don't think we need to go so far as not returning any error to the client= under any circumstance. John B. Sent from my iPhone On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: Simply not true. Phil @independentid www.independentid.com phil.hunt@oracle.com On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote: hi *, my understanding is that there is a rough consensus that if an OAuth Provid= er follows rfc6749 verbatim will end up having an open redirector. My next question would be now, is there anything we can do to raise some aw= areness about this issue? regards antonio On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrot= e: I am convinced about the issue in the use case Antonio provided but I hope = not to close the door on returning errors to known and trusted clients. Not= sure anymore if that's possible though because the distinction can't be "r= egistered"... Hans. On 9/4/14, 3:01 PM, Antonio Sanso wrote: hi Bill On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: FWIW, Antonio convinced me and I'm going to change this in our IDM project.= Thanks Antonio. What convinced me was that the user is probably expectin= g a login screen. Since there is this expectation, it might make it a litt= le easier for the attacker to convince the user that a spoofed login screen= is real. I know this issue can only happen with unrestricted registration= , but, IMO, this proposed change doesn't really have much of an effect on u= sability and is even backward compatible with the current RFC. Wouldn't it better though to never do a redirect on an invalid request and = just display an error page? thanks for sharing your thoughts :). Display an error 400 is what Google do= es :) regards antonio On 9/4/2014 3:50 AM, Antonio Sanso wrote: Hi Hans, I really fail to see how this can be addressed at registration time for cas= es where registration is unrestricted (namely all the big Providers) regards antonio On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrot= e: Classifying like this must also mean that consent should not be stored unti= l the client is considered (admin) trusted, and admin policy would interfer= e with user policy. IMHO the security consideration would apply only to dynamically registered = clients where registration is unrestricted; any other form would involve so= me form of admin/user approval at registration time, overcoming the concern= at authorization time: there's no auto-redirect flow possible for unknown = clients. Hans. On 9/4/14, 9:04 AM, Richer, Justin P. wrote: I think this advice isn't a bad idea, though it's of course up to the AS what an "untrusted" client really is. In practice, this is something that was registered by a non-sysadmin type person, either a dynamically registered client or something available through self-service registration of some type. It's also reasonable that a client, even dynamically registered, would be considered "trusted" if enough time has passed and enough users have used it without things blowing up. -- Justin On Sep 4, 2014, at 1:26 AM, Antonio Sanso > wrote: hi again *, after thinking a bit further IMHO an alternative for the untrusted clients can also be to always present the consent screen (at least once) before any redirect. Namely all providers I have seen show the consent screen if all the request parameters are correct and if the user accepts the redirect happens. If one of the parameter (with the exclusion of the client id and redirect uri that are handled differently as for spec) is wrong though the redirect happens without the consent screen being shown.. WDYT? regards antonio On Sep 3, 2014, at 7:54 PM, Antonio Sanso > wrote: Well, I do not know if this is only dynamic registration... let=92s talk about real use cases, namely e.g. Google , Facebook , etc.. is that dynamic client registration? I do not know=85 :) Said that what the other guys think? :) Would this deserve some =93spec adjustment=94 ? I mean there is a reason if Google is by choice =93violating=94 the spec right? (I assume to avoid open redirect=85) But other implementers do follow the spec hence they have this open redirector=85 and this is not nice IMHO... On Sep 3, 2014, at 7:40 PM, Hans Zandbelt > wrote: On 9/3/14, 7:14 PM, Antonio Sanso wrote: On Sep 3, 2014, at 7:10 PM, Hans Zandbelt > wrote: Is your concern clients that were registered using dynamic client registration? yes I think your issue is then with the trust model of dynamic client registration; that is left out of scope of the dynreg spec (and the concept is not even part of the core spec), but unless you want everything to be open (which typically would not be the case), then it would involve approval somewhere in the process before the client is registered. Without dynamic client registration that approval is admin based or resource owner based, depending on use case. Otherwise the positive case is returning a response to a valid URL that belongs to a client that was registered explicitly by the resource owner well AFAIK the resource owner doesn=92t register clients=85 roles can collapse in use cases especially when using dynamic client registration and the negative case is returning an error to that same URL. the difference is the consent screen=85 in the positive case you need to approve an app.. for the error case no approval is needed,,, I fail to see the open redirect. why? because the client and thus the fixed URL are explicitly approved at some point Hans. Hans. On 9/3/14, 6:56 PM, Antonio Sanso wrote: On Sep 3, 2014, at 6:51 PM, Hans Zandbelt > wrote: Let me try and approach this from a different angle: why would you call it an open redirect when an invalid scope is provided and call it correct protocol behavior (hopefully) when a valid scope is provided? as specified below in the positive case (namely when the correct scope is provided) the resource owner MUST approve the app via the consent screen (at least once). Hans. On 9/3/14, 6:46 PM, Antonio Sanso wrote: hi John, On Sep 3, 2014, at 6:14 PM, John Bradley > wrote: In the example the redirect_uri is vlid for the attacker. The issue is that the AS may be allowing client registrations with arbitrary redirect_uri. In the spec it is unspecified how a AS validates that a client controls the redirect_uri it is registering. I think that if anything it may be the registration step that needs the security consideration. (this is the first time :p) but I do disagree with you. It would be pretty unpractical to block this at registration time=85. IMHO the best approach is the one taken from Google, namely returning 400 with the cause of the error.. *400.* That=92s an error. *Error: invalid_scope* Some requested scopes were invalid. {invalid=3D[l]} said that I hope you all agree this is an issue in the spec so far=85. regards antonio John B. On Sep 3, 2014, at 12:10 PM, Bill Burke > wrote: I don't understand. The redirect uri has to be valid in order for a redirect to happen. The spec explicitly states this. On 9/3/2014 11:43 AM, Antonio Sanso wrote: hi *, IMHO providers that strictly follow rfc6749 are vulnerable to open redirect. Let me explain, reading [0] If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, perAppendix B : Now let=92s assume this. I am registering a new client to thevictim.com > > provider. I register redirect uriattacker.com > >. According to [0] if I pass e.g. the wrong scope I am redirected back to attacker.com > >. Namely I prepare a url that is in this form: http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX1298KP= j2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://attacker.com and this is works as an open redirector. Of course in the positive case if all the parameters are fine this doesn=92t apply since the resource owner MUST approve the app via the consent screen (at least once). A solution would be to return error 400 rather than redirect to the redirect URI (as some provider e.g. Google do) WDYT? regards antonio [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ 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 -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity _______________________________________________ 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 --_000_3F605B05F12343AA88CFACFC596E3D63adobecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable hi Phil.
On Sep 15, 2014, at 11:21 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

So, let=92s say you have a client that has =93obt= ained=94 a client Id from a legit registered client.  How does the mal= icious client exploit the previously registered URL if the server only redi= rects to that URL?

These are the steps:

- the malicious client can registers a malicious url (attacker.com)

as per https://tools.ietf.org/html/rfc6749#section-4.1.2.1 the user= is redirected to http://attacker.com (since the wrong pa= rameter is the scope )

regards

antonio


Are you referring to the case Nat Sakimura previously raised where mobile a= pp stores do not enforce custom URL registrations?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



On Sep 15, 2014, at 2:11 PM, Antonio Sanso <asanso@adobe.com> wrote:<= br>

On Sep 15, 2014, at 11:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=

I=92m not sure I understand why this is an OAuth = protocol problem?

If you are starting with a false client with a false registration, everythi= ng down stream is likely invalid.

registration is not false. But the client can be a malicious one=85.



This seems like a registration curation (whitelisting) problem.

there is not way a whitelist can cover all the malicious uris..

regards

antonio


This is a bit like saying, how can I prove that the application on this jai= l-broken phone is legitimate?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



On Sep 15, 2014, at 1:52 PM, Antonio Sanso <asanso@adobe.com> wrote:<= br>
The problem is that a malicious client can regist= er a malicious redirect uri and https://tools.ietf.org/html/rfc6749#section= -4.1.2.1 does the rest (as previously discussed)

regards

antonio

On Sep 15, 2014, at 10:43 PM, Phil Hunt <phil.hunt@oracle.com> wrote:=

If a server accepts a URL from a client to be use= d as a redirect that the server doesn=92t recognize or is not registered, t= hat is an open redirect.

The specification does no allow open-redirects, it considers this a mis-con= figuration.

Take a look at sections 3.1.2.2 and 10.15 of RFC6749.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



On Sep 15, 2014, at 1:00 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:<= br>
There may be a problem with semantics in this dis= cussion.

There is a redirect performed by athe authorization endpoint to a fixed uri= that is pre registered with the authorization server without user promptin= g.

That probably doesn't fit the strict definition of a open redirector.

It may however create similar security issues in situations with relatively= open registration of clients.

The largest issues are that the browser might leak information across the r= edirect in the fragment or referrer.  That has been used in attacks ag= ainst Facebook in the past.

This is no where near the end of the world,  however we need to look a= t the security considerations and see if we can provide better advice to im= plementors.  In some cases returning a error to the browser may be bes= t.  

I don't think we need to go so far as not returning any error to the client= under any circumstance.

John B.

Sent from my iPhone

On Sep 15, 2014, at 4:41 PM, Phil Hunt <phil.h= unt@oracle.com> wrote:

Simply not true.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



On Sep 15, 2014, at 12:10 PM, Antonio Sanso <a= sanso@adobe.com> wrote:

hi *,

my understanding is that there is a rough consensus that if an OAuth Provid= er follows rfc6749 verbatim will end up having an open redirector.
My next question would be now, is there anything we can do to raise some aw= areness about this issue?

regards

antonio

On Sep 4, 2014, at 3:15 PM, Hans Zandbelt <hza= ndbelt@pingidentity.com> wrote:

I am convinced about the issue in the use case Antonio provided but I hope = not to close the door on returning errors to known and trusted clients. Not= sure anymore if that's possible though because the distinction can't be &q= uot;registered"...

Hans.

On 9/4/14, 3:01 PM, Antonio Sanso wrote:
hi Bill
On Sep 4, 2014, at 2:52 PM, Bill Burke <bburke= @redhat.com> wrote:

FWIW, Antonio convinced me and I'm going to change this in our IDM project.=  Thanks Antonio.  What convinced me was that the user is probabl= y expecting a login screen.  Since there is this expectation, it might= make it a little easier for the attacker to convince the user that a spoofed login screen is real.  I know this issue can = only happen with unrestricted registration, but, IMO, this proposed change = doesn't really have much of an effect on usability and is even backward com= patible with the current RFC.

Wouldn't it better though to never do a redirect on an invalid request and = just display an error page?

thanks for sharing your thoughts :). Display an error 400 is what Google do= es :)

regards

antonio


On 9/4/2014 3:50 AM, Antonio Sanso wrote:
Hi Hans,

I really fail to see how this can be addressed at registration time for cas= es where registration is unrestricted (namely all the big Providers)

regards

antonio

On Sep 4, 2014, at 9:47 AM, Hans Zandbelt <hza= ndbelt@pingidentity.com> wrote:

Classifying like this must also mean that consent should not be stored unti= l the client is considered (admin) trusted, and admin policy would interfer= e with user policy.

IMHO the security consideration would apply only to dynamically registered = clients where registration is unrestricted; any other form would involve so= me form of admin/user approval at registration time, overcoming the concern= at authorization time: there's no auto-redirect flow possible for unknown clients.

Hans.

On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
I think this advice isn't a bad idea, though it's of course up to the AS what an "untrusted" client really is. In practice, this is someth= ing
that was registered by a non-sysadmin type person, either a dynamically
registered client or something available through self-service
registration of some type. It's also reasonable that a client, even
dynamically registered, would be considered "trusted" if enough t= ime has
passed and enough users have used it without things blowing up.

-- Justin

On Sep 4, 2014, at 1:26 AM, Antonio Sanso <asanso@adobe.com
<mailto:asanso@adobe.com>> wrote:

hi again *,

after thinking a bit further IMHO an alternative for the untrusted
clients can also be to always present the consent screen (at least
once) before any redirect.
Namely all providers I have seen show the consent screen if all the
request parameters are correct and if the user accepts the redirect
happens.
If one of the parameter  (with the exclusion of the client id and
redirect uri that are handled differently as for spec) is wrong though
the redirect happens without the consent screen being shown..

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso <asanso@adobe.com
<mailto:asanso@adobe.com>> wrote:

Well,
I do not know if this is only dynamic registration...
let=92s talk about real use cases, namely e.g. Google , Facebook ,
etc.. is that dynamic client registration? I do not know=85 :)

Said that what the other guys think?  :)
Would this deserve some =93spec adjustment=94 ? I mean there is a reason if Google is by choice =93violating=94 the spec right? (I assume to avoid open redirect=85)
But other implementers do follow the spec hence they have this open
redirector=85 and this is not nice IMHO...


On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com>> wrote:

On 9/3/14, 7:14 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
<hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com>>= ; wrote:

Is your concern clients that were registered usin= g dynamic client
registration?

yes

I think your issue is then with the trust model of dynamic client
registration; that is left out of scope of the dynreg spec (and the
concept is not even part of the core spec), but unless you want
everything to be open (which typically would not be the case), then
it would involve approval somewhere in the process before the client
is registered. Without dynamic client registration that approval is
admin based or resource owner based, depending on use case.

Otherwise the positive case is returning a respon= se to a valid URL
that belongs to a client that was registered explicitly by the
resource owner

well AFAIK the resource owner doesn=92t register clients=85

roles can collapse in use cases especially when using dynamic client
registration

and the negative case is returning an error to th= at same URL.

the difference is the consent screen=85 in the positive case you need
to approve an app.. for the error case no approval is needed,,,


I fail to see the open redirect.

why?

because the client and thus the fixed URL are explicitly approved at
some point

Hans.



Hans.

On 9/3/14, 6:56 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 6:51 PM, Hans Zandbelt
<hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com> <mailto:hzandbelt@pingidentity.com>> wrote:

Let me try and approach this from a different ang= le: why would you
call it an open redirect when an invalid scope is provided and
call it
correct protocol behavior (hopefully) when a valid scope is
provided?

as specified below in the positive case (namely when the correct
scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).



Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:
hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com
<mailto:ve7jtb@ve7jtb.com>
<mailto:ve7jtb@ve7jtb.com>
<mailto:ve7jtb@ve7jtb.com>> wrote:

In the example the redirect_uri is vlid for the a= ttacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that
needs
the security consideration.

(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time=85.
IMHO the best approach is the one taken from Google, namely
returning
400 with the cause of the error..

*400.* That=92s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=3D[l]}

said that I hope you all agree this is an issue in the spec so
far=85.

regards

antonio


John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com>
<mailto:bburke@redhat.com>
<mailto:bburke@redhat.com>> wrote:

I don't understand.  The redirect uri has to= be valid in
order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:
hi *,

IMHO providers that strictly follow rfc6749 are vulnerable
to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or
invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the
request
fails for reasons other than a missing or invalid
redirection URI,
the authorization server informs the client by adding the
following
parameters to the query component of the redirection URI
using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let=92s assume this.
I am registering a new client to thevictim.com
<http://thevictim.com/>
<http://victim.com/><http://victim.com <http://victim.com/><= br> <http://victim.com/>>
<http://victim.com <http://victim.com/> <http://victim.com/>= >
provider.
I register redirect uriattacker.com <http://uriattacker.com/>
<http://attacker.com/><http://attacker.com
<http://attacker.com/> <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>
<http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected
back to
attacker.com <http://attacker.com/>
<http://attacker.com/><http://attacker.com
<http://attacker.com/>
<http://attacker.com/>> <http://attacker.com
<http://attacker.com/> <http://attacker.com/>>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=3Dcode&client_id=3Dbc88FitX12= 98KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_uri=3Dhttp://at= tacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are
fine this
doesn=92t apply since the resource owner MUST approve the app
via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect
to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


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

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com <http://bill.burkecentral.com/>

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

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



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

--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com>
<mailto:hzandbelt@pingidentity.com>| Ping
Identity

--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com> |
Ping Identity

--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com>| Ping<= br> Identity

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

--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity

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

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

_______________________________________________
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

--
Hans Zandbelt           &= nbsp;  | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity

_______________________________________________
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






--_000_3F605B05F12343AA88CFACFC596E3D63adobecom_-- From nobody Tue Sep 16 02:08:51 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC6F1A015D for ; Tue, 16 Sep 2014 02:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 jzDNyaRqwEB9 for ; Tue, 16 Sep 2014 02:08:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0071.outbound.protection.outlook.com [65.55.169.71]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05871A0151 for ; Tue, 16 Sep 2014 02:08:43 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Tue, 16 Sep 2014 09:08:42 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.112]) with mapi id 15.00.1024.012; Tue, 16 Sep 2014 09:08:40 +0000 From: Antonio Sanso To: John Bradley Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgBGs+4CAAAiDgIAABXsAgAAL1wCAAAKvgIAABlQAgAALdQCAALv0gA== Date: Tue, 16 Sep 2014 09:08:40 +0000 Message-ID: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> <29F9628D-EBD4-4C32-BD8B-4FC520ADAED0@ve7jtb.com> In-Reply-To: <29F9628D-EBD4-4C32-BD8B-4FC520ADAED0@ve7jtb.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: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51444003)(377454003)(199003)(52604005)(189002)(51704005)(479174003)(107046002)(83322001)(54356999)(99396002)(82746002)(105586002)(83072002)(16601075003)(15974865002)(90102001)(587094003)(83716003)(19580395003)(101416001)(50986999)(106116001)(95666004)(106356001)(15395725005)(76482001)(76176999)(15975445006)(19580405001)(15202345003)(77096002)(99286002)(4396001)(33656002)(97736003)(87936001)(21056001)(86362001)(31966008)(36756003)(92566001)(85852003)(64706001)(2656002)(93886004)(77982003)(110136001)(92726001)(66066001)(74502003)(74662003)(81542003)(85306004)(46102003)(79102003)(20776003)(80022003)(81342003)(104396001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <18E48CD01E00E0488470F5C1FBB5DA68@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kttTgjZhhc4OZsyTAgW8CJBFWxc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 09:08:49 -0000 Hi John, agree that there are at two different things (as you pointed out below) whe= re we could spend some word and provide some advice. To summarize: - one is the 'open redirect=92 issue (net of semantic :), pointed by me, w= here nothing is leaked=20 - one is the leakage, pointed by John Those two scenarios are different and might deserve to be discussed indepen= dently=85 :) On Sep 15, 2014, at 11:56 PM, John Bradley wrote: > Something might get leaked by the browser, the fragment may be leaked by = the browser if the redirect URI doesn't contain a fragment in some browsers= . >=20 > A simple security consideration might be to add a fragment to the redirec= t_uri in the error case. >=20 > The other way that information may leak is via the referrer. If there i= s only one redirect by the AS the URI that was sent to the AS including all= the parameters would still be available to the target. > A simple fix is to redirect to a intermediate page before redirecting to = the registered client, this clears the referrer. >=20 > It is true that nothing is leaked in the redirect_uri itself but there ar= e side channels in the browser that need to be considered. >=20 > The fixes are quite simple implementation issues and don't break anything= . >=20 > Yes if the client is trusted then this is probably unnecessary but wouldn= 't hurt anything. >=20 > John B. >=20 > PS for OAuth this would really only be exploitable if exact redirect_uri = matching is not happening. =20 >=20 > As I am a inherently bad person, I could hypothetically use this to attac= k a AS that is doing domain level pattern matching of redirect URI and has = a public client in the same domain as the AS. >=20 > I should also note that domains using pattern matching are also vulnerabl= e if they allow other sorts of user hosted content like blog posts that pul= l in images and leak the referrer. if somebody is curios about some real world attack this is one I performed = to Facebook that does exactly what John describes here http://intothesymmet= ry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html regards antonio >=20 > So we do probably need to provide some advice. >=20 > John B. >=20 > On Sep 15, 2014, at 6:15 PM, Richer, Justin P. wrote: >=20 >> As we discussed before: This isn't really an open redirection in the cla= ssical sense since nothing gets leaked and the URI is tied back to a known = (albeit malicious) client registration. And I thought the clear solution wa= s to have an AS not automatically redirect to an untrusted client in error = conditions, where "untrusted" is defined by the AS with guidance. If anythi= ng this is a security considerations addendum. >>=20 >> -- Justin >>=20 >> On Sep 15, 2014, at 4:52 PM, Antonio Sanso wrote: >>=20 >>> The problem is that a malicious client can register a malicious redirec= t uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest= (as previously discussed) >>>=20 >>> regards >>>=20 >>> antonio >>>=20 >>> On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: >>>=20 >>>> If a server accepts a URL from a client to be used as a redirect that = the server doesn=92t recognize or is not registered, that is an open redire= ct. >>>>=20 >>>> The specification does no allow open-redirects, it considers this a mi= s-configuration. >>>>=20 >>>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >>>>=20 >>>>> There may be a problem with semantics in this discussion.=20 >>>>>=20 >>>>> There is a redirect performed by athe authorization endpoint to a fix= ed uri that is pre registered with the authorization server without user pr= ompting.=20 >>>>>=20 >>>>> That probably doesn't fit the strict definition of a open redirector.= =20 >>>>>=20 >>>>> It may however create similar security issues in situations with rela= tively open registration of clients.=20 >>>>>=20 >>>>> The largest issues are that the browser might leak information across= the redirect in the fragment or referrer. That has been used in attacks a= gainst Facebook in the past.=20 >>>>>=20 >>>>> This is no where near the end of the world, however we need to look = at the security considerations and see if we can provide better advice to i= mplementors. In some cases returning a error to the browser may be best. = =20 >>>>>=20 >>>>> I don't think we need to go so far as not returning any error to the = client under any circumstance.=20 >>>>>=20 >>>>> John B.=20 >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: >>>>>>=20 >>>>>> Simply not true. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrot= e: >>>>>>>=20 >>>>>>> hi *, >>>>>>>=20 >>>>>>> my understanding is that there is a rough consensus that if an OAut= h Provider follows rfc6749 verbatim will end up having an open redirector. >>>>>>> My next question would be now, is there anything we can do to raise= some awareness about this issue? >>>>>>>=20 >>>>>>> regards >>>>>>>=20 >>>>>>> antonio >>>>>>>=20 >>>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrote: >>>>>>>>=20 >>>>>>>> I am convinced about the issue in the use case Antonio provided bu= t I hope not to close the door on returning errors to known and trusted cli= ents. Not sure anymore if that's possible though because the distinction ca= n't be "registered"... >>>>>>>>=20 >>>>>>>> Hans. >>>>>>>>=20 >>>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>>>> hi Bill >>>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote= : >>>>>>>>>>=20 >>>>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our I= DM project. Thanks Antonio. What convinced me was that the user is probab= ly expecting a login screen. Since there is this expectation, it might mak= e it a little easier for the attacker to convince the user that a spoofed l= ogin screen is real. I know this issue can only happen with unrestricted r= egistration, but, IMO, this proposed change doesn't really have much of an = effect on usability and is even backward compatible with the current RFC. >>>>>>>>>>=20 >>>>>>>>>> Wouldn't it better though to never do a redirect on an invalid r= equest and just display an error page? >>>>>>>>>=20 >>>>>>>>> thanks for sharing your thoughts :). Display an error 400 is what= Google does :) >>>>>>>>>=20 >>>>>>>>> regards >>>>>>>>>=20 >>>>>>>>> antonio >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>>>> Hi Hans, >>>>>>>>>>>=20 >>>>>>>>>>> I really fail to see how this can be addressed at registration = time for cases where registration is unrestricted (namely all the big Provi= ders) >>>>>>>>>>>=20 >>>>>>>>>>> regards >>>>>>>>>>>=20 >>>>>>>>>>> antonio >>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Classifying like this must also mean that consent should not b= e stored until the client is considered (admin) trusted, and admin policy w= ould interfere with user policy. >>>>>>>>>>>>=20 >>>>>>>>>>>> IMHO the security consideration would apply only to dynamicall= y registered clients where registration is unrestricted; any other form wou= ld involve some form of admin/user approval at registration time, overcomin= g the concern at authorization time: there's no auto-redirect flow possible= for unknown clients. >>>>>>>>>>>>=20 >>>>>>>>>>>> Hans. >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>>>> I think this advice isn't a bad idea, though it's of course u= p to the AS >>>>>>>>>>>>> what an "untrusted" client really is. In practice, this is so= mething >>>>>>>>>>>>> that was registered by a non-sysadmin type person, either a d= ynamically >>>>>>>>>>>>> registered client or something available through self-service >>>>>>>>>>>>> registration of some type. It's also reasonable that a client= , even >>>>>>>>>>>>> dynamically registered, would be considered "trusted" if enou= gh time has >>>>>>>>>>>>> passed and enough users have used it without things blowing u= p. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- Justin >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> hi again *, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> after thinking a bit further IMHO an alternative for the unt= rusted >>>>>>>>>>>>>> clients can also be to always present the consent screen (at= least >>>>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>>>> Namely all providers I have seen show the consent screen if = all the >>>>>>>>>>>>>> request parameters are correct and if the user accepts the r= edirect >>>>>>>>>>>>>> happens. >>>>>>>>>>>>>> If one of the parameter (with the exclusion of the client i= d and >>>>>>>>>>>>>> redirect uri that are handled differently as for spec) is wr= ong though >>>>>>>>>>>>>> the redirect happens without the consent screen being shown.= . >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> regards >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Well, >>>>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , Fac= ebook , >>>>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know=85= :) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean ther= e is a reason >>>>>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I a= ssume to avoid >>>>>>>>>>>>>>> open redirect=85) >>>>>>>>>>>>>>> But other implementers do follow the spec hence they have t= his open >>>>>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Is your concern clients that were registered using dynam= ic client >>>>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I think your issue is then with the trust model of dynamic= client >>>>>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec= (and the >>>>>>>>>>>>>>>> concept is not even part of the core spec), but unless you= want >>>>>>>>>>>>>>>> everything to be open (which typically would not be the ca= se), then >>>>>>>>>>>>>>>> it would involve approval somewhere in the process before = the client >>>>>>>>>>>>>>>> is registered. Without dynamic client registration that ap= proval is >>>>>>>>>>>>>>>> admin based or resource owner based, depending on use case= . >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to a= valid URL >>>>>>>>>>>>>>>>>> that belongs to a client that was registered explicitly = by the >>>>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clients= =85 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> roles can collapse in use cases especially when using dyna= mic client >>>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> and the negative case is returning an error to that same= URL. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> the difference is the consent screen=85 in the positive c= ase you need >>>>>>>>>>>>>>>>> to approve an app.. for the error case no approval is nee= ded,,, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly a= pproved at >>>>>>>>>>>>>>>> some point >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: w= hy would you >>>>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is prov= ided and >>>>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid sco= pe is >>>>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> as specified below in the positive case (namely when th= e correct >>>>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app vi= a the consent >>>>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the atta= cker. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client regi= strations with >>>>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates tha= t a client >>>>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration = step that >>>>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with yo= u. It would be >>>>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time= =85. >>>>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, = namely >>>>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in th= e spec so >>>>>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be val= id in >>>>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states thi= s. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vu= lnerable >>>>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or= mismatching >>>>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is mi= ssing or >>>>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resourc= e owner of the >>>>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user= -agent to the >>>>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or= if the >>>>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by add= ing the >>>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirecti= on URI >>>>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perApp= endix B >>>>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I = am redirected >>>>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode&c= lient_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_ur= i=3Dhttp://attacker.com >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the paramete= rs are >>>>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST appr= ove the app >>>>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather tha= n redirect >>>>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.= 1.2.1 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Bill Burke >>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>=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 >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>=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 >>> _______________________________________________ >>> 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 From nobody Tue Sep 16 02:12:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE841A027C for ; Tue, 16 Sep 2014 02:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 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, FRT_ADOBE2=2.455, SPF_PASS=-0.001] autolearn=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 WBDwII1NJo8y for ; Tue, 16 Sep 2014 02:12:24 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C7E1A0444 for ; Tue, 16 Sep 2014 02:12:14 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id t60so5341548wes.25 for ; Tue, 16 Sep 2014 02:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QtTbGC9xqDTQBNuz944l07sxdtCF8w8feRyuo+HvRIg=; b=AdKgwT4QKx3HGhfMfKsQyXwNDXj7bRxdYO71cQeNXrnKtud/sjcA0n/UuAuunwApP8 nRiQDUA+0mV7d0xALWp8SyQxVbc964YlpDNBiZOUjVHDv5+1knrSSswNLJMSMjFaFqTh uKNIrg0Le3ksra2wmxkxtrsP7y/q6Xn/yXzAVLJ6sqC2pZh6jht+ZtzXdAtwj8pjzbQP TR430XZosm2srPIfGExdElLX8Dz7CYiHvDVAjLjYOnfhlP/c4agJADbsAxz58H/VLQTH b7YmwkSmXVZ1cWvu5R3DNG2kEeb32wz7Mcg8wGCk43LevCdiZ8luJBC0B9X8kNpxHuoh UY9w== X-Received: by 10.194.203.105 with SMTP id kp9mr41890393wjc.41.1410858733350; Tue, 16 Sep 2014 02:12:13 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id hf9sm1154161wib.11.2014.09.16.02.12.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Sep 2014 02:12:12 -0700 (PDT) Message-ID: <5417FEEB.6070706@gmail.com> Date: Tue, 16 Sep 2014 10:12:11 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Antonio Sanso References: <5nofjvf5jjbcqjdv9bmdgdg0.1410846275737@email.android.com> <5417EC3D.8060601@pingidentity.com> <5417F820.8000804@gmail.com> <5417F886.4030801@gmail.com> <4DE5DA70-605F-42CD-A698-9AF930890393@adobe.com> In-Reply-To: <4DE5DA70-605F-42CD-A698-9AF930890393@adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OVgqzW7J8wK-i-Oc5ilhUHwZAbo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 09:12:28 -0000 Hi Antonio On 16/09/14 09:52, Antonio Sanso wrote: > hi Sergey > > On Sep 16, 2014, at 10:44 AM, Sergey Beryozkin > wrote: > >> Hi >> >> I wonder, when we have a situation where any client, the malicious >> clients, or good clients, all of them can easily register and provide >> bad redirect URIs, intentionally or unintentionally, then does it imply >> there's serious a weakness present somewhere else, in the >> registration process for example ? Should the client registrations be >> validated ? > > as previously discussed is pretty fought to filter bad redirect uri > specially for big OPs like Facebook/Google et al where all you need to > have in order to create a new OAuth client is an email address (the > registration process is self-service). > Right, looks like it is weak all right if all what is needed for a 3rd party registration to succeed is to register an email address :-) That said, the end user should be cautious, right ? I recall playing with the Salesforce account and it is up to the user to either add or not add a given client registration to the account. > Justin proposed some mitigation though… (namely a client can gain > ‘reputation’ with time) Sure, I guess it is a good advice on its own... Cheers, Sergey > > regards > > antonio > >> >> Sergey >>> >>> On 16/09/14 08:52, Hans Zandbelt wrote: >>>> +1, Antonio and John convinced me that this is not limited to a >>>> registration curation problem although that is where the problems starts >>>> as Phil points out (and as much as I'd like it to stay there). >>>> >>>> There are and will be consumer OPs (like Google) that have no means to >>>> do whitelisting yet have perfectly valid OAuth 2.0 use cases. A security >>>> consideration for OPs that have no policy in place to allow only trusted >>>> clients to register would be a good thing. >>>> >>>> The advice for those OPs would be to not send errors back to untrusted >>>> clients or do it only after explicit user interaction. >>>> >>>> Hans. >>>> >>>> On 9/16/14, 7:44 AM, Torsten Lodderstedt wrote: >>>>> I think a security considerations addendum makes sense. >>>>> >>>>> regards, >>>>> Torsten. >>>>> >>>>> >>>>> -------- Ursprüngliche Nachricht -------- >>>>> Von: "Richer, Justin P." >>>>> Datum:15.09.2014 23:15 (GMT+01:00) >>>>> An: Antonio Sanso >>>>> Cc: oauth@ietf.org >>>>> Betreff: Re: [OAUTH-WG] open redirect in rfc6749 >>>>> >>>>> As we discussed before: This isn't really an open redirection in the >>>>> classical sense since nothing gets leaked and the URI is tied back to a >>>>> known (albeit malicious) client registration. And I thought the clear >>>>> solution was to have an AS not automatically redirect to an untrusted >>>>> client in error conditions, where "untrusted" is defined by the AS with >>>>> guidance. If anything this is a security considerations addendum. >>>>> >>>>> -- Justin >>>>> >>>>> On Sep 15, 2014, at 4:52 PM, Antonio Sanso >>>> > wrote: >>>>> >>>>> > The problem is that a malicious client can register a malicious >>>>> redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>> does the rest (as previously discussed) >>>>> > >>>>> > regards >>>>> > >>>>> > antonio >>>>> > >>>>> > On Sep 15, 2014, at 10:43 PM, Phil Hunt >>>> > wrote: >>>>> > >>>>> >> If a server accepts a URL from a client to be used as a redirect >>>>> that the server doesn’t recognize or is not registered, that is an open >>>>> redirect. >>>>> >> >>>>> >> The specification does no allow open-redirects, it considers this a >>>>> mis-configuration. >>>>> >> >>>>> >> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>>>> >> >>>>> >> Phil >>>>> >> >>>>> >> @independentid >>>>> >> www.independentid.com >>>>> >> phil.hunt@oracle.com >>>>> >> >>>>> >> >>>>> >> >>>>> >> On Sep 15, 2014, at 1:00 PM, John Bradley >>>> > wrote: >>>>> >> >>>>> >>> There may be a problem with semantics in this discussion. >>>>> >>> >>>>> >>> There is a redirect performed by athe authorization endpoint to a >>>>> fixed uri that is pre registered with the authorization server without >>>>> user prompting. >>>>> >>> >>>>> >>> That probably doesn't fit the strict definition of a open >>>>> redirector. >>>>> >>> >>>>> >>> It may however create similar security issues in situations with >>>>> relatively open registration of clients. >>>>> >>> >>>>> >>> The largest issues are that the browser might leak information >>>>> across the redirect in the fragment or referrer. That has been used in >>>>> attacks against Facebook in the past. >>>>> >>> >>>>> >>> This is no where near the end of the world, however we need to >>>>> look at the security considerations and see if we can provide better >>>>> advice to implementors. In some cases returning a error to the browser >>>>> may be best. >>>>> >>> >>>>> >>> I don't think we need to go so far as not returning any error to >>>>> the client under any circumstance. >>>>> >>> >>>>> >>> John B. >>>>> >>> >>>>> >>> Sent from my iPhone >>>>> >>> >>>>> >>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt >>>> > >>>>> wrote: >>>>> >>>> >>>>> >>>> Simply not true. >>>>> >>>> >>>>> >>>> Phil >>>>> >>>> >>>>> >>>> @independentid >>>>> >>>> www.independentid.com >>>>> >>>> phil.hunt@oracle.com >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso >>>> > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> hi *, >>>>> >>>>> >>>>> >>>>> my understanding is that there is a rough consensus that if an >>>>> OAuth Provider follows rfc6749 verbatim will end up having an open >>>>> redirector. >>>>> >>>>> My next question would be now, is there anything we can do to >>>>> raise some awareness about this issue? >>>>> >>>>> >>>>> >>>>> regards >>>>> >>>>> >>>>> >>>>> antonio >>>>> >>>>> >>>>> >>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt >>>>> > wrote: >>>>> >>>>>> >>>>> >>>>>> I am convinced about the issue in the use case Antonio provided >>>>> but I hope not to close the door on returning errors to known and >>>>> trusted clients. Not sure anymore if that's possible though because the >>>>> distinction can't be "registered"... >>>>> >>>>>> >>>>> >>>>>> Hans. >>>>> >>>>>> >>>>> >>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>> >>>>>>> hi Bill >>>>> >>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke >>>> > >>>>> wrote: >>>>> >>>>>>>> >>>>> >>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our >>>>> IDM project. Thanks Antonio. What convinced me was that the user is >>>>> probably expecting a login screen. Since there is this expectation, it >>>>> might make it a little easier for the attacker to convince the user >>>>> that >>>>> a spoofed login screen is real. I know this issue can only happen with >>>>> unrestricted registration, but, IMO, this proposed change doesn't >>>>> really >>>>> have much of an effect on usability and is even backward compatible >>>>> with >>>>> the current RFC. >>>>> >>>>>>>> >>>>> >>>>>>>> Wouldn't it better though to never do a redirect on an invalid >>>>> request and just display an error page? >>>>> >>>>>>> >>>>> >>>>>>> thanks for sharing your thoughts :). Display an error 400 is >>>>> what Google does :) >>>>> >>>>>>> >>>>> >>>>>>> regards >>>>> >>>>>>> >>>>> >>>>>>> antonio >>>>> >>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>> >>>>>>>>> Hi Hans, >>>>> >>>>>>>>> >>>>> >>>>>>>>> I really fail to see how this can be addressed at >>>>> registration time for cases where registration is unrestricted (namely >>>>> all the big Providers) >>>>> >>>>>>>>> >>>>> >>>>>>>>> regards >>>>> >>>>>>>>> >>>>> >>>>>>>>> antonio >>>>> >>>>>>>>> >>>>> >>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt >>>>> > wrote: >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> Classifying like this must also mean that consent should not >>>>> be stored until the client is considered (admin) trusted, and admin >>>>> policy would interfere with user policy. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> IMHO the security consideration would apply only to >>>>> dynamically registered clients where registration is unrestricted; any >>>>> other form would involve some form of admin/user approval at >>>>> registration time, overcoming the concern at authorization time: >>>>> there's >>>>> no auto-redirect flow possible for unknown clients. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> Hans. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>> >>>>>>>>>>> I think this advice isn't a bad idea, though it's of course >>>>> up to the AS >>>>> >>>>>>>>>>> what an "untrusted" client really is. In practice, this is >>>>> something >>>>> >>>>>>>>>>> that was registered by a non-sysadmin type person, either a >>>>> dynamically >>>>> >>>>>>>>>>> registered client or something available through >>>>> self-service >>>>> >>>>>>>>>>> registration of some type. It's also reasonable that a >>>>> client, even >>>>> >>>>>>>>>>> dynamically registered, would be considered "trusted" if >>>>> enough time has >>>>> >>>>>>>>>>> passed and enough users have used it without things >>>>> blowing up. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> -- Justin >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>> >>>>> >>>>>>>>>>> > wrote: >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>>> hi again *, >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> after thinking a bit further IMHO an alternative for the >>>>> untrusted >>>>> >>>>>>>>>>>> clients can also be to always present the consent screen >>>>> (at least >>>>> >>>>>>>>>>>> once) before any redirect. >>>>> >>>>>>>>>>>> Namely all providers I have seen show the consent screen >>>>> if all the >>>>> >>>>>>>>>>>> request parameters are correct and if the user accepts the >>>>> redirect >>>>> >>>>>>>>>>>> happens. >>>>> >>>>>>>>>>>> If one of the parameter (with the exclusion of the client >>>>> id and >>>>> >>>>>>>>>>>> redirect uri that are handled differently as for spec) is >>>>> wrong though >>>>> >>>>>>>>>>>> the redirect happens without the consent screen being >>>>> shown.. >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> WDYT? >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> regards >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> antonio >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>> >>>>> >>>>>>>>>>>> > wrote: >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Well, >>>>> >>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>> >>>>>>>>>>>>> let’s talk about real use cases, namely e.g. Google , >>>>> Facebook , >>>>> >>>>>>>>>>>>> etc.. is that dynamic client registration? I do not >>>>> know… :) >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> Said that what the other guys think? :) >>>>> >>>>>>>>>>>>> Would this deserve some “spec adjustment” ? I mean there >>>>> is a reason >>>>> >>>>>>>>>>>>> if Google is by choice “violating” the spec right? (I >>>>> assume to avoid >>>>> >>>>>>>>>>>>> open redirect…) >>>>> >>>>>>>>>>>>> But other implementers do follow the spec hence they have >>>>> this open >>>>> >>>>>>>>>>>>> redirector… and this is not nice IMHO... >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>> >>>>> >>>>>>>>>>>>> > wrote: >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>> >>>>>>>>>>>>>>> >>>> >>>>> > wrote: >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> Is your concern clients that were registered using >>>>> dynamic client >>>>> >>>>>>>>>>>>>>>> registration? >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> yes >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> I think your issue is then with the trust model of >>>>> dynamic client >>>>> >>>>>>>>>>>>>> registration; that is left out of scope of the dynreg >>>>> spec (and the >>>>> >>>>>>>>>>>>>> concept is not even part of the core spec), but unless >>>>> you want >>>>> >>>>>>>>>>>>>> everything to be open (which typically would not be the >>>>> case), then >>>>> >>>>>>>>>>>>>> it would involve approval somewhere in the process >>>>> before the client >>>>> >>>>>>>>>>>>>> is registered. Without dynamic client registration that >>>>> approval is >>>>> >>>>>>>>>>>>>> admin based or resource owner based, depending on use >>>>> case. >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to >>>>> a valid URL >>>>> >>>>>>>>>>>>>>>> that belongs to a client that was registered >>>>> explicitly by the >>>>> >>>>>>>>>>>>>>>> resource owner >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> well AFAIK the resource owner doesn’t register clients… >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> roles can collapse in use cases especially when using >>>>> dynamic client >>>>> >>>>>>>>>>>>>> registration >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> and the negative case is returning an error to that >>>>> same URL. >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> the difference is the consent screen… in the positive >>>>> case you need >>>>> >>>>>>>>>>>>>>> to approve an app.. for the error case no approval is >>>>> needed,,, >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> why? >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly >>>>> approved at >>>>> >>>>>>>>>>>>>> some point >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> Hans. >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> Hans. >>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>> >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>> >>>>>>>>>>>>>>>>> >>>> >>>>> >>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>> >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: >>>>> why would you >>>>> >>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is >>>>> provided and >>>>> >>>>>>>>>>>>>>>>>> call it >>>>> >>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid >>>>> scope is >>>>> >>>>>>>>>>>>>>>>>> provided? >>>>> >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> as specified below in the positive case (namely when >>>>> the correct >>>>> >>>>>>>>>>>>>>>>> scope >>>>> >>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app >>>>> via the consent >>>>> >>>>>>>>>>>>>>>>> screen (at least once). >>>>> >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> Hans. >>>>> >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>> >>>>>>>>>>>>>>>>>>> hi John, >>>>> >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the >>>>> attacker. >>>>> >>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client >>>>> registrations with >>>>> >>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>> >>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates >>>>> that a client >>>>> >>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>> >>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>> I think that if anything it may be the >>>>> registration step that >>>>> >>>>>>>>>>>>>>>>>>>> needs >>>>> >>>>>>>>>>>>>>>>>>>> the security consideration. >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with >>>>> you. It would be >>>>> >>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration >>>>> time…. >>>>> >>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from >>>>> Google, namely >>>>> >>>>>>>>>>>>>>>>>>> returning >>>>> >>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> *400.* That’s an error. >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in >>>>> the spec so >>>>> >>>>>>>>>>>>>>>>>>> far…. >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> regards >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> antonio >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>> John B. >>>>> >>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>> >>>>> >>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>> > wrote: >>>>> >>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be >>>>> valid in >>>>> >>>>>>>>>>>>>>>>>>>>> order for a >>>>> >>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states >>>>> this. >>>>> >>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>> >>>>>>>>>>>>>>>>>>>>>> hi *, >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are >>>>> vulnerable >>>>> >>>>>>>>>>>>>>>>>>>>>> to open >>>>> >>>>>>>>>>>>>>>>>>>>>> redirect. >>>>> >>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, >>>>> or mismatching >>>>> >>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is >>>>> missing or >>>>> >>>>>>>>>>>>>>>>>>>>>> invalid, >>>>> >>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the >>>>> resource owner of the >>>>> >>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the >>>>> user-agent to the >>>>> >>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request >>>>> or if the >>>>> >>>>>>>>>>>>>>>>>>>>>> request >>>>> >>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or >>>>> invalid >>>>> >>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>> >>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by >>>>> adding the >>>>> >>>>>>>>>>>>>>>>>>>>>> following >>>>> >>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the >>>>> redirection URI >>>>> >>>>>>>>>>>>>>>>>>>>>> using the >>>>> >>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, >>>>> perAppendix B >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> : >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> Now let’s assume this. >>>>> >>>>>>>>>>>>>>>>>>>>>> I am registering a new client to >>>>> thevictim.com >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> > >>>>> >>>>>>>>>>>>>>>>>>>>>> provider. >>>>> >>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>> >>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> >. >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope >>>>> I am redirected >>>>> >>>>>>>>>>>>>>>>>>>>>> back to >>>>> >>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>> >>>>>>>>>>>>>>>>>>>>>> >. >>>>> >>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>> >>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>> >>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the >>>>> parameters are >>>>> >>>>>>>>>>>>>>>>>>>>>> fine this >>>>> >>>>>>>>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST >>>>> approve the app >>>>> >>>>>>>>>>>>>>>>>>>>>> via the >>>>> >>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather >>>>> than redirect >>>>> >>>>>>>>>>>>>>>>>>>>>> to the >>>>> >>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> regards >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> antonio >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> [0] >>>>> https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>> >>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>> >>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>> >>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>> >>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>> >>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>> >>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>> >>>>> >>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>> >>>>>>>>>>>>>>>>>>>>> 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 >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>> >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>> >>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>> >>>>> >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> -- >>>>> >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>> >>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>> >>>>> >>>>>>>>>>>>>>>>>> | Ping >>>>> >>>>>>>>>>>>>>>>>> Identity >>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> -- >>>>> >>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>> >>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>> | >>>>> >>>>>>>>>>>>>>>> Ping Identity >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> -- >>>>> >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>> >>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>> | Ping >>>>> >>>>>>>>>>>>>> Identity >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> _______________________________________________ >>>>> >>>>>>>>>>>> OAuth mailing list >>>>> >>>>>>>>>>>> OAuth@ietf.org >>>>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> -- >>>>> >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>> >>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>> >>>>>>>>> >>>>> >>>>>>>>> _______________________________________________ >>>>> >>>>>>>>> OAuth mailing list >>>>> >>>>>>>>> OAuth@ietf.org >>>>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>>>>> >>>>> >>>>>>>> -- >>>>> >>>>>>>> Bill Burke >>>>> >>>>>>>> JBoss, a division of Red Hat >>>>> >>>>>>>> http://bill.burkecentral.com >>>>> >>>>>>>> >>>>> >>>>>>>> _______________________________________________ >>>>> >>>>>>>> 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 >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>> >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> 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 >>>>> >> >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>> >> >> >> -- >> Sergey Beryozkin >> >> Talend Community Coders >> http://coders.talend.com/ >> >> Blog:http://sberyozkin.blogspot.com >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Tue Sep 16 07:40:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21711A0515 for ; Tue, 16 Sep 2014 07:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Xk-GGYIjIeME for ; Tue, 16 Sep 2014 07:40:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 215281A0794 for ; Tue, 16 Sep 2014 07:40:20 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8GEeIJT030502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 16 Sep 2014 10:40:19 -0400 Received: from [10.10.48.184] (vpn-48-184.rdu2.redhat.com [10.10.48.184]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8GEeGND013124 for ; Tue, 16 Sep 2014 10:40:17 -0400 Message-ID: <54184BCC.6000101@redhat.com> Date: Tue, 16 Sep 2014 10:40:12 -0400 From: Bill Burke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: oauth@ietf.org References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> <29F9628D-EBD4-4C32-BD8B-4FC520ADAED0@ve7jtb.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4ZpeqsOxY0G2IEbVockucLNVpnI Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 14:40:24 -0000 I'll reiterate what convinced me if it helps. The danger was a matter of expectations. In Antonio's scenario, the user is more likely to be expecting a login screen and thus more likely to be fooled by a login-screen spoof. Antonio's suggested changes don't break any compatibility either, it just requires the AS to display an error page on *any* parameter error instead of redirecting back. Something the spec already requires for a bad client id. On 9/16/2014 5:08 AM, Antonio Sanso wrote: > Hi John, > > agree that there are at two different things (as you pointed out below) where we could spend some word and provide some advice. > > To summarize: > > - one is the 'open redirect’ issue (net of semantic :), pointed by me, where nothing is leaked > - one is the leakage, pointed by John > > Those two scenarios are different and might deserve to be discussed independently… :) > > On Sep 15, 2014, at 11:56 PM, John Bradley wrote: > >> Something might get leaked by the browser, the fragment may be leaked by the browser if the redirect URI doesn't contain a fragment in some browsers. >> >> A simple security consideration might be to add a fragment to the redirect_uri in the error case. >> >> The other way that information may leak is via the referrer. If there is only one redirect by the AS the URI that was sent to the AS including all the parameters would still be available to the target. >> A simple fix is to redirect to a intermediate page before redirecting to the registered client, this clears the referrer. >> >> It is true that nothing is leaked in the redirect_uri itself but there are side channels in the browser that need to be considered. >> >> The fixes are quite simple implementation issues and don't break anything. >> >> Yes if the client is trusted then this is probably unnecessary but wouldn't hurt anything. >> >> John B. >> >> PS for OAuth this would really only be exploitable if exact redirect_uri matching is not happening. >> >> As I am a inherently bad person, I could hypothetically use this to attack a AS that is doing domain level pattern matching of redirect URI and has a public client in the same domain as the AS. >> >> I should also note that domains using pattern matching are also vulnerable if they allow other sorts of user hosted content like blog posts that pull in images and leak the referrer. > > if somebody is curios about some real world attack this is one I performed to Facebook that does exactly what John describes here http://intothesymmetry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html > > regards > > antonio > >> >> So we do probably need to provide some advice. >> >> John B. >> >> On Sep 15, 2014, at 6:15 PM, Richer, Justin P. wrote: >> >>> As we discussed before: This isn't really an open redirection in the classical sense since nothing gets leaked and the URI is tied back to a known (albeit malicious) client registration. And I thought the clear solution was to have an AS not automatically redirect to an untrusted client in error conditions, where "untrusted" is defined by the AS with guidance. If anything this is a security considerations addendum. >>> >>> -- Justin >>> >>> On Sep 15, 2014, at 4:52 PM, Antonio Sanso wrote: >>> >>>> The problem is that a malicious client can register a malicious redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as previously discussed) >>>> >>>> regards >>>> >>>> antonio >>>> >>>> On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: >>>> >>>>> If a server accepts a URL from a client to be used as a redirect that the server doesn’t recognize or is not registered, that is an open redirect. >>>>> >>>>> The specification does no allow open-redirects, it considers this a mis-configuration. >>>>> >>>>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >>>>> >>>>>> There may be a problem with semantics in this discussion. >>>>>> >>>>>> There is a redirect performed by athe authorization endpoint to a fixed uri that is pre registered with the authorization server without user prompting. >>>>>> >>>>>> That probably doesn't fit the strict definition of a open redirector. >>>>>> >>>>>> It may however create similar security issues in situations with relatively open registration of clients. >>>>>> >>>>>> The largest issues are that the browser might leak information across the redirect in the fragment or referrer. That has been used in attacks against Facebook in the past. >>>>>> >>>>>> This is no where near the end of the world, however we need to look at the security considerations and see if we can provide better advice to implementors. In some cases returning a error to the browser may be best. >>>>>> >>>>>> I don't think we need to go so far as not returning any error to the client under any circumstance. >>>>>> >>>>>> John B. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt wrote: >>>>>>> >>>>>>> Simply not true. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wrote: >>>>>>>> >>>>>>>> hi *, >>>>>>>> >>>>>>>> my understanding is that there is a rough consensus that if an OAuth Provider follows rfc6749 verbatim will end up having an open redirector. >>>>>>>> My next question would be now, is there anything we can do to raise some awareness about this issue? >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> antonio >>>>>>>> >>>>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrote: >>>>>>>>> >>>>>>>>> I am convinced about the issue in the use case Antonio provided but I hope not to close the door on returning errors to known and trusted clients. Not sure anymore if that's possible though because the distinction can't be "registered"... >>>>>>>>> >>>>>>>>> Hans. >>>>>>>>> >>>>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>>>>> hi Bill >>>>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wrote: >>>>>>>>>>> >>>>>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM project. Thanks Antonio. What convinced me was that the user is probably expecting a login screen. Since there is this expectation, it might make it a little easier for the attacker to convince the user that a spoofed login screen is real. I know this issue can only happen with unrestricted registration, but, IMO, this proposed change doesn't really have much of an effect on usability and is even backward compatible with the current RFC. >>>>>>>>>>> >>>>>>>>>>> Wouldn't it better though to never do a redirect on an invalid request and just display an error page? >>>>>>>>>> >>>>>>>>>> thanks for sharing your thoughts :). Display an error 400 is what Google does :) >>>>>>>>>> >>>>>>>>>> regards >>>>>>>>>> >>>>>>>>>> antonio >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>>>>> Hi Hans, >>>>>>>>>>>> >>>>>>>>>>>> I really fail to see how this can be addressed at registration time for cases where registration is unrestricted (namely all the big Providers) >>>>>>>>>>>> >>>>>>>>>>>> regards >>>>>>>>>>>> >>>>>>>>>>>> antonio >>>>>>>>>>>> >>>>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy. >>>>>>>>>>>>> >>>>>>>>>>>>> IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients. >>>>>>>>>>>>> >>>>>>>>>>>>> Hans. >>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>>>>> I think this advice isn't a bad idea, though it's of course up to the AS >>>>>>>>>>>>>> what an "untrusted" client really is. In practice, this is something >>>>>>>>>>>>>> that was registered by a non-sysadmin type person, either a dynamically >>>>>>>>>>>>>> registered client or something available through self-service >>>>>>>>>>>>>> registration of some type. It's also reasonable that a client, even >>>>>>>>>>>>>> dynamically registered, would be considered "trusted" if enough time has >>>>>>>>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Justin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> hi again *, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>>>>>>>>>>> clients can also be to always present the consent screen (at least >>>>>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>>>>> Namely all providers I have seen show the consent screen if all the >>>>>>>>>>>>>>> request parameters are correct and if the user accepts the redirect >>>>>>>>>>>>>>> happens. >>>>>>>>>>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>>>>>>>>>> redirect uri that are handled differently as for spec) is wrong though >>>>>>>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Well, >>>>>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook , >>>>>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know… :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>>>>> Would this deserve some “spec adjustment” ? I mean there is a reason >>>>>>>>>>>>>>>> if Google is by choice “violating” the spec right? (I assume to avoid >>>>>>>>>>>>>>>> open redirect…) >>>>>>>>>>>>>>>> But other implementers do follow the spec hence they have this open >>>>>>>>>>>>>>>> redirector… and this is not nice IMHO... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Is your concern clients that were registered using dynamic client >>>>>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think your issue is then with the trust model of dynamic client >>>>>>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec (and the >>>>>>>>>>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>>>>>>>>>> everything to be open (which typically would not be the case), then >>>>>>>>>>>>>>>>> it would involve approval somewhere in the process before the client >>>>>>>>>>>>>>>>> is registered. Without dynamic client registration that approval is >>>>>>>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to a valid URL >>>>>>>>>>>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> well AFAIK the resource owner doesn’t register clients… >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> roles can collapse in use cases especially when using dynamic client >>>>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> the difference is the consent screen… in the positive case you need >>>>>>>>>>>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly approved at >>>>>>>>>>>>>>>>> some point >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: why would you >>>>>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provided and >>>>>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> as specified below in the positive case (namely when the correct >>>>>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via the consent >>>>>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client registrations with >>>>>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a client >>>>>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration step that >>>>>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It would be >>>>>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time…. >>>>>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *400.* That’s an error. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the spec so >>>>>>>>>>>>>>>>>>>>>> far…. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable >>>>>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatching >>>>>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or >>>>>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner of the >>>>>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the >>>>>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if the >>>>>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding the >>>>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B >>>>>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Now let’s assume this. >>>>>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected >>>>>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the app >>>>>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than redirect >>>>>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Bill Burke >>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From nobody Tue Sep 16 20:39:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BA51A0196 for ; Tue, 16 Sep 2014 20:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 C1EQX6h4NAcT for ; Tue, 16 Sep 2014 20:38:49 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CAF1A0177 for ; Tue, 16 Sep 2014 20:38:48 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id el20so1038196lab.19 for ; Tue, 16 Sep 2014 20:38:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DPHX2BGn0TUyqAt5krsIbK0YYCgT/dPWCTkpNVXGnpc=; b=S2nq3WqNTr7UDZbe94tUXBqNqRBW/xXScBTm++Kp8UwWhmspcbVN7RvzHG/xfvdX4M qei36G2Cif3Hl72+NFc4kjsc7GpQtMerx6CxmCM2kNjwdjNQvkmqzbYbYdXXtcH5/u4S pyvyArpC5wuIQUK277zPrBUdK3nvj51P4sCc4n23rQYibg1GgMX5CGoudcaYPjdie1Sc bFoZC6X5IUGFVipg3r3ClDcRK5uui1FEHcmDLhmtHaPM91u4dlsRR/PAv6qwvduBZXB/ 85YFExgFysqTsWzYYuH6tYwS6c5WCKXj4ZbtONMapfKvlxDzo6G0RquQvpaZ8iF8Byhl /dfg== X-Gm-Message-State: ALoCoQnSBScPdgerPpxYtRjDgxLd8sdKq3Sc8MNxFBJ83+VKc8g4Wl6FiHCtz6CnIiBn/8NJZ/qm MIME-Version: 1.0 X-Received: by 10.112.4.33 with SMTP id h1mr37966335lbh.67.1410925126700; Tue, 16 Sep 2014 20:38:46 -0700 (PDT) Received: by 10.25.159.84 with HTTP; Tue, 16 Sep 2014 20:38:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Sep 2014 23:38:46 -0400 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=bcaec52be6a7fb63df05033a9afc Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Qn2NslQadQ_jLakb9X7O8JQT_pY Cc: "secdir@ietf.org" , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , "jose@ietf.org" , Warren Kumari , "oauth@ietf.org" Subject: Re: [OAUTH-WG] [jose] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 03:38:51 -0000 --bcaec52be6a7fb63df05033a9afc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I will re-iterate here my strong preference that an "unsecured" or "plaintext" JWS object be syntactically distinct from a real JWS object. E.g. by having two dot-separated components instead of three. Beyond that, seems like just shuffling deck chairs. On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell wrote: > cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA. > > I agree that "plaintext=E2=80=9D is not the most intuitive wording choice= and that > "unsecured" might better convey what's going on with the "none" JWS > algorithm. > > Mike mentioned that, if this change is made in JWT, there are parallel > changes in JWS. But note that there are also such changes in JWA (more th= an > in JWS actually). > > On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones > wrote: > >> -----Original Message----- >> From: Warren Kumari [mailto:warren@kumari.net] >> Sent: Monday, September 01, 2014 3:40 PM >> To: secdir@ietf.org; draft-ietf-oauth-json-web-token.all@tools.ietf.org >> Subject: Review of: draft-ietf-oauth-json-web-token >> >> I'm a little confused by something in the Terminology section (Section 2= ): >> >> Plaintext JWT >> >> A JWT whose Claims are not integrity protected or encrypted. >> >> The term plaintext to me means something like "is readable without >> decrypting / much decoding" (something like, if you cat the file to a >> terminal, you will see the information). Integrity protecting a string >> doesn't make it not easily readable. If this document / JOSE uses >> "plaintext" differently (and a quick skim didn't find anything about >> >> this) it might be good to clarify. Section 6 *does* discuss plaintext >> JWTs, but doesn't really clarify the (IMO) unusual meaning of the term >> "plaintext" here. >> >> >> >> I=E2=80=99ve discussed this with the other document editors and we agree= with you >> that =E2=80=9Cplaintext=E2=80=9D is not the most intuitive wording choic= e in this context. >> Possible alternative terms are =E2=80=9CUnsecured JWT=E2=80=9D or =E2=80= =9CUnsigned JWT=E2=80=9D. I think >> that =E2=80=9CUnsecured JWT=E2=80=9D is probably the preferred term, sin= ce JWTs that are >> JWEs are also unsigned, but they are secured. Working group =E2=80=93 a= re you OK >> with this possible terminology change? (Note that the parallel change >> =E2=80=9CPlaintext JWS=E2=80=9D -> =E2=80=9CUnsecured JWS=E2=80=9D would= also be made in the JWS spec.) >> >> >> > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec52be6a7fb63df05033a9afc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I will re-iterate here my strong preference that an &= quot;unsecured" or "plaintext" JWS object be syntactically d= istinct from a real JWS object.=C2=A0 E.g. by having two dot-separated comp= onents instead of three.

Beyond that, seems like just shufflin= g deck chairs.

On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell &l= t;bcampbell= @pingidentity.com> wrote:
<= div dir=3D"ltr">cc'ing JOSE on a minor JWT review comment that might im= pact JWS/JWA.

I agree that "plaintext=E2=80=9D is not the= most intuitive wording choice and that "unsecured" might better = convey what's going on with the "none" JWS algorithm.
Mike mentioned that, if this change is made in JWT, there are p= arallel changes in JWS. But note that there are also such changes in JWA (m= ore than in JWS actually).
On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

-----Original Message-----
From: Warren Kumari [mailto:warren@kumari.net]
Sent: Monday, September 01, 2014 3:40 PM
To: secdir@ietf.org; draft-ietf-oauth-json-web-token.all@tools.ietf.org
Subject: Review of: draft-ietf-oauth-json-web-token

I'm a little confused by something in the Terminology section (Secti= on 2):

Plaintext JWT

A JWT whose Claims are not integrity protected or encrypted.

The term plaintext to me means something like "is readable without = decrypting / much decoding" (something like, if you cat the file to a = terminal, you will see the information). Integrity protecting a string does= n't make it not easily readable. If this document / JOSE uses "plaintext" differently (= and a quick skim didn't find anything about

this) it might be good to clarify. Section 6 *does* discuss plaintext JW= Ts, but doesn't really clarify the (IMO) unusual meaning of the term &q= uot;plaintext" here.

=C2=A0

I=E2=80=99ve discussed this with th= e other document editors and we agree with you that =E2=80=9Cplaintext=E2= =80=9D is not the most intuitive wording choice in this context.=C2=A0 Poss= ible alternative terms are =E2=80=9CUnsecured JWT=E2=80=9D or =E2=80=9CUnsi= gned JWT=E2=80=9D.=C2=A0 I think that =E2=80=9CUnsecured JWT=E2=80=9D is probab= ly the preferred term, since JWTs that are JWEs are also unsigned, but they= are secured.=C2=A0 Working group =E2=80=93 are you OK with this possible t= erminology change?=C2=A0 (Note that the parallel change =E2=80=9CPlaintext = JWS=E2=80=9D -> =E2=80=9CUnsecured JWS=E2=80=9D would also be made in the JWS spec.)

=C2=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec52be6a7fb63df05033a9afc-- From nobody Wed Sep 17 05:39:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B171A0346 for ; Wed, 17 Sep 2014 04:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 TS-CtnRpq0zF for ; Wed, 17 Sep 2014 04:40:07 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25A41A00F5 for ; Wed, 17 Sep 2014 04:40:06 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so1247887wgh.19 for ; Wed, 17 Sep 2014 04:40:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nXns91o69u7OIojyqugWnOQpJEqDh9CG7mMTbHGSw0Q=; b=LVdqm5c3qTFnGs152kTTYSAobUbg9G8JToT7L40cvHfDAyhSgWG2s3NjYu7I2Myit+ pvT0gTbly6q0bnl2MX9iVL98AjLutyyj1CalMoF+xxzoWoQ0qJWNo9Gr+Z9t3jMesBZd IK+qrbnN65lA5j1ZJLJ1DgLW6fwWDn2rrsHMRFRI6oUhIBymyP7tTDJNrDMINHkB2BiE xzjOrfRpAk2vlSeOQRTrC8xf+u+//XYFTfBAt9QvuXj7yF7MRVl0xFAMxT3e3riDwbc5 xOqCJS64r6v6p3Ug34o7Ze1M1zgm6rhcP2a0qHdW/m4FSY2at8jXRapxhHttdNe3a0+E hMjQ== X-Gm-Message-State: ALoCoQl51XVYoo12ycBZXAeBaCQJ0fi5BHtyfqizGvjc318zXQVJEVILm88pCLDL0xkY7T9fdZSN MIME-Version: 1.0 X-Received: by 10.194.24.169 with SMTP id v9mr2699538wjf.114.1410954005479; Wed, 17 Sep 2014 04:40:05 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Wed, 17 Sep 2014 04:40:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Sep 2014 07:40:05 -0400 Message-ID: From: Warren Kumari To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7b45101a4a9ea60503415491 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fSaIQCmWboj-RlxrBkcjHe5ST3g X-Mailman-Approved-At: Wed, 17 Sep 2014 05:39:47 -0700 Cc: "secdir@ietf.org" , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , "jose@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 11:40:09 -0000 --047d7b45101a4a9ea60503415491 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, September 16, 2014, Richard Barnes wrote: > I will re-iterate here my strong preference that an "unsecured" or > "plaintext" JWS object be syntactically distinct from a real JWS object. > E.g. by having two dot-separated components instead of three. > So, *I* was just grumping about the term used in the draft, but yes, these should (IMO, etc) be different. I'm also still uncomfortable about the "you can have the same information in the "secured" and "unsecured" section, but the secured one shold be trusted more bit. This seems like it will end in fail. (Apologies if this was already discussed and I missed it, and for rushed tone of mail, traveling...) W > Beyond that, seems like just shuffling deck chairs. > > On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell < > bcampbell@pingidentity.com > > wrote: > >> cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA. >> >> I agree that "plaintext=E2=80=9D is not the most intuitive wording choic= e and >> that "unsecured" might better convey what's going on with the "none" JWS >> algorithm. >> >> Mike mentioned that, if this change is made in JWT, there are parallel >> changes in JWS. But note that there are also such changes in JWA (more t= han >> in JWS actually). >> >> On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones > > wrote: >> >>> -----Original Message----- >>> From: Warren Kumari [mailto:warren@kumari.net >>> ] >>> Sent: Monday, September 01, 2014 3:40 PM >>> To: secdir@ietf.org ; >>> draft-ietf-oauth-json-web-token.all@tools.ietf.org >>> >>> Subject: Review of: draft-ietf-oauth-json-web-token >>> >>> I'm a little confused by something in the Terminology section (Section >>> 2): >>> >>> Plaintext JWT >>> >>> A JWT whose Claims are not integrity protected or encrypted. >>> >>> The term plaintext to me means something like "is readable without >>> decrypting / much decoding" (something like, if you cat the file to a >>> terminal, you will see the information). Integrity protecting a string >>> doesn't make it not easily readable. If this document / JOSE uses >>> "plaintext" differently (and a quick skim didn't find anything about >>> >>> this) it might be good to clarify. Section 6 *does* discuss plaintext >>> JWTs, but doesn't really clarify the (IMO) unusual meaning of the term >>> "plaintext" here. >>> >>> >>> >>> I=E2=80=99ve discussed this with the other document editors and we agre= e with >>> you that =E2=80=9Cplaintext=E2=80=9D is not the most intuitive wording = choice in this >>> context. Possible alternative terms are =E2=80=9CUnsecured JWT=E2=80= =9D or =E2=80=9CUnsigned >>> JWT=E2=80=9D. I think that =E2=80=9CUnsecured JWT=E2=80=9D is probably= the preferred term, since >>> JWTs that are JWEs are also unsigned, but they are secured. Working gr= oup >>> =E2=80=93 are you OK with this possible terminology change? (Note that= the >>> parallel change =E2=80=9CPlaintext JWS=E2=80=9D -> =E2=80=9CUnsecured J= WS=E2=80=9D would also be made in >>> the JWS spec.) >>> >>> >>> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --047d7b45101a4a9ea60503415491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, September 16, 2014, Richard Barnes <rlb@ipv.sx> w= rote:
I will re-ite= rate here my strong preference that an "unsecured" or "plain= text" JWS object be syntactically distinct from a real JWS object.=C2= =A0 E.g. by having two dot-separated components instead of three.

So, *I* was just grumping about the term used= in the draft, but yes, these should (IMO, etc) be different.

I'm also still=C2=A0uncomfortable about the "you can have th= e same information in the "secured" and "unsecured" sec= tion, but the secured one shold be trusted more bit. This seems like it wil= l end in fail. (Apologies if this was already discussed and I missed it, an= d for rushed tone of mail, traveling...)

W

=C2=A0
Beyond that, seems like just shuffling deck chairs.

On Mon, Se= p 8, 2014 at 12:10 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
cc'ing JOSE on a minor JWT revi= ew comment that might impact JWS/JWA.

I agree that "plain= text=E2=80=9D is not the most intuitive wording choice and that "unsec= ured" might better convey what's going on with the "none"= ; JWS algorithm.

Mike mentioned that, if this change is = made in JWT, there are parallel changes in JWS. But note that there are als= o such changes in JWA (more than in JWS actually).

On Fri, Sep 5, 2014 at= 6:28 PM, Mike Jones <M= ichael.Jones@microsoft.com> wrote:

-----Original Message-----
From: Warren Kumari [mailto:warren@kumari.net] Sent: Monday, September 01, 2014 3:40 PM
To: secdir@ietf.org; draft-ietf-oauth-json-web-token.all@tools.ietf.org
Subject: Review of: draft-ietf-oauth-json-web-token

I'm a little confused by something in the Terminology section (Secti= on 2):

Plaintext JWT

A JWT whose Claims are not integrity protected or encrypted.

The term plaintext to me means something like "is readable without = decrypting / much decoding" (something like, if you cat the file to a = terminal, you will see the information). Integrity protecting a string does= n't make it not easily readable. If this document / JOSE uses "plaintext" differently (= and a quick skim didn't find anything about

this) it might be good to clarify. Section 6 *does* discuss plaintext JW= Ts, but doesn't really clarify the (IMO) unusual meaning of the term &q= uot;plaintext" here.

=C2=A0

I=E2=80=99ve discussed this with th= e other document editors and we agree with you that =E2=80=9Cplaintext=E2= =80=9D is not the most intuitive wording choice in this context.=C2=A0 Poss= ible alternative terms are =E2=80=9CUnsecured JWT=E2=80=9D or =E2=80=9CUnsi= gned JWT=E2=80=9D.=C2=A0 I think that =E2=80=9CUnsecured JWT=E2=80=9D is probab= ly the preferred term, since JWTs that are JWEs are also unsigned, but they= are secured.=C2=A0 Working group =E2=80=93 are you OK with this possible t= erminology change?=C2=A0 (Note that the parallel change =E2=80=9CPlaintext = JWS=E2=80=9D -> =E2=80=9CUnsecured JWS=E2=80=9D would also be made in the JWS spec.)

=C2=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
I don't think the execution is releva= nt when it was obviously a bad idea in the first place.
This is like put= ting rabid weasels in your pants, and later expressing regret at having cho= sen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0= ---maf
--047d7b45101a4a9ea60503415491-- From nobody Wed Sep 17 09:41:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C341E1A04BC; Wed, 17 Sep 2014 09:41:35 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EHYfous8WBXj; Wed, 17 Sep 2014 09:41:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::720]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA04D1A04B9; Wed, 17 Sep 2014 09:41:31 -0700 (PDT) Received: from CH1PR03CA007.namprd03.prod.outlook.com (10.255.156.152) by BY2PR0301MB0776.namprd03.prod.outlook.com (25.160.64.12) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Wed, 17 Sep 2014 16:41:08 +0000 Received: from BL2FFO11FD037.protection.gbl (10.255.156.132) by CH1PR03CA007.outlook.office365.com (10.255.156.152) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Wed, 17 Sep 2014 16:41:07 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD037.mail.protection.outlook.com (10.173.161.133) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Wed, 17 Sep 2014 16:41:07 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0195.002; Wed, 17 Sep 2014 16:40:44 +0000 From: Mike Jones To: Warren Kumari , Richard Barnes Thread-Topic: alternative term to "plaintext" for the "none" alg (was Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token) Thread-Index: AQHP0mwjMH5fKbfHa0qoJPYCQJJBhZwFhKbQ Date: Wed, 17 Sep 2014 16:40:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439B941EA6@TK5EX14MBXC292.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439B941EA6TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(377454003)(13464003)(199003)(189002)(51444003)(24454002)(55846006)(26826002)(19300405004)(106116001)(19580395003)(44976005)(83322001)(19617315012)(80022003)(85852003)(64706001)(69596002)(74662003)(77982003)(19580405001)(66066001)(74502003)(79102003)(81542003)(90102001)(15975445006)(84676001)(81156004)(86362001)(86612001)(76482002)(77096002)(92726001)(20776003)(50986999)(83072002)(106466001)(512874002)(85306004)(54356999)(21056001)(99396002)(87936001)(4396001)(76176999)(92566001)(230783001)(6806004)(31966008)(46102003)(68736004)(15202345003)(2656002)(97736003)(107046002)(104016003)(71186001)(95666004)(84326002)(85806002)(33656002)(81342003)(16236675004)(19625215002)(372894003)(9078065003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0776; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0337AFFE9A Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KC8KZJt2zDtdoqOL_g20ZCTR7yE Cc: "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , "oauth@ietf.org" , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 16:41:35 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439B941EA6TK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGlzIHdhcyBhbHJlYWR5IGV4dGVuc2l2ZWx5IGRpc2N1c3NlZC4gIEl0IHdhcyBjb3Zl cmVkIGluIGlzc3VlICMzNiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMv dGlja2V0LzM2IGFuZCB0aGUgcmVsYXRlZCB3b3JraW5nIGdyb3VwIGUtbWFpbCB0aHJlYWQuICBJ dCB3YXMgYWxzbyBhIHRvcGljIGR1cmluZyBtdWx0aXBsZSBpbnRlcmltIHdvcmtpbmcgZ3JvdXAg Y2FsbHMuICBBcyBub3RlZCBieSBLYXJlbiBP4oCZRG9ub2dodWUgKG9uZSBvZiB0aGUgY2hhaXJz KSBpbiB0aGUgaXNzdWUgZGVzY3JpcHRpb24g4oCcTm90ZTogVGhlcmUgd2FzIGV4dGVuc2l2ZSBk aXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCB0aGUgcm91Z2ggY29uc2Vuc3VzIG9m IHRoZSB3b3JraW5nIGdyb3VwIHdhcyB0byBsZWF2ZSAibm9uZSIgaW4gdGhlIGRvY3VtZW50LuKA nSAgQXMgcGFydCBvZiB0aGUgcmVzb2x1dGlvbiBhZ3JlZWQgdG8gYnkgdGhlIHdvcmtpbmcgZ3Jv dXAsIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0ZXh0IGF0IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0zMSNzZWN0aW9u LTguNSB3YXMgYWRkZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogV2FycmVuIEt1bWFyaSBbbWFp bHRvOndhcnJlbkBrdW1hcmkubmV0XQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTcsIDIw MTQgNDo0MCBBTQ0KVG86IFJpY2hhcmQgQmFybmVzDQpDYzogQnJpYW4gQ2FtcGJlbGw7IE1pa2Ug Sm9uZXM7IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxsQHRvb2xzLmlldGYub3Jn OyBvYXV0aEBpZXRmLm9yZzsgam9zZUBpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogYWx0ZXJuYXRpdmUgdGVybSB0byAicGxhaW50ZXh0IiBmb3IgdGhlICJub25lIiBhbGcg KHdhcyBSZTogW09BVVRILVdHXSBSZXZpZXcgb2Y6IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWIt dG9rZW4pDQoNCk9uIFR1ZXNkYXksIFNlcHRlbWJlciAxNiwgMjAxNCwgUmljaGFyZCBCYXJuZXMg PHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCkkgd2lsbCByZS1pdGVyYXRl IGhlcmUgbXkgc3Ryb25nIHByZWZlcmVuY2UgdGhhdCBhbiAidW5zZWN1cmVkIiBvciAicGxhaW50 ZXh0IiBKV1Mgb2JqZWN0IGJlIHN5bnRhY3RpY2FsbHkgZGlzdGluY3QgZnJvbSBhIHJlYWwgSldT IG9iamVjdC4gIEUuZy4gYnkgaGF2aW5nIHR3byBkb3Qtc2VwYXJhdGVkIGNvbXBvbmVudHMgaW5z dGVhZCBvZiB0aHJlZS4NCg0KU28sICpJKiB3YXMganVzdCBncnVtcGluZyBhYm91dCB0aGUgdGVy bSB1c2VkIGluIHRoZSBkcmFmdCwgYnV0IHllcywgdGhlc2Ugc2hvdWxkIChJTU8sIGV0YykgYmUg ZGlmZmVyZW50Lg0KDQpJJ20gYWxzbyBzdGlsbCB1bmNvbWZvcnRhYmxlIGFib3V0IHRoZSAieW91 IGNhbiBoYXZlIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIHRoZSAic2VjdXJlZCIgYW5kICJ1bnNl Y3VyZWQiIHNlY3Rpb24sIGJ1dCB0aGUgc2VjdXJlZCBvbmUgc2hvbGQgYmUgdHJ1c3RlZCBtb3Jl IGJpdC4gVGhpcyBzZWVtcyBsaWtlIGl0IHdpbGwgZW5kIGluIGZhaWwuIChBcG9sb2dpZXMgaWYg dGhpcyB3YXMgYWxyZWFkeSBkaXNjdXNzZWQgYW5kIEkgbWlzc2VkIGl0LCBhbmQgZm9yIHJ1c2hl ZCB0b25lIG9mIG1haWwsIHRyYXZlbGluZy4uLikNCg0KVw0KDQoNCkJleW9uZCB0aGF0LCBzZWVt cyBsaWtlIGp1c3Qgc2h1ZmZsaW5nIGRlY2sgY2hhaXJzLg0KDQpPbiBNb24sIFNlcCA4LCAyMDE0 IGF0IDEyOjEwIFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208 amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbScp Oz4+IHdyb3RlOg0KY2MnaW5nIEpPU0Ugb24gYSBtaW5vciBKV1QgcmV2aWV3IGNvbW1lbnQgdGhh dCBtaWdodCBpbXBhY3QgSldTL0pXQS4NCg0KSSBhZ3JlZSB0aGF0ICJwbGFpbnRleHTigJ0gaXMg bm90IHRoZSBtb3N0IGludHVpdGl2ZSB3b3JkaW5nIGNob2ljZSBhbmQgdGhhdCAidW5zZWN1cmVk IiBtaWdodCBiZXR0ZXIgY29udmV5IHdoYXQncyBnb2luZyBvbiB3aXRoIHRoZSAibm9uZSIgSldT IGFsZ29yaXRobS4NCk1pa2UgbWVudGlvbmVkIHRoYXQsIGlmIHRoaXMgY2hhbmdlIGlzIG1hZGUg aW4gSldULCB0aGVyZSBhcmUgcGFyYWxsZWwgY2hhbmdlcyBpbiBKV1MuIEJ1dCBub3RlIHRoYXQg dGhlcmUgYXJlIGFsc28gc3VjaCBjaGFuZ2VzIGluIEpXQSAobW9yZSB0aGFuIGluIEpXUyBhY3R1 YWxseSkuDQoNCk9uIEZyaSwgU2VwIDUsIDIwMTQgYXQgNjoyOCBQTSwgTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnTWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJyk7Pj4gd3JvdGU6DQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBXYXJyZW4gS3VtYXJpIFttYWlsdG86d2FycmVuQGt1bWFyaS5uZXQ8 amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCd3YXJyZW5Aa3VtYXJpLm5ldCcpOz5dDQpTZW50 OiBNb25kYXksIFNlcHRlbWJlciAwMSwgMjAxNCAzOjQwIFBNDQpUbzogc2VjZGlyQGlldGYub3Jn PGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnc2VjZGlyQGlldGYub3JnJyk7PjsgZHJhZnQt aWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi5hbGxAdG9vbHMuaWV0Zi5vcmc8amF2YXNjcmlwdDpf ZSglN0IlN0QsJ2N2bWwnLCdkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLmFsbEB0b29s cy5pZXRmLm9yZycpOz4NClN1YmplY3Q6IFJldmlldyBvZjogZHJhZnQtaWV0Zi1vYXV0aC1qc29u LXdlYi10b2tlbg0KDQpJJ20gYSBsaXR0bGUgY29uZnVzZWQgYnkgc29tZXRoaW5nIGluIHRoZSBU ZXJtaW5vbG9neSBzZWN0aW9uIChTZWN0aW9uIDIpOg0KDQpQbGFpbnRleHQgSldUDQoNCkEgSldU IHdob3NlIENsYWltcyBhcmUgbm90IGludGVncml0eSBwcm90ZWN0ZWQgb3IgZW5jcnlwdGVkLg0K DQpUaGUgdGVybSBwbGFpbnRleHQgdG8gbWUgbWVhbnMgc29tZXRoaW5nIGxpa2UgImlzIHJlYWRh YmxlIHdpdGhvdXQgZGVjcnlwdGluZyAvIG11Y2ggZGVjb2RpbmciIChzb21ldGhpbmcgbGlrZSwg aWYgeW91IGNhdCB0aGUgZmlsZSB0byBhIHRlcm1pbmFsLCB5b3Ugd2lsbCBzZWUgdGhlIGluZm9y bWF0aW9uKS4gSW50ZWdyaXR5IHByb3RlY3RpbmcgYSBzdHJpbmcgZG9lc24ndCBtYWtlIGl0IG5v dCBlYXNpbHkgcmVhZGFibGUuIElmIHRoaXMgZG9jdW1lbnQgLyBKT1NFIHVzZXMgInBsYWludGV4 dCIgZGlmZmVyZW50bHkgKGFuZCBhIHF1aWNrIHNraW0gZGlkbid0IGZpbmQgYW55dGhpbmcgYWJv dXQNCg0KdGhpcykgaXQgbWlnaHQgYmUgZ29vZCB0byBjbGFyaWZ5LiBTZWN0aW9uIDYgKmRvZXMq IGRpc2N1c3MgcGxhaW50ZXh0IEpXVHMsIGJ1dCBkb2Vzbid0IHJlYWxseSBjbGFyaWZ5IHRoZSAo SU1PKSB1bnVzdWFsIG1lYW5pbmcgb2YgdGhlIHRlcm0gInBsYWludGV4dCIgaGVyZS4NCg0KDQoN CknigJl2ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIHRoZSBvdGhlciBkb2N1bWVudCBlZGl0b3JzIGFu ZCB3ZSBhZ3JlZSB3aXRoIHlvdSB0aGF0IOKAnHBsYWludGV4dOKAnSBpcyBub3QgdGhlIG1vc3Qg aW50dWl0aXZlIHdvcmRpbmcgY2hvaWNlIGluIHRoaXMgY29udGV4dC4gIFBvc3NpYmxlIGFsdGVy bmF0aXZlIHRlcm1zIGFyZSDigJxVbnNlY3VyZWQgSldU4oCdIG9yIOKAnFVuc2lnbmVkIEpXVOKA nS4gIEkgdGhpbmsgdGhhdCDigJxVbnNlY3VyZWQgSldU4oCdIGlzIHByb2JhYmx5IHRoZSBwcmVm ZXJyZWQgdGVybSwgc2luY2UgSldUcyB0aGF0IGFyZSBKV0VzIGFyZSBhbHNvIHVuc2lnbmVkLCBi dXQgdGhleSBhcmUgc2VjdXJlZC4gIFdvcmtpbmcgZ3JvdXAg4oCTIGFyZSB5b3UgT0sgd2l0aCB0 aGlzIHBvc3NpYmxlIHRlcm1pbm9sb2d5IGNoYW5nZT8gIChOb3RlIHRoYXQgdGhlIHBhcmFsbGVs IGNoYW5nZSDigJxQbGFpbnRleHQgSldT4oCdIC0+IOKAnFVuc2VjdXJlZCBKV1PigJ0gd291bGQg YWxzbyBiZSBtYWRlIGluIHRoZSBKV1Mgc3BlYy4pDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0 Zi5vcmc8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdqb3NlQGlldGYub3JnJyk7Pg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg0KDQotLQ0KSSBkb24n dCB0aGluayB0aGUgZXhlY3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlvdXNseSBh IGJhZCBpZGVhIGluIHRoZSBmaXJzdCBwbGFjZS4NClRoaXMgaXMgbGlrZSBwdXR0aW5nIHJhYmlk IHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3NpbmcgcmVncmV0IGF0IGhh dmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFuZCB0aGF0IHBhaXIg b2YgcGFudHMuDQogICAtLS1tYWYNCg== --_000_4E1F6AAD24975D4BA5B16804296739439B941EA6TK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCB0aGlzIHdhcyBhbHJlYWR5IGV4dGVuc2l2ZWx5IGRp c2N1c3NlZC4mbmJzcDsgSXQgd2FzIGNvdmVyZWQgaW4gaXNzdWUgIzM2DQo8YSBocmVmPSJodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0LzM2Ij5odHRwOi8vdHJh Yy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0LzM2PC9hPiBhbmQgdGhlIHJlbGF0 ZWQgd29ya2luZyBncm91cCBlLW1haWwgdGhyZWFkLiZuYnNwOyBJdCB3YXMgYWxzbyBhIHRvcGlj IGR1cmluZyBtdWx0aXBsZSBpbnRlcmltIHdvcmtpbmcgZ3JvdXAgY2FsbHMuJm5ic3A7IEFzIG5v dGVkIGJ5IEthcmVuIE/igJlEb25vZ2h1ZSAob25lDQogb2YgdGhlIGNoYWlycykgaW4gdGhlIGlz c3VlIGRlc2NyaXB0aW9uIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+Tm90ZTogVGhlcmUgd2FzIGV4dGVuc2l2ZSBkaXNjdXNzaW9uIG9uIHRoZSBt YWlsaW5nIGxpc3QsIGFuZCB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRoZSB3b3JraW5nIGdyb3Vw IHdhcyB0byBsZWF2ZSAmcXVvdDtub25lJnF1b3Q7IGluIHRoZSBkb2N1bWVudC48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnSZuYnNwOw0KIEFzIHBh cnQgb2YgdGhlIHJlc29sdXRpb24gYWdyZWVkIHRvIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGV4dCBhdA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTMxI3NlY3Rp b24tOC41Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtcy0zMSNzZWN0aW9uLTguNTwvYT4gd2FzIGFkZGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IFdhcnJlbiBLdW1hcmkgW21haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldF0NCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNywgMjAxNCA0OjQwIEFNPGJyPg0KPGI+ VG86PC9iPiBSaWNoYXJkIEJhcm5lczxicj4NCjxiPkNjOjwvYj4gQnJpYW4gQ2FtcGJlbGw7IE1p a2UgSm9uZXM7IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxsQHRvb2xzLmlldGYu b3JnOyBvYXV0aEBpZXRmLm9yZzsgam9zZUBpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBhbHRlcm5hdGl2ZSB0ZXJtIHRvICZxdW90O3BsYWludGV4dCZx dW90OyBmb3IgdGhlICZxdW90O25vbmUmcXVvdDsgYWxnICh3YXMgUmU6IFtPQVVUSC1XR10gUmV2 aWV3IG9mOiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIFR1ZXNkYXksIFNlcHRlbWJlciAx NiwgMjAxNCwgUmljaGFyZCBCYXJuZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4Ij5y bGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgd2lsbCByZS1pdGVyYXRlIGhlcmUgbXkgc3Ryb25nIHByZWZl cmVuY2UgdGhhdCBhbiAmcXVvdDt1bnNlY3VyZWQmcXVvdDsgb3IgJnF1b3Q7cGxhaW50ZXh0JnF1 b3Q7IEpXUyBvYmplY3QgYmUgc3ludGFjdGljYWxseSBkaXN0aW5jdCBmcm9tIGEgcmVhbCBKV1Mg b2JqZWN0LiZuYnNwOyBFLmcuIGJ5IGhhdmluZyB0d28gZG90LXNlcGFyYXRlZCBjb21wb25lbnRz IGluc3RlYWQgb2YgdGhyZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TbywgKkkqIHdhcyBqdXN0IGdydW1waW5nIGFib3V0IHRoZSB0ZXJt IHVzZWQgaW4gdGhlIGRyYWZ0LCBidXQgeWVzLCB0aGVzZSBzaG91bGQgKElNTywgZXRjKSBiZSBk aWZmZXJlbnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J J20gYWxzbyBzdGlsbCZuYnNwO3VuY29tZm9ydGFibGUgYWJvdXQgdGhlICZxdW90O3lvdSBjYW4g aGF2ZSB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiB0aGUgJnF1b3Q7c2VjdXJlZCZxdW90OyBhbmQg JnF1b3Q7dW5zZWN1cmVkJnF1b3Q7IHNlY3Rpb24sIGJ1dCB0aGUgc2VjdXJlZCBvbmUgc2hvbGQg YmUgdHJ1c3RlZCBtb3JlIGJpdC4gVGhpcyBzZWVtcyBsaWtlIGl0IHdpbGwgZW5kIGluIGZhaWwu IChBcG9sb2dpZXMgaWYgdGhpcyB3YXMgYWxyZWFkeSBkaXNjdXNzZWQNCiBhbmQgSSBtaXNzZWQg aXQsIGFuZCBmb3IgcnVzaGVkIHRvbmUgb2YgbWFpbCwgdHJhdmVsaW5nLi4uKTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CZXlvbmQgdGhhdCwgc2VlbXMgbGlrZSBqdXN0IHNodWZmbGluZyBkZWNrIGNoYWly cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwg U2VwIDgsIDIwMTQgYXQgMTI6MTAgUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJqYXZh c2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJyk7IiB0 YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jYydpbmcgSk9TRSBv biBhIG1pbm9yIEpXVCByZXZpZXcgY29tbWVudCB0aGF0IG1pZ2h0IGltcGFjdCBKV1MvSldBLg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpJIGFncmVlIHRoYXQgJnF1b3Q7cGxhaW50ZXh04oCdIGlz IG5vdCB0aGUgbW9zdCBpbnR1aXRpdmUgd29yZGluZyBjaG9pY2UgYW5kIHRoYXQgJnF1b3Q7dW5z ZWN1cmVkJnF1b3Q7IG1pZ2h0IGJldHRlciBjb252ZXkgd2hhdCdzIGdvaW5nIG9uIHdpdGggdGhl ICZxdW90O25vbmUmcXVvdDsgSldTIGFsZ29yaXRobS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZSBtZW50aW9uZWQgdGhhdCwgaWYgdGhp cyBjaGFuZ2UgaXMgbWFkZSBpbiBKV1QsIHRoZXJlIGFyZSBwYXJhbGxlbCBjaGFuZ2VzIGluIEpX Uy4gQnV0IG5vdGUgdGhhdCB0aGVyZSBhcmUgYWxzbyBzdWNoIGNoYW5nZXMgaW4gSldBIChtb3Jl IHRoYW4gaW4gSldTIGFjdHVhbGx5KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBTZXAgNSwgMjAxNCBhdCA2OjI4IFBN LCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ01p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbScpOyIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cD4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFdhcnJlbiBLdW1h cmkgW21haWx0bzo8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3dhcnJlbkBr dW1hcmkubmV0Jyk7IiB0YXJnZXQ9Il9ibGFuayI+d2FycmVuQGt1bWFyaS5uZXQ8L2E+XQ0KPGJy Pg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTQgMzo0MCBQTTxicj4NClRvOiA8YSBo cmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3NlY2RpckBpZXRmLm9yZycpOyIgdGFy Z2V0PSJfYmxhbmsiPnNlY2RpckBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJqYXZhc2NyaXB0Ol9l KCU3QiU3RCwnY3ZtbCcsJ2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxsQHRvb2xz LmlldGYub3JnJyk7IiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLW9hdXRoLWpzb24td2Vi LXRva2VuLmFsbEB0b29scy5pZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZXZpZXcgb2Y6IGRy YWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW48bzpwPjwvbzpwPjwvcD4NCjxwPkknbSBhIGxp dHRsZSBjb25mdXNlZCBieSBzb21ldGhpbmcgaW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gKFNl Y3Rpb24gMik6PG86cD48L286cD48L3A+DQo8cD5QbGFpbnRleHQgSldUPG86cD48L286cD48L3A+ DQo8cD5BIEpXVCB3aG9zZSBDbGFpbXMgYXJlIG5vdCBpbnRlZ3JpdHkgcHJvdGVjdGVkIG9yIGVu Y3J5cHRlZC48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSB0ZXJtIHBsYWludGV4dCB0byBtZSBtZWFu cyBzb21ldGhpbmcgbGlrZSAmcXVvdDtpcyByZWFkYWJsZSB3aXRob3V0IGRlY3J5cHRpbmcgLyBt dWNoIGRlY29kaW5nJnF1b3Q7IChzb21ldGhpbmcgbGlrZSwgaWYgeW91IGNhdCB0aGUgZmlsZSB0 byBhIHRlcm1pbmFsLCB5b3Ugd2lsbCBzZWUgdGhlIGluZm9ybWF0aW9uKS4gSW50ZWdyaXR5IHBy b3RlY3RpbmcgYSBzdHJpbmcgZG9lc24ndCBtYWtlIGl0IG5vdCBlYXNpbHkgcmVhZGFibGUuIElm IHRoaXMgZG9jdW1lbnQNCiAvIEpPU0UgdXNlcyAmcXVvdDtwbGFpbnRleHQmcXVvdDsgZGlmZmVy ZW50bHkgKGFuZCBhIHF1aWNrIHNraW0gZGlkbid0IGZpbmQgYW55dGhpbmcgYWJvdXQ8bzpwPjwv bzpwPjwvcD4NCjxwPnRoaXMpIGl0IG1pZ2h0IGJlIGdvb2QgdG8gY2xhcmlmeS4gU2VjdGlvbiA2 ICpkb2VzKiBkaXNjdXNzIHBsYWludGV4dCBKV1RzLCBidXQgZG9lc24ndCByZWFsbHkgY2xhcmlm eSB0aGUgKElNTykgdW51c3VhbCBtZWFuaW5nIG9mIHRoZSB0ZXJtICZxdW90O3BsYWludGV4dCZx dW90OyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3 MEMwIj5J4oCZdmUgZGlzY3Vzc2VkIHRoaXMgd2l0aCB0aGUgb3RoZXIgZG9jdW1lbnQgZWRpdG9y cyBhbmQgd2UgYWdyZWUgd2l0aCB5b3UgdGhhdCDigJxwbGFpbnRleHTigJ0gaXMgbm90IHRoZSBt b3N0IGludHVpdGl2ZSB3b3JkaW5nIGNob2ljZSBpbiB0aGlzIGNvbnRleHQuJm5ic3A7IFBvc3Np YmxlIGFsdGVybmF0aXZlIHRlcm1zIGFyZSDigJxVbnNlY3VyZWQgSldU4oCdIG9yIOKAnFVuc2ln bmVkIEpXVOKAnS4mbmJzcDsgSSB0aGluayB0aGF0DQog4oCcVW5zZWN1cmVkIEpXVOKAnSBpcyBw cm9iYWJseSB0aGUgcHJlZmVycmVkIHRlcm0sIHNpbmNlIEpXVHMgdGhhdCBhcmUgSldFcyBhcmUg YWxzbyB1bnNpZ25lZCwgYnV0IHRoZXkgYXJlIHNlY3VyZWQuJm5ic3A7IFdvcmtpbmcgZ3JvdXAg 4oCTIGFyZSB5b3UgT0sgd2l0aCB0aGlzIHBvc3NpYmxlIHRlcm1pbm9sb2d5IGNoYW5nZT8mbmJz cDsgKE5vdGUgdGhhdCB0aGUgcGFyYWxsZWwgY2hhbmdlIOKAnFBsYWludGV4dCBKV1PigJ0gLSZn dDsg4oCcVW5zZWN1cmVkIEpXU+KAnSB3b3VsZCBhbHNvDQogYmUgbWFkZSBpbiB0aGUgSldTIHNw ZWMuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnam9zZUBpZXRmLm9yZycpOyIgdGFyZ2V0PSJf YmxhbmsiPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQotLSA8YnI+ DQpJIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2 aW91c2x5IGEgYmFkIGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLjxicj4NClRoaXMgaXMgbGlrZSBw dXR0aW5nIHJhYmlkIHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3Npbmcg cmVncmV0IGF0IGhhdmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFu ZCB0aGF0IHBhaXIgb2YgcGFudHMuPGJyPg0KJm5ic3A7ICZuYnNwOy0tLW1hZjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439B941EA6TK5EX14MBXC292r_-- From nobody Fri Sep 19 10:52:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9007D1A06DE for ; Fri, 19 Sep 2014 10:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 HFEjlLhCW8aa for ; Fri, 19 Sep 2014 10:52:28 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D15F1A06EA for ; Fri, 19 Sep 2014 10:52:26 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id em10so26352wid.5 for ; Fri, 19 Sep 2014 10:52:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=syzRxJQVugOMd8X3HV3sjS51G/vxJFIAAiNECguwOQ4=; b=Y+kKeTRKj5mtdAysJwugFuWju8Nt7PacEXcSKd7Vn6wPJ3stqH8nV60mHrlcHLwD7d wPU8zELDcB+gh1uHVRD4D1pxOp2+wJHLZxbWd3XUTYNPZBB/UVWihAXTGOvpO8IclWMx k3mPUsVtzNNRMDhuKzqLy8y877Ew6PJOO0t+hlQu9nZJwbCr7dqzH2xmwCBUrRpnN3N8 0tJ2SqMKVc/AjLKmwSp2MjMWkSDkwk/QNvXz8wML3k4PLSWCNlRgRZ/nXvxkzKm/yEtT o7ZUPon2ZATHsYK8t2oMrB803R9uLA1s9iTJAeWZHz6qvZGFN0PvordhjY16ccEYQzem fjeQ== X-Gm-Message-State: ALoCoQkvMQMD1fybq7xI9As48404H2/NwEc3BhgG/egZFxepfliN2R0l+X7tppVwnNdBO08k4g2u MIME-Version: 1.0 X-Received: by 10.194.86.34 with SMTP id m2mr2651710wjz.23.1411149144594; Fri, 19 Sep 2014 10:52:24 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Fri, 19 Sep 2014 10:52:24 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439B941EA6@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439B941EA6@TK5EX14MBXC292.redmond.corp.microsoft.com> Date: Fri, 19 Sep 2014 13:52:24 -0400 Message-ID: From: Warren Kumari To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fgFTeujBGCw6ZbImen4KBTjJz9I Cc: "secdir@ietf.org" , Richard Barnes , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , "jose@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 17:52:30 -0000 On Wed, Sep 17, 2014 at 12:40 PM, Mike Jones wrote: > Yes, this was already extensively discussed. It was covered in issue #36 > http://trac.tools.ietf.org/wg/jose/trac/ticket/36 and the related working > group e-mail thread. It was also a topic during multiple interim working > group calls. As noted by Karen O=E2=80=99Donoghue (one of the chairs) in= the issue > description =E2=80=9CNote: There was extensive discussion on the mailing = list, and > the rough consensus of the working group was to leave "none" in the > document.=E2=80=9D As part of the resolution agreed to by the working gr= oup, the > security considerations text at > https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#sectio= n-8.5 > was added. That seems to be mainly talking about the "alg": "none" / null cipher bit. I was specifically speaking to: 5.3. Replicating Claims as Header Parameters ..... This specification allows Claims present in the JWT Claims Set to be replicated as Header Parameters in a JWT that is a JWE, as needed by the application. If such replicated Claims are present, the application receiving them SHOULD verify that their values are identical, unless the application defines other specific processing rules for these Claims. It is the responsibility of the application to ensure that only claims that are safe to be transmitted in an unencrypted manner are replicated as Header Parameter values in the JWT. ..... Having the claims appear in 2 places seems like bad mojo - but, if this was discussed, and people are OK with it,... W > > > > -- Mike > > > > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Wednesday, September 17, 2014 4:40 AM > To: Richard Barnes > Cc: Brian Campbell; Mike Jones; > draft-ietf-oauth-json-web-token.all@tools.ietf.org; oauth@ietf.org; > jose@ietf.org; secdir@ietf.org > Subject: Re: alternative term to "plaintext" for the "none" alg (was Re: > [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token) > > > On Tuesday, September 16, 2014, Richard Barnes wrote: > > I will re-iterate here my strong preference that an "unsecured" or > "plaintext" JWS object be syntactically distinct from a real JWS object. > E.g. by having two dot-separated components instead of three. > > > > So, *I* was just grumping about the term used in the draft, but yes, thes= e > should (IMO, etc) be different. > > > > I'm also still uncomfortable about the "you can have the same information= in > the "secured" and "unsecured" section, but the secured one shold be trust= ed > more bit. This seems like it will end in fail. (Apologies if this was > already discussed and I missed it, and for rushed tone of mail, > traveling...) > > > > W > > > > > > Beyond that, seems like just shuffling deck chairs. > > > > On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell > wrote: > > cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA. > > > I agree that "plaintext=E2=80=9D is not the most intuitive wording choice= and that > "unsecured" might better convey what's going on with the "none" JWS > algorithm. > > Mike mentioned that, if this change is made in JWT, there are parallel > changes in JWS. But note that there are also such changes in JWA (more th= an > in JWS actually). > > > > On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones > wrote: > > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Monday, September 01, 2014 3:40 PM > To: secdir@ietf.org; draft-ietf-oauth-json-web-token.all@tools.ietf.org > Subject: Review of: draft-ietf-oauth-json-web-token > > I'm a little confused by something in the Terminology section (Section 2)= : > > Plaintext JWT > > A JWT whose Claims are not integrity protected or encrypted. > > The term plaintext to me means something like "is readable without > decrypting / much decoding" (something like, if you cat the file to a > terminal, you will see the information). Integrity protecting a string > doesn't make it not easily readable. If this document / JOSE uses > "plaintext" differently (and a quick skim didn't find anything about > > this) it might be good to clarify. Section 6 *does* discuss plaintext JWT= s, > but doesn't really clarify the (IMO) unusual meaning of the term "plainte= xt" > here. > > > > I=E2=80=99ve discussed this with the other document editors and we agree = with you > that =E2=80=9Cplaintext=E2=80=9D is not the most intuitive wording choice= in this context. > Possible alternative terms are =E2=80=9CUnsecured JWT=E2=80=9D or =E2=80= =9CUnsigned JWT=E2=80=9D. I think > that =E2=80=9CUnsecured JWT=E2=80=9D is probably the preferred term, sinc= e JWTs that are > JWEs are also unsigned, but they are secured. Working group =E2=80=93 ar= e you OK > with this possible terminology change? (Note that the parallel change > =E2=80=9CPlaintext JWS=E2=80=9D -> =E2=80=9CUnsecured JWS=E2=80=9D would = also be made in the JWS spec.) > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > > -- > I don't think the execution is relevant when it was obviously a bad idea = in > the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Sep 19 11:17:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BD01A069E; Fri, 19 Sep 2014 11:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 CKSVLjTH4ifC; Fri, 19 Sep 2014 11:17:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D631A064D; Fri, 19 Sep 2014 11:17:39 -0700 (PDT) Received: from BN3PR0301CA0078.namprd03.prod.outlook.com (25.160.152.174) by BL2PR03MB387.namprd03.prod.outlook.com (10.141.91.152) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Fri, 19 Sep 2014 18:17:37 +0000 Received: from BL2FFO11FD008.protection.gbl (2a01:111:f400:7c09::186) by BN3PR0301CA0078.outlook.office365.com (2a01:111:e400:401e::46) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Fri, 19 Sep 2014 18:17:36 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Fri, 19 Sep 2014 18:17:36 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Fri, 19 Sep 2014 18:16:54 +0000 From: Mike Jones To: Warren Kumari Thread-Topic: alternative term to "plaintext" for the "none" alg (was Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token) Thread-Index: AQHP0mwjMH5fKbfHa0qoJPYCQJJBhZwFhKbQgAM7cQCAAAYboA== Date: Fri, 19 Sep 2014 18:16:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA59B5E@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439B941EA6@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(24454002)(377454003)(51704005)(13464003)(189002)(2656002)(15975445006)(84676001)(54356999)(104016003)(99396002)(26826002)(15202345003)(74502003)(85852003)(80022003)(86362001)(19580405001)(77982003)(85306004)(87936001)(230783001)(19580395003)(92726001)(6806004)(15188555004)(81342003)(92566001)(74662003)(107046002)(93886004)(110136001)(68736004)(44976005)(55846006)(81156004)(79102003)(83322001)(66066001)(23676002)(21056001)(4396001)(20776003)(47776003)(33656002)(77096002)(69596002)(97736003)(95666004)(31966008)(83072002)(106466001)(90102001)(64706001)(85806002)(46102003)(76482002)(106116001)(86612001)(76176999)(50466002)(50986999)(81542003)(372894003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB387; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0339F89554 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/EpL3UwwRlmKZZtRF3xgh75aTwZ8 Cc: "secdir@ietf.org" , Richard Barnes , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , "jose@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:17:44 -0000 VGhpcyB3YXMgZGlzY3Vzc2VkIGluIHRoZSB0aHJlYWQgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTEzMTUuaHRtbCBhbmQgcHJpb3IgdG8gdGhh dCwgYXMgSk9TRSBpc3N1ZSAjMTcgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90 cmFjL3RpY2tldC8xNy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdhcnJl biBLdW1hcmkgW21haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldF0gDQpTZW50OiBGcmlkYXksIFNlcHRl bWJlciAxOSwgMjAxNCAxMDo1MiBBTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBSaWNoYXJkIEJhcm5l czsgQnJpYW4gQ2FtcGJlbGw7IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxsQHRv b2xzLmlldGYub3JnOyBvYXV0aEBpZXRmLm9yZzsgam9zZUBpZXRmLm9yZzsgc2VjZGlyQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogYWx0ZXJuYXRpdmUgdGVybSB0byAicGxhaW50ZXh0IiBmb3IgdGhl ICJub25lIiBhbGcgKHdhcyBSZTogW09BVVRILVdHXSBSZXZpZXcgb2Y6IGRyYWZ0LWlldGYtb2F1 dGgtanNvbi13ZWItdG9rZW4pDQoNCk9uIFdlZCwgU2VwIDE3LCAyMDE0IGF0IDEyOjQwIFBNLCBN aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiBZZXMsIHRo aXMgd2FzIGFscmVhZHkgZXh0ZW5zaXZlbHkgZGlzY3Vzc2VkLiAgSXQgd2FzIGNvdmVyZWQgaW4g aXNzdWUgDQo+ICMzNg0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMv dGlja2V0LzM2IGFuZCB0aGUgcmVsYXRlZCANCj4gd29ya2luZyBncm91cCBlLW1haWwgdGhyZWFk LiAgSXQgd2FzIGFsc28gYSB0b3BpYyBkdXJpbmcgbXVsdGlwbGUgDQo+IGludGVyaW0gd29ya2lu ZyBncm91cCBjYWxscy4gIEFzIG5vdGVkIGJ5IEthcmVuIE/igJlEb25vZ2h1ZSAob25lIG9mIHRo ZSANCj4gY2hhaXJzKSBpbiB0aGUgaXNzdWUgZGVzY3JpcHRpb24g4oCcTm90ZTogVGhlcmUgd2Fz IGV4dGVuc2l2ZSBkaXNjdXNzaW9uIA0KPiBvbiB0aGUgbWFpbGluZyBsaXN0LCBhbmQgdGhlIHJv dWdoIGNvbnNlbnN1cyBvZiB0aGUgd29ya2luZyBncm91cCB3YXMgDQo+IHRvIGxlYXZlICJub25l IiBpbiB0aGUgZG9jdW1lbnQu4oCdICBBcyBwYXJ0IG9mIHRoZSByZXNvbHV0aW9uIGFncmVlZCB0 byANCj4gYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0 ZXh0IGF0DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtcy0zMSNzZWMNCj4gdGlvbi04LjUNCj4gd2FzIGFkZGVkLg0KDQpUaGF0 IHNlZW1zIHRvIGJlIG1haW5seSB0YWxraW5nIGFib3V0IHRoZSAiYWxnIjogIm5vbmUiIC8gbnVs bCBjaXBoZXIgYml0Lg0KDQpJIHdhcyBzcGVjaWZpY2FsbHkgc3BlYWtpbmcgdG86DQoNCjUuMy4g IFJlcGxpY2F0aW5nIENsYWltcyBhcyBIZWFkZXIgUGFyYW1ldGVycw0KDQouLi4uLg0KDQogICBU aGlzIHNwZWNpZmljYXRpb24gYWxsb3dzIENsYWltcyBwcmVzZW50IGluIHRoZSBKV1QgQ2xhaW1z IFNldCB0byBiZQ0KICAgcmVwbGljYXRlZCBhcyBIZWFkZXIgUGFyYW1ldGVycyBpbiBhIEpXVCB0 aGF0IGlzIGEgSldFLCBhcyBuZWVkZWQgYnkNCiAgIHRoZSBhcHBsaWNhdGlvbi4gIElmIHN1Y2gg cmVwbGljYXRlZCBDbGFpbXMgYXJlIHByZXNlbnQsIHRoZQ0KICAgYXBwbGljYXRpb24gcmVjZWl2 aW5nIHRoZW0gU0hPVUxEIHZlcmlmeSB0aGF0IHRoZWlyIHZhbHVlcyBhcmUNCiAgIGlkZW50aWNh bCwgdW5sZXNzIHRoZSBhcHBsaWNhdGlvbiBkZWZpbmVzIG90aGVyIHNwZWNpZmljIHByb2Nlc3Np bmcNCiAgIHJ1bGVzIGZvciB0aGVzZSBDbGFpbXMuICBJdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkg b2YgdGhlIGFwcGxpY2F0aW9uDQogICB0byBlbnN1cmUgdGhhdCBvbmx5IGNsYWltcyB0aGF0IGFy ZSBzYWZlIHRvIGJlIHRyYW5zbWl0dGVkIGluIGFuDQogICB1bmVuY3J5cHRlZCBtYW5uZXIgYXJl IHJlcGxpY2F0ZWQgYXMgSGVhZGVyIFBhcmFtZXRlciB2YWx1ZXMgaW4gdGhlDQogICBKV1QuDQoN Ci4uLi4uDQoNCg0KSGF2aW5nIHRoZSBjbGFpbXMgYXBwZWFyIGluIDIgcGxhY2VzIHNlZW1zIGxp a2UgYmFkIG1vam8gLSBidXQsIGlmIHRoaXMgd2FzIGRpc2N1c3NlZCwgYW5kIHBlb3BsZSBhcmUg T0sgd2l0aCBpdCwuLi4NCg0KVw0KDQoNCg0KDQoNCg0KPg0KPg0KPg0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+ DQo+DQo+DQo+IEZyb206IFdhcnJlbiBLdW1hcmkgW21haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldF0N Cj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTcsIDIwMTQgNDo0MCBBTQ0KPiBUbzogUmlj aGFyZCBCYXJuZXMNCj4gQ2M6IEJyaWFuIENhbXBiZWxsOyBNaWtlIEpvbmVzOw0KPiBkcmFmdC1p ZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLmFsbEB0b29scy5pZXRmLm9yZzsgb2F1dGhAaWV0Zi5v cmc7IA0KPiBqb3NlQGlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IGFs dGVybmF0aXZlIHRlcm0gdG8gInBsYWludGV4dCIgZm9yIHRoZSAibm9uZSIgYWxnICh3YXMgUmU6 DQo+IFtPQVVUSC1XR10gUmV2aWV3IG9mOiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2Vu KQ0KPg0KPg0KPiBPbiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTYsIDIwMTQsIFJpY2hhcmQgQmFybmVz IDxybGJAaXB2LnN4PiB3cm90ZToNCj4NCj4gSSB3aWxsIHJlLWl0ZXJhdGUgaGVyZSBteSBzdHJv bmcgcHJlZmVyZW5jZSB0aGF0IGFuICJ1bnNlY3VyZWQiIG9yIA0KPiAicGxhaW50ZXh0IiBKV1Mg b2JqZWN0IGJlIHN5bnRhY3RpY2FsbHkgZGlzdGluY3QgZnJvbSBhIHJlYWwgSldTIG9iamVjdC4N Cj4gRS5nLiBieSBoYXZpbmcgdHdvIGRvdC1zZXBhcmF0ZWQgY29tcG9uZW50cyBpbnN0ZWFkIG9m IHRocmVlLg0KPg0KPg0KPg0KPiBTbywgKkkqIHdhcyBqdXN0IGdydW1waW5nIGFib3V0IHRoZSB0 ZXJtIHVzZWQgaW4gdGhlIGRyYWZ0LCBidXQgeWVzLCANCj4gdGhlc2Ugc2hvdWxkIChJTU8sIGV0 YykgYmUgZGlmZmVyZW50Lg0KPg0KPg0KPg0KPiBJJ20gYWxzbyBzdGlsbCB1bmNvbWZvcnRhYmxl IGFib3V0IHRoZSAieW91IGNhbiBoYXZlIHRoZSBzYW1lIA0KPiBpbmZvcm1hdGlvbiBpbiB0aGUg InNlY3VyZWQiIGFuZCAidW5zZWN1cmVkIiBzZWN0aW9uLCBidXQgdGhlIHNlY3VyZWQgDQo+IG9u ZSBzaG9sZCBiZSB0cnVzdGVkIG1vcmUgYml0LiBUaGlzIHNlZW1zIGxpa2UgaXQgd2lsbCBlbmQg aW4gZmFpbC4gDQo+IChBcG9sb2dpZXMgaWYgdGhpcyB3YXMgYWxyZWFkeSBkaXNjdXNzZWQgYW5k IEkgbWlzc2VkIGl0LCBhbmQgZm9yIA0KPiBydXNoZWQgdG9uZSBvZiBtYWlsLA0KPiB0cmF2ZWxp bmcuLi4pDQo+DQo+DQo+DQo+IFcNCj4NCj4NCj4NCj4NCj4NCj4gQmV5b25kIHRoYXQsIHNlZW1z IGxpa2UganVzdCBzaHVmZmxpbmcgZGVjayBjaGFpcnMuDQo+DQo+DQo+DQo+IE9uIE1vbiwgU2Vw IDgsIDIwMTQgYXQgMTI6MTAgUE0sIEJyaWFuIENhbXBiZWxsIA0KPiA8YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20+DQo+IHdyb3RlOg0KPg0KPiBjYydpbmcgSk9TRSBvbiBhIG1pbm9yIEpXVCBy ZXZpZXcgY29tbWVudCB0aGF0IG1pZ2h0IGltcGFjdCBKV1MvSldBLg0KPg0KPg0KPiBJIGFncmVl IHRoYXQgInBsYWludGV4dOKAnSBpcyBub3QgdGhlIG1vc3QgaW50dWl0aXZlIHdvcmRpbmcgY2hv aWNlIGFuZCANCj4gdGhhdCAidW5zZWN1cmVkIiBtaWdodCBiZXR0ZXIgY29udmV5IHdoYXQncyBn b2luZyBvbiB3aXRoIHRoZSAibm9uZSIgDQo+IEpXUyBhbGdvcml0aG0uDQo+DQo+IE1pa2UgbWVu dGlvbmVkIHRoYXQsIGlmIHRoaXMgY2hhbmdlIGlzIG1hZGUgaW4gSldULCB0aGVyZSBhcmUgcGFy YWxsZWwgDQo+IGNoYW5nZXMgaW4gSldTLiBCdXQgbm90ZSB0aGF0IHRoZXJlIGFyZSBhbHNvIHN1 Y2ggY2hhbmdlcyBpbiBKV0EgKG1vcmUgDQo+IHRoYW4gaW4gSldTIGFjdHVhbGx5KS4NCj4NCj4N Cj4NCj4gT24gRnJpLCBTZXAgNSwgMjAxNCBhdCA2OjI4IFBNLCBNaWtlIEpvbmVzIA0KPiA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KPiB3cm90ZToNCj4NCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogV2FycmVuIEt1bWFyaSBbbWFpbHRvOndhcnJlbkBrdW1hcmku bmV0XQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAwMSwgMjAxNCAzOjQwIFBNDQo+IFRvOiBz ZWNkaXJAaWV0Zi5vcmc7IA0KPiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLmFsbEB0 b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBSZXZpZXcgb2Y6IGRyYWZ0LWlldGYtb2F1dGgtanNv bi13ZWItdG9rZW4NCj4NCj4gSSdtIGEgbGl0dGxlIGNvbmZ1c2VkIGJ5IHNvbWV0aGluZyBpbiB0 aGUgVGVybWlub2xvZ3kgc2VjdGlvbiAoU2VjdGlvbiAyKToNCj4NCj4gUGxhaW50ZXh0IEpXVA0K Pg0KPiBBIEpXVCB3aG9zZSBDbGFpbXMgYXJlIG5vdCBpbnRlZ3JpdHkgcHJvdGVjdGVkIG9yIGVu Y3J5cHRlZC4NCj4NCj4gVGhlIHRlcm0gcGxhaW50ZXh0IHRvIG1lIG1lYW5zIHNvbWV0aGluZyBs aWtlICJpcyByZWFkYWJsZSB3aXRob3V0IA0KPiBkZWNyeXB0aW5nIC8gbXVjaCBkZWNvZGluZyIg KHNvbWV0aGluZyBsaWtlLCBpZiB5b3UgY2F0IHRoZSBmaWxlIHRvIGEgDQo+IHRlcm1pbmFsLCB5 b3Ugd2lsbCBzZWUgdGhlIGluZm9ybWF0aW9uKS4gSW50ZWdyaXR5IHByb3RlY3RpbmcgYSBzdHJp bmcgDQo+IGRvZXNuJ3QgbWFrZSBpdCBub3QgZWFzaWx5IHJlYWRhYmxlLiBJZiB0aGlzIGRvY3Vt ZW50IC8gSk9TRSB1c2VzIA0KPiAicGxhaW50ZXh0IiBkaWZmZXJlbnRseSAoYW5kIGEgcXVpY2sg c2tpbSBkaWRuJ3QgZmluZCBhbnl0aGluZyBhYm91dA0KPg0KPiB0aGlzKSBpdCBtaWdodCBiZSBn b29kIHRvIGNsYXJpZnkuIFNlY3Rpb24gNiAqZG9lcyogZGlzY3VzcyBwbGFpbnRleHQgDQo+IEpX VHMsIGJ1dCBkb2Vzbid0IHJlYWxseSBjbGFyaWZ5IHRoZSAoSU1PKSB1bnVzdWFsIG1lYW5pbmcg b2YgdGhlIHRlcm0gInBsYWludGV4dCINCj4gaGVyZS4NCj4NCj4NCj4NCj4gSeKAmXZlIGRpc2N1 c3NlZCB0aGlzIHdpdGggdGhlIG90aGVyIGRvY3VtZW50IGVkaXRvcnMgYW5kIHdlIGFncmVlIHdp dGggDQo+IHlvdSB0aGF0IOKAnHBsYWludGV4dOKAnSBpcyBub3QgdGhlIG1vc3QgaW50dWl0aXZl IHdvcmRpbmcgY2hvaWNlIGluIHRoaXMgY29udGV4dC4NCj4gUG9zc2libGUgYWx0ZXJuYXRpdmUg dGVybXMgYXJlIOKAnFVuc2VjdXJlZCBKV1TigJ0gb3Ig4oCcVW5zaWduZWQgSldU4oCdLiAgSSAN Cj4gdGhpbmsgdGhhdCDigJxVbnNlY3VyZWQgSldU4oCdIGlzIHByb2JhYmx5IHRoZSBwcmVmZXJy ZWQgdGVybSwgc2luY2UgSldUcyANCj4gdGhhdCBhcmUgSldFcyBhcmUgYWxzbyB1bnNpZ25lZCwg YnV0IHRoZXkgYXJlIHNlY3VyZWQuICBXb3JraW5nIGdyb3VwIA0KPiDigJMgYXJlIHlvdSBPSyB3 aXRoIHRoaXMgcG9zc2libGUgdGVybWlub2xvZ3kgY2hhbmdlPyAgKE5vdGUgdGhhdCB0aGUgDQo+ IHBhcmFsbGVsIGNoYW5nZSDigJxQbGFpbnRleHQgSldT4oCdIC0+IOKAnFVuc2VjdXJlZCBKV1Pi gJ0gd291bGQgYWxzbyBiZSBtYWRlIA0KPiBpbiB0aGUgSldTIHNwZWMuKQ0KPg0KPg0KPg0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBqb3Nl IG1haWxpbmcgbGlzdA0KPiBqb3NlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vam9zZQ0KPg0KPg0KPg0KPg0KPg0KPiAtLQ0KPiBJIGRvbid0IHRoaW5r IHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFkIA0K PiBpZGVhIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4gVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQg d2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyANCj4gcmVncmV0IGF0 IGhhdmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFuZCB0aGF0IHBh aXIgDQo+IG9mIHBhbnRzLg0KPiAgICAtLS1tYWYNCg0KDQoNCi0tDQpJIGRvbid0IHRoaW5rIHRo ZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFkIGlkZWEg aW4gdGhlIGZpcnN0IHBsYWNlLg0KVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2VscyBp biB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdyZXQgYXQgaGF2aW5nIGNob3Nl biB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpciBvZiBwYW50cy4N CiAgIC0tLW1hZg0K From nobody Tue Sep 23 15:46:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59D61A1BD3; Tue, 23 Sep 2014 15:46:44 -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] autolearn=ham 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 Cj8ZY2KQk4MI; Tue, 23 Sep 2014 15:46:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 501351A8908; Tue, 23 Sep 2014 15:46:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923224640.6154.50670.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 15:46:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jpoF1qnGxjohJhkXjwFOqLG7AzI Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-26.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 22:46:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-26.txt Pages : 33 Date : 2014-09-23 Abstract: JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The suggested pronunciation of JWT is the same as the English word "jot". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-26 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/ From nobody Tue Sep 23 15:52:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292851A889F for ; Tue, 23 Sep 2014 15:52:30 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 4gJ8Mya1SZV3 for ; Tue, 23 Sep 2014 15:52:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::713]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62521A1BD3 for ; Tue, 23 Sep 2014 15:52:27 -0700 (PDT) Received: from BY2PR03CA044.namprd03.prod.outlook.com (10.141.249.17) by DM2PR0301MB1215.namprd03.prod.outlook.com (25.160.219.16) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 22:52:12 +0000 Received: from BN1BFFO11FD034.protection.gbl (2a01:111:f400:7c10::1:131) by BY2PR03CA044.outlook.office365.com (2a01:111:e400:2c5d::17) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 22:52:04 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD034.mail.protection.outlook.com (10.58.144.97) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 22:52:03 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 22:51:39 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -32 and JWT -26 drafts addressing IETF Last Call comments Thread-Index: Ac/XgNa19S8xdv/2R86jWszcWuzHlwAABFbw Date: Tue, 23 Sep 2014 22:51:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6EB70@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA6EB70TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(199003)(377454003)(80022003)(87936001)(69596002)(68736004)(106466001)(85852003)(97736003)(85806002)(71186001)(2656002)(79102003)(16236675004)(4396001)(86612001)(19580405001)(99396002)(77096002)(81156004)(85306004)(19580395003)(95666004)(15975445006)(74502003)(54356999)(83322001)(512954002)(50986999)(83072002)(84676001)(81342003)(2501002)(92726001)(44976005)(19300405004)(66066001)(76482002)(92566001)(33656002)(21056001)(15202345003)(31966008)(2351001)(19625215002)(90102001)(104016003)(74662003)(77982003)(107046002)(81542003)(46102003)(16297215004)(6806004)(84326002)(55846006)(120916001)(86362001)(110136001)(10300001)(107886001)(19617315012)(64706001)(20776003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1215; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1215; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0343AC1D30 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xAb9lKC9XT0DeggjroUVhUE7trQ Subject: [OAUTH-WG] FW: JOSE -32 and JWT -26 drafts addressing IETF Last Call comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 22:52:30 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BA6EB70TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Mike Jones Sent: Tuesday, September 23, 2014 3:51 PM To: jose@ietf.org Cc: Russ Housley; 'Roni Even'; 'Tero Kivinen'; 'Scott Kelly'; 'Stephen Kent= '; 'Charlie Kaufman'; 'Warren Kumari'; 'Tom Yu'; gen-art@ietf.org; secdir@i= etf.org; ietf@ietf.org Subject: JOSE -32 and JWT -26 drafts addressing IETF Last Call comments New versions of the JSON Object Signing and Encryption (JOSE) and JSON Web = Token (JWT) specifications have been published incorporating feedback recei= ved in IETF Last Call comments. Thanks to Russ Housley and Roni Even for t= heir Gen-ART reviews, to Tero Kivinen, Scott Kelly, Stephen Kent, Charlie K= aufman, and Warren Kumari for their secdir reviews, to Tom Yu for his indiv= idual review, and to James Manger and Chuck Mortimore who provided feedback= based on deployment experiences, as well as to the many JOSE and OAuth wor= king group members who pitched in to discuss resolutions. Many clarificati= ons resulted. No breaking changes were made. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-32 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-32 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-32 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-26 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-3= 2.html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-= 32.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-32.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-= 32.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-26.h= tml -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1284 and a= s @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439BA6EB70TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Jon= es
Sent: Tuesday, September 23, 2014 3:51 PM
To: jose@ietf.org
Cc: Russ Housley; 'Roni Even'; 'Tero Kivinen'; 'Scott Kelly'; 'Steph= en Kent'; 'Charlie Kaufman'; 'Warren Kumari'; 'Tom Yu'; gen-art@ietf.org; s= ecdir@ietf.org; ietf@ietf.org
Subject: JOSE -32 and JWT -26 drafts addressing IETF Last Call comme= nts

 

New versions of the JSON Object Signing and Encrypti= on (JOSE) and JSON Web Token (JWT) specifications have been published incor= porating feedback received in IETF Last Call comments.  Thanks to Russ= Housley and Roni Even for their Gen-ART reviews, to Tero Kivinen, Scott Kelly, Stephen Kent, Charlie Kaufman, and = Warren Kumari for their secdir reviews, to Tom Yu for his individual review= , and to James Manger and Chuck Mortimore who provided feedback based on de= ployment experiences, as well as to the many JOSE and OAuth working group members who pitched in to discuss= resolutions.  Many clarifications resulted.  No breaking changes= were made.

 

The specifications are available at:

·         http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-32

·         http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-32

·         http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-32

·         http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-32

·         http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-26

 

HTML formatted versions are available at:=

·         http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-32.html

·         http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-32.html

·         http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-32.html

·         http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-32.html

·         http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-26.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

P.S. This notice was also posted at http://self-issued.info/?p=3D1284 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B16804296739439BA6EB70TK5EX14MBXC286r_-- From nobody Tue Sep 23 16:21:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554591A8972; Tue, 23 Sep 2014 16:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 koO6mDIK0foM; Tue, 23 Sep 2014 16:21:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDFE1A8973; Tue, 23 Sep 2014 16:21:08 -0700 (PDT) Received: from BN3PR0301CA0009.namprd03.prod.outlook.com (25.160.180.147) by DM2PR0301MB1216.namprd03.prod.outlook.com (25.160.219.17) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 23:21:07 +0000 Received: from BY2FFO11FD019.protection.gbl (2a01:111:f400:7c0c::132) by BN3PR0301CA0009.outlook.office365.com (2a01:111:e400:4000::19) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 23:21:06 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD019.mail.protection.outlook.com (10.1.14.107) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 23:21:05 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 23:20:33 +0000 From: Mike Jones To: Warren Kumari , "secdir@ietf.org" , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" Thread-Topic: Review of: draft-ietf-oauth-json-web-token Thread-Index: AQHPxjXHxo1AOZ59oEC2WFnyXP3ehZvzMhKQgBxLLKA= Date: Tue, 23 Sep 2014 23:20:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6F10C@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AE9DB28@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AE9DB28@TK5EX14MBXC292.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA6F10CTK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(13464003)(51444003)(377454003)(51914003)(199003)(189002)(95666004)(64706001)(77096002)(2656002)(87936001)(2201001)(92726001)(76176999)(46102003)(90102001)(76482002)(19300405004)(21056001)(85806002)(84326002)(106466001)(107046002)(86362001)(33656002)(83072002)(74662003)(230783001)(79102003)(81342003)(99396002)(85852003)(55846006)(92566001)(77982003)(80022003)(81156004)(81542003)(106116001)(512874002)(15202345003)(83322001)(15975445006)(66066001)(31966008)(71186001)(85306004)(15395725005)(16236675004)(4396001)(74502003)(20776003)(104016003)(120916001)(19580395003)(68736004)(54356999)(2501002)(50986999)(6806004)(19625215002)(19617315012)(84676001)(44976005)(19580405001)(69596002)(10300001)(97736003)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1216; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1216; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0343AC1D30 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/PBQco2WBVuQfdl-Pexrsiitlg20 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 23:21:13 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BA6F10CTK5EX14MBXC286r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldywgV2FycmVuLiAgVGhlIHJlc29sdXRpb25zIGRp c2N1c3NlZCBiZWxvdyBoYXZlIGJlZW4gYXBwbGllZCBpbiB0aGUgLTI2IGRyYWZ0Lg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwNSwgMjAx NCA1OjI4IFBNDQpUbzogV2FycmVuIEt1bWFyaTsgc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRm LW9hdXRoLWpzb24td2ViLXRva2VuLmFsbEB0b29scy5pZXRmLm9yZw0KQ2M6IG9hdXRoQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZXZpZXcgb2Y6IGRyYWZ0LWlldGYtb2F1dGgt anNvbi13ZWItdG9rZW4NCg0KDQpUaGFua3MgZm9yIHRoZSB1c2VmdWwgcmV2aWV3LCBXYXJyZW4u ICBJ4oCZbSBjY+KAmWluZyB0aGUgd29ya2luZyBncm91cCBzbyB0aGV54oCZcmUgYXdhcmUgb2Yg dGhlIGNvbnRlbnRzIG9mIHlvdXIgcmV2aWV3LiAgUmVwbGllcyBpbmxpbmUgYmVsb3figKYNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBXYXJyZW4gS3VtYXJpIFttYWls dG86d2FycmVuQGt1bWFyaS5uZXRdDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAwMSwgMjAxNCAz OjQwIFBNDQpUbzogc2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBkcmFm dC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJh ZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi5hbGxAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZXZpZXcgb2Y6IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4NCg0KDQoNCkJlIHll IG5vdCBhZnJhaWQgLS0gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0 aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElF VEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRz IHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBh cmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJl YXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMu DQoNCg0KDQpEaXNjbGFpbWVyOiBJIGtub3cgbmV4dCB0byBub3RoaW5nIGFib3V0IEpPU0UuIElu IHJlYWRpbmcgdGhpcyBkb2N1bWVudCBJIGFsc28gd2VudCBvZmYgYW5kIHJlYWQgc29tZSBvdGhl ciBKT1NFIHdvcmsgLyBXRyBkb2N1bWVudHMuDQoNClRoZSBtYWluIHRoaW5nIHRoYXQgSSBsZWFy bnQgd2FzIHRoYXQgdGhlbSB0aGFyIEpPU0UgZm9sayBzdXJlIGRvIGxpa2UgdGhlaXIgYWNyb255 bXMuLiA6LSkgTXkgdW5mYW1pbGlhcml0eSB3aXRoIEpPU0UgbWVhbnMgdGhhdCwgdW5saWtlIHdo YXQgdGhlIGFib3ZlIGJvaWxlcnBsYXRlIHNheXMsIHlvdSBzaG91bGQgdHJlYXQgdGhlc2UgbGVz cyBzZXJpb3VzbHkgdGhhbiBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzIQ0KDQoNCg0KU3Vt bWFyeToNCg0KTmVlZHMgc29tZSB3b3JrLCBub3RoaW5nIG1ham9yLg0KDQoNCg0KTm90ZXM6DQoN CkluIGEgbnVtYmVyIG9mIHBsYWNlcyB0aGUgZG9jdW1lbnQgc2F5cyB0aGluZ3MgbGlrZTogIklm IGFueSBvZiB0aGUgbGlzdGVkIHN0ZXBzIGZhaWxzIHRoZW4gdGhlIEpXVCBNVVNUIGJlIHJlamVj dGVkIGZvciBwcm9jZXNzaW5nLiIgLSBkb2VzIGl0IGFjdHVhbGx5ICptZWFuKiB0byByZWplY3Qg YSBKV1Q/IFdoYXQgc2hvdWxkIGFuIGFwcGxpY2F0aW9uIGRvIHdoZW4gaXQgcmVqZWN0cyBhIEpU VyAoeWVzLCBJIHJlYWxpemUgdGhhdCB0aGlzIGlzIHNvbWV3aGF0IGFwcGxpY2F0aW9uIHNwZWNp ZmljLCBidXQgYSBnZW5lcmFsICJFeHBsb2RlLCBraWxsaW5nIGV2ZXJ5Ym9keSBpbnNpZGUiIHZz ICJTaW1wbHkgcHJldGVuZCB5b3UgZGlkbid0IG5vdGljZSB0aGlzIiB3b3VsZCBiZSBoZWxwZnVs KS4NCg0KDQoNCkFzIHlvdSBwb2ludCBvdXQsIHdoYXQgaXQgbWVhbnMgdG8gcmVqZWN0IHRoZSBK V1MgaXMgYWN0dWFsbHkgYXBwbGljYXRpb24gc3BlY2lmaWMsIHNvIGl04oCZcyBub3QgY2xlYXIg d2hhdCBlbHNlIHRvIHNheSBpbiB0aGlzIHJlZ2FyZCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4gIEkg c3VwcG9zZSB0aGF0IHdlIGNvdWxkIHNheSB0aGF0IGl0IG11c3QgYmUgcmVqZWN0ZWQgYnkgdGhl IGFwcGxpY2F0aW9uIGFuZCBsZWF2ZSBpdCBhdCB0aGF0LiAgV291bGQgdGhhdCB3b3JrIGZvciB5 b3U/DQoNCg0KDQpJJ20gYSBsaXR0bGUgY29uZnVzZWQgYnkgc29tZXRoaW5nIGluIHRoZSBUZXJt aW5vbG9neSBzZWN0aW9uIChTZWN0aW9uIDIpOg0KDQpQbGFpbnRleHQgSldUDQoNCkEgSldUIHdo b3NlIENsYWltcyBhcmUgbm90IGludGVncml0eSBwcm90ZWN0ZWQgb3IgZW5jcnlwdGVkLg0KDQoN Cg0KVGhlIHRlcm0gcGxhaW50ZXh0IHRvIG1lIG1lYW5zIHNvbWV0aGluZyBsaWtlICJpcyByZWFk YWJsZSB3aXRob3V0IGRlY3J5cHRpbmcgLyBtdWNoIGRlY29kaW5nIiAoc29tZXRoaW5nIGxpa2Us IGlmIHlvdSBjYXQgdGhlIGZpbGUgdG8gYSB0ZXJtaW5hbCwgeW91IHdpbGwgc2VlIHRoZSBpbmZv cm1hdGlvbikuIEludGVncml0eSBwcm90ZWN0aW5nIGEgc3RyaW5nIGRvZXNuJ3QgbWFrZSBpdCBu b3QgZWFzaWx5IHJlYWRhYmxlLiBJZiB0aGlzIGRvY3VtZW50IC8gSk9TRSB1c2VzICJwbGFpbnRl eHQiIGRpZmZlcmVudGx5IChhbmQgYSBxdWljayBza2ltIGRpZG4ndCBmaW5kIGFueXRoaW5nIGFi b3V0DQoNCnRoaXMpIGl0IG1pZ2h0IGJlIGdvb2QgdG8gY2xhcmlmeS4gU2VjdGlvbiA2ICpkb2Vz KiBkaXNjdXNzIHBsYWludGV4dCBKV1RzLCBidXQgZG9lc24ndCByZWFsbHkgY2xhcmlmeSB0aGUg KElNTykgdW51c3VhbCBtZWFuaW5nIG9mIHRoZSB0ZXJtICJwbGFpbnRleHQiIGhlcmUuDQoNCg0K DQpJ4oCZdmUgZGlzY3Vzc2VkIHRoaXMgd2l0aCB0aGUgb3RoZXIgZG9jdW1lbnQgZWRpdG9ycyBh bmQgd2UgYWdyZWUgd2l0aCB5b3UgdGhhdCDigJxwbGFpbnRleHTigJ0gaXMgbm90IHRoZSBtb3N0 IGludHVpdGl2ZSB3b3JkaW5nIGNob2ljZSBpbiB0aGlzIGNvbnRleHQuICBQb3NzaWJsZSBhbHRl cm5hdGl2ZSB0ZXJtcyBhcmUg4oCcVW5zZWN1cmVkIEpXVOKAnSBvciDigJxVbnNpZ25lZCBKV1Ti gJ0uICBJIHRoaW5rIHRoYXQg4oCcVW5zZWN1cmVkIEpXVOKAnSBpcyBwcm9iYWJseSB0aGUgcHJl ZmVycmVkIHRlcm0sIHNpbmNlIEpXVHMgdGhhdCBhcmUgSldFcyBhcmUgYWxzbyB1bnNpZ25lZCwg YnV0IHRoZXkgYXJlIHNlY3VyZWQuICBXb3JraW5nIGdyb3VwIOKAkyBhcmUgeW91IE9LIHdpdGgg dGhpcyBwb3NzaWJsZSB0ZXJtaW5vbG9neSBjaGFuZ2U/ICAoTm90ZSB0aGF0IHRoZSBwYXJhbGxl bCBjaGFuZ2Ug4oCcUGxhaW50ZXh0IEpXU+KAnSAtPiDigJxVbnNlY3VyZWQgSldT4oCdIHdvdWxk IGFsc28gYmUgbWFkZSBpbiB0aGUgSldTIHNwZWMuKQ0KDQoNCg0KTUFDZWQgZG9lcyBub3Qgc2Vl bSB0byBiZSBhIHdlbGwga25vd24gdGVybSAtIHN1cnByaXNpbmdseSBlbm91Z2ggZXZlbiBNQUMg ZG9lc24ndCBoYXZlIGFuIGFzdGVyaXNrIGF0IGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3Jm Yy1zdHlsZS1ndWlkZS9hYmJyZXYuZXhwYW5zaW9uLnR4dA0KDQoNCg0KRG8geW91IGhhdmUgYW5v dGhlciBzdWdnZXN0aW9uIHRvIHJlcGxhY2Ug4oCcTUFDZWTigJ0gYW5kIOKAnE1BQ2luZ+KAnSwg b3RoZXIgdGhhbiB2ZXJib3NlIGZvcm11bGF0aW9ucyBsaWtlIOKAnHRoYXQgaGF2ZSBhIE1BQyBh cHBsaWVkIHRvIHRoZW3igJ0/ICBHaXZlbiB0aGF0IGluIEVuZ2xpc2ggdXNhZ2UgaXTigJlzIGNv bW1vbiB0byDigJx2ZXJiIGEgbm91buKAnSAoZS5nLiwgdXNhZ2Ugb2YgdGhlIHZlcmIg4oCcR29v Z2xl4oCdKSwgSSBkb27igJl0IHRoaW5rIHRoZXJl4oCZcyBhY3R1YWxseSBhbnkgYW1iaWd1aXR5 IGFzIHRvIHRoZSBpbnRlbmRlZCBtZWFuaW5nLg0KDQoNCg0KU2VjdGlvbiA0Og0KDQoiLi4uICBy ZWNpcGllbnRzIE1VU1QgZWl0aGVyIHJlamVjdCBKV1RzIHdpdGggZHVwbGljYXRlICBDbGFpbSBO YW1lcyBvciB1c2UgYSBKU09OIHBhcnNlciB0aGF0IHJldHVybnMgb25seSB0aGUgbGV4aWNhbGx5 IGxhc3QgIGR1cGxpY2F0ZSBtZW1iZXIgbmFtZS4uLiINCg0KDQoNClRoaXMgc29tZXdoYXQgbWFk ZSBtZSBpdGNoIC0gc29tZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCByZWplY3QgYSBnaXZlbiBKV1Qs IHNvbWUgd2lsbCBhY2NlcHQgaXQgLS0gSSBrbm93IHZlcnkgbGl0dGxlIGFib3V0IHBhcnNpbmcg SlNPTiwgYnV0IGNvdWxkIHlvdSBzdWdnZXN0IHdoaWNoIGFuIGltcGxlbWVudGF0aW9uIHNob3Vs ZCBwcmVmZXI/IENhbiBJIGluc3RydWN0IHN0YW5kYXJkIHBhcnNlcnMgdG8gZG8gWCBpbiB0aGlz IGNhc2U/DQoNCg0KDQpJIHVuZGVyc3RhbmQgdGhlIGl0Y2h5IGZlZWxpbmcuIOKYug0KDQoNCg0K VW5mb3J0dW5hdGVseSwgdGhlIGludGVudGlvbmFsIGxheG5lc3MgaW4gdGhlIHNwZWMgaW4gdGhp cyByZWdhcmQgaXMgYSByZWZsZWN0aW9uIG9mIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGFjdHVhbCBK U09OIHNwZWNpZmljYXRpb25zIGFuZCBpbXBsZW1lbnRhdGlvbnMuICBGb3IgaW5zdGFuY2UsIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxNTkjc2VjdGlvbi00IHNheXM6DQoNCg0KICAg QW4gb2JqZWN0IHdob3NlIG5hbWVzIGFyZSBhbGwgdW5pcXVlIGlzIGludGVyb3BlcmFibGUgaW4g dGhlIHNlbnNlDQogICB0aGF0IGFsbCBzb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbnMgcmVjZWl2aW5n IHRoYXQgb2JqZWN0IHdpbGwgYWdyZWUgb24NCiAgIHRoZSBuYW1lLXZhbHVlIG1hcHBpbmdzLiAg V2hlbiB0aGUgbmFtZXMgd2l0aGluIGFuIG9iamVjdCBhcmUgbm90DQogICB1bmlxdWUsIHRoZSBi ZWhhdmlvciBvZiBzb2Z0d2FyZSB0aGF0IHJlY2VpdmVzIHN1Y2ggYW4gb2JqZWN0IGlzDQogICB1 bnByZWRpY3RhYmxlLiAgTWFueSBpbXBsZW1lbnRhdGlvbnMgcmVwb3J0IHRoZSBsYXN0IG5hbWUv dmFsdWUgcGFpcg0KICAgb25seS4gIE90aGVyIGltcGxlbWVudGF0aW9ucyByZXBvcnQgYW4gZXJy b3Igb3IgZmFpbCB0byBwYXJzZSB0aGUNCiAgIG9iamVjdCwgYW5kIHNvbWUgaW1wbGVtZW50YXRp b25zIHJlcG9ydCBhbGwgb2YgdGhlIG5hbWUvdmFsdWUgcGFpcnMsDQogICBpbmNsdWRpbmcgZHVw bGljYXRlcy4NCg0KDQoNClRoaXMgdG9waWMgaGFzIGJlZW4gaGVhdmlseSBkaXNjdXNzZWQgYnkg dGhlIHdvcmtpbmcgZ3JvdXAsIGFuZCB3aGlsZSB0aGUgc3BlY3MgdXNlZCB0byBqdXN0IHNheSB0 aGF0IG9iamVjdHMgd2l0aCBkdXBsaWNhdGUgbWVtYmVyIG5hbWVzIE1VU1QgYmUgcmVqZWN0ZWQs IHdvcmtpbmcgZ3JvdXAgbWVtYmVycywgaW5jbHVkaW5nIFRpbSBCcmF5ICh0aGUgZWRpdG9yIG9m IHRoZSBKU09OIHNwZWMpLCBwcmV2YWlsZWQgb24gdXMgdG8gd2Vha2VuIHRoaXMgc28gdGhhdCBw YXJzZXJzIHRoYXQgaW1wbGVtZW50IHRoZSBFQ01Bc2NyaXB0IGJlaGF2aW9yIG9mIHJldHVybmlu ZyBvbmx5IHRoZSBsYXN0IG1lbWJlciBuYW1lIG1heSBiZSBsZWdhbGx5IHVzZWQuICAoVGhlIGFy Z3VtZW50IHdhcyBtYWRlIHRoYXQgdGhlcmUgd2FzIG1vcmUgc2VjdXJpdHkgZG93bnNpZGUgaW4g ZWZmZWN0aXZlbHkgcmVxdWlyaW5nIHBlb3BsZSB0byB3cml0ZSBhbmQgZGVidWcgdGhlaXIgb3du IHN0cmljdCBwYXJzZXJzIHRoYW4gaW4gdXNpbmcgbGF4ZXIsIGJ1dCB3ZWxsLXN1cHBvcnRlZCBh bmQgZGVidWdnZWQgcGFyc2Vycy4pDQoNCg0KDQpIb3dldmVyLCB3ZSBhbHNvIGludGVudGlvbmFs bHkgcmVxdWlyZSB0aGF0IHByb2R1Y2VycyB1c2Ugb25seSBvbmUgaW5zdGFuY2Ugb2YgZWFjaCBt ZW1iZXIgbmFtZSwgc28gdGhhdCBsZWdhbGx5IHByb2R1Y2VkIG9iamVjdHMgd2lsbCBuZXZlciBl eGVyY2lzZSB0aGUgYW1iaWd1aXRpZXMgdGhhdCBhcmUgcHJlc2VudCBpbiByZWFsIEpTT04gcGFy c2Vycy4gIFRoYXQgc2VlbWVkIHRvIGJlIHRoZSBtb3N0IHByYWN0aWNhbCBzb2x1dGlvbiB0byB0 aGUgd29ya2luZyBncm91cC4NCg0KDQoNClNlY3Rpb24gNC4xLjQuICJleHAiIChFeHBpcmF0aW9u IFRpbWUpIENsYWltIChhbmQgb3RoZXIgdGltZSBiYXNlZCBDbGFpbXM6DQoNCldoYXQgc2hvdWxk IG15IGJlaGF2aW9yIGJlIGlmIEkgc2ltcGx5IGRvbid0IGtub3cgd2hhdCB0aGUgdGltZSBpcz8N Cg0KKEknbSBqdXN0IGEgZHVtYiBkZXZpY2UsIGFuZCBteSBSVEMgaXMgY2xhaW1pbmcgaXQgaXMg SmFuMXN0LCAxOTcwKSAtIEknbSBhc3N1bWluZyBJIG11c3Qgbm90IHByb2Nlc3MgdGhpcyBKV1Q/ IERvZXMgdGhpcyBjcmVhdGUgYm9vdHN0cmFwcGluZyBpc3N1ZXM/DQoNCg0KDQpUaGUgdXNlIG9m IGFsbCBjbGFpbXMgaXMgb3B0aW9uYWwuICBJdOKAmXMgdXAgdG8gYXBwbGljYXRpb25zIHdoaWNo IG9uZXMgbWFrZSBzZW5zZSBmb3IgdGhlbSB0byB1c2UuICBJbiB1c2UgY2FzZXMgaW4gd2hpY2gg cGFydGljaXBhbnRzIGRvbuKAmXQga25vdyB0aGUgdGltZSwgZWl0aGVyIHRoaXMgY2xhaW0gd291 bGQgbm90IGJlIHVzZWQgYnkgdGhlIGFwcGxpY2F0aW9uIG9yIHRoZSBhcHBsaWNhdGlvbiB3b3Vs ZCBuZWVkIHRvIGRlZmluZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBiZWhhdmlvcnMgZm9yIHdoYXQg dG8gZG8gaW4gdGhvc2UgY2FzZXMuDQoNCg0KDQo1LjMuIFJlcGxpY2F0aW5nIENsYWltcyBhcyBI ZWFkZXIgUGFyYW1ldGVycyBUaGlzIHNlY3Rpb24gc2NhcmVzIG1lLCBhbmQgSSBob3BlIEknbSBz aW1wbHkgbm90IHVuZGVyc3RhbmRpbmcgd2hhdCBpcyBiZWluZyBwcm9wb3NlZC4gSWYgeW91IHNl bmQgdGhlIHVuZW5jcnlwdGVkIHZlcnNpb24gb2Ygc29tZSBlbmNyeXB0ZWQgQ2xhaW1zIHNvbWUg aW1wbGVtZW50YXRpb25zIHdpbGwgbWFrZSBpbXBvcnRhbnQgc2VjdXJpdHkgZGVjaXNpb25zIGJh c2VkIHVwb24gdGhvc2UgdW5lbmNyeXB0ZWQgY2xhaW1zLCBldmVuIGlmIHlvdSB0ZWxsIHRoZW0g aW4gYSBzZXJpb3VzIHZvaWNlIG5vdCB0by4gaHR0cDovL3hrY2QuY29tLzExODEvDQoNCg0KDQpG b3Igd2hhdCBpdOKAmXMgd29ydGgsIHRoZSBjb250ZXh0IGluIHdoaWNoIHRoaXMgYXJvc2Ugd2Fz IHdoZW4gYXBwbGljYXRpb24gdXNlZCBpbnRlcm1lZGlhdGUgc29mdHdhcmUgdGhhdCBpbnNwZWN0 ZWQgdGhlIGF1ZGllbmNlIG9mIGFuIGVuY3J5cHRlZCBKV1QgaW4gb3JkZXIgdG8gcm91dGUgaXQg dG8gdGhlIGNvcnJlY3QgcmVjaXBpZW50LiAgT25seSB0aGUgcmVjaXBpZW50IGhhcyB0aGUga2V5 IHRvIGRlY3J5cHQgdGhlIEpXVCBhbmQgbG9vayBhdCB0aGUgZW5jcnlwdGVkIGF1ZGllbmNlIHZh bHVlLiAgQnV0IGJ5IHBsYWNpbmcgYW4gdW5lbmNyeXB0ZWQgY29weSBvZiB0aGUgYXVkaWVuY2Ug aW4gdGhlIGhlYWRlciwgdGhlIHJvdXRpbmcgc29mdHdhcmUgY291bGQgaW5zcGVjdCBpdCBhbmQg cm91dGUgaXQgY29ycmVjdGx5LiAgVGhpcyBzZWVtZWQgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgbGlr ZSBhIGxlZ2l0aW1hdGUgdXNlIGNhc2UsIGFuZCBzbyB3ZSBkZWNpZGVkIHRvIHN1cHBvcnQgaXQu ICBUaGlzIGZlYXR1cmUgd2FzIHByb3Bvc2VkIGFuZCBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQ6 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEx MzE1Lmh0bWwuDQoNCg0KDQpBbHNvLCB0aGUgU0hPVUxEIGluICJJZiBzdWNoIHJlcGxpY2F0ZWQg Q2xhaW1zIGFyZSBwcmVzZW50LCB0aGUgYXBwbGljYXRpb24gcmVjZWl2aW5nIHRoZW0gU0hPVUxE IHZlcmlmeSB0aGF0IHRoZWlyIHZhbHVlcyBhcmUgaWRlbnRpY2FsLCAuLi4iIC0gd2h5IGlzIHRo aXMgbm90IGEgTVVTVD8gQW5kIGlmIGFuIGFwcGxpY2F0aW9uICpkb2VzKiBjb21wYXJlIHRoZW0g YW5kIHRoZXkgYXJlIG5vdCBpZGVudGljYWwsIHdoYXQgc2hvdWxkIGl0IGRvPyAgUGVyaGFwcyBh IG11Y2ggc3Ryb25nZXIganVzdGlmaWNhdGlvbiBmb3IgY2FycnlpbmcgMiBjb3BpZXMgb2YgdGhl IGRhdGEgaXMgaW4gb3JkZXIuDQoNCg0KDQpUaGUgdGV4dCByaWdodCBhZnRlciB0aGlzIGluIHRo ZSBzcGVjIGFscmVhZHkgYW5zd2VycyB0aGlzIHF1ZXN0aW9uOiDigJx1bmxlc3MgdGhlIGFwcGxp Y2F0aW9uIGRlZmluZXMgb3RoZXIgc3BlY2lmaWMgcHJvY2Vzc2luZyBydWxlcyBmb3IgdGhlc2Ug Q2xhaW1z4oCdLiAgSXTigJlzIGEg4oCcU0hPVUxE4oCdIGJlY2F1c2UgYXBwbGljYXRpb25zIG1p Z2h0IG5lZWQgdG8gZG8gdGhpcy4NCg0KDQoNCkVkaXRvcmlhbDoNCg0KVGhlIGludHJvIGlzIGFs bW9zdCBpZGVudGljYWwgdG8gdGhlIGFic3RyYWN0LiBNYWtpbmcgdGhlIGFic3RyYWN0IG1vcmUg YWJzdHJhY3QsIG9yIHRoZSBpbnRybyBtb3JlIGludHJvZHVjdG9yeSAoSSBoYXZlIG5vIGlkZWEg d2hhdCBtYW55IG9mIHRoZSBhY3JvbnltcyB3ZXJlISkgd291bGQgYmUgbmljZS4gU29tZXRoaW5n IHNob3J0IGV4cGxhaW5pbmcgd2hhdCBhIEpXVCBpcywgd2h5IEknZCBsaWtlIG9uZSx3aGF0IHRo ZXkgZ2V0IHVzZWQgZm9yLCB3aHkgSSBzaG91bGQga2VlcCByZWFkaW5nIHRoaXMgZG9jdW1lbnQg d291bGQgYmUgdmVyeSBoZWxwZnVsIC0gYmFzaWNhbGx5IGEgYmFja2dyb3VuZCB0eXBlIHNlY3Rp b24uLi4NCg0KDQoNClNwZWNpZmljIHdvcmRpbmcgc3VnZ2VzdGlvbnMgd291bGQgYmUgd2VsY29t ZWQuICBBcyBmb3Igbm90IGtub3dpbmcgd2hhdCB0aGUgYWNyb255bXMgYXJlLCBJ4oCZbSB0b2xk IHRoYXQgdGhlIHN0eWxlIGd1aWRlcyBkb27igJl0IGFsbG93IHJlZmVyZW5jZXMgdG8gYmUgcHV0 IGluIHRoZSBhYnN0cmFjdC4gIE90aGVyd2lzZSwgZm9yIGluc3RhbmNlLCB0aGVyZSB3b3VsZCBi ZSBhIHJlZmVyZW5jZSB0aGVyZSB0byBSRkMgNzE1OSBzbyBwZW9wbGUgd2hvIGRvbuKAmXQga25v dyB3aGF0IEpTT04gaXMga25vdyB3aGVyZSB0byBsb29rIHRvIGdvIGZpbmQgb3V0Lg0KDQoNCg0K Tml0czoNCg0KQWJzdHJhY3QNCg0KTzogaXMgYSBjb21wYWN0IFVSTC1zYWZlIG1lYW5zDQoNClA6 IGlzIGEgY29tcGFjdCwgVVJMLXNhZmUgbWVhbnMNCg0KDQoNClRoYW5rcw0KDQoNCg0KMy4gIEpT T04gV2ViIFRva2VuIChKV1QpIE92ZXJ2aWV3DQoNCk86IFRoZSBjb250ZW50cyBvZiB0aGUgSk9T RSBIZWFkZXIgZGVzY3JpYmUNCg0KUDogU3BlbGwgb3V0IEpPU0U7IGZpcnN0IHVzZSBpbiBkb2N1 bWVudCBhcyBmYXIgYXMgSSBjb3VsZCBzZWUNCg0KDQoNCkFjdHVhbGx5LCB0aGUgZmlyc3QgdXNl IG9mIHRoZSB0ZXJtIOKAnEpPU0UgSGVhZGVy4oCdIGlzIGluIFNlY3Rpb24gMiAoVGVybWlub2xv Z3kpLCB3aGVyZSBpdCBpcyBpbmNvcnBvcmF0ZWQgaW50byB0aGlzIHNwZWNpZmljYXRpb24gYnkg cmVmZXJlbmNlLg0KDQoNCg0KNS4yICJjdHkiIChDb250ZW50IFR5cGUpIEhlYWRlciBQYXJhbWV0 ZXINCg0KTzogbm9ybWFsIGNhc2Ugd2hlcmUgbmVzdGVkIHNpZ25pbmcNCg0KUDogbm9ybWFsIGNh c2UgaW4gd2hpY2ggbmVzdGVkIHNpZ25pbmcNCg0KDQoNClRoYW5rcw0KDQoNCg0KOC4gIEltcGxl bWVudGF0aW9uIFJlcXVpcmVtZW50cw0KDQpPOiBGb3IgaW5zdGFuY2UsIGFuIGFwcGxpY2F0aW9u IG1pZ2h0IHJlcXVpcmUgc3VwcG9ydA0KDQogICBmb3IgZW5jcnlwdGVkIEpXVHMgYW5kIE5lc3Rl ZCBKV1RzOyBhbm90aGVyIG1pZ2h0IHJlcXVpcmUgc3VwcG9ydA0KDQpQOiBGb3IgaW5zdGFuY2Us IG9uZSBhcHBsaWNhdGlvbiBtaWdodCByZXF1aXJlIHN1cHBvcnQgWy4uLl0sIHdoaWxlIGFub3Ro ZXIgbWlnaHQgcmVxdWlyZSBzdXBwb3J0IFsuLi5dDQoNCg0KDQpUaGFua3MNCg0KDQoNCjExLiBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQpPOiBUaGUgZW50aXJlIGxpc3Qgb2Ygc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgaXMgYmV5b25kIHRoZSBzY29wZSBvZg0KDQogICB0aGlzIGRvY3VtZW50 LCBidXQgc29tZSBzaWduaWZpY2FudCBjb25zaWRlcmF0aW9ucyBhcmUgbGlzdGVkIGhlcmUuDQoN ClA6IFRoZSBlbnRpcmUgbGlzdCBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpcyBiZXlvbmQg dGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNClI6IEEgZmV3IG9mIHRoZSBjb25zaWRlcmF0 aW9ucyBhcmUgYWxyZWFkeSBsaXN0ZWQgYWJvdmU7IHdlIGRvbid0IG5lZWQgdG8gcmVzdGF0ZSB0 aGF0IHRoZXkgYXJlIGxpc3RlZCBoZXJlIC0tIGFuZCBpZiB3ZSBkbywgdGhlIGFzc3VtcHRpb24g aXMgdGhhdCBzYWlkIGxpc3Qgd291bGQgZm9sbG93LCBub3QgYmUgYWJvdmUuDQoNCg0KDQpTZXZl cmFsIHJldmlld2VycyBoYXZlIG9iamVjdGVkIHRvIHRoaXMgc2VudGVuY2UuICBJdHMgcmVtb3Zh bCBpcyBwbGFubmVkLg0KDQoNCg0KMTEuMiBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIE9yZGVyDQoN Ck86IFdoaWxlIHN5bnRhY3RpY2FsbHksIHRoZSBzaWduaW5nIGFuZCBlbmNyeXB0aW9uIG9wZXJh dGlvbnMgZm9yIE5lc3RlZA0KDQogICBKV1RzIG1heSBiZSBhcHBsaWVkIGluIGFueSBvcmRlciwN Cg0KUDogV2hpbGUgc3ludGFjdGljYWxseSB0aGUgc2lnbmluZyBhbmQgZW5jcnlwdGlvbiBvcGVy YXRpb25zIGZvciBOZXN0ZWQNCg0KICAgSldUcyBtYXkgYmUgYXBwbGllZCBpbiBhbnkgb3JkZXIs DQoNCg0KDQpUaGFua3MNCg0KDQoNCi0tDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIGV4ZWN1dGlvbiBp cyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQgaWRlYSBpbiB0aGUgZmlyc3Qg cGxhY2UuDQoNClRoaXMgaXMgbGlrZSBwdXR0aW5nIHJhYmlkIHdlYXNlbHMgaW4geW91ciBwYW50 cywgYW5kIGxhdGVyIGV4cHJlc3NpbmcgcmVncmV0IGF0IGhhdmluZyBjaG9zZW4gdGhvc2UgcGFy dGljdWxhciByYWJpZCB3ZWFzZWxzIGFuZCB0aGF0IHBhaXIgb2YgcGFudHMuDQoNCiAgIC0tLW1h Zg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwgV2FycmVuLA0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739439BA6F10CTK5EX14MBXC286r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUy MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+VGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldywgV2FycmVuLiZuYnNwOyBUaGUgcmVzb2x1 dGlvbnMgZGlzY3Vzc2VkIGJlbG93IGhhdmUgYmVlbiBhcHBsaWVkIGluIHRoZSAtMjYgZHJhZnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIFNlcHRlbWJlciAwNSwgMjAxNCA1OjI4IFBNPGJyPg0KPGI+VG86PC9iPiBX YXJyZW4gS3VtYXJpOyBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWIt dG9rZW4uYWxsQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZXZpZXcgb2Y6IGRyYWZ0LWlldGYt b2F1dGgtanNvbi13ZWItdG9rZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VGhhbmtzIGZvciB0aGUg dXNlZnVsIHJldmlldywgV2FycmVuLiZuYnNwOyBJ4oCZbSBjY+KAmWluZyB0aGUgd29ya2luZyBn cm91cCBzbyB0aGV54oCZcmUgYXdhcmUgb2YgdGhlIGNvbnRlbnRzIG9mIHlvdXIgcmV2aWV3LiZu YnNwOyBSZXBsaWVzIGlubGluZSBiZWxvd+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFdhcnJlbiBLdW1hcmkgWzxhIGhyZWY9Im1haWx0bzp3 YXJyZW5Aa3VtYXJpLm5ldCI+bWFpbHRvOndhcnJlbkBrdW1hcmkubmV0PC9hPl0NCjxicj4NClNl bnQ6IE1vbmRheSwgU2VwdGVtYmVyIDAxLCAyMDE0IDM6NDAgUE08YnI+DQpUbzogPGEgaHJlZj0i bWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxsQHRvb2xzLmlldGYub3JnIj4N CmRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxsQHRvb2xzLmlldGYub3JnPC9hPjxi cj4NClN1YmplY3Q6IFJldmlldyBvZjogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZSB5ZSBub3QgYWZyYWlkIC0tIEkgaGF2ZSBy ZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl J3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9j ZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmlt YXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhDQogZGlyZWN0b3JzLiZu YnNwOyBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNv bW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5EaXNjbGFpbWVyOiBJIGtub3cgbmV4dCB0byBub3RoaW5nIGFi b3V0IEpPU0UuIEluIHJlYWRpbmcgdGhpcyBkb2N1bWVudCBJIGFsc28gd2VudCBvZmYgYW5kIHJl YWQgc29tZSBvdGhlciBKT1NFIHdvcmsgLyBXRyBkb2N1bWVudHMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgbWFpbiB0aGluZyB0aGF0IEkgbGVhcm50IHdhcyB0 aGF0IHRoZW0gdGhhciBKT1NFIGZvbGsgc3VyZSBkbyBsaWtlIHRoZWlyIGFjcm9ueW1zLi4gOi0p IE15IHVuZmFtaWxpYXJpdHkgd2l0aCBKT1NFIG1lYW5zIHRoYXQsIHVubGlrZSB3aGF0IHRoZSBh Ym92ZSBib2lsZXJwbGF0ZSBzYXlzLCB5b3Ugc2hvdWxkIHRyZWF0IHRoZXNlIGxlc3Mgc2VyaW91 c2x5IHRoYW4gYW55IG90aGVyIGxhc3QgY2FsbA0KIGNvbW1lbnRzITxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5TdW1tYXJ5OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+TmVlZHMgc29tZSB3b3JrLCBub3RoaW5nIG1ham9yLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Ob3Rlczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkluIGEgbnVtYmVyIG9mIHBsYWNlcyB0aGUgZG9jdW1lbnQgc2F5cyB0aGluZ3MgbGlrZTogJnF1 b3Q7SWYgYW55IG9mIHRoZSBsaXN0ZWQgc3RlcHMgZmFpbHMgdGhlbiB0aGUgSldUIE1VU1QgYmUg cmVqZWN0ZWQgZm9yIHByb2Nlc3NpbmcuJnF1b3Q7IC0gZG9lcyBpdCBhY3R1YWxseSAqbWVhbiog dG8gcmVqZWN0IGEgSldUPyBXaGF0IHNob3VsZCBhbiBhcHBsaWNhdGlvbiBkbyB3aGVuIGl0IHJl amVjdHMgYSBKVFcgKHllcywNCiBJIHJlYWxpemUgdGhhdCB0aGlzIGlzIHNvbWV3aGF0IGFwcGxp Y2F0aW9uIHNwZWNpZmljLCBidXQgYSBnZW5lcmFsICZxdW90O0V4cGxvZGUsIGtpbGxpbmcgZXZl cnlib2R5IGluc2lkZSZxdW90OyB2cyAmcXVvdDtTaW1wbHkgcHJldGVuZCB5b3UgZGlkbid0IG5v dGljZSB0aGlzJnF1b3Q7IHdvdWxkIGJlIGhlbHBmdWwpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+QXMgeW91IHBvaW50IG91dCwgd2hh dCBpdCBtZWFucyB0byByZWplY3QgdGhlIEpXUyBpcyBhY3R1YWxseSBhcHBsaWNhdGlvbiBzcGVj aWZpYywgc28gaXTigJlzIG5vdCBjbGVhciB3aGF0IGVsc2UgdG8gc2F5IGluIHRoaXMgcmVnYXJk IGluIHRoZSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBJIHN1cHBvc2UgdGhhdCB3ZSBjb3VsZCBzYXkg dGhhdCBpdCBtdXN0IGJlIHJlamVjdGVkDQogYnkgdGhlIGFwcGxpY2F0aW9uIGFuZCBsZWF2ZSBp dCBhdCB0aGF0LiZuYnNwOyBXb3VsZCB0aGF0IHdvcmsgZm9yIHlvdT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkknbSBhIGxpdHRsZSBjb25mdXNlZCBieSBzb21ldGhpbmcg aW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gKFNlY3Rpb24gMik6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QbGFpbnRleHQgSldUPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5BIEpXVCB3aG9zZSBDbGFpbXMgYXJlIG5vdCBpbnRlZ3JpdHkg cHJvdGVjdGVkIG9yIGVuY3J5cHRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhl IHRlcm0gcGxhaW50ZXh0IHRvIG1lIG1lYW5zIHNvbWV0aGluZyBsaWtlICZxdW90O2lzIHJlYWRh YmxlIHdpdGhvdXQgZGVjcnlwdGluZyAvIG11Y2ggZGVjb2RpbmcmcXVvdDsgKHNvbWV0aGluZyBs aWtlLCBpZiB5b3UgY2F0IHRoZSBmaWxlIHRvIGEgdGVybWluYWwsIHlvdSB3aWxsIHNlZSB0aGUg aW5mb3JtYXRpb24pLiBJbnRlZ3JpdHkgcHJvdGVjdGluZyBhIHN0cmluZyBkb2Vzbid0IG1ha2Ug aXQgbm90IGVhc2lseQ0KIHJlYWRhYmxlLiBJZiB0aGlzIGRvY3VtZW50IC8gSk9TRSB1c2VzICZx dW90O3BsYWludGV4dCZxdW90OyBkaWZmZXJlbnRseSAoYW5kIGEgcXVpY2sgc2tpbSBkaWRuJ3Qg ZmluZCBhbnl0aGluZyBhYm91dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+dGhpcykgaXQgbWlnaHQgYmUgZ29vZCB0byBjbGFyaWZ5LiBTZWN0aW9uIDYgKmRvZXMqIGRp c2N1c3MgcGxhaW50ZXh0IEpXVHMsIGJ1dCBkb2Vzbid0IHJlYWxseSBjbGFyaWZ5IHRoZSAoSU1P KSB1bnVzdWFsIG1lYW5pbmcgb2YgdGhlIHRlcm0gJnF1b3Q7cGxhaW50ZXh0JnF1b3Q7IGhlcmUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPknigJl2ZSBkaXNjdXNzZWQgdGhp cyB3aXRoIHRoZSBvdGhlciBkb2N1bWVudCBlZGl0b3JzIGFuZCB3ZSBhZ3JlZSB3aXRoIHlvdSB0 aGF0IOKAnHBsYWludGV4dOKAnSBpcyBub3QgdGhlIG1vc3QgaW50dWl0aXZlIHdvcmRpbmcgY2hv aWNlIGluIHRoaXMgY29udGV4dC4mbmJzcDsgUG9zc2libGUgYWx0ZXJuYXRpdmUgdGVybXMgYXJl IOKAnFVuc2VjdXJlZCBKV1TigJ0gb3Ig4oCcVW5zaWduZWQNCiBKV1TigJ0uJm5ic3A7IEkgdGhp bmsgdGhhdCDigJxVbnNlY3VyZWQgSldU4oCdIGlzIHByb2JhYmx5IHRoZSBwcmVmZXJyZWQgdGVy bSwgc2luY2UgSldUcyB0aGF0IGFyZSBKV0VzIGFyZSBhbHNvIHVuc2lnbmVkLCBidXQgdGhleSBh cmUgc2VjdXJlZC4mbmJzcDsgV29ya2luZyBncm91cCDigJMgYXJlIHlvdSBPSyB3aXRoIHRoaXMg cG9zc2libGUgdGVybWlub2xvZ3kgY2hhbmdlPyZuYnNwOyAoTm90ZSB0aGF0IHRoZSBwYXJhbGxl bCBjaGFuZ2Ug4oCcUGxhaW50ZXh0IEpXU+KAnSAtJmd0OyDigJxVbnNlY3VyZWQNCiBKV1PigJ0g d291bGQgYWxzbyBiZSBtYWRlIGluIHRoZSBKV1Mgc3BlYy4pPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1BQ2Vk IGRvZXMgbm90IHNlZW0gdG8gYmUgYSB3ZWxsIGtub3duIHRlcm0gLSBzdXJwcmlzaW5nbHkgZW5v dWdoIGV2ZW4gTUFDIGRvZXNuJ3QgaGF2ZSBhbiBhc3RlcmlzayBhdA0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLXN0eWxlLWd1aWRlL2FiYnJldi5leHBhbnNpb24udHh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0 cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLXN0eWxlLWd1aWRlL2FiYnJldi5leHBhbnNpb24u dHh0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+RG8geW91 IGhhdmUgYW5vdGhlciBzdWdnZXN0aW9uIHRvIHJlcGxhY2Ug4oCcTUFDZWTigJ0gYW5kIOKAnE1B Q2luZ+KAnSwgb3RoZXIgdGhhbiB2ZXJib3NlIGZvcm11bGF0aW9ucyBsaWtlIOKAnHRoYXQgaGF2 ZSBhIE1BQyBhcHBsaWVkIHRvIHRoZW3igJ0/Jm5ic3A7IEdpdmVuIHRoYXQgaW4gRW5nbGlzaCB1 c2FnZSBpdOKAmXMgY29tbW9uIHRvIOKAnHZlcmIgYSBub3Vu4oCdIChlLmcuLCB1c2FnZQ0KIG9m IHRoZSB2ZXJiIOKAnEdvb2dsZeKAnSksIEkgZG9u4oCZdCB0aGluayB0aGVyZeKAmXMgYWN0dWFs bHkgYW55IGFtYmlndWl0eSBhcyB0byB0aGUgaW50ZW5kZWQgbWVhbmluZy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAw NzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+U2VjdGlvbiA0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+JnF1 b3Q7Li4uJm5ic3A7IHJlY2lwaWVudHMgTVVTVCBlaXRoZXIgcmVqZWN0IEpXVHMgd2l0aCBkdXBs aWNhdGUmbmJzcDsgQ2xhaW0gTmFtZXMgb3IgdXNlIGEgSlNPTiBwYXJzZXIgdGhhdCByZXR1cm5z IG9ubHkgdGhlIGxleGljYWxseSBsYXN0Jm5ic3A7IGR1cGxpY2F0ZSBtZW1iZXIgbmFtZS4uLiZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIHNvbWV3aGF0IG1hZGUgbWUg aXRjaCAtIHNvbWUgaW1wbGVtZW50YXRpb25zIHdpbGwgcmVqZWN0IGEgZ2l2ZW4gSldULCBzb21l IHdpbGwgYWNjZXB0IGl0IC0tIEkga25vdyB2ZXJ5IGxpdHRsZSBhYm91dCBwYXJzaW5nIEpTT04s IGJ1dCBjb3VsZCB5b3Ugc3VnZ2VzdCB3aGljaCBhbiBpbXBsZW1lbnRhdGlvbiBzaG91bGQgcHJl ZmVyPyBDYW4gSSBpbnN0cnVjdCBzdGFuZGFyZCBwYXJzZXJzIHRvDQogZG8gWCBpbiB0aGlzIGNh c2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPkkgdW5kZXJzdGFuZCB0aGUg aXRjaHkgZmVlbGluZy4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rpbmdz O2NvbG9yOiMwMDcwQzAiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VW5mb3J0dW5hdGVseSwgdGhl IGludGVudGlvbmFsIGxheG5lc3MgaW4gdGhlIHNwZWMgaW4gdGhpcyByZWdhcmQgaXMgYSByZWZs ZWN0aW9uIG9mIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGFjdHVhbCBKU09OIHNwZWNpZmljYXRpb25z IGFuZCBpbXBsZW1lbnRhdGlvbnMuJm5ic3A7IEZvciBpbnN0YW5jZSwNCjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxNTkjc2VjdGlvbi00Ij5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3MTU5I3NlY3Rpb24tNDwvYT4gc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgQW4gb2JqZWN0IHdob3NlIG5hbWVzIGFyZSBhbGwgdW5pcXVlIGlzIGludGVyb3BlcmFibGUg aW4gdGhlIHNlbnNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgdGhhdCBhbGwgc29mdHdhcmUgaW1wbGVtZW50YXRpb25zIHJlY2VpdmluZyB0aGF0 IG9iamVjdCB3aWxsIGFncmVlIG9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIG5hbWUtdmFsdWUgbWFwcGluZ3MuJm5ic3A7IFdoZW4gdGhl IG5hbWVzIHdpdGhpbiBhbiBvYmplY3QgYXJlIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHVuaXF1ZSwgdGhlIGJlaGF2aW9yIG9mIHNvZnR3 YXJlIHRoYXQgcmVjZWl2ZXMgc3VjaCBhbiBvYmplY3QgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB1bnByZWRpY3RhYmxlLiZuYnNwOyBNYW55 IGltcGxlbWVudGF0aW9ucyByZXBvcnQgdGhlIGxhc3QgbmFtZS92YWx1ZSBwYWlyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgb25seS4mbmJzcDsg T3RoZXIgaW1wbGVtZW50YXRpb25zIHJlcG9ydCBhbiBlcnJvciBvciBmYWlsIHRvIHBhcnNlIHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG9i amVjdCwgYW5kIHNvbWUgaW1wbGVtZW50YXRpb25zIHJlcG9ydCBhbGwgb2YgdGhlIG5hbWUvdmFs dWUgcGFpcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgaW5jbHVkaW5nIGR1cGxpY2F0ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA3MEMwIj5UaGlzIHRvcGljIGhhcyBiZWVuIGhlYXZpbHkgZGlzY3Vzc2VkIGJ5IHRo ZSB3b3JraW5nIGdyb3VwLCBhbmQgd2hpbGUgdGhlIHNwZWNzIHVzZWQgdG8ganVzdCBzYXkgdGhh dCBvYmplY3RzIHdpdGggZHVwbGljYXRlIG1lbWJlciBuYW1lcyBNVVNUIGJlIHJlamVjdGVkLCB3 b3JraW5nIGdyb3VwIG1lbWJlcnMsIGluY2x1ZGluZyBUaW0gQnJheSAodGhlIGVkaXRvcg0KIG9m IHRoZSBKU09OIHNwZWMpLCBwcmV2YWlsZWQgb24gdXMgdG8gd2Vha2VuIHRoaXMgc28gdGhhdCBw YXJzZXJzIHRoYXQgaW1wbGVtZW50IHRoZSBFQ01Bc2NyaXB0IGJlaGF2aW9yIG9mIHJldHVybmlu ZyBvbmx5IHRoZSBsYXN0IG1lbWJlciBuYW1lIG1heSBiZSBsZWdhbGx5IHVzZWQuJm5ic3A7IChU aGUgYXJndW1lbnQgd2FzIG1hZGUgdGhhdCB0aGVyZSB3YXMgbW9yZSBzZWN1cml0eSBkb3duc2lk ZSBpbiBlZmZlY3RpdmVseSByZXF1aXJpbmcgcGVvcGxlDQogdG8gd3JpdGUgYW5kIGRlYnVnIHRo ZWlyIG93biBzdHJpY3QgcGFyc2VycyB0aGFuIGluIHVzaW5nIGxheGVyLCBidXQgd2VsbC1zdXBw b3J0ZWQgYW5kIGRlYnVnZ2VkIHBhcnNlcnMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+SG93ZXZlciwgd2UgYWxzbyBpbnRlbnRpb25hbGx5IHJlcXVpcmUgdGhh dCBwcm9kdWNlcnMgdXNlIG9ubHkgb25lIGluc3RhbmNlIG9mIGVhY2ggbWVtYmVyIG5hbWUsIHNv IHRoYXQgbGVnYWxseSBwcm9kdWNlZCBvYmplY3RzIHdpbGwgbmV2ZXIgZXhlcmNpc2UgdGhlIGFt YmlndWl0aWVzIHRoYXQgYXJlIHByZXNlbnQgaW4gcmVhbCBKU09OIHBhcnNlcnMuJm5ic3A7DQog VGhhdCBzZWVtZWQgdG8gYmUgdGhlIG1vc3QgcHJhY3RpY2FsIHNvbHV0aW9uIHRvIHRoZSB3b3Jr aW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VjdGlvbiA0LjEuNC4gJnF1b3Q7ZXhwJnF1b3Q7IChF eHBpcmF0aW9uIFRpbWUpIENsYWltIChhbmQgb3RoZXIgdGltZSBiYXNlZCBDbGFpbXM6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XaGF0IHNob3VsZCBteSBiZWhhdmlv ciBiZSBpZiBJIHNpbXBseSBkb24ndCBrbm93IHdoYXQgdGhlIHRpbWUgaXM/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oSSdtIGp1c3QgYSBkdW1iIGRldmljZSwgYW5k IG15IFJUQyBpcyBjbGFpbWluZyBpdCBpcyBKYW4xc3QsIDE5NzApIC0gSSdtIGFzc3VtaW5nIEkg bXVzdCBub3QgcHJvY2VzcyB0aGlzIEpXVD8gRG9lcyB0aGlzIGNyZWF0ZSBib290c3RyYXBwaW5n IGlzc3Vlcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VGhlIHVzZSBvZiBh bGwgY2xhaW1zIGlzIG9wdGlvbmFsLiAmbmJzcDtJdOKAmXMgdXAgdG8gYXBwbGljYXRpb25zIHdo aWNoIG9uZXMgbWFrZSBzZW5zZSBmb3IgdGhlbSB0byB1c2UuJm5ic3A7IEluIHVzZSBjYXNlcyBp biB3aGljaCBwYXJ0aWNpcGFudHMgZG9u4oCZdCBrbm93IHRoZSB0aW1lLCBlaXRoZXIgdGhpcyBj bGFpbSB3b3VsZCBub3QgYmUgdXNlZCBieSB0aGUgYXBwbGljYXRpb24NCiBvciB0aGUgYXBwbGlj YXRpb24gd291bGQgbmVlZCB0byBkZWZpbmUgYXBwbGljYXRpb24tc3BlY2lmaWMgYmVoYXZpb3Jz IGZvciB3aGF0IHRvIGRvIGluIHRob3NlIGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij41LjMuIFJlcGxp Y2F0aW5nIENsYWltcyBhcyBIZWFkZXIgUGFyYW1ldGVycyBUaGlzIHNlY3Rpb24gc2NhcmVzIG1l LCBhbmQgSSBob3BlIEknbSBzaW1wbHkgbm90IHVuZGVyc3RhbmRpbmcgd2hhdCBpcyBiZWluZyBw cm9wb3NlZC4gSWYgeW91IHNlbmQgdGhlIHVuZW5jcnlwdGVkIHZlcnNpb24gb2Ygc29tZSBlbmNy eXB0ZWQgQ2xhaW1zIHNvbWUgaW1wbGVtZW50YXRpb25zIHdpbGwgbWFrZSBpbXBvcnRhbnQNCiBz ZWN1cml0eSBkZWNpc2lvbnMgYmFzZWQgdXBvbiB0aG9zZSB1bmVuY3J5cHRlZCBjbGFpbXMsIGV2 ZW4gaWYgeW91IHRlbGwgdGhlbSBpbiBhIHNlcmlvdXMgdm9pY2Ugbm90IHRvLg0KPGEgaHJlZj0i aHR0cDovL3hrY2QuY29tLzExODEvIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3hrY2QuY29tLzExODEvPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3 MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Rm9yIHdoYXQgaXTigJlzIHdvcnRoLCB0aGUg Y29udGV4dCBpbiB3aGljaCB0aGlzIGFyb3NlIHdhcyB3aGVuIGFwcGxpY2F0aW9uIHVzZWQgaW50 ZXJtZWRpYXRlIHNvZnR3YXJlIHRoYXQgaW5zcGVjdGVkIHRoZSBhdWRpZW5jZSBvZiBhbiBlbmNy eXB0ZWQgSldUIGluIG9yZGVyIHRvIHJvdXRlIGl0IHRvIHRoZSBjb3JyZWN0IHJlY2lwaWVudC4m bmJzcDsgT25seSB0aGUNCiByZWNpcGllbnQgaGFzIHRoZSBrZXkgdG8gZGVjcnlwdCB0aGUgSldU IGFuZCBsb29rIGF0IHRoZSBlbmNyeXB0ZWQgYXVkaWVuY2UgdmFsdWUuJm5ic3A7IEJ1dCBieSBw bGFjaW5nIGFuIHVuZW5jcnlwdGVkIGNvcHkgb2YgdGhlIGF1ZGllbmNlIGluIHRoZSBoZWFkZXIs IHRoZSByb3V0aW5nIHNvZnR3YXJlIGNvdWxkIGluc3BlY3QgaXQgYW5kIHJvdXRlIGl0IGNvcnJl Y3RseS4mbmJzcDsgVGhpcyBzZWVtZWQgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgbGlrZSBhIGxlZ2l0 aW1hdGUNCiB1c2UgY2FzZSwgYW5kIHNvIHdlIGRlY2lkZWQgdG8gc3VwcG9ydCBpdC4mbmJzcDsg VGhpcyBmZWF0dXJlIHdhcyBwcm9wb3NlZCBhbmQgZGlzY3Vzc2VkIGluIHRoaXMgdGhyZWFkOg0K PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJl bnQvbXNnMTEzMTUuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29h dXRoL2N1cnJlbnQvbXNnMTEzMTUuaHRtbDwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFsc28sIHRoZSBT SE9VTEQgaW4gJnF1b3Q7SWYgc3VjaCByZXBsaWNhdGVkIENsYWltcyBhcmUgcHJlc2VudCwgdGhl IGFwcGxpY2F0aW9uIHJlY2VpdmluZyB0aGVtIFNIT1VMRCB2ZXJpZnkgdGhhdCB0aGVpciB2YWx1 ZXMgYXJlIGlkZW50aWNhbCwgLi4uJnF1b3Q7IC0gd2h5IGlzIHRoaXMgbm90IGEgTVVTVD8gQW5k IGlmIGFuIGFwcGxpY2F0aW9uICpkb2VzKiBjb21wYXJlIHRoZW0gYW5kIHRoZXkgYXJlIG5vdCBp ZGVudGljYWwsDQogd2hhdCBzaG91bGQgaXQgZG8/Jm5ic3A7IFBlcmhhcHMgYSBtdWNoIHN0cm9u Z2VyIGp1c3RpZmljYXRpb24gZm9yIGNhcnJ5aW5nIDIgY29waWVzIG9mIHRoZSBkYXRhIGlzIGlu IG9yZGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGUgdGV4dCByaWdo dCBhZnRlciB0aGlzIGluIHRoZSBzcGVjIGFscmVhZHkgYW5zd2VycyB0aGlzIHF1ZXN0aW9uOiDi gJx1bmxlc3MgdGhlIGFwcGxpY2F0aW9uIGRlZmluZXMgb3RoZXIgc3BlY2lmaWMgcHJvY2Vzc2lu ZyBydWxlcyBmb3IgdGhlc2UgQ2xhaW1z4oCdLiZuYnNwOyBJdOKAmXMgYSDigJxTSE9VTETigJ0g YmVjYXVzZSBhcHBsaWNhdGlvbnMgbWlnaHQgbmVlZCB0byBkbw0KIHRoaXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkVkaXRvcmlhbDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRo ZSBpbnRybyBpcyBhbG1vc3QgaWRlbnRpY2FsIHRvIHRoZSBhYnN0cmFjdC4gTWFraW5nIHRoZSBh YnN0cmFjdCBtb3JlIGFic3RyYWN0LCBvciB0aGUgaW50cm8gbW9yZSBpbnRyb2R1Y3RvcnkgKEkg aGF2ZSBubyBpZGVhIHdoYXQgbWFueSBvZiB0aGUgYWNyb255bXMgd2VyZSEpIHdvdWxkIGJlIG5p Y2UuIFNvbWV0aGluZyBzaG9ydCBleHBsYWluaW5nIHdoYXQgYSBKV1QgaXMsIHdoeSBJJ2QgbGlr ZSBvbmUsd2hhdA0KIHRoZXkgZ2V0IHVzZWQgZm9yLCB3aHkgSSBzaG91bGQga2VlcCByZWFkaW5n IHRoaXMgZG9jdW1lbnQgd291bGQgYmUgdmVyeSBoZWxwZnVsIC0gYmFzaWNhbGx5IGEgYmFja2dy b3VuZCB0eXBlIHNlY3Rpb24uLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+ U3BlY2lmaWMgd29yZGluZyBzdWdnZXN0aW9ucyB3b3VsZCBiZSB3ZWxjb21lZC4mbmJzcDsgQXMg Zm9yIG5vdCBrbm93aW5nIHdoYXQgdGhlIGFjcm9ueW1zIGFyZSwgSeKAmW0gdG9sZCB0aGF0IHRo ZSBzdHlsZSBndWlkZXMgZG9u4oCZdCBhbGxvdyByZWZlcmVuY2VzIHRvIGJlIHB1dCBpbiB0aGUg YWJzdHJhY3QuJm5ic3A7IE90aGVyd2lzZSwgZm9yIGluc3RhbmNlLCB0aGVyZSB3b3VsZA0KIGJl IGEgcmVmZXJlbmNlIHRoZXJlIHRvIFJGQyA3MTU5IHNvIHBlb3BsZSB3aG8gZG9u4oCZdCBrbm93 IHdoYXQgSlNPTiBpcyBrbm93IHdoZXJlIHRvIGxvb2sgdG8gZ28gZmluZCBvdXQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPk5pdHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BYnN0 cmFjdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TzogaXMgYSBjb21w YWN0IFVSTC1zYWZlIG1lYW5zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5QOiBpcyBhIGNvbXBhY3QsIFVSTC1zYWZlIG1lYW5zPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDcwQzAiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4zLiZuYnNwOyBKU09OIFdlYiBUb2tl biAoSldUKSBPdmVydmlldzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ TzogVGhlIGNvbnRlbnRzIG9mIHRoZSBKT1NFIEhlYWRlciBkZXNjcmliZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UDogU3BlbGwgb3V0IEpPU0U7IGZpcnN0IHVzZSBp biBkb2N1bWVudCBhcyBmYXIgYXMgSSBjb3VsZCBzZWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+QWN0dWFsbHksIHRoZSBmaXJzdCB1c2Ugb2YgdGhlIHRlcm0g4oCcSk9TRSBI ZWFkZXLigJ0gaXMgaW4gU2VjdGlvbiAyIChUZXJtaW5vbG9neSksIHdoZXJlIGl0IGlzIGluY29y cG9yYXRlZCBpbnRvIHRoaXMgc3BlY2lmaWNhdGlvbiBieSByZWZlcmVuY2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjUuMiAmcXVvdDtjdHkmcXVvdDsgKENvbnRlbnQgVHlwZSkgSGVhZGVyIFBhcmFtZXRlcjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Tzogbm9ybWFsIGNhc2Ugd2hl cmUgbmVzdGVkIHNpZ25pbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlA6IG5vcm1hbCBjYXNlIGluIHdoaWNoIG5lc3RlZCBzaWduaW5nPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij44LiZuYnNwOyBJbXBsZW1l bnRhdGlvbiBSZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPk86IEZvciBpbnN0YW5jZSwgYW4gYXBwbGljYXRpb24gbWlnaHQgcmVxdWlyZSBzdXBwb3J0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgZm9y IGVuY3J5cHRlZCBKV1RzIGFuZCBOZXN0ZWQgSldUczsgYW5vdGhlciBtaWdodCByZXF1aXJlIHN1 cHBvcnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlA6IEZvciBpbnN0 YW5jZSwgb25lIGFwcGxpY2F0aW9uIG1pZ2h0IHJlcXVpcmUgc3VwcG9ydCBbLi4uXSwgd2hpbGUg YW5vdGhlciBtaWdodCByZXF1aXJlIHN1cHBvcnQgWy4uLl08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjExLiBTZWN1cml0eSBDb25zaWRl cmF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TzogVGhlIGVu dGlyZSBsaXN0IG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzIGJleW9uZCB0aGUgc2NvcGUg b2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0 aGlzIGRvY3VtZW50LCBidXQgc29tZSBzaWduaWZpY2FudCBjb25zaWRlcmF0aW9ucyBhcmUgbGlz dGVkIGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QOiBUaGUg ZW50aXJlIGxpc3Qgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMgYmV5b25kIHRoZSBzY29w ZSBvZiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+UjogQSBmZXcgb2YgdGhlIGNvbnNpZGVyYXRpb25zIGFyZSBhbHJlYWR5IGxpc3RlZCBhYm92 ZTsgd2UgZG9uJ3QgbmVlZCB0byByZXN0YXRlIHRoYXQgdGhleSBhcmUgbGlzdGVkIGhlcmUgLS0g YW5kIGlmIHdlIGRvLCB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHNhaWQgbGlzdCB3b3VsZCBmb2xs b3csIG5vdCBiZSBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+U2V2 ZXJhbCByZXZpZXdlcnMgaGF2ZSBvYmplY3RlZCB0byB0aGlzIHNlbnRlbmNlLiZuYnNwOyBJdHMg cmVtb3ZhbCBpcyBwbGFubmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xMS4yIFNpZ25pbmcgYW5kIEVuY3J5 cHRpb24gT3JkZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk86IFdo aWxlIHN5bnRhY3RpY2FsbHksIHRoZSBzaWduaW5nIGFuZCBlbmNyeXB0aW9uIG9wZXJhdGlvbnMg Zm9yIE5lc3RlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IEpXVHMgbWF5IGJlIGFwcGxpZWQgaW4gYW55IG9yZGVyLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UDogV2hpbGUgc3ludGFjdGljYWxseSB0aGUgc2lnbmlu ZyBhbmQgZW5jcnlwdGlvbiBvcGVyYXRpb25zIGZvciBOZXN0ZWQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBKV1RzIG1heSBiZSBhcHBsaWVkIGlu IGFueSBvcmRlciw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VGhhbmtzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J IGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91 c2x5IGEgYmFkIGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2VscyBpbiB5 b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdyZXQgYXQgaGF2aW5nIGNob3NlbiB0 aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpciBvZiBwYW50cy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAtLS1tYWY8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhZ2FpbiwgV2FycmVuLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3 MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439BA6F10CTK5EX14MBXC286r_-- From nobody Tue Sep 23 16:26:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7CA1A6F2D; Tue, 23 Sep 2014 16:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QGRnj4O7EP9X; Tue, 23 Sep 2014 16:26:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::749]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C34E1A6F21; Tue, 23 Sep 2014 16:26:27 -0700 (PDT) Received: from BY2PR03CA062.namprd03.prod.outlook.com (10.141.249.35) by BY1PR0301MB1208.namprd03.prod.outlook.com (25.161.203.16) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 23:26:04 +0000 Received: from BN1AFFO11FD056.protection.gbl (2a01:111:f400:7c10::162) by BY2PR03CA062.outlook.office365.com (2a01:111:e400:2c5d::35) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 23:26:03 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD056.mail.protection.outlook.com (10.58.53.71) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 23:26:03 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 23:25:25 +0000 From: Mike Jones To: Warren Kumari Thread-Topic: alternative term to "plaintext" for the "none" alg (was Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token) Thread-Index: AQHP0mwjMH5fKbfHa0qoJPYCQJJBhZwFhKbQgAM7cQCAAAYboIAGoAqA Date: Tue, 23 Sep 2014 23:25:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6F1B0@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439B941EA6@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BA59B5E@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BA59B5E@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(13464003)(24454002)(199003)(69234005)(189002)(377454003)(85306004)(64706001)(15202345003)(74502003)(81342003)(74662003)(230783001)(2656002)(81542003)(50986999)(90102001)(92726001)(93886004)(86362001)(120916001)(33656002)(10300001)(23676002)(85852003)(46102003)(54356999)(97736003)(81156004)(87936001)(76176999)(66066001)(20776003)(21056001)(106466001)(83322001)(106116001)(15975445006)(76482002)(77096002)(95666004)(4396001)(84676001)(79102003)(99396002)(44976005)(68736004)(47776003)(83072002)(107046002)(55846006)(6806004)(86612001)(80022003)(19580395003)(85806002)(104016003)(77982003)(50466002)(31966008)(19580405001)(110136001)(92566001)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1208; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1208; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0343AC1D30 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/IFPTajJkCxeq-NEaqxy9JH6-9es Cc: "secdir@ietf.org" , Richard Barnes , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , "jose@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 23:26:33 -0000 RllJLCB0aGUgLTMyIGFuZCAtMjYgZHJhZnRzIG5vdyB1c2UgdGhlIHRlcm1zICJVbnNlY3VyZWQg SldTIiBhbmQgIlVuc2VjdXJlZCBKV1QiLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogam9zZSBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1p a2UgSm9uZXMNClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE5LCAyMDE0IDExOjE3IEFNDQpUbzog V2FycmVuIEt1bWFyaQ0KQ2M6IHNlY2RpckBpZXRmLm9yZzsgUmljaGFyZCBCYXJuZXM7IGRyYWZ0 LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxsQHRvb2xzLmlldGYub3JnOyBqb3NlQGlldGYu b3JnOyBCcmlhbiBDYW1wYmVsbDsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbam9zZV0g YWx0ZXJuYXRpdmUgdGVybSB0byAicGxhaW50ZXh0IiBmb3IgdGhlICJub25lIiBhbGcgKHdhcyBS ZTogW09BVVRILVdHXSBSZXZpZXcgb2Y6IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4p DQoNClRoaXMgd2FzIGRpc2N1c3NlZCBpbiB0aGUgdGhyZWFkIGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzExMzE1Lmh0bWwgYW5kIHByaW9yIHRv IHRoYXQsIGFzIEpPU0UgaXNzdWUgIzE3IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pv c2UvdHJhYy90aWNrZXQvMTcuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBX YXJyZW4gS3VtYXJpIFttYWlsdG86d2FycmVuQGt1bWFyaS5uZXRdDQpTZW50OiBGcmlkYXksIFNl cHRlbWJlciAxOSwgMjAxNCAxMDo1MiBBTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBSaWNoYXJkIEJh cm5lczsgQnJpYW4gQ2FtcGJlbGw7IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxs QHRvb2xzLmlldGYub3JnOyBvYXV0aEBpZXRmLm9yZzsgam9zZUBpZXRmLm9yZzsgc2VjZGlyQGll dGYub3JnDQpTdWJqZWN0OiBSZTogYWx0ZXJuYXRpdmUgdGVybSB0byAicGxhaW50ZXh0IiBmb3Ig dGhlICJub25lIiBhbGcgKHdhcyBSZTogW09BVVRILVdHXSBSZXZpZXcgb2Y6IGRyYWZ0LWlldGYt b2F1dGgtanNvbi13ZWItdG9rZW4pDQoNCk9uIFdlZCwgU2VwIDE3LCAyMDE0IGF0IDEyOjQwIFBN LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiBZZXMs IHRoaXMgd2FzIGFscmVhZHkgZXh0ZW5zaXZlbHkgZGlzY3Vzc2VkLiAgSXQgd2FzIGNvdmVyZWQg aW4gaXNzdWUNCj4gIzM2DQo+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJh Yy90aWNrZXQvMzYgYW5kIHRoZSByZWxhdGVkIA0KPiB3b3JraW5nIGdyb3VwIGUtbWFpbCB0aHJl YWQuICBJdCB3YXMgYWxzbyBhIHRvcGljIGR1cmluZyBtdWx0aXBsZSANCj4gaW50ZXJpbSB3b3Jr aW5nIGdyb3VwIGNhbGxzLiAgQXMgbm90ZWQgYnkgS2FyZW4gT+KAmURvbm9naHVlIChvbmUgb2Yg dGhlDQo+IGNoYWlycykgaW4gdGhlIGlzc3VlIGRlc2NyaXB0aW9uIOKAnE5vdGU6IFRoZXJlIHdh cyBleHRlbnNpdmUgZGlzY3Vzc2lvbiANCj4gb24gdGhlIG1haWxpbmcgbGlzdCwgYW5kIHRoZSBy b3VnaCBjb25zZW5zdXMgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgd2FzIA0KPiB0byBsZWF2ZSAibm9u ZSIgaW4gdGhlIGRvY3VtZW50LuKAnSAgQXMgcGFydCBvZiB0aGUgcmVzb2x1dGlvbiBhZ3JlZWQg dG8gDQo+IGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg dGV4dCBhdCANCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1hbGdvcml0aG1zLTMxI3NlYw0KPiB0aW9uLTguNQ0KPiB3YXMgYWRkZWQuDQoNClRo YXQgc2VlbXMgdG8gYmUgbWFpbmx5IHRhbGtpbmcgYWJvdXQgdGhlICJhbGciOiAibm9uZSIgLyBu dWxsIGNpcGhlciBiaXQuDQoNCkkgd2FzIHNwZWNpZmljYWxseSBzcGVha2luZyB0bzoNCg0KNS4z LiAgUmVwbGljYXRpbmcgQ2xhaW1zIGFzIEhlYWRlciBQYXJhbWV0ZXJzDQoNCi4uLi4uDQoNCiAg IFRoaXMgc3BlY2lmaWNhdGlvbiBhbGxvd3MgQ2xhaW1zIHByZXNlbnQgaW4gdGhlIEpXVCBDbGFp bXMgU2V0IHRvIGJlDQogICByZXBsaWNhdGVkIGFzIEhlYWRlciBQYXJhbWV0ZXJzIGluIGEgSldU IHRoYXQgaXMgYSBKV0UsIGFzIG5lZWRlZCBieQ0KICAgdGhlIGFwcGxpY2F0aW9uLiAgSWYgc3Vj aCByZXBsaWNhdGVkIENsYWltcyBhcmUgcHJlc2VudCwgdGhlDQogICBhcHBsaWNhdGlvbiByZWNl aXZpbmcgdGhlbSBTSE9VTEQgdmVyaWZ5IHRoYXQgdGhlaXIgdmFsdWVzIGFyZQ0KICAgaWRlbnRp Y2FsLCB1bmxlc3MgdGhlIGFwcGxpY2F0aW9uIGRlZmluZXMgb3RoZXIgc3BlY2lmaWMgcHJvY2Vz c2luZw0KICAgcnVsZXMgZm9yIHRoZXNlIENsYWltcy4gIEl0IGlzIHRoZSByZXNwb25zaWJpbGl0 eSBvZiB0aGUgYXBwbGljYXRpb24NCiAgIHRvIGVuc3VyZSB0aGF0IG9ubHkgY2xhaW1zIHRoYXQg YXJlIHNhZmUgdG8gYmUgdHJhbnNtaXR0ZWQgaW4gYW4NCiAgIHVuZW5jcnlwdGVkIG1hbm5lciBh cmUgcmVwbGljYXRlZCBhcyBIZWFkZXIgUGFyYW1ldGVyIHZhbHVlcyBpbiB0aGUNCiAgIEpXVC4N Cg0KLi4uLi4NCg0KDQpIYXZpbmcgdGhlIGNsYWltcyBhcHBlYXIgaW4gMiBwbGFjZXMgc2VlbXMg bGlrZSBiYWQgbW9qbyAtIGJ1dCwgaWYgdGhpcyB3YXMgZGlzY3Vzc2VkLCBhbmQgcGVvcGxlIGFy ZSBPSyB3aXRoIGl0LC4uLg0KDQpXDQoNCg0KDQoNCg0KDQo+DQo+DQo+DQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN Cj4NCj4NCj4NCj4gRnJvbTogV2FycmVuIEt1bWFyaSBbbWFpbHRvOndhcnJlbkBrdW1hcmkubmV0 XQ0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNywgMjAxNCA0OjQwIEFNDQo+IFRvOiBS aWNoYXJkIEJhcm5lcw0KPiBDYzogQnJpYW4gQ2FtcGJlbGw7IE1pa2UgSm9uZXM7DQo+IGRyYWZ0 LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxsQHRvb2xzLmlldGYub3JnOyBvYXV0aEBpZXRm Lm9yZzsgDQo+IGpvc2VAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog YWx0ZXJuYXRpdmUgdGVybSB0byAicGxhaW50ZXh0IiBmb3IgdGhlICJub25lIiBhbGcgKHdhcyBS ZToNCj4gW09BVVRILVdHXSBSZXZpZXcgb2Y6IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9r ZW4pDQo+DQo+DQo+IE9uIFR1ZXNkYXksIFNlcHRlbWJlciAxNiwgMjAxNCwgUmljaGFyZCBCYXJu ZXMgPHJsYkBpcHYuc3g+IHdyb3RlOg0KPg0KPiBJIHdpbGwgcmUtaXRlcmF0ZSBoZXJlIG15IHN0 cm9uZyBwcmVmZXJlbmNlIHRoYXQgYW4gInVuc2VjdXJlZCIgb3IgDQo+ICJwbGFpbnRleHQiIEpX UyBvYmplY3QgYmUgc3ludGFjdGljYWxseSBkaXN0aW5jdCBmcm9tIGEgcmVhbCBKV1Mgb2JqZWN0 Lg0KPiBFLmcuIGJ5IGhhdmluZyB0d28gZG90LXNlcGFyYXRlZCBjb21wb25lbnRzIGluc3RlYWQg b2YgdGhyZWUuDQo+DQo+DQo+DQo+IFNvLCAqSSogd2FzIGp1c3QgZ3J1bXBpbmcgYWJvdXQgdGhl IHRlcm0gdXNlZCBpbiB0aGUgZHJhZnQsIGJ1dCB5ZXMsIA0KPiB0aGVzZSBzaG91bGQgKElNTywg ZXRjKSBiZSBkaWZmZXJlbnQuDQo+DQo+DQo+DQo+IEknbSBhbHNvIHN0aWxsIHVuY29tZm9ydGFi bGUgYWJvdXQgdGhlICJ5b3UgY2FuIGhhdmUgdGhlIHNhbWUgDQo+IGluZm9ybWF0aW9uIGluIHRo ZSAic2VjdXJlZCIgYW5kICJ1bnNlY3VyZWQiIHNlY3Rpb24sIGJ1dCB0aGUgc2VjdXJlZCANCj4g b25lIHNob2xkIGJlIHRydXN0ZWQgbW9yZSBiaXQuIFRoaXMgc2VlbXMgbGlrZSBpdCB3aWxsIGVu ZCBpbiBmYWlsLg0KPiAoQXBvbG9naWVzIGlmIHRoaXMgd2FzIGFscmVhZHkgZGlzY3Vzc2VkIGFu ZCBJIG1pc3NlZCBpdCwgYW5kIGZvciANCj4gcnVzaGVkIHRvbmUgb2YgbWFpbCwNCj4gdHJhdmVs aW5nLi4uKQ0KPg0KPg0KPg0KPiBXDQo+DQo+DQo+DQo+DQo+DQo+IEJleW9uZCB0aGF0LCBzZWVt cyBsaWtlIGp1c3Qgc2h1ZmZsaW5nIGRlY2sgY2hhaXJzLg0KPg0KPg0KPg0KPiBPbiBNb24sIFNl cCA4LCAyMDE0IGF0IDEyOjEwIFBNLCBCcmlhbiBDYW1wYmVsbCANCj4gPGJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tPg0KPiB3cm90ZToNCj4NCj4gY2MnaW5nIEpPU0Ugb24gYSBtaW5vciBKV1Qg cmV2aWV3IGNvbW1lbnQgdGhhdCBtaWdodCBpbXBhY3QgSldTL0pXQS4NCj4NCj4NCj4gSSBhZ3Jl ZSB0aGF0ICJwbGFpbnRleHTigJ0gaXMgbm90IHRoZSBtb3N0IGludHVpdGl2ZSB3b3JkaW5nIGNo b2ljZSBhbmQgDQo+IHRoYXQgInVuc2VjdXJlZCIgbWlnaHQgYmV0dGVyIGNvbnZleSB3aGF0J3Mg Z29pbmcgb24gd2l0aCB0aGUgIm5vbmUiDQo+IEpXUyBhbGdvcml0aG0uDQo+DQo+IE1pa2UgbWVu dGlvbmVkIHRoYXQsIGlmIHRoaXMgY2hhbmdlIGlzIG1hZGUgaW4gSldULCB0aGVyZSBhcmUgcGFy YWxsZWwgDQo+IGNoYW5nZXMgaW4gSldTLiBCdXQgbm90ZSB0aGF0IHRoZXJlIGFyZSBhbHNvIHN1 Y2ggY2hhbmdlcyBpbiBKV0EgKG1vcmUgDQo+IHRoYW4gaW4gSldTIGFjdHVhbGx5KS4NCj4NCj4N Cj4NCj4gT24gRnJpLCBTZXAgNSwgMjAxNCBhdCA2OjI4IFBNLCBNaWtlIEpvbmVzIA0KPiA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KPiB3cm90ZToNCj4NCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogV2FycmVuIEt1bWFyaSBbbWFpbHRvOndhcnJlbkBrdW1hcmku bmV0XQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAwMSwgMjAxNCAzOjQwIFBNDQo+IFRvOiBz ZWNkaXJAaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4uYWxsQHRv b2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJldmlldyBvZjogZHJhZnQtaWV0Zi1vYXV0aC1qc29u LXdlYi10b2tlbg0KPg0KPiBJJ20gYSBsaXR0bGUgY29uZnVzZWQgYnkgc29tZXRoaW5nIGluIHRo ZSBUZXJtaW5vbG9neSBzZWN0aW9uIChTZWN0aW9uIDIpOg0KPg0KPiBQbGFpbnRleHQgSldUDQo+ DQo+IEEgSldUIHdob3NlIENsYWltcyBhcmUgbm90IGludGVncml0eSBwcm90ZWN0ZWQgb3IgZW5j cnlwdGVkLg0KPg0KPiBUaGUgdGVybSBwbGFpbnRleHQgdG8gbWUgbWVhbnMgc29tZXRoaW5nIGxp a2UgImlzIHJlYWRhYmxlIHdpdGhvdXQgDQo+IGRlY3J5cHRpbmcgLyBtdWNoIGRlY29kaW5nIiAo c29tZXRoaW5nIGxpa2UsIGlmIHlvdSBjYXQgdGhlIGZpbGUgdG8gYSANCj4gdGVybWluYWwsIHlv dSB3aWxsIHNlZSB0aGUgaW5mb3JtYXRpb24pLiBJbnRlZ3JpdHkgcHJvdGVjdGluZyBhIHN0cmlu ZyANCj4gZG9lc24ndCBtYWtlIGl0IG5vdCBlYXNpbHkgcmVhZGFibGUuIElmIHRoaXMgZG9jdW1l bnQgLyBKT1NFIHVzZXMgDQo+ICJwbGFpbnRleHQiIGRpZmZlcmVudGx5IChhbmQgYSBxdWljayBz a2ltIGRpZG4ndCBmaW5kIGFueXRoaW5nIGFib3V0DQo+DQo+IHRoaXMpIGl0IG1pZ2h0IGJlIGdv b2QgdG8gY2xhcmlmeS4gU2VjdGlvbiA2ICpkb2VzKiBkaXNjdXNzIHBsYWludGV4dCANCj4gSldU cywgYnV0IGRvZXNuJ3QgcmVhbGx5IGNsYXJpZnkgdGhlIChJTU8pIHVudXN1YWwgbWVhbmluZyBv ZiB0aGUgdGVybSAicGxhaW50ZXh0Ig0KPiBoZXJlLg0KPg0KPg0KPg0KPiBJ4oCZdmUgZGlzY3Vz c2VkIHRoaXMgd2l0aCB0aGUgb3RoZXIgZG9jdW1lbnQgZWRpdG9ycyBhbmQgd2UgYWdyZWUgd2l0 aCANCj4geW91IHRoYXQg4oCccGxhaW50ZXh04oCdIGlzIG5vdCB0aGUgbW9zdCBpbnR1aXRpdmUg d29yZGluZyBjaG9pY2UgaW4gdGhpcyBjb250ZXh0Lg0KPiBQb3NzaWJsZSBhbHRlcm5hdGl2ZSB0 ZXJtcyBhcmUg4oCcVW5zZWN1cmVkIEpXVOKAnSBvciDigJxVbnNpZ25lZCBKV1TigJ0uICBJIA0K PiB0aGluayB0aGF0IOKAnFVuc2VjdXJlZCBKV1TigJ0gaXMgcHJvYmFibHkgdGhlIHByZWZlcnJl ZCB0ZXJtLCBzaW5jZSBKV1RzIA0KPiB0aGF0IGFyZSBKV0VzIGFyZSBhbHNvIHVuc2lnbmVkLCBi dXQgdGhleSBhcmUgc2VjdXJlZC4gIFdvcmtpbmcgZ3JvdXAgDQo+IOKAkyBhcmUgeW91IE9LIHdp dGggdGhpcyBwb3NzaWJsZSB0ZXJtaW5vbG9neSBjaGFuZ2U/ICAoTm90ZSB0aGF0IHRoZSANCj4g cGFyYWxsZWwgY2hhbmdlIOKAnFBsYWludGV4dCBKV1PigJ0gLT4g4oCcVW5zZWN1cmVkIEpXU+KA nSB3b3VsZCBhbHNvIGJlIG1hZGUgDQo+IGluIHRoZSBKV1Mgc3BlYy4pDQo+DQo+DQo+DQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGpvc2Ug bWFpbGluZyBsaXN0DQo+IGpvc2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9qb3NlDQo+DQo+DQo+DQo+DQo+DQo+IC0tDQo+IEkgZG9uJ3QgdGhpbmsg dGhlIGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQgDQo+ IGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLg0KPiBUaGlzIGlzIGxpa2UgcHV0dGluZyByYWJpZCB3 ZWFzZWxzIGluIHlvdXIgcGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nIA0KPiByZWdyZXQgYXQg aGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFp ciANCj4gb2YgcGFudHMuDQo+ICAgIC0tLW1hZg0KDQoNCg0KLS0NCkkgZG9uJ3QgdGhpbmsgdGhl IGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQgaWRlYSBp biB0aGUgZmlyc3QgcGxhY2UuDQpUaGlzIGlzIGxpa2UgcHV0dGluZyByYWJpZCB3ZWFzZWxzIGlu IHlvdXIgcGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nIHJlZ3JldCBhdCBoYXZpbmcgY2hvc2Vu IHRob3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQgdGhhdCBwYWlyIG9mIHBhbnRzLg0K ICAgLS0tbWFmDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vam9zZQ0K From nobody Tue Sep 23 16:49:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07231A895D for ; Tue, 23 Sep 2014 16:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0UF9ps0OCSDk for ; Tue, 23 Sep 2014 16:49:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0E71A896B for ; Tue, 23 Sep 2014 16:49:02 -0700 (PDT) Received: from BN3PR0301CA0047.namprd03.prod.outlook.com (25.160.152.143) by BY1PR0301MB1208.namprd03.prod.outlook.com (25.161.203.16) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 23:49:00 +0000 Received: from BN1BFFO11FD018.protection.gbl (2a01:111:f400:7c10::1:186) by BN3PR0301CA0047.outlook.office365.com (2a01:111:e400:401e::15) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 23:48:59 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD018.mail.protection.outlook.com (10.58.144.81) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 23:48:59 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 23:48:26 +0000 From: Mike Jones To: Tom Yu Thread-Topic: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: draft-ietf-oauth-json-web-token-25.txt) Thread-Index: AQHPnILMO9QfoSuztEeIi1wIm35Xz5wP2HQA Date: Tue, 23 Sep 2014 23:48:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6F7BB@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20140704223838.27871.23006.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADA3843@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(377454003)(13464003)(199003)(52604005)(15975445006)(76482002)(77096002)(95666004)(84676001)(4396001)(20776003)(66066001)(97756001)(106466001)(106116001)(83322001)(21056001)(104016003)(31966008)(50466002)(69596002)(92566001)(19580405001)(77982003)(44976005)(99396002)(68736004)(79102003)(80022003)(86612001)(85806002)(19580395003)(83072002)(47776003)(6806004)(107046002)(55846006)(2171001)(2656002)(74662003)(230783001)(81542003)(81342003)(74502003)(86362001)(50986999)(90102001)(93886004)(92726001)(85306004)(15202345003)(46406003)(64706001)(54356999)(46102003)(85852003)(81156004)(76176999)(87936001)(97736003)(120916001)(23726002)(33656002)(10300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1208; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1208; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0343AC1D30 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/H-QR8vIJ0boPF0JtE6FGjfH6xBY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: draft-ietf-oauth-json-web-token-25.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 23:49:04 -0000 Thanks for bringing this issue to our attention Tom, and for proposing its = resolution. This refinement has been added to the -26 draft. -- Mike -----Original Message----- From: Tom Yu [mailto:tlyu@MIT.EDU]=20 Sent: Thursday, July 10, 2014 2:06 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action: dr= aft-ietf-oauth-json-web-token-25.txt) Mike Jones writes: > Thanks for pointing this out, Tom. I agree that we should use the POSIX = semantics. Other experts on the list - is there an RFC containing the appr= opriate definition, or should I just reference my old POSIX.1 spec (IEEE St= d 1003.1-1988)? Hi Mike, My reference for Seconds Since the Epoch in IEEE 1003.1-2013 is http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html= #tag_04_15 I believe there have been several technical and editorial corrections to th= at section of POSIX since 1988, so a more recent citation might be appropri= ate. As far as I know, there is no RFC containing a specification of the POSIX S= econds Since the Epoch definition. I think there is also no RFC that gives= general guidance on the handling of leap seconds when protocol time stamps= are represented as a number of seconds elapsed since some epoch. http://www.eecis.udel.edu/~mills/leap.html (and to some extent, RFC 5905) provides a description of what happens with leap seconds in NTP. RFC 7164 provides a useful and generally applicable contrast among behavior= s of official UTC, typical POSIX implementations, and NTP (even though the = nominal subject of the RFC is the interaction of leap seconds with RTP). > As for whether IntDate must be an integer, the normative text says "no". = It's defined as "a JSON numeric value", which allows the values to be non-= integers. The name "IntDate" is misleading in that way. I'll try to come = up with a better name for use in the next version of the spec. Thanks. RFC 7164 shows how there is additional ambiguity of time stamps at= the sub-second level. I suspect that this does not have significant conse= quences for most use cases of JWT. You might or might not want to mention = that there will be some ambiguities or anomalies in time stamps near leap s= econds, but that they will not have serious consequences for most applicati= ons. From nobody Thu Sep 25 23:23:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3691F1A1A26; Thu, 25 Sep 2014 23:23:12 -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] autolearn=ham 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 Cb1EH9JFAgpT; Thu, 25 Sep 2014 23:23:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 855551A1A3E; Thu, 25 Sep 2014 23:23:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140926062309.29849.42094.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 23:23:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uL8NREN1Imq3Pjbszj3HPQIfGGs Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-27.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 06:23:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-27.txt Pages : 33 Date : 2014-09-25 Abstract: JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The suggested pronunciation of JWT is the same as the English word "jot". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-27 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-27 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/