Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -06

[Ian McKellar]

Hi,

I'm reading through draft 6 of the bearer token spec and had a
question about one of the examples. In section 2.4 there's an error
response example when an expired token is used:
   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: Bearer realm="example"
 error="invalid_token",
 error_description="The access token expired"

I think there should be a comma after realm="example"

Also, I wasn't sure about spaces in the error_description. I'm digging
through related linked specs to try to work out what a quoted-string
should actually look like. Are spaces allowed? Should characters be
backslash-quoted or percent-quoted?

Ian

On Wed, Jun 22, 2011 at 8:53 PM, Mike Jones  wrote:
> I’ve published draft 06 of the OAuth Bearer Token Specification.  It
> contains the following changes:
>
> · Changed parameter name bearer_token to access_token, per working
> group consensus.
>
> · Changed HTTP status code for invalid_request error code from HTTP
> 401 (Unauthorized) back to HTTP 400 (Bad Request), per input from HTTP
> working group experts.
>
>
>
> It doesn’t change the use of 403 (Forbidden) to (401) Unauthorized as had
> been discussed as a possibility, also due to input from the same HTTP
> working group experts.
>
>
>
> I believe that this addresses all the bearer token specification issues
> arising from the interim working group meeting and working group discussions
> since then.
>
>
>
> The draft is available at these locations:
>
> ·
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.pdf
>
> ·
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.txt
>
> ·
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.xml
>
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.html
>
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.pdf
>
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.txt
>
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.xml
>
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will
> point to new versions as they are posted)
>
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will
> point to new versions as they are posted)
>
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will
> point to new versions as they are posted)
>
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will
> point to new versions as they are posted)
>
> · http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion
> repository, with html, pdf, txt, and html versions available)
>
>
>
>     -- Mike
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>



-- 
Ian McKellar  
i...@mckellar.org: email | jabber | msn
ianloic: flickr | aim | yahoo | skype | linkedin | etc.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] state parameter and XSRF detection

[Eran Hammer-Lahav]

> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Sunday, July 10, 2011 2:17 AM

> Eran Hammer-Lahav  schrieb:
> 
> >The security of the protocol relies fully (implicit grant) or partially
> >(authorization code) on the validation of the redirection URI. This was
> >well understood by many experts but until -17, we largely ignored by
> >the specification.
> 
> what does "security of the protocol" mean? Wrt what threats?

s/security of the protocol/client identification

> I personally think there are various features of the protocol contributing to
> the overall security level of the protocol protocol (for different threats). 
> For
> example: user engagement and control plays an important role. We
> documented those relations in the security document.

User engagement is nice in theory. In practice, it is more likely to enable 
attacks than prevent them (e.g. phishing).
 
> Redirect uri validation is, in my opinion, not effective for native apps and
> useless if the attacker uses a native app (no matter whether the legitimate
> client is a web, user agent based or native app). Thus I consider relying on
> this mean exclusively is dangerous.

There are no other practical means. Also, can you describe an attack involving 
a native application that is more problematic than the actual installation of a 
malicious native application?

> >Using dynamic values are still fully supported:
> >
> >   3.1.2.2.  Registration Requirements
> >
> >   The authorization server MUST require public clients to register
> >   their redirection URI, MUST require all clients to register their
> >   redirection URI prior to utilizing the implicit grant type, and
> > SHOULD require all clients to register their redirection URI prior to
> >   utilizing the authorization code grant type.
> >
> >   The authorization server SHOULD require the client to provide the
> >   complete redirection URI (the client MAY use the "state" request
> >   parameter to achieve per-request customization).  The authorization
> >   server MAY allow the client to register multiple redirection URIs.
> >   If requiring the registration of the complete redirection URI is not
> > possible, the authorization server SHOULD require the registration of
> >   the URI scheme, authority, and path.
> >
> 
> So what this text basically says is: You should enforce full uri registration 
> &
> validation but you don't have to. Which also means my use case for XSRF
> prevention using other parameters is still supported. Am I wrong?

Full registration is recommended. Allowing changes should be limited to the 
query, and doing that comes with its own can of worms to look for. But yes, 
your use case is still supported. Personally, I will never deploy anything but 
full registration of redirection URI.

EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh token security considerations

[William J. Mills]

I agree that this is something you could do, but it doesn't seem like a good 
design pattern.




From: Torsten Lodderstedt 
To: Eran Hammer-Lahav ; OAuth WG 
Sent: Sunday, July 10, 2011 1:21 AM
Subject: Re: [OAUTH-WG] Refresh token security considerations

replacement of the refresh token with every access token refresh is an example. 
The authz server creates and returns a new refresh token value with every 
access token refreshment. The old value is invalidated and must not be used any 
further. Note: The authz server keeps track of all old (invalidated) refresh 
tokens.

If a client presents one of those old refresh tokens, the legitimate client has 
been compromised most likely. The authz then revokes the refresh token and the 
associated access authorization.

regards,
Torsten.




Eran Hammer-Lahav  schrieb:
“the authorization server SHOULD deploy other means to detect refresh token 
abuse”
> 
>This requires an example. 
> 
> 
>EHL
___
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

Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth]

[Brian Campbell]

Not before the submission deadline tomorrow.  Probably sometime before
submissions reopen.

On Sat, Jul 9, 2011 at 9:04 AM, Eran Hammer-Lahav  wrote:
> Sounds reasonable. Can you provide a schedule outline?
>
> EHL
>
>> -Original Message-
>> From: Brian Campbell [mailto:bcampb...@pingidentity.com]
>> Sent: Saturday, July 09, 2011 5:53 AM
>> To: Eran Hammer-Lahav
>> Cc: oauth
>> Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 1: client auth]
>>
>> Thanks for the response, Eran. I'm breaking this thread up into the distinct
>> issues.  Reply inline below to the first item about client auth.
>>
>> On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav
>>  wrote:
>> >
>> > > However, the SAML draft does not currently cover SAML for client
>> > > authentication and profiling draft-ietf-oauth-assertions would
>> > > suggest that it should.  Is there any general consensus as to if
>> > > SAML should be profiled as a client authentication method?  It is
>> > > certainly feasible but might require restructuring and retitling the 
>> > > draft.
>> >
>> > Are there use cases pending such functionality today? It would be a shame
>> to delay an otherwise useful draft when the functionality can be added later.
>>
>> I don't have any such use cases in the near future.  Perhaps others can speak
>> up? I personally see assertion based grants as being more important and
>> more immediately useful.  That was one of the reasons I was looking to keep
>> assertion grants and client assertion authentication separate.  That said,
>> Chuck has done a nice job with his general treatment of them together in
>> draft-ietf-oauth-assertions and the logical thing to do, in terms of how the
>> various documents play together, would be to have draft-ietf-oauth-saml2-
>> bearer cover client auth now too.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] state parameter and XSRF detection

[Torsten Lodderstedt]

Eran Hammer-Lahav  schrieb:

>The security of the protocol relies fully (implicit grant) or partially
>(authorization code) on the validation of the redirection URI. This was
>well understood by many experts but until -17, we largely ignored by
>the specification.

what does "security of the protocol" mean? Wrt what threats?

I see detection/prevention of malicious clients. Anything else?

I personally think there are various features of the protocol contributing to 
the overall security level of the protocol protocol (for different threats). 
For example: user engagement and control plays an important role. We documented 
those relations in the security document.

Redirect uri validation is, in my opinion, not effective for native apps and 
useless if the attacker uses a native app (no matter whether the legitimate 
client is a web, user agent based or native app). Thus I consider relying on 
this mean exclusively is dangerous.

>
>Using dynamic values are still fully supported:
>
>   3.1.2.2.  Registration Requirements
>
>   The authorization server MUST require public clients to register
>   their redirection URI, MUST require all clients to register their
>   redirection URI prior to utilizing the implicit grant type, and
>  SHOULD require all clients to register their redirection URI prior to
>   utilizing the authorization code grant type.
>
>   The authorization server SHOULD require the client to provide the
>   complete redirection URI (the client MAY use the "state" request
>   parameter to achieve per-request customization).  The authorization
>   server MAY allow the client to register multiple redirection URIs.
>   If requiring the registration of the complete redirection URI is not
>  possible, the authorization server SHOULD require the registration of
>   the URI scheme, authority, and path.
>

So what this text basically says is: You should enforce full uri registration & 
validation but you don't have to. Which also means my use case for XSRF 
prevention using other parameters is still supported. Am I wrong?

>And 3.1.2.3.  Dynamic Configuration, adds:
>
>   If the authorization server allows the client to dynamically change
>   the query component of the redirection URI, the client MUST ensure
>   that manipulation of the query component by an attacker cannot lead
>   to an abuse of the redirection endpoint as an open redirector.
>
>The rational for this is that comparing full URIs (using simple string
>comparison) provides for much less moving parts. We know from
>experience that URI normalization is hard and that attackers sometimes
>find ways to inject values into the redirection URI and still pass
>validation (based on the specific issues with the server’s
>normalization logic).
>
>We were unable to come up with a useful set of rules for redirection
>URI validation based on individually registered URI components. This
>has also been an area of great confusion by OAuth 1.0 developers, as
>each provider has its own set of rules and methods for URI
>registration. Some implementations are outright idiotic. On the other
>hand, if we recommend developers to simply do string comparison (per
>RFC 3986 section 6) and not allow any changes, we know it is much more
>likely to be implemented securely.
>
>Beyond the complexity of normalization and comparison: many existing
>platform allow for internal redirections and special handling using
>special query parameters. Most login pages support some form of
>automatic redirection to the referring resource. If an attacker can
>access such a parameter, it can manipulate the redirection URI to pass
>validation but produce very different results. The worst case scenario
>is finding a query parameter capable of triggering a redirection which
>will then send the credentials to the attacker.
>
>The simplest form of this attack is the availability of an open
>redirector (which most large providers have, some with better
>safeguards then others). If example.com offers an open redirector,
>registration of the scheme and authority will accomplish nothing, as
>the open redirector endpoint will pass validation. Registration of the
>full path is *usually* sufficient, but not always, and relies of proper
>normalization that forces a query separator '?' between the fully
>registered path and the appended query (as well as enforce proper
>reserved characters encoding).
>
>The typical sophistication of the authorization server developer is
>much greater than that of the client developer. It is better to
>encourage the server developer to enforce better policy, than hope that
>the client developer will be able to find and close every potential
>security hole in its entire system to render redirection URI validation
>trustworthy.
>
>The specification provides and highlights the 'state' parameter as the
>proper way of accomplishing redirection URI customization. It is
>significantly simpler to restrict validation to simple string
>comparison, and protect the 'state'

Re: [OAUTH-WG] Section 10.1 (Client authentication)

[Torsten Lodderstedt]

Hi,

I just remembered the original aim of the text. We not just intended to list 
alternative means but to get a general message across: If you cannot 
authenticate a client considers this in your security design! Either (1) you 
accept the fact the respective identities can be forged and handle them as 
untrusted entities through your logic (as far as I remember Skylar suggested 
the term forgeable clients) or (2) you find other ways to establish trust in 
the client's identity. 

The effect of (1) depends on the security policy of the certain deployment and 
the risk associated with certain functions. It could e.g. mean to rely on the 
id to aggregate log entries (not critical) but never to automatically process 
authz processes or settle payment transaction.

Examples for (2) are: redirect uri validation, relying on the user to identify 
the client, and (subsequently) use refresh tokens as mean for client 
authentication. I don't think we can give a complete list of means here since I 
assume some deployments will have their own capabilities.

Please also note: redirect uri validation is not an adequate replacement for 
client authentication. It's not effective for native apps and useless if the 
attacker uses a native app (no matter whether the legitimate client is a web, 
user agent based or native app).

regards,
Torsten.



Eran Hammer-Lahav  schrieb:

Hey Torsten,

The provided text and alternative text are just not helpful. If I am unable to 
understand it, I have doubt other readers will be able to.

I don't know what you mean by 'other means' which are not already described in 
the document (based on -17). Referencing the security thread model document in 
a normative reference requires making it a normative reference which I am 
opposed to doing - the v2 document should include everything needed to 
implement the protocol without any additional specifications (for the core 
functionality).

When I was asking for examples, I was hoping for something like 'for example, 
use x, y, or z', not a reference to about 10 pages of text (which by itself is 
pretty confusing, but that's a different issue - I hope to find the time to 
provide detailed feedback for that document).

I think the current document makes a pretty good case for using the redirection 
URI as a form of client validation, and clearly lays out the differences 
between a public and private client. It has new requirements for the 
registration of redirection URIs when client authentication is not possible.

If there are specific things the authorization server can do to improve 
security beyond client authentication, we should list them explicitly in the 
document.

Can you list exactly what you have in mind by 'other means'? Just the bullet 
points will be enough.

EHL


> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Friday, July 08, 2011 12:59 AM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: Section 10.1 (Client authentication)
> 
> seems you are contradicting yourself.
> 
> You criticised the MUST and suggested to include some examples. I bought
> into your argument and suggested to refer to the security doc for examples
> and additional explanations. That's what this document is intended for, to
> provide background beyond what we can cover in the core spec.
> 
> And I don't think the spec already makes that point. But you are free to refer
> me to the respective text.
> 
> regards,
> Torsten.
> 
> 
> 
> Eran Hammer-Lahav  schrieb:
> 
> >I still don’t find it useful. I think the existing text overall makes
> >this point already.
> >
> >EHL
> >
> >From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> >Sent: Wednesday, July 06, 2011 12:48 AM
> >To: Eran Hammer-Lahav; OAuth WG
> >Subject: Re: Section 10.1 (Client authentication)
> >
> >Hi Eran,
> >
> >I would suggest to change it to SHOULD and add a reference to
> >https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections
> >3.7 and 5.2.3.
> >
> >regards,
> >Torsten.
> >
> >
> >Eran Hammer-Lahav
> mailto:e...@hueniverse.com>>
> >schrieb:
> >It's a pointless MUST given how undefined the requirements are. It will
> >only be understood by security experts and they don't really need it.
> >At a minimum, it needs some examples.
> >
> >EHL
> >
> >From: Torsten Lodderstedt
> >mailto:tors...@lodderstedt.net>>
> >Date: Wed, 1 Jun 2011 00:53:37 -0700
> >To: Eran Hammer-lahav
> >mailto:e...@hueniverse.com>>, OAuth WG
> >mailto:oauth@ietf.org>>
> >Subject: Section 10.1 (Client authentication)
> >
> >Hi Eran,
> >
> >would you please add the following sentence (which was contained in the
> >original security considerations text) to the second paragraph of
> >section 1.0.1?
> >
> >Alternatively, authorization servers MUST utilize
> > other means than client authentication to achieve their security
> > objectives.
> >
> >
> >I think it's important to state that authorization server should
> >consider alternative way to validat

Re: [OAUTH-WG] Refresh token security considerations

[Torsten Lodderstedt]

replacement of the refresh token with every access token refresh is an example. 
The authz server creates and returns a new refresh token value with every 
access token refreshment. The old value is invalidated and must not be used any 
further. Note: The authz server keeps track of all old (invalidated) refresh 
tokens.

If a client presents one of those old refresh tokens, the legitimate client has 
been compromised most likely. The authz then revokes the refresh token and the 
associated access authorization.

regards,
Torsten.



Eran Hammer-Lahav  schrieb:

“the authorization server SHOULD deploy other means to detect refresh token 
abuse”

 

This requires an example. 

 

 

EHL

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth