Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
"Donald Coffin" <donald.coffin@reminetworks.com> Tue, 02 December 2014 18:49 UTC
Return-Path: <donald.coffin@reminetworks.com>
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 721D91A1B21 for <oauth@ietfa.amsl.com>; Tue, 2 Dec 2014 10:49:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level:
X-Spam-Status: No, score=-1.656 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 ruqRiRxr_FJr for <oauth@ietfa.amsl.com>; Tue, 2 Dec 2014 10:49:31 -0800 (PST)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 10A461A6EE4 for <oauth@ietf.org>; Tue, 2 Dec 2014 10:49:31 -0800 (PST)
Received: (qmail 11211 invoked by uid 0); 2 Dec 2014 18:49:29 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 2 Dec 2014 18:49:28 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by CMOut01 with id Nioy1p01C2is6CS01ip1Fv; Tue, 02 Dec 2014 11:49:01 -0700
X-Authority-Analysis: v=2.1 cv=dfgTgxne c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=UGkfVyPCAAAA:8 a=rE68L1KyjUoA:10 a=VhNdJee_-yMA:10 a=A92cGCtB03wA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=2oeSqxxVzlsA:10 a=sMBj6sIwAAAA:8 a=48vgC7mUAAAA:8 a=9hn9lkgQvH-8MDNfBhoA:9 a=pL8WwNu0vnHEXfgG:21 a=JcLFklui71tuRfnR:21 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=PKjczCZQm44nRn8oK9QA:9 a=RJNTIGC05BKz0n-p:21 a=zaKb1prAdGbajsfN:21 a=HZK3P_hFCrB_44ae:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=G7AE6tyXK8Ktf5xWCylQPCGxPp/SpyLwd8ALNdQZkUo=; b=I7g9Z+gCSx28jxrs7KBBR2swtZcEBGkW4CVpQLy9JSj4ocq9JJPcerWNy10/INQXTaD9yNIQw+cbqxwGUvbtM088Ed0h6D2ayhZRQkFREJUA+6g/jKx8L47H/k0EPJYW;
Received: from [72.194.76.57] (port=53928 helo=HPLaptop) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from <donald.coffin@reminetworks.com>) id 1XvsVO-0002WR-L1; Tue, 02 Dec 2014 11:48:58 -0700
From: Donald Coffin <donald.coffin@reminetworks.com>
To: "'Richer, Justin P.'" <jricher@mitre.org>
References: <547DA128.9090606@gmx.net> <547DC736.5070609@mit.edu> <009101d00e54$f099aff0$d1cd0fd0$@reminetworks.com> <506AAEA8-7D72-4B14-8CB6-F3F2319ACFFB@mitre.org>
In-Reply-To: <506AAEA8-7D72-4B14-8CB6-F3F2319ACFFB@mitre.org>
Date: Tue, 02 Dec 2014 10:49:02 -0800
Organization: REMI Networks
Message-ID: <00d601d00e60$a5dfa0d0$f19ee270$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01D00E1D.97BED1D0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQKGGpy4MgmEfHmE8Q3UIvvG5HsInALnUkxoASbP4AECL+/gY5rem25w
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 72.194.76.57 authed with donald.coffin@reminetworks.com}
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vQvTpyTxhqiszL9ydIZO9L9rT3M
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2014 18:49:38 -0000
Justin, Thanks for the clarification. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com <mailto:donald.coffin@reminetworks.com> From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Tuesday, December 2, 2014 10:19 AM To: Donald Coffin Cc: Justin Richer; Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 No, this isn't an appropriate mapping in this case, especially if the introspection endpoint is itself OAuth protected. You need to be able to differentiate between the token being asked about and the token authorizing the question. These error codes apply to the latter and should not be conflated with the former. -- Justin On Dec 2, 2014, at 12:25 PM, Donald Coffin <donald.coffin@reminetworks.com <mailto:donald.coffin@reminetworks.com> > wrote: Hi Justin, I believe you will find the answer to which HTTP Status code the AS should return if the token is INACTIVE in Section 3.1 Error Codes of "The OAuth 2.0 Framework: Bearer Token Usage" [RFC6750] which states: 3.1. Error Codes When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and includes one of the following error codes in the response: invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code. invalid_token The access token provided is expired, revoked, malformed, or invalid for other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request. insufficient_scope The request requires higher privileges than provided by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the scope attribute with the scope necessary to access the protected resource. If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT include an error code or other error information. For example: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example" Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 22751 El Prado Suite 6216 Rancho Santa Margarita, CA 92688-3836 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com <mailto:donald.coffin@reminetworks.com> From: Justin Richer [mailto:jricher@mit.edu] Sent: Tuesday, December 2, 2014 6:06 AM To: Hannes Tschofenig; oauth@ietf.org <mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 Hannes, thanks for the review. Comments inline. On 12/2/2014 6:23 AM, Hannes Tschofenig wrote: Hi Justin, I have a few remarks regarding version -01 of the token introspection document. * Terminology The token introspection protocol is a client-server protocol but the term "client" already has a meaning in OAuth. Here the client of the token introspection protocol is actually the resource server. I believe it would make sense to clarify this issue in the terminology section or in the introduction. Maybe add a figure (which you could copy from Figure 4 of http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt. Maybe you want to call these two parties, the introspection client and the introspection server. I tried to avoid the word "client" for this very reason. The draft used to say "client or protected resource" throughout, but in a few years of deployment experience it's become clear that it's pretty much just protected resources that need to do introspection so I changed that text throughout. I don't think that "introspection client" will help here because the party already has a name from OAuth and we should inherit it. * Scope I think the document needs to be very clear that is only applicable to bearer tokens (and not to PoP tokens). This issue was raised at the last IETF meeting as well. I think the document should be clear that it *specifies* the mechanism for bearer tokens, since that's the only OAuth token type that's defined publicly right now, and that the details for PoP will have to be specified in another spec -- that's exactly what Appendix C is there for, and if that can be clearer, please suggest better text. However, I think it's very clear how PoP tokens would work. You send the value returned as the "access_token" in the token endpoint response, which is effectively the public portion of the PoP token. Just like a bearer token, this value is passed as-is from the client to the RS and would be passed as-is from the RS to the AS during introspection. The AS can then use that to look up the key and return it in an as-yet-unspecified field so that the RS can validate the request. The RS wouldn't send the signature or signed portion of the request for the AS to validate -- that's a bad idea. But these are all details that we can work out in the PoP-flavored extension. As I noted in the other thread, we'll have to make a similar extension for Revocation, so I still don't think it makes sense to hold up this work and wait for PoP to be finished because it's useful now, as-is. * Meta-Information You have replicated a lot of the claims defined in https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31 and I am wondering why you have decided to not just re-use the entire registry from JWT? If you want to create a separate registry (which I wouldn't recommend) then you have to put text into the IANA consideration section. The idea was to inherit JWT's syntax and semantics, at least on the wire, and add additional fields. It probably makes sense to just inherit the JWT registry, so we can do that. When you write: " The endpoint MAY allow other parameters to provide further context to the query. " You could instead write that the token introspection MUST ignore any parameters from the request message it does not understand. Noted, will add. Of course, there is the question whether any of those would be security critical and hence ignoring them would cause problems?! Anything security critical would be provider-specific, in which case it wouldn't ignore them. * Security The requirement for authenticating the party issuing the introspection request to the token introspection endpoint is justified in the security and the privacy consideration section. The security threat is that an attacker could use the endpoint to testing for tokens. The privacy threat is that a resource server learns about the content of the token, which may contain personal data. I see the former as more dangerous than the latter since a legitimate resource server is supposed to learn about the authorization information in the token. An attacker who had gotten hold of tokens will not only learn about the content of the token but he will also be able to use it to get access to the protected resource itself. In any case, to me this sounds like mutual authentication should be mandatory to implement. This is currently not the case. On top of that there is single technique mandatory-to-implement outlined either (in case someone wants to use it). That's in general not very helpful from an interoperability point of view. Yet another thing to agree on between the AS and the RS. I had similar thoughts when putting draft -01 together but didn't want to make a normative change like that without the WG input. I'm fine with strengthening this to a MUST, since as far as I'm aware that's how it works in all existing implementations (can anyone else comment on this?). I'm less comfortable with making one particular mechanism MTI, since I know of implementations that use either a special set of credentials passed just like client credentials to the token endpoint, or an OAuth token specifically for the introspection endpoint. If we do standardize on one MTI form, I'd suggest that we make it the OAuth bearer token. * SHOULDs This is my usual comment that any SHOULD statement should give the reader enough information about the trade-off decision he has to make. When should he implement something and when should he skip it? Noted, thanks. * Minor items You write: " These include using structured token formats such as JWT [JWT] or SAML [[ Editor's Note: Which SAML document should we reference here? ]] and proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses) that convey token information. " Just reference the JWT since that's what we standardize. I'm fine with that, didn't want to offend the SAML cabal but we can cut it. * 'Active' claim you write: " active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. " Wouldn't it make more sense to return an error rather than saying that this token is not active. It's not an error, really. It's a valid request and valid response saying that token isn't any good. It would be easy enough to change the returned error code on the {active:false} response, but to which code? The request isn't Forbidden, or Not Found (the token could have been found but it's been deactivated or just not available to the RS that's asking for it), or Unauthorized, or even a Bad Request. So my logic is that the response is "OK", but the content of the response tells you the metadata about the token, which is that it's not active. * Capitalization Reading through the text I see bearer token/Bearer Token, Client/client, etc. issue. Thanks, still breaking old Bad Habits of capitalizing Terms In The Document. Tried to clean it up, will do more. * AS <-> RS relationship You write: " Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource, only that they must have an agreement on the tokens themselves, there have been many different approaches to bridging this gap. " I am not sure what you mean by "defines no relationship" between the AS and the RS. Of course, there is a relationship. The AS issues tokens for access for a specific RS. The RS needs to understand the tokens or if it does not understand them it needs to know which AS to interact with to learn about the content. In a nutshell, I am not sure what you want to say with this paragraph particularly since you state that they have to have an agreement about the tokens. What I was trying to point out is that it doesn't define the nature of the relationship between the two components. Specifically, it says: The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server. This spec provides one mechanism for this validation. So we could reference this directly if that's helpful. -- Justin Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Justin Richer
- [OAUTH-WG] Review of draft-ietf-oauth-introspecti… Hannes Tschofenig
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Sergey Beryozkin
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Hannes Tschofenig
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Sergey Beryozkin
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Hannes Tschofenig
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Justin Richer
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Sergey Beryozkin
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Richer, Justin P.
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Sergey Beryozkin
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Richer, Justin P.
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Donald Coffin
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Thomas Broyer
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Richer, Justin P.
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Bill Mills
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Donald Coffin
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Richer, Justin P.
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Bill Mills
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Richer, Justin P.
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Bill Mills
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… John Bradley
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Richer, Justin P.
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… John Bradley
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Bill Mills
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Richer, Justin P.
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Eve Maler
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… John Bradley
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Richer, Justin P.
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Phil Hunt
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Justin Richer
- Re: [OAUTH-WG] Review of draft-ietf-oauth-introsp… Phil Hunt