Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 21

From: Panca Agus Ananda <[email-masked]>
Date: Wed, 3 Dec 2014 02:19:04 +0700

Panca.blogspot.com

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: [email-masked]
Terkirim: Rabu, 3 Desember 2014 02.06
Ke: [email-masked]
Balas Ke: [email-masked]
Perihal: OAuth Digest, Vol 74, Issue 21

Send OAuth mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."

Today's Topics:

   1. Re: Notes on draft-ietf-oauth-introspection-01 (Richer, Justin P.)
   2. Re: Review of draft-ietf-oauth-introspection-01
      (Richer, Justin P.)

----------------------------------------------------------------------

Message: 1
Date: Tue, 2 Dec 2014 18:53:25 +0000
From: "Richer, Justin P." <[email-masked]>
To: Thomas Broyer <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>
Subject: Re: [OAUTH-WG] Notes on draft-ietf-oauth-introspection-01
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="windows-1252"

Thomas, thanks for the review. Responses inline.

On Dec 2, 2014, at 11:08 AM, Thomas Broyer <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Here are some notes about draft-ietf-oauth-introspection-01.
Background: I have implemented and deployed -00 (actually that was some version of the individual draft, before it got adopted by the WG), currently with only a couple "clients" (out of 20 or so OAuth 2.0 clients currently, only a couple expose resources themselves and thus need the introspection endpoint; we otherwise have many resources exposed by the same piece of software as the AS so they use internal means of validating the token without the need for the introspection endpoint).

   resource_id  OPTIONAL.  A service-specific string identifying the
      resource that the token is being used for.  This value allows the

      protected resource to convey to the authorization server the
      context in which the token is being used at the protected
      resource, allowing the authorization server to tailor its response
      accordingly if desired.

I think it should be noted somewhere that it's totally OK for the introspection endpoint to tailor the response to the resource server making the request too, independently of whether there's a resource_id or not. With "tailoring the response" meaning that it could return active:false even if the token is active but the AS doesn't want the RS to know about it (because, for example, it knows that the token doesn't grant any scope that the RS accepts, and therefore couldn't be used at the RS), or limiting the returned list of scopes to the ones the AS knows the RS handles.

This is very true, we should call that out explicitly in the description of the response. Thanks!

As far as resource_id is concerned, I really think an example would make things clearer (what kind of value could be used in a real scenario, etc. ? there's been a mail earlier today assuming it would be a URL, which I assume to mean the URL of the resource that received the token and needs to introspect it to allow access or not; my interpretation of the draft initially was that it would rather be identifiers as can be seen for scopes, or a resource-set ID <https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-03> )

My thought on this was that it would be the URL in many cases, but I want to keep it as a generic string to allow for resource sets or other identifying mechanisms. This is going to have to be something that's agreed on between the AS and RS if it's going to mean anything. I agree on adding it to at least one of the examples.

   The methods of managing and
   validating these authentication credentials are out of scope of this
   specification, though it is RECOMMENDED that these credentials be
   distinct from those used at an authorization server's token endpoint.

and later in the Security Considerations section:

   The authorization server SHOULD issue credentials to any
   protected resources that need to access the introspection endpoint,
   SHOULD require protected resources to be specifically authorized to
   call the introspection endpoint, and SHOULD NOT allow a single piece
   of software acting as both a client and a protected resource to re-
   use the same credentials between the token endpoint and the
   introspection endpoint.

Could you expand on the RECOMMENDED and SHOULD NOT here?
What would be the problem with using the same credentials? What's the trade-off?

Different credentials for different purposes, and it lets you manage things separately at the server. In other words, you've got one class of thing that *gets* tokens, and one class of thing that *accepts* tokens. The dynamic resource registration draft doesn't presume client credentials at all, since a resource might not (and in many cases is not) also an OAuth client. This draft even uses tokens to authorize its calls to the introspection endpoint, which was suggested as MTI in another thread.

Additionally, and this may be getting unnecessarily colored by our own implementation and deployment of pre-WG drafts: we have it currently implemented such that both are clients (and Ping does something similar with their own method of accomplishing the same thing), and we want to start to keep these classes separate. We've found that developers get confused about whether they're a client or a resource or whatnot as it is. This recommendation helps keep the roles separate logically, though servers are of course free to throw everyone in the same bucket if they so choose.

   The response MAY be cached by the protected resource, and the
   authorization server SHOULD communicate appropriate cache controls
   using applicable HTTP headers.

Reading through https://tools.ietf.org/html/rfc7234 (and https://tools.ietf.org/html/rfc7231), it's not clear to me how cache headers would really help, given that the requests to the introspection endpoint are mostly using the POST method ("optionally" a GET method, and the Security Considerations section somehow discourages it).
You'd want to check with the HTTPWG but maybe this text should define what the cache-key would be (it would at least include the token and resource_id if provided, maybe also the token_type_hint), and that the response SHOULD NOT have Cache-Control:public or even s-maxage (for the same reason that it should be protected by authentication).
I'd actually rather say that the RS may cache the response (we're talking about an "application-level cache" here, not an HTTP cache), and probably should do it for a small amount of time; and possibly (not sure how well that would fit here) hint that the AS could very well return an HTTP 429 (Too Many Requests) <https://tools.ietf.org/html/rfc6585> if it somehow detects that the RS doesn't use a (application-level) cache (e.g. asks many times for the same token in a very short time frame). This is the kind of things I could very well add to my implementation later on if we ever see a very high number of requests on our introspection endpoint (because looking up a key-value store using the token as key is much faster than validating the token ? our tokens are base64url-encoded JSON structures containing an ID and a salt, and we store the ID and a hash in our datastore; validating a token thus involves decoding base64url, parsing JSON and computing a hash, in addition to looking it up
  in the datastore and validating "iat" and "exp").

All that we're really trying to say here is that the protected resource is allowed to cache the response if it wants to, and that the AS could give some hints as to how to do it. I can pull out the HTTP-cache-mechanism language if it's just confusing the matter (which I suspect it is). In one deployment profile I've written of this, we say that the RS can cache the introspection result for up to half the token lifetime, given by the 'exp' claim (which we also require in the profile).

   If the protected resource uses OAuth 2.0 client credentials to
   authenticate to the introspection endpoint and its credentials are
   invalid, the authorization server responds with an HTTP 400 (Bad
   Request) as described in section 5.2<https://tools.ietf.org/html/draft-ietf-oauth-introspection-01#section-5.2> of OAuth 2.0 [RFC6749<https://tools.ietf.org/html/rfc6749>].

Either I don't understand what "OAuth 2.0 client credentials" actually means, or that section should mention HTTP 401 (Unauthorized).
(we use HTTP Basic auth FWIW so, per the HTTP spec, we return a 401 for bad credentials).

   If the protected resource uses an OAuth 2.0 bearer token to authorize
   its call to the introspection endpoint and the token used for
   authorization does not contain sufficient privileges or is otherwise
   invalid for this request, the authorization server responds with an
   HTTP 400 code as described in section 3<https://tools.ietf.org/html/draft-ietf-oauth-introspection-01#section-3> of OAuth 2.0 Bearer Token
   Usage [RFC6750<https://tools.ietf.org/html/rfc6750>].

Same here; unless you use the "Form-Encoded Body Parameter" or "URL Query Parameter" means of sending a Bearer token, the status code would be a 401.
BTW, if an introspection endpoint MAY support those means of authenticating a RS, then it should be more clearly stated in the draft that it is allowed and left at the discretion of the implementation. As an implementer, unless I'm told that I could use access_token in the request body, I would assume only the Authorization header is accepted.

Noted, I'll change these to 401.

Thanks very much!
 -- Justin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/ed245936/attachment.html>

------------------------------

Message: 2
Date: Tue, 2 Dec 2014 19:05:02 +0000
From: "Richer, Justin P." <[email-masked]>
To: Bill Mills <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

The call to introspection has a TLS requirement, but the call to the RS wouldn't necessarily have that requirement. The signature and the token identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

"However, I think it's very clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) would then also have a TLS or transport security requirement unless there is token introspection client auth in play I think.  Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.

-bill

On Tuesday, December 2, 2014 6:06 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/de09852b/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

------------------------------

End of OAuth Digest, Vol 74, Issue 21
*************************************