[OAUTH-WG] Security Considerations Section Proposal

Hi all, I just uploaded a proposal for the security section of the core spec to the IETF site (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-securityconsiderations/). As posted on the list previously, our idea was first to derive a security consideration section for the core spec

Re: [OAUTH-WG] Security Considerations Section Proposal

Hi all, I am very happy that you got a proposal put together to quickly. Thanks for the good writeup! A few comments below. --- 2. Security Considerations Note: This section focuses on the security principles implementors of the protocol MUST consider. These principles

[OAUTH-WG] Presentation slides, please!

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

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

I would like to strongly disagree with this proposal. It amounts to explicitly making OAuth 2.0 insecure so as to satisfy some mysterious and unspecified set of legacy OAuth 1.0 deployments. The SAML web SSO (artifact) profile - which shares many characteristics with the initial steps in OAut

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

A requirement for TLS on the callback would make OAuth prohibitive for many of our developers. The developers are usually volunteers and they are already donating their own resources to help a non-profit (from which US law mandates the developers cannot profit). In other cases the developers are

Re: [OAUTH-WG] Security Considerations Section Proposal

I just uploaded a revised version incorporating most comments we gathered today. http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01 regards, Torsten. Am 31.03.2011 12:08, schrieb Torsten Lodderstedt: Hi all, I just uploaded a proposal for the security section of the

Re: [OAUTH-WG] Security Considerations Section Proposal

Some comments Torsten. Will also think about missing considerations later 2.4. Token Scope I think this should be from the perspective of the Authorization server. e.g. When obtaining end user authorization and where the client requests scope, the authorization server MAY want to consider whether

Re: [OAUTH-WG] Security Considerations Section Proposal

Hi Mark, thank you for your comments: Am 31.03.2011 18:01, schrieb Mark Mcgloin: Some comments Torsten. Will also think about missing considerations later 2.4. Token Scope I think this should be from the perspective of the Authorization server. e.g. When obtaining end user authorization and w

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

It is important to distinguish between securing the resource server and securing the client. I think this is where this conversation has been somewhat broken. If the client is user-agent based or web server based, it MUST user TLS 100% of the time when authenticating its users or delivering any

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

+1 I agree this is not just about setting one TLS setting to mandatory. I believe we need language that is simple and clear. Terms like SHOULD are loopholes that create risk as they are too broad. They also have served to make the security considerations incredibly long and complex since we h

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

Seems like your +1 is for a different conclusion :-) My point is that specifications should reflect reality, not unattained aspirations. That leads to devaluation of the specification and dismissal of other - more important - security requirements. If the majority of members will confirm that t

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

Unfortunately these aren't just "aspirations". We're talking about what are the *necessary* minimums. Yes, I have been focusing on a couple of very specific aspects of authorization and I agree, the whole spec is important. But I disagree that that would be justification not to fix authorizatio

[OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -04

I’ve published draft 04 of the OAuth Bearer Token Specification. All changes were in response to working group last call feedback on draft 03. The changes in this dr

[OAUTH-WG] I-D Action:draft-ietf-oauth-v2-bearer-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : M. Jones, et al. Filename

Re: [OAUTH-WG] OAuth Bearer Token draft

This suggestion has been adopted in draft 04. Thanks all, -- Mike From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Monday, March 21, 2011 11:44 AM To: George Fletcher Cc: Mik

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

I have removed the extension of the OAuth Parameters registry in draft-ietf-oauth-v2-bearer-04, per your feedback Peter. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Saturday,

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

Responses to suggestions not adopted on draft 04 are inline below. Thanks for your input. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, March 23, 2011 1:52 PM

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

Responses to suggestions not adopted are inline below. Thanks for your input. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, March 02, 2011 8:34 AM To: Hannes Tschofe

Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-bearer-03

Responses to suggestions not adopted are inline below. Thanks for your input. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Wednesday, March 02, 2011 7:35 PM To: OAuth Mailing

Re: [OAUTH-WG] editorial comment on section 2 of bearer token draft

This text has been revised accordingly in draft 04. Thanks for the feedback. -- Mike -Original Message- From: Ron Monzillo [mailto:ron.monzi...@oracle.com] Sent: Friday, March 11, 2011 6:35 AM To: OAuth WG; Mike Jones Subject: editorial comment on section

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

Responses to suggestions not adopted on draft 04 are inline below. Thanks for your input. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Wednesday, March 23, 2011 11:11 AM To:

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

> -Original Message- > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Thursday, March 31, 2011 11:19 AM > > Section 2.4: > > > > - ABNF includes '( token "=" ( token / quoted-string ) )', but no prose is > provided about how new parameters may be defined. Retained this > e

Re: [OAUTH-WG] Error extensibility proposal

I object to this proposal on two grounds: First, changing some of the "error" return codes to HTTP numbers is an unnecessary and unsolicited breaking change at a time that we should be stabilizing the spec. Second, the OAuth Errors registry is simpler and follows IETF standard practices. I kn

Re: [OAUTH-WG] Error extensibility proposal

I also object, an error registry the proper approach here. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Thursday, March 31, 2011 11:31 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Error extensibility proposal

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

I think I understand both of your points. Phil is saying that the client must run over HTTPS to be secure so not being able to take an HTTP endpoint is a non-starter anyway. Eran is saying security is a holistic evaluation, and since all secure clients would be HTTPS anyway (as Phil also assert

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

Hi Torsten, > 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? >

[OAUTH-WG] Agenda Update

After a chat with Blaine we have an updated agenda proposal: First, we need to cover our working group items: –draft-ietf-oauth-v2 •Security Consideration Section (Torsten) •Error Code registry (Mike) •Client Assertion Credentials (Mike) •Anything else? –draft-ietf-oauth-v2-bearer •Open issues?

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

Hi Francisco, Am 31.03.2011 20:59, schrieb Francisco Corella: Hi Torsten, > 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 wo

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

Skylar, > So, imagine a website secured inside a corporate > firewall. This service needs to access the provider's > services via OAuth and thus exposes one callback open to the > world for purposes of the OAuth handshake. The redirect URI > is HTTP since the corporation is having trouble acquirin

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

I have to agree. In OAuth, client credentials are dramatically weakened by the number of clients sharing the same credential. If the hacker has the same client with the same credentials (such as the case with mobile client apps), then use of client credentials when exchanging for an access toke

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

Hi Torsten, > > 4.4.1.6 that you reference you propose the following > > countermeasure: > > > > >    o  The authorization server shall require the client to authenticate > > >   with a secret, so the binding of the authorization code to a > > >   certain client can be validated in a relia

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

On 2011-03-31, at 7:32 AM, Skylar Woodward wrote: > A requirement for TLS on the callback would make OAuth prohibitive for many > of our developers. The developers are usually volunteers and they are already > donating their own resources to help a non-profit (from which US law mandates > the

Re: [OAUTH-WG] Agenda Update

To this, I'd like to add discussion of draft-jones-oauth-jwt-bearer -- the JWT equivalent of draft-ietf-oauth-saml2-bearer. In specific, I'd like us to consider taking this up as a working group item. Thanks and see you in the morning! -- Mike -Original Mes

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

Skylar's scenario is not valid even if only one client has the client credential, for the reason explained in my reply to Skylar, below.  Francisco --- On Thu, 3/31/11, Phil Hunt wrote: From: Phil Hunt Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt To: fcore...@pomcor.com Cc: "Sky

Re: [OAUTH-WG] Error extensibility proposal

'PROPER' REQUIRES USE CASES AND REQUIREMENTS! You have to show how the proposal does not satisfy you requirements. It fully satisfies all the requirements presented to the working group. EHL > -Original Message- > From: Anthony Nadalin [mailto:tony...@microsoft.com] > Sent: Thursday, M

Re: [OAUTH-WG] Error extensibility proposal

> -Original Message- > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Thursday, March 31, 2011 11:31 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: Error extensibility proposal > > I object to this proposal on two grounds: > > First, changing some of the "error" retu

Re: [OAUTH-WG] Google launched OAuth 2 v10 support

On Tue, Mar 15, 2011 at 12:43 PM, Torsten Lodderstedt wrote: > Congratulation! > > I've got some questions: > - do you support the token_type parameter for the revocation endpoint? No, we don't. At this point I think our implementations is compliant with your latest draft, I will double check tha

Re: [OAUTH-WG] Flowchart for legs of OAuth

On Wed, Mar 23, 2011 at 12:56 PM, Torsten Lodderstedt wrote: > Hi Phil, > > looks even better now :-) > > As already pointed out > (http://www.ietf.org/mail-archive/web/oauth/current/msg05599.html), "Have > client credentials? No" does not automatically imply usage of implicit > grant. The client

Re: [OAUTH-WG] Flowchart for legs of OAuth

Thanks, I'll put it on the next version. Phil phil.h...@oracle.com On 2011-03-31, at 4:41 PM, Marius Scurtescu wrote: > On Wed, Mar 23, 2011 at 12:56 PM, Torsten Lodderstedt > wrote: >> Hi Phil, >> >> looks even better now :-) >> >> As already pointed out >> (http://www.ietf.org/mail-archi

Re: [OAUTH-WG] Flowchart for legs of OAuth

Done. It isn't quite what the flow shows in the earlier diagram. I was originally avoiding client type and trying to focus on section 4 options. But this should be a better diagram. http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html Phil phil.h...@oracle.com On 2011

[OAUTH-WG] Authorization code security issue (reframed)

(The previous thread is became completely inaccessible to anyone not following it carefully for the past week or so. For the sake of reaching a conclusion, I am going to sum up the issue and try to start over with a more narrow focus.) * The security issue is very simple: The authorization code

Re: [OAUTH-WG] Error extensibility proposal

On 3/30/11 1:01 AM, Eran Hammer-Lahav wrote: > Please send any feedback, comments, support, and objections by 3/1 I think you meant 4/1. :) > (so it can be included or not in -14). Given how busy things are during IETF week, I'm sure that many people who are in Prague for the meeting might not

Re: [OAUTH-WG] Authorization code security issue (reframed)

Sadly, see below. Phil phil.h...@oracle.com On 2011-03-31, at 5:09 PM, Eran Hammer-Lahav wrote: > (The previous thread is became completely inaccessible to anyone not > following it carefully for the past week or so. For the sake of reaching a > conclusion, I am going to sum up the issue an

Re: [OAUTH-WG] Authorization code security issue (reframed)

Thanks Eran. Well put. As one of the original advocates of MUST, I'll offer a bit of background on what we've done/seen in our 1.0a and 2d10 deployments * we only block HTTP (and javascript:). Other schemes not using TLS are allowed * we've seen 1.0 signatures being much harder for developers

Re: [OAUTH-WG] Flowchart for legs of OAuth

On Thu, Mar 31, 2011 at 4:56 PM, Phil Hunt wrote: > Done. > > It isn't quite what the flow shows in the earlier diagram. I was originally > avoiding client type and trying to focus on section 4 options. > > But this should be a better diagram. > > http://independentidentity.blogspot.com/2011/03/o

Re: [OAUTH-WG] Error extensibility proposal

Yeah, 4/1 and it gives people the chance to express their views at the meeting. It's a draft... which is the way this WG has been more effective in getting people's attentions to proposal. I'll include it in -14 and take it out if we have another solution or lack of consensus when I do -15 with

Re: [OAUTH-WG] Error extensibility proposal

On Tue, Mar 29, 2011 at 4:01 PM, Eran Hammer-Lahav wrote: > *** 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 >

Re: [OAUTH-WG] Authorization code security issue (reframed)

The point of this message is to help people choose between the two options, not to promote one over the other. I have tried to present a balanced view, given that a MUST is the easy way out (specification wise) since it moves the problem elsewhere. Not sure what you 'totally disagree' with rega

Re: [OAUTH-WG] OAuth without HTTP redirects

Hi Greg, Google is working on a pure JavaScript flow which does not involve redirects. Marius On Thu, Mar 17, 2011 at 12:20 PM, Greg Brockman wrote: > Hi, > > I notice that the current OAuth2 draft seems to have browser redirects > baked in rather deeply.  Are there any plans to add support f

Re: [OAUTH-WG] Error extensibility proposal

Hi Marius, > -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Thursday, March 31, 2011 6:07 PM > Many error codes (if not most) are not parameter specific. Like what? After a long debate, not a single use case was presented for a new error code that is

Re: [OAUTH-WG] Error extensibility proposal

I have not seen your explanation of why an error registry does not satisfy the requirements as originally proposed in the bearer token. Your proposal recognizes the need to have a registry which is good but then you conflate parameters registry with an error registry, not all errors will be para

Re: [OAUTH-WG] Error extensibility proposal

Maybe I don't understand how you want to deal with errors, sorry if you have to repeat the same argument. Here are a couple of examples. JavaScript clients need to be able to get new access tokens without user interaction (after an initial consent). The solution is to define an immediate mode thr

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

Francisco, correct me if I'm wrong, but in your discussion you assume that the application is incapable of keeping secrets from the public (eg, mobile, desktop apps, etc.). According to the spec, those applications should never receive client credentials to begin with. They can't keep secrets

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

Right, but just so we are clear, the only case you are discussing here is the MITM attack, which George, I and others have recently outlined. I'm not outright opposed to the language requiring TLS for the redirect URI, but the consequence is that some providers may need to find workarounds or (

Re: [OAUTH-WG] Error extensibility proposal

> -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Thursday, March 31, 2011 7:21 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Error extensibility proposal > > Maybe I don't understand how you want to deal with errors, sorry if you

Re: [OAUTH-WG] Error extensibility proposal

> -Original Message- > From: Anthony Nadalin [mailto:tony...@microsoft.com] > Sent: Thursday, March 31, 2011 7:07 PM > To: Eran Hammer-Lahav; Mike Jones; OAuth WG > Subject: RE: Error extensibility proposal > > I have not seen your explanation of why an error registry does not satisfy th

Re: [OAUTH-WG] Agenda Update

new slide for my first part Am 31.03.2011 21:13, schrieb Hannes Tschofenig: After a chat with Blaine we have an updated agenda proposal: First, we need to cover our working group items: –draft-ietf-oauth-v2 •Security Consideration Section (Torsten) •Error Code registry (Mike) •Client Assertion