Re: [OAUTH-WG] draft-ietf-oauth-introspection

Justin Richer <jricher@mit.edu> Tue, 02 December 2014 00:42 UTC

Return-Path: <jricher@mit.edu>
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 550F51A7004 for <oauth@ietfa.amsl.com>; Mon, 1 Dec 2014 16:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4hgmra4vbtC for <oauth@ietfa.amsl.com>; Mon, 1 Dec 2014 16:42:06 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74ED1A701B for <oauth@ietf.org>; Mon, 1 Dec 2014 16:42:05 -0800 (PST)
X-AuditID: 1209190d-f793c6d000001ec0-27-547d0adc7e9d
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.73.07872.CDA0D745; Mon, 1 Dec 2014 19:42:04 -0500 (EST)
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 sB20g3rc028263; Mon, 1 Dec 2014 19:42:04 -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 sB20fxXm008923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Dec 2014 19:42:02 -0500
Content-Type: multipart/signed; boundary="Apple-Mail=_7A8F6DAA-D6A2-4F12-BF0C-C8CBB0954526"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <BN3PR0301MB1234973440252E2F6A36D770A67D0@BN3PR0301MB1234.namprd03.prod.outlook.com>
Date: Mon, 01 Dec 2014 19:41:58 -0500
Message-Id: <4B1239F5-5DD3-4F1B-8691-75E8B07F3891@mit.edu>
References: <BN3PR0301MB12348944618D97E9C2B87E6EA67C0@BN3PR0301MB1234.namprd03.prod.outlook.com> <375CE45E-8896-4BD1-B398-ECE53A464BF7@mit.edu> <BN3PR0301MB1234973440252E2F6A36D770A67D0@BN3PR0301MB1234.namprd03.prod.outlook.com>
To: Anthony Nadalin <tonynad@microsoft.com>
X-Mailer: Apple Mail (2.1878.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDKsWRmVeSWpSXmKPExsUixCmqrXuHqzbE4P4iIYuTb1+xWWyau43R gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGVsv5BTcGcOU8X8rZ3MDYzbvzJ2MXJySAiY SBxbdZAJwhaTuHBvPVsXIxeHkMBsJoklG9exgySEBDYwSnzo8YVI3GCSeDf/FVgVs8AkRon+ i7OZQap4BQwkluzaBGYLC5hJrFvawgZiswmoSkxf0wK2glMgUeLhhhlgNSwCKhLzp+wHO4MZ qObLgvdMEHOsJO4seQJ1xhNGibONt8GKRAS0JU68X8kMcau8xIcPx9knMArMQnbILCSHzAIb nCSx/+JaJghbW2LZwtdQcQOJp52vWDHF9SXevJsDVS8vsf3tHKi4pcTimTdYIGxbiVt9C6Bq 7CQeTVvEuoCRexWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrpJkZwxEny7mB8d1Dp EKMAB6MSD++J8zUhQqyJZcWVuYcYJTmYlER5F34ECvEl5adUZiQWZ8QXleakFh9iVAHa9WjD 6guMUix5+XmpSiK8j0FaeVMSK6tSi/JhyqQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ 8O7krA0REixKTU+tSMvMKUFIM3FwHmKU4OABGv4NpIa3uCAxtzgzHSJ/ilFRSpxXD5jqhARA EhmleXC9sET5ilEc6C1h3n0g7TzAJAvX/QpoMBPQYIbmSpDBJYkIKakGRt/s3XcEywXTXrwy Ov4370/Uc8O3K/mK33oGB0Wsr1Jn+sNaJNRwWjihVuLtiX27jxk62K7YtfX4sg3zOVfLSJ6Q efuEfZmm0KVpaXl2fKnbnshdkP8415Rrl8KXxqtnN1m0p+hurnuZcnVC6Y/vx47u4v1wMLv9 pvND18yFyoLn6k629VtpTlNiKc5INNRiLipOBAD6ZCCEbwMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6bBFvbtVneUV6ES8Mz1Z3TAlb4w
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection
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 00:42:10 -0000

> 1.       Is the metadata (introspection response) being returned from the authorization endpoint or from the token or a combination of both ?

As I said below, ultimately it’s about the token and what it represents. If the token was issued through use of the authorization endpoint, then it’s likely that there’s some context from that authorization endpoint tied to the token that can be returned.

> 2.       “context” there may be no context other than the token, are you expecting the authorization endpoint to always keep a context of how/why the token was issued ?

If you’re asking if stateless tokens can be supported with this, then yes, that’s fine. If the token’s completely on its own (like a structured token generated as an assertion and used as an OAuth 2.0 access token) and a server’s able to unpack that for a client without access to other pieces of context, then that’s what it returns. But in that case, if you’re issuing stateless tokens, with self-contained metadata and expirations and no other context to be conveyed beyond what’s already inside the token, then you’d probably just tell your protected resources how to parse and handle them directly. 

> 3.       The specification should clearly state which type of tokens are supported and what profiles/bindings are supported, like JWT Bearer, etc.

That’s opaque to the protected resource for purposes of this protocol, just like a token is opaque to a client for purposes of 6749/6750 OAuth. The introspection protocol supports whatever tokens are supported by the AS, so we don’t need to list token types, but maybe we can be clearer about the opaqueness of the token value in this process. Since these are OAuth tokens and not assertions, no bindings or profiles are needed beyond this. It’s a simple query-response and it’s up to the server to know how to fulfill this contract. 

> 4.       If I have an SAML Bearer assertion, and the SAML assertion is encrypted and have no way to know this, it can potentially fail if it can’t be decrypted but as far as I can tell I’m not sending an encrypted token since this is just a SAML assertion, not sure how one really determines what is wrong

If the AS can’t decrypt the token then it can’t introspect it. So it doesn’t in this case. And if you’re issuing encrypted OAuth tokens with no means to decrypt them back at the AS, then you probably wouldn’t offer an introspection service to begin with. This is covered in the security considerations section already.

> 5.       Should be spelled out what “active” is supposed to mean so folks get the same results on different endpoints

As I said below, it means to answer “is this token still good or not?” for a protected resource that can’t answer that on its own, and I believe the current definition reflects that. Please submit text if the existing definition is insufficient or unclear to you.

 — Justin

>  
>  
> From: Justin Richer [mailto:jricher@mit.edu] 
> Sent: Sunday, November 30, 2014 6:57 PM
> To: Anthony Nadalin
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-introspection
>  
> Tony, thanks for the comments. Your timing is great, as I was just today sitting down to polish the introspection draft into a proper WG document ready for the last-call tomorrow. I’ve just posted the updated draft, and I think that you’ll find it addresses your concerns. More direct answers inline:
>  
>  
> On Nov 30, 2014, at 1:01 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
> 
> 
> Comments
>  
> Intro
> “about the authentication conext”, not sure what this is since there is no authentication context in Oauth
>  
> There are several authentication contexts in OAuth: the resource owner at the authorization endpoint, the client at the token endpoint, etc. Regardless, this is meant to be the context of the authorization decision, text now reads: "context in which the token was issued"
> 
> 
> Use of Oauth2, mixed with use of Oauth, pick one
>  
> All usage changed to “OAuth 2.0” throughout the document, let me know if I missed any.
> 
> 
> “allows holder of a token to query” so anything/anyone that has a token can use this endpoint?
>  
> Now reads authorized holder of the token and has stronger language and recommendations about requiring authorization on the endpoint to prevent public token fishing. This was already addressed in the security considerations section, but that has been propagated throughout the specification now. 
> 
> 
>  
> Introspection Endpoint
> Use of Oauth2, mixed with use of Oauth, pick one
>  
>  
> See above.
> 
> 
> 
> Introspection Request
> The endpoint SHOULD also require some form of authentication”, what about some form of authorization ? Why do we have to have another endpoint that we have to manage and then have a management API draft?]
>  
> This is now clearer that it needs to be an authorized protected resource. This authorization may be carried through a credential mechanism as defined in OAuth 2.0, through an access token, or through some other mechanism. 
> 
> 
>  
> Token – is this any type of token ? how does the endpoint know that it can deal with this token type?
>  
> Clarified that it’s either the access_token from the token endpoint or the refresh_token from the token endpoint. You can use this with other token types, but that’s not defined in this spec which concerns itself with RFC6749/RFC6750. 
> 
> 
> So endpoint has to try to lookup token  to determine if it can maybe find out something about the token?
>  
> That’s the idea, the protected resource is asking an authoritative source (the authorization server) about a given token. I had always thought it was obvious that the authorization server would have to be able to know something about the token in order to provide an introspection service, but since that seems to have been unclear to some I’ve made it explicit in the security considerations section. 
> 
> 
> Can the one use the authorization code or does one have to get a token first?
>  
> No, this is for tokens only. I don’t see the point of introspecting an authorization code — those aren’t sent to protected resources, they’re sent to clients, which would in turn just hand it to the token endpoint to get a token. There’s nothing else to find out about it.
> 
> 
>  Can I send a encrypted token and expect a proper response ?
>  
> If the server can decrypt or otherwise understand the token, yes. I’ve pointed out this requirement in the security considerations section. 
> 
> 
> What about a Proof of Possession Token?
>  
> Yes, I think this fits great with PoP tokens, but those aren’t defined well enough yet to say anything concrete. As the PoP work progresses, we can have an extension document to determine what needs to be done there. Note that we’ll have to do the same thing with the Revocation RFC.
> 
> 
>  Introspection Response
> What is “active” mean ? Is this up to the server to determine ?
>  
> It means the token is live, hasn’t been revoked, was actually issued by this server, isn’t expired, and the protected resource that’s asking has the right to know all that information. This is all up to the server to determine. If the server can’t determine that information for its own tokens, it probably shouldn’t be offering this service.
> 
> 
> “scope OPTIONAL”, is this the scope in the token or is this the scope that the introspection endpoint sources may have ? It’s unclear if all these return values are from the token or from the introspection endpoint sources ?
>  
> These are the scopes of the token. All return values are, as stated, metadata about the token itself that is being queried against.
> 
> 
> What error codes/conditions are there? Just the 400  (bad request)?
>  
> The errors are more clearly spelled out. Most of it involves bad client authentication (when client credentials are used), bad authorization (when access tokens are used to access the introspection endpoint itself), or the like. If the token being introspected isn’t good, that’s still a 200 response — the request is fine, but the token being introspected isn’t active, which is what’s returned. This isn’t an error, it’s a valid answer to the question of “what is this token?” that’s being asked every time introspection is called.
> 
> 
> Can the endpoint return a encrypted response ?
>  
> That’s outside the scope of this document. It returns JSON like the rest of OAuth.
> 
> 
> What about PII such as user_id, aud ?
>  
> This is now covered in the Privacy Considerations section, which wasn’t A Thing when this draft was first written.
>  
>  — Justin
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>