Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6101AC3F2 for ; Mon, 2 Nov 2015 16:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxs0RNIWeMQ9 for ; Mon, 2 Nov 2015 16:45:23 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 8B8861AC3CF for ; Mon, 2 Nov 2015 16:45:23 -0800 (PST) Received: by qgeo38 with SMTP id o38so1153604qge.0 for ; Mon, 02 Nov 2015 16:45:22 -0800 (PST) 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:content-type; bh=hCq0aT3L1u8OwieTBeyPiA7yHgyEIdBN7bD/8/yUyH8=; b=j9UHCCQNcZm2b6YdEZv9Prnle3hbqh7EjyIXjwdDHaCFeK/B5XaLCwsD0p/JTwVWgS M08VSsBBwju5rALKDk881V0LRj3rO7xtR+DoOUnW/drJ9LrxufrIPsUj5lE5ItIRKFMJ s4hnE0zASSC/FCxBUuvf+vd0gESQrXMni2jJFMpUVmFa8zTBuiybh3f3t1h4S+2f2Ags usIxqUU+BikW7ucGWlELDRxiiFxMqm/q/5sOWQjxVrPuS1wAriUibMx0puLhLi45nUTo AkKpecIc59i+6RqXgMctkWSJzYTVhMkH8Uvry/fctOWyeV7ufpvEjJGAjeKYMCVmmsZr JV2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hCq0aT3L1u8OwieTBeyPiA7yHgyEIdBN7bD/8/yUyH8=; b=FDhQZEQxPlLBwXlfEsiw2JMnBQNE6gLa1T60tm/FlQLj0rHZFiAdeiCHF0kNe5YLq5 wkgWXepx/qrNYpeByVuuCwrM/AUgCIm+K8kKMdavLOWyq0Yh2b5F9tQiNAovq7Eopabe 68hqZcQXrvT7ZkJTMe7KRuVkHlWJ48vUtg+Q7aGLPhE30urXJsHzO4tiiNyTcmRrd8UA t3tTTMg9hzmFjs444rSxWhZFqWqZmX+0t1vLblnEE9pcgURIrcOPPSIg64R598TczIvO pFWd0pvfsecQRyHHgKIvLdXLBu6AtVShXsejte5YgBBn9L/txubLs68sRcClM7Ktruuv jCHw== X-Gm-Message-State: ALoCoQl6ICUEsugF47gZz0flhVcw5TS8hEkatBWL8GEycGP94E5PDoC1ZzJ2cOotDt/HqJjA2jQ7 X-Received: by 10.140.39.105 with SMTP id u96mr21150634qgu.35.1446511522623; Mon, 02 Nov 2015 16:45:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.18 with HTTP; Mon, 2 Nov 2015 16:45:03 -0800 (PST) In-Reply-To: <5637feb5.611a450a.bf33d.4307@mx.google.com> References: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> <5637feb5.611a450a.bf33d.4307@mx.google.com> From: William Denniss Date: Tue, 3 Nov 2015 09:45:03 +0900 Message-ID: To: Michael Ciarlillo Content-Type: multipart/alternative; boundary=001a11c13044787dfd052398352a Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 00:45:27 -0000 --001a11c13044787dfd052398352a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I advocated a similar position as yours 4 months ago, in the thread titled [OAUTH-WG] Token introspection for public clients? . My impression at the time is that the primary use-case of the spec was the RS one, even though it could support these other use-cases but for that MUST. I agree that using the token for authentication as a workaround does kind of break the point of the MUST, but as it is, the spec defines the authentication as "The methods of managing and validating these authentication credentials are out of scope of this specification.", so it is open to interpretation. On Tue, Nov 3, 2015 at 9:24 AM, Michael Ciarlillo < michael.ciarlillo@gmail.com> wrote: > Thanks for the feedback. > > I agree that the spec is not badly designed over all. I just think that > the MUST is a bit too restrictive, especially with how none of the OAuth > grants requires authentication to begin with except when a client is > Confidential or when using Client Credential flow (for obvious reasons). > > I don't believe that simply using a token to determine its validity is a > good course of action. There may very well be unintended side-effects (li= ke > the issuance of a new refresh/access token when using a refresh token at > the Token endpoint, or one-time use access tokens). One use case presente= d > by K=C3=A9vin Chalet is when a client might need to determine and what us= ers it > has been authorized access on behalf of and possibly remove those that ar= e > no longer valid. Another might be something like determining if an initia= l > one-time use access token for registration requests is still active and > available to use for client registration. > > Not having available resources or libraries to validate JWTs or other > tokens on the client was another use case mentioned in discussions we had= . > I'm glad others have had similar discussions for this scenario. > > That being said, the idea of using the token itself for authentication > intrigues me, though doesn't that inherently break the entire point of > having the authentication be a MUST in the spec to begin with? How might = an > Authorization Server mitigate inherent security risks with this approach > for any type of tokens? > ------------------------------ > From: William Denniss > Sent: =E2=80=8E11/=E2=80=8E2/=E2=80=8E2015 6:58 PM > To: Justin Richer ; Michael Ciarlillo > > Cc: > Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues > > We had a debate on that MUST at the last IETF, but the spec was too far > along to change. The workaround is to treat the token you are introspecti= ng > as the authentication. With that workaround, the spec is quite usable for > non-confidential clients, even if resource servers were the primary targe= t. > > Google currently runs an introspection endpoint of sorts for clients, > named "tokeninfo", and the latest version (v3) is close to the spec > (coincidence - it's a good design pattern). Aimed mostly at debugging > use-cases or if you don't have a JWT decoding library handy. > On Tue, Nov 3, 2015 at 1:43 AM Justin Richer wrote: > >> Hi Michael, >> >> Thanks for the comments. First off, the text of an RFC is fixed and >> cannot be changed. The spec can only be altered with a new document that >> obsoletes RFC7662, which would have to go through the working group proc= ess >> again from the very beginning. >> >> Authentication is required but we=E2=80=99re open to how it happens. The >> introspection spec is targeted at resource servers, not clients, since a >> client can always just *use* the token in order to see if it=E2=80=99s v= alid or >> not. Why bother with the extra round trip to check if the token is good >> before trying it, since trying it will also tell you if the token=E2=80= =99s good? >> The recovery process for a failed token is the same in either state. We >> initially had this written for either clients or protected resources, bu= t >> that=E2=80=99s not how people were using it and restricting its focus he= lped >> clarify the spec immensely. >> >> ID tokens are a slightly different case as they=E2=80=99re an assertion = targeted >> at the client itself, but in those cases an ID token is really meant to = be >> self-contained as a JWT, and generally has a short validity period. If >> you=E2=80=99re looking to introspect an old ID token to check an OIDC se= ssion >> status, then you might be better served implementing one of the OIDC >> session spec components for that purpose. >> >> Also, we didn=E2=80=99t mandate a specific authentication technology. Mo= st people >> are going to use either client authentication or a specific OAuth token >> designed for this purpose. The latter of these is technically available = for >> public clients, but then you have the question of if you want to check t= he >> status of *that* token too. Still, I think that for any clients (includi= ng >> public ones) the right thing to do is just use the token and see if it >> works. >> >> To the other comment, HTTP POST is the only defined verb and we=E2=80=99= re silent >> on the use of other verbs. That said, many HTTP implementation framework= s >> don=E2=80=99t differentiate between verbs for requests and so a POST wit= h body form >> parameters and a GET with query parameters would come out the same. We >> don=E2=80=99t outright prohibit this behavior, but it=E2=80=99s off-labe= l and there are >> security considerations for its use. >> >> Hope this helps, >> =E2=80=94 Justin >> >> On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo < >> michael.ciarlillo@gmail.com> wrote: >> >> Hello all, >> >> I have a couple of comments/issues with the RFC at >> https://tools.ietf.org/html/rfc7662. >> >> According to Section 2.1 (Introspection Request) says that "To prevent >> token scanning attacks, the endpoint MUST also require some form of >> authorization to access this endpoint..." This might make sense for >> token introspection requests only coming from Resource Servers, but to m= any >> implementers it makes sense to allow Clients access to the introspection >> endpoint since it would serve the same purpose (token validity checking, >> particularly for refresh tokens, but also for access tokens, or identity >> tokens in OpenID Connect, or possibly other token types in UMA and other >> specs). Unfortunately, this means that public clients should be accounte= d >> for in some way, as refresh tokens don't have an explicit requirement in >> the OAuth 2.0 spec that they be issued only to Confidential Clients. As >> such, many implementers don't feel like the Introspection spec fits well >> for Client consumption because of the "MUST" requirement on authenticati= on, >> when public clients won't have a Client Secret to authenticate with. >> Further, token scanning attacks would not be mitigated for authenticated >> callers (be they Resource Servers or Clients). >> >> An example of a real-world implementer discussion talking about this >> topic is one I had with K=C3=A9vin Chalet: >> https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/p= ull/159 >> >> We are not the only ones who see this as a problem with the spec, and >> there do not seem to be many concrete reasons for this endpoint ONLY bei= ng >> for Resource Servers themselves. Can some insight into why this is the >> case? Can the MUST be changed to a SHOULD with the Security Consideratio= ns >> section expanded to talk about the issue? If not, is there another spec = or >> draft out there somewhere for OAuth token validity for which the intent = is >> explicitly client consumption? Any and all feedback on this would be >> greatly appreciated as we develop the ASOS middleware project. >> >> Another (small) comment on the spec: Section 2.1 (Introspection Request) >> currently says that requests be HTTP POST method requests, however Secti= on >> 4 (Security Considerations) mentions Authorization Servers explicitly >> disallowing the GET method due to server logs. What is the requirement >> here? POST with optional GET or explicitly only allowing POST requests? >> >> Sincerely, >> Michael Ciarlillo >> _______________________________________________ >> 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 >> > --001a11c13044787dfd052398352a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I advocated a similar position as yours 4 months ago, in t= he thread titled [OAUTH-W= G] Token introspection for public clients?.

My = impression at the time is that the primary use-case of the spec was the RS = one, even though it could support these other use-cases but for that MUST.= =C2=A0 I agree that using the token for authentication as a workaround does= kind of break the point of the MUST, but as it is, the spec defines the au= thentication as "The methods of managing and validating these authenti= cation credentials are out of scope of this specification.", so it is = open to interpretation.

On Tue, Nov 3, 2015 at 9:24 AM, Michael Ciarlillo <= span dir=3D"ltr"><michael.ciarlillo@gmail.com> wrote:
Thanks for the feedback.

I agree that the spec is n= ot badly designed over all. I just think that the MUST is a bit too restric= tive, especially with how none of the OAuth grants requires authentication = to begin with except when a client is Confidential or when using Client Cre= dential flow (for obvious reasons).

I don't believe that simply = using a token to determine its validity is a good course of action. There m= ay very well be unintended side-effects (like the issuance of a new refresh= /access token when using a refresh token at the Token endpoint, or one-time= use access tokens). One use case presented by K=C3=A9vin Chalet is when a = client might need to determine and what users it has been authorized access= on behalf of and possibly remove those that are no longer valid. Another m= ight be something like determining if an initial one-time use access token = for registration requests is still active and available to use for client r= egistration.

Not having available resources or libraries to validate= JWTs or other tokens on the client was another use case mentioned in discu= ssions we had. I'm glad others have had similar discussions for this sc= enario.

That being said, the idea of using the token itself for auth= entication intrigues me, though doesn't that inherently break the entir= e point of having the authentication be a MUST in the spec to begin with? H= ow might an Authorization Server mitigate inherent security risks with this= approach for any type of tokens?
From:= William Denniss
Sent: =E2=80=8E11/=E2=80=8E2/=E2=80=8E2015 6:58 PM
To: <= /span>Justin Richer; Michael Ciarlillo
Cc: <oauth= @ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection R= FC Issues

We had a debate on tha= t MUST at the last IETF, but the spec was too far along to change. The work= around is to treat the token you are introspecting as the authentication. W= ith that workaround, the spec is quite usable for non-confidential clients,= even if resource servers were the primary target.

Google currently = runs an introspection endpoint of sorts for clients, named "tokeninfo&= quot;, and the latest version (v3) is close to the spec (coincidence - it&#= 39;s a good design pattern). Aimed mostly at debugging use-cases or if you = don't have a JWT decoding library handy.
On Tue, Nov 3, 2015 at 1:43 AM Justin Richer <jricher@mit.edu> wrote= :
Hi Michael,

Thanks for = the comments. First off, the text of an RFC is fixed and cannot be changed.= The spec can only be altered with a new document that obsoletes RFC7662, w= hich would have to go through the working group process again from the very= beginning.

Authentication is required but we=E2= =80=99re open to how it happens. The introspection spec is targeted at reso= urce servers, not clients, since a client can always just *use* the token i= n order to see if it=E2=80=99s valid or not. Why bother with the extra roun= d trip to check if the token is good before trying it, since trying it will= also tell you if the token=E2=80=99s good? The recovery process for a fail= ed token is the same in either state. We initially had this written for eit= her clients or protected resources, but that=E2=80=99s not how people were = using it and restricting its focus helped clarify the spec immensely.
=

ID tokens are a slightly different case as they=E2=80= =99re an assertion targeted at the client itself, but in those cases an ID = token is really meant to be self-contained as a JWT, and generally has a sh= ort validity period. If you=E2=80=99re looking to introspect an old ID toke= n to check an OIDC session status, then you might be better served implemen= ting one of the OIDC session spec components for that purpose.
Also, we didn=E2=80=99t mandate a specific authentication tech= nology. Most people are going to use either client authentication or a spec= ific OAuth token designed for this purpose. The latter of these is technica= lly available for public clients, but then you have the question of if you = want to check the status of *that* token too. Still, I think that for any c= lients (including public ones) the right thing to do is just use the token = and see if it works.=C2=A0

To the other comment, H= TTP POST is the only defined verb and we=E2=80=99re silent on the use of ot= her verbs. That said, many HTTP implementation frameworks don=E2=80=99t dif= ferentiate between verbs for requests and so a POST with body form paramete= rs and a GET with query parameters would come out the same. We don=E2=80=99= t outright prohibit this behavior, but it=E2=80=99s off-label and there are= security considerations for its use.

Hope this he= lps,
=C2=A0=E2=80=94 Justin

On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo <<= a href=3D"mailto:michael.ciarlillo@gmail.com" target=3D"_blank">michael.cia= rlillo@gmail.com> wrote:

Hello all,
I have a couple of comments/issues with the RFC at https://tools.i= etf.org/html/rfc7662.

According to Section 2.1 (Intr= ospection Request) says that "To pre= vent token scanning attacks, the endpoint MUST also require=C2=A0some form of authorization to access this en= dpoint..."=C2=A0This might make sense for token introspection r= equests only coming from Resource Servers, but to many implementers it make= s sense to allow Clients access to the introspection endpoint since it woul= d serve the same purpose (token validity checking, particularly for refresh= tokens, but also for access tokens, or identity tokens in OpenID Connect, = or possibly other token types in UMA and other specs). Unfortunately, this = means that public clients should be accounted for in some way, as refresh t= okens don't have an explicit requirement in the OAuth 2.0 spec that the= y be issued only to Confidential Clients. As such, many implementers don= 9;t feel like the Introspection spec fits well for Client consumption becau= se of the "MUST" requirement on authentication, when public clien= ts won't have a Client Secret to authenticate with. Further, token scan= ning attacks would not be mitigated for authenticated callers (be they Reso= urce Servers or Clients).

An example of a real-wor= ld implementer discussion talking about this topic is one I had with=C2=A0K= =C3=A9vin Chalet:=C2=A0https://github.co= m/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pull/159

We are not the only ones who see this as a problem with th= e spec, and there do not seem to be many concrete reasons for this endpoint= ONLY being for Resource Servers themselves. Can some insight into why this= is the case? Can the MUST be changed to a SHOULD with the Security Conside= rations section expanded to talk about the issue? If not, is there another = spec or draft out there somewhere for OAuth token validity for which the in= tent is explicitly client consumption? Any and all feedback on this would b= e greatly appreciated as we develop the ASOS middleware project.
=
Another (small) comment on the spec: Section 2.1 (Introspect= ion Request) currently says that requests be HTTP POST method requests, how= ever Section 4 (Security Considerations) mentions Authorization Servers exp= licitly disallowing the GET method due to server logs. What is the requirem= ent here? POST with optional GET or explicitly only allowing POST requests?=

Sincerely,
Michael Ciarlillo
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--001a11c13044787dfd052398352a--