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

[Panca Agus Ananda <[e-mail]>]

  1.  Panca.blogspot.com

Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: [e-mail]
Terkirim: Selasa, 2 Desember 2014 21.06
Ke: [e-mail]
Balas Ke: [e-mail]
Perihal: OAuth Digest, Vol 74, Issue 12


Send OAuth mailing list submissions to
        [e-mail]

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
        [e-mail]

You can reach the person managing the list at
        [e-mail]

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


Today's Topics:

   1. Re: Review of draft-ietf-oauth-introspection-01
      (Hannes Tschofenig)
   2. Re: Review of draft-ietf-oauth-introspection-01 (Justin Richer)


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

Message: 1
Date: Tue, 02 Dec 2014 14:31:31 +0100
From: Hannes Tschofenig <[e-mail]>
To: Sergey Beryozkin <[e-mail]>, [e-mail]
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="windows-1252"

Hi Sergey,

comments below.


On 12/02/2014 01:39 PM, Sergey Beryozkin wrote:
> Hi Hannes
>
> Thanks for the clarifications, comments below...
> On 02/12/14 12:02, Hannes Tschofenig wrote:
>> Hi Sergey,
>>
>> On 12/02/2014 12:30 PM, Sergey Beryozkin wrote:
>>>>
>>>> * 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.
>>>>
>>> Interesting, I was reading the doc yesterday and thought it was good it
>>> was not talking about specific access token types :-)
>>>
>>> I wonder why a pop token can not be introspected in the interoperable
>>> way as per the text for the resource server to tale the authorization
>>> decision ?
>>>
>>
>> The problem is that the AS needs to have the same context as the RS. In
>> the bearer token case, the RS really only needs to pass the the access
>> token along but in the PoP case one could imagine a couple of different
>> solutions.
>>
>> A possible solution is that the AS sends the RS the necessary key so
>> that the RS is able to verify the MAC or digital signature covering the
>> request.
>>
>> The story would again be different if the PoP solution involves TLS.
>>
>> Yet another solution would be to also forward the entire request to the
>> AS (which I wouldn't do).
>>
>> This is not specified in the current version of token introspection and,
>> from the responses Justin gave at the last IETF meeting, he does not
>> want to wait till the PoP work is finished to actually work out the
>> details.
>>
>> Finally, from a security point of view it would be extremely important
>> that the AS only provides a key to the RS if the RS is (a) authenticated
>> and (b) the audience field from the token matches the RS since otherwise
>> the PoP security degrades to a bearer token.
>
> I see the draft specifying an optional resource_id hint (which I read
> being an actual request URI) which is the primary signing material in
> the pop case, the extra parameters like the nonce/timestamp can be
> forwarded along.

Of course we haven't worked out the details for the HTTP signing yet.
Hence, it would be a bit premature to make that conclusion.

>
> I agree it does not make sense to forward the actual body but that is
> probably going to be a very rare case where a body hash is also provided.

Maybe. I see a lot of value in protecting the body of the message as
well but I would do it with the help of TLS and then use a channel
binding mechanism.

>
> Explicitly disallowing the support for the pop tokens in the
> introspection text might the interoperability reach of either pop tokens
> or token introspections in cases where a given RS integrates with a 3rd
> party AS. May be it is a Security Considerations draft issue which would
> make it more open for pop tokens

Ultimately, we are really only talking about a document management issue
here. I assume that we want to have support for introspection with PoP
tokens as well and we might just end up dumping the text into the HTTP
signing draft (as an extension to the token introspection doc).

Ciao
Hannes

>
> Thanks, Sergey
>
>>
>> Ciao
>> Hannes
>>
>>> Thanks, Sergey
>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 513 bytes
Desc: OpenPGP digital signature
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/8dc9d121/attachment.asc>

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

Message: 2
Date: Tue, 02 Dec 2014 09:05:42 -0500
From: Justin Richer <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, "[e-mail]"
        <[e-mail]>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

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
> [e-mail]
> 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/72a4ff34/attachment.html>

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

Subject: Digest Footer

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


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

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