From nobody Tue Nov 1 09:41:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C591294BF for ; Tue, 1 Nov 2016 09:41:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUhJF8WqHC3W for ; Tue, 1 Nov 2016 09:41:38 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB8A1294DA for ; Tue, 1 Nov 2016 09:41:37 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id p190so216208424wmp.1 for ; Tue, 01 Nov 2016 09:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=k9Qe3We3RCkSN4EguQBwndc4qtKRmLFa2pxnG0ieEx0=; b=X2E4Jy5nnFcUSfWEqRE2BOPD8RcOMSWL4yGLQBRRejeQnhuOn54/GbwyVFw8AYThfv VuEFxZOGANOegqSAo+zMxOsH0y6S+5BFH5e28GRULUEPol0iMlk7J5km6Ae+a0p3Ivgb bYIHzdXAH117q6nGHIJ4/5BKRudS9KpOem1QacKvIULocfUbpl1ktn8TPKl+cYaXy0pM NVNL/oBKvz6MgCZPYrnRVIzIfy3quCoHWLdoc4cNUn9PMfm7jlI31tzpvxvSAENTLTmC m6N2slKFnIm7zGSaUzYuKV7TvKEYBpIpuz8N3O6JQOaGhF1vhqeZfLt9fLB5gsNu6uqu 958w== 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; bh=k9Qe3We3RCkSN4EguQBwndc4qtKRmLFa2pxnG0ieEx0=; b=QoBeEnB8z42Ad5Raw8mp0z/Zc8rCTvSC+CkSuqIAPXl01g9MZEg117FptMA1PduV7g zntT46pCxWJsFTaOeslQh6AT12ZNh39DDTvKdme/wd2TNdkf8MKviEB0HE+i9pkxfxLG 5wVlogHc3DUTrB203v7Iu8YLE+lqmF87K7bzCZWejM1TuH1U9Y8qUBTvGbG9Z1biJfke D5fDHgYxEneWd9uUXgXsNcyUGL9g2lCc8AJwwdq6DI7R8BEh1gsASONOJRdwbnv/oPU+ rLaQ7QpNPZRZXd1kcRrqn+nmMZmg4oteMPbPsNIdugW09qItOMt/Lt8o58k2/C//Yu2G 0mpQ== X-Gm-Message-State: ABUngvenFU6Woqn8Rh41Sua6RwpOOVce2u6Ut0qxA1J6VhrjccaFr6goHRDyTfe15UyDwKr2bIFMUzlk8z/jHg== X-Received: by 10.28.141.143 with SMTP id p137mr2224575wmd.5.1478018496457; Tue, 01 Nov 2016 09:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.172.232 with HTTP; Tue, 1 Nov 2016 09:41:36 -0700 (PDT) From: Samuel Erdtman Date: Tue, 1 Nov 2016 17:41:36 +0100 Message-ID: To: "" , William Denniss , John Bradley Content-Type: multipart/alternative; boundary=001a114717b6742ec405403fff93 Archived-At: Subject: [OAUTH-WG] Review of draft-ietf-oauth-native-apps-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 16:41:41 -0000 --001a114717b6742ec405403fff93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks for the great work of putting this together. I have a few comments on the current draft. See below Best Regards Samuel Erdtman 5. Using Inter-app URI Communication for OAuth The end of this section is a bit confusing with first a MUST statement and then a RECOMMENDED statement =E2=80=9CNative apps MUST use an external user-agent to perform OAuth=E2=80= =9D and =E2=80=9CThis best practice focuses on the browser as the RECOMMENDED exter= nal user-agent for native apps.=E2=80=9D 7.1.1. Custom URI Scheme Namespace Considerations =E2=80=9CFor example, an app that controls the domain name "app.example.com= " can use "com.example.app:/" as their custom scheme.=E2=80=9D drop the slash in the custom schema. 7.2. App-claimed HTTPS URI Redirection =E2=80=9CWhen the browser encounters a claimed URL, instead of the page being loaded in the browser, the native app is launched instead with the URL supplied as a launch parameter.=E2=80=9D drop one =E2=80=9Cinstead=E2=80=9D changing it to: =E2=80=9CWhen the browser encounters a claimed URL, instead of the page being loaded in the browser, the native app is launched with the URL supplied as a launch parameter.=E2=80=9D 7.2. App-claimed HTTPS URI Redirection If this is the recommended way to do it when possible maybe it should be first? 8.1. Embedded User-Agents =E2=80=9CEmbedded user-agents are an alternative method for authorization native apps.=E2=80=9D change to =E2=80=9CEmbedded user-agents are an alternative method to authorize native apps.=E2=80=9D or =E2=80=9CEmbedded user-agents are an alternative method for authorization of native apps.=E2=80=9D 8. Security Considerations I see normative language here (MUST, RECOMMENDED, SHOULD, etc.), and it felt a bit odd to me to have that under Security Considerations. Not sure if there are guidelines around that, but to me it would make sense to keep the normative parts out of Security Considerations. And it says =E2=80=9CConsiderations=E2=80=9D, to me that sounds mor like things to thin= k about then this is how it works. 8.2. Protecting the Authorization Code =E2=80=9CA limitation of using custom URI schemes for redirect URIs is that multiple apps can typically register the same scheme, which makes it indeterminate as to which app will receive the Authorization Code. PKCE [RFC7636] details how this limitation can be used to execute a code interception attack (see Figure 1). Loopback IP based redirect URIs may be susceptible to interception by other apps listening on the same loopback interface.=E2=80=9D I think it would be preferable to separate custom URI and Loopback IP based redirect. 8.2. Protecting the Authorization Code =E2=80=9CLoopback IP based redirect URIs may be susceptible to interception by other apps listening on the same loopback interface.=E2=80=9D Are you referring to an application listening to loopback traffic or an application killing the original application and start listening on the same port. The second alternative would be relatively intrusive and notable= . Appendix A. Server Support Checklist 1. Support custom URI-scheme redirect URIs. I could not see that this was required in section Section 7.1. Appendix A. Server Support Checklist 5. Support PKCE. in Section 8.2 it says MUST =E2=80=9CAuthorization servers MUST support PKCE [RFC7636] for public native app clients.=E2=80=9D --001a114717b6742ec405403fff93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the great work = of putting this together. I have a few comments on the current draft. See b= elow

Best Regards
Samuel Erdtman


5.=C2=A0 Using Inter-app URI Communication for OAuth
The end of thi= s section is a bit confusing with first a MUST statement and then a RECOMME= NDED statement
=E2=80=9CNative apps MUST use an external user-agent to p= erform OAuth=E2=80=9D
and
=E2=80=9CThis best practice focuses on the = browser as the RECOMMENDED external
=C2=A0=C2=A0 user-agent for native a= pps.=E2=80=9D


7.1.1.=C2=A0 Custom URI Scheme Namespace Considera= tions
=E2=80=9CFor example, an app that controls the domain name "<= a href=3D"http://app.example.com">app.example.com"
=C2=A0=C2=A0= can use "com.example.app:/" as their custom scheme.=E2=80=9D
= drop the slash in the custom schema.


7.2.=C2=A0 App-claimed HTTP= S URI Redirection
=E2=80=9CWhen the browser encounters a claimed URL, in= stead of the
=C2=A0=C2=A0 page being loaded in the browser, the native a= pp is launched instead
=C2=A0=C2=A0 with the URL supplied as a launch pa= rameter.=E2=80=9D
drop one =E2=80=9Cinstead=E2=80=9D changing it to:
= =E2=80=9CWhen the browser encounters a claimed URL, instead of the
=C2= =A0=C2=A0 page being loaded in the browser, the native app is launched
= =C2=A0=C2=A0 with the URL supplied as a launch parameter.=E2=80=9D

<= br>7.2.=C2=A0 App-claimed HTTPS URI Redirection
If this is the recommend= ed way to do it when possible maybe it should be first?


8.1.=C2= =A0 Embedded User-Agents
=E2=80=9CEmbedded user-agents are an alternativ= e method for authorization
=C2=A0=C2=A0 native apps.=E2=80=9D
change = to
=E2=80=9CEmbedded user-agents are an alternative method to authorize<= br>=C2=A0=C2=A0 native apps.=E2=80=9D
or
=E2=80=9CEmbedded user-agent= s are an alternative method for authorization
=C2=A0=C2=A0 of native app= s.=E2=80=9D


8.=C2=A0 Security Considerations
I see normative = language here (MUST, RECOMMENDED, SHOULD, etc.), and it felt a bit odd to m= e to have that under Security Considerations. Not sure if there are guideli= nes around that, but to me it would make sense to keep the normative parts = out of Security Considerations. And it says =E2=80=9CConsiderations=E2=80= =9D, to me that sounds mor like things to think about then this is how it w= orks.


8.2.=C2=A0 Protecting the Authorization Code

=E2=80= =9CA limitation of using custom URI schemes for redirect URIs is that
= =C2=A0=C2=A0 multiple apps can typically register the same scheme, which ma= kes it
=C2=A0=C2=A0 indeterminate as to which app will receive the Autho= rization Code.
=C2=A0=C2=A0 PKCE [RFC7636] details how this limitation c= an be used to execute a
=C2=A0=C2=A0 code interception attack (see Figur= e 1).=C2=A0 Loopback IP based redirect
=C2=A0=C2=A0 URIs may be suscepti= ble to interception by other apps listening on
=C2=A0=C2=A0 the same loo= pback interface.=E2=80=9D

I think it would be preferable to separate= custom URI and Loopback IP based redirect.


8.2.=C2=A0 Protecti= ng the Authorization Code
=E2=80=9CLoopback IP based redirect
=C2=A0= =C2=A0 URIs may be susceptible to interception by other apps listening on=C2=A0=C2=A0 the same loopback interface.=E2=80=9D
Are you referring t= o an application listening to loopback traffic or an application killing th= e original application and start listening on the same port. The second alt= ernative would be relatively intrusive and notable.


Appendix A.= =C2=A0 Server Support Checklist
1.=C2=A0 Support custom URI-scheme redir= ect URIs.
I could not see that this was required in section Section 7.1= .


Appendix A.=C2=A0 Server Support Checklist
5.=C2=A0 Support= PKCE.
in Section 8.2 it says MUST
=E2=80=9CAuthorization servers MUS= T support PKCE [RFC7636]
=C2=A0=C2=A0 for public native app clients.=E2= =80=9D





--001a114717b6742ec405403fff93-- From nobody Tue Nov 1 11:02:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31A11296FA for ; Tue, 1 Nov 2016 11:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQKo0kthk3tX for ; Tue, 1 Nov 2016 11:02:19 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419911296BA for ; Tue, 1 Nov 2016 11:02:19 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l124so48445702ywb.3 for ; Tue, 01 Nov 2016 11:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yzbTdgMfQ3O6+1QL4qhNhSzAfhCUbi7pjof5Qktfrr4=; b=SUzaACJMorTb5GzW35PvHROC4EwD2ID5afFKevHiYfv+e5VbFN+IQG4cOoGRyQWYsU wPh0EudW9j5zG63V0zZptv8MCjRnOYzNrsidm8eKm3QGabpZFDL0b97fDGpBWjYEh7D5 /3bTfJ0DImtOUmvR0wzr7ZUKZLkDgHGCsF205gce9gOJ0Lwj6TbkUCxc29Mt0vvJOTyw NGgXPdhkbRZCsWxeS/iFmpIBLv0i+FlzB1SfJAEQnGg5PKeezRJ4HAxpRp1g9FwjdyBS CDDODL3x4pRPsltYOj3KkO5zy2uWCokZ9ckls5xByxgP1ZVhFoNxQ/QQRWDST8NEgLyh MuYA== 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; bh=yzbTdgMfQ3O6+1QL4qhNhSzAfhCUbi7pjof5Qktfrr4=; b=JCmtTpqwbYavrHE/GwE5G/v43qzbl486G4v81aJ/NEk3hhdQ8saV9dUBosWsqiABWr 1EyLK+d988RC9zHkeOTHqAS0CjZygD9sQEcBZEM+pm+3zWqLborD1WkPnBeqzjcs4LfA mSt2+c/ecmS9QMkCpAJjjWLo+g/dIoT82r4nROYh0Dzw9nBgrglKFHO4gdW84b3tVWE4 +/211phLTnFykjD2JekhkODfW/5pR1k8mamvdCzIR+nywXOiKldZ4DecCXsZKJiJigCz Qwl+1tXq1frywBMctoiwS2y4dz/XUKmDg8ZFDUEWNWtnGJZuiocTZfJOlYH0TtRgrX0Z gAgA== X-Gm-Message-State: ABUngvcBn1yLIRPq7T5lrcLvYMitqld5QNfVfagCInCxZl/+pRztAN8oTmIe8LiSM7X3bB9YjwigmzyP+n7k5zgR X-Received: by 10.13.246.2 with SMTP id g2mr30045305ywf.233.1478023338350; Tue, 01 Nov 2016 11:02:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.3 with HTTP; Tue, 1 Nov 2016 11:01:57 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Tue, 1 Nov 2016 11:01:57 -0700 Message-ID: To: Samuel Erdtman Content-Type: multipart/alternative; boundary=94eb2c0357540dd4e605404120de Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-native-apps-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 18:02:21 -0000 --94eb2c0357540dd4e605404120de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Samuel, Thanks for your review! I've replied inline: On Tue, Nov 1, 2016 at 9:41 AM, Samuel Erdtman wrote: > Hi, > > Thanks for the great work of putting this together. I have a few comments > on the current draft. See below > > Best Regards > Samuel Erdtman > > > > 5. Using Inter-app URI Communication for OAuth > The end of this section is a bit confusing with first a MUST statement an= d > then a RECOMMENDED statement > =E2=80=9CNative apps MUST use an external user-agent to perform OAuth=E2= =80=9D > and > =E2=80=9CThis best practice focuses on the browser as the RECOMMENDED ext= ernal > user-agent for native apps.=E2=80=9D > > The browser is one external user-agent. Using an external agent is a MUST to comply with this BCP, and the browser is the RECOMMENDED user agent. > > 7.1.1. Custom URI Scheme Namespace Considerations > =E2=80=9CFor example, an app that controls the domain name "app.example.c= om" > can use "com.example.app:/" as their custom scheme.=E2=80=9D > drop the slash in the custom schema. > Done. > 7.2. App-claimed HTTPS URI Redirection > =E2=80=9CWhen the browser encounters a claimed URL, instead of the > page being loaded in the browser, the native app is launched instead > with the URL supplied as a launch parameter.=E2=80=9D > drop one =E2=80=9Cinstead=E2=80=9D changing it to: > =E2=80=9CWhen the browser encounters a claimed URL, instead of the > page being loaded in the browser, the native app is launched > with the URL supplied as a launch parameter.=E2=80=9D > > Good catch, thanks. 7.2. App-claimed HTTPS URI Redirection > If this is the recommended way to do it when possible maybe it should be > first? > It's ideal in a security sense, but less broadly supported currently than custom URI schemes. The order is roughly based on popularity. 8.1. Embedded User-Agents > =E2=80=9CEmbedded user-agents are an alternative method for authorization > native apps.=E2=80=9D > change to > =E2=80=9CEmbedded user-agents are an alternative method to authorize > native apps.=E2=80=9D > or > =E2=80=9CEmbedded user-agents are an alternative method for authorization > of native apps.=E2=80=9D > Fixed in 06. > 8. Security Considerations > I see normative language here (MUST, RECOMMENDED, SHOULD, etc.), and it > felt a bit odd to me to have that under Security Considerations. Not sure > if there are guidelines around that, but to me it would make sense to kee= p > the normative parts out of Security Considerations. And it says > =E2=80=9CConsiderations=E2=80=9D, to me that sounds mor like things to th= ink about then > this is how it works. > I actually thought it was common, but I might be wrong. I'll wait and see if others weigh in on this too. 8.2. Protecting the Authorization Code > > =E2=80=9CA limitation of using custom URI schemes for redirect URIs is th= at > multiple apps can typically register the same scheme, which makes it > indeterminate as to which app will receive the Authorization Code. > PKCE [RFC7636] details how this limitation can be used to execute a > code interception attack (see Figure 1). Loopback IP based redirect > URIs may be susceptible to interception by other apps listening on > the same loopback interface.=E2=80=9D > > I think it would be preferable to separate custom URI and Loopback IP > based redirect. > Can add a paragraph break. 8.2. Protecting the Authorization Code > =E2=80=9CLoopback IP based redirect > URIs may be susceptible to interception by other apps listening on > the same loopback interface.=E2=80=9D > Are you referring to an application listening to loopback traffic or an > application killing the original application and start listening on the > same port. The second alternative would be relatively intrusive and notab= le. > The former. The assumption is that other desktop apps may be able to observe all local HTTP traffic on the loopback interface. Appendix A. Server Support Checklist > 1. Support custom URI-scheme redirect URIs. > I could not see that this was required in section Section 7.1. > It's there in section 7: "To fully support this best practice, authorization servers MUST support the following three redirect URI options. Native apps MAY use whichever redirect option suits their needs best, taking into account platform specific implementation details." > > Appendix A. Server Support Checklist > 5. Support PKCE. > in Section 8.2 it says MUST > =E2=80=9CAuthorization servers MUST support PKCE [RFC7636] > for public native app clients.=E2=80=9D > "Recommended" is used in normal sentence case here, but I can see how that might be confusing, perhaps I should delete that word. Will think about this section. Incidentally, the idea for Appendix A was a non-normative checklist of items for authorization servers to collect the core requirements of the BCP, and give developers a quick way to evaluate authorization server compliance. 06 changes staged: https://github.com/WilliamDenniss/oauth-native-apps/pull/3 --94eb2c0357540dd4e605404120de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Samuel,

Thanks for your review! I've replied inline:

On Tue, Nov 1, 2016 at= 9:41 AM, Samuel Erdtman <samuel@erdtman.se> wrote:
Hi,

Thanks for the great work of putting this together. I ha= ve a few comments on the current draft. See below

Best Regards=
Samuel Erdtman



5.=C2=A0 Using Inter-app = URI Communication for OAuth
The end of this section is a bit confusing w= ith first a MUST statement and then a RECOMMENDED statement
=E2=80=9CNat= ive apps MUST use an external user-agent to perform OAuth=E2=80=9D
and=E2=80=9CThis best practice focuses on the browser as the RECOMMENDED ext= ernal
=C2=A0=C2=A0 user-agent for native apps.=E2=80=9D


The browser is one external user-= agent. Using an external agent is a MUST to comply with this BCP, and the b= rowser is the RECOMMENDED user agent.
=C2=A0

7.1.1.=C2= =A0 Custom URI Scheme Namespace Considerations
=E2=80=9CFor example, an = app that controls the domain name "app.example.com"
=C2=A0=C2=A0 can use "c= om.example.app:/" as their custom scheme.=E2=80=9D
drop the slash i= n the custom schema.

= Done.
=C2=A0
7.2.=C2=A0 App-claimed HTTPS URI Redirect= ion
=E2=80=9CWhen the browser encounters a claimed URL, instead of the=C2=A0=C2=A0 page being loaded in the browser, the native app is launched= instead
=C2=A0=C2=A0 with the URL supplied as a launch parameter.=E2=80= =9D
drop one =E2=80=9Cinstead=E2=80=9D changing it to:
=E2=80=9CWhen = the browser encounters a claimed URL, instead of the
=C2=A0=C2=A0 page b= eing loaded in the browser, the native app is launched
=C2=A0=C2=A0 with= the URL supplied as a launch parameter.=E2=80=9D

=

Good catch, thanks.

= 7.2.=C2=A0 App-claimed HTTPS URI Redirection
If this is the recommended = way to do it when possible maybe it should be first?
<= /blockquote>

It's ideal in a security sense, but les= s broadly supported currently than custom URI schemes. The order is roughly= based on popularity.

8.1.=C2=A0 Embedded User-Agents=
=E2=80=9CEmbedded user-agents are an alternative method for authorizati= on
=C2=A0=C2=A0 native apps.=E2=80=9D
change to
=E2=80=9CEmbedded = user-agents are an alternative method to authorize
=C2=A0=C2=A0 native a= pps.=E2=80=9D
or
=E2=80=9CEmbedded user-agents are an alternative met= hod for authorization
=C2=A0=C2=A0 of native apps.=E2=80=9D

Fixed in 06.
=C2=A0
=C2=A0
8.=C2=A0 Security Considerations
I see normative la= nguage here (MUST, RECOMMENDED, SHOULD, etc.), and it felt a bit odd to me = to have that under Security Considerations. Not sure if there are guideline= s around that, but to me it would make sense to keep the normative parts ou= t of Security Considerations. And it says =E2=80=9CConsiderations=E2=80=9D,= to me that sounds mor like things to think about then this is how it works= .

I actually thought = it was common, but I might be wrong. I'll wait and see if others weigh = in on this too.

8.2.=C2=A0 Protecting the Authorizati= on Code

=E2=80=9CA limitation of using custom URI schemes for redire= ct URIs is that
=C2=A0=C2=A0 multiple apps can typically register the sa= me scheme, which makes it
=C2=A0=C2=A0 indeterminate as to which app wil= l receive the Authorization Code.
=C2=A0=C2=A0 PKCE [RFC7636] details ho= w this limitation can be used to execute a
=C2=A0=C2=A0 code interceptio= n attack (see Figure 1).=C2=A0 Loopback IP based redirect
=C2=A0=C2=A0 U= RIs may be susceptible to interception by other apps listening on
=C2=A0= =C2=A0 the same loopback interface.=E2=80=9D

I think it would be pre= ferable to separate custom URI and Loopback IP based redirect.

Can add a paragraph break.
=

8.2.=C2=A0 Protecting the Authorization Code
=E2=80= =9CLoopback IP based redirect
=C2=A0=C2=A0 URIs may be susceptible to in= terception by other apps listening on
=C2=A0=C2=A0 the same loopback int= erface.=E2=80=9D
Are you referring to an application listening to loopba= ck traffic or an application killing the original application and start lis= tening on the same port. The second alternative would be relatively intrusi= ve and notable.

The f= ormer. The assumption is that other desktop apps may be able to observe all= local HTTP traffic on the loopback interface.

Append= ix A.=C2=A0 Server Support Checklist
1.=C2=A0 Support custom URI-scheme = redirect URIs.
I could not see that this was required in section Sectio= n 7.1.

It's there= in section 7:
"To fully support this best practice, au= thorization servers MUST support
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the = following three redirect URI options. Native apps MAY use
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 whichever redirect option suits their needs best, taki= ng into account
=C2=A0 =C2=A0 =C2=A0 =C2=A0 platform specific imp= lementation details."
=C2=A0

Appendix A.=C2= =A0 Server Support Checklist
5.=C2=A0 Support PKCE.
in Section 8.2 it= says MUST
=E2=80=9CAuthorization servers MUST support PKCE [RFC7636]=C2=A0=C2=A0 for public native app clients.=E2=80=9D
=
=C2=A0
"Recommended" is used in norma= l sentence case here, but I can see how that might be confusing, perhaps I = should delete that word. Will think about this section.=C2=A0
Incidentally, the idea for Appendix A was a non-normative check= list of items for authorization servers to collect the core requirements of= the BCP, and give developers a quick way to evaluate authorization server = compliance.


--94eb2c0357540dd4e605404120de-- From nobody Tue Nov 1 23:15:11 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B251293F2 for ; Tue, 1 Nov 2016 23:15:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB8CvwRJcYvw for ; Tue, 1 Nov 2016 23:15:05 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918BA12964B for ; Tue, 1 Nov 2016 23:15:05 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n67so14898387wme.1 for ; Tue, 01 Nov 2016 23:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VfwsQAqXo0f7onBIWUGs1x2AL+GW/5txqo096zmKkMM=; b=AOeP6PoQuBWL5WgbVR7nM7CSJ5jE/dD8GhdvQQAWDHDg6WQqb8Y2n44eGsoNxSqJLf w5oD6kuvjOppQCVEdbh/5wi7gmByrNgbU3Xhx4eZpjFdA9ge3DY3MMtCwHqNxxrkoy3z UXX4Tnv11ZIBusy0wqxL4kZ1Qx5WXAda3xBeIb8gEgNJbCgxXPncE+2xKTyIj7pz4Q/a GybuuR7QtdebD9akV+nxUPvGBunydgQZ8THj/gLIJvHFUpn3CaxwPsZRBX4Jsn3OxTKU V1CfGK0ddVJkvV5of/4dIZ8LIS/Davq00fDU1r4mORbSgRT0hQXVSKINXLSg3uicUdsT sslw== 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; bh=VfwsQAqXo0f7onBIWUGs1x2AL+GW/5txqo096zmKkMM=; b=cSymtJ5bYVxBLzefAgt4uXJN3xROhbPyCkpU3vRCZNhRdtGRaIXczzGNhAHbboj3gd 3w2LnfsdGxTMAlyT7RLtCyXZxmEm7e/v85ls5lkIQIBdKsZIiQemOZWwi0bfyORC3HD/ opb2Z0eoK3vHJ/sIcUpVSB3DjyX2QzIiJLfWd+5O9Q7I4UHByuDpx6UjU/K4RsuHumJV h0Hd67QWsb5A3qDSoF9xP24PWQ55BP8NvIjrVSEVwazDFdmCF7GEb8CSlHo3C/hpU46s atgQj0xrdSPSpAoP9++Ng72SivSWmCGG0H+El+ff2AM8sG2wNzq+PiWW/QenBShDyCyu OL9A== X-Gm-Message-State: ABUngvf0xoxTjBQBN4oDfdByLeAbHY9ZL21CamYlt4BylQRXEVWMllKOkJEFDHpnNuaKZR4u3I2+vqgix4lKTw== X-Received: by 10.28.169.4 with SMTP id s4mr1231760wme.65.1478067303945; Tue, 01 Nov 2016 23:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.172.232 with HTTP; Tue, 1 Nov 2016 23:15:03 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Wed, 2 Nov 2016 07:15:03 +0100 Message-ID: To: William Denniss , Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a114b91829b2df405404b5c85 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-native-apps-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 06:15:09 -0000 --001a114b91829b2df405404b5c85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable see inline Hannes could you have a look at the comment on Security Considerations. On Tue, Nov 1, 2016 at 7:01 PM, William Denniss wrote= : > Hi Samuel, > > Thanks for your review! I've replied inline: > > On Tue, Nov 1, 2016 at 9:41 AM, Samuel Erdtman wrote: > >> Hi, >> >> Thanks for the great work of putting this together. I have a few comment= s >> on the current draft. See below >> >> Best Regards >> Samuel Erdtman >> >> >> >> 5. Using Inter-app URI Communication for OAuth >> The end of this section is a bit confusing with first a MUST statement >> and then a RECOMMENDED statement >> =E2=80=9CNative apps MUST use an external user-agent to perform OAuth=E2= =80=9D >> and >> =E2=80=9CThis best practice focuses on the browser as the RECOMMENDED ex= ternal >> user-agent for native apps.=E2=80=9D >> >> > The browser is one external user-agent. Using an external agent is a MUST > to comply with this BCP, and the browser is the RECOMMENDED user agent. > My comment is not that something is formally wrong, just that I had to read it twice before I got it. I=C2=B4m fine with keeping as is, just wanted to hilight the potential confusion. > > >> >> 7.1.1. Custom URI Scheme Namespace Considerations >> =E2=80=9CFor example, an app that controls the domain name "app.example.= com" >> can use "com.example.app:/" as their custom scheme.=E2=80=9D >> drop the slash in the custom schema. >> > > Done. > > >> 7.2. App-claimed HTTPS URI Redirection >> =E2=80=9CWhen the browser encounters a claimed URL, instead of the >> page being loaded in the browser, the native app is launched instead >> with the URL supplied as a launch parameter.=E2=80=9D >> drop one =E2=80=9Cinstead=E2=80=9D changing it to: >> =E2=80=9CWhen the browser encounters a claimed URL, instead of the >> page being loaded in the browser, the native app is launched >> with the URL supplied as a launch parameter.=E2=80=9D >> >> > Good catch, thanks. > > 7.2. App-claimed HTTPS URI Redirection >> If this is the recommended way to do it when possible maybe it should be >> first? >> > > It's ideal in a security sense, but less broadly supported currently than > custom URI schemes. The order is roughly based on popularity. > makes sense > > 8.1. Embedded User-Agents >> =E2=80=9CEmbedded user-agents are an alternative method for authorizatio= n >> native apps.=E2=80=9D >> change to >> =E2=80=9CEmbedded user-agents are an alternative method to authorize >> native apps.=E2=80=9D >> or >> =E2=80=9CEmbedded user-agents are an alternative method for authorizatio= n >> of native apps.=E2=80=9D >> > > Fixed in 06. > > > >> 8. Security Considerations >> I see normative language here (MUST, RECOMMENDED, SHOULD, etc.), and it >> felt a bit odd to me to have that under Security Considerations. Not sur= e >> if there are guidelines around that, but to me it would make sense to ke= ep >> the normative parts out of Security Considerations. And it says >> =E2=80=9CConsiderations=E2=80=9D, to me that sounds mor like things to t= hink about then >> this is how it works. >> > > I actually thought it was common, but I might be wrong. I'll wait and see > if others weigh in on this too. > Sounds like a plan. > > 8.2. Protecting the Authorization Code >> >> =E2=80=9CA limitation of using custom URI schemes for redirect URIs is t= hat >> multiple apps can typically register the same scheme, which makes it >> indeterminate as to which app will receive the Authorization Code. >> PKCE [RFC7636] details how this limitation can be used to execute a >> code interception attack (see Figure 1). Loopback IP based redirect >> URIs may be susceptible to interception by other apps listening on >> the same loopback interface.=E2=80=9D >> >> I think it would be preferable to separate custom URI and Loopback IP >> based redirect. >> > > Can add a paragraph break. > Thanks > > 8.2. Protecting the Authorization Code >> =E2=80=9CLoopback IP based redirect >> URIs may be susceptible to interception by other apps listening on >> the same loopback interface.=E2=80=9D >> Are you referring to an application listening to loopback traffic or an >> application killing the original application and start listening on the >> same port. The second alternative would be relatively intrusive and nota= ble. >> > > The former. The assumption is that other desktop apps may be able to > observe all local HTTP traffic on the loopback interface. > Ok > > Appendix A. Server Support Checklist >> 1. Support custom URI-scheme redirect URIs. >> I could not see that this was required in section Section 7.1. >> > > It's there in section 7: > "To fully support this best practice, authorization servers MUST support > the following three redirect URI options. Native apps MAY use > whichever redirect option suits their needs best, taking into > account > platform specific implementation details." > My bad, I missed it. > > >> >> Appendix A. Server Support Checklist >> 5. Support PKCE. >> in Section 8.2 it says MUST >> =E2=80=9CAuthorization servers MUST support PKCE [RFC7636] >> for public native app clients.=E2=80=9D >> > > "Recommended" is used in normal sentence case here, but I can see how tha= t > might be confusing, perhaps I should delete that word. Will think about > this section. > > Incidentally, the idea for Appendix A was a non-normative checklist of > items for authorization servers to collect the core requirements of the > BCP, and give developers a quick way to evaluate authorization server > compliance. > I like the idea of the checklist. > > 06 changes staged: https://github.com/WilliamDenniss/oauth-native- > apps/pull/3 > > --001a114b91829b2df405404b5c85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
see inline

Hannes could you have a look = at the comment on Security Considerations.

On Tue, Nov 1, 2016 at 7:01 PM, William = Denniss <wdenniss@google.com> wrote:
Hi Samuel,
<= div class=3D"gmail_extra">
Thanks for your review! I've replied inli= ne:

On Tue, Nov 1, 2016 at 9:41 AM, Samuel Erdtman &= lt;samuel@erdtman.se= > wrote:
Hi,

Thanks for the great work= of putting this together. I have a few comments on the current draft. See = below

Best Regards
Samuel Erdtman


5.=C2=A0 Using Inter-app URI Communication for OAuth
The end of th= is section is a bit confusing with first a MUST statement and then a RECOMM= ENDED statement
=E2=80=9CNative apps MUST use an external user-agent to = perform OAuth=E2=80=9D
and
=E2=80=9CThis best practice focuses on the= browser as the RECOMMENDED external
=C2=A0=C2=A0 user-agent for native = apps.=E2=80=9D


=
The browser is one external user-agent. Using an external agent is a M= UST to comply with this BCP, and the browser is the RECOMMENDED user agent.=

My comment is not = that something is formally wrong, just that I had to read it twice before I= got it. I=C2=B4m fine with keeping as is, just wanted to hilight the poten= tial confusion.
=C2=A0
=C2=A0

7.1.1.=C2=A0 Custom URI Scheme Namespace = Considerations
=E2=80=9CFor example, an app that controls the domain nam= e "app.example.co= m"
=C2=A0=C2=A0 can use "com.example.app:/" as their = custom scheme.=E2=80=9D
drop the slash in the custom schema.

Done.
=C2=A0
<= div dir=3D"ltr">
7.2.=C2=A0 App-claimed HTTPS URI Redirection
= =E2=80=9CWhen the browser encounters a claimed URL, instead of the
=C2= =A0=C2=A0 page being loaded in the browser, the native app is launched inst= ead
=C2=A0=C2=A0 with the URL supplied as a launch parameter.=E2=80=9Ddrop one =E2=80=9Cinstead=E2=80=9D changing it to:
=E2=80=9CWhen the b= rowser encounters a claimed URL, instead of the
=C2=A0=C2=A0 page being = loaded in the browser, the native app is launched
=C2=A0=C2=A0 with the = URL supplied as a launch parameter.=E2=80=9D


Good catch, thanks.

7.2.=C2=A0 App-claimed HTTPS URI Redirection
If this = is the recommended way to do it when possible maybe it should be first?
=

It's ideal in= a security sense, but less broadly supported currently than custom URI sch= emes. The order is roughly based on popularity.

makes sense
=C2=A0

8.1.=C2=A0 Embedded U= ser-Agents
=E2=80=9CEmbedded user-agents are an alternative method for a= uthorization
=C2=A0=C2=A0 native apps.=E2=80=9D
change to
=E2=80= =9CEmbedded user-agents are an alternative method to authorize
=C2=A0=C2= =A0 native apps.=E2=80=9D
or
=E2=80=9CEmbedded user-agents are an alt= ernative method for authorization
=C2=A0=C2=A0 of native apps.=E2=80=9D<= br>

Fixed in 06.
=C2=A0
=C2=A0
8.=C2=A0 Security = Considerations
I see normative language here (MUST, RECOMMENDED, SHOULD,= etc.), and it felt a bit odd to me to have that under Security Considerati= ons. Not sure if there are guidelines around that, but to me it would make = sense to keep the normative parts out of Security Considerations. And it sa= ys =E2=80=9CConsiderations=E2=80=9D, to me that sounds mor like things to t= hink about then this is how it works.

I actually thought it was common, but I might be wr= ong. I'll wait and see if others weigh in on this too.

Sounds like a plan.
= =C2=A0

8.= 2.=C2=A0 Protecting the Authorization Code

=E2=80=9CA limitation of = using custom URI schemes for redirect URIs is that
=C2=A0=C2=A0 multiple= apps can typically register the same scheme, which makes it
=C2=A0=C2= =A0 indeterminate as to which app will receive the Authorization Code.
= =C2=A0=C2=A0 PKCE [RFC7636] details how this limitation can be used to exec= ute a
=C2=A0=C2=A0 code interception attack (see Figure 1).=C2=A0 Loopba= ck IP based redirect
=C2=A0=C2=A0 URIs may be susceptible to interceptio= n by other apps listening on
=C2=A0=C2=A0 the same loopback interface.= =E2=80=9D

I think it would be preferable to separate custom URI and = Loopback IP based redirect.

Can add a paragraph break.

Thanks
=C2=A0

8.2.=C2=A0 Protecting the Autho= rization Code
=E2=80=9CLoopback IP based redirect
=C2=A0=C2=A0 URIs m= ay be susceptible to interception by other apps listening on
=C2=A0=C2= =A0 the same loopback interface.=E2=80=9D
Are you referring to an applic= ation listening to loopback traffic or an application killing the original = application and start listening on the same port. The second alternative wo= uld be relatively intrusive and notable.
=

The former. The assumption is that other desktop= apps may be able to observe all local HTTP traffic on the loopback interfa= ce.

Ok
=C2=A0

<= div>Appendix A.=C2=A0 Server Support Checklist
1.=C2=A0 Support custom U= RI-scheme redirect URIs.
I could not see that this was required in sect= ion Section 7.1.

It's there in section 7:
"To fully support this = best practice, authorization servers MUST support
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 the following three redirect URI options. Native apps MAY use=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 whichever redirect option suits thei= r needs best, taking into account
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pla= tform specific implementation details."
<= /blockquote>

My bad, I missed it.
=C2=A0
=C2=A0

Appe= ndix A.=C2=A0 Server Support Checklist
5.=C2=A0 Support PKCE.
in Sect= ion 8.2 it says MUST
=E2=80=9CAuthorization servers MUST support PKCE [R= FC7636]
=C2=A0=C2=A0 for public native app clients.=E2=80=9D
=C2=A0
"Recommended"= is used in normal sentence case here, but I can see how that might be conf= using, perhaps I should delete that word. Will think about this section.=C2= =A0

Incidentally, the idea for Appendix A was a no= n-normative checklist of items for authorization servers to collect the cor= e requirements of the BCP, and give developers a quick way to evaluate auth= orization server compliance.
<= br>
I like the idea of the checklist.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">



--001a114b91829b2df405404b5c85-- From nobody Wed Nov 2 14:03:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BDA1296B5 for ; Wed, 2 Nov 2016 14:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19nHyiyaKyn3 for ; Wed, 2 Nov 2016 14:03:47 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BD9129453 for ; Wed, 2 Nov 2016 14:03:47 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id x4so38075085oix.2 for ; Wed, 02 Nov 2016 14:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uhqJs9p4zR2KTuEBhyrjUGan1Yx/ut1ZWhS3Q7V6u6M=; b=Ktsn3rsX0u+nm/wnoR5ig7I/RiNBmB7wbZVK0k7s9jkYaAB2W4U+PagBYx5EOmkeG6 FoiwUORewK/dGHnD43XBq1xgk6K7XFzWmsxtmINgjnx1Z3tgAEmQexwGqFXYu+/Nyf6t wi+7c3tLMXL76n2Ali3zMMBSWJafehtyNVemI= 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; bh=uhqJs9p4zR2KTuEBhyrjUGan1Yx/ut1ZWhS3Q7V6u6M=; b=DzdfRbcN6HZ/EQWt/HSc1fvS6h7eqAjqyiOwnTS5gXOu69c6zr0uJZeGMp9CqGfel6 BCUzlvwwwJCZ+DRlRra5Uhzf8LC+kkgBYzOCMgOpyOPStpCUD07qXGtEJNzRTb3WsZ3C Bewcycp+v9FOyjgn/zAZIFb2/Jmk6VIhLsLxxQ1k9GMDfq/u3MubHo1kdoUZkv5kn6E4 pOqQL1f0yKaBEIkayHDkPV1mCCS7yWjoG3q56EVtEaYJZirV6jakJ4Hy6okjC9uc3HA4 PgvaLqbzs3EoS85J+CmwW/mXR/S+w5dO/uJa+6X1SXjwUP+dATLewF8LQehNSeBopkLK UG1w== X-Gm-Message-State: ABUngveBv5xSvS326VSwTrGkSL6Ms5Klx7pogiGmYBs8XyJ8GZvoE4xGf+yBohghc5h0R+g1yApYHPpGhsnFQnao X-Received: by 10.107.201.86 with SMTP id z83mr6050369iof.156.1478120626672; Wed, 02 Nov 2016 14:03:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Wed, 2 Nov 2016 14:03:16 -0700 (PDT) In-Reply-To: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> From: Brian Campbell Date: Wed, 2 Nov 2016 15:03:16 -0600 Message-ID: To: Samuel Erdtman Content-Type: multipart/alternative; boundary=94eb2c0b92ace374b5054057c68d Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 21:03:49 -0000 --94eb2c0b92ace374b5054057c68d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wrote: > > I agree it is written so that the connection to the certificate is > implicitly required but I think it would be better if it was explicit > written since the lack of a connection would result in a potential securi= ty > hole. > That's fair. I agree it can be made more explicit and that it be good to do so. > When it comes to the client_id I think subject common name or maybe > subject serial numbers will be the common location, and I think an exampl= e > would be valuable. > > In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common. I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward. > > I=C2=B4m not saying it is a bad Idea just that I would prefer if it was n= ot a > MUST. > With very limited addition of code it is just as easy to get the > certificate attribute for client id as it is to get it from the HTTP > request data (at least in java). I also think that with the requirement t= o > match the incoming certificate in some way one has to read out the > certificate that was used to establish the connection to do some kind of > matching. > > Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. --94eb2c0b92ace374b5054057c68d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 30, 2016 at 9:2= 7 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

<= div class=3D"gmail_extra">
I agree it is written so that the connection to the certificat= e is implicitly required but I think it would be better if it was explicit = written since the lack of a connection would result in a potential security= hole.

That'= ;s fair. I agree it can be made more explicit and that it be good to do so.=

=C2=A0
When it comes to the client_id I thin= k subject common name or maybe subject serial numbers will be the common lo= cation, and I think an example would be valuable.
=C2=A0
=

In my experience and the way w= e built support for mutual TLS OAuth client auth the client_id value does n= ot appear in the certificate anywhere. I'm not saying it can't happ= en but don't think it's particularly common.

I can look at = adding some examples, if there's some consensus that they'd be usef= ul and this document moves forward.

=C2=A0

I=C2=B4m not saying it is a bad Idea just that I wo= uld prefer if it was not a MUST.
With very limited addition of code it = is just as easy to get the certificate attribute for client id as it is to = get it from the HTTP request data (at least in java). I also think that wit= h the requirement to match the incoming certificate in some way one has to = read out the certificate that was used to establish the connection to do so= me kind of matching.

<= /div>

Getting data = out of the certificate isn't a concern. I just believe that the constan= cy of having the client id parameter is worth the potential small amount du= plicate data in some cases. It's just a -00 draft though and if the WG = wants to proceed with this document, we seek further input and work towards= some consensus.

--94eb2c0b92ace374b5054057c68d-- From nobody Thu Nov 3 05:42:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008B012957F for ; Thu, 3 Nov 2016 05:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3OyhopytANR for ; Thu, 3 Nov 2016 05:42:07 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C99F12955F for ; Thu, 3 Nov 2016 05:42:07 -0700 (PDT) X-AuditID: 1209190f-ad7ff70000004c24-1e-581b309d8554 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E2.71.19492.D903B185; Thu, 3 Nov 2016 08:42:06 -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 uA3Cg53C004966; Thu, 3 Nov 2016 08:42:05 -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 uA3Cg2dM023635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Nov 2016 08:42:03 -0400 To: Brian Campbell , Samuel Erdtman References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> From: Justin Richer Message-ID: <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> Date: Thu, 3 Nov 2016 08:41:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C7006D8E48835A0C09F5585D" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixCmqrDvPQDrCoOuklMXq/zcZLU6+fcVm 8fnWYVaL/0tPMTmweLz4t4fRY8mSn0wez3f2M3ncPXqRJYAlissmJTUnsyy1SN8ugSvj4bSJ bAWXvCs+rz3L2MC4zKiLkZNDQsBE4tuVA0xdjFwcQgJtTBK3nvcwQzgbGCW2952Fytxikvh7 4w4rSIuwQLrE61n/mEFsEYEYifMnVrBDFF1hkdiz/RYbSIJZIF/iw6WbYA1sAqoS09e0MIHY vAJWEmebJ4A1swioSEz7ORusXhRo0PVnj9ggagQlTs58wgJicwoESrx8dIUZYmaYRMeEZrYJ jPyzkJTNQpKCsG0l7szdzQxhy0s0b50NZetKLNq2gh1ZfAEj2ypG2ZTcKt3cxMyc4tRk3eLk xLy81CJdE73czBK91JTSTYzgKJDk38E4p8H7EKMAB6MSD2/GD8kIIdbEsuLK3EOMkhxMSqK8 bzSlI4T4kvJTKjMSizPii0pzUosPMUpwMCuJ8CrqAeV4UxIrq1KL8mFS0hwsSuK8/92+hgsJ pCeWpGanphakFsFkZTg4lCR4D+sDNQoWpaanVqRl5pQgpJk4OEGG8wANPwBSw1tckJhbnJkO kT/FqCglzntSByghAJLIKM2D6wUlqYS3h01fMYoDvSLMWwvSzgNMcHDdr4AGMwENNk+SABlc koiQkmpg3Hpkc3VUpbiwHkflPZYvJoY79zzsDz7KH35mccwqjfNTvnbub5kRmcrw6/5dsTXS zpWOpxQnuRpMNwiSSPg5Me3tgec1M/afYy1uCr8ey7/tuNqv9MlzbGe+7o6tkEgyXWKxYMIZ L9avq8qE5GambGIxE5vsy53Zxb3jwILH1UukOOp2bfydpcRSnJFoqMVcVJwIAKUAMrgtAwAA Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 12:42:09 -0000 This is a multi-part message in MIME format. --------------C7006D8E48835A0C09F5585D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today. I do think that more examples and guidance are warranted, though, to help AS developers. -- Justin On 11/2/2016 5:03 PM, Brian Campbell wrote: > > On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman > wrote: > > > I agree it is written so that the connection to the certificate is > implicitly required but I think it would be better if it was > explicit written since the lack of a connection would result in a > potential security hole. > > > That's fair. I agree it can be made more explicit and that it be good > to do so. > > When it comes to the client_id I think subject common name or > maybe subject serial numbers will be the common location, and I > think an example would be valuable. > > > In my experience and the way we built support for mutual TLS OAuth > client auth the client_id value does not appear in the certificate > anywhere. I'm not saying it can't happen but don't think it's > particularly common. > > I can look at adding some examples, if there's some consensus that > they'd be useful and this document moves forward. > > > Im not saying it is a bad Idea just that I would prefer if it was > not a MUST. > With very limited addition of code it is just as easy to get the > certificate attribute for client id as it is to get it from the > HTTP request data (at least in java). I also think that with the > requirement to match the incoming certificate in some way one has > to read out the certificate that was used to establish the > connection to do some kind of matching. > > > Getting data out of the certificate isn't a concern. I just believe > that the constancy of having the client id parameter is worth the > potential small amount duplicate data in some cases. It's just a -00 > draft though and if the WG wants to proceed with this document, we > seek further input and work towards some consensus. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------C7006D8E48835A0C09F5585D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.

Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

I do think that more examples and guidance are warranted, though, to help AS developers.

-- Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explicit and that it be good to do so.

When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.


In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.


Im not saying it is a bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



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

--------------C7006D8E48835A0C09F5585D-- From nobody Thu Nov 3 05:48:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A479129578 for ; Thu, 3 Nov 2016 05:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkoqkBFvTjIm for ; Thu, 3 Nov 2016 05:48:43 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3BC12946E for ; Thu, 3 Nov 2016 05:48:43 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id p16so27186900qta.0 for ; Thu, 03 Nov 2016 05:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6aPmNpYjVkJQ1+d0mPQ6AQF7YK/D2OR9mPbrrvoiG6Y=; b=HbYJlb4IdY+EqQ7INlJciPZM84PIKRhvLWTw965Mqb4NYMJBBId6++Zxv5l6a7LA95 K/VFmZnwaNAlXGVNioXE6YeBtdL4S6IK8laqhqUDMgNAR5Rm0lG2qoWi4e9m1QbMh+zx B6c49kZcL+zyhR4qZg4r+p2i/c56TczrD2YglC77wYokwPNVkpwy+umoqGa3aV4NkOEU 4d5rns+BvDRdXJ5l+HeJXHS81w4SMNN7MmxbGhsKQFIPNn7YF3TAW6+q76NINaQ2h4wR 6J0ssDFOUkGQJtM1wtm6kxVf1b2hUHluBUk4aOHP2RP77rsdpvcmGOTwzzB4klMdjSzG REZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6aPmNpYjVkJQ1+d0mPQ6AQF7YK/D2OR9mPbrrvoiG6Y=; b=ftmao8Kp9aYdEtSG0TRff0LrxUpccqkMpDjw9rVHEvVBzZgco+2fcCYfC1CvR8TNQA pIpGXv9dNTFWHqGRj4D7LxJkBHxCuJQp6DFewxZDNfTHcECm8ksdCwOLKR5IJJTplDWu 1PHh0Ge/Dg1015YJQwlDS9HyUp4bSkNJijSINKymykiOtpqWYU6b9aNT0Nrr1g8+PEoc wd2sxv9F1c1+O2zMw/7iEuVBrGkD9lY1sqfAov+TG2Q9wFX+zl94rr1hYEFL8UluDjT2 ROOCT/Rlx46b8fDj0+ODIuMP54AW1MNb4XMak6t6u+9e2+OI4bJWUxtjCRtRX3bMgQ3Z MepA== X-Gm-Message-State: ABUngvfawRj3EqdASTlzKczG0wwP76taNLwZi08kmRbVgleeuy1lcgRVXgOZpEuN+GVwO34m X-Received: by 10.200.43.5 with SMTP id 5mr7951345qtu.145.1478177322286; Thu, 03 Nov 2016 05:48:42 -0700 (PDT) Received: from [172.16.60.144] (modemcable085.143-176-173.mc.videotron.ca. [173.176.143.85]) by smtp.gmail.com with ESMTPSA id s66sm4273668qkb.17.2016.11.03.05.48.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 05:48:41 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-7070A0C4-C21F-4D47-8D1C-10580ADA6B8E Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14B100) In-Reply-To: <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> Date: Thu, 3 Nov 2016 08:48:41 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> To: Justin Richer Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 12:48:45 -0000 --Apple-Mail-7070A0C4-C21F-4D47-8D1C-10580ADA6B8E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just to be clear, the relationship should more like... AS issues public key to clients, or client sends public key to AS. The autho= rities job is NOT to give the client the public key, but to sign the public k= ey for authenticity. It's bad practice to accept the full cert (pub key+sign= ature) from an authority. If an authority is creating your public key, they a= re also creating your private key.... bad. > The client will use the same cert across multiple connections, possibly mu= ltiple AS's, but the same isn't true of the client_id.=20 This seems like a bad idea. I suggest a separate key/signature for each serv= ice. -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Nov 3, 2016, at 8:41 AM, Justin Richer wrote: >=20 > I agree that the client_id is unlikely to be found inside the certificate i= tself. The client_id is issued by the authorization server for the client to= use at that single AS. The certificate is issued by the CA for the client t= o use on any connection. The AS and CA are not likely to be the same system i= n most deployments. The client will use the same cert across multiple connec= tions, possibly multiple AS's, but the same isn't true of the client_id.=20 > Additionally, I think we want to allow for a binding of a self-signed cert= ificate using dynamic registration, much the way that we already allow bindi= ng of a client-generated JWK today.=20 > I do think that more examples and guidance are warranted, though, to help A= S developers. >=20 > -- Justin >=20 >> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>=20 >>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wrot= e: >>>=20 >>> I agree it is written so that the connection to the certificate is impli= citly required but I think it would be better if it was explicit written sin= ce the lack of a connection would result in a potential security hole. >>=20 >> That's fair. I agree it can be made more explicit and that it be good to d= o so.=20 >>=20 >> =20 >>> When it comes to the client_id I think subject common name or maybe subj= ect serial numbers will be the common location, and I think an example would= be valuable. >>> =20 >>=20 >> In my experience and the way we built support for mutual TLS OAuth client= auth the client_id value does not appear in the certificate anywhere. I'm n= ot saying it can't happen but don't think it's particularly common.=20 >>=20 >> I can look at adding some examples, if there's some consensus that they'd= be useful and this document moves forward.=20 >>=20 >> =20 >>>=20 >>> I=C2=B4m not saying it is a bad Idea just that I would prefer if it was n= ot a MUST.=20 >>> With very limited addition of code it is just as easy to get the certifi= cate attribute for client id as it is to get it from the HTTP request data (= at least in java). I also think that with the requirement to match the incom= ing certificate in some way one has to read out the certificate that was use= d to establish the connection to do some kind of matching. >>>=20 >>=20 >> Getting data out of the certificate isn't a concern. I just believe that t= he constancy of having the client id parameter is worth the potential small a= mount duplicate data in some cases. It's just a -00 draft though and if the W= G wants to proceed with this document, we seek further input and work toward= s some consensus.=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-7070A0C4-C21F-4D47-8D1C-10580ADA6B8E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Just to be clear, the relationship sho= uld more like...

AS issues public key to clients, or client sends public ke= y to AS. The authorities job is NOT to give the client the public key, but t= o sign the public key for authenticity. It's bad practice to accept the full= cert (pub key+signature) from an authority. If an authority is creating you= r public key, they are also creating your private key.... bad.

> The client will use the sam= e cert across multiple connections, possibly multiple AS's, but the same isn= 't true of the client_id. 
<= br>
This seems like a bad idea. I sugges= t a separate key/signature for each service.
--
Jim Manico=
@Manicode
Secure Coding Education
+1 (808) 65= 2-3805

On Nov 3, 2016, at 8:41 AM, Justin Richer <jricher@mit.edu> wrote:

<= blockquote type=3D"cite">
=20 =20 =20

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.

Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

I do think that more examples and guidance are warranted, though, to help AS developers.

 -- Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se>= wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explicit and that it be good to do so.

 
When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
 

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

 
I=C2=B4m not saying it is a bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



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

=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-7070A0C4-C21F-4D47-8D1C-10580ADA6B8E-- From nobody Thu Nov 3 05:51:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B061295A3 for ; Thu, 3 Nov 2016 05:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9lAblJ78vNT for ; Thu, 3 Nov 2016 05:51:26 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B03512959D for ; Thu, 3 Nov 2016 05:51:26 -0700 (PDT) X-AuditID: 12074423-623ff70000001060-fd-581b32cbac77 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 26.42.04192.BC23B185; Thu, 3 Nov 2016 08:51:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id uA3CpMJZ020540; Thu, 3 Nov 2016 08:51:23 -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 uA3CpK7v025448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Nov 2016 08:51:21 -0400 To: Jim Manico References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> From: Justin Richer Message-ID: <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> Date: Thu, 3 Nov 2016 08:51:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> Content-Type: multipart/alternative; boundary="------------2B4D02C9812810AB04DD4778" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixCmqrXvWSDrCYOcVKYvV/28yWrzYf5Dd 4uTbV2wWn28dZrX4v/QUkwOrx4t/exg9liz5yeTxfGc/k0fjjAeMHnePXmQJYI3isklJzcks Sy3St0vgytg4dz97wd+yiuVNy1gaGF/5djFyckgImEgcOf2VpYuRi0NIoI1JYu36p1DOBkaJ 5evmMEI4t5gkdq55wALSIiyQLvF61j9mEFtEQFHiwJ4mJoii3awSbUveMIM4zAKXGCXeT3gO VsUmoCoxfU0LE4jNK2AlsfbFXDCbRUBF4tf802wgtqhAjMT1Z4/YIGoEJU7OfAK2jVPAQeLJ 072sIDazQJhE+9TlbBMY+WchKZuFJAVhm0nM2/yQGcKWl2jeOhvI5gCy1SSWtSohCy9gZFvF KJuSW6Wbm5iZU5yarFucnJiXl1qka6aXm1mil5pSuokRFBnsLso7GF/2eR9iFOBgVOLhzfgh GSHEmlhWXJl7iFGSg0lJlPeNpnSEEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeRT2gHG9KYmVV alE+TEqag0VJnPe/29dwIYH0xJLU7NTUgtQimKwMB4eSBC8fMAEICRalpqdWpGXmlCCkmTg4 QYbzAA2/aggyvLggMbc4Mx0if4pRUUqcNwskIQCSyCjNg+sFJa6Et4dNXzGKA70izCsLsoIH mPTgul8BDWYCGmyeJAEyuCQRISXVwMjPr76fa/8ym8lnVthErF272bSyQrwgyeLgybSz/3kf xVv/2akiWLdsrwa3/9HTLOKbtN5rrLsQFXyB8c4f4ea3Oa8shZ9rTvw9ty48Rt93+oLv3i9r 97qUixyfKhSfEJik/41dccmB3MXzHtxu6e5PFBAWfmMZEJ8r9nXty+WeP8vc/m+dWKPEUpyR aKjFXFScCAC9y3TsNwMAAA== Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 12:51:29 -0000 This is a multi-part message in MIME format. --------------2B4D02C9812810AB04DD4778 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yes, I elided the certificate issuance process. The point remains the same: you're not going to be submitting a CSR to the same party you're getting your client_id from, usually. If the draft assumes that, then it's incredibly limiting. Do people really use separate TLS client certs for separate connections in the wild? I've personally never seen that. What I've seen is that a piece of software gets its certificate that it uses to make whatever connections it needs to make. -- Justin On 11/3/2016 8:48 AM, Jim Manico wrote: > Just to be clear, the relationship should more like... > > AS issues public key to clients, or client sends public key to AS. The > authorities job is NOT to give the client the public key, but to sign > the public key for authenticity. It's bad practice to accept the full > cert (pub key+signature) from an authority. If an authority is > creating your public key, they are also creating your private key.... bad. > > > The client will use the same cert across multiple connections, > possibly multiple AS's, but the same isn't true of the client_id. > > This seems like a bad idea. I suggest a separate key/signature for > each service. > -- > Jim Manico > @Manicode > Secure Coding Education > +1 (808) 652-3805 > > On Nov 3, 2016, at 8:41 AM, Justin Richer > wrote: > >> I agree that the client_id is unlikely to be found inside the >> certificate itself. The client_id is issued by the authorization >> server for the client to use at that single AS. The certificate is >> issued by the CA for the client to use on any connection. The AS and >> CA are not likely to be the same system in most deployments. The >> client will use the same cert across multiple connections, possibly >> multiple AS's, but the same isn't true of the client_id. >> >> Additionally, I think we want to allow for a binding of a self-signed >> certificate using dynamic registration, much the way that we already >> allow binding of a client-generated JWK today. >> >> I do think that more examples and guidance are warranted, though, to >> help AS developers. >> >> -- Justin >> >> >> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>> >>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman >> > wrote: >>> >>> >>> I agree it is written so that the connection to the certificate >>> is implicitly required but I think it would be better if it was >>> explicit written since the lack of a connection would result in >>> a potential security hole. >>> >>> >>> That's fair. I agree it can be made more explicit and that it be >>> good to do so. >>> >>> When it comes to the client_id I think subject common name or >>> maybe subject serial numbers will be the common location, and I >>> think an example would be valuable. >>> >>> >>> In my experience and the way we built support for mutual TLS OAuth >>> client auth the client_id value does not appear in the certificate >>> anywhere. I'm not saying it can't happen but don't think it's >>> particularly common. >>> >>> I can look at adding some examples, if there's some consensus that >>> they'd be useful and this document moves forward. >>> >>> >>> I´m not saying it is a bad Idea just that I would prefer if it >>> was not a MUST. >>> With very limited addition of code it is just as easy to get the >>> certificate attribute for client id as it is to get it from the >>> HTTP request data (at least in java). I also think that with the >>> requirement to match the incoming certificate in some way one >>> has to read out the certificate that was used to establish the >>> connection to do some kind of matching. >>> >>> >>> Getting data out of the certificate isn't a concern. I just believe >>> that the constancy of having the client id parameter is worth the >>> potential small amount duplicate data in some cases. It's just a -00 >>> draft though and if the WG wants to proceed with this document, we >>> seek further input and work towards some consensus. >>> >>> >>> >>> _______________________________________________ >>> 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 --------------2B4D02C9812810AB04DD4778 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Yes, I elided the certificate issuance process. The point remains the same: you're not going to be submitting a CSR to the same party you're getting your client_id from, usually. If the draft assumes that, then it's incredibly limiting.


Do people really use separate TLS client certs for separate connections in the wild? I've personally never seen that. What I've seen is that a piece of software gets its certificate that it uses to make whatever connections it needs to make.


 -- Justin


On 11/3/2016 8:48 AM, Jim Manico wrote:
Just to be clear, the relationship should more like...

AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.

> The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 

This seems like a bad idea. I suggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On Nov 3, 2016, at 8:41 AM, Justin Richer <jricher@mit.edu> wrote:

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.

Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

I do think that more examples and guidance are warranted, though, to help AS developers.

 -- Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explicit and that it be good to do so.

 
When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
 

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

 
I´m not saying it is a bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



_______________________________________________
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

--------------2B4D02C9812810AB04DD4778-- From nobody Thu Nov 3 07:38:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C2D129A80 for ; Thu, 3 Nov 2016 07:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufJQQ3AilZI6 for ; Thu, 3 Nov 2016 07:38:10 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665A9129A78 for ; Thu, 3 Nov 2016 07:31:44 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o68so58899556qkf.3 for ; Thu, 03 Nov 2016 07:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YDBkHLSa1Bn+UuxKtsYljy2QDadYWz3oXQOFLVvJwRE=; b=KAPPg2GqLQ5Otp2GVUeVdpkD62QrshZJgG9f2dulnCyX5RaAkxOWeBRChLHgU5LBVq smtLIZg8McDjvDIk8wTkU2QXeFixF13lBbOIUcZlmnWdZP4QZ0doNfQkXmhyaFV734uc 6VfOm1bN/K+f017QTNMcLkK1csP4rtjktTRTHHtRRgHqev0T4zN6Uuy5iC+Lh2N+urKp eNYIaCWnOMw4VQ3aB6sqB/YNH2SdLZolfQvka+HJjnZzlbdZ5tZRxMCB7+ICFFl28J8K rhwanjG5lqocyprNISXQAWFhhzLsEdHe32fAIKrj8gVntknap0s50E3ENiD7O7ahfFHI i6DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YDBkHLSa1Bn+UuxKtsYljy2QDadYWz3oXQOFLVvJwRE=; b=MIBsVVdj6JgLLTUknoxHcuJXY+zYck9zgNGL1fpVN5hfVN6uPI4S9ObnWMxLlvybDM +xymi9ZlCi1Xrp9rZ3lyZ4oT1i2tVRjDWDmwlLTHL5MdUaIcFnmYreVZWtdaGUrEAYpy lP+RLHUOuQ9Fb+FihV3lc50uugk33dtFl0Uy+CXx5IJxF0FL7L0RxHQU+DBX/KKAj8tn 4oTtarkFoIuLr/oWY1ptW2+TbdI866uFheB0o9zPGdzzg9vKTR3brUlytIaZ4DPvC1YC 3P5BNn+9HGe1TwVjgB2crMFJDH6em9nCm17XxF9dED6dd6rq6+Htvy3vENcqMa9j0465 IhUw== X-Gm-Message-State: ABUngvevBPFj0sMdolsiRxebeMOYP65dmnoKP2l7yInh0/5gOfKLsOLGoqm4W7QlXfoPXhIV X-Received: by 10.55.137.3 with SMTP id l3mr7939731qkd.128.1478183503137; Thu, 03 Nov 2016 07:31:43 -0700 (PDT) Received: from [172.16.60.144] (modemcable085.143-176-173.mc.videotron.ca. [173.176.143.85]) by smtp.gmail.com with ESMTPSA id w12sm4554021qka.4.2016.11.03.07.31.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 07:31:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-214CADEC-1C0A-468B-956C-B8F85EF07B26 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14B100) In-Reply-To: <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> Date: Thu, 3 Nov 2016 10:31:39 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> To: Justin Richer Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:38:11 -0000 --Apple-Mail-214CADEC-1C0A-468B-956C-B8F85EF07B26 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Justin. I use several security intel services and they all have diffe= rent cert delivery mechanisms for mutual TLS. It's =E2=80=A2rare=E2=80=A2 fo= r services to let clients choose certs, they are usually assigned to users b= y each service from my experience. Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Nov 3, 2016, at 8:51 AM, Justin Richer wrote: >=20 > Yes, I elided the certificate issuance process. The point remains the same= : you're not going to be submitting a CSR to the same party you're getting y= our client_id from, usually. If the draft assumes that, then it's incredibly= limiting. >=20 >=20 > Do people really use separate TLS client certs for separate connections in= the wild? I've personally never seen that. What I've seen is that a piece o= f software gets its certificate that it uses to make whatever connections it= needs to make. >=20 >=20 > -- Justin >=20 >> On 11/3/2016 8:48 AM, Jim Manico wrote: >> Just to be clear, the relationship should more like... >>=20 >> AS issues public key to clients, or client sends public key to AS. The au= thorities job is NOT to give the client the public key, but to sign the publ= ic key for authenticity. It's bad practice to accept the full cert (pub key+= signature) from an authority. If an authority is creating your public key, t= hey are also creating your private key.... bad. >>=20 >> > The client will use the same cert across multiple connections, possibly= multiple AS's, but the same isn't true of the client_id.=20 >>=20 >> This seems like a bad idea. I suggest a separate key/signature for each s= ervice. >> -- >> Jim Manico >> @Manicode >> Secure Coding Education >> +1 (808) 652-3805 >>=20 >> On Nov 3, 2016, at 8:41 AM, Justin Richer wrote: >>=20 >>> I agree that the client_id is unlikely to be found inside the certificat= e itself. The client_id is issued by the authorization server for the client= to use at that single AS. The certificate is issued by the CA for the clien= t to use on any connection. The AS and CA are not likely to be the same syst= em in most deployments. The client will use the same cert across multiple co= nnections, possibly multiple AS's, but the same isn't true of the client_id.= =20 >>> Additionally, I think we want to allow for a binding of a self-signed ce= rtificate using dynamic registration, much the way that we already allow bin= ding of a client-generated JWK today.=20 >>> I do think that more examples and guidance are warranted, though, to hel= p AS developers. >>>=20 >>> -- Justin >>>=20 >>>> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>>>=20 >>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wr= ote: >>>>>=20 >>>>> I agree it is written so that the connection to the certificate is imp= licitly required but I think it would be better if it was explicit written s= ince the lack of a connection would result in a potential security hole. >>>>=20 >>>> That's fair. I agree it can be made more explicit and that it be good t= o do so.=20 >>>>=20 >>>> =20 >>>>> When it comes to the client_id I think subject common name or maybe su= bject serial numbers will be the common location, and I think an example wou= ld be valuable. >>>>> =20 >>>>=20 >>>> In my experience and the way we built support for mutual TLS OAuth clie= nt auth the client_id value does not appear in the certificate anywhere. I'm= not saying it can't happen but don't think it's particularly common.=20 >>>>=20 >>>> I can look at adding some examples, if there's some consensus that they= 'd be useful and this document moves forward.=20 >>>>=20 >>>> =20 >>>>>=20 >>>>> I=C2=B4m not saying it is a bad Idea just that I would prefer if it wa= s not a MUST.=20 >>>>> With very limited addition of code it is just as easy to get the certi= ficate attribute for client id as it is to get it from the HTTP request data= (at least in java). I also think that with the requirement to match the inc= oming certificate in some way one has to read out the certificate that was u= sed to establish the connection to do some kind of matching. >>>>>=20 >>>>=20 >>>> Getting data out of the certificate isn't a concern. I just believe tha= t the constancy of having the client id parameter is worth the potential sma= ll amount duplicate data in some cases. It's just a -00 draft though and if t= he WG wants to proceed with this document, we seek further input and work to= wards some consensus.=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 >=20 --Apple-Mail-214CADEC-1C0A-468B-956C-B8F85EF07B26 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Justin. I use several security i= ntel services and they all have different cert delivery mechanisms for mutua= l TLS. It's =E2=80=A2rare=E2=80=A2 for services to let clients choose certs,= they are usually assigned to users by each service from my experience.

Alo= ha,
--
Jim Manico
@Manicode
Secure Cod= ing Education
+1 (808) 652-3805

On Nov 3, 2016= , at 8:51 AM, Justin Richer <jricher@m= it.edu> wrote:

=20 =20 =20

Yes, I elided the certificate issuance process. The point remains the same: you're not going to be submitting a CSR to the same party you're getting your client_id from, usually. If the draft assumes that, then it's incredibly limiting.


Do people really use separate TLS client certs for separate connections in the wild? I've personally never seen that. What I've seen is that a piece of software gets its certificate that it uses to make whatever connections it needs to make.


 -- Justin


On 11/3/2016 8:48 AM, Jim Manico wrote:
Just to be clear, the relationship should more like...

AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.

> The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 

This seems like a bad idea. I suggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On Nov 3, 2016, at 8:41 AM, Justin Richer <jricher@mit.edu> wrote:

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.

Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

I do think that more examples and guidance are warranted, though, to help AS developers.

 -- Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explicit and that it be good to do so.
 
When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
 

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

 
I=C2=B4m not saying it is a bad Idea just tha= t I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



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

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

=20
= --Apple-Mail-214CADEC-1C0A-468B-956C-B8F85EF07B26-- From nobody Thu Nov 3 09:32:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09810129505 for ; Thu, 3 Nov 2016 09:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0g165ILPFsN for ; Thu, 3 Nov 2016 09:32:51 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 4E209129658 for ; Thu, 3 Nov 2016 09:32:50 -0700 (PDT) X-AuditID: 1209190e-d3fff70000002f99-45-581b66b0729f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 82.23.12185.0B66B185; Thu, 3 Nov 2016 12:32:49 -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 uA3GWmDK017679; Thu, 3 Nov 2016 12:32:48 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uA3GWjXn025847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Nov 2016 12:32:46 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_8ECDA5C2-45FD-47E9-BC4D-0F17EBD3CF76" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Thu, 3 Nov 2016 12:32:45 -0400 Message-Id: <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> To: Jim Manico X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixCmqrLsxTTrCYNdjbovV/28yWrzYf5Dd 4uTbV2wWn28dZrX4v/QUkwOrx4t/exg9liz5yeTxfGc/k0fjjAeMHnePXmQJYI3isklJzcks Sy3St0vgyji6bR5LwY25jBW9O/axNzD+Kehi5OSQEDCRmPVpGxOILSTQxiQx+3JMFyMXkL2B UWLzlzY2COcBk8Te7dtZuhg5OJgFEiTef+IGaeAV0JPYtP4tWLMwUPjMq3Ywm01AVWL6mhYw m1PAQeL6u+csIDaLgIpE38KT7CA2s8AdRontt2Ig5lhJzNj8CGpXF5vEgfetYA0iAooSB/Y0 MUFcKivx5OQilgmM/LMQzpiF5IxZYGO1JZYtfM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMsim5 Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxjBUSHJt4NxUoP3IUYBDkYlHl4HH+kIIdbE suLK3EOMkhxMSqK8i2OAQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4NyUC5XhTEiurUovyYVLS HCxK4rz/3b6GCwmkJ5akZqemFqQWwWRlODiUJHgVgNEvJFiUmp5akZaZU4KQZuLgBBnOAzS8 IxVkeHFBYm5xZjpE/hSjopQ47xOQhABIIqM0D64XlLQS3h42fcUoDvSKMC83yAoeYMKD634F NJgJaLB5kgTI4JJEhJRUA2OXw7qJ1+YYpCgnXJ7hsepz5o/k/1MuVv6+/H5Pl3n+O9sXibvt DRsFxbwfvGDND9M3PFZQ/Hjv0dkMiel9kn3OM3i27dubcpBD+ETRoqCJwXuz13L7/9XY/Cbl 9Z33pZUMi0qKeF4v5N1g9kD36Sv3cveMzddTb7XvMCtcwZbF3p3y/t/6oJVKLMUZiYZazEXF iQB4ZDzpNQMAAA== Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 16:32:55 -0000 --Apple-Mail=_8ECDA5C2-45FD-47E9-BC4D-0F17EBD3CF76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jim, In those circumstances, are the clients generally calling multiple = different services? Or just one? For those that call multiple services, = are they using multiple (different) client certificates? I=E2=80=99m not saying the client would issue its own cert in all cases = =E2=80=94 much more common is what I=E2=80=99ve seen, with clients being = assigned a certificate from a trusted CA, and then services that the = client talks to being told to trust that CA and also assign the CN/DN of = the cert a set of privileges. What I *haven=E2=80=99t* seen is a client = being issued multiple certificates to talk to multiple systems. That = latter case is common enough in the OAuth world that I wouldn=E2=80=99t = want us to paint ourselves in a corner. =E2=80=94 Justin > On Nov 3, 2016, at 10:31 AM, Jim Manico wrote: >=20 > Thanks Justin. I use several security intel services and they all have = different cert delivery mechanisms for mutual TLS. It's =E2=80=A2rare=E2=80= =A2 for services to let clients choose certs, they are usually assigned = to users by each service from my experience. >=20 > Aloha, > -- > Jim Manico > @Manicode > Secure Coding Education > +1 (808) 652-3805 >=20 > On Nov 3, 2016, at 8:51 AM, Justin Richer > wrote: >=20 >> Yes, I elided the certificate issuance process. The point remains the = same: you're not going to be submitting a CSR to the same party you're = getting your client_id from, usually. If the draft assumes that, then = it's incredibly limiting. >>=20 >>=20 >> Do people really use separate TLS client certs for separate = connections in the wild? I've personally never seen that. What I've seen = is that a piece of software gets its certificate that it uses to make = whatever connections it needs to make. >>=20 >>=20 >> -- Justin >>=20 >> On 11/3/2016 8:48 AM, Jim Manico wrote: >>> Just to be clear, the relationship should more like... >>>=20 >>> AS issues public key to clients, or client sends public key to AS. = The authorities job is NOT to give the client the public key, but to = sign the public key for authenticity. It's bad practice to accept the = full cert (pub key+signature) from an authority. If an authority is = creating your public key, they are also creating your private key.... = bad. >>>=20 >>> > The client will use the same cert across multiple connections, = possibly multiple AS's, but the same isn't true of the client_id.=20 >>>=20 >>> This seems like a bad idea. I suggest a separate key/signature for = each service. >>> -- >>> Jim Manico >>> @Manicode >>> Secure Coding Education >>> +1 (808) 652-3805 >>>=20 >>> On Nov 3, 2016, at 8:41 AM, Justin Richer > wrote: >>>=20 >>>> I agree that the client_id is unlikely to be found inside the = certificate itself. The client_id is issued by the authorization server = for the client to use at that single AS. The certificate is issued by = the CA for the client to use on any connection. The AS and CA are not = likely to be the same system in most deployments. The client will use = the same cert across multiple connections, possibly multiple AS's, but = the same isn't true of the client_id.=20 >>>> Additionally, I think we want to allow for a binding of a = self-signed certificate using dynamic registration, much the way that we = already allow binding of a client-generated JWK today.=20 >>>> I do think that more examples and guidance are warranted, though, = to help AS developers. >>>>=20 >>>> -- Justin >>>>=20 >>>> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>>>>=20 >>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman > wrote: >>>>>=20 >>>>> I agree it is written so that the connection to the certificate is = implicitly required but I think it would be better if it was explicit = written since the lack of a connection would result in a potential = security hole. >>>>>=20 >>>>> That's fair. I agree it can be made more explicit and that it be = good to do so.=20 >>>>>=20 >>>>> =20 >>>>> When it comes to the client_id I think subject common name or = maybe subject serial numbers will be the common location, and I think an = example would be valuable. >>>>> =20 >>>>>=20 >>>>> In my experience and the way we built support for mutual TLS OAuth = client auth the client_id value does not appear in the certificate = anywhere. I'm not saying it can't happen but don't think it's = particularly common.=20 >>>>>=20 >>>>> I can look at adding some examples, if there's some consensus that = they'd be useful and this document moves forward.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I=C2=B4m not saying it is a bad Idea just that I would prefer if = it was not a MUST.=20 >>>>> With very limited addition of code it is just as easy to get the = certificate attribute for client id as it is to get it from the HTTP = request data (at least in java). I also think that with the requirement = to match the incoming certificate in some way one has to read out the = certificate that was used to establish the connection to do some kind of = matching. >>>>>=20 >>>>>=20 >>>>> Getting data out of the certificate isn't a concern. I just = believe that the constancy of having the client id parameter is worth = the potential small amount duplicate data in some cases. It's just a -00 = draft though and if the WG wants to proceed with this document, we seek = further input and work towards some consensus.=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 = >>=20 --Apple-Mail=_8ECDA5C2-45FD-47E9-BC4D-0F17EBD3CF76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jim,

In = those circumstances, are the clients generally calling multiple = different services? Or just one? For those that call multiple services, = are they using multiple (different) client certificates?

I=E2=80=99m not saying = the client would issue its own cert in all cases =E2=80=94 much more = common is what I=E2=80=99ve seen, with clients being assigned a = certificate from a trusted CA, and then services that the client talks = to being told to trust that CA and also assign the CN/DN of the cert a = set of privileges. What I *haven=E2=80=99t* seen is a client being = issued multiple certificates to talk to multiple systems. That latter = case is common enough in the OAuth world that I wouldn=E2=80=99t want us = to paint ourselves in a corner.

 =E2=80=94 Justin

On Nov 3, 2016, at 10:31 AM, Jim Manico <jim@manicode.com> = wrote:

Thanks Justin. I = use several security intel services and they all have different cert = delivery mechanisms for mutual TLS. It's =E2=80=A2rare=E2=80=A2 for = services to let clients choose certs, they are usually assigned to users = by each service from my experience.

Aloha,
--
Jim Manico
@Manicode
Secure Coding = Education
+1 (808) 652-3805

On Nov 3, 2016, at 8:51 AM, Justin Richer = <jricher@mit.edu> = wrote:

Yes, I elided the certificate = issuance process. The point remains the same: you're not going to be submitting a CSR to the same party you're getting your client_id from, usually. If the draft assumes that, then it's incredibly limiting.


Do people really use separate TLS client certs for = separate connections in the wild? I've personally never seen that. What I've seen is that a piece of software gets its certificate that it uses to make whatever connections it needs to make.


 -- Justin


On 11/3/2016 8:48 AM, Jim Manico = wrote:
=20
Just to be clear, the relationship should more = like...

AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.

> The client will use the = same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 

This seems like a bad idea. I suggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On Nov 3, 2016, at 8:41 AM, Justin Richer <jricher@mit.edu> wrote:

I agree that the client_id is = unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.

Additionally, I think we want to allow for a = binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

I do think that more examples and guidance = are warranted, though, to help AS developers.

 -- = Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:

On Sun, Oct 30, 2016 at 9:27 = AM, Samuel Erdtman <samuel@erdtman.se> wrote:

I agree it is written so that = the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made = more explicit and that it be good to do so.

 
When it comes to the client_id = I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
 

In my experience and the way we built = support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

 
=

I=C2=B4m not saying it is a = bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of = matching.


Getting data out of the certificate = isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



_______________________________________________
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

= --Apple-Mail=_8ECDA5C2-45FD-47E9-BC4D-0F17EBD3CF76-- From nobody Thu Nov 3 09:40:57 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008CE129658 for ; Thu, 3 Nov 2016 09:40:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hh4v_Dgd4QP for ; Thu, 3 Nov 2016 09:40:50 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA0712949B for ; Thu, 3 Nov 2016 09:40:49 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id p16so31822712qta.0 for ; Thu, 03 Nov 2016 09:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=8oocJq4lC48hOxpXwyfT6pQfNiCqftjT+nbHLtcwAZ4=; b=gHK3RWbbFZ0ILtTF61pXh0TkigVLodKZphhJrv7YxIvam5sZWfV9rMBHLeuotQx5Ex LISNksvKQfhCKKwVgdlr+VTA2oAVbhjRN/aVSKZefgVTybUu91cGhbEP0h4/PX6glr40 66aUJC+563225hyMiJQ3LtKxHWshPIz67Xkfkzr0A1zc94DjbC0Je2tYa0/Hur8WFlm5 4juW1osrSEwnWdTiXUujo0FV/hzaSmRr23yzX1yeSKKcMawR0ATid4VstH5N/mq4AmJ2 ihcks99qXrlfa69exQJcBzWgh+ZWkiuoO7q3fjoDpASAj8ZkK3GHUwMS+EWL+GBSYQlJ nytg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=8oocJq4lC48hOxpXwyfT6pQfNiCqftjT+nbHLtcwAZ4=; b=TGBlzQeS/zOJHzgxjXrfOowKwrwErszgX2jfS8WdKKpH0oGdRhKH6dvh1jwisB2zeC GNxzn/e+lkwiKT/wbgw8os4+3vANj35yngkIcacyOw1I5rZajcZq0KF78s4hBGoGWQXS 9YmeWFZ+bMJFxe6iDjbzB8GTmtAucgXi+VJo4iFVWEyp2bqmngULD6UFkQWBoySG+BvW 5PDcmUxNS+8C+1fXubEEtTS2p5kOXtQdhazTCBTQ6lV6kD1iF2SsivLY2kHDTHjqHLRe sZwoD6Jus6FHeeTS6/uF7ZCoNvJZTFsqoMVzZAHNCETGLsL0Kuu7VvckAdaWNzMzlJuA 1IHQ== X-Gm-Message-State: ABUngvdwfyVzAq+ic9rixVy26SA2m4i3PYkdXJAHR9oCZYmz9j8GjeeHUb6MYtIHD9k980rc X-Received: by 10.200.49.41 with SMTP id g38mr8363306qtb.99.1478191248377; Thu, 03 Nov 2016 09:40:48 -0700 (PDT) Received: from heembo.local (modemcable085.143-176-173.mc.videotron.ca. [173.176.143.85]) by smtp.googlemail.com with ESMTPSA id b94sm4889518qkb.16.2016.11.03.09.40.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 09:40:47 -0700 (PDT) To: Justin Richer References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu> From: Jim Manico Message-ID: <282a8209-d597-4724-0bc6-c0c772f2cee0@manicode.com> Date: Thu, 3 Nov 2016 12:40:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu> Content-Type: multipart/alternative; boundary="------------7A2BE04C6AF5F963911E2591" Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 16:40:55 -0000 This is a multi-part message in MIME format. --------------7A2BE04C6AF5F963911E2591 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > In those circumstances, are the clients generally calling multiple different services? Or just one? For those that call multiple services, are they using multiple (different) client certificates? Ah, good point. I hear you now. I personally like the idea of "one cert per service" so I can selectively manage each access separately, but I understand where you are coming from and it makes sense. Thanks for taking the time to respectfully explain your perspective and provide me with a little education. :) ALOHA, Jim Manico On 11/3/16 12:32 PM, Justin Richer wrote: > Jim, > > In those circumstances, are the clients generally calling multiple > different services? Or just one? For those that call multiple > services, are they using multiple (different) client certificates? > > I=E2=80=99m not saying the client would issue its own cert in all cases= =E2=80=94 much > more common is what I=E2=80=99ve seen, with clients being assigned a > certificate from a trusted CA, and then services that the client talks > to being told to trust that CA and also assign the CN/DN of the cert a > set of privileges. What I *haven=E2=80=99t* seen is a client being issu= ed > multiple certificates to talk to multiple systems. That latter case is > common enough in the OAuth world that I wouldn=E2=80=99t want us to pai= nt > ourselves in a corner. > > =E2=80=94 Justin > >> On Nov 3, 2016, at 10:31 AM, Jim Manico > > wrote: >> >> Thanks Justin. I use several security intel services and they all >> have different cert delivery mechanisms for mutual TLS. It's =E2=80=A2= rare=E2=80=A2 >> for services to let clients choose certs, they are usually assigned >> to users by each service from my experience. >> >> Aloha, >> -- >> Jim Manico >> @Manicode >> Secure Coding Education >> +1 (808) 652-3805 >> >> On Nov 3, 2016, at 8:51 AM, Justin Richer > > wrote: >> >>> Yes, I elided the certificate issuance process. The point remains >>> the same: you're not going to be submitting a CSR to the same party >>> you're getting your client_id from, usually. If the draft assumes >>> that, then it's incredibly limiting. >>> >>> >>> Do people really use separate TLS client certs for separate >>> connections in the wild? I've personally never seen that. What I've >>> seen is that a piece of software gets its certificate that it uses >>> to make whatever connections it needs to make. >>> >>> >>> -- Justin >>> >>> >>> On 11/3/2016 8:48 AM, Jim Manico wrote: >>>> Just to be clear, the relationship should more like... >>>> >>>> AS issues public key to clients, or client sends public key to AS. >>>> The authorities job is NOT to give the client the public key, but >>>> to sign the public key for authenticity. It's bad practice to >>>> accept the full cert (pub key+signature) from an authority. If an >>>> authority is creating your public key, they are also creating your >>>> private key.... bad. >>>> >>>> > The client will use the same cert across multiple connections, >>>> possibly multiple AS's, but the same isn't true of the client_id.=20 >>>> >>>> This seems like a bad idea. I suggest a separate key/signature for >>>> each service. >>>> -- >>>> Jim Manico >>>> @Manicode >>>> Secure Coding Education >>>> +1 (808) 652-3805 >>>> >>>> On Nov 3, 2016, at 8:41 AM, Justin Richer >>> > wrote: >>>> >>>>> I agree that the client_id is unlikely to be found inside the >>>>> certificate itself. The client_id is issued by the authorization >>>>> server for the client to use at that single AS. The certificate is >>>>> issued by the CA for the client to use on any connection. The AS >>>>> and CA are not likely to be the same system in most deployments. >>>>> The client will use the same cert across multiple connections, >>>>> possibly multiple AS's, but the same isn't true of the client_id. >>>>> >>>>> Additionally, I think we want to allow for a binding of a >>>>> self-signed certificate using dynamic registration, much the way >>>>> that we already allow binding of a client-generated JWK today. >>>>> >>>>> I do think that more examples and guidance are warranted, though, >>>>> to help AS developers. >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>>>>> >>>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman >>>>>> > wrote: >>>>>> >>>>>> >>>>>> I agree it is written so that the connection to the >>>>>> certificate is implicitly required but I think it would be >>>>>> better if it was explicit written since the lack of a >>>>>> connection would result in a potential security hole. >>>>>> >>>>>> >>>>>> That's fair. I agree it can be made more explicit and that it be >>>>>> good to do so. >>>>>> >>>>>> =20 >>>>>> >>>>>> When it comes to the client_id I think subject common name or >>>>>> maybe subject serial numbers will be the common location, and >>>>>> I think an example would be valuable. >>>>>> =20 >>>>>> >>>>>> >>>>>> In my experience and the way we built support for mutual TLS >>>>>> OAuth client auth the client_id value does not appear in the >>>>>> certificate anywhere. I'm not saying it can't happen but don't >>>>>> think it's particularly common. >>>>>> >>>>>> I can look at adding some examples, if there's some consensus >>>>>> that they'd be useful and this document moves forward. >>>>>> >>>>>> =20 >>>>>> >>>>>> >>>>>> I=C2=B4m not saying it is a bad Idea just that I would prefer = if >>>>>> it was not a MUST. >>>>>> With very limited addition of code it is just as easy to get >>>>>> the certificate attribute for client id as it is to get it >>>>>> from the HTTP request data (at least in java). I also think >>>>>> that with the requirement to match the incoming certificate >>>>>> in some way one has to read out the certificate that was used >>>>>> to establish the connection to do some kind of matching. >>>>>> >>>>>> >>>>>> Getting data out of the certificate isn't a concern. I just >>>>>> believe that the constancy of having the client id parameter is >>>>>> worth the potential small amount duplicate data in some cases. >>>>>> It's just a -00 draft though and if the WG wants to proceed with >>>>>> this document, we seek further input and work towards some >>>>>> consensus. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Jim Manico Manicode Security https://www.manicode.com --------------7A2BE04C6AF5F963911E2591 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

> In those circumstances, are the clients generally calling multiple different services? Or just one? For those that call multiple services, are they using multiple (different) client certificates?

Ah, good point. I hear you now.  I personally like the idea of "one cert per service" so I can selectively manage each access separately, but I understand where you are coming from and it makes sense.

Thanks for taking the time to respectfully explain your perspective and provide me with a little education. :)

ALOHA,

Jim Manico


On 11/3/16 12:32 PM, Justin Richer wrote:
Jim,

In those circumstances, are the clients generally calling multiple different services? Or just one? For those that call multiple services, are they using multiple (different) client certificates?

I’m not saying the client would issue its own cert in all cases — much more common is what I’ve seen, with clients being assigned a certificate from a trusted CA, and then services that the client talks to being told to trust that CA and also assign the CN/DN of the cert a set of privileges. What I *haven’t* seen is a client being issued multiple certificates to talk to multiple systems. That latter case is common enough in the OAuth world that I wouldn’t want us to paint ourselves in a corner.

 — Justin

On Nov 3, 2016, at 10:31 AM, Jim Manico <jim@manicode.com> wrote:

Thanks Justin. I use several security intel services and they all have different cert delivery mechanisms for mutual TLS. It's •rare• for services to let clients choose certs, they are usually assigned to users by each service from my experience.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On Nov 3, 2016, at 8:51 AM, Justin Richer <jricher@mit.edu> wrote:

Yes, I elided the certificate issuance process. The point remains the same: you're not going to be submitting a CSR to the same party you're getting your client_id from, usually. If the draft assumes that, then it's incredibly limiting.


Do people really use separate TLS client certs for separate connections in the wild? I've personally never seen that. What I've seen is that a piece of software gets its certificate that it uses to make whatever connections it needs to make.


 -- Justin


On 11/3/2016 8:48 AM, Jim Manico wrote:
Just to be clear, the relationship should more like...

AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.

> The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 

This seems like a bad idea. I suggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

On Nov 3, 2016, at 8:41 AM, Justin Richer <jricher@mit.edu> wrote:

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.

Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

I do think that more examples and guidance are warranted, though, to help AS developers.

 -- Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explicit and that it be good to do so.

 
When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
 

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

 
I´m not saying it is a bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



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

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



-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------7A2BE04C6AF5F963911E2591-- From nobody Thu Nov 3 09:48:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934A4129497 for ; Thu, 3 Nov 2016 09:48:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqp29MEQsZD6 for ; Thu, 3 Nov 2016 09:48:18 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47521293F3 for ; Thu, 3 Nov 2016 09:48:17 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id b14so44177674lfg.2 for ; Thu, 03 Nov 2016 09:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q8iGafBmmE1eNJMHNwTIi7KaBvuqshdBJPSB7Q/3CKU=; b=AmZeZnCmzXxtftqQj1znB4ZUD9C+pzwuJOvkWofaiyZs+6drRneS5Uc+6HRqnqtJkp yGkYBez/nlXH9+hX9TX0eRlxDmAvdtqIdQA6OkD36vY4768NCVnRkpR4JcLL/VuB3TFn pb0OZypkUX2KhqCXA52J4JAzQdjQc4SoG+uWV9tRSgSQtMsXT47MAT+qaS0ucJaEAbra QTOED7Mx4ERywL4cADvBB9AuvboB4gfXk24i9Jy2XWKXNapVEbCy0ACZTIgU0H6TIWKk 2H9fMUkvsK2c+adtL8Bk1MMgWrlIU2JPos4ainJRLyAKik+gyMQPihNy9pzzQc8jwbrV FJEw== 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; bh=Q8iGafBmmE1eNJMHNwTIi7KaBvuqshdBJPSB7Q/3CKU=; b=mY+p/oSiJipbuwZ+H5LzTY+bHWdq1X8Ji57eZ2zkBoBtvRdDvKaRb8dawIa4NK2pz/ 2U47eoO0Pbpnclkm6EaIytHhnke0TflwQZ/M1+a41Z0tTGyrSIfp9YiXJ46IXTWs3xzv 64q3mCBJRQ6HMv9/TPFjD4GC5cJS3UV2gt23gsT/Ofy9ln8WixbU4h8Y3ZXmQ4UsDlyh d5N7CbcnqnXolwlZQbShYT35V3zXSvEEtwAnOyc5fgsnKqQ7pKoCxWajEcuEFkxl2Bim DCUAji0WZq0ZwiXamp6Rs9TlYgc27OKED8jXlED32TPXKnNHKM+SSs3CBqfO6BfyY7dC U3GQ== X-Gm-Message-State: ABUngvfW5Lg4pvPMQ4igSxUVM/4NRj1GQ1K1L68TnbMpQOvXlMNpYDrrzcHva5IKLh/0Z+NHlkd1uwFZ1iw3Lg== X-Received: by 10.194.222.202 with SMTP id qo10mr8252077wjc.115.1478191695552; Thu, 03 Nov 2016 09:48:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.172.232 with HTTP; Thu, 3 Nov 2016 09:48:14 -0700 (PDT) In-Reply-To: <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu> From: Samuel Erdtman Date: Thu, 3 Nov 2016 17:48:14 +0100 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c3ba62ec7ee90540685294 Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 16:48:20 -0000 --001a11c3ba62ec7ee90540685294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I can see your point, maybe the client_id will not be in the certificate. If I had an AS I would select to trust one or several CAs and then create certificate mappings between certificate serial number (or some other unique attribute in the certificate) and client_id. If I were to bind a specific certificate to a client_id I lose the flexibility of the PKI (maybe what you want). I think multiple certificates might not be a uncommon situation especially if you call ASs from different organizations because they will trust different CAs. //Samuel On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer wrote: > Jim, > > In those circumstances, are the clients generally calling multiple > different services? Or just one? For those that call multiple services, a= re > they using multiple (different) client certificates? > > I=E2=80=99m not saying the client would issue its own cert in all cases = =E2=80=94 much > more common is what I=E2=80=99ve seen, with clients being assigned a cert= ificate > from a trusted CA, and then services that the client talks to being told = to > trust that CA and also assign the CN/DN of the cert a set of privileges. > What I *haven=E2=80=99t* seen is a client being issued multiple certifica= tes to > talk to multiple systems. That latter case is common enough in the OAuth > world that I wouldn=E2=80=99t want us to paint ourselves in a corner. > > =E2=80=94 Justin > > On Nov 3, 2016, at 10:31 AM, Jim Manico wrote: > > Thanks Justin. I use several security intel services and they all have > different cert delivery mechanisms for mutual TLS. It's =E2=80=A2rare=E2= =80=A2 for services > to let clients choose certs, they are usually assigned to users by each > service from my experience. > > Aloha, > -- > Jim Manico > @Manicode > Secure Coding Education > +1 (808) 652-3805 > > On Nov 3, 2016, at 8:51 AM, Justin Richer wrote: > > Yes, I elided the certificate issuance process. The point remains the > same: you're not going to be submitting a CSR to the same party you're > getting your client_id from, usually. If the draft assumes that, then it'= s > incredibly limiting. > > > Do people really use separate TLS client certs for separate connections i= n > the wild? I've personally never seen that. What I've seen is that a piece > of software gets its certificate that it uses to make whatever connection= s > it needs to make. > > > -- Justin > > On 11/3/2016 8:48 AM, Jim Manico wrote: > > Just to be clear, the relationship should more like... > > AS issues public key to clients, or client sends public key to AS. The > authorities job is NOT to give the client the public key, but to sign the > public key for authenticity. It's bad practice to accept the full cert (p= ub > key+signature) from an authority. If an authority is creating your public > key, they are also creating your private key.... bad. > > > The client will use the same cert across multiple connections, possibly > multiple AS's, but the same isn't true of the client_id. > > This seems like a bad idea. I suggest a separate key/signature for each > service. > -- > Jim Manico > @Manicode > Secure Coding Education > +1 (808) 652-3805 > > On Nov 3, 2016, at 8:41 AM, Justin Richer wrote: > > I agree that the client_id is unlikely to be found inside the certificate > itself. The client_id is issued by the authorization server for the clien= t > to use at that single AS. The certificate is issued by the CA for the > client to use on any connection. The AS and CA are not likely to be the > same system in most deployments. The client will use the same cert across > multiple connections, possibly multiple AS's, but the same isn't true of > the client_id. > > Additionally, I think we want to allow for a binding of a self-signed > certificate using dynamic registration, much the way that we already allo= w > binding of a client-generated JWK today. > > I do think that more examples and guidance are warranted, though, to help > AS developers. > > -- Justin > > On 11/2/2016 5:03 PM, Brian Campbell wrote: > > > On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wrote= : > >> >> I agree it is written so that the connection to the certificate is >> implicitly required but I think it would be better if it was explicit >> written since the lack of a connection would result in a potential secur= ity >> hole. >> > > That's fair. I agree it can be made more explicit and that it be good to > do so. > > > >> When it comes to the client_id I think subject common name or maybe >> subject serial numbers will be the common location, and I think an examp= le >> would be valuable. >> >> > > In my experience and the way we built support for mutual TLS OAuth client > auth the client_id value does not appear in the certificate anywhere. I'm > not saying it can't happen but don't think it's particularly common. > > I can look at adding some examples, if there's some consensus that they'd > be useful and this document moves forward. > > > >> >> I=C2=B4m not saying it is a bad Idea just that I would prefer if it was = not a >> MUST. >> With very limited addition of code it is just as easy to get the >> certificate attribute for client id as it is to get it from the HTTP >> request data (at least in java). I also think that with the requirement = to >> match the incoming certificate in some way one has to read out the >> certificate that was used to establish the connection to do some kind of >> matching. >> >> > Getting data out of the certificate isn't a concern. I just believe that > the constancy of having the client id parameter is worth the potential > small amount duplicate data in some cases. It's just a -00 draft though a= nd > if the WG wants to proceed with this document, we seek further input and > work towards some consensus. > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --001a11c3ba62ec7ee90540685294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I can see your point, maybe the client_id will not be= in the certificate.
If I had an AS I would select to trust = one or several CAs and then create certificate mappings between certificate= serial number (or some other unique attribute in the certificate) and clie= nt_id. If I were to bind a specific certificate to a client_id I lose the f= lexibility of the PKI (maybe what you want).

I thin= k multiple certificates might not be a uncommon situation especially if you= call ASs from different organizations because they will trust different CA= s.

//Samuel


On Thu, Nov 3, 2016 at 5:32 PM, Ju= stin Richer <jricher@mit.edu> wrote:
Jim,

In tho= se circumstances, are the clients generally calling multiple different serv= ices? Or just one? For those that call multiple services, are they using mu= ltiple (different) client certificates?

I=E2=80=99= m not saying the client would issue its own cert in all cases =E2=80=94 muc= h more common is what I=E2=80=99ve seen, with clients being assigned a cert= ificate from a trusted CA, and then services that the client talks to being= told to trust that CA and also assign the CN/DN of the cert a set of privi= leges. What I *haven=E2=80=99t* seen is a client being issued multiple cert= ificates to talk to multiple systems. That latter case is common enough in = the OAuth world that I wouldn=E2=80=99t want us to paint ourselves in a cor= ner.

=C2=A0=E2=80=94 Justin
On Nov 3, 2016, at 10:31 AM, Jim Manic= o <jim@manicode.co= m> wrote:

Thanks Justin. I use several security intel services= and they all have different cert delivery mechanisms for mutual TLS. It= 9;s =E2=80=A2rare=E2=80=A2 for services to let clients choose certs, they a= re usually assigned to users by each service from my experience.
=
Aloha,
--
Jim Manico
@Manicode
Secure Coding Education

On Nov 3, 2016, at 8:51 AM, Justin Richer <jricher@mit.edu> wrote= :

Yes, I elided the certific= ate issuance process. The point remains the same: you're not going to be submitting a CSR to the same party you're getting your client_id from, usually. If the draft assumes that, then it's incredibly limiting.


Do people really use separate TLS client certs for separate connections in the wild? I've personally never seen that. What I've seen is that a piece of software gets its certificate that i= t uses to make whatever connections it needs to make.


=C2=A0-- Justin


On 11/3/2016 8:48 A= M, Jim Manico wrote:
=20
Just to be clear, the relationship should more like...

AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.

> The cl= ient will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.=C2=A0

This seems like a bad idea. I suggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education

On Nov 3, 2016, at 8:41 AM, Justin Richer <jricher@mit.edu> wrote:

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.

Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

I do think that more examples and guidance are warranted, though, to help AS developers.

=C2=A0-- Justin


On 11/2/2016 = 5:03 PM, Brian Campbell wrote:

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explici= t and that it be good to do so.

=C2=A0
When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
=C2=A0

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm no= t saying it can't happen but don't think it's particularly common.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

=C2=A0
I=C2=B4m not saying it is a bad Idea just th= at I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -0= 0 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus.


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

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

=20


--001a11c3ba62ec7ee90540685294-- From nobody Thu Nov 3 10:11:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7AE12955D for ; Thu, 3 Nov 2016 10:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh7a0Exk51g7 for ; Thu, 3 Nov 2016 10:11:25 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63054128E18 for ; Thu, 3 Nov 2016 10:11:25 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id c184so4850869wmd.0 for ; Thu, 03 Nov 2016 10:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=QeVqBrp1xGkB8XtGxWLhMe86L2MaNvVE3GnEbBp2g5k=; b=MF87cSjc2ZQq/mQNHuXKWQ1VyToR7D+fSQ9slNwEaeC56SH9wv3x8XdX/ABduE/4h1 uUs2JMCIx7s0F5bdBhG+SMP2KagPXABLaXawddBfMfWt3BWd3tMz6nxonqvzfd/h8Jp/ qDMyou3rSulu3v6bheKzLuStNjnmV13HBsXrec9mf37c+xnZC74KIYCyeVEe1osHWq6c 0wQJT7gOON27B9gW65YTcbezHVWglcdkxFEgnAeacxadChtqbZAnsI8QNtOEFMVn3RNw oHipYXBRSKN+UBp77UV0QpTuXpH5b4A1bUunj5SXhdpMljQtqUHNL7XJUxM4nDFTxFQw ZnVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QeVqBrp1xGkB8XtGxWLhMe86L2MaNvVE3GnEbBp2g5k=; b=Pz4yumyBa1XiJ1EPzq1Q4OmX8Sv+yEf/JTIuryZ8s751KEiqHVoDFiGxhYt9+f8kyi yLT5SPWibHgno5/qZPs5S2t2QoyVqyeG8JVdxyEcHkGfNSB9CAHOxwJpJ8XbUQk0N3af znecKz38SWETcaG5oADhGYkF5aGpYO0kpftj0CQ+GNMVEmYZlceVXfuNAYziARu8r79x LtM+dy3E4KvV891T+AgLb6SAHOc0f7O5MNDzv4QxEIF7ooN21IWkXFOFz0fWj+6IRIRw sb35AWwgmL6ma9gzEQHIyyIqFEUznKERFobs2udS6TaMVSro4vYS0byXjzrFq50Sw5Gv VqKg== X-Gm-Message-State: ABUngvcCY8zoBwVmjDLuTakp7URyikDJwHfz1S0Q5PLv8HeQdZItzBdfLPCiKL0hDWKY0w== X-Received: by 10.28.126.146 with SMTP id z140mr7660369wmc.84.1478193083509; Thu, 03 Nov 2016 10:11:23 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id k74sm10118110wmd.18.2016.11.03.10.11.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 10:11:22 -0700 (PDT) To: Samuel Erdtman , Justin Richer References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu> From: Sergey Beryozkin Message-ID: <613701d6-7857-1933-f385-0969b4b0c9ba@gmail.com> Date: Thu, 3 Nov 2016 17:11:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 17:11:28 -0000 Hi In our implementation we support the following scenario: - the client registers its public certificate during the client registration - next, mutual/two-way TLS is used, so AccessTokenService tries to figure out the client_id. At the moment it assumes the client_id is (Java) X509Certificate.getSubjectX500Principal().getName(). Next it retrieves a client with this name and compares the TLS client/peer certificate against the pre-registered one. I think it may be interesting to explore further if client_id can become optional based on what Samuel said. For example, indeed I can see how I can update our code to have a mapping between some of client certificate's properties and a client id stored within a Client registration. The question is how to find a given Client registration effectively given only a certificate, without an optional client_id. One would need to have a map between these client certificate attribute and client_id or Clients. Cheers, Sergey On 03/11/16 16:48, Samuel Erdtman wrote: > I can see your point, maybe the client_id will not be in the certificate. > If I had an AS I would select to trust one or several CAs and then > create certificate mappings between certificate serial number (or some > other unique attribute in the certificate) and client_id. If I were to > bind a specific certificate to a client_id I lose the flexibility of the > PKI (maybe what you want). > > I think multiple certificates might not be a uncommon situation > especially if you call ASs from different organizations because they > will trust different CAs. > > //Samuel > > > On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer > wrote: > > Jim, > > In those circumstances, are the clients generally calling multiple > different services? Or just one? For those that call multiple > services, are they using multiple (different) client certificates? > > Im not saying the client would issue its own cert in all cases > much more common is what Ive seen, with clients being assigned a > certificate from a trusted CA, and then services that the client > talks to being told to trust that CA and also assign the CN/DN of > the cert a set of privileges. What I *havent* seen is a client > being issued multiple certificates to talk to multiple systems. That > latter case is common enough in the OAuth world that I wouldnt want > us to paint ourselves in a corner. > > Justin > >> On Nov 3, 2016, at 10:31 AM, Jim Manico > > wrote: >> >> Thanks Justin. I use several security intel services and they all >> have different cert delivery mechanisms for mutual TLS. It's >> rare for services to let clients choose certs, they are usually >> assigned to users by each service from my experience. >> >> Aloha, >> -- >> Jim Manico >> @Manicode >> Secure Coding Education >> +1 (808) 652-3805 >> >> On Nov 3, 2016, at 8:51 AM, Justin Richer > > wrote: >> >>> Yes, I elided the certificate issuance process. The point remains >>> the same: you're not going to be submitting a CSR to the same >>> party you're getting your client_id from, usually. If the draft >>> assumes that, then it's incredibly limiting. >>> >>> >>> Do people really use separate TLS client certs for separate >>> connections in the wild? I've personally never seen that. What >>> I've seen is that a piece of software gets its certificate that >>> it uses to make whatever connections it needs to make. >>> >>> >>> -- Justin >>> >>> >>> On 11/3/2016 8:48 AM, Jim Manico wrote: >>>> Just to be clear, the relationship should more like... >>>> >>>> AS issues public key to clients, or client sends public key to >>>> AS. The authorities job is NOT to give the client the public >>>> key, but to sign the public key for authenticity. It's bad >>>> practice to accept the full cert (pub key+signature) from an >>>> authority. If an authority is creating your public key, they are >>>> also creating your private key.... bad. >>>> >>>> > The client will use the same cert across multiple connections, >>>> possibly multiple AS's, but the same isn't true of the client_id. >>>> >>>> This seems like a bad idea. I suggest a separate key/signature >>>> for each service. >>>> -- >>>> Jim Manico >>>> @Manicode >>>> Secure Coding Education >>>> +1 (808) 652-3805 >>>> >>>> On Nov 3, 2016, at 8:41 AM, Justin Richer >>> > wrote: >>>> >>>>> I agree that the client_id is unlikely to be found inside the >>>>> certificate itself. The client_id is issued by the >>>>> authorization server for the client to use at that single AS. >>>>> The certificate is issued by the CA for the client to use on >>>>> any connection. The AS and CA are not likely to be the same >>>>> system in most deployments. The client will use the same cert >>>>> across multiple connections, possibly multiple AS's, but the >>>>> same isn't true of the client_id. >>>>> >>>>> Additionally, I think we want to allow for a binding of a >>>>> self-signed certificate using dynamic registration, much the >>>>> way that we already allow binding of a client-generated JWK today. >>>>> >>>>> I do think that more examples and guidance are warranted, >>>>> though, to help AS developers. >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>>>>> >>>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman >>>>>> > wrote: >>>>>> >>>>>> >>>>>> I agree it is written so that the connection to the >>>>>> certificate is implicitly required but I think it would be >>>>>> better if it was explicit written since the lack of a >>>>>> connection would result in a potential security hole. >>>>>> >>>>>> >>>>>> That's fair. I agree it can be made more explicit and that it >>>>>> be good to do so. >>>>>> >>>>>> >>>>>> >>>>>> When it comes to the client_id I think subject common name >>>>>> or maybe subject serial numbers will be the common >>>>>> location, and I think an example would be valuable. >>>>>> >>>>>> >>>>>> >>>>>> In my experience and the way we built support for mutual TLS >>>>>> OAuth client auth the client_id value does not appear in the >>>>>> certificate anywhere. I'm not saying it can't happen but don't >>>>>> think it's particularly common. >>>>>> >>>>>> I can look at adding some examples, if there's some consensus >>>>>> that they'd be useful and this document moves forward. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Im not saying it is a bad Idea just that I would prefer >>>>>> if it was not a MUST. >>>>>> With very limited addition of code it is just as easy to >>>>>> get the certificate attribute for client id as it is to >>>>>> get it from the HTTP request data (at least in java). I >>>>>> also think that with the requirement to match the incoming >>>>>> certificate in some way one has to read out the >>>>>> certificate that was used to establish the connection to >>>>>> do some kind of matching. >>>>>> >>>>>> >>>>>> Getting data out of the certificate isn't a concern. I just >>>>>> believe that the constancy of having the client id parameter >>>>>> is worth the potential small amount duplicate data in some >>>>>> cases. It's just a -00 draft though and if the WG wants to >>>>>> proceed with this document, we seek further input and work >>>>>> towards some consensus. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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/ From nobody Fri Nov 4 10:06:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C281295E3 for ; Fri, 4 Nov 2016 10:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wnga_92g41ir for ; Fri, 4 Nov 2016 10:06:16 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50900129582 for ; Fri, 4 Nov 2016 10:06:16 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id o68so105049124qkf.3 for ; Fri, 04 Nov 2016 10:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BwNNrxbhOU6EuM3gyQUaDd8/4MIIhEfuRt8gA191Hjs=; b=yS1CxTUQwtl8DPJu+fOXEEsc6ryC3UBFKqM7ro4iL/cNjshQdpLaSIFC7tBJyJkQ0S mj+oIu/oJ/tBbXRuzCWscQd5rq/vDxWblYei4zrw+NXgn/aGQXKxZASj5VllilYY2R99 CxG0+fiBbYIsJGG3sonugrDjt4Tp3tTZ522TFvrHp+2qca6SrFlYiY96Op9YIEwH5GNR h8D17evFKTCZm853XBypaSQU7c+zjmSrbWR9+wpZefhUe23N8FCs3CIxhrPCh68RS/Xt Ui7QyIrCyfRffqjRCb5mIAhuDENv6iQhTDe9E4hbbYuff6hwqf9Da9BGzZqDOSSdTGqC 25Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BwNNrxbhOU6EuM3gyQUaDd8/4MIIhEfuRt8gA191Hjs=; b=ke6Epw+9tx81xLX8z+Eg8fEJu53vdvuwZDmw6Bhk6DQCPWAEjsfdU8rICCj8EkPi6V TohdJrxlgB/VmeDNjjczGjktUmj1aeBj/luWSPjLFRSNUUPxywFWX9fbtJDbD9enJDts wMBiESSfiJeh8Aw+tGC50xYdBKt8+pjiD7sRul18bKH9T2deG/egKiXgYALcyCG1Cwee BL/g2GR73gbupZXqodSbcye3ba8/21G44X7yZ0ROtOlA7u9LepvQkuC8lAgb4t2oxGMG zHrexbR0+xi0MEkz3amPzxCM9Crh0G7Fv3Eta3UWkuDFdzMdro8gf+Z4c5T39qlq7vY0 ZOaw== X-Gm-Message-State: ABUngve89u0ZqfrWT1DUdL79B9ua3uLuzi3ugcRvq4TZbGRnlxmwG1uzWfr0nEp92aaPKtvF X-Received: by 10.55.200.27 with SMTP id c27mr13351638qkj.276.1478279175052; Fri, 04 Nov 2016 10:06:15 -0700 (PDT) Received: from heembo.local (modemcable085.143-176-173.mc.videotron.ca. [173.176.143.85]) by smtp.googlemail.com with ESMTPSA id g63sm8012424qkf.47.2016.11.04.10.06.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 10:06:14 -0700 (PDT) To: Sergey Beryozkin , Samuel Erdtman , Justin Richer References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu> <613701d6-7857-1933-f385-0969b4b0c9ba@gmail.com> From: Jim Manico Message-ID: <5bdf0443-bc2a-fc2b-9105-bed7e8192925@manicode.com> Date: Fri, 4 Nov 2016 13:06:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <613701d6-7857-1933-f385-0969b4b0c9ba@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 17:06:18 -0000 You could also sign the client_id with your private cert and send it like normal OAuth requests... But I like the idea of mapping the client_id server-side to the cert as well. Now we're talking real security. Bearer tokens are so Q1-2016. :) Aloha, Jim On 11/3/16 1:11 PM, Sergey Beryozkin wrote: > Hi > > In our implementation we support the following scenario: > - the client registers its public certificate during the client > registration > > - next, mutual/two-way TLS is used, so AccessTokenService tries to > figure out the client_id. At the moment it assumes the client_id is > (Java) X509Certificate.getSubjectX500Principal().getName(). > > Next it retrieves a client with this name and compares the TLS > client/peer certificate against the pre-registered one. > > I think it may be interesting to explore further if client_id can > become optional based on what Samuel said. > > For example, indeed I can see how I can update our code to have a > mapping between some of client certificate's properties and a client > id stored within a Client registration. > > The question is how to find a given Client registration effectively > given only a certificate, without an optional client_id. One would > need to have a map between these client certificate attribute and > client_id or Clients. > > Cheers, Sergey > > > > On 03/11/16 16:48, Samuel Erdtman wrote: >> I can see your point, maybe the client_id will not be in the >> certificate. >> If I had an AS I would select to trust one or several CAs and then >> create certificate mappings between certificate serial number (or some >> other unique attribute in the certificate) and client_id. If I were to >> bind a specific certificate to a client_id I lose the flexibility of the >> PKI (maybe what you want). >> >> I think multiple certificates might not be a uncommon situation >> especially if you call ASs from different organizations because they >> will trust different CAs. >> >> //Samuel >> >> >> On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer > > wrote: >> >> Jim, >> >> In those circumstances, are the clients generally calling multiple >> different services? Or just one? For those that call multiple >> services, are they using multiple (different) client certificates? >> >> Im not saying the client would issue its own cert in all cases >> much more common is what Ive seen, with clients being assigned a >> certificate from a trusted CA, and then services that the client >> talks to being told to trust that CA and also assign the CN/DN of >> the cert a set of privileges. What I *havent* seen is a client >> being issued multiple certificates to talk to multiple systems. That >> latter case is common enough in the OAuth world that I wouldnt want >> us to paint ourselves in a corner. >> >> Justin >> >>> On Nov 3, 2016, at 10:31 AM, Jim Manico >> > wrote: >>> >>> Thanks Justin. I use several security intel services and they all >>> have different cert delivery mechanisms for mutual TLS. It's >>> rare for services to let clients choose certs, they are usually >>> assigned to users by each service from my experience. >>> >>> Aloha, >>> -- >>> Jim Manico >>> @Manicode >>> Secure Coding Education >>> +1 (808) 652-3805 >>> >>> On Nov 3, 2016, at 8:51 AM, Justin Richer >> > wrote: >>> >>>> Yes, I elided the certificate issuance process. The point remains >>>> the same: you're not going to be submitting a CSR to the same >>>> party you're getting your client_id from, usually. If the draft >>>> assumes that, then it's incredibly limiting. >>>> >>>> >>>> Do people really use separate TLS client certs for separate >>>> connections in the wild? I've personally never seen that. What >>>> I've seen is that a piece of software gets its certificate that >>>> it uses to make whatever connections it needs to make. >>>> >>>> >>>> -- Justin >>>> >>>> >>>> On 11/3/2016 8:48 AM, Jim Manico wrote: >>>>> Just to be clear, the relationship should more like... >>>>> >>>>> AS issues public key to clients, or client sends public key to >>>>> AS. The authorities job is NOT to give the client the public >>>>> key, but to sign the public key for authenticity. It's bad >>>>> practice to accept the full cert (pub key+signature) from an >>>>> authority. If an authority is creating your public key, they are >>>>> also creating your private key.... bad. >>>>> >>>>> > The client will use the same cert across multiple connections, >>>>> possibly multiple AS's, but the same isn't true of the client_id. >>>>> >>>>> This seems like a bad idea. I suggest a separate key/signature >>>>> for each service. >>>>> -- >>>>> Jim Manico >>>>> @Manicode >>>>> Secure Coding Education >>>>> +1 (808) 652-3805 >>>>> >>>>> On Nov 3, 2016, at 8:41 AM, Justin Richer >>>> > wrote: >>>>> >>>>>> I agree that the client_id is unlikely to be found inside the >>>>>> certificate itself. The client_id is issued by the >>>>>> authorization server for the client to use at that single AS. >>>>>> The certificate is issued by the CA for the client to use on >>>>>> any connection. The AS and CA are not likely to be the same >>>>>> system in most deployments. The client will use the same cert >>>>>> across multiple connections, possibly multiple AS's, but the >>>>>> same isn't true of the client_id. >>>>>> >>>>>> Additionally, I think we want to allow for a binding of a >>>>>> self-signed certificate using dynamic registration, much the >>>>>> way that we already allow binding of a client-generated JWK >>>>>> today. >>>>>> >>>>>> I do think that more examples and guidance are warranted, >>>>>> though, to help AS developers. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>>>>>> >>>>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman >>>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> I agree it is written so that the connection to the >>>>>>> certificate is implicitly required but I think it would be >>>>>>> better if it was explicit written since the lack of a >>>>>>> connection would result in a potential security hole. >>>>>>> >>>>>>> >>>>>>> That's fair. I agree it can be made more explicit and that it >>>>>>> be good to do so. >>>>>>> >>>>>>> >>>>>>> >>>>>>> When it comes to the client_id I think subject common name >>>>>>> or maybe subject serial numbers will be the common >>>>>>> location, and I think an example would be valuable. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In my experience and the way we built support for mutual TLS >>>>>>> OAuth client auth the client_id value does not appear in the >>>>>>> certificate anywhere. I'm not saying it can't happen but don't >>>>>>> think it's particularly common. >>>>>>> >>>>>>> I can look at adding some examples, if there's some consensus >>>>>>> that they'd be useful and this document moves forward. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Im not saying it is a bad Idea just that I would prefer >>>>>>> if it was not a MUST. >>>>>>> With very limited addition of code it is just as easy to >>>>>>> get the certificate attribute for client id as it is to >>>>>>> get it from the HTTP request data (at least in java). I >>>>>>> also think that with the requirement to match the incoming >>>>>>> certificate in some way one has to read out the >>>>>>> certificate that was used to establish the connection to >>>>>>> do some kind of matching. >>>>>>> >>>>>>> >>>>>>> Getting data out of the certificate isn't a concern. I just >>>>>>> believe that the constancy of having the client id parameter >>>>>>> is worth the potential small amount duplicate data in some >>>>>>> cases. It's just a -00 draft though and if the WG wants to >>>>>>> proceed with this document, we seek further input and work >>>>>>> towards some consensus. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> > > -- Jim Manico Manicode Security https://www.manicode.com From nobody Fri Nov 4 14:18:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822E012960B for ; Fri, 4 Nov 2016 14:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ_g3ZLTV7Hk for ; Fri, 4 Nov 2016 14:18:26 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826811293DA for ; Fri, 4 Nov 2016 14:18:25 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id u205so8994959itc.0 for ; Fri, 04 Nov 2016 14:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VvhQryLZ8JORx54ZGNqTlDEiWu+pZngltFVW3V5Pwx8=; b=ZPoxZGnoznMkKhxitxDDWAGaiuYphTci5bYbVyihrCRjOqRLMj6bY+1MhVcZEEnflG YRs5VARaF3621nCeC6Uq/0zhdsERIItwWlgzv99p0L2yKJGsEAi6ZgABwre2kiYby7q1 A20D++dLVnJZXPS5fZjVnpNUiAy4RghJ/yFiM= 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; bh=VvhQryLZ8JORx54ZGNqTlDEiWu+pZngltFVW3V5Pwx8=; b=VmVd1q/tgIyJ0Kl338WlBypz/Sqt6N6uMUTzeUTU4W6RZPyBD8lLX0UfnGP6IabcU6 +PS+6fpaq6Mw+MuKjprbvljDVs7RD3X2aGK0mrQ3w2zJd73yBNsZUtB5rUotDytS17d0 ZKp41se4AFrz8stWXoLbVY8mwEqx84LN4fym2K/Ku+w6FzSuBg5C8xgzNSHO2rW9K4TC 5Y4tbuz+8nqovpoJWA3qzikQ93M89v0Ti8e6U9Sdy5ILId53UbogvzSj89qcQo7Eje/i 3hwiNscJIvt1rwhu07z7xr4cZC83zO9TXsIMQyvWR6TKz3K42s0ZGuHxdgVWJ3+9zvXL 2UPw== X-Gm-Message-State: ABUngvcQPc2ngRdWZmDnZxEGeg6U396WEhj9nzePZ0sLX/AehYpTyjUXWVqTdE4jDe4cKm2NATrWjyuAdPa7ogLo X-Received: by 10.107.141.211 with SMTP id p202mr5535067iod.47.1478294304758; Fri, 04 Nov 2016 14:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Fri, 4 Nov 2016 14:17:54 -0700 (PDT) In-Reply-To: <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> From: Brian Campbell Date: Fri, 4 Nov 2016 15:17:54 -0600 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=94eb2c062c9ee8ba1f05408036a7 Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 21:18:28 -0000 --94eb2c062c9ee8ba1f05408036a7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable few little things inline... On Thu, Nov 3, 2016 at 6:41 AM, Justin Richer wrote: > I agree that the client_id is unlikely to be found inside the certificate > itself. The client_id is issued by the authorization server for the clien= t > to use at that single AS. The certificate is issued by the CA for the > client to use on any connection. The AS and CA are not likely to be the > same system in most deployments. The client will use the same cert across > multiple connections, possibly multiple AS's, but the same isn't true of > the client_id. > You said it better than I. > Additionally, I think we want to allow for a binding of a self-signed > certificate using dynamic registration, much the way that we already allo= w > binding of a client-generated JWK today. > Binding the client to a self-signed certificate is pretty similar to binding to the public key. But I agree it should be possible. The jwks_uri or jwks client registration metadata parameters are well suited to convey such info. The JWKs in them can convey the public key (obviously) but can also can convey a self-signed certificate with the "x5c" (X.509 Certificate Chain) parameter. > I do think that more examples and guidance are warranted, though, to help > AS developers. > Noted. > -- Justin > > On 11/2/2016 5:03 PM, Brian Campbell wrote: > > > On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wrote= : > >> >> I agree it is written so that the connection to the certificate is >> implicitly required but I think it would be better if it was explicit >> written since the lack of a connection would result in a potential secur= ity >> hole. >> > > That's fair. I agree it can be made more explicit and that it be good to > do so. > > > >> When it comes to the client_id I think subject common name or maybe >> subject serial numbers will be the common location, and I think an examp= le >> would be valuable. >> >> > > In my experience and the way we built support for mutual TLS OAuth client > auth the client_id value does not appear in the certificate anywhere. I'm > not saying it can't happen but don't think it's particularly common. > > I can look at adding some examples, if there's some consensus that they'd > be useful and this document moves forward. > > > >> >> I=C2=B4m not saying it is a bad Idea just that I would prefer if it was = not a >> MUST. >> With very limited addition of code it is just as easy to get the >> certificate attribute for client id as it is to get it from the HTTP >> request data (at least in java). I also think that with the requirement = to >> match the incoming certificate in some way one has to read out the >> certificate that was used to establish the connection to do some kind of >> matching. >> >> > Getting data out of the certificate isn't a concern. I just believe that > the constancy of having the client id parameter is worth the potential > small amount duplicate data in some cases. It's just a -00 draft though a= nd > if the WG wants to proceed with this document, we seek further input and > work towards some consensus. > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --94eb2c062c9ee8ba1f05408036a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
few little things inline...

On Thu, Nov 3, 2016 at 6:41 AM, Justin= Richer <jricher@mit.edu> wrote:
=20 =20 =20

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client= _id.


You said it better tha= n I.
=C2=A0

Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

Binding the client to a self-signed certificate is pretty similar to binding to the public ke= y. But I agree it should be possible.

The jwks_uri or jwks client r= egistration metadata parameters are well suited to convey such info. The JW= Ks in them can convey the public key (obviously) but can also can convey a = self-signed certificate with the "x5c" (X.509 Certificate Chain) = parameter.

=C2=A0

I do think that more examples and guidance are warranted, though, to help AS developers.


Note= d.
=C2=A0

=C2=A0-- Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:
=20

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explicit and that it be good to do so.

=C2=A0
When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
=C2=A0

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly co= mmon.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

=C2=A0
I=C2=B4m not saying it is a bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



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


--94eb2c062c9ee8ba1f05408036a7-- From nobody Fri Nov 4 18:11:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE6912946C for ; Fri, 4 Nov 2016 18:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCJLOo4poddA for ; Fri, 4 Nov 2016 18:11:31 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD551293E9 for ; Fri, 4 Nov 2016 18:11:31 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id n204so108105297qke.2 for ; Fri, 04 Nov 2016 18:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/+B6KVCew/Dh5FpXHyuiNjft8FREXVQJ27C2Ve6dUUI=; b=nSTm4IpVtjqf6r9OMYQxqMDF6BCzvH5wu0xQDcPIMWZ7lwj8lZ79W6bIOki2kbmy9o WG4jTb+8/NmmPqpBRLqJcmNLuDSgfGL1scEBfUX9qAYhD4TCNTepYW7awcy6A8tA6b1U 7qRvbknPd8/V3PLbARt6+9KAXnMi0MN+Iyvaf6qEneuP+FU9QLMoqXj9xbFjXJpbnxfo 33VRiKOY5suNIiCri92UzgvLXJQp9gMVc0hxb+cAFxWzvTWvUvGkSb7gUMcLMH0NdzpY Isz+qyr07+9U7+qk0KhL78RFNxpTf3O6p+iZ0sHJijOpGzer4jB2vXX2c3pQeubBiIVH 4DAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/+B6KVCew/Dh5FpXHyuiNjft8FREXVQJ27C2Ve6dUUI=; b=AlfgunPrHUOhFB8/w+b9BKXIaDfCcOKLeef5JOzUbuSbXCcREe12tn3oNE+7vttS4D CrqjVn2SNUwslhVVCU73FPGt8TIFOCt4bJdR1J6GyG6qJUNDWJXBzeiJq8fSh4N0zgad PrhDXV5d3pXdaiwV3Y/Cq2YbUczivjoeypRVcYz7RoL5S22hRZju8e0MzXB637dRZ1Im Zlel5B/0+CuPSRDcENjAlJ851bVJ3pCg0I0iu9asYxbI/iy1GV41BPvi5wktVnReUhkZ Xye2dRGDoXq2HTG0BwQCT7usbyqFfdJuPTymqaV6XRUOLQk9iqS9oj06Z6oIlTdTTIGA Lx5A== X-Gm-Message-State: ABUngvf1RVBlIRX0kPjLxlXP3xqQKOfkO9yfzeHKFfq84w3XrxI1ABqmRNg+AXvgS+98aW+W X-Received: by 10.55.68.73 with SMTP id r70mr15418828qka.277.1478308289980; Fri, 04 Nov 2016 18:11:29 -0700 (PDT) Received: from [192.168.1.39] ([191.115.180.247]) by smtp.gmail.com with ESMTPSA id w72sm9333750qkb.33.2016.11.04.18.11.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 18:11:29 -0700 (PDT) From: John Bradley Message-Id: <3B6518A2-CE89-48A4-B817-02C774C786B4@ve7jtb.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3FF01AC3-F34A-4F6A-A702-6041793F4287" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Fri, 4 Nov 2016 22:11:19 -0300 In-Reply-To: To: Brian Campbell References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 01:11:34 -0000 --Apple-Mail=_3FF01AC3-F34A-4F6A-A702-6041793F4287 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I can easily see Research and education publishing self signed certs in = meta-data that is then used for client authentication and other things. I don=E2=80=99t want to limit this to only CA issued certs where the = client_id is in the DN. Client_id tend not to be domain names = currently. Looking up a raw key provided via JWK in registration based on = client_id will be one way that people will use this. Passing the cert = is seen as just a way of passing the key to many people. I also understand the desire in ACE to save bytes. If you are using self signed certs then including the client_id in the = cert vs as a parameter is a bit of a no op re size. Perhaps if there is a common pattern we could document a IoT profile = where ca issued cert is used and what it would look like. I have concerns that this may open a can of worms around what the CN = would be and the interpretations of use extensions if this is flagged as = something other than a host cert. What do devices do now when they = are issued certs. Is there a common standard or is it by manufacturer. My main concern would be to not hold up what should be a simple spec for = the server to server case, but am willing to accommodate IoT if = possible. Regards John B. > On Oct 28, 2016, at 5:31 PM, Brian Campbell = wrote: >=20 > Not wanting to add more meta parameters was a motivation. Also not = being sure of how to enumerate the possible approaches. My thinking was = also that there are a lot of factors involved and that it'd probably be = better left to service documentation to describe things like what = authorities are trusted and what the client to cert binding is. Like I = said, we can look at adding more metadata, if there's some consensus to = do so. But I worry that it'll just be bloat that doesn't really add = value.=20 >=20 > I also think that, in many situations, it's unlikely that a cert will = contain a client id anywhere as subject information. A client id is = scoped to a particular authorization server and it's hard to imagine a = CA issuing a cert with an identifier that's only meaningful in the = context of some other entity like that. Maybe in a more closed system = where the AS and an organizational CA are both in the same = management/administrative domain but not in the more general case. =20 >=20 >=20 >=20 > On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov = > wrote: > I see. Do you reckon the AS could simply probe the likely cert places > for containing the client_id? My reasoning is that there aren't that > many places where you could stick the client_id (let me know if I'm > wrong). If the AS is in doubt it will respond with invalid_client. I'm > starting to think this can work quite well. No extra meta param will = be > needed (of which we have enough already). >=20 > On 22/10/16 01:51, Brian Campbell wrote: > > I did consider something like that but stopped short of putting it = in the > > -00 document. I'm not convinced that some metadata around it would = really > > contribute to interop one way or the other. I also wanted to get the = basic > > concept written down before going too far into the weeds. But I'd be = open > > to adding something along those lines in future revisions, if = there's some > > consensus that it'd be useful. > > > > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov = > >> wrote: > >> Superb, I welcome that! > >> > >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls- = > >> client-auth-00#section-5.2 : > >> > >> My concern is that the choice of how to bind the client identity is = left > >> to implementers, and that may eventually become an interop problem. > >> Have you considered some kind of an open ended enumeration of the = possible > >> binding methods, and giving them some identifiers or names, so that = AS / > >> OPs can advertise them in their metadata, and clients register = accordingly? > >> > >> For example: > >> > >> "tls_client_auth_bind_methods_supported" : [ = "subject_alt_name_match", > >> "subject_public_key_info_match" ] > >> > >> > >> Cheers, > >> > >> Vladimir > >> > >> On 10/10/16 23:59, John Bradley wrote: > >> > >> At the request of the OpenID Foundation Financial Services API = Working group, Brian Campbell and I have documented > >> mutual TLS client authentication. This is something that lots of = people do in practice though we have never had a spec for it. > >> > >> The Banks want to use it for some server to server API use cases = being driven by new open banking regulation. > >> > >> The largest thing in the draft is the IANA registration of = =E2=80=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method = for use in Registration and discovery. > >> > >> The trust model is intentionally left open so that you could use a = =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct = lookup of the subject public key against a reregistered value, or = something in between. > >> > >> I hope that this is non controversial and the WG can adopt it = quickly. > >> > >> Regards > >> John B. > >> > >> > >> > >> > >> > >> Begin forwarded message: > >> > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for = draft-campbell-oauth-tls-client-auth-00.txt > >> Date: October 10, 2016 at 5:44:39 PM GMT-3 > >> To: "Brian Campbell" > >, "John Bradley" > > > >> > >> > >> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt > >> has been successfully submitted by John Bradley and posted to the > >> IETF repository. > >> > >> Name: draft-campbell-oauth-tls-client-auth > >> Revision: 00 > >> Title: Mutual X.509 Transport Layer Security (TLS) = Authentication for OAuth Clients > >> Document date: 2016-10-10 > >> Group: Individual Submission > >> Pages: 5 > >> URL: = https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-= 00.txt = > >> Status: = https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ = > >> Htmlized: = https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 = > >> > >> > >> Abstract: > >> This document describes X.509 certificates as OAuth client > >> credentials using Transport Layer Security (TLS) mutual > >> authentication as a mechanism for client authentication to the > >> authorization server's token endpoint. > >> > >> > >> > >> > >> 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 = . > >> > >> The IETF Secretariat > >> > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing = listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth = > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth = > >> > >> >=20 >=20 >=20 --Apple-Mail=_3FF01AC3-F34A-4F6A-A702-6041793F4287 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I can easily see Research and education publishing self = signed certs in meta-data that is then used for client authentication = and other things.
I don=E2=80=99t want to limit this to = only CA issued certs where the client_id is in the DN.   =  Client_id tend not to be domain names currently.
Looking up a raw key  provided via JWK in registration = based on client_id will be one way that people will use this.   = Passing the cert is seen as just a way of passing the key to many = people.

I also = understand the desire in ACE to save bytes.

If you are using self signed certs then = including the client_id in the cert vs as a parameter is a bit of a no = op re size.

Perhaps if there is a common pattern we could document a IoT = profile where ca issued cert is used and what it would look = like.

I have = concerns that this may open a can of worms around what the CN would be = and the interpretations of use extensions if this is flagged as = something other than a host cert.    What do devices do now = when they are issued certs.  Is there a common standard or is it by = manufacturer.

My= main concern would be to not hold up what should be a simple spec for = the server to server case, but am willing to accommodate IoT if = possible.

Regards
John B.

On Oct 28, 2016, at 5:31 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Not wanting to add more meta parameters was a = motivation. Also not being sure of how to enumerate the possible = approaches. My thinking was also that there are a lot of factors = involved and that it'd probably be better left to service documentation = to describe things like what authorities are trusted and what the client = to cert binding is. Like I said, we can look at adding more metadata, if = there's some consensus to do so. But I worry that it'll just be bloat = that doesn't really add value.

I = also think that, in many situations, it's unlikely that a cert will = contain a client id anywhere as subject information. A client id is = scoped to a particular authorization server and it's hard to imagine a = CA issuing a cert with an identifier that's only meaningful in the = context of some other entity like that. Maybe in a more closed system = where the AS and an organizational CA are both in the same = management/administrative domain but not in the more general case. =  



On Wed, Oct 26, 2016 at 8:42 PM, Vladimir = Dzhuvinov <vladimir@connect2id.com> wrote:
I see. Do = you reckon the AS could simply probe the likely cert places
= for containing the client_id? My reasoning is that there aren't that
many places where you could stick the client_id (let me know if I'm
wrong). If the AS is in doubt it will respond with invalid_client. = I'm
starting to think this can work quite well. No extra meta param will = be
needed (of which we have enough already).

On 22/10/16 01:51, Brian Campbell wrote:
> I did consider something like that but stopped short of putting it = in the
> -00 document. I'm not convinced that some metadata around it would = really
> contribute to interop one way or the other. I also wanted to get = the basic
> concept written down before going too far into the weeds. But I'd = be open
> to adding something along those lines in future revisions, if = there's some
> consensus that it'd be useful.
>
> On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <vladimir@connect2id.com
>> wrote:
>> Superb, I welcome that!
>>
>> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
>> client-auth-00#section-5.2 :
>>
>> My concern is that the choice of how to bind the client = identity is left
>> to implementers, and that may eventually become an interop = problem.
>> Have you considered some kind of an open ended enumeration of = the possible
>> binding methods, and giving them some identifiers or names, so = that AS /
>> OPs can advertise them in their metadata, and clients register = accordingly?
>>
>> For example:
>>
>> "tls_client_auth_bind_methods_supported" : [ = "subject_alt_name_match",
>> "subject_public_key_info_match" ]
>>
>>
>> Cheers,
>>
>> Vladimir
>>
>> On 10/10/16 23:59, John Bradley wrote:
>>
>> At the request of the OpenID Foundation Financial Services API = Working group, Brian Campbell and I have documented
>> mutual TLS client authentication.   This is something = that lots of people do in practice though we have never had a spec for = it.
>>
>> The Banks want to use it for some server to server API use = cases being driven by new open banking regulation.
>>
>> The largest thing in the draft is the IANA registration of = =E2=80=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method = for use in Registration and discovery.
>>
>> The trust model is intentionally left open so that you could = use a =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a = direct lookup of the subject public key against a reregistered = value,  or something in between.
>>
>> I hope that this is non controversial and the WG can adopt it = quickly.
>>
>> Regards
>> John B.
>>
>>
>>
>>
>>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for = draft-campbell-oauth-tls-client-auth-00.txt
= >> Date: October 10, 2016 at 5:44:39 PM GMT-3
>> To: "Brian Campbell" <brian.d.campbell@gmail.com> <brian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com> <ve7jtb@ve7jtb.com>
>>
>>
>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
>> has been successfully submitted by John Bradley and posted to = the
>> IETF repository.
>>
>> Name:                = draft-campbell-oauth-tls-client-auth
>> Revision:    00
>> Title:              =  Mutual X.509 Transport Layer Security (TLS) Authentication for = OAuth Clients
>> Document date:       2016-10-10
>> Group:              =  Individual Submission
>> Pages:              =  5
>> URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
>> Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
>>
>>
>> Abstract:
>>   This document describes X.509 certificates as OAuth = client
>>   credentials using Transport Layer Security (TLS) = mutual
>>   authentication as a mechanism for client = authentication to the
>>   authorization server's token endpoint.
= >>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>




= --Apple-Mail=_3FF01AC3-F34A-4F6A-A702-6041793F4287-- From nobody Fri Nov 4 18:14:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217EC12946C for ; Fri, 4 Nov 2016 18:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sV6rJCJWtVt for ; Fri, 4 Nov 2016 18:14:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F101293E9 for ; Fri, 4 Nov 2016 18:14:36 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uA51EYtA021947 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 5 Nov 2016 01:14:35 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id uA51EYIG030029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Nov 2016 01:14:34 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uA51EWdS016132; Sat, 5 Nov 2016 01:14:33 GMT Received: from [25.161.39.173] (/72.143.234.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Nov 2016 18:14:30 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-A2A85717-A6D9-4834-A926-FF56C82983FB Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14B100) In-Reply-To: <3B6518A2-CE89-48A4-B817-02C774C786B4@ve7jtb.com> Date: Fri, 4 Nov 2016 18:14:23 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <3B6518A2-CE89-48A4-B817-02C774C786B4@ve7jtb.com> To: John Bradley X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 01:14:39 -0000 --Apple-Mail-A2A85717-A6D9-4834-A926-FF56C82983FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Phil > On Nov 4, 2016, at 6:11 PM, John Bradley wrote: >=20 > I can easily see Research and education publishing self signed certs in me= ta-data that is then used for client authentication and other things. > I don=E2=80=99t want to limit this to only CA issued certs where the clien= t_id is in the DN. Client_id tend not to be domain names currently. > Looking up a raw key provided via JWK in registration based on client_id w= ill be one way that people will use this. Passing the cert is seen as just= a way of passing the key to many people. >=20 > I also understand the desire in ACE to save bytes. >=20 > If you are using self signed certs then including the client_id in the cer= t vs as a parameter is a bit of a no op re size. >=20 > Perhaps if there is a common pattern we could document a IoT profile where= ca issued cert is used and what it would look like. >=20 > I have concerns that this may open a can of worms around what the CN would= be and the interpretations of use extensions if this is flagged as somethin= g other than a host cert. What do devices do now when they are issued cer= ts. Is there a common standard or is it by manufacturer. >=20 > My main concern would be to not hold up what should be a simple spec for t= he server to server case, but am willing to accommodate IoT if possible. >=20 > Regards > John B. >=20 >> On Oct 28, 2016, at 5:31 PM, Brian Campbell w= rote: >>=20 >> Not wanting to add more meta parameters was a motivation. Also not being s= ure of how to enumerate the possible approaches. My thinking was also that t= here are a lot of factors involved and that it'd probably be better left to s= ervice documentation to describe things like what authorities are trusted an= d what the client to cert binding is. Like I said, we can look at adding mor= e metadata, if there's some consensus to do so. But I worry that it'll just b= e bloat that doesn't really add value.=20 >>=20 >> I also think that, in many situations, it's unlikely that a cert will con= tain a client id anywhere as subject information. A client id is scoped to a= particular authorization server and it's hard to imagine a CA issuing a cer= t with an identifier that's only meaningful in the context of some other ent= ity like that. Maybe in a more closed system where the AS and an organizatio= nal CA are both in the same management/administrative domain but not in the m= ore general case. =20 >>=20 >>=20 >>=20 >>> On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov wrote: >>> I see. Do you reckon the AS could simply probe the likely cert places >>> for containing the client_id? My reasoning is that there aren't that >>> many places where you could stick the client_id (let me know if I'm >>> wrong). If the AS is in doubt it will respond with invalid_client. I'm >>> starting to think this can work quite well. No extra meta param will be >>> needed (of which we have enough already). >>>=20 >>> On 22/10/16 01:51, Brian Campbell wrote: >>> > I did consider something like that but stopped short of putting it in t= he >>> > -00 document. I'm not convinced that some metadata around it would rea= lly >>> > contribute to interop one way or the other. I also wanted to get the b= asic >>> > concept written down before going too far into the weeds. But I'd be o= pen >>> > to adding something along those lines in future revisions, if there's s= ome >>> > consensus that it'd be useful. >>> > >>> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov >> >> wrote: >>> >> Superb, I welcome that! >>> >> >>> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls- >>> >> client-auth-00#section-5.2 : >>> >> >>> >> My concern is that the choice of how to bind the client identity is l= eft >>> >> to implementers, and that may eventually become an interop problem. >>> >> Have you considered some kind of an open ended enumeration of the pos= sible >>> >> binding methods, and giving them some identifiers or names, so that A= S / >>> >> OPs can advertise them in their metadata, and clients register accord= ingly? >>> >> >>> >> For example: >>> >> >>> >> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match"= , >>> >> "subject_public_key_info_match" ] >>> >> >>> >> >>> >> Cheers, >>> >> >>> >> Vladimir >>> >> >>> >> On 10/10/16 23:59, John Bradley wrote: >>> >> >>> >> At the request of the OpenID Foundation Financial Services API Workin= g group, Brian Campbell and I have documented >>> >> mutual TLS client authentication. This is something that lots of pe= ople do in practice though we have never had a spec for it. >>> >> >>> >> The Banks want to use it for some server to server API use cases bein= g driven by new open banking regulation. >>> >> >>> >> The largest thing in the draft is the IANA registration of =E2=80=9Ct= ls_client_auth=E2=80=9D Token Endpoint authentication method for use in Regi= stration and discovery. >>> >> >>> >> The trust model is intentionally left open so that you could use a =E2= =80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct lookup of= the subject public key against a reregistered value, or something in betwe= en. >>> >> >>> >> I hope that this is non controversial and the WG can adopt it quickly= . >>> >> >>> >> Regards >>> >> John B. >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> Begin forwarded message: >>> >> >>> >> From: internet-drafts@ietf.org >>> >> Subject: New Version Notification for draft-campbell-oauth-tls-client= -auth-00.txt >>> >> Date: October 10, 2016 at 5:44:39 PM GMT-3 >>> >> To: "Brian Campbell" , "John Bradley" >>> >> >>> >> >>> >> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >>> >> has been successfully submitted by John Bradley and posted to the >>> >> IETF repository. >>> >> >>> >> Name: draft-campbell-oauth-tls-client-auth >>> >> Revision: 00 >>> >> Title: Mutual X.509 Transport Layer Security (TLS) Auth= entication for OAuth Clients >>> >> Document date: 2016-10-10 >>> >> Group: Individual Submission >>> >> Pages: 5 >>> >> URL: https://www.ietf.org/internet-drafts/draft-campbell-o= auth-tls-client-auth-00.txt >>> >> Status: https://datatracker.ietf.org/doc/draft-campbell-oauth= -tls-client-auth/ >>> >> Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-tls-= client-auth-00 >>> >> >>> >> >>> >> Abstract: >>> >> This document describes X.509 certificates as OAuth client >>> >> credentials using Transport Layer Security (TLS) mutual >>> >> authentication as a mechanism for client authentication to the >>> >> authorization server's token endpoint. >>> >> >>> >> >>> >> >>> >> >>> >> Please note that it may take a couple of minutes from the time of sub= mission >>> >> until the htmlized version and diff are available at tools.ietf.org. >>> >> >>> >> The IETF Secretariat >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo= /oauth >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> >> >>> >> >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-A2A85717-A6D9-4834-A926-FF56C82983FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Phil

On Nov 4,= 2016, at 6:11 PM, John Bradley <ve7= jtb@ve7jtb.com> wrote:

I can e= asily see Research and education publishing self signed certs in meta-data t= hat is then used for client authentication and other things.
= I don=E2=80=99t want to limit this to only CA issued certs where the client_= id is in the DN.    Client_id tend not to be domain names currentl= y.
Looking up a raw key  provided via JWK in regis= tration based on client_id will be one way that people will use this.  = Passing the cert is seen as just a way of passing the key to many people.

I also understand t= he desire in ACE to save bytes.

If you are using self signed certs then including the client_i= d in the cert vs as a parameter is a bit of a no op re size.

Perhaps if there is a common patt= ern we could document a IoT profile where ca issued cert is used and what it= would look like.

= I have concerns that this may open a can of worms around what the CN would b= e and the interpretations of use extensions if this is flagged as something o= ther than a host cert.    What do devices do now when they are iss= ued certs.  Is there a common standard or is it by manufacturer.
<= div class=3D"">
My main concern would be= to not hold up what should be a simple spec for the server to server case, b= ut am willing to accommodate IoT if possible.

Regards
John B.

On Oct 28, 2016, at 5:31 PM, Brian Campbell <= ;bcampbell@pingiden= tity.com> wrote:

Not wanting to add more= meta parameters was a motivation. Also not being sure of how to enumerate t= he possible approaches. My thinking was also that there are a lot of factors= involved and that it'd probably be better left to service documentation to d= escribe things like what authorities are trusted and what the client to cert= binding is. Like I said, we can look at adding more metadata, if there's so= me consensus to do so. But I worry that it'll just be bloat that doesn't rea= lly add value.

I also think that, in man= y situations, it's unlikely that a cert will contain a client id anywhere as= subject information. A client id is scoped to a particular authorization se= rver and it's hard to imagine a CA issuing a cert with an identifier that's o= nly meaningful in the context of some other entity like that. Maybe in a mor= e closed system where the AS and an organizational CA are both in the same m= anagement/administrative domain but not in the more general case.  



On Wed, O= ct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov <= vlad= imir@connect2id.com> wrote:
I see. Do you reckon the AS could simply probe t= he likely cert places
for containing the client_id? My reasoning is that there aren't that
many places where you could stick the client_id (let me know if I'm
wrong). If the AS is in doubt it will respond with invalid_client. I'm
starting to think this can work quite well. No extra meta param will be
needed (of which we have enough already).

= On 22/10/16 01:51, Brian Campbell wrote:
> I did consider something like that but stopped short of putting it in t= he
> -00 document. I'm not convinced that some metadata around it would real= ly
> contribute to interop one way or the other. I also wanted to get the ba= sic
> concept written down before going too far into the weeds. But I'd be op= en
> to adding something along those lines in future revisions, if there's s= ome
> consensus that it'd be useful.
>
> On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <vladimir@connect2id= .com
>> wrote:
>> Superb, I welcome that!
>>
>> Regarding https://tools.ietf.= org/html/draft-campbell-oauth-tls-
>> client-auth-00#section-5.2 :
>>
>> My concern is that the choice of how to bind the client identity is= left
>> to implementers, and that may eventually become an interop problem.=
>> Have you considered some kind of an open ended enumeration of the p= ossible
>> binding methods, and giving them some identifiers or names, so that= AS /
>> OPs can advertise them in their metadata, and clients register acco= rdingly?
>>
>> For example:
>>
>> "tls_client_auth_bind_methods_supported" : [ "subje= ct_alt_name_match",
>> "subject_public_key_info_match" ]
>>
>>
>> Cheers,
>>
>> Vladimir
>>
>> On 10/10/16 23:59, John Bradley wrote:
>>
>> At the request of the OpenID Foundation Financial Services API Work= ing group, Brian Campbell and I have documented
>> mutual TLS client authentication.   This is something tha= t lots of people do in practice though we have never had a spec for it.
>>
>> The Banks want to use it for some server to server API use cases be= ing driven by new open banking regulation.
>>
>> The largest thing in the draft is the IANA registration of =E2=80=9C= tls_client_auth=E2=80=9D Token Endpoint authentication method for use in Reg= istration and discovery.
>>
>> The trust model is intentionally left open so that you could use a =E2= =80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct lookup of= the subject public key against a reregistered value,  or something in b= etween.
>>
>> I hope that this is non controversial and the WG can adopt it quick= ly.
>>
>> Regards
>> John B.
>>
>>
>>
>>
>>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-campbell-oauth-tls-clie= nt-auth-00.txt
>> Date: October 10, 2016 at 5:44:39 PM GMT-3
>> To: "Brian Campbell" <brian.d.campbell@gmail.com&= gt; <brian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com>= ; <ve7j= tb@ve7jtb.com>
>>
>>
>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
>> has been successfully submitted by John Bradley and posted to the >> IETF repository.
>>
>> Name:                draft-= campbell-oauth-tls-client-auth
>> Revision:    00
>> Title:               Mutual= X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
>> Document date:       2016-10-10
>> Group:               Indivi= dual Submission
>> Pages:               5
>> URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.t= xt
>> Status:         https://datatracker.ietf.org/doc= /draft-campbell-oauth-tls-client-auth/
>> Htmlized:       https://tools.ietf.org/html/draft-campbe= ll-oauth-tls-client-auth-00
>>
>>
>> Abstract:
>>   This document describes X.509 certificates as OAuth cli= ent
>>   credentials using Transport Layer Security (TLS) mutual=
>>   authentication as a mechanism for client authentication= to the
>>   authorization server's token endpoint.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of s= ubmission
>> until the htmlized version and diff are available at tools.i= etf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAut= h@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=
= --Apple-Mail-A2A85717-A6D9-4834-A926-FF56C82983FB-- From nobody Sun Nov 6 03:43:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F03127077 for ; Sun, 6 Nov 2016 03:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVwz4AFdBHgN for ; Sun, 6 Nov 2016 03:43:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 6EFB3129415 for ; Sun, 6 Nov 2016 03:43:05 -0800 (PST) Received: from [192.168.91.155] ([80.92.115.71]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MEsXW-1c51cl3mu2-00G45Y for ; Sun, 06 Nov 2016 12:43:02 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <927b21e8-e3d2-cdd9-84d3-de4b42786f79@gmx.net> Date: Sun, 6 Nov 2016 12:42:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Dugwh16RfqRArslSIKfqiw1vrDURwmSDW" X-Provags-ID: V03:K0:RkFWlNuf7nxeyEXL9s1N96c69231oSpWuNN3I0v/Ie7n0U2x7vs 2fmLJZrtGRNGsDw5O/Ved4m/y53kvqg6+se9WgOle3JcE4X3ARctJv+O1TSOOVQVqbJm9CK CXNbSCD+1oMGuJvlfgEOXZIhwu1KNKZb5hd1B4b4g9HKiyj5R8kvBx4x3wYySKJiFJ5XipR 9sWALpYElMiD5fahoc6/g== X-UI-Out-Filterresults: notjunk:1;V01:K0:kwlqKaN/n+I=:+bK2kCTLIqsXd3yNd7PxMy Q+uGaaEMSKIqu1aWroVo6dSOAiIx+6+KAxjoTEZCvvqvQJGwtxfSzY+3+TnqdDXT3A7szEXEO q4Cl4TWAZsYzvg1myQW6XzxBhNhhasYFpQ0yra+nhZFqcQn7gaeDPYsgyHbJH2+yy11MmAsXy g+OwsUzwWPcP3el9AJccTvpV1l4Oe1qEjNq1nKj4XlSh81NCNL1FFspWevM4H0TUUV+S8151p sdJRgb1LjciOZZvYpVZOhAC1Z/is8XmcT+cqzM6SIjUNgUcGrrFOkscLUO91zmTbavsyTe9jd gOwIuUmvsIwE8RYVt9dRn5EXUIh/3inkizw4UONS1LSTeo34p4h6+DrDPQoQe43hpgFwxIRBX ndcSDHzLAhqM5Hq1Q63tOVQrJGN7WkJsMhHdAs61bV3k7nR3q0mYEHZCDFTTAvgbEtzpvTaus 7Kv+pZpg46wHlydgW3VpW/og+h6oxo11xVDOLQu1PepGgxYKuyyw4/T2KEJAW3KqKBTtXHUtV GiIMwSXWPdTefWg7uytiMjzTej6qtkolu9vhZaP4FDUHY8CxGXpY4ddxhUQLE+y8r3Jwx2VsL 5D/o9OY+CMxcSibTbPNvx/f7HsBk/sznGk3BDUiDf29gRztliYjVIdjihLwJNC4FbHTghFqMf YAV4PGzhluyY4hLjJ1oAOsEBkjBEy3a18u3shFjLQrlrYS5tuv3OkItsCFDNZTfYdas0V/8ms bza0ocrbvQSsLekbYVSF5C+1cBQR2tSTtNQkvp5Pv8ekb8UXIUcxfbWrqWQ= Archived-At: Subject: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 11:43:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Dugwh16RfqRArslSIKfqiw1vrDURwmSDW Content-Type: multipart/mixed; boundary="UXGggg36O0N4LU5q85UsF7ld1UsXS7e2A"; protected-headers="v1" From: Hannes Tschofenig To: "oauth@ietf.org" Message-ID: <927b21e8-e3d2-cdd9-84d3-de4b42786f79@gmx.net> Subject: Agenda --UXGggg36O0N4LU5q85UsF7ld1UsXS7e2A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, here is a first draft of the agenda for the upcoming meeting: https://datatracker.ietf.org/doc/agenda-97-oauth/ Feedback welcome Ciao Hannes --UXGggg36O0N4LU5q85UsF7ld1UsXS7e2A-- --Dugwh16RfqRArslSIKfqiw1vrDURwmSDW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYHxdEAAoJEGhJURNOOiAtZ78H/jHNVGbGANJYLi8X2OSO27ej ZR4vDAoEHtfKsV2JozTXqzgCBbqb7YLq8C4LXvtkMqbF2NGSEWwO+1CBRNQFPz2D DXGMIqmk4NxPbJQ3d5/0XqPNkeVcxvGooMXFb5HxSfNxpbm9lsV09Cw/WovL24zH JRR8ZD0O77cwz5vFw1qVoHbn3g9V9qCbpX8vKVdkM8K1bRwKeVgv1q8jAxYoBG9k Jen5OBMRb4kTwo61g7imazSAdg+TjgkaEbHhcN2zQuHMinPljcHMYi482mqrAtAx JKoZ3RUgE99b5qZyVTxQkHcn8a4Kdr1n0b8lrsFgBrXptM+swFqdt5h3pS/40Ac= =nRsy -----END PGP SIGNATURE----- --Dugwh16RfqRArslSIKfqiw1vrDURwmSDW-- From nobody Sun Nov 6 10:31:11 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C602B129810 for ; Sun, 6 Nov 2016 10:31:09 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw6_ljyup3gW for ; Sun, 6 Nov 2016 10:31:07 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C83B1296DC for ; Sun, 6 Nov 2016 10:31:06 -0800 (PST) Received: from [80.140.198.142] (helo=[192.168.71.132]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c3SDg-0003Be-JM; Sun, 06 Nov 2016 19:31:04 +0100 To: Hannes Tschofenig , "oauth@ietf.org" References: <927b21e8-e3d2-cdd9-84d3-de4b42786f79@gmx.net> From: Torsten Lodderstedt Message-ID: <581F76E5.40002@lodderstedt.net> Date: Sun, 6 Nov 2016 19:31:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <927b21e8-e3d2-cdd9-84d3-de4b42786f79@gmx.net> Content-Type: multipart/alternative; boundary="------------080708030304090909090002" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 18:31:10 -0000 This is a multi-part message in MIME format. --------------080708030304090909090002 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes, I would like to present and discuss the OAuth Security draft I'm working on (with John and Andrey). Can you please reserve 15 min in the Wednesday session? I plan to publish the draft after the IETF submission tool has re-opened. best regards, Torsten. Am 06.11.2016 um 12:42 schrieb Hannes Tschofenig: > Hi all, > > here is a first draft of the agenda for the upcoming meeting: > https://datatracker.ietf.org/doc/agenda-97-oauth/ > > Feedback welcome > > Ciao > Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080708030304090909090002 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Hannes,

I would like to present and discuss the OAuth Security draft I'm working on (with John and Andrey). Can you please reserve 15 min in the Wednesday session?

I plan to publish the draft after the IETF submission tool has re-opened.

best regards,
Torsten.

Am 06.11.2016 um 12:42 schrieb Hannes Tschofenig:
Hi all,

here is a first draft of the agenda for the upcoming meeting:
https://datatracker.ietf.org/doc/agenda-97-oauth/

Feedback welcome

Ciao
Hannes




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

--------------080708030304090909090002-- From nobody Mon Nov 7 01:06:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77FE129B6C for ; Mon, 7 Nov 2016 01:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.617 X-Spam-Level: X-Spam-Status: No, score=-3.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yda0spIo50td for ; Mon, 7 Nov 2016 01:06:09 -0800 (PST) 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 002A8129B5A for ; Mon, 7 Nov 2016 01:06:07 -0800 (PST) Received: from [192.168.91.155] ([80.92.115.71]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Mdafs-1cSvxJ0xxc-00PLbx; Mon, 07 Nov 2016 10:06:05 +0100 To: Torsten Lodderstedt , "oauth@ietf.org" References: <927b21e8-e3d2-cdd9-84d3-de4b42786f79@gmx.net> <581F76E5.40002@lodderstedt.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Mon, 7 Nov 2016 10:06:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <581F76E5.40002@lodderstedt.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="auQbj7viLWQxrS2hvFE2HOq6xNTJQEnKL" X-Provags-ID: V03:K0:iiw0Up2OITOoDiUMQQGd6S5ocE510Phgbt//9TgJoufnntDEUtw ke0fHmn+mYpW6rZBncp9GM+YuUErCavEAlQaH5aGdNqcvxw8MshoAt4tg8d9ML+OdUdvt4K a3bgqKvgcPix5XRxv54MizSJjPd6aIo0orSZb/WbO1K1OC11Wgh3DlOP8SE88RSvHDuXt5s xczHCaeORZo4A4poVxbhA== X-UI-Out-Filterresults: notjunk:1;V01:K0:lvRQCzV4Gyo=:PpCrA0MZ7jw2SDVpGEd/Ai gTBxexq094OVre0X7Iu8QsUBxFW63BuZ7VuHpwBWGZuaKPiL631uuBoe1iMSoyKKR84U0/jMA GZLvHxuPmv7At9ldZILJpD43HadfaVP4Ylc1m7m2RzZl0VGRq+v/+Yewi+md8nNWTu6fBiKpH uYDZOEE/6iPFMBRdZXhs3s9MFnjf6uE+pCJVTqGcypvE3TIDRJgvcuszabpXkKcKTZidj9TZP e4B99O7V/V9LCgx01JdP9nLCdlbBTdAgwGfpl3J3wSe1Lfu5xjcveMIlaD1gG4sNuPJH62l+T dRvw+ERQrAH3wjexhafBtOC7L/7tP22+6BhngXhh61OKBea2oyOot9qMby8MWdaqgB7sCFCdb x+JpFa6rm6neFLguoalMl7HBCtyRLnY80Wi41WP/z+3fJfxAKvp8GUsVhhlTXpZIs7VWRMiju +UEJ3rHSe6G8ewvd/UpLVeG9e+FzdDlhGHDKRJcsGvmY3fdBicAtcM/72ZeZJ9XjvaFcdR/oA 0X0hAtd/pj/M7rU+yAUvROT/r6w4MuVajltYFGAM9gNQQtC3w4n52OnosRqr+RbUYwOOykjYZ nMPpzTcW3O6Wr/lOBNd23C/2J3LbDjum60yg2dVqtYdPwbnJIm22xAMhbmWxMq4aJPcg+g8lM 4TuS77jW+PnoYsEClp0XfPLRrnfl4CQ139c1oEvfawP4jlaAEJC8oRrFHv0AwkKkKfLWRsnrC fPTFVfnuPsMQMKYwVr2TMU1I6MPx4SdnPDqQP48p9MPpj0A6w/tYotAEsm8= Archived-At: Subject: Re: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 09:06:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --auQbj7viLWQxrS2hvFE2HOq6xNTJQEnKL Content-Type: multipart/mixed; boundary="JkS5R5eNspAaBVKisuqQcgixkJQfRGMd2"; protected-headers="v1" From: Hannes Tschofenig To: Torsten Lodderstedt , "oauth@ietf.org" Message-ID: Subject: Re: [OAUTH-WG] Agenda References: <927b21e8-e3d2-cdd9-84d3-de4b42786f79@gmx.net> <581F76E5.40002@lodderstedt.net> In-Reply-To: <581F76E5.40002@lodderstedt.net> --JkS5R5eNspAaBVKisuqQcgixkJQfRGMd2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Torsten. Added it to the agenda. Ciao Hannes On 11/06/2016 07:31 PM, Torsten Lodderstedt wrote: > Hi Hannes, >=20 > I would like to present and discuss the OAuth Security draft I'm workin= g > on (with John and Andrey). Can you please reserve 15 min in the > Wednesday session? >=20 > I plan to publish the draft after the IETF submission tool has re-opene= d. >=20 > best regards, > Torsten. >=20 > Am 06.11.2016 um 12:42 schrieb Hannes Tschofenig: >> Hi all, >> >> here is a first draft of the agenda for the upcoming meeting: >> https://datatracker.ietf.org/doc/agenda-97-oauth/ >> >> Feedback welcome >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --JkS5R5eNspAaBVKisuqQcgixkJQfRGMd2-- --auQbj7viLWQxrS2hvFE2HOq6xNTJQEnKL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYIEP8AAoJEGhJURNOOiAtqwQH/2HATzkQCv3eEAghMZ5kIsUu Mdvvg5rK97TCaNZ1o7vDZibBJ3p0DuSaVxA8ZGDO0wEtlN9vwo/Yxh/tz4aHa/N/ 8MdEd8WslnP6K9HBIUDOtFMDbk3E+gqzcWJ7D1E+Y6oAsB24P3qVP4DpNwKaHFDJ xSye3xHs0UkMFMyOR54BBsUKP3r9hjj7bVnJZdqBci55hd/XOd10FtlDSJDdP83A Ee/FkDCDjjBd3JGtn9SdNNbHnBm8Jd3GmGpWsKs87/QyF9KUiD1d1SkR5fulj3AO 968eoVkmySuclqX1EfpaIRrImBG2RpDzQA6k0h2Jnqp8Om5H/hnWVcqevwpKu9c= =1Qs0 -----END PGP SIGNATURE----- --auQbj7viLWQxrS2hvFE2HOq6xNTJQEnKL-- From nobody Mon Nov 7 08:43:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6A9129953 for ; Mon, 7 Nov 2016 08:43:34 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpuUesuDbzcW for ; Mon, 7 Nov 2016 08:43:31 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0DA12973D for ; Mon, 7 Nov 2016 08:43:30 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id p190so194552273wmp.1 for ; Mon, 07 Nov 2016 08:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YncGBzbPExxL3i6Ry0laEcP/eZb7l/iHp/tjYm3lzdc=; b=ufNVy5LdCgpM4mQscBUl+aV88nN4qQi5bJgUvnwP5Wzt0cgCXXgl6Rgznx9Ftf9Tf8 E8bx7i3PtlQdfssPj1aVE0CLJtq6eC1iF3oiRD2xk23bWcIWn4NPY1FK5cqcbTFUeJ2+ 0T/LoWIgdlDyUU1cJDFDV2PNjiRnqvOq0SjApOb1I7HfkDy7T1OFiaEMynmWdaZONFVN jwwkg0FY8q5NaATtjtnx43tDk31EqXJrvSQYeQ0UCv5dkk+UCHK2HCDdfaCrbtqmixSF Hrz5iQnzc2U3QdzoAXEK0twmk25XoO+VfGpMZK9olkwgvDPfU/o8RicB6lhAPHZjU0hG RG2g== 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; bh=YncGBzbPExxL3i6Ry0laEcP/eZb7l/iHp/tjYm3lzdc=; b=SVWot47g7xFKOTYjEyovV86O2qVRITvXbSbQl2zYmRU3VzHGvTMVsNF2OvDk58H5yJ ykPIrepR3CHzjkDkShXf5QzlX8SYzEGv7Rgm4q9nRNPupQohJAYjjZA+zJgrntnowvWu HUPnd2u1jBiC6tiHKsDu4apXNhqU9uVxp7L6GG+OetKdSh0x9aTVf7cdAT3AC7ogDE2j EqcqesQJ+Mh5KxNxh9Qc+8DH7ezrNgbSzjG19mGOY2uvIJaiJhUzllE+9am+XQ9UwNTQ CU/WFH2FNoMtfewyxVsZq617yyCABq3dhPFfQnYjsk+OO3pyrVT+9perEOhUwnG3xDTs 7gdg== X-Gm-Message-State: ABUngvdkkSUtb8TkUzLpADNFAWlzOHmNsXtk/n401hcS4LhN5GsTCYqj5UgNL+hQJQo+n7AT3ienYeSNssjx4g== X-Received: by 10.28.40.67 with SMTP id o64mr9533935wmo.5.1478537009418; Mon, 07 Nov 2016 08:43:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.172.232 with HTTP; Mon, 7 Nov 2016 08:43:28 -0800 (PST) In-Reply-To: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <3B6518A2-CE89-48A4-B817-02C774C786B4@ve7jtb.com> From: Samuel Erdtman Date: Mon, 7 Nov 2016 17:43:28 +0100 Message-ID: To: "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary=001a114973c23bf7600540b8b922 Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 16:43:34 -0000 --001a114973c23bf7600540b8b922 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Phil, what is your +1 referring to? //Samuel On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) wrote: > +1 > > Phil > > On Nov 4, 2016, at 6:11 PM, John Bradley wrote: > > I can easily see Research and education publishing self signed certs in > meta-data that is then used for client authentication and other things. > I don=E2=80=99t want to limit this to only CA issued certs where the clie= nt_id is > in the DN. Client_id tend not to be domain names currently. > Looking up a raw key provided via JWK in registration based on client_id > will be one way that people will use this. Passing the cert is seen as > just a way of passing the key to many people. > > I also understand the desire in ACE to save bytes. > > If you are using self signed certs then including the client_id in the > cert vs as a parameter is a bit of a no op re size. > > Perhaps if there is a common pattern we could document a IoT profile wher= e > ca issued cert is used and what it would look like. > > I have concerns that this may open a can of worms around what the CN woul= d > be and the interpretations of use extensions if this is flagged as > something other than a host cert. What do devices do now when they are > issued certs. Is there a common standard or is it by manufacturer. > > My main concern would be to not hold up what should be a simple spec for > the server to server case, but am willing to accommodate IoT if possible. > > Regards > John B. > > On Oct 28, 2016, at 5:31 PM, Brian Campbell > wrote: > > Not wanting to add more meta parameters was a motivation. Also not being > sure of how to enumerate the possible approaches. My thinking was also th= at > there are a lot of factors involved and that it'd probably be better left > to service documentation to describe things like what authorities are > trusted and what the client to cert binding is. Like I said, we can look = at > adding more metadata, if there's some consensus to do so. But I worry tha= t > it'll just be bloat that doesn't really add value. > > I also think that, in many situations, it's unlikely that a cert will > contain a client id anywhere as subject information. A client id is scope= d > to a particular authorization server and it's hard to imagine a CA issuin= g > a cert with an identifier that's only meaningful in the context of some > other entity like that. Maybe in a more closed system where the AS and an > organizational CA are both in the same management/administrative domain b= ut > not in the more general case. > > > > On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > >> I see. Do you reckon the AS could simply probe the likely cert places >> for containing the client_id? My reasoning is that there aren't that >> many places where you could stick the client_id (let me know if I'm >> wrong). If the AS is in doubt it will respond with invalid_client. I'm >> starting to think this can work quite well. No extra meta param will be >> needed (of which we have enough already). >> >> On 22/10/16 01:51, Brian Campbell wrote: >> > I did consider something like that but stopped short of putting it in >> the >> > -00 document. I'm not convinced that some metadata around it would >> really >> > contribute to interop one way or the other. I also wanted to get the >> basic >> > concept written down before going too far into the weeds. But I'd be >> open >> > to adding something along those lines in future revisions, if there's >> some >> > consensus that it'd be useful. >> > >> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov < >> vladimir@connect2id.com >> >> wrote: >> >> Superb, I welcome that! >> >> >> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls- >> >> client-auth-00#section-5.2 : >> >> >> >> My concern is that the choice of how to bind the client identity is >> left >> >> to implementers, and that may eventually become an interop problem. >> >> Have you considered some kind of an open ended enumeration of the >> possible >> >> binding methods, and giving them some identifiers or names, so that A= S >> / >> >> OPs can advertise them in their metadata, and clients register >> accordingly? >> >> >> >> For example: >> >> >> >> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match"= , >> >> "subject_public_key_info_match" ] >> >> >> >> >> >> Cheers, >> >> >> >> Vladimir >> >> >> >> On 10/10/16 23:59, John Bradley wrote: >> >> >> >> At the request of the OpenID Foundation Financial Services API Workin= g >> group, Brian Campbell and I have documented >> >> mutual TLS client authentication. This is something that lots of >> people do in practice though we have never had a spec for it. >> >> >> >> The Banks want to use it for some server to server API use cases bein= g >> driven by new open banking regulation. >> >> >> >> The largest thing in the draft is the IANA registration of >> =E2=80=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method f= or use in >> Registration and discovery. >> >> >> >> The trust model is intentionally left open so that you could use a >> =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct lo= okup of the subject >> public key against a reregistered value, or something in between. >> >> >> >> I hope that this is non controversial and the WG can adopt it quickly= . >> >> >> >> Regards >> >> John B. >> >> >> >> >> >> >> >> >> >> >> >> Begin forwarded message: >> >> >> >> From: internet-drafts@ietf.org >> >> Subject: New Version Notification for draft-campbell-oauth-tls-clien >> t-auth-00.txt >> >> Date: October 10, 2016 at 5:44:39 PM GMT-3 >> >> To: "Brian Campbell" < >> brian.d.campbell@gmail.com>, "John Bradley" < >> ve7jtb@ve7jtb.com> >> >> >> >> >> >> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >> >> has been successfully submitted by John Bradley and posted to the >> >> IETF repository. >> >> >> >> Name: draft-campbell-oauth-tls-client-auth >> >> Revision: 00 >> >> Title: Mutual X.509 Transport Layer Security (TLS) >> Authentication for OAuth Clients >> >> Document date: 2016-10-10 >> >> Group: Individual Submission >> >> Pages: 5 >> >> URL: https://www.ietf.org/internet- >> drafts/draft-campbell-oauth-tls-client-auth-00.txt >> >> Status: https://datatracker.ietf.org/ >> doc/draft-campbell-oauth-tls-client-auth/ >> >> Htmlized: https://tools.ietf.org/html/d >> raft-campbell-oauth-tls-client-auth-00 >> >> >> >> >> >> Abstract: >> >> This document describes X.509 certificates as OAuth client >> >> credentials using Transport Layer Security (TLS) mutual >> >> authentication as a mechanism for client authentication to the >> >> authorization server's token endpoint. >> >> >> >> >> >> >> >> >> >> 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. >> >> >> >> The IETF Secretariat >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing listOAuth@ietf.orghttps://www. >> ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114973c23bf7600540b8b922 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Phil, what is your +1 referring to?

//Sa= muel

On = Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) <phil.hunt@oracle.com= > wrote:
+1

Phil

On Nov 4, 2016, at 6:11 PM, John Bra= dley <ve7jtb@ve7j= tb.com> wrote:

I can eas= ily see Research and education publishing self signed certs in meta-data th= at is then used for client authentication and other things.
I don=E2=80= =99t want to limit this to only CA issued certs where the client_id is in t= he DN. =C2=A0 =C2=A0Client_id tend not to be domain names currently.
<= div>Looking up a raw key =C2=A0provided via JWK in registration based on cl= ient_id will be one way that people will use this. =C2=A0 Passing the cert = is seen as just a way of passing the key to many people.

I also understand the desire in ACE to save bytes.

If you are using self signed certs then including the client_id in = the cert vs as a parameter is a bit of a no op re size.

Perhaps if there is a common pattern we could document a IoT profile = where ca issued cert is used and what it would look like.

I have concerns that this may open a can of worms around what the C= N would be and the interpretations of use extensions if this is flagged as = something other than a host cert. =C2=A0 =C2=A0What do devices do now when = they are issued certs.=C2=A0 Is there a common standard or is it by manufac= turer.

My main concern would be to not hold up wha= t should be a simple spec for the server to server case, but am willing to = accommodate IoT if possible.

Regards
Joh= n B.

On Oct 28= , 2016, at 5:31 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
=
Not wanting to add more meta parameters was a motivation. Als= o not being sure of how to enumerate the possible approaches. My thinking w= as also that there are a lot of factors involved and that it'd probably= be better left to service documentation to describe things like what autho= rities are trusted and what the client to cert binding is. Like I said, we = can look at adding more metadata, if there's some consensus to do so. B= ut I worry that it'll just be bloat that doesn't really add value. =

I also think that, in many situations, it's unlikely that= a cert will contain a client id anywhere as subject information. A client = id is scoped to a particular authorization server and it's hard to imag= ine a CA issuing a cert with an identifier that's only meaningful in th= e context of some other entity like that. Maybe in a more closed system whe= re the AS and an organizational CA are both in the same management/administ= rative domain but not in the more general case. =C2=A0



On Wed, Oct 26,= 2016 at 8:42 PM, Vladimir Dzhuvinov <vladimir@connect2id.com>= ; wrote:
I see.= Do you reckon the AS could simply probe the likely cert places
for containing the client_id? My reasoning is that there aren't that many places where you could stick the client_id (let me know if I'm
wrong). If the AS is in doubt it will respond with invalid_client. I'm<= br> starting to think this can work quite well. No extra meta param will be
needed (of which we have enough already).
On 22/10/16 01:51, Brian Campbell wrote:
> I did consider something like that but stopped short of putting it in = the
> -00 document. I'm not convinced that some metadata around it would= really
> contribute to interop one way or the other. I also wanted to get the b= asic
> concept written down before going too far into the weeds. But I'd = be open
> to adding something along those lines in future revisions, if there= 9;s some
> consensus that it'd be useful.
>
> On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <vladimir@connect2id.com<= br> >> wrote:
>> Superb, I welcome that!
>>
>> Regarding https://tools.ietf.org/html/= draft-campbell-oauth-tls-
>> client-auth-00#section-5.2 :
>>
>> My concern is that the choice of how to bind the client identity i= s left
>> to implementers, and that may eventually become an interop problem= .
>> Have you considered some kind of an open ended enumeration of the = possible
>> binding methods, and giving them some identifiers or names, so tha= t AS /
>> OPs can advertise them in their metadata, and clients register acc= ordingly?
>>
>> For example:
>>
>> "tls_client_auth_bind_methods_supported" : [ "= subject_alt_name_match",
>> "subject_public_key_info_match" ]
>>
>>
>> Cheers,
>>
>> Vladimir
>>
>> On 10/10/16 23:59, John Bradley wrote:
>>
>> At the request of the OpenID Foundation Financial Services API Wor= king group, Brian Campbell and I have documented
>> mutual TLS client authentication.=C2=A0 =C2=A0This is something th= at lots of people do in practice though we have never had a spec for it. >>
>> The Banks want to use it for some server to server API use cases b= eing driven by new open banking regulation.
>>
>> The largest thing in the draft is the IANA registration of =E2=80= =9Ctls_client_auth=E2=80=9D Token Endpoint authentication method for use in= Registration and discovery.
>>
>> The trust model is intentionally left open so that you could use a= =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct look= up of the subject public key against a reregistered value,=C2=A0 or somethi= ng in between.
>>
>> I hope that this is non controversial and the WG can adopt it quic= kly.
>>
>> Regards
>> John B.
>>
>>
>>
>>
>>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-campbell-oauth-tls-cli= ent-auth-00.txt
>> Date: October 10, 2016 at 5:44:39 PM GMT-3
>> To: "Brian Campbell" <brian.d.campbell@gmail.com= > <br= ian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com> <ve7jtb@ve7jtb.com&= gt;
>><= br> >>
>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00= .txt
>> has been successfully submitted by John Bradley and posted to the<= br> >> IETF repository.
>>
>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft= -campbell-oauth-tls-client-auth
>> Revision:=C2=A0 =C2=A0 00
>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mutua= l X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
>> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A02016-10-10
>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indiv= idual Submission
>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05
>> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draft= s/draft-campbell-oauth-tls-client-auth-00.txt
>> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-campbell-oa= uth-tls-client-auth/
>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-campbell-oauth-tls-clien= t-auth-00
>>
>>
>> Abstract:
>>=C2=A0 =C2=A0This document describes X.509 certificates as OAuth cl= ient
>>=C2=A0 =C2=A0credentials using Transport Layer Security (TLS) mutua= l
>>=C2=A0 =C2=A0authentication as a mechanism for client authenticatio= n to the
>>=C2=A0 =C2=A0authorization server's token endpoint.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.iet= f.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.or= g/mailman/listinfo/oauth
=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a114973c23bf7600540b8b922-- From nobody Mon Nov 7 09:12:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520511299DC for ; Mon, 7 Nov 2016 09:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emkJI8W3Mutx for ; Mon, 7 Nov 2016 09:12:00 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD13129648 for ; Mon, 7 Nov 2016 09:12:00 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uA7HBvli022545 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2016 17:11:58 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id uA7HBvxW026363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2016 17:11:57 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uA7HBtIX017129; Mon, 7 Nov 2016 17:11:55 GMT Received: from [10.0.1.4] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Nov 2016 09:11:54 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-1F030E6E-EA17-40A4-8069-DF44EFD0D6C2 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Mon, 7 Nov 2016 09:11:53 -0800 Content-Transfer-Encoding: 7bit Message-Id: <5E89F330-0A2E-4B60-A5F6-B9A6AEC6BE64@oracle.com> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <3B6518A2-CE89-48A4-B817-02C774C786B4@ve7jtb.com> To: Samuel Erdtman X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:12:02 -0000 --Apple-Mail-1F030E6E-EA17-40A4-8069-DF44EFD0D6C2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John's comments Phil > On Nov 7, 2016, at 8:43 AM, Samuel Erdtman wrote: >=20 > Phil, what is your +1 referring to? >=20 > //Samuel >=20 >> On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) wr= ote: >> +1 >>=20 >> Phil >>=20 >>> On Nov 4, 2016, at 6:11 PM, John Bradley wrote: >>>=20 >>> I can easily see Research and education publishing self signed certs in m= eta-data that is then used for client authentication and other things. >>> I don=E2=80=99t want to limit this to only CA issued certs where the cli= ent_id is in the DN. Client_id tend not to be domain names currently. >>> Looking up a raw key provided via JWK in registration based on client_i= d will be one way that people will use this. Passing the cert is seen as j= ust a way of passing the key to many people. >>>=20 >>> I also understand the desire in ACE to save bytes. >>>=20 >>> If you are using self signed certs then including the client_id in the c= ert vs as a parameter is a bit of a no op re size. >>>=20 >>> Perhaps if there is a common pattern we could document a IoT profile whe= re ca issued cert is used and what it would look like. >>>=20 >>> I have concerns that this may open a can of worms around what the CN wou= ld be and the interpretations of use extensions if this is flagged as someth= ing other than a host cert. What do devices do now when they are issued c= erts. Is there a common standard or is it by manufacturer. >>>=20 >>> My main concern would be to not hold up what should be a simple spec for= the server to server case, but am willing to accommodate IoT if possible. >>>=20 >>> Regards >>> John B. >>>=20 >>>> On Oct 28, 2016, at 5:31 PM, Brian Campbell wrote: >>>>=20 >>>> Not wanting to add more meta parameters was a motivation. Also not bein= g sure of how to enumerate the possible approaches. My thinking was also tha= t there are a lot of factors involved and that it'd probably be better left t= o service documentation to describe things like what authorities are trusted= and what the client to cert binding is. Like I said, we can look at adding m= ore metadata, if there's some consensus to do so. But I worry that it'll jus= t be bloat that doesn't really add value.=20 >>>>=20 >>>> I also think that, in many situations, it's unlikely that a cert will c= ontain a client id anywhere as subject information. A client id is scoped to= a particular authorization server and it's hard to imagine a CA issuing a c= ert with an identifier that's only meaningful in the context of some other e= ntity like that. Maybe in a more closed system where the AS and an organizat= ional CA are both in the same management/administrative domain but not in th= e more general case. =20 >>>>=20 >>>>=20 >>>>=20 >>>>> On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov wrote: >>>>> I see. Do you reckon the AS could simply probe the likely cert places >>>>> for containing the client_id? My reasoning is that there aren't that >>>>> many places where you could stick the client_id (let me know if I'm >>>>> wrong). If the AS is in doubt it will respond with invalid_client. I'm= >>>>> starting to think this can work quite well. No extra meta param will b= e >>>>> needed (of which we have enough already). >>>>>=20 >>>>> On 22/10/16 01:51, Brian Campbell wrote: >>>>> > I did consider something like that but stopped short of putting it i= n the >>>>> > -00 document. I'm not convinced that some metadata around it would r= eally >>>>> > contribute to interop one way or the other. I also wanted to get the= basic >>>>> > concept written down before going too far into the weeds. But I'd be= open >>>>> > to adding something along those lines in future revisions, if there'= s some >>>>> > consensus that it'd be useful. >>>>> > >>>>> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov >>>> >> wrote: >>>>> >> Superb, I welcome that! >>>>> >> >>>>> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls- >>>>> >> client-auth-00#section-5.2 : >>>>> >> >>>>> >> My concern is that the choice of how to bind the client identity is= left >>>>> >> to implementers, and that may eventually become an interop problem.= >>>>> >> Have you considered some kind of an open ended enumeration of the p= ossible >>>>> >> binding methods, and giving them some identifiers or names, so that= AS / >>>>> >> OPs can advertise them in their metadata, and clients register acco= rdingly? >>>>> >> >>>>> >> For example: >>>>> >> >>>>> >> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name_matc= h", >>>>> >> "subject_public_key_info_match" ] >>>>> >> >>>>> >> >>>>> >> Cheers, >>>>> >> >>>>> >> Vladimir >>>>> >> >>>>> >> On 10/10/16 23:59, John Bradley wrote: >>>>> >> >>>>> >> At the request of the OpenID Foundation Financial Services API Work= ing group, Brian Campbell and I have documented >>>>> >> mutual TLS client authentication. This is something that lots of p= eople do in practice though we have never had a spec for it. >>>>> >> >>>>> >> The Banks want to use it for some server to server API use cases be= ing driven by new open banking regulation. >>>>> >> >>>>> >> The largest thing in the draft is the IANA registration of =E2=80=9C= tls_client_auth=E2=80=9D Token Endpoint authentication method for use in Reg= istration and discovery. >>>>> >> >>>>> >> The trust model is intentionally left open so that you could use a =E2= =80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct lookup of= the subject public key against a reregistered value, or something in betwe= en. >>>>> >> >>>>> >> I hope that this is non controversial and the WG can adopt it quick= ly. >>>>> >> >>>>> >> Regards >>>>> >> John B. >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> Begin forwarded message: >>>>> >> >>>>> >> From: internet-drafts@ietf.org >>>>> >> Subject: New Version Notification for draft-campbell-oauth-tls-clie= nt-auth-00.txt >>>>> >> Date: October 10, 2016 at 5:44:39 PM GMT-3 >>>>> >> To: "Brian Campbell" , "John Bradley" >>>>> >> >>>>> >> >>>>> >> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >>>>> >> has been successfully submitted by John Bradley and posted to the >>>>> >> IETF repository. >>>>> >> >>>>> >> Name: draft-campbell-oauth-tls-client-auth >>>>> >> Revision: 00 >>>>> >> Title: Mutual X.509 Transport Layer Security (TLS) Au= thentication for OAuth Clients >>>>> >> Document date: 2016-10-10 >>>>> >> Group: Individual Submission >>>>> >> Pages: 5 >>>>> >> URL: https://www.ietf.org/internet-drafts/draft-campbell= -oauth-tls-client-auth-00.txt >>>>> >> Status: https://datatracker.ietf.org/doc/draft-campbell-oau= th-tls-client-auth/ >>>>> >> Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-tl= s-client-auth-00 >>>>> >> >>>>> >> >>>>> >> Abstract: >>>>> >> This document describes X.509 certificates as OAuth client >>>>> >> credentials using Transport Layer Security (TLS) mutual >>>>> >> authentication as a mechanism for client authentication to the >>>>> >> authorization server's token endpoint. >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> Please note that it may take a couple of minutes from the time of s= ubmission >>>>> >> until the htmlized version and diff are available at tools.ietf.org= . >>>>> >> >>>>> >> The IETF Secretariat >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listin= fo/oauth >>>>> >> >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> OAuth mailing list >>>>> >> OAuth@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>> >> >>>>> >> >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail-1F030E6E-EA17-40A4-8069-DF44EFD0D6C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
John's comments

Phil
=
On Nov 7, 2016, at 8:43 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

Phil, what is your +1 referring to?
//Samuel

On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) <= ;phil.hunt@oracle.= com> wrote:
+1

Phil

On Nov 4, 2016, at 6:11 PM, John B= radley <ve7jtb@ve7= jtb.com> wrote:

I can eas= ily see Research and education publishing self signed certs in meta-data tha= t is then used for client authentication and other things.
I don=E2=80=99= t want to limit this to only CA issued certs where the client_id is in the D= N.    Client_id tend not to be domain names currently.
L= ooking up a raw key  provided via JWK in registration based on client_i= d will be one way that people will use this.   Passing the cert is seen= as just a way of passing the key to many people.

I= also understand the desire in ACE to save bytes.

I= f you are using self signed certs then including the client_id in the cert v= s as a parameter is a bit of a no op re size.

Perha= ps if there is a common pattern we could document a IoT profile where ca iss= ued cert is used and what it would look like.

I hav= e concerns that this may open a can of worms around what the CN would be and= the interpretations of use extensions if this is flagged as something other= than a host cert.    What do devices do now when they are issued c= erts.  Is there a common standard or is it by manufacturer.
<= br>
My main concern would be to not hold up what should be a simpl= e spec for the server to server case, but am willing to accommodate IoT if p= ossible.

Regards
John B.

On Oct 28, 2016, at 5:31 PM, Br= ian Campbell <bcampbell@pingidentity.com> wrote:

Not wanting= to add more meta parameters was a motivation. Also not being sure of how to= enumerate the possible approaches. My thinking was also that there are a lo= t of factors involved and that it'd probably be better left to service docum= entation to describe things like what authorities are trusted and what the c= lient to cert binding is. Like I said, we can look at adding more metadata, i= f there's some consensus to do so. But I worry that it'll just be bloat that= doesn't really add value.

I also think that, in many situatio= ns, it's unlikely that a cert will contain a client id anywhere as subject i= nformation. A client id is scoped to a particular authorization server and i= t's hard to imagine a CA issuing a cert with an identifier that's only meani= ngful in the context of some other entity like that. Maybe in a more closed s= ystem where the AS and an organizational CA are both in the same management/= administrative domain but not in the more general case.  

=

On Wed, O= ct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
I se= e. Do you reckon the AS could simply probe the likely cert places
for containing the client_id? My reasoning is that there aren't that
many places where you could stick the client_id (let me know if I'm
wrong). If the AS is in doubt it will respond with invalid_client. I'm
starting to think this can work quite well. No extra meta param will be
needed (of which we have enough already).

= On 22/10/16 01:51, Brian Campbell wrote:
> I did consider something like that but stopped short of putting it in t= he
> -00 document. I'm not convinced that some metadata around it would real= ly
> contribute to interop one way or the other. I also wanted to get the ba= sic
> concept written down before going too far into the weeds. But I'd be op= en
> to adding something along those lines in future revisions, if there's s= ome
> consensus that it'd be useful.
>
> On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <vladimir@connect2id.com >> wrote:
>> Superb, I welcome that!
>>
>> Regarding https://tools.ietf.org/html/dr= aft-campbell-oauth-tls-
>> client-auth-00#section-5.2 :
>>
>> My concern is that the choice of how to bind the client identity is= left
>> to implementers, and that may eventually become an interop problem.=
>> Have you considered some kind of an open ended enumeration of the p= ossible
>> binding methods, and giving them some identifiers or names, so that= AS /
>> OPs can advertise them in their metadata, and clients register acco= rdingly?
>>
>> For example:
>>
>> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name= _match",
>> "subject_public_key_info_match" ]
>>
>>
>> Cheers,
>>
>> Vladimir
>>
>> On 10/10/16 23:59, John Bradley wrote:
>>
>> At the request of the OpenID Foundation Financial Services API Work= ing group, Brian Campbell and I have documented
>> mutual TLS client authentication.   This is something tha= t lots of people do in practice though we have never had a spec for it.
>>
>> The Banks want to use it for some server to server API use cases be= ing driven by new open banking regulation.
>>
>> The largest thing in the draft is the IANA registration of =E2=80=9C= tls_client_auth=E2=80=9D Token Endpoint authentication method for use in Reg= istration and discovery.
>>
>> The trust model is intentionally left open so that you could use a =E2= =80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct lookup of= the subject public key against a reregistered value,  or something in b= etween.
>>
>> I hope that this is non controversial and the WG can adopt it quick= ly.
>>
>> Regards
>> John B.
>>
>>
>>
>>
>>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-campbell-oauth-tls-clie= nt-auth-00.txt
>> Date: October 10, 2016 at 5:44:39 PM GMT-3
>> To: "Brian Campbell" <brian.d.campbell@gmail.com> <brian.d.campbell= @gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com> <ve7jtb@ve7jtb.com>
>> >>
>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.= txt
>> has been successfully submitted by John Bradley and posted to the >> IETF repository.
>>
>> Name:                draft-= campbell-oauth-tls-client-auth
>> Revision:    00
>> Title:               Mutual= X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
>> Document date:       2016-10-10
>> Group:               Indivi= dual Submission
>> Pages:               5
>> URL:            https://www.ietf.org/internet-drafts/dra= ft-campbell-oauth-tls-client-auth-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-= tls-client-auth/
>> Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
>>
>>
>> Abstract:
>>   This document describes X.509 certificates as OAuth cli= ent
>>   credentials using Transport Layer Security (TLS) mutual=
>>   authentication as a mechanism for client authentication= to the
>>   authorization server's token endpoint.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of s= ubmission
>> until the htmlized version and diff are available at tools.ietf.org= .
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.o= rg/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org<= /a>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>




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


= --Apple-Mail-1F030E6E-EA17-40A4-8069-DF44EFD0D6C2-- From nobody Mon Nov 7 09:54:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D1E12956F for ; Mon, 7 Nov 2016 09:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr9TopL75JvG for ; Mon, 7 Nov 2016 09:54:21 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076311296EC for ; Mon, 7 Nov 2016 09:54:21 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id C9832780346 for ; Mon, 7 Nov 2016 18:54:17 +0100 (CET) To: oauth@ietf.org From: Denis Message-ID: <58eb4c58-59c2-dac6-2e41-76ec359d4210@free.fr> Date: Mon, 7 Nov 2016 18:54:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------2D99B49BC4E79227F050D7A4" Archived-At: Subject: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:54:24 -0000 This is a multi-part message in MIME format. --------------2D99B49BC4E79227F050D7A4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies requirements. One of them (which, BTW, should be moved into Section 4 - Threats) is : Collusion: Resource servers that collude ... This threat addresses the case of "/collusion between servers"/ while the case of "/collusion between clients"/ has not been considered. When access tokens are being used, /collusion between clients /is of primary importance. Let us consider the following "Alice and Bob Collusion attack" (ABC attack). An uncle (Bob) is willing to collaborate with his young niece (Alice) who is less than 18 during a short period of time. The niece is opening her own session and creates an account on a server. The uncle does not hand over his own session to her niece at any point of time. Let us assume that some crypto expert has written two specific pieces of software. One has been installed on the laptop of the uncle and another one on the laptop of the niece. The two laptops are able to communicate using a network (e.g. a WAN or a LAN). The niece creates an account on a resource server. Later on, the resource server asks her (or him ?) to demonstrate that she (or his ?) is more than 18. She forwards the information received from the resource server to her uncle using the network. The uncle receives that information and connects to an Authorization Server. The uncle requests an access token containing information demonstrating that he is older than 18 and passed it back to his niece. The niece then presents it to the resource server. The access token is accepted. Since the niece has been able to demonstrate once that she is more than 18, the resource server will remember this attribute and in the future she will not need to demonstrate it again. She will keep the advantages related to this attribute associated with her account on that resource server until she does not need it anymore, i.e. when she will really be over 18. Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it . The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element. RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 has omitted to take into consideration the Alice and Bob Collusion attack. Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.2 available at: https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 : To prevent “credential pooling”, i.e., multiple Users sharing their credentials, credentials can optionally be bound to a secret key, i.e. a cryptographically strong random value that is assumed to be known only to a particular user. The credential specification specifies whether the credentials issued according to this specification are to employ key binding or not. A presentation token derived from such a key-bound credential always contains an implicit proof of knowledge of the underlying secret key, so that the Verifier can be sure that the rightful owner of the credential was involved in the creation of the presentation token. As an extra protection layer, the credentials can also be bound to a trusted physical device, such as a smart card, by keeping the secret key in a protected area of the device. That is, the key cannot be extracted from the device, but the device does participate in the presentation token generation to include an implicit proof of knowledge of this key in the token. Thus, for credentials that are key-bound to a physical device it is impossible to create a presentation token without the device. The rightful owner of the credential was indeed involved in real-time in the creation of the presentation token but in the collaboration scenario, the key binding mechanism is not sufficient to counter that specific attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft)are currently not resistant to the "ABC attack". The IRMA card project (https://www.irmacard.org/) based on the use of a smart card and of the Idemix scheme claims to provide security and privacy simultaneously. However, this project will not be resistant either to the ABC attack. *draft-ietf-oauth-pop-architecture-08 should take into consideration the ABC attack.* The threat related to the ABC attack should be identified in the security considerations section and the core of the document should attempt to identify one or more ways to counter it. The scope of draft-ietf-oauth-token-exchange-06 is limited to the definition of a basic request and response protocol for an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security Considerations) has omitted to take into consideration the ABC attack and therefore the currently described "basic request and response protocol" will allow Bob to obtain an access token and to pass it successfully to Alice so that she can use it. *draft-ietf-oauth-token-exchange-06 **should take into consideration the ABC attack.* The threat related to the ABC attack should be identified in the security considerations section and the core of the document should attempt to identify one or more ways to counter it. Denis PS. I have recently registered to the OAuth mailing list. --------------2D99B49BC4E79227F050D7A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies requirements.
One of them (which, BTW, should be moved into Section 4 - Threats) is :

Collusion:

      Resource servers that collude ...

This threat addresses the case of "collusion between servers" while the case of "collusion between clients"
has not been considered. When access tokens are being used, collusion between clients is of primary importance.

Let us consider the following "Alice and Bob Collusion attack" (ABC attack).

An uncle (Bob) is willing to collaborate with his young niece (Alice) who is less than 18 during a short period of time.
The niece is opening her own session and creates an account on a server. The uncle does not hand over his own session to her niece
at any point of time.

Let us assume that some crypto expert has written two specific pieces of software. One has been installed on the laptop
of the uncle and another one on the laptop of the niece. The two laptops are able to communicate using a network (e.g. a WAN or a LAN).

The niece creates an account on a resource server. Later on, the resource server asks her (or him ?) to demonstrate that she (or his ?)
is more than 18. She forwards the information received from the resource server to her uncle using the network. The uncle receives
that information and connects to an Authorization Server. The uncle requests an access token containing information demonstrating
that he is older than 18 and passed it back to his niece. The niece then presents it to the resource server. The access token is accepted.

Since the niece has been able to demonstrate once that she is more than 18, the resource server will remember this attribute
and in the future she will not need to demonstrate it again. She will keep the advantages related to this attribute associated
with her account on that resource server until she does not need it anymore, i.e. when she will really be over 18.

Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be
unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective
to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element.

RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 has omitted to take into consideration
the Alice and Bob Collusion attack.

Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.2 available at:
https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 :

To prevent “credential pooling”, i.e., multiple Users sharing their credentials, credentials can optionally be bound to a secret key,
i.e. a cryptographically strong random value that is assumed to be known only to a particular user. The credential specification
specifies whether the credentials issued according to this specification are to employ key binding or not.

A presentation token derived from such a key-bound credential always contains an implicit proof of knowledge of the underlying secret key,
so that the Verifier can be sure that the rightful owner of the credential was involved in the creation of the presentation token.
As an extra protection layer, the credentials can also be bound to a trusted physical device, such as a smart card, by keeping
the secret key in a protected area of the device. That is, the key cannot be extracted from the device, but the device does participate
in the presentation token generation to include an implicit proof of knowledge of this key in the token. Thus, for credentials that are key-bound
to a physical device it is impossible to create a presentation token without the device.

The rightful owner of the credential was indeed involved in real-time in the creation of the presentation token but in the collaboration scenario,
the key binding mechanism is not sufficient to counter that specific attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft) are currently
not resistant to the "ABC attack".

The IRMA card project (https://www.irmacard.org/) based on the use of a smart card and of the Idemix scheme claims to provide security
and privacy simultaneously. However, this project will not be resistant either to the ABC attack.

draft-ietf-oauth-pop-architecture-08 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

The scope of draft-ietf-oauth-token-exchange-06 is limited to the definition of a basic request and response protocol for
an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security Considerations) has omitted to take into consideration
the ABC attack and therefore the currently described "basic request and response protocol" will allow Bob to obtain an access
token and to pass it successfully to Alice so that she can use it.

draft-ietf-oauth-token-exchange-06 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

Denis

PS. I have recently registered to the OAuth mailing list.


--------------2D99B49BC4E79227F050D7A4-- From nobody Thu Nov 10 12:11:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0B6129552 for ; Thu, 10 Nov 2016 12:11:30 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9zvGtD-ARpN for ; Thu, 10 Nov 2016 12:11:28 -0800 (PST) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (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 73756129680 for ; Thu, 10 Nov 2016 12:11:28 -0800 (PST) Received: from [192.168.1.10] ([79.100.90.55]) by :SMTPAUTH: with SMTP id 4vgUcMfdjjyME4vgVcyuEz; Thu, 10 Nov 2016 13:10:57 -0700 To: oauth@ietf.org References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu> <613701d6-7857-1933-f385-0969b4b0c9ba@gmail.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <57b45c6b-6ee4-41e6-264b-e557145991e6@connect2id.com> Date: Thu, 10 Nov 2016 22:10:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <613701d6-7857-1933-f385-0969b4b0c9ba@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040303060208010602020107" X-CMAE-Envelope: MS4wfB0dAPeFPXI5wQnFXKJCJzUZY8h8d0W6aqzGlvyW3nqXozAaOkb8qv3oFE9pOZrw7Lmhc/f51ZeZrzuRfU0TnFC7AGWKnAvX+p3zGbVGPSE/ZIp0sWjy /H77SVj/CHJQN12efUTtIU5cdOMr0Dqk0gKc3UwtVaab+RFT9BDveg8L Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 20:11:30 -0000 This is a cryptographically signed message in MIME format. --------------ms040303060208010602020107 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/11/16 19:11, Sergey Beryozkin wrote: > Hi > > In our implementation we support the following scenario: > - the client registers its public certificate during the client > registration Did you extend the standard client reg API for this purpose? How does the cert registration actually take place? > > - next, mutual/two-way TLS is used, so AccessTokenService tries to > figure out the client_id. At the moment it assumes the client_id is > (Java) X509Certificate.getSubjectX500Principal().getName(). > > Next it retrieves a client with this name and compares the TLS > client/peer certificate against the pre-registered one. > > I think it may be interesting to explore further if client_id can > become optional based on what Samuel said. > > For example, indeed I can see how I can update our code to have a > mapping between some of client certificate's properties and a client > id stored within a Client registration. > > The question is how to find a given Client registration effectively > given only a certificate, without an optional client_id. One would > need to have a map between these client certificate attribute and > client_id or Clients. > > Cheers, Sergey > > > > On 03/11/16 16:48, Samuel Erdtman wrote: >> I can see your point, maybe the client_id will not be in the >> certificate. >> If I had an AS I would select to trust one or several CAs and then >> create certificate mappings between certificate serial number (or some= >> other unique attribute in the certificate) and client_id. If I were to= >> bind a specific certificate to a client_id I lose the flexibility of t= he >> PKI (maybe what you want). >> >> I think multiple certificates might not be a uncommon situation >> especially if you call ASs from different organizations because they >> will trust different CAs. >> >> //Samuel >> >> >> On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer > > wrote: >> >> Jim, >> >> In those circumstances, are the clients generally calling multiple= >> different services? Or just one? For those that call multiple >> services, are they using multiple (different) client certificates?= >> >> I=92m not saying the client would issue its own cert in all cases = =97 >> much more common is what I=92ve seen, with clients being assigned = a >> certificate from a trusted CA, and then services that the client >> talks to being told to trust that CA and also assign the CN/DN of >> the cert a set of privileges. What I *haven=92t* seen is a client >> being issued multiple certificates to talk to multiple systems. Th= at >> latter case is common enough in the OAuth world that I wouldn=92t = want >> us to paint ourselves in a corner. >> >> =97 Justin >> >>> On Nov 3, 2016, at 10:31 AM, Jim Manico >> > wrote: >>> >>> Thanks Justin. I use several security intel services and they all= >>> have different cert delivery mechanisms for mutual TLS. It's >>> =95rare=95 for services to let clients choose certs, they are usu= ally >>> assigned to users by each service from my experience. >>> >>> Aloha, >>> -- >>> Jim Manico >>> @Manicode >>> Secure Coding Education >>> +1 (808) 652-3805 >>> >>> On Nov 3, 2016, at 8:51 AM, Justin Richer >> > wrote: >>> >>>> Yes, I elided the certificate issuance process. The point remain= s >>>> the same: you're not going to be submitting a CSR to the same >>>> party you're getting your client_id from, usually. If the draft >>>> assumes that, then it's incredibly limiting. >>>> >>>> >>>> Do people really use separate TLS client certs for separate >>>> connections in the wild? I've personally never seen that. What >>>> I've seen is that a piece of software gets its certificate that >>>> it uses to make whatever connections it needs to make. >>>> >>>> >>>> -- Justin >>>> >>>> >>>> On 11/3/2016 8:48 AM, Jim Manico wrote: >>>>> Just to be clear, the relationship should more like... >>>>> >>>>> AS issues public key to clients, or client sends public key to >>>>> AS. The authorities job is NOT to give the client the public >>>>> key, but to sign the public key for authenticity. It's bad >>>>> practice to accept the full cert (pub key+signature) from an >>>>> authority. If an authority is creating your public key, they ar= e >>>>> also creating your private key.... bad. >>>>> >>>>> > The client will use the same cert across multiple connections= , >>>>> possibly multiple AS's, but the same isn't true of the client_i= d. >>>>> >>>>> This seems like a bad idea. I suggest a separate key/signature >>>>> for each service. >>>>> -- >>>>> Jim Manico >>>>> @Manicode >>>>> Secure Coding Education >>>>> +1 (808) 652-3805 >>>>> >>>>> On Nov 3, 2016, at 8:41 AM, Justin Richer >>>> > wrote: >>>>> >>>>>> I agree that the client_id is unlikely to be found inside the >>>>>> certificate itself. The client_id is issued by the >>>>>> authorization server for the client to use at that single AS. >>>>>> The certificate is issued by the CA for the client to use on >>>>>> any connection. The AS and CA are not likely to be the same >>>>>> system in most deployments. The client will use the same cert >>>>>> across multiple connections, possibly multiple AS's, but the >>>>>> same isn't true of the client_id. >>>>>> >>>>>> Additionally, I think we want to allow for a binding of a >>>>>> self-signed certificate using dynamic registration, much the >>>>>> way that we already allow binding of a client-generated JWK >>>>>> today. >>>>>> >>>>>> I do think that more examples and guidance are warranted, >>>>>> though, to help AS developers. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>>>>>> >>>>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman >>>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> I agree it is written so that the connection to the >>>>>>> certificate is implicitly required but I think it would b= e >>>>>>> better if it was explicit written since the lack of a >>>>>>> connection would result in a potential security hole. >>>>>>> >>>>>>> >>>>>>> That's fair. I agree it can be made more explicit and that it= >>>>>>> be good to do so. >>>>>>> >>>>>>> >>>>>>> >>>>>>> When it comes to the client_id I think subject common nam= e >>>>>>> or maybe subject serial numbers will be the common >>>>>>> location, and I think an example would be valuable. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In my experience and the way we built support for mutual TLS >>>>>>> OAuth client auth the client_id value does not appear in the >>>>>>> certificate anywhere. I'm not saying it can't happen but don'= t >>>>>>> think it's particularly common. >>>>>>> >>>>>>> I can look at adding some examples, if there's some consensus= >>>>>>> that they'd be useful and this document moves forward. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I=B4m not saying it is a bad Idea just that I would prefe= r >>>>>>> if it was not a MUST. >>>>>>> With very limited addition of code it is just as easy to >>>>>>> get the certificate attribute for client id as it is to >>>>>>> get it from the HTTP request data (at least in java). I >>>>>>> also think that with the requirement to match the incomin= g >>>>>>> certificate in some way one has to read out the >>>>>>> certificate that was used to establish the connection to >>>>>>> do some kind of matching. >>>>>>> >>>>>>> >>>>>>> Getting data out of the certificate isn't a concern. I just >>>>>>> believe that the constancy of having the client id parameter >>>>>>> is worth the potential small amount duplicate data in some >>>>>>> cases. It's just a -00 draft though and if the WG wants to >>>>>>> proceed with this document, we seek further input and work >>>>>>> towards some consensus. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------ms040303060208010602020107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7 r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+ 4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ 4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjExMTAyMDEwNTRaMC8GCSqGSIb3DQEJBDEiBCDBAvfG5QcyaC4Zqx2shvhC57RFXVcV oK0/t6wVfqS6CDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQB0kb5lu2VD tr9i9JfcyJ+CitG/LbAj6LMgjK3RcQlGhg8quDPzAqiCghtR+H5jtE+z3m3wt/VZbNxZ7FRd s1OB9IR+AfHYlUtW+w6Vz07xMZNw/fT+vAXyMSJOJ2jXy5NzLkbW/mJHPyq9W/lwFBwuEvfy RLzYq/vYYLIwTdTxcARkTb0GoWh5VQgWap3638KzO9tEPinT5CeWkICy3DGFTggjgoKp2+SQ dTP7/nx65ViUYd7jhqbSvvUAgR/leKBRj/1lqbuT41CS44ipUA6rtFhT9azEy1wsEG2qUQpH XhGJ2zWjsb2b1FZ07+Nd3ae0cU5Py2qYYkcJvQbzYEqiAAAAAAAA --------------ms040303060208010602020107-- From nobody Thu Nov 10 13:58:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDEC12965A for ; Thu, 10 Nov 2016 13:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aruw7jdWNUYy for ; Thu, 10 Nov 2016 13:57:57 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B20A1294C2 for ; Thu, 10 Nov 2016 13:57:57 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id f82so58998937wmf.1 for ; Thu, 10 Nov 2016 13:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=85x82nEUmR+556Pf91NWkIZxX6wGXi821LSkDzV5f0I=; b=PmvxvFeTGQo8/oEPdztzBskDGUyQJ4kHjx95oN+5QkpkhidBI3VPu8ASeoTPK9JMIe DQTsbUXkwLLTHIS/+nHd2QlP+aJ+726uMvL5QgfyhEZKoVZKMu02/vwqQ+oFplNVQMt8 12Pkkdoc3xSWpq2TEkgMHbLNC6E5xRGStB9l8BEGSyd6L3Q1H0GuZK06plW17PgCv2EP D/MLQRDXa5OsUuW1lZXyJ1rJWGttEekwSeVRkja4650I1DMHsDpGcq7ZIaT7ZQEvQkOv PG+rb0mqTxNMZyoJwV8+DhWtV/zlHMXe1rCCNVr4A9pQzgvgIiFcub44RyFEasMPQf4R QueA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=85x82nEUmR+556Pf91NWkIZxX6wGXi821LSkDzV5f0I=; b=drUDJHYB1SlSy+MPR0H/9llgjQXqTJIiPv+z8R/cOo3yTlKlBVDfBgLVfKRWQphxkr z7fHU4WHeGfGQh5aRRWNlCxitAqnwu7R4KHTM8/VGEBF0+gS+lzoTyhD4WZkMWbKGmT/ mtWI0GkH5Mo67jLhgIbuSLn7XBmcNNWzbvVnOEljGiC2bKT67JjtBqglRt63AsJ1x49W dISUfPxYVSQfqHIKA+61O02i00s7TW4RjnNQJBze17gV2zWhPNPtYCiaQd8LjJhEGrER 1rho/2hp86KrVbmikuZc/qruOOsUJKJAfywqzliUWThSDpqiiUx/UMhbZQWWBdrA5GQr 1pfA== X-Gm-Message-State: ABUngve2mzKfnl5fowEQCRG4MWhjlKgaBdXgYebMHmC75u1m2qJYDUycnJUWPsoijfJz8A== X-Received: by 10.28.229.213 with SMTP id c204mr14353684wmh.72.1478815075346; Thu, 10 Nov 2016 13:57:55 -0800 (PST) Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id c202sm24114023wme.1.2016.11.10.13.57.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Nov 2016 13:57:54 -0800 (PST) To: Vladimir Dzhuvinov References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu> <613701d6-7857-1933-f385-0969b4b0c9ba@gmail.com> <57b45c6b-6ee4-41e6-264b-e557145991e6@connect2id.com> From: Sergey Beryozkin Message-ID: Date: Thu, 10 Nov 2016 21:57:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 21:58:00 -0000 On 10/11/16 21:57, Sergey Beryozkin wrote: > On 10/11/16 20:10, Vladimir Dzhuvinov wrote: >> >> >> On 03/11/16 19:11, Sergey Beryozkin wrote: >>> Hi >>> >>> In our implementation we support the following scenario: >>> - the client registers its public certificate during the client >>> registration >> >> Did you extend the standard client reg API for this purpose? > No. Should there be an option in the client reg API ? >> >> How does the cert registration actually take place? > The encoded certificate is an optional property of the Client class > which is part of the larger OAuth2 model. The clients are registered out > of band - the assumption that the product integrating our model will let > the admins upload a certificate associated with a given client, > alongside all the other information one would typically allocate at a > client registration time via some UI page. > In a particular integration instance I'm aware of no such option to > upload the certs is offered yet > > Sergey >> >>> >>> - next, mutual/two-way TLS is used, so AccessTokenService tries to >>> figure out the client_id. At the moment it assumes the client_id is >>> (Java) X509Certificate.getSubjectX500Principal().getName(). >>> >>> Next it retrieves a client with this name and compares the TLS >>> client/peer certificate against the pre-registered one. >>> >>> I think it may be interesting to explore further if client_id can >>> become optional based on what Samuel said. >>> >>> For example, indeed I can see how I can update our code to have a >>> mapping between some of client certificate's properties and a client >>> id stored within a Client registration. >>> >>> The question is how to find a given Client registration effectively >>> given only a certificate, without an optional client_id. One would >>> need to have a map between these client certificate attribute and >>> client_id or Clients. >>> >>> Cheers, Sergey >>> >>> >>> >>> On 03/11/16 16:48, Samuel Erdtman wrote: >>>> I can see your point, maybe the client_id will not be in the >>>> certificate. >>>> If I had an AS I would select to trust one or several CAs and then >>>> create certificate mappings between certificate serial number (or some >>>> other unique attribute in the certificate) and client_id. If I were to >>>> bind a specific certificate to a client_id I lose the flexibility of >>>> the >>>> PKI (maybe what you want). >>>> >>>> I think multiple certificates might not be a uncommon situation >>>> especially if you call ASs from different organizations because they >>>> will trust different CAs. >>>> >>>> //Samuel >>>> >>>> >>>> On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer >>> > wrote: >>>> >>>> Jim, >>>> >>>> In those circumstances, are the clients generally calling multiple >>>> different services? Or just one? For those that call multiple >>>> services, are they using multiple (different) client certificates? >>>> >>>> Im not saying the client would issue its own cert in all cases >>>> much more common is what Ive seen, with clients being assigned a >>>> certificate from a trusted CA, and then services that the client >>>> talks to being told to trust that CA and also assign the CN/DN of >>>> the cert a set of privileges. What I *havent* seen is a client >>>> being issued multiple certificates to talk to multiple systems. >>>> That >>>> latter case is common enough in the OAuth world that I wouldnt >>>> want >>>> us to paint ourselves in a corner. >>>> >>>> Justin >>>> >>>>> On Nov 3, 2016, at 10:31 AM, Jim Manico >>>> > wrote: >>>>> >>>>> Thanks Justin. I use several security intel services and they all >>>>> have different cert delivery mechanisms for mutual TLS. It's >>>>> rare for services to let clients choose certs, they are usually >>>>> assigned to users by each service from my experience. >>>>> >>>>> Aloha, >>>>> -- >>>>> Jim Manico >>>>> @Manicode >>>>> Secure Coding Education >>>>> +1 (808) 652-3805 >>>>> >>>>> On Nov 3, 2016, at 8:51 AM, Justin Richer >>>> > wrote: >>>>> >>>>>> Yes, I elided the certificate issuance process. The point remains >>>>>> the same: you're not going to be submitting a CSR to the same >>>>>> party you're getting your client_id from, usually. If the draft >>>>>> assumes that, then it's incredibly limiting. >>>>>> >>>>>> >>>>>> Do people really use separate TLS client certs for separate >>>>>> connections in the wild? I've personally never seen that. What >>>>>> I've seen is that a piece of software gets its certificate that >>>>>> it uses to make whatever connections it needs to make. >>>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> On 11/3/2016 8:48 AM, Jim Manico wrote: >>>>>>> Just to be clear, the relationship should more like... >>>>>>> >>>>>>> AS issues public key to clients, or client sends public key to >>>>>>> AS. The authorities job is NOT to give the client the public >>>>>>> key, but to sign the public key for authenticity. It's bad >>>>>>> practice to accept the full cert (pub key+signature) from an >>>>>>> authority. If an authority is creating your public key, they are >>>>>>> also creating your private key.... bad. >>>>>>> >>>>>>> > The client will use the same cert across multiple connections, >>>>>>> possibly multiple AS's, but the same isn't true of the >>>>>>> client_id. >>>>>>> >>>>>>> This seems like a bad idea. I suggest a separate key/signature >>>>>>> for each service. >>>>>>> -- >>>>>>> Jim Manico >>>>>>> @Manicode >>>>>>> Secure Coding Education >>>>>>> +1 (808) 652-3805 >>>>>>> >>>>>>> On Nov 3, 2016, at 8:41 AM, Justin Richer >>>>>> > wrote: >>>>>>> >>>>>>>> I agree that the client_id is unlikely to be found inside the >>>>>>>> certificate itself. The client_id is issued by the >>>>>>>> authorization server for the client to use at that single AS. >>>>>>>> The certificate is issued by the CA for the client to use on >>>>>>>> any connection. The AS and CA are not likely to be the same >>>>>>>> system in most deployments. The client will use the same cert >>>>>>>> across multiple connections, possibly multiple AS's, but the >>>>>>>> same isn't true of the client_id. >>>>>>>> >>>>>>>> Additionally, I think we want to allow for a binding of a >>>>>>>> self-signed certificate using dynamic registration, much the >>>>>>>> way that we already allow binding of a client-generated JWK >>>>>>>> today. >>>>>>>> >>>>>>>> I do think that more examples and guidance are warranted, >>>>>>>> though, to help AS developers. >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>> >>>>>>>> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>>>>>>>> >>>>>>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I agree it is written so that the connection to the >>>>>>>>> certificate is implicitly required but I think it would be >>>>>>>>> better if it was explicit written since the lack of a >>>>>>>>> connection would result in a potential security hole. >>>>>>>>> >>>>>>>>> >>>>>>>>> That's fair. I agree it can be made more explicit and that it >>>>>>>>> be good to do so. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> When it comes to the client_id I think subject common name >>>>>>>>> or maybe subject serial numbers will be the common >>>>>>>>> location, and I think an example would be valuable. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> In my experience and the way we built support for mutual TLS >>>>>>>>> OAuth client auth the client_id value does not appear in the >>>>>>>>> certificate anywhere. I'm not saying it can't happen but don't >>>>>>>>> think it's particularly common. >>>>>>>>> >>>>>>>>> I can look at adding some examples, if there's some consensus >>>>>>>>> that they'd be useful and this document moves forward. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Im not saying it is a bad Idea just that I would prefer >>>>>>>>> if it was not a MUST. >>>>>>>>> With very limited addition of code it is just as easy to >>>>>>>>> get the certificate attribute for client id as it is to >>>>>>>>> get it from the HTTP request data (at least in java). I >>>>>>>>> also think that with the requirement to match the incoming >>>>>>>>> certificate in some way one has to read out the >>>>>>>>> certificate that was used to establish the connection to >>>>>>>>> do some kind of matching. >>>>>>>>> >>>>>>>>> >>>>>>>>> Getting data out of the certificate isn't a concern. I just >>>>>>>>> believe that the constancy of having the client id parameter >>>>>>>>> is worth the potential small amount duplicate data in some >>>>>>>>> cases. It's just a -00 draft though and if the WG wants to >>>>>>>>> proceed with this document, we seek further input and work >>>>>>>>> towards some consensus. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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/ From nobody Thu Nov 10 23:27:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A54129A16 for ; Thu, 10 Nov 2016 23:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgmdvDr5cVwO for ; Thu, 10 Nov 2016 23:27:24 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96E0129A13 for ; Thu, 10 Nov 2016 23:27:23 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id p9so7106577vkd.3 for ; Thu, 10 Nov 2016 23:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EHk1TTwcgPyC8tDQGCoUScqxFTtglbyMuyZvD6syF9M=; b=Qw0XbwEh9pL1q1W6H203JqOamnxxJqq9KpwhwfVIfraIVVePHfyzd1YqdAJYk6C4EM EJ5og8T0LGqA3T1+Q7Hch/FGcDYaSU0xw9TuVH6U4+fJD6cWK1pkq1oXrxFQz5vY08jb FyIeYErA9y+GmGSYCjrLqYn+8Webzc1yyJnrAjkvHnF9dvzQ5NvqA8tzz8DQnqo0fPRz 2wm1r+LzSofZrqAWdrL2e2OCb1nyU8XEBdMiiZvnHiL+hJ/xQp/CPyVheY8xkC0E4Czz YGiZ/+X3b0F1Hzta00IFB8zoXIuLhCAcgPUFNgSUB/bMYFSRioPC+/7zyHHhxKt1TMOJ 1N4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=EHk1TTwcgPyC8tDQGCoUScqxFTtglbyMuyZvD6syF9M=; b=GiZ4T37uIKdS2+IJJi+MQpH++9OCR1ELF9BO7kF+UcRLklcYnj9kWo0y4dnVxe4kgb OCIeZKpzWCUTVN3+fVacAXF9bfcICebAKHwpYITkKvkRVkXeYo7VzTHZy7KUwSjSQ80e 7dWPi8/XyHENosHiv9BZFY+FdmR2Bi+oLgeWZayZzxdrF8oNtEYNd8LDpYg3e1X/AUMs G1fFmSy3Dp7hfdPmlCi2o34tFm4J5Iul7aQTs7P+t23QAUw6A9fXPeU/Iv4XYcfyEbPb VBaaEIAciQJKc5P8BKl5hBW2X0X8AeVBkgBYnhE7p6NQ8uOQHP576SLRpAQG3aqQuX+5 s2Eg== X-Gm-Message-State: ABUngvcO/RlKXkdupHAPjS+L67UBHrW/kqJ85gzu8GB/0D0GZhcL9oBYu7xZ91icIF97IGzoLgiNP/QA+suY+Q== X-Received: by 10.31.178.66 with SMTP id b63mr997986vkf.70.1478849242861; Thu, 10 Nov 2016 23:27:22 -0800 (PST) MIME-Version: 1.0 References: <58eb4c58-59c2-dac6-2e41-76ec359d4210@free.fr> In-Reply-To: <58eb4c58-59c2-dac6-2e41-76ec359d4210@free.fr> From: Nat Sakimura Date: Fri, 11 Nov 2016 07:27:12 +0000 Message-ID: To: Denis , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11439232cc19240541016b44 Archived-At: Subject: Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 07:27:27 -0000 --001a11439232cc19240541016b44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Denis for pointing it out. It may be desirable to add ABC attack to the list of threats. Torsten et al. are updating Threat Model and Security Considerations so it could potentially be included in there. Some remarks: - I suppose the assumption is that the Bob does not share his credentials with Alice: Otherwise, sharing the credential would achieve something worse. - In addition, it assumes that Bob does not give his device to Alice: Otherwise, something similar to ABC attack can be achieved by Bob giving Alice his Laptop or Phone, and I guess this happens more often than shipping Bob's access token to Alice. - With these assumptions: - It looks like a variation of token injection attack that we have been talking about for many years. - If we token bind the refresh and access tokens, the ABC attack as described does not work. - For something like Age verification, recognizing such attacks, it probably is a bad practice to rely on refresh/access token. The servi= ce should do more active check, e.g., through OpenID Connect. Best, Nat On Tue, Nov 8, 2016 at 2:54 AM Denis wrote: > Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies > requirements. > One of them (which, BTW, should be moved into Section 4 - Threats) is : > > Collusion: > > Resource servers that collude ... > > This threat addresses the case of "*collusion between servers"* while the > case of "*collusion between clients"* > has not been considered. When access tokens are being used, *collusion > between clients *is of primary importance. > > Let us consider the following "Alice and Bob Collusion attack" (ABC > attack). > > An uncle (Bob) is willing to collaborate with his young niece (Alice) who > is less than 18 during a short period of time. > The niece is opening her own session and creates an account on a server. > The uncle does not hand over his own session to her niece > at any point of time. > > Let us assume that some crypto expert has written two specific pieces of > software. One has been installed on the laptop > of the uncle and another one on the laptop of the niece. The two laptops > are able to communicate using a network (e.g. a WAN or a LAN). > > The niece creates an account on a resource server. Later on, the resource > server asks her (or him ?) to demonstrate that she (or his ?) > is more than 18. She forwards the information received from the resource > server to her uncle using the network. The uncle receives > that information and connects to an Authorization Server. The uncle > requests an access token containing information demonstrating > that he is older than 18 and passed it back to his niece. The niece then > presents it to the resource server. The access token is accepted. > > Since the niece has been able to demonstrate once that she is more than > 18, the resource server will remember this attribute > and in the future she will not need to demonstrate it again. She will kee= p > the advantages related to this attribute associated > with her account on that resource server until she does not need it > anymore, i.e. when she will really be over 18. > > Whatever kind of cryptographic is being used, when two users collaborate,= a > software-only solution will be > unable to prevent the transfer of an attribute of a user that possess it > to another user that does not possess it . > > The use of a secure element simply protecting the confidentiality and the > integrity of some secret key or private key will be ineffective > to counter the Alice and Bob collusion attack. Additional properties will > be required for the secure element. > > RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in > January 2013 has omitted to take into consideration > the Alice and Bob Collusion attack. > > Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.= 2 > available at: > https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 : > > To prevent =E2=80=9Ccredential pooling=E2=80=9D, i.e., multiple Users sha= ring their > credentials, credentials can optionally be bound to a secret key, > i.e. a cryptographically strong random value that is assumed to be known > only to a particular user. The credential speci=EF=AC=81cation > speci=EF=AC=81es whether the credentials issued according to this speci= =EF=AC=81cation are > to employ key binding or not. > > A presentation token derived from such a key-bound credential always > contains an implicit proof of knowledge of the underlying secret key, > so that the Veri=EF=AC=81er can be sure that the rightful owner of the cr= edential > was involved in the creation of the presentation token. > As an extra protection layer, the credentials can also be bound to a > trusted physical device, such as a smart card, by keeping > the secret key in a protected area of the device. That is, the key cannot > be extracted from the device, but the device does participate > in the presentation token generation to include an implicit proof of > knowledge of this key in the token. Thus, for credentials that are > key-bound > to a physical device it is impossible to create a presentation token > without the device. > > The rightful owner of the credential was indeed involved in real-time in > the creation of the presentation token but in the collaboration scenario, > the key binding mechanism is not sufficient to counter that specific > attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft) are currently > not resistant to the "ABC attack". > > The IRMA card project (https://www.irmacard.org/) based on the use of a > smart card and of the Idemix scheme claims to provide security > and privacy simultaneously. However, this project will not be resistant > either to the ABC attack. > > *draft-ietf-oauth-pop-architecture-08 should take into consideration the > ABC attack.* > > The threat related to the ABC attack should be identified in the security > considerations section > and the core of the document should attempt to identify one or more ways > to counter it. > > The scope of draft-ietf-oauth-token-exchange-06 is limited to the > definition of a basic request and response protocol for > an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security > Considerations) has omitted to take into consideration > the ABC attack and therefore the currently described "basic request and > response protocol" will allow Bob to obtain an access > token and to pass it successfully to Alice so that she can use it. > > *draft-ietf-oauth-token-exchange-06 **should take into consideration the > ABC attack.* > > The threat related to the ABC attack should be identified in the security > considerations section > and the core of the document should attempt to identify one or more ways > to counter it. > > Denis > > PS. I have recently registered to the OAuth mailing list. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation --001a11439232cc19240541016b44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Denis for pointing it out. It may be desirable to a= dd ABC attack to the list of threats. Torsten et al. are updating Threat Mo= del and Security Considerations so it could potentially be included in ther= e.=C2=A0

Some remarks:=C2=A0
  • I suppose the a= ssumption is that the Bob does not share his credentials with Alice: Otherw= ise, sharing the credential would achieve something worse.=C2=A0
  • In= addition, it assumes that Bob does not give his device to Alice: Otherwise= , something similar to ABC attack can be achieved by Bob giving Alice his L= aptop or Phone, and I guess this happens more often than shipping Bob's= access token to Alice.=C2=A0
  • With these assumptions:=C2=A0
    • It looks like a variation of token injection attack that we have b= een talking about for many years.=C2=A0
    • If we token bind the refres= h and access tokens, the ABC attack as described does not work.=C2=A0
      • <= li>For something like Age verification, recognizing such attacks, it probab= ly is a bad practice to rely on refresh/access token. The service should do= more active check, e.g., through OpenID Connect.=C2=A0
= Best,=C2=A0

Nat

On Tue, Nov 8, 2016 at 2:54 AM Denis &= lt;denis.ietf@free.fr> wrote:<= br>
=20 =20 =20

Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identi= fies requirements.
One of them (which, BTW, should be moved into Section 4 - Threats) is :=

Collusion:

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Resource servers that collude ...

This threat addresses the case of "collusion= between servers" while the case of "collusion between clients"
has not been considered. When access tokens are being used, collusion between clients is of primary importance.

Let us consider the following "Alice and Bob Collusion attack"= ; (ABC attack).

An uncle (Bob) is willing to collaborate with his young niece (Alice) who is less than 18 during a short period of time.
The niece is opening her own session and creates an account on a server. The uncle does not hand over his own session to her niece
at any point of time.

Let us assume that some crypto expert has written two specific pieces of software. One has been installed on the laptop
of the uncle and another one on the laptop of the niece. The two laptops are able to communicate using a network (e.g. a WAN or a LAN).<= /p>

The niece creates an account on a resource server. Later on, the resource server asks her (or him ?) to demonstrate that she (or his ?)
is more than 18. She forwards the information received from the resource server to her uncle using the network. The uncle receives
that information and connects to an Authorization Server. The uncle requests an access token containing information demonstrating
that he is older than 18 and passed it back to his niece. The niece then presents it to the resource server. The access token is accepted. =

Since the niece has been able to demonstrate once that she is more than 18, the resource server will remember this attribute
and in the future she will not need to demonstrate it again. She will keep the advantages related to this attribute associated
with her account on that resource server until she does not need it anymore, i.e. when she will really be over 18.

Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be
unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .=

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective
to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element.

RFC 6= 819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 has omitted to take into consideration
the Alice and Bob Collusion attack.

Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.2 available at:
https://abc4trust.eu/download/Deliverable= _D2.2.pdf states on page 17 :

<= span style=3D"font-family:Arial;color:#000099" lang=3D"EN-US" class=3D"gmai= l_msg">To prevent =E2=80=9Ccredential pooling=E2=80=9D, i.e., multiple Users sharing their credentials, credentials can optionally be bound to a secret key,
i.e. a cryptographically strong random value that is assumed to be known only to a particular user. The credential speci=EF=AC=81ca= tion
speci=EF=AC=81es whether the credentials issued according to this speci=EF=AC=81cation are to employ key binding or not.

A presentation token derived from such a key-bound credential always contains an implicit proof of knowledge of the underlying secret key,
so that the Veri=EF=AC=81er can be sure that the rightful owner of = the credential was involved in the creation of the presentation token.
As an extra protection layer, the credentials can also be bound to a trusted physical device, such as a smart card, by keeping
the secret key in a protected area of the device. That is, the key cannot be extracted from the device, but the device does participate
in the presentation token generation to include an implicit proof of knowledge of this key in the token. Thus, for credentials that are key-bound
to a physical device it is impossible to create a presentation token without the device.

The rightful owner of the credential was indeed involved in real-time in the creation of the presentation token but in the collaboration scenario,
the key binding mechanism is not sufficient to counter that specific attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft) are currently
not resistant to the "ABC attack".=

The IRMA card project (<= a class=3D"m_-9161026523283189907moz-txt-link-freetext gmail_msg" href=3D"h= ttps://www.irmacard.org/" target=3D"_blank">https://www.irmacard.org/) based on the use of a smart card and of the Idemix scheme claims to provide security
and privacy simultaneously. However, this project will not be resistant either to the ABC attack.

draft-ietf-oauth-pop-architecture-08 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

The scope of draft-ietf-oauth-token-exchange-06 is limited to the definition of a basic request and response protocol for
an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security Considerations) has omitted to take into consideration
the ABC attack and therefore the currently described "basic request and response protocol" will allow Bob to o= btain an access
token and to pass it successfully to Alice so that she can use it.

draft-ietf-oauth-token-exchange-06 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

Denis

PS. I have recently registered to the OAuth mailing list.


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

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a11439232cc19240541016b44-- From nobody Fri Nov 11 08:41:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181EC1297CC for ; Fri, 11 Nov 2016 08:41:23 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVnOrjnDeNBa for ; Fri, 11 Nov 2016 08:41:20 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446F9129437 for ; Fri, 11 Nov 2016 08:41:19 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id f82so101772630wmf.1 for ; Fri, 11 Nov 2016 08:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dLxp8/xYixpiE12Cp/qUiiyiWuZd+DeA3vPAz6qOa0M=; b=r7nWTCeNgmrG2Tb0hw5Fv4byYewFFKJ8w6un9sY0haDlyIDT3boBPDevYpXNHrs8sZ FXD82RpOpmq/2MCotO1KloMj8F7uHd1WiShq1FRB1Z0ggQCRxoMUUN6ijuZr295kUtvm J40PId9wWZPZcj8OI+xOIo39BWsexi4wkEbK9//K/I7HFf8mteFHfeyatFw+BX2XKc2q qIAW5ZUDpV2j7UQTEPCz9wYgOTzq6NWHKpIQ7UZdrGe9T2Phas0XBW425/Ff5sVgzeIO P0tHM885mXEKBvI1dDrFVSklV6/iwMO2WAftvWpnkXpabj5QMeS9gIDpSnI1ydqoaOA0 m0qg== 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; bh=dLxp8/xYixpiE12Cp/qUiiyiWuZd+DeA3vPAz6qOa0M=; b=WU2z4hAERG/O/SaVv7QHl1DEXfm7O8qebVVFEh5bIxhqHYjdzNc2UGXK/aPB+RizKQ ZEJO6u7C+AFlYMQYdHNye2FKRG8McZMXFL66YftcUG0yLNTFGuyqrZl10Ey5fOIyebZP uwgTL/VEjQ0GRT8V8cgI7rk/xZYriKAqRSAx+moWNqMIOVn+EhvH+b80Wh/Z9d8YPq9x JNOCjHKVxDq6dntekKGcMJsFPNADbQTzxhEL75R8eUwPQU01Y/KXteCM9Q93VNjGi6jZ SifYyJCHQCot9pkONtmlHvufBsrWNqfdvBCMMZNNpFKFEaxayf/O8tHKRvotJrpWBg4l fTDA== X-Gm-Message-State: ABUngverd5jl43ubqxjvXAfBdtT/2DvyScYpPPviqoViAsfsF6MQVr7g5rtPV4wZuQAduDkL/ZNIhmXxe7UITw== X-Received: by 10.28.226.7 with SMTP id z7mr13389319wmg.83.1478882478332; Fri, 11 Nov 2016 08:41:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.117.103 with HTTP; Fri, 11 Nov 2016 08:41:17 -0800 (PST) In-Reply-To: <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> From: Samuel Erdtman Date: Fri, 11 Nov 2016 17:41:17 +0100 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a114b05fcc939dd0541092847 Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 16:41:23 -0000 --001a114b05fcc939dd0541092847 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a quick comment, see inline On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer wrote: > I agree that the client_id is unlikely to be found inside the certificate > itself. The client_id is issued by the authorization server for the clien= t > to use at that single AS. The certificate is issued by the CA for the > client to use on any connection. The AS and CA are not likely to be the > same system in most deployments. The client will use the same cert across > multiple connections, possibly multiple AS's, but the same isn't true of > the client_id. > > Additionally, I think we want to allow for a binding of a self-signed > certificate using dynamic registration, much the way that we already allo= w > binding of a client-generated JWK today. > Should this specification then extend the dynamic registration specification (https://tools.ietf.org/html/rfc7591) with the certificate parameter to actually do the registration or is that another document? > I do think that more examples and guidance are warranted, though, to help > AS developers. > > -- Justin > > On 11/2/2016 5:03 PM, Brian Campbell wrote: > > > On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wrote= : > >> >> I agree it is written so that the connection to the certificate is >> implicitly required but I think it would be better if it was explicit >> written since the lack of a connection would result in a potential secur= ity >> hole. >> > > That's fair. I agree it can be made more explicit and that it be good to > do so. > > > >> When it comes to the client_id I think subject common name or maybe >> subject serial numbers will be the common location, and I think an examp= le >> would be valuable. >> >> > > In my experience and the way we built support for mutual TLS OAuth client > auth the client_id value does not appear in the certificate anywhere. I'm > not saying it can't happen but don't think it's particularly common. > > I can look at adding some examples, if there's some consensus that they'd > be useful and this document moves forward. > > > >> >> I=C2=B4m not saying it is a bad Idea just that I would prefer if it was = not a >> MUST. >> With very limited addition of code it is just as easy to get the >> certificate attribute for client id as it is to get it from the HTTP >> request data (at least in java). I also think that with the requirement = to >> match the incoming certificate in some way one has to read out the >> certificate that was used to establish the connection to do some kind of >> matching. >> >> > Getting data out of the certificate isn't a concern. I just believe that > the constancy of having the client id parameter is worth the potential > small amount duplicate data in some cases. It's just a -00 draft though a= nd > if the WG wants to proceed with this document, we seek further input and > work towards some consensus. > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --001a114b05fcc939dd0541092847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a quick comment, see inline

On Thu, Nov 3, 2016 at 1:41 PM, Justin = Richer <jricher@mit.edu> wrote:
=20 =20 =20

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client= _id.

Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

Should this specification then extend the dynamic= registration specification (https://tools.ietf.org/html/rfc7591) with the certificate parameter t= o actually do the registration or is that another document?
= =C2=A0

I do think that more examples and guidance are warranted, though, to help AS developers.

=C2=A0-- Justin


On 11/2/2016= 5:03 PM, Brian Campbell wrote:
=20

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explicit and that it be good to do so.

=C2=A0
When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
=C2=A0

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly co= mmon.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

=C2=A0
I=C2=B4m not saying it is a bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus.


= 

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


--001a114b05fcc939dd0541092847-- From nobody Fri Nov 11 10:13:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE211129C10 for ; Fri, 11 Nov 2016 10:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyir9BJMY579 for ; Fri, 11 Nov 2016 10:13:07 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48FE129BB2 for ; Fri, 11 Nov 2016 10:13:07 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id q124so328351028itd.1 for ; Fri, 11 Nov 2016 10:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2pWDnmJVypMNfgpsu6I676kragGCzs0xbOfCh4cf2SQ=; b=GUzjgCRDQP2oChcquTQUEmJqNhqgANPvlrA6Rzu9e89KYoTFFsw5QyiC1Xpe4gkrhy bN9sxXAfBYyxKhc/cJ8z4p254ptOMf5x9noL4peSwJ0ZAdg7R0FlvdEFB6peL2qJnjSg 0kHrV/BeoTvjP2hE76ux/ZNkgaK9d//K1dTnE= 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; bh=2pWDnmJVypMNfgpsu6I676kragGCzs0xbOfCh4cf2SQ=; b=gaje68pFthmJayHLy1BB7J1M47kqpec5Lur2hTNGwPjpjo8XOSzBFPbUWOIAS2WbKl 4ZjMHp+DGbWmcbnuJF9dNzw0DYYIWMUFVhh4tlfy9PpErDWR1qx67esE/VTWl4MQHqXs A3zjK4lCfqqkTpIa9xevoi3Z/dhU/cdiqn0KtAdCDCdKpF3D8d2L5KsZeVx3vI7Vm9et LL12BqgsxjUCfGcBooXtn7HpyKk1SUI8Yq3+6BezOlc+mXgUCM0oDaAq+x94CP564Wjv vzH1w1k+aN2Fhu592qQshGkIESpPwtGcOLU64+O1EeKEId2nq0uJONN4nvn12i0JtWpB 1sBg== X-Gm-Message-State: ABUngvcQePD6BL+S5G3JWBeZSRxyE7nIVFntw4etYPj2bQBy8jzqfnvZToi3+W6d+0Pe3jWLrpS13fq0E5atG6/S X-Received: by 10.36.31.82 with SMTP id d79mr9539323itd.79.1478887986111; Fri, 11 Nov 2016 10:13:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Fri, 11 Nov 2016 10:13:05 -0800 (PST) Received: by 10.79.156.74 with HTTP; Fri, 11 Nov 2016 10:13:05 -0800 (PST) In-Reply-To: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> From: Brian Campbell Date: Fri, 11 Nov 2016 11:13:05 -0700 Message-ID: To: Samuel Erdtman Content-Type: multipart/alternative; boundary=001a1145e85213700105410a71cb Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 18:13:09 -0000 --001a1145e85213700105410a71cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wouldn't the existing jwks/jwks_uri client metadata parameters suffice? Perhaps some guidance in this document about that is warranted. But I don't believe anything new is needed for that case. On Nov 11, 2016 9:41 AM, "Samuel Erdtman" wrote: > Just a quick comment, see inline > > On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer wrote: > >> I agree that the client_id is unlikely to be found inside the certificat= e >> itself. The client_id is issued by the authorization server for the clie= nt >> to use at that single AS. The certificate is issued by the CA for the >> client to use on any connection. The AS and CA are not likely to be the >> same system in most deployments. The client will use the same cert acros= s >> multiple connections, possibly multiple AS's, but the same isn't true of >> the client_id. >> >> Additionally, I think we want to allow for a binding of a self-signed >> certificate using dynamic registration, much the way that we already all= ow >> binding of a client-generated JWK today. >> > Should this specification then extend the dynamic registration > specification (https://tools.ietf.org/html/rfc7591) with the certificate > parameter to actually do the registration or is that another document? > > >> I do think that more examples and guidance are warranted, though, to hel= p >> AS developers. >> >> -- Justin >> >> On 11/2/2016 5:03 PM, Brian Campbell wrote: >> >> >> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman >> wrote: >> >>> >>> I agree it is written so that the connection to the certificate is >>> implicitly required but I think it would be better if it was explicit >>> written since the lack of a connection would result in a potential secu= rity >>> hole. >>> >> >> That's fair. I agree it can be made more explicit and that it be good to >> do so. >> >> >> >>> When it comes to the client_id I think subject common name or maybe >>> subject serial numbers will be the common location, and I think an exam= ple >>> would be valuable. >>> >>> >> >> In my experience and the way we built support for mutual TLS OAuth clien= t >> auth the client_id value does not appear in the certificate anywhere. I'= m >> not saying it can't happen but don't think it's particularly common. >> >> I can look at adding some examples, if there's some consensus that they'= d >> be useful and this document moves forward. >> >> >> >>> >>> I=C2=B4m not saying it is a bad Idea just that I would prefer if it was= not a >>> MUST. >>> With very limited addition of code it is just as easy to get the >>> certificate attribute for client id as it is to get it from the HTTP >>> request data (at least in java). I also think that with the requirement= to >>> match the incoming certificate in some way one has to read out the >>> certificate that was used to establish the connection to do some kind o= f >>> matching. >>> >>> >> Getting data out of the certificate isn't a concern. I just believe that >> the constancy of having the client id parameter is worth the potential >> small amount duplicate data in some cases. It's just a -00 draft though = and >> if the WG wants to proceed with this document, we seek further input and >> work towards some consensus. >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> > --001a1145e85213700105410a71cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Wouldn't the existing jwks/jwks_uri client metadata para= meters suffice? Perhaps some guidance in this document about that is warran= ted. But I don't believe anything new is needed for that case.


On Nov 11, 2016 9= :41 AM, "Samuel Erdtman" <samuel@erdtman.se> wrote:
Just a quick comment, see inline

On Thu, Nov 3, 2016 at 1:= 41 PM, Justin Richer <jricher@mit.edu> wrote:
=20 =20 =20

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client= _id.

Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

Should this specification then extend the dynamic= registration specification (https://tools.ietf.org/html/rfc7591) with the = certificate parameter to actually do the registration or is that another do= cument?
=C2=A0

I do think that more examples and guidance are warranted, though, to help AS developers.

=C2=A0-- Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:
=20

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explicit and that it be good to do so.

=C2=A0
When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
=C2=A0

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly co= mmon.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

=C2=A0
I=C2=B4m not saying it is a bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



________=
_______________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth


--001a1145e85213700105410a71cb-- From nobody Fri Nov 11 12:05:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897DE129571 for ; Fri, 11 Nov 2016 12:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.497, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org 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 mMgm5zmAhkcn for ; Fri, 11 Nov 2016 12:05:34 -0800 (PST) Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504B5129CA0 for ; Fri, 11 Nov 2016 12:05:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id D8677B41CA for ; Fri, 11 Nov 2016 20:05:33 +0000 (UTC) Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1478894733; x=1479758734; bh=NVJOEt8YLW nyFHGAFwSmmGqbKJH/S8fShvO3fKq72Us=; b=aCbUr7pxp6iRnuE20gL8JJ66gC ZAaRfuMuydIfjSKqe3JAHzX7NWdYQKkX1uj1WtEuQ4bfGWOXog/8y4EIj2cRc6aZ b8xy6UW0sdoSD7UDQS0M982zEqjzo2/Qj8+ISyKuMg1epw5/ww1aFBraFyG/OR2X N3PcdLKCB88eKa+KM= Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KjDfoxLaIdC for ; Fri, 11 Nov 2016 15:05:33 -0500 (EST) Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id A4F2AB410E for ; Fri, 11 Nov 2016 15:05:33 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 11 Nov 2016 14:05:33 -0600 From: Mike Schwartz To: oauth@ietf.org Organization: Gluu In-Reply-To: References: Message-ID: X-Sender: mike@gluu.org User-Agent: Roundcube Webmail Archived-At: Subject: [OAUTH-WG] Publishing authentication level as first amr value X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 20:05:36 -0000 Gluu is working on a free open source app called Cred Mgr: github.com/GluuFederation/cred-mgr As the name suggests, this app is a user-facing application that let's the person reset existing credentials and register new credentials. To avoid degrading the security of credentials, we want to make sure that a person can only reset a credential if they present one with equal or greater stength, or "level" Cred-mgr knows the level, because we are returning it as the first value in the amr array in the id_token. We are also publishing a mapping of amr values to acr values in the OP discovery page. For example: "auth_level_mapping": { "50": ["http://example.com/saml"], "10": ["http://example.com/u2f", "http://example.com/duo"], "1": ["http://example.com/pw"] }, If we could agree on this appraoch, then it could be interoperable across domains. I don't see any other solutions being proposed, so no one can figure out how to properly handle multi-factor credential reset in a standard way. - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org http://support.gluu.org From nobody Fri Nov 11 12:17:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8D1129CC5 for ; Fri, 11 Nov 2016 12:17:28 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkfsARUWiy19 for ; Fri, 11 Nov 2016 12:17:25 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E85129CB3 for ; Fri, 11 Nov 2016 12:17:25 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id t79so110824069wmt.0 for ; Fri, 11 Nov 2016 12:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qFc5z3HMPuR1KUaj3AVoX8WHMeXtjhbMasSOOm008lc=; b=mz1uV71VcbzFQxGyBxGyHc9YdT65jdMYhZLH6a5q9j3sbiLbeBJXpQRLtdBxxfO+my eDrBMqvV4XfY804GqWgGMY+F6StYV+xSa7fVMQQhpE4vkA/gUvLXp56SC2722Dm3TPtY ja4joajm9imjmGpPQTSnGZLjXgJpri4mR4WyNEaR5ZjwYD4dqISTZGKh7UQGrvAVLEAS OFO9ENp5n2+h7x6q6thGGpKeGOEPdW+SVpXXXvLzPe8tg/JEar3wgmfIWlLXGx34WLYY ze+6DatSEHDd3SuTukgxQkjf8STYGWzMWuGvF46i/FVZT3jkNYwAjWY4VyQ6UEmhDWiw i6dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qFc5z3HMPuR1KUaj3AVoX8WHMeXtjhbMasSOOm008lc=; b=Ml0pbQ5AKqc/iOxHQsz4IztoW4qp62mXLcHXraYNa8UCmXOFbAN/XmXMvtIImGu8lR fmlS0pJrjDvw7pOgvZ1AymKhXe34te3PSgAa4AC+28MIqgAvTbPkTxbfsOOEtFt1/i4t PpFCLCjXQsP1sxnLDzNvSuPGg3eoznOlLsB+Dvw0sc6OGr8u50QST4pk8xZkL6uneKnC dwN5qsmk9PXQCp8vy2x68WtN1NNsGWwJZWH91h1zahRt9SvwhQGTKvZaXk74nozYeFyR oTwDY4MnFsFLWGGr7c1zJ2FcB3vS/lPjl+kWtj1fOVXrQMO6/oEHZ9NzSe2dI7cysOxh 000Q== X-Gm-Message-State: ABUngvd2IpviQpWJ8yhf8ZwKmWGUXPdTWo9RPeFcBwVSK8dMy0jBXbnBop8JqSA8JSApfuluUMsc49pspZ0UBg== X-Received: by 10.194.123.197 with SMTP id mc5mr10221458wjb.231.1478895443892; Fri, 11 Nov 2016 12:17:23 -0800 (PST) MIME-Version: 1.0 References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> In-Reply-To: From: Samuel Erdtman Date: Fri, 11 Nov 2016 20:17:13 +0000 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=089e011831ae9800d105410c2d65 Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 20:17:28 -0000 --089e011831ae9800d105410c2d65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You are absolutely right one could use the On Fri, 11 Nov 2016 at 19:13, Brian Campbell wrote: > Wouldn't the existing jwks/jwks_uri client metadata parameters suffice? > Perhaps some guidance in this document about that is warranted. But I don= 't > believe anything new is needed for that case. > > On Nov 11, 2016 9:41 AM, "Samuel Erdtman" wrote: > > Just a quick comment, see inline > > On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer wrote: > > I agree that the client_id is unlikely to be found inside the certificate > itself. The client_id is issued by the authorization server for the clien= t > to use at that single AS. The certificate is issued by the CA for the > client to use on any connection. The AS and CA are not likely to be the > same system in most deployments. The client will use the same cert across > multiple connections, possibly multiple AS's, but the same isn't true of > the client_id. > > Additionally, I think we want to allow for a binding of a self-signed > certificate using dynamic registration, much the way that we already allo= w > binding of a client-generated JWK today. > > Should this specification then extend the dynamic registration > specification (https://tools.ietf.org/html/rfc7591) with the certificate > parameter to actually do the registration or is that another document? > > > I do think that more examples and guidance are warranted, though, to help > AS developers. > > -- Justin > > On 11/2/2016 5:03 PM, Brian Campbell wrote: > > > On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wrote= : > > > I agree it is written so that the connection to the certificate is > implicitly required but I think it would be better if it was explicit > written since the lack of a connection would result in a potential securi= ty > hole. > > > That's fair. I agree it can be made more explicit and that it be good to > do so. > > > > When it comes to the client_id I think subject common name or maybe > subject serial numbers will be the common location, and I think an exampl= e > would be valuable. > > > > In my experience and the way we built support for mutual TLS OAuth client > auth the client_id value does not appear in the certificate anywhere. I'm > not saying it can't happen but don't think it's particularly common. > > I can look at adding some examples, if there's some consensus that they'd > be useful and this document moves forward. > > > > > I=C2=B4m not saying it is a bad Idea just that I would prefer if it was n= ot a > MUST. > With very limited addition of code it is just as easy to get the > certificate attribute for client id as it is to get it from the HTTP > request data (at least in java). I also think that with the requirement t= o > match the incoming certificate in some way one has to read out the > certificate that was used to establish the connection to do some kind of > matching. > > > Getting data out of the certificate isn't a concern. I just believe that > the constancy of having the client id parameter is worth the potential > small amount duplicate data in some cases. It's just a -00 draft though a= nd > if the WG wants to proceed with this document, we seek further input and > work towards some consensus. > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > --089e011831ae9800d105410c2d65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You are absolutely right one could use = the

On Fri, 11 Nov 20= 16 at 19:13, Brian Campbell <bcampbell@pingidentity.com> wrote:

Wouldn't the existing jwks= /jwks_uri client metadata parameters suffice? Perhaps some guidance in this= document about that is warranted. But I don't believe anything new is = needed for that case.


On Nov 11, 2016 9:41 AM, "Samuel Erdtman" = <samuel@erdtman.se> wrote:
Just a quick comment, see inline

On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <jricher@mit.edu> wrote:
=20 =20 =20

I agree that the client_id is unlikely to be fou= nd inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client= _id.

Additionally, I think we want to allow for a bin= ding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

Should th= is specification then extend the dynamic registration specification (https://tools.ietf.org/html/rfc7591) with the certificate paramete= r to actually do the registration or is that another document?
=C2=A0

I do think that more examples and guidance are w= arranted, though, to help AS developers.

=C2=A0-- Justin


On 11/2/2016 5:03 PM, Brian Campbe= ll wrote:
=20

On Sun, Oct 30, 2016 at 9:27 A= M, Samuel Erdtman <samuel@erdtman.= se> wrote:
I agree it is written so that = the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be mad= e more explicit and that it be good to do so.

=C2=A0
When it comes to the client_id= I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
=C2=A0

In my experience and the way we built = support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly co= mmon.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

=C2=A0
I=C2=B4m not saying it is a ba= d Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate is= n't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



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


--089e011831ae9800d105410c2d65-- From nobody Fri Nov 11 12:21:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9436129CCA for ; Fri, 11 Nov 2016 12:21:44 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVJFsTQuvzIW for ; Fri, 11 Nov 2016 12:21:43 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746AA1295AC for ; Fri, 11 Nov 2016 12:21:42 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id c184so438508wmd.0 for ; Fri, 11 Nov 2016 12:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4x3Vt8/zMPx9yjgIX8phy/MVkqcgwHL3ki+cnxdrH/Q=; b=ZEDgwHDvQpca+xoz9+EpmLawIwpQ84UQR/DBT4Dk9cT7zoDXvaRvk1JK47AcH6utVU g2kXNXLH7Z+rCBKgLCk3yT72Mknqhfb0VVNYP1lrkyP+C9yWqbEguSuC/w+2JtdnJSPa NSDjZrGi6kxXOxChjcFWVOU8yota2efYgOwwFOZfcHxTuRcEp55DycQxLAuvAMBzu4UI dLsRPqVgzIZQsKC5Lgx71lNcCWlyiDpLvzac5qkObF2V+FAFLrRGCypXiRTNwa5poGVe mfC1ewzDjm2zKfRDJk6BX1vlFz8PvDEF8iieKL4oGMHjGha96/oOYrneW517hzSm0+vB rRyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4x3Vt8/zMPx9yjgIX8phy/MVkqcgwHL3ki+cnxdrH/Q=; b=UNkKKAK8WpG00A2PHWJAlIoD0I+assZYMw50AlKHNeScpYw5VYTKVi6OE/LnxN9cXM lO4jXn61bc+nrBeCbDd6pLI7Ff2bGxTp1nLXH28odWL3FBr0KbvsOcGdc6rS6D0R65Ro O6n7Kz2ZylYEXcg9t5L5tyHCzsRPVBsGutrOedSlvPfMWmJK8Fb0jNMksXAK8sBp+oaH a9ihbD3coy5TNdK7eefSX3n3BEL7RYCWr0C/WLg996E4Rr+AomyFAbhhiZYx7p0585sD sdfNv7zIdyuuHHfKl+y8ApJtjc+IVW7I8ZkFK9H7UzGu19pDASfsa0sh2b2hwDN37K0K feVg== X-Gm-Message-State: ABUngvdq0opzXCade9cD4P5xq5SoGimUjish7T8ScNQz+yGi3yTRyGGOcqNXtxbIPyTnJFsgHWo8p+P0SwfrSw== X-Received: by 10.194.222.202 with SMTP id qo10mr10535637wjc.115.1478895701034; Fri, 11 Nov 2016 12:21:41 -0800 (PST) MIME-Version: 1.0 References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> In-Reply-To: From: Samuel Erdtman Date: Fri, 11 Nov 2016 20:21:30 +0000 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c3ba62eb9b6a05410c3cdd Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 20:21:45 -0000 --001a11c3ba62eb9b6a05410c3cdd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You are right one could absolutely use the jwks or jwks_uri attribute, but from my point of view that would be a workaround. I would prefer that x5u, x5c and/or x5t was directly available in the client registration request not via jwks. This would be a cleaner solution. Best Regards Samuel On Fri, 11 Nov 2016 at 19:13, Brian Campbell wrote: > Wouldn't the existing jwks/jwks_uri client metadata parameters suffice? > Perhaps some guidance in this document about that is warranted. But I don= 't > believe anything new is needed for that case. > > On Nov 11, 2016 9:41 AM, "Samuel Erdtman" wrote: > > Just a quick comment, see inline > > On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer wrote: > > I agree that the client_id is unlikely to be found inside the certificate > itself. The client_id is issued by the authorization server for the clien= t > to use at that single AS. The certificate is issued by the CA for the > client to use on any connection. The AS and CA are not likely to be the > same system in most deployments. The client will use the same cert across > multiple connections, possibly multiple AS's, but the same isn't true of > the client_id. > > Additionally, I think we want to allow for a binding of a self-signed > certificate using dynamic registration, much the way that we already allo= w > binding of a client-generated JWK today. > > Should this specification then extend the dynamic registration > specification (https://tools.ietf.org/html/rfc7591) with the certificate > parameter to actually do the registration or is that another document? > > > I do think that more examples and guidance are warranted, though, to help > AS developers. > > -- Justin > > On 11/2/2016 5:03 PM, Brian Campbell wrote: > > > On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman wrote= : > > > I agree it is written so that the connection to the certificate is > implicitly required but I think it would be better if it was explicit > written since the lack of a connection would result in a potential securi= ty > hole. > > > That's fair. I agree it can be made more explicit and that it be good to > do so. > > > > When it comes to the client_id I think subject common name or maybe > subject serial numbers will be the common location, and I think an exampl= e > would be valuable. > > > > In my experience and the way we built support for mutual TLS OAuth client > auth the client_id value does not appear in the certificate anywhere. I'm > not saying it can't happen but don't think it's particularly common. > > I can look at adding some examples, if there's some consensus that they'd > be useful and this document moves forward. > > > > > I=C2=B4m not saying it is a bad Idea just that I would prefer if it was n= ot a > MUST. > With very limited addition of code it is just as easy to get the > certificate attribute for client id as it is to get it from the HTTP > request data (at least in java). I also think that with the requirement t= o > match the incoming certificate in some way one has to read out the > certificate that was used to establish the connection to do some kind of > matching. > > > Getting data out of the certificate isn't a concern. I just believe that > the constancy of having the client id parameter is worth the potential > small amount duplicate data in some cases. It's just a -00 draft though a= nd > if the WG wants to proceed with this document, we seek further input and > work towards some consensus. > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > --001a11c3ba62eb9b6a05410c3cdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You are right one could absolutely use = the jwks or jwks_uri attribute, but from my point of view that would be a w= orkaround.
I would prefer that x5u, x5c and/or x5t was directly availabl= e in the client registration request not via jwks. This would be a cleaner = solution.

Best Regards
Samuel

On Fri, 11 Nov 2016 at 19:13, Brian Campbell <bcampbell@pingidentity.com> w= rote:

Wouldn't the existing jwks/jwks_uri client metadata parameters su= ffice? Perhaps some guidance in this document about that is warranted. But = I don't believe anything new is needed for that case.


On Nov 11, 2016 9:41 AM, "Samuel Erdtman" = <samuel@erdtman.se> wrote:
Just a quick comment, see inline

On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <jricher@mit.edu> wrote:
=20 =20 =20

I agree that the client_id is unlikely to be fou= nd inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client= _id.

Additionally, I think we want to allow for a bin= ding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

Should th= is specification then extend the dynamic registration specification (https://tools.ietf.org/html/rfc7591) with the certificate paramete= r to actually do the registration or is that another document?
=C2=A0

I do think that more examples and guidance are w= arranted, though, to help AS developers.

=C2=A0-- Justin


On 11/2/2016 5:03 PM, Brian Campbe= ll wrote:
=20

On Sun, Oct 30, 2016 at 9:27 A= M, Samuel Erdtman <samuel@erdtman.= se> wrote:
I agree it is written so that = the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be mad= e more explicit and that it be good to do so.

=C2=A0
When it comes to the client_id= I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
=C2=A0

In my experience and the way we built = support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly co= mmon.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

=C2=A0
I=C2=B4m not saying it is a ba= d Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate is= n't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



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


--001a11c3ba62eb9b6a05410c3cdd-- From nobody Fri Nov 11 13:54:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697EB12954A for ; Fri, 11 Nov 2016 13:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI5rV4evAFEW for ; Fri, 11 Nov 2016 13:54:46 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE81129498 for ; Fri, 11 Nov 2016 13:54:46 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id u205so3527232itc.0 for ; Fri, 11 Nov 2016 13:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qPrFfWUFpb0e1lX7d6RwhdfA3ybOyNGJxnUrc/ahwvc=; b=MwBcDnIsZkidvIj0t5tyRAQEN273GxJNVUziMNsotsxRzDAXAhoatP7arxb5HgT/7K Skn0yOEYWAPIQtA4dCMgi7Df/RSv20gmgkH3gpm+VofPdq1ehLsqDXXgIULWOjJSaWco QwU2wsCfaPSK6j1jaEx83BsQXX8BmtI7Hi/IA= 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; bh=qPrFfWUFpb0e1lX7d6RwhdfA3ybOyNGJxnUrc/ahwvc=; b=TYOGjjxJQRx0gvnNQSLWZ5ARPs2fb4es4KCMI6rifyncHEmjDEWNWRklc5EEGceK75 ahhVjbahWhHXVTkkGeq5WzN/cN85Gv//xpUVWKmkB55pSv/mF0BYAqDG0ed6TRSRmCDk 1RqAaDNWSiABmC6Mxb/Auzb4+tXQzPCz9Alm6h+7PQPVVEuCV9Wt25W6fO027HNi7xcp uh7xFistQtXyOHk8MjYInIVPL65kAsJaggBDOD7qaqcS9okZO6xLJ/nq4JBH02qt4km2 oF9jdEZeTusIV/LmoL2Ml+fOGABLt/35jhv8FNn5+wwjbTwJRMaC7/ND+WlkU3+OU700 /b9g== X-Gm-Message-State: ABUngvekyj0+fL9didflenbdLOb4S/57OyKOafbbP4lCsrp1s6KFMzoDx6o2fuxJwsF9TYtsRHr8sv/oCB7OU0+M X-Received: by 10.107.13.137 with SMTP id 131mr14062736ion.122.1478901285487; Fri, 11 Nov 2016 13:54:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Fri, 11 Nov 2016 13:54:14 -0800 (PST) In-Reply-To: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> From: Brian Campbell Date: Fri, 11 Nov 2016 14:54:14 -0700 Message-ID: To: Samuel Erdtman Content-Type: multipart/alternative; boundary=001a113fdfd4c7d96f05410d8944 Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 21:54:48 -0000 --001a113fdfd4c7d96f05410d8944 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >From my point of view, the cleaner solution is using existing fields for what they are well suited rather than inventing new ones. On Fri, Nov 11, 2016 at 1:21 PM, Samuel Erdtman wrote: > You are right one could absolutely use the jwks or jwks_uri attribute, bu= t > from my point of view that would be a workaround. > I would prefer that x5u, x5c and/or x5t was directly available in the > client registration request not via jwks. This would be a cleaner solutio= n. > > Best Regards > Samuel > > On Fri, 11 Nov 2016 at 19:13, Brian Campbell > wrote: > >> Wouldn't the existing jwks/jwks_uri client metadata parameters suffice? >> Perhaps some guidance in this document about that is warranted. But I do= n't >> believe anything new is needed for that case. >> >> On Nov 11, 2016 9:41 AM, "Samuel Erdtman" wrote: >> >> Just a quick comment, see inline >> >> On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer wrote: >> >> I agree that the client_id is unlikely to be found inside the certificat= e >> itself. The client_id is issued by the authorization server for the clie= nt >> to use at that single AS. The certificate is issued by the CA for the >> client to use on any connection. The AS and CA are not likely to be the >> same system in most deployments. The client will use the same cert acros= s >> multiple connections, possibly multiple AS's, but the same isn't true of >> the client_id. >> >> Additionally, I think we want to allow for a binding of a self-signed >> certificate using dynamic registration, much the way that we already all= ow >> binding of a client-generated JWK today. >> >> Should this specification then extend the dynamic registration >> specification (https://tools.ietf.org/html/rfc7591) with the certificate >> parameter to actually do the registration or is that another document? >> >> >> I do think that more examples and guidance are warranted, though, to hel= p >> AS developers. >> >> -- Justin >> >> On 11/2/2016 5:03 PM, Brian Campbell wrote: >> >> >> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman >> wrote: >> >> >> I agree it is written so that the connection to the certificate is >> implicitly required but I think it would be better if it was explicit >> written since the lack of a connection would result in a potential secur= ity >> hole. >> >> >> That's fair. I agree it can be made more explicit and that it be good to >> do so. >> >> >> >> When it comes to the client_id I think subject common name or maybe >> subject serial numbers will be the common location, and I think an examp= le >> would be valuable. >> >> >> >> In my experience and the way we built support for mutual TLS OAuth clien= t >> auth the client_id value does not appear in the certificate anywhere. I'= m >> not saying it can't happen but don't think it's particularly common. >> >> I can look at adding some examples, if there's some consensus that they'= d >> be useful and this document moves forward. >> >> >> >> >> I=C2=B4m not saying it is a bad Idea just that I would prefer if it was = not a >> MUST. >> With very limited addition of code it is just as easy to get the >> certificate attribute for client id as it is to get it from the HTTP >> request data (at least in java). I also think that with the requirement = to >> match the incoming certificate in some way one has to read out the >> certificate that was used to establish the connection to do some kind of >> matching. >> >> >> Getting data out of the certificate isn't a concern. I just believe that >> the constancy of having the client id parameter is worth the potential >> small amount duplicate data in some cases. It's just a -00 draft though = and >> if the WG wants to proceed with this document, we seek further input and >> work towards some consensus. >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> >> --001a113fdfd4c7d96f05410d8944 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From my point of view, the cleaner solution is using exist= ing fields for what they are well suited rather than inventing new ones.

On Fri, N= ov 11, 2016 at 1:21 PM, Samuel Erdtman <samuel@erdtman.se> w= rote:
You are right one could absolutely use the jwks or jwks_uri attribute, but= from my point of view that would be a workaround.
I would prefer that x= 5u, x5c and/or x5t was directly available in the client registration reques= t not via jwks. This would be a cleaner solution.

Best Regards
Samuel

=
On Fri, 11 Nov= 2016 at 19:13, Brian Campbell <bcampbell@pingidentity.com> wrote:
=

Wouldn't the existing jwks/jw= ks_uri client metadata parameters suffice? Perhaps some guidance in this do= cument about that is warranted. But I don't believe anything new is nee= ded for that case.


On Nov 11, 2016 9:41 AM, "Samuel Erdtman" <samuel@erdtman.se> wrote:
Just a quick comment, see inline

On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <jr= icher@mit.edu> wrote:
=20 =20 =20

I agree that the client_id = is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client= _id.

Additionally, I think we wa= nt to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

Should this specification then extend the = dynamic registration specification (https:/= /tools.ietf.org/html/rfc7591) with the certificate parameter to ac= tually do the registration or is that another document?
=C2=A0

I do think that more exampl= es and guidance are warranted, though, to help AS developers.

=C2=A0-- Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:
=20

On Sun, O= ct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

=
<= span class=3D"m_4055722970116019915m_-7085697107402748528m_3505641874876562= 717gmail-m_-1237624956419455067gmail- m_4055722970116019915gmail_msg">
I agree i= t is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. = I agree it can be made more explicit and that it be good to do so.

=C2=A0
When it c= omes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
=C2=A0

In my experience = and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly co= mmon.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

=C2=A0
I=C2=B4m = not saying it is a bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out = of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



______________________________________=
_________
OAuth mailing list
OAuth@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/oauth



--001a113fdfd4c7d96f05410d8944-- From nobody Fri Nov 11 14:18:20 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2671295EE for ; Fri, 11 Nov 2016 14:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asXYFwqHfHMO for ; Fri, 11 Nov 2016 14:18:18 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 290021293DB for ; Fri, 11 Nov 2016 14:18:18 -0800 (PST) Received: (qmail 8329 invoked by uid 0); 11 Nov 2016 22:18:13 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 11 Nov 2016 22:18:13 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id 6mJ71u00n2UhLwi01mJAfV; Fri, 11 Nov 2016 15:18:11 -0700 X-Authority-Analysis: v=2.1 cv=PIacp5aC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=L24OOQBejmoA:10 a=48vgC7mUAAAA:8 a=1YrUzTAg4sB3_6XAbO0A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 Received: from [162.119.128.105] (port=51755 helo=[192.168.150.230]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1c5K9B-0004hv-CT for oauth@ietf.org; Fri, 11 Nov 2016 15:18:09 -0700 To: IETF OAuth WG From: =JeffH Message-ID: <7eb1fc97-ecec-d533-c352-2e4859850225@KingsMountain.com> Date: Fri, 11 Nov 2016 14:18:09 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 162.119.128.105 X-Exim-ID: 1c5K9B-0004hv-CT X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.150.230]) [162.119.128.105]:51755 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 22:18:19 -0000 > here is a first draft of the agenda for the upcoming meeting: > https://datatracker.ietf.org/doc/agenda-97-oauth/ > > Feedback welcome in the above agenda is this.. > - OAuth 2.0 Token Exchange (Brian) > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > The token binding work has been around for a while. Is it ready for > WGLC? do you mean to say "the token exchange work has been around for awhile"? HTH, =JeffH From nobody Fri Nov 11 15:08:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690FB1295A7 for ; Fri, 11 Nov 2016 15:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzYZP3S0Ans9 for ; Fri, 11 Nov 2016 15:08:52 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C970612943D for ; Fri, 11 Nov 2016 15:08:52 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uABN8pIN017351 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Nov 2016 23:08:51 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id uABN8opS001659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Nov 2016 23:08:51 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uABN8o2W028154; Fri, 11 Nov 2016 23:08:50 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Nov 2016 15:08:50 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_5E8DFED4-BCF6-4309-819A-AB3EB6DA3F1A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: <7eb1fc97-ecec-d533-c352-2e4859850225@KingsMountain.com> Date: Fri, 11 Nov 2016 15:08:48 -0800 Message-Id: <3075D65D-820A-451E-9D4D-08BE59973814@oracle.com> References: <7eb1fc97-ecec-d533-c352-2e4859850225@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: IETF OAuth WG Subject: Re: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 23:08:54 -0000 --Apple-Mail=_5E8DFED4-BCF6-4309-819A-AB3EB6DA3F1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yup. This concept has been laying around since 2011=E2=80=A6 https://tools.ietf.org/html/draft-hunt-oauth-chain-00 Plus Mike Jone=E2=80=99s and Brian Campbell=E2=80=99s and Justin = Richer=E2=80=99s. Let=E2=80=99s get this draft through WGLC. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Nov 11, 2016, at 2:18 PM, =3DJeffH = wrote: >=20 >=20 > > here is a first draft of the agenda for the upcoming meeting: > > https://datatracker.ietf.org/doc/agenda-97-oauth/ > > > > Feedback welcome >=20 > in the above agenda is this.. >=20 > > - OAuth 2.0 Token Exchange (Brian) > > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > The token binding work has been around for a while. Is it ready for > > WGLC? >=20 > do you mean to say "the token exchange work has been around for = awhile"? >=20 > HTH, >=20 > =3DJeffH >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5E8DFED4-BCF6-4309-819A-AB3EB6DA3F1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yup. This concept has been laying around since 2011=E2=80=A6https://tools.ietf.org/html/draft-hunt-oauth-chain-00=

Plus Mike Jone=E2=80=99= s and Brian Campbell=E2=80=99s and Justin Richer=E2=80=99s.

Let=E2=80=99s get this = draft through WGLC.




On Nov 11, 2016, at 2:18 PM, =3DJeffH <Jeff.Hodges@KingsMountain.com> wrote:


> here is a first draft of the agenda for the upcoming = meeting:
> https://datatracker.ietf.org/doc/agenda-97-oauth/
>
> Feedback welcome

in the above agenda is this..

>= - OAuth 2.0 Token Exchange (Brian)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchang= e/
>
> The token binding work has = been around for a while. Is it ready for
> WGLC?

do you mean to say "the token exchange work = has been around for awhile"?

HTH,

=3DJeffH

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

= --Apple-Mail=_5E8DFED4-BCF6-4309-819A-AB3EB6DA3F1A-- From nobody Sat Nov 12 19:31:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F861294F0 for ; Sat, 12 Nov 2016 19:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2uKccUqznes for ; Sat, 12 Nov 2016 19:31:30 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.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 EA2D91293EC for ; Sat, 12 Nov 2016 19:31:29 -0800 (PST) Received: from [58.120.104.2] (helo=[192.168.101.185]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5lVu-0001qW-5b; Sun, 13 Nov 2016 04:31:26 +0100 To: John Bradley , OAuth WG , Brian Campbell References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> From: Torsten Lodderstedt Message-ID: <5827DE8A.4010807@lodderstedt.net> Date: Sun, 13 Nov 2016 12:31:22 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------000200070909010906040504" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: Nat Sakimura via Openid-specs-fapi Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 03:31:33 -0000 This is a multi-part message in MIME format. --------------000200070909010906040504 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi John and Brian, thanks for writting this draft. One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft? best regards, Torsten. Am 11.10.2016 um 05:59 schrieb John Bradley: > At the request of the OpenID Foundation Financial Services API Working > group, Brian Campbell and I have documented > mutual TLS client authentication. This is something that lots of > people do in practice though we have never had a spec for it. > > The Banks want to use it for some server to server API use cases being > driven by new open banking regulation. > > The largest thing in the draft is the IANA registration of > tls_client_auth Token Endpoint authentication method for use in > Registration and discovery. > > The trust model is intentionally left open so that you could use a > common name and a restricted list of CA or a direct lookup of the > subject public key against a reregistered value, or something in between. > > I hope that this is non controversial and the WG can adopt it quickly. > > Regards > John B. > > > > >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **New Version Notification for >> draft-campbell-oauth-tls-client-auth-00.txt* >> *Date: *October 10, 2016 at 5:44:39 PM GMT-3 >> *To: *"Brian Campbell" > >, "John Bradley" >> > >> >> >> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >> has been successfully submitted by John Bradley and posted to the >> IETF repository. >> >> Name:draft-campbell-oauth-tls-client-auth >> Revision:00 >> Title:Mutual X.509 Transport Layer Security (TLS) Authentication for >> OAuth Clients >> Document date:2016-10-10 >> Group:Individual Submission >> Pages:5 >> URL: >> https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ >> Htmlized: >> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 >> >> >> Abstract: >> This document describes X.509 certificates as OAuth client >> credentials using Transport Layer Security (TLS) mutual >> authentication as a mechanism for client authentication to the >> authorization server's token endpoint. >> >> >> >> >> 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 >> . >> >> The IETF Secretariat >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000200070909010906040504 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented
mutual TLS client authentication. This is something that lots of people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of tls_client_auth Token Endpoint authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a common name and a restricted list of CA or a direct lookup of the subject public key against a reregistered value, or something in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.




Begin forwarded message:

Subject: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
Date: October 10, 2016 at 5:44:39 PM GMT-3
To: "Brian Campbell" <brian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: draft-campbell-oauth-tls-client-auth
Revision: 00
Title: Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 2016-10-10
Group: Individual Submission
Pages: 5
URL: https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00


Abstract:
This document describes X.509 certificates as OAuth client
credentials using Transport Layer Security (TLS) mutual
authentication as a mechanism for client authentication to the
authorization server's token endpoint.




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.

The IETF Secretariat




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

--------------000200070909010906040504-- From nobody Sat Nov 12 20:40:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0212B12950D for ; Sat, 12 Nov 2016 20:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ui1WKGBbnLf for ; Sat, 12 Nov 2016 20:40:05 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 C86E81294FA for ; Sat, 12 Nov 2016 20:40:04 -0800 (PST) X-AuditID: 1209190d-ca3ff70000000ceb-28-5827eea35a58 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 5A.96.03307.3AEE7285; Sat, 12 Nov 2016 23:40:03 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id uAD4e27Q009968; Sat, 12 Nov 2016 23:40:02 -0500 Received: from dhcp-8693.meeting.ietf.org (dhcp-8693.meeting.ietf.org [31.133.134.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAD4dtfS020255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 12 Nov 2016 23:39:59 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_7CE3C1D0-6016-44D8-B4C3-E8292BD9811F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <5827DE8A.4010807@lodderstedt.net> Date: Sun, 13 Nov 2016 13:39:55 +0900 Message-Id: <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> To: Torsten Lodderstadt X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsUixG6norv4nXqEwdnjuhar/99ktDj59hWb xedbh1ktXh17ymKx+u5fNgdWjyVLfjJ5PN/Zz+RxrKef1ePu0YssHrdvb2QJYI3isklJzcks Sy3St0vgylgzaydrwbWyivlf5RoYl8Z1MXJySAiYSPyauZepi5GLQ0igjUli56w+RghnI6PE ncNP2CGcK0wStw5tYQZpYRZIkDj67SE7iM0roCexaf1bJhBbGCh+5lU7mM0moCoxfU0LmM0p oC/x+nA/WD0LUHzPsbdg65gFLjJKXH/TwgIxyEpi4YcnrBDbFjFKPPmynq2LkYNDRMBQ4tec TIhbZSWenFzEMoGRfxaSO2YhuQMiri2xbOFrZgjbQOJp5ytWTHF9iTfv5jAtYGRbxSibklul m5uYmVOcmqxbnJyYl5dapGukl5tZopeaUrqJERQXnJK8Oxj/3fU6xCjAwajEw7shTT1CiDWx rLgy9xCjJAeTkijvOxWgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFe8ZdAOd6UxMqq1KJ8mJQ0 B4uSOO9/t6/hQgLpiSWp2ampBalFMFkZDg4lCV7Zt0CNgkWp6akVaZk5JQhpJg5OkOE8QMOV QWp4iwsSc4sz0yHypxh1Od7sevmASYglLz8vVUqc1/ANUJEASFFGaR7cHFA6k29tm/yKURzo LWHeFSCjeICpEG7SK6AlTEBLZsSpgCwpSURISTUw2ogfiGz9IBB50MHqqPatPfvCdj0WuG71 rfqu3+uvHDt+16yccT9RUdxEzJBNUmT2xKzLSvxMXdX3DHKsWy5c9lBUmvY9eXf+vw0bHgZe fMN15m3v5S7ZbZr13aGTFKfP2/FS84lxgX1Y1JQFN3sWPefa3FfpU6HCalW930iUmZ/XmYuh LFZNiaU4I9FQi7moOBEAlZKHgUIDAAA= Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 04:40:07 -0000 --Apple-Mail=_7CE3C1D0-6016-44D8-B4C3-E8292BD9811F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Torsten, I believe this is intended to be triggered by the = tls_client_auth value specified in =A73.=20 Nit on that section, the field name for the client metadata in RFC7591 = is token_endpoint_auth_method, the _supported version is from the = corresponding discovery document. =97 Justin > On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt = wrote: >=20 > Hi John and Brian, >=20 > thanks for writting this draft. >=20 > One question: how does the AS determine the authentication method is = TLS authentication? I think you assume this is defined by the = client-specific policy, independent of whether the client is registered = automatically or manually. Would you mind to explicitely state this in = the draft? >=20 > best regards, > Torsten. >=20 > Am 11.10.2016 um 05:59 schrieb John Bradley: >> At the request of the OpenID Foundation Financial Services API = Working group, Brian Campbell and I have documented=20 >> mutual TLS client authentication. This is something that lots of = people do in practice though we have never had a spec for it. >>=20 >> The Banks want to use it for some server to server API use cases = being driven by new open banking regulation. >>=20 >> The largest thing in the draft is the IANA registration of = =93tls_client_auth=94 Token Endpoint authentication method for use in = Registration and discovery. >>=20 >> The trust model is intentionally left open so that you could use a = =93common name=94 and a restricted list of CA or a direct lookup of the = subject public key against a reregistered value, or something in = between. >>=20 >> I hope that this is non controversial and the WG can adopt it = quickly. >>=20 >> Regards >> John B. >>=20 >>=20 >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org = >>> Subject: New Version Notification for = draft-campbell-oauth-tls-client-auth-00.txt >>> Date: October 10, 2016 at 5:44:39 PM GMT-3 >>> To: "Brian Campbell" < = brian.d.campbell@gmail.com = >, "John Bradley" > >>>=20 >>>=20 >>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >>> has been successfully submitted by John Bradley and posted to the >>> IETF repository. >>>=20 >>> Name: draft-campbell-oauth-tls-client-auth >>> Revision: 00 >>> Title: Mutual X.509 Transport Layer Security (TLS) = Authentication for OAuth Clients >>> Document date: 2016-10-10 >>> Group: Individual Submission >>> Pages: 5 >>> URL: = https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-= 00.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ = >>> Htmlized: = https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 = >>>=20 >>>=20 >>> Abstract: >>> This document describes X.509 certificates as OAuth client >>> credentials using Transport Layer Security (TLS) mutual >>> authentication as a mechanism for client authentication to the >>> authorization server's token endpoint. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=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=_7CE3C1D0-6016-44D8-B4C3-E8292BD9811F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Torsten, I believe this is intended to be triggered by the = tls_client_auth value specified in =A73. 

Nit on that section, the field name for = the client metadata in RFC7591 is token_endpoint_auth_method, the = _supported version is from the corresponding discovery = document.

 =97 Justin

On = Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20
Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
=20 At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented 
mutual TLS client authentication.   This is something that lots of people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of =93tls_client_auth=94 Token Endpoint = authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a =93common name=94 and a restricted list of CA or = a direct lookup of the subject public key against a reregistered value,  or something in between.

I hope that this is non controversial and the WG = can adopt it quickly.

Regards
John B.




Begin forwarded message:

From: internet-drafts@ietf.org
Subject: New = Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
Date: October 10, 2016 at 5:44:39 PM GMT-3
To: "Brian Campbell" = <brian.d.campbell@gmail.com&= gt;, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
= has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: = draft-campbell-oauth-tls-client-auth
Revision: 00
Title: Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 2016-10-10
Group: Individual Submission
Pages: 5
URL: =            https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-c= lient-auth-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-clien= t-auth/
Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-tls-client-aut= h-00


Abstract:
  This document describes X.509 certificates = as OAuth client
  credentials using Transport Layer Security = (TLS) mutual
  authentication as a mechanism for client authentication to the
  authorization server's token endpoint.




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.

The IETF Secretariat




_______________________________________________
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=_7CE3C1D0-6016-44D8-B4C3-E8292BD9811F-- From nobody Sat Nov 12 21:21:26 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28D512969B for ; Sat, 12 Nov 2016 21:21:24 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS1TAehpwRtI for ; Sat, 12 Nov 2016 21:21:22 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A9112951A for ; Sat, 12 Nov 2016 21:21:21 -0800 (PST) Received: from [58.120.104.2] (helo=[192.168.101.185]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5nED-00067o-84; Sun, 13 Nov 2016 06:21:17 +0100 To: Justin Richer References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> From: Torsten Lodderstedt Message-ID: <5827F848.3060803@lodderstedt.net> Date: Sun, 13 Nov 2016 14:21:12 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> Content-Type: multipart/alternative; boundary="------------040804070709030708070902" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:21:25 -0000 This is a multi-part message in MIME format. --------------040804070709030708070902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Justin, Am 13.11.2016 um 13:39 schrieb Justin Richer: > Torsten, I believe this is intended to be triggered by the > tls_client_auth value specified in 3. in the token request? > > Nit on that section, the field name for the client metadata in RFC7591 > is token_endpoint_auth_method, the _supported version is from the > corresponding discovery document. > > Justin > Torsten. >> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt >> > wrote: >> >> Hi John and Brian, >> >> thanks for writting this draft. >> >> One question: how does the AS determine the authentication method is >> TLS authentication? I think you assume this is defined by the >> client-specific policy, independent of whether the client is >> registered automatically or manually. Would you mind to explicitely >> state this in the draft? >> >> best regards, >> Torsten. >> >> Am 11.10.2016 um 05:59 schrieb John Bradley: >>> At the request of the OpenID Foundation Financial Services API >>> Working group, Brian Campbell and I have documented >>> mutual TLS client authentication. This is something that lots of >>> people do in practice though we have never had a spec for it. >>> >>> The Banks want to use it for some server to server API use cases >>> being driven by new open banking regulation. >>> >>> The largest thing in the draft is the IANA registration of >>> tls_client_auth Token Endpoint authentication method for use in >>> Registration and discovery. >>> >>> The trust model is intentionally left open so that you could use a >>> common name and a restricted list of CA or a direct lookup of the >>> subject public key against a reregistered value, or something in >>> between. >>> >>> I hope that this is non controversial and the WG can adopt it quickly. >>> >>> Regards >>> John B. >>> >>> >>> >>> >>>> Begin forwarded message: >>>> >>>> *From: *internet-drafts@ietf.org >>>> *Subject: **New Version Notification for >>>> draft-campbell-oauth-tls-client-auth-00.txt* >>>> *Date: *October 10, 2016 at 5:44:39 PM GMT-3 >>>> *To: *"Brian Campbell" , "John Bradley" >>>> > >>>> >>>> >>>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >>>> has been successfully submitted by John Bradley and posted to the >>>> IETF repository. >>>> >>>> Name:draft-campbell-oauth-tls-client-auth >>>> Revision:00 >>>> Title:Mutual X.509 Transport Layer Security (TLS) Authentication >>>> for OAuth Clients >>>> Document date:2016-10-10 >>>> Group:Individual Submission >>>> Pages:5 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 >>>> >>>> >>>> Abstract: >>>> This document describes X.509 certificates as OAuth client >>>> credentials using Transport Layer Security (TLS) mutual >>>> authentication as a mechanism for client authentication to the >>>> authorization server's token endpoint. >>>> >>>> >>>> >>>> >>>> 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 >>>> . >>>> >>>> The IETF Secretariat >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 > --------------040804070709030708070902 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Justin,

Am 13.11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe this is intended to be triggered by the tls_client_auth value specified in 3.

in the token request?


Nit on that section, the field name for the client metadata in RFC7591 is token_endpoint_auth_method, the _supported version is from the corresponding discovery document.

Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented
mutual TLS client authentication. This is something that lots of people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of tls_client_auth Token Endpoint authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a common name and a restricted list of CA or a direct lookup of the subject public key against a reregistered value, or something in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.




Begin forwarded message:

Subject: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
Date: October 10, 2016 at 5:44:39 PM GMT-3
To: "Brian Campbell" <brian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: draft-campbell-oauth-tls-client-auth
Revision: 00
Title: Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 2016-10-10
Group: Individual Submission
Pages: 5
URL: https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00


Abstract:
This document describes X.509 certificates as OAuth client
credentials using Transport Layer Security (TLS) mutual
authentication as a mechanism for client authentication to the
authorization server's token endpoint.




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.

The IETF Secretariat




_______________________________________________
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


--------------040804070709030708070902-- From nobody Sat Nov 12 21:24:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B110212949B for ; Sat, 12 Nov 2016 21:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdTEp-kDNyON for ; Sat, 12 Nov 2016 21:24:38 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 71234129459 for ; Sat, 12 Nov 2016 21:24:38 -0800 (PST) X-AuditID: 1209190c-e73ff700000003f7-df-5827f91563aa Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E8.90.01015.519F7285; Sun, 13 Nov 2016 00:24:37 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id uAD5Oaij023060; Sun, 13 Nov 2016 00:24:36 -0500 Received: from dhcp-8693.meeting.ietf.org (dhcp-8693.meeting.ietf.org [31.133.134.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAD5OTID026833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Nov 2016 00:24:33 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_34D41132-2D7E-4DB0-9022-23C13F977550" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <5827F848.3060803@lodderstedt.net> Date: Sun, 13 Nov 2016 14:24:29 +0900 Message-Id: <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> To: Torsten Lodderstadt X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsUixG6nriv6Uz3CYMoxcYvV/28yWpx8+4rN 4vOtw6wWr449ZbFYffcvmwOrx5IlP5k8nu/sZ/I41tPP6nH36EUWj9u3N7IEsEZx2aSk5mSW pRbp2yVwZZyavJStYOU8xopN8/awNTBezu9i5OSQEDCRmNvxiLGLkYtDSKCNSeJZ50EmCGcj o8SW+zdYIZwrTBJ32x4wg7QwCyRI7Lm6nBXE5hXQk9i0/i0TiC0MFD/zqh3MZhNQlZi+pgXM 5hTQl5jx7wY7iM0CEj98jQ1kKLPARUaJ629aWCAGWUl8P/CfGWLbF0aJM3v7gI7i4BARMJT4 NScT4lZZiScnF7FMYOSfheSOWUjugIhrSyxb+JoZwjaQeNr5ihVTXF/izbs5TAsY2VYxyqbk VunmJmbmFKcm6xYnJ+blpRbpGurlZpbopaaUbmIExQanJM8OxjNvvA4xCnAwKvHwcmSqRwix JpYVV+YeYpTkYFIS5X2nAhTiS8pPqcxILM6ILyrNSS0+xCjBwawkwuv2HSjHm5JYWZValA+T kuZgURLn/e/2NVxIID2xJDU7NbUgtQgmK8PBoSTB+xykUbAoNT21Ii0zpwQhzcTBCTKcB2h4 Ndjw4oLE3OLMdIj8KUZdjje7Xj5gEmLJy89LlRLn3fAOqEgApCijNA9uDiilybe2TX7FKA70 ljAv8w+gKh5gOoSb9ApoCRPQkhlxKiBLShIRUlINjCfOHRdu9Cz/8PWz2Eu5WZIy3kfaeDe8 rY/TnJB5tu602tqsgMvnnWwDpZbvv8w6dXbDG5n/xbdeKQWYJt+xFhL0tPzJ1PP76keDhMR3 xW9FfpR/YefJ+qfXuVhQ5IXs/FqNstrgMzIPZyTMylNk2KzzqLShY5J/50XT8/9MVLM/3V55 1W7dYyWW4oxEQy3mouJEANmsoSZEAwAA Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:24:41 -0000 --Apple-Mail=_34D41132-2D7E-4DB0-9022-23C13F977550 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 As part of the client=92s registered data model. At least, based on how = our own implementation works (where we support client_secret_basic, = private_key_jwt, etc), that=92s where we=92d check to see if the client = was supposed to be using TLS auth or not. We don=92t let clients switch away from their registered auth mechanism. =97 Justin > On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt = wrote: >=20 > Justin, >=20 > Am 13.11.2016 um 13:39 schrieb Justin Richer: >> Torsten, I believe this is intended to be triggered by the = tls_client_auth value specified in =A73.=20 >=20 > in the token request? >=20 >>=20 >> Nit on that section, the field name for the client metadata in = RFC7591 is token_endpoint_auth_method, the _supported version is from = the corresponding discovery document. >>=20 >> =97 Justin >>=20 > Torsten. >>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt = > wrote: >>>=20 >>> Hi John and Brian, >>>=20 >>> thanks for writting this draft. >>>=20 >>> One question: how does the AS determine the authentication method is = TLS authentication? I think you assume this is defined by the = client-specific policy, independent of whether the client is registered = automatically or manually. Would you mind to explicitely state this in = the draft? >>>=20 >>> best regards, >>> Torsten. >>>=20 >>> Am 11.10.2016 um 05:59 schrieb John Bradley: >>>> At the request of the OpenID Foundation Financial Services API = Working group, Brian Campbell and I have documented=20 >>>> mutual TLS client authentication. This is something that lots of = people do in practice though we have never had a spec for it. >>>>=20 >>>> The Banks want to use it for some server to server API use cases = being driven by new open banking regulation. >>>>=20 >>>> The largest thing in the draft is the IANA registration of = =93tls_client_auth=94 Token Endpoint authentication method for use in = Registration and discovery. >>>>=20 >>>> The trust model is intentionally left open so that you could use a = =93common name=94 and a restricted list of CA or a direct lookup of the = subject public key against a reregistered value, or something in = between. >>>>=20 >>>> I hope that this is non controversial and the WG can adopt it = quickly. >>>>=20 >>>> Regards >>>> John B. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: internet-drafts@ietf.org = >>>>> Subject: New Version Notification for = draft-campbell-oauth-tls-client-auth-00.txt >>>>> Date: October 10, 2016 at 5:44:39 PM GMT-3 >>>>> To: "Brian Campbell" >, "John Bradley" > >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >>>>> has been successfully submitted by John Bradley and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-campbell-oauth-tls-client-auth >>>>> Revision: 00 >>>>> Title: Mutual X.509 Transport Layer Security (TLS) = Authentication for OAuth Clients >>>>> Document date: 2016-10-10 >>>>> Group: Individual Submission >>>>> Pages: 5 >>>>> URL: = https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-= 00.txt = >>>>> Status: = https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ = >>>>> Htmlized: = https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 = >>>>>=20 >>>>>=20 >>>>> Abstract: >>>>> This document describes X.509 certificates as OAuth client >>>>> credentials using Transport Layer Security (TLS) mutual >>>>> authentication as a mechanism for client authentication to the >>>>> authorization server's token endpoint. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org . >>>>>=20 >>>>> The IETF Secretariat >>>>>=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 = >>=20 >=20 --Apple-Mail=_34D41132-2D7E-4DB0-9022-23C13F977550 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 As part of the client=92s registered data model. At least, = based on how our own implementation works (where we support = client_secret_basic, private_key_jwt, etc), that=92s where we=92d check = to see if the client was supposed to be using TLS auth or not.

We don=92t let clients = switch away from their registered auth mechanism.
 =97 Justin

On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20
Justin,

Am 13.11.2016 um 13:39 schrieb Justin Richer:
=20 Torsten, I believe this is intended to be triggered by the tls_client_auth value specified in =A73.

in the token request?


Nit on that section, the field name for the client metadata in RFC7591 is token_endpoint_auth_method, the _supported version is from the corresponding discovery = document.

 =97 Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20
Hi = John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented 
mutual TLS client authentication. =   This is something that lots of people do in practice though we have never had a spec for it.

The Banks want to use it for some = server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of =93tls_client_auth=94 Token Endpoint authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a =93common name=94 and a restricted list of CA or a direct lookup of the subject public key against a reregistered value, =  or something in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.




Begin forwarded message:

Subject: New Version Notification for = draft-campbell-oauth-tls-client-auth-00.txt
Date: October = 10, 2016 at 5:44:39 PM GMT-3
To: "Brian Campbell" <brian.d.campbell@gmail.com&= gt;, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, = draft-campbell-oauth-tls-client-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: = draft-campbell-oauth-tls-client-auth
Revision: 00
Title: Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 2016-10-10
Group: Individual Submission
Pages: 5
URL: =            https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-c= lient-auth-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-clien= t-auth/
Htmlized: =       https://tools.ietf.org/html/draft-campbell-oauth-tls-client-aut= h-00


Abstract:
  This document describes X.509 = certificates as OAuth client
  credentials using Transport = Layer Security (TLS) mutual
  authentication as a mechanism = for client authentication to the
  authorization server's token = endpoint.




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.

The IETF Secretariat




_______________________________________________
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=_34D41132-2D7E-4DB0-9022-23C13F977550-- From nobody Sat Nov 12 21:32:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1221295A8 for ; Sat, 12 Nov 2016 21:32:15 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA-lzNLLLMOO for ; Sat, 12 Nov 2016 21:32:14 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (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 9CE511294C0 for ; Sat, 12 Nov 2016 21:32:13 -0800 (PST) Received: from [58.120.104.2] (helo=[192.168.101.185]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5nOk-00015C-S9; Sun, 13 Nov 2016 06:32:11 +0100 To: Mike Jones , "oauth@ietf.org" References: From: Torsten Lodderstedt Message-ID: <5827FAD7.1090105@lodderstedt.net> Date: Sun, 13 Nov 2016 14:32:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090001020106010803060204" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:32:16 -0000 This is a multi-part message in MIME format. --------------090001020106010803060204 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Mike, just read your spec and I'm also a bit confused about the "resource" meta data element in section 2. I would assume the metadata are provided for a certain resource server managing a set of resources in a particular administrative domain. So I would prefer to name the respective element "resource_server". In the example George gave the URL would be "https://idp.example.com/tenant//". Resource managed by a particular resource server could use sub-paths of the respective URL, such as " https://idp.example.com/tenant//users/". best regards, Torsten. Am 05.08.2016 um 02:10 schrieb George Fletcher: > Mike, thanks for drafting and publishing these specifications. I have > a couple of questions regarding the > draft-jones-oauth-resource-metadata-00. > > 1. Is a "protected resource" a server? or an actual API endpoint. The > non-normative examples use /.well-known/oauth-protected-resource and > /resource1/.well-known/oauth-protected-resource which is a little > unclear. I think of "resource" as something like "Mail" or "Instant > Messaging". > > 2. Assuming that "protected resource" means an actual API endpoint, > what is the expected location of the metadata for a fully REST > compliant API where the full URL points to a specific resource and not > the concept of a general API. > > Using an example of an IdP that supports user management > capabilities. Let's assume the IdP supports a REST API of... > > CREATE -- POST https://idp.example.com/tenant//users > READ -- GET > https://idp.example.com/tenant//users/ > UPDATE -- > PUThttps://idp.example.com/tenant//users/ > DELETE -- > DELETEhttps://idp.example.com/tenant//users/ > > Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots > of users. Where does the .well-known/oauth-protected-resource get > added? > > ?? > https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource > > In this case would not the oauth-protected-resource metadata be > duplicated across the set of tenants and users? Is that the > desired behavior? > > Thanks, > George > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090001020106010803060204 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Mike,

just read your spec and I'm also a bit confused about the "resource" meta data element in section 2.

I would assume the metadata are provided for a certain resource server managing a set of resources in a particular administrative domain. So I would prefer to name the respective element "resource_server". In the example George gave the URL would be "https://idp.example.com/tenant/<tenantid>/". Resource managed by a particular resource server could use sub-paths of the respective URL, such as " https://idp.example.com/tenant/<tenantid>/users/<userid>".

best regards,
Torsten.

Am 05.08.2016 um 02:10 schrieb George Fletcher:
Mike, thanks for drafting and publishing these specifications. I have a couple of questions regarding the draft-jones-oauth-resource-metadata-00.

1. Is a "protected resource" a server? or an actual API endpoint. The non-normative examples use /.well-known/oauth-protected-resource and /resource1/.well-known/oauth-protected-resource which is a little unclear. I think of "resource" as something like "Mail" or "Instant Messaging".

2. Assuming that "protected resource" means an actual API endpoint, what is the expected location of the metadata for a fully REST compliant API where the full URL points to a specific resource and not the concept of a general API.
Using an example of an IdP that supports user management capabilities. Let's assume the IdP supports a REST API of...

CREATE -- POST https://idp.example.com/tenant/<tenantid>/users
 READ -- GET https://idp.example.com/tenant/<tenantid>/users/<userid>
UPDATE -- PUT https://idp.example.com/tenant/<tenantid>/users/<userid>
DELETE -- DELETE https://idp.example.com/tenant/<tenantid>/users/<userid>

Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users. Where does the .well-known/oauth-protected-resource get added?

?? https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource

In this case would not the oauth-protected-resource metadata be duplicated across the set of tenants and users? Is that the desired behavior?
Thanks,
George
 

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

--------------090001020106010803060204-- From nobody Sat Nov 12 21:48:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8796212949B for ; Sat, 12 Nov 2016 21:48:29 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-wz3rqn2eXB for ; Sat, 12 Nov 2016 21:48:28 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (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 AD75B1294C6 for ; Sat, 12 Nov 2016 21:48:27 -0800 (PST) Received: from [58.120.104.2] (helo=[192.168.101.185]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5neT-0004Dk-0Z; Sun, 13 Nov 2016 06:48:25 +0100 To: Mike Jones , "oauth@ietf.org" References: From: Torsten Lodderstedt Message-ID: <5827FEA5.5090906@lodderstedt.net> Date: Sun, 13 Nov 2016 14:48:21 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030505060702000908050706" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:48:29 -0000 This is a multi-part message in MIME format. --------------030505060702000908050706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Mike, does this mean the binding ID is indicated to the authorization server via a respective HTTP header? I'm asking because I didn't find the respective parameter in the draft. Could you add a HTTP request example? I think that would help a lot to better understand the mechanism. best regards, Torsten. Am 20.09.2016 um 21:16 schrieb Mike Jones: > > The OAuth Token Binding specification has been revised to use the > Referred Token Binding ID when performing token binding of access > tokens. This was enabled by the Implementation Considerations in the > Token Binding HTTPS specification being added to make it clear that > Token Binding implementations will enable using the Referred Token > Binding ID in this manner. Protected Resource Metadata was also defined. > > Thanks to Brian Campbell for clarifications on the differences between > token binding of access tokens issued from the authorization endpoint > versus those issued from the token endpoint. > > The specification is available at: > > http://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 > > An HTML-formatted version is also available at: > > http://self-issued.info/docs/draft-ietf-oauth-token-binding-01.html > > -- Mike > > P.S. This notice was also posted at http://self-issued.info/?p=1610 > and as @selfissued > . > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030505060702000908050706 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Mike,

does this mean the binding ID is indicated to the authorization server via a respective HTTP header? I'm asking because I didn't find the respective parameter in the draft.

Could you add a HTTP request example? I think that would help a lot to better understand the mechanism.

best regards,
Torsten.

Am 20.09.2016 um 21:16 schrieb Mike Jones:

The OAuth Token Binding specification has been revised to use the Referred Token Binding ID when performing token binding of access tokens. This was enabled by the Implementation Considerations in the Token Binding HTTPS specification being added to make it clear that Token Binding implementations will enable using the Referred Token Binding ID in this manner. Protected Resource Metadata was also defined.

Thanks to Brian Campbell for clarifications on the differences between token binding of access tokens issued from the authorization endpoint versus those issued from the token endpoint.

The specification is available at:

http://tools.ietf.org/html/draft-ietf-oauth-token-binding-01

An HTML-formatted version is also available at:

http://self-issued.info/docs/draft-ietf-oauth-token-binding-01.html

-- Mike

P.S. This notice was also posted at http://self-issued.info/?p=1610 and as @selfissued.



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

--------------030505060702000908050706-- From nobody Sat Nov 12 21:59:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD06129516 for ; Sat, 12 Nov 2016 21:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUoNTwCfaaWQ for ; Sat, 12 Nov 2016 21:59:30 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBB612943A for ; Sat, 12 Nov 2016 21:59:29 -0800 (PST) Received: from [58.120.104.2] (helo=[192.168.101.185]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5np7-00041Y-CO; Sun, 13 Nov 2016 06:59:26 +0100 To: Justin Richer References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> From: Torsten Lodderstedt Message-ID: <58280139.2040505@lodderstedt.net> Date: Sun, 13 Nov 2016 14:59:21 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> Content-Type: multipart/alternative; boundary="------------030609000504090809070103" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:59:32 -0000 This is a multi-part message in MIME format. --------------030609000504090809070103 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I understand. My point is different: the text seems to assume everybody is using client registration, but that's not the case. I would like to point out it makes sense to explicitely state the assumption that it is determined by client policy (indepedent of the way this policy is established). Am 13.11.2016 um 14:24 schrieb Justin Richer: > As part of the clients registered data model. At least, based on how > our own implementation works (where we support client_secret_basic, > private_key_jwt, etc), thats where wed check to see if the client > was supposed to be using TLS auth or not. > > We dont let clients switch away from their registered auth mechanism. > > Justin > >> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt >> > wrote: >> >> Justin, >> >> Am 13.11.2016 um 13:39 schrieb Justin Richer: >>> Torsten, I believe this is intended to be triggered by the >>> tls_client_auth value specified in 3. >> >> in the token request? >> >>> >>> Nit on that section, the field name for the client metadata in >>> RFC7591 is token_endpoint_auth_method, the _supported version is >>> from the corresponding discovery document. >>> >>> Justin >>> >> Torsten. >>>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt >>>> > wrote: >>>> >>>> Hi John and Brian, >>>> >>>> thanks for writting this draft. >>>> >>>> One question: how does the AS determine the authentication method >>>> is TLS authentication? I think you assume this is defined by the >>>> client-specific policy, independent of whether the client is >>>> registered automatically or manually. Would you mind to explicitely >>>> state this in the draft? >>>> >>>> best regards, >>>> Torsten. >>>> >>>> Am 11.10.2016 um 05:59 schrieb John Bradley: >>>>> At the request of the OpenID Foundation Financial Services API >>>>> Working group, Brian Campbell and I have documented >>>>> mutual TLS client authentication. This is something that lots of >>>>> people do in practice though we have never had a spec for it. >>>>> >>>>> The Banks want to use it for some server to server API use cases >>>>> being driven by new open banking regulation. >>>>> >>>>> The largest thing in the draft is the IANA registration of >>>>> tls_client_auth Token Endpoint authentication method for use in >>>>> Registration and discovery. >>>>> >>>>> The trust model is intentionally left open so that you could use a >>>>> common name and a restricted list of CA or a direct lookup of >>>>> the subject public key against a reregistered value, or something >>>>> in between. >>>>> >>>>> I hope that this is non controversial and the WG can adopt it quickly. >>>>> >>>>> Regards >>>>> John B. >>>>> >>>>> >>>>> >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> *From: *internet-drafts@ietf.org >>>>>> *Subject: **New Version Notification for >>>>>> draft-campbell-oauth-tls-client-auth-00.txt* >>>>>> *Date: *October 10, 2016 at 5:44:39 PM GMT-3 >>>>>> *To: *"Brian Campbell" , "John >>>>>> Bradley" > >>>>>> >>>>>> >>>>>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >>>>>> has been successfully submitted by John Bradley and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Name:draft-campbell-oauth-tls-client-auth >>>>>> Revision:00 >>>>>> Title:Mutual X.509 Transport Layer Security (TLS) Authentication >>>>>> for OAuth Clients >>>>>> Document date:2016-10-10 >>>>>> Group:Individual Submission >>>>>> Pages:5 >>>>>> URL: >>>>>> https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This document describes X.509 certificates as OAuth client >>>>>> credentials using Transport Layer Security (TLS) mutual >>>>>> authentication as a mechanism for client authentication to the >>>>>> authorization server's token endpoint. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 . >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> > --------------030609000504090809070103 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I understand. My point is different: the text seems to assume everybody is using client registration, but that's not the case. I would like to point out it makes sense to explicitely state the assumption that it is determined by client policy (indepedent of the way this policy is established).

Am 13.11.2016 um 14:24 schrieb Justin Richer:
As part of the clients registered data model. At least, based on how our own implementation works (where we support client_secret_basic, private_key_jwt, etc), thats where wed check to see if the client was supposed to be using TLS auth or not.

We dont let clients switch away from their registered auth mechanism.

Justin

On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Justin,

Am 13.11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe this is intended to be triggered by the tls_client_auth value specified in 3.

in the token request?


Nit on that section, the field name for the client metadata in RFC7591 is token_endpoint_auth_method, the _supported version is from the corresponding discovery document.

Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented
mutual TLS client authentication. This is something that lots of people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of tls_client_auth Token Endpoint authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a common name and a restricted list of CA or a direct lookup of the subject public key against a reregistered value, or something in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.




Begin forwarded message:

Subject: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
Date: October 10, 2016 at 5:44:39 PM GMT-3
To: "Brian Campbell" <brian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: draft-campbell-oauth-tls-client-auth
Revision: 00
Title: Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 2016-10-10
Group: Individual Submission
Pages: 5
URL: https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00


Abstract:
This document describes X.509 certificates as OAuth client
credentials using Transport Layer Security (TLS) mutual
authentication as a mechanism for client authentication to the
authorization server's token endpoint.




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.

The IETF Secretariat




_______________________________________________
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




--------------030609000504090809070103-- From nobody Sat Nov 12 22:08:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0D129582 for ; Sat, 12 Nov 2016 22:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4McwT89kyDsd for ; Sat, 12 Nov 2016 22:08:36 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) (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 8D199128874 for ; Sat, 12 Nov 2016 22:08:35 -0800 (PST) Received: from [58.120.104.2] (helo=[192.168.101.185]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5nxw-0001cF-Al; Sun, 13 Nov 2016 07:08:33 +0100 To: Nat Sakimura , Denis , oauth@ietf.org References: <58eb4c58-59c2-dac6-2e41-76ec359d4210@free.fr> From: Torsten Lodderstedt Message-ID: <5828035C.801@lodderstedt.net> Date: Sun, 13 Nov 2016 15:08:28 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050808000303080902090908" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 06:08:39 -0000 This is a multi-part message in MIME format. --------------050808000303080902090908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I agree, we should analyse the threat. From my first impression it feels like injection with some specialties. @Denis: So far, I'm struggeling to understand how this attack is performed from a practical perspective. Every token/assertion issued to the uncle is bound to its identity. So it the niece wants to "upgrade" her age, she would need to somehow mix identity data for two identities (her's and her uncle's identity) into a single token, which needs to be signed by the respective AS. How is this gone work? kind regards, Torsten. Am 11.11.2016 um 16:27 schrieb Nat Sakimura: > Thanks Denis for pointing it out. It may be desirable to add ABC > attack to the list of threats. Torsten et al. are updating Threat > Model and Security Considerations so it could potentially be included > in there. > > Some remarks: > > * I suppose the assumption is that the Bob does not share his > credentials with Alice: Otherwise, sharing the credential would > achieve something worse. > * In addition, it assumes that Bob does not give his device to > Alice: Otherwise, something similar to ABC attack can be achieved > by Bob giving Alice his Laptop or Phone, and I guess this happens > more often than shipping Bob's access token to Alice. > * With these assumptions: > o It looks like a variation of token injection attack that we > have been talking about for many years. > o If we token bind the refresh and access tokens, the ABC attack > as described does not work. > o For something like Age verification, recognizing such attacks, > it probably is a bad practice to rely on refresh/access token. > The service should do more active check, e.g., through OpenID > Connect. > > Best, > > Nat > > On Tue, Nov 8, 2016 at 2:54 AM Denis > wrote: > > Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies > requirements. > One of them (which, BTW, should be moved into Section 4 - Threats) > is : > > Collusion: > > Resource servers that collude ... > > This threat addresses the case of "/collusion between servers"/ > while the case of "/collusion between clients"/ > has not been considered. When access tokens are being used, > /collusion between clients /is of primary importance. > > Let us consider the following "Alice and Bob Collusion attack" > (ABC attack). > > An uncle (Bob) is willing to collaborate with his young niece > (Alice) who is less than 18 during a short period of time. > The niece is opening her own session and creates an account on a > server. The uncle does not hand over his own session to her niece > at any point of time. > > Let us assume that some crypto expert has written two specific > pieces of software. One has been installed on the laptop > of the uncle and another one on the laptop of the niece. The two > laptops are able to communicate using a network (e.g. a WAN or a LAN). > > The niece creates an account on a resource server. Later on, the > resource server asks her (or him ?) to demonstrate that she (or > his ?) > is more than 18. She forwards the information received from the > resource server to her uncle using the network. The uncle receives > that information and connects to an Authorization Server. The > uncle requests an access token containing information demonstrating > that he is older than 18 and passed it back to his niece. The > niece then presents it to the resource server. The access token is > accepted. > > Since the niece has been able to demonstrate once that she is more > than 18, the resource server will remember this attribute > and in the future she will not need to demonstrate it again. She > will keep the advantages related to this attribute associated > with her account on that resource server until she does not need > it anymore, i.e. when she will really be over 18. > > Whatever kind of cryptographic is being used, when two users > collaborate, a software-only solution will be > unable to prevent the transfer of an attribute of a user that > possess it to another user that does not possess it . > > The use of a secure element simply protecting the confidentiality > and the integrity of some secret key or private key will be > ineffective > to counter the Alice and Bob collusion attack. Additional > properties will be required for the secure element. > > RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) > issued in January 2013 has omitted to take into consideration > the Alice and Bob Collusion attack. > > Section 2.3 of the ABC4Trust project about key-binding in > Deliverable D2.2 available at: > https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 : > > To prevent “credential pooling”, i.e., multiple Users sharing > their credentials, credentials can optionally be bound to a secret > key, > i.e. a cryptographically strong random value that is assumed to be > known only to a particular user. The credential specification > specifies whether the credentials issued according to this > specification are to employ key binding or not. > > A presentation token derived from such a key-bound credential > always contains an implicit proof of knowledge of the underlying > secret key, > so that the Verifier can be sure that the rightful owner of the > credential was involved in the creation of the presentation token. > As an extra protection layer, the credentials can also be bound to > a trusted physical device, such as a smart card, by keeping > the secret key in a protected area of the device. That is, the key > cannot be extracted from the device, but the device does participate > in the presentation token generation to include an implicit proof > of knowledge of this key in the token. Thus, for credentials that > are key-bound > to a physical device it is impossible to create a presentation > token without the device. > > The rightful owner of the credential was indeed involved in > real-time in the creation of the presentation token but in the > collaboration scenario, > the key binding mechanism is not sufficient to counter that > specific attack. ABC4Trust, Idemix (IBM) and U-Prove > (Microsoft)are currently > not resistant to the "ABC attack". > > The IRMA card project (https://www.irmacard.org/) based on the use > of a smart card and of the Idemix scheme claims to provide security > and privacy simultaneously. However, this project will not be > resistant either to the ABC attack. > > *draft-ietf-oauth-pop-architecture-08 should take into > consideration the ABC attack.* > > The threat related to the ABC attack should be identified in the > security considerations section > and the core of the document should attempt to identify one or > more ways to counter it. > > The scope of draft-ietf-oauth-token-exchange-06 is limited to the > definition of a basic request and response protocol for > an STS-style token exchange utilizing OAuth 2.0. Section 6 > (Security Considerations) has omitted to take into consideration > the ABC attack and therefore the currently described "basic > request and response protocol" will allow Bob to obtain an access > token and to pass it successfully to Alice so that she can use it. > > *draft-ietf-oauth-token-exchange-06 **should take into > consideration the ABC attack.* > > The threat related to the ABC attack should be identified in the > security considerations section > and the core of the document should attempt to identify one or > more ways to counter it. > > Denis > > PS. I have recently registered to the OAuth mailing list. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050808000303080902090908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I agree, we should analyse the threat. From my first impression it feels like injection with some specialties.

@Denis:
So far, I'm struggeling to understand how this attack is performed from a practical perspective. Every token/assertion issued to the uncle is bound to its identity. So it the niece wants to "upgrade" her age, she would need to somehow mix identity data for two identities (her's and her uncle's identity) into a single token, which needs to be signed by the respective AS. How is this gone work?

kind regards,
Torsten.

Am 11.11.2016 um 16:27 schrieb Nat Sakimura:
Thanks Denis for pointing it out. It may be desirable to add ABC attack to the list of threats. Torsten et al. are updating Threat Model and Security Considerations so it could potentially be included in there. 

Some remarks: 
  • I suppose the assumption is that the Bob does not share his credentials with Alice: Otherwise, sharing the credential would achieve something worse. 
  • In addition, it assumes that Bob does not give his device to Alice: Otherwise, something similar to ABC attack can be achieved by Bob giving Alice his Laptop or Phone, and I guess this happens more often than shipping Bob's access token to Alice. 
  • With these assumptions: 
    • It looks like a variation of token injection attack that we have been talking about for many years. 
    • If we token bind the refresh and access tokens, the ABC attack as described does not work. 
    • For something like Age verification, recognizing such attacks, it probably is a bad practice to rely on refresh/access token. The service should do more active check, e.g., through OpenID Connect. 
Best, 

Nat

On Tue, Nov 8, 2016 at 2:54 AM Denis <denis.ietf@free.fr> wrote:

Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies requirements.
One of them (which, BTW, should be moved into Section 4 - Threats) is :

Collusion:

      Resource servers that collude ...

This threat addresses the case of "collusion between servers" while the case of "collusion between clients"
has not been considered. When access tokens are being used, collusion between clients is of primary importance.

Let us consider the following "Alice and Bob Collusion attack" (ABC attack).

An uncle (Bob) is willing to collaborate with his young niece (Alice) who is less than 18 during a short period of time.
The niece is opening her own session and creates an account on a server. The uncle does not hand over his own session to her niece
at any point of time.

Let us assume that some crypto expert has written two specific pieces of software. One has been installed on the laptop
of the uncle and another one on the laptop of the niece. The two laptops are able to communicate using a network (e.g. a WAN or a LAN).

The niece creates an account on a resource server. Later on, the resource server asks her (or him ?) to demonstrate that she (or his ?)
is more than 18. She forwards the information received from the resource server to her uncle using the network. The uncle receives
that information and connects to an Authorization Server. The uncle requests an access token containing information demonstrating
that he is older than 18 and passed it back to his niece. The niece then presents it to the resource server. The access token is accepted.

Since the niece has been able to demonstrate once that she is more than 18, the resource server will remember this attribute
and in the future she will not need to demonstrate it again. She will keep the advantages related to this attribute associated
with her account on that resource server until she does not need it anymore, i.e. when she will really be over 18.

Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be
unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective
to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element.

RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 has omitted to take into consideration
the Alice and Bob Collusion attack.

Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.2 available at:
https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 :

To prevent “credential pooling”, i.e., multiple Users sharing their credentials, credentials can optionally be bound to a secret key,
i.e. a cryptographically strong random value that is assumed to be known only to a particular user. The credential specification
specifies whether the credentials issued according to this specification are to employ key binding or not.

A presentation token derived from such a key-bound credential always contains an implicit proof of knowledge of the underlying secret key,
so that the Verifier can be sure that the rightful owner of the credential was involved in the creation of the presentation token.
As an extra protection layer, the credentials can also be bound to a trusted physical device, such as a smart card, by keeping
the secret key in a protected area of the device. That is, the key cannot be extracted from the device, but the device does participate
in the presentation token generation to include an implicit proof of knowledge of this key in the token. Thus, for credentials that are key-bound
to a physical device it is impossible to create a presentation token without the device.

The rightful owner of the credential was indeed involved in real-time in the creation of the presentation token but in the collaboration scenario,
the key binding mechanism is not sufficient to counter that specific attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft) are currently
not resistant to the "ABC attack".

The IRMA card project (https://www.irmacard.org/) based on the use of a smart card and of the Idemix scheme claims to provide security
and privacy simultaneously. However, this project will not be resistant either to the ABC attack.

draft-ietf-oauth-pop-architecture-08 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

The scope of draft-ietf-oauth-token-exchange-06 is limited to the definition of a basic request and response protocol for
an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security Considerations) has omitted to take into consideration
the ABC attack and therefore the currently described "basic request and response protocol" will allow Bob to obtain an access
token and to pass it successfully to Alice so that she can use it.

draft-ietf-oauth-token-exchange-06 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

Denis

PS. I have recently registered to the OAuth mailing list.


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

Nat Sakimura

Chairman of the Board, OpenID Foundation



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

--------------050808000303080902090908-- From nobody Sat Nov 12 22:15:53 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38A21295C0 for ; Sat, 12 Nov 2016 22:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUuOPV8gWDgr for ; Sat, 12 Nov 2016 22:15:48 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) (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 D68C51294B4 for ; Sat, 12 Nov 2016 22:15:46 -0800 (PST) Received: from [58.120.104.2] (helo=[192.168.101.185]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5o4t-0004PC-07; Sun, 13 Nov 2016 07:15:44 +0100 To: Simon Moffatt , William Denniss , Aaron Parecki References: <8b540eff-2b1c-2d9f-6d40-2be327f91eb7@gmx.net> From: Torsten Lodderstedt Message-ID: <58280507.2000700@lodderstedt.net> Date: Sun, 13 Nov 2016 15:15:35 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010406020009000301040507" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Device Flow: Alternative to Polling X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 06:15:51 -0000 This is a multi-part message in MIME format. --------------010406020009000301040507 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit It would be great to learn more about implementation experiences and have implementation considerations in this spec. In the OpenID MODRNA working group, we are working on specs facing similar challenges and decided to offer both pull and push style communication (e.g. https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-user-questioning-api.xml). If your experience suggests pull is totally sufficient and easier to implement (esp. for the client), we could also simplify our stuff. best regards, Torsten. Am 24.10.2016 um 17:30 schrieb Simon Moffatt: > > I agree, simplicity is key here. > > From a practicality perspective (ForgeRock implemented the AS part of > the device flow in January), there were some steps to mitigate things > like potential excessive polling and DoS but they can be easily > overcome on the AS side of things), but as William says, polling is > simple and solves the use case. > > The option of running an HTTP stack on the device, is maybe overkill > for some deployments though, especially with lower powered devices and > the management overhead. > > Websocket style notifications are gaining popularity for other web > access management use cases like session destruction notifications and > session attribute changes so that seems a viable option. > > > On 21/10/16 23:50, William Denniss wrote: >> We've been operating with polling for a while and handle a decent >> amount of traffic (the YouTube TV app uses it), the polling gets the >> job done. The simplicity of the protocol definitely helps when used >> on constrained devices. >> >> I like the idea of adding HTTP/2 based long-poll as an optional >> enhancement, especially if we can define it in ways that don't alter >> the underlying protocol a whole lot. >> >> On Fri, Oct 21, 2016 at 3:35 PM, Aaron Parecki > > wrote: >> >> Part of the beauty of the current device flow spec is that it's >> so simple to support. Keeping that simplicity is crucial >> especially for this, since this flow is used by a variety of >> devices that often do not have higher level stacks. >> >> I would love to hear from someone who has experience with >> large-scale deployments of this to know whether polling is even a >> problem in the first place. >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> On Fri, Oct 21, 2016 at 3:23 PM, Hannes Tschofenig >> > wrote: >> >> Hi all, >> >> the device flow document outlines the case when an OAuth >> interaction >> gets "outsourced" to a separate device in order to allow user >> authentication and collecting the consent. >> >> The exchange is described in Section 1 of >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03 >> . >> >> Here is the step that was raised during the discussions: >> >> (E) While the end-user authorizes (or denies) the >> client's request >> (D), the client repeatedly polls the authorization >> server to find >> out if the end-user completed the end-user >> authorization step. >> The client includes the verification code and its client >> identifier. >> >> The question was whether we could come up with an alternative >> to polling >> since this step could potentially take some time. Hence, it >> would be >> better if the authorization server has a way to send a >> message to the >> client without polling. Of course, the polling frequency >> matters and how >> quickly one (e.g., user) wants to know about the successful >> authorization. >> >> So, the first question is whether polling is considered as a >> problem in >> the first place. >> >> If so, then the question is how this could be addressed and >> (from work >> in other areas) there are really only two approaches: >> >> 1) We make use of some protocol that keeps the connection >> open and allow >> asynchronous communication. HTTP/2 and Websockets come to mind. >> >> 2) The client can be addressed through some push notification >> mechanism, >> such as by running an HTTP server on the device that can then >> be used by >> the authorization server. >> >> Any views about this topic? >> >> 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 > > -- > ForgeRock *Simon Moffatt* > OpenAM - Technical Product Manager | ForgeRock > *tel* +44 (0) 7903 347 240 | *e* Simon.Moffatt@Forgerock.com > > *skype* simon.moffatt | *web* www.forgerock.com > | *twitter* @simonmoffatt > > > > Summits > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010406020009000301040507 Content-Type: multipart/related; boundary="------------000808020600020703070609" --------------000808020600020703070609 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit It would be great to learn more about implementation experiences and have implementation considerations in this spec.

In the OpenID MODRNA working group, we are working on specs facing similar challenges and decided to offer both pull and push style communication (e.g. https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-user-questioning-api.xml). If your experience suggests pull is totally sufficient and easier to implement (esp. for the client), we could also simplify our stuff.

best regards,
Torsten.

Am 24.10.2016 um 17:30 schrieb Simon Moffatt:

I agree, simplicity is key here.

From a practicality perspective (ForgeRock implemented the AS part of the device flow in January), there were some steps to mitigate things like potential excessive polling and DoS but they can be easily overcome on the AS side of things), but as William says, polling is simple and solves the use case.

The option of running an HTTP stack on the device, is maybe overkill for some deployments though, especially with lower powered devices and the management overhead.

Websocket style notifications are gaining popularity for other web access management use cases like session destruction notifications and session attribute changes so that seems a viable option.


On 21/10/16 23:50, William Denniss wrote:
We've been operating with polling for a while and handle a decent amount of traffic (the YouTube TV app uses it), the polling gets the job done. The simplicity of the protocol definitely helps when used on constrained devices.

I like the idea of adding HTTP/2 based long-poll as an optional enhancement, especially if we can define it in ways that don't alter the underlying protocol a whole lot.

On Fri, Oct 21, 2016 at 3:35 PM, Aaron Parecki <aaron@parecki.com> wrote:
Part of the beauty of the current device flow spec is that it's so simple to support. Keeping that simplicity is crucial especially for this, since this flow is used by a variety of devices that often do not have higher level stacks.

I would love to hear from someone who has experience with large-scale deployments of this to know whether polling is even a problem in the first place.

----
Aaron Parecki

----
Aaron Parecki


On Fri, Oct 21, 2016 at 3:23 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

the device flow document outlines the case when an OAuth interaction
gets "outsourced" to a separate device in order to allow user
authentication and collecting the consent.

The exchange is described in Section 1 of
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03.

Here is the step that was raised during the discussions:

(E) While the end-user authorizes (or denies) the client's request
(D), the client repeatedly polls the authorization server to find
out if the end-user completed the end-user authorization step.
The client includes the verification code and its client
identifier.

The question was whether we could come up with an alternative to polling
since this step could potentially take some time. Hence, it would be
better if the authorization server has a way to send a message to the
client without polling. Of course, the polling frequency matters and how
quickly one (e.g., user) wants to know about the successful authorization.

So, the first question is whether polling is considered as a problem in
the first place.

If so, then the question is how this could be addressed and (from work
in other areas) there are really only two approaches:

1) We make use of some protocol that keeps the connection open and allow
asynchronous communication. HTTP/2 and Websockets come to mind.

2) The client can be addressed through some push notification mechanism,
such as by running an HTTP server on the device that can then be used by
the authorization server.

Any views about this topic?

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

--
ForgeRock Simon Moffatt
OpenAM - Technical Product Manager | ForgeRock
tel +44 (0) 7903 347 240 | e Simon.Moffatt@Forgerock.com
skype simon.moffatt | web www.forgerock.com | twitter @simonmoffatt


Summits 


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

--------------000808020600020703070609 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAALkAAABGCAYAAACQaTWQAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAA2hpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tl dCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu My1jMDExIDY2LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRp ZDo0MTdDMzdBN0FBMjE2ODExODA4M0ZGQjNERTYwNDVFMiIgeG1wTU06RG9jdW1lbnRJRD0i eG1wLmRpZDo0RjYxRUYyOUNGOEMxMUU0OTM4QkU4RDlBQzg0QTY2NyIgeG1wTU06SW5zdGFu Y2VJRD0ieG1wLmlpZDo0RjYxRUYyOENGOEMxMUU0OTM4QkU4RDlBQzg0QTY2NyIgeG1wOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M2IChNYWNpbnRvc2gpIj4gPHhtcE1NOkRl cml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6MDcwNEQ1QTUxRDIwNjgxMThD MTQ5QjkzQTA5OEZCQTYiIHN0UmVmOmRvY3VtZW50SUQ9InhtcC5kaWQ6NDE3QzM3QTdBQTIx NjgxMTgwODNGRkIzREU2MDQ1RTIiLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4g PC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz4qUGMsAAAoB0lEQVR42tx9CZhdVZXu 2ufeW3Wr6tZcRSYSwkxAJHQQfbS2jAJO8emTp5EPuhsB7RZbaRAjMisoqPDsthVQoZ1QEFEE mechhISETGSeA5lTSaWqUqnUPeutvc+09z5rn3vDM75cbn2nzjztvfba//rX2usIRIQPT7kY AAFAQPgvXEE5NzepX7h59foG+OoFK+Hzn10BPT2NwP98dRkhvHgdwDP2B+v2dvNcRF+7hnwG Ol4k5wX7QbuGH87Na6rjoncC5rrGc6ljOujfDbTe7Pv58+rr+qCuMADDfl1YHL51Hfu+jnVV nl7yLtozpY/RrxHcr6FxCyxfcwo88+olkM8PQs4bjp+8va0VXnh5Ojw/bTq0t7bSZQVdKqy0 uDK1urQ2mXIA5rH0+8s9t8O++G3YsAFHjhwp/trXzRsvhuGbCH1u/2ijwKDgfGQvmgiSZ1aa VVG8gOvLXii4oQApwQat0fjxObygeimhFYZwR+upxngQLX+Wlk+n406huedj7qvNjZuhb7AL np/1RSj7BcjnhtwlqysFbv3t/GKlI6BAgr1p2+G0iLQ8REWTC2+DzKNgIq8CU3WZCDYj0X/N 5///9Mvb8pvS4FzrRrswhaGRIgFMBMnWmF6GBk+0G8bXCq8X3sm+TiCcYGjTYJvZYOL96HO9 Sjtd41yaT6Ht74uEP3h2eLy+MHBbnoRp+rzz4I1VZ0NTcYshAEIIVsDCl3AKjVIWmOxT10GM izpat69PjQ7q63qhoX47+NTgUte3JVJwMow1K7h7L+TIdFHCFmBMtXqh/qILaFo2FJ5IC4PR ldtzx4+OF0oY/YovEQl9NEfkYVP8DPLawcaRNJ1Pwv+/ad/xwb3Sz0aN5fLG4jaYPv98WLL6 ZBjZvpgX6H35c2hSv1xwCKqmvXVIEjW4vRJuYfUAtSjksaZBRitZQq8XthedKzSBSPewiSYH RqODAxenMXWgmYHB88k10OhNXNAFxtP0ME1Hmz0PWI1RXlfc0VbaOHfdpokwe/GnoKW04Vja fyYd+b2ooe+VwCOnZIUJLbTtCOhQzME+va6czyJ0SOoQcLQUm9ab1LKA69hAa7FgdJ+VYWLQ OMxTbOH1U9rWbehp1xBZ2j4x+GxtLhznBceqfbfR8tE6pk96HsP425nP77nSp/V5yz5KHZJH +HfXP5Jo3UL73qMLpS6owpYi1Ho+kT4Otb+kh7SOw+xGEQs4Y0gKl9pG17ag8fC9h6hVIY8K AisbGFElyUN9tDZ7hrCb8ME3mQTDGPQ0IeQe0dcE1NOWISXQyTU8Bq6ohU/SNDnC+prgG8av fGbS4lObGzdsWbzqFFix9iRobtowAdG7NDzoOynjTteweiHGRYspg5ATwOi4eB5qVbtRuDR+ CmlaSoyVV8GcI7iGgLUr5MjBErZL1QrTMzWTJkiasPma8WhSYoEg+Zom1YXdZGTccAaYhuVr k/6q6hrfSASZM4bjhrewWNf7o/5dnTB32WSoq+uHnOd/Q7vgqbKxQIpEQSes5fa7jkdTFbNQ JNL4qWtydYda3WEFeUVHQ8CalHFd3UUFYXZTUQGh683jErU4bAMepKlBW4unDcTKhqYNVeR6 SpOjr7Mpl9D+SVGPw+P2SMPD1MaGHnhj1RmwpecQKDX0nOqjONc64aZAyNICEmtp/OsoQoOB sTV6BWFF29AUDGWOYGp7hMzGui9+Qoh9KOSoGSSWYWIWkEipCuTaTIiLTSHKMgSthoCcw8i3 tLzH9hgBRZhcN1E+fhetX5dgd5ctoF7vARLqP0keev7Sj0FjcTsQMrvK6NGCC0+g8pnqEoKo 7GzoIqqUlBTkAR72OGGlqHBNBqboXDzLSta0JrdfFoTexzpbnNAEEZHzWur7OBjDNxIH1DC8 mhEHn3ImCc/Q+iHXfZnkwjnvYdpG8G8qFPph3tLJ0Edwpb5u5/kCvJNTFR68/NdIcDqyCZXq IIptpHLwRG8kIuluGeEVLDRB29tpG7gi2SlSgi72qSbfG8LjbVCIHJ2kGaHC/TDIwIi0qzth LjgoktCL9n7fdH/HlKRvCH7arZ8yPo+h616hO47MBpg4nciw/M/WpvUz1mw4AZauez+0NG1s pG03CXAIiYA22vYdKpOL8rkcFBuK2RBCd0UIm2q1FCmaMosaC2jLs76tVCpBIeeBX/bd2Dqu 1ySEwzA2BQdPapNKzGfiLmGyixYvFfl/MmhAHYtnxaiAReHpNKKtZdPwxsDhcRyIpzeUbyPD 4Sc9QmyEDuVzg99DyMGcJZNheLgeCo1b/s0ve6NQoCEgStOKmP2YUygUwCNDfP2GjYGH0pK+ xJPJxAYZEs/sMzSz1hqYVuFRQ+vZvgPWrd8A9fV1ptBathZyFig6epwsr+5+jsnzTovajuex 3dNoy6rHOGfM/Qaboa6nC67LSOVwO2gBWmYPgmkFdAYdN1mg72hISQMjw/Ka9tKG1QuWfwRW kyZvK711kO971xnQ2K5ohBdzudyP2lpb4fmXpsFzL0+HUlMj5CRE0pxrHGUYrZt0IK8vdWoy mEcyqzuDgsIcLpdpp4Bm0uio21iCEWCut+YfYJ97efctXAGmhdtUIiMckidHhxYXBsTwLfxs aVoDbmjGp8gI3mLDBLwgpMC89s2cR9XcJo/LzSvW9X2nf6AL5i79CBS8QfBE+RYfvYJeLqjH 7gh15hUdbS2w4I2FJOSvEH4vqMoaxnLyZJiIbzl+SlT7y4wmExI60LKcR29Wtpp6OXpzIVLC Ia/v5T1zuwuCMBGHrMZ+xwRoycqzumWzUKzYFU/XS54Dntj7PdbZky3EHCOj42srqCs56Hw6 bqKJfSMWxnwGaq83NzVuhhnzz4WNPUdAV+uqk0jAP8113ZEQkBDd3dLc/PKWLdvgkaeeg3wh V9/Y2Ci37456vpzlYMuBNXcqkUDw7OOjasgLYUUXAh8uXcnBF7vtK1An4m2EMOx37Ar3npXe x9expM8LqwFHshkv07vJNQhf48LT7nvrcZtow3eDjR7jHEqeiQT88VLDtl9t3X4IvLHiTCgV t0lv580u+i2EDcM5L3dtXSEH06bPhJ29OwmmlL5JAn6LYSGiGwoEbIbgqT1XF4pW1y7SeFs7 KEU/prh7O/IU9NBcUT0rtN8LOTKOAVEdVkvjKBM7uwWWhzmJdvaZ63D8u2aUmvj829QbjDB9 Vp4VahAIP3VIl9XVDZCx+UnY0TcGGup3fIGu9Pe88AXbymX/utbW5tXLV66BuQsXQ1t7W4HK 4hIqo0vokFEcv22XcyBMaOJd1BsUo12FJdiG884WYMHj6hS9yGwTtcumOOgFVwEyBacJvF/2 oKllj0KI5bJnQRI9MIvTpLZnEsKQXF0AweLUfSa+xbN6eLX/EJr+VYc9HGQJlvM/a23aOG/t xuNh6epToKW0Pu/7uct1rW1rMpqvqKvP31wmA+/V12Yr7FzI5aRTqDVQzuJS1oAXDLZ12D6o +9Bdvas+uAU5oWTO1ytbVBDod4aMa5rcyedieltYUY1Ne2DOnDYF7dvbhwDLwgrAynIMeany RAAWhmTTjH7c02IsQP7Npr3hgRmxGO/ozeeGvi7HMS0gY3NPOQ/53O5raPUQXWvbzhfS2Ne1 trQMzZn3BixdvhJaW1vGk1BelUQr42X0byKLtatEJc5zxP+DIEb1iZimKLGKZ8J3giZH4Ls7 vWvUjh19wG74w2MHwLU/mAC5XBmKDWXDccNrXI/1dCbsC0dJepkwxwzj9c6m6VPc8bajiXD3 1c2lDVuWrjkZlq07ScaKj0X0/t3S2jbV90KxWPzFzp39MGPWnICLBvFN1ahMYfyWgb2xSkFK c33gsg2cTh5W43N+D51FEGaP4+w59h3Fsm9jV3RIYkAVm2nBRNAVr+zB+AMH4a77xsKDT4wh zT4gueYq+FATdgTrkA1FWJaGHfw81dUgjOhG9JYX6/r/o3+gA15f/HGoLwwQNvelYDZwwqRh 5m+0NJdg1py5sGnzFmhuKk2ijRcwgvARms6MzxXgjPCMGwCCaTAicHGzvEdVMJY8corLhUlc Q/f+dhp8X/HknmZ2JzEQmRx5UgHyoQp5H0Z27obbfzkOtu0oQUfrbhJ02+g0GRfbeBRxQJeL hYkiCX2LyfE0wVX7/pm2fcCMEdc6LENBiqmNDZv8xatPg809h0Njw7aTSbOfl8Um0Pv+qrnU 9OLaN9+CGbPnQKnUJMvmhpi1AMuWAbgppb0554tt5Kc0b7AgKsWO2CN7OM0MDMmAYLIpmfEq NUwhcoZWNXiNBAO6SMiXrCjBfQ+OBpEbdjiEKnGRfmxw2lo+ce+nIUxi2Hot9O9GO0ZcpxwT b6z3QlPDtvs2bz8S5i37iBRwee9vViirYepOr60v1sNrs+dCX98ANDQUzyHBP9sot5g6VNr2 +KDh2SyNqICbGeMSLU0nHJSkQdGI1CgjO5TabARaQ8LMB6pNIU8KULixHLox5IgRg3DvwyNg 89ZG6OwYAt/XYYmfSRvG3krGTW9EGWIYsAXpiEaarqV/I+LjtVhzG+tT3X9NUoZzl3wMdvSN hGLdTtLg4jRdUGzq0Pf9H7S3ty5ftnIVLFi0WOUzoW03sFhSGJMcQdRsQBasIoALHVg7A9On GgFiahSRcxCzsDQ51wPUaKwtFxLo1tyO8X7ylNbSMKzfVIT7HxpNW/ZAZ+cuyKnQbl2D+nGs eBp/+8wEhkZWRq0WL54MXPbG0fSFiDGh5Z005yZpR/xna2n9K29tOgaWyyjD0pYiYO5GjTlJ GXn0t76uULh+eE8ZXnl1JgwPl6FQl5MG6hEV47sRuun/tSkBAoexn2VMVpK3rPOwil4j1SB0 vj7pUWrtlzeZFPfIfMOlyyaqARhD2vzu34+BJasb4eLProUjD98O5eHdMDQYxiYD2sBYG6gh NA4QzdjSlMNCM4ADoeynfUfS6mZaK6TiaZPre/n8noHh4SJMn38eDJfrgGDLZb7vjbHfV6/s crl8dWdnR780NpcuXwVdHR0jfR+vMcvNjio0iuYrtPNHdNgKNiowa2SPYARbuCELHzZt16lg SAVOq2M6dEDUspAbA2FFKrbYFc2my1F9Pf3zhuGxZ7vhuWmdcO4n18KUyVKB1sPQHt80ZEJB FeG1BRNolGwTaeIAjRraGkxq46DdSvW20dq8HmYt+jS8ufFYaG9ZdwQJ+A2mjSVsB9CMYkPx pzv7diosXqyvlzE719O1mi1KJCu+Q4Yk3k67znALFQNBBKO6rSRPLOXHwH8z8A5Twszy6QJq OjDLEnLzRTFVgFpyGS5RTYxbSY3mAA4eNwA7+z340S8OgMHhz8AxR42Dnh19DC8lIGvUbFK+ wsFriSq9Kcl5eWqEu4cblLDTlkGq/D10p4J+Vz2stez7V7e1tqgIwzVvvgUjursmUcO70IUb UI/vNq1C32hIXP4TuzdNxaOIxJnj0syOurFDa5NnwGwo9DcU8H0cT+4KqxRm5izOpZySOyRh F9BYLMOo7n5oaChAvtAEe8p9kMt56cLDbF9GKrgOTHQQbpKxIh20skW9k9uDmxvc07CpkN89 6HllyQytoa1fpgr/MZdSwkf/ty3NjY9u2LhJafGWJhWffaP5wOiAEAb0k7EPF7qoSSdITgms K30funsGDuJE0aYiw5B1DLaoRZ48X0n7GbHFIgMzWtpDUA+dz+VhxqxX4MAx7dDdUYTtO3rB y3kmZYnpbr5iSCemoMVIms0KL1nWjSY0iWsPcjJDLVyNGFOmP6F//0Z7j9IFUM494V1bT/Dk ladfUKNturs7P+37/of22hUP8H9oWuMuN738wNTU7Egeq3et9AxOOCOyjUlWwGs+uVD6paod r2hqlAB3NzY0wrIVq+H3DzykGInm5pKk3cxrCxMmCMfgaa7ytEqfTdvuDJdz0UT7c9p69K5X 0T2ONN5ZwBUp2hDhltbWlsUrV62F+W8sgtY2RRle5XTmuP0KG2m6lu2edFysa2vhYD343Bd8 eaEjuEs42BJRicUR1Tg89mMhR9uZsZf8vzMLGUJXRzssW7kaHvzLY1DI56FYLCrtzWWPMtKl CYvGMuw7NsZaaujdDP2XosTo+t/S06rR8oO060HtmTYRtPqW3DnjtdlQxjL1Srl/oe3HJvaf qEzJBUJ1JR3az8MMzcjL0iRc43AaqRWy2QKmWSAXN+/CkDUp5E43vuDL34hj5lIfmAbPAd2d sHDxUnj62Zegu7MDurs6oaO9TUbvEU7PkYZER/WKlMaPYqKZIKW1NF0DKdM13fDo979oOlm/ Hv10rvwaerbeeQsWwqKlK6C11NJOW68z7IfIn4AGprDns+nAn2UKiKjEYSOf21BkHF+N34ZT ZBlp49h03rVHITpKQvBWMOqjT4y4i3TpyuNldz9n/nwFV1paStA/MAClUiNMPPZYaC41Kbwe UYkuRkAfMe7A7N+laQoJwbu5QcKWsMtw3BO1Y6ZLbU7G5mnU2/xkaGg3vDprDhQKeWlHXE/P 1uViLlJDzJLly7NoV6fgiWx8zTMzFYklnnnBKh1QonY1ed5JYbksakxrVtNRlLba5T45wHfY y8HM1+dIWk4Ju7zd8pVr4QMnnQjjx40DyUUP9A+q1A62Vom0F+eRs5Jf3kzrv7LpQMa59R7a PoWm30R0Gv3dQI3ov6Tt8NK0V2Hj5s3SfX807fuSafAyoR1pLfgQTU+5ytKgEbmyzDLyq3EC 6fcR6GZj2Gu5P6VSi6G2+ZSx4rLIo5ePPqWC6Exiyf2kvSmFV0IUVYdecI0Vq1bDujffgvdM mgjvnXQ8dHd3wLae7aoReFFaB6gyMWbw+zVNMprwQylNnk7JILX5H2h5UIUO+/7MAzo7YfHS ZfDM8y+BHJRM1/i2zS7x10wJxtedyoKj8HQYlDnoWMS+yEyZQw2KodUDZ1CLLDVsvN6+U+f7 NtRWF2JgDL6UQY6VjVDMKBwtB3onYfO6+jrlbPn1fffDgkVLoJOMVQllfPT3ooQMAbwsJYz8 4APpzr8+KuBSUxNs2roNHnvyWUV1NtTXT6bTPpF5T17Wvk1bFlQcxLAXRrzuFEL7g2XVZJsV bPYvd76dvXm2mjI8LZrKcO3b35gRkJ2xVVRh7EgNr2LS88oY3bptO9z/p7/Aw48+Cbt27Vbb PM+rroWb95tH088tmtDVC3yZpnGFXJD04clnnqPn6IHWlhZpEF/nxG3ooDNRhRjcClzumqql R6QiBgyPmKgAYRAckaMizahw54FFbwLUbNpmgyc3edQKlneWccJRX1kVGo2LJEFuaW6GtpZm eGXWbPj17/4AcgyldKk3NjTE/Do35tLxk3ChrwooVS8NViT4tJuMzd6d/VBfrxIEXUj/jktJ KccroyEkMi59a1WMhvMYZEfaM4aFlqGLGb5mNzKsxnkkeKZM1LomN7qrKpurEG5hRge+t6+P lsEl47sIJozs6oL+XQPwwEOPwCOPP6XCAVpJ+KWg68yK7kBi+PDNNqXocjTR9s+Uh8unN5ea 4egjj4ChITXwYwlLj7pc4cH0Cv3/CRsLnjX8jTWMIcPTaDpxUPvek319IUQVnk8LVqY+pbI3 FNF+KuTGQFuxF9pGoxmFnsRfVOBjOUMQk4qSvLnExx1trTBt5iy494E/yzwn0CIFveynOHT7 0yKaEfNDmlbZRqr93Z5w+5V9/f1wwvHHwrixo2FHb+9zdNzPWRrN5U8AuNEtPA6t7mhA6GK5 XH4LLdTBaAuuARpZjqUUN1/p0xQ1IOTOgbbIaMAI0iCDb11Zo7KMNm4EeBR+S3h8ZPcBsHzF KsLqD6trN5UaY48pY3Ba384RUiVPtbU9l0uFficPDQ2d30DQ6ITjjgM5QML3y1eCCt3loJuw /Ql/poU/p3Asi5cF38tV1YOCe4wow/wIozcS1RnATCKkdwAmF6xGiZKwpykzzEq/6jZkMhgD N2RHMkC7YPHy5fDUsy8SPi9CngzVLOLFEubf0jQNdVbC8h5Gx5ORe+P2HTuaJhx1OBxx+CHQ 29u7QY7rdH4n01y9jB0XyfRkAhgsn0EDmj2nyMb5XI8gGH6cvW/6Y17VDk3d/4Vcw88pj6Ow agch25FgYdAUDsaMyrTzjWhauruzE1597XWYOWsudHS0GyaBLazMlx2+ZnxeUDgHbo8mDX61 LJb3TpoIdXVFIKx+Kx2y1qJS7Hf+Ie1awtKnogK3z/WerrgUJ08tqhREYTI0rhyK75DBEg4K 0focnt7NMXjWGVVn05Au5wOkP+GhOy50DCxjXCROf+q5F2Hp8hVw4JhR0NnRBu2E22Vu8FJz ExTqCxp6MGroRZruwHjkEAxKBxAdo6Zw2y51X098eUfvjnEHjRsLRx91GPT29w3Rpb4RCtiw OlaEU/DbYBu4TgMzi1YVwA9Vs6k/Vr6r/AgXIt9zcukohKj87DXyc8euIN/NObOpCot5cYx8 EZbgI/LDrFJeRjquobEB+vr64NEnnoH16zeqdLRlwi3FYr2iH6UTqauzQyWh7+vrV/nThYg/ Ayj5cNLSSby5/aHZcJTQCLrXrhzZAx1tbeAPyyRy4h4U+KjRhIPnlZmZd9G8Nw0voKI3smL8 iXBCo1QOcXTRnPb92NgbSI02EuIdkwqRH/5WPRcOUBVeNQbGcia+NgAgg4+XI/NlXMng4G54 6vmXYtGUCefrCac3NTbBoeMPggmkgceMHq08pr29O9WchGK3iu2GZOyolmdcj27cIZdlfM3Q nj2qtlFleRRb0EWLupgjO184VuFzqAYmcMrBlWR/b3B1ipaEKmiimhFyNDUEE2TFDnpNj9Bx V5Qxgh5NAzZLBVrDyyRXXldXgM66Ng3hBDHSAwO7YPprs2HeG4vg0EMOguOPexccfNA4tV3S g9J7qtsarlBc+f5ywEdDQ32YRkOLNXGO6snQ0JqAs5GRlTS+lkErFbMiKjQS4aB/XbHtolL7 ErUq5Ek3hpnuaF6QMWuMoWGAZWXnQmOcaNV4UCTJ7IsklA2NRdLAwzB3wUJYQth94jHHwPtO /Dvo7uqA7dt7lYYO6EkBpcZGkB+0SuLZg5H9Ev9v2LQJ1qx9K/m4lJ5ywsCtFeJ4XDCsmp5S mFAiZXcK4RZY3Q/A9UCOXsYVtQkVAuVqCJNjhbQIlWrTWhaQ7S0UFbpa2+gXjgowvhwiY2Fy CpsPDe2Bl16dCUtXroLTPvh+OOzg8eEY0+CE5bR989YtUFeoi80IGUcjY91nz11A2n8ApBc0 SGCE7mSZVWg/FByXWK132VIE7FAecCugzLzo6OD+wZ0RoCaFHJnutxJ36yxs1BxGGQFdro8z cQUqHEZvBlxUyUgLeRg5ootweZ8afjdm1EiQHLhsAPPmL4RFS5bCAOF7eZz+k9pe5ldpbmqK 4UpmJWd9Qc0Bi6xPUUHFOP5sjj47CZHe2CpkBEDXe2WFANeEkFfKzJSCHZpwO7tczKRz2Yqz U0RnDbSt0qBSIQIlOYC6DKvWvQnr1q9XzqRdJNwqdKChgU1qFLvEU9/hgaoT67P2DQdbKn15 jRE8fYxqZlSibaxmwqIsxqzWMTlmd3luIxKrMFqq7ebsARmY3WWKKpVd2GjkAAwZ4ahCAmgq 1hcN7t8QmhTzKSpn+2UEAtFRPuhusM7MtfYH3UR1SiRlrGKWMSrAmRAU4W/yLc99q8mrMJoy u9Jgu0yfPA5k+CrCNhKONZJ+qy6WRWM8RAXuPvt5SuoZhEqmL9N2yXwnu6IKjAQajBwvkCEI AtC6l2nMZXjCssrQCp8Ir9dFqweqpDWBk+ktVtkIG9cb95UesYNAfr8IldNrDe3emdm7CK43 TSkgqRXqaP/O6GYfnnJxO80m0bTiL7+5fcX+KuRRqO3MoFDFQprHExWIsR56+X6uw5Gw+/oQ TS/QtIO2zKNdM2nzCirgnvD4Ax09xmdBppFAWEzHBPfA+H5LaHkRBMPZTucbokFb/ANNT9LS dpovCN5JLFLPJLcjnsJo1HZ6xteVMOnvKd89LgsMJqGcSNdAkrPxGvntWWE8szxWPfMSOv8N mt9J553IalszAvPztC7P26xG+AO8RtOb8rlU7EzQcDWta+dAUS91KN3zl7Qoy3ypen8B82mi OoGXaDpLM0Q/CjJJKsJKmm8KBdWmgT6ongFhGa2sU04vgHdFbZ4EXKakvjc89wpafyIU+rf9 29djPI+gSSawHOHGjfFvnHXMY0rI9Uy3icaTebn/iRbl9FXacJul0dqVdhDq/i6HikwENIWW ZcVLQd2ZnB9/1vt31H2fw9JeZH/Susw9fhot303L/2S9/1F0kBw4YXyWMAVdggoYrXXnMke1 RwJ6VAbmnkAzKcAP0jSZgW7jaXqeNo91wINRdB3ZmK6i5bOoPJ8IYEpK415PAn8V8rEycstJ 9P8RWvwZnfh5UMlKQQ5gHR9ep2SyN/A+et9nwchZjz+lfy/LXoKE+TM07wl3nk6TVC53hEJ/ xtsVxr/NGE8XyOM+txGc8yrNP+SGxagffyv9vzQOpBIVPhSZNjgn0fwBBgo8SoVzTiZHn+x7 1tpnUkPMcLNk0AGaudsxDA+o9IHfYP/H6f/dYORqgXFUDnNoeawTUKNRT4/Te57KwDSZm/Gq VNIj9hOV+KARnJXcVo/pnBj0yobz7lY67sLwuuulYBM8kek/gOZSqC+iuVRCK6gBHLJ/anKT HpMxGl9RmgrRM7/riY0Q5fQTMJX+vcfixO+h6X4Vy4FwKG35Il373XFORcTvkyZ6nLbPdzzP xWHXKhPXS1f6cXTO9UrjBxV7WqgpngjXLwL58SnThX4PrdwbQCepbQUJmGoE8qNX/+02sBXu lGG5MuPVwXFHkBh4JQVFeKfKjhB6bVUaMoiPeT+o5Puqp5K/88OvTiwKi+w2UgItWq8joeDt SisiDNP2v6P5l1QPk1TPnSBT3AkcDnswKn+Yqqe2oGtKbXt7YA9JjI+foO2fo20yOdKDyXg5 LuccHA4ymA3DL9kF1/2FVE6as2xI6+EnkVAvp/l94brE5YeE8/1Gk3NZbVfRtFjhZKdjAJro dS+1DBgJKe7RjpeC+BOFqQVM0QzKr9J0gcNp8jJdc0FSYaRRhIo3uVe7z0Ql5MH6FdYlzqWz fm0l75f3/0oMcxhIpDErS6UtEVeSkypMsTxDND1Nm/Q0dS+EndlN2nHvDxvKe+me/1Mrv10q D4x89+T3KEnULRDYDEeH20iAUKar+2Eo0FdYz0m9ZfChXM2n8Hs68HqF96130gzoTeGmaTQ1 icTzfY9qnJrhH33cL8TfUntLjX6RBl3u2F8NT70bLcYlIEBPmJnTaNKT4oxSwU/itXt4DYlf pH9btLZ0NnDRj4G3Msd8aWyN9XxNkRYJtUZUY/eERmp0ai68jwi72IFwPRdXNZoMWsgKReUS vDOGU7YzhkfDCDOsXIOF8LCzLAXxNZoWpI1SlCmf/9FywJ1sYO3kcZYGGlfPkxEbRzLWvcdg qdCAk0eGuLpTayCycUzRX1kbMC0FWfZKTxJMkee9RkIvG9xrtN6zfwq5Sf6fo7R5MFBgdThJ QRuONbBkMswqfYzljYN1GYb6R63yRtH2cY6hWMMpWUIFUfRKXhGuTLQYh6c1mkwakrMVhSjo PQRIdmBNOA2H75h2lwsJrxTjsCZ+d6G08wtWQ7O8xCLKYGriYEEQBrWYeSHvjwEsSARfQo8/ uLtqMSNknqLWeHC44xhaH6WV4bOG3cQ1Ro7tFLAnhCSn6cJMf1emnEnhK5Ig3xc2itMlqxJq cLn96/s1T645DRoVz8rnpg7TXxE+NfneHtZ5kVT6RtMVKPlWlg+/JKTgWhQEEOoTgedodUYV gs+Ey2OtLABbtaqVmHIsvVM9vdMY4x0DLdbkcME3S+Yh6q61lG2jWCFJLiCvd5XikIN3k5j6 JFr/qOZAkZr24fC8knY9OkdsZ51cSVw3QQ0xIXSQFcO9TVb5bdI/h1hVGK6IefW2lGdUqARN F6WcVeFzhoJ+X+04g0y6cEeoxeo0CZL/DoUkn8hWKwHnSGeYbnDgWAvGDDhiWS52el2DY6Qh Fg5Fk/ytIXSaVlMjeBbScx0evousxEO1YKUhQ50lhrd8r3UoKcXE6ByhuGKhBVqlhaYxNFiz PItf0pa3a4xCO8p7gOpBUkoirJfRGrbqC+/RY3H+B1psVIWUf1AhJEBcSI1K9mC/fGekbjZ/ 99N0nOJ4BUwQci65ZIUnMWInnrEax6dZly+GXLCO7YSCQmveRgzE2YlRo86dbXkhP6bdc3eI V7tp/QSafmtV8FrDw5f87gwN2wnxhNBBgngGgCv/oIP6MzcfQxse1+610DrhAvtcjQr8MP0/ TNu3JDxySQgro+1nhl5et/mQFe8jFOQ8x+JgZXkf7KRka0nILW4VU2M00xTDNE2jyt9kOuxK Q0Mkhudd8ntU2rEPpAQmKbif0+apNF0ed+0xzhSHWTUnDbXXtWF0Z9H8GqYSumnbv8Q8LKqe aq75OrGw73F+BJYbaJxYrNIb+D1alGM9L4NgTKk+7vJwK87nIat8r6Rjz9K0aLT9YHrouyyh fEIT2GeS9BZiJP37jSMvy/8A+ckZvgHKn/waxucC+IEagSAkNLor9RnyGvvlGUH20l+hAjv+ 2FdetuQTJnKb5KE/RdOPIXBPnxhi7JJWsPKLCz9wB/DDrcoVHdzyexB8JmVi+Az/ETasP8Wf RpSJ8XUHkeSlkRqcUMfK2I8TafnyiJEJodRdyluX+viXOv84mn+A5mN1IywsHwl5pBE4g6FV +1R6OBFSiAJk4v1FdL8R4TF/pGOkSzxKAroAglyN/xyjEIGPKAMeyQgUKK/zsYC+M+pmhnIq Jfe9gY49L2CCVEP8hBJYUJ5l6YtopWPPo9I6A2Vmr4Dp4jT7eTSPoOi/0vZTFUwLAuY+SM92 BW37blz/tSjkxgvb6XttC8akDaVF/hnteserLs5pgFKlIaxLRRaKWFPmlFAlDpgLFBebVEbo WsbN4RFSeH4csiLR4x4fChBHxG8OPYTMQAT1+7iabEMrWb8jFLQUwW/QkkJh7s/Tu/1ZE1Kp Id9tOb5kI3yXtu1MBTv4SMFdiq0xbAmF47+onis55wBauJH5ZOUXlB0j4PuxhzOp2n7tVXrU oG8Bv9Pu/h1af5p995rC5EmhFvhPoyAfYIVKazrYr7jgZHf+4RDvW8JhZvpBc7TBLJrfoCWi 7IrpyOQcCUVuqGgUBYOYPxg7RaKzMQo5cjy/ifuFoSCS8yI/gl6OBEnwbu34Y9X7J/ulcfze kIpzOJ3iZ19J26R3c7lRJwE0uTPUxGU2uZF+zSRGxrOyZBUi2jM0zu+N/B5aL/+I/DJOLQp5 NFpfunvlC0gv1itOloAPyf2yMtgQLqXlSSEbUSB56KOTV5NgPEbd9m20r4+5hnQJT9fYmu3p z4zj9eqagIepa8hwAVnhkaMlqImrQ0eQ9PZJYRgd0ocDNF9FV5LvJz8zOGiF0RIswD+G791n D8mzepVxGERrRr+ZqucijE/HrUXl9UwZ3v8OQSBUSxg+OzKMVVkbjpwaCL/SfJYKUUBl7Etj mSCj2Eb7lymNGkCsVB1oSfV/qdLUCfX+p9L6+JDxkTSshG2zlDIKIhxB+UCECrbqofIp0jtu ZMYG0LNLf4MK5ZDe4hNom3RE3VtrQv5/BRgAcKtc5z2U87AAAAAASUVORK5CYII= --------------000808020600020703070609 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAj8AAADICAIAAACIxhfoAAAACXBIWXMAAAsTAAALEwEAmpwY AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAB6mlJREFUeNqUvQm4LVlV Jhg7Is50pzdl5iMnyTlJwBSEJJOERIQuSwuFBCdABmlLAbG0++uq/qottb/6qqr9qq2uwSpE SssBlcJSU1TUdmhABZQpmZJMhvdyziSnN9zp3HuGiOi11r/WinXi3MR8Jx+Xc8+NE7Fjx95r /Ne/0vr6Rl1XmbzyvPD3eNV1LZ/n8T296fz0g/19/BVf9PN0Tu6vv/cqnRPik84Xy7LnJ5zP Z/gr3ZccUPkN4pOiyOOo8CFOi4P7/X57QEr9Xg/vk5zU76IsS3ozm07pTbLP5/N5v8dfn1dz Oqapa/yJ3tCfev1+QRcoyqqi3+ZFWfIl5Q3O7DeV5FQypHo4HFZh0oaDIZ28kU/oVPTTz0Zf L4vST4LJoUHQkDCePOU02lxmoK5kGou8SHnCnKSczlPKqHhCGj6efvJVm4xGPqMhyYc0PPoK HYyv9Ad9fJ1vuKpxfh5eyqsGD6j0+ZlOpnEM9H5/fz8eQ3/C2OhzHEnnobuby8v/Sm/oVPJM 2ptqqpoGVsrBfn68x1TQJ531U/ZKnw3cON0Ofp1Op37kdDblg4sSM4Cz+WzjKjgzTTU+xwjx K54Rjz/PB8Mh3tBnSX7iur624/Do4Mn+fiGTg+dLJ6QHSn+aTPZHo5W5nBljoPujMdMCrmTt 0YfrGxs8pBkfgIWNF+aWvktPFoPHr6WsKN96tSxiWoF4RljeOJ4mhN7Q8ZhAugS94cVT1f6s O2/oPHQ2DGY2m/KGkgU53hvT6qIx08/BYIgVRefBLGE8uGv6FUOle69kD/I5q1rnvMh9xdJV +OBKlmg1p31ayGhdpPiZ46b2+ceuwXOnM9BP7FNfqDS9DW09e6ZRrPH9JtokCROOR4zv+ptG rqWrtF5YpfTduqqijMIgfYEtS04/xu9rbouqc3x8+WaH6KMHiTd+wqqqe70Sl6D3kJxVBcmT L59w+eXf9U/ohLPZPJ7KpbS/9+UXR+4HFIPBoGkam6uc3vMqlVdKiX7iy34M3vhPnzj/hL5l Z0vxi/HIeHIc8GRXUW0hp8Kbzl/9ijghPq/kkeNXfI5ngxvEndoZ6O9JdF47bHrRBPV6/AiL ghQePbmeKsKikL/mWH9YfLndC20J+utsPmPB1+vrkBKfmj7plT06G/0CIZvJn3i0JLnoSB5e ogNYashYcDbaPLQ8VlZWS3k1LDH1MPtr4auHNidOktujpG2T5B5xL/RhIS+I1Fz+xl9Peu+F 3CCdVqc3k8mUoapKoKFm8gj50wZf0Qcnt0ZCMNc55NmlYyBHcC3RdyrF6B7w+LBG5UjSODkU Eh1Jh2EAeoA8R37cKcMwWNsWBR43TohLsAqXqaaD6EOWX6zqKpyWb02Gx7MhY5CJbTA2X0X0 0OknS+fpFPOmck0mpzT5BWuAvks/VbGJEK/qCo8GAreCEZM1WDZkvtBI9dHLyWl4PhukqLDe KhGINFbSW/PZDCvHtk/dSqWkzw5jm4iC4fGz7J7RJ2tr6429aEmQcsFXaNiVvEozm2jw9CGt VfqvEdFasb6d0bf29/ewhmWKeEnwPWJJp7zX78FwwUzSf/gTjoHMJWnDdzcY8IOgE+SJZizD 7diiooXdkxcdTwppNpthg2MBQw/RYXgcssgrGhW2LWZYZoxPSM/dhCbfYCVHynOXfUEbX54U DQYrQdeMLAOX/lgndAba13LOmQj2yvegHimLn0ZDA6YFA2lGb+hmMWNJVBGPx7Y8VhtUGpYB fmIFyqLKqwozTDKqpLPRr7xs7HlhMWDx409RH9Mn0+mEFgd2DQ6Ikjm+om6gxw1RSdoF4tz1 QslbzLVgkn/5sqLylYwrztiASHL3FWSv6zO/uusgWXGVKwKX8/BD6E+t9ur1yo4nhOP8PqNi 6Lw6Ksc/8XHjhQPoWceBdjSQX9S/4mNwa8IVVVC3yVe27N5SDJ08XgKqiDYgpiYeINKngFZj SUG7gq9bYJ+oiCc91O/z8pUPedGY4CuDFYzlC4GOSYDaY6ltpittftotNPsQCTysXJUZbSre 51jEsjN9ZmDX43agF+lgFlKZTCArlIr2C52L/lqJDZWJhCK5QD/ho8TphQTHBsB+cGXP81zk qq4yVejY0gUv1AQdg83AMo72r3hm+ohJT8D9osvJRRMER6+EQMlMT2TyH5wzzFItstifuOyc GeQItJ5vUSgG3D4LzbJ0k4UGgJ+tNUqzOpv3SpUyLH1kkjE8iF0W0zQw2ghN5rpcF3YiNdNj HVkWUHt0wGQ6wUyyQhKtjBc+xA3y+esmWvew2SHCki0hWC1sMfCjVHWFOYeuIiFOnzTsXU1U AGUZvR+Q705rlx3R0nUYgg37e3t9Epn9AQ1+OiHhlZEuxLDFXx/w45OVA1HLxkFT021iSVei RPG8eG2LMsOFVlZXYB/Ay5clwHdNT5xXZlKdQadqb1wOwoTQzM9EldIbVgazGZ2N1wBNznQy Go5ge2EH4VHq/i149jBp7pezTdnvudjB3vR1WFcyq7mKL7oLjFBkX+4GKMZWyk5X2ZKpXIJ6 wDPCFOlFZdfQc6HP6YZ4N9EbES+NbCFsXvoK5IZKEnmgLq9wWshJGCj+CWy1VnaJGMGw8Wjw OT6BandXzM19H7bZkKkTEouSuePuQx6KAktRY0FXRZeDZ4VvcEHmR8Hrqit8+Pd7aRg8FFVU SRYbK/xIDo7R7zKI0jWKv3xMB2qvzocxxBfPExWy3zmO7/hSy36bH+A3gPvv6C03WzDv8bqm C2H+5PBY8TAw9TjAgkgFLG64IJn5EAvSn/0DtTdp1ZIuEbVXY9lBwvIW5QXdYK9CEcKZa+RQ XKIxzwkuFPYSlj7WE4tpuzTeQClij9Ffs/AIxru7o9FII1oclRr4onelxWMQgQvTVazsEh5M AQ+s0WiJGX3tVCebz6quMA8ZwoYzDXRUHHMQHSBnxth4tsU3IIHCpydFKLPHe5KOl/BXkXRu eR5ET+AD2pxwEGERQwiymQL91IjVnKk/AfWDnUwHwK8lQQ9B4/qeRwuLgWSfmP9QPxqiKXLc hZsgLGTFvavMN3LZR+eB9R3DCSod4GKKPSRbjC8nUb4qS+0Lkg7fxZOFq8RXlGVDL/a65vOV lRUEx+jrdGODwZAEOivjiu0VOvVMxA2+SxeCF8gjybLV1VVWHrMZnQTDhoEyC3E8RLdYLvPp WBRgftjBbTjS2ECkynrm2OOgL+G3wmPaMA74oYpmoq9jR9B7PO65iWl1TIuCBknDpgfE2rpi TwvKGNOCYYz3xrgR1Vsp8/P4NlE1UFXYvFgqbfyN9P2U/puQjpQYmB7Wiq/E5oKbRB46hjHn G1CUkAaH2QWczchJpI+weRHDFx+O5oU+bKBd4OTV7LqpHLC938A5c0noY8Yqwg7VKIKJUJhH PjyPSOHM7imSDCR53omLqsQvClc2EA60R1SqNJBXNGpaVAXCeu510Y3QJ7JWM48fuscRBf6S 43Gw+kBs0PWZXavy0XbcmGXNx9oL0g1Oie9PNw1cu8Qo34Gj8a/EI+MI/OQx5BhVo6srNxCi 7rUDcg8Ati5kUL1pQTqUrvPFjsmj+cDGa1741UuJP+AB46kjfITBYMH1OV9VwEabig0OEa/2 gnwdDxQekmdWcvGIMUKIMwS+C3uR/4SYicfrLEHFll1MhvE2q1XtwVzFtWjzQzGwnOz1EOug M+OcsGoxckT82KuDUyKKTfSNhPJFKOe4gPtqtYYdOJpH2y+XDBm7pBWUn+63pMZy5gqMJ0Wj fCxWyF5L7DDCUcNFPcs1n1kIRQ7m8BWyL5KmUmMZtnnKfb+p+yXbB1+k88CFVc8eAlFkK8aJ QJ+HK6FWNXgoKq0UkQFPtBAXJEsLS91DrJhYzCTsBpp2jKbVSXPNSNGzoGXDj3s6hb5sJJSE ODP9yTMWiA/zn8iP4kBaX5JnE9j+yTw+ekr0tMfjMVQLx4pJRzb1TJJe9DOXMLIKXHF6YC1h uuCpkGgfSqySTl5IeqNPrhjSlk0GLQI3FIsHNhByXbDxEbTEhTAbrJ/Kwp1auOAabiVfnPOX BRxAmAuTyT49bchKF6xReCFuQUOC7oHLzmqJJq1Y8BX8GbViToaHMJ3swTYy5I47L4mq7kg2 D8exGoZ/KTHbxOPpwUhld5nUM4fpph7t4l3JIVpVky4VoXpdDEKBQc3j1VEGHvFzmwln80+i Q+YSG46LqNHCp7HdDjYkWZkzJFA84UJrJGALUnA2Eoz+qqpNiiboMB9PR7DjbMvKAooq3GPe yUm5FvD30eXykxQwDZbjjzFeF1VIPCwqp6h4Xc+7MovpX5/ljrbzkxSWLnbnzwOArn49AOhv 4GB5bBD/HKMBvRVsk8o0kx4AjYi4fIy0egS8EPGEIJ76PVmGxLX5hbmmH0yvYNvQVWGgJbGa EaOnxdOzxBiWkao03kBsRdKZNQ9UsDgg3YbIJGREI6E22N2qTU2Msg8nmSE683AwgKhCeAHj 3NvfQ/zT9YQ+TXFxoiSCJ1bVlT+CpA4HaYJM5xhZLrhmSfEaSGlgxWM8uihZVpa1bI8MFijn OTTZsL+3j2xHAVsBulFcNIk/zLAD4fxp5Fa+KJmtWWleqRgKtSRecvoQ+RucrTWM5D+fE1d+ cO+AMcGNu26GAvZFTlcncQbxTT6NRlzVDCqxtmH6QAhK3qsSqMIMl6KpYDhA0gUmuIkmlwUD OTvoDyCpEdZGzDkXlSaLSpMioiwbJGPgaMJLEKwB52lm5uLgQSCypys5CZ6lV6r1SmJFDAsN 2ErKBAsDyg9eO0cL5SSZKCcoVPaxTE9AGahzXFmmUEaFMQPrAQGC3KFHy+HJQT7QfqTzDIYD LNSeeHuIeyMbTfcl3lTVaFq2wvBwIRV8RU5KDsFPsUtKbCVEI11ARckBeQF/TuMl8uAcz9Lg OYrx4eALthT7fblNM3/lDIj6wkhtFQzdbwBruG3RyaHA2sDuQzoNf8V2cCkqSijrxN47ORdE 43E7EvjNxc2aQYLheBoC/CEoGBf1SDCZFsTwELDN3XkAuMMiVklUYxW9q+WgnflLeYRsuCR3 DRLCG3k8icLq3Jd0hW84vXrZu4opvvbZB9CEK4moYDt61S/n2s69pYiq8GeJ8QD3UovwCuFN defheMY79NmBpeCxTdoV4p0AoNWLtgkEk7vSwFJpxp73g+c22Xj0KLwLOIke8HZNBrtQrZYh S6BmLzJA+FacXuxJ2d4zOb2qRpjGHPpAGknOMxqO1LSXGyExAlcMoCyoUlP8ORISNAJWkyKD IDJcCCKyX2oOhiUQFD52tCIsgIwQpwqOFItmuSNBA8qE1JAkPOHsMJF8ZF9N/Tt+QDQhFlfU zSx5NXhL0JGFJScwq3QeJPA9jgGHhkOIKVeZBVmMDGiuCBFYDFBpyPbDe8tkq+cWGMnkitBz MpIMZ4awc0wNvu45M4HjZA7YKyycxU5wWajKlAfNSS+aT4vsSZBWsyyI9CJHpfgRzuj0c08o JrUU2c11AJRY8Y3BQNjq910m152xOpk2IlVHI85XwYVCCFSxJKK8R8NhCYEkmkadZqzqnONp tLxyedayFUqTwryf4EZjQvriItKFxrtjuhYePblGbhPA7MBWcl0VEvIcXJWoQY8OIxsLcVea OoAY86TQTUGRMApmb2+MJcqO0XQ6lMwZlr3AentQqB5NAewQfqG74B7Sh++Fe1egUNGmNioW rLkENivHyEBoVJbIhCmJfURPE4/JQX2ubGYy7Y0t45jP01iOHY9nDbMDGUpsEIQTF+3+zPN5 bpAhDNuEjQaLyjcRzWLiCSmi8wD5mefASTbywHPLvKgLIYsIYYzcgdzmNHrUoUTi7etnuaLq 6qTHFoELGiDs+l4dLF/nTXSwXA3G98tgCvdwl1EeMZfWJlSSg+LKCDhx+J/jTEzP5a6fMd1y 593YqPlbqdDgNU+ohQr1zKVgqPBQXdBjufcHgxLCNKV2jRrgTQVKGCryHHDIEPoT0JfCHT1c XhkM1OPXMT8HBTOZ7CebdnXaxAci/cQZiKwJyP7ajX2A3BCegk2NF4stzw4izWPTDgU25fhS jrAJdAlEWKuoirxNZSFaKFYhy3o6RrQBDHb4VanQxE8mHka+YDHJyGnbSIapkSwZBIraFkUO VYT0leM24X6RYoCSA7a4FCu+lAwKRAy7RJJoQYAR/iseBxJm89kcrkkLCZE3rG+qWu/IFLN4 V+JLy1wpMK/JHFbADxfAjUKVKINWJDdD84m0B5QEjJJk4GmNc8p6czednC12sm0xwF0AHIOe DCAYsOjdeB8OhhCy7gTsbG9vb23B6uKAZJ4cceBZooGkuCTMyK4TLJRCpj6TxCRElkALJQEm mhrLDE9QjVRRYC3YIdM4GJJwrGNkTqDzENFFmAGeCnw+R0JCTJKnQq5So0nTHvJnnoqm9/uT fYCSJEPHS30ukp3dzX6fw9SiSlsBEmyUNpgEwE6pGh22Djx+yC7GmEjgne/FkqOATdUSt69l uyEMYAhbNjj4MZkFXxhYw3XG3FA5EQogm9cQpAYP9uCWpzN9rjroRPe33JGwjEABwYVfAckx U7uBEoKcpAcVnS2Y8Q6GyDW60zgmUARpguMVMy8hMVzUFrP5+5D0VcwHRbXiUTFc8QDfiwwW 9zGXwYRRSz3Zzw7yMPpkHUx8xL5Hted+YjQTYsoqBj3hXTlMDtO0HBV1QLw4WLR6SqhGfxhu 2scR4gFDk7VRGhll3tG1TR2sleRmrwfusJ0g6eAecfCB9gOrzxpGpYKPDdrnj00hapJehsRE ehynop2pes6MBs/EupEOAxnKAIklz4e36lDUD7QUpKnirASYx5VJjAqROrBcHS+4TUmGrIFD fO5BSJgGkP6i9vJgW8Eb4gWABJh5bArEtzAmybq5mQXAZXjOAFEvkm+j0QiKFpkD9x1To0IB KpzrwGQM8KuAKsRsq2UqlwZcBQhJjEfjnKJHWSNW856EcB2oBrwdTkUTBaWoXoW4em10oWjt P68YgyuvQWlRkE2NWiWOykoGqMZq9BoA2OB74zG+4/KRrj4ej0XmT+ai4AeDwcrKqlZKNBrY YLC4yXG6R3Ju2H0fjeaC/VMopgYGc9iC9CwlFuJJFzcQG9FhCd6lS4/9vX1o4sFwgKoyCE29 EVlpfcmZaRELnnLifJt50upY0CKn/6SurugJLAVmE6K1mEypb5vt7uzQzKysroqtKsCfoiAN h+Xt+8L9EhQ2CIaGpW2/13PQP+YKkVI439FvqwVk5BB5q6+oaZw4g6NRPBSEZKQ7TLAm5ZG1 AO+IrPOTq1wNeS+ru6o6mjgKMcgTz7lgAB7H9pyZRS84klQiShzCfRCVMTXjMT0okqjMYoor ahAfRsxyRTngQbJFDySLWLwApCxEU6Zu6osjyzZQwFSWnbAOgiOiCn3uItBjuU7LofrRmcMV YypLXOPSFPgCut2nwBzbIs5vZ0YWwZe5B20XawhaTHyrdO1hxzuKqsVnQ6PSVsvin9CWAJoO e4k3WMWY9RmjuXq6NLPGRYmXScUks2ZfZIT+SdlT9WPJ1blXwMDwV5AbJ8lmEOj0K+r54Mq4 GEVwqQ3Ei2TxjYdCGUQRHcheGLyF3xgC0BBbGQAe/qckM4lKtSSRPXa2YhmGoDkKhBDxmFC9 IOGmJDqGRZtEAhFU1JyTjK0vmsnrulIAyziseW9vT2VKoxpdnc6k9wUoQW1KAtBwVAVAM8M1 9BA/CuTmArvCtLD7JaksQEigTT35jzQGymPbgl9RUT51jupWBKOEDWsZVQvKrytgOugk+/t7 niva39ujg8nP8uouOttQwPGoXlKXqGkYaihTqhA4CYdyzHA0QkBYs2Vq1eWS7lTtFZel5jZ5 hrtiIclkqvsChW1VGbXiECsA2aGQ2m1YKLbTkW9aiOg1XrxfMiRsePyD/u7uDhLAtYQQaYUP JYRu4RD2mXzNe8GZx+ShXBFswPC8JNEfHP7qCEAvroh5TUxvBwow10ICk5Yhee/A91iWileE ZmCDx1pjuG60o33Le9jGR+Jgd9dP0YPROhOrQLA4Uy6p91yM0sKtEDlVU2p6vokxvZimitkp CORYKxzBGp0gXFSK7vB1oOmdsGHnJJ45Yu3ViT/G5FYszHbFEzV/B2TiVkBnTNFXC/opucoh GypUGxyAj4yj96rvYNG76u5GDmFcoCBEJiLJ0+/FzFYEqog6R0zJFKfEr10/YaGrXklZBJtq QX6+UACkHhjv0goeWCbywkOUSkywmABDnZkjxedWz8i2JyIASdM8i74mi+n1tfWB4DViAS+k pJbEitxHiosdDmAcoCQkztaTgBKqVkkRaapAsgIYDEJAXEaDPLBvYzkGeje3lcfaIoOLpnZc bYepsNAJ1wgeTOw22AIaCLHHAVPE5VDQjYo3LzqO5hufxK0Elj6pEqVltWIJGsinCAYDAn0Z KpqRhENpOQcS51C95LggcwZPi1E2gz5cWAehYBgIgk0m+14LmELwWQCN6g3Xol8h/hjGBldY HEf+ME/AZJNW5hRIKMOgk5B+0uCk0qxwzICVh6ROyRERkznHRNEJsTxoPOQtMYOMFAbQg86L IsRnQh26V/8tbmfsDphrqC4g6w1mFn0kTB8VVALPD28F/lcJ4MgL0pW5QwKqIH1w9ASqPoAt dMic7y+6UF+gmMi30Z/oTrHpyB+qzJYHU4YrIXeO8RSQG2MER6ZlW66HIgp8b2/slAUtzA1L KVlW0grGtW5PwuaaobSCUQ96e5FWT8rCPILi+syFodTDTfEnT0DELFf0q2Iq3UEikZbIr+IB TAGMzMCvIbuWY4AIWdn580WNosI2wJR6VlCbYLN1pLeDvTt+WKj6LSK5RACB58tKy12XVnsF CVh0FE8EL8ai5ujKxDXdqVP28KO5d1WMFppEq31l+ACWM34o1XIoS4wZNqoS2jkqrbLS3UpF MS3GAOOCKMSwUbNXEqft4BUTnzuwKqKDmhDpdnC5bzNfhRwSkYQ8NptCIeQcgNtq8qZX4hKk JICMigEBhd0P+qQMA/MCr/7haNi3WmYt7bK4LpwPr7YBMI82Hon4vmx+WMGQ7PTrdDKNKgE4 8pQp2B3/+L3II1QFJUufBKYJBJeyPLjR8oQ1LMNDqiUkyJG9DF8XgINC/B02lhtPBzJPiGqq m2u0DpyisJotGCKqFBUVInWsjTpzuRSxAutVSHYLyWpUBEsd26xJmYuMWoQV4Bh4iMBB0Cek PAAVkaiq8oDA4aAjSQRDiyQrflATQXI2fpso2YbTmUudg8vf6XSyu7NDC3J/fx8aa2V1VRnC pOxDg04irVBCx9diw4KVCkteGTB5ZhNJntFs4+S4HdZbPBs9DwZGfPaBpTK+PWG5odIO5C00 9xPBLLhzNhoOUXhQNbUnsZAhI22HlQaDjJ4gcmawA1CPgbA2uDAcT89HCjcbouvqwZDdM516 /M0rjqHj4XYgzOvkKTC/aJfBoPR4I56Fm5VIH0LQK60Gbhv1c7UqA1jh21tbFXQGwKaAbDQa FHEkYS52NIKKHpHy+oqgWuahYjeP0T/HH+I9LTaA4KFvvEIxymF3AR14YlRSbNlPpwqg95he rBzoUDJ5tBPqWUYyXw7xAZTgimo5QubqMLpPnujpsE9EF+UA7YXBLePgOxPxdUqVO7iM2oj4 PEFqk9UtF4ujlMLhEpFZAMcMfJEbh5NOk+mq0jZMZqWmCpUhAYIV7LZ5rELDT8+mgvYB9RzI TMCXB/0SLNaYSo01mG5DuV4koztufmQ4nO7By5sgxTgjvb8Hc5IT4JMpToIUFzYPvY/lXx5Y cJOKY4ZiX7OfV9VOs4RQEoC2rhLgvji3xe54V/HTgqCDurJAQR1ZMICg01pOYf2BiK8YxcRh w6TFDAnLBI9juUoQBdcckQM8vRFHELxBYiCztEVRsK6MBpSGYI5wXAY2MwamPFviuHCUrOTb qYRhCzoPQkdJ6qpafESpd5lLsk5GSS7Ozu4OE0ysrKgcgY5UbHqNWl1RQhz9Jm+i9uiHeHik aXyd0APal0IFTslIwol1zHw2nUyQc1JOzpSGgyEy//t7eyT2JnT03phuaiTVymCFqISggc6P yncXasmCWjgbvQe6AZxGNNQRFztrETfWEu6FI4eyFXAHbnLFNMEiF4Ozn1h9vUXnODO3t+fH I3zqlb+wmaCnF0p3zckR/H3PBbqycImAVhinJfYRdKXrouQ5y1oQKWKK0IUKnZjPEUtAuA9n gMx1MAtUPr14D4qyNxT4vLbFz4kAVq8zrac2npfW65K4ayxF90gdfoUUciSLKw+ssSqwGjpi PtrBmFWxM3LXcC6lLdGQ3PupGJZVOvslbtmRehblm9udVm79R3SCg1SdLwnh7Twwq4UFkzpu 1rKu6tQpdzRlwAYWnWNCkktSFR3tFf2h5WhhJxLYoX3s8GJE4hBfCsbC0ouo96jYTdI5Qyi7 ol4cF2qW22LvyFjobCL4HDln5I3dQpkbd5wnV91V8jfOheq2HnRMDDNqML3fIm0AQFLnRuL3 KWtBjG0ptNUGOVIRUReMkx0vyBKjuEUGDGEXCaa3iFimPJDw3bd927e94Y1vvOuuOyeMqtdi T4hvjrpIUEs4pWYgCjL8GIciSZbR55w/4BTCABwBpVGI7bEY1QA9kuoC7uIgVS2OIwifnNoO ohwTOBcvKqyBg1hhrJIB4ruQImhAGxvTu7DcHQ7OgkxSLyhn1mRbrvUGQNijGqwWbAjgIZV4 Xag5zVU3J6gcJtybTHE8siYI55ZW5AcTeiZ2A0dNWf0UWmotRVozEdNarC3al6a95UKUgJjy flkBxoQDelw2lIvnjeof+hDkGig9PHz4CI1kbXUNkDyA9IHgQMgLkojEGWk59q4Gw8YyjpBH K6MVDzAg7uqIJ/ZsGuQs7Rmllt11EfqVdypejMNFrHIscgi1erFGXhQM3QItLdgZWrQnGTJe +WwDFE6y5alZLQ9vMqew8TB7Y6hXNUFEH4PahqYO2CK4sLprzEHBQoLA6UDJJXKYgaRUnNpG lFzF1qelBhSOIayDGPyySERIBhpLjWlb51NJOrpLGhkUc4MgQl0x8VveMmJ48tsJQl11OclI lEvkqZO97mkzEJfH7H5uRTKYFk/LmQxETq42D2GBL9DKxVqiXg9xxYQR0vHmt+T2SYwKlkFd KRDPBWksT471Z0zNZTESPknHxVtE93ULjQ9kdl8mkl8mj18y3yqnhJcB5ZHh3knbTO7nS7mu 2gvo8GycETmiMNzrB0jX70JWfHIYnv/sGJitlhJVB172DtMzh6SFKB1JoNLmM880LIZheIyb jokENnoq5bpUjtQsc/YJIywnl6BoMVF8LxJUPP/8829+0YtvvvmFL3/ZS+nz97//jx5/4gn2 umrgG+c0HlJv7MwJpHs+maNujETt3v6+c/QJSUcuDp9eGkYBMwk12UB9Qd05A+H81kR6Uwtt a2sfMT64yBGDonUOFoyZlmQ2Xa/LK4po4QolfEL5iED+GttLUEWVQfmjSuAhleUypT0yZHhe X3v44UOHDuPGaRp9n+OKRdESwzM3IL2vy0boTEBawdzwSMZw5CsDHFGKIrKZeIE0qsl4F9dC RhDu10zS7I3GnXKnFW/CAiOPiuE8QlqI05IYHQrvO0a1u7tDBgVk60h4nlB1tTcek1O4L3oO WRaoMTpec0i2C5CIdcJ4+pX0WUtSThOS5bUagkXkMn8yPvJo0mWZgn4FQSrcylVG59eKpcLI +9nzkyhxpmRkPabkyPqZlBNk/CBiuwPvCZCXGjdjuS/5Y1T+0V2Asz9vcvRhQB8AmquZ2AG1 1Q/QLDn+Al67b3bsWVyRtL4Kil5/jq0tzwsbAX/VGyfLQHBAdGk4N0pQyUEzPS0/aCY13scs 0RtefguwiHYahf5433FY3h8DiahYV+M/kQbzlezHCBVWV/aC7Dgqv/gzDglORaVF/awLEAl0 AnjXSfiQ488VQpHtAa7YZpwarwSsV3eI5J1oCry9T9LJZEEZGalH7tKGV3Ukou/osI4e6vy6 TKKFm1+cu+JAlvs43NidJJy5gFry+Ypz1La0KHuxoYlrrMiRsbjZMoDgM0XcVn0jgtLSKGPa 9oYmgDyB/VaBzmgXYrePDeD3oivJmI04mdS0UlV5aauFhgXIvgxHQ04eSEGlTxEWNC5RDspc BM2RI0defMtLXvziF0Fp4bW1tf2ud70z7gHkyfEGsoB2r+C1MghKkjLauKThNE8t0hzDFnw5 i5iFAG+ZuXxp7GfN+cE5epHACVg0AhrwD4lYn0ELRgRbZYIvGbJfVJmo1TLH/ofKd+mGxh+c q89KbtSSWLVjK0JM8DHVFBFacmT8iUT7NC/y7qoLcpP/OhfCeOu4AR3W9g0xxe/ir870yUrJ EQcqnZbFSbCyQVsR6AYQaVYWRom7nMzFeVKkmekk9CIR1AB/CyW6sMb4r7SGzUobjVbor6qJ ub3IfhasLu8topaNQUI4eTkovZ5ycZs3UTIcxCauYJae9ENh1zarjSyTbxM2xBQJKmYnmRtH cItWZa93nvW0so1ZnnvWXYVWBdeHiDHRS2XVKFkinXM0HG7v7qAWgo0qUy2toCepvbrWiOpq Cy5tFeXWPSfWBaNdC41NFXAx9yY4QHYwgxoMQbONKimURnVdbaz/ldgrpErJyGD2jbLUh2XN SkCQ7QPQDStFeG5LHdS7RPUK5F6rlpLyX3N0wFSFy2QBf/EBU8G+IkxtZ5jZeHryvprN5h20 RdQIkMBGmDuLDVOMmmRBRMceKOLw1fjE9VzoS1VYB6v6QIcK3guEvA+ytDhbsWRhFXMrzTuw MUxUQk4AbOOon6zXl7mxxVxD1VXsv3Ugn1V0eDEXuFUoS3rKmH0/TInVQ7OlTsOe1kWz4kE1 2BlMHKrhxHxLclgTdVu94IbXwaCArtKSkSKL/Z9cYmrXBmM392slqfjJI4ZFJLjunPn0+PEL XkRK60Uvetm3fsvyFP339/02OV7aWolzhdIwjK47Zy+NxBZncZhHsQ/RDxRDZS4LlyvlSrWA zcmaz5SusDy0nU3Y6xf6H3eDoLSspLpcWoINVGPljcRMVtaASEgDsCTcihJJy3FyklyYEBjX MyGVwPOFm4vNz56W9HACukz3fFYiakQ7nHT2yuoFChZNbfcvB0DyvAzallfQVQjVrgxWrGR4 jv5n7C7QPrTWX6kHUIs85dLgIXR8artt1dKSg8VHymPOEhp3ZXVF3IKVtoWVLGDSRqhMkggb n4STWLIIZ0LNxNwUlm927iVGSazwF9kXERVYjkqcZ6XP7hrNDE6Vc0iezaY90fqFxtubDsLw ydo1YRNxnFBuWboczKEV6HYgWPnGZaI4Wi7prszw+N7gDVotiRdLs40HjccEojB+snlZ2SZi G2XENsqRQ4fRZ86bFaBz3mR/n37CxYTfTzppAO+qCjvR9j5MnLxWIAW5U+O9MZeBM+xCFu9s Hlv6qe8iOblKrugSBsRa+TAHdoOf/pKLA8/J38AWASBebM1BZkkWd7Cgw9wn8/mH0zaU2kc6 Zm9vT6azF927KOKwrkxysqobSM8BDzDSPnafyZ0ewbzU/qt3/IqOUXQVXMZG1RV9eldd/sZ0 TRXP4MNAHs7Mi/mC77XkchWu4Q9cuNEW67i6pkIXyD86Pd863Rc7XTE9YNi5Fh4JhKTxEOsI Pa9wcMRSgoR9IdBzhyaCdD146C4XfiJaqGF0i70shI/NU/Ex5Nba0Reod+qCTPR2J1pHbCfh WJ81kKQDPE5CO+T8889/0Ytuufnmm/6nl7/syUTJgw8+dNvv/S4HVUayRSWOTWPYF8wIvWgn x0aRjVf0tF6IRnXwa/S6gM6dSNkvxDdsYbxHzr9dZ/woG+TeBpLqaEKLwkF/wKHFhYcrfA4I RU6Y4Fx5PcyHh75xLcu+juGtIdckdaRKQmlSg+wV9nQWSft7+wOyTkSGgtGnsiUHeCG4Pwpp MuB4Px98I46FP985AhY+KrHqcdfkhNFdVOJw9wsV3FmVechXSrX2sYTQ7JGdD5kNcKw0qOOR 0iV6cCRJPdiIIGENDTdjij+n3xXIDEvS2uQgGOVZNA760MeksdZW18iOUYu7KEfQMW1IvFl0 sNJyLHExa6B9BtwDU3lXqrIZDUfKziIufoHod6P2HB43TRENYwYrRPQWTBYyKege/VTOygil wuyFQrexu7XDjqYJNXhCiMHCx0WE1huuthIvqxFNgdGDaDx8X9qjKhZmLAF6YkCg7iUqbzS6 bA1QpDyqebKoYyfINJRmpG6B+XhoDahNZhXcauuYlxYs7IFrQXehoAiBxIEb5Dov9pQRoVSF XsRQNuoAwJ2IkbDYdjJmB9yRii6aK5XYciv6Xovcx60ujL2RIfwtutvrnHD5uuWBsbv46zKZ hZPYQ6N0/oRBeBQxqKtiuYOz2RFVdOPiMOjmjdvQM1sA6sximN4h71mAqtcWIYzdSNvQouQq 214YkpBQCyvgJxn5Grr9LoStPTYo4azFkFQOZrZ4L7GtcNsr1komEZHw0OKRw4df9GIODx7o aXVev/Krv37q1Gk2S/f2nUqATruxvuH9jl3xtL1OJJETjW1UPHkTan9SVsjcwBurggXdU68r IQYI3WAZQGYeqe2hJ0YqzzwlJpNP5xRUdIGGIhmcRXWSKi00hvLQDSnOJc32aDAs+yWCRe5h wxxhU7rQLsnwALQ3qa0WEuU0J0l9Sp2KIgbZjQQI/V9ye6we+FIioorEnLWvTarPSpO2ghCZ +zrRR5zy8e6YPZK8jzvy9s1SrpAlS5Ix2+FgSPoMgriwPKthO+e++CENgZ7X9QkcrFla177k JfnRI5uXXgIn8QJ54Ie+cOf48Ufv+cIXAU+hORmNRp1u6QfanW7/wf52U0Zg69oKvDR6MOX1 bzRwzYOnaeG+QiWWyswkODQfVmmSZzebaf0DbUi4UHROuOPq9zeQbn10PUZhOCIobVAOcX4x EL2RtHs2+BZC91LiWztktLFtDt1GzwvqHyEZOF49YfEvLO1UiD7LzN7FpE2ZgHGIEE4UQTEw 6HoOGsu9MXhOMcUlXQiKjhOGVnDxkQnAtQdlGW1u1xCLAnlBdS3X1HZ6KMc4FpwnT2JBYnuW K3RMrjt6a9G9KTwa522qgu4vXLNIw6M2EZjW1zdcOUW/J34nelcxT+YyDkP3ry+ntUKogb/i iKl4oSejwccNRw0c0l219ziPrqtDKtydj6rRn6gxviwkuqKGawxp4DkMZL+0VinXDUOmX4xx JVNCC7dvasl70rvJHBXbsaNHX/SSJw0PHvj6+Cc++YYf+AGUPdJOg2B9+cv/wZ/92Z96J3io Upi66MSbGYFo615YcgjuFGQHxLq7KSR5V1ZXFGFhCqyxu8P7ot0V0FKVa0fED7nOSdupa94L 4TifDaQVG5fm4LEOHhgpaQRdj19ySfHqV3XXzJ/+vw+dvAdiC1LymltuOfvsZzkaZuP2z979 iU/SJY5d+LTea25VTZwW2EOy4J7ideie+07+xV9c9Z2vOHvRhfgTje/wHXee+MhHKsn84TvX vPxlZ6+92r96+MGHTn7gj3fHYyhXkp7Pesktuzc830+9cXbzK7/5Xggp+Moo2PrmH3zz1gUX BARP1vurv7n9Qx9CigX8GnTwDe/40fGxo9ZNNK3s7p74tfeMd3dRYXb5c65PL3zhlPuFRjAQ wsD8uI489LX7/uIvzp4+g4bLdBfHnnZhetV3+sOtw2xkoazz8B137T3x2MNf+arrZqyl8y6+ iJ4I1zA0YJjM5re9//GHHvZ0F/28/AU3bH3zczOUOsg56Wx3/+3HcIBHurAYiryArFC2xqr2 dUJeaWn0QHBb4XUtZvEREFwIk7BisOw1DAjESzzrTA+iNXq0XD2z1M4c6S43dpMoxYgHwQgd eoNiOyi28XiMnKWnqD0TFoNAMVvvomzKKNY2XxW7IcsMTCAwh8NRDD510mYm51VbRIHvTkUH o+C5NI/dOeDiwESPfx4P6GiZeLllLQCnjX4djVbiYXBm/LGW0btazFRVng/DWMuALusM2u7k YDjiUryxkDhpe1cdbbfY1mQB2eH6yeN+7cmtvjLajwuJevu8Q65RaH+EHMmtnp1W1buJddhi 6JCL5YgE2PrGhia6jEEVpn20rTLXD4u63GOefuR//Pn/dN0zrs3O5fUbv/GbR44c9Z1DA/6G yy772f/rX62urt522+9qEBI9+mbTQdavTEUBXOBZaP5wLvSjVc3FRtjeMw3lA4KoLcRATuoh b8kPRSUXLPQEfcaVv3I58qjqvHbMoevOFs8pwbdc8IepUZSmovzz3vb2Nie0BOp5IBM0vVYv vqQ+cdKN/VzrArvpHEUkN1luoOb2T/JhWkL381lOn20uurA93eoKyg8qX8NHj6BCWuRyqtdW Z7JWaRhMvk66R4qudEhNlr72CCst8khkaZXDIbKsO5/7fPYPXh6vP7r4YinS4rwOhNq1118/ pssJoZPewpe/eurxx8kkpQtdfcPz926+KVtefKn95MzFF15y66vKD/zJ6SeeoOvS8shMaXXC PSnLvHss/f/ms6/LsuuuvubaL//BH0J5x2XvRPgJ7ot4usiIj9ZWJ9c/W+YnwTYk/X3yIx9J guhRXVjViHYiw5oMzSiD1lAtKwzxnICwwHQCl+HmqUv/YTmss9qRkL55EaVAUFEkS97J1qvZ ajWLXEelLL3s2kK3cUhcsI50dSgnD/ppj1lpmdUWlpnfTEeOx2P3tKzWeL4IFCgtdAQBW6Gq ZjGzNQsSW/ey/4zuVwAuVh1XLGL3ngxo2gZjqm7GZ1mN4U+uq6Lq6gAvgRkJbp/fHfjDWlxF r5fF5NSCNgrwj4gtrCLk0SOV6GKDnEe0BeLgOjDCJ0FkFJ5pxKnEbVSIi3T57AUIxqwTY2xR UpbqnEvD6o7i7KAQuyRY7giDudV53xH4V+A+00vQWqeVyiteVicWN6eGBd4mNIMKami5cSvF H86t7BFj5soe5hKdMyX49tbu7s4/esV3nqvq+sM/+uPbb/+02m6SFScN8ba3vY3+9BM//o7j FxxHoEzhGBKWUZO2QOstRaAqWNybR4gNq1EaUmb7+42ZAq51ZpOpzxL3rRAvyletWxv+Fcu6 64qHEQ14vUoouRZfFE6qeKhMxOAJ/JoJmVwuOA64I2bnV17BZApQq9LH0ox+r73hriJeHIqK MGfxk5FYm5eO/iIr+9QTrrrosOroUekEViv+sKn3WHvp1+mArUOHkoTFpC5AIsbHjrXqhM6w szMcDIVdpSRLU6qYGWf/xY9/fO3M2Xj1vadfSs+kMoOdXkeuuaal7m+acjY/8bd/iznfOHxo fsPz9JYbcyOFjbWDyNg6fOjiF928urqSWcdF97rqJQUWFTy9Tl34tGu+/R+Ci5mc8jaAv2gN 4G73pCLtwptumjAdjBXvZdnpD35oAgS8lGAjPrElkAcvE64qjYI0tnJgkzmEkudQqrP3xmMh h6wdrcoQFfF7tALaohEAyjsPUx2Si9jgSgRczaMwAWslCrALeZMAorFAHwNGkHG0slEP8E5n 6u44RsPho+ZdTQ34XkUQBKAWvCH7A6ilvkAZ8er3BzFFtIhYhnCuYN3amb0oNsd3IxutC+qo CGYz+H9V251Eu5gV0cnpQM19Sm0MVRS8ntky/ZRD1AvnAJI2VXAHTSLYmWcS0s+sw1juqQ7X Ja7ScDorvWqdMCBSlvNVHa/WL78cXfVTGQSj58rSR9WaQqVyrvsj90Xpz4wJ8Xq9J0OapAVM S2sNVfMWylIBrOHftTQy9hIiAC5BaNeR3kIjdn6/v7+zu6P/dnbI3B7vjfftRVuLa3Q4ASTF QKIU6V5oF11xxRU/8sM/dE6qixyR3/qt32IdZHAM+nfjjTd960tfQr+ur6/f+upXl1ZxpdhC JANEFhg3UoEMEH9YaacrKELk5GjLjIKegGeG2ixo5UrETQgYFhU6BoLoKKQ0oEiU4z+UiEmH ME0HQrg4epODmb0eC12x7pG01/Kd6dSdgSgnxysrV37TN5rCq91zsH+a6OppdUTjnlfd4F+j DllSie8N5Gl+Nh/+WrzeZHUExjzI0PWNQxM2aPRCEvpMF199VSrAjSls6yuj+BB3H3tMzW3h UmFydMvRNidOLuSAe71n33yzR5zYALr6qkg0sHL/A5tnzsCOufg5z5nxLmg8Qrz+uS88+B// 82Pvenf1++8/9Ojj8cxnLn/6xnnnoYOa8c+2unzJd9OwMNqV0nfPv+iiFKsOGp1MVTZGfUQT fuF1z6Djo/I+9IU7H773PlVIxsSBWD2MJ6wNhlCSb9ooQq+WajwasGcNaZfRAWQFYk9xD7++ /qks2sQSTS+ZifTPYSyO+usUicIwleZ+pTaIENsUEoA2LA2ALVq09RJ1Qn9aW1vjiumQSrcW xnOwjOLZKSDTXh5LdG20trbucAx8GLP7ndJjl7Qk0B3W0RG2EYUfS8eiD+ThO4fFad+1XhkT N8IW0oOmGQwGsQCrsAJKq1/Sw3yEQPZ5QZQh4NVj6XECsgjKtegM2OHy0Eelu4EezTM6+gMA hx3cZIBLFtFbBGTDPwTg8smCpAdCRVyndvJwMTaI+HVUnLHuOLplMdGVmWOuXNFiN/Vs7foc VUZuDZRUxF8UlhUDQLmRCsfWsSvyYRpmQWTGAi8HFjp8ADlaesqv+Z7vu+SSi89Je733fb9z zz13+/0ief6jP/p2P+D1r/v+D37wg1/+0pdiKSjfZlYXmTScTUq5VFgn5ayqY8RVAozc8Sl5 jZfkCZpwDJdzFsNdqdhllJ1AISoDMYs91JTio9fw3SutTq3m6o1llXpm6PzUeMFcIYa2qDcv 22IrQHAZCrdZFq0pW738iurOuzA2NAOMfwYnxLyZx6/jkOYP/nDriVMxb4ef9OtjkgjcOnv2 6Hi8M1pBvJHciNX19fH2Nr6yduxoIzEx/BVacLBxCGYNsAnTtbWQVUsPfPUE3HfEwaK99bkP fehZz7l+0ut5Wmt4+WXzD38YD+j6W26Z9xc26aO3364rOeX71z3Dv0X/Dn3pK1/88F9Bwp55 9LH9P/+Lo6/7vknwDI5eddXjDz3sob8U0n7NH3xg5/RprN7jV13Z/6bryV3DlEHVHbv66rOP PQaYe2O6v7GAJthBx+PxkWNH0zddH1KKzeru+K4Pfwi0JuxkF/nqyooWdRXKA6BwfPe/ZTNi p/dMIkMloBhcgyJ2a0o3NdPac6SHPWriTPNpMbaGwr5SokIC25F8Tz0tTJkhWwYV2JNFC8mw gI4L2kIDgFXVb3kFcze7PcqHnoLAJXq23l00B3S4HuJIBpPDTVyvTJVBrRAp3+L97HOv3+Lk 2XA4spG0mIZOzAzqcDmJ5Sm0xeKtiJgvlkuwOl6NM1FAJ8FLM+x+KQ5f0QF6+B31hF06f4qy suMeLsMr3JHMWihaWyYNj63z9Vg34AFJ0cAHeHJeShxQlaUvAo/wRmuCAxGWFaibhdJLX9++ +DzRZfEuKPV5W7CVNFiB1Drj+oqSyZXkFTNMShOFIr7KiiiTuhQxuA/L64rLr3jd93/vOamu Bx986P23/Z6rVZRMveK7Xhljj+R+veENb0QBb7JCLh1SpZVPQIvpaCWOp21QDFEJVkCUzjS6 ADRvU5hfTn8l/0xbXMqt8ePOQcpXzTVgUgg/j4aANJqKbuhwcAt2YiC8/AExGTFakAi2ra7a Z6StRg5Kfe1dejE7anU90RCNOQJCAARuN+8uEbyLxisEAB+XMSQ4kT5FPQnoeWzwyCUX0cCA 2lg577waLR1huMjpe+tryJvSgzh20YUTNWP5++tnztBIyG+IZcIQmzz4/f3+nV9qlRC5DseP X3TJJQg9rV55RdTaG48+du9XvsJxoun0kquunKFG1b64dfLERCLbyPFsb26OTt6zQBt/9GjS goeqEyc0JiHGgD564uTjf/pnfSB6nB1I+CwEjAO6KeWk868jS33JjTfuSnzSFdj0ox/jzs6C iaCfk8kU0zgQxCykPJxyUlSj0QjEMc5iU0mcPJJNMKmHGaYoWgAPPcAdvmcrA/IxWliiIDML RboMARbRAVbigvRjjAdLEdID7perGX+ILpTc9/JSP/oKrYc1MWVc4w4Hg2UrPL7BtMAS4gvJ SkZQiubHY3FAcJBj5JRRi+CI2tdb1CWxbHcJdFq5eusIZ0ckHgjWi17UggVvy8wg5ZWzsDoE H16gwxqFYHK+4DVF9QMPMUbtOlE+9x9dZ8ZzHagkMQIvZ1tUnmWsJ4B6W/QxNTxqkcx6OauJ YH2ogZg7UBXHDMWcoYUiT7fEwmr5O7xlHOA002kTVow6TylvO9ctps2gpfS6BomGFFb7KGVG XqgYYvzqCgwe5Bve9KaNjfVz0l6/+uvvOXX6VCyXPnL06E/8+Ds6h33Xd37H82+4AbWiLF5X VzxngOifl1tBXTFDo1Q+IR2F8wOw7qhCtK+kDU9+m6L/BR0OG9YrkWfyYtNVCqomRmODryDr hq8gXqQdjOyi0IX7e1wOxerBdvXu7g44k8BPn6UD6mrJX3nGjS+wBobztvbO2vB1yszDMq64 x6M0BRavq3IMfSPzwP9On81MM7EQWd+AG83Ox/p6ZhqjsSBkduQwY0lW17iw6dBG5hqXxv7E KQTBENTKjKLCReSXP/KRFpFBV+n3LnrWs+iv5x8/vnXpJZmHN0lhk4dtga/hoUMWmmMnaDCd nrzzLkaWhyrsamcnKKm0d/x8MvxhZ7TtjZq20bAhQLOdrc2Vxx5X3iNkydZWFb6Klq1LkUb6 +mXPftbmYk73yFe++sjd9yApC1cDCwxrif34Psck6EOG8gfOT99uTaXBbTRTBagKdE1QD9ho OBiMoMibIrSI9QaM4jwkDkihbqxvrMnzcpChi13lK8FXki5mhRKL6YBT0Zu98Xhq+bBYnw5q eYiRsRwTYYf4nLRar9/vpL48Bus4L3fj4sSSxoKsxogWY3F5RBJwspG38CzURSwA/Ix6ovLc lSfDXAW6FojEhkWRd7y0KNUdAAKdhOhdxAnOzN7FmKGV8DMqmjxi+SNQ0hVJGEcdY4aeLYva zvVf1GQIRbrmjH8CZZYzBXeIRnz0HZrEqbX7UwI0a4jgPCuwgOBru9pDYAFv3IeDJvPIoZfN RxIwGK1ePNshQgRnq++uZBsXRZcx5BjVG7AJ+NYtL3nJra/8znNSXZ/45Kf++I/+yIEGsP1f /ZrvXl8/QAW+6U1vZFkg2CrFMqRQOSD+FvPDzqYeG/TkEIZdoe6EGWznvn96Fp9hSqqC93wy QS/31UhvYjZ+kXLHjfsX3fdKsNoakoFrCt3sxDll+9ClSZORiCdfl/f8jPHNldSQdpEVqAy9 /HLQ1i35WNr8M3+SKEKj5JbcI2bCyJQGEhCWPrsCO9tJA4Psx+Wrq6hD5xMiKpg1vels4+xZ hQStrnpF4MoFxyN0otnlcCtqZkGE2Ei53kTKkujed7a3N07crV9Bw4GLLqSf10gCrIUj7o7v +OjHuD5duLUGrL3aOOpAnEXIR0D1eBMxLMJ6+CVOqs1MinnGqzECdRw5nWhUKmNG45Bx3NlN haqcbIHUVWebXZMX3BBhn6u74699+tMcZh+NeoP+ikA3B+woFF4yj9rkZDGrWorwsN56FlHE F1dWVsg8XV/f4Kp8bTNbg8tD7cWCA4C8VaWFgno/UGZGyOJ8TskZc+AIDoZRKDUiEBCV2d7a Kjj3M4yRIUeBwX9yv3BnZwdoC3YiLdEF94s+H8AHtQuhkoxHJVkmLrrPF/hBfBsCeUHTaKKv cIgc3s+FhhtvSFfBZ4BL4FkoqBkmczMpDWy6IzU6SLeoCxA/8/RT/PVALKKDuUjsR//Htcly 9NIwI3UXMxKdrU6RROdo13MxdtdxuUIPtNz4r4plHw56zilGfIKQtXPSrU7U2LGhsdzPXWz6 SetAWkLM4u2YvJ074ALYjWKxABldJ1ouEzzVQnUbQoXOduoaTifKH1Uhp0Wb+UKxD0qtZLkl z2+DM41EFWmX7Bxfv/7r7yEJDmkARMall176w//4LQce/IIbnn/rq19TmZGoCknCcY74GDCU coiwIajh2G8yglrZQSWkhhRRMYyiFtghaJOgXSqhXLIlm6TFTO3SUBo5awAQY5iI1FbQfEIF VR0VG5CcLowgd1QTCzCMDe2AK9h49LHBXPXZ2UsuOiLoPnHvUggNZu57dZCxmXV5biL1V90k S1LSP5r2Mw89JNkdy1zJqlP367CqjQGppZ1dcbMYdgixxcDxtsyDWxbsPfE4B0vnCmxLZk4J fGMChbd98mR0v7YuvfT4hRcWF1/k+owRLYLvwFrl7RBRS/StySRve+BqjH33zBnoLQ/xnXch h0AVMNICFBUwjPApMzqQD83Rjsa+zuYkc5RIqy1vM5gZETjN9nXf+tLdlZVWfqU0/8Qndza3 JB+cEKZ2Qg2YOAzf7w9AjKk9Tq38yyMuIxHZuuMsqqGKJOXRDI1RMvbzemVLQ5VayptYTuMl YjGIx1UNUlQD6Hzf6JUT2sTL/KeQ1MiMvh2xU+2oEgAaCDl2WPfcmAYGzWVUh1HIE/+gAOYE gelLh9fHKJe7XLhNM+5baJ/X4HpcLSpCRA7NA8vd64K0RwAQvL1PlmDyCwmbTRlpn6L30gEx gh1xWdfwkdapJXdv0VWoe2A+Vg8BO21ux99CrAjzi/6tfofLHp7PUVStEpGa0UaHjd6JwApm tN9yZ0hIfSyloO7J9q1cYC7NruKK9GXRhBwv3ldgWgtJr0Y7ri7gc2B2xbqxdjEVZUeLK0gd TaQKRU81HgCRLfe6173+RjZLz+H1wQ/91Uc/8hH4msxeKsN461vf9nW+8oNvfuPR845pWNUi gY3g/biX4HTCIMjJdF86MykeTxxEaDjoGOfpwDqCw8e4DwGDNZJCOCMysd17Jkab0InVpQYi Zgg5wpSOfPzKwCRGA8gh96X/BVr3IpOR8m7YcACcnszyJc99TsTIRAidgty6MXppc2P4yQaE h4IZievw0QceHLT7PFXke4maOXz0qOd18tNnmp0dUQB80WMXPg0KmFQdVBoUw+kHH5LemMwZ XwUqjdFoBaKZPvzyZz5DWjlq2CtuvHH7+AUegSQ/7/5PfbowC52NreFC2yNax+SdOAuMgk7b bmSaw+uPhmjNw+FYgDKgyxum/tIcZ1MfPX78LOnOCIX/2sOONc1Coz7M6NoFxzef/cw8+QNo Nk7ec/8X7+SmYmIcgIFlNBwh46h5U0kWYNXRfzSA3d0xcqhewC4Bf4OGWeBxiPxr04p4iF+2 lmTzIv4Br8sVVWSk9Nh1tIBb4qwgwVJIVQIySvYxnqMGDMXvRFIcgiszLhVQC2j0Qt74r7QY gMvH5QoLJinpHQdUe/hKB3YID9JZdyFXFwjBmYBj5N4bQBkO/wOA0CGFnuiCz4ATRovfeNId QJgDNwg5Dy/KsfLIDS0nwCJMsQNEj4zDHZyg3k6naqqDHlnO7C1G9pZrqlRJIuoa1WGXJDDk h6WVUWVPqtepDF8uN3bCZvQ6ieCceCQIVNxgiQkzFDZb28Yy4UMD+EJqVOjQIYJVn7eEvJFN kUMzJZgXIZ5pNKn2bQDVhZ3mXEd8zFwtvmPnH3vLD775XB2vX3jnO73fCoMvyvyFN9/89bk5 Lrnk4td89/f+2n/7ZQAfUt5yW0hog+HPPTgnfDtMCjVH6EC68rCd4PFhb51ciXxvlJgOsMBB r78AqpZvZGiiIUyGHktRLkEhW3KGhSrQPjFwbrbvARxywrhzo7AaduwGL9eluxg//FDG+RWp FBZupLIsO4XHaAcl2fuqXPxL+ZpbLzConTBBZJ7ievg//4Lb44MzZydKhJG2DjMdVzbP1s87 5k5btb1dI84mdBIbx4+feYw10JScMw0bNis7u3c98AATw0/HA1E8sdbQARd8tvvuzy443z/e ec71cdDDE3efPXvGKaMa9WNbioxM21+1TLIc5pVhuAfJz6nfR5eyPGsxLng7YOAZ82Zd8dzn 1dc9Y6z1ALy+Nza37vnKV7OImA/X5iDtc64HlUku56NrPPLxjzeWEaks7uLOx0BKmkKFRgWS SZByNbZKaVkAT9QTOkSNcHBEgIO02nnV2NrY3yLjsjA4RlO2LQWkCQ4g7LmFyoF3jUBz/JwI IWElEWmEATh2XeRAyVe2pyIXgWc03N9iK038pMbCPIptFrsugeLOgYviq8EKRyEQn82arcDf Wu4EgjGQMkLKCtgNfB455p2Gw9EcEUnotBpSnDqJfIbWV6iHeFiHaCJ8sYgEhjGj5n6RayZ3 15xryuOKkewj3myZLfXfMi9qDhiJKx7HO0bmQ8eiWL13HdmuYlIN9+B0+jEG6pMVm2w58CYS UiwWu5XLHcjivYDmy33HCK9vFuExFdpE+WyKOawLix+IlqOGJopqF9WhCjhgqSw8CKi90ZmH yInahre+5rvPFSX/7l/6lXvvvXcggsYZNCJK/sler/v+7/393/udre1tErQMl0CPV9QVVuoU ol+XRaVVS2l3LoERthHqvJiJ2h5k/WYRGZXadVx4RReQNerwyUMBp63GVKWLINcPWMCn7C2s BFJjQ0s/oKuTimWFYyCAxnCSk5/7wnU33cRxqqbZPnL4+KWXnPraI20osFnkUFjmg8pcXSV/ 34R4r3545mzG2kvPePl1zzhxxx3DjY09359bWxOB0UMS9TcO0XfXNjbMOZPWmqdPo+4CKw26 J1m7MjbhU0LZ+Oc+9KFveuZ1AbC38Hrii3eA9IEUIU0OSdLGYBSuBeezeSwVojVz+tFHL2ix 8Rnio0mfI1DvCeqhuPWVh0yN7YSvcHpvNj/zwQ81BgdFGEDxll6VSE6kgDuAmFnZ3H5svNcz bsPI0GHmToaetGxMSL+EkGlu0kFwG7j44H+JRVTulnkkUMoHy+hmKf5etiow+piriBApQ/eT LGtJOlDDRz+1m5L4T1Wwkt3UnlqRaCNBGk7ZSrAH9c7ewiIpbId9q3gGoO2HpmycmwOokP5g 0A/Itdh+xcu/vBoauTHhS8wjc2CnmmrZ0ckOIDysYom3MheHYKCnnJwcJHoyyjodKA4cSxHD cp4Jc6b59idyYhEuAaevzR8GXqll0iZninRnMwIXPWzoDqN9Urja83pvUW/zRQaR0oE6salo J3ZHe8KzoHEq8YDdv8YXkVpALaFepZDSjsWyZUQAsDhQk89+PjkWKfAOO0l8wNOj9UljSHT3 vZQ63Xjc6Zjzjp33+teeG0p+e3v7D37/NumJnfsVX/WqW58KQ8fGxvp3f8/3AU4CjTKTsJgD NAAdbLToq+owLAh2o6qtBrmy0nVm3ZVbQwIMIr5aABolj1lhEjggmbc9kwS+OENFFBOuCwfd VCjtMe2gHs5C6zItZQ1W6oLuOXHSwXjnXX2NVIUv8CTp0i9yj992GJEU1O+YbxOCDs+pWDO1 /B3Dw4eZ63KjxUrMdrbHgSkjiToh58xQ+zyi5vSZiCFCS3G3roAFyKztQL5QudwO+tADD937 1a+CFAYtMYHybyESgmlytNHK6grkuFGQBMXeNMPRSPqqu+sG/6zNV9mRcunPf/HM+37n4Xvv 2x2PGyVJ4aRXkhusG+/MnEnja41Gbp539PhVVwhZMxcCiupyvsBkOehG8kElPrGIIvdkpy8O +NV3tYQoy+KS095DuZFKO/gQwA03OjV1VLRlLahe4BIxO8wBfiB6ns+VCxjZNfB6FFbdNfPm EiFhnwnJPYKHnmVwPyzWDifLfbr5niyXWRbaeQr+ltP4IhnpYXDg6Q8kfPIbacFQTDnb5p8A u48wwg4eIlsknm/zLCGFDOG/rEEiLt0dqcBM33M8oePjvZLM+TEcFYK/5rFAOmomRouVvVAH kC+37PI/gcOpA6n0Y4DcN9etJZS0cOrc2Se9HA+egWetOgtiGVoSKXpjWCmOfMXyxhpTluVb 5FoiCp+gMa2GiCIZswPwQ0vC1gtN9LSG3wPFUW3M4ilwyyaDzzX+VAzp97a3v/1AiODXef2n n3/nE088ASwW1POxo0f/1//lJ57i1//yL/8c6HOUwjhRYbL+wk5XSKIGEqGwTseoE5qJimJY kr0HaB65CiASJZ3G9hAn1cR1A184vgVOoIkoLeVItnDN0GBXKlYYtaA9IR1Q7s0vFjAXjcpT BHW3H7jfP59febn4Jakj9gF8PBCsmBvZRNM0XtdFP4ExoVElIchYwCgLaD4/dtQ/eejkPWdO nxpgczZZdeQwsxltbGStV9fMFbOuNImKkBYgjzfrcv/ywc98JiTbWljo+KtfYQahwRDGB6Br C2q3Ucg7ohGN8O6jiq6bVG/wNGexHiBylLS2AnzdC48fEQAkbEFJp8lTMbB9WjiPz2RT3HBD WzqijkdtOixHlxZjaW5MKMtS1CfegMYdyBGkYNVssgZjEa6FXnSe/YpGJ5JVDmlh1hukjpKC FRSZVeQwXsmckv/v7+7sYEE2ARviMRuPyfcWrecqOP3JwjxOu7xN/rpARouAnqtCw2WVlrOZ nxNqTMhHmvF4HPvrWuHQJKLtI4DQHQ/al4JRKBy12GFB6kDtQs3yAmg+cgQ6BDFCzSM8BJ9H ziaE5RxIESEhsTEKfbOlZ1oOJob46QIDo0cIvRzaWZqyhW6WlbPCIw7ZKVjzbpZeZy6Zw3Ie jNA2iSrPwxOesXKizX6F/sheRUHfWhXWFsfNO00GvHvxzBZwmZClVa196GGx+spGHYlScAbK am9ukoXe51ngn00Wf2iytj/Qdddd98rvesU5qa67vvTlP/mTDyBKnhXahPNVr371UywU+633 /vbJEyextxvTNKDY0f5GHq/zLo4cZJTEYa3UBp7l5s6VeO4sQiT9kJXaGz5L3vFLUc6OExNw I4nIftkPXB7aiVjtTUub70tzkAjpJDvXOf69E2Bk36WlR588eOLuZ57d3DpEqiLtGmtUDBIm nLNYJPkVd2V2222PP/xwYYSQcClmXj3NTexZUm+fOr3atKVmzcqIY0Grq1CZK+M93Nrw9JnJ 8fPpo+naGqdbyFhxfr+UxmdOA0k0FbYXMPUhNIr29lBdU5aJ9SMPP3zpfQ9MrroipvrWTp/+ /O2f8W6We3tjZGUacg2PXxAR6klOq5ywAxapR48/bXFaEslaqR3uReUdaDeaxeBq2rrg/Ppl L33G+vrnP/xh51NPpp7zg+Kxom7S3urKpc99zkOf+5zAMir0HAiQSGdkaOCExU5GImR67tbP pJKBvo2iBRFJUkO5p11jmFYmaBS0rQGpG+rAkF8QTASIXQxJL2aEbwokSmdSTzavFaruGC6J IszYeQ1kQIU0stGfIlsaqx5r4CAW2mh00R9iB3ogDlbk7Ahk3w26rgAP0iZEmiaeBNg3IBti WZglXIoIi/fYVQQliEdRiRlf2swrLiFGAj3C6XoIez92Uu4gDyOjfFSQruc6NVcOO4ykGRyQ XC6Q9mhm6NFVxataLLVa/tyRLcsuWkBbBpLggNyLEJoOVz09IfKc5lap3qayZgym4hqXorCQ bh4d9o59jaar8McHsrgbU3ul5RtykW6lLLUFeIyBMmCsgQcdtf3NonBcsGqbrBQrL1klJjY1 iHTP6fWLv/hfmQMwZcCd0ydXXnnlG37g9U/lu1tb2+95z68JAn3uxgPyDYfWN9AGRYjbJ95d SbVUXpC+EaN2jv6B1oE3c4lAAkS7ods9V8HuCW1OG9TfFFZ25g1Q6MuYz5jSWJGOgtyQyYgS dHmk0HQKOMZkuSmJkjG07/4Hs+ufhYuOLro4m807WALIo04dmAOv/TEhoAqgStEvMA80zu3N zQs3t3eOHMKzT+vrNLytwxv4Uv/MGYXAnT2bsfbKJmVx4aXfkNj7bxBcJrfsTuGyQoMovrsi t+R8H/4lLVeoJWlxlT/yqU+tXHVlW4ZM707enVkXyvlYmc7b/uApuZ9WSHkGYD6gul+fTXuW jIJqme6OBbUxLzi95OyO2fR3b3vk/gewVZ/+zOvKG1+wu7piiz7NnnN9/ld/Dem/v7fPTyC1 u0HRjLRytne3pJxAS+Wue8bexz9uve0bLCGhBW6Mo6vbGspSPoNssVUmt87BZkysJzRoL4zJ iN7vS+fonvUS6wnDE/26t7+vjlqpVpQzRPuZsx5/XV2rjJ2nopCQ13wOP8lZNvooXpSH5aID 6IxJsMs1eZEWgljeMaOwzm0x+945jJtxr6x0mi+70NNMR+BRNCdhFqmecAmDF5ZR0LlGdGOC lmRg3CijA+NaMIIsYkNkVxDLGPpOKRhUaSfxFtuGOe9uJ8+10HOsg7P0+KErJ5+IyLSYHcAa mXvZltVp9YB+ccRLx99ynubOqZTjS2RTT3wOPCeAcLwDoZdfwG0HBCgFxuU4TvDQFqJ+Cph1 VejkJg15F0iqFuuO1RFJWbK6V0Qjq5D+ARDRm/XBRaPjv+VbvvWG5z/vXFHyn/g7pg8nAbEn ySH68I1PmaHjl3/lV8+cOdOXstC19TX6yeDAhj0hbsruETApG5eKzl7ZwlsTQF9QXZBZCOzQ MtrdHUsnP54QZdmo6thdRE7SQHWhMlp/4uSFMvbG7KYio2ZS7JW05yTyVRHmrv2pQ9VsylTq PfiZ2y3clSZXXl5HeyJp/SxpiHQQTwe3tJ6jbcDcPY7KTDr3qvOdnVoJobL9o0cuvfrKVmbv jlFO10wmrkgOXfi07PzzHdIz2N3twHeZWGSyrxsBnTtC2HwwGD720MMdB2i6vZUb3VcKwG7V 1sacn4YDJr/fG2MFAlPurVz9nPvjXc0sNt5bLfO+KJBxD3z5y5OPfcy/RVed9PpXPvtZBerw 9EkJ5l77xPLIio9/avq5z7pHR38dr4y4Z6bWY6RFTFYh/J9puTVE0AFt0jGGCrEZUTeNQEhm PflmRjKi1NIipmFIOQ0YWhO4ZVYh/5o0TJRZ+1N4zIj0ki5BvQ0kPig2PGuFPHrsQUjuL6m9 Smh/mQbBuqrihOi+5FZ1Yw2bollPqsslZ2EVJl7KtsznYLjrHsJjyoQtAnllZdXDWl4IaHz8 LSehZP8nPi1ORgUfJsLoXeUgAuccge5RLRO1R7DisqOmrd2s0bH3IdH5XIak+1nwHZDqZ6FV Veca6FpCx8iRtVCPzC0mO7CEVpEttjXxSYf8QsR5RXKbyvBk5oNjrDVDaMPwNttOw8xzbBEM GDJIrnrBRBHYmpMUIwMv1FhBfhYY5bPQf2FhloqWcw+s502lgQicBw0jQGVbpJbYxmXoj73j 7efqeL373e9G+fPAIuk33nTTra/6rqfIiPje3/xNhdvJUK0clYUyxik5KotZN5qysoXVoDUX mANRj28oIKkRgf0ls0TvmWlUNJk/7pn6bQMxdJLrA8dD+yNDdl3DUD15Io32w6U3nFFvFlCm yQImqiJE5NEdbZ45u/HYY8AJMMvtN1xq5EyNM+91HmurvKzajHOElVYU4XbgPSNrmJ3d9CTZ pCxH552vqZ6mmW1uIr84Q2ZLjhkcOjxZW/G2oOmRR1dX18hbQk9RbD0uCWhapBm8qNW1NWYm 3N6aGJWUtzuBhqBlTwaNQ9c40DRbaJVbi/HkNoHIoulgfS03Ugyko6r9iRUYpFzdTwcB5t5R +uETJweLU7d6wQVJMhaex+WnbJHVww9/7b7Pf/7RE3cLsX3yHNj4GdesCyeICyORJA2e4FKG 7+BnNRAJIyQBpTfWgVhw5n4spyh8lRihkL3uzlajUeXU0hIq02lPdEtPDD42p3poV8ZZRno6 RcjQA6DhNN+5psU9msf+8Wi0UoXqY1oGOr09qQArmHcDChLKqRBh5XhCcH/QMcCaxczIqhTO x5ZgWSDO71AUYj1gonD83t5etCFizy0g8tyBMWaJhZRTZNxw9wspq6/TBqzjrnVKgSMvcKy2 Vg/KwBvFMrykE/2TfTG3yu0iQjyggY26aeAdv5bPhmRVTGXNJQnJaB+jBWvpVcRG9tI/Xx+K 7Ci7ifdO+wCyg/Ynk9iru7AQcFO3CS0NSS1uE7fmnNC6rXKdzT2v6/y2umiK1hDOLCyGSi/a ZtBkb3nLD10cij2fyuuXfvlX77/33kJ2W5JA0mg4fPOb3/QUv/5v/++fw2gwwgGpq6o+77zz EIEE64qCGHO1skGTIXOu5i18L7DYeQKsyRrrmFcUIZe7yNtSgYhBM/8MzVb+wCIs5eVHGd3l zHq0N+aaAGienG8Cekf6uqnQue9+y/uk7SOHswN6qRy82r0FGt3vXLgc1XqTym6YIKwFmGkp GZCh6Z13njNfTLY2yeQmDbHz2OMtVG91ZWLN7JlnY16B4ZCWH/IrUD6VGDqcyJFmlcwBPRjS T4iwcLNgcW+81RM4sWCqz4MYYuV65DCNB/1ZWvqojUN1Y+T6TUM++NkzZ5BQXCx0S14GCyVB i6fHQqOtKKCV0bScy8KIaGXO9L/Tn/x0IU3dJl+6yxmv2Gkryouf+1wvSZPSyjIkxQuvD/aH Fjvcd0RhylKbejAhiLps7FYQR7FVIVmoCmacERWy9VnNgSgGzgidjNz2BY4RggJMiW2xjc1P bdAbJdEAU6+JLJjOTV27gUJ6CxYzPV9udiE4HTBzIkmWFgNaIPKghdGIqnOx5hELTqFVVWjQ XEBoe197j9E5wBtn3tnZ3t/fg8IInmIBPF20MDwx5GdzqIUTOGXGGugACEQOY29IXCuqKykm m3UCiR3y90j8IYTZyElKJVasf444C0cohu/nnZA0Qqgcf9jfi0yODkp0VzqS/0NQeqHlAjRT nr8Hizod5EDp5kxfvm/xgN3YKZmcqOXGdURyC7gA1kMyXsxZvlhjAXrdtpFYNY8IImAOoa4g fZDOScbUDpXQE0OykmLPI4ePvPb7v+dcUfLv//3bpAVihfQUuORfcMPzn8rXP/GJT/3NX/81 9ic3maxqstNf8cpXvvXtbwc/oUmLwkFcQBWCIH+meZdCmmxltuBS4HpP4IVCn55sgci4qS0p 6JEoCKnG6sDcumafYDKNvWzaqa7m5HYged74o4RhyxmvZoEVyV6P3PUlcREOyGz5enAbIzfi QbeQEDLSUiHpDQ1GY+BE6Oep++5V4S4X3bzyco9lnXnoYVI5K6srm48/PrCNs3nF5d5cjDOR 99/nuwBtvYCu7AmwjWO8KyvOfQcCrYXiNkTham2L5fIR9vvuY496kDQTzuLLrr2WFaoFlDga 5nhXUV+D06dBW2MkWNqczNCGddTuJEGhgQ4yn8s8AjzFQcRsP373PYcfP5XaBs3Z/nXXHDr/ /F54EFkg2m7Ni1DA0CnOFfzFRFvvVK1DAzw9WtPRg8B7fD4RV5WxP4FrA4AOz3jpwRJDRnmG LtEZK7zx3tgNX4eAReWKLCNgXwjhCH88e13JqnSiYkOZzVIAW5FiyDM7MZAjmCrJvTnmQp0H S6YAQxfThILyYIrFAtHjwJqEI5HWGY93HdYQGjcrTSJibB1vJyqISJCBPBZSVqbJeu60OSWH 57eWM2E4v6MQXU22TFGo9+pQy4delrVr1E5/TNjddEmPEGahyWQHguGahmZBy3rABF+1xfZe 8UM/GZNqh0GmYDPDoUaksW06ZxlUmELOJAbETmEPCQa7KzDf+bDOvE1XJy3sIW/A/JxXxjvj efepzIgA6Ik5hSASHZjOH3jjG88VJf/uX/pvp0+dUi52KSs+fOTID775qVIjvutd75LeE7xd STaR6Dl+wfGf+Cfv+K5XfMfV11wrMPeZzT8HQ8E33xf/DDWwGk60Mi8FHRmfoWNWxIRsaZHl tG3saTHI0IAacSJWpBPAK1i5yBHZN1KckuX4YAgBoXQGwimXKS4uBVGpQSf6+uaZM6NHH1vC yrWCtdK+X413UoasbaS+hB+ulfGBKATKVUAcrM/HOzs91r6oTm/9v8FstnnmrFaCV9Vgd9f9 sxaAnrKd02e8+SdA0hBntSkkLEhw6qu8Y3nqTaATrotxwgNjSKQceeKLd/amNjZRQseuvXZt dQ2SmgT6kWPHJgwAabmzmkceZTaTEYrMUuY8+TInqMf36sDCaIW1MNnsMxUR3o4mpSxgF2mp 7N95p/cJpdOSYX/sOd/kBnEndlIEij/kukIxaJsIQXijw7kMzhGuVZAIP9KQQCqBtz7WZgAy A3MNxygTv1clTlTVTZgmer9FkTQu+vsoVdb1b2kC+NaIH+KTtbU11N1zUePMLPIGsbi+l4I1 ZjEnqw9obXoRBY0VRzt/SoxSSHps1U0xhxQ6qsCrp5EJy0OcHzFDL+GNdUcxWwTyX3rF+uAI FzwQyg6dBI3jxVsdhGH05w5idCpAop85x3wMicaseIxpej9mBAbxzyp/ZqHeK49n0EaOVnYg dVerw2HbE6sfOkPSXCP1BUFWmpZCnNdzoU2oHtcOHZH5ODR/A24V+V8vC3WBRmsL4QI3+SOf 9MKsGSDeo4WRhz6apU2oS0D/YqR26KJPv+yy17/2+85JdXHK6rd+08tZIGyeOkPH+//wA5/5 zGcy48nuS4+MW1/9GmjQt771R0BpiHpheE59KQXF7gWPHvLntQW1jWg8dQgFAg8cGygIFWK1 OeTBKlIb7UAoIdbCiq/RhRki22cbcnxeaUOmnoc1zOxw8Ys4opvPDDa7556DsyVNM2ufXdJO yoB0izbmjp2NwkeTNUUcjUYplECQwTR65DHXm851Ozh9xun2WSaeOh26ROoVN85unj1zGkt3 Z2eHI6Kw98XWhh/GyanJfsui2ZOEx2JDMsdTAK+4J/2FgfgY3X1P8GeyzWdcc+1LbsFeO3bR hRd/+7dNemUIcKfTJ04wtjNU0TliEEXl7hnDdV4Yh/HnzqU1s7KTJPUmHBpDX3zinnsPwf2y lNuZy75h7ejR2Ei+ZWpXYE7hlFHu0AfbPylslTYaGnoByNCoSYS4SBZI2dnqNagLfqK+SiMo YAEVLTEUv03d34pjM+vrGx7soUkGQGMgRWCFR/CKEpWjsdco7ieWf8D98oJ0VYSy1FGr7mVh Uj9fz8x6A3EUQ1UDtVgybl8kX7xq1t+7RehwDEMYABVcLvd+is00YpsqqyaeiXfV8yYmoKoA ut3hER0OQ+kF6FnzPNYyL3MKP0mGLDd3sCodhugXQxHZ4rXzQBC1ULaMmCYmwrHvDgBVluWq Io0VW3DheGgX1z3s2VRg5eqjXDw3/pXBYrJRzCkxeeyTnhkXil7t9ds0m4CPG+s8CX+c/G6F dVnvrk49mfdX9UZTeZl7UIK+QlYq/uSc6KhZToGdGshxQMPpu//0n/5v5wrW+Ll/9+95kKIU oRovufTSp9jHcmtr+12/8E5YguhjRB9eddVVb/2RH8IBNzz/eS94wY2f++xn81w6CPPptSEQ pso6dfFOLKSLa2bd1GiPFxZAjstdllOCT+Z/TdLgsaelqVWjDEDZeHfcE5CLJgtxmxIqbNuj mGOxJ1zM7YbXosiqDFh4rZA19pMTn779yhtvmCDZHuEOIn2ahTqkBuqnfM2t57EqyoJL2YbI 7v8PPw/DnCVdyhsrN27pOehgARxqw0Ma6u54uQMZHQNuPWbH2J2ORiv9vO9MS/Q5GRAT6btN q3Rg7I42n8kqxnJNykqShhtTjVZgitFpn/jiF/tgYDFY/Ob1z37a9d8Iy23L1DZ+PXz3vXc8 8KD2tEsL3FF4P+iBPjFDzUbqxGJTEhApMqNF9iSIC8gNcr+al7zYVRo9s6PPf97ZP/nTiJJ3 KwOqS29cTJMO5luWWSFtSJVHnxbIRCoCk1O4NcqaP2SrgsWRb1sl2+RKRLnE3Eo4wOWWFoBa qNwoLJCIPIWmDAB2kzotLjkQowvHZ8Yr7W6ZQzy8SzI9faQMR6RjqhKdw7QAn0YiQxuISeRS TommxEIsrBxoKsyuPAbrYImLkoXkPVZieRZ9uLm5KTSzjLbrC8Nk3MuApzvRhCXPZh7lQz/J yNgXYX2L7UeqCFCPFcqOqo8cH7WFeTolYn4hVpzSZKXX6cslXoh6Z56j89MFoo7CAZqxdWQs LgaYzRupRUBEjAqOxDTIpaGAP13garytSVt/bkZBYT0RtOQbCMPgZTuAnjZ2T4IJrQbtachF 3YVq3iHvaJuhVLXnHjxAgbBPh9xvIZxiDSGx7W+66eZzRcl/8lO3f/KTHwf/hVIJNBx7fKrl yf/9tx995FGP48NiePuP/mg85p+RQk2ttStp+R6yCPmCctL3YOJoMlVde3t7EVlr+S1tT+wh R2TOHOiBRYJC4Lnh9XOL/yjlsfhhUGNIMRYiC9hosFU0R+ivaeUk6r4QpIWvMODmWIuytNF0 URsltjQPyP3gOmTW/iMPzVV61mgUsMP56TOeMGuf/s6OI99Yqm6eVXxnkPbNqVN6aSZZ5hpY J4GEZNzjnuA1YqQMtEGMYtCPN4vkB25kfW0NDBp0/HDAvsXD99638YU7ltdm3lWlaXV3/NBH P1aWZcQ7tKRQGaMHsZJnEjXlEBz3tGsVfBr0RQconrPxeQ5ss66ZHj1x8sgTp2Oe8vRFT7vw mqvhqXvSy9DRVXLvrdGYoVu9UytIaCw5h9Y/6NfcBPJ4YICTkkj1GEIFHEGtkFfvHFYEVm7Q T7M4QtRRPBjyxsCO6AQcygxXaGAA7yE9yl5beAoqPfqzQ0xjFzGACbFslBGxbqlAPFpOIrEx xQkMF2LgyJiA0t6DTz6L3orTKFdGLgbRCcRo6WNef+a73nhyZq4/0JSxp3RfddB2C+mn2Oiq g7zo8E6B3n4xX1OEKxaetNrd3UWDTU5OddRmjGzG4uVY6YagJEKIzvAUI9TTRX0Ti3gQ+nNg odNtxJgs/gTYKJQQSrIUtBpkJT1Rhh0LG167pUPllvhzc5TNN9pqeYhImg/bBRm4oJxUxiOE sSSQNVmTaXfa+dxXW2M9qJJxpsFCd8Xzv/+zc3a8/t3P/VxjcV3kmW688aan2MfywQcfetc7 /wsgD671X3zLLS9/2UvjYRdffNGtt74GSS+n5Af5BeQRgn6GPFQSKf/6aDTyVHmna4z7Xj21 fhQSkizolwSSjq6GSLYxxHw+nwjWnDHiOztk6TtMvBQpv7/H8A1cDiHlLLXuEfRQruzSvKd3 HnhAgeweuEuKouSwnpbWArgRtKApwoWyX4sZ+kbY39rsOCF0xtnOjuS/NRiwx+zvDcx/B5Xs nz2LFAuX6w6GjD2T3eEzu7qyCr8KVlR/MIDxFAuQOXKYK8MszdV4PAaOSUtrq/lX/vpvhn/z 0SU6qMw0Lif8Dj/xxOaf/fn25ub+ZD8P2PGWFMrewKXDM6q3t4HagIcwX1mFbtvjAczasKDl vUzI6JvpXXdlbZ6R/cLBM58JSkNNjWtCMQPGFT414o2ht726UKhHHDBVLf9DVTIqMllQJW33 U4R27dGcd/UuieqEBJhyzcgLywxNaH3tR3iROiuGJIy/dhqFg8PTIz0ovtIdVM0X2C6SQoRw vFv8YLlzvgBA8/cnk9jdCWLWo19u3+/v73ntk3sUy9miSBtPDhmkPWkXd1oApnCgH/2cTCbI O8SInXMNxi5aHVesqtqwZCflBPXpShSOkxSZVW1ZNMbkOsw1k7f4AjwxgjKA0UCgM8Lz/L17 xNHm8nCitwrFGzc0sFC8R1Gl9UM6AtRmOeeCWj0WUqgkyuetC4FC5tIcsUqUSdPoBtpkSaMw QiyXnmRclDZJe30vgr8bK49tWlmGzz2D0BioGlEL3P73vva158ol/973/Y/777uPphlMg8ID X7/pTU8VJf9rv/4bAOkdEgo+BKl+7MfesXzk//yWN62urrK3pb1d+HEDf2Xs8pVRJRXyWNnx mkwne/t7c6slhKqLHrbVZCCVgHZpWnuYrFuYZxNx6Z5cF5MPBUC3AMkOdAOz+UnKleNjFXZ+ FTn0OC5k5F70NMlQ/upnP8u8TYtkviQEUfPETk8L3Giij5Y6fIImxqVkYgbD/Gv33CPgiMyU H59k+9FHgZ/kCESRP/DVk7FCC/9/6l4GHG4x5l6L2LT5p9BA7O7ucFIBzezVAeUp3NrcWkBt SEWwdCDjCdHmVWAKHfRHwkFzx8c+tv2e39j4/B3oEAbPErd86AtfHH3070787m1bp045fkE3 bPRWpbjbk15o4Th94pRxN/MxO4c3Lnve83TNp+Qul9P0GuZCP3/07rsPP34qeoWb5x/7hm9+ ruApCq+aN/cUyf2263dpTPYW+0n9wSBGPrw6RVPRliEzRyRpTAzdyEIP+0bwRChxgZ5OId1S GOxes2izeUyQN4Yk1IxsURq6O6TPvZZUJI+3rcktzNim0pNS0ce6Y6cARq0q+DDlWkVTLxRN pqW6LoAsUNHk4CCAFdx/wGtvbw+JpIm5tnB5oX4C+LzLjhuP95aQoP3NFnt09TiJO4BKc5BI ZMbwgmioxqnUOqA+2r09nofDhw876iP2BIu/DgaDNhPOgPgcZFGxJs4UW5twQvmwf7HTzcQL uSIGHe9TRFggJeaulWgOBEyQ2IzEyXPTYaAjMzapqXY4DJ1JY7MD/6IH2ZZbMOQWCvfqY/hY sYcCk0L1bDCNZoxpD5x/3vnve997zwlquL29/drXvv7M2TNzIdAEW+4//Pbv+Kl/8c+fWsjx 0z/+Y/9kYk0cAEV71a23/vRP/eSTUSD+h3///+SBtx6GtqN46deV1ZVGODhm0h4Q/njP6qJi lmux4Y4SSMVQhhiMFclWD94C00VCh3aO634gR3ySmWxegM7MZCOVOn0JnjDn22jolc7AU2ii QlagWvR2KjS6hFYArFlDRgGy7C3Z2qcvK4CuC3ohLIZBrw830SuKUFiN2xwNhwC8+WCg2r1D x87ODkw9GuRISA4BXsXMMFdnj6EBZzfPuoBjPIh4bPTdldGKl8Tt7Y3dgfM4AejS11bXUHkN BSk0FtqBAbZjT+ijSskA8dSBtBPiVUj/sIuZnUgyc6X002KnWVxnpmshr13uMfbQcaLCGJvR TY3oYtNA1YllWQR0YhZpkIxZI3Ovq20awry3lcCOKm3mkiubl2sLOGEtVsISXSgRgd9fSR9n jTM5qSY64cliwIeIGI93x4juTictSQJUPjQQW8CDfshTWraimq9J4TmWStu8KTRx1uKEpu0r hm1IEg+tVciyAR/YQLgawCruaLUo4sADEgmGxuNdkP+FLsm1gyOM/GGSW1IgO6ifcNRAkdSi U34XABPFMo+G98zqkFdFMh1AAh0A4k2ZIxmjtGsnL7VpOu0syYroMZUOanWrqgJsLHkfh8oQ Fto7QFJWwBkx6bMsTY6e8fkTPgGIQxuGFoWPBssXcQY6spCbk+RqIXqLVzhCB+7rCAkYZ/pp 3wqpriZj3MtmpcWcofzSbgJNjYuDAhtXhB+WjHLG2LEbbgQsV0SJsMfWGzQtxH6TKg3pr1Im 9EOSb4M5ScxQ/vG6H3jDC1944zk5Xv/lnb94+2c+LQmgxDGF2ezI0aM//dP/YmNj46l8/Wd/ 9t/efffdpYwQD/vYsWM/8zM//WRfv/4bn/2X/98HSSAiKAphJGYE30Cv30tit9Kd4iEWWjzH 08V1YLJ+GO8n7OIWdkgGZ2cRhua8dCONpOL5uKoGxKAwSCFYt1g7ktdKL6Fn7QmzFBw4eu2J RIb148uMXjRId8VEODYYKhpRkgWg65MbR82xUelP9C3eIpUS6OAYktfJ8UHic03FEwIyky7K 5QTylJnuuiyY23em3RJKxlxVli3gmyVxwPdVFqDV5vjnfCYsgg10J/0qCQyert3xLuMPZeSV vIBIpoPBa8UJiOkMe4THmfOZxV5mB24mM08nofslySWbu8DMYDU2RkG5z4SfPbFCKjgTmiJq lGRIuhjPMYFMZTsYNlKAPOMyowqcsPS7UF3wLqMPgYCAv2W2YNIdJC88LO5yKV8HGT2igSmg E4EzlGlMEqQSHSOWO4spk84oS2MmTDHJxaitBOjbtEH+lLVZWF54Oe0myQxVKEzWAs2GiR3R FoXms5KfMEDZrZG1BIsNIIVChudVVnjiM4u28Qw3qopYviUNU8MxTdaLLlklHM6PBcn8gUWJ uZISb5YzWCouA3OIUxG5SHTBQ6Vf6WAOMlcmruU8rmLpq8z32OtjZUoWhh8H70VxCARBLvOj WyYTWnztdSOhF8UKwuZwhhtZsU6uoc0PsZuixkLxlRyc3EfH1aE7aAg4lSw8BTaLI4hKJ0lK ehg/hQLsRZ6Pbs4tBtDgygX6KMQVC+/gidQobAcJtgaAA9121Z4TZh1KuFDFhSaz4PtCTL9B KgveQJ57kSDqRlHF5S45vDSSL8zY3StR4AUzc2i0zXp8oTkDz4K4jxUrB/VZpNwtJlRaJEBs pUIZHzZeywlKQFF6F1966Q//47ecK0r+d/7HbydFAyfwtr3yVbc+xdjjH33gT//ub/+2Z5g6 hDv+XpD92972NkFGsEHtLmYuLHAeu7eCswaFxhx7UU4pWI4NGrcvFoGhWEVwzFJC4Iz7yTyS mQVhoCHIY4A8FYLjUrPNMw3lHzp82CPGTkyAfmAj6WXDHpUUY2qWvlCDTstrqto7DVaVEjFg fZIDhz9xA5fJFA3pYZjDDwMrmDO/YT14rWvs54sUvWdhA9J3jrWXhRaLWKiKG7TGHJubZ1Gi h+ChUFSz4oLqBemJc2+SW0yOF7liyOnCJ0PUgeu3DJoIF4S+znVd4M4wLw1dIn2LeWgERHxK VDGdNh5gLBT74E3Mk7JJJbg1av5L09EU6KbUQm8ak0ENagod4KH+mchcb5UijlGCThXp0VhH lQS0N7xk7wzn2WhaxgBoeHsH+F49C8hjEXprb3+mXsFXieuDp5BLeYmmNuxXZ7vG5CMp656E 1LPWiMOjqkGj61VLhNgufqlV53qJah7ZxuHYIZXhXXaRVQFOJBnphoLxwAob0AxII4HNueVh ELfEMRSessKHwD0g44XYW8xpxZcf4NQWhiEfuGrogCo8XTUL0dc4mOC31QhI9qSvW3TymMQH o0ltHxBozeRoRS6OEQsIhd+wvKF76fOGHRr1pXxmYVbIAVNMBD0V+hNsxgTvp2mY+qFpoK6Q jWwEuIzJZesjV8Onli8KTAgaXnG0YkH0GttyhZWGwKarRE3CxOagKbOesOVLCxp2CtCrvbKn YQcxjpC+xrfEJk4RkV0JEYvmusQWhpUEF008CjZ85Px8kv/jJ3/y8suefk7a62f+z3/50IMP 0k6SxcpuytFjR//1v/qXgxDc/zohx3/9b/7N9tYWCNTpFuhpPP2yy37qJ//51//65Zdf9oU7 7nzkkUfgNPTEoHYjsSjFE9KUPjtPGgMUqDSrJTFdM3HFWIGJXwuP3CkQaX4Y9NEo3y7cC55D KRKCe4dP5Csz+A3sLc3mo9GI7WOBA+JP8AUrMRVpdGhBWaNdiySEKoGrwRiXYtIC9gWcNg8b /P+kvQmcXVWVPXyHN1dVUlWZRxISBIKAYQiDrd2tIN3tvx0ARWzbfwu2DAr2oPZHt5/9te2E IyIgKiKDgCAzttoKKuDAGMYkEBLIUBmrUvOrN957v733Omff815VYSL1w7JS9d59dzhnj2uv hXyag1YhE6FPpFfyrKvPgH5D2sTE7XxATqGanH5gMTCOv1KhP9HSwpJrSHeBbj5Pg5WKuBBc Ke0FE7H6pkSG4gRuuDA5cTeRLlbWnM+IGEk9gbcG1b1cKzcYcBOwjKsCUBR8E585ygZawgVr n7kPvFkMtA/P1G60AGYCaQT9QIetCKMEtjOdBu4A18N5C/twY0gXmrZjRFE6doGbZ/iS27S0 Ey1eQ+LrQNMu7C/P+UFB/LhSZKtirDihZ+pdLqqzSCnOHPcExD2hrAohw62Z6jQ9IHEMnEL5 PtCwWHLIEXnl57JAW/jy7LKhgRnbKTZPBK9DNXFifxJTiRH/xKuL2VPN+ueKhRixSOgxcP8Z 8yWf68IrWbBCbqAZkpHVojlKKExf4GZLoGOJewg0nqSnuK5atYojw8wiq5NkMY8cy1p12C5j zJFKFgpFlDQwNyUZm4dDcdLsB4kDJXXnDiUPRBE4YDE2Pn8UFX3gO/jp+a46M0YVU8ZBPRlb v6EEtwlDGhhiHe72WQwgu6cQRg3vwclBUAfXoDmj5obINHU+THZTRmvWyhFpb30g6I4sHpXy JYf2SzCXXCRkeEIYGjyE9T1N2aJIfrOC5FYUk/EZViRXM3EtAGohAmk+LUpKk2RBp2xGInQW 4tnAmUEUFtkbhIbVxCTmIfnG+nCfvGb8pTMkCyMLTfdjjz/+wgvOOyDX9djjT3z/+98XwAdd OKeJdMR/+ddPHHXk6/fn7Tf88JZf/+oBjuMaTcwt0MWcf8GFRx915B9977Jly+67776G2DWu cckNQaqNQllstx8HaImdBhL6ROw62VCGdtk+Aowh+4KgiXBYT0BiqOlZ0E2E3gyP+gmvPCMV fUCWDaMutjFnAHZXK8gb7gcBO51tZ2enYl8tma8P2jA6ZqVaMbGLLXeTn5Bpmwj9HriiSGJD fFZF6gdGnjjxjIls1KVCI04lm0GREGUfmHsT83JAnZVpJB9xki5s0A5h4dEv5e0henhm0lYM H8TqwECI86GNQBEY7oYxgixRL84v4ucOw2RUfYuUklKQkaHjkEMFHgS3i48vQDgMGCFiKwiE uilqOPTg4CaNsxSnhbhBNmnQsDRCQpgpSkCJiW9wAgp21zohXu87BMEumkbdCdYPR4fCEi3I kZpvUwrfjHYxf6aolhh6e3gOoyrJaZO4KLuRA6mdwhgKNCPEhfPLZIGZ8p6SuOBfieknoMYY JWZFAcsKL4uVAxcIyJgJNSTm0zobknJ0IrACVUuIgpuarPyM7cvgJkSWt5ArByJY7RvURoiP hhQcgndMF5jCskX/WkOXwW13Yd7yKRhCiDCxECkMShwzvJqtFqb8uSjxYeOjawB4hHWpnnxc ZOt7BiOJwqN6DfFPdKoZnBTyaYdQ0Ye70ilpeDi4Oh9D6nC5OIRnJSVt/VCZ37K4Kg2N8Txo 2wv4MCvxDu150HRGVTYQQDAaLkiT4YrFwaAxbnHbIExkkM7C7RRF4ATD80CuoyseJ2BGBZO0 yaE9NuFTaJjnbT1Qi+iXn/o5i81NkMXnCwazhC5XiCaEdINNRciHlo+PJo3UuELsFswz8YVH zc9//vNzZs8+IO9FjmpwkIeByOzBh616/es/9Yl/2U+sx+f++3PCKhujK0OZwYknnfSv/7xf 4st0qjt37dn00kbOqJDjsnXIgope0JjcJeK8BF3SwLcaur7BOAT8RgTUAoT2xWR5EFyH0Q9Q 6/dNewAjX4KGb5hMolY1szIGC+ojkuW0WIJKya1sdmVTN8UHwSkissGyQQ6H5TExUVa3R1cH 90lWA1z7MLLIWelTaBkgr0Kybhhdoyb9HgsMaxJEJWjn4FOYAzefx4uFBK8GIyvtFQ+5KTsw CKrJrcI5F/IF9DkyNsHqYGY8HzQGZjKmkKeLxc6Cy9HmP73YuGGxIkWmMy/63POPUADUqA4r n5YHrgXPFM4Jj9taJR+NHAjAITmAUE6MGMKUCkHLkuCu8s2ULl3qnKw3Ciy/lx4/9WqtriyS G8IEFo1mYGNEWBXce9iyGBU3JC6x+hWTMipIB8k9ewJxq6hANmVTa3/LWBhppiFQNp17o1Lr ow2MiUSs/FhdF7qtSAFDgwNST2DYUDMAGZgGpCZeplgVcMRD9w1eDaESEnfJ2qXSU69nbcE2 YsyRcboodYib57hBOMMSDc4QLbkyNGa4kKOfBuw/HbZU6sDqkNdHFoIAUqEImZMiSHEvAr6l TWVrA6pTX5PlCn8Ihn7EH66EinjlrO+nbBhwpdY5BZpJawlRMzPNlzIWvWPUxhyxlsjFULYp gwHCD9TKmuNPWLxkcUdn18qVK+ksn32GqYmefvpplKEwl6OzRGjJ6kyiS2v25299K/1w9NGr 6bS2bHllfGxs/bp1/fsGMFWO7r9n+R8VmYYsO3bgYXTwiy6+2CVuXbfu+Ycfegg9rXTgwDJl KAnpSSedTKdx0LJlXZ2dW7ZsHR8f27xp08C+AbC18hAJht8sGA8gN7f/AYgt8ELvevfph4Ps YL+/7rnvf7Zt2YI6PgahaKWef97+Zm+XXX4FwxTBpS1IS9pC/3e/Qfb09fGLP/rbhx8aGxsN BBOf8dBpMOC6SDDcyvwG+QYlj0cLoeFByzGxcLgQwT7dpfHxcYbh+exXlbYHwC0lQ8JAXj6X w8gOqxX6phvRjJuirVxAgwGk4GhEIVEw8MioWcgU8Dj4lzWDmUT/jynbBWjHcKxG0wzAJkEe YxJShUF/SHFrIA1i75hwbwMGEXhFYMwizzC/yLaOgVlVLgOIT9ICzsmWY5EtC6bFLmiIsLJm V+RvaLspcyakqmQ+P4YKNgbteTHHgUoHAKxE76LUDTcWjU86FMpoZrkmhrMjF+Ywfssjd3Lh +Fy+51GqTWoI2h1WQASbeKa4sdIH4g4aeoQmFmHfHFpYHbKFoG26yOW1gSlIWkQeQOkS5YQJ ArEjhY5ghbZDqIIGso1qCKtSal+P6g0L72yZ1LTUARybZgLMaIL/kC1bjZZUnVYCNrXpaHoZ qKciPhOiGUN7lthPxGQO3Bq9nkcdcnyQhvCkYMHwbxIDKcQjiD2DBkA3FCvNhU/rbyLL4Iod Rx9H8RbQK2jA42QaFq0X2XEuADcMio2NQj2VzrA8uVZ5MQNuDnFmkYs8RzsKhUQXggGchII1 hDgKBa2mI1MZqJSxehb9K8qDLn0Gnrs6I5cO0GtV0sm4j9abXrC5jT8R76RfHnfc8R/+x/P+ 6rRTZ86cGsn2/Lr19933k9t/fNvOnTtTRnmrONCwcwynnPq2M88449RT3zrlQbZt7/vJT/7n rjvu2LN3r0JCdMWbhx0ZzDqGLQ477LDzPvJh9yBXf+eaP/z+90YmCpNnUhjEX086+eR3vetd bWO8Lobipz//XzmBPS6mXCGtbAVCtgK0cMETQXt43rx55AkOyHUxsdOVV2J3YTY5zIV/9qY3 H3/cMfvz9vUbXvjxrbe695lO5i1vOWXNmuP2/xy6urpOP/PMG6+/Hmh4aNEiIKDNWa1U2Q6G njt5U6lWwT6AWplv2FpTAQsBesWGIFUsLOCg5GOw5/mOxcbsolJRs4IDMHnYV0ZmiVnDi4zE k9veNEqs9D23Zvm8OdlkRTxis0G+hWvj+eNNf+0ru9iqgfI/myUz7SqjFrIFM+GHMgurotSV 2i4TGnsEBL8JFRNJg+RUEWFDzQTXSNc2PsZo+KHBwYzVxajHRk4Q2CJwGLJAYphpS6DxIIaG hiAjGTsThHTrSpkSX4ssQspTS8US7rCOpsAcAz+UF7FgRs+PG8+n3oi7ZVFMz64pqHGKL43f DQMrmW3Y1FL0uey4ifIEcDFwXfD0oUzXJjIjGBqu5FTTUtHqXjr+5Srp8C+PXdjZ7TWWRKPm 8SVePchs8Hp2TMS7h8v0KLOFDNhUKQe2QlMGcZexnABAUSlGg5bE7Gy8Mh5Vwiw6q2f87uFa /Pz2Aaw9cCTyDJ9vKByxr9+0cm6P31waj2G0jB2AH27wuuh8+vaNaqyjUoImqA0pefFOPng2 vzexAqQ+n+3TXnd/NXlxxwA8GW41dK4NkAfDLRi7DA2gDLSHAMdjRogeiu+g2NXl0+aoWXYo dR46LkZGW8lmFY+ugYLEZzUDRwqA9c2o8VcOJvwSk1vqLzCzpQos9JAVJa8tPT2gwilS+xAY IRGlw8cJpBMmBroCPeRM7JDc+pgmc+afQhe/77pfPV365Ve/9o1zz/mH/TTKn/jEJ3/2s596 jnKMISkpFD796c988O//uLY9+bB///d/X7t2LShc9YSVCAOpBuL3j3zk/PPPa/de1157DaJ1 cGgiAJ89e9Z/ffazJ6w5fn+Kchdd9PHnn38e2UYkykwKdTNCujbzo7V41tnv/+ePf+wAueSv veG6a7GRgIyizXXLLTfvJ9Twwo9e9NuHHwZwDpg9Os8f3/7jA52Spq+zzjr7lS2vSFLlJ5pF +QHcP7YrIsEsIBs2hs1Ig0eCoiyKFfp2GBfcumwmCyC4BphcZ2s0IICJUl6xVEIcYMRrZPCo MjHRNWMGGALZq9WqCHIPWzT7jTMaXXFDKQcxzmtHmL3BsPBAf7Jt9wCAi6qjgSdIRztoXs/f do63ElJ4W7zOW5/dns8b5ntktPTied1d75lVd+YPBeo5VtrePxJYH0/Hf9PKeauDUT3m7+ud D23YCorVnOj4hEIrDvOEgxw0b/bZ8yLPa2FZTMkYY88W2PgaN/mddz27ffmi+e+dVXcRnq2d JPiL5Bm/Z28lJtOJ8TiUDSYmJkqlEqhV8Pols2fSfUiSFrO4Lej8yaahrEQq6uHoIc7qKp4+ s9zCIOklP63M3L53GAkTTMrxi7uOjAb1lJ7wZz27c9RODfOHHDZ/5prMSC6J2i8iAduv90LY 88jOCbU/eHZnLvQ6mrX0sF7vI5t3ax1l1ZJ5JxQnuuK6+0D1VJMkGQyLvxn0dwwMAX6C54i4 6sjFs0/IjqXnMzlS9Gf+dvuI7gvfGRM8fH63vLeZJCnfmFsH2hp0Pry71j84DOAickTMp2pR hyFXQjelDIqagUEOHtpvjNBxjCE6LzXZpMoTa4WSmw7rbqQeCIwTlv+oZjtM2oprYRl2m0pt fPBCkNhwHFI68SkDZOnUFyyDS6hYLpfJB7kZuaYoKa+sM63rDuxmVAvOITkM3fRQXZr+/jvf /f5733P6fprCGTO6vvvdq//pn/7ljjtudycQ6euLX7z0jNPfuT8HWbpk8VVXXvnRj33sySef xBC748ADEGTAMx39htXvP/usdup3PxUNCnKc3Yvrmv31b3x91eGH7WdScvnl37z4YnZgDXFg qBgUZHo0rjUp5uJdnRiu9NtuuZn+02WHuXS8MXJqj1rySoyshNR8Lf3aB8/58H76nl/9+sHH Hn0UMOhE2qdRFP3DOef8Ca6Lvt7/gQ986fOfR/EQU5y+qCpSnF4XPD02fJSkWnOU/uK0wXCD miHcMD90P3YFomKLj4BnosNUWtUUQyFHzuQy9KwM8XbDUB2SwaV/YpKXc5Fa/egVi9+aH+FC TOIpu67bQqFf9ETVd8wK7457dw+y3SS3R5uc3JI0V3gxLO4IXT1G6D8v8CtwlnSK5dFx+hkl RGV8RiyPQv/ijszWvXGzZuQnUok/JfyVLgXXBkslrhYKr50C+slhQ6KQ10syyW+BVNC6osT+ nKSkur4jBZOosEaSGALio5Nhr+C9bmXPfZuGTFppFXUxck4Pmh730i5KjzD+ZA/heQu9akom QM8i4WpHw2v4fqkFeMbBik93co9lyWp5Bn4LTbi1ud7r5nS9MRj0EyvnkkwiOkm8Q5tD+UXd D2ylNChKi5BJ6Iq72XFSj1bNirndb80NuyGAwVjYG0g/zIorf9uTuc/r2TM8hkuLJKgl9/Om zJCX+NMFBOwak5H8QTMe2DqKMM63zJyHzZv5xnAokIflp0DldEHS92XJ+IwFxfviGWMT1Ybl asIEbSYwKKSgYXwY1EpZHqhhin5QWiFzF0mhVTqORokX/ERIWXQMV2sMWisCDkuZkiwhjpHy aiMO1IaROjz0jFBI1Akrl1bQmTtu2GQL3N+BpckIFfHLLeFsxqXic5SgY3fWO1VVNMB6WT9t FUJXHNOdmraEh9FnP/f5/Xdd+vXZz/7X4sWLVVSGwvaPXfzx/XRd6gUvueQSJFha9NOLLJfH 6eBHHXXUf//X/zeZxBb2ALMvUAKjF3/2s5/dT9elJ/C5z/333LlzwXfQMKVYQ+EIg66yGulH J3Fox+nNPL9tGERiOGBHxsbHMe0EAV9a6rNmz37fe8/Yz3O76qqrpJduaBXJdfX29p79vrO8 P+nrnX/79uPWrGk0GnkrBB6JBLNvRZbZ2goYMrHtLiSdmP1E34tzqdiIBgZ2Bi4SV4T7Ay4A zyoBZh2WWOlvZcwsVxwjaZ4Q+Q9Kv/hZN+paMzyhMOFZewFGQ5c7Sk0hhdJrZmcxwIQVCP4C KMf3+E2H1c8QxlOWcfCcbqsnnku1eHzfMlum9BCHZCoYmRobY6M2OjZq29eepRLm+hKS/mKx hHms8fFxHDOU+oFA+ZVc3AscTsnADjA4tFP+jBkzBPqUno9zxcaDK98ua/Qk4391yCzuWYaB klKaKQJpLOE+qAQXDpuJmyvndaOM7DttY5nR9vU/vH65N16pVNtY4gSHaOw4sNd4Cj0d+TXZ 0VT12rDhGw59T1XMPG9ZY3j5nBlgSzDc35OQ27EVTOclkaZZnuqNxbakjDfSkji2J8CEPuQf Z3eVKHNy/JbrSVs+bEU0Sj4ysMIIHNsVcifmxt2FpzfQRjnmc7ujyskLOzwrkWoqY9YsCAao DteFpim2A/6JEqJAVVPmw5pwakSWLdYV8oVOipCWhcp8qIrEtvmiI5uxKmFp+Q2UTu5EV2oT rFakSy3vMm64isw2b8Zcf6NarbiMvW5FrY1vxeVubqNcCVRMGaxTOrPc1rizU0ErPjSNIP3z 69Zfe90N9N+27X1Tmv7zL/yoxlzz5sy94LyPTFlm/OUvH7jjznvWrVs/+a/kbM4480x3Xk8l m09922lf/vJXbrjhuimzDRCuqkY4PUU6zpQNobGxMcpjvvO9ax9/4snJf6WDv+Wtb0U5Cyte C0r4p074NiQiE1byrG9fiSIbU/f6ppPUsOOrWu4zTCJR/JHzzt9PcqnvfPeaTS+9xMtXqHXJ r2Sz2fMuuGA/qein/PrgBz8IG9FgJ8TIPW7pW0lJNE54Gh9WTHAiOvsJELAMtJqLSmxDAo4c E9CRsE9Bdla54PBAfRcaKiXQDhnFpRfnGbRRUOKxEw49qDNppCSCvrfR67x2e3zF5sZNe7O7 g5Kbhy3zJg6aP8fc8NDqGkv+N1/Si8CaNjX/SztDZvdJoUztKohgLqT/uuLGqqXzWdCkUGhI YceEfaj1+cZs+5ZcHGycAmflEiiaYYEeDpz3sVv1Sow/U9r7JBkdHa3xsFcy5UNMWnMf/HNl PLpoTk8kPBSYq8bjQxFsflLxvPbD8dB9KUC9AYufTlgmgaaQ/qT7cOii2S5dE2IB309FoRUA fHh3zi3Q0eseT3qv3ZW5dnf2Cb/Xd+DI9PMRhbq1cUw1EUwSHs1Jk4+Sp864pr6D3rjJ77px T/aqlxs37g53Sr6o/oUyoXk9XUDH0OEO687K+aTu9LG4+7t93vd3Zh6Ne9qulM4Hc8coNhwx p0Ru3mV5fsab+bX1Y5dvrNy2L7/TLybWi9Pjo6cwt7vTc7jRM63tz0QG9dj3yFweViy4xVtl Buy1Sy3aLW4BqCloIwH7yXyF+g/Q1RYsEzrMfuTQuqKuaPUhQ2XB1ZQma+nzofXlwv3In7a5 RhUUFRBHCsp3eY1drkXNt1R7K6U/FjOkjj/rtUqtaH1z8tf7zj57SozGFy/9ylVXXlGXqcDv fWfpNddcc8QRq9pe8+53vuMzn/4P/Px/3vGOybaVXNc73/muHTt3ANBx0003n3jimrbXvOc9 Z95x++1oe/7rv37ykJUrFi5c8EfrY2DYTLRqEQbnnjMF/8Vjjz3xsYs+hkzie1H86c98ZjKh +9/8zV/fduut9WZdBaIYPpDJoSntS7OKAWAWiFgtVw3vRmj1q8TEo2FjsDR+03B8CGM05Gme e/65d/zt3+xPQ+6uO+8w6EdhyqCfX3fooZQ/ea/pS2ZZJB30GoY215RMJc1iByxkd+yVq80O AW4gP+MfzLRTVCwWUX5M5MVwRUAMspJFBpSSbNnqVrQa6BtLAhunMBmZWFKyFdy6hXklBmIr vzfT+bP1/ZScdXR0lqv1X+0J3jsvk0vSXbGst3P30Bi2Ry5fogPSdS2b15tjq20SuLof5j2z web5Nd1Uhp610XR5exMnRF/ZFTxrC/QdImTcUnkS8C9klEFCyLByp+4t0x0OO67P6dKtA9mB 0QmlfETbyVIhly0RaGQ4TeSD7hrt2DU4ItCJ/EGzOlcXqj1RxT2PQ2eXHpmoBZ6DB5GUetGc rlwyoc1CClKyMQRKvAUBP76apLylUqnoFZJJqhTpTS7Gm1EfFkRG4tTQXFoN+uvByVhaW/O8 DWH3czvGhGLDX7t9ML+056hkSA87Py6X8oVqgwtHtKUc4W48/QSba342co37rqDjpxv2wlAO jY7/kozYQr6uNCSdkd+1bwQifCu9cdf1bwh6nto6KEW8+Jmdw0U6n3hIH+r8eGJW94yRcab2 p5x+VVDw0uIz98Z+t3kA6dHe4fEHmqWz5qdLkW7p62YV6fda09P5Hy82spwqpOImPeh6KEtL PWAPGspfkYFpMqcYQhWotCiBLCBRWglr62MVCkVbo4vjVFc2aDuZFkZ821rSo6k3cTGlCspo rR630Bu6fJjuG11QYvq5LshQUI8RA3YdZ6Z5H/137LFTKFT97y/uv+zrX6tWKshM+/r6Lr/8 W1OmX2/8sz/D2Zx99vsmv+BrX79s27at4IiifPnSSy+dMv065JBD0MZfufJgyp/2p7UDdiPl v1l1+KrJ7yLf+Z//+Z9ugfXmH/5wyhNQ0SnwwoXSfRF6oRrtH54YFeIo/BLGGm4A6ZGh65Zp M/BXydhcBi0QqOY0mo377rmnr2/HH720a669fnh4BIZ+ojyBeub555//2lyX99WvfFW4CQz5 lqG4DQItiuoPdMkU0EgUlJX5DxHRkIwtSSu3EV7py21JBL4hwN96Yjthbu5luolRStdLWxGu y02b6HunHzm1NW9XM1T1B7ohu/sHdnoFz6le5cME95x+MT4+LtPN1SVdWTf8f65ZMnTyidcb VbpKBa1aQMo9BWv4aW+GfljqTRj18GIpdUXWt+EBR9YXAvVj1DekS69zIEi/7J2JR0aGkRhx MFSpgpIKBByRoxCt36F3zgiaWm39tj3/28/+2MkVvQ4/QoUZs/BZC81fKvdBM7z1cSd+oAvp jauUJiOG4ApnEjvmpr2qtiQuAz0PEkW4q8Spw+HJzp9ZzMZN9y5tKWOIM4JwV99Em3f0F3Z3 pHhFt58kHSDheWl2+Zo88YfuqAdSjzfFtLGJ6i6v6Day8oEpzCyZPVMSLz1R/+VxZlHgiVlh lto+1na3k9kdObiuw5YtyksSGdhW3OYxXploRXOUWalu8jpdupFuv+ki5g2dnhXQKFhtZW0Y q9SRijureBAgG0oBBVNjlpZtcChdHxTtAV+CY9PCGyqEcCqsKy3MUrSxS6KA4/qqwHQo4skU UOg9Of2meNIPkXq1Fk0ZR2hJr9RrFXlBO03KpVItUAUwB2qIVl6kuaTKV5504hRss7958EH1 n1jT99//yylt4vx58+k8Xv/6I5cuWTz5r7fcclOaR2cyG17Y8Ohjj09+2VFHHy2U2Bl/Ujd1 ui9L62g6z6e+7bSp3MAPhoaGIBOOUt7LL78M+HLb19FvWA0ZQM4VoiaEBFFrph1L9gWUr1gr ptJSqaLDAR8ApEZoy4+aXsiIIkcPKLV99Wtff/XrIvd20403MPO60KlBgvKEE07cT5D9dF83 33Lb1q1bIfABLkej4RsbUkcUYE1mZomgxEX5WXCrZLOJEPeBpCexozbQ7uIkVWqPdMLslspl 0/vBYJPg1CF2pbN0nqOqDGEIKJ3ntMsg7Q1ZsTIWEzUBJqwnvrO/GD0CzgLYCFRjFmTSdGow yO+uem79Z/nsLjTYUO6zg+1TrLBc3Dz24IVYw2R9fKdHxYP8dq4lsWKJRotHXs/qrFJI9CfV /opFVkSEYBgCRLo0Wk6dnZ0AofmtZUIMvSLx7erqqtSbe8NSatC9pJSw+AW0rxh2LE+ZnvWC MG3+DfiFbWMN9XiB79N9UMpEI/bo+207zLMtxlWLejO20gjn5RJqhFJF78k61Vef8fF7R6uY EBIMWbh7eKKtHtARGqoRADRSXKWkdBQ4cjnUi121Uis/n1NenmbK/qasGrz1ZuWVu4CPRy5/ e/9I09L+UkywY2jMaWZJmTTrC3dXZkYOk/jmQ+t+ZuueId0g8ECjTdNVxXsVC0NOCLMQutRd TUHt8evEAhawjLdn0AbTFpd2VVyQngs4bGuMgYmCl1epIyeiRGBxFEGlRDDGWQu4zyhpIbwD 3J7qpCgcva0CqYgKdSvuNRqVUav8AuC+BouKcFavhhPW7C0zXalNUzwXWzJl2fCpJ5+AqrSD NmlOediVhxxC65+s/+Q/PfLIY5HTmsP+X/vUM5Ph7PPmzXcxKvvlvaxRwAjnIYesmPyazZs2 oSMCFBYWwT33/s/rDlmJPQ9ecP4u8/lGgI42cz7jsPobtM8/fuS88z5y7gH5jM99/kv33ns3 ijlsUCLvoYcefPyJta/iii798le07ABytnpU/7dPffK1uC5y2Ndfdy2CWTqLKplsP8OISuQc YaCINZUdyTi0vEBLQnEjY/UyYiEcYr5UWUsoOfoyMowIUY0fHhDKvJS75kVQmC+wYaTddABr XEQg617gpD/+/AwPtmcEgkVpGL3l3nU7mTxJyE8l9eknZ5Cxwi7kBubO6lkQT6hN2h3nB0bH /U5P06+eMNLhYqANOVNMprTb/vJi8ngQOGNhCji0Q9PAUwVcPEDETfe5o6NTOJ9SmHUK5JM3 GhR+1KyOVRGHQi8GSBDy2oJ3SACrg40G+tn4ey9w4Hn+hM+6CvQUspYLiksjpdL8uAwIJb14 d5LvHx6KuwILrUxm50wg7zUF5hCBXcIwabR58mX5aCOGqICKTNJkiJnapfJcIO/mBO7jPp1w U20lqHjHg1xnXHcQ54lTwvL91h6dWTaJ7wz8eeSSDVohNH73Fy8P/cIO7YhXGDD17TBR+nKW yA6yzWYFgWZsiwflsNAR1RWPybQsdKqFQm8x4yibJvv8fJyU8YiRRdFnjdZjv5jeJfLx2Lks qRzHIGvWGnXdsKoHmNaHqVHbWJmYgHivkTqzevQoGIKOXFL5BO6BwziLFcB3TL9wnaBUEj6z SLXBXPUWR6sPYNpa26yeC5F3MRPOyHkE3l43qXLzLT24ykkC/ajjX2jKuHwXliDey7TVGbWw qHdKXZfOSLd9Pfnkk4plpI+UykY4nXGkvTp//rzJv9+xc5ebRYaGH2WKdvQxq98wXcF92sqh GNfE6Hhm1hw/BV7jd7/9rUp0+1LTo3dd9o2vmwl5K8ADllWuOKt+tPXU6L2DmuHO23989vve e0C4iY9f/NGHH/zN0MgwxjW4vBUWvvrVr976o5unfP1jjz/x6KOPkEtgKyY2i06AvOafhpJ3 MSD9AwOmiya0DkJRkaMUUwetANmwRNchvFFopw7NQJgILzUspwbnauA9k3icWTySVHYLvTSA tpGhcvHQAhqZm8BnSDxyJowt49PHk8BaDDY8C5PKKauW/uL5LSCbJ58HQ48uAlkEtKMmJiZE EljKXN1kUca0XdFfTQZHxgYW9fYmNWv+6i5e2Xx3nNZOvzgrqeXFEi9LJmaUimOjo2SSmMM6 FKarOIGhZShHjotC2gwAsch4eZziaEqxZAVGLaCQIKD8iVkQmfA6mNE1g+2O5P2o6LbQMfnp /1WqFcl+hGWqdXSp6YWmDSyIA8zhHdRbouxF/dBQM2gm/mBQmJ1U4QzmB3U1CxivhJ/TQeBd QQfdB6AwlkSjxXxxTOiejbKQA7IwjUyh7NMd3mDCI5A/8eQ7gHabk5IfdML1MkqFWQ8Ne6+B Izr+Hj+Qb9YpAnTL3rRy7iNbBlnLO6prhGpSZBl9o4iNbnI+8B2gvF9PApenIxYNsM1Jhxd0 eJYHfLzOFkqwAy1nwRl/ZJTc9SCD45W4kCJu6Bzn9XRt3dUPU6PFYZU5NEztmRxKO55VSaSF hhhIJ5qhY8CycLS65Gh2iDuoCxuh9r3Uyam0QpqcyWnhlziUHV42IsuQKcb8lvqwtgkwZGMK PgQ/rx1nNlQYkMdM7adkjVVerjg4vwy1yjQXstTS7kfz+TgONlRifK9FKzqy1CzBNL4hEnmU nC1cRi5osjWuH6fdeMghh0z+0549u5X7RLJRfjCvvLx5yuMgQDjnnHNSNy50LBS8XP3tqyeD CS1omOOv3t7e6Y7pWS04xVPonQLyomFvHzsqux91kMIAIMUo9+8b+MZl3/zPz3x6/90G7Z93 nXHmD669xrp55ovbvn3bLT8iR/ieKdqEX/s6nSoLoZLJa3rNuLl08ZLzW0lGDvSrr2/Hj265 JZ/NVaKq2eT2hiitAJ4yBgxNYAXRE+l1QasQU8xNz9yWNhnPmDwUF9JkxWeskJ3VDeE96cdA MKPjRRsSQosaaWmfYG/dX5lpwTav9kcWHzV/Yz3362c36dCVWhCQRxighIhuz8n71jhK+5NZ huo7o9wsvwZT1BvXDl26cOueQfBCIdRtqxpujIpHBmWk5muWzbl//TY6YYsxs9UiwxkYh63R a0OI0EodpaoAzX07Yoy+mrygCvVOMoUYEGSbEgcdpQ7hu2okWp60phzgHQ7XwmBWV3FpPOrO EvRVjBQApuzpUdIjm5X1xP8aGtHhKtsBysBmJVXU2XqjyvIFszbv6Dfqmk4sq/5zk9e1yhvG 5R4xu/A72u9eAJEj3zen6dvZ9jz9JUqBLbUkSBKDRYReGt2tJ3eOg3zW/gbbDaJThvTdhYTQ FQ1GGYuvNJ94dDK0ZHlpYz3/zI4hw0AGPJsQ7kDLlEegvJKzkhJKWLkMI0xRDSsF8PtX9gE0 azixQqPSXjBRhzmXhmEbMY1hVCxETLXh3rF8NuTag59O0SBBVGxnnBiFd9W9pNuuCqgIaECk B/+kHgVz6OrwNKYEOZOL1rZ2LwEzqdVcbrqYQEA52O6JNHHbkFVb30tfYHX+PLdK6bayNIYw rsgCiQ3BVRimXGKWclrhi1DjSr0iqjpOcmfmlyUOMg72Qx86V/7kt0aHoXh+dp6Izd/85jdP aRxf3ryJnsWUGQkIJUNb6MTjLJfLk19Jzkn7k4qUBSOqEciYCkFnlmwSrFi5crreGCPoBMbS 09OzcuUhOKvf/ObXbC7FHKTTXV4KpMEy1TyD+xOy8u66885zz/nQAWVCF5z34d/8+oFtW7ZW G01yS1APuvGG69/+N3/VdtPuvvcnL77wgmrmQhDoH84594AUnCd/ffkrXxWRQwP/A8SOqZsa dfVbEPwFv1xiKzCcNvFWD2UQJ8bJJ5YaTl9DTgvavp7IAoE9FsRC0uCv4V2s1iGfyO1rqyFr 8FFCIJrN5SgLKZfHH1q/5cg3zDcsG4kBO8xOarMztWOPXfB81PHMzpHhsTK43g2eWEAf9F4G B4WZ+UENzigBFdCWHfQR/bUkKaQwveXdhe397DJ5xrlQEAWQlL6BFsmuWnBk0djmgzKcl9CV ZoxXTstjLGInSSGQY3QJ5Ieg2jU+Pg5L5bUSbZzZWwtm0f4q2mFqFGO5LXHF5rKIX7jDsEZn BLAaWhjHLp11mD/msFgkQ2Hphe170XfMemkDb0FQ823mUfPDrXuYMHNf3fNzSK34hUu7sq8E gbI4onLo+0rC5O2oxKsK5pBL/CrGyX3fn7wp6QSyBo8gfichb+FLcG1IEdOyEpeMfFcVHTIx fEq+i5CVsnYzXrtt3+HL85Zlw3xwb1w5MVM5Zll2Xdz93J7y8HgZARlH73ASlPClD4offMML DHFUzYyImEqjlA0Yc+vUjZ1h/MRFqJo0MdXpdoegvQ4xHSg2aJIXcJ0iyEhYjjkT+g0yFXQH aHVR9Bwq3b7UyV3xeoAyQIxeS9kL+SM6O7uQgYG1S1M6vNGoGQSGBiy21PVIfdwSnSXTMcmW 55B3eJY7SouHSNeUZcOlekoFzFJIiOSFUTQhyB1NTDV0RgfOlHk8q/EMYTG30SVCoobJypP9 dvfddwJVgoImHLI9+0in4d5wzLFTGsddO3dG0xT9UNFGLgxRomKpNJ2RZXk9Kb8AaK4K7iiV TIubtxq+U/6VTPa82fNOP+M9b//r09pcDlMI/vj2O26/XZnH3N1oPJZNTVBeq9arhWLh0i9/ 5VuXX3ZA/uO8887/1Cc/iYVLFjyTZAb2Ddx62+2uxCUzIl51pU6w8VXXvMMPO/wDf/e+1+K6 Hn9i7e9/9zsTE1kxPcVNaOiXs3O7RSnueULTgKqgyOqkSw1Bom/+xC7N/ElyVggNx02OTCvy SmkweWBjMvB020BlDYQgBrsY9hUlN6C+vX+f9/ZZYQ7dYOQ5Ykp5FjUYO3ZJsMlfuH64ubFv N2M9iqVarWrFX4POYr43TtmGdnuGVHfvaIWxir7huejlQQbm4DGiF3x1kZ3EYtHeZzZvO/no uZ0R7+dZSW3BrJk7BobSoWnuklpEpa128J3Mm94VDE2KB3CbagmYilP0rG+6sB68CGtNpcVG NrtndFe87pw5SrwPFTakZXU/86t9Hq6dSc6KRcz5dBYLgqo3n73LKwYh83buHa8lPSlPRK8f WcrXOlAkSco5wl8v7hg48ZAO8Rx+b1yd2925c2BYhI1Tk83NmChuRPWc745EG7QknBDt6ALL 1jQwMWkLJ2Fs2zOJk/VpwJqVdJM28kPjM0/piPJJZBqBljkslzRX+6Or5yebgjnrhps7BsfA 7kYOibdtmj8lRrPKUvHqOlTOs2bSRFEB3dNOc4WpmLixvBLIMuK0mO/rH/RmFto2nakTZgLk o75od9F/2XwuEVlLsAlrZoaHjtEajF4krQVArC7wboCWVzmaUQaUvdtAu8t066MosPmAi+/A WzLuDJklfAJbh2Y7OjTsWS4oL6WkitCK4og2m0FtUGuYbhdNNcZcN6ZOrs5fNaD5UypXne5K paxbp6MxiQYpzDbcpGtf6Lg46OLFiz96wRSI7XXrNmx6eXMYBNNZTwTFiI6Zy6s2dd8LgA6t FpIVqwjfKMcLUXPag1ujPN0xV69effuPbzvvH6dgV1p1+GH/+ZlPf++a7y1asBBQXXgXc3Mj xhnSaZBPBRYI2A36/eOP0dcTB+RC3vKXf37iSSeVOgRQl81Bef3aa77noudv+dGt+wb2GaCR tYD/9m//9hpR8l/72tfS/SkMF8yqLnJTbpaJXUR3O5EAn/4bGxszckGY45ZKY6OZzhXgr4B6 oxJiUYU+j4JJFOzbo8HtQWIYuESLxhTCGWzIbA7/0e9f3L77fwYzA0Hecj74ThcokfncsXfM qLzziEXKrIgqJbnJlfN63EBkXxSC7v2VXXsBLEHGs8A3BRPgu0RPy4RcwMVT0LqxUVAnc+js DqlPtrB9AEJJTqsosC5auqMjo0wWLtIenlUMVzSc2Si+ov5SaL6xxfkcynfJlAAS/af1EU97 M28fyA6MlFVsGvEEPeiDekueMlB53lAcYqph1+BIg4FdBj25wKtqVwbbM/BbcBP0yDZFRW1x rejOaQHNxfRzRS6fsx9nsH90V/P5nG8poWFhshnlI6fl1FTlW69lVMGMhHN/UZbN9v6RByY6 9wVFqEAFhhxSyZt4WPidMyZOW9GriN9cej6JYhFxl0zUL74EJMjo45p3RTGq6C6ukv9m6ee1 vaKjwbgPUA5Klze2jGWvx9QNdgTqh54Vtibbgqpg4hnGDc1m1BpHlvDaJfJXu68TXSCOIWtL e7NarWq+pYkm0jj9QskuJ/ArUNS78Ajl/9XvcHj4vQubsA2moMVRiZYXQI+KNsQZoi7a2TXD hXvwX1nWNWrpvGnxECwgrKIt+H0dAkOXy3aeDedjtVoR91j/xCc/NWVt8Cc//SkeyZSsuP39 /WjIw4cBctMmXpe6IolbMd6rYG709qcDHTIZhFSKp7Pdl19+2auX3ei0L7v8m6jao++idVtw 7jEqrNFEn9aIlDfqX/jCFw7Ui1x44QWs6iumX6fHrrzqam1NXfPd7+JDqxBuD4K/fMtbD4hL fvLX3ff+ZPNLL4G1tmkjlZTmOWv4BvOWcdy3rE5IkvCdQY8O8BehIo8QiMNDDJh3FG0q1Qp5 vgpTDubQWgBnB/4DwSBKo6j7g1AAVgNcl3Bp61/e9r21fb+vdw4G+fYhCYuBPiQZ/8BRC/kS wLorQe7BpcSJ3b3RRqImYGdSSOX44mj5gllaN9Ydqx6io7Nz+3jD+InEOyQjSaeLYEuMuB1d zlh5vCoE8wbKGDVdoK/mXpOJen2nNEV/pUNVJiYUy9euedvqvOhv84PG/BlFkGMBI0Bml6cV 6/Vl+aaWH+kg41EAxQ3ywbsZJ5dYKHxzxaI5waRRHvfzdkykgPWV/kQ2xQYr+YWPrKUV6G9V gIVQTWkYPYeEHpV5UQSNUuflWVop3+qQiRHYtGPv9esGHmnO3Bfkk6TlTqgbWxGNvmN5J0J2 24ZIZ7pBOY/2ocCUcoBKwi3xrRNYPwi1tflgAycWV+NmeWgooCJHc8dLh9cDjaphnbDZdVaE HjGZAmwKldxEuQ/zHlHr4sHCbrLSad0NHOEw8Ev4Cb299VoNv3dh+lb4BrwwCfphGGbQj0Pn SZ9RPp/PaJZseQjB06QEvgC7g4zDZmC1dIhNFgbQj+a08bm+iXiqlg1Vr85g8BWsIbQfTU0D 1aO2EoekTl6vAUiSb17+rfecOQUL4ujo2E/uuSeZHiu4c+fOhrgWFvQTiLOOYkz+wiCwuemJ AUHxUpgGFQkTxpTk2dzygw+eDjTxR038EasOv/if/gVUID4Gj8DF5yAadK4W1nz9hvU33Hjz ATkSSvVOP/NMTHHhIPRZv/7VA489zmncVVddjQCTqxbMLcRXfdFFH3strotcyHe+/e1EkLju 1EQKZoksibWV+PJDM6PtPhQ4JwXd6hiHGdCW49QadQPgtBBQcWNVTJIxqiJnotEURxOaTDeb NTNSgdhcjKBqsPXr5zZ/96md94wU1kZd6Xyulr18QSQeOh+fgl73QoZmpFZ0894RqGfRZ+2L AtcqLyqFXV0z8lKFV71g9RC0JDbv6B8MTf7XlTRWzutWEEViURvG/wmTiJu+e1aFuW3Si75u G8h+ff3YV9eNffn5ka+tH/vSs/sue7FMP3z5uSHRRw3CdnxvYvXJXXvtAX33luzg6iW9niVV 0gc9L1YyDsbCvTIwptNCg3GYuuDEW9KZSawhtt0vC+4XzHrfwOhggPTL64jrS3s7W90qI/JB OsXTDimLoG8MXEvtJ7DtEwj0hu7dcW8vWPdljLWhAS/lCE9s7f/xK5X/meh6Nuip+xnHwZhP XBCX/2I581oxMMQLJjfntOkAohkZyQ/57ol8Lnpy9N4JL+Mmd76oH5OrFVqQPDbsgt6Zk5v9 yHG5cx81TfM+iXUHGcEd6X+b3AhurGHYvSPBCoA+LSfjWjgxN0FxRcaN40m9tadJj2nKCPGY S/KbsarlLvU1sjcFqOtYmHiBVJrLlfJCsiXJHE+YKexWha5MOVE8FrKjNni9Bo5uRTGr+mDu LDQ6b1hLChex82UNl/FexS2/cdk3zzzj3VNzN3ztGzt37SwWS9NlPyyAK3w5vsZ0vhdMU2ZU V6FjEAWZmZjePiemohoGXZ2vCdfwd2ef9aObfrinfy8aJGmCQmciZWdW34lMq4ZD/zi+7gfX vuudf3tA6Pl//vhFv/vtw5iejgWvS7/89lXf9i684Fe/ekDHrehhU0j4ttP+6kBlMNu+brr5 VlYvk7zELUNjR6mdimT2q1Gr+0JJpR3phnIp1dNsCRVgBXbTfguDwA0SlaOomClAnAKqgGZC JVNArxvs8pxvFXIoOTLHfGVCcB8FICkMdl8ex4vbdr0UBPfH8QmvW3pMoUqOxDXsr/fHnpjZ 1T/ITalDlyzIxjULW0sGg8LewZ2ZjIlnKZc6rjtNzBZkjNiVLTGlNjBgLWauYW5p5HrDGmpP C0uBwQIm+gkJlopJvCTQ7ujopCC9LNTDXso50sJrDj+Xy7AkGNiDKtLz80KPST2QwzkokjtH OkYqIs8YJSvn95xQnOiM6mp5VodjT4o59nmirkY/HLJkXo4Zm0zRbF9QGK+OG0Je39s6Wn/D jDQSmCeXha7+1AjkJO7zir2eGflekE9qceIWUVgUG4UyOd9E+3sCW00kE1JO2ENmd3RlEsBR 6EbWYm/dnrJoebCD0NQayWUmm0G+gtqyDvZu6x/eM5L/Q6OxalHv6ly5M264iu6rkuFnS8Vy td7gpK2lKBnqyJosdVqNr5vb1Z2X4TkGVHRQrr5ubzkntFWJ04jD4TU1wRCky52M2KLS4Bpp IcuYz45iqaHTJokd3RXAiJ1LM+aF7AySVxhxWgwNLd/Z3aqhJ1pfdRmWUlCi9pxQgTSvcUT1 8HpFahiyQdFXhlt1lSRt6dJQvwPO6hQJG63OJW7rN6XoAeuxNC/MSKEP8P00yLO1a8/zMu5B VS4MUpjQGWvtdQUKAqH30jJicXFZaldcedV0ruuRRx778W0/guuaru/FItxiK3m4LzRCO9M5 JIA1VBzP/EbSkWkwh6YlKPMxr2bHb/zhLY899mgURSed/Ma/nwoEQU7oz//yLXQ5wI8ldgKM oyGZKEKZS/X9yML27ei7+rvf+9Qn/uWA0PPvee9Z137/GlUkoR/WrV93/vnnozACUTHarp1d Xf/8Tx9/La5r+/a+K751OVrHrg3CB5Eph5CHcS1JrE1slDu4MdY0D8VkVH46QYjHFCRcHyNH puvPbUbWJZzERFcKOkILrZUDzbBAxQxBBJ4+sQ1q34r4Rjaa+8MLW16c0XX2wR1dST1tPZE9 7e7cPbCPXr90Rs736paq0O+Nav/P0bPSvMevurW7BUllTvfMkXKFofAzSpNXFz30tX1DxxwE fgTvdf7E882Sgb0b1t0EE4HoSYQS3nrW94dicGVQsmm9nYfoRwFH8NZ0AkIJH6Px7u4RnDCZ IZYsEOXJTbuHvPk9p+TrzpBsc+mc7pd3DeRslry4I3SbV7Pi6oXLdAqBzscVr/EpWZnRURwc GWsr7OMAKM6sH6geZcdSVnrj67yOtvond4Uy4nucWYcOz5A7G5Zn6XAtzMfLm8O6pzeHMz3D 9Bp7Tgvbt8Pg4GZDrsOv9HIIl0GW/cLukS3ZzLsXtExA09fcrsLzg0NJ0kLgW7KDnCgzZD3O kOh8VkTDmpG/nO2WIN6vJcZtGfZ63geGjgtCr3GQeH4q0YI8rYGWDUQYwpxvvY5KKKDtVPck UhRbHcRBOjESGmFMESCKq7UarBsyJ3emiqIindTU3MXU4WWDgRpKU65cNut2yzgulFIKXQAq ioqBhAMDil1R+C4plJNAm6ExdSWafglnVU0TrLa6tIsl0bksICGVQjh0h7fa/uleCROb5mz3 nvnz2dVd/Z3vTVkwFLDG+ksuuYQz3NB7FYIMHfCGwChfYTJt3wujXQhAXIcMIMCUhUNTtOER yWnt+CX//v/+7//+DA7joYcefOWVlz/z6X+f/LKjjz6avJdqzprJTclUfPsbw2SIAKdYuuG6 697/vrMOCD1/1nvO+MXPf75lyxZDNijQJqUvQ/2NLvn00894LVzy9PXNy6+AvCfuITgpkFly DGvjAxMxNT2ULCAjmxIWWPlzcD/yZHHTIIW4nCti81EGUN0MGmkt1p8nk0yQpPVSBmI5PWcQ ELCJz8oku+ctmt191tyWOdxb9gQv9+3KyhKnJ7JveGRtddaf5xpuPtMle5Ze0BvGUKVK64OJ Sy/e/v2QBb1Pb9nDERhPIDXcUVuk/sPj5d3BgvnxBK2xnBcty9a9KD1yIKtZ9aMjEfoyrQkp lQOS0IpvYDgiM9bL5QRFZpOi5cQOTG4UL/iZHb7XKoslZEoMqxFP/kJf/5tXFi0/LL9ubjGz U1CdgRC1d3uNNiS3TeN8p1GU6FZa0l0cK1fa6iK+xcvQ70fGyrtnd9J94JpHEi0N615Lg8yn iykWihNexs2B8p4ZrnCPrC5EYfHwFmnX0c7qSaupOL9nxukzJ5x2WnDHcM++8QqSWsrpKo3G U/XuN2VavFcn02UUyolbmeTz0dGgYrEI7ooOL02OEyd2aSQtdCNZ1kVKhTxYHyDwe0q0c8u+ gmI9r9qIjSqm2BwN2lw76duJyUwu446KY5gS7GWWJyF0GX80ggwtm6I6DAjcg+eFJ2tzJo5J cfkW0Y5DUbwlinpZWqDMcSNfxlxwYpQ3JyYeyGvVBnPAhzpVHLjzZC64o1WcJdBz1o5d+gLp kraoeYGlUX9ua4EoQb3LOrV06dKbb7l1Otf1/Lr1F1108Y6dO/TBTGdD0cMEGhtGyu17Tw51 1W+5A8ue24JvAW0YEMur5F3rN7xw3733NM2UOAcmt9922/ap1F4WL14YWqJY5b4rioSHL6D/ kqg3wQebDNL3Lvvmtw7IqVD69f4PfIDJgSpV+C1aoyomQr+hfx500EHnvbbx5Mcee+L+X/4C 5Tiz7rO5RGf1aZNYBIdAjXL6GjxNEBYbtIVUJHTAGZ0VlSDBhSAzyOdysTPnyNVFS52uQZJu pyBMO8OhXetogIH5wmWeo2g8FJlBbFp65e6RiTYUA+JTes1Cv2pMoO9OqTq4dStIhffOzhlk rG8ZKdTMwgPRn16phTa94DHn9EMDKdYFAXQp8qL2Ym5g0iIG4VIHmoEEeTHq5ICAYo3pylcN X0hJhSCkEzJJPJGaHySO9FcuSMxAgjy+BbbKp3dB+SAcMkDPIgO9WVkvSmLb/2tRDq4JkxBl k1saWf04Suba8HhFmbSptWoXdyYNt+qFE8il8wL8pCa8zDRMCIn4gFprDJI4Q4rctG8IA2l/ ud7WIwyk/1R37j19dCmuV6pV05EV2DWzSRk/bEavx2PTuqsnRgbHjBYkVVGOjhTQwZ4vVHgk f68HmbGJipaOgGaEQ0psY1iFLBQTn8IrLGRDm7jqdfKWGhiAWC2tmw0l4yKepesEf42GxTo3 FoqHQ2mRjNvM7m6QidNvtI4HiCB6SUo/qO5KQRxYj9BkaaPM0HTNLSd6k1gQlfJD0ZXG0erE GYv/WvUHuC6ckHvjFHaCzUau6/obbjjtbadMl3Vd9NGPbd++Df1IZCfTOTAYem4a2fRQ0C7T JkooCMSWu53Rd43mq5hplI9p1/nTlC4ffPAh4D5M0CFW+zcPPjQl+FAkuJi4GgaIYSb2nNlM V6sQOaWT5EBJEIk//9lPpyQdfpWvd73j/5x00smaeYCXNvQNlVlnR+cFF17wGlHyV155Jcwu APFYi2jaoWvVwu9pwSnA6EMfWW2tO0sHs6gzW5xyOeMQFQHE8x0Ger7RTI2pUwcDOBjMW3ji EJY13F06H+pkKrO6OrDxdFEVchk1ZXAqtSihOOO4w1bkk7hdKMnyySYKVXReMD+oAaSOZalg cVqmdG6J6Luv3znUEMBInLTU1EQcOeXpECFKXiE8+yGs+fa2h86gl2nn0A3s7OxkHik/YAQa yH5CY+mU+Td2hncbLJI5RncVAUctaSmYk6EFBICbXgt6HQWZFk9uNTg9pVvEPxcEPKieZ0Bd 2DKb5vv0e+6lhcFLA2ULnGnfwpD7otPeV2vpC2Tj5uJZXa5BKOVzPc2K61lHjCZBC9xRnz/v br8dlzF7Rgdwj+WJMq46n209bc+rcIswHqhGetdlOCxaKBJcDbEb9LBmdnTYqTjzAaP1pMF1 M3+fiKwl9oFn42h+d4fY1NTXdoUtfMX7/DymzUJBdmD2n3wsfjC4fIUsAm3Y4AcKVHOGM42C TQ1LblM5EoYalkJlHGDGRT2gbKZk0JC7BAwNo8qKKiiPjzfEbbA1i/g1GCCjf4JwHJGohEcN ByjfhOwkVDNdH6ZdN/WyCk6x0SpUnmOrQ9ZUBya88g4KTFl9tS6pLTjPEdmUT0qDX+3hA1z3 35/7/Osn6XjpdNeFF1y4c9dOhA905YnkJdMVD2fPnkPnhAoMXEIw/WQYOwxxh75trrxKkww7 hoIoVKv27Nk95Uv27t1rDLQdgKMTKJcnpht8rjVZiltuTRAHfDeAe0QFWdkzE6lzNsTyXnHF FSfccP0BeZf/+8EPPvzQQzimbeyZ2t1JJ598ylvf8hpR8k899RSvD69p+LFi2zdGl0W9DgWD GUNnQC/ShANL0CV41NhC4ylO2kKeJUDsoo+Jfm2609kMPJmyyEO7wcCWLL6D3V5lwlTGxf70 7R1szO3ORpEW91Z0es85a5XO6OAZWS+ppZojiTdc4R27qOSrQBT9b2vQ8aNn+xoONKvJ0+uz zl/BzBrY6pRLlXLZYXG0Ku5ldqYko5QPjZQrO5IZB/sTaqccdasEVB1Y3iY4sCmv7klX7V4c ZALtU8MVRHcpyKD2wG+PzZZMBYClhoalgo4jJfFNciQpg59Hd4RrlflcuTy+qDTb3Sdb/c4b Ht/c09MbWMlsOsOuUvHv5mh+xpRRnaXiSLnsBJe+70CE6QGNjE/s9HqWsVyW3zLBYKFYtCf6 9o3VF4WqTkl/WlgKdg6BhJ4t0oqevJeMqzAxfcCOsYbOqHi+W9OUz4/iwfFqfWaoCpMsJ52P tghhMYY9yKEs7wg8M/Rtskk6Kl3m1r3D9WVZ8eU+spblPYW+fVz97iixfN3KWUWKBNzq4rZh SZ4yPl1LYzF9TFOX1LIOf/dwmi50lQoHJ6N6J+jweymx9MqR7Gi05USjmUfWsh5rU+CWhapF 7nNpymBS8jmXz6kec7EKrYyGgC9MskILRBAZbCdlO4BZSmEX2CMoV+BdKCqOjY4CLqGJjiqt uOgJN1E2vJHSFSMHBoy6UkVbRKLhTtRYH7+k1ytYUcGHLg+Gg/7IaPdOuoC2RgnXBwyhctq7 qI2WMl0QfPvq7/zVaadOaRbvvOveCy+4YJdQF6KLjuoHNEqmTEHmL1jgZlS8q6dvUKEWHFqJ QnVgr9JXw4anm7J7164pX9Df34+RWDBDY4c8++wzr5L5NQS0jY4RmQNtsBsBKh6Vy0F4kG7C yPDwQw8+eMed9xyQg1mz5rjTzzgDVTgzESwhM13I33/gA6/FdY2Ojl35LVPMVAIInWMVDG0G 9Nh2LqQOol6zdhumCmG8ji3WI38CGTw2qr5FKXkw7NmwBDmIGAJLDWcwUWGgo7gquEemHzQZ 6gJ3xHm3drUyGf/rVYtRriTD+/bXLz0yGG+ZDfCzG7fvpnNbIJyzaSAcheg86W6kzxoaHasZ WWOz6pb2dKSSwSkGwRS90brYWgtblb38tiQuFsOEvDPtq9ucMiUktAkgbBavNzQ8ZLHxkP7E hOS4kQOTT/uIClSjZKhVqt7LJBFyPsrnFgZ1mxGxOR72sl1dM7KS4met9FT/4JDAzQ3igM5r WW9JxnVTlDhGAhguKNNa9K+tXET1vbZCaOJ5jmB8X9DpPp0jo8HXz+tkwpYked2cziOZMjF1 j3uzXZV6wzOkG2BPdC45SQpCFS8Dap4ONRwcjZy4sKPRaKCp9sYlM1clI27XaszP9e0bxUji Nr+EgbtA5E6OTobWHDyvUOTA8YhFvavDMSvrxo91d1CqNlhBmzwxJXYvJR3uTN7h0fCxCztx pXO7O/9ybgCpT0W4vDRYBRBR64QCagtdpD7tMjAAJE6N3YygNIzzoOURWslWNErdhhzqhEmr 3iNm/RWFGIkf0lyHTJoOVrepeXR2drryYM68F5oEIRgxApZN6FCgvLq6dArIGZ0GfsLNi3SS 2NYJQ0WIuMQaBnNo5ZaN9peU2vPKvev2UdXbn3Puh6dDGJKBvuSSf1MnZ8fIyCaaimcSJ1Om R0xCGjVTVsoknjL96uvbASq8YonPrVQqcSLWaIL0b7paI5he3dh/MmwEIDejiVyr5uLcq5PZ 86SFJItwXSYVE9eCyphbKaXnRMbi6quuPPWUtxwQzuLD557zu9/+dt/gPi0K0SeuXLnyNY4n 33zLrUNDQ+CrdaMnbU+6akNu/dBrJdlsEz81GBNaNnVk8M2ixK1YA2Bnb1riecWCpoUFz3gy LAOcT7VcNeRSdcl3fcMrT4tkY9lf1uG5sIsj/LEjDtfbO+YOFdPSeL5ZooU+u3vmrLimnSWy dPvkbH2IG4hXpjyJznyXVziIO+2mS7+sEK2Vc9Ymh6EfFBhYIeQ9//imvpOP7E3Ve/3UsUDV AjUD+l6rVYHnzEhECaOQ2Oge7ICUhZQ6SvBeSavEbaYA+uNQaenp7tJfItvD8O2CSRxpSHFS CR7u7J7u3riqeR59DdSMxkIik3lI+AodhT1BcUmUxgGLMvXnHHiewg+bVkGbjr9u5+BJy/NI rdyEEmraYu38Z4eaK2YYzw7C+jXB0Jr5OGLN5Is2e91QzdPVBILb9oUl30/SYXDURum3m2rZ pVmr4yzvPzwePvwg0EBRTDzcCvzzXog7s5kxLLan9zVW9qAGi2Kpv8YfWrMMEfywykSD8GRD nW4yJSvZcrlMN/zFkeYRM9NqMb3uqHjoqMU8Re35YyJik0YYL4czhyfG4VDBZaRDAqDnhho7 6IAx8mg6wYKhNzmKNN1B11KpTGQtUgOEsagQJgrTCDNYb3U71okaO0O0bMc64/Bi5ywmNp1T dAg4FD0xIYcSfFakrshWUPLWX0RwPEqf4VoMQD/c4pmrWqnyLm1MT4qw58ur1WoymBy67Irq kPUj4XKPO/a46USkKOv61Cf/VQXTEiv/Gkp4Hspn+cHUsEAUoJTeit676ojXT+m9gCgbHx83 XhqT6rLDp0TE08FB2UdHnpiK+RdlD1oBkCvdT/EwBML6IIHUoEgNJ4OuGJwBnS2FtORot+/o ++HNPzogN7N48aLTz3wP8huDnsjltm3bdve9P/mTXRfdw7vvulPdtnZQ3Xl7/OD6MLU+rgoq invuaCSdXhYVdtYGzMCLew6rDXPzRgapaNSGagbQ4XZuDZF2zdRjARlP+6ZiBZ7funtj0uG1 9UDaylXGvnqb/M7fv9hHRztkfk8r2sBjcIdwK+jEDP1MbmwwCn1nIncRiOeZIKqFIQl042b0 sFDYGJXaawUcy/ugF4LrCoUODTKnuCdtjevEiReR7nMfwib6+iDaYeuC2iBzgDm8BjjpvcDt P2UkLiSnKARROtrM/98/zkTJE+UJgFoRKZMNpdzUuQ2srOgATBTW4RmhnJAPXiwUXglmtKm3 pHAyHgny941Xnwl6zDC5l/Ix2lcnyiKywe/evHdEWDYS6TpHIBdpi1bpo1/pHyXf4DAD+157 fTPtPr2cmfnk1gFyHqFUSnfuG37a63ZVZ1qPkJKQbQi6twyMQnmJ8gy6acMTtWf8npQ02TdX Za/B8HvR93KYf3RvDc4+liwSQ64gXqpJuwjVwoYVuQWbKxrPKvgA5E4YmrIELSSNRLWzZQBt 4rqg2qpxNv2zJh16O0ScgXnv7u6GxzJuJjHgF2ROigy0JBU8fUxuuLOzy/A5iWhqq45ztg0A 2Na55NdInRF6Y0Z+zyZOdckFNeHT9/LJCG9VrqenF2xdLAjd0am9PtQxWxplmcy//8d/TJk9 3HX3vZ+0U02hRUPhTqGogiXz5Nqnp0Jt+Lj1UdPID2azuSkxh+WJCUCwoOeGwARCAzxJOlXB EQT7IEJcu3btdOPSBtDhp9ZzxYoVUw5IoUGCUg+aMVwatcBTNO2yUkpKYqP2y7RyEyzzccdt t26bCsr46iPSixcvxqmhKERH++ENN4yOjv1p3uv71143MDDgT4qDUKdSxATSX7eX2zZ1iDE7 I5Qs2G6stgpKBIl9ZdLyRl+VuBupbrJOIOoT0MokxntN6SOJNSnHOdzzfN+6pMs1+X6bAq58 /b4x46cv9mMab07edz3cviA/PF7WwguKLXDPI/XYPVA2iVYsmgMT2waUAIAIS2LHRNxqNk14 BBdVA2lCEoOMGB1T9UZIg1C5Qt8L4Sd9UQCEk/SsTjyIFUzmZIHYoDAGrxJojSw2HeU9f2aY 0J4nazg7nyIJuXwaFMcmKolTrpBJKU7FxpopBxKUFZcvmDXZwOcZVMbclXIaye56kKRcJunt YG4Lpmau0It/u7n/4WZ34pTUHLQI2l3+i2Hv73eMp5pSKWDVVzxOYhNNOvgDW0fWeTMnPYEU OYmvx5OeB/smIkG3A31Ht/fRrUMP1mfoweOpijnr/e6Htw3TBco69IEwY8u2c/z3ca+Fv3pt b0XitTvTcf9IjqIDHiER5g65aWbQllYnIzgEK+fLzZeJ6aZvPZlL/qQAd3wnQwSWIoYNy+Cj UkChD63yv/ghEs5rVVTBTkcbLMc9jxzUwnRjpm02LXfbWWZtiWm2pNTAbUPKLi4fRWAj9BxF ri3yLH9xTnQEXd0WnQDj74rrMB14UQxKh0btF7lEnOgpp77tpJNOmBJh+KlPfkIrrS6XPEJO xNeCZpnC5h5zzGqTq2GaVR48dI3bvjZt2sT4n+5uUJ2C3hBO23PJSVvLkhjzRD7hMt7q1+uP PIpimaywhyGKKZfHIZLW9rVjx04UjhlVU+M+PLypNt40AuJ0k7lvcvhlR0cnfd+xa+f3r/3B ATkbihU++A//4LYr+TT6+m750a1/Ckr+8Sfuu/cexHfuV9OmRGYo2JZSjZ66uGSXXghUrYB7 eBbbrUtQ/Y12raASa5pkYeqrVNxIl3vDMr+hFImUHYms58iE4590h3+2vu+2gexT8YzBMB/4 rtqXt8Gf+Yw38/KNlSe29uP4nHME1dRA+t44Y8SM59aqCy7kpd1DbSrKS7tymipobKQOGBv+ hR0DY37Wm2S8wGpo4twwY6Cb0rpACdFzIB6xHWMC9xh4RkxgkTURqOHLRwHTkqknltQDZA30 l32Nllx0Vlw59qA59PvFSdnNvcaSsGElpuSU5Dyz5LLjrYMTnue53G2LuPOVhpfIbiWByGA6 mN66Zd94OcxZ/ERiWZT9LMJ1riYl9HA37B6+ZV/hGb97d2hm1/ApdT94Nuj5eXXmI7smHLBA Q6sd7qe7RRe6Vw9tGbpnvPNpv3swKDiMWQl8DyVJV22JntoxREfLCvksyAzpZCjpfGbb3pv6 5XyCUuCALet+SOfzs+rM3/eN6ThXW0rx4t6xWwaLz4W9ezIdrTmfR+99OOr5aV9tcJzx9FnG BERmWtm+XSoNPrg5gHVka4zJP4mAc6I2risNewFlHjZKWY4gM7ZsaJg+mkxzk5XZ5MjunTQt sxmPZxWIMOupuCdwDyKp0hQtxe4LrVQmDHXCDCVHGXj13QqN5/Ds1C2a0Q45eFrO0RzJjE5H kVuM8VyiJZhcL1VVTmWhtXSDECy0cwAf+tCHph56/eblCF1BOeE5IqE4MzMZF8RTQiEWLFhg epAWhEb/OPR1U+hYPvfcc2aQXoA3bALqnsINpubaEHMJQAG97IUXX5w8OEyfpf5Vu0FTus+N L21SYx1ZHJ2pcYEbOwy078UxrJAe1S2LI53qLTff9NennXbiiWsOCD1/zz33PPfMM6r13PCb d99119v/5q8PVEz5+utvUEeIDWBmIYJcKmAmILcQA21SA9TMAHgWaHWmqq/ZTJo6GDm7AtTu 23pmrsY5qJbpNywfHEfmTGS1owMamC2W8yPDEKhkgGDFTKz13zkwDDEO5WHBIygUI3XGtEX5 bJveD15qtohleyacQnUFVetEFjzlZF9YazaznV0boe+XDaQt0igawu7ggbzQ7KDvrRtEq49C FoPXisYwKqchKvlRnXJjWHyhc/fg6DcH0waD7LgKlqI5SNzMBTlNv2hD7egf+kZ/2ntj7qik 1gbufWH3yAbrviDIkMmwQ7vxZX4WkTDDSpWgAm0EALVrwluBEtTA0PBlQ8zwQg8arICJx0SL V+8Lctwjj0VFsxzankcYhlzc85LbdtCJsQBohByRr3REzUujaVS5KRd5YkdD+YdqtVreHHYM dK42mI6sWQ5u2xEzzN5YMfIlYwY3xG0kvlc7BoYHxwu/kxChyElGYv/aj1ocaAN9K6fuordH yuVHt9cgLEk3oQIhG06HhkC6qLqsTYMHSSQV43tcqTcf78OKypJ1zuWV2RYKq741MuS5Q3eS 12tVY0HrC0XCifIEVkUW9PZh4LUoTBbAgg2SX7MsAZcDRF5Y62jxF4uMEkD/mIthGO0StCFF 4VEzLV/jJtcEdqjqKsoypds8VvkkqW9ZO5zALWkbgkWjqtXWWa5IG2Pa9HIbEG4y52oFa6Jl TtKlD+FBIutjwS4ciN9Gz3nVqiNOPOH4KfHxv/71r3xLc4ItSveCLr4yMZFIlU/V3B/5wx8m l7yWLln8pje/2ZyuFJROfdvbJttleuNvH34YzQ9MvwLUp52DKSEhdAKUSKE5QS9++OHfTX7N 8ccdu2D+AuQEoRiCJUuWnnDCFA7m2WefVcFvFMHAeW870h5IlZSFAWyqOueL/35w3XUHmjNd cN55mvrg0/v7+6+97sAg+Hff+xNA8D1HvsEELpFR+DRt4aiJ5odSmaQ4oMjcZcOZGwTaxDLK NZYgMbTi5Qre0doX6HBgQdimSNsS/KfwQKoni2I98IpoXgLQH1obrXNpODcTNvkB9yBlnszc McsnZGbSw5SWG9NXECgBDRX+a1gldf1orDfPMmNp5dNkio71Aa2wCuYqLNbSXjd1Hg5z6Hhl WpMJDScQpnywwBKtlFiFjpwDHkM+iroNPFBRGDdAcUu5DgCcCN5DAAsFJpgKJPqeMpGCFYx+ RZfR0VHK2kl5mEioT9Gf5JZHQtwQyoiuisSHpo/OIpaJoyUf6WVmpYuDYg8tAQTarvQGXFdD 8i1ygZZRE7KKiRMtmdoh4yDDAFkjPBYkeJSKk7IZJDEgrIKorPlrYiYa0WRiKAGTz3NxLzSs aZELc9QJFmlfJQ35zsLKOrdUq+H+CBl9oKkipze1uoqhIP2yhIp8jYncUNxkDC9rQFPD6K6f hmi0yJUYHv0UNfRhJpM4UAhzBwx0zuzmcrls+V6adVt18xyyU4VIeKK5iF6SrreiZUpEsdGI m4Qp3M8l+FB4oOuzhXK+rqU+9VUmY7ME8239NuOw2kBlTTe19H06JxRSkHKe/MY3TmkTjzji 8Jde2rjxxRfw3/PPP/vChvWbN2/Cfxs2rH/22afpvws/+jGIGD3wq19PPsgXv/D5ObNn49Tn zZv38YsvmvyaX/3mQY3foa3lMg5IS3xqPg0W0pWInv788EMPTnafM2Z0XXHFFVo6o1vzhS9+ cXJ7r69vx89/9lPDKxGZ6CAvvAmoEYd+igjSjNYIfEcpPuKhB39z5133Hih6/i/+4i2aueOX 991994YXXtx/lPyN11+vEQ3yd4gMabVW28Ipcb5FIbpVbMOPboCyASj/bfDbdFN7LzFDtfQ9 byH42ABmCiTP2s2Jpa80rkuqSxiCxj5MwyxWqgxMWVxyfYgEtnXmsjYmM4dqDfEQn+nODEMj AYPqklsHRjnFJVpEgVGFaFErg2ND4OJaE3WohkpG/PpEhYeOazXTANMRC40nrA6TmWWmQC02 yrEZw0YvZTgAK1KXKegkitNFToLn9yMm5coq4xHXu1rBDELK7mNQXW5VlmnP5Oln0xKNwI/z eVhqqbClZPD4pzVSprWWWCRibEdHtTgG5VzAm8lmsnS71MdkRiJrd3Sobp73FzfSEnIeFh+U iHvG6UXyTFv6ao2maRSRF6gxpS8v6RprgdRkaWXRzPO1iRKahrepVtn5KvAKlSfKYGHHOndn EtCFLQhiQDyuaIULaNCN58DTLL4ZCQrfTFygNrcEhUmuix1bQ3jm2KPEBrthJnBsDUAhM6Ef pOGajeGwFwzjj4SYqiQFVJpvtxL9qVgs4p9SNsu6TIOATuhWhR1zoYMYFNP6nFuQlEg0j+aZ SycPBAfUUvTx2YkuI6cpwqT2S/iCFYfRBlkEUZXNtOy4GZxw3kI2PEGbUhR4zOrVrwWlTR8B EPkvfvGLd7/rHZP9xx133rHhhRfGxsamm8O96cYbPatfbCyD4LAz+UzBm1adEpMpSJ/pLdu3 b/vhTTdfeMF5k30wOd1f3v8rL0ko65oSmXLN96+lFUBPmmIceji+IxmOMpqx7M4IlDDjpSkI ylP0ww3XX3f6u99xQDfw4os+ev/9vzBxn8WUf/vb37n8m1/fn7ff8qNbN2/e3Ib/QYUNyZYS /IN5T1USlA9efZjUxNOOFxJQl74MDiO2YWNqo3XSPjS01kiPcgKFx3QzomCDsRRXgZ/VqQTN QM8nncwNTcVS5gu5XBPVmfGdieBokYuQILaiPiZjC5LYBeym8sdCAQeETtaGPlwf8jlXU0yX dhowro6hHNxVKW+2XDVdWhQZNQx4owYLBRQ8qxDvjhOMC/G8jHPyrD3TEkrJ1LfDPRa4EZuk mUKofAFzWsiobFxPFi1P1rtsm/P5Yh6FOOY98cxtLGaLuCGcRvDNCSF2jKec2KmSDCDd4sBc kKoLlGH/FDIxrRvIe5Oo7ZBvkXOiOxVahnIXI4AcjgnAwoxpB9og21o0JmHiDpGXSAcrSSKj chAkJuUFb70UFJte6EljydNUDJw4iDsjj4eakVxyWiaEO3y3CyE6iKA0i2Q2C+PPZAGYH8sK HyKFClO6czz0JLJSQW0SMNaaG+7NvBXQMtvT92JHOB5RmhnjI6viG1AMNhG/wG8ZeinYZiqA u17soVsPh8oLO2O2p/LzYkumJOOym0BySL7N6LZQtOd4OJcOGFW60Omd1231IoWbWuVl0DbR cymKo60yiocHvzJOc8sF6E9GQYezZ88RIj4fARHP9tfroleSjaTMavp4IYcf//jhf5w7d86f 7L0ef2Lt2iefpI/YtnXroYcefvDBy9peQEZn8aJFBx+8fMq3X/2da+6//5cUgnENocGgnUTE 7vCoeLfEyTvf8c5Fixa24xQee+LRxx4VPG6CrdW3ve/449dMeS0rDl6+YsXBOn7hfj3yyGNf +tKXyPpk5WH6IktKpyGLMqNd7JCBNDWJQBmeS3dSUXPcHxZ7Sj5sdHSUdvfxxx/A2NaMGTPo LU+tXUs3gT4Fj3Prti2rVx8z+aonZ41fvvTS8fGyjMBnItsORbYaWcwPYMh8adm0xEf2FvUQ usPgQTB8ZawF6HPzQKpDtuwT4p/a4pfwmdkA8KG+RS5LROhLycX4yCz3PTmBcGtNYLwMM6HR Nbb5K24CGDLpVuM3BoVP216EDOlQWVBcyiwtUA0Ul/D6iUxgDlwf7id9rM6BCXQiBsyOc46Q kWncq0hibfDgXnFtU/SmaGFEkmrg8kG8DfdGN1AKQlFiJQHpfOgtUmFjFwjDl7HkcrVajfdc lgFgMmGaxQ7PMqIsgcSwMPjR8U18WigyMwh7WRb6C2WYgUefqkI/SCfW2dmJI+OmCSs521Yy EEIFUsPjSCw6EVche4F/Jn+MfaE5IhYDHiiOqfAcsGzjc+2ioifbkB6VJ10itjk81SQwE/gh yUbM0fBwDU7VSCozYF6mD3xxafL05Xtop33oPhYKlCYmCB9D+YrkQQiYnwFlciG5CTaXvHLQ rcBT0z692OKsqSfbvh0tGFnwEa1GAZckoa1i+XYMEQmxL51jPWc6NzYFdsIX54/vsuliVeLO SWoImm8saSjBhgJfCsSq0AlgMWMOQ2nGmMZMLkeNg565PiBRGw6xobCGa0IrxWSJskci+4U7 zjm33dRYq1gtjLynQ0ka5Yvf4vq/CHTRd2iQ0i9wyfqw5DuftKXhCHE0dATdm6NrQH92vwu8 2RaysYKRfmF6AKJnCjsBtQRlJ68l9/JsMY32/xe/+IX1G144gIbN3fd95ctfAuhc9d2ZsgHQ AKi3kRGZXiEFjF4YNd+xc8cXv/TFA0Kc09lecsklmDpCHAT6rbTX5UA2ssIyrMrf2l9FnlyV sUH6zX333nugqPf3n33WrFm9SkiBDOzSSy/dD5T8D/YN7IMsgqnvW00To+2pOFQrrYnLKUmx m7/yZobRt0BBFBi1DaDzW6bMHaZxd5TErkADPB8aQijccz4UGX5SPaAirIAiMQWKMNB0UKs3 iLI5KrTQRM4MREtT1YQb4h4iayn0yJ4l30IZEKq16SiFjENouOo5nFiawJWKpVJHib6jUKm4 EjOLg3qpMP2EYUaTtrpwx6Gwk5fGMMYDeJARTXihi6Qom2IdMDUnrvoa2to2xaebw00aK6iG 50LWFhLJoSgpKykB170p3ZHIJbDc5Fkb2Cr7lC9ZC308UHmgWjdTStpfsA4ssTPARh0ClPMh MMjQPfHhCOk/gHRYfTgIRfuUPHHklP4ati8TtWneA6EO4nZjly0nZWxwCnkZ4zDGTTKlSOj2 ARsJTXuvVgdRsi42H8R9DSNcJ70xBAHci/JFZb6j1AEGQvqUIhlJcBLaGdkmh0Rcqi11dMhp aIXA1+IYBNNZ15XvagyctRhu31bSeEGH9rFKCit8UXGsQG44jMTuPt/KjSI5hi3C2KXi91zU n+foa4PDN7a93pR/QFwd3Y/y+Dg5gqzkWz58FQg+bONflQ7hqFDYwPPicrToOCtWfmKi7M4p 61iYGSbO50WC1oAqVTkTZW0tkAgGniGdsLB5czhZiKDENxT6Dik9GnSv6UtKLgzf8IK9e/d+ /KKLP/eFz5+w5vg/+j7Kuq668oqiWAfkpIkXoxwXyhgZcPPTOk1x7sbcWHTNk088cfq7T//8 F7+wPydw400/uuEH1/b392vqChYJWGHGenWUqoLmgpQJHoZf8wyhi1DbqZYBVhv9kw54zjnn zpk7FyGYawW0ZqKoZEmrGzqf6Hb4N2/e/KEPnUt7BmGO79DO6QF/+/DD2lxBs9qgy8Bs0soq opLKvOU829IPTU8LLcbYS/0WF6y9jIIt2wZvtbiH+9aMMlBEY0OfeKijGe9ODzTy1DkZgKJV m3XFI9g8ZczQGIqWGakMw03yyeZCsjXliXJeyUTsn8hygAOQPp3+2vDRWgsaDmbXFHa8tMTv WwHMFq6a0NATdHV20hH402s870IeiO5JV1fBlGHZr+YghOHbwX+LRTTaPZL5GhNDeTmPbdqO WmdHpzSHjOY4U5LItTC+11LvoDrKh5Ulx066xq49L9M/lhRf4ANNDw4cUjWNpil2BVLFmiiX Q4Et1KO6bP8I7k1pi8mOK5OcfkeiifAZGijyUmdUjm9dIsTB3MTS5JV+znJyaZIeCmDIZ4gf jfj22/dnnYKb5yg32WdBbzdZuOTuNeknZYElkRvmJeYc/LSK5fnCIGUUVn1BQKCZhJKgIMES LVRGluqJ7m3SYHYMEIuYqAhrOInbkPRSVAw1AVLuPiAV08EyQ15s5oxRQSUPR16Q6wQ8/5oF qiW0paZsmDMT644GNLffkkDroikPmSu7JWV89lv5grJyRI6eVmix4mCH4SK/SDPC5CoaEKwx vm2rVioVo8Ksqkb1FHwO0l4Xr+/GJWY7SBKFvhUqgnB+qV2Sm6AkVRl3CbrVRs9ieiKTRHPx 8dHHHqcHRxGbQvvMzxA/jROdaEzs7CRejx/27tmthAt0F/oHBi644IKTT37jKaeeetwxqycj DCndWbv26Ttu//Err7wC+nn0jVC9BX9HM05Fe8kQvPjiS/bk0/PsH+iHJ84J76IJ0sMMZWDn nnPum970preddtpxxx6zZMnithOg6924cdNdd96xceNGBAiwNYYZwcITDP5HJK+0CUFfHR2d gNsCOI73dnZ2IvbCQOILL7xABzdget+AxRnI3miSg6vUqlwtpB1SM7gG7fFoSwmebN36deYc LN82zDqCUHarOaOyoRMRXBZObMqojZlWYrAWNxnFpmmUtGRIyHuydlTLnfcCHa0ZbJKry+VL bump7sx9Z1Id8aY7VoKWFV4MaL5JmNB4AKbDssrCpssgtl8RzptY0HHwtYpJ0Y2a9g/ErKOx Qd+rlWqLtmwSR2mvJVCv4w7h4VD0ltGxUTz9FJHoEA9a+TdfxkhNaYWZyTDgKQYCfdN6s86X VxN1tzKvoq6uGUjIAFME2gLPnScayxOIipCRI0ZJbKKMMinTGxYKFSHjwGhKVspNkPMAfMCz o8d4Vxbcp/IC+pm8XTar3ZpQwyO0eVyAhi85lkLMxXeGbazz9ib7DNDPZun1eYaHJDmVFZRr QUHJOipN8aPQZMm+RTZKJ89XpglfK3JZh/EBwIpY+J2xxjiIkUeJZJROABrivseOXIrPTGKO dZL1gqSlnc8LDIvQizzkkVoCZRSiQF3cO2PhMIn0vRI9SYcJLIGwS6ogL4hHRHKhtAzldlo1 GZuEYbXzToxMeUP8dGD4xyNzNPqZ1ifXpeMcLiEXpnAwSIjV47rxLqFpaap2lelDBx7y10io XDOSJ1VrNWRBjuxiwy6PCGJgDgA1NWLOOLMRseQ/JYnMO5YxSsHVF4vYYre9dOlBLhBLD6Tu 13WVAFxBD8Kd6zTDkDIfoMMxQFhVRM0yny9URdfcjIY06mAIVGM0ISXBVYevmjdvHr1gz549 L7/8Mh4MxmjgtAxg1/I1+JZ/CCkdvVJJqnifC8cod+8ECY1AAJ5POQnxRp1YOuqoozo6O2mf bHzxxd27dyseAU8LOEO02ZUNHRbTjLtKtUdFwpj7TvwQnZiKuJsF4XNPtVgsUnLAgm8iOa/u kAL5CJLNYph8O9gED6eCkJ4jH44BLB1TxZ7HqBZeoGKerjfS5MblenAbv1r9aKkQWlwlKm9g YzPIhVqqI6f1ARfUmka+1t/AzkLBNoU12hPTTFGvK5UU8Fu4lA5delQh6CxWuh0xRW+ssKfp 1fv6X4bqvDGF8lnKVg5qSs/S3kPrALM1DRsYGq4ZeWpmcsU3JUT+p++VZJKmhUxLPLfyxTXt tAAtBhDN4QtTaJhLUcAI+AFSght7kvz7jhJtFl7VwodgmiWyeHAVRYmXIUMDVL3hK5ILx52E diXiIboVeYARGE2eRe0d1HMGeifI+xqWWcAdcbfHqR1KU4ASy4XmnwJ83LAYtUeOEgxXBdcJ pUaXwXSUFiHQ18Tx7UKKbI7i25QltuMQvlEsNP0zbBOQZ/nSbPPtVJZZigacIo4faTpCPV3J eZ7fQDLkK4eTnQWWLqkkkagZosbVvsgdOSt6iKjK4MWAmcDla5EoSIegE3ulYPki717TnUUO HoAazIdhdEFTUtNAzWaBsdRYE2/nurQfuIK0RoFPNS39dNg3naONDXO3LmYVt7St8Sbk5sFM jzOfsISKTcth3zbmpSV0MaRG49tlKCRPRq9H3lYqdbjM9LxIli1b7mJ4UnSyTRKRVypPnQHR SaYJLxLpSLY9J9x4+CrTwnW4F90xNK+Vvb5ph1INnxV4uEGtjShe/JNWfuEy0ZMrFksISBXS xtN2QkaQLiDHqiojBsxQylAiH0Rv1ElYA8uxCorabqEsCg5ApmILmhPQYpuosH0xzzsySFBX jjknHeHESylrja6BWBzyapSGIzdCjlWXcXrfQr/SApotdmcljVB7ofkNXmCQ61YsFZ7VHYM1 baRG02vV5NbH6jqwlt6V4/zUNZobZW+sy//rei+cpE5EAY7sOjDPio+oo1Vvp5Eyy53MWzY3 WJ6J8g6xRQtbXpSvbSuv3zfcj6bjSSvflqkV3Qxgj795y+6Nyg6M469ZdkpYT48ZZxovDj82 Wh49ftEpQTOLgF8BDl6S8sg3c7RrR5966Q90+fCIiCRoY8+dNX9l4XgvFRvmSsXm6tpXtr/E DKoybtzR0bF83qqu6lzD9+p7w/kdL21/XkRbFhycO0Yzm6RVVdOS3RoukEpx+Lmtj6xe+uZM teTOkQzktmzZtRHDsE2ZLqI7efTCNwfVXHqx2eazAw9pfQ9DXb6lXtUgum3/Sr2FS39wOVCA i9P0q4XuGSmXSwLihstGAlQuRyed4aKwGpD5wV2xGRc/R/barUnWpFSrLShd7UxsaGlw9fe2 tMhzvkprgvUjLHoJJrGQmyYWh6klzTaKmbQeK+4H44qJKZmmGaErXt/CA9nKb4t7CFBSU3NE cVQY97Yj277hiWe5yIzuRJXl0/gPxHVZMdGAXLqdF6S8Gr+6mxpplhoB2p6wdUAn+raaomPL cKXkfhqNJvQtdfbLpYzikLFYBECpjcVb0zjVcNHhsJAcGtZHVka7AFNxXRcGv7g7J4JjAHcx fobhVU2DJJF2C1aJhZwZ/lAJsmIw4HFpAjV025vh7D0y9lQQYrXAgosAB9JXctLDCGSpxXMN IwIzIfq0slmiQC6EIUxhBvsnMSRmCSIF/JIOo6OX2Dum5i4BI50wMn2YBgM+9EHMU6MASpCd ARA+HAEJ5gd3tlDII/oACyp9HFNONOp0HRTcsYQmKPwLeZwJMEX4DaIz2rKCc2KoGFo4dEz+ FB/UMrwLcHq4n3xdvhlHx/kDqAOwnKZcfBtBE2tHR1GLT4f8/dQQmzqeXT0B9znMkQEyTIRz VI6mhub/Z+09wC27qjPBs0+44aUKKlWVVJKlklQKVgAhERUQIAR43B6b6enxuMc2jbEBYbtt 99fTH93TPd1O38z0zPRnD8aASXbPtN0GRMaAjAjKQmTlUEoVVLleuvfdcM6evda/1jr73nfv KxnxkJ9fvXfvuSfulf5AV8rucoXPFjZ7A4iRxbpKAJ/wrizP8FcB/uWZfQrSwEKFV1IGpznW 0aEbKWe0kkt2bT93Z3Vh6rNRnTCV9QvPc0hpy2xTsaOXLx1fPBZ+PbOpNedPi+We0kay7+hT mN9Qo9L7M7aftaU6M6YRLeeH9x99JhzdWZvOd9WYw69TtXr+ryxa5dw5p13c3tI8euIQlSNO ej6zM3NbsjNid0T6apUHjz4nkxX+Om1hZ7Oct+12s6WlzgkihzZntmRnqoeU00+M1YCdKSgN i7Xjq8/noSD1p42IFzeSk51D4erQE0Ft0ua2LTs3lTtjbcbV1rHltePYmtGGDCkHBB3AcqYd 5aDoKnsgHl04Pp360O2QRl+A0WU828BtyQZgspobKo9vrYxHnAN+tO1DHNe4pVOYIlaAkpZR B30jJ3dfojhQDwagZxg7zfAqwtNKpgNDNYa8Ej6zovuz4pKUgsdgCOkNSI3jQbAEnbdAB2hm SeTa5WJ9SErmOMrKmDDsURaFLgCLPKNRBgTOzEtmAvTD4+85X3dsXxli1bAEuTXc/xDsYN40 3a1DXpEIOKMO2VavwIFWgB5A6tI5KNEkqynAvNRj51mcU/CHaBsY2hBzL6yTXKiUIGijYtYh dwmuAneY0YkpcGMAKIsriCsEzKcV08DchrfjB709CPhTJ0yAc4Cfz2ILouoYC3K4iCyNC4M5 ngVqI1GGkmV1daXP5FPkL2jROA3mw9gbjftg0CMIb0wV0GJakGhDWWaHHqDlJtCgLJn7CWxk yF5D6gofUggoeGXh8OC3gZKrwRY4ptVthRdOBWqdcINj0IVFB7+HrGrGhWAtvMZcJehg9tgE S/IF4At5hpFx1Ziz5mEaQf4yFjeRs+RFw4IYJD3zZKJuL8RsSqUoAiAXnhngEXwEmTPSn7X4 nKIB6SPKiJrjVKICeaE5kujdE7OpZEzKP1uJiXrI+v5joctyK8MfAnRn3CZL9yxJAuULzBsA SkXz0ItULnYAf8WEKbx3e3puooresSYhli0vNhthVUt3ze8BiHHfoadCNRbDU9vDzSjsDKZ1 +tyuWLPeZ37/8b00JYqYLs7A9ZEMrH5ikpbp9uHuPedc6hScaQT2MenYBb/d8e2KapgFjqPi DMs0tzRZ7sGvk371zgInFAUj0b+DR54pG5g7ivxta7CJO6I0FwTQY+vMGTHf1+f+wIm9PGMW faCwnAH0DATHeusi6AVDmA5fQpnQLC2WecUfFE/lze7LwAvGi7D+JDDiLXUTtkUAocjo2DxJ yjGxy7gyo2BQjWjl8eEM6xtVNVCANMF9Tp1ShvYAJbG6utrtdukClpW1x0VPX5GNVi1BYzdq AFY4QP1laTIiCDylCk+EXQ1LM+JZJs3GAgNIF1Etw8FCfBJzSkFRaWvEZUICwy3nsnpu7XjP DTAMxHKq3mCQm4mVWrE+5Kp5aL837JLT95pinMGRsCmekXslOxeGUBXfyyyL2KIFtOViqV/g ofJohkVjbFQgqM8Mglmq7Dx4ynCISKAgoE9d2N2zd5110SWXGPOGoiIHpycff/zg888nDWri hfdedNFFO3eeYU8RblmQCSzyh5/vvfcerPIZh0PhkCtp3GTFcZNddtnlZ+7aBa9bSwds/0Fx ABWs7kJw/yH8/PBDD+0/sB/X8PVvuNGAiI5TP+zh8wcPPrfvOYFFOBmk07O9desFe/aoTHiJ lPDgwQNP7X0qvOCyyy8L9as1/Y2JZfnj+gXLwFF2cr5z//3hXl5d7Vx51VXzRMqh4hWbCift 2Wee2bdvX7izw+GHswoMCFaTIbM0pmI8DcesmUt444EDB85gL9CxqxP+eecdd4DVGMtlEtRw OHzpS186y2yhmI0Rfnjiscf2HzyAZYVau4M1axEbPVlgJkylqgVk2XjcNC+sFWkdwtTX6gyU JkcTOPRUkzI594wLXT9H3EL46rZOPHfy0ZXOSqhyzt/8krzXNr/Hxtr8zm1nHj72fPj3kj+8 JTm7luqtsot2X/7coSeRD1EruLclquF8r1jsl/1WxN+P1Xf1uyTwXoNK+HmbP/f4wqHFpZOj 4lIuukRJOmxccv7lT+17PGrBpaMK7s5UprTYcrFyOz4rdWIKzI+Mg5lIOF3L7ujmZJeYj9Ba 687fdckzhx6fZdhx2IN2T4aFiPfhYAdD5qQxVKrVbmOVDDckNFvlWPguiAF1yaixTsYMuVhl wyQQQQtDjzEGLOBT7Df4GZKJPXoem1ZqglGUUJEHxpvTSQTAhwRzx2Ap6lJ6tujNrO9X8rCQ 5j1JBXo+EkqaI1elJ6B7hTHn/Px8CGCk1zMsMaa1y4+xNyZ5XjLakoaIrdyQhPFkK2x7yHRV hsNIAgRgC8Sl4tTE7LJYzBesm5JRJxU7xVUYPFfaw0RHscfSOZlaz2c5sZvjGViscCYwhWbD 1n+TzwBeQ4hVMEBnSGKqooBoxVP+F8qGsC4pux8iGKF+FTlvVUc0LBhBT1Ua0Vy+LP+29V/e 5dwMA7xDYBpAK4svk+A9cBa9Fo+eg5uLPi9nM5gQJPZcdNH7/+z/Wb9Q/uZv/fMQvfhM0dtv etNb3v3Od7xAIP2+ffvvv/+7d9x5x5f/7u8wLEGlYnELknQ3venN77n5nT8eVv+d77r5+ecP ohz6s/f96TQNwD/+oz80Ua9wvoBGO/+CC/70T/7T2Iv//IMf/uhffCjcoze/++YXaRQZvl79 qteUXBjd/O53v/zql4399S8+/LGPf+wj4Yc33Hjjb7zj7S/ys/7tv/v3f/D7/37in/7xP/4n TzzxxKg8iqRpf/iHfzBRDviNb3yTCJ5WgmVaDwMR2b2yMgi4NCezeqpfU+jpUazyJDdPdKzN Mj3P0rVh7cE2m23G+AfrYNlae+LID4esqrC8urQ3+cGe2Vf6UjqK4f+2zG4P0Su8d+/Bh1+2 fZcra2DYQrbNJU/iKdrzU5e6yAg3/HRgaa/YjVa1YB3CwYnGc0/sexBn6ZwzLtjidmW9Rr0A Dd3OTeeeWPwucvwo+Hlzxgrb29Lc+Uz6pEE2EhbiU1xvwgRVadfUgF74HA6+e/TEYQKINxsQ m7A50/D4AFXIvqNPbt6yi+BwGlnn0tOK/GksEDs2n52sjVhAH+48myQgKSeg0wi6SnMmOQBX x6d4rRn5eSSw+ahIqoyIysgF6grq/CbGPnhM3PmVkQKehkzsDOYd7LlcWuLFW/MchkoduXmM 63IGN2JoGsosiOESE1QJRr1eD0QrK+9C6KKTz4l1+GuR5CVPv5wWPeEAfEpbhqgHwMbh/MeV n97hQxM8NNtGnugUg2QgLdVGFmPzkhrunyAZBkC3AGQxtSkalZXNRgbEeDjCZlpgJ1tZy/Qe jX+SslLgyuqKFbUAGcUe95jrSweF1V7w0TKxZmQAXg/oPIM1Vufm5s1VMi7gaq4ITwriKi2W OhwDRswvLITvy0tLPS7FoPlLW7ZU0GSBpIxQJUeciN6aIHr9FLth9BtxMPyy8oWvp2FZ/Pmf /0f/53/83//2E3979VVXI3JgJAjQxAu0i9zgC3c5qetmUzf1+htee9rW0ygHcTXHdsQWYiQd ZkG8skp+El/whRnLjGKFLWnb+p/AZ504ceK2r39z4p9e+epXj3gleyGMvv71N04MXSHeEweu yGuRzLKybgwziPJ6O14Q7cjgqI5R3D9SPyAnC9OxRRGmQI+6wVgwMpB7IIVvSujiYNBNlkql hRK8qrPSy5fM+ZB3LDNVwOX8sAUS0vobzoVyDX9ayLfVVoRha83ukROHyPhRCAkjhvcwmUR+ evjE/qdXfuiLUpuKdJvMJlusZ66jLGetR4TC1mDBIFg0/tRs3erq8LiudlbNGQQWYymXPqTj 2Gx0VjvhnCwvLxNUgYobB1lCGHB0W8ctzBOhqt+eac/ioZh1W3E3A543bK0tdxZJdpYpwwOW UkaNFZMR6/pRugu+7itktRBJHISgfGEYwpjLaE0wKAmZMbwiikteWJtRu36AEw5BF9kOcnlu VyguUcJnKaxnZ5MIhDc05L0qFOfcHOpz6OIrKxDE8PsmEatTQO0NToVLGK7+7OxMxu0vNH7a 7XZ4KUIXlAwNn4JDh26yYt3LcGU9y/tmwjrwY7xDVSKmLVgJLqsuGeEOzNYKiNMEFbNLwRUD r7lUbVKqmSBrBw2BrG4YitxasyXyaTwUgJ6A0YpBbDVvBHkky9pQaWFhE4hiBdu4gOk8KhJG ES6yDqhkVFSDbIvIAoKYZD0FwYoDGWYZ2KdSMej4c/i8kiOZKWpjhRVk6pSvnEr4Prj1G7Sz Nvj66Usu/vjHP/oLb32rAZqx1tD5IhjCi5BY1CfBxnWTdJjmr7n2OkPBSeq8YWuOpaN/EuHL JQrVnRQpHZQ6/fp5w4/39elPf3ri7/+bn3mL5T7WWAj/vPbayerMn/3MZ0ZF2+QxQFcLky3J vDLSMgZFCTEJpRgrRKiZkLJEQSDVRpOMowi+DJEqyJUyZ9b51CAMTks3apKo4YUn5TcTgZA5 R8LQmIM82kEsoWW9dDs2/1T4/Wlbt7X6kSlw4k5Wh7DDPg479ZjIYxqHUdzy8uJydjieTmW9 5pbNW42x4GSxHbHwdVV67pkXjXUkEzW7QhjA+YFNlRPMoaTbWH9LxhyR7mqGQW/hZelMMcdK vDgSJ6XbOrOTkFYh7nVnY6zmyer51dVVmvowX1BWSY4BFrrQPx9N7JzIjhIdbWhtau6alElM YnBQ3y9M9YdgKyQ1UljxTUAAhc4bQ1QFxFVPiOtLO4eMJHJI6tHhDDFgLSx7a12aIpcid2tm WuCiYfZss1uKTGHHMNHi6NJutaETFnKCkgFTNOfme1h6yoz+gIUKpl/IQUudS0HD3gJS+JdN 1Ljo9FAboVtI5X0BEEPmgYNDRNc6jAEguSD1VzsdcNSQaeKvMC0ztzZk4ZChwfwblfT4iFrh WvS4FTKEdgZa5ioN4GeBOkdy70aCnp2dgxwEtI0QkLJIYFffUphFWaJOyol60pK82VoXR0Rw ee9NNATWJUMo2yHJiceqUL7Cx5PND1+YDAOwaqNSA4bCqoXx4y/q/+u/+1+ufNmVaz3ynBUo gR83Qf+HRwdBP25Qe4Wva655DaiLWIizNC2ml30xCfxFfglJsNefsvPO8C8v/rPCRr75jW9M 9HcO2cPVV19tRQC+7zrzzNe/7ob1L77vvvsffPABC1GoP5DN+VHzZYAsHLTanMQelpxvUhDy gv4oq1E4skpwofXBq4k3VR7gRCpt8An4IllwCvTHUTzw7L3fOXbr947//Q8Wb/v+4m1P7P+R w0i8rAblYK11Uqdi1J5rJ/Phg87cvDuqrnyZ95/a/2ghPNaUBMXrWs4lavcML0E09I8s7zel JWxqy/zp2vyJoIajgWoTFXxJxKwwg2gP2pbU3wam5E2kaRqr6YfVFvKGpF3L+ThU0lc6y53W iTg2tt0mwrwsnBPfZL4Y7j+yF4E2bvUYNNeUPIFxHZGUlQEPwxRRY3nYaiPeZCI0qnANxnYM DdUGEBpASSzPKONYHRcZ1N4BplhqVm3I5G6nA81Mky2fmZ0RLB8fCNvE5DG+CSU+iG6KJyyz 2OxH8eJAe9fdOfKsaaJ5AAwI+gFSTFUCbSfyNVu0VJUN8zKTbrKWEoE1MqqT2El5gFanbJYj YppCT7UXqR47PAuzLIHEaxXVHZDT5HZuBukvYeuzcANaHXgATYmKuv1pas4SOC0gR0JXAVRC VGnoilFmozuPTqBoR5DTS986MSi/YAqBmgnbscO3EIg5lpViYHcB6MH7m8eVVXtmphGSDBP8 kNjDAbCn0zMW/aq9yGDONC2EINVC7zFkUln6okqS9773vaTwz6cDgFT20Pvxtxnud0xfBbA3 5et1N1y/fft2MGfD673WsJNEr1IoHTj3E6iHoIAAKsLEziHBMgc/megFrP/HP/5XE/964xtv qqMOjxtffc01E+X2/+7LX4YxilhBRl3s+GVA/ah+3dApNJEercHAq6VIeMgBuAL3Oe5NeV0R PEzlyWxC+DLDpDdS/a+1zz/zcqv/zMUKo2zwc7HxAcvNLQ6OorxBRCjW5mfbc+1kk0+8Uak6 +QkcXcF3zvoxBsoyJ48r5VkhVPisvpBhyS/S1uzs7AgHDRJEra7PVJ51bW7r5q0W9qKa0kGK euS0SBWVgKjgWNh+QOYaA5CNMLkJ15oHIXRiV8oTiZV+LnzcbKvZblXzHFQkVnaKEwPtrTlG uwmBksBZgj8SCLsuowaOF/lmVsVVkLjDX9HAcInTzqelB/IClTBGGi1/I4dDIaSXUhOowix1 cUkYjFVumboB3J2NwUC1BCmwqe5oOntLAfCjAU+v71X1SuZkNcKi9gIOb+cbsILXmpM47aED gIhIfCH0CZpAfwA6mGF26NVDGQUZq4SY0lWpaA7BGfpI2Aw7CaI0o0B7Q1CHej2ijiivyQhk nJxlKOOcCgIYekAaofxQYKxl8MIiempM/KnT7dTiUpFnEAijNXPZV/hOUJEsBzi8gFY9ZO2c yAEn6gIBZrSIGbJQRohJiGEQVmV4cLj9CkGYh0Me1Lba4r2HaGZUNewZJHrD5gDccIwfg4qo nzJ7sStdY4fXfT308CM3v+e33vObv/2bv/XP/8Pv/+F//n//et++/dNaiL/w1reKIiofv3tx TbOw2zOMiplW39TL90031cpGSIiybOIr4W7+E6m92JUxowdjSiwkHQrKbn5SxV5y5+3fmigQ fMNrrxMVDMh9pul11103EWjzqU9+sh7JutQ8TYDCT1S0BtMs2CmZ5hOKFYslvK4JdNhpVkg3 XCg4igKrsyCAFVkg1g9Jd7z9u7bj8u3X7Nl1GSfoGd6LtaOnYmPQxwp7tfe5R4eNTjzE2bnp nGytZT1Dn1UHTz6F+IpAS/sfkYQTlaL3fK9219bgl5GklTM7eu/zNF8n1ucwZ+oWx62pduaW 8+geyNLEhnWuXsig2DQyc2NukNnpFhC9JfQBaztxC84q0cMn9pXtNWNVh02fsXl3YaxtWrf8 gRN0sE12n4LUntI/yrE+QSyVa3RA5aA5sIwt28QFRUMPwzOgJKSYY9ISdwKdeVGSmjsrDYYH sMEq7wZutKalqyde9FGkIs3uppZhh4gC2CE0D80EEqLDOC2hPuNiYoA7sFI1egvPPAIUUVDc AANRnS0RyXDHksoftwRQ7hgpMxxId62LxuCQJ1sINjgKq5MgJYwDDHVeuASYQmVcdjMzLjP4 e8n3G5rtGTf37PEZ69kgbFs/M9OGp0tTawBmyhlAnxBwUHma5hdggDkzI25hmc6hzSWcCrIQ KrgEBAS/0P4eghy6aAN1UYHLOVqFJDEEmjOr/cbAH7DH6hYX+zWfOH58dWWl1J6kejWhhcjt gJxxkuAFE3OtImYmbNoZqTJ5BTXqq1LlJ7xmeZmdkVV9JJy+j330I+/7s/eFWLX+xddee+2n b7nF3KG4GTqh8rj3vm//2tt/DUhF5P5rTB1DzAN2EQ4d7EnROOXo6C1vftPf/s3fQHLNm3zG hGpJpqa/97u/C7YgFuJ2qw2NsjvvvGP9u37rt3/n/vvu6/HsDVkPS5RSOgaZgA0GbOHrIx/+ 8F/95cfBsYcFH1LO973vfa9Y57Tywb/46F988ANjqkumoXfo8OHPff6L/9M//cX1CJqXXPGS H/zwB/jn+eef/4bXT2gbfvFLf1eT8GP6SCJJDOuxEq+u5McDBBSnOK5UfdEQ3nzcEuT1N5Ox rbclHFdkoOMxtBOfPvTI5advT/t5XKll/eam5MzLtpyxWhw+uPjManfFaZE00A4+/MnCHi4n J7Yks05xOHPdHS5CoofQstJZSUSztb4ZXD3zknY/rDHqxSIbpMPcRVGOGaC51CWKdw9L2NLg +KzbBjzFTLJFuqZ+BFafKphFeOJAqfCP5zWuco0JNAk35x5Y+aaJLyCp76SLC65tldtc9/RE Ig1tqtM80V/sYczDNh0jukf2M2IMwqgJHcm+ealNJew5YcfLoI/lkQz6IYY1in0HNmRMaSnc ABCmksmfeqaIjP2oqjXAC612W5Q+ItAaQBwhLOoUh9B9zVTuMX7Mad+ahEgsR6WbADmhwh0o j4EOxU28ESBDYVxlCUQ1QwZMepLDLskkalZhRGyjD+MTB6jVuCazzCAcuIJT6FAhbKhl3xDe 0EgK8Rzh0HpAM3Ga2FeN0MJIypn0CXDmYZQYQ/8bZrSdJSZEAhW6NBqAxf6rlq1CFc+c/Jpp ShGdCVTmhwmLjzKy7Q0bmZ2bK1UEq92egYWmcXBNot7g9Wu9XqMowrtImXDAzR91f8gKldN3 XOtxk7GRK0V3gxrI0CNV7VYz/jXgehMradjLw4cP/+v3/uuJRUBYNE/bulXcNhkrOK1pCdM/ 7F4P4Yq1y+CTjXlAr9+HydYph1WXXHzROeeeiykFlfxlNblf55yqXWA6mlmbBTPbDUZcMlfg RgE5JXA5iDJuIqTT8croZPaQIV/DcD62ol9Xb1Y2R3EqHCUSfPyWT9/yqYnve8ONbzTZp9dc c+3E19zyyU+a272UXBHFGNVkpr/HM5OTG1AGCBZWK3b0yEDbxDQ+Ee2cdOz6mmlLaoq6Sm05 VD7pcx9147A2J27oQija03jFRTuu3L5tF7RWw0kDvdRkup5+/pGkMRTk+uigMXwdWd1Xsbw3 VYdeir/R+9Bj7Id5HiYr/Ni7mjVNaH6sBSJTEktjhJKoKob4xLzf3Lr59BE0hJcgJ4P3PIuw 7TC3c3E/cF17W75Qc+w7+kT4LAU78v+ognGIZkc7+4mpzGbH5k5isdp0njRiOcQnqOeYAQ2g 8IJ1Er0bj+GWQ7DX+AR5rTgUQW+e+ew+nvDX/UajyGn7MTZ/Qr1o+I5kVH6JEnP+U0lKvl0l Dpdr3W44XqgI8hs9mzDTf+xSPQj19JCReyxowah6Z7IUmf0SvwFFAX02b1TUNLMVX+jSCEW8 2yRPLApVZdzHspaM54uiusPcdXRpfKOiZgrxkspWL2wBxkk2UbENWAwh/NxnDp+ZNRMUwFeZ jgmQFJo7vFO71wHj5vBeGxPIyACRmA1mBQni62cWDVzchU3VszcQh0HcQzmFxQPAdeAPV1ZW gEy1fh4IZGw47jJmcKWgLjvGQeJElOqDVfL9Gl6ELVaK5dwADlCvNVPA3y6S6MbBPPLoI7// B3848cUXXXJJTHWcVjYNGAAK96nZ2TnoJSrCR9UeWZtx7Iae9vXGm24C2xGeHZO7ebq++Gjf kJ2hGz5lOphaHoS4iLI9JCnD4aCcQjPwLDMBviGYJUBO2rRsI4xGdCGccq2we88888zXbvvG xOZhrvPet7zlTROB8seOH1dUQxUbblXalEPQSmoHZJEVgAG8zAkoI8tsJKaIskytmNwEhKeh /iA4OxgcPfn8geqRstmL45eLYA/ttS27qksu3nU1FiBxCQEEg1H7y+mxCEyo1pThnmktr64t 637mcM+CSBIHixo9j84eozZIwo4P3Neoi3DaXWbNKKcupqivwt2ykh2zUmzr7E4bj2H8JsJL grBLrRABxU3inI+4afp2898SFyR+0jvFcVv4ZBf5xf326tLKCVCy2q02LDYVABGVU4p9xzCs UvChPQKgGGOCi90AEloENXzkTSGCAYKe51sOkEWuRRjHDYR9aiUXz4BN1M0utgpNoXvm+So7 KEuFl1Hjjvc8XEL2eKREkxuVmWjGMzDAjpGQ5TQTKFiUjpALPYaPWYlTaXSH3Ds395oStypq J87OzLbZ3t4QZwOgFQkiuIpltMeiSpTDFcXi4hKDNSqQHNa6ElwxnYVhAljJ6Etj98ZE6xM1 v7YBLa4vCBX03p6oDKNDgFWIxeoqpzKG4UiBnzT9ORgaAHm+ML9gWlNmKS6jjYHEtm63g2wG 0y/A/YToyRfVmoHSfYnsu5oM3AjvWllZ7pOlKvVSa3dm58zEWduMXLZndalexVZjdnbCPuna 5zfAHFrWMIUj5eBOkjqhN6JI/OIXPj9xg1dc8RLc/dJmnlTQgcwAmDteGc41n8l+TURjJ7os y19g9HrLm25C8QhL1sklH9aXsjKPuBCBcE+HW3kaUjE8YpYlYAFF0mTl2uTSVnvWsLZT7Cyh e2PF3vUxz54fryt+zCMOf/3Upz41kX53+RVXhM1eeeWVE5u6n/n0LRYahfTmEzNJQSgyCXnt P3gv0b2oqhooaELa1jmEqIwRXFKr6VJr75FfTPhPlpKqPHjkuR8dvnOxdaBq9uK4NQJHXNv8 0l3XDVjGnqpk1toBSGTf0cd9Jj1KC0jh/44Png8Ln4GYc657KLK6qERz0vjCZsPhhAtk/u6I LeGR6ZeDGs2lUDo+FkocVwcnFfLvZoeniWiHM/krVqqVC1f6ZKTOHPGcrXuSEpaAII9Jr4eX nw0HO3ZPhrefLA8ZaIIz5abQzFOnXkmA/ORmXZiosiW7vdAtpcsuQ+x0xxr8JZKeUsbx4MYL XN58otkXOBNTLp/UhLBoMYEOahZRyszvO2FjMP5OkMvwPPZJua0rrWZFsZbRiCiDj6X6wlB4 YdPONIW3SwL2hTnQoudfCPnBxeQkRkKmlqInan9aadhA55wFEDwc1ASIwYgMGUFxQOWJI4Dv BbW7Sfikj51kQYBCc2XpIkATywISY9UHAOKj2Q6tlsyU5HT2TxtneFqXXEg6dpUFpakBrMue BiiJhCu5vFQoBN2wqRD8QyTD4Knk94ZfVoor9lx45ZF5ZMmyGBTguWQKddjiyZOkKJsXCwub xJ+ItT8gRQb1qZMnT4TiDMIfOeRSUKk0uNqNAzt2HXEy3Zj8pLTlDdDtK6srYhKTpqFUwum4 975vr3eJ3HnGTuG3boi1M+12nEHPrVUMFS3Ir89TNvjatevMiy6++NFHHrH2/cTgVbLFHH3n QZTimhwmHNPK09h5hM34pHZRCMDELmVaNxvtptdbcBrWw7nEprJShJUqPJ9LGLvv3nv37du/ nol8441v/NEPf/iGG984EXrzwI8eQIucNsjxiRWKWwaKE20nDLESqLgIl2VQD65LAxQltRVT LDdeWoQzNiunnKGAa4zxosJG9h54KPywfduuuWLLQrkjGQo517jl2Vrr0nOufvLwg8CPidF6 lnZ6nV5jiaxVvPXqkmGzd+DgMxmjUQYJuVGUFYrXQnt3vvYRTSUgIB8vlXYTiUglNiyJuU/A he8//Mz2M8/Nek2aEg3zM3ecG6n4hvDlxA5UI6wY6PFmnq1+cGLpmGYwMo+vGXvs/ymeJk7c D9bm+GDrOO3KZv/QkeeSSPIcdbCGPY/CBXLPytHOlGUllO00FSk47b54J4O66PmJnMDqVFIP ByMczJsxwRqZ5KnnqoMglp58HCzuK7wXEyCoXcQYYzytoxB/ypsQP8K1hkcP32MYhqWNpAHb T8juQNowTlBqM3uyGJXUYsARIh2dlcIQlSon2pGCS6tBv1eHQ3LW7nZtGZEhGTjSaWZgVCO9 tbi86zMRLcQf8izMhZcCmp1Tz/eKxekHOgazziEtxUq0Mh+ovJmHSIbQZSI4ZlJDovKDTrtN II5wL4HXbCTaIddbA14NUCfB6CfEpNm5OYoLanOK2Ca6BOEj0Dvl37AMegaciJVDY+ryMzOz 9DIKvJ0O04F9pdNObLTHahyIZCTkPH0pxx1mMq8o5CdUA6SXTENF8zoiRCazFx9//Mn1rz9j 5w444oBrMrEbGfJvchHrdlC3hp+J4K3+Wwb0JB+28Pt2ayJifj308Q2shYhif8pQSfxhC1Gf TNE2hFRjOh1/AYp7+A6okinNWG44bVpWsMvJ7OyMNQAt5ZnYzvVewNw1rNZX1ja0GdVHP/aX 69/72uuvDS+74bUT0Iaf+MSnksidC/3xEctjlxqNxpgoWOIlJeTGTq5wTX2vG51SDM1zFpUZ vg+hVw1LCwqQTmi8ntLkUPUeOrr/see+/4NjXz/aeMY3ypEQFyqw7mnNommdWxPOObz6jLTp dIy0khyt+BBkCWDcmhaFSTyA0QJR/PREMyLJlNHleOiYWFRwiXmYJKg5SAfWnSQ5KMYcLxRb 6xLcvIl5hl9TrGQrCaKFOULFok1Qzh3rs4XdPNp9bjyhdEdRPA1URJvjgU2PHPhABo4gKXS1 +AK+DkQrLyUImLPMzA3JOA29aJ5klFvT+XTUC+ohp4YSOUmEcGcsXEqkLwJl1C8pIn2UO/Bp wtQZCEBZ67N0fn4e0Qh1DCTEMtU5BCjfxsZAQKSsOt8lmvMaMrBUn9N2uw0wJ5rJKSa2vDpR D1AWCkrC7NHAkCxTAQSrjRYXF5F9Eou/2YBBPEgRg2iMTeLI4fTyK9H0hrkwywQPoDnSI+cP sZH0avViFLQsKhztMLFX4T9aJ1UXO4u8zVpsxzhUq/GmynualAFZoXY7YACDWBWCBcS0wi9D bBPMZ6tlqus0seZKi6C5nfDuDgIKuZAPBl11AlPecG5dwPDD3NwceGabNm2GT7LcmYbl6DO7 G3sTQiX4zPLkUDwg74+SNaQ3QG1Y0uemLN+xiEP4oIznaqRKt7y0wdgGxePEbeIWRrEF4IaP Jl44v2JeBWmvSWXKgYMHv/6Nb8W/uf66azDqCAnOtHKzPolKbIxNgacB90XGjLE9sc8k7Mmn 4f0r5vNTZb3a8RonBCYzJeZ509yMVOET1YY3oOC999y9vLy8vnn4a7/2jvU12dLS8mc/+2lT fjJgvW3QFOvDw6Aib87yIZ5CI6l0ZqZjCay1g7hWczEbxlAD4jYrPgCFeMzzO1vqMIQn8OmD jz6xdD9ACjHGfGH2NF2kKhMLJyEooNh1SVwbdvBU09POnZy4/zY+edXxdSItmsxVaVKPr5Jh NYyHmmZGA0xzWGUOLT1j/KdWfwvSEV/faSUEGmJoBkCHiZpNRKIJXsWWZHbFN/8AN0N4/0p3 qW5981d3uIrAU6hQ3EB13zmeUZXAhULPmhlO9a9jDYWaQiAzM1Gt1crb6RwNd75nXfPCWBYI mXje+ZJmgHsQlFFF60tRMiyxdsNsbKDrLIp+WujR9dJsCWcAUklChBI2fYahF7D10CP2pZiJ DHgOlAsMhyDTg0jzgnmHJX7IRHo/A5LLRVRo8PGtTSIpdSFz5XarjZBTMjICeZjqWlFmTGMI Zpuhshyo82Qq9pjUeWq36ItZ3rlBpZDVYaZlqaSMYCLNNvyS4pzRufjwZ7i6El8VDkimt2vW gKi6cuZcccxrVmqNRulHqyVOMczlMqn3LluCQDgX92S4r8KxLy0trfFv7AxDnlA8M/krvLfH humU34R8BX9G5ydRb7HwYWPuySyywv+cspTDFwcHDJDbtC4fblPkLGTf12RHnElM5EsuvtgI ccQLnjJ+GkROHFTSZbTDq6srW7ZsNZ1fVMRmuba+cLzzrrted8P1cfPw1ddcc+ftt8eCY2M1 n7Vr0NLBUxqDdCcGb8FNeCkN0TpwUet14tmFa3NdlwyT2DdyCqY/CbUmHrxeqLuLXCxOkspA FuFsHD927HOf/9I//aX/Yezt7/yNCSLLf/03/7VG8MMVhc3TjBxGYBwAebNU2ZpevQQNgJPZ PZNEuOc4mba3VKo1kKjAHYJWeCw3zW7ZnV9poTps6Knh9xarE06hNEsrS8cX9m1Lzk3qLp5r 5TOCrYKQPWe1RT6KaGV7JFRFarCRRSSnOgLh7gGdyBIaBpVn0Yf6oa+X0UiYkbHYfBpXuyvl whor4pNm1Wy+FR8CmEZ4vYjmwQbTeRPqxbjFAIGwKGTF5xq9xogJ8heOba9F90IKm1QxeIkV ygCLp8RUC6dioEY8YsgElITZTg7FDnGkGAWstJ4w8S/1vcO44K5Yk0IU9IXuJsE1bvuLrjyP EtejnaVxyji3JK8rUQjXqmgW7Qb5HBXQcYBoCIUh+LAQQ7YoHEazOU2jCbNGqrkN1HZxjo4d E8l8GbH3QAtBhtpZ7eBesYeUnpE+1WRhOQqLNXJW87/VuJjgPsf+c4VdgcWfKRjKYE2w32T+ cr/N+ECXWS9A2vVpmbDaQz3isfQaC34rpwbgsCf5NHJrOOsCAefVBsQQE2CMAeJXWPuRY1LS apW9oQ34Qf+Kr9eMMolLdUVGIzEEsIojdLPZHNYZYZIqqNAqBBRRQgQWjFklsH30HwvydhNH Tgh+hNDnTyX3gAgxEdoR7kiKkWroHm4xOnHt1qhgQsQ8XZi3Wg3DuvWveeUrXv7kk09svEsf /NBHPvyhD4KO4yYLdri777xz7FeveuWrbv/mNye6GcV1pJmRY2YAbZhpgzpYL1ZDTYvDM5OL i5X00PzUfiOqOrsP0AMEVjWZhu8MGWhSIV2wCky8u0raAi7upz99y/roNfHrq1/5ykhZzBuR Atc0naEbyM8N9Av496mVL2IBXg+kkroNJeMWb+wLL8h4x4ILHo0deaP3Ntlyo4QEwYAUyXLn xLbiXCNIGT7QnnDgbhKVtYw7w9jOkC3YRzOSmoXGPW0LzGK/u3nzlljBKryyN+wqT7aqA5gR lXifV5MTm5I2Xp/1GpCfraUFtY2G0+tcBKZXgD7fgTlgbGFVCdkv5HrD34vI6H28my+RqAJS Y91rhNeFn3F6LXRpDSeIwVhKfMThIoJ0Rf5BGYwrsc4Oh7UeOQJ27C6EN2J3qMFq07VR+hRG ztgHI0uh3kJjHx1p3EUQIUR61263yRpX8wBBUqCZVuXtdouR9H0buAqkmabdTXJvUbImxktS niZufn6+qpRO7uWNbdaVBV2aRFKyhvQVhwLrKNlPAPViqrI3PMeiydxscxaVMUnEhzSxFKAj KMygNlO7j1MNhigPmIuZGuvRkuZYR1vovCGwMUiEApVLQgVGSI1q2Gq2QhiDV2mm0P/wGky5 bBwV6i243jvuhcD0hHXkGjBozFQIDY8hCqeGMsC2bN26urIyIDfaDGUVtr9Gbj19+D+E+tg4 P3T5u50OACfh1eH9pq8RC7ZCKSrdUH6X5wIy+psmyWHLTA1e4MTk6aeemgoGYb2ojdVyTym1 ARSpL6diN0IJMqa8/robrhsDXI3NvaIYBtZFYfi06dFL0OTW+pNllJs2cMCa+D6jB6L7kaj7 3HgdMMqnHglXUXmXRTsQfti798lpqvNjQPknn3yyrmUzTkW5CYy1HFK8UC7mbl5m/K06dFEc Hao+ghvzP4MLSm0UItWbQ+mAx1jCVZa6dRSndnOu0F45rkWj0QJ6LVH+byg9M+4FSfbACH6A 3OJJkxKphHMjea5K7Y31rm1v0X3aNr8rUcg7xZvcH188LCDsLBtBZDiRhAg7cGzlQJL52OQ6 HnEJulUdSiVw8iiIpTFkIogThdgAqQJg8GIWkcFhZHbGFyIu4CrWpNDkwdv0y8R0TCsWr40/ d6zxgDMD32GkbmieozkWw/35+qaIHOCAJ6pElShIxO51A/XUAEj+G+4W8xH2+mjorSjb9JoQ mMiA8NgYLRJiA+5wlBrNpkBJcWutdbsY8lGiTwITHhMyvc+zODEIJw1gegihhZfNzs7gAUEJ hdkYXkBZIKeYToGR5j6Dn724iBls2IPX5dWWUyjMuGZhn3s9NmuWoQn2yQYWSTSAsI8GGhm9 QbM3ws/cJ2vB3ZeCGaYkCoJHD3Co0EQAC2fn5iClofoAIzJyEPTS5bQSa73hEJKSsE0JwSzE JsyHRHWT2YQSlSxdxWmCFBXwi9hWX2ELGXZ0OmpjyHLKG6PSbW5pMnoU2wfD1dWVaZ1GDIrc P9B1Zf3nFjwpmcKpIjboXXfdHf8q5E1vfNObp/GuXSqjZBN2w8NTqFDmtLNkorToO1elWAMk G/mt+FSJyeJNUDfuUxMCX/9huN1BKC7Us9ja8aaUEX55yy23nPIc3vrVrwozkUevWAUQurBI ILjqI5FFebeLp1+2+o+5GqJhqC0gv27E6LUE8VjKV7pLwlPWr02N0y1HAYx4S2v72LnpDVYT VfK1oF5fL8Ph1b93hruDf8fUdEGFyecGp8cddYhRibGFYA/MXUQ2RD39XnfQ6Fg1KR7NuvOE H4kcESX2J17LjiwS5HSo82BZYJJOGbfUUIXXfVo4OboR50BapFjiPbYMBvLTNhgZydvwklaI pLZE8bUrOs2HvHEMEna4t/pMY78wtDLh8TpOHZqAeBjgcMgSM5wG5kQaY70o3aVMaWcedTAU /9C05Bb0wEZH8vtMDBBsqiriFEWBGTmW4263ayhiwgsqtJLZCJ7ocb6CgQuGVdA8FHYwqRH0 cC+FXbK5NQQYLYkHQQ1sKsctAUGrk8pUKdKFWDcw7RPyooDmhb3DngwkOsyjMnHk0SfIM2oW HdwkyjWh3wgomdQ0kTSPVdKkYYQT5WTxoRhRDkN9FoLZ/MJCk8UJw89UgbEyb48hgdB8Rz9v wJg12Kl4OrEdHEKT32UuXUAqdjqrDJHv4RQBHglnL5H6hYRMXKGXkdaqwSXBWS6nwNvkxirl s1GNTsQcgrMNDqD5wWxQq2GbyYv7Mn2DcEWlE71u58P3L33pC2P4hWte85razHZSGWmSa3nk 4gqmxQb7g6fCwlWrTZzZLqNXpu3/WnfNWBrcshjKkHi6RrBX/BIeeMyiZDzu6lIMT+999907 TXPSgPL33nMPPlQa4rEhGWovo2ZFo7hRzSNvEIxYiDq2MrI+ajUKbk5Eoje6N8I6VHTizbe7 m/ec8VKwksM/f/rsq2c6p8VFVVUMDx7dZxsZ9PqeCTdy5qPddC5Lo4Rdm8PIZfxIuqAuVuGv p28+88KtV6WDXB0kaZuLw6PinRFBdq2TmSrTiNxVymOxDqGoUTB7WcAgkTmY6D2qBk+sTJFr 32lQw509RNm5V99GCPHCh/aIEyZTBC9jBfKpzjeLRwHehvoMiDvMsWoAvdYxGLyYYB1r+JWJ sgMTFas0/CGAD5h+mcGKRGrFa+CQEX4S7S6aRl0VKf2M3UIQ1YSqixOhgBIKT2Z1owLHQ0Tu JrM2uY8HpgdlZuG5I+4yaZ+mpmQPYckkUk5CDAM8xNa18NGMWpR1lSWVZfjHZ88B09jkAFb6 yu5bcJaHTERDgmiaoijLZHbObE70QpHmAkcj4vdOUM2W/oZjMZcybNAMVG2JQGCTPDsEm06H xg1MXkaWw+CJBjoxqJ9sxTY8IGAXAnqoxIMi3I3oFrK7PTUhlxm1YR7iNB6bhTVzBr5XCGYx 03llZTk3rA6AG8OybEVCwuhLijw+RIg34HtpJwoGXxPnXqjHZxRSOSYFNKlBV+WKcf+xO4fE zWI1F1Oim1afff0bt//cP/qZqHl4/f+9aVM6HaiCCKbPibN2xDSfSasCIUjR5aslymB53Ryf wNwCHIY5efX0MskBwdhAoQPLjUHz6fVZbt0/U+0KL/jYX/7Vv/03752225/4xCeByoHtkx0L Uce4g9/3Q5TI6jThrZU0CmxJ1fJcF0EODPo9NaSGjyKWN1ULzkxNKepkeWh7cp6MSSAV2Nl6 9Wk3SQDo1EKD+M1Seoj2tgk6mjPPrSTGfsjZK2G2Kxp0PEVUlVWrjRjEuHbGZXNn6nwS6r5i zMVUqt7BI0/HWkH1s8AVBY3cuX0Uvj97+Iktp53thkTxkiLQop1UnbXOIV5wTvaSZKbGOLgR 3+fkR0vfjPhzFfVN+V519chKGL9gBcS8ydHSWRyB2RaExpYhI27lBQePIbyPaykpfoGVayru 4EQLUdc1OzYZWTFy0rkR4gSOFM1G+DjrjVeGOs+CVjx3LIAq5IvLNGFqaYYXlmq1g8pmoOlj 5Sqwg0PEEWpRrwefSSivQ3sCbwEmYEinkTHuZEpPGlQ4Y1yTDWHsCRIxRnFW3BecBIQ41FSH 1U2bFtj/c4C5A8AawLiCveC1WdUvaQVHzz/LRS/U5S7O8FxOETpUiiW3Cm01hgDQCNgKQO6y iuHi0CKh+Dcg32ILQo0CMsEyboAXJXjrYq3CUEM6gzBj40wPQ/p2eyYs+O1mi6CGpfwTEArU TyyRUrNyY0fmEM4XT55EDDLo1liWUHswk2Di7KyJu+A9orapQh0bVELmuGPiDutrL3SxbOMh jBNqI0m2b98xDXmA7jMbY74omXnYxE2pU2Qdv/vuu8f+8prXXDsRLSKKbXijgq/gnRNuPtbq nfplmk/Wqhaw8pQDjM8mVLTrYiVLpyMVk0TNCeGv6qIeXYm4FVEp77rjjomCkwDKf+qTn6xT DTdCzDK7ZKhAFaP2YJgLGprawNXW7UHQigsfS5ORsXqFwEWmWyJx8vS+xzrN48mIwCH0kiIT Dl0H19qLjz33I7RKPJtNrHY64iFXy8Zbb480EXq9vqHvOHto2trqpvn1RERan/nDw6cH6ns7 noFpsIGVIihl3cZxCba2Ed4gowMSwRx6P/HTx0IXdBys3Rct9OOFI4x912/Himd9l9N2WQlL e44rJP1eKzlVYhaDzgD6t3KJnTOwAwB+2iD2o2Wfdrqk6PI2rDL4jDm2WLRj51Ka8LHpNmHZ w/XlMJAO1PIb4SqLuqy4aXnIJ/uC+y2JDAGQ2ccytSmTKMaAxNTX6ZC9dQgeISMhN8uK9mHA FlmmOGNrEbib4GwA1WnSgrwgl5hPe53s4HPFMAENPYo0AzQMMa0IEXp5eVkMBzgtLvUZ56wi hYh5vHQgzwYmolKbTcy3YitEeDeG35sJCX7ZY1oY1oTZ9gyswlCKhe+zs3NQgQpxq9lqQSwX DcMa+cLyGdIVUGKZAN0Z0KFUkB56vyBLACKXx34H5tCcRJK7oJI3GEACq4Jp5CcUgJiIbFAl GQTWlN/CZnfs3Dlx0Zybm0Ovb9o2oTFfKSG31WwZqwCN1AbXttbC3mCvwvev3/a15eX/eX6+ trN661t//oMf/IuJ9RBE2AyCrOkqoV42+KCQUIR7Gss94EYQXAihv4J+zlSkixqP6lKILvkp dYft7eibF1yHERwY9Cyun8K1OHb82Oe/8KWJ4MP/8tf/FVILdqIYqFo/zPhNIQo3tVqTwQht 7RgmA7QC1g/5FSPjE0UMxysOhgd0QZOGjbvDf48d/v6FZ7w0lFzwHBnBVDixIQlfi80DTz// SGTOlNjAAHZuVnkJyMNX4caL7gRnwJO4+HZKpq3VjPTnMh8c9nuPnDiIyBsbT9SvHCWQUfNw cGI22SbCuTYD8zX0YKz2GscP6thO0ApSYZdxMhFr79Y9cHJ1ESI507ByAALxx0h2AZdVCmuj 65njF3Q9dPXwYjgiMawUTnd9ZUuORFgKRxStoEdcx2Mv0FTrVeJx8zIVziFbxdADImk4NRgk yCgnVYId12oevT4asyWpAihK3NsM0xDEEKCGaDZgqB87hiuI30GfHkDHNkuEWHhzqNI46qyu dgp2OhazFXCrS25aehVsdJXdxkRHU4B76nCXJrHKe8YEZ7GD5zFVoerANjXgvRqia0LNp0YD /6ycdPMARhdmLS8pWMbrx9PJeLsaViFcgYyMGymsSMTl4omaWTnLGyt2Z+zXz7gs+41Gb20t rMp9rrYhz7G6sjIzMwPXrvmFBcAv8BVC2tLSUkNbynbm6ULgJwiRYb6FeMgJtRd6msoJU/Sa 0uLDTNiQKhMVj8zgzrhH1r2d2J175JFHsfd4y9SOZYSdte9tNrcUvSguwtutVjMc5sTtcAOH CLbNxhe++OX4LxdduGfb6adPCwrK//dQuBEp0lHZiHF2WsjEXRLbmEoXJ0s3yujVOycGa/gN W5SJCbtxD92pO5GBNdAzbDORDoSte+65e+J2fvSjH47VeUZ2dhHYJBInTKsIk4nsWxNk1W7g BkukE2HOuQ7ZMUo0+qdaDlJ+NzMb/gn/jpxN3MOfHjv4/aeG31tuHzKdQzurnZnjy61D3zv2 93sPPOQ1FsIZQEjiPF0XKoXqHLKAVAZn3tH6Y7zWER/L0eq8O3tiaebgwyfvOrb4vEo4OgBe Rp6LWL5PaU+Hj++viqEMv3xdRQFAOIr48OtzHR9N+dA6dhKbSqsgedH3cY1Izy6fcB8ZfKOV BzxFjNGo0YbmUuWSiAyQWElkU0wBoOskDDMwcKIB4cM/4wfZ+yQO7QALCOxF0Y+QwgmbRQWA JjmKLac3P9TZgY+HWgqqK/QqscOAkITFDa6eMqXj/waKWcM4AAtXAc+5VOAkPOspsQKgNdJX mAbrvg9hXFI/rV5qPjgXSxvfJfV0hp8vGt+iEvUSOEUMWlmemGnZnCL8Zq1LH4d/snxSZXAh fCftq6JhUc3kqpGbmpIhMBrIsOHvAbJpWYomYdglGHeZGEJ4DbHE1PpMfMCV7IxKDhhF2KDw 78kfGUcUQhfgGInKTc3PL9jMDGgpFoiagS8z2oFiA4j7GHHCJl4dVe+IxSOmaW1YowNRcCL7 mG47nvGEA+50O8tLSzt27KTamSAp5cQAkbJZDskokJZoMnWW1u+P+dmnqn4Lx6lEpSenAdmB SQ07c9ttX/sff/G/H8VuvHrKEXtDD4ebvk1EhBJ0xWlOXXSjAcyTVJYaWwue07HJ3sr04Fcj TUIMsU7ZLwXDMVGPlUJBTWIINBhinHvKAq6GRGa1HBSeYFwXSzYjc6ZSRXizUg3XFVhYpmLT 7tUpyln3xiAS+MF0I7V9mCL2oN0EDYKl1RPHFo+IvqISpYlqc1JKFh+J0yeR2VgOaEZZ/WDx NqsSDMo1EL5tfFH8QyfujFi6w9jOXA58sYo25aITUi2vLj6U1sZv1UplQyZ72Q+OfBOVgeH+ 7XZa6S59b/g1/BOkzhjwEpOpMbzhpmut/kB9GG5LPty5cwQp00lU5MxlxBUr4WthEaVS9YcR Hwk3wnmIpQtrmhrTyLT+luLVCJGUpjSaceMn/iE1dD76HAoA8iw6hUYrIvoYJQDCuz7CgqLX ZBZZGUy5GPm2NlzLZjKBdJsBt3IoCYNgRMmMsnMiBYfqiu8nNDalFS+myYYWXDN8FuNocjyJ pnpjBxt+JGGkYa3kxO0LLpUSeoslrEmZ5A1qYyZDqbqwb5Bn7Jd9aDilQ7Hx67MxiukEIhtE EtxXueFhIiXEkFmoIQLRu0KcaM+gwAj3DIEpqLpNgLPACtYiI5sEAUxm4X68qAhvbCq2nhb5 noD+BqprkegUH409COq2lRBmN8PcHMnhrjGuDWMwQSeN3C6aYRm0A43IkUd0ek+Q4rOZu0wK NRiHkWIxp06bNm8OJ5Eao0k+Pze3/vUrK6vheEKcC6dyAx8QhPcaJ8Mdi5nmDLSAiQ0HVIy2 iTZCA2bpY48+sn//gV27zrRfvvb6a6c1SwG7IoEv5T+SfNkwabfbU3bVjB6EbxReWXLKY8ic icytWKzMGtk5VyBT8Y06iyp14oXFelhqvjaszLp3DCg4gWQdtQrR6hwZv4lpgBuV2a3sB2tM +Uh5Ie7zYaU251lTSYC6AYQSRISqqmcYkPxBAMMQccjHxfeqdL1IU1GkngRfY6BkWF0I4VbC at1IV7xGEh8UeKloDpvDC05obEY1inoYW/Sdi9Z3Q7LEQoh2jBjhwPTeIpn4sKi+DIpXjvE1 eJgKbm6amYki3k4LTa0W4SNN3vrZtz1XbQ46Ol6efBwgceOZv5fEv6gdSrCXwlRI/IA1Th3n YQg/NCJiRodBeyr1LdTxhnwE15wO4wMWUiliOL4dQojZJK2khbs1AHCZIIWNEZHT2YyrpE0N TGP4gSpFJ60L2hNXN+eREIfIF16DRw+PIao38bDv9e1PdTLRp15cuChd9W03twe7ScyXGY9t hjuQDdXDB0D2t78m6z5MWwx5EQssJWliEoU8UZcCC82eIqFAggmLlG76LGOdRPloqoyhhrHk DHWbeHcp08AyBhORQrGBEsp6zqLbx7+H6KAlbTi9KysrNFhrNsNGvFpQJiyWmKjaIaSkQFsG ftob0Qx/K3QZDWUauNNQaURlN22FLdmsBtXl1L5Z6hjF39FukuDfwg8X7rlgQufw0ce8nrKp LTKXYDCYqmV1uNJ0bRheiKIYuQM0VKaov3uN9tQY+ebtd7wwGMgA3IuQXc7OzEIGVEuEdFoc KPLcnhzgoywzoPpyUnaAbgy6u8AdNdQkWrzE3NTCa3QMlADFayEH6pxCMd4ItOmsB20Fb3wn uNFu4YhQrN4z6NhhWIUXR+wumWuWta58ZT+LHIZCP4wTihrXa9cRQy4clGLzZYIQydVXZoeB AlQ7KllmsjrqjhFTXC2fK2qhXh9x1KwK9zGR1gqXkao0StiBax9jEcSJGqZELGqcxwY0huPH LIo8iPNC1cfpP2K/svCdUYwzLSvjUsmGwZX2veNbV2mgHto8FvPiS8y+JzVrGAOwUQZ6athR oIdMnLMhocvFNGoFLua1Mos2O1IexVUKkWe03jD2sczFkrvUhqczKpWdbeB9jKpoZqdQoKD6 jN8X7o0W02ZH+YhCGAeBUtqwZQV/PgBSEORiqo+02pjYihYLohQCFUTgANlY6xKnijRwVzsY j4UoFVs3tNqteJd8Vc8OQNCGN+/YJaD4MRjCFXa12zHVDzT6bAs0D7MCgEMdVXJagkPSEDuM URxgihBArzmUPGxCfoz6zMQPUXX11ta8ijpBUGNotxbM29gzBfhBKHRA/xdzMgNk0KeTtJdK HQKQzWg0n/Mgy1hpeAaGdTY6GR9o4vHTwO2l8KVFjZBez8d/8cUXrX/xkcOHcAbpzK5N8ffy PoRD3CuNtFEv09AS5N1AsxVOBxNxfSR1vLwiVaZLP/uZz/zSL/6TU+Lw4eqNSazFRcxjp6I2 vGS7JlnmlLsNrOo02AVIGCgv0ATDh2YFz34nijemsksmoigjkLKyOtUnyQtkIQgPX8FOsXJH LaweFR+6wOlUnyHo8J7g38QNxooVV7zdWijRLJDbKNiA9dFQXWDQ1jCMHMUSSGnERt9g4Nal W2QwBsU0nI9CSE6oUdwotESYBhKM2eoCW9Ols4oLGhtmjN0SEDGyWKVsaJhzVlEb0HOAEVzi +j3hT8/i1rQFV0VjsGKX5Dq9kjSEmtYnyKQ4wzBMlPrSLGaapyDnxpV0nJRAyZ6FKkpMKMmd UocROFE2hTJLNqeKX+S9x90qaJrUs1KduqHwAq8Le9Vd6+ZiY10oXtHFOSXT1bPYWrMcRUG7 0Wa4uZlYSJB7KWp3q6i8kP2xdnMrnrCgJQ+6wo5JWKpk4TZ+y1hdHru5UnbOjX3M7WRnWEJa fF+1Y2+gRZnl07o+jJnFiDGe3Yat4iFcd9IiTYMs7a524itr9ihDJgOEFRIG9Lmi+WI7J2Aa 6sKjyK01OhTVSvon7BWBMIw5xGaYsqbivMI45kZdqKuAqAg7H9bzTZs3Y1QW4hpRueA2VxTh Z1RdCFWiCdaemcl13BW20mAch2PMoou08e2kT0RtIE7grE1zkmQU/ww2UnLkDwf85rf8zMLC /PrXP7V3r3RFe8TWnuyQwvZ3ST8BhEaBwgQTMi3BsIUl1rAnjltvZeLwbHZmxkSYDuzf/8ij j1980Z6NF3TkC9z6KyEACsedKhr2TngXl2sgYInsPcTNfLVBd1TqdFLkS0wezZqBU/le3N+3 GS9CyAiOnNd6EjGK9SYmzQWpoMkkFcDDti50uah5GKMwEm5zkaWg6W6MdVMZHy91GBbdsUim 8j91L0inWR7jKxPnYAyXuLFgefIyB+obDi3TWZeT4RkoQX7MzVnhuDaZizqlPD3JBDxZWH1j rOpMEApl3JZfFwBKuxQKaHTGvsC6TzJCzdZAIN2iPo5IzzVI3UiMSrEk2mACyVfcmYS+k9lh Vk9PU2HdCkuPSz00uNqtdhwbmLVS73+tZ5hl4FeNSC1H/s5wwsPYieZCfKtX2tBW+IALtyFE mATdw0EUG2QIiQDuzVsLmHiFMjpVA0lwWVM1hKNfDisTYRrWcjC5CfHTSEmXewoDZWJGCijQ rdFnCEDsdtgxEZQi2FeVt0gXuxuh+DC8sGCv4vHCv7SCfpAMiL7J9V8rb2HaFJ7xmKclpnTh IiacV1WshcGIETaizq1/C1mJEpNO3PNOwrP4A8uFo2pPDllne+HWQDCz9qMMjKJLD5pXHJsx fltdXWnasMlJuYZVAA1AuqnYuAvwQJCM5RlhpH632wkRbsjiv9TW4uZfl7uXxmJG2AsBL0Vr AvYq7EJSWy3gA+xPWjW7abTieg5J49DJL6NdYZ6aV6L1zp073/72t61/5bPP7bvn3nukFqyq 2dm5iXwv9lYVezQBcbLE5MrKSqfbASQESPqF+YV2qzVxwAa4Z8FSdFjavvLVr54CDcEtjOWV 5VWWMxmIwFcPEOFqqiIJy4orytzQ56DBj8jNjiOrlRpjtC1qOxSWG06cltEymkkLuzK2pn6i jM2LWAU8m9Y5hIkXysoarcQ+66ruODL4sRtmoLe4AVLWKyNE/Z9Mx+x1KM106m6DKzTo7K8G pPTsNYUIDekBPl5nSr6luutWfGacyEXGZpIThpSjkARv8DkMVKJaU8whOZVx1gZEYmdTkPVO K5rduzhw0pZL6WXFpyJN6+73aOgCWyMzjl2v38MpDWWNEr9qV7MQ0goWRkqUQmBKSySgVy/u 8SyqFoAYORw/gtsSbBe3EE2WKVFzRTRs4Woj+ZNunKsrJ8gcPR2Vslnjkad1d+HEbX+1pEeR UOQsg/uh8pU3hyDtIlDPxtdzI27dJ2PlESotyGHHSGm048Lq1CwaszOzCLdx6AJQcIyog4YT oHmlwrV6bD2jRtVJ7V0yGGJxN9Emk64RlRy9BLL2MliDNahYBaPR8KpYO1CzDrxMiFaKLwWS DjeDJCVebnhAH9BNJXIkHwt5nIaKotTdM7kpbqtmLBOHz1LrA6E2m2VXwXMQsqyMOMS93pq6 /CRO52GIFGvs/mwoQomjdmtKF5vPKVhp5LlM8O7agWkDqVwyI2X2cfgvy/JqUiJPriJZDtlH r0DBP/rjP5poP/8NNtxiXLRmCtMiIs+BLDjTGQ8hm43XwvVAlxbfY7G4sdW5YOdy42zed+89 G0evjFuF83Pz4caNupGOGwhrG7fgQDmCWoyNfDYovCyPA5kD854avD6dW+a18gDdxACyuPtr lyPL01M3bWBpnn54bDAw485bGfuDKLq6zrudAqzHEBmRIdRI0WA4sXjERXsojZ0S5dRQZ+9o Q/myijjLsrJn2vfwrGOJRqLVHAO2xrCx4sgENFolYxqGqtP69QLqY0KOvNvauytNTzaBKmYt ExDNvVUS15sEUSGW8872RDucmfHQyQ+lKseoMJZboLGGqZgpnhmUPK4sdZ0tDfkWd4Ntqtej /KwaAxkiwNDjMxgYOnHIQHldhQcYuJaasMNr0R7GsIwSUJ2++omKa4SthdRQZsu8BcgHm8IT HybwhxJO4K3sOcCU2tH1kWmqt6fJ151DYUGV0hGJVbDXDxpSwQQKKE64w4zjMEtP4wVVCtIb aHqNUIGTMBAh2T7qPJF3UokmQ8/BHCrjmgn9Om/CRj6BriDsuIi/rAEGRLo4vKFLCY0okz4A vxgx1YKZKWhEw9fcOMhhh0PdA4Jvh4UKQ6mA8z8/vxB+GXaIxk6ZoO0xigNcHqYqGCGF0GXr tsnGJypM2O12AfGLb+w1mHtxOUvhAw3E0VlFCvFEej/fRmsq3Qul+Y3WdH62FP4w/jU3O3fd 9dcDmBSux+7zz3/t9de98hUvn7ipz3z6FgNH5XoZ1n9dcvHFf/b+99ey3D6J/eDRMQ8/Pv74 k3/yJ//Jyuf1BZy1lbCS7ntu38bNQ9bakCcfqwwERkV2S++DdQO20homdHQJt86L3KhIk5MD JywNmq4leVaD9/yGgzmnXo6l05Y9AqdXrq6C13P4QiXTnAG8IPdo0UnqwRJ6O6AeR2HJmWiW 5d2jC71XtILBsjOrzKI+pDcgIs+HC4MsmqeJePSxagOeCvRgY44qNAbp+dEqEztmroNGsrZY jrFN7PQRr9TcuGhG0yln4txJZNgx4i3iGDrIGD/vkmSdtKOxgE3RGL/BpNBy2Agh7GJ5iKgr 5TKaFsA1EbTiwvLfcIvmEhENeOJHidgWKQ2+6GPkZBapFya1S30WFps44NWVmatA9srKGu5L tFZPbFnck1RKKhqQ1e5zsUGJMJZpI4MLJW1Eb79MhFoykxzLGFLrozEtrKoypQbXKrRWUKpi dTWsjPMLEQqToqj1HEotc9DKS6TrCO4KBDMNsNfjPB6IaPTQ4qhPAA3VXorHMRgpxUJueUoC UDa+MXsEYRDzv0IUUUP5HJ9lInDx0wdhI8FAMscLCEmLTCmPJKRdqXe7rcPSY+TyKBzUzOwM Go8Iiq2sFUMoRzC3QPAP+mH1QGWWMdKiyisToS9Vnz5ENafVsLUK0S001ahwG7ea7JBm1GV4 aKURP8DOdQ2jn1IAAXJTMgYfpdX6r0svveTP3/++F4IR+NQtn33k0UeUuiHshImKTQsL8694 xdWn3CAmNxvMltABo+UslxXnU7fc8m/e+6+SDcJXNMrCg+HYzo6UotpTlaKAqPEhS1Wl+SIT 2Ou0mSIUtqGQFgIGPk4bfRtRvqT5o4yfVMUUwuHGZKwINTCNZC0GZmKxyJ9eVWXU8nIxugGr iVP1LPOtj9B3MnpBlyjCpotEEBIhjjQJlq1mI0siwhZiWIWDQnGjKovNtACkQkDPReGd1Nyq s0DLJRbg664+6/TN7oLty17NxsJu3/P4/JGTwyefORbPKsCuZcxhJig765qX1RhoZUSsj1Mo cTWLBu+J2Mdk8bAqURy8AfwMmakzPzmT2PPzty87U9tMknsemzu6WD3+1BH1oS4NVW9iskmk ZIjOZ5plVvChJCSzq6hWTrN0VBZA0CXYmVA/SGaj3PO6vOaoUNd2DDod+mEjZ1OrhONBSsod CHJQ8wGQMrxZL7pjhl/YezEsBZUCKoLct0D+gR6S66GlwQ87leANNKIpgSAOXzJMYlGWUu6l LHIlrFdhaFInw3WPpIQ3DPBEkAJTMa1sEIbHSZC+sjgxJqATa9mYFi2ameEgiEiqLn0px0ub tgKbLrwuXipD7QK5BhRVMEAhfUIYKzvpRRlQ0Dqc8f4jiNr0TsQ4UoEXYi6D4mcYaXGJVntW K+gSLi/Lze8eZ8Y8ijGlw7RsdXUVDVU2DxuEdS9UdZY7AihPMvY6WsstdAEQD2n6GizrxQhO yG7T5XTDPs6yJLBQ7l+Em8nS0vL7/vRPwgUIhwT8PR15Mhm18QK/vBdyQzKlPzdgE0J+jFGO pPfcfffG8ZCWM7UuhPst9Tcwho1k0MZblCoTjEfX5bXefJFP1eaPJwqW5MakosnHrOuRjqbK NLUDHAOqOZNRmEaqs9ijKXYW90vHoNgxPM+ADF4loHj1cfHsympTM9OCVp7q24rJHv4pzLA0 275t4ZdvNItmWsL/8lZ/5OiiCBaU2rYKSwbRPwdRuyy5dM/2171k2MxXksipBLXvq/YshR/3 nrvj1ntPrHbqxkP4uF+5MalFg/k9f3tHse/AiTh3vvaqXa/aUytGfuuhue8+dBiqhv/sZ7cs NNfGLq4zsEqS7Ds+t+9ocvf3n09G1XIHIhBMO3/ZhTtuuGLQyFbkqPUGCf989YWkw/342Ttu u39xeaUTo/h2bN/0y6/33o8ICXzijsaz+45Zkhu+v+bKM/jwZyo2H/lm2PkHD4mnAa6XkzoV 2rLURSYge7jKGVhceHzYubFBQ648oXCSJhjRe616TfnF+sYQ0Vc0/BCk5oilU0bN25pir0qJ nkEu5JzSbLpwuliunrIuoXPJs0ARUdxDfFIDuzINDC4dG3aS5qz28Spf/wC8lcAT+n2LdsTB 4m2KVzJvFhgroCvxKTBsQn8M9ZYQxUb5gogls8WsaOUolj18ClwuSaupPWMPXcYNwyoXH3mq /NJaT85x5LNYWz+nLqyL3I7r9aGTi3au6cChVhNJ8RAsumvGpm1yILT4JGTQoj6NtJ3ZvFJn qJn2DAIeMBrGogOqEMBCrucKAr17H8J2iEpV1AuBImIGpSj0BnF4fQXHyxizLEV+WEdKG1hy 0JhOqU5uOrD+lKHr5ve85+Ch54FLCZentv56ESq9jgm/eJwmxodSPBRSm8mfPHHi6zx7m7LB BDYKOcvGgMeas4IRt7kH00pA1P6yEpH2TCEiNzyWm+YUAxgVtJHUZD1N01PC3WXSoeo4WRI1 g0bf7ox6NZkNp6dlrCc8hgaum/syni3j/ch41MGrTIEXDBhZF4+7TI/DsBuo+RgLlxlGlDN9 sXcSZUEvmoDAp8C/CcANIMQQO7HNn75g+5tf1m1mAyuHnJqGWK5w3ulLv3D9/Ey7MXKuDFoj Nh/+nJ2t+DzpVfGjTeZq5FSuP726+V1bVl65Z+XmX9h8+cU7I3qW55qPtFxD6HrTyzqNbCCB S/fYR+2APTtXwp7Pz82MCRHU1D0NYT+1o1VPtemm9W4MjKtmj/VqXtZwCWHO9tYgSusjRzT2 GcnY7BFu12K2ax514WcklAPF3VFvkwdIYjNUSfJRCdDCOpkeJkSUyWn/MIKSlnF9qRztgQUk 0gjmmSgcPQyJZ1WIGIWo77BTjTRUWkVkC0crdVlDkFK902Coa39CEKpUhCM87FA7XGXLD0yz oHrDaXTfYA7U+Ww0eJo1YPXhxER78WKcT3Q4QJ4rpXioYsJG+BMYxFLzuaRmvyhbFNsB3i+J pOCw4LfaLQHylJV1RxHSkI4A/5Lrl1VdUrwysI1qJicJGfqcIe6G/xCKTBOEB2RgKJKaFM3Y uIjCNlF7FSxOn+I2SiLVRXw3FicOqaFfG7hTWg7yYzty3Xvft3/1bW+77777Eh2Chx+2bNka wrV7EQ4p2MGCM77JuHCH8FBhOBwSIlz7u++595SNQ1vQQT1mnHFrWu2VqIXjkKFx0BRQCwlm w0xkbjmb8ZTa/JGZykYCGSoniOaPFXbQQVHHqXIM+Tb9aDGS8WP8p3XvNQcvH4Mv0NtR0T80 sgcG6R7j3kXaFpnWi5Xo48kOY3JWGkDbnLDincasW1CaXoEqZdVqFjdc3vcGq/BR6210nHj6 Que6l502ap0yfpovOrMXI1aiAZIfrVxHUxM3XlUDVSFuy/nwppeuhgCm3APRL960MB+qLmeP ghvFSkbb3L7QufalmyPCONAuqvyrKNafPrtOs+BjkuhOICdgFdp8lJyXJqO63jbKhTFj+IiQ L2MZEU0yKPJVMkmyU1PpCMdgy0o+SeO8jZApUSRAOYVHDE/QgB9bRHewv3lWCniH1BycvJLS q8sECWm7hMXaSGkugpjDoFnQtuxFMNDJmXlZmWq7KP7pg4YlG8UHDItRwuYcutg7LUf1Bt4u TkqmfUVjeoHkBNwgUYAZyw5AVggqFBIyES4wUfJSpp5VvGOpGrtXyr2zaC0gIMlOU0ANZmZn hJTNIBdyvFRgJJQTSBeCP92QJgiHjUhOVsB0kmynIntE1AjRPg6npWBYf/hOwWxmpj8YdDud cNQrq6sIYw2uCqgHzK9xrKBIIiDGpsRlRuw12UCQn812hVOVclqSD6oyGq/TaoiJX88+t++7 3/neV2/96l133pkoTAqEO8NNUlvyxQQvJgaxUEo2EbVBhqra0xP8blXeefu3lt/zrlhyfiLT 2YAAkHuYZsccN82dzqtNprOARM1UOEztlTWiFO6RH7lpQHdlEfT4ppSRux/B9UUSShulHQbb dxFWMAbsCiI60k1wpkVkk4zYajJjXJkCykuk6qHGgkbf6CTJC1tAWa4AbnBIyOJdRIchV6Vt zwsTlB7x9rALV126rZGvxMHo7sfm7vjOvvDzjm2b3nD1/FlbVkjAD8PaXUv3b5k7dmLFLqvC gtDt85tmehecu+2xvYfXTbxslfYyW4Lro7MQX/cMXVSDaWjyr72s/9RzzU63rzhGd8WFm1q0 505B6jTouv07+xLs+cvnz966agH4p89avv+0+SPHlqW2rLO/2vVsvtnds/t0TPjQQB57cEtp 3ImOu10OPskFYpf15SDyqTRwkacCz8yGOj7qwhl816p/F8EgkWtH1mheK/KwRApOpOJhOKSh EEf5zoETe6W24x71n/mJWMcvXmTrWygSD6TqSnEZ8PqCOBOqqGTIa8WwSiOmvIBLnQDTDS8X f1B4GZWYpfhgdVY75oEy05wx2H0SCffYEFFUCzJFAygSGJruCE4IGEISDZGyaPCzXdkjgHxM E3pCf5TKnqYX55URyQn9RNwcMSZNK2Q5PHV2wq120Kov1zA2iwdm4CyBdoaVHO1TiMoKJwHV ObjCpGLVDJEJpDSv0zIlU/dAuzLLSTmz0NmzUZtBXPDXlZUVrOnf//73fv3X3wm+pBAn+bZ+ 7LHHcJapRC2rW7/y5R98/3tAHCQK/PPqLYs5dvh+YP/+hx9+CIEZTAWScG4QyxrIe8sswtet t976wAMPALIo2tZO2hpwczCFUBd9Ct67urICdno4rb/1278TVnUvhIYsvHZxaSmDkggj0+QW TJITJ0/83r/4l+12uw4YugIcPnRIh+qC4ZZVUnEH4VNi8DeS2ccefcTQRCSukTCBlFF8UE77 wAc+8FfE5ss086U3Pv/883YH21Ie56cf/NCH5ojHFo6XTg4mFocPH4KvBMDKhIxwNWFAlQal nELd+dijj/7O7/4L+tw05pglTz755Bh4ekyKJuo9jotBrBOGkKkVcB/O/lSKhpPCDUzDtDRK WaypUY/W19VFLYbMUHWruUKp4CtAV67cPTJ5+u5eCgBYJY8eX/n87YO3/8xMqxgmGlouOnf+ rhMrtEHvR9l3MgU6/8z8iafrozaRKhfXXnJ/utjr+VsPzn3nwUPY2AXnnv6qi12o9szeq5EN XnLRltvv32dpx8vO6yVwP+EXfe/p+bu+dwCn4vDRxS/f7X/lpmYjH1jgDHse4q4iLGTGpgWn PCYXnNV46jnp52ClgH8YELupUxxKVotZcIE1VN5VYqhOiGdC/x86anCph7It1muAAM1QsJEJ wss8KhO4hkaEbrMlM3lJls6aRc4EXA/uK3goI5jlGtIwN63vogiUIX3CZg4yE0ZZok7L+2nC ThZ7sIbIRGfQH4MCAG4EEHwNmVapAQvYXkUU+6z9aDq8UKGMpWHiYRjCksxx3IjaL608hfbr 9OyZYn1voNKLPACuY6FWS0Sl8oKCTot6XMeWRkMMFWPcA1iDSAJcmSz3Ou1mC3weceTiQEun rhqajlQNReGt0QrPLcRut4OKc3V1BfuPXqKwsDkMkUlKsxkeorCrAGcsLCzkGHEZnUv1gGsx sbpfzJ8dVtLPfe6zrVYrXpgAcxQNRwaSPsVfotvL/LtBv48dCsFpoA1G8NdQbGEMKLNKZbpB FwQp0t69T4b/TCEN5zeEVbRTw7lA4Wh3G3Sh6NqsdsDnwANz7733WAZUKjCp4PyxkFZ+aQ/G Iw8/DLwAulhAw8MqEOSwip9dJHSlTkrDg3r7t76FLAOfpYV5ZnQTz9UAPteMwEP8QP0xhj5f 16zzMZ7t8ccei6/U6KjDic1jI4sKRI+ZE/Ba2GD40MXFxW/fd69XqaRkNDiMKLTKvvlY2WH9 HC4S/asBhFhHnKpdWGTCvvGAylt9ZuKHuLJuVA6/xiDU5YQ3hAjyiVI7+INeP6zGF+w+ndf3 +uvJA71YJmOt139w32lX7V5OxCfZbd/sIEIRKzDpj/R/F+xc+0pEivB+zIvOSYfKj3ceoyrd 7X32+MHDjV98w+ymdi9R5eDzdlZ3C7GhOnvX1iZHJii7Ezrj2a6pfoR/Li6tPrx/y0vPWbIT s22TNpkzaGxMqK0v2NH9il5ZhvxFPqGgFgHRE0n0qmIcLWt4iBism9boBh5c9QYkAUpEKG7W kaKEH0DCI1RpkKBN1FpMRrlETPTxzKYu9DMZa6muq4fIbzzJxgI6po1ieh/A0wO7O9YBrswl y1MkqKAzp04OhukAxHxmdoZ0MViIHcHMBAHaswRLSYeCYmB/51CRzCSlnNW+Oi6aJWGp3GFE HUzFxG1ENy6jI9s91twxoLgR1GKNmLp7ORRzLxBt8UFYdswPjChJartcm8to6zKL7Tu0yux3 1GswTyFALJTqwbDVbuFshJ20pp3dGGTjMuhDwBbxu2iIeq/JZaCXmPAJIUh9pyM4Q77tO0wC IzgiKdJj0cfoD5GTkzJuX0KAojBFxfAykehQWfua5lzS4NFgOdgboo4pQw1By8XkcOimcDdT FJr7/RgOgO5qTJ+SwakuZBLzAHpR06yxZIdCHUgJ0X02VC810eouqGUP6HAuWgne2D85ADe1 TOpgoHKfggvI5K4KFwOpqGUcUQJOnbFCu8DCeQQkAXY4pfRhIn5PJBRrtPEsS2IZcvFHdJF+ lTBqrTbFfZYJhE/qZuTIY4ALGJdE76q5RzoMrpSua1B7F2lVuPjy6fIhaMZMxt9pbFbilafJ Y38fhy6cYUy8MT7x3K/PNPGsp7AuwoLqdDNzNSZYeiYuXZgZAXb2h/lTTx/idKW0sdzSqq+7 hIk/c0t3LHsQ+2ZFcISgctmF2+OGbazGhX8hTfaRZZeDe0CUI6521r6/t7C6Lfy/7fOdmXYT UgebZgsDaoRt9sviwKGTeDRsmhv2XI3n6NycvXUNE1Ako/rRnuOfbKrICAmC/i2lDiNFI5qF zjxsjXWOB4SULDQLSZm/7wh3ICjT8NxQzHC26nkwSUIqS1JnzUZRC8zTp/RZv99qERhukd4q VxUE3+CxhfXDIY1o4Q0ovibXTKOSHBRhbQ0h2RFmk6HfgxRHPY4JXoF0h+yAi8YYgD5y6UyE 4JypLi3vc48tu2wRgzAS3tKDSq9Spowonek0CCGNUDD9yPdLsX+qaJz4UcAInRwGVCeRGGP9 QzSHM73TZrNRo3j0wuUZFGdzEulnE1fbQyCenAoZh2Kg1+sbOMsKSjvqDk+t5HMdvabN1Y6Z YwDTb4GWuMmdThaJepveSs2BU9ggw+NJ6DLUKiQ/BThQjBazrwbTNhu8niK0ICYVzBpDL1Jc pbHYezrXgIEsLi2G3ZqfX7A9LjjUQfAj3idTkwRqEfRsk59HQodTg/yoy8Zrvh410yluc4+R xDX41Ic7z5m1KE87DbJpqRYs54H65ce71KmeM1/zeFSDTZhIbqkbxGUe2AQR+CLOm9A45s3I dkCLLhg9aCSkRHFNOkuoYjlwRbF5Ex612OAVM2ewcY6aEnohvTOuD6sKgQOxyvVxvInBabZm xWAKHZCkNikZnRz4mJqNdT7q/MSMqMykELjrncYiZLZeOMVE+dHhW+bSsfG+MtRrOEDpa2Ug G7FsmhsZfB5abOh0wTi//uTywGD04TtXPLX7osXyGINx/pnpKOrEmflj9DqfjFY2kciFZOIP 7z0e41rDa87YPo8bb9NcWkVdxyNLTRKQVDMz6NCfXBlIwOF9aObQ2vE8Mnc1AgdloJfu9AW7 UkY4DCxk151P7w2/Z/0G9OisEWcLK8pTqAC7aIyvaYQxoB2ilKZTABZK1qiddg+CGimV+CTK zMQSBS2TcGlpNVD1p1Ksamr5LvS44MTd5VEZ2m54tnExeoP+2FgaQyNvgkwKi7AVSVhQWZ2m 1wMXBlaoxhblXkBtWDevnlQpgkOqmX7faFJIuAkxNztj8RLekk1e3xAVCk2pY8ahHYWhHwnj x+L0rrYYlT6kVCfNBpBrPI7qIR3BtcN+Eo6aDH7bWGBxTowxhroNZQbIXkYbwHDLQDqSRmfi W7K8vORZ1KlJSLcGmnMIbE5jldcwkWlx1Wq1QfHKsa2QZMArDG9YWV0NWRK0ivsrK2PQKeor rlGbLh6MXXPttbOzc+LEQzOqr4aYR/6YmVSCpSoW4nT3B4NGISs1KRDzWQA8FI21GNpkaYiB owCVpHKqYNYFD5BAU6XBbJ5CVbpWQ3cpGrt0Onj8k42I6Y17TSXj4AsPYycbMmNwVSpiKmUR W8djv0zLCwYlJbhB+ZGTMVSqKw4MBtcD0JWvOtC6x1neF0MypEYpS+jH+3VtQ1t0xiRu+eea p2ym75EfUq5e78KWZTEOb1oMoB+tVwI07pd1QvSjy1g+yoQbrIsYA/HLSK/IaKSVqvKbQDBj wKpkFIYjUi983W0MaU91j9oyvu6G+qQ3dMBTDFUdMfzvxGKH3h3FmNNPm3/+yElr96Hq2n9i dtt8r5kNwj/P374y0250un0GPlSCyMAq7P06IG5d4MROVNQPWV3rDWea2tsMr1mYRd/GNQrn XN257A2tnK2v7OJKD7x+FOThf6dvmz9ydNko1dqS9PtPzJ0+v4bwdt72lfm59vJKF8uEi58I 5xCxXJR8gJCAbaa5aK+geqv9d3h58zzHwi6DDWaTMxNkiclYvNz3rdU52gCEMWndZEvgfsmi vTgJmQJ/TNQDVL+Q2kLgAy9Ax2zAlRAWHGMyxYYP/aEQnoDLEMQgS1QYKgFcLrFnRDeIhxpq AVzHPIuClXrEQG3ElaIqHtNyTSPDFBdzl1tmhtBC7GMvclZpLqysWAQEflpkF4XZTMKKdMTr Iiq6Wa/hLvKusuY8nDChYAm+s4wDdcG3c0XPWpLiCTUUhrHoYlI2lEcID9kbhkA115oL5crs 3BwhIbOocMryUAnXi3bYbEXDJqH/6tVvMmg+h+69WIeFK9rvcxs0g5VJ+A5fS5TGFrGGvCKc teusn/25n3vt9de/6lWvmIgkvP/+7/793996221fw9AriaR0Zmdnb7jhdVdccYVhExKx63Uf +tAH7JIb8CZ85m/8xruck1EB5B3C43PrV7/69NNPYxx1zbXXXXb55Wa+jgEPRwxppz7wowfu v/++uDGlCDrag5ve/OYdO3bw632kKsuzFP7Uj33sI1qN0et/6W2/UiMrkvpTGCrjDx069IXP f66Etg0jhVypKqVpdtXLX37ppZfZZMWP0oPCL2/72tf279unBd/w6pe/8vIrLh+D0R8+dOjL f/elsGqEtfeXf/VtUcou62Z9BtYh/bn7lMqHhcUudQ888MB3vv1tYwrHIhpxHDL6wdhAbkwn aVSJPI9U55PII6pMFb5h2upWiVqKgLUPuXbJrsq1Qp2fyEunJdVmA4k6OdHDkCatRlT+uJB3 w0t+gK4yZjC0EHshgeG14WGxt8XQvQefa121m0ljzr/04q13fe/gephm6owK5iIsohuNuXW2 tNZPm3n9Ea2G1P3NYiTR6g2c6mkZRaHykSANXWLv2tSc8IwDkrhln/rgvvbLdi+jwLriws13 f7+nyajD3AzPDq4CJpTh/DRZrh5PkGnKWEvAK+ELUYRTPZ+oHw1+gLVQGkUaYvpDuJZJY5h+ xfkrA+KLUpw4vN1gzSY6DRXkWqAeYD5t4EpbYgQ9AZpPD6tYj6Nwufmbm4dtNZB4A2J1jQs3 HSl1SDdhQEJ/eBn+mUS9AQKNeoyHAo2rqk8H0mQ53TSv4SHUamK4QAg2aS4DjlSwVwx8595S ok0gOFsC7Beb8dLvvVw+xBunoxPuu9bePZRDsC4lBj2m0xGipgmwAXcTQ0ZBOS9Vj8NU5+tw lTVQBQKXYV2QldUVp5FTwBODfl2eRvR56GylOg+DOBSGULkIe+T56upK+MNpp20Ln4qh2YCV EGdZlN1IzbhpQhh7x2+88z3vftdEZxN8/dTZZ4X/3voLP3fPvd/+0z/9k/vvv5/Y0fA4YMrC 5ZdfcfO737n+je//s/fVOU5ad37f9c53rH9xWHP38SofLu2ll13667/2tg2g6v/lr//22/fe o7I3ZKURVzO//Zs3bwyO//jHPmItxPD9nb/+9g1evLy8/MXPfy7La0gu8j4kyzfeeOPP/syb N3j7gw88EKKXCfOEqPyOdUr8377/u1/64hc453XvePvbkhf39eGPfjxEL6tKTPpvrIFpYJAx W5B1oJIRa3krAWNR9jSCgQGsNSbunClQML7vfey+M4GY4U2eThJkxcrDo3YilwP5O+qAiKhb NyrbRM7JHZQ0o6bf/iPDq3aj7k3O21HeNV6yu0jNJK3l2GOLqUiMSmZX3XzTTM8rMdr2t2ak SSPZx8V0PKu3wotoOrkkQI7rc+drlZD9hwdh5zH/On9n9S2upzlTG9HjgESkRBpONWrwHuGY CgDlwZhE9xvAJblPSgHdsI1y+BPSdmgRiec14O+cEtU2oXH+SpGJJ81DoCdURAZKUV59zGJ6 E+JZqlYyOvXJMHmUGsXAGtRGrEVQbY2mdb8paGRYh2AoAPsuwWl7cVgeAyhiSkT2uTkUCMNt 1ujqEmpYDMDf0ZLJkygwJCPe5R6upJyZjQCVwntDGd7Mgd7EAA85drjSvV5P3tvrm7K2rxcx j8wA55zktssRCVD6uIKCNFV7a2QsPDc7V580hRGYbhY0EhG3gICvcf+qCN/EqVO3MMTI8BZh 5iHEoneVEHaGWoshhrVnQgxbXlrCYgK/FXLwgvRvwY4p4VxTe7GgSq1gVnOG+DEYAOmBNev/ +I//13v/1b/cIHTFX6965cs/8Od/ftVVV3m9GKsrK2H708jHxmOweQBNy7qdKTxaL7wKAsGf Yk/27LmgRfB3QUkUilkgc+eLLto4dOF2KSsR0i5PJYUVtnbO7t3NZsME9+xxJZTa+eefUhzE OFg03nAT1ZvoKpfl8Memh48R1xhvMohqLJ+MGJr4uHiK1VrHKMcR2GTEh3c9IRrNQ0BF4t+Y pD3EVZ2WYgztqJ0sxrnzxM4xE+Q8XolQw4U/bZrxI1r0vO7hP6ed22MnVl1ddzkNFdYadTaJ e+Lpo4trTeZSue0Lna2bZ2O0no8wmVHtVQcQr6tuNFstrSc8JomyedbH4724yMCwJ/zz8NGl xGSsNM5CacIMGj2wIy557KkjJzsNzLhOX+jsPH1zPRbzosuGWi4sgqWvVLNKdO28IpiEySCA wKy7Fv7XNRgOw0UqBYLz8ToboJYoeggDx9BKLKbQiWf8gsBBh1xUYUZjMtNhmcTFI3cxRl1R gOSCD2IciepiA4PK6vRwbBkh2NbdTqX0irq/3jO1qJKLoG06kYXmL6mhR/gFkwckcIECKLwa CsculAY+ROfNqFri3Gu3sR/Bd8RNOcd42hAXO6sdBFqwvmxAqJigjjfmcibphcqalDrvFP/r 8L3Nau5DRcaT2TQ3IdEwbCiwPt4TaR4QL2sNeMKhEsal2ViSpr45rZDqLhdJnqNawTUo4BFG uM6ol5jCPCWUUkDBIP7x2LAUGD4FNC+chvCijJU8lIyVQaIjfP+jP/7f/ru3/rf/oJUxxLkP fuADO3fsNBFFs01b/4XRpVl24WumPTNtlY+Ux07BZ3751S+Lk9w4udt93vmnPIqCHX1gE/VC mNMXnH8BjYv5ueI6vZ4cnNL6MsrZ3TRFKO0auXy6tMc/9EsB9E7BhIKGZ3xiEYHyvfGm48Jo VOowpjb7UeBFko9iLhT0IytynX3zs4TF0aaYRmRxkxjVeK5KjXDmh1uLICM0pYmhAcVWQ2xN JuAyxnReTJYpHOnDz9Un/+LdC5XWJTVoMQ7vbmRfw0ay2gvGCWbBjTR6i3ycKOGiG9LI8mqJ KUHXRyWiAc+82kd6RqyF/z2kOx9+s+en5ghD6NeVh1yzcnO+x0PqoY1wjIqOgb9VzObrLObx GHX3+gMWiZBoyv3MTL2kezTwL7GYlnqlwmPDCJEBEwEzNlx2VivghnT17LDW9TcRDdC/6hIf 1xroPrVkTCILFYqovupy9LW4Qmt9WI64YjM3kxgOBvRAqujKcMjNogExC8GsOyn1HJtjAaNB si8MpsD5hIAFdckyEWVHuzVVaXwgXc2UGSPhSOxRHo0u0XrXhopVAbBOgCcMVSd1roGBSEsG c9amtRbt8MjUMkDasUdAKoejXwxVw3ZCmIDHlicl2D7+CiELVEqSBDD0kcRBCqEQ4Gc4U0P1 yjzewgYdtwND5QOSFZ1qGKUIU8/J6A+4ER6KDk3qos1Dr0svvexXfvmXfoxlMQSw3/m9fxGu UKYAkukLaJ1xhJBby3NN1K2QVD2l5s8LkJK66OKL08xQpal5ne3evfuU72WJfZFvSF+AkOO5 5+1GFwWKTSk0YHjo9QJPmg3kp5WVBkd88XHLcWuJ3aecyThZFDGZlWi+5Y3ePiqK4ePmoTJt bTxTqWRwtV5xyrg7mZo/2Z1gy6m1NcbrYo04eLCth4MnHHyGuv2oCoGJWiZqWQy3BB8BK+r6 KZyhGtOvLZinD3Tt0y85a4AJ06h4U40D8pWPRaRw9SJ1zUyRiXUPsD8Q2WiEaxW1EmEpgDnN VbXiyZdMrXguiLJM5L39CM0pnKWn9q/YIYadrzHZrg7baVYzHDB3MVHdOlxpEYOMPgQMFM3Y MVwvWcfVVS4zAbCyjLVgMGc1YgVYE3Lp2S8mxltZ1MTdCNc3SxrEXzvSwcHrXdSXFq6Lkq5q fUItMnBysKomah8v8DHWbq+UyWugCXIZ7nTAB7BpGbhQg6HKYRR5xEtILCA0dZtJUmubgY+c 8TgQKDA0IUqdSqK7YO5uptBRKmCPWfwkLEVYXO7FKdolE4VVrlBhsIlC1qgmMc2rUKSj098o 3FRV5H2F3iCghjYJo+LJiRWcdcsMpRLCldCFddCQsi2U43mYaufK60MAE4QBYgnYWhExKNVE uLL1HcjFX33bP5u49u3bt//9f/7Bd77r5vDfX/7n/2/ia0LFdtZZZ9t+bLDkWmlZKElrmmOW 9xAnrOApfuqIsvs8WoWZDhPLOV9w/nmnfG+p89vshekFX/mSl1jQZdUZOeDd5546UnrBxwsI eFpcHqhmwU+q9gqfyw3rAu1Bdp7061GRY53ACOuYJZF4fPyndSHKG5TD6i3Twq/QPtKOqzVe jEoZB6wRKH0kEOWYIAxTqJJhZmE3/n/23jxesqq6Fz/7nKpbd+yBGQShmxlkRgXMz4EICE74 EjXGERAwGpUkxiFq0MQMDokmTlFRRDROz6cMgoCiqIxNT0za3XQ3U9N0N9DjHepWnbPf3uu7 1jrrnKq6+Mvfr7ifS3XdU2c+e+211nfYMZ3WKp3wX2YdOTrYPXefUOnbpFQTjDW3irc4vX18 07YtO1EYcPNH2oct3kusnPmiFaUkZiww+irUXikNYlKV1jJK7En42/ZJlxg5fNOeVPJ43PNE umUK0FGNWt9z8zz06JNx52mL80fbhy/au5ZlOmk0ImvB6Yqwi7xshQLfS8gCR9UtZihT+S5W 2gkHw1UvYqbkYshCkrsZ8OtZzioBmZT049Ehhy5IjAYavrmY5AFSn2WlM3UhOyljcSopNeuM iPxuE7ttGVQ8nuY8BCMetChoacBWVViltGJAV9rrzDRrxkJ4FzlWTDWy2I6BL0mIIZF0RQDx mM9BCZ4GuvC7I0IkihMZGRnJSMClTT0t1fnVGiPf7TLuM9eKqLcA1ivJtSN665bWgoQYoIwO KdSEfwGgkYqrVNg0ZoQgTSoXImLiKYnE+AzQYFK1R0jEZBhVPSSpWGAmUrnTWoUgundSOXB6 eiqiCMX5RVV646M6Oxv+GsEbaGCEqwJYCHCWeBOWGB0fn5qKPtAYTc946em9Q94Dv/v9e9/9 ng0bH8d6b/7Fz9etW/fxSz/au+RJJ5/81A1P7dy5I02foc6HOU5MdYtijjKjJ107Vf16xtei gw4ipG+uyQHEap978onPnJ0IW8s/kxUyXocddogTpQNntB8XL178h0SRhCr1GRl6DVpM605f +/o3a6CysOnjjj3m5H7Hddk3vlk2QuQy3H/fvbakTh0C6mVXNQuMY0UFZ5jU3OJ7UIjmPfxZ SkVEZ8jXqkCmQGou9eSFzb+9Ld76ShkRNZ9UFHHw5JMlRpGZTM6uylv2dGJlNBhmMd3u2iju 2N+WkSlrn0j3mGCI/AF7NWfLYMFoUo3KEGGyCaPlzDH3OSsSk2U5xz6ivsTAAjKqUshILzI7 e1PLmJk2ozShoGbFiDH6rN3o9pzgT/YPO98zEQLoHAHGUeXQE9SRDipDEqP4C5wQINS1cNch Ud0IOiZ765TAgU1jNxqCEPQ74jq7CQU8thrIFDMCphRqrcYNDtU5xWXAjSE1Gi7ww8NjGBO9 yATihIllcKnypIVl0JAxoHdEwTwR9SPopkdxnzBgEj+NHbOow430K8SnKOXnuLVj71sExa6w QahSypVtzpk826mokWaHIP5sHoakZChi5VspVX3zxOJEolLi0Ciqylx+yEiSI5+FYGN4o10A jeggEWlPBKzq2S4xeqdncAh4rJquAaQlNNlBBYOFW60Mo1gtXoaaQSqEG36PjoyGlIuVnkQg kf1CKeUaIaSGL5gAk4s92MS8eaLSm+cphQfIdfDd0OlGq+ksHUvHFfgXbsfnn3JKX6TGF7/4 pae2Ph1PdJfloL7/ve9ecP55zz5g/9qSiw8+pPDXowg5R+6lZspxvxup5a73SYnC0ealX+oz RJRDD7GNGZzlxYf8QV0oph9R3/gP2dbExMS+++238fHHdWjC83Mo7cMzp3pFntHyMZ2fqzQY S0Pf/tYVvdqDb37r2/pGrysuvxx1FVXAAnEb5LMwxnVmO8ZCLFOnY91cLYCVaA5XI+gks6Tf aCy7UmqteZl9O3VC4aRK1EDKLA1K89qjlgCTmz5WWVikSld4SpUlxv0GunaRWdipFCJbTY8/ JWJ3WS9IUhiZmenY1hNLD8g5Wf7AU88/ZAgFt6P2n16+flh5zVKcrABAkIFRD6PeDaNmT6Fd t7jpWYYsalxBa2tI9PDA2FOHT+cqZ2mmPasIC9PHk9JZmqz43dOnHtZC7D36gBnsfK2X6Fgz iV0cIc7pBFaa0VAIRQZmNaTNkCV5GolwG3OXLvUCPItId7XHm+5OE8WqQ7sU70OlTivcMSIM kw7V3zpWwzAcfocxgRznEvGBQxRUkiVCF9M0fQGHR9RUob0bB8+hEiAec6/hmAwpOgMRFH8d IpMOELwiKJrggqJVJCmRxEiSt43rdyIqXzYjpHqJIiGoZmVuJOgP73AFGCLPkEg8IN1E+0ZK rM6JTNZMGu3ObIvyHlaimgVaJFep7nCWIpg8S6lfFa9Lu91G9hMiBLxRpmmBsAfT+QzGTKSb tupT0kwFPIkRFuYpec4sPe1yKSIvpEYY8MFyARVB1+wiP53du1S8MUSZyBVL1IFXjeA8F3lB nFalrPCaGO+PyrvzjjsQmYFXBJzxllt+MwjbpiabgxYoK61Q7zXYmz69H5HxdwOQ65Xk76QT pB+Twg8l/Bx66GF/UPQSNYHkD3aBWVwBgzh0mP8gyIZzEF2MqsGJnxvZoSXQHvz6XF9Mbaed 4hia+hYimFbJsDqcWa/6ys7kuajmsGgCxSqWnyebJ6uOmNmWj2ILU2GAaVnMm4JhLljETNQj LPsYriiYpeamAoMBJdxKM7MV5EOr4asAv1j3nz/echVMiJtpdwX1kNSyt7Dq6XbnsW3jiZib LN47Byxb2YDCWEq5rCcJXur6GNMMN3KTPrlOl4EzIRywOgZ9HuKueryhGxSrf+OtRECDOMrp 6S66I0Ce2IIHDO2275x89OkxLB13fp+8Gr69dlO8PJUCBwWNvQGDErmL+L6FtwhqgMqySBiX 6KhIW2Si15CxSUczYSGPTspR0GHWCIK8E0gImZ90UGi17j8dsR3HbePkzssEucNzGtM3BSwQ b1jYhXDXCD/qh8IJhGi4hDdhZG9TjY4NJ6k0in9CpdeCPjIZdvUh7ZLKKMJYKbtKFi/y2JV4 dFjMgLOokzac9rDukZERixXwBq3tsrIZlkM9QR6iWEiM/bnJrvieiApUG5ruUOnT9kQixigJ 0+p3zRAOkKU3RACTidhiM5YX3IFm72ZXlgeRjaGrqqcLiP82lfoalAihYQ5QIaBNXrSmUlhY akUFRxhWtHPnjrBq7F/I71DwLfxcIQfXGOlheO00Ih0m0kAgILX6mz1IhFQhVYrJmTtahPlF LIX3c6i6e+nyXuBGItqGqFf0QjaW9nxL8XgqRdi7wO9Xral9cmAsVFbISSeceFJtmQ2Pb+wb KfVUuGQuPEqvpjv1hp8ZRq/2E75n6lB972o1Q5XGqX0FKZRcWS+Njf4lWG7OGzlEEq1hT0uw GqQyhh6KiMRnaR3FUym8lTwYx8K4FXTizGzltOw9f7bGiKAY0PBes6dkppNt37FLUMXGDMwl mpU+uKFc554TU5YznBhou22bCaqisj9jo1Ek3qLtt+1iCb52h2Ma/rDXRNvSGBDv5080dYFI 9+k2duycBNEHo4DKGgOOgdO4ZkOZxe41b7ruk0apW04tpRzvRYJLm3bKrMJGuqJbTV5fs+CZ qNUWhBMJQJiJWF8pFV0wXD5XtxRPbRWucZGoBzIYii4dAgIUoDQx1o7tvlInETeXfpjC6jJX dm1VxYb72Z690VNRSwKkYmZ6BgEsvFFsnuZGcYzudJly6xi7EbMfst2cph1zEqpLJUZqm8F8 1Uu/1u4S8IdRV1C50nQ1I75CPdYpxbSSUbAD1WCJ6YsjoSnERSgBdcQpFF0xkleMpK4QmXZs 34FsbGR4ZGxsbJhe4bQwUJCKdaX4PfOdG5yTEeoSFyhmWi4JEWRi3jzGZQCN1YQSYUx5R0ZH WYQ2TbU31qT+Frpc4fPpMFegKi6KNlELMMRX/BvWlohp4DaDCh6d0EiJkr0+BwyIz372s9et WwdgCYPxh4buv+/e//rKZRj8VITo3ntWAl1K3M+B2IdYeg5xOJ8FKxDKK4P6Q0xKaKRJv+C6 dt26l7z4hTXgxqrf/14K9FEs4NAqZCOErr5lTSnsZoNMzkKeF0LRs/bb1wA3jv3OlSXnKezt gQcdWPvW8hUr7Vd6GzPohw86V+EBVkl4HJRRiJ+rLAmmvSZeGHSsyJPm5T3tK2c/rNkVVpD0 NIiY28bVOGEqi6WellZVUoX2hXnqAGNJxOurd74C0EEpx5zwfDmT/sSWrR0T4pJWs3vQAXs+ /OiTntTpsdp546m9BJt3tBi2wEW/MoDJDvtV67eeekRUeBLnkVL+XpOSOrhGcPemreiPWLQg SXZJfupmuo1HHnsKy2ze2nals2TMkw541m7rH9rEWnzUBZk35ny5br9l57DaWXmb0BkYbTgn v1u79bQjxsOp6J1shJV0yMdE4C3xWCKwnuwRYFMAfCD05jumPVmY3mS8BEmsdgC7QQiaDC42 7DNJbc6udLxQC0VrTdCnTTtryVxJLgY6A+an9g5X0CluAIAOYO2IN2rbWHnoXALkZOlCAk/I RlcbObkRl8qa8Z8wmgiL7ersKkQzN0QDCHwgQWlS4RHJX9MUkwCdIM3sBnKv4eaw7mciaq5o 5XIeRu4z4rGcQDav7M3LjQaPrsSoT5F/JysCKl0aVcddu3blebfVGk6LmFGh46VnqegWJLbr wm8HTH/Csq7Q+OA0QwGT4Sgaw/wYmuKQMsG186rXEYxvbspSK5EmyjN2kGmRhiSKqKztMQIX D/IuCflW+A2qclzz7GxBAbAhkuS9rzPPetkXvvCfYatjY+Mqp3vnHXcsWXIXaqYoDWuhD+nd HI0vdS1LWgmkQQYX2FxpZd0vHN57z729wI1wAa0PSK05tPrBtYMgiOFepdvL9bWgDHPrWig6 7LBDaolRjaccAt4TTzwxd4Y0qAIYNhezwDy1uAmLVp8jXRNhsUw5xdY/ycZCLSSqtRJUzFJh 6mjlrmZCzzr0LqmFN2qPMfbAOWt6ad3LnNFFBPSRVQ20GaZJle+tiFbn2twcpVFs/SOb2529 Ws2u5sOH7D/80KNe+5oTY6NH7z9dwdM+6fAAi9SGSu6XCg+7Jmcee3q3g/fqULXQa3cKdIec HzdnO1KsA6/yoTRsHb+o6wyAcsPTw3pKH93wdLuzMCoTipDGYQeMbNiIJzzmKKMjQ0fvP5Oo lGH4ypYElRnq4VdQPXBkjfzupAiZ5aNP737I3t3eOVJKfEr1BykE8tBoNaz1mkjdRwyCFxcS rKzVGuqIXygg7wjaUbmx1TIonhI405S0OxGftpiHpYXOWlQ8JR57l0dDukd52uGNmVZlNiNl 50a4GUg+I86MhxmrrfANJGc5sZ0QABDmEzFXjNkPDf1QVQ1rxA3mYvY8Ok1DFqpqIRDGk59w N4vjaASVEM6kE2EguQzoDRLvDnd7m2wYndQPNYxhQhZPOEEq9AaH9QlDXdpdDfB67XQ9CEjh u47xOCxqNZsAmN7AMQK4D08WBLkovz490xoaUr/pbtLVxh72B6cuBC2oMiUCttLeE6SdYlKV DdUSA0vw7XRmQ4YzORmpXcij9CmgapmoA6vIIYduwm5ywRGFxG43ZG3hzcjIKLqvva93XPz2 P/nT14ZdR3UR8/em3AFK2QNEsk1G2pRcu4GNMQK9jJAL2VyO9dJF425ev9wrbGTJ3cvsJ4cc cjCgNVjzoYfVm1733Xfv4ESnS6A4P6jsufbBtTXgxrP231/dMsPr+OOPm7uwqWOusXUfTI72 vl8V8Zl5bzZEGZauppi5cUJxqs6puDI4susga4HveB+OlCWbfentUin1SbOKGGaZWm4a1T6v qLxEkHs2OuZGlsIADCopjqZcOpw5EiesEBsO2vnCk/fHn/bea/4r/mjhUKNr17vqoR2Cffe+ Giwt9+jBx3InlT3X5+KUV8dpaKMlsMOHH7z3687YZ97oDFtH0grWPFbJ8u9/bMQbBP8Ji3ae dsJ+yI93Xzh2zmkLonWZ5+gWtrHmkV3UhYLbmfc9HdRMTIjWbih6H5xEvKq5iSKOPxgHifQK 6YrIL0YrC+QElhOkD8EzQfWvQy+EPcoB6J/iaEMq51mRs8hrIoq0zhR1UQyEhaw3xiVwyYKJ mhbf1AkWxUMnjiFRBR8UY5nvxqaLML0yV9bcVAUjSUrvp5SSfvRpAOgnm4oGSny5r2SfMNBS YRXFKHIvn65lTudWDyeErqYAYdQGjxJZNzIywj4mQ0OioJZTfbLZlNQHJhtlK1d0anT9IXnK u10VJ8SrJXQrvNejCBcp5GQaPyanpyYnp5588skQyXhOULALFbgBnlyiUADU0QCBNposN5la ELuG7RnuEVKF0FWxyiELdGnlQuCLQMqgHxbPQlhRiHJRLFIoY1hFh9rvwAci3P36llsGjYYf v/Sj55z9sssv/+Ztt94KHE4upUj1igxREFxEoCaesZcDTl9ifNIGZSfcJPT9w9uaBx+0gPjw Hlg7YOWPfs4xPRHowUHbapJpbLP0eqgngg88cH891Vu0OOrtRgqOnzdvXq1IuHbdur7Bxo7L kqzMgfBgXL6eAvhNzxHGXM8KEahU3hAgbKMRB3ZBbjEX1UvmtBRJDflMHbS92YROgPBXrrM5 XVspbK91OQV6NBsNbSCz+1elPhdfbz0jmjI61+dmuP+x8at/+VB4LO99cMeJiytToucfuuuU QxdInJ20DpT3PzaxafPDlpxrq2qkL8V5532rN734mN1C/Ci3rmmUzJ2FRca9pxcfM/ni50zI Ecxopw3wxS07Rh94cLMWJ8PvB9ZPnrgoSTSD8v6UQ3eecuiE+IlP2tgW93zLo2Va03MDoHoG a++VD2x48TFlSmqfJtWBdaZqlxgER4cGZWgiI5/Lo5x5Cm3AKXrqgQKgyUpq9XnD4Jilwh+K xcBcUYXI3mKcEwqE+kyKWkcZaWLvI+HCb0N80qGRnRl6O9Tx85zNoB0h1J34bEVxZxG5YC6N 2Bkz9NqVhS/OKjoUI7scq0ImCKENnDfwu6EYkrH3ZhIXCrdxN8H8PlwKuIGrnxbb/oX0rhkT HcyYMy60etvFcFTrRb1RXcoIP9LK6UzCeyi8zRoSNQkuz+L0NAhbjB8Qhqr6iBPC8Ao51ZC3 Z49NluOilGskwuvD7yHXgBaugv7ZVTlrlPxXSq1SknOyXiXYUAg60XaYbJet1Kp2Ckq/pYl5 8zLpQEIwUUMCRo7RkVGoS4XXL27+1aAB8fnPe+5/ffmL113309e+7nXxUGkqFbYB5y1FVWRE 3KMm0MCmF5MKwY3odNUwZVCc44aw698Y6y0eHn7EkQqUCqlYpUz02IZ169b2rdXBhSjeRhET 5fpua7WxOeY220EHqYPkwT3Q/Afuv39uZGDfHKt2BsjHK5zhrnZQOHI8E6pTxHNzjRbhR9Ks TFmfMnHM7dwdODoISkHxoRRCzFIVBvSGN0vK/aJXJHZlauCkSj/6u0wQMzhrdF0pnVCacSRG 2YKzH99zM/hy2H1i87Y7Vo9pBqQlPo06KgS1Y7r122VPxfJs1ocjQaU4R9C7HL/vf2y43JqB kKAnD9QGnwEJUl6EP5LSbIEkNrrNX67saCMQCeiWJ3feuWZeyWL2di5SieTbp1q3rtimpf5M tAHtvepz9QSJp7eWktZgvSWvgCpO6g2U9FC/CT+aqrbyENWaMtH6i5ANQgYiD9MeBkp2uSgi dqivg1hVeM3e2qgLIMODFIWvCrKo92wmehC6k4x8o9AFUi22iw2xfBQLi7I/n6ZcKg9RsTiQ IKdIohC6onFJwY6OrOrb6Vh4FDDSkMygpCrHWEQaQCUACaKOQJNCHwv7qZ0wJ96SQCdBKxLi hLi1GKxIHUo9FU0hzzUpPWoTPDKkdC5LFcePjFk7Z6A8cyurNQwZJ0W9A6yBJWHxpchDBEuV eQybCzEJZzi8HxsbDz/IyUIkwwq9uKuErcyQXnxTmOCw2VIxjshUblEWGW+w1jAoUxoJ8U1H eHyNED/+8Y/nHmb33/9Zl/79R26++RcXXPD2gw48KKST0T4uLxSKwybOraFB6USEtRAXPc1Y CiROeYq5cq+hiklrfYhZu7aeSx1zzDGUa8eiyqGHVNhXax5ca+0/anwvKRP173th/Fu2bIX9 7PjjjxNgtz/66KPrkI1ly/puy5sRf45jL7MuZ8ZwCl1znzE865C30ayctXloIAaXQFiNPALC zFO5XMYfUptVPPzjRoJnJs8TXUXUyuLye1WjzGoh+dMtWMcvS42aVGIVczW18dVwb7KdXIqH v77r0Z8tHVH/SYua1y8+vm386ttmt+/YpabPGlrZAovYylEitsH+KY9t7qC35Kq7AQQdBgK9 UC4pY6fNk8NXQuy56g736Iankx5JrV8veeSG5aP4SspmOF7EdRkt/+jWsatubU9OzSRG5Dfr qXYA4JeI0u6jmzuDbjAMKE5hnzIq4et5tWKP8NYR2GFTMhVHsMA4CGuxTqQfAGqPNSuSL2KY u/jHNsW1BGM9imyIZyD8VkQsTbxJXRlHlYreMaCkTFHpGbNLCw2leaGcX6uxmRk9jsSU5pSJ jEvL7GPHhw+L9kyatWjKpKL4jtNLz51HzZA4A6kW5GOnLUoepFy/pbFrWO1pSPYe+SgIAwio rRYzq1hBSU4FoIaTU1NQHQyft2fbsdVFsQfDNXqlTWo7QRAEfakYnglVqKBo3roA4lPjso0M hMMYQdvnTcwDgNMKbuUkKp8Rhh5KHJDHVPeu8NcQp4Au5G5RnsdiJkuPhCEsJxE/nbyTfBSC FhjReP/b3/zmO//9/WdMFebNm7j4orf/4Aff+9g//MPixYvVhwUaKsmc4kazBA/lLqWUX93A nMSjpEsnt38YePThh0NGZT88+OCDwwWbnpkOl7zGvlqxYqUfXDb0Uhru3/eisWpFNdU76cTj bcvN/mnV6jXJnNW9QSLufbZrdjoXSOQgolhhGlTqtYrmvzoIowmBh8eYwec91p1WhdZVEib2 BOGGlq+aNPZNpo1mUmE25IUEVqimFBohLqk6rPVt+lX/rTb296za+JVrZu96cGLD1nHGT8iS d6wev3H56H9f/9jGzVuBTLbr90k9t+MeYV6sWrtpx9Rwz0Y9q+FRSlomWz17Gj5btn7ilvvH L7v6SUANq39kCdr712z+6k+LsJMhSpUR3vOe37Bs9Ps3bHxq6y49bzQ7dr7nfDBdXSpCv39w Y8g1e0+el1HeG3gYI+JMIVHfAJiQCAmXZWHhLi8UQ3zdPtqAWmAIRm7nhdUEtAgm9V48JxE8 OtT/qBUzATFQS3vUB6zUnHZAYyHaJyq6kYjEkQLiiWrGeR76+h1Ra8SkOU61WV25NBoGjMIL YAG3MaaDKvmIzCzPK+23LqSw1IKEPIPivZmlJYjDeE8rlUo9mglSCPPPBE04clMjygGtpCPC PbH050pAE1HouuolnZNwWrvDbA1uZRHKfmp6CoLLEW1IZ4mR4UUR/lQYawi+cIgdOeOZNZri QsAbBWLzDE2kJSPRgt5kaanZiMZW2GhIFmM5ELLzSKUxZIT4Nj01NUKNwWZzqNOZDfs0RBVY hJZP/uu/hJzv3Fe94g+h64bFws+3v/O9K6/45qbNmxNj0ZYMQMyzAn8ylElSP0eow9xQbJQH ltdCRhWSwhIKeOghuBjPO+XU2pIPPfTQHDU62OgNGnwTmoyvj62syuvQww5bs3p12NVDq9Fr 2fKVgyJTve/lBwbvvvvJZeJkoDh9VJgxkHf1AHTioqu4SpW9kOpirtPwvueBkypqwmVRJcRL vHR2gT5tTkGIWM2hxNCxVXUJULdwITY9uf3T3y3b3YpGY3Ep3pNUOk/btIeKGfe27btuWTLF cUVM9qjBs00KeN6LGGNY4IlNWz/93VQ7KI3mTiVyhe8h7/n6tU9h0AlDU8qOZduU5P6Na5+u qpO4mu9MUezUk6+EAUn3tTHpd+ycvHXZpLmCTrhxu0Q92QsWBmJU6aZNWz95ZZKUamfbmH4U 5vQCDfnKTzZhxMEJVMJ6ITL/XLA16AOL+URKkVTh+BYYDSGJWHfJk8ZIC8B07sF40dYxbtra XkqlKWWJVt70vKHIisqSKxLuYCEDSNl9in0jCzkWuuhd0oBQfhWSNi/7zHOp8KbBKDtnG37d 7sTEBMb9RKTo024KQd44fibc+spF6kkNSpDNaNURQr3ohHWI/5PTK81KK1eIlSBpnm23NW0F 2YADsEsQdQCRJ3baNNcJKVRjUJglgizOedEtWs0hXMTwBlEH6ZSSd5F+cCTxqYoZhiPdvn1b iCCzJEjYakWGVdotSQhsM02NtNl8NhELCJxqRCyA4IdJlh6DBIq3zOOCtDfldgDDO2F9RX8v 1BBxz4eIFtY+TOVET2EwtqkIPY/7L3Zfm41P/MM//Ntn/2PHjp3JH/Z60xv/7LP/8bl99tk7 9rSajCWdC0lIVPaQw2IOlc6pituU266v7ntK6KaQUdkPjzzi8CiMNNTqlRy8e8mdA8lVroSb 941eCDn33LOy3voiNvTEvHn7VSEbDz20flBLy7aLoPs3N2oDVSxtes0N1AyLzBIkl+ZPpbqx g9gEtbg6EqS1VY6MJwr4Ck2SC8GyXX0DKBT0pHUfbdZV9Hnl0KBCC039lwclkc5qbUgDAANo V+bmuOkNldlhjuyMTKIYUxXeVodkeuurW0+l9+NEAKIZa4aJhnnITCCL9SyPK768Upg1uSlb uKmoRJmr0Qqj8jqBaGjC5M2ZtCobHN4EkJmBPOcN54lCrLdNILB3GfBNax5qtQDk09MI/yr1 4yik6QKWKzo6TgSUm82mSgXap1XcpVPbYMN6kASw8SPSO5eq/ovW5QTakFhrEmXUKCtfsT2F mExjN7wk9JoJUZey0Mq5ZSBxRtVkDSSm8Ur5JyZ/nS5iNqy/yMUjV6heubwr6boWsI78LwpQ xTJdc2R4GDIZGaEEYlCn6ij7sPjCyIU4byjM4cYIr/B7cmqSwJY5GlpE92cOFs4SEI9osNEy jRr6BkEupycFCRxw43opEbeQXXESljUU4x4WDjkQ9IVHYGLlE62XFr7EvOBS6nmepaQI7UnI RLHjR0aOaPTCTAjGKHaqnSuNB14pZR9MemJhV1CpRKeu1N6XLPv73/vueeedf9U1P61JMQ16 HXXkEZ/93Od23303/HNqcmpQY6YM8jIk2S5rb3BCq2wQgcxRy5GAGJXXyc99bvh8cZXXteTu ZTUN5uqI6QAEH2TXQvYcfueOHTX5jEWLFlPZsA7ZuO/eewcFSmpc5XMHIQE+xDmal8xvUH5T b33FbMDDPT2XemBq1AVVbkfFFGIdiCvyOhxnNfndxHgiCJRjrlJhFbXvqj0el1TYvqnuFcdR 2HDIdAfNI4U1cx+Cnl4nug9OzKhctWalozCe7QjuyotaUoy+hQ7uqnPoJYorf0P3WTVZNB/q sZdjjys51d5mY6QFowaDqihdqDoUUjFgbRwjRVk6QVosThKIyJlLs0yNLVxWOjTmsS7XtmLQ qciUoM2D8Ug1lppiSaXYDVaKios1m5JokvBpF/0Sx1lvrpmcnij4XgLpAIdGbaQhw8NcREt5 rlqzFj1f/haLX2Ql/NUX7CeimythNS5RHF1iHHFVWJXbBOK/jK5HObhLLGfejoRhyK4r5F33 Cu15zHtQy0UI78glQ7m+SXJTgIQQryBEQQ/cDRRV4oyTTgs6YZhMhEgGFnnYyvjEOPZ52ggk oeroKIi2mkzbmiWBkikxrgzDMkT0o7IGaWixLCF5ZmFstBMIBXpAgwPpVFiDFyw+zgyOqE05 EoDy2L1RSpag0KH264yNyBq5DD5N8tXKJPihARYhETlFP0jrNqX42CSV5VwA+2rMw3bOGc8j 1j+0/h8//vE//dPXhjzsd79f9YwBLGQ87/zLd2uG7gfg6Moh2FjLDAp1cEzKMOXst8JoAJil S+66qwcKuCisswbZeHDtOuWaDAxfzqWuf+6lTly1VA8Fw6OqkI0Q9Tc+/jhW2R8AYhQF+x97 vfXlQSXKjRHXoMqh4gwTOXuoHBKusnL4iG1dhmg6Ve/tbVPJ2JoqXaimJlXdJV9LxWrdL5Pm OlXM0goJEYDhhpwlEpzwzMQZrmeJhFxGJW1s4IFn1w8ZWZATOEMeQvpoezzKQFJso6F8wavT lS4n5f73MhNyjTpmAU3OnCZqak6kp0u9QzXki4dOLhDQIjeKxuHJDklVVlpdJ+pbjUjshMuM PpMTYT1sBKV7hPx2e1ZH7byqKerFL4NCo4fLhrrFA37VEckiVPPCkkRdanINpkruQI2rkAiH y6cAP5+YP4mWoLf6+gr4pPEPGHqWgZDMqSsiSQo0KMOS4zEnju+CzrWknTBcZirDkTPfFFAF VoNMWWkTuQW2iK846bdBpR/FwzIpoYuY5+IJSescGxtHNSiqnMSMi63nUevWU2ENxMOfRgjT oUqJuEbh2yE+gc6kvGzbDty+fRsqpREnQnQ0hXQNE3QctDY4lUDnCaeIcXkZ5x0hgO3atQuG iCwUkjHFDXS+sDYYDof3nc5smPHHtiIJE2KmpzVGpMteml5qtBY31yTYvjdzRoYtQj55aIjU QRJ0TbHfuJCQog+zjE2bNl95xRVv+LM3vO71b/jKVy+bu5z4khe9cOHChVxGGMxhUt0R9n8b nEk4lj/p6PS8b34WA1iVs0xZl69BNu699x6aCLTcgHAh5rT9G05OiochCtaAG2H5Qw+p5HnL l6+cA4uROmcn8n2bY6mD3lmjZJETSp6gt2kyJxK/VmXllqforSlOgW3aqe6EMyylkqx39eQK ViLnRAKqbOqU3WZKy3picQXWoSrjJifLmtIVd0zgj4mjk7YK//hCfUeh5aguf14CGEZtfK4I 49Ih2jT2EtVvhcUJalCVeqmTw4Fyo8XWlwYotcmEbexJ2CuQaVlnZluMtfXGWpjHeW6K7rgv w0BFatKuh69szviIzJUyS1o10nylFIE1tdTUicNhbJ2lJgkuC4ZILDi2mckBRtIwTnMJWtpj qM3GbILkeGyjiN2qsobiHrlGlzUUK6/3Bhd4DTrAspj1sUKXq3bplaUUU0lpcHD/xrEQn6O7 C8i6ODq7ZGZ6houKWVWqhg42JDdCAGClKDABtKYVQRYxMLVB4EWNMeYo4MY1MtCRESMx/EKY KvrdSyepQykRIBVteDtAbkM6eV5Kr1PTUYAidrnE5Ryf77nXXqi0YYi2bFrsT/gi/LeQ8YVd zYtSLT5Soanuh2dfTb8YqtOJuXXY2xC3cOwIh+GcTcybxwZplJkR5GSGJwoN/gnbapGcB2JY 3E+wl0dGRqGKiEdC+Gp8KyTdBPAS9ngm4zUo5CtwNvzlwQfXPPLww1/76lcvvPgdF194/iAs 4lkvO/vbV36Lcq+ByQEqvKokNrdKb1nH6xcOkSiF+eDyFSssZzlkXccdX3cPeWjduna7HbEG gyt1HBj653k+PpBZRiyuGsPsiJpG1JoQ4VSKvDc98r4uTjGgQQhogI1GMfKFr0PZaEDfy4AF WG7J1rUEZOFN4Y41Bl2i0rSoXPXBu1vghkH8O278yOfVtMwr4F6NLnsvuvqAwDNQNQ8zEAq1 M++Z5+7I54kxCILpKKRpr8iC2qinWDs0S0rHr6Q0GtbYbFCRqvrIJwfADU2DDFCzFGi01Iuw TC2pVoaGgjm7LFQWSTxEYkoUIWJ6afZyuFr4tMbEsOzC+XESAGDXZKcVjEHvFlrVx/kBcwsg +I50sFxSyiYhcjSdjNE5QwzU6JL1WXzJJg4fjo6OqjQlFwzl6oTZWWzGO7bCwjw7LpNJqYZI uxbQrymXjVLcW+qWHtwcRLNEoSjhiEaaI4XjjJPxTQQqKaf/WeliFbb71a9+9XnPOzn5f6// 6etLX/7KF77w+eGhYUh1AHYYojncS3A7Rg8Tl4SMjcuL4V2btEAQ5mDJHCb1yK9VUJKdAsTx i2dkvhxJUTP9+mVfveDtFw3av8WLF4uJRjJHQCJKePMPqhzKdKnvWI1MttUaWr9uvf08ZF01 afkNj2/csGFDyLjTATJQtsA1KDAgDVqzul5HPeroo2uQjQfuv6+U9OmXV9mj7o/aKBtdnKg5 /dacQhuCT0MMc7YYhUkhlIjxNyT+BO7NXXXALR/7HkMWQCZ6A1vSB6biBRxcRkRbdrNfb4pC FbxjXOnPmSGdwlwSCpZo1CHkZNKvsphvVlgwPbCUjIPpHogrRG/A9t4y9V2v2pjZVEk0G0ui sZQEU9VvNH5p9eti6mg8S9Bza2uqsdtJyLBUcuKueEMj8KOKaBW/EiGMAwOp6KShVgQRKJJF FV0TSXHQ/dIH34Jl0EfEeSNaN8MZlEEFPJvKvUNBw1Xli6DNankyKDN6YVbphhhJCIdfqQo6 ASAkxqI3rlDcNxh86MpRi0jEXWtKaTNUJwRbNhCRUhBrmyFjU5Od5tAf4lX7/15/4CsEoKht K4SweAuFNCuT8+9i4hX+GT/sUE+1SXeYgkliahxlMRMFdw7T3fPKV71qz732DrcE+EUQGrnv 3vuWL1s6PT2t90FYcvnyZZ/598+9768v6d25/fbdp9TK6feCS2lBTtU6FA4GzTvckeDtD6Bg xcV61Qtf+6f/y/5z9eo1YO8qoXKOvHCQ5KO+li5bYZleZ515Rm2B5cuWzXkaEutTPBj7XvRp jDku3A3KbntHXjEg7fC0lHjKuZggR+sKSR20Bog0SAJPYUbtwrod10To7XsXW3RdQg65aiKY WCy47p7MmbSQCG0qJ/jVzGZN1YPNtWxY8pbk7EMTljELpmCIhpZVjO0t2ZnaYJ+CXjyNZMWp p0KDnKobG4aAM4HKVYGXiGEVJ+taSpeVJqIepAJQhXK2Xc4pIctwiXOmfiNNBP3IIy32pInc SSjG5KUXpzN1trBYBO9IMHBi1YZQWrLuSF8OOZnCbcob1PCcGAPtKiD7GFoyJiazCXJ7Vsg2 CdDzbCPgS/WmZoPNf+GGFQexgsEa4OokonyIbp9KpGtBEhh6ZtyTWhLkiwD0j2zaEKqTISXz FKbDh/W/+z2X3HnHHZCVUvvKWvOsEMCLEqtV6WPnzh3z5y+YmJjAtcaEkol3orOVkC0Uel1O PJe1ETgyPBLmNoDFT01PIUMFAyocLCEyohAwBtWZ9gxkn1R7HudHdy8MiRDRwMkHwkLrikxw omMfGxul9D3T2TaQOGExlBwjr2t2dnxiHGiR8mZ2yTvf9e53vuNCjKs6O8zgWokGtqsMJjHn 1ueBERnAsrcZHJkYWfvw++yzX/a859bz4q989bI77rgNsy0t0YTlb7rxhr7RC/tKYC03KDxo mq/l1xNOOGFQ7sUFkAFDvJce4I7t22v2JZYBFqEWK1fOxngJbmB/hxR+XEnMYg78evhrWJuN XocfVmmwrVq9xivldU7jZOlg9YfVW732RHjKEVrmgCEeGPNM96WcqteYXlKs69Dn6toVHyaY EplRW5UJCxtsamANnrkTbhMdxJjiiMy8TmBNutA/7bb6xUaN3qkhEPI5JIsqA88zcVMMRI+w K0Ta3rPkhUumXVU5ohzjtYbtKmst7cO0SHw1j/Ry8p2GbUVwPP+wPfcZK06ct8P7VIsKN29Z sG3ar1z/lMZF9fdCNELwMIh/VfMqUi635vZP6vjDByIBBmwKk3RySgRjZb0bVVg2o4kOJB8x sGLqgywwBgJO2sIUoSAzEa7jQcwwrlbiorLxIH6P/AnbCrldnKHKQI+Fc2poIVqBE6bjD3Lr MFJH9Vhfqq1raOxQX7+Un/cFq9P6tAS+EyUZVSXoFsaRkJqFLO2YS1esVboway0KUc0r06uZ znZnNTAABwcdyHCwqH+GDxfutptcYh6fu0m3HekTkZlQkGRUOBtOipbeiDHC2hEq5xFn0eAe UE79oI7Yj8XJDYX/DsG5cTmGiXel7UZoxquKvLKM9eSHDY0TV1hTXrYoy3PF9OpDDWsxYCli mKTCBiMz8+5QYyjhvqAHFr9s2pFhcoi7XP71MTAhWsWyIWhiYIqZMn3Dlok1ivQdrhFdY404 4SZT2NLWrVvnAmUMNaanpwYmj9Sjiw296LDQCk/LxLz5cyRD4eoOVooqR7qlS5f3OmmVTa/1 DyVGqKJvINGUyw9oVqHvpWsb9AJP2Q2Ww7AD4sDOl2O8oi9NDpma6ufEHJreTGrn8poTIICJ yI26sGtlD2JRSTVu5caI2WtlTH1VyoQvS2vgeGtz1wuX70NtdkzW2Wu38Xcd0+5Bf2D5IVyj 303OW7ctuX3VZq6FSuhS1tqBe8+/4Mjp8tu05fCt79y5SWltGs/2Wjj+l8fN2jar97UycvzK zZvnb9yZr35sq9mr2Ou65AXjC7IZneJc9/j8ux6saGoc9qyFLz+os6CxrbaJ8Dp9z/ChO3Xv +T98YHbT0zstSZng8swHp7lFE2FN+pSpXJ2sK+7DEXUNQETqbLJo6d7UqSJSMGgVwubGcKnS w7kJijjJyijPZYXKKS5VsqTp5YxUoAJKGf2Yima8S3KqxCDZUhUP1vYNC8QMs8SMYMyOFh6i 2KSgOOX8RPVFIlppTy6XQm0cZ9tdrBCJXVPsj7W4WgIOhWsRLQZ7XjFxyVjrL2YbiukQwjK3 M/Mu7ydajHnhK3cOm12FoTVj6fcoZOy4aOE74sIVdhuSS+xClRcTE/NGRkZ27toZQ1rKfb7J qckQnLKhzE9Pl627hKNLjJdkIOpMgUd1LmI3YTii08ehUkhI49HRUS/4mpJAKdeUnbpk9lCD IgN270znHj4npYAkyjB6sRKGw/CJ43KwNLqQSIGdoLRihfbXXocddihod5i14YEBGKnv6/GN TyBLfWj9+r4LgBcF7Q8goSknHeu7cOwweSFIukG5F/OZ1vaoYFTIXkvujKi2Jggrru+gD8V0 by3i+0A34uuelSvm2FZseqnAT/8WWpmaGguuvpvyGgnKebQb3C0zuZEFGlTx9F4B2ZYnW8UK OmHOunK6IxUwwyFL9Vu8xVi1055QAa0vPQk2dykDcNVUUZgL4rZVQYFyKiay68lR4ztesf+O d75gt332mI+BW3+AXD9o96Fq0TX+LB6dRr4isyJnK7TYOtSeNHTZq3j6Xtv/fPHO15+0W8JS HWVz0cmcwzmjmU1vDtt/4RsP2bmgMdOLY8XmwkHtMzR54bFJCKI2XdNLn1S18DORhcRRlPhM mUagOtqVqrv6Jiv7O6nq+DWM9C3YzRr20I+EqBIMjhMRpADSJBHVmMygGXGIFVdDmV7YDmAm oPMwzsQRyTO+Tuk3iWTVjvpSisVAaxPxLOYi4AWLxXAuLT1lgEBYFXVCDLvYN3Z+ocU6VA2z YPdCDtPCu7SLg9imQJJSpd4oHUPY3gnqRPGBPEGHE42LuVees94/QJvUAS2ZRcrKgtskQsv0 zHSLaoZK9cFWQgzjagTMoAmOoPhDlbNSpprCF0O+yCAputzDI9F2GX1hy3SCLQ4HPApI1rNG LURqjw+mp7VCqz59nD4SRIMdU5ihbUg8LDTiCw1mSmCsvU4+6YQFCxdyU52h/fE4jjn2uL5D 56ZNm6N4x8jw1PR03wWef8opiucJ98TUZJTVOvXUU3qX3Llz5/Zt28MpiJWovBjA9/Ji0sox o+/rriV3E1q1DTlnN6AkCOG+Ofpwaryybdu2GmfZviJ7Woe9AYGQ2TtFPgfq0EgCVlAAcxjK yCV2tSCB9IjIyBZJ6NQEWXWDeop4Na5C/HqzH+m7RuqqWFlKymv9mivdS3W8N4kvGnvOKY7G 27RUPozj/rOGp99ybGPhxHh5IBRlw72x35ivQFZpxGy5zuH771awXkfXeJ4lok1WR+74pLJ7 4Y8hcL76+D16MEB+UD59zoEdI7FSzhu8ryBiRrLOGYeNWiV+63mWGHUJkzgyYSikZeFhgdZt JqhOoknAg6ZpsXlQ2PP97iV0Y7SiCKRPYmzvgbnIJZOYnpnRRLBDg34MbEZ70CLmOZUpw2Qj avzTuAlCbrfUcJGpWMYFwMzowbNfV0l4YAAaBD5UHlCpx1wWc4k2dWy5CFfA+n6BDh9jKnGh dIdxY1jpcM+OhnEZKCepsZZ93yHJWeVsWI8FmKgB8xKDLl1KFBKtrqMpbjP4doYUi9qdkkA9 K+qFOF3ILMPehqMYIh13ux44eGnlkDOwZkOVt2IO5yr8nFINIEtTI86SiGSw1m81gKWu9EmP n3gIcxdK1ZghOUSqnQ5p7I86GnDURsRWphhRDVKlHCZkPr18RZ98YmJi4n/9yZ/iIZHzmI+P j7/j4ov7Dp1ISsKSD9x7b19y2Otf+6e777673mfhtB573HEvftEL+2RLdy9zBHaCkmZfrQ1F PYRl7rvnnkED+po1a1GFCMESary9LwKG5NaJsW+Ia0iff9ny/ulXiGobQ2Ar3a1c3yJkwrQq V4PzJUl9EBetimeW2KhNZGzQRb5FaL0yl8qyRmL2UHtjNp4J9JHLVtFysCvKbyVW2/cON4nV yDc7r+UCJT67mmFX/Yy52pteL6vwe7dG+8SDxk2Dij3DFo1M9fYfwyeLd488MG0mSVpZ+DrH wVffe4mjcaUnzNu+54KxMqIMbnEet2j3hY22zmji/bN9/qeXpJfe0vnUXem66QlbSDxybMdu E8NWzhhnO+MWZg7OMuTJbf2WRoRMp8mixMiRLFy4DOkp/eb+Fq0nE8ccFYT0psqHZRDPVCgI 752p8CNUYNjKCTHoxf8JFx0UKxWtQMrFBcmcuecdERBKhMpqGbvMR9YxzSSOEAfhEBIG65ER /ZYGJ0v8srkRZjAq/GHncE73vNF0qrfb7QKArb0rDNyRCExKHJZBjwKjnRDHf3a6IWci8lYH LiqItQiK8VJGWnPeJvFiKNtymkHbAtVaNbqYekWp4ujIKE4UJIqQY4XrO9RqQa0KjRsro8VI TscAzhDDkE3y/UBqBlHaY3oaEISSFC+YVa0iwnpGkZw6yZBqAWtB1EaD8bFx5c8hsWEKWMIO FDwXjvEMZI5c8BpZggh5x513XnzR23sfvAvfft4hhxx81VVXPfbYY5O7dh13/Alvfeubjzzi 8N4lH3tsw5133MGzs0Zx869u6VX73X//Z33m3z7zox/9+N577xkbG3vOMcdceMF5IUb2ru22 22+PySnx8hDD+va9nOmshIBnWV/6WrlyBWYZ2WBuGX3OPoFZ2h9zGHW7pXu0bm3/QuXatWur 03bfFzE/tzeK/VqNa9W3ezQIr6hCugI4zhJx3tI/oV4K+URLeqvBOo34nlJ0e/IMHYC16Ffu o1dKTSUJo52gWxYGiF6NWBTArejNL97b2rJ9Gu//6PCFp+0xOeK6iuR7wZ5Tv13Fq40jdZod sOe84XRag0rbN0PWhatz0NisEddXx2fR7o2VyfivL6wcemrHDK7UYc9aePoB+b6tKUr4eOEj 9xnZ9PSuGsRDC5vSvsoXLXBlkumT9TMTV63gltjUzOyP7nPvPqk57DqaZR681+jmrTuTUoAj MaBQzsOQcEFL3nD4IMqVS1ExZmMk5U6xxzhRafkRkUnvOsy1YwaQl2q2IRMIK2kSjSEiSmCy BTFfe38KaiYT4XAVEddMxRkZFOaQRaAzE/U0JmH9TkGkDQYUZHARa5fyCwmZs2RwrWzEoDg9 M5OYthnqZqgWwn0R0IDwWyWMrWofEBxd44nsuWXubboWMzzfVdCAxhKA9JBFhf1MG5WqhjaH AM+LpqxhXGlH7Al1ZJxOBZKukg45ZQR0BTvZarGjMaJRDEg5i2WEhKnTntUdQxTgMENmlQqy 4EmABCEVwg63bUzspmd4z10DnT+FSmXEOYnKVc0hS3svJwdJgRPOVHQZS6jqPNvUHfCpduYA fVTFywbaSwwwjTdRbC2WlIi8CyF9lEHvv+/eu5bc3Qs7DK+XvPiF4ecZZ/3f/f4P9AqFo/3l zb/sq1UfIt9HPvzBuVcVAuFPr77aCy0m5tQDxupYuOhOYz64YuU9faPX+nXrAHiN1kSdzqB4 gS406de5uaNC2Kv7BxQql69YWUYF7wcZuzyjQiA4YTXYhc5CIPH5jHHLQh8ZAyI0Mk4NuTfn dIcr+yNZUS3WhocLcrE1NliRcyrDx84DFavR1w5Ed1US6AS7l5QOWZXQJT5XbD/y21Vb293d zt53m+7VsOsesNe8Rzfv0JOzeI+Wc9Magm/dMnr6Xtuxgn2HpsZHh6dm2iaJ9EkvNcHs8OoN Wx/f2ophJu3qxV04koh2vt41nk5bmcSF0zW/mZvTmazfWbnou6Zm1k3tfuRYR3PukaarJdx2 ViE8YsoSKFqQUWGeURjz5jagMniHjFSaIjqVIWKJBmauJ9kbX9A0V0cxDpbiTcW4efU4tuZq HO0y7n5h2M2odqIlSoUsupypaVGJfKjVJcvKOIwmnO540rqLI2wipRrIF9kwQCchqltRJQrF zLDzCpYL8WNoeMhSGLuui1E+McqKiuNA9I3jQMYxTKV4vZRM4JySF8aaWXJBraEhDwsjMtIg tLvI7VoqioJTj/VemS6HhCwehXS/dCXaJWLXNKRQ7Vml7oUzg7LhwrGF8T6hyJFRrIpDvesC cqRAFQulAS0hozXAKjpsMUaKZrnRWYIpav7akROFMwxIpyPoil4adMUEZQqZSh/2MDOqtnrq InZUwr86rYiWmudWU1lVzGIehpw6A+swL77zne/+j2lod91193euvFJ9zMKR/OY3t/z3937w P1vbJz/1adzKoLCEtHcQpD5KvRFCKfysW7u2byBcu25tuzObe8Xo93UeyRg1G8syjUG5Vydy vyO8dU2PzzJeDz/0sC0PDoLdW3bUoAUNv8rywzh5KuZQknRSeHSczSQCSHGCLOiLRyiDlhT0 qlHW2U6M3aVaEsaxStCSYWC1MvkVxIejun/G2HpnbHH0COyqeX8oPVqy9unazu8zrymd3Yil PGgi11U+MTv20NYuDgs/h+47YV2nJehW2mye3Kj1JFCYGbEVywXNQuEV3uAasSHV1B9OKw3O WlMtbH2m6COZiN/hEYDGvFqggcqtQwmTrEUuC4Kw6h6QGiFEDUWQdgTpwov/gFhEVowZMXdW dy6qc+S6dShReUFeFALbUxCEtoXgaYnujhYDO1SHZnMcAT3mEp/go2GhJYWhfOvAiqRErYtL /CHt0ujYqKvyTQFVi3U0KpGh8hYW007MCL2ytGS8FShsMnEFxbwuACmaDISBW3XiuWk0Mgy8 BjsOQyKrYNmHsdGxJusteYzS0eVSjhcQpJhIjbCK+izJ4CKRCscVEqOR4eGx0dFEy7MEdti+ YzumJphtqMoiOmRK/R6KSvhDln4XRkhYWXbaZZ0T5mEQY0JHLdYe4WorIMMWrSp8fWpyKjHO 1BpoKPCXbGWtW2pTsDBWWZyp64UHur8CapQ34PTlAt9YsuTOf/qXT374Qx/4H4Suj370I0S2 76Iyi9MU4tkJJxx/5OGH/f9a2z//66eXLb2bjNdyNbH2A/QolBQTtrhyxfLeZVatXoMcFAKv gwDxOZuYl2q8fTaHZLnVwuizdOnyk06qM9VWLF9WwZP1TY+8t7Nj198L09tiFENxylazd3N6 WrIFM+GSy1zQfMf3Y+Rp5FCLRoXz6LHUXJIVdGfcqipJVaL2lS7RsmHS0+byDNKsQClt6oqU i4W+5ORs7Y4saLTtgqqGFVKrxSO7dCsPTQ09vXOHDSH7TqQrOaAmNvfqi5XXI50pnHHK9Nui WF1GJWV7OuF/XRZdZ4rMZrmLJopbbC8wdT9euuWqiofAkyEAR58nzk5yxcrjoShdQlShOI18 og5RrDSn0Z5ZiIDEh81QaeSQQwflmb/vyKrDE1iZHuGc73mWbhK2WYfABYXxn9TAw1oEVDBM REyhZmhZS28xhIVxPRxdTuVNp9VFH0OFN6BqT8QmIMjCUONFOYyTQjErwcKNVjkHBTNH8Wue ejkZnYeh8F+TcxrOSwiwzlA1SozCmK4DOoS8PZUrMYSGzBDK5hXZKtIkVLTI0NDQTHvG6Hx2 GeHZjan5UCsL1zqi/Okkh80BEokVJiK/Gf6JthZAgAqdCHugM8JwWpx4k4bl4qqkWYgpQsxy CPZQ87HCqeu0wVEqK4G2Hpg1uasSIlZERcVzmAGTBZstypvoTCYmhiWsgg1kXEwTQ/BvR2Nk JdVh98CkQl2XmQGWAGhYKwnpIBdQm57txrgaJiDXXnXVzu07PvzhD/btRfVFBn7vBz/6+te+ qty3MCMABiac2V27dr7vr//mfX/7t39I4RFr++SnPvObX98i4IIIXyJD0c6AKlkeLk8mZnrb t28LmVaNp7xy5T2Y4w9lQzIQp33rhrGrmEQR90GYQ7QrVUtixcp7atErxDNTM6yUj2oPrY7v A1WyKmPxQG7vADaZ6w//876XZCsjhbfZmDfCj71gQuWTGTB9XsXo9wrXVnVDHIa/rKwNepF9 iCbgXrPDWu2VnFCcymhR6KoDOpCZHrz3eJLs0O9t2N7dsWt6Y3shNa4StL6S/sIw5eVzad2N bDjzNrC1i1RDlzgBSN5rgnQIcn64nHMsGt75oqP2uOWBLTXMRYkhIq0T7tKXfGTkAF2YSJXN KswJTJoiQAzlmMeBrBAnMC+DEZocLE5IPh1hGdj1ViB5GVMMtcEME8v+qX8mbTPpaUFZEQUS 7ZHEDIB2SW2IkeSBlgS1cup1cOMqI/GwDlUXQUrDyNYkLB8Gn/CAs7xhWonr1uAxA/BkpAV7 Np9z4TS2u1oNEiDKCpmqqoZIbUDghEwkgJGwgvakpTxUBRlclzQgsXjuua/51Cf/pcJDffiR f/qnf169atUee+55zTVX1U7mjTf94iMf+XBY7ZkvO/ucc85+wWkRm719+47Lr7jym9/4ehhp Tz/9pZ/4x4/dc9/9b/rzN4YNnXf++X91yXvw3R/+6MeXf/3r7afaV1zxrWOec1Rtzd/45rfC WXrbW95URzlc9BePPvLwz352Xe3zf/nkZ370wx8kwrO2wEUnzHRU/FpDQyXmkCYEMaCi4UqV w5hoJjwRj7FKlAUh81GoybKSlCGjwtc4hNy8QvUIrxC3Yj+NKpW//s0t9/7ZPaee9oKzzjqz bxsJYWbJ3ct+e+utd91xx1NPPokqKjK8ELqIf9D0scg2+3T7qY9d+vdXnXTy6S85/cQTjquF FoswvO2223/+8xt3bN8OPW99jCH3snnzJgjJW4WkqL0fgaGsCR0299PrbzjxhOO9kKLCjXnv PSubdN/H80hNzjVr1oBOpQlcohcAvc20LlofXg8+uFYll9I48Gb333//0mUr7Az31ttvr+V2 m7dsDstwUiF/2LVrl625bdq0STenE3so2ddigKDI4vR08+YtZbCkeOKk4gemSCLCjF6O1tU7 UmUbSUNybf8VJ2J8fjndBTKiVjPsRaPoGiq6iDAPZHQExwOnoReNr9TVC5s+KSOdc887eLcQ F+zfn9jR0fElpFYmOLltU7EqEDKwEL1w9PsOTR2w57xHt+wQvlrcosHiU7CpHt0eC0aPGttp MO5u3VNdFQTB6RfAvVjE0vFumkrdfNVwiXv1kj22HXnKguVPNe9csyURlApSKwhtQN5CbFmy MllxpToGRtguJVu2b4czKF0cnwvykBtOCcMqxMksL28H0do3BJ3M4PW9+oPoMK1ADy6BQOBf Pskp1nqDjPBCGFLuijfWoIlKTLlSzF7pz7pXKHOpn1kYDb0rLEzDyWqj7gYlIlzIIsoPNNoT k0SzCIBE9LAAWK0AlAPiUQvSDd9QUCJSVZX2KDHVQwzfiAWwkWG0fK7/2Y0feP/7w4qPPPLI yy772mc+/alXverVg2ai4TDPOPvl//SJj99z7/3nnP3yp7du/Zu//dtL3vOuZz1rv09/6pOM +qQS/V/9zd/8yWvOPe/8C8K4dMYZZ4WvHHXEERdedOFb3/qWiHo97vjLv3FZiHwveMEfoXP2 3vde0rcXg5s/LPmiF70Y9Luvf+MbH/rA+57Y+Pitv/1tM2m081mKUq1wrBrj4xSBeOXwGAOA kLEzpi6hORYsMYGmKR1t0rR0jDNK4qXwAQ8cLtHGIMOEwk3T4A7wli1brr76Jz+95uqwwLOf feDee+8jYSOu8cE1a55++mmFrDTI9zM2hCiuNlwDICi9gUIEWr506dIlS7AnJ5x4oidfeXSx w7Yeefhh7jCLWACwv7G3I6SBn157zXXXXkuetkyb0KIBHhuc06995b+09ad30jDZ4RQiqvbv //ZvWkFt0v5ju9oNDlu/5L3v8SUnNJXRBPUWZtKsWL4s/EA9RSUPEB40/brxhhtuuuGGXrCG oU+5G3/2s/BTK3+poqAwlJ0VGAzvb7j+uvBjdJVojKNTqjlQ2f1SySnJG7zztiTYK+1YFeGt lDGTipjeoHJinUBdi2elKJeroOQlxvsiL2oAOeeUGOxeeMTuL95jqyUczPjGo1t2qqYMpVa8 2pmi8fCm7TG87fLJwrJoumj3oYc3RUknACmj/ahcO0Qxbw7n1MP3OmWPKR3xwjIbZ0d+/+hT osnudDpQowCENdyxevMpe05AiUOPZd/W5L77JafvM3rbk2NLH965a6pt01Mj+5TlRibDSQvW S0ipod4pknGHLFc/5TyKRallmtrBeEkyKsjDWCNqWnlManLAb6xrZSS15axSHZbNmhjDGqXx uqzKH6I7HJakmauY//mkPskWGhNzXemgaN4mqsGJcVdxEvnUiiUEGLwhwmKmUqslpsOzjzOB nCNeDEU8C6/XrhsOjSUoKV2IHR0quuaGZNYR/AjpmeT2iVi7bu0jjz4WEqNDDzvssUcfRcw4 48wzkX3GIhYlcBdddEH4/dnPfhYKR5/8l38586V//No/ec3//uEPUbWLFTlf/PHpL9m+Y/vK lStDQnPzz2+67w2vf87RRx144EEPrl6d+55CSMx04/v//PyXvv3tb2mvLhzawt13L8H9VPy8 e+mysJMHH3zwnXfcARypXikohbKKtMBbYpl0ZibiKrIKv9NJ8ZbNvfIIn1HWRwSJFAUk5xsa qJQnYUel2Il1EaiqBi040Vx7bcb9LpLCdZOQSMK8GPMmYB9yA1kBiLZFwAow7DB5ZIU9qmXP tts6w1p69xI7p4O3jcgwtiQMNPAExpJgXuJr9VbANCdESqBFxVQsBcWhxLC2Ih4UZevU0DVY G43us5Rmrd32rDdaAF4wu4XgjxG0xEHClclKaRTi+LYweYzBrwn/yRQDqxJKdd5rxUZE6ni6 rYrOb6ykiaggjfHhKdIshuKBcGNdFQ7hyoqcGLIUFl5hgpZXs5WE5YvqGEIbzPoq0CMMM51Y S2zSabSlwgrWXqqa74zCUalImGytRYkQA8LjRj0JPzbSCqlVyR+fDtOXybDRDU9PJQfwsYTV 7j2SAwgedoeZRs62tZJ3H9ehOjvu1a2aVwF//6PfddPUZni8O7VqMU7Fj1a7Nx3BsHhbnxxO Oy/Zc9vpeyXLtu++/PHuI5u32wceY6iGrrKiZXCDyuhKVbRQuFwNWUBZjF0pvinijm6zXAcj 1pWXuysTlzW69BwjGQMdLlKDEO2eU5Zcsisvqk6aJiZVSxqNAdphYqIYgA95oXbP3vixhfU3 VXqD7rEIyaMtooTI0/asgdK04ji8uFnGz7s8kkTsA2GwWclCAHLxDDTCiSp0tAkpRVSKcuU4 OTIyMjM93QiJCDpYUiwtLTcNEqF8jlyF/XLw4oOffcD+jzz66N1Lluy3337hw/nz59115x26 zEc++rGpqckDn/3shx95ZNWq37PwY5KcccaZgAUeLMZMoyOjj2/YcNppp37wg3+3dt26a67+ ycUXXRyrI8hQuyW0ChUyHQzf8+53hh+8v+/+By6+6KISK5uzTOLJJ8UK3D333ONAtXINgBLC tZulYVOjOxCnmEGyxBcOn+sVDmLxccSOJ1RUKItCbZcRuuLQXbJHJaWF/Ak6nDBh47sz3mfZ kFHAVHpEh3IdW9UFA06rBGGCMD0zE8IpWnlhTeGs+bxEBymLgn2ps2HtT0T6d55Tx7IVvgXz C0zxLGMj0rPzbqZijqrNmJVzOq2rlCzFjGvoqVjashc1nYFu0rWSM/o4Fa6Ah7d3hVWlNClI WE8X4CuakOpYQ/EmL3qDFl08wSUIwd5SqawkubzJbKaS9OjhgrMlSr7VgZ4Vqrx2iWxbq0oo ozJjRrblWaYlx9qGdPdMFcsbtcaKznqfiGWF5EspDV8TRNaSpu/XKfRV/jLijx7HQzMTv121 Vf9+8N5jLtmmX9k0xZC0p3bMzBRhTsgh5JDxNkIXkXvAHvQ92oa9+5L8csuCJeu3b985qWdD qyNOaqHSOGQ+2aNbdlzpJ15+SDOEVedUs8MpA/qEedtPnJ8s22/3Hy/bkhhx3rzUn82skZhU BSKIAykXSgg2heryQ+oyxalHAHuijK4M+A7J2JBuMrtZcA2ZSdcglmh9F/HQpS2ulaEsqRGL v5u4yt0vaR86UqC+OmEgcSAU0BqHQw6lqU1reCKL0oikF1FZUeTxIPwR9wrVJmGhhfdIv9ii JU9y4ckWnfhXlRZU3nHNbKVjqjWM52p3czM6hbEuDqHiHxaJfdNTAI6f/bIzw4+u6otf+nJC Jda+0C3YKO/YsQtp0F+86y/Pe+ubNLbZhT/3uf8IB/+610ZvjQ994H3h9xe+9JXvf/e/21OT Ec6uDbnZWQbWud7NJW1RSAlx9L57S/2HH/zw/6xYvlzloAgK2432cXQy46mO1PlZ6HVpRzBE KBhG6vAJvGaJMCxoAUj1hzRE4YiKKkGp2ot4JWAqkbBGmlfq7xcfN4mfFdvTgq2ssd8RHkme 35BRSYw363RUxXc0Ysa7KowL4dQPj4yMjY5FDnmzGTYaUaoxvjZVrt8+BmEvZmejmmKHNPZZ HDp6CzXCSiCZXIPB8NTJJzaJLMkEInSmtntqucvPRtbQiRLAsq6Ufo95oS9VeeITBZ1fSi49 /L9tgqJcK+pFMYAOAlR4cJEhxXiWd6vlNScjIOtT1ISVk4pLb7dSGPS2hydEWvFVAko+6YeO F6i0jNlVrHZiBO7E3NIpeVZ9sPpSqgdkXUb7ylWSKlei+Cto/vKgqv7yripSsmzHvG/dvV07 fGElR+xWuRe2zXhgysPX1sc8jDtuIYwdtM9CGvHi7Ux3uOsJXb43jB443t13wUhSEfnVimd5 Ln3CSmZQ43lk844v37bt+o0LNrZHqhdBkCs+6ne87fm7KUMDQAOZEqmSskOhj+aWXW0LpdBU q+pE0MZzYBEd310pK2UIxEOZ+AWrWLLfW0c8uuivWdkek1wKkcZqXigkRCWFAAkxCZlD7HRE tS53QDoRuv6aM3LiGF6hzmE8mCIUOfZoLorSVEzPA0MWE/Z+Qv6EfhjrP7jyTsZs287hGArv k6TiD95VTRD2JzPiHaptj+FxmISasEc33HDTscce/5xjjv3Q3300/PPP//wNTfJXRuXw+ONP fN7zTwk/4c1NN92AHvnExDiqSv/x2X8/9ZTTbrv9Tvt4ghv60MMPXfLe95588vNe//o3fOOb V4Z07S/fefE5r3glPNgULhB2g08y7c3nv/DlsMKwrfBz/tve1hXhvbAnJ550cvjwrJedHd6H oHjwIYeAScnnyhMGx3HC4EglC+zhmekZ5Vpk7GzBrWxwBgAsjBD8nDMlZBdKVWSVXtUpYWYZ 8pKsoR3RECfyotBWqqZKTqFBoDZ3WZYYvH1P/AZG2xf8V0onPdgnQ0MtqiJyD7BJ4So8hy0K hNMz0+1220zJ2YSwQzNNpGiFSKJZF4xS1lOOBXursl0q26hilIoHhQ8ecEpOpMmwwlJChmro oNdQZuNaFHfFkAYf1pF1tTYP04RNy8lSrHwpE5VUq23GGhE5kK9EAnV3ZGvj2pqlKaT1NyVR eclR0Nep0nFLDVzzp5pdb2E1KSAeYbKuJElcL1KjVkjE4agAlV4yRWf04xUUvTHXBq3HZ0d/ 9eTCL97bumbl1jCr0Dgd3hw0MpUYE8+1m3ZxczsvNk5piIo/i/ZoGjab3dYgxcJ42haP7Hrz YVOnHr63hpMk6RUecUjiSZaplB+7fdXmL9227Ru/H715y/yZotlz8pOw8nOO34vlDHBjcH8l g9UynjInVCpvAJmV5EYfauHk9lOn5IRM1QK1D68RTjUPk6pIayrf0uMuVZJFMRnhig1mWd6e xV/kr2WgTV2J3bCGgqB+igRDibbQwonCDi1AH91x6InqOvHToHaF6r7jVgTxiyUtRM0Wf+WO nc5UfDE1NQVyNCSvlBKQiAtXTZUqZ3131F09ZI+WUQ9l4YIFVBL0ykhj95ahSEdbsuSuEDwO OvDZhx5yKPzJwsJHH3VkjYETlr/pxhtvuunGSDl9+OH/+vIXr7rqmiSKMI2RbU1Xcy/V1ygb j1mZhFgYPT556smnHnn0sfDPefPmJSJHGmtpTS7xWSJE5kqDLszZ2pB25Cm1z7sotsfW1zD5 UipkA1LyGF3bMzMNsK/0jEe8japbplyRi+JaKSXXPgX0HDXDaDOTNjvGYw3lY8wmOsKjLrMc 1hHhHixQeer5xH05nrnHiVjaaqDAqE428BSImphdZnFDICpiIUmYUWvZKJJwA5ACvlIoYNpm CwtIsDTJQ2DHg4TkDxbDEMxulvWZwljosuZAHgVahhBi1LlR2SH6oc2BLK5PhnqnaHhkFaj+ ccSSXg6yt57emMzWPWPKMT9gqUBfJjQQXyh7bMCmlyxcXwXXVVhuPeHZ16i1moH12jamFdJS 2rcHJlONDHHeGY6zhl42TahsxoVA9eT2KbP/u5ybFNHIstF4wF7zRtykRpqNs6OTM7tKOvnT 3WTP8nAOGs9vqedZZd/r8yubT24DUsMdut+Ccw7qLmSR+LjM6ftO3bYq1prDDaOYQxuHLASj 5qz2yObtj2x2N3e7Jx6y10v2m92tOWO7Zacs2HbLyNCOyWklF7dl4HaCIXSmXcSdyDxHsyE1 vONcHi54H3s7OcgThVZl0v3yzHssYSOiHhSTMtQSMT6EabcXHSlNoXCYjartZ1NkahUh4iWY 1ySnVZWDXcE8R8pc8dI0+UYJsfQfgSwvwa+JPICD7UKoAtgNZXShEa54bu2GYDSIcAOywmKh I7l7YwLgS90A1aEI23KGnQ2AOOpeOnsIA++s0SyGyD33XwDmyjlhr/W9Qtw6+5xzvvyVr33w /X/z3ksu+dillz799NOf+MQ/hcUY5tfN9Wr+n59cfd5b3/Sud7/na1/9r7zdPfnkk6lZtTKe nKRQWBbP46V9++53/UX40S1+/otfvvaaq+3DULLOKSC1JDr4PFGSg0VOsLbI7CzaWpbsjxLO GKENRUK6waQCEiWBxAYifQMIer3e8ebIuE6NMjGrNfuyL4oAxrQ+0TyOl7lbOpx28lnlBvI9 IfsHV9ZWq2XjlugP8cUKt06TsCHh+9PdmaQbW2JKwNRStbL2tLQdg1N3lgzQSCmnU7CQvkB4 dcqjM0Qm5Cfxzo53eZIeeOCBDz/ycLxTxR+I2RsunoQQlYeyVNQTytYO6makxOMxIqkEmXVR sh8iMhUaQpSoq6OUg7oP02+trF+JXQsBjPiApr3kKjGxB+NO0dHbPpbKCSrmnFH10nvjaFfF tRuzYPUCLiqlQpdoClWhB+F0UTkXo7lqKlbCsNl/bRBqT6x2NgQlbxGUJQyk1hZbtFvTVuT2 G5q69I/SEoGcTHrGr6RIdCbGhnfGOFFTTOZZgvb81jy+7Xq38M8PLnGDI2l30T4LH3piqw5q ldTW1WzMfFI1mMbnK9Y9uWbj0EUnDS+05ik+2X/38ft3TCIIOYHzKeqBdZ4EMVHQ1DPGhryc HdvhMkkq1sY6WENoNeX6MQM0vNGjcgn3xhgBn5eiIKXMPHdBYkONHLETHZq5YBQ7TBXwiAK+ VJ4qo+ZTSsjnMq9S8m/Oevax1S3qd1rIggweGioqrKeuyohSzggG2vQOZwMgkdhSyYbKmahL VfBeS5HhErdIVMlJ6qaZimhC8nbDKJdTGSnx1fKMS2amo+Xx5s2bQ3xasGD+SSefvHHDhr4V iBBNr77qx+HNK19+zo03/izm7rff+Z+f/+J73v0u2lx5v33p8/+5a+fOt7z5jWiM3Xb7nR/5 6MdWrlwRAqfNqDJi4GUDHBPtcxQjEMWFnTuj5OZxx5+wcsUKWApEepLvNjw5vzQSgF+scjGQ Co2kARC86N45O8WH+jDT+em7HeJ+wQy6oQgFBLd4DUjdMsSAaEsqGr7RVZo22ZH5Hc93Ci5r 4taBblX4U8iao8stQVcjyVzagDy/yJJ2uy1IwtwSMDE9VCAmVLyGR4Y7YjyWEMMyTwrByXDw h4tPPAtUPOyQXBjY3Zo79DIKWbGY6lRHH39MeJ39srNWrV7zz//0iU5Ud+5qx06xT4WEH5U2 wOhPnkY5cQMaeoFF2iSjsaBZQVV4EHI5OBVVV8xKQc/obpi6ImtvA8tucYZ2du97sRgyXtj1 VBICGjBQGgWyz7EwRFEDaFgdDeVtVGObV+ij3pFydzqoy+gxWnWoMoAhXFH6FRNNJ6HdZoQ1 qEbf0+gqSeTeI12TQvka7kNPhBc61+K9xlaun+mpADs5FV7EOKLUYXvxyHDa0dO534LWI5vZ Kc1X9ei5epIX++654D0ndBXoGPb08yuHntwGxEeccE5Oz/5q4/zXHDBjN75gpKyawKEYdwKY +046QPqMIwmIhT4yt1UUnJW3KMTySgHlZsrlaz1jhJokK3WBGTSIeZjx8SKVtUTYHV5R/lmF K1ZS/pVSpiXNWsGwBk/X9gTymKYUD4uksJ2S+Mi7Qo2fEmvELCq0iQHQK5qR7QYjcyLR0S9+ segix+KhyfHT3cGzED5vNaDWyMbQWH/Ck2aIcQBVEEa5sBvXX/fTn157TTTlmg5D6G4TExMv etGLOfPIi1NPOQ25SxjZpiankPyNDI+EbV3/02t/es3VaBPCaeVbV1yBKcj111/XImMR74or r7ziu9/9DgXjZsEd+gY0hu6//75TTjlNL18Yn7/ypS+Fn7Dzk1OTPPVx7HP2nGOOxWmJ8bvo vuPii+H84qg11RDcn2YLZYLlwuA/Q+tnzvJUONLolZyL6MkwVB9jlTIdUjIo8hA7q2vg/kh9 qdms94dW2DDpwt4Mkf5KRPe5umVOeEy4nkuFuET8b6Z37Sqd2ejijzSGYxJDryZJlaibKiIK ZAIwuqVS7w7PHg6jOdQEaqO08NF0sMs1QKynmTbBUGYUg4G96mGG2+LVr37NBee/DSzpMIm4 9NKPvfJVr77qxz9WT1Xgj21RGDDQdt7OYhWxoTEsDvp5atxsUzOjyWwNDdmGAivKKhyCR55b lLCygKW7lsHUEQEG+ZlGDkQCzWZstS2VrKsmhWWV43VzMji7fvq5vreVVa0QliBDPT81QQ0r HmF1ESVvK+WYtPzujfmVRZ37fjNDhGRlV0F0GJFs0ei069Gy9IMnmlEyyuAmXCW5TVhCVNxG potsOC2lMluNAc41jmkMtQ1yibdgOoQK9j/21FRyQEkF4yAuY02D4eO5RtyOgTvl3pC6RN/d BhiUDZNuYSOZFgwBXmAFKcEoKt7P+i3A2doZ+pS3BcaKCWphv0h17IINq6h6iW15aUZovLGs GMxx27Ox3KJWh4gZGRlJc69LBYsFLqEuPPBuFiew1FZlcHq1c2YLSLGF4Y2ILQVOJAS4LdjU cYg11DsdWFx1Kzr6MCA2MvnQd8cD0gozb88wOj4EV+A6Qm0EOJSwz+Gio5GRmDMfic/Uv89J WyQsP9wcyUlbGSlEJ+lggsLUaceXCeiEBpW1cLanp6eRhTeSqDs8K9kPhPlVpT5sUQ1CeZwk WsJsPsumZUUMuvFJaQ5NTu7KCJfRyBsQjmBvZZca1KJw+R2TvRSaGDOF2dkGZPbBKFQt4UYD ks2xVoarkqXo6zqYRqN81xAHQkw0YCcDGGhZpJb6w8TweN7gXmXkZCQMRbXgC1YyFtiBQurV jDWjSQ3B7kuePO7yYZrdcImgIGVhYIULQwbsFirQEu+JbtzhgxYt+uu/eo+qXn3v+/87jCkf /fCHxsbGfvi972HE0goJ3XwZ4Js4Fi+SuOp1K2Wxhquixr2wvmq0X6rRdbUqxZFVmVtUME2M v5TalMjjVKYcWmPUVaOiaLMWxIDekVoLfSW7uSrGWo1YZQ1NhlfXk5p4a/7bl7Pcl7BsT5Gv mk6WqWTPEbjeNptgNLSQiOM+dL+Fw25HP5x9TTSxXNVBo7NlVdVEVW0NYuJCD4ibybMoA2Cw nYNcAhzPDDPp9nPiFb67+8TwUzumbT9gNA4pHfFnoZIRJZAgG8WMCqIVRpBCOcIYDlw1INXw L05R8uLGpG5hNDXKcmM4hxhJFXVnwR0p69k7EGa8AawjGCv5jIV3DXYfHWJFF6NqohBzncVq JC7zpzTVKAXIFZgAOU2jQWtJG8JqNdU8O6O1GhmFsS7jHLSRVjI/Guu0U65VnFL5AQOasMdK l+QeUIlC3uyqwhA/OhK1g0PSw5ILOUvOWrxok7r7nsY0EN3CG3RVuOXfGpqemUFXKEYjGhXx pKumCRIYiDdqQTgXmDQahIBTwg9FFZtCrhkiFpwgndSZZqdnNYrHjRLRFq2+kPOENAtDdDPi U9JwjIR4IYwoWqqeNa9tShC+G88QYRFzcBtQPMOFxJOKdC+eyiQePPxaxA0zVjBiuY/bwlKv iHG9QIEST8vo6OjU1BQ0Axl4Q+yyyampECFiW3U4fj45OamULFCDCzHPJj/pdi7FEAamm4Sp I7OYGOrieO29zBSgDqnFhLxbqEN06ku4KtRNkCC++S1v0dD12GMbfvx/fvS+v/3bKOd1wXk/ v/HG7du3AYoyRE1mAj22ReetiRhf5g000tK92GmVjRxfa2PUpGYpzYpfpLq/H6KVGyyGZ0dB Hkrii8Shy6gZZjHMlanmBYrFqMMdqwN6WeujKjmX9fgBcFzkTJJS1MPELRm2eDZfdUb2NuD1 am3UPxfFeoRnVZT3PekUgJR+rmSpXgl05uuLFqa2aPi7yXk/XL7N5pfhzfyJ0fedXNay9m1N TYyN7JycwYmT3fPcqI5ThHByuJc2XaSGn5CMDrGPcxSXYWZd4srWXAx4m5/eNePHhl1XS51H 7pmu3sBDCRCtR+/bCnmdjdpbJzs4BGCU1H4JT6str+GxwmJAQ+DBKQwBJvcl7VdQGEUlW5K1 QT0hpd9UY0DttKwEqmJTmlWc8DAYRbtFyHyUNOo8iVP1FLinxJhpAb3FORxxvHjIEhCa2qNk Da5Z4XRhhGHQoyC/VO5dN5EYhaqSCyRAg5iJZonSW7V3HvIJrEo9zDD1r9yrFMC4tYyMNkuU nKNnMqd+CrB8mNCHf4IvXPJQKSuY8sX42DhNJNI22Vyp2i8giCgq5uRFAml/FWWP8SlJSVGv mdBcXHm9vEsygYpfacR8yCkuBqW1vIvhviHRMQJYOjPcgmqMs8og1Q9xlpDhsPNLTuY1pgxY 9qqgW8gge1l/s9wKvsjC8+B9I7AxJYLeROVcSYYwZDtpDkULhpx1mtFuRcDviOtzlHOm8xh7 a46Rx+HDUdLn1xt3ZGQkcj/pXLMZDOx2EGNE1QllQFcRv2KEbmTVRWBq/JO1n4/ZLuqThVdN 69g20/qn8RqfFYDiqae94NWvfLnecN+84spDDzv89Je8iPgTE6f90R9haMBqcRWbRsS9WkkT eZhYS2zKaOiSqk0wkcp9jSyCJanOyjMOslzCb0f3RyX+ScBLKIxFeEXCQ3ocGnE9xCjEV5pn vtCaZMKUZVfC64WkReEwsfFSwlVugYXSZbUFUi8SvUVfwGGvaZnVCsGDbelcFnhiUOaiNu8L pXb5nuof19B4+TLhPGi0Iv/zxFQ9HQxXYSo8l0Wla33IPuOpkH5KwUWIugIXFOmJTaSLBq7p Whn3I+muqCjT6/wm/HX91IgzGlEnzt9x9rF7ApkWRvkzn7P7KQu26V9j6OoOP7J5B+tThHMm qHcmbwiFFp6/XBRCPywr3YpdUsKLSnZXOcH3Rk2wrLCJPASmGhl1zXOFICIHdcpTrrIdIH2p 4CKB6WdO8PQqKo9dalLdTEuLTgYlDCDqg5GImDrNtl0NjeLVK1mkKKKfLbmfIIFDzmqfStYT j3TUYeWNqaS6StABygFrQM1EC7F75pHTFAxZIaHD3aAOQfDxISvQi92HVfwjQnoXCvos74zc jpAmyuDG1zPRnYAC39TkVFadQ0SBWaOzhcBJ1dQMQAcUvTKp05YwN8+DVbs9g41285JxVLZj PPPbQqYVMxlAKJtDaHehu6SICiDj8SccmdqjqPAHpOShHQXxlLDZ1vAwk7qAKEXyFHMjWgIZ pcJRAPlgfKdk36hs6hSAxZujXlqYHcxkBjFvZK15D7oGE6GVDYSHVqOVkKA1nrcSyCukaWG3 8P3P7gBFbiHUKArHrbQaqJVnpAulJOvZmdk3vvENVgX42muuvvybl6vK8O233qrg3U5EgrYs YF1zEXSYANKrjtEeyGCb+Fht3GrDqVxnIpEDhZre9hKgGeGlQAlR5rXBvgrhkwGXZXkJB5FW h1G9aWI/Eq56op0h2Vim1C6NYUYHJNyLYYGuCOV51mytBKpeIccKdL4ETBr3SfXJNFohFCTS 1KLXVYGe33ln5K4covXYyNC+rWmbn23cmXtjsKnQmPXTI0eO7dQlD19Y3POQ65UeqLFTFYdS RtySkxfnXM4ZzcMyCvqljxdHHqphOP7/lIXbnv9C3DwhKG5PSlvn+NEdW8KougMdWbC74KWQ 9IhWUHPel0mV+RN5DTcUFKdyt2hygFCsKRor2xJMA/eDWqKwqZjpDOETBluJh4sqKDqD2tBV weTFalMhQXTS3tPKJ1cmRSNRsxkullKY1fGk92ZzBnmvcQgpWqk8QAEAUrwT4+PTMzOMYcnE wliUtECksXXrWBkjcxPNZQsq6zGnllT+cCyNVkNB+UVSqEIChmwVa6W65TDOJw2qUeZ/cmpy dpKdhEtnS8AlfMqobE91JlZdzlyzUt73FOrCArL/XhNQLV+BkKCaD4i1YXYbhvdmc2h0ZFR1 i2KMaM+khe2dpwj5UidrINBgrhfeh5QaH8YH2dyEKNpFslejEdYZ94FOWtpN2zMzzaEh5nvF nLfd1Ralz8sSLc4CCHHh/svIneyii94R/vSNb1yGGdCFF168adOm6667Nnxx0aLFp5xyapis hKty7z0rb7v1VjQzX/u61++zz97hvpjcteuuu+485thj99h9d09DJ8kVp5s3b9606Yljjzte 40L403333bfnXnvuuedeKakoPfLwQyuWLw/bakq59i3nv51UuuMXNm/ZfM/Klfvss+9zjjlm 584d3/vuf4cPX/yS0xctOmjTps0hJuUJzzVUGDTs2Ktffa71if72t7/z8le88sgjDsc/v/b1 y8fGxz/28Y+/613vjHPAZlPQiTkyFUtGtvbBJGelRdvEkrFK1/a4krSsquGBpEhmn7dCgH9W 8hGjiYI+emhVvsYRxoaSErxQ4ZjVQIkg0juuWqf284LT9VShBBq6EKhUu9KK8FoER638aNPW siBpHER8T82TUYhS5fPiv+BteZCxgi6pHC6XVckVZbutM254arKEO0rPI7x9Yio7csyA7Edn iO9c9GIaa7qU7cIG2mS40UtqVhxKeQXXbtq5Yu+FJ8zbLh1F14OtL81qlu+Yf/uqzVKQLNB1 E03tXJ9l1eDwFrMnOAhu8oterZ6QDvVOrHigk7xKRajhnV0antHh49bVSWrMAsUsA0R7SxEr NaIK9afOVFXYYj6ddN2cofCrQB+GYLTHINsI1KUOtdozazjue7GGIamn8HlIywEQZcDZfBaY i5npabSFPOu1Nkr1uBCTXAwtmHM7IRSWRkIo+bRY/RW1xJhLkScG9GejxpArjYwhzepE8yIO 96LIzrKNlLXAYUpvHsWNh4A3Njoa9fVF5TYEwjARHx0ddcK6Y2W7Lt8A7fasnuSEekbeMSG9 Ifk6WkjddleRZa3WMKhv0bQTcJsQdFvD0YGz022RaIjOiso38Y4J7xsjo6M4CXHlnVRp2hH0 ND01f8ECzPmi3kXeDREu/Mb7kZHRtrigNWx+rZcZHVRaY4oZK6Z1IUF+x8VvDwtc9rWvhjlI WOzCt59315K7r776J0cf/Zz//I/PWsevn1x97cf+/u/f/4EPvumNf6YfPvbYhg2PP/785z3X DgF33rVk6bIVF194vv3wa5ddfvzxx1n7lXANLvmrv/79736HR/HCC95mlw9//bsPf/TPXvcn YR/Wr1u3evWqv/vQB+bNm3j/B/4OPUBcABmg4wW44Pzz7N6uWb3qE//4Md3P737721/88pfC Dpx66gvuuuN2ZGDP2n//l55xhtPprU/uvy9E6pVnnHXWmWecEf79+MYnfvGLny+9++5w6t78 1rfJNDzs3q5bfnnz1q1Ph8t35FFHvfrcc/fZe+/wmNx6++2//MUvtm7d+ua3vrWcznuPePzS l54BAn/4MIT4G3/2M6zwrLPPfsFpp42Pj2984olf/Pzny5YuxZ1x0sknv/rVrw6f79q16xc/ /8X6h9a95PQ/DvOA5UuXzp8//1XnvsYROfHcc8/92KWXKpy9RrSSsBRmxB2pHjeTUnpcg3FD Mh+HfMskVb4qXuUlpir7LS2MOYiJc2WTzIL4K++pNqcZqks6/YOcfSPOYOG53Xe8kj9tbI/u mtqOxN3G1PDaOl0JVMOuc9A+C3bNzPbFWFpYyrbZLBkrQ87CRm4RldXpgrPf/fHyJ2eO3fPU hdt8nQ0GYXs+ousen3/b7zcBel4mi7bI4YuQOWlQT6Ro4aoaJYBFuKzUnihlA0tttrgakpN3 okSMclNmdFUAj8xZBc1EKbROq76gZQxGkuQNU1tFfiHZZltomqUpXiOi49JmWzhqgDZk5j7k 0d+VqUOWZFDE15SLwQuORbe5dNRgfQ3g7FthTa1WkZYZthKNES+VaaDYpXAJRhpDFpqBXDYM wSkEk6Bmi79mnPFESHY3fg44Q0I1SRRyw1cA9lMrqxqCnPRBGsg0UDPUszQ8MozSIqCP1ClM UfNESA5HN9tud6p6sAoRgOGysq9iNbsxVE7cKWucnp5GQWtkeFhbbpgoeJn7RvZqtzs2Nh7S qUbeQAKKoGs1FUHtil0UpXvTNiHN4Sm+zkJmPhOMprVpxwFb6d60kmAKuU98mMI///EfPh7C xu9+v+ryy6847rjj3vjnrz/3Va/4+U03vYq6SiEYfPJTn/7jl740DLXbtm395vjEmWee+Zpz X/WTn1xz4003hpzs1NNegBASFiAUcbrx8Q3HHXdM+PCzn/t8SM7OOOOlp7/kRZ/77L+f9bKz vVHKeO8lfxPmGh/60PvD1hcvPvh73//fIaC+851/sXTp8hC6QmT97W9/rbiaMHdA7b5wxYUX v8MaiX37yitDRNHo+/kvfPGU005DZvaOd1wUohemovvss8/bz69Ezcu+8c0zzjjj5ee8DP88 KUle+YqzP/zRS3/9q1+9/fy32iXPftlZF1900f/3ohf+8yf+QT88+eQT169fv3Xp0tpql9y9 bPOmzeFY7IfhAP/rS198x1+88w1/9lr98BXnvOyf//VTN1x//dkvf/nfffD9+vlhhx7ymX/7 97DasIfr16795Kc+dcThh1573c+evHmL3PR1tSepBzrBskNJ3OGB12HFVAv1i1lSccj0aPg3 ZXquWrTxt4U1Uu5Fvi0V2EWv6aWiIktZ4R7ooRclpNQ5wxPwzqOIGGndR0xMq7kJdY90zzMl jyeqHfXsKvJwt+YDG+smqM7VSqPJxp2FX6CwDrdva+r5h+255MGn6hPzqhoTctYb7n9q2fyx o/YdOXxe20rgR27p0wumu/5X929Jki0IHrlgH1SpnaFoCRXcpNrGRslVbjLxQ1MnCt0i0WRO prBlJB/KepCigGw0k9IeTOMNp6Qx+6E+XK1IoDQAMyViXwG5f1QuxMF+TClcbFOCCgphVXx1 Cp5IbwyUGy0wcjsHiRcx5SPImQCBUdOViEPlPF6dXGj5IfLHwCQe2gWZOGfCCSyMLYpLDJcY yoFQSXbCXtBwAiNKMKXATwX4gClrjviy1PBDEszglCZLI4XkowVvEflTR8p32pnrSIceuAQF r0UZW5qPttttxC08g6qGDASN1nhxEFRTKhTIHmMwvUoXSgi4EDxkuBHhJ82k4YyQY1Q8L9IQ usLXx8fGgZCIayDnaYptgLm6kF1ZzHNEi3RiVqdoT43lMfxqjqWs8jgpaEc7Sr0VFLaA13kX vN2gfl1IvEIkCNnPX13yV9u2bfvVL28eGx8L0euYY45dtXr1c08+Kfw1RJTrrvtZyJy2bNkS 1vZ/2bv2aLvq4rx/e59zH8lNUCvkga3VukrwUYog4OqyLa0VkIAsG0ulVm3tasuj0ioqRbE+ sHVpAMUSEqAIVau2CFq1GAgqEYoiNCDBtksUCyQQJCp53Nc5e/86M9/M7NnnxH/6d8/Kyrr3 3HP247f3nsc333zzol85ggvmu3Ztve022ju81+qVK1/4whfSFimhIZuO5/z733/w7m9/+9Zb b7nhc5+j7Rx99DHb/uMet2v0+ZllM+R1aO9bbrl59+7dJ534isPXHAYAcP36i0HQwBA8XM66 ap7xjKefERzApquuoT392Z/qSZHPIyf6iU9+Ar/Spk4+5VSgozCW5Fre8ld/hb+uOfzwq67c KBOfL77vvm1nnnnWK0864awz//z2rVvlk/ece+65rzx57bsuOJ+cx5EvfvHZZ7Hmyhe/fNNn P/OZ57/ghfv376PEyJ3xb/zG8W676cPY13lvfetbz3vbqae88rWnr/vSF78A1/XRj13+1S1b TnnVaeQj/+LsM8l7Qc3lo5dd/q1v3XnssS/dvv3+pUs5BaD/4bpu23r7xevXk3V+94UXWpJR O989yBS1KUsTzFachm7mJh2Q8h6seTu0BbOAR1ymP7Hy1CEXrEaEryLL0f7Tzf7op7N/c1sn gUtpDhmKD1Ez4X4tTF56x74uf/2nI8Op/cD2zc7/zW0jJ7ibPvbeb4wgxrOx/53+v++h3fc9 NLImu8H/vOybc93068dRxhPn9uRTs7fRv9wFVHndnoxikk3gmucwZwSVKk2bvJFIqKcoKcGT eb15KF3M7RAK+wygJB/905HACGuFyqjPcLIQp3SCgCffoUqqhYkwn6z0bhCXHGqrX1Ihg5QB He0014Sy07txwOj/NVGbjOwzdg5IK7XS3J3rDyVV5bsPG6jZuSwsxjyBNoJjI+MrbPKacjHV eq3U4encKIDMz32ula559YQ41YyLpaEZ0Rm2jak4+zv+1/irfwx8K7xJP9b1sNO/ITX4nk7k qB29kCgN1VOu2qTUotIyr7wrBpBStiJiPLwIkIzAHnK+TVRzxceGNl0IG0HhIwc1uxUrDkE0 GtXjdKEEL03WgsX/K2Meta6miR0VyGQd+E6V65PqsXZRPvaWnGDt2Pnjn/wYR7lr1xM4/g/+ 3QfPPuccSpvgUU466YQ3/OHrU+UAsVZ6sQjHHHM0/aMfrrz6mm9SumMXCaSdxx7fRd4L4tke SHp28tRTezCBjZK8j132EfikH/7wIVBOAI6DMYxyyAXvvNBP4MHvfe/Ms87yX6/YuInyMC+A cYb35rP/9V8/X5gMM3mCSy69tJBhypQX0g9f+rfN39jKbvjDH/oQea9DV6/CF2dmZo466ugV h6ygn3fs2Ek7wp8uWb/+FSee+IqXv5yO+dWnnXbe287D59dffLHu8dw34zYi33zkUUctWzZD P1NCebBs6mtf33rD9dfT9fr0pz5J3pq2efLaU8iF/9d/f+/zN95A63n9wzyi+6iXMEL72tPV T2/atCnOpbScqR7p0/KxhBAEQgsOuvQKcWBgiISbWLMxGLIc6vPuI0VqoR9Z8iOk+Vazo0va iB/wRwW0SWe7jPMYveIV9SMDQNoev0OUY3PL6jEi/ih/Mj6N44zKcVXi0pooDiix35WxqEf4 qF15SShJKgvAs64cupTaJrO2zqRAMXI150k5YQ8xcuwJG5n7lVqxbCXT+/RRVLaMSFUdiIyD 449dgJVJ7SSTiQHJolPyjNUyjJwHQ8GFE6O6laQO7ERRyQPrWkCXxSQDJyG3zyUo6cn1iV/e y6zU+aqogshI3weMpcT+uC5bHU62+U0VdPzo9Za/fHPx/6//0ytHyZ7EpMQk6htxbnUlhP7K G+V6pqYsBMghSKI6rg3yKq6GJ683n/sWPLeXffQS+vUH338QOcratafe8LnrVxxyyMknncC1 qH302nv99df/3Qc+8MY/ftMfnHH68w9fc8SRR967bVs6UM2A/M11117jgryxc2LNC16AGthj jz0W68kvexmz2z/96X8ix3bG61739x+77O677sKfvkB2XHrXwKcHlQ6x2LLlB7HSSdZ0lTwQ uUYvgO189JGPXnpJXFNyzBi2NqombqrtMzNLseLLDzrISPkLWBO4Unp9/Np/3P3kk/iZ8iGy YytXrVQ/N9a5VEmIxFs47Jc/csl6vPnh9etXruQZ1qtWrSps/CMOiJLOAlMSOJUZtLIQ4XXK qa+6cuMV0bYC1x8jNPqwQZ/8UnUp/iO8jDZjG9mWD/zFQA2vhTgR35GiNpa3PToq54bbWSqe LcUhZ4XjhCl1Jn15zSylA8oBl1UcBdAa067DqA6YZY680wU8O71u0nQ5MFZe1lPuUDFi/9/I 5M/OwxKEV6oRjSV/Lhz5KVudCxZlye30uDJKPxjhW1TNIF5qgto6r6vf/9kGpyi7TV1jVa7x BonknYVFoK54rOPnFdWkpO+z35SNn7LPc2Eek33L1RG9FxjLsiBuj6zeYH6+6LFYXTvaEI2t mKMkPs81f3FDYgIGDh5AOr0Tw2jcLt978MFsYzlNnEzmNDT5Z9vr3BJlu+33Fnt5e7jRkXy4 qBXgMXmuHTErv4epOk0RuLmpNa026aJ9M48NTGhh4k4326gl7H5bef2cumHj2YmORSu6PTZt t3hi1+PoPeeulTmeuZetsRg9VBmDm4Vk34ttehRxSFNbrw79+eD7NxJ3+17uvON2bkOxK/fU U0/902f++Yzf/713X3jBunWvJhcFGsUtm7/y/osuOuYlR//nf/33oTIYdM+evdvvv5/p+CZY AHoI8HfyeS8+8lexza9s3owlOOssyovORCZEruWRRx7WFEpelAOR50AF6/HHH/e5PvBJWsOb mgI2TTHU/Nzc1PT0/n371r7yxEMPXa29qCtXXLFhA+39oIOWX7Hh8lf/7rrly5fFVd248Urt lZHjphQHyCFt89BnPasozj7l5JN27dr10EMPnfaqVwHuwxo++uiOL9+0+ddf9mt0/AcffDC9 SX8iN0w51o03fn65ZFQ7dj7mO/rUpz6FZTlszRqYXMrYbtp88+mvYTbK837pefd95z5aWEr+ 3n7++V+99da1a9euXr1qx86d/37H7fRJOqP3vPe9t2zZctyxx33n/u88+aMf4Wg3btpELvC1 p6/bvv1+QJquN9g1wSmyyArjJTvcnw1CGcoD7G7My+ld08kGpemMeknuIaDt69DiCPEhyjyO kCnG2sOt/qVwXBoxClHI3x2Y19uapj6glxpzG3XZxcRGPM14E1sQP8xheRGz9zCoSGlj+Wep bUUKjB85wN4yCkJye18I6Tx0SCHXjCoSLhxjBrHtlvPAJRmgJ/Wsapycgl1IMd5zsnb9RyYe +FXuJsru4L13UFO3WtGqOpKJuImxbJyjn6TT0ZtntWwjTEs94NReRPQd47ymRITJkVJnxImI sDInK+m3QX2VuxEWFialRAQ7MGEi42RTkuANcG8UPWOKCkKiCRmWGwuKTW5FOsBWaKcCOd+1 YtoCqAa0BUo76H+dCSUdvhMiAdxOCGsaaCT65DMeA8J9sUpN9BgFRzU9NQ0fnIyAyqMWe/25 +TnYNG4QrEQezAbhIsedn5sHC8ara8OuFHsUIcKESLBUaI+0OyyLgtXhW8j+aSVB/QBZY1FE Oth6T07BUpHXmJyaqsSH6VA0lIXQFIkc3HfPbA7resOvvgpZYGskNKiI0GXj6P7kk+C67rrr 7g0bNuze/eNt2+5dvWoVfA+Z8n+45uOzs7N+E2deyikBEnlZyQk5k2LbvffiQcB3yf9t3fqN 6667FgCUR4JIyMigf/XrW2/ZvDmmCJBk7Jd6c0NDpRJBlJ/+5CeUCb3rnefjk6eecvKNN9zw 8ev+8ZBDVixbttwLYHh97etb77zzDjpOppa2xBj9aeeOHX/7wQ9fcP7bnHZBB0PeAr5/587H Nm3csOXmzddcc/Wf/embvvvd71555ZVrDvswuZ+/Pv9tClResdEf6Y9cqsjhPfds+8QnPyku edcnrrv2Bz/4wd9e9L53vOO8173u9X9/+Ub6LvlaTXD37n3Pe95HV/C973v/xes/dPxv/jr9 o/eP/82XXfhuplB+4/Y7tt1zz9XXXEtHeP7bzzvjvnv3PLVnvO8KagERqGmnpiXNw3pBSrwK TcrOOosgj49ks7ae8fKSxt3Rgflfc5jG4uCeEXZVASsOc4HYY6gqpZw74ap4i2HADPXwPPux 7ddxboD92iEHulpUt+QmbeOeV7UrEyHQVISpAgeeMS0TA2JYa8lWPZKE0R7NylTdprfC3YAl 19mRwOyDSVElt1w/ijbJ+6lR59RmwHW4xPEHi3tSvJTRAQMk9JXx6ak2gjzDEcrk9FwE6R9f LlYhqEZT3sravLwdGxWsyYkKrVqgzqe6gFkrggJkzzqi0LHq4wyV/i7TJDI6qEy/iitekxOz +2fBR+jbNGpMuEY26e3GyCGUlyjUD/WLvdK5fIUk+b68cFReuwHVAhQbb7T1Dl/N6futRK0m i6kZMLt8HokBpGVdLDGzAPwc4CiXmaUVA5gMuVSZaDqQm8dkIsDO64eZJL2Wr+5Dv1x3H7QU Ph2hfZLdteFMyrTEQA9UHJElpyq4HplOCQ0OLM7MzMzc7CxYhEjL2D2/6EVHaAggW5yUNAh4 1ECyFnSM05LNLJvxWxwnAO8Vb1PrxLaUXC45tJB9BAO2hg/jBlqydIm7a/LStLh09yxY/OIN iRYXKI2t7rb3A3OH/EcZ7vImNDm6Kod0FcxtuGKD93vd9e27zznnHPrhgne+67RT18Yn5PdO f+2jjz6C1umff/azX3HCCU888aObvvylUH8eHH7484877qV0hfbt27fl5puffPJJ+usfvelP nti16wufv5GO+fjf+u1ffO5zHtj+wF3fvPPpz3jG75xw4rJlM2R9vnrrlp07dtLZvf6Nf2RI ZELiuH37d+hb9MPmm26id169bt3SpUu/+8AD99x997N+/ln0J3pz/779t9y8mXJfHAy9f8wx xy2dYVjy1i23kHk7/rdf/sD2++kr3CH3hjfSEVLG9tjOna4kFqXnIvgD+DHm9/JsTMK4QDK/ RRSsWmZcNehPJFTmR6TEY5v5eFXJbTeGs7jmIdR1i5ZrmAMkWHTmRqYDqPaiY3fkyL03HEUp B1pdDv+AQl8ueZyCztZInhR9lXf1xrM+sN8atfsdKeQRtqcNvXQ9lLoo0hhqh7kNCgxC4bMO /PiktSLtGMO1036gbn9VIBPm7tzUHJr/WrnLEbMQ8afuh3PITfWuM7pjm/CNq9Gn0MTm3dCu MuV2f0StCoKluEudQe2OzZUhvWu7kO434EwpaCL7GBrnPyuqKdaPZ75DD6mvsxkh9dQzQXNX yAPx3anhPtEqip0WxlYHu1tLcWQhhTWKbjDcsSwOMjVFR7Jn756nP+3pnu6IDv3UnIwl854o bYYRHGvgsuYSPdRyUp4Y4WLt3z/rphvNakgHlyxZAm1brhGUOvPTReKjWr/3D6iT7uZhUcVx 6BNF4NQXF5GkxitLy5yOOOJIl7HSBNbubPbbpqDV1/ujvcthXyxYzt664ZL4KUjOsC7LxCRl Cd6wHTlacKeGBkiXdCo9r0dfgs5AsWIyrbLTuOG0SqVI8S2cTDgYW/Cb0qXoMYflJcceh7od Xm9/xwU//OFD//zZT0ezsumqa67etDHZbFDa7PT0tFFLGy1mCCd4cWHBy91MTIK4YhhkhcnR kB4YF/0LvcbVSIdvCORjWlBHexHsbC66wyz8GTDaccdthDFL3kTV6mjgWqNZwk8ZFfvE0lY9 tz4hUymKLlo4OlnjAChcjlavCHNbClN5Up0tDJQJIvrOLRSyOzc2HnBAjOsgj2vejxTSrLu2 jJdgnIBgqh4dociupEh24KXre0brZO4vR2Qk47hSrK1RyJpYrNI2GFttqGX2LInxUM9DT2/z it3HbQ4xGOSg5zvirjxGGfFtsYMiHnZ0V93CmN82rWaH9PEsxNHPJmplilaiGJBldK0X+Sqj 9jmJw7MWsjkm1mPsEnkwXaVXVTOqlvkNE4EZF25GXY8qd/gjfRFy4xWDZAkOGzbdYUA6YEoJ BmHupQvyYuhi0dUIhioSermGIUd0XM7RRbDn8V3KRegrU9NTgPf37tsHfRD3Io5bQp8PC4g4 BoNeWdhQ3K2L+tMXly1bBstGC4iMLY6Yh2+O+GF7cwYBJjQ10+Ghy23//n2Tk1MucsjMiD17 Vq1ezQ5+YR7S9fDNaGfGxYLLiM/s3r17qpUrV7FjNOYibiCZ21X7oCCZkF15UMMNEPVQ2mj4 tuBB1DwuqEryJwA42AE7EmkqceVgbJPZpSJeianHlcifl4KBsFXSwUKJDj3BctFfGSURB246 6KJm1PeeTe7OzAIyVKXXSwR8GExM9KWzRY5NrjdXUXN+5JGHD16xcs1hv6zM+MPXXH3VVc/9 pec95zm/6BjgRe+/aHb/fggr8QFPTvTk7LjciSRDVoaNYymFU9aUGmIIfTu3vkxaws3aV+G0 BXobym+wEbV154lNzGCaiiRSMi0DEajNTWC684cFxU5i0FVGtsE01pzhdSrmTCcgtPIVZcCG LuBk1SYK9FQuna6sjsPgO6QUMm7SqfOq5ueYnuJ1SS43jzZPpc2eTjzRVxi6BUaAyzjKrvYE WO7JKcK4Rphqr7RaUTlpZG1btq4J30aGcRTCcAn/Ur1dIfTiGk3PTk3MQSDYuLylb82bt3yb KdStozCjbYQPSq5ggb3Y6pVRIcVJw8Xo7MoUUED1f9hCTMVw7DF3wT1jFEo9QRQgo+uSrDOI 98tNQp+kexuFcdbWqSpASXIAdaMSVQmfVN8p91uESV3FUR8RufC897odPC9nAc3iEouMBVS+ tQRN/MhgjzIoAGwLJ6D3YJHkGSzilBkX5WJTJpcbXAb5X2ZQtFcQPeyinZGwOOK0Gm4WtKub RJSdzZScjnRl8bLTIy667WJSJLqHdjb9T9Et1/XFGvC8tarywEguoE1fNC1Hsp8tA14ynmRq MhLvVpRkKOun1rC+tkdAm+okNeEMYWqSpxLWQzoSVlqSISkRTpiamkzqktm803kNZO/9PsvQ g6oDY0IrQ053TnaNzgE6F0Z365rtVVXRLsDxhrVPZcKcW+DnvOyF4vnc/YaS4XC4sLggNm1A qwRrTxtfunSp5LI6L9ftAS4fPka/iaAUf3coJ8iO4xee/Wy6ZjJVLFWy2Ehmk7VfwIDSFxbm F7D6FBske16VBCy+R6jVbNQ4hSr1EZqQpK0/wfpGdBxK9u9B0pRTuhpbK3QQqvNgMPOe7wBW LtEHHcEg32ryMAn4mweLA+gxyhyQhPue6bwQp2T4dUB7xFkA/ZALxi7t4Yf/5zXr1uECL1++ vM7pXz772de8Rt+5/IpN37rzTjsA7lFIMlMR93EtLgH2iDY9kL0kOFG5Ki6MW4guFt0r7HpF YocWE6PieTHhJCzu9ksOKV7h22SYQrcgZhC1k4Y9hIylBAuGPkxrUpTJBX5QHsA0Kc9Xsmlu iopr6ZMtVcbX/Js8hJqxSWCeJX3sgdQUkKXWk4kERpyuaaPUJGQxCKntWZHjUZ+Nc0cLC4y1 /m8DoFPoRHYfpZOgA4/DniK4BKlyqYnsFMY6koqu72Oggvsza5TpiAW7cP0IAGjBUwuOuSOM zhJMsDJktG7ErT1gdOhMqAX6pLEydgU5PqmtPOZuNWPW6eSyaYm0dOJgsp5ls68RI63roQt2 F/L0eb5fiZ8OCa4ETNCbF3eFiBbOO24Tt2JsFoKvVYGoJDL22npurWw4O4TITCau9RdBXciC 9zmWZ5Ib7UOkjXX8Y6lDTsASbFJQG8Hp2tUucbdjZQppq2fr3KvqoQ5/wRKxdhGFxYuDRvrx exJDVxVuj0zWhrkkEovDiPMPFoby4NxBK/aBP4FbpDFxzsyms+ZlvTcyi6zi6aAdsSWxmwRe E1+kRYAVipuFbacXqv6YBA4+OhnneRmCzDEuj/hKMotEHPnUpFd2eEklJUDKQcYcphWdCaDO cqYl8S/rgEvm46XEgRgNffAlLCC3SpncHOWLMk8Vjzz9ILIjFfBJf5TgULgMxpLE6i8Rf6fj jn1pabMSPKVtByuUOn/MWTGA75zc0rZlmK4Mm+aFBZc9Tt0SlB/ZzMxMQAN0argq6gtPhl5L lixp578B92v4KoIFx2Du9DQGLni2i6YufADihEB1YwIeNUlL6wZvbMTf0EaClkGqOYoIJ5+W aXi6yvhaAz+mZAE4Re0R6wM4IlvXZBnadCIGgqUoddpk3QSuBP3CUUxgpkBTEX31qoLPqe0k 1gRpU2gELkdY1ONiFtrtL9OAOKwJmA9wS3T5/AzieAsAmkWuIX7obfylaQLJcU505RmrbnNu MdIaGUUXHYDSqrLjhzoXRol8yUYz61mnzkze8bJTEPXQvs2RuZqeJbZdnV57yyO6jrrmxgsf qfO1Iv16aTi5HLo/OwBducsOdaWlMmigdClFKeqn+FVwdoYKK3SqZR0g2tv48EXQoOKxtZNQ unXNeI+NtRYkh5qj/uciPbCcX/VaboXxistQL4gqwKDk6DRnTFm0JjB/M1boUfRqrKjTchFt ipjqo1u3cqx+eZkNfWN0Cj4dvmhblOoFB7hS4aZjn43nxS6UdiFqEVrtk5qW4ooyxWpKOpxA bZgSnI31kxbmMW0K0GI7IKbXm90/izIbX6DcLJlews1S0vsUZ6mQwXRkGOOeQTxBTQ7QKHh8 +/bve9rTngbqo4o8mB8FfQMWD9MfcZOjcOXtd9oDbm5FleOzDmPT6Z3GPYmsSGzBS4PsDmRB 2hlpUuQaLC5WP/fMgwWf0XlOzGoRfghncEmOMmcGWxtlHiIpFkdSi34uj54S8lVSBRdxeBr1 lRjCUSAxgo8kT7tk6RL6LpwKuWDJByUrAh4jG0H2Ru+w96mVGgQYFGPWkPB58znARhadnGff yemRHLxAZ6YwJKEQ+wOeYqLN3k7jUVEZiQ8rgwdjkwfWRLCsDHxWTzZzbz8CN+9IL8YGUykM YmOTBM9RB69a11J25sWXtIxhRsqKJDIaSvoMGBZmhfNoCa5qiamHFNrIscHVAflAlUuCpp6E abUkZ7nUOBGlOCjU5RDNUXBZA6Q2DXWO+GrL0iRPSrGhxM2xM93xwMjGcztDwP7PoAPaoCyD 2lLAzcyz1w3yTg/EcJAIdb3SaclQCpmN5Wc+TFKi6QOOoHQ8Ce9kmyMTUb6OrEBy9EE9XJTA LxVbS11ZjZGOmOSJqSeOjvpG/NPTOBWw5qUv/C5LqcRlRQtwkjW3Fm3NSw3nZk9TS66vmTJ/ uIdv2aTN1IVeS9eyK8YoKkPkFlKrD4L6fLPF4COWIeEdowa/HG0jVxl15QH2BQgrGX+SwRKb PmMJM0/CQxrR4OwSkmZKvzSnESHwAkggAB0AM9oTJtaJkxLKXZpsZZEE/CnShdgG8oTeCpgY 4B8MPqRgc3E4oL0sLC6SJaQPQI0QMAx5zSzKuTBoQPz0pkotj0wzvyKLjFOy8ZUZz7sbIiwq wx6YkGIWDNN/yMoLSJOml0zDvk9PTUtSVWFJKWdi24XkT/TN4exxOehQYfR4SjVSogEni5wh VBWdAgwpG2R0y6S0KCOt6c0a04nF4PGBiZ1cYB5AphwL0+dRdsFKYmYIOaRaDIv3DwxtO/Th eUlA6U0u/fQnxBEsymSWAVhdfIgrV67i3asuCx8HfZmrnRKAyMxphkR7FVTgMuBOHTGFhFFO ntE5ueoFF0V0boijQMjbnGrIByd9AIJSVrgAWDLeU4+7K3DOyQqAA8nH4WysYJgqkWsUN2aD g7VlL/ugJp0bl9DAUdE5UPrCcpZgqEiEQtfVnqWyEC0P9lWGmzN0JgBBIbeC3pTwKGi0FDgR d7w/xzhOr4cAOeT72MszkDsS9wz/SmuE4IDreRymZTqORsYim7pXX9gTbOZ6orts4twJJslQ GsWUxI6wSa9rb6mpRhImgSNacg2ML5+mQlKJgVl4ZbFTsB36xOTC3EnpZSYmZ1c9T33kVY7b r1IhQ/zaFF1JdfcShocJf3qw6LUTd1EOP2oQE6pfHXQxNJBFqDMUXRy/UjDKTMZof7rPZ8nW s2mVnibFV6mIjXmytm0rpm1eMoyHhgWJnMPU+ksr22T1ZIDIJMvP0VV4gVPDBbtyUEmH25MV Ljp9cjkGIgKsKcmlFfFSD5dafin8TakXupM346it1oir04Y+7sJbdUFztmwEpXDQ5OzrrEwi qaXxlMuh9FpRAsH1p4oHKtvoN03HIfyIyVsc3Fa1AXRaVxOYHUaJ3Z7UgWDrUghqanlpP1zS khjqGtyQJEW4odjiyqonQoVgQwzmNmzXvFhzJI4DmeEHZA+IHPvUhDWvwBovbJoSOtukW4up GXBFRRjKI0K3GtVxhrBkCXJQqAu5bgWcUCUpB8rvRnqwejktaVJ0sS9FE7hAOtqe6I1pJERm UKpoPC3MgHr/E4Z4kGWjz+B9J3pAKZiZigvz2iydODOrrZqFewDe2kFFH5TKqKkhcOq9kHVp fyLMXtVDJc2NLPtkpCy4MwRPGEiDBS9TofEdm3XGhSvEDs51xvngbgY8iNkzHiIpri0oAaIV JEwgH3jZE0+ICprJ/Ve3ZEo14hKeyCTGYY1tS592UtQoof1wUa40t1aA4QPgGQej9TY5F2Tr zVD7UnVOj5AK+FJl4fJN9JWeJHlxsjowgGA+gKonNIzCS5oYti1ix1JhlriYrgqvT1XNzy/o nWG19BIVcsYWas2TAGVI/CvymB0VXTNkkfymeklOoPCRKLFsZm4Jrb1VA38m0QRMTy0NoRbm e/KU8VWvyXEGJ7QUR9egYWH4HguxVUY0MLfhfi4fyBZX7mzi2Y14rFDYy7FyhkUT/be2XGeO h9+MQ9fi+Jg2tZJkKxUp0jSKQHoJYbIPgSssqS1DnpdMi3FkZkp2t4HzNZpJMvqG6wu3mR9H 61XlNE5znU7xSD6ntGX5lm0tyhOgbqpX+r60oKiRRC7aoXSVJ/Fwn0Z1Seae+R6IM9uiprOf Mt2AEukOGyMRJbFhVWlSeIZMMhvKcke2cUMZBla2I7lLq/Wi4IZTjk0a3h/CFrYKSLJYZeAi sKFgXCNa5S2IgQT5y3xhISwDHvc8WFz0PgQUupDWaBXNqj78DPU5FGAegEXYqCdpTaunjBjE 0zj9GgopKWD14oqGwg5zIo8SDiiVlLoUY1pWw07CymYsSm5t3gsgH9o4xe79HmwIng6gShkZ QqkVDdoVpxXcHLYI4gKXFaTAASqH+wVGXIVSB+hLL1ZVRnE1S7+G5Nv6Or+ipJ/BrPEpcUhs FmVmctvVIOVS4TAMq2c+82DkenBR2lsnhpK+OT83j7hGbqfk6bbcDMmpX0wIGQxdfU47KBMw qwrJJlwu+8ykEytEYkPvJ+wC0EHL2kAlsARVr4cbC94IkwJA0wDU1pYJ5dsL4h2RmeI+kOCl QkWxFsi2L8x1cCa9nMsQKA4ma80TlBuR/c+oamLXzvzB+/DWyo5Dy0hqNV2yWXev5OEcCxOa q8C2SvonDEFGD7zjjrxWw6E2DrCsV93rKxqgmJVEuACCjLJYV6KwHNKUKtmBKgpXMnGUmxAk gTYZTTAzC6fFS44/iN3HzuBPFjfk8JLIoJIY32kFEAZNauaSZyEtxQAPpMlYKIwpVlI/gGcM s6ejA7CnvXHwLbVAYoPjR2zmhiwcdhFcYJwKnUFEgNfXPTobxRqlNbtAvpXSSKdOZBXGlDE4 G2fJtpBa2VIVYhOVO7bS0jXstooMRne3bgHhtZWVI5fPj4GteXahoOQQaXS3URnNPdNY43Bl Z50C4qo0Vzzmmo2mwtff8dVa2Ex8+2lM2uSwh1IzxUKQiZ7g9BnhlJBjKwoD8VwYs0lmPwo1 ERnMUOaPS9d2CWMKbkUWwApeSms2qa2Rc4YHzr3o5btMrTe8U97GIakMV5uYnESKhnUGgQKl NeXUSVJF5tifslKMrfCx2Iih3k8fY9gt5+npaZ9AC1uqE9RkF95W6+WipUuXTk5MgNPBjUmL 7LFwh5NvAN0MvDO0+rDPoGMe1igDTXDoXOBxw+3fF3ALBxM5ELSRvXv2AgkEZJWcVym3HCpw QgyZcNfldyaSJVFcSlojlMoUcEWVESnV+HMckJWZKczTnqJ09Fq9+lDQ2Q1m1aSB7gCX4UDm 5HGXQzB9ceZgUmrsU5UOjiPdodf8/DxIel5vR2aDnbLvSSW3RAwGxkCt4N/aeanWPeCFK9gd yMMAVwSrUE1brWlQ61HUcDMoxzUiZDxaDWrg4T0ohlMRb02RSJ/vWhAxJF4T3FuJJE48U6cu nFf4gI7OXqEcSLUUBvRpL7YkheBV0sVjqy3HMDU1BbgfCz+UUe7ZwmeuRcnpc6af7dG1ajm8 jrmoEeHqIo6u1/tPCHXGmypcuBplsJDMqY/EFiRQ6rtFdvkiB9gY5xHuGZI2eCPD64CbJYMf s5V/2lIN6NqI7yprjcB9jMo5doHDZqSCp/5UkYbgPMP2lC0rzXE6s/g8pNSKJxntO7A5Uixa oOjYrqF3G3jzgdXhHD80PLAY8WR+FWJKF51cJJq7OPfY7MrWVxmOinQze5cCBsVVpjKOglm/ vYJFNxf0RLBTrjPotAgFM+8riPW2mFxKYuFyhbkYkUt3ps+idI+gx0MDC8YCFTrkLQgSwGgY akLMXO+BieCq+fT8c/7ROngVLZOwMmODSRpy6HGbnZsDQQOthAIxVKYLmQe1NoGhGFFKkQzu n6zzQEAmvUN4eZW8rrgfmo4FoMMeQdng7G1irP4i6ZTfBsgBwCFkNSIjAcAbJYXcC5SFNJ3K mbwXwEAAKkgBuUCeC7eE8BNSX1TPga+jLCKcUn4h/aDjpgSGPjA3N9sYxRoECKF4aNTu1BtY e8WfwLLOyh5HSQi7c+IxvIAWYu28sHQg7qMzAbuupDsLuZC680MOWeFT7fEdJ3lrGU14htKl 1MDNDgUnZG8x4BpMUiJpgpNrDEulpUckokFWagNzRCIY+w0ji1EFvpSmctb0q96Esey0QbWw gjxY7D0dMQz/UZuasEdAhaB/eObMMRSNldAq4XZnrlX2UTzz2YlS+1H2vxYJkbpZPj4hCANc KRx2X4qTuHgGq2dHupxgmo2JDh85FGSAa12Us5L9lRVmdq9cV9BbvONV6w3GHm44UCodNkRO IwRTJD1NbCenh7w/MWHggycznSq6R0lYZDHoLT+7qrxslgU/7MU0ItbSGpuY62iSJRalG+KY PAUAxEc4amamxgIs5MUBEF0W69SqXjtCAo8ftuZK1aFipLgo0jv11u2UMMf3Ou20UXoqqEjU rafR1q/AdE+2mJZHBmnaEdpHm7bF6RhtWlamFIgPoS+q9PfBcrTiZfY8zDBVk/MRQrl4+qJV yWqBzRQIh8nIXbWPP4ZDivWwUD9S1Q9QbALs2SDCQKs7IhVgG6Wl4Ox4UNgW3SAfblkbW1KN WqcmJ82dbbLJ28R3/QONALzYkQgkDmttyE1AegA1cbVJQnlP1iPJubQSVMJiy9OXTaNA/KVG zPAiSB+RwwGyUra6fVeNpDW2IufjAjZYJEHtrMmtuLOSOAyzRd+RAoxoumoaSq2mpqcYqs8q dQRDRO+j59XFH/yvYFLE3iSkWb0Kc7F7SAk8zsDhAVqERVXMsKqsdT0BMARnhPME6R4vzNb1 peDaF1kp3Dhw4fBMwBKlFUd9GPgj2YhRyDHAyZR0rf5fAQYAuloUfAEKdQEAAAAASUVORK5C YII= --------------000808020600020703070609-- --------------010406020009000301040507-- From nobody Sat Nov 12 22:37:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698A91295BE for ; Sat, 12 Nov 2016 22:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X989E3M-sMY for ; Sat, 12 Nov 2016 22:37:12 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0127.outbound.protection.outlook.com [104.47.40.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549BB1295EC for ; Sat, 12 Nov 2016 22:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=giK8RvSk6a1cqrVJ6MuAmPOTjXnKEIHjivb+31mXxLY=; b=blN3tYRJyyIPss+yndI0xzCp4CR/nh2gAqMUC3hBml0ehE1ivX9J9P0CfTky9XNdgyfynbZznK8MBOa0fdUMB0uNHjO73LGjIniM27EuZuGdH7ncwHQOFBAs81HUYE1ae8YJZzlYWMOBKEI734RG/aimUfhefdylMy7bdHLBfSo= Received: from CO2PR03MB2358.namprd03.prod.outlook.com (10.166.93.18) by CO2PR03MB2360.namprd03.prod.outlook.com (10.166.93.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Sun, 13 Nov 2016 06:37:08 +0000 Received: from CO2PR03MB2358.namprd03.prod.outlook.com ([10.166.93.18]) by CO2PR03MB2358.namprd03.prod.outlook.com ([10.166.93.18]) with mapi id 15.01.0707.015; Sun, 13 Nov 2016 06:37:08 +0000 From: Mike Jones To: Torsten Lodderstedt , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00 Thread-Index: AQHR7nMq9VN5jV0CyUuUVt511dz2nqDXAaWAgAAQcsA= Date: Sun, 13 Nov 2016 06:37:08 +0000 Message-ID: References: <5827FAD7.1090105@lodderstedt.net> In-Reply-To: <5827FAD7.1090105@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [31.133.159.163] x-microsoft-exchange-diagnostics: 1; CO2PR03MB2360; 7:TRDQDDPPgYIPCRj7JHZX3ODsbmL+Jzkz/HHa25hu71SltfysCutPsUe5zwlSbAZlH9fxU6BDgj+3ajRxpHayZ9Q1WA/fRRMW+2ebHW9mwZntTCIEGd8jfcOx+zWbh7aVY/5ZD5WkDyXqFc9DsSBSTQFGIhMuYXLYfWPYrSGUErC3YSJryWrRBoKDn0PgLssBGb+MZ8PR+MX9KHhQC2nsxXSu2SNJ3OCrFPrw4fzA1yEL+GQoMp0T45xTdW56XPodB4TFDBBUmUSxW1NLR9+wX/019jK36+f9LIoJ6fSuwbhQ0WP2HcYq1ezAmTUmQaQ7m+IRF90Vw/CrxSBNN5ZxaDdoklhBOFWhElCXm5pTassm+3qdOPV3/Ym5bu+RxSYV x-ms-office365-filtering-correlation-id: 33e5d4f2-2aa9-42b9-fc0d-08d40b8f7dbf x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2360; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(149059832740258)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(6045074)(6060229)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:CO2PR03MB2360; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2360; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(377454003)(199003)(189002)(5001770100001)(66066001)(74316002)(97736004)(7906003)(33656002)(87936001)(8936002)(2950100002)(229853002)(122556002)(2900100001)(7736002)(77096005)(5660300001)(54356999)(9686002)(189998001)(50986999)(76176999)(101416001)(2501003)(6116002)(86362001)(3280700002)(102836003)(586003)(5005710100001)(3846002)(10090500001)(7846002)(68736007)(76576001)(86612001)(3660700001)(8990500004)(81156014)(2906002)(790700001)(99286002)(106356001)(81166006)(230783001)(106116001)(4326007)(105586002)(92566002)(8676002)(7696004)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2360; H:CO2PR03MB2358.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB235854922A12B3E4CCE498C7F5BD0CO2PR03MB2358namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 06:37:08.1823 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2360 Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 06:37:15 -0000 --_000_CO2PR03MB235854922A12B3E4CCE498C7F5BD0CO2PR03MB2358namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, it's intentionally a particular resource that the metadata applie= s to - exactly as the AS metadata applies to a particular AS. It is *not* = metadata about all resources that might be managed by a resource server, ju= st as the AS metadata is not about all ASs that a particular server (such a= s a multi-tenant server) might manage. Bear in mind that just as different ASs are likely to use different keys fo= r security reasons, even if they are on the same physical server - such as = in the multi-tenant case, different resources need to be able to use differ= ent keys, even if they are hosted at the same resource server. That mandat= es the metadata being resource-specific. For what it's worth, if we ever do an OAuth 3.0, I believe we should get ri= d of the "resource server" term entirely. It doesn't have any actionable s= emantics tied to it and its existence only encourages confusion. Thanks for reading the draft, Torsten. -- Mike From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, November 13, 2016 2:32 PM To: Mike Jones ; oauth@ietf.org Cc: gffletch@aol.com Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00 Hi Mike, just read your spec and I'm also a bit confused about the "resource" meta d= ata element in section 2. I would assume the metadata are provided for a certain resource server mana= ging a set of resources in a particular administrative domain. So I would p= refer to name the respective element "resource_server". In the example Geor= ge gave the URL would be "https://idp.example.com/tenant//". Reso= urce managed by a particular resource server could use sub-paths of the res= pective URL, such as " https://idp.example.com/tenant//users/". best regards, Torsten. Am 05.08.2016 um 02:10 schrieb George Fletcher: Mike, thanks for drafting and publishing these specifications. I have a cou= ple of questions regarding the draft-jones-oauth-resource-metadata-00. 1. Is a "protected resource" a server? or an actual API endpoint. The non-n= ormative examples use /.well-known/oauth-protected-resource and /resource1/= .well-known/oauth-protected-resource which is a little unclear. I think of = "resource" as something like "Mail" or "Instant Messaging". 2. Assuming that "protected resource" means an actual API endpoint, what is= the expected location of the metadata for a fully REST compliant API where= the full URL points to a specific resource and not the concept of a genera= l API. Using an example of an IdP that supports user management capabilities. Let'= s assume the IdP supports a REST API of... CREATE -- POST https://idp.example.com/tenant//users READ -- GET https://idp.example.com/tenant//users/ UPDATE -- PUT https://idp.example.com/tenant//users/ DELETE -- DELETE https://idp.example.com/tenant//users/ Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users.= Where does the .well-known/oauth-protected-resource get added? ?? https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oaut= h-protected-resource In this case would not the oauth-protected-resource metadata be duplicated = across the set of tenants and users? Is that the desired behavior? Thanks, George _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CO2PR03MB235854922A12B3E4CCE498C7F5BD0CO2PR03MB2358namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, it’s intentionally a = particular resource that the metadata applies to – exactly as the AS = metadata applies to a particular AS.  It is *not* metadata about all resources that might be managed by a resource server, just as th= e AS metadata is not about all ASs that a particular server (such as a mult= i-tenant server) might manage.

 

Bear in mind that just as different A= Ss are likely to use different keys for security reasons, even if they are = on the same physical server – such as in the multi-tenant case, different resources need to be able to use different keys, even if t= hey are hosted at the same resource server.  That mandates the metadat= a being resource-specific.

 

For what it’s worth, if we ever= do an OAuth 3.0, I believe we should get rid of the “resource server= ” term entirely.  It doesn’t have any actionable semantics tied to it and its existence only encourages confusion.<= /p>

 

Thanks for reading the draft, Torsten= .

 

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           -- Mike=

&nbs= p;

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, November 13, 2016 2:32 PM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org Cc: gffletch@aol.com
Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metad= ata-00

 

Hi Mike,

just read your spec and I'm also a bit confused about the "resource&qu= ot; meta data element in section 2.

I would assume the metadata are provided for a certain resource server mana= ging a set of resources in a particular administrative domain. So I would p= refer to name the respective element "resource_server". In the ex= ample George gave the URL would be "https://idp.example.com/tenant/<tenantid>/". Resource managed by a particular resource server could use sub-paths of th= e respective URL, such as " https://idp.example.com/tenant/= <tenantid>/users/<userid>".

best regards,
Torsten.

Am 05.08.2016 um 02:10 schrieb George Fletcher:=

Mike, thanks for drafting and publishing these specifications. I h= ave a couple of questions regarding the draft-jones-oauth-resource-metadata= -00.

1. Is a "protected resource" a server? or an actual API endpoint.= The non-normative examples use /.well-known/oauth-protected-resource and /= resource1/.well-known/oauth-protected-resource which is a little unclear. I= think of "resource" as something like "Mail" or "Instant Messaging".

2. Assuming that "protected resource" means an actual API endpoin= t, what is the expected location of the metadata for a fully REST compliant= API where the full URL points to a specific resource and not the concept o= f a general API.

Using an example of an IdP that supports user management capabilit= ies. Let's assume the IdP supports a REST API of...

    CREATE -- POST https://idp.example.com/tenant/<tenantid>/users
    READ -- GET = https://idp.example.com/tenant/<tenantid>/users/<userid>     UPDATE -- PUT https://idp.example.com/tenant/<tenantid>/users/<userid><= br>     DELETE -- DELETE https://idp.example.com/tenant/<tenantid>/users/<userid&g= t;

Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users.= Where does the .well-known/oauth-protected-resource get added?

   ?? https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-prot= ected-resource

In this case would not the oauth-protected-resource metadata be duplicated = across the set of tenants and users? Is that the desired behavior?

Thanks,
George



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

 

--_000_CO2PR03MB235854922A12B3E4CCE498C7F5BD0CO2PR03MB2358namp_-- From nobody Sat Nov 12 22:43:11 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A031295BE for ; Sat, 12 Nov 2016 22:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDqRhb5AXdiT for ; Sat, 12 Nov 2016 22:43:08 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0113.outbound.protection.outlook.com [104.47.42.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5587A129611 for ; Sat, 12 Nov 2016 22:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yxiHqhYC2JzanWyFvjoQ/YNj//ATCopXBR54gLwV6jo=; b=XAIvSZCG4NpYIqgsXqGoKT0PVjpgFEUdaD+QHNGtra/PU8c7df0tnwwGBJ4C2kvV0Ryd7UfzqUmn2jIG+5BT4SbG8ZsOyW1Kw6zhqL5Md4pss+Uh2OZY8qOHl4XDNUOsYqzXsehsFe12YtTr4n/3ygtn8w9ZN7U0fTxxmNVa6rc= Received: from CO2PR03MB2358.namprd03.prod.outlook.com (10.166.93.18) by CO2PR03MB2360.namprd03.prod.outlook.com (10.166.93.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Sun, 13 Nov 2016 06:43:04 +0000 Received: from CO2PR03MB2358.namprd03.prod.outlook.com ([10.166.93.18]) by CO2PR03MB2358.namprd03.prod.outlook.com ([10.166.93.18]) with mapi id 15.01.0707.015; Sun, 13 Nov 2016 06:43:04 +0000 From: Mike Jones To: Torsten Lodderstedt , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens Thread-Index: AdITLN3AvEZSb1qWQgWbF/NlQqhekwqRKyqAAAG3GIA= Date: Sun, 13 Nov 2016 06:43:04 +0000 Message-ID: References: <5827FEA5.5090906@lodderstedt.net> In-Reply-To: <5827FEA5.5090906@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [31.133.159.163] x-microsoft-exchange-diagnostics: 1; CO2PR03MB2360; 7:V06k2MeOkPJupvGpkcUu8OaSH0Y6OnzAtya2MwWf0QNF+n/BXjLBNCU4Cy02ZQfM637uVLyYgvH5f9oANmBZ6SYwbKVgFwCuCNsXxno3Z0ZI3jl59ZEZLlugobAiblA7nOI4/CV+12Ua9887ASC1N9Sswcysyp/M6hr2Qy9ka6GkuNIdqayVksy+qPf97vovF5/W5MTu+i4Fk6uAx7hU3quaG7ydDCroalBpm4EZOkVvW0PvYX2y8KYkLOI/NTz6rQ9a1Ckjo+TmYspfei4f6ZeiCXpgljvH3wncceLgsyVJMdmzm4ToqN6hCPu+ksiHUzrSMgDJUJ146A9TPLQDfUZuYhDBIQ6H+TIM/2/9+5UjDkpznn0VwxP8o76vzjFO x-ms-office365-filtering-correlation-id: 1af3877b-e97f-46d8-77f5-08d40b9051e0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2360; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(6045074)(6060229)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:CO2PR03MB2360; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2360; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(209900001)(199003)(377454003)(51444003)(189002)(7846002)(68736007)(76576001)(86612001)(3660700001)(2501003)(6116002)(86362001)(3280700002)(101416001)(102836003)(10090500001)(586003)(3846002)(5005710100001)(7696004)(10290500002)(99286002)(790700001)(2906002)(106356001)(81156014)(8990500004)(92566002)(8676002)(105586002)(81166006)(33656002)(87936001)(8936002)(66066001)(5001770100001)(7906003)(74316002)(97736004)(54356999)(5660300001)(7736002)(77096005)(50986999)(76176999)(9686002)(189998001)(229853002)(2950100002)(122556002)(107886002)(2900100001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2360; H:CO2PR03MB2358.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB235848A7FA8FDC21AA53C468F5BD0CO2PR03MB2358namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 06:43:04.1722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2360 Archived-At: Subject: Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 06:43:10 -0000 --_000_CO2PR03MB235848A7FA8FDC21AA53C468F5BD0CO2PR03MB2358namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The HTTP header is described in https://tools.ietf.org/html/draft-ietf-tokb= ind-https-06#section-2 where it talks about a Sec-Token-Binding Header Fiel= d with a TokenBindingMessage with a TokenBinding structure with TokenBindin= gType of referred_token_binding. The example is a good idea. -- Mike From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, November 13, 2016 2:48 PM To: Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding o= f Access Tokens Hi Mike, does this mean the binding ID is indicated to the authorization server via = a respective HTTP header? I'm asking because I didn't find the respective p= arameter in the draft. Could you add a HTTP request example? I think that would help a lot to bett= er understand the mechanism. best regards, Torsten. Am 20.09.2016 um 21:16 schrieb Mike Jones: The OAuth Token Binding specification has been revised to use the Referred = Token Binding ID when performing token binding of access tokens. This was = enabled by the Implementation Considerations in the Token Binding HTTPS spe= cification being added to make it clear that Token Binding implementations = will enable using the Referred Token Binding ID in this manner. Protected = Resource Metadata was also defined. Thanks to Brian Campbell for clarifications on the differences between toke= n binding of access tokens issued from the authorization endpoint versus th= ose issued from the token endpoint. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-token-binding-01.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1610 and = as @selfissued. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CO2PR03MB235848A7FA8FDC21AA53C468F5BD0CO2PR03MB2358namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The HTTP header is des= cribed in https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-2 where= it talks about a Sec-Token-Binding Header Field with a TokenBindingMessage= with a TokenBinding structure with TokenBindingType of referred_token_bind= ing.

 

The example is a good = idea.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

From:= Torsten Lodderstedt [mailto:torsten@lodde= rstedt.net]
Sent: Sunday, November 13, 2016 2:48 PM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org Subject: Re: [OAUTH-WG] Using Referred Token Binding ID for Token Bi= nding of Access Tokens

 

Hi Mike,

does this mean the binding ID is indicated to the authorization server via = a respective HTTP header? I'm asking because I didn't find the respective p= arameter in the draft.

Could you add a HTTP request example? I think that would help a lot to bett= er understand the mechanism.

best regards,
Torsten.

Am 20.09.2016 um 21:16 schrieb Mike Jones:

The OAuth Token Binding specification has been revis= ed to use the Referred Token Binding ID when performing token binding of ac= cess tokens.  This was enabled by the Implementation Considerations in= the Token Binding HTTPS specification being added to make it clear that Token Binding implementations will enabl= e using the Referred Token Binding ID in this manner.  Protected Resou= rce Metadata was also defined.

 

Thanks to Brian Campbell for clarifications on the d= ifferences between token binding of access tokens issued from the authoriza= tion endpoint versus those issued from the token endpoint.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oauth-to= ken-binding-01

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft-ietf= -oauth-token-binding-01.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1610 and as @selfissued.

 




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

 

--_000_CO2PR03MB235848A7FA8FDC21AA53C468F5BD0CO2PR03MB2358namp_-- From nobody Sun Nov 13 00:18:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FC4129477 for ; Sun, 13 Nov 2016 00:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbtQpG1HkAqM for ; Sun, 13 Nov 2016 00:18:18 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CB9129431 for ; Sun, 13 Nov 2016 00:18:18 -0800 (PST) Received: from [58.120.104.2] (helo=[192.168.101.95]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5pzT-00055s-1w; Sun, 13 Nov 2016 09:18:15 +0100 To: Mike Jones , "oauth@ietf.org" References: <5827FEA5.5090906@lodderstedt.net> From: Torsten Lodderstedt Message-ID: <582821C3.8090005@lodderstedt.net> Date: Sun, 13 Nov 2016 17:18:11 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000501090606060608040307" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 08:18:21 -0000 This is a multi-part message in MIME format. --------------000501090606060608040307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit thanks. So the underlying implementation is supposed to create the signed data (TokenBindingMessage) and the client (or library) is supposed to create the header? Am 13.11.2016 um 15:43 schrieb Mike Jones: > > The HTTP header is described in > https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-2 > where it talks about a Sec-Token-Binding Header Field with a > TokenBindingMessage with a TokenBinding structure with > TokenBindingType of referred_token_binding. > > The example is a good idea. > > -- Mike > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Sunday, November 13, 2016 2:48 PM > *To:* Mike Jones ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Using Referred Token Binding ID for Token > Binding of Access Tokens > > Hi Mike, > > does this mean the binding ID is indicated to the authorization server > via a respective HTTP header? I'm asking because I didn't find the > respective parameter in the draft. > > Could you add a HTTP request example? I think that would help a lot to > better understand the mechanism. > > best regards, > Torsten. > > Am 20.09.2016 um 21:16 schrieb Mike Jones: > > The OAuth Token Binding specification has been revised to use the > Referred Token Binding ID when performing token binding of access > tokens. This was enabled by the Implementation Considerations in > the Token Binding HTTPS specification being added to make it clear > that Token Binding implementations will enable using the Referred > Token Binding ID in this manner. Protected Resource Metadata was > also defined. > > Thanks to Brian Campbell for clarifications on the differences > between token binding of access tokens issued from the > authorization endpoint versus those issued from the token endpoint. > > The specification is available at: > > http://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 > > An HTML-formatted version is also available at: > > http://self-issued.info/docs/draft-ietf-oauth-token-binding-01.html > > -- Mike > > P.S. This notice was also posted at > http://self-issued.info/?p=1610 > and as @selfissued . > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --------------000501090606060608040307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit thanks. So the underlying implementation is supposed to create the signed data (TokenBindingMessage) and the client (or library) is supposed to create the header?

Am 13.11.2016 um 15:43 schrieb Mike Jones:

The HTTP header is described in https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-2 where it talks about a Sec-Token-Binding Header Field with a TokenBindingMessage with a TokenBinding structure with TokenBindingType of referred_token_binding.

The example is a good idea.

-- Mike

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, November 13, 2016 2:48 PM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens

Hi Mike,

does this mean the binding ID is indicated to the authorization server via a respective HTTP header? I'm asking because I didn't find the respective parameter in the draft.

Could you add a HTTP request example? I think that would help a lot to better understand the mechanism.

best regards,
Torsten.

Am 20.09.2016 um 21:16 schrieb Mike Jones:

The OAuth Token Binding specification has been revised to use the Referred Token Binding ID when performing token binding of access tokens. This was enabled by the Implementation Considerations in the Token Binding HTTPS specification being added to make it clear that Token Binding implementations will enable using the Referred Token Binding ID in this manner. Protected Resource Metadata was also defined.

Thanks to Brian Campbell for clarifications on the differences between token binding of access tokens issued from the authorization endpoint versus those issued from the token endpoint.

The specification is available at:

http://tools.ietf.org/html/draft-ietf-oauth-token-binding-01

An HTML-formatted version is also available at:

http://self-issued.info/docs/draft-ietf-oauth-token-binding-01.html

-- Mike

P.S. This notice was also posted at http://self-issued.info/?p=1610 and as @selfissued.




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


--------------000501090606060608040307-- From nobody Sun Nov 13 00:27:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3665E129524 for ; Sun, 13 Nov 2016 00:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ySvXJqUXC9s for ; Sun, 13 Nov 2016 00:27:41 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35053129431 for ; Sun, 13 Nov 2016 00:27:41 -0800 (PST) Received: from [58.120.104.2] (helo=[192.168.101.95]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5q8Y-0006OC-CS; Sun, 13 Nov 2016 09:27:38 +0100 To: Mike Jones , "oauth@ietf.org" References: <5827FAD7.1090105@lodderstedt.net> From: Torsten Lodderstedt Message-ID: <582823F7.8010106@lodderstedt.net> Date: Sun, 13 Nov 2016 17:27:35 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000409000609080904020904" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 08:27:44 -0000 This is a multi-part message in MIME format. --------------000409000609080904020904 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I see your point but do you really think this is needed and efficient enough for practical use? Basing metadata handling on single resources (distinct URLs including different query parameters, right?) in my opinion means: - the client needs to discovery the AS for every of those URLs - the client needs to acquire an access token per URL - I'm not quite sure what it means when it comes to token binding I think it would be good idea to have a container on a more coarse grain level in order to make that more efficient. If every resource (distinct URL) belongs to such a container (let's call it resource server or something else), the client-side handling should become easier. BTW: we don't have different meta data for token endpoint and authorization endpoint of a particular AS, right? So the comparision does not completely fit. What do you think? best regards, Torsten. Am 13.11.2016 um 15:37 schrieb Mike Jones: > > Actually, its intentionally a particular resource that the metadata > applies to exactly as the AS metadata applies to a particular AS. > It is **not** metadata about all resources that might be managed by a > resource server, just as the AS metadata is not about all ASs that a > particular server (such as a multi-tenant server) might manage. > > Bear in mind that just as different ASs are likely to use different > keys for security reasons, even if they are on the same physical > server such as in the multi-tenant case, different resources need to > be able to use different keys, even if they are hosted at the same > resource server. That mandates the metadata being resource-specific. > > For what its worth, if we ever do an OAuth 3.0, I believe we should > get rid of the resource server term entirely. It doesnt have any > actionable semantics tied to it and its existence only encourages > confusion. > > Thanks for reading the draft, Torsten. > > -- Mike > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Sunday, November 13, 2016 2:32 PM > *To:* Mike Jones ; oauth@ietf.org > *Cc:* gffletch@aol.com > *Subject:* Re: [OAUTH-WG] Comments on > draft-jones-oauth-resource-metadata-00 > > Hi Mike, > > just read your spec and I'm also a bit confused about the "resource" > meta data element in section 2. > > I would assume the metadata are provided for a certain resource server > managing a set of resources in a particular administrative domain. So > I would prefer to name the respective element "resource_server". In > the example George gave the URL would be > "https://idp.example.com/tenant//". Resource managed by a > particular resource server could use sub-paths of the respective URL, > such as " https://idp.example.com/tenant//users/". > > best regards, > Torsten. > > Am 05.08.2016 um 02:10 schrieb George Fletcher: > > Mike, thanks for drafting and publishing these specifications. I > have a couple of questions regarding the > draft-jones-oauth-resource-metadata-00. > > 1. Is a "protected resource" a server? or an actual API endpoint. > The non-normative examples use > /.well-known/oauth-protected-resource and > /resource1/.well-known/oauth-protected-resource which is a little > unclear. I think of "resource" as something like "Mail" or > "Instant Messaging". > > 2. Assuming that "protected resource" means an actual API > endpoint, what is the expected location of the metadata for a > fully REST compliant API where the full URL points to a specific > resource and not the concept of a general API. > > Using an example of an IdP that supports user management > capabilities. Let's assume the IdP supports a REST API of... > > CREATE -- POST https://idp.example.com/tenant//users > READ -- GET > https://idp.example.com/tenant//users/ > UPDATE -- PUT > https://idp.example.com/tenant//users/ > DELETE -- DELETE > https://idp.example.com/tenant//users/ > > Assuming there are 3 tenants (tenantA, tenantB, tenantB) and > lots of users. Where does the > .well-known/oauth-protected-resource get added? > > ?? > https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource > > In this case would not the oauth-protected-resource metadata > be duplicated across the set of tenants and users? Is that the > desired behavior? > > Thanks, > George > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --------------000409000609080904020904 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I see your point but do you really think this is needed and efficient enough for practical use?

Basing metadata handling on single resources (distinct URLs including different query parameters, right?) in my opinion means:
- the client needs to discovery the AS for every of those URLs
- the client needs to acquire an access token per URL
- I'm not quite sure what it means when it comes to token binding

I think it would be good idea to have a container on a more coarse grain level in order to make that more efficient. If every resource (distinct URL) belongs to such a container (let's call it resource server or something else), the client-side handling should become easier.

BTW: we don't have different meta data for token endpoint and authorization endpoint of a particular AS, right? So the comparision does not completely fit.

What do you think?

best regards,
Torsten.



Am 13.11.2016 um 15:37 schrieb Mike Jones:

Actually, its intentionally a particular resource that the metadata applies to exactly as the AS metadata applies to a particular AS. It is *not* metadata about all resources that might be managed by a resource server, just as the AS metadata is not about all ASs that a particular server (such as a multi-tenant server) might manage.

Bear in mind that just as different ASs are likely to use different keys for security reasons, even if they are on the same physical server such as in the multi-tenant case, different resources need to be able to use different keys, even if they are hosted at the same resource server. That mandates the metadata being resource-specific.

For what its worth, if we ever do an OAuth 3.0, I believe we should get rid of the resource server term entirely. It doesnt have any actionable semantics tied to it and its existence only encourages confusion.

Thanks for reading the draft, Torsten.

-- Mike

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, November 13, 2016 2:32 PM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Cc: gffletch@aol.com
Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

Hi Mike,

just read your spec and I'm also a bit confused about the "resource" meta data element in section 2.

I would assume the metadata are provided for a certain resource server managing a set of resources in a particular administrative domain. So I would prefer to name the respective element "resource_server". In the example George gave the URL would be "https://idp.example.com/tenant/<tenantid>/". Resource managed by a particular resource server could use sub-paths of the respective URL, such as " https://idp.example.com/tenant/<tenantid>/users/<userid>".

best regards,
Torsten.

Am 05.08.2016 um 02:10 schrieb George Fletcher:

Mike, thanks for drafting and publishing these specifications. I have a couple of questions regarding the draft-jones-oauth-resource-metadata-00.

1. Is a "protected resource" a server? or an actual API endpoint. The non-normative examples use /.well-known/oauth-protected-resource and /resource1/.well-known/oauth-protected-resource which is a little unclear. I think of "resource" as something like "Mail" or "Instant Messaging".

2. Assuming that "protected resource" means an actual API endpoint, what is the expected location of the metadata for a fully REST compliant API where the full URL points to a specific resource and not the concept of a general API.

Using an example of an IdP that supports user management capabilities. Let's assume the IdP supports a REST API of...

CREATE -- POST https://idp.example.com/tenant/<tenantid>/users
READ -- GET https://idp.example.com/tenant/<tenantid>/users/<userid>
UPDATE -- PUT https://idp.example.com/tenant/<tenantid>/users/<userid>
DELETE -- DELETE https://idp.example.com/tenant/<tenantid>/users/<userid>

Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users. Where does the .well-known/oauth-protected-resource get added?

?? https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource

In this case would not the oauth-protected-resource metadata be duplicated across the set of tenants and users? Is that the desired behavior?

Thanks,
George



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


--------------000409000609080904020904-- From nobody Sun Nov 13 03:03:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20A01296BD for ; Sun, 13 Nov 2016 03:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.687 X-Spam-Level: X-Spam-Status: No, score=-5.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw0gxjMghGPx for ; Sun, 13 Nov 2016 03:03:24 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06731296E0 for ; Sun, 13 Nov 2016 03:03:24 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uADB3Mss005822 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 13 Nov 2016 11:03:22 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id uADB3LTC017572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 13 Nov 2016 11:03:22 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uADB3LtE000391; Sun, 13 Nov 2016 11:03:21 GMT Received: from [10.0.1.2] (/31.133.150.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Nov 2016 03:03:20 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-1BDC4C29-426C-4249-B737-9E4D5372FB1E Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14B100) In-Reply-To: <582823F7.8010106@lodderstedt.net> Date: Sun, 13 Nov 2016 20:03:17 +0900 Content-Transfer-Encoding: 7bit Message-Id: <3AD23C8A-FF74-48B0-9A9A-636ADF550C8F@oracle.com> References: <5827FAD7.1090105@lodderstedt.net> <582823F7.8010106@lodderstedt.net> To: Torsten Lodderstedt X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 11:03:27 -0000 --Apple-Mail-1BDC4C29-426C-4249-B737-9E4D5372FB1E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For example scim has many resources. But it is reasonable to discover at its= root since clients may ask for other resources. The as would not likely cha= nge across a single scim provider.=20 Phil > On Nov 13, 2016, at 5:27 PM, Torsten Lodderstedt = wrote: >=20 > I see your point but do you really think this is needed and efficient enou= gh for practical use? >=20 > Basing metadata handling on single resources (distinct URLs including diff= erent query parameters, right?) in my opinion means: > - the client needs to discovery the AS for every of those URLs > - the client needs to acquire an access token per URL > - I'm not quite sure what it means when it comes to token binding >=20 > I think it would be good idea to have a container on a more coarse grain l= evel in order to make that more efficient. If every resource (distinct URL) b= elongs to such a container (let's call it resource server or something else)= , the client-side handling should become easier. >=20 > BTW: we don't have different meta data for token endpoint and authorizatio= n endpoint of a particular AS, right? So the comparision does not completely= fit. >=20 > What do you think? >=20 > best regards, > Torsten. >=20 >=20 >=20 >> Am 13.11.2016 um 15:37 schrieb Mike Jones: >> Actually, it=E2=80=99s intentionally a particular resource that the metad= ata applies to =E2=80=93 exactly as the AS metadata applies to a particular A= S. It is *not* metadata about all resources that might be managed by a reso= urce server, just as the AS metadata is not about all ASs that a particular s= erver (such as a multi-tenant server) might manage. >> =20 >> Bear in mind that just as different ASs are likely to use different keys f= or security reasons, even if they are on the same physical server =E2=80=93 s= uch as in the multi-tenant case, different resources need to be able to use d= ifferent keys, even if they are hosted at the same resource server. That ma= ndates the metadata being resource-specific. >> =20 >> For what it=E2=80=99s worth, if we ever do an OAuth 3.0, I believe we sho= uld get rid of the =E2=80=9Cresource server=E2=80=9D term entirely. It does= n=E2=80=99t have any actionable semantics tied to it and its existence only e= ncourages confusion. >> =20 >> Thanks for reading the draft, Torsten. >> =20 >> -- Mike >> =20 >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 >> Sent: Sunday, November 13, 2016 2:32 PM >> To: Mike Jones ; oauth@ietf.org >> Cc: gffletch@aol.com >> Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-0= 0 >> =20 >> Hi Mike, >>=20 >> just read your spec and I'm also a bit confused about the "resource" meta= data element in section 2. >>=20 >> I would assume the metadata are provided for a certain resource server ma= naging a set of resources in a particular administrative domain. So I would p= refer to name the respective element "resource_server". In the example Georg= e gave the URL would be "https://idp.example.com/tenant//". Resour= ce managed by a particular resource server could use sub-paths of the respec= tive URL, such as " https://idp.example.com/tenant//users/= ". >>=20 >> best regards, >> Torsten. >>=20 >> Am 05.08.2016 um 02:10 schrieb George Fletcher: >> Mike, thanks for drafting and publishing these specifications. I have a c= ouple of questions regarding the draft-jones-oauth-resource-metadata-00. >>=20 >> 1. Is a "protected resource" a server? or an actual API endpoint. The non= -normative examples use /.well-known/oauth-protected-resource and /resource1= /.well-known/oauth-protected-resource which is a little unclear. I think of "= resource" as something like "Mail" or "Instant Messaging". >>=20 >> 2. Assuming that "protected resource" means an actual API endpoint, what i= s the expected location of the metadata for a fully REST compliant API where= the full URL points to a specific resource and not the concept of a general= API. >> Using an example of an IdP that supports user management capabilities. Le= t's assume the IdP supports a REST API of... >>=20 >> CREATE -- POST https://idp.example.com/tenant//users >> READ -- GET https://idp.example.com/tenant//users/ >> UPDATE -- PUT https://idp.example.com/tenant//users/ >> DELETE -- DELETE https://idp.example.com/tenant//users/ >>=20 >> Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of user= s. Where does the .well-known/oauth-protected-resource get added? >>=20 >> ?? https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oa= uth-protected-resource >>=20 >> In this case would not the oauth-protected-resource metadata be duplicate= d across the set of tenants and users? Is that the desired behavior? >> Thanks, >> George >>=20 >>=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 --Apple-Mail-1BDC4C29-426C-4249-B737-9E4D5372FB1E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
For example scim has many resources. B= ut it is reasonable to discover at its root since clients may ask for other r= esources. The as would not likely change across a single scim provider. = ;

Phil

On Nov 13, 2016, at 5:27 PM, Torsten Lodderstedt= <torsten@lodderstedt.net&= gt; wrote:

=20 =20 =20 I see your point but do you really think this is needed and efficient enough for practical use?

Basing metadata handling on single resources (distinct URLs including different query parameters, right?) in my opinion means:
- the client needs to discovery the AS for every of those URLs
- the client needs to acquire an access token per URL
- I'm not quite sure what it means when it comes to token binding

I think it would be good idea to have a container on a more coarse grain level in order to make that more efficient. If every resource (distinct URL) belongs to such a container (let's call it resource server or something else), the client-side handling should become easier.

BTW: we don't have different meta data for token endpoint and authorization endpoint of a particular AS, right? So the comparision does not completely fit.

What do you think?

best regards,
Torsten.



Am 13.11.2016 um 15:37 schrieb Mike Jones:

Actually, it=E2=80=99s intentionally a particular resource that the metada= ta applies to =E2=80=93 exactly as the AS metadata applies to a particular AS.  It is *not* metadata about all resources that might be managed by a resource server, just as the AS metadata is not about all ASs that a particular server (such as a multi-tenant server) might manage.<= /span>

 

Bear in mind that just as different ASs are likely to use different keys for security reasons, even if they are on the same physical server =E2=80=93 such as in the multi-tenant case,= different resources need to be able to use different keys, even if they are hosted at the same resource server.  That mandates the metadata being resource-specific.=

 

For what it=E2=80=99s worth, if we ever do an OAuth 3.0, I believe w= e should get rid of the =E2=80=9Cresource server=E2=80=9D term ent= irely.  It doesn=E2=80=99t have any actionable semantics tied to it and its= existence only encourages confusion.

 

Thanks for reading the draft, Torsten.

 

     &= nbsp;            = ;            &nb= sp;            &= nbsp;           -- Mike

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, November 13, 2016 2:32 PM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Cc: gffletch@aol.com
Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

=

 

Hi Mike,

just read your spec and I'm also a bit confused about the "resource" meta data element in section 2.

I would assume the metadata are provided for a certain resource server managing a set of resources in a particular administrative domain. So I would prefer to name the respective element "resource_server". In the example George gave the URL would be "https://idp.example.com/tenant/<tenantid>= ;/". Resource managed by a particular resource server could use sub-paths of the respective URL, such as " https://idp.example.com/tenant/<tenantid>/users/<userid>"= .

best regards,
Torsten.

Am 05.08.2016 um 02:10 schrieb George Fletcher:

Mike, thanks for drafting and publishing these specifications. I have a couple of questions regarding the draft-jones-oauth-resource-metadata-00.

1. Is a "protected resource" a server? or an actual API endpoint. The non-normative examples use /.well-known/oauth-protected-resource and /resource1/.well-known/oauth-protected-resource which is a little unclear. I think of "resource" as something like "Mail" or "Instant Messaging".

2. Assuming that "protected resource" means an actual API endpoint, what is the expected location of the metadata for a fully REST compliant API where the full URL points to a specific resource and not the concept of a general API.

Using an example of an IdP that supports user management capabilities. Let's assume the IdP supports a REST API of...

    CREATE -- POST https://idp.example.com/tenant/<tenantid>/users
    READ -- GET https://idp.example.com/tenant/&= lt;tenantid>/users/<userid>
    UPDATE -- PUT https://idp.example.com/tenant/<tenantid>/users/<userid>
    DELETE -- DELETE https://idp.example.com/tenant/= <tenantid>/users/<userid>

Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users. Where does the .well-known/oauth-protected-resource get added?

   ?? https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oaut= h-protected-resource

In this case would not the oauth-protected-resource metadata be duplicated across the set of tenants and users? Is that the desired behavior?

Thanks,
George



_______________________________________________
          
OAuth mailing list

          
OA=
uth@ietf.org

          
https://www.ietf.org/mailman/listinfo/oauth

 


=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-1BDC4C29-426C-4249-B737-9E4D5372FB1E-- From nobody Sun Nov 13 04:06:28 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E4B1297BC for ; Sun, 13 Nov 2016 04:06:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147903878699.5611.14667415255722811316.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 04:06:26 -0800 From: IETF Secretariat Archived-At: Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 12:06:27 -0000 Changed milestone "Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG for consideration as a Proposed Standard", resolved as "Done". Changed milestone "Submit 'Authentication Method Reference Values' to the IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/oauth/charter/ From nobody Sun Nov 13 07:10:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FB4129670 for ; Sun, 13 Nov 2016 07:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsfBT8xtpU1O for ; Sun, 13 Nov 2016 07:10:46 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) (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 E0BE012950A for ; Sun, 13 Nov 2016 07:10:45 -0800 (PST) Received: from [80.140.198.142] (helo=[10.8.0.6]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1c5wQd-0005Eh-JE for oauth@ietf.org; Sun, 13 Nov 2016 16:10:44 +0100 References: <147904932421.5603.18087367198758224042.idtracker@ietfa.amsl.com> To: "oauth@ietf.org" From: Torsten Lodderstedt X-Forwarded-Message-Id: <147904932421.5603.18087367198758224042.idtracker@ietfa.amsl.com> Message-ID: <5828826E.2090600@lodderstedt.net> Date: Mon, 14 Nov 2016 00:10:38 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <147904932421.5603.18087367198758224042.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030709020701030809010004" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-topics-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 15:10:49 -0000 This is a multi-part message in MIME format. --------------030709020701030809010004 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, I just uploaded the first version of a security document we have been talking about since Berlin. It is intended to be a tool to help us to systematically address all open topics re OAuth security. I will present the draft in the meeting on Wednesday. I would like to ask anybody to review the document upfront, so we can have a productive discussion about the further work. If you cannot be in the meeting, please give feedback to the list. Thanks to Andrey and John for being co-authors. best regards, Torsten. -------- Weitergeleitete Nachricht -------- Betreff: New Version Notification for draft-lodderstedt-oauth-security-topics-00.txt Datum: Sun, 13 Nov 2016 07:02:04 -0800 Von: internet-drafts@ietf.org An: Torsten Lodderstedt , Andrey Labunets , John Bradley A new version of I-D, draft-lodderstedt-oauth-security-topics-00.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. Name: draft-lodderstedt-oauth-security-topics Revision: 00 Title: OAuth Security Topics Document date: 2016-11-12 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-security-topics-00.txt Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/ Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 Abstract: This draft gives a comprehensive overview on open OAuth security topics. It is intended to serve as a tool for the OAuth working group to systematically address these open security topics, recommending mitigations, and potentially also defining OAuth extensions needed to cope with the respective security threats. This draft will potentially become a BCP over time. 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. The IETF Secretariat --------------030709020701030809010004 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all,

I just uploaded the first version of a security document we have been talking about since Berlin. It is intended to be a tool to help us to systematically address all open topics re OAuth security. I will present the draft in the meeting on Wednesday. I would like to ask anybody to review the document upfront, so we can have a productive discussion about the further work. If you cannot be in the meeting, please give feedback to the list.

Thanks to Andrey and John for being co-authors.

best regards,
Torsten.


-------- Weitergeleitete Nachricht --------
Betreff: New Version Notification for draft-lodderstedt-oauth-security-topics-00.txt
Datum: Sun, 13 Nov 2016 07:02:04 -0800
Von: internet-drafts@ietf.org
An: Torsten Lodderstedt <torsten@lodderstedt.net>, Andrey Labunets <isciurus@fb.com>, John Bradley <ve7jtb@ve7jtb.com> 


A new version of I-D, draft-lodderstedt-oauth-security-topics-00.txt
has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name:		draft-lodderstedt-oauth-security-topics
Revision:	00
Title:		OAuth Security Topics
Document date:	2016-11-12
Group:		Individual Submission
Pages:		15
URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-security-topics-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/
Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00


Abstract:
   This draft gives a comprehensive overview on open OAuth security
   topics.  It is intended to serve as a tool for the OAuth working
   group to systematically address these open security topics,
   recommending mitigations, and potentially also defining OAuth
   extensions needed to cope with the respective security threats.  This
   draft will potentially become a BCP over time.

                                                                                  


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.

The IETF Secretariat


--------------030709020701030809010004-- From nobody Sun Nov 13 10:29:02 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 309B9129595; Sun, 13 Nov 2016 10:29:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147906174117.5578.7228114675980681151.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 10:29:01 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 18:29:01 -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 of the IETF. Title : OAuth 2.0 for Native Apps Authors : William Denniss John Bradley Filename : draft-ietf-oauth-native-apps-06.txt Pages : 18 Date : 2016-11-13 Abstract: OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-06 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 Sun Nov 13 13:21:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11CF129651 for ; Sun, 13 Nov 2016 13:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI1fPCGzUc55 for ; Sun, 13 Nov 2016 13:21:35 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E28C1295A0 for ; Sun, 13 Nov 2016 13:21:35 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id c20so44210240itb.0 for ; Sun, 13 Nov 2016 13:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PHp4KAR4xq/3f0q96MKsvDzZrdup0VO7ucp/IkwGq+M=; b=cpG1/SdqbLIJa5SgGdCcrwkJK7rzatmeRd8SfVB9Q7w7Ipt6HwIJvmSitkLhetVg/w 6wxFoCQGF9T0OcGHOu6AQ4aqWZQgSCkK4RLch8DPw0W7Ae2LJcgbyLsUCrilEoFAUmJi 99U5ZTMWvwFeOlVqzPRdXSmksb1HmuUA7iJ5w= 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; bh=PHp4KAR4xq/3f0q96MKsvDzZrdup0VO7ucp/IkwGq+M=; b=mF2y6eWffWVT3isN4IMexpjwjTDvQi1wT1g5uAlYAU8pnZDiT+Gw9Ck9w+4Yjy34pH eVkbKoV5CuUPt9wfiaJbW5Lt61eft7+fueMaIudLKYeou+OSydJBpjTQlA2ju7O4ggeR ADBg51QDQGdQX1JABFUY6O0SbGhnu2xFl3pYwYgSIKkqUBrEAXnnsnwzzkhDTvbGs+Mo ycmZRjIX8TkD9dkV/TWHlxGtMbjAUzLnxST8TIY5VktbFlct7i2h8Qhrm0XlmAg/O+SV uckAf/FneEqw2rBQpnJWx/WshxADQ8QWpcWgepnQ1Y5x8eVaK/9acT6tBl5kislFNo9c YmIA== X-Gm-Message-State: ABUngvci2qEt+jjXQ7+cGO0y0ikHFIClHa48DQZTRdc3DWJO/0Qql/aEjNoH1Rgv9Nzc56GjHlZhdGW5P6eU66Eg X-Received: by 10.36.31.82 with SMTP id d79mr4016864itd.79.1479072094268; Sun, 13 Nov 2016 13:21:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Sun, 13 Nov 2016 13:21:03 -0800 (PST) In-Reply-To: <58280139.2040505@lodderstedt.net> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> <58280139.2040505@lodderstedt.net> From: Brian Campbell Date: Sun, 13 Nov 2016 14:21:03 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001a1145e852c6be0e0541354e36 Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 21:21:37 -0000 --001a1145e852c6be0e0541354e36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, the intend is that the authentication method is determined by client policy regardless of whether the client was dynamically registered or statically configured or whatever. I can make that point more explicit in future revisions of the draft. On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > I understand. My point is different: the text seems to assume everybody i= s > using client registration, but that's not the case. I would like to point > out it makes sense to explicitely state the assumption that it is > determined by client policy (indepedent of the way this policy is > established). > > > Am 13.11.2016 um 14:24 schrieb Justin Richer: > > As part of the client=E2=80=99s registered data model. At least, based on= how our > own implementation works (where we support client_secret_basic, > private_key_jwt, etc), that=E2=80=99s where we=E2=80=99d check to see if = the client was > supposed to be using TLS auth or not. > > We don=E2=80=99t let clients switch away from their registered auth mecha= nism. > > =E2=80=94 Justin > > On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt > wrote: > > Justin, > > Am 13.11.2016 um 13:39 schrieb Justin Richer: > > Torsten, I believe this is intended to be triggered by the tls_client_aut= h > value specified in =C2=A73. > > > in the token request? > > > Nit on that section, the field name for the client metadata in RFC7591 is > token_endpoint_auth_method, the _supported version is from the > corresponding discovery document. > > =E2=80=94 Justin > > Torsten. > > On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi John and Brian, > > thanks for writting this draft. > > One question: how does the AS determine the authentication method is TLS > authentication? I think you assume this is defined by the client-specific > policy, independent of whether the client is registered automatically or > manually. Would you mind to explicitely state this in the draft? > > best regards, > Torsten. > > Am 11.10.2016 um 05:59 schrieb John Bradley: > > At the request of the OpenID Foundation Financial Services API Working > group, Brian Campbell and I have documented > mutual TLS client authentication. This is something that lots of people > do in practice though we have never had a spec for it. > > The Banks want to use it for some server to server API use cases being > driven by new open banking regulation. > > The largest thing in the draft is the IANA registration of > =E2=80=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method fo= r use in > Registration and discovery. > > The trust model is intentionally left open so that you could use a =E2=80= =9Ccommon > name=E2=80=9D and a restricted list of CA or a direct lookup of the subje= ct public > key against a reregistered value, or something in between. > > I hope that this is non controversial and the WG can adopt it quickly. > > Regards > John B. > > > > > Begin forwarded message: > > *From: * internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-campbell-oauth-tls-client-auth-00.txt* > *Date: *October 10, 2016 at 5:44:39 PM GMT-3 > *To: *"Brian Campbell" < > brian.d.campbell@gmail.com>, "John Bradley" < > ve7jtb@ve7jtb.com> > > > A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt > has been successfully submitted by John Bradley and posted to the > IETF repository. > > Name: draft-campbell-oauth-tls-client-auth > Revision: 00 > Title: Mutual X.509 Transport Layer Security (TLS) Authentication for > OAuth Clients > Document date: 2016-10-10 > Group: Individual Submission > Pages: 5 > URL: > > https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client- > auth-00.txt > Status: > > https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ > Htmlized: > > https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 > > > Abstract: > This document describes X.509 certificates as OAuth client > credentials using Transport Layer Security (TLS) mutual > authentication as a mechanism for client authentication to the > authorization server's token endpoint. > > > > > 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. > > The IETF Secretariat > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > --001a1145e852c6be0e0541354e36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, the intend is that the authentication method is deter= mined by client policy regardless of whether the client was dynamically reg= istered or statically configured or whatever. I can make that point more ex= plicit in future revisions of the draft.

On Sat, Nov 12, 2016 at 10:59 PM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
I understand. My point is different: the text seems to assume everybody is using client registration, but that's not the case. I would like to point out it makes sense to explicitely state the assumption that it is determined by client policy (indepedent of the way this policy is established).


Am 13.11.2016 um 1= 4:24 schrieb Justin Richer:
=20 As part of the client=E2=80=99s registered data model. At least, base= d on how our own implementation works (where we support client_secret_basic, private_key_jwt, etc), that=E2=80=99s where we= =E2=80=99d check to see if the client was supposed to be using TLS auth or not.

We don=E2=80=99t let clients switch away from their registered auth mechanism.

=C2=A0=E2=80=94 Justin

On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20
Justin,

Am 13.= 11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe this is intended to be triggered by the tls_client_auth value specified in =C2=A73.

in the token request?


Nit on that section, the field name for the client metadata in RFC7591 is token_endpoint_auth_method, the _supported version is from the corresponding discovery document.

=C2=A0=E2=80=94 Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented=C2=A0
mutual TLS client authentication. =C2=A0 This is something th= at lots of people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of =E2=80=9Ctls_client_auth=E2=80=9D Token End= point authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a =E2=80=9Ccommon name=E2=80=9D a= nd a restricted list of CA or a direct lookup of the subject public key against a reregistered value, =C2=A0or something in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.




Begin forwarded message:

Subject: New Version Notification for draft-campbell-oauth-tls-cli= ent-auth-00.txt
Date: To: = "Brian Campbell" <brian.d.campbell@gmail.= com>, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, draft-campbell-oauth-tls-clien= t-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: <= /span>draft-campbell-oauth-tls-client-auth
Revision: 00
Title: <= /span>Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 2016= -10-10
Group: <= /span>Individual Submission
Pages: <= /span>5
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-campbe= ll-oauth-tls-client-auth-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0https://datatracker= .ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0https://tools.ietf.org/html/d= raft-campbell-oauth-tls-client-auth-00


Abstract:
=C2=A0=C2=A0This document describes= X.509 certificates as OAuth client
=C2=A0=C2=A0credentials using Trans= port Layer Security (TLS) mutual
=C2=A0=C2=A0authentication as a mec= hanism for client authentication to the =C2=A0=C2=A0authorization server= 9;s token endpoint.




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.

The IETF Secretariat




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

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





--001a1145e852c6be0e0541354e36-- From nobody Sun Nov 13 13:26:07 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAE512957D for ; Sun, 13 Nov 2016 13:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4oiCC5e9MWS for ; Sun, 13 Nov 2016 13:26:04 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E08B129458 for ; Sun, 13 Nov 2016 13:26:04 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id q124so65982362itd.1 for ; Sun, 13 Nov 2016 13:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RXriWHZoowbCqGfFYM6TSinC0E6GHkZlKQ/sYGkzOec=; b=YRZqfj42cCZTOOvsdBmsdOyTG9SgXLEgoe+q6smyDED2EwLpnvWbdTmFKHJNzUzWk1 z+OFQ01C5rinaFs5zk3LL6cSU5jvbkDf9gOHLeTNJIErVuJqPsSlblFGhsIZPh1cOjgq wjfVjft4a5OGIPahsn/4BYMhB/+v541DF9O84= 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; bh=RXriWHZoowbCqGfFYM6TSinC0E6GHkZlKQ/sYGkzOec=; b=KlMpoGcdguslmySRKsJoLmQ69cvl5WJithQ6W/419M/OiVG6takPCNR/kiZPLhDYXb /SJD0NJGAxx+vB+Cq/S4+FmzqlBTcI+8H87/V13+mVTEckLLHkrXWKoqxlL4wPSxuvr/ HHX//HgXt9tjGiEVR+1Z/E3ItVG1dAaFU/g244DeYbNyyPZ/DIKM+eJJ/Yfo5Z8QkMRc 7t7y0AhMvn86n4RpeOEu5+mFd+fCsrEL3hy4TFtBX4tIZ7rHDhFx75tP2scOkFPWsa4X jcFyRDcX9v5UEZzpNJfiVIENabZWzf1rjsMW2EZBzr8dzEXujPoW3yT5QyeCYsCGYMY/ +yCQ== X-Gm-Message-State: ABUngvdYoKKdbkCGOlJQkTF2nGQ8AZCUTt/D+JxN+uZfy5RBxKPk4p7LYUqVUy0FanpwR9Um3ZcquWzyB5qRl16k X-Received: by 10.107.13.137 with SMTP id 131mr20883560ion.122.1479072364046; Sun, 13 Nov 2016 13:26:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Sun, 13 Nov 2016 13:25:33 -0800 (PST) In-Reply-To: <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> From: Brian Campbell Date: Sun, 13 Nov 2016 14:25:33 -0700 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a113fdfd4db47820541355e7b Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 21:26:05 -0000 --001a113fdfd4db47820541355e7b Content-Type: text/plain; charset=UTF-8 Good catch Justin, thank you. I got the filed names switched around for some reason. On Sat, Nov 12, 2016 at 9:39 PM, Justin Richer wrote: > > > Nit on that section, the field name for the client metadata in RFC7591 is > token_endpoint_auth_method, the _supported version is from the > corresponding discovery document. > --001a113fdfd4db47820541355e7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good catch Justin, thank you. I got the filed names switch= ed around for some reason.

On Sat, Nov 12, 2016 at 9:39 PM, Justin Richer <jricher@m= it.edu> wrote:

Nit on that section, the field name= for the client metadata in RFC7591 is token_endpoint_auth_method, the _sup= ported version is from the corresponding discovery document.


=C2=A0
--001a113fdfd4db47820541355e7b-- From nobody Sun Nov 13 14:58:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05D6129559 for ; Sun, 13 Nov 2016 14:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyTECPW6pOp9 for ; Sun, 13 Nov 2016 14:58:19 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2841294CA for ; Sun, 13 Nov 2016 14:58:18 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 41B667802D7; Sun, 13 Nov 2016 23:58:16 +0100 (CET) To: Torsten Lodderstedt , Nat Sakimura , oauth@ietf.org References: <58eb4c58-59c2-dac6-2e41-76ec359d4210@free.fr> <5828035C.801@lodderstedt.net> From: Denis Message-ID: <37928b52-928a-86a0-52b2-dd5504ad9f03@free.fr> Date: Sun, 13 Nov 2016 23:58:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5828035C.801@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------CB06F4B0E2C086C3ED956B4F" Archived-At: Subject: Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 22:58:23 -0000 This is a multi-part message in MIME format. --------------CB06F4B0E2C086C3ED956B4F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Nat and Torsten, My responses ares embedded in your text. > I agree, we should analyse the threat. From my first impression it > feels like injection with some specialties. Not exactly. In most scenario attacks, we have two good guys (Alice and Bob) and one bad guy (Carol) acting as the single attacker.. In this scenario, we have two bad guys (Alice and Bob willing to collaborate) and one good guy (Carol) acting as a relying party. > > @Denis: > So far, I'm struggeling to understand how this attack is performed > from a practical perspective. > Every token/assertion issued to the uncle is bound to its identity. This key question is to which "identity" since I am considering a scheme where privacy considerations are as important as security considerations. So the goal is only to reveal to the third party that the user making the access is more than 18, without revealing anything else than the relying party would already know about the user making the access request. > So if the niece wants to "upgrade" her age, she would need to somehow > mix identity data for two identities > (her's and her uncle's identity) into a single token, which needs to > be signed by the respective AS. How is this gone work? As yourself, I don't believe this is a solution. As I already said: Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it . The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element (i.e. some physical device with security properties). > > kind regards, > Torsten. > > Am 11.11.2016 um 16:27 schrieb Nat Sakimura: >> Thanks Denis for pointing it out. It may be desirable to add ABC >> attack to the list of threats. >> Torsten et al. are updating Threat Model and Security Considerations >> so it could potentially be included in there. >> >> Some remarks: >> >> * I suppose the assumption is that the Bob does not share his >> credentials with Alice: Otherwise, sharing the credential would >> achieve something worse. >> The assumption is correct. >> * In addition, it assumes that Bob does not give his device to >> Alice: Otherwise, something similar to ABC attack can be achieved >> by Bob >> giving Alice his Laptop or Phone, and I guess this happens more >> often than shipping Bob's access token to Alice. >> The assumption is correct. If Bob is using a smart card that protects some keys, he will never give the smart card nor the PIN to Alice. >> * >> >> >> * With these assumptions: >> o It looks like a variation of token injection attack that we >> have been talking about for many years. >> Not exactly. >> o If we token bind the refresh and access tokens, the ABC >> attack as described does not work. >> I am not sure I understand what you mean here, since my belief is still : Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it . >> o For something like Age verification, recognizing such >> attacks, it probably is a bad practice to rely on >> refresh/access token. >> The service should do more active check, e.g., through OpenID >> Connect. >> Same comment as above. Denis >> Best, >> >> Nat >> >> On Tue, Nov 8, 2016 at 2:54 AM Denis wrote: >> >> Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" >> identifies requirements. >> One of them (which, BTW, should be moved into Section 4 - >> Threats) is : >> >> Collusion: >> >> Resource servers that collude ... >> >> This threat addresses the case of "/collusion between servers"/ >> while the case of "/collusion between clients"/ >> has not been considered. When access tokens are being used, >> /collusion between clients /is of primary importance. >> >> Let us consider the following "Alice and Bob Collusion attack" >> (ABC attack). >> >> An uncle (Bob) is willing to collaborate with his young niece >> (Alice) who is less than 18 during a short period of time. >> The niece is opening her own session and creates an account on a >> server. The uncle does not hand over his own session to her niece >> at any point of time. >> >> Let us assume that some crypto expert has written two specific >> pieces of software. One has been installed on the laptop >> of the uncle and another one on the laptop of the niece. The two >> laptops are able to communicate using a network (e.g. a WAN or a >> LAN). >> >> The niece creates an account on a resource server. Later on, the >> resource server asks her (or him ?) to demonstrate that she (or >> his ?) >> is more than 18. She forwards the information received from the >> resource server to her uncle using the network. The uncle receives >> that information and connects to an Authorization Server. The >> uncle requests an access token containing information demonstrating >> that he is older than 18 and passed it back to his niece. The >> niece then presents it to the resource server. The access token >> is accepted. >> >> Since the niece has been able to demonstrate once that she is >> more than 18, the resource server will remember this attribute >> and in the future she will not need to demonstrate it again. She >> will keep the advantages related to this attribute associated >> with her account on that resource server until she does not need >> it anymore, i.e. when she will really be over 18. >> >> Whatever kind of cryptographic is being used, when two users >> collaborate, a software-only solution will be >> unable to prevent the transfer of an attribute of a user that >> possess it to another user that does not possess it . >> >> The use of a secure element simply protecting the confidentiality >> and the integrity of some secret key or private key will be >> ineffective >> to counter the Alice and Bob collusion attack. Additional >> properties will be required for the secure element. >> >> RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) >> issued in January 2013 has omitted to take into consideration >> the Alice and Bob Collusion attack. >> >> Section 2.3 of the ABC4Trust project about key-binding in >> Deliverable D2.2 available at: >> https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page >> 17 : >> >> To prevent “credential pooling”, i.e., multiple Users sharing >> their credentials, credentials can optionally be bound to a >> secret key, >> i.e. a cryptographically strong random value that is assumed to >> be known only to a particular user. The credential specification >> specifies whether the credentials issued according to this >> specification are to employ key binding or not. >> >> A presentation token derived from such a key-bound credential >> always contains an implicit proof of knowledge of the underlying >> secret key, >> so that the Verifier can be sure that the rightful owner of the >> credential was involved in the creation of the presentation token. >> As an extra protection layer, the credentials can also be bound >> to a trusted physical device, such as a smart card, by keeping >> the secret key in a protected area of the device. That is, the >> key cannot be extracted from the device, but the device does >> participate >> in the presentation token generation to include an implicit proof >> of knowledge of this key in the token. Thus, for credentials that >> are key-bound >> to a physical device it is impossible to create a presentation >> token without the device. >> >> The rightful owner of the credential was indeed involved in >> real-time in the creation of the presentation token but in the >> collaboration scenario, >> the key binding mechanism is not sufficient to counter that >> specific attack. ABC4Trust, Idemix (IBM) and U-Prove >> (Microsoft)are currently >> not resistant to the "ABC attack". >> >> The IRMA card project (https://www.irmacard.org/) based on the >> use of a smart card and of the Idemix scheme claims to provide >> security >> and privacy simultaneously. However, this project will not be >> resistant either to the ABC attack. >> >> *draft-ietf-oauth-pop-architecture-08 should take into >> consideration the ABC attack.* >> >> The threat related to the ABC attack should be identified in the >> security considerations section >> and the core of the document should attempt to identify one or >> more ways to counter it. >> >> The scope of draft-ietf-oauth-token-exchange-06 is limited to the >> definition of a basic request and response protocol for >> an STS-style token exchange utilizing OAuth 2.0. Section 6 >> (Security Considerations) has omitted to take into consideration >> the ABC attack and therefore the currently described "basic >> request and response protocol" will allow Bob to obtain an access >> token and to pass it successfully to Alice so that she can use it. >> >> *draft-ietf-oauth-token-exchange-06 **should take into >> consideration the ABC attack.* >> >> The threat related to the ABC attack should be identified in the >> security considerations section >> and the core of the document should attempt to identify one or >> more ways to counter it. >> >> Denis >> >> PS. I have recently registered to the OAuth mailing list. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> -- >> >> Nat Sakimura >> >> Chairman of the Board, OpenID Foundation >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --------------CB06F4B0E2C086C3ED956B4F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Nat and Torsten,

My responses ares embedded in your text.

I agree, we should analyse the threat. From my first impression it feels like injection with some specialties.

Not exactly. In most scenario attacks, we have two good guys (Alice and Bob) and one bad guy (Carol) acting as the single attacker..
In this scenario, we have two bad guys (Alice and Bob willing to collaborate) and one good guy (Carol) acting as a relying party.

@Denis:
So far, I'm struggeling to understand how this attack is performed from a practical perspective.
Every token/assertion issued to the uncle is bound to its identity.

This key question is to which "identity" since I am considering a scheme where privacy considerations are as important as security considerations.
So the goal is only to reveal to the third party that the user making the access is more than 18, without revealing anything else than the relying party
would already know about the user making the access request.

So if the niece wants to "upgrade" her age, she would need to somehow mix identity data for two identities
(her's and her uncle's identity) into a single token, which needs to be signed by the respective AS. How is this gone work?

As yourself, I don't believe this is a solution. As I already said:
Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable
to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key
will be ineffective to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element
(i.e. some physical device with security properties).

kind regards,
Torsten.

Am 11.11.2016 um 16:27 schrieb Nat Sakimura:
Thanks Denis for pointing it out. It may be desirable to add ABC attack to the list of threats.
Torsten et al. are updating Threat Model and Security Considerations so it could potentially be included in there. 

Some remarks: 
  • I suppose the assumption is that the Bob does not share his credentials with Alice: Otherwise, sharing the credential would achieve something worse.
The assumption is correct.

  • In addition, it assumes that Bob does not give his device to Alice: Otherwise, something similar to ABC attack can be achieved by Bob
    giving Alice his Laptop or Phone, and I guess this happens more often than shipping Bob's access token to Alice.

The assumption is correct. If Bob is using a smart card that protects some keys, he will never give the smart card nor the PIN to Alice.


  • With these assumptions: 
    • It looks like a variation of token injection attack that we have been talking about for many years.

Not exactly.


    • If we token bind the refresh and access tokens, the ABC attack as described does not work.

I am not sure I understand what you mean here, since my belief is still :
Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable
to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

    • For something like Age verification, recognizing such attacks, it probably is a bad practice to rely on refresh/access token.
      The service should do more active check, e.g., through OpenID Connect.

Same comment as above.

Denis

Best, 

Nat

On Tue, Nov 8, 2016 at 2:54 AM Denis <denis.ietf@free.fr> wrote:

Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies requirements.
One of them (which, BTW, should be moved into Section 4 - Threats) is :

Collusion:

      Resource servers that collude ...

This threat addresses the case of "collusion between servers" while the case of "collusion between clients"
has not been considered. When access tokens are being used, collusion between clients is of primary importance.

Let us consider the following "Alice and Bob Collusion attack" (ABC attack).

An uncle (Bob) is willing to collaborate with his young niece (Alice) who is less than 18 during a short period of time.
The niece is opening her own session and creates an account on a server. The uncle does not hand over his own session to her niece
at any point of time.

Let us assume that some crypto expert has written two specific pieces of software. One has been installed on the laptop
of the uncle and another one on the laptop of the niece. The two laptops are able to communicate using a network (e.g. a WAN or a LAN).

The niece creates an account on a resource server. Later on, the resource server asks her (or him ?) to demonstrate that she (or his ?)
is more than 18. She forwards the information received from the resource server to her uncle using the network. The uncle receives
that information and connects to an Authorization Server. The uncle requests an access token containing information demonstrating
that he is older than 18 and passed it back to his niece. The niece then presents it to the resource server. The access token is accepted.

Since the niece has been able to demonstrate once that she is more than 18, the resource server will remember this attribute
and in the future she will not need to demonstrate it again. She will keep the advantages related to this attribute associated
with her account on that resource server until she does not need it anymore, i.e. when she will really be over 18.

Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be
unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective
to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element.

RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 has omitted to take into consideration
the Alice and Bob Collusion attack.

Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.2 available at:
https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 :

To prevent “credential pooling”, i.e., multiple Users sharing their credentials, credentials can optionally be bound to a secret key,
i.e. a cryptographically strong random value that is assumed to be known only to a particular user. The credential specification
specifies whether the credentials issued according to this specification are to employ key binding or not.

A presentation token derived from such a key-bound credential always contains an implicit proof of knowledge of the underlying secret key,
so that the Verifier can be sure that the rightful owner of the credential was involved in the creation of the presentation token.
As an extra protection layer, the credentials can also be bound to a trusted physical device, such as a smart card, by keeping
the secret key in a protected area of the device. That is, the key cannot be extracted from the device, but the device does participate
in the presentation token generation to include an implicit proof of knowledge of this key in the token. Thus, for credentials that are key-bound
to a physical device it is impossible to create a presentation token without the device.

The rightful owner of the credential was indeed involved in real-time in the creation of the presentation token but in the collaboration scenario,
the key binding mechanism is not sufficient to counter that specific attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft) are currently
not resistant to the "ABC attack".

The IRMA card project (https://www.irmacard.org/) based on the use of a smart card and of the Idemix scheme claims to provide security
and privacy simultaneously. However, this project will not be resistant either to the ABC attack.

draft-ietf-oauth-pop-architecture-08 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

The scope of draft-ietf-oauth-token-exchange-06 is limited to the definition of a basic request and response protocol for
an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security Considerations) has omitted to take into consideration
the ABC attack and therefore the currently described "basic request and response protocol" will allow Bob to obtain an access
token and to pass it successfully to Alice so that she can use it.

draft-ietf-oauth-token-exchange-06 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

Denis

PS. I have recently registered to the OAuth mailing list.


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

Nat Sakimura

Chairman of the Board, OpenID Foundation



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


--------------CB06F4B0E2C086C3ED956B4F-- From nobody Sun Nov 13 16:26:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E562B129558 for ; Sun, 13 Nov 2016 16:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxFNeB66NKuO for ; Sun, 13 Nov 2016 16:26:48 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC2A129467 for ; Sun, 13 Nov 2016 16:26:48 -0800 (PST) X-AuditID: 12074423-0abff70000005d64-6d-582904c6e001 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 2E.33.23908.6C409285; Sun, 13 Nov 2016 19:26:47 -0500 (EST) 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 uAE0Qj6q013490; Sun, 13 Nov 2016 19:26:46 -0500 Received: from dhcp-8693.meeting.ietf.org (dhcp-8693.meeting.ietf.org [31.133.134.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAE0Qd0j016975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Nov 2016 19:26:42 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_F321B417-8580-4E8D-9F5B-63BE1E7CD0F6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Mon, 14 Nov 2016 09:26:37 +0900 Message-Id: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> <58280139.2040505@lodderstedt.net> To: Brian Campbell X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsUixCmqrHucRTPCYMFKaYvV/28yWpx8+4rN 4tWxpywWq+/+ZXNg8Viy5CeTx7GeflaPu0cvsnjcvr2RJYAlissmJTUnsyy1SN8ugSvjyslO 9oIX1xkrLi8Ta2DsmcLYxcjJISFgInHowFHmLkYuDiGBNiaJR11XWEASQgIbGSVWTSqESFxh kljx4icbSIJZIEHi6JxfYDavgJ7EpvVvmUBsYaD4mVftYDabgKrE9DUtYDanQKDE7Vub2EFs FqD4jBkvmUCGMgs0MkrMmnoFapCVxNppr6HO6GaWWL5iIliHiIC+xO2nc9ghbpWVeHJyEcsE Rv5ZSA6ZheQQiLi2xLKFr5khbE2J/d3LWTDFNSQ6v01kXcDItopRNiW3Sjc3MTOnODVZtzg5 MS8vtUjXTC83s0QvNaV0EyMoDthdlHcwvuzzPsQowMGoxMP7oFAjQog1say4MvcQoyQHk5Io 71lzoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3gPMmhFCvCmJlVWpRfkwKWkOFiVx3v9uX8OF BNITS1KzU1MLUotgsjIcHEoSvAtBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGq7GADC8uSMwtzkyH yJ9iNOZ4s+vlAyaOPbNePWASYsnLz0uVEueVYQQqFQApzSjNg5sGSmXyrW2TXzGKAz0nzBsK spQHmAbh5r0CWsUEtGoXyI+8xSWJCCmpBsbpkhMWhc/Tey9QunDm1iNLpj89xLtzrlTNSqHK TTUnRDe19h1fM0FK9/CKq/qtapN+pbtXCEndva4axcF5VeeRwgOO3ded3/37liZqUHB5mW8p EwfbApvNsRvFb39iNc3YfE94aoBeY/6dDb8NTHbNYW/7Z/d2y64v/SXT9b4aLNtQ9SFZWm2G EktxRqKhFnNRcSIANgypmkADAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 00:26:51 -0000 --Apple-Mail=_F321B417-8580-4E8D-9F5B-63BE1E7CD0F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Right =E2=80=94 this is a fine way to put it. RFC7591 defines a client = model where RFC6749 didn=E2=80=99t. Ideally all that metadata would=E2=80=99= ve been in the original spec, but it=E2=80=99s not. It doesn=E2=80=99t = matter whether the client was registered dynamically or statically, it = just matters that the AS knows what to expect from a given client. =E2=80=94 Justin > On Nov 14, 2016, at 6:21 AM, Brian Campbell = wrote: >=20 > Yes, the intend is that the authentication method is determined by = client policy regardless of whether the client was dynamically = registered or statically configured or whatever. I can make that point = more explicit in future revisions of the draft.=20 >=20 > On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt = > wrote: > I understand. My point is different: the text seems to assume = everybody is using client registration, but that's not the case. I would = like to point out it makes sense to explicitely state the assumption = that it is determined by client policy (indepedent of the way this = policy is established). >=20 >=20 > Am 13.11.2016 um 14:24 schrieb Justin Richer: >> As part of the client=E2=80=99s registered data model. At least, = based on how our own implementation works (where we support = client_secret_basic, private_key_jwt, etc), that=E2=80=99s where we=E2=80=99= d check to see if the client was supposed to be using TLS auth or not. >>=20 >> We don=E2=80=99t let clients switch away from their registered auth = mechanism. >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt = > wrote: >>>=20 >>> Justin, >>>=20 >>> Am 13.11.2016 um 13:39 schrieb Justin Richer: >>>> Torsten, I believe this is intended to be triggered by the = tls_client_auth value specified in =C2=A73.=20 >>>=20 >>> in the token request? >>>=20 >>>>=20 >>>> Nit on that section, the field name for the client metadata in = RFC7591 is token_endpoint_auth_method, the _supported version is from = the corresponding discovery document. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>> Torsten. >>>>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt < = torsten@lodderstedt.net = > wrote: >>>>>=20 >>>>> Hi John and Brian, >>>>>=20 >>>>> thanks for writting this draft. >>>>>=20 >>>>> One question: how does the AS determine the authentication method = is TLS authentication? I think you assume this is defined by the = client-specific policy, independent of whether the client is registered = automatically or manually. Would you mind to explicitely state this in = the draft? >>>>>=20 >>>>> best regards, >>>>> Torsten. >>>>>=20 >>>>> Am 11.10.2016 um 05:59 schrieb John Bradley: >>>>>> At the request of the OpenID Foundation Financial Services API = Working group, Brian Campbell and I have documented=20 >>>>>> mutual TLS client authentication. This is something that lots = of people do in practice though we have never had a spec for it. >>>>>>=20 >>>>>> The Banks want to use it for some server to server API use cases = being driven by new open banking regulation. >>>>>>=20 >>>>>> The largest thing in the draft is the IANA registration of = =E2=80=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method = for use in Registration and discovery. >>>>>>=20 >>>>>> The trust model is intentionally left open so that you could use = a =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct = lookup of the subject public key against a reregistered value, or = something in between. >>>>>>=20 >>>>>> I hope that this is non controversial and the WG can adopt it = quickly. >>>>>>=20 >>>>>> Regards >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Begin forwarded message: >>>>>>>=20 >>>>>>> From: internet-drafts@ietf.org = >>>>>>> Subject: New Version Notification for = draft-campbell-oauth-tls-client-auth-00.txt >>>>>>> Date: October 10, 2016 at 5:44:39 PM GMT-3 >>>>>>> To: "Brian Campbell" < = brian.d.campbell@gmail.com = >, "John Bradley" < = ve7jtb@ve7jtb.com > >>>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, = draft-campbell-oauth-tls-client-auth-00.txt >>>>>>> has been successfully submitted by John Bradley and posted to = the >>>>>>> IETF repository. >>>>>>>=20 >>>>>>> Name: draft-campbell-oauth-tls-client-auth >>>>>>> Revision: 00 >>>>>>> Title: Mutual X.509 Transport Layer Security (TLS) = Authentication for OAuth Clients >>>>>>> Document date: 2016-10-10 >>>>>>> Group: Individual Submission >>>>>>> Pages: 5 >>>>>>> URL: = https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-clie= nt-auth-00.txt = >>>>>>> Status: = ht= tps://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ = >>>>>>> Htmlized: = https= ://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 = >>>>>>>=20 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> This document describes X.509 certificates as OAuth client >>>>>>> credentials using Transport Layer Security (TLS) mutual >>>>>>> authentication as a mechanism for client authentication to the >>>>>>> authorization server's token endpoint. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Please note that it may take a couple of minutes from the time = of submission >>>>>>> until the htmlized version and diff are available at = tools.ietf.org . >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=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 = >>>>=20 >>>=20 >>=20 >=20 >=20 --Apple-Mail=_F321B417-8580-4E8D-9F5B-63BE1E7CD0F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Right =E2=80=94 this is a fine way to put it. RFC7591 defines = a client model where RFC6749 didn=E2=80=99t. Ideally all that metadata = would=E2=80=99ve been in the original spec, but it=E2=80=99s not. It = doesn=E2=80=99t matter whether the client was registered dynamically or = statically, it just matters that the AS knows what to expect from a = given client.

 =E2=80=94 Justin

On = Nov 14, 2016, at 6:21 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Yes, the intend is that the = authentication method is determined by client policy regardless of = whether the client was dynamically registered or statically configured = or whatever. I can make that point more explicit in future revisions of = the draft.

On Sat, Nov 12, 2016 at 10:59 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
I understand. My point is different: the text seems to assume everybody is using client registration, but that's not the case. I would like to point out it makes sense to explicitely state the assumption that it is determined by client policy (indepedent of the way this policy is established).


Am 13.11.2016 = um 14:24 schrieb Justin Richer:
=20 As part of the client=E2=80=99s registered data model. At least, = based on how our own implementation works (where we support client_secret_basic, private_key_jwt, etc), that=E2=80=99s where = we=E2=80=99d check to see if the client was supposed to be using TLS auth or not.

We don=E2=80=99t let clients switch away from = their registered auth mechanism.

 =E2=80=94 Justin

On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=
=20
= Justin,

Am = 13.11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe = this is intended to be triggered by the tls_client_auth value specified in =C2=A73.

in the token request?


Nit on that section, the field name = for the client metadata in RFC7591 is token_endpoint_auth_method, the _supported version is from the corresponding discovery document.

 =E2=80=94 Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John and Brian,

thanks for writting this draft.
=
One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the = request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented 
mutual TLS client authentication.   This is something = that lots of people do in practice though we have never had a spec for it.

The Banks want to use it = for some server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of =E2=80=9Ctls_client_auth=E2=80=9D Token = Endpoint authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a =E2=80=9Ccommon name=E2=80=9D = and a restricted list of CA or a direct lookup of the subject public key against a reregistered value,  or something = in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.




Begin forwarded message:

From: internet-drafts@ietf.org
Subject: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
Date: October 10, 2016 at 5:44:39 PM GMT-3
To: "Brian Campbell" <brian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: draft-campbell-oauth-tls-client-auth
Revision: 00
Title: Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 2016-10-10
Group: Individual Submission
Pages: 5
URL: =            https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized: =       https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00


Abstract:
  This document = describes X.509 certificates as OAuth client
  credentials using = Transport Layer Security (TLS) mutual
  authentication as a = mechanism for client authentication to = the
  authorization = server's token endpoint.




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.

The IETF Secretariat




_______________________________________________=

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=_F321B417-8580-4E8D-9F5B-63BE1E7CD0F6-- From nobody Sun Nov 13 22:50:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB98129434 for ; Sun, 13 Nov 2016 22:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP-Zs8fzU7qg for ; Sun, 13 Nov 2016 22:50:43 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0116.outbound.protection.outlook.com [104.47.42.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AECD129415 for ; Sun, 13 Nov 2016 22:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w7Fs/yMe8sX7lB3MTWKkt50leJKE1PEMKyso2iRCwzc=; b=miT3vnwUmbH3ra+Hk7hxuLy2q1/x0IiqlMZcG57FBFB7j1EByKDR1A1jVZg60CkaRVNsXs34a+lqMK46Y6MzX2bho33DrVpr0hDouPIsI2wUXZI1ywqa7B03ikFisSNMAluyNcLR6gy67lMnEMQumygYO46JQuzio6cUWZf56lg= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2356.namprd03.prod.outlook.com (10.166.74.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Mon, 14 Nov 2016 06:50:39 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0721.015; Mon, 14 Nov 2016 06:50:39 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Draft OAuth WG meeting minutes for 9:30-noon 14-Nov-16 in Seoul Thread-Index: AdI+H8UE2+gxPU7lR1K21KAy4X6OIA== Date: Mon, 14 Nov 2016 06:50:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:67c:370:128:dca7:1fb6:1ff6:f5d3] x-microsoft-exchange-diagnostics: 1; BN3PR03MB2356; 7:8qa8lDfVYEBlR67/Ar7uM/T10TS4YN/x5QIrDTBUB3y0z5NN/UEKCYl2i83FJQQPqXvhR3uTuYqZ2cm7qI+0WPFwQD/cAbzA5/Kx06ytpiKc8odCx8AvkbkoPApJEAqHLT47RKvyrl2xynpUz/IFsEevtAh7g+8STMnYX+HRjsArgkDnAiUXARHeMs2s0fX+AEL3B4NtVlPdfvlNUEJAR9n11SrmuW3AAUxo+0Hml96jY1PzFe/ryMYxi2SXN2HXBmQjr5HjBH8IkBsAoEDjUWiNk0ofgBO0b3svq5TEOqcNLbP2YhJ9uCppjmz4pujJ/C5g55RlXhcfYvPqO5ZCiYDhra3tJnbLbIcVCIfIzvAa44i8+UlbOhClqh/ZXdM/ x-ms-office365-filtering-correlation-id: da135692-a878-46f5-8aac-08d40c5a8bc5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2356; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(209352067349851)(192374486261705)(231181664957973)(211936372134217)(100405760836317)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060322)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6061317)(6046074); SRVR:BN3PR03MB2356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2356; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(336003)(53824002)(22804003)(189002)(199003)(8676002)(189998001)(5005710100001)(6916009)(87936001)(9686002)(10290500002)(586003)(2351001)(102836003)(790700001)(6116002)(7696004)(110136003)(5660300001)(7846002)(1730700003)(5640700001)(81156014)(81166006)(8936002)(74316002)(5630700001)(97736004)(7736002)(86362001)(86612001)(8990500004)(107886002)(3280700002)(3660700001)(68736007)(101416001)(230783001)(2906002)(450100001)(54356999)(122556002)(10090500001)(50986999)(76576001)(2900100001)(99286002)(105586002)(77096005)(2501003)(106356001)(10126002)(561944003)(92566002)(33656002)(559001)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2356; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB2355F2647C7FB9A1BA94F4D6F5BC0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 06:50:39.6460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2356 Archived-At: Subject: [OAUTH-WG] Draft OAuth WG meeting minutes for 9:30-noon 14-Nov-16 in Seoul X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 06:50:48 -0000 --_000_BN3PR03MB2355F2647C7FB9A1BA94F4D6F5BC0BN3PR03MB2355namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hannes gave an OAuth WG status update AMR Values spec sent to the IESG Request by JWS spec sent to the IESG Native apps specification Recently updated to make it more readable Hannes is working on a shepherd update John Bradley said that some minor updates to the= Windows Universal Platform language are being done It's nearly done. People are requested to provi= de feedback. People are using an SDK embodying this specifica= tion that was published by the OpenID Connect working group The spec is a BCP that we can revise as needed Hannes suggested that a tutorial be done on how = to use the SDK at the next IETF Hannes reviewed the published meeting agenda OAuth Device Flow specification Hannes described the specification Issue #1 is about polling The AS polls the device for the authorization co= de Hannes asked whether there are other ways to dea= l with this or whether polling is fine Aaron Parecki said that polling is simple William Denniss suggested also adding HTTP/2 lon= g-poll as an option Simon Moffatt said that the HTTP stack itself ma= y be too much Torsten Lodderstedt said that the OpenID MODRNA = WG is working on similar specs Hannes said that people appear to be happy enoug= h with polling Torsten: MODRNA is using polling for back-channe= l authentication Also for user consent There is not much implementation e= xperience yet Torsten asked whether there is sufficient implem= entation experience showing that polling works well enough William Dennis: We run this at large scale. Eve= ry YouTube TV app uses this. It works. John Bradley: Roland Hedberg has use cases in wh= ich identity proofing is interleaved and responses may be delayed Polling works well if the replies = come soon Leif Johansson: We could solve the long-response= time situations differently Identity proofing is a longer-live= d use case It's not reasonable to always assu= me that authentication is quick Hannes asked whether the long-latency authentica= tion use case might not be different than the device flow use case Justin Richer: The long polling use case might j= ust need a different flow Don't use the device flow in the "= three days later" use case John Bradley: I'm OK with that Hannes asked Leif to get together with Roland to= describe their use case Hannes: From this discussion, it's clear that we= go ahead with what we have now Issue #2 is about the user interface AS provides user code and verification URI to th= e user User enters these on a separate device What guidance can be given to improve the user i= nteraction and experience? Dick Hardt asked what the question is and said t= hat Amazon makes a number of devices Hannes got Dick to volunteer to write down some = user interface guidance Issue #3 is about alternative contact mechanisms In the current mechanism, the device shows the u= ser info that is entered in another place A possible alternative is for the user to enter = a phone number into the device client, which initiates an SMS sending a use= r code The user enters the user code This could make the experience eas= ier and faster Hannes: Should we document both methods or just= the current one? Or should the additional mechanism= be documented in a different specification? William Denniss: The protocol is the same so it= 's fine to describe this in the same specification John Bradley: There is an additional user hint = parameter It is close enough that we should = probably describe this in the Device Flow document Mike Jones: Asked whether there is deployment e= xperience with the second method John Bradley: I have seen it in the wild Phil Hunt: Asked whether sending people links sp= ontaneously to click on is training users in bad behaviors Torsten Lodderstedt: Repeated Mike's question. = Said that at the minimum, the security considerations would be different. Hannes will reach out asking for deployment expe= rience for the SMS method If there isn't deployment experien= ce, we shouldn't include it OAuth Authorization Server Metadata Hannes started WGLC earlier this year We got a bit stuck on this This led to a new document on Resource Metadata Hannes: In Berlin, there appeared to be consensus to proceed = with this work Hannes would like to get feedback on where we are with the wo= rk and how we should proceed The AS Metadata document makes the AS configuration informati= on available online in a JSON structure The Resource Metadata document does the same for protected re= sources Hannes: Should we publish one or both of these or should we d= o additional security work? Justin Richer: The AS Metadata document is very stable and w= idely used. We should publish it. Resource Metadata is a different beast. It's mo= re dynamic. Different kinds of APIs need different kinds of = resource discovery There are security considerations and subtle pri= vacy considerations with resource-first discovery We shouldn't conflate the two Tony Nadalin: I'm not sure the AS metadata document is accura= te enough to publish yet We have a multi-tenant system and AS metadata ab= out only a single tenant causes problems Tony is concerned that as we develop resource me= tadata it might result in changes to the AS metadata John Bradley: This document actually does deal with multi-te= nant situations We are not precluding multi-tenant situations I agree with Justin that resource metadata is mo= re complicated, since it relates closely to the protocol using OAuth Being able to describe the characteristics of th= e AS separately has value even without the resource metadata Other specs can deal with the problems with reso= urce discovery Trying to do it in metadata is the= wrong way to do it William Denniss: I see the AS metadata as being valuable. I= t improves security. There is a fair bit of proven deployment experie= nce William doesn't have an immediate use for resour= ce metadata Phil Hunt: His concern is that as we automate configuration = we make some things better both for the legitimate and for attackers He is concerned that clients could be convinced = to use an attacker's resource proxy Phil said that Mike Jones and he have been talki= ng and working on this The resource metadata makes things better in com= bination with the AS metadata Phil thinks that the two specs should be combine= d Phil is frustrated that there isn't a clear unde= rstanding of the problems or the solutions Phil said that Mike legitimately asked whether w= e are solving a problem that people want to deploy solutions to Phil asked whether there is willpo= wer to solve the problem Hannes asked Phil whether he thought both should= move forward Phil said that the most important thing is for p= eople to verify the relationships between the AS and resource Phil and Hannes talked about the proof-of-posses= sion and token binding work being related to this Hannes: People want to start with the simpler problem first = and then in a second phase, work on resource metadata Phil: It's important for the client to understand whether it= has a valid set of endpoints and how the client knows that We don't know whether to express this as metadat= a or in some other way Torsten: There is a need for automatic configuration to ASs He's not sure whether there's such a need for re= sources The AS metadata is mature and proven. I propose= that we move it forward. John Bradley: George Fletcher from AOL says that it's OK for= the client to specify what AS to use It's OK if the AS doesn't have a pre-existing re= lationship with the resource It's fine as long as the access token is audienc= ed in a way that the token can't be replayed at a different resource AS metadata is mature and ready for publication Resource metadata is not mature and not ready fo= r publication Brian Campbell and John did a draft allowing the= client to tell the AS where it plans to use the token draft-campbell-oauth-resource-indi= cators This enables the AS to audience re= strict the access token to the resource Phil Hunt: We should keep the audience restriction idea on t= he table Phil asked about combining the documents in response to Hanne= s formulating questions Hannes said that that's just a document manageme= nt issue. Hannes asked these questions: 1. Should we move forward with the AS metadata d= ocument as a standalone document? 8 in favor 2. Should we adopt the resource metadata documen= t? 2 in favor 3. Who thinks we should not adopt the resource = metadata document 4 against adoption 4. Should we work on a combined AS/RS document? 5 in favor 5. Should we stop work on metadata? 0 in favor William Denniss: I disagree that they go together. We need = the AS metadata now. We don't need the other now. They need not be linked Hannes: Who is deploying the AS metadata specification? The question got interrupted by clarification qu= estions Tony Nadalin: Microsoft uses it but it doesn't meet our needs= because it doesn't support multi-tenancy John Bradley: Microsoft publishes an AS metadata document per= tenant Multi-tenancy is more a discovery issue than a m= etadata issue Leif Johansson: Salesforce does the same thing - publishing a= metadata document per tenant Hannes: I am trying to determine deployment status Phil: You have to have a bootstrap process to determine the = AS to use William Dennis: Google has a real need that is solved by the = AS metadata spec Torsten: It's just a URL and you obtain the metadata from it.= There's no magic. It works very well. It helps with mix-up. Hannes asked: 6. Who has deployed or is planning to deploy AS= metadata? 9 7. Who has deployed or is planning to deploy re= source metadata? 1 Hannes: My sense is that we should proceed with the AS m= etadata I see people using it already I see people wanting it to progress it as a stan= dalone document For resource metadata, I think additional clarif= ication is needed before we work on it as a working group Kathleen Moriarty (Security Area Director): I agree with the= se conclusions OAuth 2.0 Token Binding Brian Campbell gave a presentation on the status of Token Bin= ding for OAuth 2.0 and OpenID Connect The current WG draft uses the referred token binding for toke= n binding access tokens Brian talked about how using the referred token binding for a= ccess tokens is conceptually the right thing But that there may be practical problems with do= ing this Brian is concerned about the HTTPSTB text about = "explicitly signaling" John Bradley (a TokBind chair): The current HTTP= STB text is focused on the redirect case There are also other use cases sup= ported by token binding We may have to refactor the curren= t text Dick Balfanz (HTTPSTB editor) said= that he was OK doing this The privacy principle is that unin= tended correlations not be created In the OAuth case, it's the client= who should be making this decision Brian asked Dirk if they could work on this text= together and Dirk agreed Brian is concerned that using the referred token binding coul= d be cumbersome in some cases For instance, clustered web server clients HTTPSTB has a SHOULD for an eTLD+1 scoping requirement This means that different access tokens would be= needed for resources not sharing an eTLD+1 This prevents token replay across resources not = sharing an eTLD+1 Torsten asked about the case in which resources = share keys Torsten said that they use audienc= ed access tokens - different access tokens are used at different resources John Bradley: Some of this may be platform-spec= ific In general, you're going to have t= o indicate which referred token binding to use If you have two different access t= okens, you should probably have different keys for them Ben Kaduk: You're right that if you already use= the same access token across sites, they would need to share token binding= keys Hannes: I'm concerned that some deployment patt= erns could lose some of the privacy properties of OAuth Justin Richer: My skepticism of the use of Toke= n Binding for OAuth is that it's designed for browser cookies OAuth access tokens aren't browser= cookies Clients tend not to think in terms= of domains they're calling - they think in terms of APIs providing functio= nality We are going to a world that's mor= e dynamic, which is a really hard nut to crack Justin pointed out that Google use= s both google.com and googleapis.com There are up to 5 TLS connections = that are involved in some OAuth flows This is a very diffe= rent world than the browser case It works well for ID Tokens in the= implicit flow and refresh tokens at the Token Endpoint But it doesn't match= access token usage Brian: Ideally the client developer isn't going= to have to know about these things If you use the same key, it just w= orks Justin: What problem are we trying to solve? A= udience restriction or presentation restriction? Brian: Both Tony Nadalin: I am concerned about the browser = situation John Bradley: We still have some questions abou= t JavaScript in the browser using fetch eTLD+1 is still appropriate for th= at use case Brian: I am not proposing a change to token bin= ding William Dennis: I agree that access tokens are = somewhat tricky The token binding gives us more be= nefits than it adds in complexity Brian: It makes sense to try to take advantage = of what token binding provides Andrei Popov: The tokens should be scoped no br= oader than the keys are scoped The OAuth token binding specificat= ion could live at the same level as the HTTPSTB specification John Bradley: The data structures are defined i= n the HTTPSTB specification Things building on HTTPSTB makes m= ore sense than repeating most of HTTPSTB in other specifications Torsten: Things can get tricky for access token= s. Refresh tokens could get tricky as well. John: The client being a cluster can make thing= s tricky Torsten: Developers need to consider which acce= ss tokens to use at which resources Reusing things all over rightly ma= kes privacy people nervous Is there any deployment experience= ? Mike Jones: Microsoft internally has deployed s= omething with the same semantics but different syntax Dick Hardt: Wants to enable refresh token to be= token bound without requiring access tokens be token bound John: Nothing stops people from doing refresh t= okens now, because it doesn't actually have to be interoperable William Denniss: We see a lot of value in prote= cting the refresh token. Google is moving forward with that. Dirk Balfanz: We are removing explicit mentions= of the key and always using the referred token binding Brian: Where referred is possible, always use r= eferred. Otherwise, use explicit. John: We tried to have only one way to do thing= s for each leg You can provide two different toke= n bindings for different legs - one referred and one provided This is being done in the next doc= ument revision Token binding for authorization codes is still TBD Brian asked whether double binding (as described= in a doc by Dirk Balfanz before Berlin) is necessary Brian presented a strawman for authorization cod= e token binding It uses PKCE with a code_challenge= value that is a hash of the provided token binding ID It uses a new code_challenge_metho= d value The code_verifier is the provided = token binding ID Binds the code to the channel between the browse= r and the client Brian proposed different methods for the native = app and browser client cases Some of this was based on the prop= osal that Dirk wrote prior to Berlin The two methods are appropriate fo= r different kinds of clients Torsten: Asked which is easier to implement John: In OAuth, there is no signed response In OpenID Connect, we can put it i= n the ID Token, which is signed The second method for browsers avo= ids having to have a signed response Dirk: The double binding isn't needed Token Binding Metadata presented The resource metadata now may be in question Talked about phasing in Token Binding and detect= ing downgrade attacks It's more subtle than just "suppor= ts" - it also includes all participants supporting the same cryptographic a= lgorithms The Boolean metadata values may not be granular = enough to actually express all the information needed Support may be dependent upon platform features = as well Next steps Resolve conflict with wording in HTTPSTB Add token binding for authorization codes Flesh out or back off metadata and downgrade det= ection logic Hannes: We should work on getting implementation experience OAuth 2.0 Token Exchange Brian Campbell presented on the current Token Exchange status Relatively minor changes were made last month The want_composite request parameter was removed It's ultimately up to the AS what = to issue Added a short mention of PoP Torsten: The current version is really light-weight What I'm missing is a description of the relatio= nship between audience, resource, and scopes Brian: I'm not sure how to do that Torsten agreed to help Brian with wording Tony Nadalin: We've been going through this doc with the deve= lopers at Microsoft Tony has asked them to describe their use cases = and what is needed for them Their feedback is expected this we= ek The Microsoft developers are having problems map= ping the current document to their needs John Bradley: Should we reconstitute the stand-alone resourc= e specification? Hannes: That's a brilliant idea William Denniss: I agree with Tony. I'd like to get a few i= mplementations done in the next year. It's valuable to prove it out with some implemen= tations Justin Richer: We will eventually implement this I agree that more implementation experience will= be good for this Developers are there and ready to try this out Talked about the relationships between scopes, r= esources, and audiences Torsten: The use case of being able to indicate the resource= is very relevant for every client John: We're seeing the development of general-purpose APIs This was not initially imagined when OAuth was d= eveloped This means that we'll have scopes used across co= ntexts This is part of OAuth growing up I'm getting questions from customers about why T= oken Exchange isn't done yet Torsten: We didn't move the resource spec forward before bec= ause resources without scopes don't make sense There is implementation experience at Deutsche T= elekom with combining resources and scopes John: Torsten is right that people do horrible things creati= ng structured scopes with key-value pairs that aren't interoperable I suggest adopting the resource document as a st= arting point to have these more general discussions Hannes: We will discuss the resource indicator topic at our = next session on Wednesday We should give it another try --_000_BN3PR03MB2355F2647C7FB9A1BA94F4D6F5BC0BN3PR03MB2355namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hannes gave an OAuth WG status update

        &nbs= p;     AMR Values spec sent to the IESG

        &nbs= p;     Request by JWS spec sent to the IESG<= /p>

        &nbs= p;     Native apps specification

        &nbs= p;            &= nbsp;     Recently updated to make it more readable

        &nbs= p;            &= nbsp;     Hannes is working on a shepherd update

        &nbs= p;            &= nbsp;     John Bradley said that some minor updates to = the Windows Universal Platform language are being done

        &nbs= p;            &= nbsp;     It’s nearly done.  People are requ= ested to provide feedback.

        &nbs= p;            &= nbsp;     People are using an SDK embodying this specif= ication that was published by the OpenID Connect working group

        &nbs= p;            &= nbsp;     The spec is a BCP that we can revise as neede= d

        &nbs= p;            &= nbsp;     Hannes suggested that a tutorial be done on h= ow to use the SDK at the next IETF

 

Hannes reviewed the published meeting agenda

 

OAuth Device Flow specification

        &nbs= p;     Hannes described the specification

        &nbs= p;     Issue #1 is about polling

        &nbs= p;            &= nbsp;     The AS polls the device for the authorization= code

        &nbs= p;            &= nbsp;     Hannes asked whether there are other ways to = deal with this or whether polling is fine

        &nbs= p;            &= nbsp;     Aaron Parecki said that polling is simple

        &nbs= p;            &= nbsp;     William Denniss suggested also adding HTTP/2 = long-poll as an option

        &nbs= p;            &= nbsp;     Simon Moffatt said that the HTTP stack itself= may be too much

        &nbs= p;            &= nbsp;     Torsten Lodderstedt said that the OpenID MODR= NA WG is working on similar specs

        &nbs= p;            &= nbsp;     Hannes said that people appear to be happy en= ough with polling

        &nbs= p;            &= nbsp;     Torsten: MODRNA is using polling for back-cha= nnel authentication

        &nbs= p;            &= nbsp;           &nbs= p;       Also for user consent

        &nbs= p;            &= nbsp;           &nbs= p;       There is not much implementation exp= erience yet

        &nbs= p;            &= nbsp;     Torsten asked whether there is sufficient imp= lementation experience showing that polling works well enough

        &nbs= p;            &= nbsp;     William Dennis: We run this at large scale.&n= bsp; Every YouTube TV app uses this.  It works.

        &nbs= p;            &= nbsp;     John Bradley: Roland Hedberg has use cases in= which identity proofing is interleaved and responses may be delayed

        &nbs= p;            &= nbsp;           &nbs= p;       Polling works well if the replies co= me soon

        &nbs= p;            &= nbsp;     Leif Johansson: We could solve the long-respo= nse time situations differently

        &nbs= p;            &= nbsp;           &nbs= p;       Identity proofing is a longer-lived = use case

        &nbs= p;            &= nbsp;           &nbs= p;       It’s not reasonable to always = assume that authentication is quick

        &nbs= p;            &= nbsp;     Hannes asked whether the long-latency authent= ication use case might not be different than the device flow use case<= /o:p>

        &nbs= p;            &= nbsp;     Justin Richer: The long polling use case migh= t just need a different flow

        &nbs= p;            &= nbsp;           &nbs= p;       Don’t use the device flow in t= he “three days later” use case

        &nbs= p;            &= nbsp;     John Bradley: I’m OK with that

        &nbs= p;            &= nbsp;     Hannes asked Leif to get together with Roland= to describe their use case

        &nbs= p;            &= nbsp;     Hannes: From this discussion, it’s clea= r that we go ahead with what we have now

        &nbs= p;     Issue #2 is about the user interface<= /p>

        &nbs= p;            &= nbsp;     AS provides user code and verification URI to= the user

        &nbs= p;            &= nbsp;     User enters these on a separate device

        &nbs= p;            &= nbsp;     What guidance can be given to improve the use= r interaction and experience?

        &nbs= p;            &= nbsp;     Dick Hardt asked what the question is and sai= d that Amazon makes a number of devices

        &nbs= p;            &= nbsp;     Hannes got Dick to volunteer to write down so= me user interface guidance

        &nbs= p;     Issue #3 is about alternative contact mechanisms=

        &nbs= p;            &= nbsp;     In the current mechanism, the device shows th= e user info that is entered in another place

        &nbs= p;            &= nbsp;     A possible alternative is for the user to ent= er a phone number into the device client, which initiates an SMS sending a = user code

        &nbs= p;            &= nbsp;           &nbs= p;       The user enters the user code

        &nbs= p;            &= nbsp;           &nbs= p;       This could make the experience easie= r and faster

        &nbs= p;            &= nbsp;     Hannes:  Should we document both methods= or just the current one?

        &nbs= p;            &= nbsp;            &nb= sp;      Or should the additional mechanism be doc= umented in a different specification?

        &nbs= p;            &= nbsp;     William Denniss:  The protocol is the sa= me so it’s fine to describe this in the same specification=

        &nbs= p;            &= nbsp;     John Bradley:  There is an additional us= er hint parameter

        &nbs= p;            &= nbsp;           &nbs= p;       It is close enough that we should pr= obably describe this in the Device Flow document

        &nbs= p;            &= nbsp;     Mike Jones:  Asked whether there is depl= oyment experience with the second method

        &nbs= p;            &= nbsp;     John Bradley:  I have seen it in the wil= d

        &nbs= p;            &= nbsp;     Phil Hunt: Asked whether sending people links= spontaneously to click on is training users in bad behaviors

        &nbs= p;            &= nbsp;     Torsten Lodderstedt: Repeated Mike’s qu= estion.  Said that at the minimum, the security considerations would b= e different.

        &nbs= p;            &= nbsp;     Hannes will reach out asking for deployment e= xperience for the SMS method

        &nbs= p;            &= nbsp;           &nbs= p;       If there isn’t deployment expe= rience, we shouldn’t include it

 

OAuth Authorization Server Metadata

        &nbs= p;     Hannes started WGLC earlier this year=

        &nbs= p;            &= nbsp;     We got a bit stuck on this

        &nbs= p;     This led to a new document on Resource Metadata<= o:p>

        &nbs= p;     Hannes: In Berlin, there appeared to be consensu= s to proceed with this work

        &nbs= p;     Hannes would like to get feedback on where we ar= e with the work and how we should proceed

        &nbs= p;     The AS Metadata document makes the AS configurat= ion information available online in a JSON structure

        &nbs= p;     The Resource Metadata document does the same for= protected resources

        &nbs= p;     Hannes: Should we publish one or both of these o= r should we do additional security work?

        &nbs= p;     Justin Richer:  The AS Metadata document is= very stable and widely used.  We should publish it.

        &nbs= p;            &= nbsp;     Resource Metadata is a different beast. = It’s more dynamic.

        &nbs= p;            &= nbsp;     Different kinds of APIs need different kinds = of resource discovery

        &nbs= p;            &= nbsp;     There are security considerations and subtle = privacy considerations with resource-first discovery

        &nbs= p;            &= nbsp;     We shouldn’t conflate the two

        &nbs= p;     Tony Nadalin: I’m not sure the AS metadata= document is accurate enough to publish yet

        &nbs= p;            &= nbsp;     We have a multi-tenant system and AS metadata= about only a single tenant causes problems

        &nbs= p;            &= nbsp;     Tony is concerned that as we develop resource= metadata it might result in changes to the AS metadata

        &nbs= p;     John Bradley:  This document actually does = deal with multi-tenant situations

        &nbs= p;            &= nbsp;     We are not precluding multi-tenant situations=

        &nbs= p;            &= nbsp;     I agree with Justin that resource metadata is= more complicated, since it relates closely to the protocol using OAuth

        &nbs= p;            &= nbsp;     Being able to describe the characteristics of= the AS separately has value even without the resource metadata<= /p>

        &nbs= p;            &= nbsp;     Other specs can deal with the problems with r= esource discovery

        &nbs= p;            &= nbsp;           &nbs= p;       Trying to do it in metadata is the w= rong way to do it

        &nbs= p;     William Denniss:  I see the AS metadata as = being valuable.  It improves security.

        &nbs= p;            &= nbsp;     There is a fair bit of proven deployment expe= rience

        &nbs= p;            &= nbsp;     William doesn’t have an immediate use f= or resource metadata

        &nbs= p;     Phil Hunt:  His concern is that as we autom= ate configuration we make some things better both for the legitimate and fo= r attackers

        &nbs= p;            &= nbsp;     He is concerned that clients could be convinc= ed to use an attacker’s resource proxy

        &nbs= p;            &= nbsp;     Phil said that Mike Jones and he have been ta= lking and working on this

        &nbs= p;            &= nbsp;     The resource metadata makes things better in = combination with the AS metadata

        &nbs= p;            &= nbsp;     Phil thinks that the two specs should be comb= ined

        &nbs= p;            &= nbsp;     Phil is frustrated that there isn’t a c= lear understanding of the problems or the solutions

        &nbs= p;            &= nbsp;     Phil said that Mike legitimately asked whethe= r we are solving a problem that people want to deploy solutions to

        &nbs= p;            &= nbsp;           &nbs= p;       Phil asked whether there is willpowe= r to solve the problem

        &nbs= p;            &= nbsp;     Hannes asked Phil whether he thought both sho= uld move forward

        &nbs= p;            &= nbsp;     Phil said that the most important thing is fo= r people to verify the relationships between the AS and resource=

        &nbs= p;            &= nbsp;     Phil and Hannes talked about the proof-of-pos= session and token binding work being related to this

        &nbs= p;     Hannes:  People want to start with the simp= ler problem first and then in a second phase, work on resource metadata

        &nbs= p;     Phil:  It’s important for the client = to understand whether it has a valid set of endpoints and how the client kn= ows that

        &nbs= p;            &= nbsp;     We don’t know whether to express this a= s metadata or in some other way

        &nbs= p;     Torsten:  There is a need for automatic con= figuration to ASs

        &nbs= p;            &= nbsp;     He’s not sure whether there’s suc= h a need for resources

        &nbs= p;            &= nbsp;     The AS metadata is mature and proven.  I= propose that we move it forward.

        &nbs= p;     John Bradley:  George Fletcher from AOL say= s that it’s OK for the client to specify what AS to use

        &nbs= p;            &= nbsp;     It’s OK if the AS doesn’t have a = pre-existing relationship with the resource

        &nbs= p;            &= nbsp;     It’s fine as long as the access token i= s audienced in a way that the token can’t be replayed at a different = resource

        &nbs= p;            &= nbsp;     AS metadata is mature and ready for publicati= on

        &nbs= p;            &= nbsp;     Resource metadata is not mature and not ready= for publication

        &nbs= p;            &= nbsp;     Brian Campbell and John did a draft allowing = the client to tell the AS where it plans to use the token

        &nbs= p;            &= nbsp;           &nbs= p;       draft-campbell-oauth-resource-indica= tors

        &nbs= p;            &= nbsp;           &nbs= p;       This enables the AS to audience rest= rict the access token to the resource

        &nbs= p;     Phil Hunt:  We should keep the audience res= triction idea on the table

 

        &nbs= p;     Phil asked about combining the documents in resp= onse to Hannes formulating questions

        &nbs= p;            &= nbsp;     Hannes said that that’s just a document= management issue.

 

        &nbs= p;     Hannes asked these questions:

        &nbs= p;            &= nbsp;     1. Should we move forward with the AS metadat= a document as a standalone document?

        &nbs= p;            &= nbsp;           &nbs= p;       8 in favor

        &nbs= p;            &= nbsp;     2. Should we adopt the resource metadata docu= ment?

        &nbs= p;            &= nbsp;           &nbs= p;       2 in favor

        &nbs= p;            &= nbsp;     3.  Who thinks we should not adopt the r= esource metadata document

        &nbs= p;            &= nbsp;           &nbs= p;       4 against adoption

        &nbs= p;            &= nbsp;     4.  Should we work on a combined AS/RS d= ocument?

        &nbs= p;            &= nbsp;           &nbs= p;       5 in favor

        &nbs= p;            &= nbsp;     5.  Should we stop work on metadata?

        &nbs= p;            &= nbsp;           &nbs= p;       0 in favor

 

        &nbs= p;     William Denniss:  I disagree that they go t= ogether.  We need the AS metadata now.  We don’t need the o= ther now.

        &nbs= p;             =       They need not be linked

 

        &nbs= p;     Hannes: Who is deploying the AS metadata specifi= cation?

        &nbs= p;            &= nbsp;     The question got interrupted by clarification= questions

        &nbs= p;     Tony Nadalin: Microsoft uses it but it doesnR= 17;t meet our needs because it doesn’t support multi-tenancy

        &nbs= p;     John Bradley: Microsoft publishes an AS metadata= document per tenant

        &nbs= p;            &= nbsp;     Multi-tenancy is more a discovery issue than = a metadata issue

        &nbs= p;     Leif Johansson: Salesforce does the same thing &= #8211; publishing a metadata document per tenant

        &nbs= p;     Hannes: I am trying to determine deployment stat= us

        &nbs= p;     Phil:  You have to have a bootstrap process= to determine the AS to use

        &nbs= p;     William Dennis: Google has a real need that is s= olved by the AS metadata spec

        &nbs= p;     Torsten: It’s just a URL and you obtain th= e metadata from it.  There’s no magic.  It works very well.=   It helps with mix-up.

 

        &nbs= p;     Hannes asked:

        &nbs= p;            &= nbsp;     6.  Who has deployed or is planning to d= eploy AS metadata?

        &nbs= p;            &= nbsp;           &nbs= p;       9

        &nbs= p;            &= nbsp;     7.  Who has deployed or is planning to d= eploy resource metadata?

        &nbs= p;            &= nbsp;           &nbs= p;       1

 

        &nbs= p;     Hannes:

        &nbs= p;            &= nbsp;     My sense is that we should proceed with the A= S metadata

        &nbs= p;            &= nbsp;     I see people using it already

        &nbs= p;            &= nbsp;     I see people wanting it to progress it as a s= tandalone document

        &nbs= p;            &= nbsp;     For resource metadata, I think additional cla= rification is needed before we work on it as a working group

        &nbs= p;     Kathleen Moriarty (Security Area Director): = ; I agree with these conclusions

 

OAuth 2.0 Token Binding

        &nbs= p;     Brian Campbell gave a presentation on the status= of Token Binding for OAuth 2.0 and OpenID Connect

        &nbs= p;     The current WG draft uses the referred token bin= ding for token binding access tokens

        &nbs= p;     Brian talked about how using the referred token = binding for access tokens is conceptually the right thing

        &nbs= p;            &= nbsp;     But that there may be practical problems with= doing this

        &nbs= p;            &= nbsp;     Brian is concerned about the HTTPSTB text abo= ut “explicitly signaling”

        &nbs= p;            &= nbsp;     John Bradley (a TokBind chair): The current H= TTPSTB text is focused on the redirect case

        &nbs= p;            &= nbsp;           &nbs= p;       There are also other use cases suppo= rted by token binding

        &nbs= p;            &= nbsp;           &nbs= p;       We may have to refactor the current = text

        &nbs= p;            &= nbsp;           &nbs= p;       Dick Balfanz (HTTPSTB editor) said t= hat he was OK doing this

        &nbs= p;            &= nbsp;           &nbs= p;       The privacy principle is that uninte= nded correlations not be created

        &nbs= p;            &= nbsp;           &nbs= p;       In the OAuth case, it’s the cl= ient who should be making this decision

        &nbs= p;            &= nbsp;     Brian asked Dirk if they could work on this t= ext together and Dirk agreed

        &nbs= p;     Brian is concerned that using the referred token= binding could be cumbersome in some cases

        &nbs= p;            &= nbsp;     For instance, clustered web server clients

        &nbs= p;     HTTPSTB has a SHOULD for an eTLD+1 scoping r= equirement

        &nbs= p;            &= nbsp;     This means that different access tokens would= be needed for resources not sharing an eTLD+1

        &nbs= p;            &= nbsp;     This prevents token replay across resources n= ot sharing an eTLD+1

        &nbs= p;            &= nbsp;     Torsten asked about the case in which resourc= es share keys

        &nbs= p;            &= nbsp;           &nbs= p;       Torsten said that they use audienced= access tokens – different access tokens are used at different resour= ces

        &nbs= p;            &= nbsp;     John Bradley:  Some of this may be platf= orm-specific

        &nbs= p;            &= nbsp;           &nbs= p;       In general, you’re going to ha= ve to indicate which referred token binding to use

        &nbs= p;            &= nbsp;           &nbs= p;       If you have two different access tok= ens, you should probably have different keys for them

        &nbs= p;            &= nbsp;     Ben Kaduk:  You’re right that if y= ou already use the same access token across sites, they would need to share= token binding keys

        &nbs= p;            &= nbsp;     Hannes:  I’m concerned that some d= eployment patterns could lose some of the privacy properties of OAuth<= /o:p>

        &nbs= p;            &= nbsp;     Justin Richer:  My skepticism of the use= of Token Binding for OAuth is that it’s designed for browser cookies=

        &nbs= p;            &= nbsp;           &nbs= p;       OAuth access tokens aren’t bro= wser cookies

        &nbs= p;            &= nbsp;           &nbs= p;       Clients tend not to think in terms o= f domains they’re calling – they think in terms of APIs providi= ng functionality

        &nbs= p;            &= nbsp;           &nbs= p;       We are going to a world that’s= more dynamic, which is a really hard nut to crack

        &nbs= p;            &= nbsp;           &nbs= p;       Justin pointed out that Google uses = both google.com and googleapis.com

        &nbs= p;            &= nbsp;           &nbs= p;       There are up to 5 TLS connections th= at are involved in some OAuth flows

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        This is a very different wo= rld than the browser case

        &nbs= p;            &= nbsp;           &nbs= p;       It works well for ID Tokens in the i= mplicit flow and refresh tokens at the Token Endpoint

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        But it doesn’t match = access token usage

        &nbs= p;            &= nbsp;     Brian:  Ideally the client developer isn= ’t going to have to know about these things

        &nbs= p;            &= nbsp;           &nbs= p;       If you use the same key, it just wor= ks

        &nbs= p;            &= nbsp;     Justin:  What problem are we trying to s= olve?  Audience restriction or presentation restriction?

        &nbs= p;            &= nbsp;     Brian:  Both

        &nbs= p;            &= nbsp;     Tony Nadalin:  I am concerned about the = browser situation

        &nbs= p;            &= nbsp;     John Bradley:  We still have some questi= ons about JavaScript in the browser using fetch

        &nbs= p;            &= nbsp;           &nbs= p;       eTLD+1 is still appropriate for = that use case

        &nbs= p;            &= nbsp;     Brian:  I am not proposing a change to t= oken binding

        &nbs= p;            &= nbsp;     William Dennis:  I agree that access tok= ens are somewhat tricky

        &nbs= p;            &= nbsp;           &nbs= p;       The token binding gives us more bene= fits than it adds in complexity

        &nbs= p;            &= nbsp;     Brian:  It makes sense to try to take ad= vantage of what token binding provides

        &nbs= p;            &= nbsp;     Andrei Popov:  The tokens should be scop= ed no broader than the keys are scoped

        &nbs= p;            &= nbsp;           &nbs= p;       The OAuth token binding specificatio= n could live at the same level as the HTTPSTB specification

        &nbs= p;            &= nbsp;     John Bradley:  The data structures are d= efined in the HTTPSTB specification

        &nbs= p;            &= nbsp;           &nbs= p;       Things building on HTTPSTB makes mor= e sense than repeating most of HTTPSTB in other specifications

        &nbs= p;            &= nbsp;     Torsten:  Things can get tricky for acce= ss tokens.  Refresh tokens could get tricky as well.

        &nbs= p;            &= nbsp;     John:  The client being a cluster can ma= ke things tricky

        &nbs= p;            &= nbsp;     Torsten:  Developers need to consider wh= ich access tokens to use at which resources

        &nbs= p;            &= nbsp;           &nbs= p;       Reusing things all over rightly make= s privacy people nervous

        &nbs= p;            &= nbsp;           &nbs= p;       Is there any deployment experience?<= o:p>

        &nbs= p;            &= nbsp;     Mike Jones:  Microsoft internally has de= ployed something with the same semantics but different syntax

        &nbs= p;            &= nbsp;     Dick Hardt:  Wants to enable refresh tok= en to be token bound without requiring access tokens be token bound

        &nbs= p;            &= nbsp;     John:  Nothing stops people from doing r= efresh tokens now, because it doesn’t actually have to be interoperab= le

        &nbs= p;            &= nbsp;     William Denniss:  We see a lot of value = in protecting the refresh token.  Google is moving forward with that.<= o:p>

        &nbs= p;            &= nbsp;     Dirk Balfanz:  We are removing explicit = mentions of the key and always using the referred token binding<= /p>

        &nbs= p;            &= nbsp;     Brian:  Where referred is possible, alwa= ys use referred.  Otherwise, use explicit.

        &nbs= p;            &= nbsp;     John:  We tried to have only one way to = do things for each leg

        &nbs= p;            &= nbsp;           &nbs= p;       You can provide two different token = bindings for different legs – one referred and one provided

        &nbs= p;            &= nbsp;           &nbs= p;       This is being done in the next docum= ent revision

 

        &nbs= p;     Token binding for authorization codes is still T= BD

        &nbs= p;            &= nbsp;     Brian asked whether double binding (as descri= bed in a doc by Dirk Balfanz before Berlin) is necessary

        &nbs= p;            &= nbsp;     Brian presented a strawman for authorization = code token binding

        &nbs= p;            &= nbsp;           &nbs= p;       It uses PKCE with a code_challenge v= alue that is a hash of the provided token binding ID

        &nbs= p;            &= nbsp;           &nbs= p;       It uses a new code_challenge_method = value

        &nbs= p;            &= nbsp;           &nbs= p;       The code_verifier is the provided to= ken binding ID

        &nbs= p;            &= nbsp;     Binds the code to the channel between the bro= wser and the client

        &nbs= p;            &= nbsp;     Brian proposed different methods for the nati= ve app and browser client cases

        &nbs= p;            &= nbsp;           &nbs= p;       Some of this was based on the propos= al that Dirk wrote prior to Berlin

        &nbs= p;            &= nbsp;           &nbs= p;       The two methods are appropriate for = different kinds of clients

        &nbs= p;            &= nbsp;     Torsten:  Asked which is easier to imple= ment

        &nbs= p;            &= nbsp;     John:  In OAuth, there is no signed resp= onse

        &nbs= p;            &= nbsp;           &nbs= p;       In OpenID Connect, we can put it in = the ID Token, which is signed

        &nbs= p;            &= nbsp;           &nbs= p;       The second method for browsers avoid= s having to have a signed response

        &nbs= p;            &= nbsp;     Dirk:  The double binding isn’t ne= eded

 

        &nbs= p;     Token Binding Metadata presented

        &nbs= p;            &= nbsp;     The resource metadata now may be in question<= o:p>

        &nbs= p;            &= nbsp;     Talked about phasing in Token Binding and det= ecting downgrade attacks

        &nbs= p;            &= nbsp;           &nbs= p;       It’s more subtle than just = 220;supports” – it also includes all participants supporting th= e same cryptographic algorithms

        &nbs= p;            &= nbsp;     The Boolean metadata values may not be granul= ar enough to actually express all the information needed

        &nbs= p;            &= nbsp;     Support may be dependent upon platform featur= es as well

 

        &nbs= p;     Next steps

        &nbs= p;            &= nbsp;     Resolve conflict with wording in HTTPSTB=

        &nbs= p;            &= nbsp;     Add token binding for authorization codes

        &nbs= p;            &= nbsp;     Flesh out or back off metadata and downgrade = detection logic

 

        &nbs= p;     Hannes: We should work on getting implementation= experience

 

OAuth 2.0 Token Exchange

        &nbs= p;     Brian Campbell presented on the current Token Ex= change status

        &nbs= p;     Relatively minor changes were made last month

        &nbs= p;            &= nbsp;     The want_composite request parameter was remo= ved

        &nbs= p;            &= nbsp;           &nbs= p;       It’s ultimately up to the AS w= hat to issue

        &nbs= p;            &= nbsp;     Added a short mention of PoP

        &nbs= p;     Torsten:  The current version is really lig= ht-weight

        &nbs= p;            &= nbsp;     What I’m missing is a description of th= e relationship between audience, resource, and scopes

        &nbs= p;     Brian:  I’m not sure how to do that

        &nbs= p;     Torsten agreed to help Brian with wording

        &nbs= p;     Tony Nadalin: We’ve been going through thi= s doc with the developers at Microsoft

        &nbs= p;            &= nbsp;     Tony has asked them to describe their use cas= es and what is needed for them

        &nbs= p;            &= nbsp;           &nbs= p;       Their feedback is expected this week=

        &nbs= p;            &= nbsp;     The Microsoft developers are having problems = mapping the current document to their needs

        &nbs= p;     John Bradley:  Should we reconstitute the s= tand-alone resource specification?

        &nbs= p;            &= nbsp;     Hannes:  That’s a brilliant idea

        &nbs= p;     William Denniss:  I agree with Tony.  = I’d like to get a few implementations done in the next year.

        &nbs= p;            &= nbsp;     It’s valuable to prove it out with some= implementations

        &nbs= p;     Justin Richer:  We will eventually implemen= t this

        &nbs= p;            &= nbsp;     I agree that more implementation experience w= ill be good for this

        &nbs= p;            &= nbsp;     Developers are there and ready to try this ou= t

        &nbs= p;            &= nbsp;     Talked about the relationships between scopes= , resources, and audiences

        &nbs= p;     Torsten:  The use case of being able to ind= icate the resource is very relevant for every client

        &nbs= p;     John:  We’re seeing the development o= f general-purpose APIs

        &nbs= p;            &= nbsp;     This was not initially imagined when OAuth wa= s developed

        &nbs= p;            &= nbsp;     This means that we’ll have scopes used = across contexts

        &nbs= p;            &= nbsp;     This is part of OAuth growing up

        &nbs= p;            &= nbsp;     I’m getting questions from customers ab= out why Token Exchange isn’t done yet

        &nbs= p;     Torsten:  We didn’t move the resource= spec forward before because resources without scopes don’t make sens= e

        &nbs= p;            &= nbsp;     There is implementation experience at Deutsch= e Telekom with combining resources and scopes

        &nbs= p;     John:  Torsten is right that people do horr= ible things creating structured scopes with key-value pairs that aren’= ;t interoperable

        &nbs= p;            &= nbsp;     I suggest adopting the resource document as a= starting point to have these more general discussions

        &nbs= p;     Hannes:  We will discuss the resource indic= ator topic at our next session on Wednesday

        &nbs= p;            &= nbsp;     We should give it another try

 

--_000_BN3PR03MB2355F2647C7FB9A1BA94F4D6F5BC0BN3PR03MB2355namp_-- From nobody Sun Nov 13 23:22:58 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A249128874; Sun, 13 Nov 2016 23:22:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147910817342.27856.14741759375499641940.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 23:22:53 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-amr-values-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 07:22:53 -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 of the IETF. Title : Authentication Method Reference Values Authors : Michael B. Jones Phil Hunt Anthony Nadalin Filename : draft-ietf-oauth-amr-values-04.txt Pages : 13 Date : 2016-11-13 Abstract: The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-amr-values-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-amr-values-04 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 Sun Nov 13 23:27:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B1F12954E for ; Sun, 13 Nov 2016 23:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6SdYMfBwm9I for ; Sun, 13 Nov 2016 23:27:22 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0127.outbound.protection.outlook.com [104.47.41.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B241129415 for ; Sun, 13 Nov 2016 23:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gkzxmNcVHUBKqoVHDstx86MVfErfUimh1551h1EuDR0=; b=mASEkai0+2EM9Tp/uwhxZdt0dOiWDOwkTEBYS99m78YfO3vg9RPEqB7E1Ho3EjDCynskcpRwv/fzMEU2BKbbrDUBKgAvuFubTpmcT9CU88I+RkwBjbUEEllSz/JHoqsfviP97zGxnfDPs9GU+BXgmywaAPvbuupMZnOsDsL1h2k= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Mon, 14 Nov 2016 07:27:17 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0721.015; Mon, 14 Nov 2016 07:27:17 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: =?Windows-1252?Q?=93amr=94_Values_specification_addressing_area_director_?= =?Windows-1252?Q?comments?= Thread-Index: AdI+RPl5sFlAkle3SfCPM1tej3BFVQ== Date: Mon, 14 Nov 2016 07:27:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:67c:370:128:dca7:1fb6:1ff6:f5d3] x-microsoft-exchange-diagnostics: 1; BN3PR03MB2355; 7:ywTsOfbu+nvPqUQnyqCG0GbgihsHCOia4SKkG3Pq9Pow78Nm9fJuzxOBn2Nd1k30zrrUR+4+UFBXPYHJRPoo7NNChMfa23DpVP61mwZQAPk5wQzaS+v3UAq9LE7HvcbSUmPL0zw6voL4X55Wz9lnmOnM/IT+rkeugvzim1+jFWbcigPBXYBK/+Y02/E56N/7zLqSUDpm5ud01x68sqrsTCu2begCT1ClUrCvLwTyRujPNjsbJ1FW/veCbtNRRHJaepJVS9BVpycUES35wdsy+Yltl4/En/W0eVzJnN/kPkoD9JQ/B/L0kfiDFSW43sttWRFz/pu5ph/6PL6D0NdQJcDyodqy9JXWoGgHcn+sY2uJpShSMhrHBK6nX/chCNP+ x-ms-office365-filtering-correlation-id: 36e6b604-a216-4550-9c74-08d40c5fa992 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2355; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060324)(6045074)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6061318); SRVR:BN3PR03MB2355; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2355; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(336003)(199003)(189002)(81166006)(1730700003)(8936002)(101416001)(122556002)(77096005)(99286002)(81156014)(2351001)(86612001)(86362001)(5630700001)(106356001)(33656002)(92566002)(68736007)(2900100001)(74316002)(7906003)(7846002)(7736002)(97736004)(189998001)(10290500002)(5005710100001)(9686002)(8990500004)(10090500001)(107886002)(105586002)(3280700002)(87936001)(2906002)(5640700001)(110136003)(586003)(7696004)(54356999)(50986999)(5660300001)(6116002)(790700001)(76576001)(102836003)(3660700001)(2501003)(6916009)(450100001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2355; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB2355F7434CE53FDF7007AA1BF5BC0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 07:27:17.1986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2355 Archived-At: Subject: [OAUTH-WG] =?windows-1252?q?=93amr=94_Values_specification_addres?= =?windows-1252?q?sing_area_director_comments?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 07:27:24 -0000 --_000_BN3PR03MB2355F7434CE53FDF7007AA1BF5BC0BN3PR03MB2355namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Draft -04 of the Authentication Method Reference Values specification addre= sses comments by our security area director Kathleen Moriarty. Changes wer= e: =B7 Added =93amr=94 claim examples with both single and multiple valu= es. =B7 Clarified that the actual credentials referenced are not part of = this specification to avoid additional privacy concerns for biometric data. =B7 Clarified that the OAuth 2.0 Threat Model [RFC6819] applies to ap= plications using this specification. The specification is available at: =B7 http://tools.ietf.org/html/draft-ietf-oauth-amr-values-04 An HTML-formatted version is also available at: =B7 http://self-issued.info/docs/draft-ietf-oauth-amr-values-04.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1617 and = as @selfissued. --_000_BN3PR03MB2355F7434CE53FDF7007AA1BF5BC0BN3PR03MB2355namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Draft -04 of the Authentication Method Reference Val= ues specification addresses comments by our security area director Kathleen= Moriarty.  Changes were:

=B7       Added =93amr=94 claim examples with both single and multiple= values.

=B7       Clarified that the actual credentials refere= nced are not part of this specification to avoid additional privacy concern= s for biometric data.

=B7       Clarified that the OAuth 2.0 Threat Model [R= FC6819] applies to applications using this specification.

 

The specification is available at:

=B7       http://tools.ietf.org/html/draft-ietf-oauth-amr-v= alues-04

 

An HTML-formatted version is also available at:=

=B7       http://self-issued.info/docs/draft-ietf-oa= uth-amr-values-04.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1617 and as @selfissued.

 

--_000_BN3PR03MB2355F7434CE53FDF7007AA1BF5BC0BN3PR03MB2355namp_-- From nobody Sun Nov 13 23:29:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6DA1295EC for ; Sun, 13 Nov 2016 23:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX9m-b9qM_X1 for ; Sun, 13 Nov 2016 23:29:24 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0120.outbound.protection.outlook.com [104.47.33.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39461129554 for ; Sun, 13 Nov 2016 23:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jvQXCKZisRE+KdD+GSxKuHUJniTOEnjwU3CZxpnjgOI=; b=SuYMyKzL/g2dluAu1TRhzx/zgNNJfGXmfIpDUVqVyF67+p+8hlFhATBvelwoWxaEPWQdXnuI/vC58Sa500aHZ1HNAZy0I1Nvr353sDhTsSxgFcdaLCKQ2jkMQccIaCXmCswS6M1d7ROqvc2yFEidIqiXs4svuKkAKOLpLUlFrdM= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Mon, 14 Nov 2016 07:29:21 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0721.015; Mon, 14 Nov 2016 07:29:21 +0000 From: Mike Jones To: Kathleen Moriarty , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-amr-values Thread-Index: AQHSMU17leOjgPWSW0iFyu0dFkkDAKDYLIoQ Date: Mon, 14 Nov 2016 07:29:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:67c:370:128:dca7:1fb6:1ff6:f5d3] x-microsoft-exchange-diagnostics: 1; BN3PR03MB2355; 7:fGyRBnh1TJb8H6VQDdzheiwtT/UCvHvNac8bLHbFSi0Vo4e6qGYzCz5m0BA4FQ9ILumr5rrMUoeBPZp9SR4DrIvmMzhRkdADHOD9CNHPx/L93VpWDRAqkROiLDjTdPdwyWSdB6qrq+1QV/D+/alMFM2kx2+4ePvicCyEjI3rucgZWOpJ191iOere7QTEGGSbhI/fDLADgFckM67u9/5H835pTRA7GXeMeQqC/wYgYguKrhaavD8M1QuRYDjiy99HSFD3ByZ+gwTrw9HEzOuo3Yo+6B7aGlLC/NqFN3W2OjjbpowwI/6/BZb2KzVcWU8kPrw6oQElXGDRRvVHvObqxnjTOz5IGCaBpjwKBoPtF/n+q/1ivqq0zifqrBtYKyuY x-ms-office365-filtering-correlation-id: bf0b6a46-4e6f-47f9-ded7-08d40c5ff393 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2355; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060324)(6045074)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6061318); SRVR:BN3PR03MB2355; BCL:0; PCL:0; RULEID:(304825118); SRVR:BN3PR03MB2355; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(336003)(199003)(377454003)(189002)(81166006)(8936002)(101416001)(122556002)(77096005)(229853002)(106116001)(99286002)(81156014)(86612001)(8676002)(86362001)(106356001)(33656002)(92566002)(68736007)(2900100001)(74316002)(5001770100001)(7846002)(7736002)(97736004)(189998001)(10290500002)(5005710100001)(9686002)(8990500004)(7520500002)(10090500001)(107886002)(105586002)(3280700002)(87936001)(2906002)(586003)(7696004)(54356999)(50986999)(230783001)(5660300001)(6116002)(76176999)(790700001)(76576001)(102836003)(3660700001)(2501003)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2355; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB235557F8D25DA58E3CDB4CFEF5BC0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 07:29:21.2752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2355 Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-amr-values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 07:29:26 -0000 --_000_BN3PR03MB235557F8D25DA58E3CDB4CFEF5BC0BN3PR03MB2355namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHJldmlldywgS2F0aGxlZW4uICBEcmFmdCAtMDQgaGFzIGJlZW4gcHVi bGlzaGVkIHRvIGFkZHJlc3MgdGhlc2UgY29tbWVudHMuICBBY3Rpb25zIHRha2VuIGFyZSBkZXNj cmliZWQgaW5saW5lLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLYXRobGVlbiBNb3JpYXJ0eQ0KU2VudDogU2F0dXJk YXksIE9jdG9iZXIgMjksIDIwMTYgMzo1MSBBTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0 OiBbT0FVVEgtV0ddIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMNCg0K SGVsbG8sDQoNCkkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzIGFuZCBoYXZl IGEgZmV3IGNvbW1lbnRzLiAgRmlyc3QsIHRoYW5rcyBmb3IgeW91ciB3b3JrIG9uIHRoaXMgZHJh ZnQhDQoNClNldmVyYWwgb2YgdGhlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgbWVudGlvbmVkIGFy ZSB0eXBpY2FsbHkgdXNlZCAob3IgcmVjb21tZW5kZWQgZm9yIHVzZSkgYXMgYSBzZWNvbmQgb3Ig dGhpcmQgZmFjdG9yLiAgSSBzZWUgaW4gc2VjdGlvbiAzIHRoYXQgbXVsdGlwbGUgbWV0aG9kcyBj YW4gYmUgY29udGFpbmVkIGluIHRoZSBjbGFpbS4gIEknZCBsaWtlIHRvIHNlZSBhbiBleGFtcGxl IG9mIHNpbmdsZSBhbmQgbXVsdGlwbGUgYXV0aGVudGljYXRpb24gbWV0aG9kcyBiZWluZyByZXBy ZXNlbnRlZC4gIFdhcyBpdCBhIFdHIGRlY2lzaW9uIHRvIGxlYXZlIG91dCBleGFtcGxlcz8NCg0K wrcgICAgICAgQWRkZWQg4oCcYW1y4oCdIGNsYWltIGV4YW1wbGVzIHdpdGggYm90aCBzaW5nbGUg YW5kIG11bHRpcGxlIHZhbHVlcy4NCg0KSW4gdGhlIFByaXZhY3kgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbiwgSSB0aGluayBpdCBzaG91bGQgYmUgbWFkZSBjbGVhciB0aGF0IHRoZSBhY3R1YWwgY3Jl ZGVudGlhbHMgYXJlIG5vdCBwYXJ0IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBhdm9pZCBhZGRp dGlvbmFsIHByaXZhY3kgY29uY2VybnMgZm9yIGJpb21ldHJpYyBkYXRhLg0KDQrCtyAgICAgICBD bGFyaWZpZWQgdGhhdCB0aGUgYWN0dWFsIGNyZWRlbnRpYWxzIHJlZmVyZW5jZWQgYXJlIG5vdCBw YXJ0IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBhdm9pZCBhZGRpdGlvbmFsIHByaXZhY3kgY29u Y2VybnMgZm9yIGJpb21ldHJpYyBkYXRhLg0KDQpTZWN0aW9uIDUsIHNob3VsZG4ndCBhIHBvaW50 ZXIgYmUgaGVyZSB0byB0aGUgYXR0YWNrcyBvbiBPQXV0aCAyLjAgYXMgd2VsbD8NCg0KwrcgICAg ICAgQ2xhcmlmaWVkIHRoYXQgdGhlIE9BdXRoIDIuMCBUaHJlYXQgTW9kZWwgW1JGQzY4MTldIGFw cGxpZXMgdG8gYXBwbGljYXRpb25zIHVzaW5nIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KDQpUaGFu ayB5b3UuDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0K --_000_BN3PR03MB235557F8D25DA58E3CDB4CFEF5BC0BN3PR03MB2355namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4NTMwMzcyODY7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDk1MDc3NTQ2IDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoYW5rcyBmb3IgeW91ciBy ZXZpZXcsIEthdGhsZWVuLiZuYnNwOyBEcmFmdCAtMDQgaGFzIGJlZW4gcHVibGlzaGVkIHRvIGFk ZHJlc3MgdGhlc2UgY29tbWVudHMuJm5ic3A7IEFjdGlvbnMgdGFrZW4gYXJlIGRlc2NyaWJlZCBp bmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5LYXRobGVlbiBNb3JpYXJ0eTxicj4NCjxiPlNlbnQ6PC9iPiBT YXR1cmRheSwgT2N0b2JlciAyOSwgMjAxNiAzOjUxIEFNPGJyPg0KPGI+VG86PC9iPiBvYXV0aEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIEFEIHJldmlldyBvZiBkcmFm dC1pZXRmLW9hdXRoLWFtci12YWx1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgcmV2aWV3ZWQmbmJzcDtkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMgYW5kIGhhdmUgYSBm ZXcgY29tbWVudHMuJm5ic3A7IEZpcnN0LCB0aGFua3MgZm9yIHlvdXIgd29yayBvbiB0aGlzIGRy YWZ0ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TZXZlcmFsIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzIG1lbnRpb25lZCBhcmUgdHlw aWNhbGx5IHVzZWQgKG9yIHJlY29tbWVuZGVkIGZvciB1c2UpIGFzIGEgc2Vjb25kIG9yIHRoaXJk IGZhY3Rvci4mbmJzcDsgSSBzZWUgaW4gc2VjdGlvbiAzIHRoYXQgbXVsdGlwbGUgbWV0aG9kcyBj YW4gYmUgY29udGFpbmVkIGluIHRoZSBjbGFpbS4mbmJzcDsgSSdkIGxpa2UgdG8gc2VlIGFuIGV4 YW1wbGUgb2Ygc2luZ2xlIGFuZA0KIG11bHRpcGxlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgYmVp bmcgcmVwcmVzZW50ZWQuJm5ic3A7IFdhcyBpdCBhIFdHIGRlY2lzaW9uIHRvIGxlYXZlIG91dCBl eGFtcGxlcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkZWQg4oCcPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hbXI8L3NwYW4+4oCd IGNsYWltIGV4YW1wbGVzIHdpdGggYm90aCBzaW5nbGUgYW5kIG11bHRpcGxlIHZhbHVlcy4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgUHJpdmFjeSBjb25z aWRlcmF0aW9ucyBzZWN0aW9uLCBJIHRoaW5rIGl0IHNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQg dGhlIGFjdHVhbCBjcmVkZW50aWFscyBhcmUgbm90IHBhcnQgb2YgdGhpcyBzcGVjaWZpY2F0aW9u IHRvIGF2b2lkIGFkZGl0aW9uYWwgcHJpdmFjeSBjb25jZXJucyBmb3IgYmlvbWV0cmljIGRhdGEu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkNsYXJpZmllZCB0aGF0IHRoZSBhY3R1 YWwgY3JlZGVudGlhbHMgcmVmZXJlbmNlZCBhcmUgbm90IHBhcnQgb2YgdGhpcyBzcGVjaWZpY2F0 aW9uIHRvIGF2b2lkIGFkZGl0aW9uYWwgcHJpdmFjeSBjb25jZXJucyBmb3IgYmlvbWV0cmljIGRh dGEuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiA1LCBz aG91bGRuJ3QgYSBwb2ludGVyIGJlIGhlcmUgdG8gdGhlIGF0dGFja3Mgb24gT0F1dGggMi4wIGFz IHdlbGw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkNsYXJpZmllZCB0aGF0IHRo ZSBPQXV0aCAyLjAgVGhyZWF0IE1vZGVsIFtSRkM2ODE5XSBhcHBsaWVzIHRvIGFwcGxpY2F0aW9u cyB1c2luZyB0aGlzIHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkthdGhsZWVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN3PR03MB235557F8D25DA58E3CDB4CFEF5BC0BN3PR03MB2355namp_-- From nobody Sun Nov 13 23:37:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03971296C5 for ; Sun, 13 Nov 2016 23:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlG5ZcVWzxqQ for ; Sun, 13 Nov 2016 23:37:14 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A246129634 for ; Sun, 13 Nov 2016 23:37:14 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id w194so57449192vkw.2 for ; Sun, 13 Nov 2016 23:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yTwG0phjmo5j/MjhifJc1DQCj/9qRFqOcafhqnlWZCo=; b=WfPc9vAL/CXM+bZYsb5uL0wtSSVDdnrCL5+ZYc1KvON7OwLHHzGnK3I/8/bA09O3fs NUPFOggt78OETNQ3puFQV/IWS1fMUi7QCQ4ufv5DqW3tXHPbUrPQPWSlMGHh9YPeZSc+ bJ5enbcybvjxoVv/84qswJ7ExMvbOjIfvbNwlNtI40OnXnpZ0PgRSpozxQK1X28jCovc XAqZD0MeSN3Y2gVFJm9p+AxfxFPyeKMGbIoZHnVHs2SDAzaCvL67Od60rp5ryBZ2SnoI jNjt0gbq8jGlzpouPe2qTNNLpXrTR250iFf5zGl9ZdvoSrN6n5L0ilA/IXEH4zjbJupD IPgg== 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; bh=yTwG0phjmo5j/MjhifJc1DQCj/9qRFqOcafhqnlWZCo=; b=kunGxBlH5YUJTjbmSMuOXKSYmky+k7SVDg9QNt7I8yifOKkaLex0fjC/fvrTIrKKFI G7UZf+9isUBXIN3Jtd0cykQNUxHstb9UUGX53lWyiceqhXxgbpUSU+TJ7f6gmTtcakHl sq54gVeVGLS74T6Ry/mF+BIq1qvLVToez7D+Xz9RwxmJHojAaDKTi18mMmly9SYOlDbL uJXNr4q7c3OYjEX9p3W+ApMaW5LbCF2WjpiXNqE5NZSS1gPqq6qQMc89wnq9eO0ar3EU CR9lkG3RlOAgyglGVftTAj7qkc+2EfbKkP3OTAHipyED/U4dTGjeYa2/PTdwq0UoaIjP TgSQ== X-Gm-Message-State: ABUngvdTgqYkJDopYxRL8/VHRssQcwXofqTmVy4jMiPTbpDiTrW4VbsuzaS+cLIb5nDGBm8wmmdTGWsvKdkCDg== X-Received: by 10.31.151.13 with SMTP id z13mr9392820vkd.41.1479109033433; Sun, 13 Nov 2016 23:37:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.82.143 with HTTP; Sun, 13 Nov 2016 23:37:13 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Mon, 14 Nov 2016 02:37:13 -0500 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a1140fd5885a00b05413de863 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-amr-values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 07:37:16 -0000 --001a1140fd5885a00b05413de863 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Mike. I'll look at the shepherd report and see if it is ready to start last call. Best regards, Kathleen On Mon, Nov 14, 2016 at 2:29 AM, Mike Jones wrote: > Thanks for your review, Kathleen. Draft -04 has been published to addres= s > these comments. Actions taken are described inline. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kathleen > Moriarty > *Sent:* Saturday, October 29, 2016 3:51 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] AD review of draft-ietf-oauth-amr-values > > > > Hello, > > > > I reviewed draft-ietf-oauth-amr-values and have a few comments. First, > thanks for your work on this draft! > > > > Several of the authentication methods mentioned are typically used (or > recommended for use) as a second or third factor. I see in section 3 tha= t > multiple methods can be contained in the claim. I'd like to see an examp= le > of single and multiple authentication methods being represented. Was it = a > WG decision to leave out examples? > > =C2=B7 Added =E2=80=9Camr=E2=80=9D claim examples with both single = and multiple values. > > > > In the Privacy considerations section, I think it should be made clear > that the actual credentials are not part of this specification to avoid > additional privacy concerns for biometric data. > > =C2=B7 Clarified that the actual credentials referenced are not par= t of > this specification to avoid additional privacy concerns for biometric dat= a. > > > > Section 5, shouldn't a pointer be here to the attacks on OAuth 2.0 as wel= l? > > =C2=B7 Clarified that the OAuth 2.0 Threat Model [RFC6819] applies = to > applications using this specification. > > > > > > Thank you. > > -- > > > > Best regards, > > Kathleen > --=20 Best regards, Kathleen --001a1140fd5885a00b05413de863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Mike.

I'll look at the shep= herd report and see if it is ready to start last call.

=
Best regards,
Kathleen

On Mon, Nov 14, 2016 at 2:29 AM, Mike Jones= <Michael.Jones@microsoft.com> wrote:

Thanks for your review, Kathleen.=C2= =A0 Draft -04 has been published to address these comments.=C2=A0 Actions t= aken are described inline.

=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 -- Mi= ke

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of Kathleen Moriarty
Sent: Saturday, October 29, 2016 3:51 AM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] AD review of draft-ietf-oauth-amr-values<= u>

=C2=A0

Hello,

=C2=A0

I reviewed=C2=A0draft-ietf-oauth-amr-values and= have a few comments.=C2=A0 First, thanks for your work on this draft!

=C2=A0

Several of the authentication methods mentioned are = typically used (or recommended for use) as a second or third factor.=C2=A0 = I see in section 3 that multiple methods can be contained in the claim.=C2= =A0 I'd like to see an example of single and multiple authentication methods being represented.=C2=A0 Was it a WG decis= ion to leave out examples?

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Added =E2=80=9Camr=E2=80=9D claim examples with both single and= multiple values.

=C2=A0

In the Privacy considerations section, I think it sh= ould be made clear that the actual credentials are not part of this specifi= cation to avoid additional privacy concerns for biometric data.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clarified that the actual credentials reference= d are not part of this specification to avoid additional privacy concerns f= or biometric data.

=C2=A0

Section 5, shouldn't a pointer be here to the at= tacks on OAuth 2.0 as well?

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clarified that the OAuth 2.0 Threat Model [RFC6= 819] applies to applications using this specification.

=C2=A0

=C2=A0

Thank you.

--

=C2=A0

Best regards,

Kathleen




--
Best regards,
Kathleen
--001a1140fd5885a00b05413de863-- From nobody Mon Nov 14 02:38:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4312957A for ; Mon, 14 Nov 2016 02:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IzL2Cn8u8iD for ; Mon, 14 Nov 2016 02:38:18 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13192129454 for ; Mon, 14 Nov 2016 02:38:18 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 51so59339842uai.1 for ; Mon, 14 Nov 2016 02:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EQKoaO9CTvc9T+9xCxooxQjY03HIpHWJfOvIY/Et/Jg=; b=aJUi1Vpbckz5ICEWIu639jKpKCZxDke+6y6hxM5usb9TzKmi8YXq3CgepuXxID0Cmt YRm6sG7Zj4u4bkCSmzmlegk8fIXDDm3oiURAiYMZE9RXzKDXUgULRRAXAbb8uBNynPA9 XSTo1Msz+5LfnQ2r3ROLmaSsOavOeXH4ByURVi947HFcLGPEFQR4uu9l1Dq7jPIppR+h cXocVNrWUR3F4g/LLis3wv4HG37QShhg8blp90eTPdjKuzVXLK5Tn/6edIVGwYwN3npL PfAv/96W9f/x3RXdamvCjJvEy5s233tyu0pM8riq7RCBT9MirT5REqA+qXEytiBCr+1x Tn5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=EQKoaO9CTvc9T+9xCxooxQjY03HIpHWJfOvIY/Et/Jg=; b=F8hHPb7kiHlfRNqemO7gIidijvOeCAz8Wg5LDn0qLLQDJL3kdWuLU4ET1y3eCg+Cbh ro+Ih4QmGC8czVfnQ7bi6GyTaSlWyz13L2+Vjp5uVRON0aMkaBsv+9HhtbkCUmtGA8fD go2lqjtSWLQsIDjbATD1e9KpcjxH4KFapMPobcGf46rv1h05/Sdog6L2NzNi5r7X14Cw OWgGyIzxTG+E391rjrc2sPD61YvQmmNkNQk0D7Zl7GEvhPQLPqNUh92phcf1zCZdwEGJ ZMKsWodDfK/5iIeg5sSzZuICJ7PAwNtj16BjuHbJ7ZF4NXkYlU32MtHAU2fTFizFAzsm Qi+g== X-Gm-Message-State: ABUngvfFYU18psho292lb7Ot9rL3UCxoc/KMTEiU0twl0kvegEiQIpWn+WAS6y5JV50VAN44Y3IeU+QENAH+Pw== X-Received: by 10.176.80.101 with SMTP id z34mr9389908uaz.140.1479119897103; Mon, 14 Nov 2016 02:38:17 -0800 (PST) MIME-Version: 1.0 References: <58eb4c58-59c2-dac6-2e41-76ec359d4210@free.fr> <5828035C.801@lodderstedt.net> <37928b52-928a-86a0-52b2-dd5504ad9f03@free.fr> In-Reply-To: <37928b52-928a-86a0-52b2-dd5504ad9f03@free.fr> From: Nat Sakimura Date: Mon, 14 Nov 2016 10:38:06 +0000 Message-ID: To: Denis , Torsten Lodderstedt , oauth@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07dfc60c15da054140707d Archived-At: Subject: Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 10:38:21 -0000 --94eb2c07dfc60c15da054140707d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Torsten, I think what Denis is referring to is the case where two bad actors, Alice and Bob collude and take advantage of the "bearer token". By doing so, instead of Bob buying Vodka for Alice, Alice can order Vodka disguised as Bob. So, the increased risk here is that Alice does not have to bother Bob to get additional vodka. Note: In this case, the token does not identify Alice nor Bob to the relying party but just provides the authorization to perform some action. Mitigation 1: If the token is Token Bound, then the attack does not work, and Alice has to ask Bob to get her Vodka every time so the risk stays the same as pre-attack. Mitigation 2: If the AS provides only very short lived access/refresh token, then Alice has to get Bob act for her every time and so it becomes the same as Bob buying vodka for Alice every time so the risk stays the same as pre-attack. Best, Nat On Mon, Nov 14, 2016 at 7:58 AM Denis wrote: > Nat and Torsten, > > My responses ares embedded in your text. > > I agree, we should analyse the threat. From my first impression it feels > like injection with some specialties. > > > Not exactly. In most scenario attacks, we have two good guys (Alice and > Bob) and one bad guy (Carol) acting as the single attacker.. > In this scenario, we have two bad guys (Alice and Bob willing to > collaborate) and one good guy (Carol) acting as a relying party. > > > @Denis: > So far, I'm struggeling to understand how this attack is performed from a > practical perspective. > Every token/assertion issued to the uncle is bound to its identity. > > > This key question is to which "identity" since I am considering a scheme > where privacy considerations are as important as security considerations. > So the goal is only to reveal to the third party that the user making the > access is more than 18, without revealing anything else than the relying > party > would already know about the user making the access request. > > So if the niece wants to "upgrade" her age, she would need to somehow mix > identity data for two identities > > (her's and her uncle's identity) into a single token, which needs to be > signed by the respective AS. How is this gone work? > > > As yourself, I don't believe this is a solution. As I already said: > > Whatever kind of cryptographic is being used, when two users collaborate, > a software-only solution will be unable > to prevent the transfer of an attribute of a user that possess it to > another user that does not possess it . > > The use of a secure element simply protecting the confidentiality and the > integrity of some secret key or private key > will be ineffective > > to counter the Alice and Bob collusion attack. Additional properties will > be required for the secure element > (i.e. some physical device with security properties). > > > kind regards, > Torsten. > > Am 11.11.2016 um 16:27 schrieb Nat Sakimura: > > Thanks Denis for pointing it out. It may be desirable to add ABC attack t= o > the list of threats. > Torsten et al. are updating Threat Model and Security Considerations so i= t > could potentially be included in there. > > Some remarks: > > - I suppose the assumption is that the Bob does not share his > credentials with Alice: Otherwise, sharing the credential would achiev= e > something worse. > > The assumption is correct. > > > - In addition, it assumes that Bob does not give his device to Alice: > Otherwise, something similar to ABC attack can be achieved by Bob > giving Alice his Laptop or Phone, and I guess this happens more often > than shipping Bob's access token to Alice. > > > The assumption is correct. If Bob is using a smart card that protects som= e > keys, he will never give the smart card nor the PIN to Alice. > > > - > - With these assumptions: > - It looks like a variation of token injection attack that we have > been talking about for many years. > > > Not exactly. > > > > > - If we token bind the refresh and access tokens, the ABC attack as > described does not work. > > > I am not sure I understand what you mean here, since my belief is still : > > Whatever kind of cryptographic is being used, when two users collaborate, > a software-only solution will be unable > to prevent the transfer of an attribute of a user that possess it to > another user that does not possess it . > > > > - For something like Age verification, recognizing such attacks, it > probably is a bad practice to rely on refresh/access token. > The service should do more active check, e.g., through OpenID > Connect. > > > Same comment as above. > > > Denis > > > > > Best, > > Nat > > On Tue, Nov 8, 2016 at 2:54 AM Denis wrote: > > Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies > requirements. > One of them (which, BTW, should be moved into Section 4 - Threats) is : > > Collusion: > > Resource servers that collude ... > > This threat addresses the case of "*collusion between servers"* while the > case of "*collusion between clients"* > has not been considered. When access tokens are being used, *collusion > between clients *is of primary importance. > > Let us consider the following "Alice and Bob Collusion attack" (ABC > attack). > > An uncle (Bob) is willing to collaborate with his young niece (Alice) who > is less than 18 during a short period of time. > The niece is opening her own session and creates an account on a server. > The uncle does not hand over his own session to her niece > at any point of time. > > Let us assume that some crypto expert has written two specific pieces of > software. One has been installed on the laptop > of the uncle and another one on the laptop of the niece. The two laptops > are able to communicate using a network (e.g. a WAN or a LAN). > > The niece creates an account on a resource server. Later on, the resource > server asks her (or him ?) to demonstrate that she (or his ?) > is more than 18. She forwards the information received from the resource > server to her uncle using the network. The uncle receives > that information and connects to an Authorization Server. The uncle > requests an access token containing information demonstrating > that he is older than 18 and passed it back to his niece. The niece then > presents it to the resource server. The access token is accepted. > > Since the niece has been able to demonstrate once that she is more than > 18, the resource server will remember this attribute > and in the future she will not need to demonstrate it again. She will kee= p > the advantages related to this attribute associated > with her account on that resource server until she does not need it > anymore, i.e. when she will really be over 18. > > Whatever kind of cryptographic is being used, when two users collaborate,= a > software-only solution will be > unable to prevent the transfer of an attribute of a user that possess it > to another user that does not possess it . > > The use of a secure element simply protecting the confidentiality and the > integrity of some secret key or private key will be ineffective > to counter the Alice and Bob collusion attack. Additional properties will > be required for the secure element. > > RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in > January 2013 has omitted to take into consideration > the Alice and Bob Collusion attack. > > Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.= 2 > available at: > https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 : > > To prevent =E2=80=9Ccredential pooling=E2=80=9D, i.e., multiple Users sha= ring their > credentials, credentials can optionally be bound to a secret key, > i.e. a cryptographically strong random value that is assumed to be known > only to a particular user. The credential speci=EF=AC=81cation > speci=EF=AC=81es whether the credentials issued according to this speci= =EF=AC=81cation are > to employ key binding or not. > > A presentation token derived from such a key-bound credential always > contains an implicit proof of knowledge of the underlying secret key, > so that the Veri=EF=AC=81er can be sure that the rightful owner of the cr= edential > was involved in the creation of the presentation token. > As an extra protection layer, the credentials can also be bound to a > trusted physical device, such as a smart card, by keeping > the secret key in a protected area of the device. That is, the key cannot > be extracted from the device, but the device does participate > in the presentation token generation to include an implicit proof of > knowledge of this key in the token. Thus, for credentials that are > key-bound > to a physical device it is impossible to create a presentation token > without the device. > > The rightful owner of the credential was indeed involved in real-time in > the creation of the presentation token but in the collaboration scenario, > the key binding mechanism is not sufficient to counter that specific > attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft) are currently > not resistant to the "ABC attack". > > The IRMA card project (https://www.irmacard.org/) based on the use of a > smart card and of the Idemix scheme claims to provide security > and privacy simultaneously. However, this project will not be resistant > either to the ABC attack. > > *draft-ietf-oauth-pop-architecture-08 should take into consideration the > ABC attack.* > > The threat related to the ABC attack should be identified in the security > considerations section > and the core of the document should attempt to identify one or more ways > to counter it. > > The scope of draft-ietf-oauth-token-exchange-06 is limited to the > definition of a basic request and response protocol for > an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security > Considerations) has omitted to take into consideration > the ABC attack and therefore the currently described "basic request and > response protocol" will allow Bob to obtain an access > token and to pass it successfully to Alice so that she can use it. > > *draft-ietf-oauth-token-exchange-06 **should take into consideration the > ABC attack.* > > The threat related to the ABC attack should be identified in the security > considerations section > and the core of the document should attempt to identify one or more ways > to counter it. > > Denis > > PS. I have recently registered to the OAuth mailing list. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > -- Nat Sakimura Chairman of the Board, OpenID Foundation --94eb2c07dfc60c15da054140707d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Torsten,=C2=A0

I think what Denis is re= ferring to is the case where two bad actors, Alice and Bob collude and take= advantage of the "bearer token".=C2=A0
By doing so, in= stead of Bob buying Vodka for Alice, Alice can order Vodka disguised as Bob= . So, the increased risk here is that Alice does not have to bother Bob to = get additional vodka.=C2=A0

Note: In this case, th= e token does not identify Alice nor Bob to the relying party but just provi= des the authorization to perform some action.=C2=A0

Mitigation 1: If the token is Token Bound, then the attack does not work,= and Alice has to ask Bob to get her Vodka every time so the risk stays the= same as pre-attack.=C2=A0
Mitigation 2: If the AS provides only = very short lived access/refresh token, then Alice has to get Bob act for he= r every time and so it becomes the same as Bob buying vodka for Alice every= time so the risk stays the same as pre-attack.=C2=A0

<= div>Best,=C2=A0

Nat

On Mon, Nov 14, 2016 at 7:58 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Nat and Torsten,

My responses ares embedded in your text.

=20 I agree, we should analyse the threat. From my first impression it feels like injection with some specialties.

Not exactly. In most scenario atta= cks, we have two good guys (Alice and Bob) and one bad guy (Carol) acting as the single attacker..
In this scenario, we have two bad guys (Alice and Bob willing to collaborate) and one good guy (Carol) acting as a relying party.


@Denis:
So far, I'm struggeling to understand how this attack is performe= d from a practical perspective.
Every token/assertion issued to the uncle is bound to its identity.

This key question is to which &quo= t;identity" since I am considering a scheme where privacy considerations are as important as security considerations.
So the goal is only to reveal to the third party that the user making the access is more than 18, without revealing anything else than the relying party
would already know about the user making the access request.
So if the niece wants to "upgrade" her age, she would need to = somehow mix identity data for two identities
(her's and her uncle's identity) into a single token, which n= eeds to be signed by the respective AS. How is this gone work?

As yourself, I don't be= lieve this is a solution. As I already said:
Wh= atever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable
to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key
will be ineffective
to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element
(i.e. some physical device with security properties).

kind regards,
Torsten.

Am 11.1= 1.2016 um 16:27 schrieb Nat Sakimura:
Thanks Denis for pointing it o= ut. It may be desirable to add ABC attack to the list of threats.
Torsten et al. are updating Threat Model and Security Considerations so it could potentially be included in there.=C2= =A0

Some remarks:=C2=A0
  • I suppose the assumption is that th= e Bob does not share his credentials with Alice: Otherwise, sharing the credential would achieve something worse.
The assumption is correct. =

  • In addition, it assumes that Bob do= es not give his device to Alice: Otherwise, something similar to ABC attack can be achieved by Bob
    giving Alice his Laptop or Phone, and I guess this happens more often than shipping Bob's access token t= o Alice.

The assumption is correct. If Bob = is using a smart card that protects some keys, he will never give the smart card nor the PIN to Alice.


  • With these assumptions:=C2=A0
    • It looks like a variation of toke= n injection attack that we have been talking about for many years.

Not exactly.



    • If we token bind the refresh and = access tokens, the ABC attack as described does not work.

I am not sure I understand what yo= u mean here, since my belief is still :
Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable
to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

    • For something like Age verificati= on, recognizing such attacks, it probably is a bad practice to rely on refresh/access token.
      The service should do more active check, e.g., through OpenID Connect.

Same comment as above.

Denis


Best,=C2=A0

Nat

On Tue, Nov 8, 2016 at 2:54 = AM Denis <denis.ietf@free= .fr> wrote:

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">Section= 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies requirements.
One of them (which, BTW, should be moved into Section 4 - Threats) is :

= Collusion:

= =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Resource servers that collude ...

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">This th= reat addresses the case of "collusion between s= ervers" while the case of "collusion between clients"
has not been considered. When access tokens are being used, collusion between clients is of primary importance.

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">Let us = consider the following "Alice and Bob Collusion attack" (ABC attack).

= An uncle (Bob) is willing to collaborate with his young niece (Alice) who is less than 18 during a short period of time.
The niece is opening her own session and creates an account on a server. The uncle does not hand over his own session to her niece
at any point of time.

= Let us assume that some crypto expert has written two specific pieces of software. One has been installed on the laptop
of the uncle and another one on the laptop of the niece. The two laptops are able to communicate using a network (e.g. a WAN or a LAN).

= The niece creates an account on a resource server. Later on, the resource server asks her (or him ?) to demonstrate that she (or his ?)
is more than 18. She forwards the information received from the resource server to her uncle using the network. The uncle receives
that information and connects to an Authorization Server. The uncle requests an access token containing information demonstrating
that he is older than 18 and passed it back to his niece. The niece then presents it to the resource server. The access token is accepted.

= Since the niece has been able to demonstrate once that she is more than 18, the resource server will remember this attribute
and in the future she will not need to demonstrate it again. She will keep the advantages related to this attribute associated
with her account on that resource server until she does not need it anymore, i.e. when she will really be over 18.

Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be
unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective
to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element.

<= span style=3D"font-family:Arial;color:black" class=3D"gmail_msg" lang=3D"EN= -US">RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 has omitted to take into consideration
the Alice and Bob Collusion attack.

= Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.2 available at:
https://abc4trust.eu/download/D= eliverable_D2.2.pdf states on page 17 :

To prevent =E2=80=9Ccredential pooling=E2=80=9D, i.e., multiple Users sharing their credentials, credentials can optionally be bound to a secret key,
i.e. a cryptographically strong random value that is assumed to be known only to a particular user. The credential speci=EF=AC=81cation
speci=EF=AC=81es whether the credentials issued according= to this speci=EF=AC=81cation are to employ key binding or no= t.

A presentation token derived from such a key-bound credential always contains an implicit proof of knowledge of the underlying secret key,
so that the Veri=EF=AC=81er can be sure that the rightful owner of the credential was involved in the creation of the presentation token.
As an extra protection layer, the credentials can also be bound to a trusted physical device, such as a smart card, by keeping
the secret key in a protected area of the device. That is, the key cannot be extracted from the device, but the device does participate
in the presentation token generation to include an implicit proof of knowledge of this key in the token. Thus, for credentials that are key-bound
to a physical device it is impossible to create a presentation token without the device.

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">The rig= htful owner of the credential was indeed involved in real-time in the creation of the presentation token but in the collaboration scenario,
the key binding mechanism is not sufficient to counter that specific attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft) are currently
not resistant to the "ABC attack".

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">The IRM= A card project (https://www.irmacard.= org/) based on the use of a smart card and of the Idemix scheme claims to provide security
and privacy simultaneously. However, this project will not be resistant either to the ABC attack.

<= b class=3D"gmail_msg">draft-ietf-oauth-pop-architecture-08 should take into consideration the ABC attack.

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">The thr= eat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">The sco= pe of draft-ietf-oauth-token-exchange-06 is limited to the definition of a basic request and response protocol for
an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security Considerations) has omitted to take into consideration
the ABC attack and therefore the currently described "basic request and response protocol" will allo= w Bob to obtain an access
token and to pass it successfully to Alice so that she can use it.

draft-ietf-oauth-token-exchange-06 should take into consideratio= n the ABC attack.

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US"> The th= reat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">Denis

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">PS. I h= ave recently registered to the OAuth mailing list.

<= span style=3D"font-family:Arial" class=3D"gmail_msg" lang=3D"EN-US">

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

Nat Sakimura

Chairman of the Board, OpenID = Foundation



__________________________________________=
_____
OAuth mailing list
OAuth@ietf.org
https://www.i=
etf.org/mailman/listinfo/oauth


--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--94eb2c07dfc60c15da054140707d-- From nobody Mon Nov 14 07:16:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADFE1296F9 for ; Mon, 14 Nov 2016 07:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXgs4rUWQgb5 for ; Mon, 14 Nov 2016 07:16:44 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99A71296A6 for ; Mon, 14 Nov 2016 07:16:43 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 479C57803A4; Mon, 14 Nov 2016 16:16:38 +0100 (CET) To: Nat Sakimura References: <58eb4c58-59c2-dac6-2e41-76ec359d4210@free.fr> <5828035C.801@lodderstedt.net> <37928b52-928a-86a0-52b2-dd5504ad9f03@free.fr> From: Denis Message-ID: <66ab427f-1aea-7337-b64f-7c8da91c1201@free.fr> Date: Mon, 14 Nov 2016 16:16:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------329BCAAB7E6527255DDC98F0" Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 15:16:47 -0000 This is a multi-part message in MIME format. --------------329BCAAB7E6527255DDC98F0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Nat, Cheers ! The use case of buying Vodka is a nice illustration. :-) > Torsten, > > I think what Denis is referring to is the case where two bad actors, > Alice and Bob collude and take advantage of the "bearer token". > By doing so, instead of Bob buying Vodka for Alice, Alice can order > Vodka disguised as Bob. So, the increased risk here is that Alice does > not have to bother Bob > to get additional vodka. > > Note: In this case, the token does not identify Alice nor Bob to the > relying party but just provides the authorization to perform some action. > > Mitigation 1: If the token is Token Bound, then the attack does not > work, and Alice has to ask Bob to get her Vodka every time so the risk > stays the same as pre-attack. Are you referring to draft-ietf-oauth-token-binding-01 ? The document addresses the cases of the man-in-the-middle, token export and replay attacks, but will not be an appropriate protection when Alice et Bob collaborate together. If you are referring to something else, would you be more precise ? Mitigation 2: If the AS provides only very short lived access/refresh token, then Alice has to get Bob act for her every time and so it becomes the same as Bob buying vodka for Alice every time so the risk stays the same as pre-attack. Two observations: a) In some cases, an access will be granted because it is needed to present more than one attribute. A server application normally memorizes by default the attributes that it has accepted (in some case during one year only), but if a user makes an access everyday, the user will find annoying to present everyday the attributes that are needed. b) Secondly, reducing the risk to the same as pre-attack does not mean that the risk does not exist anymore. The key point is to use a mechanism that prevents Bob to help Alice, even if Bob is willing to collaborate with Alice. Whatever Bob will be doing, he will not be able to help Alice to buy her Vodka.Every time Alice would like to buy a bottle a Vodka on-line, the single solution would be for Alice to ask Bob to buy one bottle for himself and then to send it to her. Denis > > Best, > > Nat > > On Mon, Nov 14, 2016 at 7:58 AM Denis > wrote: > > Nat and Torsten, > > My responses ares embedded in your text. > >> I agree, we should analyse the threat. From my first impression >> it feels like injection with some specialties. > > Not exactly. In most scenario attacks, we have two good guys > (Alice and Bob) and one bad guy (Carol) acting as the single > attacker.. > In this scenario, we have two bad guys (Alice and Bob willing to > collaborate) and one good guy (Carol) acting as a relying party. > >> >> @Denis: >> So far, I'm struggeling to understand how this attack is >> performed from a practical perspective. >> Every token/assertion issued to the uncle is bound to its identity. > > This key question is to which "identity" since I am considering a > scheme where privacy considerations are as important as security > considerations. > So the goal is only to reveal to the third party that the user > making the access is more than 18, without revealing anything else > than the relying party > would already know about the user making the access request. > >> So if the niece wants to "upgrade" her age, she would need to >> somehow mix identity data for two identities >> (her's and her uncle's identity) into a single token, which needs >> to be signed by the respective AS. How is this gone work? > > As yourself, I don't believe this is a solution. As I already said: > > Whatever kind of cryptographic is being used, when two users > collaborate, a software-only solution will be unable > to prevent the transfer of an attribute of a user that possess > it to another user that does not possess it . > > The use of a secure element simply protecting the > confidentiality and the integrity of some secret key or > private key > will be ineffective > > to counter the Alice and Bob collusion attack. Additional > properties will be required for the secure element > (i.e. some physical device with security properties). > >> >> kind regards, >> Torsten. >> >> Am 11.11.2016 um 16:27 schrieb Nat Sakimura: >>> Thanks Denis for pointing it out. It may be desirable to add ABC >>> attack to the list of threats. >>> Torsten et al. are updating Threat Model and Security >>> Considerations so it could potentially be included in there. >>> >>> Some remarks: >>> >>> * I suppose the assumption is that the Bob does not share his >>> credentials with Alice: Otherwise, sharing the credential >>> would achieve something worse. >>> > The assumption is correct. > >>> * In addition, it assumes that Bob does not give his device to >>> Alice: Otherwise, something similar to ABC attack can be >>> achieved by Bob >>> giving Alice his Laptop or Phone, and I guess this happens >>> more often than shipping Bob's access token to Alice. >>> > > The assumption is correct. If Bob is using a smart card that > protects some keys, he will never give the smart card nor the PIN > to Alice. > >>> * >>> >>> >>> * With these assumptions: >>> o It looks like a variation of token injection attack that >>> we have been talking about for many years. >>> > > Not exactly. > > > >>> o If we token bind the refresh and access tokens, the ABC >>> attack as described does not work. >>> > > I am not sure I understand what you mean here, since my belief is > still : > > Whatever kind of cryptographic is being used, when two users > collaborate, a software-only solution will be unable > to prevent the transfer of an attribute of a user that possess > it to another user that does not possess it . > > >>> o For something like Age verification, recognizing such >>> attacks, it probably is a bad practice to rely on >>> refresh/access token. >>> The service should do more active check, e.g., through >>> OpenID Connect. >>> > > Same comment as above. > > > Denis > > >>> Best, >>> >>> Nat >>> >>> On Tue, Nov 8, 2016 at 2:54 AM Denis >> > wrote: >>> >>> Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" >>> identifies requirements. >>> One of them (which, BTW, should be moved into Section 4 - >>> Threats) is : >>> >>> Collusion: >>> >>> Resource servers that collude ... >>> >>> This threat addresses the case of "/collusion between >>> servers"/ while the case of "/collusion between clients"/ >>> has not been considered. When access tokens are being used, >>> /collusion between clients /is of primary importance. >>> >>> Let us consider the following "Alice and Bob Collusion >>> attack" (ABC attack). >>> >>> An uncle (Bob) is willing to collaborate with his young >>> niece (Alice) who is less than 18 during a short period of >>> time. >>> The niece is opening her own session and creates an account >>> on a server. The uncle does not hand over his own session to >>> her niece >>> at any point of time. >>> >>> Let us assume that some crypto expert has written two >>> specific pieces of software. One has been installed on the >>> laptop >>> of the uncle and another one on the laptop of the niece. The >>> two laptops are able to communicate using a network (e.g. a >>> WAN or a LAN). >>> >>> The niece creates an account on a resource server. Later on, >>> the resource server asks her (or him ?) to demonstrate that >>> she (or his ?) >>> is more than 18. She forwards the information received from >>> the resource server to her uncle using the network. The >>> uncle receives >>> that information and connects to an Authorization Server. >>> The uncle requests an access token containing information >>> demonstrating >>> that he is older than 18 and passed it back to his niece. >>> The niece then presents it to the resource server. The >>> access token is accepted. >>> >>> Since the niece has been able to demonstrate once that she >>> is more than 18, the resource server will remember this >>> attribute >>> and in the future she will not need to demonstrate it again. >>> She will keep the advantages related to this attribute >>> associated >>> with her account on that resource server until she does not >>> need it anymore, i.e. when she will really be over 18. >>> >>> Whatever kind of cryptographic is being used, when two >>> users collaborate, a software-only solution will be >>> unable to prevent the transfer of an attribute of a user >>> that possess it to another user that does not possess it . >>> >>> The use of a secure element simply protecting the >>> confidentiality and the integrity of some secret key or >>> private key will be ineffective >>> to counter the Alice and Bob collusion attack. Additional >>> properties will be required for the secure element. >>> >>> RFC 6819 (OAuth 2.0 Threat Model and Security >>> Considerations) issued in January 2013 has omitted to take >>> into consideration >>> the Alice and Bob Collusion attack. >>> >>> Section 2.3 of the ABC4Trust project about key-binding in >>> Deliverable D2.2 available at: >>> https://abc4trust.eu/download/Deliverable_D2.2.pdf states on >>> page 17 : >>> >>> To prevent “credential pooling”, i.e., multiple Users >>> sharing their credentials, credentials can optionally be >>> bound to a secret key, >>> i.e. a cryptographically strong random value that is assumed >>> to be known only to a particular user. The credential >>> specification >>> specifies whether the credentials issued according to this >>> specification are to employ key binding or not. >>> >>> A presentation token derived from such a key-bound >>> credential always contains an implicit proof of knowledge of >>> the underlying secret key, >>> so that the Verifier can be sure that the rightful owner of >>> the credential was involved in the creation of the >>> presentation token. >>> As an extra protection layer, the credentials can also be >>> bound to a trusted physical device, such as a smart card, by >>> keeping >>> the secret key in a protected area of the device. That is, >>> the key cannot be extracted from the device, but the device >>> does participate >>> in the presentation token generation to include an implicit >>> proof of knowledge of this key in the token. Thus, for >>> credentials that are key-bound >>> to a physical device it is impossible to create a >>> presentation token without the device. >>> >>> The rightful owner of the credential was indeed involved in >>> real-time in the creation of the presentation token but in >>> the collaboration scenario, >>> the key binding mechanism is not sufficient to counter that >>> specific attack. ABC4Trust, Idemix (IBM) and U-Prove >>> (Microsoft)are currently >>> not resistant to the "ABC attack". >>> >>> The IRMA card project (https://www.irmacard.org/) based on >>> the use of a smart card and of the Idemix scheme claims to >>> provide security >>> and privacy simultaneously. However, this project will not >>> be resistant either to the ABC attack. >>> >>> *draft-ietf-oauth-pop-architecture-08 should take into >>> consideration the ABC attack.* >>> >>> The threat related to the ABC attack should be identified in >>> the security considerations section >>> and the core of the document should attempt to identify one >>> or more ways to counter it. >>> >>> The scope of draft-ietf-oauth-token-exchange-06 is limited >>> to the definition of a basic request and response protocol for >>> an STS-style token exchange utilizing OAuth 2.0. Section 6 >>> (Security Considerations) has omitted to take into >>> consideration >>> the ABC attack and therefore the currently described "basic >>> request and response protocol" will allow Bob to obtain an >>> access >>> token and to pass it successfully to Alice so that she can >>> use it. >>> >>> *draft-ietf-oauth-token-exchange-06 **should take into >>> consideration the ABC attack.* >>> >>> The threat related to the ABC attack should be identified in >>> the security considerations section >>> and the core of the document should attempt to identify one >>> or more ways to counter it. >>> >>> Denis >>> >>> PS. I have recently registered to the OAuth mailing list. >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> -- >>> >>> Nat Sakimura >>> >>> Chairman of the Board, OpenID Foundation >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > --------------329BCAAB7E6527255DDC98F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Nat,

Cheers ! The use case of buying Vodka is a nice illustration. :-)

Torsten, 

I think what Denis is referring to is the case where two bad actors, Alice and Bob collude and take advantage of the "bearer token". 
By doing so, instead of Bob buying Vodka for Alice, Alice can order Vodka disguised as Bob. So, the increased risk here is that Alice does not have to bother Bob
to get additional vodka. 

Note: In this case, the token does not identify Alice nor Bob to the relying party but just provides the authorization to perform some action. 

Mitigation 1: If the token is Token Bound, then the attack does not work, and Alice has to ask Bob to get her Vodka every time so the risk stays the same as pre-attack.
Are you referring to draft-ietf-oauth-token-binding-01 ? The document addresses the cases of  the man-in-the-middle, token export and replay attacks,
but will not be an appropriate protection when Alice et Bob collaborate together. If you are referring to something else, would you be more precise ?
Mitigation 2: If the AS provides only very short lived access/refresh token, then Alice has to get Bob act for her every time and so it becomes the same
as Bob buying vodka for Alice every time so the risk stays the same as pre-attack.

Two observations:

a)   In some  cases, an access will be granted because it is needed to present more than one attribute. A server application normally memorizes
      by default the attributes that it has accepted (in some case during one year only), but if a user makes an access everyday, the user will find
      annoying to present everyday the attributes that are needed.

b)  Secondly, reducing the risk to the same as pre-attack does not mean that the risk does not exist anymore. The key point is to use a mechanism
      that prevents Bob to help Alice, even if Bob is willing to collaborate with Alice. Whatever Bob will be doing, he will not be able to help Alice to buy
      her Vodka. Every time Alice would like to buy a bottle a Vodka on-line, the single solution would be for Alice to ask Bob to buy one bottle for himself
      and then to send it to her. 
Denis


Best, 

Nat

On Mon, Nov 14, 2016 at 7:58 AM Denis <denis.ietf@free.fr> wrote:
Nat and Torsten,

My responses ares embedded in your text.

I agree, we should analyse the threat. From my first impression it feels like injection with some specialties.

Not exactly. In most scenario attacks, we have two good guys (Alice and Bob) and one bad guy (Carol) acting as the single attacker..
In this scenario, we have two bad guys (Alice and Bob willing to collaborate) and one good guy (Carol) acting as a relying party.


@Denis:
So far, I'm struggeling to understand how this attack is performed from a practical perspective.
Every token/assertion issued to the uncle is bound to its identity.

This key question is to which "identity" since I am considering a scheme where privacy considerations are as important as security considerations.
So the goal is only to reveal to the third party that the user making the access is more than 18, without revealing anything else than the relying party
would already know about the user making the access request.

So if the niece wants to "upgrade" her age, she would need to somehow mix identity data for two identities
(her's and her uncle's identity) into a single token, which needs to be signed by the respective AS. How is this gone work?

As yourself, I don't believe this is a solution. As I already said:
Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable
to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key
will be ineffective
to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element
(i.e. some physical device with security properties).

kind regards,
Torsten.

Am 11.11.2016 um 16:27 schrieb Nat Sakimura:
Thanks Denis for pointing it out. It may be desirable to add ABC attack to the list of threats.
Torsten et al. are updating Threat Model and Security Considerations so it could potentially be included in there. 

Some remarks: 
  • I suppose the assumption is that the Bob does not share his credentials with Alice: Otherwise, sharing the credential would achieve something worse.
The assumption is correct.

  • In addition, it assumes that Bob does not give his device to Alice: Otherwise, something similar to ABC attack can be achieved by Bob
    giving Alice his Laptop or Phone, and I guess this happens more often than shipping Bob's access token to Alice.

The assumption is correct. If Bob is using a smart card that protects some keys, he will never give the smart card nor the PIN to Alice.


  • With these assumptions: 
    • It looks like a variation of token injection attack that we have been talking about for many years.

Not exactly.



    • If we token bind the refresh and access tokens, the ABC attack as described does not work.

I am not sure I understand what you mean here, since my belief is still :
Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be unable
to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

    • For something like Age verification, recognizing such attacks, it probably is a bad practice to rely on refresh/access token.
      The service should do more active check, e.g., through OpenID Connect.

Same comment as above.


Denis


Best, 

Nat

On Tue, Nov 8, 2016 at 2:54 AM Denis <denis.ietf@free.fr> wrote:

Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies requirements.
One of them (which, BTW, should be moved into Section 4 - Threats) is :

Collusion:

      Resource servers that collude ...

This threat addresses the case of "collusion between servers" while the case of "collusion between clients"
has not been considered. When access tokens are being used, collusion between clients is of primary importance.

Let us consider the following "Alice and Bob Collusion attack" (ABC attack).

An uncle (Bob) is willing to collaborate with his young niece (Alice) who is less than 18 during a short period of time.
The niece is opening her own session and creates an account on a server. The uncle does not hand over his own session to her niece
at any point of time.

Let us assume that some crypto expert has written two specific pieces of software. One has been installed on the laptop
of the uncle and another one on the laptop of the niece. The two laptops are able to communicate using a network (e.g. a WAN or a LAN).

The niece creates an account on a resource server. Later on, the resource server asks her (or him ?) to demonstrate that she (or his ?)
is more than 18. She forwards the information received from the resource server to her uncle using the network. The uncle receives
that information and connects to an Authorization Server. The uncle requests an access token containing information demonstrating
that he is older than 18 and passed it back to his niece. The niece then presents it to the resource server. The access token is accepted.

Since the niece has been able to demonstrate once that she is more than 18, the resource server will remember this attribute
and in the future she will not need to demonstrate it again. She will keep the advantages related to this attribute associated
with her account on that resource server until she does not need it anymore, i.e. when she will really be over 18.

Whatever kind of cryptographic is being used, when two users collaborate, a software-only solution will be
unable to prevent the transfer of an attribute of a user that possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be ineffective
to counter the Alice and Bob collusion attack. Additional properties will be required for the secure element.

RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 has omitted to take into consideration
the Alice and Bob Collusion attack.

Section 2.3 of the ABC4Trust project about key-binding in Deliverable D2.2 available at:
https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 :

To prevent “credential pooling”, i.e., multiple Users sharing their credentials, credentials can optionally be bound to a secret key,
i.e. a cryptographically strong random value that is assumed to be known only to a particular user. The credential specification
specifies whether the credentials issued according to this specification are to employ key binding or not.

A presentation token derived from such a key-bound credential always contains an implicit proof of knowledge of the underlying secret key,
so that the Verifier can be sure that the rightful owner of the credential was involved in the creation of the presentation token.
As an extra protection layer, the credentials can also be bound to a trusted physical device, such as a smart card, by keeping
the secret key in a protected area of the device. That is, the key cannot be extracted from the device, but the device does participate
in the presentation token generation to include an implicit proof of knowledge of this key in the token. Thus, for credentials that are key-bound
to a physical device it is impossible to create a presentation token without the device.

The rightful owner of the credential was indeed involved in real-time in the creation of the presentation token but in the collaboration scenario,
the key binding mechanism is not sufficient to counter that specific attack. ABC4Trust, Idemix (IBM) and U-Prove (Microsoft) are currently
not resistant to the "ABC attack".

The IRMA card project (https://www.irmacard.org/) based on the use of a smart card and of the Idemix scheme claims to provide security
and privacy simultaneously. However, this project will not be resistant either to the ABC attack.

draft-ietf-oauth-pop-architecture-08 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

The scope of draft-ietf-oauth-token-exchange-06 is limited to the definition of a basic request and response protocol for
an STS-style token exchange utilizing OAuth 2.0. Section 6 (Security Considerations) has omitted to take into consideration
the ABC attack and therefore the currently described "basic request and response protocol" will allow Bob to obtain an access
token and to pass it successfully to Alice so that she can use it.

draft-ietf-oauth-token-exchange-06 should take into consideration the ABC attack.

The threat related to the ABC attack should be identified in the security considerations section
and the core of the document should attempt to identify one or more ways to counter it.

Denis

PS. I have recently registered to the OAuth mailing list.


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

Nat Sakimura

Chairman of the Board, OpenID Foundation



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


--

Nat Sakimura

Chairman of the Board, OpenID Foundation


--------------329BCAAB7E6527255DDC98F0-- From nobody Tue Nov 15 03:50:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15ECB12957A for ; Tue, 15 Nov 2016 03:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvZ8xKqDc3yR for ; Tue, 15 Nov 2016 03:50:11 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9577F129436 for ; Tue, 15 Nov 2016 03:50:11 -0800 (PST) Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id DFA0178036C for ; Tue, 15 Nov 2016 12:50:08 +0100 (CET) From: Denis To: oauth@ietf.org Message-ID: Date: Tue, 15 Nov 2016 12:50:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D47ABB75C172DF7D3E7913DA" Archived-At: Subject: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 11:50:15 -0000 This is a multi-part message in MIME format. --------------D47ABB75C172DF7D3E7913DA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello everybody, Since I am not present at the meeting, I read the minutes from the first session, in particular: Brian Campbell and John did a draft allowing the client to tell the AS where it plans to use the token draft-campbell-oauth-resource-indicators This enables the AS to audience restrict the access token to the resource Phil Hunt: We should keep the audience restriction idea on the table The introduction contains the following sentences: Several years of deployment and implementation experience with OAuth 2.0 [RFC6749] has uncovered a need, in some circumstances, for the client to explicitly signal to the authorization sever where it intends to use the access token it is requesting. A means for the client to signal to the authorization sever where it intends to use the access token it's requesting is important and useful. The document contains a "security considerations" section but unfortunately no "privacy considerations" section. Clause 2 states: The client may indicate the resource server(s) for which it is requesting an access token by including the following parameter in the request. resource OPTIONAL. The value of the resource parameter indicates a resource server where the requested access token will be used.*It MUST be an absolute URI*, as specified by Section 4.3 of[RFC3986], With such an approach, the authorization server would have the ability to *act as a Big Brother *and hence to know exactly where the user will be performing activities. However, some users might be concerned with their privacy, and would like to restrict the use of the access token to some resource servers without the authorization server knowing which are these resource servers. The key point is whether the information is primarily intended to the authorization server or to the resource server(s). I believe that it is primarily intended to the resource server(s) rather than to the authorization server in order to be included in an access token. Obviously, the information needs to transit through the authorization sever, that should simply be copied and pasted into the access token. Its semantics, if any, does not necessarily needs to be interpreted by the authorization sever. I believe that a "privacy considerations" section should be added. The sentence "*It MUST be an absolute URI*, as specified by Section 4.3 of [RFC3986]" should be removed or replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3 of [RFC3986]". Obviously, other changes would be necessary too. Denis --------------D47ABB75C172DF7D3E7913DA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello everybody,

Since I am not present at the meeting, I read the minutes from the first session, in particular:

Brian Campbell and John did a draft allowing the client to tell the AS where it plans to use the token
draft-campbell-oauth-resource-indicators

              This enables the AS to audience restrict the access token to the resource
              Phil Hunt:  We should keep the audience restriction idea on the table

The introduction contains the following sentences:
Several years of deployment and implementation experience with OAuth 2.0 [RFC6749] has uncovered a need, in some circumstances,
for the client to explicitly signal to the authorization sever where it intends to use the access token it is requesting.

A means for the client to signal to the authorization sever where it intends to use the access token it's requesting is important and useful.
The document contains a "security considerations" section but unfortunately no "privacy considerations" section.

Clause 2 states:
The client may indicate the resource server(s) for which it is requesting an access token by including the
following parameter in the request.

resource

OPTIONAL. The value of the resource parameter indicates a resource server where the requested
access token will be used. It MUST be an absolute URI, as specified by Section 4.3 of[RFC3986],
With such an approach, the authorization server would have the ability to act as a Big Brother and hence to know exactly
where the user will be performing activities.

However, some users might be concerned with their privacy, and would like to restrict the use of the access token
to some resource servers without the authorization server knowing which are these resource servers.

The key point is whether the information is primarily intended to the authorization server or to the resource server(s).

I believe that it is primarily intended to the resource server(s) rather than to the authorization server in order to be included
in an access token. Obviously, the information needs to transit through the authorization sever, that should simply be copied
and pasted into the access token. Its semantics, if any, does not necessarily needs to be interpreted by the authorization sever.

I believe that a "privacy considerations" section should be added.

The sentence "It MUST be an absolute URI, as specified by Section 4.3 of [RFC3986]" should be removed or
 replaced by : "It MAY be an absolute URI, as specified by Section 4.3 of [RFC3986]".

Obviously, other changes would be necessary too.

Denis

--------------D47ABB75C172DF7D3E7913DA-- From nobody Tue Nov 15 09:02:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946EA12950A for ; Tue, 15 Nov 2016 09:02:07 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRHmQMrnZmnB for ; Tue, 15 Nov 2016 09:02:05 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE81512943E for ; Tue, 15 Nov 2016 09:02:04 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id g23so179694977wme.1 for ; Tue, 15 Nov 2016 09:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rHpWX3yC8D7ALuAoXMwopxWYv9wJhwi8UkyaAdO4lns=; b=0wSkdH0Z1BcB+xRFyC87ir5bwKwrB0Vu50t0NmG3/mvFbcTGJtofLq2HQ7PcAgFMF+ KXfGh4Mt4MEjqAokvXOE1iSNW7E+01H0cenoqU/ft8QyuEiQ4MU4hX9tPb1x/cZJ44Gj Vvcx5IYPq03gSpKQ1rc4I3/gccvkVvmhyWX+oWA77eBJI/bf50ZNVI1d7/oIGHTpTZrs xJRmN+3fxlXnp9ZlL/wfm30mVY3V0wRRt7ohyeO1zHuXoMK2kluMrUmqfgwS8X6C75W2 U97diNYyjPMfAuD3QCo+tod8FVSrtPf8lSge/nlPrqgt20MXOemx5bzp3t7FTCxVPY+v e9Kw== 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; bh=rHpWX3yC8D7ALuAoXMwopxWYv9wJhwi8UkyaAdO4lns=; b=FqRPNGGZ/iG82DN12g8NllaKDKJH34XO9Ai/kokwDMnDIR6hnw9pvufrvLU53qLJQq hHWPfaO1NgEdVlS0kAwapjP3jNkQ1AjY7KM3cMytmfOMclZRMnJb9dd2tHWyV+YD3yqY dJVMz3ubzLfWmKzOtP6EWgAcx2aE/v8hpGzXsvh7IQfhyX/laeT2tnYPUJXgkNKZsywP Ru8FaGK7MXlHvsU69fZVncC09mBIUVNShpzIoHsUqMBF9QlIkSLJyFnKRBGVok3tMdug Ng6FPIxZuvRTYxv96bClIol1K+fcNolUq1jxzQoIbQYBV6zpMKphM6scuNiXmGmuq12/ Bo8w== X-Gm-Message-State: ABUngvc4py5nCWq6Rx18cBfeknvsaB6oCkSNk1+tw2RbtJrcGMdWH/+VyGL5XERDA/CurzugBu75oO50AVVvuw== X-Received: by 10.194.222.202 with SMTP id qo10mr24761986wjc.115.1479229322517; Tue, 15 Nov 2016 09:02:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.117.103 with HTTP; Tue, 15 Nov 2016 09:02:01 -0800 (PST) In-Reply-To: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> From: Samuel Erdtman Date: Tue, 15 Nov 2016 18:02:01 +0100 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c3ba624fdbfb054159eaf4 Archived-At: Cc: Nat Sakimura via Openid-specs-fapi , OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 17:02:08 -0000 --001a11c3ba624fdbfb054159eaf4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The reason I think it is a workaround to use the jwks or jwks_uri is that you would then wrap the x5u, x5c and/or x5t in a jwk object that you do not really need. So the implementation needs to be aware of how to create and read jwk even though it will not use any of the jwk data. With that said, lets see what others think. On Fri, Nov 11, 2016 at 10:54 PM, Brian Campbell wrote: > From my point of view, the cleaner solution is using existing fields for > what they are well suited rather than inventing new ones. > > On Fri, Nov 11, 2016 at 1:21 PM, Samuel Erdtman wrote= : > >> You are right one could absolutely use the jwks or jwks_uri attribute, >> but from my point of view that would be a workaround. >> I would prefer that x5u, x5c and/or x5t was directly available in the >> client registration request not via jwks. This would be a cleaner soluti= on. >> >> Best Regards >> Samuel >> >> On Fri, 11 Nov 2016 at 19:13, Brian Campbell >> wrote: >> >>> Wouldn't the existing jwks/jwks_uri client metadata parameters suffice? >>> Perhaps some guidance in this document about that is warranted. But I d= on't >>> believe anything new is needed for that case. >>> >>> On Nov 11, 2016 9:41 AM, "Samuel Erdtman" wrote: >>> >>> Just a quick comment, see inline >>> >>> On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer wrote: >>> >>> I agree that the client_id is unlikely to be found inside the >>> certificate itself. The client_id is issued by the authorization server= for >>> the client to use at that single AS. The certificate is issued by the C= A >>> for the client to use on any connection. The AS and CA are not likely t= o be >>> the same system in most deployments. The client will use the same cert >>> across multiple connections, possibly multiple AS's, but the same isn't >>> true of the client_id. >>> >>> Additionally, I think we want to allow for a binding of a self-signed >>> certificate using dynamic registration, much the way that we already al= low >>> binding of a client-generated JWK today. >>> >>> Should this specification then extend the dynamic registration >>> specification (https://tools.ietf.org/html/rfc7591) with the >>> certificate parameter to actually do the registration or is that anothe= r >>> document? >>> >>> >>> I do think that more examples and guidance are warranted, though, to >>> help AS developers. >>> >>> -- Justin >>> >>> On 11/2/2016 5:03 PM, Brian Campbell wrote: >>> >>> >>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman >>> wrote: >>> >>> >>> I agree it is written so that the connection to the certificate is >>> implicitly required but I think it would be better if it was explicit >>> written since the lack of a connection would result in a potential secu= rity >>> hole. >>> >>> >>> That's fair. I agree it can be made more explicit and that it be good t= o >>> do so. >>> >>> >>> >>> When it comes to the client_id I think subject common name or maybe >>> subject serial numbers will be the common location, and I think an exam= ple >>> would be valuable. >>> >>> >>> >>> In my experience and the way we built support for mutual TLS OAuth >>> client auth the client_id value does not appear in the certificate >>> anywhere. I'm not saying it can't happen but don't think it's particula= rly >>> common. >>> >>> I can look at adding some examples, if there's some consensus that >>> they'd be useful and this document moves forward. >>> >>> >>> >>> >>> I=C2=B4m not saying it is a bad Idea just that I would prefer if it was= not a >>> MUST. >>> With very limited addition of code it is just as easy to get the >>> certificate attribute for client id as it is to get it from the HTTP >>> request data (at least in java). I also think that with the requirement= to >>> match the incoming certificate in some way one has to read out the >>> certificate that was used to establish the connection to do some kind o= f >>> matching. >>> >>> >>> Getting data out of the certificate isn't a concern. I just believe tha= t >>> the constancy of having the client id parameter is worth the potential >>> small amount duplicate data in some cases. It's just a -00 draft though= and >>> if the WG wants to proceed with this document, we seek further input an= d >>> work towards some consensus. >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> >>> > --001a11c3ba624fdbfb054159eaf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The reason I think it is a workaround to use the jwk= s or jwks_uri is that you would then wrap the x5u, x5c and/or x5t in a jwk = object that you do not really need. So the implementation needs to be aware= of how to create and read jwk even though it will not use any of the jwk d= ata.

With that said, lets see what others think.

<= br>

On= Fri, Nov 11, 2016 at 10:54 PM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:
From my point of view, the cleaner solution is using existing fiel= ds for what they are well suited rather than inventing new ones.
=

On Fri, Nov 11, 2016 at 1:21 PM, Samuel Erdtman <sa= muel@erdtman.se> wrote:
You are right one could absolutely use the= jwks or jwks_uri attribute, but from my point of view that would be a work= around.
I would prefer that x5u, x5c and/or x5t was directly available i= n the client registration request not via jwks. This would be a cleaner sol= ution.

Best Regards
Samuel

On Fri, 11 Nov 2016 at 19:13, Brian Campbell &l= t;bcampbell= @pingidentity.com> wrote:

Wouldn't the existin= g jwks/jwks_uri client metadata parameters suffice? Perhaps some guidance i= n this document about that is warranted. But I don't believe anything n= ew is needed for that case.


O= n Nov 11, 2016 9:41 AM, "Samuel Erdtman" <samuel@erdtman.se> wrote:
<= div dir=3D"ltr" class=3D"m_8008076844026580120m_4055722970116019915gmail_ms= g">Just a quick comment, see inline

On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <jricher@mit.edu>= wrote:
=20 =20 =20

I agre= e that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client= _id.

Additi= onally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.

= Should this specification then extend the dynamic registration specificatio= n (https://tools.ietf.= org/html/rfc7591) with the certificate parameter to actually do th= e registration or is that another document?
=C2=A0

I do t= hink that more examples and guidance are warranted, though, to help AS developers.

=C2=A0= -- Justin


On 11/2/2016 5:03 PM, Bri= an Campbell wrote:
=20

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel= @erdtman.se> wrote:

I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.

That's fair. I agree it can be made more explicit and that it be good to do so.

=C2=A0
When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
=C2=A0

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly co= mmon.

I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

=C2=A0
I=C2=B4m not saying it is a bad Idea just that I would prefer if it was not a MUST.
With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.


Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 



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




--001a11c3ba624fdbfb054159eaf4-- From nobody Tue Nov 15 09:14:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA9129514 for ; Tue, 15 Nov 2016 09:14:15 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omU7VRrKSwAf for ; Tue, 15 Nov 2016 09:14:13 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BFF12943E for ; Tue, 15 Nov 2016 09:14:12 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id f82so12512259wmf.1 for ; Tue, 15 Nov 2016 09:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AZ+N7O19MfgeeCf3+xRbXzCCun11LfyAkff+vvJHgys=; b=cXo4rm4ZgD4jgcsppvnPtKrdm/qxKZn/z8hjpm8QDjq/YHvTwC0nllDvEsaTrrTbXm XJGy3O1PgjLz4MaVbmoynZTVWeCbsQYgPeuWnHLh8zG4WIE3loGvqGGV4nNa5/vmPHSY VpcNKIbPP6qCE0lmkNO4ITXqn3SIO89uFaeaHUsxHeCNVJHKCtkR8T8nBriWqRKia8gn iIW7amgjFnhYYU2MSvDkY1x28WmUoshliKeFpDxWdsJYlXBK3TiiU9xvrxggieFJyelY rvFnXP9XeHVF4jVI9TCwaEzXMZLwh8SjCnilxs+k4WFsY4kNNWKq/UZkrVFJKXi4Ln2b jLtA== 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; bh=AZ+N7O19MfgeeCf3+xRbXzCCun11LfyAkff+vvJHgys=; b=FeWaoRMRWkQvS8HrFLPRtEqgv7x6tcWRigmZ9syx4Y6JeY153txkMyF0XKQNr2sV9i 0vxuDIF9sGCpHHnyjSKfPEkyzao5zTIz7iArkCC87OCYTuqTU0v6FBbBQp+JQQABsDI/ Z43dfqBjD+Qi5jwSyBN9B8M88bS9ZuIN3nramlPKiYgaflz+JT66U6O/y1MTVF5IiMeo JujgEULubPd8DfZKT9uLxaWX8MlWsXBcNwOi4rZJxv6G75zVYaIzz79BQLD8qE+U64zG 3TTmczGf5BR7PVQZa0xaxAL+hc+w+ygMsdw4r0bYDOgpDMMrqDa1+QYFcuBm/AjEN2Ne C9Yg== X-Gm-Message-State: ABUngvc6T2hChpggm8eDrnLmpFusVpVhiyl9/XXXRIHj4VtXXilivZvOgwhzEqRbH86akOpVZ3ZPunJOJgXQMQ== X-Received: by 10.194.71.228 with SMTP id y4mr29239794wju.136.1479230051254; Tue, 15 Nov 2016 09:14:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.117.103 with HTTP; Tue, 15 Nov 2016 09:14:09 -0800 (PST) In-Reply-To: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> <58280139.2040505@lodderstedt.net> From: Samuel Erdtman Date: Tue, 15 Nov 2016 18:14:09 +0100 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=047d7bfd0e44bf4b0805415a1519 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 17:14:15 -0000 --047d7bfd0e44bf4b0805415a1519 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Torstens questions triggers another question from me. If we have an AS that can handle both certificate client auth and client secret, how does the AS know that it should ask for client certificate on the TLS layer. It was a while since I last read the TLS specification and it might have changed but if i remember correctly client certificates are provided in initial handshake or in re-negotiate and it is only provided on request by the server. If this is still true the AS would need to first get the token request, see that this is a client that authenticates with certificate and request a TLS re-negotiate to get the certificate authentication and a re-submission of the token request since we cannot trust the data first submitted. Are I missing something obvious, or is this something that needs to be defined? //Samuel On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer wrote: > Right =E2=80=94 this is a fine way to put it. RFC7591 defines a client mo= del where > RFC6749 didn=E2=80=99t. Ideally all that metadata would=E2=80=99ve been i= n the original > spec, but it=E2=80=99s not. It doesn=E2=80=99t matter whether the client = was registered > dynamically or statically, it just matters that the AS knows what to expe= ct > from a given client. > > =E2=80=94 Justin > > On Nov 14, 2016, at 6:21 AM, Brian Campbell > wrote: > > Yes, the intend is that the authentication method is determined by client > policy regardless of whether the client was dynamically registered or > statically configured or whatever. I can make that point more explicit in > future revisions of the draft. > > On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> I understand. My point is different: the text seems to assume everybody >> is using client registration, but that's not the case. I would like to >> point out it makes sense to explicitely state the assumption that it is >> determined by client policy (indepedent of the way this policy is >> established). >> >> >> Am 13.11.2016 um 14:24 schrieb Justin Richer: >> >> As part of the client=E2=80=99s registered data model. At least, based o= n how our >> own implementation works (where we support client_secret_basic, >> private_key_jwt, etc), that=E2=80=99s where we=E2=80=99d check to see if= the client was >> supposed to be using TLS auth or not. >> >> We don=E2=80=99t let clients switch away from their registered auth mech= anism. >> >> =E2=80=94 Justin >> >> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt >> wrote: >> >> Justin, >> >> Am 13.11.2016 um 13:39 schrieb Justin Richer: >> >> Torsten, I believe this is intended to be triggered by the >> tls_client_auth value specified in =C2=A73. >> >> >> in the token request? >> >> >> Nit on that section, the field name for the client metadata in RFC7591 i= s >> token_endpoint_auth_method, the _supported version is from the >> corresponding discovery document. >> >> =E2=80=94 Justin >> >> Torsten. >> >> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >> Hi John and Brian, >> >> thanks for writting this draft. >> >> One question: how does the AS determine the authentication method is TLS >> authentication? I think you assume this is defined by the client-specifi= c >> policy, independent of whether the client is registered automatically or >> manually. Would you mind to explicitely state this in the draft? >> >> best regards, >> Torsten. >> >> Am 11.10.2016 um 05:59 schrieb John Bradley: >> >> At the request of the OpenID Foundation Financial Services API Working >> group, Brian Campbell and I have documented >> mutual TLS client authentication. This is something that lots of peopl= e >> do in practice though we have never had a spec for it. >> >> The Banks want to use it for some server to server API use cases being >> driven by new open banking regulation. >> >> The largest thing in the draft is the IANA registration of >> =E2=80=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method f= or use in >> Registration and discovery. >> >> The trust model is intentionally left open so that you could use a >> =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct lo= okup of the subject >> public key against a reregistered value, or something in between. >> >> I hope that this is non controversial and the WG can adopt it quickly. >> >> Regards >> John B. >> >> >> >> >> Begin forwarded message: >> >> *From: * internet-drafts@ietf.org >> *Subject: **New Version Notification for >> draft-campbell-oauth-tls-client-auth-00.txt* >> *Date: *October 10, 2016 at 5:44:39 PM GMT-3 >> *To: *"Brian Campbell" < >> brian.d.campbell@gmail.com>, "John Bradley" < >> ve7jtb@ve7jtb.com> >> >> >> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >> has been successfully submitted by John Bradley and posted to the >> IETF repository. >> >> Name: draft-campbell-oauth-tls-client-auth >> Revision: 00 >> Title: Mutual X.509 Transport Layer Security (TLS) Authentication for >> OAuth Clients >> Document date: 2016-10-10 >> Group: Individual Submission >> Pages: 5 >> URL: >> >> https://www.ietf.org/internet-drafts/draft-campbe >> ll-oauth-tls-client-auth-00.txt >> Status: >> >> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ >> Htmlized: >> >> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 >> >> >> Abstract: >> This document describes X.509 certificates as OAuth client >> credentials using Transport Layer Security (TLS) mutual >> authentication as a mechanism for client authentication to the >> authorization server's token endpoint. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> _______________________________________________ >> 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 > > --047d7bfd0e44bf4b0805415a1519 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Torstens questions triggers another questio= n from me.

If we have an AS that can handle both certificate client= auth and client secret, how does the AS know that it should ask for client= certificate on the TLS layer.

It was a while since I last read the = TLS specification and it might have changed but if i remember correctly cli= ent certificates are provided in initial handshake or in re-negotiate and i= t is only provided on request by the server.

If this is still = true the AS would need to first get the token request, see that this is a c= lient that authenticates with certificate and request a TLS re-negotiate to= get the certificate authentication and a re-submission of the token reques= t since we cannot trust the data first submitted.

Are I missin= g something obvious, or is this something that needs to be defined?

=
//Samuel





=C2=A0

On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer <jricher@m= it.edu> wrote:
Right =E2=80=94 this is a fine way to put it. RFC= 7591 defines a client model where RFC6749 didn=E2=80=99t. Ideally all that = metadata would=E2=80=99ve been in the original spec, but it=E2=80=99s not. = It doesn=E2=80=99t matter whether the client was registered dynamically or = statically, it just matters that the AS knows what to expect from a given c= lient.

=C2=A0=E2=80=94 Justin

On Nov 14, 2016, at 6:21 AM, Brian Campbell <bcampbell@ping= identity.com> wrote:

Yes, the intend is that the authe= ntication method is determined by client policy regardless of whether the c= lient was dynamically registered or statically configured or whatever. I ca= n make that point more explicit in future revisions of the draft.

On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <torste= n@lodderstedt.net> wrote:
=20 =20 =20
I understand. My point is different: the text seems to assume everybody is using client registration, but that's not the case. I would like to point out it makes sense to explicitely state the assumption that it is determined by client policy (indepedent of the way this policy is established).


Am 13.11.2016 um 14:24 schrieb Justin Richer:
=20 As part of the client=E2=80=99s registered data model. At least, base= d on how our own implementation works (where we support client_secret_basic, private_key_jwt, etc), that=E2=80=99s where we= =E2=80=99d check to see if the client was supposed to be using TLS auth or not.

We don=E2=80=99t let clients switch away from their registered auth mechanism.

=C2=A0=E2=80=94 Justin

On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20
Justin,

Am 13.11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe this is intended to be triggered by the tls_client_auth value specified in =C2=A73.

in the token request?


Nit on that section, the field name for the client metadata in RFC7591 is token_endpoint_auth_method, the _supported version is from the corresponding discovery document.

=C2=A0=E2=80=94 Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented=C2=A0
mutual TLS client authentication. =C2=A0 This is something th= at lots of people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of =E2=80=9Ctls_client_auth=E2=80=9D Token End= point authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a =E2=80=9Ccommon name=E2=80=9D a= nd a restricted list of CA or a direct lookup of the subject public key against a reregistered value, =C2=A0or something in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.




Begin forwarded message:

Subject: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
Date: To: = "Brian Campbell" <brian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, draft-campbell-oauth-tls-clien= t-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: draft-campbell-oauth-tls-cl= ient-auth
Revision: 00
Title: Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 2016-10-10
Group: Individual Submission
Pages: 5
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-dr= afts/draft-campbell-oauth-tls-client-auth-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-clie= nt-auth/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0https://tool= s.ietf.org/html/draft-campbell-oauth-tls-client-auth-00


Abstract:
=C2=A0=C2=A0This document describes= X.509 certificates as OAuth client
=C2=A0=C2=A0credentials using Trans= port Layer Security (TLS) mutual
=C2=A0=C2=A0authentication as a mec= hanism for client authentication to the =C2=A0=C2=A0authorization server= 9;s token endpoint.




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.

The IETF Secretariat




___________________________________=
____________
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<= /a>







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


--047d7bfd0e44bf4b0805415a1519-- From nobody Tue Nov 15 15:09:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AB21294CC for ; Tue, 15 Nov 2016 15:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-FuL8GVTCy5 for ; Tue, 15 Nov 2016 15:09:29 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B222129429 for ; Tue, 15 Nov 2016 15:09:29 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id c20so179770805itb.0 for ; Tue, 15 Nov 2016 15:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5NsvHyKyxcwdGywXHYmV9Lo+g9OOHuqdmvLvWZ48SzM=; b=cijBYSpxVS5HnwJqRLw5913Ib0GZoB0ITEi+kFMc8TSMVSpGOMJ6MYnE+Z7RV25dqZ 95cn1ceK6kueIapWx/bo5gbBZTJbtxE3VxK90uHvyp4VJzk6f+fBlaICag0hqwuaqlNC s3Pq1fYVz/Z5CSZmP044IlqSaALFAuqd30Bn4= 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; bh=5NsvHyKyxcwdGywXHYmV9Lo+g9OOHuqdmvLvWZ48SzM=; b=lcArJBbpCeSIANWBvc6YT0YdJcu0vejBoEYJi3e5h8a+0wzeJ4RNPJEW8rAua9EGw2 2cHXY7mIf2nHjF92qUSkkyqfAFfJHj+NS4cjZtq91aMZbOfUo5Wc9IOxV4gGUfBKd+IN pDmICX5OYiEvJD2wf199NDvceyAuay9zulBzh2Xrs5tfBMgtQudOZ2vFsYNsEcrFqJHU qNK97aASDK7fXwFOhdAfzHq51tqTGF4xa6hEpiCM5qWTxTXT8fOH+I+SD9khMbPdThxs 76ZcMqOKKeUdOiKIG9M0BGIXCbuIpCncjgA7pY274DmYMBRPLIWL86wJ0pFTKSDe0rbO Qw5A== X-Gm-Message-State: ABUngvdU1s3f48ekjVb4RVjmjUbdAJnU2lotFLq9oniYQ3TCvpUPaeI2C7225FA8RiHJXIU3oqw7BtxFSoAbGPbk X-Received: by 10.107.13.137 with SMTP id 131mr328853ion.122.1479251367618; Tue, 15 Nov 2016 15:09:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Tue, 15 Nov 2016 15:08:56 -0800 (PST) In-Reply-To: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> <58280139.2040505@lodderstedt.net> From: Brian Campbell Date: Tue, 15 Nov 2016 16:08:56 -0700 Message-ID: To: Samuel Erdtman Content-Type: multipart/alternative; boundary=001a113fdfd44d12b005415f0c94 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 23:09:32 -0000 --001a113fdfd44d12b005415f0c94 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I believe you are correct. Client certificates are provided in the handshake (initial or renegotiated) at the request of the server. If the server asks and the client doesn't provide a cert, it's up to the server whether to continue or about the handshake. There seem to be a number of different ways of trying to deal with this (not strictly for this OAuth case but similar situations). The AS could always request client certs but allow connections to proceed regardless. Then check for certs for appropriate clients while processing token requests. I guess there's a little overhead in the handshake with this for all the connections that won't present a cert. But not a ton. The main drawback is that some/many browsers have UI that will prompt users to choose a cert even when they don't have any. And the user experience can be very bad or confusing as a result. The token endpoint could be on a different host or port which always requests client certs. Still allow connections to proceed regardless and check the client credentials at the OAuth layer. Pretty similar to the above but avoids the usability issues with end users because it's only at the token endpoint. Trying renegotiation after the application sees that it's a token request or that it's a token request from a client id that's configured for mutual TLS is another approach. In my own limited experience with this kind of thing, however, this approach can be kind of flaky. And your point about the initial data not being trustworthy is legitimate. I'm not sure if it really matters in this case. I don't know. And signaling to resubmit is another issue all together. There are probably other approaches too but those are the things I've seen or can imagine. In all (or nearly all) the deployments of our stuff that I know about that deal with mutual TLS, some variation of the second option is used. All this seem like implementation/deployment details though and I'm hesitant to try and define how to do it in this doc. Maybe providing some guidance. I'm not exactly sure how to do that though. On Tue, Nov 15, 2016 at 10:14 AM, Samuel Erdtman wrote: > Torstens questions triggers another question from me. > > If we have an AS that can handle both certificate client auth and client > secret, how does the AS know that it should ask for client certificate on > the TLS layer. > > It was a while since I last read the TLS specification and it might have > changed but if i remember correctly client certificates are provided in > initial handshake or in re-negotiate and it is only provided on request b= y > the server. > > If this is still true the AS would need to first get the token request, > see that this is a client that authenticates with certificate and request= a > TLS re-negotiate to get the certificate authentication and a re-submissio= n > of the token request since we cannot trust the data first submitted. > > Are I missing something obvious, or is this something that needs to be > defined? > > //Samuel > > > > > > > > On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer wrote: > >> Right =E2=80=94 this is a fine way to put it. RFC7591 defines a client m= odel >> where RFC6749 didn=E2=80=99t. Ideally all that metadata would=E2=80=99ve= been in the >> original spec, but it=E2=80=99s not. It doesn=E2=80=99t matter whether t= he client was >> registered dynamically or statically, it just matters that the AS knows >> what to expect from a given client. >> >> =E2=80=94 Justin >> >> On Nov 14, 2016, at 6:21 AM, Brian Campbell >> wrote: >> >> Yes, the intend is that the authentication method is determined by clien= t >> policy regardless of whether the client was dynamically registered or >> statically configured or whatever. I can make that point more explicit i= n >> future revisions of the draft. >> >> On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> I understand. My point is different: the text seems to assume everybody >>> is using client registration, but that's not the case. I would like to >>> point out it makes sense to explicitely state the assumption that it is >>> determined by client policy (indepedent of the way this policy is >>> established). >>> >>> >>> Am 13.11.2016 um 14:24 schrieb Justin Richer: >>> >>> As part of the client=E2=80=99s registered data model. At least, based = on how >>> our own implementation works (where we support client_secret_basic, >>> private_key_jwt, etc), that=E2=80=99s where we=E2=80=99d check to see i= f the client was >>> supposed to be using TLS auth or not. >>> >>> We don=E2=80=99t let clients switch away from their registered auth mec= hanism. >>> >>> =E2=80=94 Justin >>> >>> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>> Justin, >>> >>> Am 13.11.2016 um 13:39 schrieb Justin Richer: >>> >>> Torsten, I believe this is intended to be triggered by the >>> tls_client_auth value specified in =C2=A73. >>> >>> >>> in the token request? >>> >>> >>> Nit on that section, the field name for the client metadata in RFC7591 >>> is token_endpoint_auth_method, the _supported version is from the >>> corresponding discovery document. >>> >>> =E2=80=94 Justin >>> >>> Torsten. >>> >>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>> Hi John and Brian, >>> >>> thanks for writting this draft. >>> >>> One question: how does the AS determine the authentication method is TL= S >>> authentication? I think you assume this is defined by the client-specif= ic >>> policy, independent of whether the client is registered automatically o= r >>> manually. Would you mind to explicitely state this in the draft? >>> >>> best regards, >>> Torsten. >>> >>> Am 11.10.2016 um 05:59 schrieb John Bradley: >>> >>> At the request of the OpenID Foundation Financial Services API Working >>> group, Brian Campbell and I have documented >>> mutual TLS client authentication. This is something that lots of >>> people do in practice though we have never had a spec for it. >>> >>> The Banks want to use it for some server to server API use cases being >>> driven by new open banking regulation. >>> >>> The largest thing in the draft is the IANA registration of >>> =E2=80=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method = for use in >>> Registration and discovery. >>> >>> The trust model is intentionally left open so that you could use a >>> =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct l= ookup of the subject >>> public key against a reregistered value, or something in between. >>> >>> I hope that this is non controversial and the WG can adopt it quickly. >>> >>> Regards >>> John B. >>> >>> >>> >>> >>> Begin forwarded message: >>> >>> *From: * internet-drafts@ietf.org >>> *Subject: **New Version Notification for >>> draft-campbell-oauth-tls-client-auth-00.txt* >>> *Date: *October 10, 2016 at 5:44:39 PM GMT-3 >>> *To: *"Brian Campbell" < >>> brian.d.campbell@gmail.com>, "John Bradley" < >>> ve7jtb@ve7jtb.com> >>> >>> >>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >>> has been successfully submitted by John Bradley and posted to the >>> IETF repository. >>> >>> Name: draft-campbell-oauth-tls-client-auth >>> Revision: 00 >>> Title: Mutual X.509 Transport Layer Security (TLS) Authentication for >>> OAuth Clients >>> Document date: 2016-10-10 >>> Group: Individual Submission >>> Pages: 5 >>> URL: >>> >>> https://www.ietf.org/internet-drafts/draft-campbe >>> ll-oauth-tls-client-auth-00.txt >>> Status: >>> >>> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ >>> Htmlized: >>> >>> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 >>> >>> >>> Abstract: >>> This document describes X.509 certificates as OAuth client >>> credentials using Transport Layer Security (TLS) mutual >>> authentication as a mechanism for client authentication to the >>> authorization server's token endpoint. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> _______________________________________________ >>> 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 >> >> > --001a113fdfd44d12b005415f0c94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I believe you are correct. Client certificates a= re provided in the handshake (initial or renegotiated) at the request of th= e server. If the server asks and the client doesn't provide a cert, it&= #39;s up to the server whether to continue or about the handshake.

=
There seem to be a number of different ways of trying to deal wi= th this (not strictly for this OAuth case but similar situations).

<= /div>
The AS could always request client certs but allow connections to= proceed regardless. Then check for certs for appropriate clients while pro= cessing token requests.=C2=A0 I guess there's a little overhead in the = handshake with this for all the connections that won't present a cert. = But not a ton. The main drawback is that some/many browsers have UI that wi= ll prompt users to choose a cert even when they don't have any. And the= user experience can be very bad or confusing as a result.
The token endpoint could be on a different host or port which = always requests client certs. Still allow connections to proceed regardless= and check the client credentials at the OAuth layer. Pretty similar to the= above but avoids the usability issues with end users because it's only= at the token endpoint.

Trying renegotiation after the a= pplication sees that it's a token request or that it's a token requ= est from a client id that's configured for mutual TLS is another approa= ch. In my own limited experience with this kind of thing, however, this app= roach can be kind of flaky. And your point about the initial data not being= trustworthy is legitimate. I'm not sure if it really matters in this c= ase. I don't know. And signaling to resubmit is another issue all toget= her.

There are probably other approaches too but those a= re the things I've seen or can imagine. In all (or nearly all) the depl= oyments of our stuff that I know about that deal with mutual TLS, some vari= ation of the second option is used.

All this = seem like implementation/deployment details though and I'm hesitant to = try and define how to do it in this doc. Maybe providing some guidance. I&#= 39;m not exactly sure how to do that though.=C2=A0


<= div>

On Tue, Nov 1= 5, 2016 at 10:14 AM, Samuel Erdtman <samuel@erdtman.se> wrot= e:
Torstens questions triggers another question from me.

= If we have an AS that can handle both certificate client auth and client se= cret, how does the AS know that it should ask for client certificate on the= TLS layer.

It was a while since I last read the TLS specification a= nd it might have changed but if i remember correctly client certificates ar= e provided in initial handshake or in re-negotiate and it is only provided = on request by the server.

If this is still true the AS would n= eed to first get the token request, see that this is a client that authenti= cates with certificate and request a TLS re-negotiate to get the certificat= e authentication and a re-submission of the token request since we cannot t= rust the data first submitted.

Are I missing something obvious= , or is this something that needs to be defined?

//Samuel





=C2= =A0

On= Mon, Nov 14, 2016 at 1:26 AM, Justin Richer <jricher@mit.edu> wrote:
Right = =E2=80=94 this is a fine way to put it. RFC7591 defines a client model wher= e RFC6749 didn=E2=80=99t. Ideally all that metadata would=E2=80=99ve been i= n the original spec, but it=E2=80=99s not. It doesn=E2=80=99t matter whethe= r the client was registered dynamically or statically, it just matters that= the AS knows what to expect from a given client.

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

On Nov 1= 4, 2016, at 6:21 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Yes, the in= tend is that the authentication method is determined by client policy regar= dless of whether the client was dynamically registered or statically config= ured or whatever. I can make that point more explicit in future revisions o= f the draft.

On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <torst= en@lodderstedt.net> wrote:
=20 =20 =20
I understand. My point is different: the text seems to assume everybody is using client registration, but that's not the case. I would like to point out it makes sense to explicitely state the assumption that it is determined by client policy (indepedent of the way this policy is established).


Am 13.11.2016 um = 14:24 schrieb Justin Richer:
=20 As part of the client=E2=80=99s registered data model. At least, base= d on how our own implementation works (where we support client_secret_basic, private_key_jwt, etc), that=E2=80=99s where we= =E2=80=99d check to see if the client was supposed to be using TLS auth or not.

We don=E2=80=99t let clients switch away from their registered auth mechanism.

=C2=A0=E2=80=94 Justin

On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20
Justin,

Am 13= .11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe this is intended to be triggered by the tls_client_auth value specified in =C2=A73.

in the token request?


Nit on that section, the field name for the client metadata in RFC7591 is token_endpoint_auth_method, the _supported version is from the corresponding discovery document.

=C2=A0=E2=80=94 Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented=C2=A0
mutual TLS client authentication. =C2=A0 This is something th= at lots of people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of =E2=80=9Ctls_client_auth=E2=80=9D Token End= point authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a =E2=80=9Ccommon name=E2=80=9D a= nd a restricted list of CA or a direct lookup of the subject public key against a reregistered value, =C2=A0or something in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.




Begin forwarded message:

Subj= ect: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
Date= : October 10, 2016 at 5:44:39 PM GMT-3
To: = "Brian Campbell" <b= rian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, draft-campbell-oauth-tls-clien= t-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: = draft-campbell-oauth-tls-client-auth
Revision: 00
Title: = Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 201= 6-10-10
Group: = Individual Submission
Pages: = 5
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0https://datatracke= r.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0https://tools.ietf.org/html/= draft-campbell-oauth-tls-client-auth-00


Abstract:
=C2=A0=C2=A0This document describes= X.509 certificates as OAuth client
=C2=A0=C2=A0credentials using Trans= port Layer Security (TLS) mutual
=C2=A0=C2=A0authentication as a mec= hanism for client authentication to the =C2=A0=C2=A0authorization server= 9;s token endpoint.




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.

The IETF Secretariat




___________________________________=
____________
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



--001a113fdfd44d12b005415f0c94-- From nobody Tue Nov 15 15:12:07 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689631295C8 for ; Tue, 15 Nov 2016 15:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8faIf970m3l0 for ; Tue, 15 Nov 2016 15:12:03 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B6A1295B7 for ; Tue, 15 Nov 2016 15:12:03 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id b123so27349183itb.0 for ; Tue, 15 Nov 2016 15:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YeWCdFFFz73OB/O5iBGBk0AJWqIvYwH4yPkc2BIn7ck=; b=Cwfy/wWTLgJ5l00JlEqTvESA8aOm623a5RKqzSG4BvbOae0nEyUccIe6VJuCr76h7y qupw68iZ2V4OWgzujMx0vjwo+JccyG/jqIRD+l1MUVI1QNP3Yd93Jw7Ta0z3+QpG1z2w Yje/WCCspSvSm7rzsTsy3qtQGsTWNt7d0bBes= 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; bh=YeWCdFFFz73OB/O5iBGBk0AJWqIvYwH4yPkc2BIn7ck=; b=VgPEXZ3g/00b1BUcL7IQ61brd4uLvfJqprFjbcb6Ban6ngYLc8ajqqAagUWx9XYEcm u4OOB7fWLwOnChjlzzsnJvIDKhYU8gEu3vjsKr8ZjTnhb+LJ98Wu7ZAqnCq0+JOX86VE qx9jOvP/8DbnVbI7ZZfkYGZyNIQwL0DzOK921soCN0DeIRBDSvkHvJIZuW4Z6qByppSk v4NlvMPQIadcvExUbJn9vRBl9N9wnGaVrrdkMq9suw3Q+MWc/bPzOZst1SzDTRwyWF+B EEKybEH9wsQJRhJF1v8V0ecaNQNXNYWO83fEuGkfIgagqA/v+PjWOmF/2ZO+GmXmCLu7 YizQ== X-Gm-Message-State: ABUngvfKuGamfBzGIb9PgIeDO+A3zu+j34tsOLoiPRbq5kNCFyzxmKPuJc7I4oD0IMqF7D5vSRJ07vDlx97P+RWy X-Received: by 10.107.141.211 with SMTP id p202mr342813iod.47.1479251522976; Tue, 15 Nov 2016 15:12:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Tue, 15 Nov 2016 15:11:32 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Tue, 15 Nov 2016 16:11:32 -0700 Message-ID: To: Denis Content-Type: multipart/alternative; boundary=94eb2c062c9e8fa2f305415f1597 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 23:12:05 -0000 --94eb2c062c9e8fa2f305415f1597 Content-Type: text/plain; charset=UTF-8 In this document the information is very much intended for the authorization server so that it can make appropriate policy choices about the token to be issued. On Tue, Nov 15, 2016 at 4:50 AM, Denis wrote: > Hello everybody, > > Since I am not present at the meeting, I read the minutes from the first > session, in particular: > > Brian Campbell and John did a draft allowing the client to tell the AS > where it plans to use the token > draft-campbell-oauth-resource-indicators > > This enables the AS to audience restrict the access token to > the resource > Phil Hunt: We should keep the audience restriction idea on > the table > > The introduction contains the following sentences: > > Several years of deployment and implementation experience with OAuth 2.0 > [RFC6749] has uncovered a need, in some circumstances, > for the client to explicitly signal to the authorization sever where it > intends to use the access token it is requesting. > > A means for the client to signal to the authorization sever where it > intends to use the access token it's requesting is important and useful. > > The document contains a "security considerations" section but > unfortunately no "privacy considerations" section. > > Clause 2 states: > > The client may indicate the resource server(s) for which it is requesting > an access token by including the > following parameter in the request. > > resource > > OPTIONAL. The value of the resource parameter indicates a resource server > where the requested > access token will be used.* It MUST be an absolute URI*, as specified by > Section 4.3 of[RFC3986], > > With such an approach, the authorization server would have the ability to *act > as a Big Brother *and hence to know exactly > where the user will be performing activities. > > However, some users might be concerned with their privacy, and would like > to restrict the use of the access token > to some resource servers without the authorization server knowing which > are these resource servers. > > The key point is whether the information is primarily intended to the > authorization server or to the resource server(s). > > I believe that it is primarily intended to the resource server(s) rather > than to the authorization server in order to be included > in an access token. Obviously, the information needs to transit through > the authorization sever, that should simply be copied > and pasted into the access token. Its semantics, if any, does not > necessarily needs to be interpreted by the authorization sever. > > I believe that a "privacy considerations" section should be added. > > The sentence "*It MUST be an absolute URI*, as specified by Section 4.3 > of [RFC3986]" should be removed or > replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3 > of [RFC3986]". > > Obviously, other changes would be necessary too. > > Denis > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c062c9e8fa2f305415f1597 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In this document the information is very much intended for the authorization server so that it can make appropriate policy choic= es about the token to be issued.

<= div class=3D"gmail_quote">On Tue, Nov 15, 2016 at 4:50 AM, Denis <denis.= ietf@free.fr> wrote:
=20 =20 =20

Hello everybody,

Since I am not present at the meeting, I read the minutes from the first session, in particular:

Brian Campbell and Joh= n did a draft allowing the client to tell the AS where it plans to use the token
draft-campbell-oauth-resource-indicators

=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 This enables the AS to audience restrict the access token to the resource
=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 Phil Hunt:=C2=A0 We should keep the audience restriction idea on the table

The introduction contains the following sentences:
Several years of deployment and implementation experience with OAuth 2.0 [RFC6749] has uncovered a need, in some circumstances,
for the client to explicitly signal to the authorization sever where it intends to use the access token it is requesting.

A means for the client to signal to the authorization sever where it intends to use the access token it's requesting is important and useful.
The document contains a "security considerations" section but unfortunately no "privacy considerations" section.

Clause 2 states:
The client may indicate the resource server(s) for which it is requesting an access token by including the
following parameter in the request.

resource

OPTIONAL. The value of the resource parameter indicates a resource server where the requested
access token will be used. It MUST be an absolute URI, as specified by Section 4.3 of[RFC3986],
With such an approach, the authorization server would have the ability to act as a Big Brother and hence to know exactly
where the user will be performing activities.

However, some users might be concerned with their privacy, and would like to restrict the use of the access token
to some resource servers without the authorization server knowing which are these resource servers.

The key point is whether the information is primarily intended to the authorization server or to the resource server(s).

I believe that it is primarily intended to the resource server(s) rather than to the authorization server in order to be included
in an access token. Obviously, the information needs to transit through the authorization sever, that should simply be copied
and pasted into the access token. Its semantics, if any, does not necessarily needs to be interpreted by the authorization sever.

I believe that a "privacy considerations" section should b= e added.

The sentence "It MUST be an absolute URI, as specified b= y Section 4.3 of [RFC3986]" should be removed or
=C2=A0replaced by : "It MAY be an absolute URI, as specif= ied by Section 4.3 of [RFC3986]".

Obviously, other changes would be necessary too.

Denis


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


--94eb2c062c9e8fa2f305415f1597-- From nobody Tue Nov 15 16:03:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E911293D6 for ; Tue, 15 Nov 2016 16:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc0V_hWM6zzL for ; Tue, 15 Nov 2016 16:03:51 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773831293E9 for ; Tue, 15 Nov 2016 16:03:51 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id b123so28949342itb.0 for ; Tue, 15 Nov 2016 16:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gXHh9fvB65HDL4rN18XcUhVsYheRGkVT1XD+9xlGj6g=; b=Wa9QOi6FAaa1exNoMrqMbzIBy8crx9M2o1jsQ5HMkjnrXeOJJ5ARl0xHAbm5QfsHuU 2GVnlco8Yx/irjmz16b426JK7xZ9N4V4gAIxZVjkrmrAUEbXxWHb9IvFKb+Mhc8ySgmc 46AbK8ikpSuyK1Ihkvy/Q+RoKmhwNSwi16Krw= 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; bh=gXHh9fvB65HDL4rN18XcUhVsYheRGkVT1XD+9xlGj6g=; b=Y5rCgwnGd+Ta5OYIA/DIttdafU9u5z/NGQMK1Oj/xBzuWqS7kNAnLeseYORFGgecSw UPiez2HOUuydC20dDZsuX8Rf1GQ/NNsZrGgm8Clvrm2VhvZi++mpAfLKxibS999N7+aq lusovXzOCR6qGcwMlRM+VqXEN5pYH5oCKJ45KAtLgZflMDS4uCJjT1o5HoJeaNASHVC4 To6xu5duB686fJgH/6RsAqeVqQ3CnWY6CklwQeV6PDnDi6D+/kxX8bSU2z/suljHurXf N2zzvTqruHj+1U3SFruZchMHfi5Pn7rJypRlwhGdhp/lwkwZ2wuD34WV9RKN7ehYgNYk femA== X-Gm-Message-State: ABUngvcYe3wTA9jpDp7ZXsPLoNA0DcxU/V6ZMu4XjhqRPBkaM6SabchC5PmA5ALOCmH1KqjoDzUoAXpC7+u7HPha X-Received: by 10.36.31.82 with SMTP id d79mr5422678itd.79.1479254630638; Tue, 15 Nov 2016 16:03:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Tue, 15 Nov 2016 16:03:49 -0800 (PST) Received: by 10.79.156.74 with HTTP; Tue, 15 Nov 2016 16:03:49 -0800 (PST) In-Reply-To: References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> <58280139.2040505@lodderstedt.net> From: Brian Campbell Date: Tue, 15 Nov 2016 17:03:49 -0700 Message-ID: To: Samuel Erdtman Content-Type: multipart/alternative; boundary=001a1145e852cac63c05415fcef9 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 00:03:54 -0000 --001a1145e852cac63c05415fcef9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Whoops, "about" at the end of the 1st paragraph should be "abort". On Nov 16, 2016 8:08 AM, "Brian Campbell" wrote: > Yes, I believe you are correct. Client certificates are provided in the > handshake (initial or renegotiated) at the request of the server. If the > server asks and the client doesn't provide a cert, it's up to the server > whether to continue or about the handshake. > > There seem to be a number of different ways of trying to deal with this > (not strictly for this OAuth case but similar situations). > > The AS could always request client certs but allow connections to proceed > regardless. Then check for certs for appropriate clients while processing > token requests. I guess there's a little overhead in the handshake with > this for all the connections that won't present a cert. But not a ton. Th= e > main drawback is that some/many browsers have UI that will prompt users t= o > choose a cert even when they don't have any. And the user experience can = be > very bad or confusing as a result. > > The token endpoint could be on a different host or port which always > requests client certs. Still allow connections to proceed regardless and > check the client credentials at the OAuth layer. Pretty similar to the > above but avoids the usability issues with end users because it's only at > the token endpoint. > > Trying renegotiation after the application sees that it's a token request > or that it's a token request from a client id that's configured for mutua= l > TLS is another approach. In my own limited experience with this kind of > thing, however, this approach can be kind of flaky. And your point about > the initial data not being trustworthy is legitimate. I'm not sure if it > really matters in this case. I don't know. And signaling to resubmit is > another issue all together. > > There are probably other approaches too but those are the things I've see= n > or can imagine. In all (or nearly all) the deployments of our stuff that = I > know about that deal with mutual TLS, some variation of the second option > is used. > > All this seem like implementation/deployment details though and I'm > hesitant to try and define how to do it in this doc. Maybe providing some > guidance. I'm not exactly sure how to do that though. > > > > On Tue, Nov 15, 2016 at 10:14 AM, Samuel Erdtman > wrote: > >> Torstens questions triggers another question from me. >> >> If we have an AS that can handle both certificate client auth and client >> secret, how does the AS know that it should ask for client certificate o= n >> the TLS layer. >> >> It was a while since I last read the TLS specification and it might have >> changed but if i remember correctly client certificates are provided in >> initial handshake or in re-negotiate and it is only provided on request = by >> the server. >> >> If this is still true the AS would need to first get the token request, >> see that this is a client that authenticates with certificate and reques= t a >> TLS re-negotiate to get the certificate authentication and a re-submissi= on >> of the token request since we cannot trust the data first submitted. >> >> Are I missing something obvious, or is this something that needs to be >> defined? >> >> //Samuel >> >> >> >> >> >> >> >> On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer wrote: >> >>> Right =E2=80=94 this is a fine way to put it. RFC7591 defines a client = model >>> where RFC6749 didn=E2=80=99t. Ideally all that metadata would=E2=80=99v= e been in the >>> original spec, but it=E2=80=99s not. It doesn=E2=80=99t matter whether = the client was >>> registered dynamically or statically, it just matters that the AS knows >>> what to expect from a given client. >>> >>> =E2=80=94 Justin >>> >>> On Nov 14, 2016, at 6:21 AM, Brian Campbell >>> wrote: >>> >>> Yes, the intend is that the authentication method is determined by >>> client policy regardless of whether the client was dynamically register= ed >>> or statically configured or whatever. I can make that point more explic= it >>> in future revisions of the draft. >>> >>> On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>> I understand. My point is different: the text seems to assume everybod= y >>>> is using client registration, but that's not the case. I would like to >>>> point out it makes sense to explicitely state the assumption that it i= s >>>> determined by client policy (indepedent of the way this policy is >>>> established). >>>> >>>> >>>> Am 13.11.2016 um 14:24 schrieb Justin Richer: >>>> >>>> As part of the client=E2=80=99s registered data model. At least, based= on how >>>> our own implementation works (where we support client_secret_basic, >>>> private_key_jwt, etc), that=E2=80=99s where we=E2=80=99d check to see = if the client was >>>> supposed to be using TLS auth or not. >>>> >>>> We don=E2=80=99t let clients switch away from their registered auth me= chanism. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>> Justin, >>>> >>>> Am 13.11.2016 um 13:39 schrieb Justin Richer: >>>> >>>> Torsten, I believe this is intended to be triggered by the >>>> tls_client_auth value specified in =C2=A73. >>>> >>>> >>>> in the token request? >>>> >>>> >>>> Nit on that section, the field name for the client metadata in RFC7591 >>>> is token_endpoint_auth_method, the _supported version is from the >>>> corresponding discovery document. >>>> >>>> =E2=80=94 Justin >>>> >>>> Torsten. >>>> >>>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>> Hi John and Brian, >>>> >>>> thanks for writting this draft. >>>> >>>> One question: how does the AS determine the authentication method is >>>> TLS authentication? I think you assume this is defined by the >>>> client-specific policy, independent of whether the client is registere= d >>>> automatically or manually. Would you mind to explicitely state this in= the >>>> draft? >>>> >>>> best regards, >>>> Torsten. >>>> >>>> Am 11.10.2016 um 05:59 schrieb John Bradley: >>>> >>>> At the request of the OpenID Foundation Financial Services API Working >>>> group, Brian Campbell and I have documented >>>> mutual TLS client authentication. This is something that lots of >>>> people do in practice though we have never had a spec for it. >>>> >>>> The Banks want to use it for some server to server API use cases being >>>> driven by new open banking regulation. >>>> >>>> The largest thing in the draft is the IANA registration of >>>> =E2=80=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method= for use in >>>> Registration and discovery. >>>> >>>> The trust model is intentionally left open so that you could use a >>>> =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct = lookup of the subject >>>> public key against a reregistered value, or something in between. >>>> >>>> I hope that this is non controversial and the WG can adopt it quickly. >>>> >>>> Regards >>>> John B. >>>> >>>> >>>> >>>> >>>> Begin forwarded message: >>>> >>>> *From: * internet-drafts@ietf.org >>>> *Subject: **New Version Notification for >>>> draft-campbell-oauth-tls-client-auth-00.txt* >>>> *Date: *October 10, 2016 at 5:44:39 PM GMT-3 >>>> *To: *"Brian Campbell" < >>>> brian.d.campbell@gmail.com>, "John Bradley" < >>>> ve7jtb@ve7jtb.com> >>>> >>>> >>>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >>>> has been successfully submitted by John Bradley and posted to the >>>> IETF repository. >>>> >>>> Name: draft-campbell-oauth-tls-client-auth >>>> Revision: 00 >>>> Title: Mutual X.509 Transport Layer Security (TLS) Authentication for >>>> OAuth Clients >>>> Document date: 2016-10-10 >>>> Group: Individual Submission >>>> Pages: 5 >>>> URL: >>>> >>>> https://www.ietf.org/internet-drafts/draft-campbe >>>> ll-oauth-tls-client-auth-00.txt >>>> Status: >>>> >>>> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ >>>> Htmlized: >>>> >>>> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 >>>> >>>> >>>> Abstract: >>>> This document describes X.509 certificates as OAuth client >>>> credentials using Transport Layer Security (TLS) mutual >>>> authentication as a mechanism for client authentication to the >>>> authorization server's token endpoint. >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > --001a1145e852cac63c05415fcef9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Whoops, "about" at the end of the 1st paragraph sh= ould be "abort".


On Nov 16, 2016 8= :08 AM, "Brian Campbell" <bcampbell@pingidentity.com> wrote:
Yes, I believe you ar= e correct. Client certificates are provided in the handshake (initial or re= negotiated) at the request of the server. If the server asks and the client= doesn't provide a cert, it's up to the server whether to continue = or about the handshake.

There seem to be a number of dif= ferent ways of trying to deal with this (not strictly for this OAuth case b= ut similar situations).

The AS could always request clien= t certs but allow connections to proceed regardless. Then check for certs f= or appropriate clients while processing token requests.=C2=A0 I guess there= 's a little overhead in the handshake with this for all the connections= that won't present a cert. But not a ton. The main drawback is that so= me/many browsers have UI that will prompt users to choose a cert even when = they don't have any. And the user experience can be very bad or confusi= ng as a result.

The token endpoint could be on= a different host or port which always requests client certs. Still allow c= onnections to proceed regardless and check the client credentials at the OA= uth layer. Pretty similar to the above but avoids the usability issues with= end users because it's only at the token endpoint.

= Trying renegotiation after the application sees that it's a token reque= st or that it's a token request from a client id that's configured = for mutual TLS is another approach. In my own limited experience with this = kind of thing, however, this approach can be kind of flaky. And your point = about the initial data not being trustworthy is legitimate. I'm not sur= e if it really matters in this case. I don't know. And signaling to res= ubmit is another issue all together.

There are probably = other approaches too but those are the things I've seen or can imagine.= In all (or nearly all) the deployments of our stuff that I know about that= deal with mutual TLS, some variation of the second option is used.

All this seem like implementation/deployment details= though and I'm hesitant to try and define how to do it in this doc. Ma= ybe providing some guidance. I'm not exactly sure how to do that though= .=C2=A0



On Tue, Nov 15, 2016 at 10:14 AM, Samuel Erdtman <samue= l@erdtman.se> wrote:
Torstens questions triggers an= other question from me.

If we have an AS that can handle both certi= ficate client auth and client secret, how does the AS know that it should a= sk for client certificate on the TLS layer.

It was a while since I l= ast read the TLS specification and it might have changed but if i remember = correctly client certificates are provided in initial handshake or in re-ne= gotiate and it is only provided on request by the server.

If t= his is still true the AS would need to first get the token request, see tha= t this is a client that authenticates with certificate and request a TLS re= -negotiate to get the certificate authentication and a re-submission of the= token request since we cannot trust the data first submitted.

Are I missing something obvious, or is this something that needs to be def= ined?

//Samuel





=C2= =A0

On Mon, Nov 14, 2016 at 1:26 AM, = Justin Richer <jricher@mit.edu> wrote:
Right =E2=80=94 this is a fine way to pu= t it. RFC7591 defines a client model where RFC6749 didn=E2=80=99t. Ideally = all that metadata would=E2=80=99ve been in the original spec, but it=E2=80= =99s not. It doesn=E2=80=99t matter whether the client was registered dynam= ically or statically, it just matters that the AS knows what to expect from= a given client.

=C2=A0=E2=80=94 Justin

On Nov 14, 2016, at 6:21 AM, Brian Campbe= ll <bcam= pbell@pingidentity.com> wrote:

Yes, the intend is tha= t the authentication method is determined by client policy regardless of wh= ether the client was dynamically registered or statically configured or wha= tever. I can make that point more explicit in future revisions of the draft= .

On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
I understand. My point is different: the text seems to assume everybody is using client registration, but that's not the case. I would like to point out it makes sense to explicitely state the assumption that it is determined by client policy (indepedent of the way this policy is established).


Am 13.11.2016 um 14:24 schrieb Justin Richer:
=20 As part of the client=E2=80=99s registered data model. At least, base= d on how our own implementation works (where we support client_secret_basic, private_key_jwt, etc), that=E2=80=99s where we= =E2=80=99d check to see if the client was supposed to be using TLS auth or not.

We don=E2=80=99t let clients switch away from their registered auth mechanism.

=C2=A0=E2=80=94 Justin

On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20
Justin,

Am 13.11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe this is intended to be triggered by the tls_client_auth value specified in =C2=A73.

in the token request?


Nit on that section, the field name for the client metadata in RFC7591 is token_endpoint_auth_method, the _supported version is from the corresponding discovery document.

=C2=A0=E2=80=94 Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented=C2=A0
mutual TLS client authentication. =C2=A0 This is something th= at lots of people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of =E2=80=9Ctls_client_auth=E2=80=9D Token End= point authentication method for use in Registration and discovery.

The trust model is intentionally left open so that you could use a =E2=80=9Ccommon name=E2=80=9D a= nd a restricted list of CA or a direct lookup of the subject public key against a reregistered value, =C2=A0or something in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.




Begin forwarded message:

Subj= ect: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
Date= : October 10, 2016 at 5:44:39 PM GMT-3
To: = "Brian Campbell" <brian.d.campbell@gmail.com&g= t;, "John Bradley" <ve7jtb@ve7jtb.com>


A new version of I-D, draft-campbell-oauth-tls-clien= t-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name: draft-campbell-oauth-tls-= client-auth
Revision: 00
Title: Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
Document date: 2016-10-10
Group: Individual Submission
Pages: 5
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-d= rafts/draft-campbell-oauth-tls-client-auth-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-cli= ent-auth/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0https://too= ls.ietf.org/html/draft-campbell-oauth-tls-client-auth-00


Abstract:
=C2=A0=C2=A0This document describes= X.509 certificates as OAuth client
=C2=A0=C2=A0credentials using Trans= port Layer Security (TLS) mutual
=C2=A0=C2=A0authentication as a mec= hanism for client authentication to the =C2=A0=C2=A0authorization server= 9;s token endpoint.




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.

The IETF Secretariat




___________________________________=
____________
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



--001a1145e852cac63c05415fcef9-- From nobody Wed Nov 16 00:07:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4C0127058 for ; Wed, 16 Nov 2016 00:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNleKoIkfgn7 for ; Wed, 16 Nov 2016 00:07:08 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0104.outbound.protection.outlook.com [104.47.32.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2D812967D for ; Wed, 16 Nov 2016 00:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xpcMNndQPht7CkiRbK1ZKi+Mp3nr4kE2aeWcS6MH5UY=; b=kh9oazcSM+k2pFggUM7SAlt/R8BtqCmqVJRZZH7+S43hz0mddyHH7OvDcPz421Yhq/rrfSfweZUyvWyBltwbeybfNj9EdLdzsluUQaX7Crc0oAPUj4fQTj2OjjWbw62w8h5HlNRhrsTDk7BgEgy7Tlmesn4wdbjBH9+cPgutwVE= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2353.namprd03.prod.outlook.com (10.166.74.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Wed, 16 Nov 2016 08:07:04 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0721.015; Wed, 16 Nov 2016 08:07:04 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Draft OAuth WG meeting minutes for 3:20-4:20 16-Nov-16 in Seoul Thread-Index: AdI/0mUhJ70MUmR8TP6FZN2Y2mzdTA== Date: Wed, 16 Nov 2016 08:07:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:67c:370:144:4422:9589:299f:2232] x-microsoft-exchange-diagnostics: 1; BN3PR03MB2353; 7:lDzR2f7MGX1aklZuT/FYFoudhiSVDXkqQQBFT6OgqHwUaWeQ6lzFHQ2+5rhQtsL72qiZl6x64GhnbxcvXuWBsw0aij0+AdXIdFjyq0ILAO6ASqcFI2DtoOaxWDWPDIvbXOpSCgENE7xVIxa+dJDvIHbpcAhB/PoJNU6qHm/zMdfEPUCu/UHUFNZATFG3PRQDkT7lxwRNbI9SsCBqyWBm6wLs6h6FmTbiTrwZBatfaFiVNtl2ZKlIOtUTCRcsJhQj0UJ7PV8d31UjUNJjCDTwcQeTVUpi3rieKCnzp/6mv+GcvQahBuf/e5gcDlLJ3VugHiiq575XNuMVBTxt7wLhW06yQ/XxN7ibzztRrCRB11SowzBT25Oihn/FXqZ/PpuG x-ms-office365-filtering-correlation-id: cc8ed2f5-dee7-40ff-e20a-08d40df78d99 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2353; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(788757137089)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6045074)(6040281)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041223)(6046074)(6061324); SRVR:BN3PR03MB2353; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2353; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(106356001)(2900100001)(81156014)(10290500002)(450100001)(97736004)(2351001)(1730700003)(3660700001)(9686002)(5005710100001)(86612001)(6916009)(76576001)(3280700002)(81166006)(33656002)(99286002)(54356999)(6116002)(6506003)(2906002)(790700001)(551934003)(68736007)(92566002)(7846002)(7736002)(230783001)(74316002)(8990500004)(101416001)(105586002)(102836003)(8676002)(189998001)(50986999)(122556002)(10090500001)(7696004)(87936001)(77096005)(5660300001)(86362001)(5640700001)(107886002)(8936002)(5630700001)(2501003)(110136003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2353; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB235514934A5A41E2A7F56F27F5BE0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2016 08:07:04.8036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2353 Archived-At: Subject: [OAUTH-WG] Draft OAuth WG meeting minutes for 3:20-4:20 16-Nov-16 in Seoul X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:07:12 -0000 --_000_BN3PR03MB235514934A5A41E2A7F56F27F5BE0BN3PR03MB2355namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rich Salz helped Hannes Tschofenig run the meeting as a guest facilitator Brian Campbell discussed the status of Token Exchange Hannes: The consensus during the Monday meeting was to gain m= ore implementation experience before WGLC Hannes asked who is implementing or planning to implement Tok= en Exchange Justin Richer Brian Campbell Mike Jones Dick Hardt Tony Nadalin William Denniss expressed an interest in having= Google do so during the previous meeting Torsten Lodderstedt presented about his new draft on security issues reveal= ed by practical OAuth deployments draft-lodderstedt-oauth-security-topics He wants to provide practical guidance to implementers OAuth is used in much more complex and dynamic setups than or= iginally anticipated This is intended to be a working document - not a standard Capture threats and mitigations He plans to refer to other drafts, for instance the mix-up-mi= tigation draft He plans to have there be a list of things that developers ne= ed to do to securely use OAuth Tony Nadalin: We've had a lot of discussions at Microsoft la= tely on the large number of OAuth documents Developers are having problems combining them to= gether and knowing what to implement Tony agrees with what Torsten is trying to do bu= t doesn't think that it's enough Torsten: We're focusing first on documenting the obvious prob= lems We didn't update the security model when we adde= d dynamic registration, for instance There's a need to recommend best practices Tony Nadalin: The many OAuth add-ons are not part of an over= all architecture For instance, PKCE was just a patch solving a pr= oblem we could have avoided up front Ben Kaduk: You should go ahead and do this even without worki= ng group adoption Torsten: I want it to record the conclusions of = the working group - not just my personal opinions Dick Hardt: Why are we starting on this now? Torsten: Because we understand many of the secur= ity best practices now Dick: Why not broaden the scope from security best practices= to OAuth best practices? Torsten: Because it would get huge John Bradley: That's just a document management issue. I sup= port working on best practices. I believe we need to adopt this so that it becom= es an RFC so that it is taken seriously by some stakeholders BCPs should be task-oriented For instance, someone doing a single page applic= ation may not need to be concerned about Token Exchange Hannes: Doing focused BCPs seems more manageable than trying = to do a comprehensive architecture document Torsten: Security practices are cross-cutting Dick: I agree that the security BCP should be all in one pla= ce Torsten: We need feedback on which scenarios and flows matte= r most to people William Denniss: I think it should be a BCP and be an RFC as= soon as possible I like the BCP model of being able to snapshot a= nd revise Hannes: Who is in favor of adopting this as a WG document? At least 15 were in favor and no one opposed Kathleen Moriarty: It looks good Hannes: Let's make OAuth great again Justin Richer presented on the motivations for the HTTP Signing document draft-ietf-oauth-signed-http-request The current spec includes signing, presentation of the token,= and a method for protecting the HTTP request OAuth 2.0 doesn't include HTTP message signing, whereas OAuth= 1.0 did Developers often got signing wrong in OAuth 1.0 Justin's draft is designed for the real world understanding t= hat many things will be changed in transit Therefore, you only sign the things that you kno= w you care about and will be unchanged There are corner cases that the spec does not cover This is all optional The base signature is over the access token plus the nonce/ti= mestamp/transaction-identifier Justin proposes putting the HTTP signing in one document and = the base signature description in another The HTTP signing can be experimental This is a detached signature He proposes to move both documents forward together You need a method to present the PoP token to the resource This would be another presentation method parallel to RFC 675= 0 Justin and a few others have implemented the current approach Ben Kaduk: Do you plan to define discovery? Justin: No. Discovery isn't defined for OAuth a= nd so this work has taken the same position. Hannes: At the Berlin IETF meeting the feeling was that we di= dn't need to do this work anymore Hannes: Who thinks that we should continue this work in this = working group? 6 for 3 against Kathleen Moriarty: Take it to the list Dick Hardt: Has anyone deployed this? Justin: Not in large scale John Bradley: Token presentment without having an audience re= striction for the token doesn't buy you much If we're going to do this work, we should do tha= t too Mike Jones: I'm on record on the mailing list as saying that= I don't think we should be doing this work It's not clear to me that this is worth our time= . We're doing a lot and this takes time away from other things. I haven't seen a groundswell of people wanting t= o deploy this Hannes: Per Kathleen, we need to take it to the list Kathleen: This discussion seems pretty stuck to me John Bradley spoke about the resource indicator specification and other out= standing work There is implementation experience with the resource indicato= r John plans to do a BCP about single-page (JavaScript) applica= tions Torsten: We should focus on the most relevant BCP Tony Nadalin: Single-page applications are not a major focus= within Azure Hannes: I will send a note to the list asking people which BC= Ps they would like to see John: We also have lingering work for using postMessage to re= place fragment encoding postMessage is complicated. It probably requir= es a lot of guidance Torsten: We should ask people whether this is = important to them Mike Jones: The postMessage draft is an individ= ual submission - not a working group document --_000_BN3PR03MB235514934A5A41E2A7F56F27F5BE0BN3PR03MB2355namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rich Salz helped Hannes Tschofenig run the meeting a= s a guest facilitator

 

Brian Campbell discussed the status of Token Exchang= e

        &nbs= p;     Hannes: The consensus during the Monday meeting = was to gain more implementation experience before WGLC

        &nbs= p;     Hannes asked who is implementing or planning to = implement Token Exchange

        &nbs= p;             =       Justin Richer

        &nbs= p;             =       Brian Campbell

        &nbs= p;             =       Mike Jones

        &nbs= p;             =       Dick Hardt

        &nbs= p;             =       Tony Nadalin

        &nbs= p;             =       William Denniss expressed an interest in hav= ing Google do so during the previous meeting

 

Torsten Lodderstedt presented about his new draft on= security issues revealed by practical OAuth deployments

        &nbs= p;     draft-lodderstedt-oauth-security-topics

        &nbs= p;     He wants to provide practical guidance to implem= enters

        &nbs= p;     OAuth is used in much more complex and dynamic s= etups than originally anticipated

        &nbs= p;     This is intended to be a working document –= ; not a standard

        &nbs= p;            &= nbsp;     Capture threats and mitigations

        &nbs= p;     He plans to refer to other drafts, for instance = the mix-up-mitigation draft

        &nbs= p;     He plans to have there be a list of things that = developers need to do to securely use OAuth

        &nbs= p;     Tony Nadalin:  We’ve had a lot of dis= cussions at Microsoft lately on the large number of OAuth documents

        &nbs= p;            &= nbsp;     Developers are having problems combining them= together and knowing what to implement

        &nbs= p;            &= nbsp;     Tony agrees with what Torsten is trying to do= but doesn’t think that it’s enough

        &nbs= p;     Torsten: We’re focusing first on documenti= ng the obvious problems

        &nbs= p;            &= nbsp;     We didn’t update the security model whe= n we added dynamic registration, for instance

        &nbs= p;            &= nbsp;     There’s a need to recommend best practi= ces

        &nbs= p;     Tony Nadalin:  The many OAuth add-ons are n= ot part of an overall architecture

        &nbs= p;            &= nbsp;     For instance, PKCE was just a patch solving a= problem we could have avoided up front

        &nbs= p;     Ben Kaduk: You should go ahead and do this even = without working group adoption

        &nbs= p;            &= nbsp;     Torsten: I want it to record the conclusions = of the working group – not just my personal opinions

        &nbs= p;     Dick Hardt:  Why are we starting on this no= w?

        &nbs= p;            &= nbsp;     Torsten: Because we understand many of the se= curity best practices now

        &nbs= p;     Dick:  Why not broaden the scope from secur= ity best practices to OAuth best practices?

        &nbs= p;            &= nbsp;     Torsten:  Because it would get huge=

        &nbs= p;     John Bradley: That’s just a document manag= ement issue.  I support working on best practices.

        &nbs= p;            &= nbsp;     I believe we need to adopt this so that it be= comes an RFC so that it is taken seriously by some stakeholders<= /p>

        &nbs= p;            &= nbsp;     BCPs should be task-oriented

        &nbs= p;            &= nbsp;     For instance, someone doing a single page app= lication may not need to be concerned about Token Exchange

        &nbs= p;     Hannes: Doing focused BCPs seems more manageable= than trying to do a comprehensive architecture document

        &nbs= p;     Torsten:  Security practices are cross-cutt= ing

        &nbs= p;     Dick:  I agree that the security BCP should= be all in one place

        &nbs= p;     Torsten:  We need feedback on which scenari= os and flows matter most to people

        &nbs= p;     William Denniss:  I think it should be a BC= P and be an RFC as soon as possible

        &nbs= p;            &= nbsp;     I like the BCP model of being able to snapsho= t and revise

 

        &nbs= p;     Hannes: Who is in favor of adopting this as a WG= document?

        &nbs= p;            &= nbsp;     At least 15 were in favor and no one opposed<= o:p>

        &nbs= p;             =       Kathleen Moriarty:  It looks good<= /o:p>

        &nbs= p;     Hannes:  Let’s make OAuth great again=

 

Justin Richer presented on the motivations for the H= TTP Signing document

        &nbs= p;     draft-ietf-oauth-signed-http-request<= /p>

        &nbs= p;     The current spec includes signing, presentation = of the token, and a method for protecting the HTTP request

        &nbs= p;     OAuth 2.0 doesn’t include HTTP message sig= ning, whereas OAuth 1.0 did

        &nbs= p;            &= nbsp;     Developers often got signing wrong in OAuth 1= .0

        &nbs= p;     Justin’s draft is designed for the real wo= rld understanding that many things will be changed in transit

        &nbs= p;            &= nbsp;     Therefore, you only sign the things that you = know you care about and will be unchanged

        &nbs= p;     There are corner cases that the spec does not co= ver

        &nbs= p;     This is all optional

        &nbs= p;     The base signature is over the access token plus= the nonce/timestamp/transaction-identifier

 

        &nbs= p;     Justin proposes putting the HTTP signing in one = document and the base signature description in another

        &nbs= p;            &= nbsp;     The HTTP signing can be experimental

        &nbs= p;            &= nbsp;     This is a detached signature

        &nbs= p;     He proposes to move both documents forward toget= her

        &nbs= p;     You need a method to present the PoP token to th= e resource

        &nbs= p;     This would be another presentation method parall= el to RFC 6750

        &nbs= p;     Justin and a few others have implemented the cur= rent approach

        &nbs= p;     Ben Kaduk: Do you plan to define discovery?=

        &nbs= p;            &= nbsp;     Justin: No.  Discovery isn’t defin= ed for OAuth and so this work has taken the same position.

 

        &nbs= p;     Hannes: At the Berlin IETF meeting the feeling w= as that we didn’t need to do this work anymore

        &nbs= p;     Hannes: Who thinks that we should continue this = work in this working group?

        &nbs= p;            &= nbsp;     6 for

        &nbs= p;            &= nbsp;     3 against

        &nbs= p;     Kathleen Moriarty:  Take it to the list

 

        &nbs= p;     Dick Hardt:  Has anyone deployed this?=

        &nbs= p;            &= nbsp;     Justin: Not in large scale

        &nbs= p;     John Bradley: Token presentment without having a= n audience restriction for the token doesn’t buy you much<= /p>

        &nbs= p;            &= nbsp;     If we’re going to do this work, we shou= ld do that too

        &nbs= p;     Mike Jones:  I’m on record on the mai= ling list as saying that I don’t think we should be doing this work

        &nbs= p;            &= nbsp;     It’s not clear to me that this is worth= our time.  We’re doing a lot and this takes time away from othe= r things.

        &nbs= p;            &= nbsp;     I haven’t seen a groundswell of people = wanting to deploy this

        &nbs= p;     Hannes:  Per Kathleen, we need to take it t= o the list

        &nbs= p;     Kathleen:  This discussion seems pretty stu= ck to me

 

John Bradley spoke about the resource indicator spec= ification and other outstanding work

        &nbs= p;     There is implementation experience with the reso= urce indicator

        &nbs= p;     John plans to do a BCP about single-page (JavaSc= ript) applications

        &nbs= p;     Torsten: We should focus on the most relevant BC= P

        &nbs= p;     Tony Nadalin:  Single-page applications are= not a major focus within Azure

 

        &nbs= p;     Hannes: I will send a note to the list asking pe= ople which BCPs they would like to see

        &nbs= p;     John: We also have lingering work for using post= Message to replace fragment encoding

        &nbs= p;             =       postMessage is complicated.  It probabl= y requires a lot of guidance

        &nbs= p;             =       Torsten:  We should ask people whether = this is important to them

        &nbs= p;            &= nbsp;     Mike Jones:  The postMessage draft is an= individual submission - not a working group document

 

--_000_BN3PR03MB235514934A5A41E2A7F56F27F5BE0BN3PR03MB2355namp_-- From nobody Wed Nov 16 00:47:26 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EEC12956B for ; Wed, 16 Nov 2016 00:47:24 -0800 (PST) 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_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9spW7i8da24M for ; Wed, 16 Nov 2016 00:47:20 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 0897A129426 for ; Wed, 16 Nov 2016 00:47:19 -0800 (PST) Received: from dhcp-898b.meeting.ietf.org (unknown [31.133.137.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3A54822E1FA; Wed, 16 Nov 2016 03:47:13 -0500 (EST) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2016 17:47:09 +0900 Message-Id: <6021A3BB-356B-4A02-AF0A-C6E8A0166609@seantek.com> To: oauth@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-campbell-oauth-tls-client-auth@tools.ietf.org Subject: [OAUTH-WG] draft-campbell-oauth-tls-client-auth-00 feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:47:25 -0000 Hello OAuth folks: I have some feedback about draft-campbell-oauth-tls-client-auth-00. = Overall I think it is a good, concise effort, and should be adopted as a = WG item. Sorry that it didn=E2=80=99t get addressed in the WG meeting. Section 1 mentions =E2=80=9Cshared secret=E2=80=9D as the default in = OAuth 2.0, but this draft provides an alternative that (implicitly) does = not require a shared secret between the client and server components. = However, this draft does not elaborate on the advantages of avoiding = shared secrets: the advantages should be addressed in Section 1 or in = the Security Considerations. In particular, a lot of enterprise = scenarios seem to do intentional man-in-the-middle attacks (aka endpoint = termination) for =E2=80=9Clogging=E2=80=9D and =E2=80=9Cauditing=E2=80=9D = purposes: see the IETF 97 TLS WG meeting materials = . These same = enterprise use cases are significant motivators for eliminating shared = secrets on the wire. Section 5.2 discusses some ideas about associating/binding a certificate = to a client identifier (client_id). I understand that in many use cases, = the certificate and public key will be long-lived and issued by an = authority prior to the client=E2=80=99s contact with the AS; in a = minority of use cases (such as IoT devices), the AS will also issue = certificates to clients. The best and most flexible way to do this is to define an attribute, = let=E2=80=99s say =E2=80=9CoauthClientID=E2=80=9D, of type = VisibleString, which can be multi-valued. By defining it as an = attribute, it can be put in at least four useful protocol slots: 1. Subject Directory Attributes (RFC 5280 Section 4.2.1.8): this is = where metadata about the subject goes that is not part of the = distinguished name. 2. Subject attributes: this is when you want the client_id to be bound = more authoritatively to the certificate, i.e., the utility and lifetime = of the certificate =3D=3D the lifetime of the client/AS association. 3. LDAP attributes: this is where metadata about the subject is = associated together with the certificate, but not part of the = certificate (which is usually in the userCertificate attribute for the = LDAP entry). 4. =E2=80=9Cother places=E2=80=9D where metadata gets associated with = certificates, such as crypto tokens and databases (LDAP, of course, is = just a type of database). By making the attribute multi-valued, one can associate multiple = client_ids with one certificate, which means that the same = certificate/keypair can be used with multiple services. Creating a new attribute is strongly preferable to reusing a field such = as =E2=80=9CcommonName=E2=80=9D, since commonName is overused and can = lead to conflicts (compare with SSL=E2=80=99s legacy use of commonName). = subjectAltName is also not preferable because the client_id itself is = not really a globally unique name; it=E2=80=99s closer to a serial = number or random (but not secret) string. To make it globally unique it = needs to be combined with an identifier for the AS, and that makes such = a structure more complicated. Furthermore, subjectAltName is specific to = being inside a certificate; it does not have semantics outside of a = certificate, whereas a generic directory attribute has equal semantics = inside and outside of certificates. Editorial: there is a typo: Section 5.2: =E2=80=9Cspecifc=E2=80=9D = should be =E2=80=9Cspecific=E2=80=9D. Regards, Sean= From nobody Wed Nov 16 15:18:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E5A1293DB for ; Wed, 16 Nov 2016 15:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNlPr08xrdhO for ; Wed, 16 Nov 2016 15:18:31 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C80A128E18 for ; Wed, 16 Nov 2016 15:18:31 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id l8so98115058iti.1 for ; Wed, 16 Nov 2016 15:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K4ur0gDctW63CIWkODu7R9W+4X1Uz8U+wPgB6IQxMkI=; b=A0JuPGH8jm6VNci7MtMvKYBQJTZhxex5YrS5eyBPCbNNKXHFXT7OqFMPUD/+7FhckX IiJZ+Js9SFp69+/dGNWm3g82rXchg6hcFcutWbuRPOdqlYR/JbDmcaEZyVDTLyaEuuu8 DXmEmwg9SyYhYJ0/vTYTFz1ygA6ATnL/Y0qjs= 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; bh=K4ur0gDctW63CIWkODu7R9W+4X1Uz8U+wPgB6IQxMkI=; b=lw3s7ZcIi0NmkwN69EDTT6vYhdEgHSjBOoZWaMrYuTeD8vi+A9fDZWmNdQU0o9SzF8 WZePPRi6l8TRjt4syvhi2ztNSmWR3L7jWYKD/sUlm00QWA7kKOWSICh3mykCydnp0IqP L7fQ1wfTW01mIC+JyP+IOZCVWR0quaeh7oFvvPvw5HrjgBkMaqkBJgAR7VxyJQqi7Usq AyNCtNH3+Sroeea67a7lRHUrCoHts4lbXZPMT2CzFHROd1yySYemceqwKKAxXdIs9Ltt TWfICMSvlSh31DqF/P6NxeVfh3xAtghDLOAidB4wVPpPsHw3Nvr9oZxr+KyG8miMj9ZX E2LA== X-Gm-Message-State: AKaTC02cQt0sGs5cgo+93xjj4JC88REAo0fEiQxSNn4ZkP6dZPORs8EqhBtVZNe/p9sNAUq4AEZlv17bTGCslUsr X-Received: by 10.107.141.211 with SMTP id p202mr539490iod.47.1479338310352; Wed, 16 Nov 2016 15:18:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.165.24 with HTTP; Wed, 16 Nov 2016 15:17:59 -0800 (PST) In-Reply-To: <6021A3BB-356B-4A02-AF0A-C6E8A0166609@seantek.com> References: <6021A3BB-356B-4A02-AF0A-C6E8A0166609@seantek.com> From: Brian Campbell Date: Wed, 16 Nov 2016 16:17:59 -0700 Message-ID: To: Sean Leonard Content-Type: multipart/alternative; boundary=94eb2c062c9e7df08e0541734a21 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] draft-campbell-oauth-tls-client-auth-00 feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 23:18:34 -0000 --94eb2c062c9e7df08e0541734a21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable inline... On Wed, Nov 16, 2016 at 1:47 AM, Sean Leonard wrote: > Hello OAuth folks: > > I have some feedback about draft-campbell-oauth-tls-client-auth-00. > Overall I think it is a good, concise effort, and should be adopted as a = WG > item. Sorry that it didn=E2=80=99t get addressed in the WG meeting. > Thanks Sean. Some things at the WG meeting ran long and it fell off the back of the list. The slides that would have been presented are in the meeting materials https://www.ietf.org/proceedings/97/slides/slides- 97-oauth-sessb-tls-client-auth-00.pdf if anyone wants to take a look (there's not a whole lot to them though). > > Section 1 mentions =E2=80=9Cshared secret=E2=80=9D as the default in OAut= h 2.0, but this > draft provides an alternative that (implicitly) does not require a shared > secret between the client and server components. However, this draft does > not elaborate on the advantages of avoiding shared secrets: the advantage= s > should be addressed in Section 1 or in the Security Considerations. In > particular, a lot of enterprise scenarios seem to do intentional > man-in-the-middle attacks (aka endpoint termination) for =E2=80=9Clogging= =E2=80=9D and > =E2=80=9Cauditing=E2=80=9D purposes: see the IETF 97 TLS WG meeting mater= ials > . These same > enterprise use cases are significant motivators for eliminating shared > secrets on the wire. > I agree that Section 1 could say more about the motivation/advantages over the shared client secret. I'll look to expand on that in future revisions. Specific proposed text is always welcome too. > Section 5.2 discusses some ideas about associating/binding a certificate > to a client identifier (client_id). I understand that in many use cases, > the certificate and public key will be long-lived and issued by an > authority prior to the client=E2=80=99s contact with the AS; in a minorit= y of use > cases (such as IoT devices), the AS will also issue certificates to clien= ts. > > The best and most flexible way to do this is to define an attribute, let= =E2=80=99s > say =E2=80=9CoauthClientID=E2=80=9D, of type VisibleString, which can be = multi-valued. By > defining it as an attribute, it can be put in at least four useful protoc= ol > slots: > 1. Subject Directory Attributes (RFC 5280 Section 4.2.1.8): this is where > metadata about the subject goes that is not part of the distinguished nam= e. > 2. Subject attributes: this is when you want the client_id to be bound > more authoritatively to the certificate, i.e., the utility and lifetime o= f > the certificate =3D=3D the lifetime of the client/AS association. > 3. LDAP attributes: this is where metadata about the subject is associate= d > together with the certificate, but not part of the certificate (which is > usually in the userCertificate attribute for the LDAP entry). > 4. =E2=80=9Cother places=E2=80=9D where metadata gets associated with cer= tificates, such > as crypto tokens and databases (LDAP, of course, is just a type of > database). > > By making the attribute multi-valued, one can associate multiple > client_ids with one certificate, which means that the same > certificate/keypair can be used with multiple services. > > Creating a new attribute is strongly preferable to reusing a field such a= s > =E2=80=9CcommonName=E2=80=9D, since commonName is overused and can lead t= o conflicts > (compare with SSL=E2=80=99s legacy use of commonName). subjectAltName is = also not > preferable because the client_id itself is not really a globally unique > name; it=E2=80=99s closer to a serial number or random (but not secret) s= tring. To > make it globally unique it needs to be combined with an identifier for th= e > AS, and that makes such a structure more complicated. Furthermore, > subjectAltName is specific to being inside a certificate; it does not hav= e > semantics outside of a certificate, whereas a generic directory attribute > has equal semantics inside and outside of certificates. > I believe that the specifics of if and how a client id is represented in a certificate is well beyond the scope of this document. But maybe some considerations or guidance about using an attribute would be appropriate in describing one possible way to do the binding between client and certificate, if you wanted to propose some specific text. > Editorial: there is a typo: Section 5.2: =E2=80=9Cspecifc=E2=80=9D should= be =E2=80=9Cspecific=E2=80=9D. > Will fix. Thanks. > > Regards, > > Sean > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --94eb2c062c9e7df08e0541734a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
inline...

On Wed, Nov 16, 2016 at 1:47 AM, Sean Leonard <d= ev+ietf@seantek.com> wrote:
Hello OAuth folks:

I have some feedback about draft-campbell-oauth-tls-client-auth-00. Ov= erall I think it is a good, concise effort, and should be adopted as a WG i= tem. Sorry that it didn=E2=80=99t get addressed in the WG meeting.

Thanks Sean. Some things at the WG meeting ran = long and it fell off the back of the list. The slides that would have been = presented are in the meeting materials https://www.ietf.org/proceedings/97/slides/slides-97-oauth= -sessb-tls-client-auth-00.pdf if anyone wants to take a look (ther= e's not a whole lot to them though).
=C2=A0

Section 1 mentions =E2=80=9Cshared secret=E2=80=9D as the default in OAuth = 2.0, but this draft provides an alternative that (implicitly) does not requ= ire a shared secret between the client and server components. However, this= draft does not elaborate on the advantages of avoiding shared secrets: the= advantages should be addressed in Section 1 or in the Security Considerati= ons. In particular, a lot of enterprise scenarios seem to do intentional ma= n-in-the-middle attacks (aka endpoint termination) for =E2=80=9Clogging=E2= =80=9D and =E2=80=9Cauditing=E2=80=9D purposes: see the IETF 97 TLS WG meet= ing materials <slides-97-tls-tls-visibility-inside-the-data-center&= gt;. These same enterprise use cases are significant motivators for elimina= ting shared secrets on the wire.

I agre= e that Section 1 could say more about the motivation/advantages over the sh= ared client secret. I'll look to expand on that in future revisions. Sp= ecific proposed text is always welcome too.
=C2=A0
Section 5.2 discusses some ideas about associating/binding a certificate to= a client identifier (client_id). I understand that in many use cases, the = certificate and public key will be long-lived and issued by an authority pr= ior to the client=E2=80=99s contact with the AS; in a minority of use cases= (such as IoT devices), the AS will also issue certificates to clients.

The best and most flexible way to do this is to define an attribute, let=E2= =80=99s say =E2=80=9CoauthClientID=E2=80=9D, of type VisibleString, which c= an be multi-valued. By defining it as an attribute, it can be put in at lea= st four useful protocol slots:
1. Subject Directory Attributes (RFC 5280 Section 4.2.1.8): this is where m= etadata about the subject goes that is not part of the distinguished name.<= br> 2. Subject attributes: this is when you want the client_id to be bound more= authoritatively to the certificate, i.e., the utility and lifetime of the = certificate =3D=3D the lifetime of the client/AS association.
3. LDAP attributes: this is where metadata about the subject is associated = together with the certificate, but not part of the certificate (which is us= ually in the userCertificate attribute for the LDAP entry).
4. =E2=80=9Cother places=E2=80=9D where metadata gets associated with certi= ficates, such as crypto tokens and databases (LDAP, of course, is just a ty= pe of database).

By making the attribute multi-valued, one can associate multiple client_ids= with one certificate, which means that the same certificate/keypair can be= used with multiple services.

Creating a new attribute is strongly preferable to reusing a field such as = =E2=80=9CcommonName=E2=80=9D, since commonName is overused and can lead to = conflicts (compare with SSL=E2=80=99s legacy use of commonName). subjectAlt= Name is also not preferable because the client_id itself is not really a gl= obally unique name; it=E2=80=99s closer to a serial number or random (but n= ot secret) string. To make it globally unique it needs to be combined with = an identifier for the AS, and that makes such a structure more complicated.= Furthermore, subjectAltName is specific to being inside a certificate; it = does not have semantics outside of a certificate, whereas a generic directo= ry attribute has equal semantics inside and outside of certificates.

I believe that the specifics of if and how a = client id is represented in a certificate is well beyond the scope of this = document.=C2=A0 But maybe some considerations or guidance about using an at= tribute would be appropriate in describing one possible way to do the bindi= ng between client and certificate, if you wanted to propose some specific t= ext.=C2=A0 =C2=A0

=C2=A0
Editorial: there is a typo: Section 5.2: =E2=80=9Cspecifc=E2=80=9D should b= e =E2=80=9Cspecific=E2=80=9D.

Will fix.= Thanks.

=C2=A0

Regards,

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

--94eb2c062c9e7df08e0541734a21-- From nobody Wed Nov 16 16:51:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586E9129606 for ; Wed, 16 Nov 2016 16:51:31 -0800 (PST) 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_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCi6YYrtVbsF for ; Wed, 16 Nov 2016 16:51:23 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 222471295D6 for ; Wed, 16 Nov 2016 16:51:22 -0800 (PST) Received: from dhcp-898b.meeting.ietf.org (unknown [31.133.137.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D29A022E253; Wed, 16 Nov 2016 19:51:15 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_20357369-F08F-4AC3-860A-94D1A49D119F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Thu, 17 Nov 2016 09:51:20 +0900 Message-Id: <97B6E31A-4B35-4CC4-B409-66C64A11A07D@seantek.com> References: <6021A3BB-356B-4A02-AF0A-C6E8A0166609@seantek.com> To: Brian Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] draft-campbell-oauth-tls-client-auth-00 feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:51:31 -0000 --Apple-Mail=_20357369-F08F-4AC3-860A-94D1A49D119F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 17, 2016, at 8:17 AM, Brian Campbell = wrote: >=20 > inline... >=20 > On Wed, Nov 16, 2016 at 1:47 AM, Sean Leonard > wrote: > Hello OAuth folks: >=20 > I have some feedback about draft-campbell-oauth-tls-client-auth-00. = Overall I think it is a good, concise effort, and should be adopted as a = WG item. Sorry that it didn=E2=80=99t get addressed in the WG meeting. >=20 > Thanks Sean. Some things at the WG meeting ran long and it fell off = the back of the list. The slides that would have been presented are in = the meeting materials = https://www.ietf.org/proceedings/97/slides/slides-97-oauth-sessb-tls-clien= t-auth-00.pdf = if anyone wants to take a look (there's not a whole lot = to them though).=20 > =20 >=20 > Section 1 mentions =E2=80=9Cshared secret=E2=80=9D as the default in = OAuth 2.0, but this draft provides an alternative that (implicitly) does = not require a shared secret between the client and server components. = However, this draft does not elaborate on the advantages of avoiding = shared secrets: the advantages should be addressed in Section 1 or in = the Security Considerations. In particular, a lot of enterprise = scenarios seem to do intentional man-in-the-middle attacks (aka endpoint = termination) for =E2=80=9Clogging=E2=80=9D and =E2=80=9Cauditing=E2=80=9D = purposes: see the IETF 97 TLS WG meeting materials = . These same = enterprise use cases are significant motivators for eliminating shared = secrets on the wire. >=20 > I agree that Section 1 could say more about the motivation/advantages = over the shared client secret. I'll look to expand on that in future = revisions. Specific proposed text is always welcome too.=20 > =20 > Section 5.2 discusses some ideas about associating/binding a = certificate to a client identifier (client_id). I understand that in = many use cases, the certificate and public key will be long-lived and = issued by an authority prior to the client=E2=80=99s contact with the = AS; in a minority of use cases (such as IoT devices), the AS will also = issue certificates to clients. >=20 > The best and most flexible way to do this is to define an attribute, = let=E2=80=99s say =E2=80=9CoauthClientID=E2=80=9D, of type = VisibleString, which can be multi-valued. By defining it as an = attribute, it can be put in at least four useful protocol slots: > 1. Subject Directory Attributes (RFC 5280 Section 4.2.1.8): this is = where metadata about the subject goes that is not part of the = distinguished name. > 2. Subject attributes: this is when you want the client_id to be bound = more authoritatively to the certificate, i.e., the utility and lifetime = of the certificate =3D=3D the lifetime of the client/AS association. > 3. LDAP attributes: this is where metadata about the subject is = associated together with the certificate, but not part of the = certificate (which is usually in the userCertificate attribute for the = LDAP entry). > 4. =E2=80=9Cother places=E2=80=9D where metadata gets associated with = certificates, such as crypto tokens and databases (LDAP, of course, is = just a type of database). >=20 > By making the attribute multi-valued, one can associate multiple = client_ids with one certificate, which means that the same = certificate/keypair can be used with multiple services. >=20 > Creating a new attribute is strongly preferable to reusing a field = such as =E2=80=9CcommonName=E2=80=9D, since commonName is overused and = can lead to conflicts (compare with SSL=E2=80=99s legacy use of = commonName). subjectAltName is also not preferable because the client_id = itself is not really a globally unique name; it=E2=80=99s closer to a = serial number or random (but not secret) string. To make it globally = unique it needs to be combined with an identifier for the AS, and that = makes such a structure more complicated. Furthermore, subjectAltName is = specific to being inside a certificate; it does not have semantics = outside of a certificate, whereas a generic directory attribute has = equal semantics inside and outside of certificates. >=20 > I believe that the specifics of if and how a client id is represented = in a certificate is well beyond the scope of this document. But maybe = some considerations or guidance about using an attribute would be = appropriate in describing one possible way to do the binding between = client and certificate, if you wanted to propose some specific text. =20= Sure, I can propose some specific text along those lines. I will try to = supply something over the next few weeks. Best regards, Sean >=20 > =20 > Editorial: there is a typo: Section 5.2: =E2=80=9Cspecifc=E2=80=9D = should be =E2=80=9Cspecific=E2=80=9D. >=20 > Will fix. Thanks.=20 >=20 > =20 >=20 > Regards, >=20 > Sean > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_20357369-F08F-4AC3-860A-94D1A49D119F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 17, 2016, at 8:17 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

inline...

On Wed, = Nov 16, 2016 at 1:47 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
Hello = OAuth folks:

I have some feedback about draft-campbell-oauth-tls-client-auth-00. Overall I think it is a good, concise effort, and = should be adopted as a WG item. Sorry that it didn=E2=80=99t get = addressed in the WG meeting.

Thanks Sean. Some things = at the WG meeting ran long and it fell off the back of the list. The = slides that would have been presented are in the meeting materials https://www.ietf.org/proceedings/97/slides/slides-97-oauth-sessb-tls-client-auth-00.pdf if = anyone wants to take a look (there's not a whole lot to them though). =
 

Section 1 mentions =E2=80=9Cshared secret=E2=80=9D as the default in = OAuth 2.0, but this draft provides an alternative that (implicitly) does = not require a shared secret between the client and server components. = However, this draft does not elaborate on the advantages of avoiding = shared secrets: the advantages should be addressed in Section 1 or in = the Security Considerations. In particular, a lot of enterprise = scenarios seem to do intentional man-in-the-middle attacks (aka endpoint = termination) for =E2=80=9Clogging=E2=80=9D and =E2=80=9Cauditing=E2=80=9D = purposes: see the IETF 97 TLS WG meeting materials = <slides-97-tls-tls-visibility-inside-the-data-center>. These same enterprise use cases = are significant motivators for eliminating shared secrets on the = wire.

I agree that Section 1 could say more about the = motivation/advantages over the shared client secret. I'll look to expand = on that in future revisions. Specific proposed text is always welcome = too.
 
Section 5.2 discusses some ideas about associating/binding a certificate = to a client identifier (client_id). I understand that in many use cases, = the certificate and public key will be long-lived and issued by an = authority prior to the client=E2=80=99s contact with the AS; in a = minority of use cases (such as IoT devices), the AS will also issue = certificates to clients.

The best and most flexible way to do this is to define an attribute, = let=E2=80=99s say =E2=80=9CoauthClientID=E2=80=9D, of type = VisibleString, which can be multi-valued. By defining it as an = attribute, it can be put in at least four useful protocol slots:
1. Subject Directory Attributes (RFC 5280 Section 4.2.1.8): this is = where metadata about the subject goes that is not part of the = distinguished name.
2. Subject attributes: this is when you want the client_id to be bound = more authoritatively to the certificate, i.e., the utility and lifetime = of the certificate =3D=3D the lifetime of the client/AS association.
3. LDAP attributes: this is where metadata about the subject is = associated together with the certificate, but not part of the = certificate (which is usually in the userCertificate attribute for the = LDAP entry).
4. =E2=80=9Cother places=E2=80=9D where metadata gets associated with = certificates, such as crypto tokens and databases (LDAP, of course, is = just a type of database).

By making the attribute multi-valued, one can associate multiple = client_ids with one certificate, which means that the same = certificate/keypair can be used with multiple services.

Creating a new attribute is strongly preferable to reusing a field such = as =E2=80=9CcommonName=E2=80=9D, since commonName is overused and can = lead to conflicts (compare with SSL=E2=80=99s legacy use of commonName). = subjectAltName is also not preferable because the client_id itself is = not really a globally unique name; it=E2=80=99s closer to a serial = number or random (but not secret) string. To make it globally unique it = needs to be combined with an identifier for the AS, and that makes such = a structure more complicated. Furthermore, subjectAltName is specific to = being inside a certificate; it does not have semantics outside of a = certificate, whereas a generic directory attribute has equal semantics = inside and outside of certificates.

I believe that the = specifics of if and how a client id is represented in a certificate is = well beyond the scope of this document.  But maybe some = considerations or guidance about using an attribute would be appropriate = in describing one possible way to do the binding between client and = certificate, if you wanted to propose some specific text.    =

Sure, I can propose some specific text along those = lines. I will try to supply something over the next few = weeks.

Best regards,

Sean


 
Editorial: there is a typo: Section 5.2: =E2=80=9Cspecifc=E2=80=9D = should be =E2=80=9Cspecific=E2=80=9D.

Will fix. Thanks.

 

Regards,

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


= --Apple-Mail=_20357369-F08F-4AC3-860A-94D1A49D119F-- From nobody Thu Nov 17 10:23:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637301299CF for ; Thu, 17 Nov 2016 10:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.688 X-Spam-Level: X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_0ymJzMDk7i for ; Thu, 17 Nov 2016 10:23:17 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93030129585 for ; Thu, 17 Nov 2016 10:23:17 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uAHINDUL011119 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Nov 2016 18:23:14 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id uAHINDVE012537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Nov 2016 18:23:13 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id uAHINCxB001080; Thu, 17 Nov 2016 18:23:12 GMT MIME-Version: 1.0 Message-ID: Date: Thu, 17 Nov 2016 10:23:11 -0800 (PST) From: Vivek Biswas Sender: Vivek Biswas To: Denis , oauth@ietf.org References: In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 15.0.4551.0 (x86)] Content-Type: multipart/alternative; boundary="__1479406992616251845abhmp0009.oracle.com" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 18:23:20 -0000 --__1479406992616251845abhmp0009.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to It MAY be an absolute URI, as specified by Section 4.3 of [RFC3986]". Since the Audience Restriction can be a logical name to be interpreted by t= he Resource Server, if it really wants to enforce the audience check for a = set of Resources it wants to protect. Hence, a logical name can be an absolute URI or a String as well. Regards Vivek Biswas, CISSP Consulting Member, Security Oracle Corporation. =C2=A0 From: Denis [mailto:denis.ietf@free.fr]=20 Sent: Tuesday, November 15, 2016 3:50 AM To: oauth@ietf.org Subject: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-ind= icators-00 =C2=A0 Hello everybody, Since I am not present at the meeting, I read the minutes from the first se= ssion, in particular: Brian Campbell and John did a draft allowing the client to tell the AS wher= e it plans to use the token draft-campbell-oauth-resource-indicators =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 This enables the AS to audience restrict the access token to the resour= ce =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 Phil Hunt:=C2=A0 We should keep the audience restriction idea on the ta= ble The introduction contains the following sentences: Several years of deployment and implementation experience with OAuth 2.0 [R= FC6749] has uncovered a need, in some circumstances,=20 for the client to explicitly signal to the authorization sever where it int= ends to use the access token it is requesting. A means for the client to signal to the authorization sever where it intend= s to use the access token it's requesting is important and useful.=20 The document contains a "security considerations" section but unfortunately= no "privacy considerations" section. Clause 2 states: The client may indicate the resource server(s) for which it is requesting a= n access token by including the following parameter in the request. resource OPTIONAL. The value of the resource parameter indicates a resource server w= here the requested access token will be used. It MUST be an absolute URI, as specified by Sect= ion 4.3 of[RFC3986], With such an approach, the authorization server would have the ability to a= ct as a Big Brother and hence to know exactly=20 where the user will be performing activities. However, some users might be concerned with their privacy, and would like t= o restrict the use of the access token=20 to some resource servers without the authorization server knowing which are= these resource servers.=20 The key point is whether the information is primarily intended to the autho= rization server or to the resource server(s). I believe that it is primarily intended to the resource server(s) rather th= an to the authorization server in order to be included=20 in an access token. Obviously, the information needs to transit through the= authorization sever, that should simply be copied=20 and pasted into the access token. Its semantics, if any, does not necessari= ly needs to be interpreted by the authorization sever. I believe that a "privacy considerations" section should be added.=20 The sentence "It MUST be an absolute URI, as specified by Section 4.3 of [R= FC3986]" should be removed or=20 =C2=A0replaced by : "It MAY be an absolute URI, as specified by Section 4.3= of [RFC3986]". Obviously, other changes would be necessary too. Denis --__1479406992616251845abhmp0009.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

+1 = to It MAY be an absolute URI, as specified by Section 4.3 of = [RFC3986]".

Since the Audience Restriction can be a l= ogical name to be interpreted by the Resource Server, if it really wants to= enforce the audience check for a set of Resources it wants to protect.
= Hence, a logical name can be an absolute URI or a String as well.

Regards
Vivek Biswas, CISSP
Consulting Member, Security
Or= acle Corporation.

&n= bsp;

From:<= /span> Denis [mailto:denis.ietf@free.fr]
Sent: Tue= sday, November 15, 2016 3:50 AM
To: oauth@ietf.org
Subject:= [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicat= ors-00

 

Hello everybody,

Since I am not present at the m= eeting, I read the minutes from the first session, in particular:

Brian Campbell and John did a draft allowing the = client to tell the AS where it plans to use the token
draft-campbell-oau= th-resource-indicators

           &nb= sp;  This enables the AS to audience restrict the access token to the = resource
          &nb= sp;   Phil Hunt:  We should keep the audience restriction id= ea on the table

The = introduction contains the following sentences:

Several years of deployment and implementation experie= nce with OAuth 2.0 [RFC6749] has uncovered a need, in some circumstances, <= br>for the client to explicitly signal to the authorization sever where it = intends to use the access token it is requesting.

A means for the cl= ient to signal to the authorization sever where it intends to use the acces= s token it's requesting is important and useful.

The document contains a "security consid= erations" section but unfortunately no "privacy considerations&qu= ot; section.

Clause 2 states:

The client may indicate the resource server(s) for which it is r= equesting an access token by including the
following parameter in the re= quest.

resource

OPTIONAL. The value of the resource parameter= indicates a resource server where the requested
access token will be us= ed. It MUST be an absolute URI, as specified by Section 4.3 of[RFC39= 86],

With such an ap= proach, the authorization server would have the ability to act as a Big = Brother and hence to know exactly
where the user will be performing= activities.

However, some users might be concerned with t= heir privacy, and would like to restrict the use of the access token
to= some resource servers without the authorization server knowing which are t= hese resource servers.

The key point is whether the infor= mation is primarily intended to the authorization server or to the resource= server(s).

I believe that it is primarily intended to the= resource server(s) rather than to the authorization server in order to be = included
in an access token. Obviously, the information needs to transi= t through the authorization sever, that should simply be copied
and pas= ted into the access token. Its semantics, if any, does not necessarily need= s to be interpreted by the authorization sever.

I believe = that a "privacy considerations" section should be added.

The sentence "It MUST be an absolute URI, as specifie= d by Section 4.3 of [RFC3986]" should be removed or
 replaced= by : "It MAY be an absolute URI, as specified by Section 4.3 o= f [RFC3986]".

Obviously, other changes would be neces= sary too.

Denis

--__1479406992616251845abhmp0009.oracle.com-- From nobody Thu Nov 17 11:26:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334E212959B for ; Thu, 17 Nov 2016 11:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HivoVjXtagJk for ; Thu, 17 Nov 2016 11:25:56 -0800 (PST) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33FE12952D for ; Thu, 17 Nov 2016 11:25:56 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id a184so71016264ybb.0 for ; Thu, 17 Nov 2016 11:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=lKwovQDzGyEHtMBLmxSjUpGGGFgusWr7sH0O7OwtHa4=; b=tu0pZLJo/jP0MfXj9uqJvGTiD/bgNZ5w748bHN2Zjr9m5ULr8f/QzCxByuAVe26ENJ OhrOaxRJIPtwSYyjDPMW9b7cAdKORQnytosgC66oWVTLjjo/UbrowylDAq7iucwn0XNv /mPC/5I+PFlNMKEzc1De/1pHrUuqsT/995pXdEvk9HuysOeUO0UpjRQeD4G6LPPjYyd2 DV5DZAQJjocziFNRWmw/JFiwN5sYEFhREc6W4FvT0UyuV1HAneY/XNzh433ML2q7kK+V 87T3BRxRLRIf69FpjDgqJnejsthEOyqhX8ubOGpmYNX4k4VarOhIE+eDuk1mukrm0b4D wv1g== 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; bh=lKwovQDzGyEHtMBLmxSjUpGGGFgusWr7sH0O7OwtHa4=; b=N3UaiZEYrttX+Jixstti+NHvWhhBzCwE4mETJb2Ij15JO0rwchRjYfBUxAe9IS2mxA xf+1COLM4uSWtL6MPS7rkyasW9quYgOKHH5jjQo8SdOxgE64kDiUuTJkUuq3Fg204nuJ e+unO9bCdA31GvCeOKTRAuY/0TXRCi1ixLqy1O2HEEPWWls06HfyIhgOunDQfoJTDONt M5B8JZQWDsblAwCSg1jD/5+UIVfZA8xIGTQODTDVyXQq+k6ix0hIitrnarFJhSqTAve2 7xrrizFPreN0M8Q9wwCfxqOZA/CJtWDNQ5uT8JmiXpfE//L5gfZyKwwbyOhcwfWTMq+D CInQ== X-Gm-Message-State: AKaTC03Ku2tQK4FtcdmRAh7ZV8ditSOx1+6s9QsyGO7kdvZzYTOLUM+XbSvVi1ds3yxxX9WlnBsw0DKoXaKLonwM X-Received: by 10.13.225.132 with SMTP id k126mr4187703ywe.40.1479410755626; Thu, 17 Nov 2016 11:25:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.234.14 with HTTP; Thu, 17 Nov 2016 11:25:15 -0800 (PST) In-Reply-To: References: From: Jim Willeke Date: Thu, 17 Nov 2016 11:25:15 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07709a913026054184280b Archived-At: Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 19:25:59 -0000 --94eb2c07709a913026054184280b Content-Type: text/plain; charset=UTF-8 I liked the usage in https://tools.ietf.org/html/rfc7515 Collision-Resistant Name A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122 ]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name. -- -jim Jim Willeke On Thu, Nov 17, 2016 at 10:23 AM, Vivek Biswas wrote: > +1 to *It MAY be an absolute URI*, as specified by Section 4.3 of > [RFC3986]". > > Since the Audience Restriction can be a logical name to be interpreted by > the Resource Server, if it really wants to enforce the audience check for a > set of Resources it wants to protect. > Hence, a logical name can be an absolute URI or a String as well. > > Regards > Vivek Biswas, CISSP > Consulting Member, Security > Oracle Corporation. > > > > *From:* Denis [mailto:denis.ietf@free.fr] > *Sent:* Tuesday, November 15, 2016 3:50 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource- > indicators-00 > > > > Hello everybody, > > Since I am not present at the meeting, I read the minutes from the first > session, in particular: > > Brian Campbell and John did a draft allowing the client to tell the AS > where it plans to use the token > draft-campbell-oauth-resource-indicators > > This enables the AS to audience restrict the access token to > the resource > Phil Hunt: We should keep the audience restriction idea on > the table > > The introduction contains the following sentences: > > Several years of deployment and implementation experience with OAuth 2.0 > [RFC6749] has uncovered a need, in some circumstances, > for the client to explicitly signal to the authorization sever where it > intends to use the access token it is requesting. > > A means for the client to signal to the authorization sever where it > intends to use the access token it's requesting is important and useful. > > The document contains a "security considerations" section but > unfortunately no "privacy considerations" section. > > Clause 2 states: > > The client may indicate the resource server(s) for which it is requesting > an access token by including the > following parameter in the request. > > resource > > OPTIONAL. The value of the resource parameter indicates a resource server > where the requested > access token will be used.* It MUST be an absolute URI*, as specified by > Section 4.3 of[RFC3986], > > With such an approach, the authorization server would have the ability to *act > as a Big Brother *and hence to know exactly > where the user will be performing activities. > > However, some users might be concerned with their privacy, and would like > to restrict the use of the access token > to some resource servers without the authorization server knowing which > are these resource servers. > > The key point is whether the information is primarily intended to the > authorization server or to the resource server(s). > > I believe that it is primarily intended to the resource server(s) rather > than to the authorization server in order to be included > in an access token. Obviously, the information needs to transit through > the authorization sever, that should simply be copied > and pasted into the access token. Its semantics, if any, does not > necessarily needs to be interpreted by the authorization sever. > > I believe that a "privacy considerations" section should be added. > > The sentence "*It MUST be an absolute URI*, as specified by Section 4.3 > of [RFC3986]" should be removed or > replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3 > of [RFC3986]". > > Obviously, other changes would be necessary too. > > Denis > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c07709a913026054184280b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I liked the usage in=C2=A0https://tools.ietf.org/html/rfc7515=C2=A0
   Collision-Resistant Name
      A name in a namespace that enables names to be allocated in a
      manner such that they are highly unlikely to collide with other
      names.  Examples of collision-resistant namespaces include: Domain
      Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
      X.670 Recommendation series, and Universally Unique IDentifiers
      (UUIDs) [RFC4122]=
.  When using an administratively delegated
      namespace, the definer of a name needs to take reasonable
      precautions to ensure they are in control of the portion of the
      namespace they use to define the name.


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


--94eb2c07709a913026054184280b-- From nobody Fri Nov 18 00:49:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9F112953C for ; Fri, 18 Nov 2016 00:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dxY4_cKIWRU for ; Fri, 18 Nov 2016 00:49:18 -0800 (PST) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [IPv6:2a00:1398:9:f712::810d:e751]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9B01294CF for ; Fri, 18 Nov 2016 00:49:17 -0800 (PST) Received: from kit-msx-29.kit.edu ([2a00:1398:9:f612::29]) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (envelope-from ) id 1c7erB-0003Lp-Ku for oauth@ietf.org; Fri, 18 Nov 2016 09:49:16 +0100 Received: from kit-msx-27.kit.edu (2a00:1398:9:f612::27) by KIT-MSX-29.kit.edu (2a00:1398:9:f612::29) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 18 Nov 2016 09:49:06 +0100 Received: from kit-msx-27.kit.edu ([fe80::184d:a4f7:c13a:714c]) by kit-msx-27.kit.edu ([fe80::184d:a4f7:c13a:714c%16]) with mapi id 15.00.1236.000; Fri, 18 Nov 2016 09:49:06 +0100 From: "Steinegger, Roland Heinz (TM)" To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 Thread-Index: AdJBeJlr6LXD93GnSWW7JTxQxR6Clw== Date: Fri, 18 Nov 2016 08:49:06 +0000 Message-ID: <101a8d47f64f453da9b0c08a6964ba51@kit-msx-27.kit.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [141.3.28.109] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0019_01D24180.FFFA78B0" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 08:49:21 -0000 ------=_NextPart_000_0019_01D24180.FFFA78B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On the new parameter. I agree. The description of a "Collision-Resistant Name" sounds great to me and would give developers good guidance. Perhaps the parameter may be called "resource-type". "resource" is ambiguous to me. It may refer to the kind of resource or to a concrete resource. (But I don't know how this is typically handled in RFCs.) On the topic privacy. In my opinion, it depends on how you implement the authorization server (AS). In many cases, the AS already knows what the user wants to access. The scope often contains this information, e.g. "calendar_read" - we are carrying out a study on how the scope is used currently. If you use OAuth just for delegation, it may be a privacy problem. But, if your AS authorizes based on authorization rules, where it has to know the protected resource as well as who wants to access it, privacy may not be a problem from my point of view. > Date: Thu, 17 Nov 2016 11:25:15 -0800 > From: Jim Willeke > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] About Big Brother and > draft-campbell-oauth-resource-indicators-00 > > I liked the usage in https://tools.ietf.org/html/rfc7515 > > Collision-Resistant Name > A name in a namespace that enables names to be allocated in a > manner such that they are highly unlikely to collide with other > names. Examples of collision-resistant namespaces include: Domain > Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and > X.670 Recommendation series, and Universally Unique IDentifiers > (UUIDs) [RFC4122 ]. When using an > administratively delegated > namespace, the definer of a name needs to take reasonable > precautions to ensure they are in control of the portion of the > namespace they use to define the name. > > > > -- > -jim > Jim Willeke > > On Thu, Nov 17, 2016 at 10:23 AM, Vivek Biswas > wrote: > > > +1 to *It MAY be an absolute URI*, as specified by Section 4.3 of > > [RFC3986]". > > > > Since the Audience Restriction can be a logical name to be interpreted > > by the Resource Server, if it really wants to enforce the audience > > check for a set of Resources it wants to protect. > > Hence, a logical name can be an absolute URI or a String as well. > > > > Regards > > Vivek Biswas, CISSP > > Consulting Member, Security > > Oracle Corporation. > > > > > > > > *From:* Denis [mailto:denis.ietf@free.fr] > > *Sent:* Tuesday, November 15, 2016 3:50 AM > > *To:* oauth@ietf.org > > *Subject:* [OAUTH-WG] About Big Brother and > > draft-campbell-oauth-resource- > > indicators-00 > > > > > > > > Hello everybody, > > > > Since I am not present at the meeting, I read the minutes from the > > first session, in particular: > > > > Brian Campbell and John did a draft allowing the client to tell the AS > > where it plans to use the token > > draft-campbell-oauth-resource-indicators > > > > This enables the AS to audience restrict the access > > token to the resource > > Phil Hunt: We should keep the audience restriction idea > > on the table > > > > The introduction contains the following sentences: > > > > Several years of deployment and implementation experience with OAuth > > 2.0 [RFC6749] has uncovered a need, in some circumstances, for the > > client to explicitly signal to the authorization sever where it > > intends to use the access token it is requesting. > > > > A means for the client to signal to the authorization sever where it > > intends to use the access token it's requesting is important and useful. > > > > The document contains a "security considerations" section but > > unfortunately no "privacy considerations" section. > > > > Clause 2 states: > > > > The client may indicate the resource server(s) for which it is > > requesting an access token by including the following parameter in the > > request. > > > > resource > > > > OPTIONAL. The value of the resource parameter indicates a resource > > server where the requested access token will be used.* It MUST be an > > absolute URI*, as specified by Section 4.3 of[RFC3986], > > > > With such an approach, the authorization server would have the ability > > to *act as a Big Brother *and hence to know exactly where the user > > will be performing activities. > > > > However, some users might be concerned with their privacy, and would > > like to restrict the use of the access token to some resource servers > > without the authorization server knowing which are these resource > > servers. > > > > The key point is whether the information is primarily intended to the > > authorization server or to the resource server(s). > > > > I believe that it is primarily intended to the resource server(s) > > rather than to the authorization server in order to be included in an > > access token. Obviously, the information needs to transit through the > > authorization sever, that should simply be copied and pasted into the > > access token. Its semantics, if any, does not necessarily needs to be > > interpreted by the authorization sever. > > > > I believe that a "privacy considerations" section should be added. > > > > The sentence "*It MUST be an absolute URI*, as specified by Section > > 4.3 of [RFC3986]" should be removed or replaced by : "*It MAY be an > > absolute URI*, as specified by Section 4.3 of [RFC3986]". > > > > Obviously, other changes would be necessary too. > > > > Denis > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > ------=_NextPart_000_0019_01D24180.FFFA78B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE7gw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcNAQELBQAw cTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQt VGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAy MB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzARBgNVBAoT CkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEds b2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1Uw5ZQ NT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFssoNTl7LZBF 0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90D8EJovZr zr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sPxRHCioOh lF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY+SGdJ68+ ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUSbfG z+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwEgYDVR0T AQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEEAYGtIYIs AQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4w PgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9ST09UX0NB XzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2LnRlbGVz ZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvY3J0L0RU X1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbypAZsNzMp9 QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW24TGnH9UH X03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8QNZapAg9 1ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaaZYnPrszy 5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMSFSMp/Cza zDlbVBcwggWUMIIEfKADAgECAgcXr/dvIyLpMA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVy ZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwODMxWhcNMTkwNzA5MjM1OTAwWjCBvzEL MAkGA1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNy dWhlMSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsT HlN0ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZI hvcNAQkBFgpjYUBraXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzLKoiomi gEFRKS9tHTwdCHo00T62o0Su5sMF6agaPwDzTfCD7XG9eqSE7W+cEAGnlT77vGAPm4uVNw5v8XhQ WskEHL1AKdOHMJv56ob73gjDqbwuNaoIqiv2UrA0JSK3u/M0A4J3SvSI0JhXb/Fwry0dIfDeYZeC /B9jQX2PXidQSD2d3mQ+rQDD2JAcO5ic7PcDw1VOlelMLOJBMJklBgRMOwL6fKdA3ay8CYBXdXUc lF78APqJ3L/oc3QS0Ag4+UTWnHXg0VLhJmpST8Xi8PynFLP9hTBsIYrggfftX1txtCYDw000oG0U upfX2i+5CffaVHBJb8LPceP7NJE/cwIDAQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAO BgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAowCDAGBgRVHSAAMB0GA1UdDgQWBBQfdGX0mh169jHp32Eb cysNbdAzSTAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpjYUBr aXQuZWR1MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYB BQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQA6Fib/1FcgfZ37KMpvcSqf Gu7Di2uF0j1P8ayheA6d1HZSncwytib8ws4hedEoh+eGbim7ClGumF8B4lhzu7bFFtvq+nJ23+hR nL8pcnjrXrULKCrwdmzIRBtH59QePvZOSLlyaXEEh4imYUWv5ajVjveYSh74bVDvHZU2LZU2khJr +kQHH8NiXGCogdhgve4d2KcIpgwtebH88GHZ4U3UlxeeAlT4MBzy/OXEf2COypULY7yOss9eJpmu 332Delu1AQzz3P+XpomCIMW8BARWeaK35Lz7X3iVLk9xSO0QZhPJj5f23rXn3Wc6hdRd+e3pq6bh h/YGWyaffEoK7kKoMIIFoDCCBIigAwIBAgIHFviy3lcd/jANBgkqhkiG9w0BAQUFADCBvzELMAkG A1UEBhMCREUxGzAZBgNVBAgTEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBxMJS2FybHNydWhl MSowKAYDVQQKEyFLYXJsc3J1aGUgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxJzAlBgNVBAsTHlN0 ZWluYnVjaCBDZW50cmUgZm9yIENvbXB1dGluZzEPMA0GA1UEAxMGS0lULUNBMRkwFwYJKoZIhvcN AQkBFgpjYUBraXQuZWR1MB4XDTE0MDExNzEzNTExMFoXDTE3MDExNjEzNTExMFowfTELMAkGA1UE BhMCREUxKjAoBgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEgMB4GA1UE CxMXSW5zdGl0dXQgZnVlciBUZWxlbWF0aWsxIDAeBgNVBAMTF1JvbGFuZCBIZWlueiBTdGVpbmVn Z2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuZFQZT1F1SlcT4zRXRW3HQzVdsBd v9ejbquGovqNmQL+OgA6+VyVilNzjJbz21q8uXkaasx5WQPnTVCQmZzjfoo89galZfSRALkFFZeP IOAA+BpqWEoazsH83w8bV7NIo43ZNhnvQadoAd46RqzXpf+BSJp0Sx56D5iDXKr27MAReEKxaClz ZnM5TRjdkD8WAkGibVX7VEq46bAVRcUT2w/F4rgBGbAdyho/2G76fMh3C81Ky+l3hRvAtS5d3+2b /Kep9Z1SfMyn8K0NbngMusuNnSfOSL78v6gIqiJf5LrxsFHcBAihyrMJcX9QmgC9hP3QtqR+WGu2 9xakTaHKkwIDAQABo4IB4DCCAdwwLwYDVR0gBCgwJjARBg8rBgEEAYGtIYIsAQEEAwEwEQYPKwYB BAGBrSGCLAIBBAMBMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQUiOW4JavEwiYN/vqYZshKhDpojmUwHwYDVR0jBBgwFoAUH3Rl 9JodevYx6d9hG3MrDW3QM0kwJAYDVR0RBB0wG4EZcm9sYW5kLnN0ZWluZWdnZXJAa2l0LmVkdTB3 BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL2tpdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRmbi5kZS9raXQtY2EvcHViL2NybC9jYWNy bC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZu LmRlL2tpdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAy LnBjYS5kZm4uZGUva2l0LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOC AQEAUn4FxZABvrcRu+UbjQ6qu1SbRymW7v6CQBgPhkrq5VJnfkXZHdzF8qW8LxnPU5cLWWqiiZBx CbG7y8ehT1bfas1EiN/nOOdn4mE2lXrJr+lwA2NL0/yI0Tmd1N/C9BVt4nXcoELBb2UPQNu/K2bg 8spPIcKCsRxrguE1J1bRI6P2PWRpWRa+EzVpGjz1pdLFxE4lGKu8RuiaHMwO5fYRlDf90bNuLrjH 6szGy8TkuKXVb63BhpJ1LTx5/odifAdStVStIJF55e+wrtBwdGpe/WbMTQqxlgq5fmK/KdjxW+yZ yl8/wiUNOOPSdebxBjqPf259hXcqCY9eDQMSivIdXzGCBLowggS2AgEBMIHLMIG/MQswCQYDVQQG EwJERTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMRIwEAYDVQQHEwlLYXJsc3J1aGUxKjAo BgNVBAoTIUthcmxzcnVoZSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEnMCUGA1UECxMeU3RlaW5i dWNoIENlbnRyZSBmb3IgQ29tcHV0aW5nMQ8wDQYDVQQDEwZLSVQtQ0ExGTAXBgkqhkiG9w0BCQEW CmNhQGtpdC5lZHUCBxb4st5XHf4wDQYJYIZIAWUDBAIBBQCgggK/MBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MTExODA4NDkwNVowLwYJKoZIhvcNAQkEMSIEILEE g/lXJajJmFOcT+1slEIVQfwPBJRLlqkIZkxmM7urMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAIC MAcGBSsOAwIaMIHcBgkrBgEEAYI3EAQxgc4wgcswgb8xCzAJBgNVBAYTAkRFMRswGQYDVQQIExJC YWRlbi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEqMCgGA1UEChMhS2FybHNydWhl IEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MScwJQYDVQQLEx5TdGVpbmJ1Y2ggQ2VudHJlIGZvciBD b21wdXRpbmcxDzANBgNVBAMTBktJVC1DQTEZMBcGCSqGSIb3DQEJARYKY2FAa2l0LmVkdQIHFviy 3lcd/jCB3gYLKoZIhvcNAQkQAgsxgc6ggcswgb8xCzAJBgNVBAYTAkRFMRswGQYDVQQIExJCYWRl bi1XdWVydHRlbWJlcmcxEjAQBgNVBAcTCUthcmxzcnVoZTEqMCgGA1UEChMhS2FybHNydWhlIElu c3RpdHV0ZSBvZiBUZWNobm9sb2d5MScwJQYDVQQLEx5TdGVpbmJ1Y2ggQ2VudHJlIGZvciBDb21w dXRpbmcxDzANBgNVBAMTBktJVC1DQTEZMBcGCSqGSIb3DQEJARYKY2FAa2l0LmVkdQIHFviy3lcd /jANBgkqhkiG9w0BAQEFAASCAQA+LgSwhX5/TtYyZnqunC4ExTX5GazGDqz8AbtdWEPrsEBL4G3G A9CjAP/7fp0BpraOq764gsjW4yPFdaN73RBuDWnVLMWHl7DXkKOpOas7yyPR2ptT0X7ZXGX5q5Jd RqPQHH5+Kbg9fe5+U7yJXJe2g0okfB4dhhtass84/CWpsa9InNujREv1xt5SgXOR3bd/k9aiL6jv V85+e4XYyhFCnr/T+7PVUs49VgezkdqrolI+oOnFb7mstJMhIKAi3ujUPsWJUONIBW4u/5pl/Q0V g7XejBW44uQRB8sl6z82xP72XRjctMMU9T2d77o5n7TUb3AiXl4sW8uNY0+gImg1AAAAAAAA ------=_NextPart_000_0019_01D24180.FFFA78B0-- From nobody Fri Nov 18 07:24:15 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C3E129536 for ; Fri, 18 Nov 2016 07:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8CcqtqWQhg1 for ; Fri, 18 Nov 2016 07:24:12 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA6A129465 for ; Fri, 18 Nov 2016 07:24:12 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id CA15F7803C2 for ; Fri, 18 Nov 2016 16:24:10 +0100 (CET) To: oauth@ietf.org References: <101a8d47f64f453da9b0c08a6964ba51@kit-msx-27.kit.edu> From: Denis Message-ID: <087d2b0a-84b2-fe00-f6f8-3a5256dc388a@free.fr> Date: Fri, 18 Nov 2016 16:24:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <101a8d47f64f453da9b0c08a6964ba51@kit-msx-27.kit.edu> Content-Type: multipart/alternative; boundary="------------F05B285937C6B40091E753A6" Archived-At: Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 15:24:14 -0000 This is a multi-part message in MIME format. --------------F05B285937C6B40091E753A6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit The resource parameter should simply be blindly copied into the access token by the AS, whether it bears a meaning or not. A privacy considerations section should be added to attract the attention of the reader/implementer to say that if it bears a meaning, there may be privacy concerns with Big Brother. Since the current draft has expired, if a new draft is being proposed, it would then be greatly simplified. Denis > On the new parameter. > I agree. The description of a "Collision-Resistant Name" sounds great to me > and would give developers good guidance. > > Perhaps the parameter may be called "resource-type". "resource" is ambiguous > to me. It may refer to the kind of resource or to a concrete resource. (But > I don't know how this is typically handled in RFCs.) > > > On the topic privacy. > In my opinion, it depends on how you implement the authorization server > (AS). In many cases, the AS already knows what the user wants to access. The > scope often contains this information, e.g. "calendar_read" - we are > carrying out a study on how the scope is used currently. > If you use OAuth just for delegation, it may be a privacy problem. But, if > your AS authorizes based on authorization rules, where it has to know the > protected resource as well as who wants to access it, privacy may not be a > problem from my point of view. > >> Date: Thu, 17 Nov 2016 11:25:15 -0800 >> From: Jim Willeke >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] About Big Brother and >> draft-campbell-oauth-resource-indicators-00 >> >> I liked the usage in https://tools.ietf.org/html/rfc7515 >> >> Collision-Resistant Name >> A name in a namespace that enables names to be allocated in a >> manner such that they are highly unlikely to collide with other >> names. Examples of collision-resistant namespaces include: Domain >> Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and >> X.670 Recommendation series, and Universally Unique IDentifiers >> (UUIDs) [RFC4122 ]. When using > an >> administratively delegated >> namespace, the definer of a name needs to take reasonable >> precautions to ensure they are in control of the portion of the >> namespace they use to define the name. >> >> >> >> -- >> -jim >> Jim Willeke >> >> On Thu, Nov 17, 2016 at 10:23 AM, Vivek Biswas >> wrote: >> >>> +1 to *It MAY be an absolute URI*, as specified by Section 4.3 of >>> [RFC3986]". >>> >>> Since the Audience Restriction can be a logical name to be interpreted >>> by the Resource Server, if it really wants to enforce the audience >>> check for a set of Resources it wants to protect. >>> Hence, a logical name can be an absolute URI or a String as well. >>> >>> Regards >>> Vivek Biswas, CISSP >>> Consulting Member, Security >>> Oracle Corporation. >>> >>> >>> >>> *From:* Denis [mailto:denis.ietf@free.fr] >>> *Sent:* Tuesday, November 15, 2016 3:50 AM >>> *To:* oauth@ietf.org >>> *Subject:* [OAUTH-WG] About Big Brother and >>> draft-campbell-oauth-resource- >>> indicators-00 >>> >>> >>> >>> Hello everybody, >>> >>> Since I am not present at the meeting, I read the minutes from the >>> first session, in particular: >>> >>> Brian Campbell and John did a draft allowing the client to tell the AS >>> where it plans to use the token >>> draft-campbell-oauth-resource-indicators >>> >>> This enables the AS to audience restrict the access >>> token to the resource >>> Phil Hunt: We should keep the audience restriction idea >>> on the table >>> >>> The introduction contains the following sentences: >>> >>> Several years of deployment and implementation experience with OAuth >>> 2.0 [RFC6749] has uncovered a need, in some circumstances, for the >>> client to explicitly signal to the authorization sever where it >>> intends to use the access token it is requesting. >>> >>> A means for the client to signal to the authorization sever where it >>> intends to use the access token it's requesting is important and useful. >>> >>> The document contains a "security considerations" section but >>> unfortunately no "privacy considerations" section. >>> >>> Clause 2 states: >>> >>> The client may indicate the resource server(s) for which it is >>> requesting an access token by including the following parameter in the >>> request. >>> >>> resource >>> >>> OPTIONAL. The value of the resource parameter indicates a resource >>> server where the requested access token will be used.* It MUST be an >>> absolute URI*, as specified by Section 4.3 of[RFC3986], >>> >>> With such an approach, the authorization server would have the ability >>> to *act as a Big Brother *and hence to know exactly where the user >>> will be performing activities. >>> >>> However, some users might be concerned with their privacy, and would >>> like to restrict the use of the access token to some resource servers >>> without the authorization server knowing which are these resource >>> servers. >>> >>> The key point is whether the information is primarily intended to the >>> authorization server or to the resource server(s). >>> >>> I believe that it is primarily intended to the resource server(s) >>> rather than to the authorization server in order to be included in an >>> access token. Obviously, the information needs to transit through the >>> authorization sever, that should simply be copied and pasted into the >>> access token. Its semantics, if any, does not necessarily needs to be >>> interpreted by the authorization sever. >>> >>> I believe that a "privacy considerations" section should be added. >>> >>> The sentence "*It MUST be an absolute URI*, as specified by Section >>> 4.3 of [RFC3986]" should be removed or replaced by : "*It MAY be an >>> absolute URI*, as specified by Section 4.3 of [RFC3986]". >>> >>> Obviously, other changes would be necessary too. >>> >>> Denis >>> >>> _______________________________________________ >>> 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 --------------F05B285937C6B40091E753A6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

The resource parameter should simply be blindly copied into the access token by the AS, whether it bears a meaning or not.

A privacy considerations section should be added to attract the attention of the reader/implementer to say that if it bears a meaning,
there may be privacy concerns with Big Brother.

Since the current draft has expired, if a new draft is being proposed, it would then be greatly simplified.

Denis

On the new parameter.
I agree. The description of a "Collision-Resistant Name" sounds great to me
and would give developers good guidance.

Perhaps the parameter may be called "resource-type". "resource" is ambiguous
to me. It may refer to the kind of resource or to a concrete resource. (But
I don't know how this is typically handled in RFCs.)


On the topic privacy.
In my opinion, it depends on how you implement the authorization server
(AS). In many cases, the AS already knows what the user wants to access. The
scope often contains this information, e.g. "calendar_read" - we are
carrying out a study on how the scope is used currently.
If you use OAuth just for delegation, it may be a privacy problem. But, if
your AS authorizes based on authorization rules, where it has to know the
protected resource as well as who wants to access it, privacy may not be a
problem from my point of view.


Date: Thu, 17 Nov 2016 11:25:15 -0800
From: Jim Willeke <jim@willeke.com>
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] About Big Brother and
	draft-campbell-oauth-resource-indicators-00

I liked the usage in https://tools.ietf.org/html/rfc7515

   Collision-Resistant Name
      A name in a namespace that enables names to be allocated in a
      manner such that they are highly unlikely to collide with other
      names.  Examples of collision-resistant namespaces include: Domain
      Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
      X.670 Recommendation series, and Universally Unique IDentifiers
      (UUIDs) [RFC4122 <https://tools.ietf.org/html/rfc4122>].  When using

an

administratively delegated
      namespace, the definer of a name needs to take reasonable
      precautions to ensure they are in control of the portion of the
      namespace they use to define the name.



--
-jim
Jim Willeke

On Thu, Nov 17, 2016 at 10:23 AM, Vivek Biswas <vivek.biswas@oracle.com>
wrote:


+1 to *It MAY be an absolute URI*, as specified by Section 4.3 of
[RFC3986]".

Since the Audience Restriction can be a logical name to be interpreted
by the Resource Server, if it really wants to enforce the audience
check for a set of Resources it wants to protect.
Hence, a logical name can be an absolute URI or a String as well.

Regards
Vivek Biswas, CISSP
Consulting Member, Security
Oracle Corporation.



*From:* Denis [mailto:denis.ietf@free.fr]
*Sent:* Tuesday, November 15, 2016 3:50 AM
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] About Big Brother and
draft-campbell-oauth-resource-
indicators-00



Hello everybody,

Since I am not present at the meeting, I read the minutes from the
first session, in particular:

Brian Campbell and John did a draft allowing the client to tell the AS
where it plans to use the token
draft-campbell-oauth-resource-indicators

              This enables the AS to audience restrict the access
token to the resource
              Phil Hunt:  We should keep the audience restriction idea
on the table

The introduction contains the following sentences:

Several years of deployment and implementation experience with OAuth
2.0 [RFC6749] has uncovered a need, in some circumstances, for the
client to explicitly signal to the authorization sever where it
intends to use the access token it is requesting.

A means for the client to signal to the authorization sever where it
intends to use the access token it's requesting is important and useful.

The document contains a "security considerations" section but
unfortunately no "privacy considerations" section.

Clause 2 states:

The client may indicate the resource server(s) for which it is
requesting an access token by including the following parameter in the
request.

resource

OPTIONAL. The value of the resource parameter indicates a resource
server where the requested access token will be used.* It MUST be an
absolute URI*, as specified by Section 4.3 of[RFC3986],

With such an approach, the authorization server would have the ability
to *act as a Big Brother *and hence to know exactly where the user
will be performing activities.

However, some users might be concerned with their privacy, and would
like to restrict the use of the access token to some resource servers
without the authorization server knowing which are these resource
servers.

The key point is whether the information is primarily intended to the
authorization server or to the resource server(s).

I believe that it is primarily intended to the resource server(s)
rather than to the authorization server in order to be included in an
access token. Obviously, the information needs to transit through the
authorization sever, that should simply be copied and pasted into the
access token. Its semantics, if any, does not necessarily needs to be
interpreted by the authorization sever.

I believe that a "privacy considerations" section should be added.

The sentence "*It MUST be an absolute URI*, as specified by Section
4.3 of [RFC3986]" should be removed or  replaced by : "*It MAY be an
absolute URI*, as specified by Section 4.3 of [RFC3986]".

Obviously, other changes would be necessary too.

Denis

_______________________________________________
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


--------------F05B285937C6B40091E753A6-- From nobody Tue Nov 22 02:04:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D0B1298A0 for ; Tue, 22 Nov 2016 02:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrqT9xK-EPI3 for ; Tue, 22 Nov 2016 02:04:19 -0800 (PST) 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 508F1129D17 for ; Tue, 22 Nov 2016 02:03:52 -0800 (PST) Received: from [192.168.91.165] ([88.128.80.118]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MOOpx-1c3tGi1hQb-005mBN; Tue, 22 Nov 2016 11:03:49 +0100 To: Denis , oauth@ietf.org References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <7fe51b7f-cc68-abda-79ed-9b6d75e00bc4@gmx.net> Date: Tue, 22 Nov 2016 11:03:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xxaek1sUCts16BiGep6uWjWT8e2Ds6lXq" X-Provags-ID: V03:K0:DDsUFJOK1HzXpdVq7RQBOOh/geXleh5SM+DxyMznazSgLvoMzNA KNjzZkTV90CXGhmQrQNEJPWppzF2qjH/1hcLulpWQ9iF1WXEUt3luUZuF0U1V9y6yjPIqdf 0a+sT9PW+zkFeVEm6q7VDciVhLVpiU+g2r20yE5aRpjFPSaslVfvOadMzsb0Oz3Htf0zSEf pyWc1Oc6PFG3YeYWi70OQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:+3SlSpoKADQ=:d7e735rcd9EhOJJyovJJmu pcFCUnpAY6not5NOPHC4n174+qilRs8z+yLCkqn6tsA7+g2MRAbu17Qm86G1J61BaW0bxeltE oxS+XBOZtKfZh+Iw5pY2az1YDlEoZcxSbAxcibI15gqRNbnuUD/EFpeUyYdbE5lURFZDZRAWo rn/CVsbXmc40bXXVyC6+bz1Ho4QEypKWbpaiEtQXtBxztLfV5pZmi2sh6aArepsWaUNl+c+t6 DVCqik6IY80G9HZ22lw6qT9qyoN2DCln1cJjeMkpmMbsBqvVVHonYB6alEQXE8cn/uKeg3av2 x7C3LAEpbg7SrHQu/DIfb/4kD5Ye/b4hgT1K5/A/cSa+s4lXrzA8bPYAeZXtIjJDghHVXQw4k n3Wqjx0L0z1CGskbYcrrkPU+gBuj1YdpMnVlJzoDfd/pD+jUk357Q5iP37yWijaLeXOklGX8p 9Qts0uCu5Kz74XJ85RkN1+4SFiOLJkU8prv74W9c8tRlHVUTWTtR/UtFU9C2VVxq33Qg8xBis dLzOyCWriea29gzc/RQK6wFh/hjn4d56yMmABe6sfHnkjBo5dxjElaBP6wM15XTGRI30nP0bu mN2/3sdgDVOcAju8oflsbYlRLukN0gQi75uvgTTpwXXKsun3x/25l+YX3GvsJ4sDYZCVOBsMq vqwaLfpCfIHs/wxwIg3mKwF+9EfF2Za52YdZOhuTyvbbiKZDe+yEUDNigwSX6w7vUC8GgIbSW VmG14Y8KWXFlS9HGGxOa8x3xsK7EU5l1EosB+AVMexedAy5h0UdJDxTaLqySglT/L4+mumx1i INb2Jrc Archived-At: Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 10:04:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xxaek1sUCts16BiGep6uWjWT8e2Ds6lXq Content-Type: multipart/mixed; boundary="XDodNbhsJ97f8wbeA8uh7e03AdSxMF106"; protected-headers="v1" From: Hannes Tschofenig To: Denis , oauth@ietf.org Message-ID: <7fe51b7f-cc68-abda-79ed-9b6d75e00bc4@gmx.net> Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 References: In-Reply-To: --XDodNbhsJ97f8wbeA8uh7e03AdSxMF106 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Denis draft-campbell-oauth-resource-indicators gives the authorization server information about the resource server the access token will be used with.= Without this information there is the risk that the access token is replayed at other resource servers and with the proof-of-possession / token binding work there obviously has to be an indication of where the token is used. The reason for using an absolute URI is that the resource server needs to take the information from the incoming access token and to compare it with its own information in order to determine whether the token is indeed intended for itself. If the authorization server does not know to whom it gives rights to access protected information then this is also a privacy risk (namely unauthorized access). Ciao Hannes On 11/15/2016 12:50 PM, Denis wrote: > Hello everybody, >=20 > Since I am not present at the meeting, I read the minutes from the firs= t > session, in particular: >=20 > Brian Campbell and John did a draft allowing the client to tell the= > AS where it plans to use the token > draft-campbell-oauth-resource-indicators >=20 > This enables the AS to audience restrict the access > token to the resource > Phil Hunt: We should keep the audience restriction > idea on the table >=20 > The introduction contains the following sentences: >=20 > Several years of deployment and implementation experience with OAut= h > 2.0 [RFC6749] has uncovered a need, in some circumstances, > for the client to explicitly signal to the authorization sever wher= e > it intends to use the access token it is requesting. >=20 > A means for the client to signal to the authorization sever where i= t > intends to use the access token it's requesting is important and > useful. >=20 > The document contains a "security considerations" section but > unfortunately no "privacy considerations" section. >=20 > Clause 2 states: >=20 > The client may indicate the resource server(s) for which it is > requesting an access token by including the > following parameter in the request. >=20 > resource >=20 > OPTIONAL. The value of the resource parameter indicates a resource > server where the requested > access token will be used.*It MUST be an absolute URI*, as specifie= d > by Section 4.3 of[RFC3986], >=20 > With such an approach, the authorization server would have the ability > to *act as a Big Brother *and hence to know exactly > where the user will be performing activities. >=20 > However, some users might be concerned with their privacy, and would > like to restrict the use of the access token > to some resource servers without the authorization server knowing which= > are these resource servers. >=20 > The key point is whether the information is primarily intended to the > authorization server or to the resource server(s). >=20 > I believe that it is primarily intended to the resource server(s) rathe= r > than to the authorization server in order to be included > in an access token. Obviously, the information needs to transit through= > the authorization sever, that should simply be copied > and pasted into the access token. Its semantics, if any, does not > necessarily needs to be interpreted by the authorization sever. >=20 > I believe that a "privacy considerations" section should be added. >=20 > The sentence "*It MUST be an absolute URI*, as specified by Section 4.3= > of [RFC3986]" should be removed or > replaced by : "*It MAY be an absolute URI*, as specified by Section 4.= 3 > of [RFC3986]". >=20 > Obviously, other changes would be necessary too. >=20 > Denis >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --XDodNbhsJ97f8wbeA8uh7e03AdSxMF106-- --Xxaek1sUCts16BiGep6uWjWT8e2Ds6lXq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYNBgEAAoJEGhJURNOOiAtzoAH/2oFtMB79xFRerp10E2HGbZ7 NQJHdESDWRmKw5WK19oTPJMVA2IqLtLo4B9W+Z2znZWjTtmivxmQTDL8T9lgWiya QThSSBcUYeHK2kI8a0cZfAICohbm5IW2hGGwxFq5QopMQbWsevTKcaVxN4VgcJ5m WGNu3Y7hb62LjSDBe8mlN5P1yVjo8OHloiqZkuSiL51JCQTx1z9PH57zF8F1WeLt 1nHGyvXQeHS+/7AUweWsI49xjrv1DYzzHv7FHF917TdzNPsv6VoZNwC9HsaXdA3h 5H/9oSDpWV0PYVlATBt+/wDZq5Y6W+QI2kAHcQ5dQUQV2TAdC80hlNDFeaIXSUM= =6LzZ -----END PGP SIGNATURE----- --Xxaek1sUCts16BiGep6uWjWT8e2Ds6lXq-- From nobody Tue Nov 22 04:34:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C771295E5 for ; Tue, 22 Nov 2016 04:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRGH2NBmuHGk for ; Tue, 22 Nov 2016 04:34:10 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD154129442 for ; Tue, 22 Nov 2016 04:34:09 -0800 (PST) Received: from [192.168.0.15] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1509C78038D; Tue, 22 Nov 2016 13:34:06 +0100 (CET) To: Hannes Tschofenig , oauth@ietf.org References: <7fe51b7f-cc68-abda-79ed-9b6d75e00bc4@gmx.net> From: Denis Message-ID: <5161dc3d-aac7-acb3-d4b3-7e6864a0520b@free.fr> Date: Tue, 22 Nov 2016 13:34:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7fe51b7f-cc68-abda-79ed-9b6d75e00bc4@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 12:34:12 -0000 Hi Hannes, I do not deny the fact that it is necessary to provide some information to the authorization server to indicate the resource server where the access token shall only be used. Let us illustrate the concept with a simple scenario. A user first connects to a resource server and announces some actions he would like to perform. In its response, the resource server indicates "demonstrate that you are older than 18 and incorporate in your access token the random value (some kind of challenge) I have just generated for you only". The client forwards that random value to the authorization server which is blindly copied and pasted into the access token. If the resource server does not recognize this value, the access will be denied. In this way, the authorization server has no way to know where the access token will be used. On the contrary, an absolute URI would allow the authorization server to know which resources the user is accessing. The use of an absolute URI should be deprecated because of this privacy concern. Denis > Hi Denis > > draft-campbell-oauth-resource-indicators gives the authorization server > information about the resource server the access token will be used with. > > Without this information there is the risk that the access token is > replayed at other resource servers and with the proof-of-possession / > token binding work there obviously has to be an indication of where the > token is used. > > The reason for using an absolute URI is that the resource server needs > to take the information from the incoming access token and to compare it > with its own information in order to determine whether the token is > indeed intended for itself. > > If the authorization server does not know to whom it gives rights to > access protected information then this is also a privacy risk (namely > unauthorized access). > > Ciao > Hannes > > On 11/15/2016 12:50 PM, Denis wrote: >> Hello everybody, >> >> Since I am not present at the meeting, I read the minutes from the first >> session, in particular: >> >> Brian Campbell and John did a draft allowing the client to tell the >> AS where it plans to use the token >> draft-campbell-oauth-resource-indicators >> >> This enables the AS to audience restrict the access >> token to the resource >> Phil Hunt: We should keep the audience restriction >> idea on the table >> >> The introduction contains the following sentences: >> >> Several years of deployment and implementation experience with OAuth >> 2.0 [RFC6749] has uncovered a need, in some circumstances, >> for the client to explicitly signal to the authorization sever where >> it intends to use the access token it is requesting. >> >> A means for the client to signal to the authorization sever where it >> intends to use the access token it's requesting is important and >> useful. >> >> The document contains a "security considerations" section but >> unfortunately no "privacy considerations" section. >> >> Clause 2 states: >> >> The client may indicate the resource server(s) for which it is >> requesting an access token by including the >> following parameter in the request. >> >> resource >> >> OPTIONAL. The value of the resource parameter indicates a resource >> server where the requested >> access token will be used.*It MUST be an absolute URI*, as specified >> by Section 4.3 of[RFC3986], >> >> With such an approach, the authorization server would have the ability >> to *act as a Big Brother *and hence to know exactly >> where the user will be performing activities. >> >> However, some users might be concerned with their privacy, and would >> like to restrict the use of the access token >> to some resource servers without the authorization server knowing which >> are these resource servers. >> >> The key point is whether the information is primarily intended to the >> authorization server or to the resource server(s). >> >> I believe that it is primarily intended to the resource server(s) rather >> than to the authorization server in order to be included >> in an access token. Obviously, the information needs to transit through >> the authorization sever, that should simply be copied >> and pasted into the access token. Its semantics, if any, does not >> necessarily needs to be interpreted by the authorization sever. >> >> I believe that a "privacy considerations" section should be added. >> >> The sentence "*It MUST be an absolute URI*, as specified by Section 4.3 >> of [RFC3986]" should be removed or >> replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3 >> of [RFC3986]". >> >> Obviously, other changes would be necessary too. >> >> Denis >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From nobody Tue Nov 22 08:10:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41EC12969B for ; Tue, 22 Nov 2016 08:10:39 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLEtjklALlF0 for ; Tue, 22 Nov 2016 08:10:37 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7822D129693 for ; Tue, 22 Nov 2016 08:10:37 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id x190so31274904qkb.0 for ; Tue, 22 Nov 2016 08:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xwxn2SQl9comYo9Mh/kFzWw34oT35jkq+zGul6yrl+U=; b=1GbQ+jHKTCP4CiNIvMZGoQQWXV7AxwR+yIN/t3B0ZfTNdMaHEoMWaXqzSDqmMYABcm tPxeOryUOaz/aImeE4Fe3mO73xwILGYZeTHy17zE6njgbkAbIyDVdw2kQHW2/YYfuf1w YnUw6d/YzFyOMWFJgDFEbUHi7+gsEshLlJyPN9YC77Mj9u8H/pMg3PkAsUEbpPkU7jwu t36Mf/pbIrNcjL8bRL0VMwd0jSnviFZxEPTExNHuxOTAVzaaFhGLEgObUTUo5T9HaC8M ZbFP62xHfMfHN6/U8SdiFnQeVNNMvi6FoqsNNoEmcmjOWlIdCTISsvDqM56KLZ7njxXu 7jPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xwxn2SQl9comYo9Mh/kFzWw34oT35jkq+zGul6yrl+U=; b=iiTCaXHrJoodepcFsJkqurbt3AYeAT87FQw2cfEBoaakXGOoa8bTPctsn4UvVfKQws ecfhO6oz+jHOYU1cNLuCPXsH3XcoH8dl1wMv6rhFryETqcfHQUqGcM/d0xT9LiDmUuyf Qj/ebQoDbZm3eJrqGDx2pOrGdej/LY20ksq6luS4KLfGzEHP+8drrv+iH/IJt5oPDPfy MBf7zSpvYkE+mXf/I8aArKs+YTRvG8Gxf6+9DcZOrrnrgN5oAfrxL0gqeVKGT6mTjcvV VhON11y4L4dzbD+a9GDvTWMrxcrAbg+RCST9PX7Nzyr1GaKvP3k7CMhGoXwCfPJwYZIT +EVQ== X-Gm-Message-State: AKaTC036sBEvgMV7irRvstMj8UDf+sxSPMMegSZXEtZ5itjGXeyt7Q7icJnXzyheRVwJ7iUU X-Received: by 10.55.91.193 with SMTP id p184mr22596627qkb.301.1479831036409; Tue, 22 Nov 2016 08:10:36 -0800 (PST) Received: from [192.168.1.216] ([191.115.236.136]) by smtp.gmail.com with ESMTPSA id e24sm7050915qkj.12.2016.11.22.08.10.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 08:10:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: John Bradley In-Reply-To: <5161dc3d-aac7-acb3-d4b3-7e6864a0520b@free.fr> Date: Tue, 22 Nov 2016 13:10:31 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <468C84B4-B2B3-4CC8-8AD1-A25A0D6893EF@ve7jtb.com> References: <7fe51b7f-cc68-abda-79ed-9b6d75e00bc4@gmx.net> <5161dc3d-aac7-acb3-d4b3-7e6864a0520b@free.fr> To: Denis X-Mailer: Apple Mail (2.3251) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 16:10:40 -0000 The privacy problem is a touch hypothetical the way that OAuth currently = works. There is not standard access token, a AS producing access tokens that = could be used across a number of RS in different security domains would = be a security disaster, unless they are proof of possession tokens. If all of the RS trust each other by being in the same security domain = they can all collude and the AS can know where the tokens are used = without the resource being indicated to the AS directly. =20 If the RS are in different security domains then potentially some = privacy is disclosed. =20 The only way to deal with that is the alternative of POP AT that the WG = is documenting separately. =20 I think it is fine to say that if the AS are in separate security = domains and privacy is a issue, then use PoP rather than resource to = protect the AT from replay. The reason for using a URI for the resource is that it is something the = client knows. If we use a abstract name the client might be tricked = into giving a token to the wrong resource. John B. > On Nov 22, 2016, at 9:34 AM, Denis wrote: >=20 > Hi Hannes, >=20 > I do not deny the fact that it is necessary to provide some = information to the authorization server > to indicate the resource server where the access token shall only be = used. >=20 > Let us illustrate the concept with a simple scenario. >=20 > A user first connects to a resource server and announces some actions = he would like to perform. > In its response, the resource server indicates "demonstrate that you = are older than 18 and incorporate > in your access token the random value (some kind of challenge) I have = just generated for you only". >=20 > The client forwards that random value to the authorization server = which is blindly copied and pasted > into the access token. If the resource server does not recognize this = value, the access will be denied. >=20 > In this way, the authorization server has no way to know where the = access token will be used. >=20 > On the contrary, an absolute URI would allow the authorization server = to know which resources the user is accessing. > The use of an absolute URI should be deprecated because of this = privacy concern. >=20 > Denis >=20 >> Hi Denis >>=20 >> draft-campbell-oauth-resource-indicators gives the authorization = server >> information about the resource server the access token will be used = with. >>=20 >> Without this information there is the risk that the access token is >> replayed at other resource servers and with the proof-of-possession / >> token binding work there obviously has to be an indication of where = the >> token is used. >>=20 >> The reason for using an absolute URI is that the resource server = needs >> to take the information from the incoming access token and to compare = it >> with its own information in order to determine whether the token is >> indeed intended for itself. >>=20 >> If the authorization server does not know to whom it gives rights to >> access protected information then this is also a privacy risk (namely >> unauthorized access). >>=20 >> Ciao >> Hannes >>=20 >> On 11/15/2016 12:50 PM, Denis wrote: >>> Hello everybody, >>>=20 >>> Since I am not present at the meeting, I read the minutes from the = first >>> session, in particular: >>>=20 >>> Brian Campbell and John did a draft allowing the client to tell = the >>> AS where it plans to use the token >>> draft-campbell-oauth-resource-indicators >>>=20 >>> This enables the AS to audience restrict the = access >>> token to the resource >>> Phil Hunt: We should keep the audience = restriction >>> idea on the table >>>=20 >>> The introduction contains the following sentences: >>>=20 >>> Several years of deployment and implementation experience with = OAuth >>> 2.0 [RFC6749] has uncovered a need, in some circumstances, >>> for the client to explicitly signal to the authorization sever = where >>> it intends to use the access token it is requesting. >>>=20 >>> A means for the client to signal to the authorization sever = where it >>> intends to use the access token it's requesting is important and >>> useful. >>>=20 >>> The document contains a "security considerations" section but >>> unfortunately no "privacy considerations" section. >>>=20 >>> Clause 2 states: >>>=20 >>> The client may indicate the resource server(s) for which it is >>> requesting an access token by including the >>> following parameter in the request. >>>=20 >>> resource >>>=20 >>> OPTIONAL. The value of the resource parameter indicates a = resource >>> server where the requested >>> access token will be used.*It MUST be an absolute URI*, as = specified >>> by Section 4.3 of[RFC3986], >>>=20 >>> With such an approach, the authorization server would have the = ability >>> to *act as a Big Brother *and hence to know exactly >>> where the user will be performing activities. >>>=20 >>> However, some users might be concerned with their privacy, and would >>> like to restrict the use of the access token >>> to some resource servers without the authorization server knowing = which >>> are these resource servers. >>>=20 >>> The key point is whether the information is primarily intended to = the >>> authorization server or to the resource server(s). >>>=20 >>> I believe that it is primarily intended to the resource server(s) = rather >>> than to the authorization server in order to be included >>> in an access token. Obviously, the information needs to transit = through >>> the authorization sever, that should simply be copied >>> and pasted into the access token. Its semantics, if any, does not >>> necessarily needs to be interpreted by the authorization sever. >>>=20 >>> I believe that a "privacy considerations" section should be added. >>>=20 >>> The sentence "*It MUST be an absolute URI*, as specified by Section = 4.3 >>> of [RFC3986]" should be removed or >>> replaced by : "*It MAY be an absolute URI*, as specified by Section = 4.3 >>> of [RFC3986]". >>>=20 >>> Obviously, other changes would be necessary too. >>>=20 >>> Denis >>>=20 >>>=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 From nobody Tue Nov 22 09:21:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A011288B8 for ; Tue, 22 Nov 2016 09:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA9QBdZEwtyw for ; Tue, 22 Nov 2016 09:21:48 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0121.outbound.protection.outlook.com [104.47.36.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C9D129529 for ; Tue, 22 Nov 2016 09:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MMJaChbu3xvZfaqRtXI1CwFZ1UbOU2ioh6eL5+/bysA=; b=kNNOBW/rc+G3JLyLxT012GTD9ZhAxhYZs/7QTxdgLLSbgjctMLCgSA2P7j3227oFH/utqCBWECK7z7EAIAu1mq4E+ZD9iA2HmGzswuirlJ8buVU9X2wRWc9e+V/gKLO4J2PZguyFzRSsLIlp0pnHmOVZMBuNss4BfwAVAGe2t/0= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2353.namprd03.prod.outlook.com (10.166.74.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Tue, 22 Nov 2016 17:21:46 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0734.014; Tue, 22 Nov 2016 17:21:46 +0000 From: Mike Jones To: "Steinegger, Roland Heinz (TM)" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 Thread-Index: AdJBeJlrUbLBw81fnEK2+Zll4wsQGQDa6ZGg Date: Tue, 22 Nov 2016 17:21:46 +0000 Message-ID: References: <101a8d47f64f453da9b0c08a6964ba51@kit-msx-27.kit.edu> In-Reply-To: <101a8d47f64f453da9b0c08a6964ba51@kit-msx-27.kit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.80.137] x-microsoft-exchange-diagnostics: 1; BN3PR03MB2353; 7:tgPTKUsUeHo1w6UmuCmSc5NOCI52aBdGg5dZ3T2xQZteRZv7dtduFoqDDYhA9BXfMTzX1d/ER2u9HfxEk/wwnZy4SR9NkV1fyBFnQ3UvW2qKRSe9PuJOJq7R5RUI6WtaFg2C6AhjrMire5/W1lL3oEIPcUF/kEiUZydG70CgU9Nr1qjx0kNYdgx8XVGQVU9BhLdw6euPTEYVcbXjUg8rE9A51iARx3CI2XOm4i3HKIoO8z83Y4t5viHzDNHoIEuzQ2aNL4uP6peWo39f1e1skPAi4BoaRP93Rj199/dvWogwoi2aQRHDU32eH8F+7OEqyrMZFgFZr41jdFBhPFJ9XaIC3B+dQXW4M/W31lLuqW5V7cwYFPeBMHHBDWCUE82H x-ms-office365-filtering-correlation-id: 553d2cbb-8c54-47be-0ad8-08d412fc095e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2353; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(191636701735510)(158342451672863)(192374486261705)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045199)(6040307)(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6041248)(6061324)(6042181)(6072148)(6047074); SRVR:BN3PR03MB2353; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2353; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(199003)(377454003)(53754006)(13464003)(189002)(8990500004)(7736002)(305945005)(3660700001)(3280700002)(9686002)(5005710100001)(74316002)(10290500002)(8936002)(7846002)(2906002)(66066001)(2171001)(86362001)(230783001)(68736007)(4326007)(5660300001)(38730400001)(76576001)(3846002)(122556002)(2950100002)(33656002)(6116002)(102836003)(92566002)(86612001)(2900100001)(189998001)(2501003)(101416001)(50986999)(8676002)(77096005)(81156014)(97736004)(5001770100001)(229853002)(99286002)(6506003)(81166006)(10090500001)(105586002)(7696004)(76176999)(54356999)(106356001)(15866825004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2353; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 17:21:46.0616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2353 Archived-At: Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 17:21:50 -0000 I believe that the parameter name should remain "resource". It's identifyi= ng a concrete protected resource and so is already correctly named. Beside= s, that name is already in production use for this purpose. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Steinegger, Roland= Heinz (TM) Sent: Friday, November 18, 2016 12:49 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource= -indicators-00 On the new parameter. I agree. The description of a "Collision-Resistant Name" sounds great to me= and would give developers good guidance. Perhaps the parameter may be called "resource-type". "resource" is ambiguou= s to me. It may refer to the kind of resource or to a concrete resource. (B= ut I don't know how this is typically handled in RFCs.) On the topic privacy. In my opinion, it depends on how you implement the authorization server (AS= ). In many cases, the AS already knows what the user wants to access. The s= cope often contains this information, e.g. "calendar_read" - we are carryin= g out a study on how the scope is used currently. If you use OAuth just for delegation, it may be a privacy problem. But, if = your AS authorizes based on authorization rules, where it has to know the p= rotected resource as well as who wants to access it, privacy may not be a p= roblem from my point of view. > Date: Thu, 17 Nov 2016 11:25:15 -0800 > From: Jim Willeke > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] About Big Brother and > draft-campbell-oauth-resource-indicators-00 >=20 > I liked the usage in https://tools.ietf.org/html/rfc7515 >=20 > Collision-Resistant Name > A name in a namespace that enables names to be allocated in a > manner such that they are highly unlikely to collide with other > names. Examples of collision-resistant namespaces include: Domain > Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and > X.670 Recommendation series, and Universally Unique IDentifiers > (UUIDs) [RFC4122 ]. When=20 > using an > administratively delegated > namespace, the definer of a name needs to take reasonable > precautions to ensure they are in control of the portion of the > namespace they use to define the name. >=20 >=20 >=20 > -- > -jim > Jim Willeke >=20 > On Thu, Nov 17, 2016 at 10:23 AM, Vivek Biswas=20 > > wrote: >=20 > > +1 to *It MAY be an absolute URI*, as specified by Section 4.3 of > > [RFC3986]". > > > > Since the Audience Restriction can be a logical name to be=20 > > interpreted by the Resource Server, if it really wants to enforce=20 > > the audience check for a set of Resources it wants to protect. > > Hence, a logical name can be an absolute URI or a String as well. > > > > Regards > > Vivek Biswas, CISSP > > Consulting Member, Security > > Oracle Corporation. > > > > > > > > *From:* Denis [mailto:denis.ietf@free.fr] > > *Sent:* Tuesday, November 15, 2016 3:50 AM > > *To:* oauth@ietf.org > > *Subject:* [OAUTH-WG] About Big Brother and > > draft-campbell-oauth-resource- > > indicators-00 > > > > > > > > Hello everybody, > > > > Since I am not present at the meeting, I read the minutes from the=20 > > first session, in particular: > > > > Brian Campbell and John did a draft allowing the client to tell the=20 > > AS where it plans to use the token=20 > > draft-campbell-oauth-resource-indicators > > > > This enables the AS to audience restrict the access=20 > > token to the resource > > Phil Hunt: We should keep the audience restriction=20 > > idea on the table > > > > The introduction contains the following sentences: > > > > Several years of deployment and implementation experience with OAuth > > 2.0 [RFC6749] has uncovered a need, in some circumstances, for the=20 > > client to explicitly signal to the authorization sever where it=20 > > intends to use the access token it is requesting. > > > > A means for the client to signal to the authorization sever where it=20 > > intends to use the access token it's requesting is important and useful= . > > > > The document contains a "security considerations" section but=20 > > unfortunately no "privacy considerations" section. > > > > Clause 2 states: > > > > The client may indicate the resource server(s) for which it is=20 > > requesting an access token by including the following parameter in=20 > > the request. > > > > resource > > > > OPTIONAL. The value of the resource parameter indicates a resource=20 > > server where the requested access token will be used.* It MUST be an=20 > > absolute URI*, as specified by Section 4.3 of[RFC3986], > > > > With such an approach, the authorization server would have the=20 > > ability to *act as a Big Brother *and hence to know exactly where=20 > > the user will be performing activities. > > > > However, some users might be concerned with their privacy, and would=20 > > like to restrict the use of the access token to some resource=20 > > servers without the authorization server knowing which are these=20 > > resource servers. > > > > The key point is whether the information is primarily intended to=20 > > the authorization server or to the resource server(s). > > > > I believe that it is primarily intended to the resource server(s)=20 > > rather than to the authorization server in order to be included in=20 > > an access token. Obviously, the information needs to transit through=20 > > the authorization sever, that should simply be copied and pasted=20 > > into the access token. Its semantics, if any, does not necessarily=20 > > needs to be interpreted by the authorization sever. > > > > I believe that a "privacy considerations" section should be added. > > > > The sentence "*It MUST be an absolute URI*, as specified by Section > > 4.3 of [RFC3986]" should be removed or replaced by : "*It MAY be an=20 > > absolute URI*, as specified by Section 4.3 of [RFC3986]". > > > > Obviously, other changes would be necessary too. > > > > Denis > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From nobody Tue Nov 22 09:22:44 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6659B1295F1 for ; Tue, 22 Nov 2016 09:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO-_T8r5YVbX for ; Tue, 22 Nov 2016 09:22:40 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5FE129593 for ; Tue, 22 Nov 2016 09:22:39 -0800 (PST) Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5D5847803EC; Tue, 22 Nov 2016 18:22:36 +0100 (CET) To: John Bradley References: <7fe51b7f-cc68-abda-79ed-9b6d75e00bc4@gmx.net> <5161dc3d-aac7-acb3-d4b3-7e6864a0520b@free.fr> <468C84B4-B2B3-4CC8-8AD1-A25A0D6893EF@ve7jtb.com> From: Denis Message-ID: Date: Tue, 22 Nov 2016 18:22:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <468C84B4-B2B3-4CC8-8AD1-A25A0D6893EF@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------05C0A3FF7FB2EFDB0EC8799D" Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 17:22:43 -0000 This is a multi-part message in MIME format. --------------05C0A3FF7FB2EFDB0EC8799D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi John, > The privacy problem is a touch hypothetical the way that OAuth > currently works. There is not standard access token, a AS producing > access tokens that could be used across a number of RS in different > security domains would be a security disaster, unless they are proof > of possession tokens. If all of the RS trust each other by being in > the same security domain they can all collude and the AS can know > where the tokens are used without the resource being indicated to the > AS directly. If the RS are in different security domains then > potentially some privacy is disclosed. I am dealing with scenarios where RS may be in the same security domain or in different security domains. More precisely, none of the RS will necessarily be in the same security domain as the AS. > The only way to deal with that is the alternative of POP AT that the > WG is documenting separately. I disagree. There are some cases, where an access token should be targeted to a RS and the target RS should be indicated in the access token. draft-campbell-oauth-resource-indicators should say that data that can be recognized by the RS may be incorporated into the access token. This has nothing to do with POP which is another issue. draft-ietf-oauth-pop-architecture-08 does not, unfortunately, provides a solution since a major threat has been omitted: Collusion between users Users can collude and one user may attempt to use an access token legitimately obtained from an AS and then transmit it to another user so that it can be used on the same RS. This document states on page (clause 3.3): * the important assumption in this use case is that a resource server does not have TLS support and the security solution should work in such a scenario. This means that binding the access token to HTTP (see draft-ietf-tokbind-https-06) is not a valid solution since it is unable to address the Alice and Bob Collusion (ABC) attack. > I think it is fine to say that if the AS are in separate security > domains and privacy is a issue, then use PoP rather than resource to > protect the AT from replay. I do not think this is what should be said. If an access token cannot be replayed on another RS, then it does not necessarily need to be targeted to a RS (... but it will not heart). If privacy is a concern _and_ if there is a need to include a target RS in an access token because the access token might be forwarded to another RS, then a pseudo-random number shall be used to identify the RS rather than an absolute URI. > The reason for using a URI for the resource is that it is something the client knows. > If we use a abstract name the client might be tricked into giving a token to the wrong resource. Please take another look at the example I have provided below. The problem you mention does not exist. Denis > John B. > > >> On Nov 22, 2016, at 9:34 AM, Denis wrote: >> >> Hi Hannes, >> >> I do not deny the fact that it is necessary to provide some information to the authorization server >> to indicate the resource server where the access token shall only be used. >> >> Let us illustrate the concept with a simple scenario. >> >> A user first connects to a resource server and announces some actions he would like to perform. >> In its response, the resource server indicates "demonstrate that you are older than 18 and incorporate >> in your access token the random value (some kind of challenge) I have just generated for you only". >> >> The client forwards that random value to the authorization server which is blindly copied and pasted >> into the access token. If the resource server does not recognize this value, the access will be denied. >> >> In this way, the authorization server has no way to know where the access token will be used. >> >> On the contrary, an absolute URI would allow the authorization server to know which resources the user is accessing. >> The use of an absolute URI should be deprecated because of this privacy concern. >> >> Denis >> >>> Hi Denis >>> >>> draft-campbell-oauth-resource-indicators gives the authorization server >>> information about the resource server the access token will be used with. >>> >>> Without this information there is the risk that the access token is >>> replayed at other resource servers and with the proof-of-possession / >>> token binding work there obviously has to be an indication of where the >>> token is used. >>> >>> The reason for using an absolute URI is that the resource server needs >>> to take the information from the incoming access token and to compare it >>> with its own information in order to determine whether the token is >>> indeed intended for itself. >>> >>> If the authorization server does not know to whom it gives rights to >>> access protected information then this is also a privacy risk (namely >>> unauthorized access). >>> >>> Ciao >>> Hannes >>> >>> On 11/15/2016 12:50 PM, Denis wrote: >>>> Hello everybody, >>>> >>>> Since I am not present at the meeting, I read the minutes from the first >>>> session, in particular: >>>> >>>> Brian Campbell and John did a draft allowing the client to tell the >>>> AS where it plans to use the token >>>> draft-campbell-oauth-resource-indicators >>>> >>>> This enables the AS to audience restrict the access >>>> token to the resource >>>> Phil Hunt: We should keep the audience restriction >>>> idea on the table >>>> >>>> The introduction contains the following sentences: >>>> >>>> Several years of deployment and implementation experience with OAuth >>>> 2.0 [RFC6749] has uncovered a need, in some circumstances, >>>> for the client to explicitly signal to the authorization sever where >>>> it intends to use the access token it is requesting. >>>> >>>> A means for the client to signal to the authorization sever where it >>>> intends to use the access token it's requesting is important and >>>> useful. >>>> >>>> The document contains a "security considerations" section but >>>> unfortunately no "privacy considerations" section. >>>> >>>> Clause 2 states: >>>> >>>> The client may indicate the resource server(s) for which it is >>>> requesting an access token by including the >>>> following parameter in the request. >>>> >>>> resource >>>> >>>> OPTIONAL. The value of the resource parameter indicates a resource >>>> server where the requested >>>> access token will be used.*It MUST be an absolute URI*, as specified >>>> by Section 4.3 of[RFC3986], >>>> >>>> With such an approach, the authorization server would have the ability >>>> to *act as a Big Brother *and hence to know exactly >>>> where the user will be performing activities. >>>> >>>> However, some users might be concerned with their privacy, and would >>>> like to restrict the use of the access token >>>> to some resource servers without the authorization server knowing which >>>> are these resource servers. >>>> >>>> The key point is whether the information is primarily intended to the >>>> authorization server or to the resource server(s). >>>> >>>> I believe that it is primarily intended to the resource server(s) rather >>>> than to the authorization server in order to be included >>>> in an access token. Obviously, the information needs to transit through >>>> the authorization sever, that should simply be copied >>>> and pasted into the access token. Its semantics, if any, does not >>>> necessarily needs to be interpreted by the authorization sever. >>>> >>>> I believe that a "privacy considerations" section should be added. >>>> >>>> The sentence "*It MUST be an absolute URI*, as specified by Section 4.3 >>>> of [RFC3986]" should be removed or >>>> replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3 >>>> of [RFC3986]". >>>> >>>> Obviously, other changes would be necessary too. >>>> >>>> Denis >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 --------------05C0A3FF7FB2EFDB0EC8799D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi John,

The privacy problem is a touch hypothetical the way that OAuth currently works.

There is not standard access token,  a AS producing access tokens that could be used across a number of RS 
in different security domains would be a security disaster, unless they are proof of possession tokens.

If all of the RS trust each other by being in the same security domain they can all collude and the AS can know 
where the tokens are used without the resource being indicated to the AS directly.  

If the RS are in different security domains then potentially some privacy is disclosed.

I am dealing with scenarios where RS may be in the same security domain or in different security domains.
More precisely, none of the RS will necessarily be in the same security domain as the AS.

 
The only way to deal with that is the alternative of POP AT that the WG is documenting separately.

I disagree. There are some cases, where an access token should be targeted to a RS and the target RS should be indicated
in the access token.

draft-campbell-oauth-resource-indicators should say that data that can be recognized by the RS may be incorporated
into the access token.

This has nothing to do with POP which is another issue.

draft-ietf-oauth-pop-architecture-08 does not, unfortunately, provides a solution since a major threat has been omitted:
Collusion between users

 Users can collude and one user may attempt to use an access token legitimately obtained from an AS
and then transmit it to another user so that it can be used on the same RS.

This document states on page (clause 3.3):
  • the important assumption in this use case is that a resource server does not have TLS support
    and the security solution should work in such a scenario.
This means that binding the access token to HTTP (see draft-ietf-tokbind-https-06) is not a valid solution
since it is unable to address the Alice and Bob Collusion (ABC) attack. 

I think it is fine to say that if the AS are in separate security domains and privacy is a issue,
 then use PoP rather than resource to protect the AT from replay.

I do not think this is what should be said.

If an access token cannot be replayed on another RS, then it does not necessarily need to be targeted to a RS (... but it will not heart).

If privacy is a concern and if there is a need to include a target RS in an access token because the access token might be forwarded
to another RS, then a pseudo-random number shall be used to identify the RS rather than an absolute URI. 

The reason for using a URI for the resource is that it is something the client knows.  
If we use a abstract name the client might be tricked into giving a token to the wrong resource.

Please take another look at the example I have provided below. The problem you mention does not exist.

Denis
John B.



On Nov 22, 2016, at 9:34 AM, Denis <denis.ietf@free.fr> wrote:

Hi Hannes,

I do not deny the fact that it is necessary to provide some information to the authorization server
to indicate the resource server where the access token shall only be used.

Let us illustrate the concept with a simple scenario.

A user first connects to a resource server and announces some actions he would like to perform.
In its response, the resource server indicates "demonstrate that you are older than 18 and incorporate
in your access token the random value (some kind of challenge) I have just generated for you only".

The client forwards that random value to the authorization server which is blindly copied and pasted
into the access token. If the resource server does not recognize this value, the access will be denied.

In this way, the authorization server has no way to know where the access token will be used.

On the contrary, an absolute URI would allow the authorization server to know which resources the user is accessing.
The use of an absolute URI should be deprecated because of this privacy concern.

Denis


Hi Denis

draft-campbell-oauth-resource-indicators gives the authorization server
information about the resource server the access token will be used with.

Without this information there is the risk that the access token is
replayed at other resource servers and with the proof-of-possession /
token binding work there obviously has to be an indication of where the
token is used.

The reason for using an absolute URI is that the resource server needs
to take the information from the incoming access token and to compare it
with its own information in order to determine whether the token is
indeed intended for itself.

If the authorization server does not know to whom it gives rights to
access protected information then this is also a privacy risk (namely
unauthorized access).

Ciao
Hannes

On 11/15/2016 12:50 PM, Denis wrote:

Hello everybody,

Since I am not present at the meeting, I read the minutes from the first
session, in particular:

    Brian Campbell and John did a draft allowing the client to tell the
    AS where it plans to use the token
    draft-campbell-oauth-resource-indicators

                  This enables the AS to audience restrict the access
    token to the resource
                  Phil Hunt:  We should keep the audience restriction
    idea on the table

The introduction contains the following sentences:

    Several years of deployment and implementation experience with OAuth
    2.0 [RFC6749] has uncovered a need, in some circumstances,
    for the client to explicitly signal to the authorization sever where
    it intends to use the access token it is requesting.

    A means for the client to signal to the authorization sever where it
    intends to use the access token it's requesting is important and
    useful.

The document contains a "security considerations" section but
unfortunately no "privacy considerations" section.

Clause 2 states:

    The client may indicate the resource server(s) for which it is
    requesting an access token by including the
    following parameter in the request.

    resource

    OPTIONAL. The value of the resource parameter indicates a resource
    server where the requested
    access token will be used.*It MUST be an absolute URI*, as specified
    by Section 4.3 of[RFC3986],

With such an approach, the authorization server would have the ability
to *act as a Big Brother *and hence to know exactly
where the user will be performing activities.

However, some users might be concerned with their privacy, and would
like to restrict the use of the access token
to some resource servers without the authorization server knowing which
are these resource servers.

The key point is whether the information is primarily intended to the
authorization server or to the resource server(s).

I believe that it is primarily intended to the resource server(s) rather
than to the authorization server in order to be included
in an access token. Obviously, the information needs to transit through
the authorization sever, that should simply be copied
and pasted into the access token. Its semantics, if any, does not
necessarily needs to be interpreted by the authorization sever.

I believe that a "privacy considerations" section should be added.

The sentence "*It MUST be an absolute URI*, as specified by Section 4.3
of [RFC3986]" should be removed or
 replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3
of [RFC3986]".

Obviously, other changes would be necessary too.

Denis



_______________________________________________
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


    

    


    

  


--------------05C0A3FF7FB2EFDB0EC8799D--


From nobody Tue Nov 22 11:31:11 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14932129B3F for ; Tue, 22 Nov 2016 11:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level: 
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqD9CGR5xLJt for ; Tue, 22 Nov 2016 11:31:06 -0800 (PST)
Received: from omr-m008e.mx.aol.com (omr-m008e.mx.aol.com [204.29.186.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A49129E87 for ; Tue, 22 Nov 2016 11:31:06 -0800 (PST)
Received: from mtaout-mac01.mx.aol.com (mtaout-mac01.mx.aol.com [172.26.222.205]) by omr-m008e.mx.aol.com (Outbound Mail Relay) with ESMTP id F1A6138000F2; Tue, 22 Nov 2016 14:31:04 -0500 (EST)
Received: from [10.172.104.61] (unknown [10.172.104.61]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mac01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 75EFA38000093; Tue, 22 Nov 2016 14:31:03 -0500 (EST)
To: Denis , John Bradley 
References:  <7fe51b7f-cc68-abda-79ed-9b6d75e00bc4@gmx.net> <5161dc3d-aac7-acb3-d4b3-7e6864a0520b@free.fr> <468C84B4-B2B3-4CC8-8AD1-A25A0D6893EF@ve7jtb.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <6f5973b7-8f16-031d-9fab-d96943fd4da7@aol.com>
Date: Tue, 22 Nov 2016 14:31:02 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------ABF556CB47122F373687E575"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1479843064; bh=tEhvZoheR6eSoswBOFSjmcSvzRbyhWmH+CU9n3LzJ6I=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=6a4MBL20U6palUVejaDs5ARB24k1yFDCI69Yt3eKiaf1NwQiqsYmaEfeKXHfusDgS /mlaOzohPxWVIJkt03DIum7++snpdkhSBUOCzCeAX0fet/5dLVZJ2oEpttf+UKirDo REC1gjJndmKN9EiQac6eoMaD2GRhLRtTfffzeaJU=
x-aol-sid: 3039ac1adecd58349cf77f3d
X-AOL-IP: 10.172.104.61
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2016 19:31:09 -0000

This is a multi-part message in MIME format.
--------------ABF556CB47122F373687E575
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Denis,

If I understand your arguments correctly, you'd like a way to ask the AS 
to add an RS supplied nonce to the access_token. This is done in OpenID 
Connect with the id_token but nothing like this exists within OAuth2. 
Largely because the entity asking for the token (client) is different 
from the entity that will consume the token (resource server).

I see this oauth-resource-indicators spec trying to address a different 
problem. Namely, allowing the AS to not issue a token if the requested 
"resource" is suspect or does not in some way meet the AS policy.

It's unclear from the spec, how the RS should do audience restriction 
though I suspect that the RS will introspect the token and then compare 
the returned audience(s) in some way with itself. [Brian/John/Hannes I'd 
recommending adding a section on audience restriction processing in the RS.]

The model you suggest in this thread is much closer to UMA (User Managed 
Access) [1] where the client first tries to access a resource and then 
is told they need to obtain some additional claims before access will be 
granted.

Thanks,
George

[1] https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html

On 11/22/16 12:22 PM, Denis wrote:
> Hi John,
>
>> The privacy problem is a touch hypothetical the way that OAuth 
>> currently works. There is not standard access token, a AS producing 
>> access tokens that could be used across a number of RS in different 
>> security domains would be a security disaster, unless they are proof 
>> of possession tokens. If all of the RS trust each other by being in 
>> the same security domain they can all collude and the AS can know 
>> where the tokens are used without the resource being indicated to the 
>> AS directly. If the RS are in different security domains then 
>> potentially some privacy is disclosed.
>
> I am dealing with scenarios where RS may be in the same security 
> domain or in different security domains.
> More precisely, none of the RS will necessarily be in the same 
> security domain as the AS.
>
>> The only way to deal with that is the alternative of POP AT that the 
>> WG is documenting separately.
>
> I disagree.  There are some cases, where an access token should be 
> targeted to a RS and the target RS should be indicated
> in the access token.
>
> draft-campbell-oauth-resource-indicators should say that data that can 
> be recognized by the RS may be incorporated
> into the access token.
>
> This has nothing to do with POP which is another issue.
>
> draft-ietf-oauth-pop-architecture-08 does not, unfortunately, provides 
> a solution since a major threat has been omitted:
>
>     Collusion between users
>
>           Users can collude and one user may attempt to use an access
>     token legitimately obtained from an AS
>           and then transmit it to another user so that it can be used
>     on the same RS.
>
>
> This document states on page (clause 3.3):
>
>   * the important assumption in this use case is that a resource
>     server does not have TLS support
>     and the security solution should work in such a scenario.
>
> This means that binding the access token to HTTP (see 
> draft-ietf-tokbind-https-06) is not a valid solution
> since it is unable to address the Alice and Bob Collusion (ABC) attack.
>
>> I think it is fine to say that if the AS are in separate security 
>> domains and privacy is a issue, then use PoP rather than resource to 
>> protect the AT from replay.
>
> I do not think this is what should be said.
>
> If an access token cannot be replayed on another RS, then it does not 
> necessarily need to be targeted to a RS (... but it will not heart).
>
> If privacy is a concern _and_ if there is a need to include a target 
> RS in an access token because the access token might be forwarded
> to another RS, then a pseudo-random number shall be used to identify 
> the RS rather than an absolute URI.
>
>> The reason for using a URI for the resource is that it is something the client knows.
>> If we use a abstract name the client might be tricked into giving a token to the wrong resource.
>
> Please take another look at the example I have provided below. The 
> problem you mention does not exist.
>
> Denis
>> John B.
>>
>>
>>> On Nov 22, 2016, at 9:34 AM, Denis  wrote:
>>>
>>> Hi Hannes,
>>>
>>> I do not deny the fact that it is necessary to provide some information to the authorization server
>>> to indicate the resource server where the access token shall only be used.
>>>
>>> Let us illustrate the concept with a simple scenario.
>>>
>>> A user first connects to a resource server and announces some actions he would like to perform.
>>> In its response, the resource server indicates "demonstrate that you are older than 18 and incorporate
>>> in your access token the random value (some kind of challenge) I have just generated for you only".
>>>
>>> The client forwards that random value to the authorization server which is blindly copied and pasted
>>> into the access token. If the resource server does not recognize this value, the access will be denied.
>>>
>>> In this way, the authorization server has no way to know where the access token will be used.
>>>
>>> On the contrary, an absolute URI would allow the authorization server to know which resources the user is accessing.
>>> The use of an absolute URI should be deprecated because of this privacy concern.
>>>
>>> Denis
>>>
>>>> Hi Denis
>>>>
>>>> draft-campbell-oauth-resource-indicators gives the authorization server
>>>> information about the resource server the access token will be used with.
>>>>
>>>> Without this information there is the risk that the access token is
>>>> replayed at other resource servers and with the proof-of-possession /
>>>> token binding work there obviously has to be an indication of where the
>>>> token is used.
>>>>
>>>> The reason for using an absolute URI is that the resource server needs
>>>> to take the information from the incoming access token and to compare it
>>>> with its own information in order to determine whether the token is
>>>> indeed intended for itself.
>>>>
>>>> If the authorization server does not know to whom it gives rights to
>>>> access protected information then this is also a privacy risk (namely
>>>> unauthorized access).
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> On 11/15/2016 12:50 PM, Denis wrote:
>>>>> Hello everybody,
>>>>>
>>>>> Since I am not present at the meeting, I read the minutes from the first
>>>>> session, in particular:
>>>>>
>>>>>      Brian Campbell and John did a draft allowing the client to tell the
>>>>>      AS where it plans to use the token
>>>>>      draft-campbell-oauth-resource-indicators
>>>>>
>>>>>                    This enables the AS to audience restrict the access
>>>>>      token to the resource
>>>>>                    Phil Hunt:  We should keep the audience restriction
>>>>>      idea on the table
>>>>>
>>>>> The introduction contains the following sentences:
>>>>>
>>>>>      Several years of deployment and implementation experience with OAuth
>>>>>      2.0 [RFC6749] has uncovered a need, in some circumstances,
>>>>>      for the client to explicitly signal to the authorization sever where
>>>>>      it intends to use the access token it is requesting.
>>>>>
>>>>>      A means for the client to signal to the authorization sever where it
>>>>>      intends to use the access token it's requesting is important and
>>>>>      useful.
>>>>>
>>>>> The document contains a "security considerations" section but
>>>>> unfortunately no "privacy considerations" section.
>>>>>
>>>>> Clause 2 states:
>>>>>
>>>>>      The client may indicate the resource server(s) for which it is
>>>>>      requesting an access token by including the
>>>>>      following parameter in the request.
>>>>>
>>>>>      resource
>>>>>
>>>>>      OPTIONAL. The value of the resource parameter indicates a resource
>>>>>      server where the requested
>>>>>      access token will be used.*It MUST be an absolute URI*, as specified
>>>>>      by Section 4.3 of[RFC3986],
>>>>>
>>>>> With such an approach, the authorization server would have the ability
>>>>> to *act as a Big Brother *and hence to know exactly
>>>>> where the user will be performing activities.
>>>>>
>>>>> However, some users might be concerned with their privacy, and would
>>>>> like to restrict the use of the access token
>>>>> to some resource servers without the authorization server knowing which
>>>>> are these resource servers.
>>>>>
>>>>> The key point is whether the information is primarily intended to the
>>>>> authorization server or to the resource server(s).
>>>>>
>>>>> I believe that it is primarily intended to the resource server(s) rather
>>>>> than to the authorization server in order to be included
>>>>> in an access token. Obviously, the information needs to transit through
>>>>> the authorization sever, that should simply be copied
>>>>> and pasted into the access token. Its semantics, if any, does not
>>>>> necessarily needs to be interpreted by the authorization sever.
>>>>>
>>>>> I believe that a "privacy considerations" section should be added.
>>>>>
>>>>> The sentence "*It MUST be an absolute URI*, as specified by Section 4.3
>>>>> of [RFC3986]" should be removed or
>>>>>   replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3
>>>>> of [RFC3986]".
>>>>>
>>>>> Obviously, other changes would be necessary too.
>>>>>
>>>>> Denis
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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


--------------ABF556CB47122F373687E575
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Denis,

    

    If I understand your arguments correctly, you'd like a way to ask
    the AS to add an RS supplied nonce to the access_token. This is done
    in OpenID Connect with the id_token but nothing like this exists
    within OAuth2. Largely because the entity asking for the token
    (client) is different from the entity that will consume the token
    (resource server).

    

    I see this oauth-resource-indicators spec trying to address a
    different problem. Namely, allowing the AS to not issue a token if
    the requested "resource" is suspect or does not in some way meet the
    AS policy.

    

    It's unclear from the spec, how the RS should do audience
    restriction though I suspect that the RS will introspect the token
    and then compare the returned audience(s) in some way with itself.
    [Brian/John/Hannes I'd recommending adding a section on audience
    restriction processing in the RS.]

    

    The model you suggest in this thread is much closer to UMA (User
    Managed Access) [1] where the client first tries to access a
    resource and then is told they need to obtain some additional claims
    before access will be granted.

    

    Thanks,

    George

    

    [1] https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html

    

    
On 11/22/16 12:22 PM, Denis wrote:

    

    

      
      
Hi John,

          

        

      

        
The privacy problem is a touch hypothetical the way that OAuth currently works.

There is not standard access token,  a AS producing access tokens that could be used across a number of RS 
in different security domains would be a security disaster, unless they are proof of possession tokens.

If all of the RS trust each other by being in the same security domain they can all collude and the AS can know 
where the tokens are used without the resource being indicated to the AS directly.  

If the RS are in different security domains then potentially some privacy is disclosed.  


      

      

        I am dealing with scenarios where RS may be in the same security
        domain or in different security domains. 

        More precisely, none of the RS will necessarily be in the same
        security domain as the AS.

        

      
      

        
The only way to deal with that is the alternative of POP AT that the WG is documenting separately. 

      

      

        I disagree.  There are some cases, where an access token should
        be targeted to a RS and the target RS should be indicated 

        in the access token.

        

        draft-campbell-oauth-resource-indicators should say that data
        that can be recognized by the RS may be incorporated 

        into the access token. 

        

        This has nothing to do with POP which is another issue.

        

        draft-ietf-oauth-pop-architecture-08 does not, unfortunately,
        provides a solution since a major threat has been omitted:

        

      
      
Collusion between
          users

          

               Users can collude and one user may
          attempt to use an access token legitimately obtained from an
          AS 

                and then transmit it to another user so that it can be
          used on the same RS.

        

      

        This document states on page (clause 3.3):

      
      
    
        
  • the important assumption in this use case
            is that a resource server does not have TLS support 
    
            and the security solution should work in such a scenario.
    • 
      

      This means that binding the access token to
        HTTP (see draft-ietf-tokbind-https-06) is not a valid solution 

        since it is unable to address the Alice and Bob Collusion (ABC)
        attack. 

        

      
      

        
I think it is fine to say that if the AS are in separate security domains and privacy is a issue,
 then use PoP rather than resource to protect the AT from replay.


      

      

        I do not think this is what should be said.

        

        If an access token cannot be replayed on another RS, then it
        does not necessarily need to be targeted to a RS (... but it
        will not heart).

        

        If privacy is a concern and if there is a need to
        include a target RS in an access token because the access token
        might be forwarded 

        to another RS, then a pseudo-random number shall be used to
        identify the RS rather than an absolute URI. 

      

      

        
The reason for using a URI for the resource is that it is something the client knows.  
If we use a abstract name the client might be tricked into giving a token to the wrong resource.

      

      

      Please take another look at the example I have
        provided below. The problem you mention does not exist.

        

        Denis

       
      

        
John B.




        

          
On Nov 22, 2016, at 9:34 AM, Denis <denis.ietf@free.fr> wrote:

Hi Hannes,

I do not deny the fact that it is necessary to provide some information to the authorization server
to indicate the resource server where the access token shall only be used.

Let us illustrate the concept with a simple scenario.

A user first connects to a resource server and announces some actions he would like to perform.
In its response, the resource server indicates "demonstrate that you are older than 18 and incorporate
in your access token the random value (some kind of challenge) I have just generated for you only".

The client forwards that random value to the authorization server which is blindly copied and pasted
into the access token. If the resource server does not recognize this value, the access will be denied.

In this way, the authorization server has no way to know where the access token will be used.

On the contrary, an absolute URI would allow the authorization server to know which resources the user is accessing.
The use of an absolute URI should be deprecated because of this privacy concern.

Denis



          

            
Hi Denis

draft-campbell-oauth-resource-indicators gives the authorization server
information about the resource server the access token will be used with.

Without this information there is the risk that the access token is
replayed at other resource servers and with the proof-of-possession /
token binding work there obviously has to be an indication of where the
token is used.

The reason for using an absolute URI is that the resource server needs
to take the information from the incoming access token and to compare it
with its own information in order to determine whether the token is
indeed intended for itself.

If the authorization server does not know to whom it gives rights to
access protected information then this is also a privacy risk (namely
unauthorized access).

Ciao
Hannes

On 11/15/2016 12:50 PM, Denis wrote:


            

              
Hello everybody,

Since I am not present at the meeting, I read the minutes from the first
session, in particular:

    Brian Campbell and John did a draft allowing the client to tell the
    AS where it plans to use the token
    draft-campbell-oauth-resource-indicators

                  This enables the AS to audience restrict the access
    token to the resource
                  Phil Hunt:  We should keep the audience restriction
    idea on the table

The introduction contains the following sentences:

    Several years of deployment and implementation experience with OAuth
    2.0 [RFC6749] has uncovered a need, in some circumstances,
    for the client to explicitly signal to the authorization sever where
    it intends to use the access token it is requesting.

    A means for the client to signal to the authorization sever where it
    intends to use the access token it's requesting is important and
    useful.

The document contains a "security considerations" section but
unfortunately no "privacy considerations" section.

Clause 2 states:

    The client may indicate the resource server(s) for which it is
    requesting an access token by including the
    following parameter in the request.

    resource

    OPTIONAL. The value of the resource parameter indicates a resource
    server where the requested
    access token will be used.*It MUST be an absolute URI*, as specified
    by Section 4.3 of[RFC3986],

With such an approach, the authorization server would have the ability
to *act as a Big Brother *and hence to know exactly
where the user will be performing activities.

However, some users might be concerned with their privacy, and would
like to restrict the use of the access token
to some resource servers without the authorization server knowing which
are these resource servers.

The key point is whether the information is primarily intended to the
authorization server or to the resource server(s).

I believe that it is primarily intended to the resource server(s) rather
than to the authorization server in order to be included
in an access token. Obviously, the information needs to transit through
the authorization sever, that should simply be copied
and pasted into the access token. Its semantics, if any, does not
necessarily needs to be interpreted by the authorization sever.

I believe that a "privacy considerations" section should be added.

The sentence "*It MUST be an absolute URI*, as specified by Section 4.3
of [RFC3986]" should be removed or
 replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3
of [RFC3986]".

Obviously, other changes would be necessary too.

Denis



_______________________________________________
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


    

    

  


--------------ABF556CB47122F373687E575--


From nobody Tue Nov 22 12:44:31 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E415512943C for ; Tue, 22 Nov 2016 12:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep5Zwxrv81_8 for ; Tue, 22 Nov 2016 12:44:26 -0800 (PST)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A89129464 for ; Tue, 22 Nov 2016 12:44:09 -0800 (PST)
Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 7E242780368; Tue, 22 Nov 2016 21:44:06 +0100 (CET)
To: George Fletcher , John Bradley 
References:  <7fe51b7f-cc68-abda-79ed-9b6d75e00bc4@gmx.net> <5161dc3d-aac7-acb3-d4b3-7e6864a0520b@free.fr> <468C84B4-B2B3-4CC8-8AD1-A25A0D6893EF@ve7jtb.com>  <6f5973b7-8f16-031d-9fab-d96943fd4da7@aol.com>
From: Denis 
Message-ID: 
Date: Tue, 22 Nov 2016 21:44:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <6f5973b7-8f16-031d-9fab-d96943fd4da7@aol.com>
Content-Type: multipart/alternative; boundary="------------DAA2F571806FF76E6C04B540"
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2016 20:44:30 -0000

This is a multi-part message in MIME format.
--------------DAA2F571806FF76E6C04B540
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi George,

As you say "It's unclear from the spec, how the RS should do audience 
restriction".

There are two cases where I can see a benefit:

a) if the user is younger than 18, the IdP knows it and can filter the 
URIs using a black list of sites that are not allowed to minors.
b) if the user is using an IdP server from his employer, the employer 
can filter the URI using a white list of sites that are allowed.

However, if the user is older than 18 and is using an independent IdP 
(e.g. from his bank), no filtering should be done
and thus a "non-URI value" should/may/can be used.

So I withdraw my previous statement saying that " The use of an absolute 
URI should be deprecated".

Also take note that there is a need to include a target RS in an access 
token *only if* the access token might be forwarded
to another RS,

I believe that, in any case, a "privacy considerations" section should 
be added to inform the reader about the pros and the cons.

Denis

> Hi Denis,
>
> If I understand your arguments correctly, you'd like a way to ask the 
> AS to add an RS supplied nonce to the access_token. This is done in 
> OpenID Connect with the id_token but nothing like this exists within 
> OAuth2. Largely because the entity asking for the token (client) is 
> different from the entity that will consume the token (resource server).
>
> I see this oauth-resource-indicators spec trying to address a 
> different problem. Namely, allowing the AS to not issue a token if the 
> requested "resource" is suspect or does not in some way meet the AS 
> policy.
>
> It's unclear from the spec, how the RS should do audience restriction 
> though I suspect that the RS will introspect the token and then 
> compare the returned audience(s) in some way with itself. 
> [Brian/John/Hannes I'd recommending adding a section on audience 
> restriction processing in the RS.]
>
> The model you suggest in this thread is much closer to UMA (User 
> Managed Access) [1] where the client first tries to access a resource 
> and then is told they need to obtain some additional claims before 
> access will be granted.
>
> Thanks,
> George
>
> [1] https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html
>
> On 11/22/16 12:22 PM, Denis wrote:
>> Hi John,
>>
>>> The privacy problem is a touch hypothetical the way that OAuth 
>>> currently works. There is not standard access token, a AS producing 
>>> access tokens that could be used across a number of RS in different 
>>> security domains would be a security disaster, unless they are proof 
>>> of possession tokens. If all of the RS trust each other by being in 
>>> the same security domain they can all collude and the AS can know 
>>> where the tokens are used without the resource being indicated to 
>>> the AS directly. If the RS are in different security domains then 
>>> potentially some privacy is disclosed.
>>
>> I am dealing with scenarios where RS may be in the same security 
>> domain or in different security domains.
>> More precisely, none of the RS will necessarily be in the same 
>> security domain as the AS.
>>
>>> The only way to deal with that is the alternative of POP AT that the 
>>> WG is documenting separately.
>>
>> I disagree.  There are some cases, where an access token should be 
>> targeted to a RS and the target RS should be indicated
>> in the access token.
>>
>> draft-campbell-oauth-resource-indicators should say that data that 
>> can be recognized by the RS may be incorporated
>> into the access token.
>>
>> This has nothing to do with POP which is another issue.
>>
>> draft-ietf-oauth-pop-architecture-08 does not, unfortunately, 
>> provides a solution since a major threat has been omitted:
>>
>>     Collusion between users
>>
>>           Users can collude and one user may attempt to use an access
>>     token legitimately obtained from an AS
>>           and then transmit it to another user so that it can be used
>>     on the same RS.
>>
>>
>> This document states on page (clause 3.3):
>>
>>   * the important assumption in this use case is that a resource
>>     server does not have TLS support
>>     and the security solution should work in such a scenario.
>>
>> This means that binding the access token to HTTP (see 
>> draft-ietf-tokbind-https-06) is not a valid solution
>> since it is unable to address the Alice and Bob Collusion (ABC) attack.
>>
>>> I think it is fine to say that if the AS are in separate security 
>>> domains and privacy is a issue, then use PoP rather than resource to 
>>> protect the AT from replay.
>>
>> I do not think this is what should be said.
>>
>> If an access token cannot be replayed on another RS, then it does not 
>> necessarily need to be targeted to a RS (... but it will not heart).
>>
>> If privacy is a concern _and_ if there is a need to include a target 
>> RS in an access token because the access token might be forwarded
>> to another RS, then a pseudo-random number shall be used to identify 
>> the RS rather than an absolute URI.
>>
>>> The reason for using a URI for the resource is that it is something the client knows.
>>> If we use a abstract name the client might be tricked into giving a token to the wrong resource.
>>
>> Please take another look at the example I have provided below. The 
>> problem you mention does not exist.
>>
>> Denis
>>> John B.
>>>
>>>
>>>> On Nov 22, 2016, at 9:34 AM, Denis  wrote:
>>>>
>>>> Hi Hannes,
>>>>
>>>> I do not deny the fact that it is necessary to provide some information to the authorization server
>>>> to indicate the resource server where the access token shall only be used.
>>>>
>>>> Let us illustrate the concept with a simple scenario.
>>>>
>>>> A user first connects to a resource server and announces some actions he would like to perform.
>>>> In its response, the resource server indicates "demonstrate that you are older than 18 and incorporate
>>>> in your access token the random value (some kind of challenge) I have just generated for you only".
>>>>
>>>> The client forwards that random value to the authorization server which is blindly copied and pasted
>>>> into the access token. If the resource server does not recognize this value, the access will be denied.
>>>>
>>>> In this way, the authorization server has no way to know where the access token will be used.
>>>>
>>>> On the contrary, an absolute URI would allow the authorization server to know which resources the user is accessing.
>>>> The use of an absolute URI should be deprecated because of this privacy concern.
>>>>
>>>> Denis
>>>>
>>>>> Hi Denis
>>>>>
>>>>> draft-campbell-oauth-resource-indicators gives the authorization server
>>>>> information about the resource server the access token will be used with.
>>>>>
>>>>> Without this information there is the risk that the access token is
>>>>> replayed at other resource servers and with the proof-of-possession /
>>>>> token binding work there obviously has to be an indication of where the
>>>>> token is used.
>>>>>
>>>>> The reason for using an absolute URI is that the resource server needs
>>>>> to take the information from the incoming access token and to compare it
>>>>> with its own information in order to determine whether the token is
>>>>> indeed intended for itself.
>>>>>
>>>>> If the authorization server does not know to whom it gives rights to
>>>>> access protected information then this is also a privacy risk (namely
>>>>> unauthorized access).
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>> On 11/15/2016 12:50 PM, Denis wrote:
>>>>>> Hello everybody,
>>>>>>
>>>>>> Since I am not present at the meeting, I read the minutes from the first
>>>>>> session, in particular:
>>>>>>
>>>>>>      Brian Campbell and John did a draft allowing the client to tell the
>>>>>>      AS where it plans to use the token
>>>>>>      draft-campbell-oauth-resource-indicators
>>>>>>
>>>>>>                    This enables the AS to audience restrict the access
>>>>>>      token to the resource
>>>>>>                    Phil Hunt:  We should keep the audience restriction
>>>>>>      idea on the table
>>>>>>
>>>>>> The introduction contains the following sentences:
>>>>>>
>>>>>>      Several years of deployment and implementation experience with OAuth
>>>>>>      2.0 [RFC6749] has uncovered a need, in some circumstances,
>>>>>>      for the client to explicitly signal to the authorization sever where
>>>>>>      it intends to use the access token it is requesting.
>>>>>>
>>>>>>      A means for the client to signal to the authorization sever where it
>>>>>>      intends to use the access token it's requesting is important and
>>>>>>      useful.
>>>>>>
>>>>>> The document contains a "security considerations" section but
>>>>>> unfortunately no "privacy considerations" section.
>>>>>>
>>>>>> Clause 2 states:
>>>>>>
>>>>>>      The client may indicate the resource server(s) for which it is
>>>>>>      requesting an access token by including the
>>>>>>      following parameter in the request.
>>>>>>
>>>>>>      resource
>>>>>>
>>>>>>      OPTIONAL. The value of the resource parameter indicates a resource
>>>>>>      server where the requested
>>>>>>      access token will be used.*It MUST be an absolute URI*, as specified
>>>>>>      by Section 4.3 of[RFC3986],
>>>>>>
>>>>>> With such an approach, the authorization server would have the ability
>>>>>> to *act as a Big Brother *and hence to know exactly
>>>>>> where the user will be performing activities.
>>>>>>
>>>>>> However, some users might be concerned with their privacy, and would
>>>>>> like to restrict the use of the access token
>>>>>> to some resource servers without the authorization server knowing which
>>>>>> are these resource servers.
>>>>>>
>>>>>> The key point is whether the information is primarily intended to the
>>>>>> authorization server or to the resource server(s).
>>>>>>
>>>>>> I believe that it is primarily intended to the resource server(s) rather
>>>>>> than to the authorization server in order to be included
>>>>>> in an access token. Obviously, the information needs to transit through
>>>>>> the authorization sever, that should simply be copied
>>>>>> and pasted into the access token. Its semantics, if any, does not
>>>>>> necessarily needs to be interpreted by the authorization sever.
>>>>>>
>>>>>> I believe that a "privacy considerations" section should be added.
>>>>>>
>>>>>> The sentence "*It MUST be an absolute URI*, as specified by Section 4.3
>>>>>> of [RFC3986]" should be removed or
>>>>>>   replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3
>>>>>> of [RFC3986]".
>>>>>>
>>>>>> Obviously, other changes would be necessary too.
>>>>>>
>>>>>> Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>


--------------DAA2F571806FF76E6C04B540
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi George,

        

        As you say "It's unclear from the spec, how the RS should do
        audience restriction".

        

        There are two cases where I can see a benefit: 

        

        a) if the user is younger than 18, the IdP knows it and can
        filter the URIs using a black list of sites that are not allowed
        to minors.

        b) if the user is using an IdP server from his employer, the
        employer can filter the URI using a white list of sites that are
        allowed.

        

        However, if the user is older than 18 and is using an
        independent IdP (e.g. from his bank), no filtering should be
        done 

        and thus a "non-URI value" should/may/can be used.

        

        So I withdraw my previous statement saying that " The use of an
        absolute URI should be deprecated".

        

        Also take note that there is a need to include a target RS in an
        access token only if the access token might be forwarded
        

        to another RS,

        

        I believe that, in any case, a "privacy considerations" section
        should be added to inform the reader about the pros and the
        cons.

        

        Denis

      

    

    

      
      Hi Denis,

      

      If I understand your arguments correctly, you'd like a way to ask
      the AS to add an RS supplied nonce to the access_token. This is
      done in OpenID Connect with the id_token but nothing like this
      exists within OAuth2. Largely because the entity asking for the
      token (client) is different from the entity that will consume the
      token (resource server).

      

      I see this oauth-resource-indicators spec trying to address a
      different problem. Namely, allowing the AS to not issue a token if
      the requested "resource" is suspect or does not in some way meet
      the AS policy.

      

      It's unclear from the spec, how the RS should do audience
      restriction though I suspect that the RS will introspect the token
      and then compare the returned audience(s) in some way with itself.
      [Brian/John/Hannes I'd recommending adding a section on audience
      restriction processing in the RS.]

      

      The model you suggest in this thread is much closer to UMA (User
      Managed Access) [1] where the client first tries to access a
      resource and then is told they need to obtain some additional
      claims before access will be granted.

      

      Thanks,

      George

      

      [1] https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html

      

      
On 11/22/16 12:22 PM, Denis wrote:

      

      

        
        
Hi John,

            

          

        

          
The privacy problem is a touch hypothetical the way that OAuth currently works.

There is not standard access token,  a AS producing access tokens that could be used across a number of RS 
in different security domains would be a security disaster, unless they are proof of possession tokens.

If all of the RS trust each other by being in the same security domain they can all collude and the AS can know 
where the tokens are used without the resource being indicated to the AS directly.  

If the RS are in different security domains then potentially some privacy is disclosed.  


        

        

          I am dealing with scenarios where RS may be in the same
          security domain or in different security domains. 

          More precisely, none of the RS will necessarily be in the same
          security domain as the AS.

          

        
        

          
The only way to deal with that is the alternative of POP AT that the WG is documenting separately. 

        

        

          I disagree.  There are some cases, where an access token
          should be targeted to a RS and the target RS should be
          indicated 

          in the access token.

          

          draft-campbell-oauth-resource-indicators should say that data
          that can be recognized by the RS may be incorporated 

          into the access token. 

          

          This has nothing to do with POP which is another issue.

          

          draft-ietf-oauth-pop-architecture-08 does not, unfortunately,
          provides a solution since a major threat has been omitted:

          

        
        
Collusion between
            users

            

                 Users can collude and one user
            may attempt to use an access token legitimately obtained
            from an AS 

                  and then transmit it to another user so that it can be
            used on the same RS.

          

        

          This document states on page (clause 3.3):

        
        
    
          
  • the important assumption in this use
              case is that a resource server does not have TLS support 
    
              and the security solution should work in such a scenario.
    • 
        

        This means that binding the access token to
          HTTP (see draft-ietf-tokbind-https-06) is not a valid solution
          

          since it is unable to address the Alice and Bob Collusion
          (ABC) attack. 

          

        
        

          
I think it is fine to say that if the AS are in separate security domains and privacy is a issue,
 then use PoP rather than resource to protect the AT from replay.


        

        

          I do not think this is what should be said.

          

          If an access token cannot be replayed on another RS, then it
          does not necessarily need to be targeted to a RS (... but it
          will not heart).

          

          If privacy is a concern and if there is a need to
          include a target RS in an access token because the access
          token might be forwarded 

          to another RS, then a pseudo-random number shall be used to
          identify the RS rather than an absolute URI. 

        

        

          
The reason for using a URI for the resource is that it is something the client knows.  
If we use a abstract name the client might be tricked into giving a token to the wrong resource.

        

        

        Please take another look at the example I
          have provided below. The problem you mention does not exist.

          

          Denis

         
        

          
John B.




          

            
On Nov 22, 2016, at 9:34 AM, Denis <denis.ietf@free.fr> wrote:

Hi Hannes,

I do not deny the fact that it is necessary to provide some information to the authorization server
to indicate the resource server where the access token shall only be used.

Let us illustrate the concept with a simple scenario.

A user first connects to a resource server and announces some actions he would like to perform.
In its response, the resource server indicates "demonstrate that you are older than 18 and incorporate
in your access token the random value (some kind of challenge) I have just generated for you only".

The client forwards that random value to the authorization server which is blindly copied and pasted
into the access token. If the resource server does not recognize this value, the access will be denied.

In this way, the authorization server has no way to know where the access token will be used.

On the contrary, an absolute URI would allow the authorization server to know which resources the user is accessing.
The use of an absolute URI should be deprecated because of this privacy concern.

Denis



            

              
Hi Denis

draft-campbell-oauth-resource-indicators gives the authorization server
information about the resource server the access token will be used with.

Without this information there is the risk that the access token is
replayed at other resource servers and with the proof-of-possession /
token binding work there obviously has to be an indication of where the
token is used.

The reason for using an absolute URI is that the resource server needs
to take the information from the incoming access token and to compare it
with its own information in order to determine whether the token is
indeed intended for itself.

If the authorization server does not know to whom it gives rights to
access protected information then this is also a privacy risk (namely
unauthorized access).

Ciao
Hannes

On 11/15/2016 12:50 PM, Denis wrote:


              

                
Hello everybody,

Since I am not present at the meeting, I read the minutes from the first
session, in particular:

    Brian Campbell and John did a draft allowing the client to tell the
    AS where it plans to use the token
    draft-campbell-oauth-resource-indicators

                  This enables the AS to audience restrict the access
    token to the resource
                  Phil Hunt:  We should keep the audience restriction
    idea on the table

The introduction contains the following sentences:

    Several years of deployment and implementation experience with OAuth
    2.0 [RFC6749] has uncovered a need, in some circumstances,
    for the client to explicitly signal to the authorization sever where
    it intends to use the access token it is requesting.

    A means for the client to signal to the authorization sever where it
    intends to use the access token it's requesting is important and
    useful.

The document contains a "security considerations" section but
unfortunately no "privacy considerations" section.

Clause 2 states:

    The client may indicate the resource server(s) for which it is
    requesting an access token by including the
    following parameter in the request.

    resource

    OPTIONAL. The value of the resource parameter indicates a resource
    server where the requested
    access token will be used.*It MUST be an absolute URI*, as specified
    by Section 4.3 of[RFC3986],

With such an approach, the authorization server would have the ability
to *act as a Big Brother *and hence to know exactly
where the user will be performing activities.

However, some users might be concerned with their privacy, and would
like to restrict the use of the access token
to some resource servers without the authorization server knowing which
are these resource servers.

The key point is whether the information is primarily intended to the
authorization server or to the resource server(s).

I believe that it is primarily intended to the resource server(s) rather
than to the authorization server in order to be included
in an access token. Obviously, the information needs to transit through
the authorization sever, that should simply be copied
and pasted into the access token. Its semantics, if any, does not
necessarily needs to be interpreted by the authorization sever.

I believe that a "privacy considerations" section should be added.

The sentence "*It MUST be an absolute URI*, as specified by Section 4.3
of [RFC3986]" should be removed or
 replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3
of [RFC3986]".

Obviously, other changes would be necessary too.

Denis



_______________________________________________
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


      

      

    

    


    

  


--------------DAA2F571806FF76E6C04B540--


From sg@teller.io  Tue Nov 22 11:14:31 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7F612956B for ; Tue, 22 Nov 2016 11:14:31 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUIKBin3Jadp for ; Tue, 22 Nov 2016 11:14:29 -0800 (PST)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530AA129B46 for ; Tue, 22 Nov 2016 11:14:29 -0800 (PST)
Received: from mfilter28-d.gandi.net (mfilter28-d.gandi.net [217.70.178.159]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id BA4EA41C089; Tue, 22 Nov 2016 20:14:27 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter28-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter28-d.gandi.net (mfilter28-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id sV3lW5Bn8FAa; Tue, 22 Nov 2016 20:14:26 +0100 (CET)
X-Originating-IP: 109.144.223.24
Received: from [10.151.231.226] (unknown [109.144.223.24]) (Authenticated sender: sg@teller.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0F42741C091; Tue, 22 Nov 2016 20:14:24 +0100 (CET)
From: Stevie Graham 
Content-Type: multipart/alternative; boundary="Apple-Mail=_9726C3BE-F373-4EC1-9F02-7A69907A6190"
Message-Id: <447103B3-BEEC-4913-AFB2-6F0A19AD77E9@teller.io>
Date: Tue, 22 Nov 2016 19:14:23 +0000
To: dick.hardt@gmail.com, jricher@mit.edu, daru.tk@gmail.com, brockallen@gmail.com, OAuth@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
Archived-At: 
X-Mailman-Approved-At: Wed, 23 Nov 2016 07:12:38 -0800
Subject: Re: [OAUTH-WG] TAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2016 19:15:22 -0000

--Apple-Mail=_9726C3BE-F373-4EC1-9F02-7A69907A6190
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

Coming across this thread late. I=E2=80=99m the Author of the TAuth =
post.

> What I don't understand is that he's saying people disable TLS checks =
so he's going to solve it with mutual TLS?=20

It=E2=80=99s simple. Mutual TLS enables service providers to assert the =
peers are properly authenticated and enforce this as a policy. This =
won=E2=80=99t stop an incompetent developer disabling peer verification =
but it will stop that developer using the service if they do.

> The reason an OAuth 2.0 server does not authenticate _public_ clients =
is because, by definition, a public client cannot keep its client secret =
confidential and so client authentication is almost meaningless.  =
but they don't recognize that their insistence relies on the assumption =
that a secret key embedded in a client application can be kept =
confidential.

This is incorrect. Modern mobile clients are capable of keeping a secret =
confidential, e.g. the Secure Enclave Processor on modern iOS devices =
and the Android analogues. The SEP can generate key material and use it =
to encrypt and sign arbitrary data. Key material is generated within the =
SEP and cannot be exfiltrated. To me this is the definition of being =
able to protect its own secrets. The TAuth bearer token analogue is not =
sensitive at all and cannot be used without the corresponding key =
material.

> Does adding TOKBIND resolve the issues?

Feel free to correct me here. I wasn=E2=80=99t that familiar with token =
binding but after reading the draft IMO it=E2=80=99s inferior to TAuth =
because it binds tokens to the connection. This necessitates refresh =
tokens, which I find an impediment to developer experience. TAuth binds =
tokens to the identity (the cert and pkey) thus can be reused again and =
again across TLS sessions. Token binding also provides no cryptographic =
guarantees that the peers are verified and that the connection is =
private.

Best

Stevie Graham

Teller - https://teller.io/ 

@stevegraham
@tellerapi


--Apple-Mail=_9726C3BE-F373-4EC1-9F02-7A69907A6190
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi,

Coming =
across this thread late. I=E2=80=99m the Author of the TAuth =
post.

> =
What I don't understand is that he's saying people disable TLS checks =
so he's going to solve it with mutual TLS? 

It=E2=80=99s simple. =
Mutual TLS enables service providers to assert the peers are properly =
authenticated and enforce this as a policy. This won=E2=80=99t stop an =
incompetent developer disabling peer verification but it will stop that =
developer using the service if they do.

> The reason an OAuth 2.0 server =
does not authenticate _public_ clients is because, by definition, a =
public client cannot keep its client secret confidential and so =
client authentication is almost meaningless. <snip> but they don't =
recognize that their insistence relies on the assumption that a =
secret key embedded in a client application can be kept =
confidential.

This is incorrect. Modern mobile clients are capable of =
keeping a secret confidential, e.g. the Secure Enclave Processor on =
modern iOS devices and the Android analogues. The SEP can generate key =
material and use it to encrypt and sign arbitrary data. Key material is =
generated within the SEP and cannot be exfiltrated. To me this is the =
definition of being able to protect its own secrets. The TAuth bearer =
token analogue is not sensitive at all and cannot be used without the =
corresponding key material.

> Does adding TOKBIND resolve the issues?

Feel free to correct me =
here. I wasn=E2=80=99t that familiar with token binding but after =
reading the draft IMO it=E2=80=99s inferior to TAuth because it binds =
tokens to the connection. This necessitates refresh tokens, which I find =
an impediment to developer experience. TAuth binds tokens to the =
identity (the cert and pkey) thus can be reused again and again across =
TLS sessions. Token binding also provides no cryptographic guarantees =
that the peers are verified and that the connection is private.

Best

Stevie Graham

Teller =
- https://teller.io/

@stevegraham
@tellerapi




=

--Apple-Mail=_9726C3BE-F373-4EC1-9F02-7A69907A6190--


From nobody Wed Nov 23 08:28:28 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E334F129F0A for ; Wed, 23 Nov 2016 08:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.698
X-Spam-Level: 
X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nritJH53xAmQ for ; Wed, 23 Nov 2016 08:28:26 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 2CBA4129F09 for ; Wed, 23 Nov 2016 08:28:25 -0800 (PST)
X-AuditID: 1209190c-7b3ff70000003e1f-25-5835c3a84422
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id DF.75.15903.8A3C5385; Wed, 23 Nov 2016 11:28:24 -0500 (EST)
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 uANGSNNx020807; Wed, 23 Nov 2016 11:28:24 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uANGSLKJ014954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Nov 2016 11:28:22 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer 
In-Reply-To: <447103B3-BEEC-4913-AFB2-6F0A19AD77E9@teller.io>
Date: Wed, 23 Nov 2016 11:28:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <447103B3-BEEC-4913-AFB2-6F0A19AD77E9@teller.io>
To: Stevie Graham 
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrLvisGmEQeM3a4sZP46yW3T1bGay eDyzyOLk21dsFqdnNrI7sHrsnHWX3WPJkp9MHqffXmQLYI7isklJzcksSy3St0vgyrg64xJz wXzTij2vNzI2MK7U7mLk5JAQMJHYdfw2axcjF4eQQBuTxN3pR5hBEkICGxklppy2hrAfMkk0 LRAEsZkF1CX+zLsEVsMroCexaf1bJhBbWEBWomnXFlYQm01AVWL6mhawOKeArcSs9z/A6lmA 4rfbvzBCzMmX6F73gBnC1pZYtvA11EwriZ8P9wPZHEB7bSTeTpYBCYsIKEjc6OtjgrhZVuLJ yUUsExgFZiG5aBaSi2YhmbqAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrqFebmaJXmpK6SZG cChL8uxgPPPG6xCjAAejEg/vjDWmEUKsiWXFlbmHGCU5mJREeU9vBArxJeWnVGYkFmfEF5Xm pBYfYpTgYFYS4VXeB5TjTUmsrEotyodJSXOwKInz/nf7Gi4kkJ5YkpqdmlqQWgSTleHgUJLg vXIIqFGwKDU9tSItM6cEIc3EwQkynAdo+DuQGt7igsTc4sx0iPwpRkUpcd77B4ESAiCJjNI8 uF5Qqkl4e9j0FaM40CvCvKtB2nmAaQqu+xXQYCagwZLfjEEGlyQipKQaGDffqmIsuuX9uDbx 4UlHw0MPfddydrJ+f1Yw26vn0Nerz1cf++t+RXjuw/Xf9CyZOy4fZCoOlI6yO3rxmk6Ysk3e adm2/AUrJFXqXbyebtxgtmyyxVf/3ecPWZ6cu0RW33nmjgfz18/bempnXOXfo+cF1T006/6d yu8Uc/ktzO5p9ntRN9fEOSlKLMUZiYZazEXFiQABsjU7EAMAAA==
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] TAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2016 16:28:28 -0000

Responses inline.

> On Nov 22, 2016, at 2:14 PM, Stevie Graham  wrote:
>=20
> Hi,
>=20
> Coming across this thread late. I=E2=80=99m the Author of the TAuth =
post.
>=20
> > What I don't understand is that he's saying people disable TLS =
checks so he's going to solve it with mutual TLS?=20
>=20
> It=E2=80=99s simple. Mutual TLS enables service providers to assert =
the peers are properly authenticated and enforce this as a policy. This =
won=E2=80=99t stop an incompetent developer disabling peer verification =
but it will stop that developer using the service if they do.

What I=E2=80=99m saying is that it=E2=80=99s a matter of complexity. The =
argument in the article I read was that deployment of TLS with server =
verification was difficult for developers. Mutual TLS is several order =
of magnitude more difficult. Does it give you reasonably strong client =
authentication? Of course, but when usability and security fight, =
usability wins. I never argued that it=E2=80=99s less secure, just less =
usable. The two arguments being made in the TAuth essay are mutually =
exclusive: =E2=80=9Cwe can=E2=80=99t use this because it=E2=80=99s too =
hard / we must use this because it=E2=80=99s more secure=E2=80=9D. You =
can=E2=80=99t say something is too difficult to use and then replace it =
with something even more difficult.=20

>=20
> > The reason an OAuth 2.0 server does not authenticate _public_ =
clients is because, by definition, a public client cannot keep its =
client secret confidential and so client authentication is almost =
meaningless.  but they don't recognize that their insistence =
relies on the assumption that a secret key embedded in a client =
application can be kept confidential.
>=20
> This is incorrect. Modern mobile clients are capable of keeping a =
secret confidential, e.g. the Secure Enclave Processor on modern iOS =
devices and the Android analogues. The SEP can generate key material and =
use it to encrypt and sign arbitrary data. Key material is generated =
within the SEP and cannot be exfiltrated. To me this is the definition =
of being able to protect its own secrets. The TAuth bearer token =
analogue is not sensitive at all and cannot be used without the =
corresponding key material.

You=E2=80=99re conflating configuration time secrets (the lack of which =
defines public clients) and runtime secrets. The ability for mobile =
applications to keep per-instance runtime secrets is exactly why we have =
both Dynamic Registration and PKCE in OAuth. What you=E2=80=99re =
describing in TAuth is largely analogous to the PoP token efforts here =
in OAuth.

>=20
> > Does adding TOKBIND resolve the issues?
>=20
> Feel free to correct me here. I wasn=E2=80=99t that familiar with =
token binding but after reading the draft IMO it=E2=80=99s inferior to =
TAuth because it binds tokens to the connection. This necessitates =
refresh tokens, which I find an impediment to developer experience. =
TAuth binds tokens to the identity (the cert and pkey) thus can be =
reused again and again across TLS sessions. Token binding also provides =
no cryptographic guarantees that the peers are verified and that the =
connection is private.

Token binding folks, correct me if I=E2=80=99m wrong, but this is my =
understanding: You don=E2=80=99t require refresh tokens with token =
binding, as the token can be used across multiple TLS connections to the =
same resource server. Refresh tokens help with cases where the resource =
owner isn=E2=80=99t present anymore and the access token is no longer =
valid.=20

There are still a lot of other issues with the premise of TAuth and its =
marketing. It=E2=80=99s not the technology of binding an access token to =
a certificate identity =E2=80=94 that=E2=80=99s not even that new: I =
proposed and built that years ago in an OAuth system in the healthcare =
space. In our case it ended up not working very well because of the =
complexities of managing mutual TLS and client certificates at the =
resource servers. We=E2=80=99re moving away from single-API systems and =
on to complex micro-service architectures with distributed resource =
servers all protected by a common AS. Keeping client credentials =
sync=E2=80=99d to such resource servers is difficult, and you=E2=80=99ll =
need a way to do that. It=E2=80=99s doable, just difficult to deploy.

But the thing is: you can do everything that TAuth can do =E2=80=94 and =
then some =E2=80=94 by augmenting OAuth with a few simple things. First, =
we=E2=80=99ve got a way to bind a certificate to a client, which is =
being discussed in a current draft here in the WG. The next step would =
be to tie that keying information to the token itself at issuance, which =
is covered in PoP architecture. The last step, and only missing step, is =
a presentation mechanism that binds the access token to the client=E2=80=99=
s certificate over mutual TLS. If you=E2=80=99re OK with the pain of =
mutual TLS (which is a huge if), then that part=E2=80=99s not difficult =
at all and could be written up in a short spec.

Instead, what really bothers me is the misinformation of what makes =
OAuth insecure and how TAuth fixes those things. The reality is that =
most of the problems cited for OAuth are deployment decisions (which do =
have very valid but not universal applicability), and TAuth is really =
just leaving different doors open for problems. For example, the essay I =
read states that =E2=80=9COAuth tokens can=E2=80=99t be revoked quickly =
but TAuth tokens can=E2=80=9D. This is just patently false, given that =
you can deploy OAuth with a shared data store or token introspection and =
get the same immediate revocation capabilities. It also states that =
OAuth tokens have to expire but TAuth tokens can live forever =E2=80=94 =
again, this is patently false. OAuth tokens don=E2=80=99t have to =
expire, but it=E2=80=99s considered good practice for them to do so in =
order to limit the attack surface. Do you really want a powerful =
credential sitting around forever? That=E2=80=99s caused many problems =
in OAuth 1 systems, which is why we built in the assumption of =
expiration possibilities in OAuth 2 and the refresh token mechanism =
(which is not a bearer token, mind you, and has a completely different =
attack surface). And if you=E2=80=99re going after developers who =
can=E2=80=99t get server-side TLS right (as per the introduction of the =
article), those same developers have exactly zero chance of getting =
mutual TLS right.=20

In the end, I welcome you to contribute TAuth to the working group here =
and hopefully have it adopted into the OAuth ecosystem.=20

 =E2=80=94 Justin


From nobody Wed Nov 23 22:48:59 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFD81294B4 for ; Wed, 23 Nov 2016 22:48:58 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFidmPyE7FsF for ; Wed, 23 Nov 2016 22:48:55 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32101294AE for ; Wed, 23 Nov 2016 22:48:54 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id g23so102759723wme.1 for ; Wed, 23 Nov 2016 22:48:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pkDaGs/24ux8xBcWrO31+gCiQqgHhC8c5jn4uzM85tQ=; b=ckOTyW/xWgS+uSlmdfsyP5PHfo7/8ox1/DDRXzFDE86V8DexKKMarhBvo/qsPHEjJD sM6qfX12PelA1MXraPixKR9tzmKjP0tp9YJsHfeS9LPe3CIkwNEtbK63jq04vUXJbZUP GpsbvIt1RqHvy/uxhgTy+YlAbKZXy6LEGr2CXGAERNCMmCsQFgNIjBBr3VsUHQjZfPIo 9KR/IphvmteN43BI5eJpop5TeUdxDYqmdTSeqdF1v+7R8ChB/5Jwn9LFB2ZwujwRYdNQ A2t0+fEapkIYXk9+WAB1t8Wt4DIzimY6N+jzKDD2WiXmj3zBAAUBksX2hi3KXR4mhzKc XOHQ==
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; bh=pkDaGs/24ux8xBcWrO31+gCiQqgHhC8c5jn4uzM85tQ=; b=LFXQh7lmY4AIBxP9NrWl56ibIsoQyYYY9qlUPyCW55YCuY9XnUzd9FbWWOnziCXxn+ vwtupIZErXI/E5wXDwrtEddgtjYu8wUK1bwqUxOI0d26VrEGHP7BwSHCjuLo9gXXW3r/ i/Y8jcSu8lyLAeCjnlSfXu7zKucyNQDdU8eWGcwKFdzvdqjJGL0OFXeU0iFsaG2ZGVHs fkKBjqRDXqaElLRSKADbcYC7JKbPbq6AaU++I64SCWOwCdmcEWMGk6dr9rDHPn96QuVh 81yeDRb6cIU/iK8ZWjpcWGIOBUQe0HMEMV0RuLkg3cfX9tX+tegk4i4wSwg8EltOLV5t vOzA==
X-Gm-Message-State: AKaTC01k2ckFQ5VryZk+d7KHwKSO9WpHOZdi8OWubpniMm52p9FuvhASa+f//JCjuZeSQrqKh4idW4DhHBrHHw==
X-Received: by 10.28.139.12 with SMTP id n12mr687658wmd.79.1479970133462; Wed, 23 Nov 2016 22:48:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.117.103 with HTTP; Wed, 23 Nov 2016 22:48:52 -0800 (PST)
In-Reply-To: 
References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> <58280139.2040505@lodderstedt.net>    
From: Samuel Erdtman 
Date: Thu, 24 Nov 2016 07:48:52 +0100
Message-ID: 
To: Brian Campbell 
Content-Type: multipart/alternative; boundary=001a11444d941567e30542066677
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2016 06:48:58 -0000

--001a11444d941567e30542066677
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 on providing guidance.


On Wed, Nov 16, 2016 at 12:08 AM, Brian Campbell  wrote:

> Yes, I believe you are correct. Client certificates are provided in the
> handshake (initial or renegotiated) at the request of the server. If the
> server asks and the client doesn't provide a cert, it's up to the server
> whether to continue or about the handshake.
>
> There seem to be a number of different ways of trying to deal with this
> (not strictly for this OAuth case but similar situations).
>
> The AS could always request client certs but allow connections to proceed
> regardless. Then check for certs for appropriate clients while processing
> token requests.  I guess there's a little overhead in the handshake with
> this for all the connections that won't present a cert. But not a ton. Th=
e
> main drawback is that some/many browsers have UI that will prompt users t=
o
> choose a cert even when they don't have any. And the user experience can =
be
> very bad or confusing as a result.
>
> The token endpoint could be on a different host or port which always
> requests client certs. Still allow connections to proceed regardless and
> check the client credentials at the OAuth layer. Pretty similar to the
> above but avoids the usability issues with end users because it's only at
> the token endpoint.
>
> Trying renegotiation after the application sees that it's a token request
> or that it's a token request from a client id that's configured for mutua=
l
> TLS is another approach. In my own limited experience with this kind of
> thing, however, this approach can be kind of flaky. And your point about
> the initial data not being trustworthy is legitimate. I'm not sure if it
> really matters in this case. I don't know. And signaling to resubmit is
> another issue all together.
>
> There are probably other approaches too but those are the things I've see=
n
> or can imagine. In all (or nearly all) the deployments of our stuff that =
I
> know about that deal with mutual TLS, some variation of the second option
> is used.
>
> All this seem like implementation/deployment details though and I'm
> hesitant to try and define how to do it in this doc. Maybe providing some
> guidance. I'm not exactly sure how to do that though.
>
>
>
> On Tue, Nov 15, 2016 at 10:14 AM, Samuel Erdtman 
> wrote:
>
>> Torstens questions triggers another question from me.
>>
>> If we have an AS that can handle both certificate client auth and client
>> secret, how does the AS know that it should ask for client certificate o=
n
>> the TLS layer.
>>
>> It was a while since I last read the TLS specification and it might have
>> changed but if i remember correctly client certificates are provided in
>> initial handshake or in re-negotiate and it is only provided on request =
by
>> the server.
>>
>> If this is still true the AS would need to first get the token request,
>> see that this is a client that authenticates with certificate and reques=
t a
>> TLS re-negotiate to get the certificate authentication and a re-submissi=
on
>> of the token request since we cannot trust the data first submitted.
>>
>> Are I missing something obvious, or is this something that needs to be
>> defined?
>>
>> //Samuel
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer  wrote:
>>
>>> Right =E2=80=94 this is a fine way to put it. RFC7591 defines a client =
model
>>> where RFC6749 didn=E2=80=99t. Ideally all that metadata would=E2=80=99v=
e been in the
>>> original spec, but it=E2=80=99s not. It doesn=E2=80=99t matter whether =
the client was
>>> registered dynamically or statically, it just matters that the AS knows
>>> what to expect from a given client.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Nov 14, 2016, at 6:21 AM, Brian Campbell 
>>> wrote:
>>>
>>> Yes, the intend is that the authentication method is determined by
>>> client policy regardless of whether the client was dynamically register=
ed
>>> or statically configured or whatever. I can make that point more explic=
it
>>> in future revisions of the draft.
>>>
>>> On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <
>>> torsten@lodderstedt.net> wrote:
>>>
>>>> I understand. My point is different: the text seems to assume everybod=
y
>>>> is using client registration, but that's not the case. I would like to
>>>> point out it makes sense to explicitely state the assumption that it i=
s
>>>> determined by client policy (indepedent of the way this policy is
>>>> established).
>>>>
>>>>
>>>> Am 13.11.2016 um 14:24 schrieb Justin Richer:
>>>>
>>>> As part of the client=E2=80=99s registered data model. At least, based=
 on how
>>>> our own implementation works (where we support client_secret_basic,
>>>> private_key_jwt, etc), that=E2=80=99s where we=E2=80=99d check to see =
if the client was
>>>> supposed to be using TLS auth or not.
>>>>
>>>> We don=E2=80=99t let clients switch away from their registered auth me=
chanism.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <
>>>> torsten@lodderstedt.net> wrote:
>>>>
>>>> Justin,
>>>>
>>>> Am 13.11.2016 um 13:39 schrieb Justin Richer:
>>>>
>>>> Torsten, I believe this is intended to be triggered by the
>>>> tls_client_auth value specified in =C2=A73.
>>>>
>>>>
>>>> in the token request?
>>>>
>>>>
>>>> Nit on that section, the field name for the client metadata in RFC7591
>>>> is token_endpoint_auth_method, the _supported version is from the
>>>> corresponding discovery document.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> Torsten.
>>>>
>>>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <
>>>> torsten@lodderstedt.net> wrote:
>>>>
>>>> Hi John and Brian,
>>>>
>>>> thanks for writting this draft.
>>>>
>>>> One question: how does the AS determine the authentication method is
>>>> TLS authentication? I think you assume this is defined by the
>>>> client-specific policy, independent of whether the client is registere=
d
>>>> automatically or manually. Would you mind to explicitely state this in=
 the
>>>> draft?
>>>>
>>>> best regards,
>>>> Torsten.
>>>>
>>>> Am 11.10.2016 um 05:59 schrieb John Bradley:
>>>>
>>>> At the request of the OpenID Foundation Financial Services API Working
>>>> group, Brian Campbell and I have documented
>>>> mutual TLS client authentication.   This is something that lots of
>>>> people do in practice though we have never had a spec for it.
>>>>
>>>> The Banks want to use it for some server to server API use cases being
>>>> driven by new open banking regulation.
>>>>
>>>> The largest thing in the draft is the IANA registration of
>>>> =E2=80=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method=
 for use in
>>>> Registration and discovery.
>>>>
>>>> The trust model is intentionally left open so that you could use a
>>>> =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct =
lookup of the subject
>>>> public key against a reregistered value,  or something in between.
>>>>
>>>> I hope that this is non controversial and the WG can adopt it quickly.
>>>>
>>>> Regards
>>>> John B.
>>>>
>>>>
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>> *From: * internet-drafts@ietf.org
>>>> *Subject: **New Version Notification for
>>>> draft-campbell-oauth-tls-client-auth-00.txt*
>>>> *Date: *October 10, 2016 at 5:44:39 PM GMT-3
>>>> *To: *"Brian Campbell" < 
>>>> brian.d.campbell@gmail.com>, "John Bradley" < 
>>>> ve7jtb@ve7jtb.com>
>>>>
>>>>
>>>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
>>>> has been successfully submitted by John Bradley and posted to the
>>>> IETF repository.
>>>>
>>>> Name: draft-campbell-oauth-tls-client-auth
>>>> Revision: 00
>>>> Title: Mutual X.509 Transport Layer Security (TLS) Authentication for
>>>> OAuth Clients
>>>> Document date: 2016-10-10
>>>> Group: Individual Submission
>>>> Pages: 5
>>>> URL:
>>>> 
>>>> https://www.ietf.org/internet-drafts/draft-campbe
>>>> ll-oauth-tls-client-auth-00.txt
>>>> Status:
>>>> 
>>>> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
>>>> Htmlized:
>>>> 
>>>> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
>>>>
>>>>
>>>> Abstract:
>>>>   This document describes X.509 certificates as OAuth client
>>>>   credentials using Transport Layer Security (TLS) mutual
>>>>   authentication as a mechanism for client authentication to the
>>>>   authorization server's token endpoint.
>>>>
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/=
oauth
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>

--001a11444d941567e30542066677
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1 on providing guidance.


On Wed, Nov 16, 2016 at 1=
2:08 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Yes, I bel=
ieve you are correct. Client certificates are provided in the handshake (in=
itial or renegotiated) at the request of the server. If the server asks and=
 the client doesn't provide a cert, it's up to the server whether t=
o continue or about the handshake. 

There seem to be a nu=
mber of different ways of trying to deal with this (not strictly for this O=
Auth case but similar situations).

The AS could always re=
quest client certs but allow connections to proceed regardless. Then check =
for certs for appropriate clients while processing token requests.=C2=A0 I =
guess there's a little overhead in the handshake with this for all the =
connections that won't present a cert. But not a ton. The main drawback=
 is that some/many browsers have UI that will prompt users to choose a cert=
 even when they don't have any. And the user experience can be very bad=
 or confusing as a result.

The token endpoint =
could be on a different host or port which always requests client certs. St=
ill allow connections to proceed regardless and check the client credential=
s at the OAuth layer. Pretty similar to the above but avoids the usability =
issues with end users because it's only at the token endpoint. 

=

Trying renegotiation after the application sees that it's a =
token request or that it's a token request from a client id that's =
configured for mutual TLS is another approach. In my own limited experience=
 with this kind of thing, however, this approach can be kind of flaky. And =
your point about the initial data not being trustworthy is legitimate. I=
9;m not sure if it really matters in this case. I don't know. And signa=
ling to resubmit is another issue all together. 

There ar=
e probably other approaches too but those are the things I've seen or c=
an imagine. In all (or nearly all) the deployments of our stuff that I know=
 about that deal with mutual TLS, some variation of the second option is us=
ed. 

All this seem like implementation/deploym=
ent details though and I'm hesitant to try and define how to do it in t=
his doc. Maybe providing some guidance. I'm not exactly sure how to do =
that though.=C2=A0 



On Tue, Nov 15, 2016 a=
t 10:14 AM, Samuel Erdtman <samuel@erdtman.se> wrote:
<=
div>Torstens questions triggers another question from me. 

If we hav=
e an AS that can handle both certificate client auth and client secret, how=
 does the AS know that it should ask for client certificate on the TLS laye=
r.

It was a while since I last read the TLS specification and it mig=
ht have changed but if i remember correctly client certificates are provide=
d in initial handshake or in re-negotiate and it is only provided on reques=
t by the server.

If this is still true the AS would need to fi=
rst get the token request, see that this is a client that authenticates wit=
h certificate and request a TLS re-negotiate to get the certificate authent=
ication and a re-submission of the token request since we cannot trust the =
data first submitted.

Are I missing something obvious, or is t=
his something that needs to be defined?

=

//Samuel

<=
div>




=C2=A0

=
On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer <jricher@mit.edu> wrote:
Right =
=E2=80=94 this is a fine way to put it. RFC7591 defines a client model wher=
e RFC6749 didn=E2=80=99t. Ideally all that metadata would=E2=80=99ve been i=
n the original spec, but it=E2=80=99s not. It doesn=E2=80=99t matter whethe=
r the client was registered dynamically or statically, it just matters that=
 the AS knows what to expect from a given client.

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

On Nov 1=
4, 2016, at 6:21 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Yes, the intend is that the authentication method is determined =
by client policy regardless of whether the client was dynamically registere=
d or statically configured or whatever. I can make that point more explicit=
 in future revisions of the draft. 

On Sat, Nov 12, 2016 at=
 10:59 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

 =20
   =20
 =20
  

    I understand. My point is different: the text seems to assume
    everybody is using client registration, but that's not the case. I
    would like to point out it makes sense to explicitely state the
    assumption that it is determined by client policy (indepedent of the
    way this policy is established).


    

    
Am 13.11.2016 um 14:24 schrieb Justin
      Richer:

    

    

     =20
      As part of the client=E2=80=99s registered data model. At least, base=
d on
      how our own implementation works (where we support
      client_secret_basic, private_key_jwt, etc), that=E2=80=99s where we=
=E2=80=99d
      check to see if the client was supposed to be using TLS auth or
      not.
      


      

      
We don=E2=80=99t let clients switch away from their
        registered auth mechanism.

      


      

      
=C2=A0=E2=80=94 Justin

      


        

          

            
On Nov 13, 2016, at 2:21 PM, Torsten
              Lodderstedt <torsten@lodderstedt.net>
              wrote:

            

            

             =20
              
 Justin,

                

                
Am 13.11.2016 um 13:39
                  schrieb Justin Richer:

                

                
 Torsten, I believe this is
                  intended to be triggered by the tls_client_auth value
                  specified in =C2=A73. 

                

                

                in the token request?

                

                

                  


                  

                  
Nit on that section, the field name for
                    the client metadata in RFC7591 is
                    token_endpoint_auth_method, the _supported version
                    is from the corresponding discovery document.

                  


                  

                  
=C2=A0=E2=80=94 Justin

                  


                  

                

                Torsten.

                

                  

                    

                      

                        
On Nov 13, 2016, at 12:31 PM,
                          Torsten Lodderstedt <torsten@lodderstedt.net>
                          wrote:

                        

                        

                          

                            Hi John and Brian,

                            

                            thanks for writting this draft.

                            

                            One question: how does the AS determine the
                            authentication method is TLS authentication?
                            I think you assume this is defined by the
                            client-specific policy, independent of
                            whether the client is registered
                            automatically or manually. Would you mind to
                            explicitely state this in the draft?

                            

                            best regards,

                            Torsten.

                            

                            
Am 11.10.2016
                              um 05:59 schrieb John Bradley:

                            

                            
 At the request of
                              the OpenID Foundation Financial Services
                              API Working group, Brian Campbell and I
                              have documented=C2=A0
                              
mutual TLS client
                                authentication. =C2=A0 This is something th=
at
                                lots of people do in practice though we
                                have never had a spec for it.

                              


                              

                              
The Banks want to use it for
                                some server to server API use cases
                                being driven by new open banking
                                regulation.

                              


                              

                              
The largest thing in the
                                draft is the IANA registration of
                                =E2=80=9Ctls_client_auth=E2=80=9D Token End=
point
                                authentication method for use in
                                Registration and discovery.

                              


                              

                              
The trust model is
                                intentionally left open so that you
                                could use a =E2=80=9Ccommon name=E2=80=9D a=
nd a
                                restricted list of CA or a direct lookup
                                of the subject public key against a
                                reregistered value, =C2=A0or something in
                                between.

                              


                              

                              
I hope that this is non
                                controversial and the WG can adopt it
                                quickly.

                              


                              

                              
Regards

                              
John B.

                              


                              

                              


                              

                              


                                


                                  

                                    
Begin forwarded
                                      message:

                                    

                                    
                                    
Subj=
ect: New Version
                                          Notification for
                                          draft-campbell-oauth-tls-client-auth-00.txt

                                      

                                    
Date=
: October 10, 2016 at
                                        5:44:39 PM GMT-3

                                      

                                    
To: =
"Brian Campbell" <brian.d.campbell@gmail.com&g=
t;,


                                        "John Bradley" <ve7jtb@ve7jtb.com>

                                      

                                    

                                    

                                      


                                        A new version of I-D,
                                        draft-campbell-oauth-tls-clien=
t-auth-00.txt

                                        has been successfully submitted
                                        by John Bradley and posted to
                                        the

                                        IETF repository.

                                        

                                        Name:		draft-campbell-oauth-tls-=
client-auth

                                        Revision:	00

                                        Title:		Mutual


                                        X.509 Transport Layer Security
                                        (TLS) Authentication for OAuth
                                        Clients

                                        Document date:	2016-10-10

                                        Group:		Individual


                                        Submission

                                        Pages:		5

                                        URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-d=
rafts/draft-campbell-oauth-tls-client-auth-00.txt

                                        Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-cli=
ent-auth/

                                        Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0https://too=
ls.ietf.org/html/draft-campbell-oauth-tls-client-auth-00

                                        

                                        

                                        Abstract:

                                        =C2=A0=C2=A0This document describes=
 X.509
                                        certificates as OAuth client

                                        =C2=A0=C2=A0credentials using Trans=
port
                                        Layer Security (TLS) mutual

                                        =C2=A0=C2=A0authentication as a mec=
hanism
                                        for client authentication to the
                                        =C2=A0=C2=A0authorization server=
9;s token
                                        endpoint.

                                        

                                        

                                        

                                        

                                        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.

                                        

                                        The IETF Secretariat

                                        

                                      

                                    

                                  

                                

                                

                              

                              

                              

                              

                              
___________________________________=
____________
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










--001a11444d941567e30542066677--


From nobody Thu Nov 24 00:42:23 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE281295C4 for ; Thu, 24 Nov 2016 00:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.877
X-Spam-Level: 
X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0T-n-qT6hhg for ; Thu, 24 Nov 2016 00:42:19 -0800 (PST)
Received: from mail-wj0-x230.google.com (mail-wj0-x230.google.com [IPv6:2a00:1450:400c:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359821295ED for ; Thu, 24 Nov 2016 00:42:18 -0800 (PST)
Received: by mail-wj0-x230.google.com with SMTP id v7so27868680wjy.2 for ; Thu, 24 Nov 2016 00:42:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to; bh=zkMRe4qSFj7u82+lXoPYL1NgGDmD6nQ38XMsyT29nO4=; b=wBzMqpkNlN6448lor/50vVGm9X9JH3lz5yNPu0STYlOGdaHr9tDfk1r9jvajmIQQQP Y1MNFpslXc9/65sIBO/bJ5Sxj3Rw3ednpjyx5AXwec6wdIT9VmYbH7JQf0YtTD7Y0BKW hM5ucI9z7GzSGfqsE/3yl/N+g+gj4ffVo4XGvB0q6soXWIQhvfYeUVJJgLqYs4j/sF1A 8y78a12tzs48dQF+gUcS4GOF/I/ocbSq8Tf/GI5DYWdgPanTA77IVHdHK5qsJiBimzzD hmbVdLqwNRafhB2uhLsgBut4b5mitMwls5d1bE1BE0baZy8C0I6T/FlX9de7o/smwts1 HvQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to; bh=zkMRe4qSFj7u82+lXoPYL1NgGDmD6nQ38XMsyT29nO4=; b=kFRGIjFjTRvKrewmidIleIBD1ailXjig08RTYgXI7B7BHUaetepcfcLSl1R9mzs/N5 Fqsm2MvbXPtQB4JENp0gWYLlxKv5DpRXz3R14hzh5j00+4K4r0GqeQJZDk59DzUiGTVv GdQJzgnxWyanci96h4BM4MFXi9RHDUjWhhseA+QnczrFVaZ/SeH+b+1ZkUG8EY4etuIg unJBkNN1dNVWjF1sPKNfu5Je5ikxB3itKNS3n/x4Ju+ElQV2MFjxNBu6WXFEEXEWasqn X+o9ZU2cSM80jAZ7geCoPu2CTtmteWydK1mnFRAIXPI/KDe8fFIvQqGRnxZINEWC/AHE 76RA==
X-Gm-Message-State: AKaTC02nVZBZAAl3a99g1BZxt9O9QVafFIMwHsUGpApGCupf2+EYjJy1PlSgps2T6nhseEGh
X-Received: by 10.194.78.195 with SMTP id d3mr1138897wjx.96.1479976936733; Thu, 24 Nov 2016 00:42:16 -0800 (PST)
Received: from [10.159.1.15] (smb-adpcdg2-02.hotspot.hub-one.net. [213.174.99.136]) by smtp.gmail.com with ESMTPSA id i132sm6980227wmf.14.2016.11.24.00.42.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2016 00:42:15 -0800 (PST)
From: Jim Manico 
Content-Type: multipart/alternative; boundary=Apple-Mail-DDF87DAC-A5CE-40D3-9B6E-4770063B407A
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Thu, 24 Nov 2016 09:42:15 +0100
Message-Id: 
References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> <58280139.2040505@lodderstedt.net>     
In-Reply-To: 
X-Mailer: iPhone Mail (14B150)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2016 08:42:22 -0000

--Apple-Mail-DDF87DAC-A5CE-40D3-9B6E-4770063B407A
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Dude. You're freaking awesome. Thanks for this insight.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 24, 2016, at 7:48 AM, Samuel Erdtman  wrote:
>=20
> +1 on providing guidance.
>=20
>=20
>> On Wed, Nov 16, 2016 at 12:08 AM, Brian Campbell  wrote:
>> Yes, I believe you are correct. Client certificates are provided in the h=
andshake (initial or renegotiated) at the request of the server. If the serv=
er asks and the client doesn't provide a cert, it's up to the server whether=
 to continue or about the handshake.=20
>>=20
>> There seem to be a number of different ways of trying to deal with this (=
not strictly for this OAuth case but similar situations).
>>=20
>> The AS could always request client certs but allow connections to proceed=
 regardless. Then check for certs for appropriate clients while processing t=
oken requests.  I guess there's a little overhead in the handshake with this=
 for all the connections that won't present a cert. But not a ton. The main d=
rawback is that some/many browsers have UI that will prompt users to choose a=
 cert even when they don't have any. And the user experience can be very bad=
 or confusing as a result.
>>=20
>> The token endpoint could be on a different host or port which always requ=
ests client certs. Still allow connections to proceed regardless and check t=
he client credentials at the OAuth layer. Pretty similar to the above but av=
oids the usability issues with end users because it's only at the token endp=
oint.=20
>>=20
>> Trying renegotiation after the application sees that it's a token request=
 or that it's a token request from a client id that's configured for mutual T=
LS is another approach. In my own limited experience with this kind of thing=
, however, this approach can be kind of flaky. And your point about the init=
ial data not being trustworthy is legitimate. I'm not sure if it really matt=
ers in this case. I don't know. And signaling to resubmit is another issue a=
ll together.=20
>>=20
>> There are probably other approaches too but those are the things I've see=
n or can imagine. In all (or nearly all) the deployments of our stuff that I=
 know about that deal with mutual TLS, some variation of the second option i=
s used.=20
>>=20
>> All this seem like implementation/deployment details though and I'm hesit=
ant to try and define how to do it in this doc. Maybe providing some guidanc=
e. I'm not exactly sure how to do that though. =20
>>=20
>>=20
>>=20
>>> On Tue, Nov 15, 2016 at 10:14 AM, Samuel Erdtman  wro=
te:
>>> Torstens questions triggers another question from me.=20
>>>=20
>>> If we have an AS that can handle both certificate client auth and client=
 secret, how does the AS know that it should ask for client certificate on t=
he TLS layer.
>>>=20
>>> It was a while since I last read the TLS specification and it might have=
 changed but if i remember correctly client certificates are provided in ini=
tial handshake or in re-negotiate and it is only provided on request by the s=
erver.
>>>=20
>>> If this is still true the AS would need to first get the token request, s=
ee that this is a client that authenticates with certificate and request a T=
LS re-negotiate to get the certificate authentication and a re-submission of=
 the token request since we cannot trust the data first submitted.
>>>=20
>>> Are I missing something obvious, or is this something that needs to be d=
efined?
>>>=20
>>> //Samuel
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> =20
>>>=20
>>>> On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer  wrote:=

>>>> Right =E2=80=94 this is a fine way to put it. RFC7591 defines a client m=
odel where RFC6749 didn=E2=80=99t. Ideally all that metadata would=E2=80=99v=
e been in the original spec, but it=E2=80=99s not. It doesn=E2=80=99t matter=
 whether the client was registered dynamically or statically, it just matter=
s that the AS knows what to expect from a given client.
>>>>=20
>>>>  =E2=80=94 Justin
>>>>=20
>>>>> On Nov 14, 2016, at 6:21 AM, Brian Campbell  wrote:
>>>>>=20
>>>>> Yes, the intend is that the authentication method is determined by cli=
ent policy regardless of whether the client was dynamically registered or st=
atically configured or whatever. I can make that point more explicit in futu=
re revisions of the draft.=20
>>>>>=20
>>>>>> On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt  wrote:
>>>>>> I understand. My point is different: the text seems to assume everybo=
dy is using client registration, but that's not the case. I would like to po=
int out it makes sense to explicitely state the assumption that it is determ=
ined by client policy (indepedent of the way this policy is established).
>>>>>>=20
>>>>>>=20
>>>>>>> Am 13.11.2016 um 14:24 schrieb Justin Richer:
>>>>>>> As part of the client=E2=80=99s registered data model. At least, bas=
ed on how our own implementation works (where we support client_secret_basic=
, private_key_jwt, etc), that=E2=80=99s where we=E2=80=99d check to see if t=
he client was supposed to be using TLS auth or not.
>>>>>>>=20
>>>>>>> We don=E2=80=99t let clients switch away from their registered auth m=
echanism.
>>>>>>>=20
>>>>>>>  =E2=80=94 Justin
>>>>>>>=20
>>>>>>>> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt  wrote:
>>>>>>>>=20
>>>>>>>> Justin,
>>>>>>>>=20
>>>>>>>>> Am 13.11.2016 um 13:39 schrieb Justin Richer:
>>>>>>>>> Torsten, I believe this is intended to be triggered by the tls_cli=
ent_auth value specified in =C2=A73.=20
>>>>>>>>=20
>>>>>>>> in the token request?
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Nit on that section, the field name for the client metadata in RFC=
7591 is token_endpoint_auth_method, the _supported version is from the corre=
sponding discovery document.
>>>>>>>>>=20
>>>>>>>>>  =E2=80=94 Justin
>>>>>>>>>=20
>>>>>>>> Torsten.
>>>>>>>>>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt  wrote:
>>>>>>>>>>=20
>>>>>>>>>> Hi John and Brian,
>>>>>>>>>>=20
>>>>>>>>>> thanks for writting this draft.
>>>>>>>>>>=20
>>>>>>>>>> One question: how does the AS determine the authentication method=
 is TLS authentication? I think you assume this is defined by the client-spe=
cific policy, independent of whether the client is registered automatically o=
r manually. Would you mind to explicitely state this in the draft?
>>>>>>>>>>=20
>>>>>>>>>> best regards,
>>>>>>>>>> Torsten.
>>>>>>>>>>=20
>>>>>>>>>>> Am 11.10.2016 um 05:59 schrieb John Bradley:
>>>>>>>>>>> At the request of the OpenID Foundation Financial Services API W=
orking group, Brian Campbell and I have documented=20
>>>>>>>>>>> mutual TLS client authentication.   This is something that lots o=
f people do in practice though we have never had a spec for it.
>>>>>>>>>>>=20
>>>>>>>>>>> The Banks want to use it for some server to server API use cases=
 being driven by new open banking regulation.
>>>>>>>>>>>=20
>>>>>>>>>>> The largest thing in the draft is the IANA registration of =E2=80=
=9Ctls_client_auth=E2=80=9D Token Endpoint authentication method for use in R=
egistration and discovery.
>>>>>>>>>>>=20
>>>>>>>>>>> The trust model is intentionally left open so that you could use=
 a =E2=80=9Ccommon name=E2=80=9D and a restricted list of CA or a direct loo=
kup of the subject public key against a reregistered value,  or something in=
 between.
>>>>>>>>>>>=20
>>>>>>>>>>> I hope that this is non controversial and the WG can adopt it qu=
ickly.
>>>>>>>>>>>=20
>>>>>>>>>>> Regards
>>>>>>>>>>> John B.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>=20
>>>>>>>>>>>> From: internet-drafts@ietf.org
>>>>>>>>>>>> Subject: New Version Notification for draft-campbell-oauth-tls-=
client-auth-00.txt
>>>>>>>>>>>> Date: October 10, 2016 at 5:44:39 PM GMT-3
>>>>>>>>>>>> To: "Brian Campbell" , "John Bradle=
y" 
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.t=
xt
>>>>>>>>>>>> has been successfully submitted by John Bradley and posted to t=
he
>>>>>>>>>>>> IETF repository.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Name:		draft-campbell-oauth-tls-client-auth
>>>>>>>>>>>> Revision:	00
>>>>>>>>>>>> Title:		Mutual X.509 Transport Layer Security (TLS)=
 Authentication for OAuth Clients
>>>>>>>>>>>> Document date:	2016-10-10
>>>>>>>>>>>> Group:		Individual Submission
>>>>>>>>>>>> Pages:		5
>>>>>>>>>>>> URL:            https://www.ietf.org/internet-drafts/draft-camp=
bell-oauth-tls-client-auth-00.txt
>>>>>>>>>>>> Status:         https://datatracker.ietf.org/doc/draft-campbell=
-oauth-tls-client-auth/
>>>>>>>>>>>> Htmlized:       https://tools.ietf.org/html/draft-campbell-oaut=
h-tls-client-auth-00
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Abstract:
>>>>>>>>>>>>   This document describes X.509 certificates as OAuth client
>>>>>>>>>>>>   credentials using Transport Layer Security (TLS) mutual
>>>>>>>>>>>>   authentication as a mechanism for client authentication to th=
e
>>>>>>>>>>>>   authorization server's token endpoint.
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Please note that it may take a couple of minutes from the time o=
f submission
>>>>>>>>>>>> until the htmlized version and diff are available at tools.ietf=
.org.
>>>>>>>>>>>>=20
>>>>>>>>>>>> The IETF Secretariat
>>>>>>>>>>>>=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
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-DDF87DAC-A5CE-40D3-9B6E-4770063B407A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Dude. You're freaking awesome. Thanks f=
or this insight.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
<=
br>On Nov 24, 2016, at 7:48 AM, Samuel Erdtman <samuel@erdtman.se> wrote:

+1 on providing guidance.


On Wed, Nov 16,=
 2016 at 12:08 AM, Brian Campbell <bcampbell@pingidentity.com&g=
t; wrote:
Yes, I=
 believe you are correct. Client certificates are provided in the handshake (=
initial or renegotiated) at the request of the server. If the server asks an=
d the client doesn't provide a cert, it's up to the server whether to contin=
ue or about the handshake. 

There seem to be a number of d=
ifferent ways of trying to deal with this (not strictly for this OAuth case b=
ut similar situations).

The AS could always request client=
 certs but allow connections to proceed regardless. Then check for certs for=
 appropriate clients while processing token requests.  I guess there's a=
 little overhead in the handshake with this for all the connections that won=
't present a cert. But not a ton. The main drawback is that some/many browse=
rs have UI that will prompt users to choose a cert even when they don't have=
 any. And the user experience can be very bad or confusing as a result.
<=
/div>

The token endpoint could be on a different host or p=
ort which always requests client certs. Still allow connections to proceed r=
egardless and check the client credentials at the OAuth layer. Pretty simila=
r to the above but avoids the usability issues with end users because it's o=
nly at the token endpoint. 

Trying renegotiation after the=
 application sees that it's a token request or that it's a token request fro=
m a client id that's configured for mutual TLS is another approach. In my ow=
n limited experience with this kind of thing, however, this approach can be k=
ind of flaky. And your point about the initial data not being trustworthy is=
 legitimate. I'm not sure if it really matters in this case. I don't know. A=
nd signaling to resubmit is another issue all together. 

T=
here are probably other approaches too but those are the things I've seen or=
 can imagine. In all (or nearly all) the deployments of our stuff that I kno=
w about that deal with mutual TLS, some variation of the second option is us=
ed. 

All this seem like implementation/deployme=
nt details though and I'm hesitant to try and define how to do it in this do=
c. Maybe providing some guidance. I'm not exactly sure how to do that though=
.  



On Tue, Nov 15, 2016 at 10:14 AM, S=
amuel Erdtman <samuel@erdtman.se> wrote:
Torstens questi=
ons triggers another question from me. 

If we have an AS that can han=
dle both certificate client auth and client secret, how does the AS know tha=
t it should ask for client certificate on the TLS layer.

It was a whi=
le since I last read the TLS specification and it might have changed but if i=
 remember correctly client certificates are provided in initial handshake or=
 in re-negotiate and it is only provided on request by the server.

If this is still true the AS would need to first get the token request, s=
ee that this is a client that authenticates with certificate and request a T=
LS re-negotiate to get the certificate authentication and a re-submission of=
 the token request since we cannot trust the data first submitted.

Are I missing something obvious, or is this something that needs to be d=
efined?

//Samuel





 =


On Mon, Nov 14, 2016 at 1:26 AM, Justin R=
icher <jricher@mit.edu> wrote:
Right =E2=80=94 this is a fine way to put it. RFC759=
1 defines a client model where RFC6749 didn=E2=80=99t. Ideally all that meta=
data would=E2=80=99ve been in the original spec, but it=E2=80=99s not. It do=
esn=E2=80=99t matter whether the client was registered dynamically or static=
ally, it just matters that the AS knows what to expect from a given client.<=
div>
 =E2=80=94 Justin

On Nov 14, 2016, at 6:21 AM, Brian Campbell <bcampbell@pingidentity.c=
om> wrote:

Yes, the intend is that the authentication me=
thod is determined by client policy regardless of whether the client was dyn=
amically registered or statically configured or whatever. I can make that po=
int more explicit in future revisions of the draft. 

On Sat, N=
ov 12, 2016 at 10:59 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

 =20
   =20
 =20
  

    I understand. My point is different: the text seems to assume
    everybody is using client registration, but that's not the case. I
    would like to point out it makes sense to explicitely state the
    assumption that it is determined by client policy (indepedent of the
    way this policy is established).


    

    
Am 13.11.2016 um 14:24 schrieb Justin
      Richer:

    

    

     =20
      As part of the client=E2=80=99s registered data model. At least, based=
 on
      how our own implementation works (where we support
      client_secret_basic, private_key_jwt, etc), that=E2=80=99s where we=E2=
=80=99d
      check to see if the client was supposed to be using TLS auth or
      not.
      


      

      
We don=E2=80=99t let clients switch away from their
        registered auth mechanism.

      


      

      
 =E2=80=94 Justin

      


        

          

            
On Nov 13, 2016, at 2:21 PM, Torsten
              Lodderstedt <torsten@lodderstedt.net>
              wrote:

            

            

             =20
              
 Justin,

                

                
Am 13.11.2016 um 13:39
                  schrieb Justin Richer:

                

                
 Torsten, I believe this is
                  intended to be triggered by the tls_client_auth value
                  specified in =C2=A73. 

                

                

                in the token request?

                

                

                  


                  

                  
Nit on that section, the field name for
                    the client metadata in RFC7591 is
                    token_endpoint_auth_method, the _supported version
                    is from the corresponding discovery document.

                  


                  

                  
 =E2=80=94 Justin

                  


                  

                

                Torsten.

                

                  

                    

                      

                        
                        

                        

                          

                            Hi John and Brian,

                            

                            thanks for writting this draft.

                            

                            One question: how does the AS determine the
                            authentication method is TLS authentication?
                            I think you assume this is defined by the
                            client-specific policy, independent of
                            whether the client is registered
                            automatically or manually. Would you mind to
                            explicitely state this in the draft?

                            

                            best regards,

                            Torsten.

                            

                            
Am 11.10.2016
                              um 05:59 schrieb John Bradley:

                            

                            
 At the request of
                              the OpenID Foundation Financial Services
                              API Working group, Brian Campbell and I
                              have documented 
                              
mutual TLS client
                                authentication.   This is something tha=
t
                                lots of people do in practice though we
                                have never had a spec for it.

                              


                              

                              
The Banks want to use it for
                                some server to server API use cases
                                being driven by new open banking
                                regulation.

                              


                              

                              
The largest thing in the
                                draft is the IANA registration of
                                =E2=80=9Ctls_client_auth=E2=80=9D Token Endp=
oint
                                authentication method for use in
                                Registration and discovery.

                              


                              

                              
The trust model is
                                intentionally left open so that you
                                could use a =E2=80=9Ccommon name=E2=80=9D an=
d a
                                restricted list of CA or a direct lookup
                                of the subject public key against a
                                reregistered value,  or something in
                                between.

                              


                              

                              
I hope that this is non
                                controversial and the WG can adopt it
                                quickly.

                              


                              

                              
Regards

                              
John B.

                              


                              

                              


                              

                              


                                


                                  

                                    
Begin forwarded
                                      message:

                                    

                                    
                                    
Subje=
ct: New Version
                                          Notification for
                                          draft-campbell-oauth-tls-client-auth-00.txt

                                      

                                    
Date:=
 October 10, 2016 at
                                        5:44:39 PM GMT-3

                                      

                                    
To: <=
/b>"Brian Campbell" <brian.d.campbell@gmail.com>,


                                        "John Bradley" <ve7jtb@ve7jtb.com>

                                      

                                    

                                    

                                      


                                        A new version of I-D,
                                        draft-campbell-oauth-tls-client=
-auth-00.txt

                                        has been successfully submitted
                                        by John Bradley and posted to
                                        the

                                        IETF repository.

                                        

                                        Name:=
		draft-campbell-oauth-tls-cli=
ent-auth

                                        Revision:	00

                                        Title:=
		Mutual


                                        X.509 Transport Layer Security
                                        (TLS) Authentication for OAuth
                                        Clients

                                        Document date:	2016-10-10

                                        Group:=
		Individual


                                        Submission

                                        Pages:=
		5

                                        URL:      &=
nbsp;     https://www.ietf.org/internet-drafts/d=
raft-campbell-oauth-tls-client-auth-00.txt

                                        Status:     &nbs=
p;   ht=
tps://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-aut=
h/

                                        Htmlized:     &n=
bsp; https://tools.ietf=
.org/html/draft-campbell-oauth-tls-client-auth-00

                                        

                                        

                                        Abstract:

                                          This document describes X=
.509
                                        certificates as OAuth client

                                          credentials using Transp=
ort
                                        Layer Security (TLS) mutual

                                          authentication as a mech=
anism
                                        for client authentication to the
=

                                          authorization server's t=
oken
                                        endpoint.

                                        

                                        

                                        

                                        

                                        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.

                                        

                                        The IETF Secretariat

                                        

                                      

                                    

                                  

                                

                                

                              

                              

                              

                              

                              
____________________________________=
___________
OAuth mailing list
OAuth@ietf.org
ht=
tps://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/mai=
lman/listinfo/oauth
=

--Apple-Mail-DDF87DAC-A5CE-40D3-9B6E-4770063B407A--


From nobody Mon Nov 28 09:31:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5D129F67 for ; Mon, 28 Nov 2016 09:31:12 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcV99rjSqS87 for ; Mon, 28 Nov 2016 09:31:10 -0800 (PST)
Received: from mail-wj0-x231.google.com (mail-wj0-x231.google.com [IPv6:2a00:1450:400c:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EF5129F69 for ; Mon, 28 Nov 2016 09:21:47 -0800 (PST)
Received: by mail-wj0-x231.google.com with SMTP id qp4so122402668wjc.3 for ; Mon, 28 Nov 2016 09:21:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=RY9RzNlgbPeB1NvgcO1pdD2uNObs5nXjV12WmryPQHM=; b=JMlqSbUeb4JfkkrDNAXQ0lSkRSbYMki9J11Rde4Mw0Uv/yd2DLV69TAkCcNV4oblJZ 4qzCNTvFtUeBCaj0iu3pDRZYaVVtO+FUH29eXFBwTgTco2TO77665zGBgxlo/42mY2fF 82sU1fEcMZahne+3ZVLuO2bed9BQwJo2qJBj16wgJ/BpWwzO1yvJPHo7j4KKVj3uOUtp L0mCsVHZgIc4NhFrVS7ptwtiE1z1RFs+MYJMq3NB1/AN+xvnAd8ZuvO91ELWa1J9J5Ue KENNoB2bBHykw0MycDfFWpg0Z3EaQntdu07pGs7rXqSCgjUxt34Kw1qmAoLy5EysOjf7 q9Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=RY9RzNlgbPeB1NvgcO1pdD2uNObs5nXjV12WmryPQHM=; b=Geg7J1XhBPlaD3/3xOoCFP6InWygJBYk31VlkgVTSzJTAvl1FSjyyz631J1R2XoCT5 oxLUjBKt8mHDrbAYFvuuNknIm6EhGDhrfLMpjL353GGQsPNPVSHaSdJizBuWpvItZpSn +RS6Y4j0hSdJ/hz52pZ2FystGX7VyK7DRBODBH9MdUw5ULnFRbJvMCITuAUkvoKp8u9h Zk0nNEF/kOCyFmmWu7decwXDzXATXo4yyov/Uw95KDT2G6cwV1+ds+nMVRedMR563DcJ vDuqBELxyJWwNbQlPxGMHl5qQZjto5rgfXdXeqMwMXbrqUPOiEi00VdCoHtKLdBXlXVJ 8N5g==
X-Gm-Message-State: AKaTC01gaCDvL5Ofvb/yTc6CIXI2fRWxa9CuJUoWAG9jo4ruGCwFNWpR841Q3Eo7ioWnhw==
X-Received: by 10.194.20.34 with SMTP id k2mr13642647wje.9.1480353705685; Mon, 28 Nov 2016 09:21:45 -0800 (PST)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id ab10sm63367223wjc.45.2016.11.28.09.21.44 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 09:21:45 -0800 (PST)
To: "oauth@ietf.org" 
From: Sergey Beryozkin 
Message-ID: 
Date: Mon, 28 Nov 2016 17:21:44 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2016 17:31:13 -0000

Hi All

Our AS allows for the manual client registration with the UI offering an 
option to assign the audience/resource URIs to a given Client 
registration with all the associated future access tokens inheriting them.

The client will not have to follow the resource indicator registration 
as recommended at [1] - the administrator who registers the clients sets 
the audiences.

We'd like to achieve the same with the dynamic client registration but 
my colleague noted the client metadata in the dynamic registration 
request has no 'audience' property.

We will consider supporting either an 'audience' or 'resource' property 
- does it sound reasonable ?

By the way, as far as [1] is concerned, should a 'resource' property 
support an array of audiences ? (To support a case a client needed to 
talk to several RSs to complete a given action)

Thanks, Sergey

[1] https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02


From nobody Mon Nov 28 10:47:15 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F831293F2 for ; Mon, 28 Nov 2016 10:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.698
X-Spam-Level: 
X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWYRAPU9nm61 for ; Mon, 28 Nov 2016 10:47:07 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C425212947C for ; Mon, 28 Nov 2016 10:47:07 -0800 (PST)
X-AuditID: 1209190f-6b7ff70000001116-1f-583c7ba972d8
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id A6.1C.04374.9AB7C385; Mon, 28 Nov 2016 13:47:05 -0500 (EST)
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 uASIl5Et005693; Mon, 28 Nov 2016 13:47:05 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uASIl3ia010334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Nov 2016 13:47:04 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer 
In-Reply-To: 
Date: Mon, 28 Nov 2016 13:47:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrLuy2ibC4FmHhcXJt6/YLP4ttXdg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4Mh7s/cRU8JW7YsfmY+wNjDc5uxg5OSQETCSW ta1n7mLk4hASaGOSmHPhMTuEs5FR4v/ETlYI5yGTxKOW1WwgLcwC6hJ/5l1iBrF5BfQkNq1/ ywRiCwtESWyYtAishk1AVWL6mhagOAcHp4CtRNtuVZAwC1D44ZRfrCBhkDHtJ10gJmpLLFv4 GmqilcTyPRfZQWwhARuJZ02NYNNFgGouvr7FDnG0rMSTk4tYJjAKzEJy0CwkB81CMnYBI/Mq RtmU3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwSvdSU0k2M4CCV5N/BOKfB+xCjAAejEg/vDiub CCHWxLLiytxDjJIcTEqivNPdgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeMOqgHK8KYmVValF +TApaQ4WJXHe/25fw4UE0hNLUrNTUwtSi2CyMhwcShK880AaBYtS01Mr0jJzShDSTBycIMN5 gIYrgw0vLkjMLc5Mh8ifYlSUEudtrwRKCIAkMkrz4HpBSSTh7WHTV4ziQK8I8xaAtPMAExBc 9yugwUxAg9++tgYZXJKIkJJqYJxmcvTakjt+txqfK6z28NNt73Cd+P7M7p6b8Ze5N6jOufDv A++Z9ovPKvrrLmbNPBZvZn+liP1jz6ISoeSFnIennS5zFJz7oNauQaVG9vrWKb+F1l2Uu/m1 JaXXMWNvv/z36Q/W/2v4+OLrbY9P105wnHbVW6mdZsu2o+74ymDVnAXNyiKtUtVKLMUZiYZa zEXFiQCL1IbA/QIAAA==
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2016 18:47:10 -0000

I would consider that a totally reasonable extension. You will need to =
define what the behavior is if the client doesn=E2=80=99t provide a =
value for that field: is there a default? Are there no resources =
available to the client?

 =E2=80=94 Justin

> On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin  =
wrote:
>=20
> Hi All
>=20
> Our AS allows for the manual client registration with the UI offering =
an option to assign the audience/resource URIs to a given Client =
registration with all the associated future access tokens inheriting =
them.
>=20
> The client will not have to follow the resource indicator registration =
as recommended at [1] - the administrator who registers the clients sets =
the audiences.
>=20
> We'd like to achieve the same with the dynamic client registration but =
my colleague noted the client metadata in the dynamic registration =
request has no 'audience' property.
>=20
> We will consider supporting either an 'audience' or 'resource' =
property - does it sound reasonable ?
>=20
> By the way, as far as [1] is concerned, should a 'resource' property =
support an array of audiences ? (To support a case a client needed to =
talk to several RSs to complete a given action)
>=20
> Thanks, Sergey
>=20
> [1] =
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Mon Nov 28 13:29:08 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30E6129FCB for ; Mon, 28 Nov 2016 13:29:07 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj7AvCGpkEyW for ; Mon, 28 Nov 2016 13:29:06 -0800 (PST)
Received: from mail-wj0-x234.google.com (mail-wj0-x234.google.com [IPv6:2a00:1450:400c:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19186129A7A for ; Mon, 28 Nov 2016 13:29:05 -0800 (PST)
Received: by mail-wj0-x234.google.com with SMTP id v7so128065422wjy.2 for ; Mon, 28 Nov 2016 13:29:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KghDIfUbm4VpI75mkIs/rLmECfM+2adZ9oU1ah1ecUA=; b=a+PLcw7RI7hJ+jDRMtS9cv5vigc9jCytCLayhb9ly9SxvW+Qxs43bsDNoboSwdgjv9 G95X8tlmnGYW2NeRbiAxpG0WRGay6rzNk4KN/4AV4XBICY4y2UWwO6M0Qm7j3iGFFIRl 8LWlt4OBtTrSXnL8gwdcGoNnpGuCXKEK29iLBuirYNZ/3NXtVgYJMaRSbtXlM3r93+Ej UJupMXriCcigLPeknw4WFoBT+MNa8Mp6WJBw5clsfRzR3slV+6HK6W3XdZcpuk9uRAgn wOe42lTDA5FN423jXutDw2MhBzIIU1Ajc6SXpLgtHu5fiPiVXNsSTcbaOU4rnENQte6J Qilw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KghDIfUbm4VpI75mkIs/rLmECfM+2adZ9oU1ah1ecUA=; b=BaFnu73h3s6r+/9pF+G+LNOIDConAw5AdDsPJ7JJ/q4BF6GP5PRU6GBMQombYGs/Wx 2JL+7naB3NyGnyAIAWoXjEgRnC+t2PzfI7iIt9OGPErQnmmjDDGvwTMQABmghtKuv/4C /gaOVwMh/vJu2ZLTVgZ0OSj7HRADoaggU4LeZ+OaFWwO03kj5sdz71NjHk6bKt+kzYh7 BMeAo/bIOxIOiBXHLVLFq1i68kwRZMe7BbsFsvvOTBKU2noEc9xNG6iGwG0c6aCG8tnn h2YWSQ93E1ItSyppAVcMSZ1DrELmQITuFVG/6bjMpLTqcrK7Hg+w1bFwZvYJ6FQXVU5M x4fw==
X-Gm-Message-State: AKaTC00Tqf/Oi2sloHMxFPfAS9HDBo1+A1ZFATjoFee9qysAj2jTow02hIRad0z2vLaL2g==
X-Received: by 10.194.24.102 with SMTP id t6mr16820182wjf.111.1480368544264; Mon, 28 Nov 2016 13:29:04 -0800 (PST)
Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id j1sm64498063wjm.26.2016.11.28.13.29.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 13:29:03 -0800 (PST)
To: Justin Richer 
References:  
From: Sergey Beryozkin 
Message-ID: <5d46b60a-8a74-1acd-0535-0712f393d149@gmail.com>
Date: Mon, 28 Nov 2016 21:28:46 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2016 21:29:08 -0000

Hi Justin

Thanks, may be if a value for that field is not set, then, by default, a 
client can use the access tokens against the arbitrary RS servers, as 
far as I understand this is what happens by default right now ?

Cheers, Sergey

On 28/11/16 18:47, Justin Richer wrote:
> I would consider that a totally reasonable extension. You will need to define what the behavior is if the client doesn’t provide a value for that field: is there a default? Are there no resources available to the client?
>
>  — Justin
>
>> On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin  wrote:
>>
>> Hi All
>>
>> Our AS allows for the manual client registration with the UI offering an option to assign the audience/resource URIs to a given Client registration with all the associated future access tokens inheriting them.
>>
>> The client will not have to follow the resource indicator registration as recommended at [1] - the administrator who registers the clients sets the audiences.
>>
>> We'd like to achieve the same with the dynamic client registration but my colleague noted the client metadata in the dynamic registration request has no 'audience' property.
>>
>> We will consider supporting either an 'audience' or 'resource' property - does it sound reasonable ?
>>
>> By the way, as far as [1] is concerned, should a 'resource' property support an array of audiences ? (To support a case a client needed to talk to several RSs to complete a given action)
>>
>> Thanks, Sergey
>>
>> [1] https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>


From nobody Mon Nov 28 14:59:20 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D7B12A049 for ; Mon, 28 Nov 2016 14:59:18 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyI0UCgmWrNn for ; Mon, 28 Nov 2016 14:59:17 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B548B12A066 for ; Mon, 28 Nov 2016 14:58:58 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id n6so138354961qtd.1 for ; Mon, 28 Nov 2016 14:58:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VhQrT3FxIf4wESe2w7mxvaPhuaz6QU9Y6Rq3wQXUUf0=; b=oYfb/V8UrTA822TCl9wZkkGZWs8jr/WK9vvVvZoyu5x8cCQIxfJoo6fGjmYmYJ/5gK y9xV1Ntx5tjobs6hLQ9D2mxXLaphNixtc96WoH1Iw+FbwOd8gFq/9LhKoSXBWqB6dBOH eftJbbkHCuhDkMtIdyJho8h8NABvUTvVwa4i1PaLW0fywNVAI9d/a+jk0evIAnLL+cSp NmgYJdR29SGuZ4phDpXOOh3s7XqghwAwDuDjRxLxWVBi/CKZVXMQbIgvrrtiWCZBR22D zjdxKCvG0PM5FagL/d1Co2jKIjN+pyUp6Osyk0ENuBdVneDxJUuvZ/+z/GbosZBsklfI KKzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VhQrT3FxIf4wESe2w7mxvaPhuaz6QU9Y6Rq3wQXUUf0=; b=MaY+NSXGHFzU9Ma7fbaAXg7o8vQmPgcAePBcis99TuILDgkfk6bCncgYdtbMf5y9a0 0t8eySqtQfNv2zgo8zqggFIWKWMlZQeyaDFb2EX4ahiNO4Clgaay1VX/YmXqzvgpD3hM 3hEqiiFBvNKaC0Zt3IBIC5wgsDhwdprLPSXWBgnHbfvKxRlI8t+iC2+hNaXCNYrGywOL OIS0Gcskdbs1BgTpL/iWpU64yEX0Jb0Km96z0ICEtbTrIO5V2HQMFp+il2fRIxlFM/nf ZIV+gEI2W3f3aRXtuBwXiz1+TCcDIA4LBwWT51j2lbBcpDQqaeuQ2QxDIv6ocqkJqwW2 jF6w==
X-Gm-Message-State: AKaTC00OH9VxJ1FI6hO2D/S6ect/JJnCIbhBM833Q0J5+Mtp/QDzJ0R346JRsOr2R8QTKeC5
X-Received: by 10.237.35.246 with SMTP id k51mr21466429qtc.263.1480373937652;  Mon, 28 Nov 2016 14:58:57 -0800 (PST)
Received: from [192.168.8.100] ([181.201.99.161]) by smtp.gmail.com with ESMTPSA id h46sm29388193qta.35.2016.11.28.14.58.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 14:58:57 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 28 Nov 2016 19:58:53 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: Justin Richer 
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2016 22:59:19 -0000

To make something like this work with a loose coupling between the RS =
and AS the format of the AT would also need to be specified.=20

To this point the WG has avoided standardizing AT.

Most AS probably believe they know what RS the token is going to be used =
at based on scopes.=20
Taking those tokens and using them at other RS is arguably at-least out =
of scope or arguably not allowed by the current specs.

People are perhaps abusing the specs and sending AT to RS that are not =
properly audienced and can be replayed between RS.
This is really bad from a security perspective with bearer tokens.

I do however see a valid use case.

Registering RS with the client is not a bad idea, however if you =
register more than one without the client saying at runtime what RS the =
token is for they can still be replayed.
The client depending on design could still be tricked by a RS or =
something else to get a token audienced to a different RS if the AS =
dosen't know where the client is sending the token.

I don=E2=80=99t think registering RS gets around the need for the =
resource indicator draft =
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators

Typically we have thought about a tight coupling between the RS and AS,  =
but now it seems people are putting more of the intelligence/burden on =
the the client.

in a more dynamic system the RS might provide a list of AS that it =
accepts tokens form and the client might dynamically register with one =
of them.

I suspect Sergey=E2=80=99s AS is doing something in between.

I am hesitant to pick off just dynamic registration as there are a =
number of interrelated issues that need to be thought through to prevent =
security issues.

John B.






> On Nov 28, 2016, at 3:47 PM, Justin Richer  wrote:
>=20
> I would consider that a totally reasonable extension. You will need to =
define what the behavior is if the client doesn=E2=80=99t provide a =
value for that field: is there a default? Are there no resources =
available to the client?
>=20
> =E2=80=94 Justin
>=20
>> On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin  =
wrote:
>>=20
>> Hi All
>>=20
>> Our AS allows for the manual client registration with the UI offering =
an option to assign the audience/resource URIs to a given Client =
registration with all the associated future access tokens inheriting =
them.
>>=20
>> The client will not have to follow the resource indicator =
registration as recommended at [1] - the administrator who registers the =
clients sets the audiences.
>>=20
>> We'd like to achieve the same with the dynamic client registration =
but my colleague noted the client metadata in the dynamic registration =
request has no 'audience' property.
>>=20
>> We will consider supporting either an 'audience' or 'resource' =
property - does it sound reasonable ?
>>=20
>> By the way, as far as [1] is concerned, should a 'resource' property =
support an array of audiences ? (To support a case a client needed to =
talk to several RSs to complete a given action)
>>=20
>> Thanks, Sergey
>>=20
>> [1] =
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>>=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 Tue Nov 29 02:49:37 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E000129679 for ; Tue, 29 Nov 2016 02:49:35 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzKwJw3eBBLC for ; Tue, 29 Nov 2016 02:49:33 -0800 (PST)
Received: from mail-wj0-x232.google.com (mail-wj0-x232.google.com [IPv6:2a00:1450:400c:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD06D12946C for ; Tue, 29 Nov 2016 02:49:29 -0800 (PST)
Received: by mail-wj0-x232.google.com with SMTP id mp19so141562279wjc.1 for ; Tue, 29 Nov 2016 02:49:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=lnhmG+GhClq5YyN8uvFqPLybVIqjgORW9SbN1EEzT24=; b=ymh6lb00VgACd8aEUEFLu4NI3fHeA1xTEW1XjvXloMTHX0CcxATF2i1QAY7h6NP7jy vw22isHubppxD61T4HfBzFTox6x+sl9DcxoEqRa43SA8dvmpnBbQVGp17SCuskmU2qFY 1+5wyzMevB4eAQP1GFAgE6VjC7PlFj2QlDYzT7oP23khcJTXC0ME5TRsH0jHecRmdDlO 1KM8q4al5aqPVec6SUFb7HZcQB7WlpHdW11t/c/V1OTOwuGtmk1iluljwcEoJJ6eqLMc kNaP9hVXBKxcIEx0pI3aSpom563jScoEdy5N4FVUQH24cjbi/+8t9dPEJACxvH5l9huA wnIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lnhmG+GhClq5YyN8uvFqPLybVIqjgORW9SbN1EEzT24=; b=h80xXHz5C/dCSv1G5YvN+gg9Bl1DGkQjigczRzB/CginSVSEzncp0IMgbXfnrm6Wvf mqbjFpOKrX0oPBpK2T+3eixA8zAz4l+NDlezJLYeWQE6aeLqs+Rikta+P10hyOhXM7vR uyT4R2ItpuRbUeN3asVg9qcYmvP1F7wl5ImkYT1rRHAs81IJwJX7bVNcCNa0XhiYcqju 60IieB4dRsd6UfBn9VyIHVyq5IQBRyiWUh3Ntg5vlsNqNavWU95sIcXDZO0kd0hYkpZ4 0ftYSt3nC7mK6wcRJCRoI+zcIVWi1x01cV3+lEOwWqdwU5mGUV8PUqJBqeoUNVmhHziG e6LA==
X-Gm-Message-State: AKaTC01HJEwlMgZF5ZMUBGcDSO4XLUx99qXJU+T5ad674mYJRv+qXtCa0mRpFHUZiz5rVw==
X-Received: by 10.194.235.98 with SMTP id ul2mr22400976wjc.229.1480416568101;  Tue, 29 Nov 2016 02:49:28 -0800 (PST)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id b15sm2165411wma.5.2016.11.29.02.49.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 02:49:27 -0800 (PST)
To: John Bradley , Justin Richer 
References:   
From: Sergey Beryozkin 
Message-ID: <6c46d3a4-ad0d-3b49-7a15-7532634702e9@gmail.com>
Date: Tue, 29 Nov 2016 10:49:26 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2016 10:49:35 -0000

Hi John, All

I've been alway thinking that the reason an audience can be an array (as 
indicated for ex by the JWT spec, etc) is because a client application 
may need to talk to more than one RS in order to complete a single 
action for the current user (ex, the client will not talk to either RS1 
or RS2 but first to RS1 and then will complete the action by talking to 
RS2).

Why else would a JWT access token have an array of audience values ?
https://tools.ietf.org/html/rfc7519#section-4.1.3

I agree the resource indicators can help on its own - in case no 
audiences for a given client have been pre-registered or as you 
suggested - to point to a specific resource at the runtime, with this 
(resource) URI being validated against the pre-registered values.

But also, pre-registering a single audience during the client 
registration (dynamic or static) can minimize the need to use the 
resource indicators at the runtime.

I did not quite understand what you were explaining about registering 
RSs with the client - I guess that client will know in advance which 
RS(s) it will need to talk to do its work,

Many thanks, Sergey




On 28/11/16 22:58, John Bradley wrote:
> To make something like this work with a loose coupling between the RS and AS the format of the AT would also need to be specified.
>
> To this point the WG has avoided standardizing AT.
>
> Most AS probably believe they know what RS the token is going to be used at based on scopes.
> Taking those tokens and using them at other RS is arguably at-least out of scope or arguably not allowed by the current specs.
>
> People are perhaps abusing the specs and sending AT to RS that are not properly audienced and can be replayed between RS.
> This is really bad from a security perspective with bearer tokens.
>
> I do however see a valid use case.
>
> Registering RS with the client is not a bad idea, however if you register more than one without the client saying at runtime what RS the token is for they can still be replayed.
> The client depending on design could still be tricked by a RS or something else to get a token audienced to a different RS if the AS dosen't know where the client is sending the token.
>
> I don’t think registering RS gets around the need for the resource indicator draft https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators
>
> Typically we have thought about a tight coupling between the RS and AS,  but now it seems people are putting more of the intelligence/burden on the the client.
>
> in a more dynamic system the RS might provide a list of AS that it accepts tokens form and the client might dynamically register with one of them.
>
> I suspect Sergey’s AS is doing something in between.
>
> I am hesitant to pick off just dynamic registration as there are a number of interrelated issues that need to be thought through to prevent security issues.
>
> John B.
>
>
>
>
>
>
>> On Nov 28, 2016, at 3:47 PM, Justin Richer  wrote:
>>
>> I would consider that a totally reasonable extension. You will need to define what the behavior is if the client doesn’t provide a value for that field: is there a default? Are there no resources available to the client?
>>
>> — Justin
>>
>>> On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin  wrote:
>>>
>>> Hi All
>>>
>>> Our AS allows for the manual client registration with the UI offering an option to assign the audience/resource URIs to a given Client registration with all the associated future access tokens inheriting them.
>>>
>>> The client will not have to follow the resource indicator registration as recommended at [1] - the administrator who registers the clients sets the audiences.
>>>
>>> We'd like to achieve the same with the dynamic client registration but my colleague noted the client metadata in the dynamic registration request has no 'audience' property.
>>>
>>> We will consider supporting either an 'audience' or 'resource' property - does it sound reasonable ?
>>>
>>> By the way, as far as [1] is concerned, should a 'resource' property support an array of audiences ? (To support a case a client needed to talk to several RSs to complete a given action)
>>>
>>> Thanks, Sergey
>>>
>>> [1] https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>>>
>>> _______________________________________________
>>> 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 Tue Nov 29 09:37:47 2016
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A68F1129C21; Tue, 29 Nov 2016 09:37:38 -0800 (PST)
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: 6.38.2
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <148044105863.11650.12387836221191350572.idtracker@ietfa.amsl.com>
Date: Tue, 29 Nov 2016 09:37:38 -0800
Archived-At: 
Cc: oauth@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth-chairs@ietf.org
Subject: [OAUTH-WG] Last Call:  (Authentication Method Reference Values) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: ietf@ietf.org
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2016 17:37:46 -0000

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'Authentication Method Reference Values'
   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 2016-12-13. 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


   The "amr" (Authentication Methods References) claim is defined and
   registered in the IANA "JSON Web Token Claims" registry but no
   standard Authentication Method Reference values are currently
   defined.  This specification establishes a registry for
   Authentication Method Reference values and defines an initial set of
   Authentication Method Reference values.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ballot/


No IPR declarations have been submitted directly on this I-D.






<=
div>--
-jim
Jim Willeke


On Thu, Nov 17, 2016 at 10:23 AM, Vivek Bisw=
as <vivek.biswas@oracle.com> wrote:
+1 to It MAY be an absolute URI, as speci=
fied by Section 4.3 of [RFC3986]".
Since the Audie=
nce Restriction can be a logical name to be interpreted by the Resource Ser=
ver, if it really wants to enforce the audience check for a set of Resource=
s it wants to protect.
Hence, a logical name can be an absolute URI or a=
 String as well.
Regards
Vivek Biswas, CISSP
Cons=
ulting Member, Security
Oracle Corporation.

=C2=A0<=
/p>
Fr=
om: Denis [mailto:denis.ietf@free.fr] 
Sent=
: Tuesday, November 15, 2016 3:50 AM
To: oauth@ietf.org
Subject: [OAUT=
H-WG] About Big Brother and draft-campbell-oauth-resource-indicators-0=
0
=C2=A0
Hello everybody,
Si=
nce I am not present at the meeting, I read the minutes from the first sess=
ion, in particular:
B=
rian Campbell and John did a draft allowing the client to tell the AS where=
 it plans to use the token
draft-campbell-oauth-resource-indicators=

=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 This enables the AS to audience restrict the access token to the res=
ource
=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 Phil Hunt:=C2=A0 We should keep the audience restriction idea =
on the table
Th=
e introduction contains the following sentences:
Several years of deployment and implementation =
experience with OAuth 2.0 [RFC6749] has uncovered a need, in some circumsta=
nces, 
for the client to explicitly signal to the authorization sever wh=
ere it intends to use the access token it is requesting.

A means for=
 the client to signal to the authorization sever where it intends to use th=
e access token it's requesting is important and useful. <=
u>
The document contains a "=
;security considerations" section but unfortunately no "privacy c=
onsiderations" section.

Clause 2 states:
The client may indicate the resource server=
(s) for which it is requesting an access token by including the
followin=
g parameter in the request.

resource

OPTIONAL. The value of t=
he resource parameter indicates a resource server where the requested
ac=
cess token will be used. It MUST be an absolute URI, as specified by=
 Section 4.3 of[RFC3986],
With such an approach, the authorization server would have the a=
bility to act as a Big Brother and hence to know exactly 
where t=
he user will be performing activities.
However, some us=
ers might be concerned with their privacy, and would like to restrict the u=
se of the access token 
to some resource servers without the authorizati=
on server knowing which are these resource servers. 
Th=
e key point is whether the information is primarily intended to the authori=
zation server or to the resource server(s).
I believe t=
hat it is primarily intended to the resource server(s) rather than to the a=
uthorization server in order to be included 
in an access token. Obvious=
ly, the information needs to transit through the authorization sever, that =
should simply be copied 
and pasted into the access token. Its semantics=
, if any, does not necessarily needs to be interpreted by the authorization=
 sever.
I believe that a "privacy considerations&q=
uot; section should be added. 
The sentence "It=
 MUST be an absolute URI, as specified by Section 4.3 of [RFC3986]"=
; should be removed or 
=C2=A0replaced by : "It MAY be an absolu=
te URI, as specified by Section 4.3 of [RFC3986]".
Obviously, other changes would be necessary too.
D=
enis