Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

We are discussing TLS right now as a mean to prevent impersonation of the end-user's session on the client site. Correct? It's definitely a good advice to protect session from being highjacked that way. But I'm wondering whether this really belongs into the scope of OAuth? BTW: It's covered in

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

I’ve been doing this longer. Requiring TLS on the redirection endpoint is a big change for OAuth deployments. This would have been unthinkable for OAuth 1.0(a). One of the main goals of 2.0 was to make it much easier for client developers. I don’t think deploying HTTPS as a prerequisite for play

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

+1 I disagree that to use TLS is a big change. Rather I'd categorize using TLS as a big inconvenience. We should define a secure profile. If individual deployments choose to relax the spec and determine HTTP acceptable for local host or other convenience thats fine, but it shouldn't be compl

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Why can't TLS be a must except when the token cannot be exposed. Eg because the redirect is local? Phil Sent from my phone. On 2011-03-29, at 22:48, Eran Hammer-Lahav wrote: > Francisco – thanks for being persistent. > > > > Sounds like the same problem exists in OAuth 1.0. Basically, t

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Francisco – thanks for being persistent. Sounds like the same problem exists in OAuth 1.0. Basically, the only way the client knows that the same user who granted authorization is the one coming back, is via the authorization code. Anyone who has that code is basically assumed to be the one gra

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

I think you got this backwards. We're talking about forcing developers using the Facebook (or any other service) API to deploy their own TLS endpoint for the incoming callback (via redirection). Every developer will need to get a cert and deploy an HTTPS endpoint. That's has never been discusse

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

On 2011-03-29, at 4:40 PM, Eran Hammer-Lahav wrote: > To clarify, I am not opposed to mandating TLS on the callback, just that if > we do, we can’t ship the protocol the way it is without coming up with some > other alternative that does not require TLS deployment on the client side. > OAuth 1

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

They don't use it because they don't know it's needed.  If they knew that not using it is as dangerous to their users as sending passwords in the clear they would use it.  And I doubt the IETF is going to endorse a protocol that sends credentials in the clear. Francisco --- On Tue, 3/29/11, Er

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

A http redirect_uri that doesn’t address localhost is a security risk. Requiring https is a solution, but with a cost to client apps. Using any http on the web is a security risk. Some sites use https for their login page and http for the content. That is a security risk (eg firesheep). Pe

Re: [OAUTH-WG] Question on scope when refreshing an access token

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Brian Campbell > Sent: Tuesday, March 29, 2011 3:32 PM > To: oauth > Subject: [OAUTH-WG] Question on scope when refreshing an access token > > I'm a bit confused by the text at the end of t

[OAUTH-WG] Proposed change to OAuth parameters registry

I would like to make the following change to section 8.2: New request or response parameters for use with the authorization endpoint or the token endpoint are defined and registered in the parameters registry following the procedure in Section 10.2

[OAUTH-WG] Error extensibility proposal

*** Requirements The following proposal is based on two requirements: 1. Provide a way to return an OAuth error response for error situations other then 400 and 401. For example, if the server is temporarily unavailable, it will return an HTTP 503 status. However, it is often desirable to still

Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

>> OAuth issues security tokens without indicating where they can be safely >> used. While that fatal flaw remains, it is pointless to specify the use of >> the Origin header. > I don't think anything should be in the base as the different token profiles > can stipulate the audience. But t

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

> As a matter of practicality, requiring all clients to deploy > server-side TLS is absurd. If we mandate redirections URIs to use > https, we are basically making everyone ignore it. It’s like a speed > limit sign of 5mph. Why is that?  Can you elaborate?  I'm very puzzled.  And didn't you propos

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

> Isn’t all this just different flavors of a session fixation attacks? > The client should use cookies and the state parameter to ensure the > same user-agent it redirected to the authorization server is the one > coming back. It's not a session fixation attack.  It's just an interception of a cre

[OAUTH-WG] Question on scope when refreshing an access token

I'm a bit confused by the text at the end of the definition of the scope parameter in section 6 on Refreshing an Access Token[1]. It says, "... The requested scope MUST be equal or lesser than the scope originally granted by the resource owner, and if omitted is treated

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Isn’t all this just different flavors of a session fixation attacks? The client should use cookies and the state parameter to ensure the same user-agent it redirected to the authorization server is the one coming back. EHL From: Francisco Corella [mailto:fcore...@pomcor.com] Sent: Tuesday, Marc

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

As a matter of practicality, requiring all clients to deploy server-side TLS is absurd. If we mandate redirections URIs to use https, we are basically making everyone ignore it. It’s like a speed limit sign of 5mph. EHL From: George Fletcher [mailto:gffle...@aol.com] Sent: Tuesday, March 29, 20

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

I agree.    - Francisco --- On Tue, 3/29/11, Phil Hunt wrote: From: Phil Hunt Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt To: "George Fletcher" Cc: fcore...@pomcor.com, "Justin Richer" , "Eran Hammer-Lahav" , "OAuth WG" , "Karen P. Lewison" Date: Tuesday, March 29, 2011,

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

> Can you explain how intercepting the authorization code > without having access to the client credentials is a > problem? For the sake of discussion, assume that the client > has valid and secure credentials that an attacker cannot > access. Also assume that the client has implemented some > form

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

My primary concern is that when the authorization code is handed back to the target app (in this case by way of redirect through a user-agent/browser), then the return path to the browser is at least secure. If the browser/user-agent is redirecting to a local app, then no big deal. BUT, if the

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Hi Francisco, So the examples that Justin gave were either localhost or non HTTP based schemes. If OAuth2 is to support these other schemes (often used in mobile clients) then I'm not sure how TLS can be a MUST unless it's qualified to apply to HTTP based URLs only. Is it sufficient to docum

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Along this same line... To make sure I understand, the attacker must execute a MITM attack against the redirect_uri so that it receives the code value and ensures the code value is never exchanged at the authorization service by the original requester. Then the attacker takes the code and pres

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Can you explain how intercepting the authorization code without having access to the client credentials is a problem? For the sake of discussion, assume that the client has valid and secure credentials that an attacker cannot access. Also assume that the client has implemented some form of cross

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Eran, It's not a reasonable compromise.  #2 MUST use tls UNLESS of course it targets localhost.  If #2 is sent without TLS to a Web server, the authorization code can be easily intercepted by an attacker.  The attacker can then use it to obtain protected resources by submitting the authorizatio

[OAUTH-WG] side meeting on security considerations

If you are in Prague for IETF 80 and would like to discuss the security considerations, please know that I have reserved the "Athens" room tomorrow from 09:00 to 11:30. This room fits only 14 people so please show up only if you want to actively participate in a working session, not if you just wan

Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

> OAuth issues security tokens without indicating where they can be safely > used. While that fatal flaw remains, it is pointless to specify the use of > the Origin header. I don't think anything should be in the base as the different token profiles can stipulate the audience. From: oauth-boun