Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17E621F8516 for ; Fri, 6 Jan 2012 23:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.266 X-Spam-Level: X-Spam-Status: No, score=-17.266 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvkEy8SMQ8ee for ; Fri, 6 Jan 2012 23:22:21 -0800 (PST) Received: from nm1.bullet.mail.sp2.yahoo.com (nm1.bullet.mail.sp2.yahoo.com [98.139.91.71]) by ietfa.amsl.com (Postfix) with SMTP id 289D121F850F for ; Fri, 6 Jan 2012 23:22:20 -0800 (PST) Received: from [98.139.91.65] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jan 2012 07:22:13 -0000 Received: from [98.139.91.31] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jan 2012 07:22:13 -0000 Received: from [127.0.0.1] by omp1031.mail.sp2.yahoo.com with NNFMP; 07 Jan 2012 07:22:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 940096.26433.bm@omp1031.mail.sp2.yahoo.com Received: (qmail 46217 invoked by uid 60001); 7 Jan 2012 07:22:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325920933; bh=V55S2marW7ULWcP5dT4seUFjGy8xy7lj3BQN738r6Y0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=mmeM8nIytk2VZZ8AWkLu/B7xeFMqzogomgHOxsH+aJEClFXciSvEmCACpHjADekt2F+RO6lZrLI9qqAuLKWgD/i/KQlal4c/T0ZgzSQmpl24SLoGJNExM3bL7oPXDT8bWZUvNzAnbK1x/J7sE7Id9S3bdcHEDTecQFhcp/IXuVY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=GSB+gJqsvhvQaRMUrLzVQhWFwNDJOMOxmePQ7ER4bye0OXYRhbUa1gZI/eURit6DH8D1IZyiO6b9EJaBmk5lDHhI0vBNx/5OXyLjhxDZErDFaes053toUh5gwOYpBVW5mWaAQUZIYLLYdmwwzQ0FE0Rey/2OC0W3qk1fhAOxyuk=; X-YMail-OSG: UjEEK98VM1kvqLg3a_wwxiqb3dzHI7DYFGR4H7WikgWSZrS aArOLhZbHt06i5FxWvXN4Q86Cfcn0Ly9mU2fiOL7Tsa_rkH8u2cMQ02Q3W78 LwPZLZRqysTOqcGPwNaNl6qWDUp0sw0Zbf8fBu8AflLkncnFvb8t04w30QQG B.xpmXCfci._s7JvOW2wCkC3TcWKdiz8LVoUGiCz7Ru8gl7uK8KwqY01Oa_s lG68Uwe3mUH4fiZDhxjpCxuNrO1xuMuek5s8z2yxPMPsKHPUOa.PqUT7GNny qLvsMuob9L3ri1svN9WUVWV4UXxszwnjYhjMwJEq9gls7jqlB8vY4CIs4cuL i0vSsPzEsJbGyF1J6Y3hViMweg1_3p1gu3ERAKcah.j6Qgb2X9TemeJV_09r II7kpV_kWDf_97XGs6hy.Q529xQ-- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Fri, 06 Jan 2012 23:22:13 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4E6E4FEA.7090100@sunet.se> <90C41DD21FB7C64BB94121FBBC2E72345213D92D5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453A72D0C2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1325920933.19255.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Fri, 6 Jan 2012 23:22:13 -0800 (PST) From: William Mills To: Eran Hammer-Lahav , "eran@sled.com" , Leif Johansson , OAuth WG In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A72D0C2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1501530307-1325920933=:19255" Subject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 07:22:23 -0000 --835683298-1501530307-1325920933=:19255 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think the only thing there I'd say might still want to get done is:=0A=0A= > > 10.10 Credentials Guessing Attack=0A> >=0A> > I found myself wanting im= plementation advice for how to generate good=0A> > tokens at this point. Th= is has been raised on the list too. The same=0A> > goes for how to generate= good CSRF cookies where the "(eg a hash of=0A> > the session cookie..." fe= els like it is implementation advice yearning=0A> > to come out of the clos= et.=0A>=0A> Need someone to suggest text.=0A=0ADidn't we get CSRF text in t= here?=0A=0A=0A=0A________________________________=0A From: Eran Hammer-Laha= v =0ATo: "eran@sled.com" ; Leif Johanss= on ; OAuth WG =0ASent: Friday, January 6, = 2012 10:57 PM=0ASubject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v= 2=0A =0AI have not seen any follow up to the open issues and will be closin= g them on my editor's list. This doesn't mean they are closed, just that I = will not be addressing them without someone raising them again on the list.= Since none of them are in the tracker, this email is the only record I kno= w of listing them (and their status/response).=0A=0AEHL=0A=0A> -----Origina= l Message-----=0A> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.= org] On Behalf=0A> Of Eran Hammer-Lahav=0A> Sent: Tuesday, September 20, 20= 11 3:13 PM=0A> To: Leif Johansson; OAuth WG=0A> Subject: Re: [OAUTH-WG] sec= dir review of draft-ietf-oauth-v2=0A>=0A> (+OAuth WG, -everyone else)=0A>= =0A> Thanks Leif.=0A>=0A> See comments inline. Whatever issues are still op= en will be addressed along=0A> with the rest of the IETF LC feedback.=0A>= =0A> EHL=0A>=0A>=0A> > -----Original Message-----=0A> > From: Leif Johansso= n [mailto:leifj@sunet.se]=0A> > Sent: Monday, September 12, 2011 11:31 AM= =0A>=0A> > ** General observations:=0A> >=0A> > POST and/or GET=0A> >=0A> >= Examples are sometimes POST and sometimes GET. In many cases it is not=0A>= > clear to me from the surrounding text if both POST and GET are allowed= =0A> > or if only one is mandated. Illustrating with both a GET _and_ POST= =0A> > example in the cases where both are supported would help or make the= =0A> > method explicit in the text before the example.=0A> >=0A> > The P-wo= rd=0A> >=0A> > The term 'password' is sprinkled throughout the document, so= metimes as=0A> > in "client password" or "resource owner password credentia= ls" and I=0A> > suspect that sometimes it is password as in 'an example of = a=0A> > credential type' and in other cases it is password as in 'plain old= =0A> > password'. This needs to be cleared up throughout (I've included som= e=0A> examples below).=0A> >=0A> > Normative Language=0A> >=0A> > I've ofte= n found myself wanting more normative language often to=0A> > replace exist= ing but less precise text. I've called out some important cases=0A> below.= =0A> >=0A> > Unknown parameters=0A> >=0A> > The sentence "The client SHOULD= ignore unrecognized response=0A> > parameters"=0A> > occurs in several pla= ces. First of all I would argue that this has to=0A> > be a MUST if you wan= t to be able to guarantee extensibility. Secondly=0A> > there are some erro= r responses that are triggered by unsupported=0A> > request parameters. Thi= s seems like an inconsistency.=0A> >=0A> > ** Specifics=0A> >=0A> > 1.1 Rol= es=0A> >=0A> > Forward references to the sections where the roles are defin= ed would=0A> > improve readability.=0A>=0A> What sections? That's the only = place these roles are defined.=0A>=0A> > As an illustration of an alternati= ve model for the authorization=0A> > server maybe an informative reference = to UMA would be illustrative here.=0A>=0A> A reference to UMA would be conf= using in this document.=0A>=0A> > 1.2 Protocol Flow=0A> >=0A> > (A) talks a= bout 'an intermediary such as an authorization server.' it=0A> > isn't clea= r it me if this refers to a separate authorization server or=0A> > if it is= the same authorization server that is referenced in (B).=0A>=0A> Changed t= o:=0A>=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 (A) The client requests authorizatio= n from the resource owner. The=0A> authorization request=0A>=A0 =A0 =A0 =A0= =A0 =A0 =A0 can be made directly to the resource owner (as shown), or pre= ferably=0A> indirectly via=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 the authorizatio= n server as an intermediary.=0A>=0A> > 1.3.3 Resource Owner Password Creden= tials=0A> >=0A> > When I first read this I thought - why not talk about Res= ource Owner=0A> > Credentials - in fact there is a parenthesis there "(e.g = a username=0A> > and password)" that seems to indicate that other credentia= ls could be=0A> supported.=0A> >=0A> > This needs to be cleared up. Either = its username and password and=0A> > nothing else or there is a way to suppo= rt things like Negotiate or=0A> > X.509-based credentials in which case it = should really be Resource=0A> > Owner Credentials with no reference to pass= words other than as as an=0A> > example of one possible credential type.=0A= >=0A> Changed to:=0A>=0A>=A0 =A0 =A0 =A0 (i.e. username and password)=0A>= =0A> This is explicitly just for username and password. Other types require= an=0A> extension.=0A>=0A> > 1.4 Access Token=0A> >=0A> > first paragraph: = "The string is usually opaque". This should be=0A> > reformulated as normat= ive language. In fact I would have liked=0A> > guidance on generating those= tokens (which has been brought up on the=0A> > list) possibly as part of a= n implementation-guide.=0A>=0A> There is not requirement for the string to = be opaque, but the general=0A> architecture assumes it is. Otherwise, pleas= e suggest language.=0A>=0A> > 1.5 Refresh Token=0A> >=0A> > Why is the refr= esh token not simply treated as an access token for the=0A> > access token = resource in the authorization server? This would seem to=0A> > simplify the= model a bit by removing a type of token whose semantic=0A> > (at least to = this=0A> > reviewer) is a duplication of a normal access token for a partic= ular=0A> > type of resource.=0A>=0A> Simpler architecture but probably more= confusing to many developers.=0A>=0A> > Also in the first paragraph: "(acc= ess tokens may have a shorter=0A> > lifetime and fewer permissions". Why no= t try to write normative=0A> > language here - there are security implicati= ons of allowing a refresh=0A> > token to get more permissions=0A> > (say) t= han the original access token.=0A>=0A> This was discussed before and we cou= ld not reach consensus.=0A>=0A> > 2.1 Client types=0A> >=0A> > I find the t= erminology public/confidential somewhat counter-intuitive.=0A> > An app you= have on your personal device is 'public' while a shared=0A> > cloud servic= e is 'confidential'...hmm...=0A>=0A> These are the best terms we could come= up with. Not intuitive but well=0A> defined.=0A>=0A> > This section also l= acks normative language which isn't good. There=0A> > should be language de= fining the behavior of public and confidential=0A> > client aswell as the t= hree profiles.=0A> >=0A> > For instance under native application we have "I= t is assumed that any=0A> > client authentication credentials included in t= he application can be=0A> > extracted". This should really be normative lan= guage. Some of what I=0A> > am looking for can be found in section 2.3 but = it isn't clear to me=0A> > that it covers the definition of the profiles.= =0A>=0A> Please suggest text.=0A>=0A> > 2.3.1 Client Password=0A> >=0A> > T= here is also some confusion here about what the client must implement=0A> >= and what the server must implement wrt the use of client_id. I read=0A> > = the text as trying to say that Servers SHOULD support both and clients=0A> = > SHOULD only do Basic.=0A>=0A> We could not reach consensus beyond this. T= his language was carefully=0A> crafted to work around the disagreements abo= ut what is required and what=0A> is not.=0A>=0A> > This section also seems = to have been the product of a partial=0A> > s/password/credential/g operati= on. Either OAUTH is only meant to use=0A> > Basic and passwords or we want = to cover all/most HTTP authentication=0A> > methods and credentials and the= n section 2.3.2 (which feels like an=0A> > afterthought) needs to get folde= d into 2.3.1 and the normative=0A> > language (and examples!) need some wor= k to cover at least X.509s and=0A> > perhaps even Negotiate.=0A>=0A> When w= e say password we mean 'plain old password'. Any other types of=0A> credent= ials are not covered by design.=0A>=0A> > Personally I would try to fold 2.= 3.1 and 2.3.2 into one section and=0A> > say that servers MUST support Basi= c and client_id+client_password.=0A> > Servers MAY support any HTTP authent= ication method with a mapping to=0A> client_id.=0A> > If a client supports = username+passwords it SHOULD do Basic and if it=0A> > supports other HTTP a= uthentication methods it MUST NOT use=0A> > client_password for anything an= d MUST follow normal HTTP=0A> > authentication method negotiation.=0A> >=0A= > > Finally, everywhere there is negotiation there must imho be some=0A> > = mention/discussion/protection of downgrade attacks.=0A>=0A> Downgrade attac= ks security section sounds useful. Text?=0A>=0A> > 3.1 Authorization Endpoi= nts=0A> >=0A> > 6th paragraph: "The authorization server SHOULD ignore unre= cognized=0A> > request parameters". This formulation returns in several pla= ces in the=0A> > document and I don't understand why it isn't a MUST - afte= r all=0A> > doesn't extensibility depend on this?=0A>=0A> I don't have an o= bjection, but extensibility isn't currently required.=0A>=0A> > 3.1.1 Respo= nse Type=0A> >=0A> > The response_type parameter is REQURED but its absence= SHOULD result=0A> > in an error. Why not MUST?=0A>=0A> This is an OAuth 1.= 0 legacy of not mandating a particular error behavior.=0A> MUST seems like = the right language - any objections?=0A>=0A> > 3.1.2 Redirection Endpoint= =0A> >=0A> > There should be a clear normative specification for how to=A0 = match=0A> endpoints.=0A> > There are traces of this in various parts of the= document when=0A> > matching is discussed. I recommend making a concise de= finition in one=0A> > place (namely=0A> > here) and referencing this throug= hout. Since this comparison has=0A> > security implications it should be a = priority for the specification to be air-=0A> tight.=0A>=0A> This has been = discussed by the WG and no consensus was reached. We can=0A> reconsider if = someone submits proposed text.=0A>=0A> > 3.1.2.2 Registration Requirements= =0A> >=0A> > "(the client MAY use the state request parameter to achieve=0A= > > per-request customization)". Doesn't this overload its use for CSRF-=0A= > protection?=0A>=0A> Yep. That's intentional.=0A>=0A> > 3.1.2.4 Invalid En= dpoint=0A> >=0A> > "The authorization server SHOULD NOT redirect...". Why i= sn't this a=0A> > MUST NOT?=0A>=0A> I'm ok with MUST NOT - any objections?= =0A>=0A> > 3.1.2.5 Endpoint Content=0A> >=0A> > This section basically seem= s to say "Serve with server-side code not=0A> > with html or client-side co= de". If this is the case then I suggest=0A> > reformulate to say precisely = that using normative language.=0A> >=0A> > The use of the word "script" cou= ld perhaps also be made less ambiguous=0A> > since in this case it could re= fer to both server-side code aswell as=0A> > in-browser code.=0A>=0A> This = is only about the HTML response sent back to the user-agent. This is=0A> ab= out including something like 'Share on Twitter/Facebook' widget on a page= =0A> with an access token in the URI fragment (which has caused tokens to l= eak to=0A> Twitter in some cases).=0A>=0A> > 3.2.1 Client Authentication=0A= > >=0A> > The phrase "clients issued client credentials" could be rephrased= to=0A> > make less violence on English - perhaps "clients that have been i= ssued=0A> > with client credentials", unless that is not the intended meani= ng in=0A> > which case I argue for something easier to understand ;-)=0A>= =0A> Ok.=0A>=0A> > The second bullet: Using client credentials more often a= lso exposes=0A> > them more which might be worth mentioning aswell.=0A>=0A>= Proposed text?=0A>=0A> > 4. Obtaining Authorization=0A> >=0A> > Perhaps no= t critical but the term 'password credentials' occurs in the=0A> > first pa= ragraph and this doesn't seem compatible with resource owner=0A> > authenti= cation being out of scope. It could just be that it should=0A> > read 'reso= urce owner credentials' but it could also signal an=0A> > underlying assump= tion about username and password being used for=0A> > resource owner authen= tication. In either case I thing its best to=0A> > avoid the use of the wor= d 'password' to avoid any confusion.=0A>=0A> Password is intentional. This = is a special case for passwords.=0A>=0A> > 4.1 Authorization Code=0A> >=0A>= > (C) - "using the redirection URI provided earlier" should perhaps read= =0A> > "using the redirection URI provided earlier or associated with the= =0A> > client in client registration"=0A>=0A> Changed to:=0A>=0A>=A0 =A0 = =A0 =A0 =A0 =A0 =A0 Assuming the resource owner grants access, the authori= zation server=0A> redirects the=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 user-agent = back to the client using the redirection URI provided earlier=0A> (in the= =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 request or during client registration). Th= e redirection URI includes an=0A> authorization=0A>=A0 =A0 =A0 =A0 =A0 =A0 = =A0 code and any local state provided by the client earlier.=0A>=0A> > 4.1= .1 and 4.1.2 Authorization Request/Authorization Response=0A> >=0A> > The r= edirect_uri is listed as OPTIONAL with a reference to 3.1.2 but=0A> > there= is no mention in 4.1.2 how to handle the case when the=0A> > redirect_uri = is not present. I believe the assumption is that the=0A> > redirect_uri is = either resent or part of client registration but that needs to=0A> be made = explicit in that case.=0A>=0A> 3.1.2 describe how to handle this parameter.= =0A>=0A> > This may apply to other uses of the redirect_uri parameter eg in= 4.2.1.=0A> >=0A> > Furthermore in 4.2.2 "code" I suggest the following re-= formulatation=0A> > of the last sentence: "The client MUST NOT use an autho= rization code=0A> > for more than one request. If an authorization code is = re-used, the=0A> > authorization server should treat that as a replay attac= k and SHOULD=0A> > revoke all tokens associated with the client." (i.e loos= e the "attempt"=0A> > bit which carries no real meaning)=0A>=0A> Changed to= server MUST not allow reuse based on previous feedback. Not=0A> sure treat= ing it as an attack is the right language, but the normative language=0A> i= s the same either way (about revoking tokens).=0A>=0A> > Also note that thi= s is potentially a DOS attack should a single authz code=0A> leak.=0A>=0A> = Explain?=0A>=0A> > 4.1.2.1 Error Response=0A> >=0A> > First paragraph, last= sentence "and MUST NOT automatically redirect".=0A> > In the light of how = willing users normally are to click on links=0A> > presented to them I woul= d strengthen this to "MUST prevent the user=0A> > from following the redire= ct URI"=0A>=0A> Not sure what you mean.=0A>=0A> > In the definition of the = invalid_request parameter I don't understand=0A> > how unsupported paramete= rs can generate an error since endpoints=0A> > should ignore unsupported pa= rameters (in order to support extensibility).=0A>=0A> Good catch. Dropped '= unsupported parameter' part.=0A>=0A> > 4.1.3 Access Token Request=0A> >=0A>= > "require client authentication for confidential clients or for any=0A> >= client issued client credentials (or with other authentication requirement= s)"=0A> >=0A> > This text seems unnecessarily convoluted. Isn't enough to s= ay that if=0A> > you have issued credentials to a client you MUST require= =0A> > authentication from that client? This applies equally to the other= =0A> > sections where client authentication is an issue (eg 4.3.2).=0A>=0A>= I felt it was important to call out confidential clients explicitly, but I= agree that=0A> if we require issuing credentials to such clients, this can= be made simpler.=0A> What do other think? The same end result, but differe= nt emphasis.=0A>=0A> > Also cf my comment on 3.1.2 for the discussion of ma= tching=0A> > redirect_uri in the last bullet: ".. and that their values are= =0A> > identical". Is this really meant to mean identical?=0A>=0A> Here yes= . String comparison.=0A>=0A> > 4.2 Implicit Grant=0A> >=0A> > The parenthes= is "(it does not support the issuance of refresh tokens)"=0A> > sounds like= it should really be normative language, "refresh tokens=0A> > MUST NOT be = issues for implicit grant" because afaiu you could easily=0A> > extend "fra= gment-transport" to include a refresh-token, so it isn't a=0A> > technicall= y motivated constraint, right?=0A>=0A> Instead I added this to 4.2.2:=0A>= =0A>=A0 =A0 =A0 =A0 =A0 =A0 The authorization server MUST NOT issue a refr= esh token.=0A>=0A> > In (D) I would like to have a normative reference to a= document that=0A> > specifies browser behavior for URL fragments since thi= s is a critical=0A> > security dependency for this grant type.=0A>=0A> That= 's RFC2616. Seems odd to reference it here.=0A>=0A> > 4.4 Client Credential= s=0A> >=0A> > I think the text should note that this model effectively impl= ies that=0A> > the client is able to impersonate all users which has the po= tential=0A> > for worse security problems than if the client has access to = individual user=0A> passwords.=0A>=0A> Worse how? You can't use this with r= esource owner password.=0A>=0A> > 6 Refreshing an Access Token=0A> >=0A> > = scope - The term "lesser than" is intuitive but imprecise. I suggest=0A> > = "MUST NOT include any scope not originally granted by the resource=0A> owne= r".=0A>=0A> Ok.=0A>=0A> > 7.1 and 8.1 Access Token Types=0A> >=0A> > The se= ction 7.1 lists two definitions of access token types and=0A> > provides a = couple of examples but doesn't provide any constraints on=0A> > future deve= lopment of access tokens except in 8.1 where it is implied=0A> > that not a= ll access token types would be associated with HTTP=0A> > authentication me= chanisms. Are there really no constraints on access=0A> > token types that = should be captured?=0A>=0A> None suggested.=0A>=0A> > 10.6 Authorization Co= de Redirection URI Manipulation=0A> >=0A> > Suggest replace the word 'famil= iar' with 'trusted' in the first=0A> > sentence of the second paragraph. Th= e notion of trust opens up several=0A> > boat loads of worm but it is the c= orrect term here I think.=0A>=0A> Ok.=0A>=0A> > In the third paragraph "the= same as" wrt redirection URIs occur and=0A> > this needs to be defined (cf= comments on 3.1.2 above).=0A>=0A> Changed to identical.=0A>=0A> > Finally = "The authorization server MUST require public clients and=0A> > SHOULD requ= ire confidential clients to register their redirection=0A> > URI". I am mis= sing a discussion of why the two types of client differ wrt this=0A> attack= vector.=0A>=0A> Public clients rely on the registration to provide a minim= al level of client=0A> identification while confidential clients are later = authenticated which can=0A> mitigate redirection URI manipulation.=0A>=0A> = > 10.10 Credentials Guessing Attack=0A> >=0A> > I found myself wanting impl= ementation advice for how to generate good=0A> > tokens at this point. This= has been raised on the list too. The same=0A> > goes for how to generate g= ood CSRF cookies where the "(eg a hash of=0A> > the session cookie..." feel= s like it is implementation advice yearning=0A> > to come out of the closet= .=0A>=0A> Need someone to suggest text.=0A>=0A> EHL=0A>=0A> _______________= ________________________________=0A> OAuth mailing list=0A> OAuth@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/oauth=0A________________________= _______________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www= .ietf.org/mailman/listinfo/oauth --835683298-1501530307-1325920933=:19255 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think the only thing there I'd say might still want to get done is:

> > 10.10 Credentials Guess= ing Attack
> >
> > I found myself wanting implementation = advice for how to generate good
> > tokens at this point. This has= been raised on the list too. The same
> > goes for how to generat= e good CSRF cookies where the "(eg a hash of
> > the session cooki= e..." feels like it is implementation advice yearning
> > to come = out of the closet.
>
> Need someone to suggest text.
=
Didn't we get CSRF text in there?

=
From: Eran H= ammer-Lahav <eran@hueniverse.com>
To: "eran@sled.com" <eran@sled.com>; Leif Johansson= <leifj@sunet.se>; OAuth WG <oauth@ietf.org>
Sent: Friday, January 6, 2012 10:57 PM<= br> Subject: Re: [OAUTH-WG= ] secdir review of draft-ietf-oauth-v2
=0AI have not seen a= ny follow up to the open issues and will be closing them on my editor's lis= t. This doesn't mean they are closed, just that I will not be addressing th= em without someone raising them again on the list. Since none of them are i= n the tracker, this email is the only record I know of listing them (and th= eir status/response).

EHL

> -----Original Message-----
= > From: oauth-bounces@ietf.org [mailto:oauth-bounc= es@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Tuesd= ay, September 20, 2011 3:13 PM
> To: Leif Johansson; OAuth WG
>= Subject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2
>
&g= t; (+OAuth WG, -everyone else)
>
> Thanks Leif.
>
>= See comments inline. Whatever issues are still open will be addressed along
> with the rest of the IETF LC feedback.
><= br>> EHL
>
>
> > -----Original Message-----
>= > From: Leif Johansson [mailto:leifj@sunet.se]
> > Sent: Monday, = September 12, 2011 11:31 AM
>
> > ** General observations:> >
> > POST and/or GET
> >
> > Examples= are sometimes POST and sometimes GET. In many cases it is not
> >= clear to me from the surrounding text if both POST and GET are allowed
= > > or if only one is mandated. Illustrating with both a GET _and_ PO= ST
> > example in the cases where both are supported would help or= make the
> > method explicit in the text before the example.
&= gt; >
> > The P-word
> >
> > The term 'passwo= rd' is sprinkled throughout the document, sometimes as
> > in "client password" or "resource owner password credentials" and I
> &= gt; suspect that sometimes it is password as in 'an example of a
> &g= t; credential type' and in other cases it is password as in 'plain old
&= gt; > password'. This needs to be cleared up throughout (I've included s= ome
> examples below).
> >
> > Normative Language> >
> > I've often found myself wanting more normative lan= guage often to
> > replace existing but less precise text. I've ca= lled out some important cases
> below.
> >
> > Unkn= own parameters
> >
> > The sentence "The client SHOULD ig= nore unrecognized response
> > parameters"
> > occurs in = several places. First of all I would argue that this has to
> > be= a MUST if you want to be able to guarantee extensibility. Secondly
>= > there are some error responses that are triggered by unsupported
> > request parameters. This seems like an inconsiste= ncy.
> >
> > ** Specifics
> >
> > 1.1 R= oles
> >
> > Forward references to the sections where the= roles are defined would
> > improve readability.
>
> = What sections? That's the only place these roles are defined.
>
&g= t; > As an illustration of an alternative model for the authorization> > server maybe an informative reference to UMA would be illustrati= ve here.
>
> A reference to UMA would be confusing in this docu= ment.
>
> > 1.2 Protocol Flow
> >
> > (A) = talks about 'an intermediary such as an authorization server.' it
> &= gt; isn't clear it me if this refers to a separate authorization server or<= br>> > if it is the same authorization server that is referenced in (= B).
>
> Changed to:
>
>              (A) The client requests authorization from th= e resource owner. The
> authorization request
>    &n= bsp;         can be made directly to the resource owne= r (as shown), or preferably
> indirectly via
>    &nb= sp;         the authorization server as an intermediar= y.
>
> > 1.3.3 Resource Owner Password Credentials
> &= gt;
> > When I first read this I thought - why not talk about Reso= urce Owner
> > Credentials - in fact there is a parenthesis there = "(e.g a username
> > and password)" that seems to indicate that ot= her credentials could be
> supported.
> >
> > This = needs to be cleared up. Either its username and password and
> > n= othing else or there is a way to support things like Negotiate or
> &= gt; X.509-based credentials in which case it should really be Resource
> > Owner Credentials with no reference to passwords oth= er than as as an
> > example of one possible credential type.
&= gt;
> Changed to:
>
>        (i.e. u= sername and password)
>
> This is explicitly just for username = and password. Other types require an
> extension.
>
> >= ; 1.4 Access Token
> >
> > first paragraph: "The string i= s usually opaque". This should be
> > reformulated as normative la= nguage. In fact I would have liked
> > guidance on generating thos= e tokens (which has been brought up on the
> > list) possibly as p= art of an implementation-guide.
>
> There is not requirement fo= r the string to be opaque, but the general
> architecture assumes it = is. Otherwise, please suggest language.
>
> > 1.5 Refresh To= ken
> >
> > Why is the refresh token not simply treated as an access token for the
> > access token resource in t= he authorization server? This would seem to
> > simplify the model= a bit by removing a type of token whose semantic
> > (at least to= this
> > reviewer) is a duplication of a normal access token for = a particular
> > type of resource.
>
> Simpler archite= cture but probably more confusing to many developers.
>
> > = Also in the first paragraph: "(access tokens may have a shorter
> >= ; lifetime and fewer permissions". Why not try to write normative
> &= gt; language here - there are security implications of allowing a refresh> > token to get more permissions
> > (say) than the origi= nal access token.
>
> This was discussed before and we could no= t reach consensus.
>
> > 2.1 Client types
> >
&g= t; > I find the terminology public/confidential somewhat counter-intuitive.
> > An app you have on your personal device is= 'public' while a shared
> > cloud service is 'confidential'...hmm= ...
>
> These are the best terms we could come up with. Not int= uitive but well
> defined.
>
> > This section also lac= ks normative language which isn't good. There
> > should be langua= ge defining the behavior of public and confidential
> > client asw= ell as the three profiles.
> >
> > For instance under nat= ive application we have "It is assumed that any
> > client authent= ication credentials included in the application can be
> > extract= ed". This should really be normative language. Some of what I
> > = am looking for can be found in section 2.3 but it isn't clear to me
>= > that it covers the definition of the profiles.
>
> Please= suggest text.
>
> > 2.3.1 Client Password
> >
> > There is also some confusion here about what the client = must implement
> > and what the server must implement wrt the use = of client_id. I read
> > the text as trying to say that Servers SH= OULD support both and clients
> > SHOULD only do Basic.
>> We could not reach consensus beyond this. This language was carefully=
> crafted to work around the disagreements about what is required an= d what
> is not.
>
> > This section also seems to have= been the product of a partial
> > s/password/credential/g operati= on. Either OAUTH is only meant to use
> > Basic and passwords or w= e want to cover all/most HTTP authentication
> > methods and crede= ntials and then section 2.3.2 (which feels like an
> > afterthough= t) needs to get folded into 2.3.1 and the normative
> > language (= and examples!) need some work to cover at least X.509s and
> > perhaps even Negotiate.
>
> When we say password we mean = 'plain old password'. Any other types of
> credentials are not covere= d by design.
>
> > Personally I would try to fold 2.3.1 and = 2.3.2 into one section and
> > say that servers MUST support Basic= and client_id+client_password.
> > Servers MAY support any HTTP a= uthentication method with a mapping to
> client_id.
> > If a= client supports username+passwords it SHOULD do Basic and if it
> &g= t; supports other HTTP authentication methods it MUST NOT use
> > = client_password for anything and MUST follow normal HTTP
> > authe= ntication method negotiation.
> >
> > Finally, everywhere= there is negotiation there must imho be some
> > mention/discussi= on/protection of downgrade attacks.
>
> Downgrade attacks secur= ity section sounds useful. Text?
>
> > 3.1 Authorization Endpoints
> >
> > 6th paragraph: "The auth= orization server SHOULD ignore unrecognized
> > request parameters= ". This formulation returns in several places in the
> > document = and I don't understand why it isn't a MUST - after all
> > doesn't= extensibility depend on this?
>
> I don't have an objection, b= ut extensibility isn't currently required.
>
> > 3.1.1 Respo= nse Type
> >
> > The response_type parameter is REQURED b= ut its absence SHOULD result
> > in an error. Why not MUST?
>= ;
> This is an OAuth 1.0 legacy of not mandating a particular error b= ehavior.
> MUST seems like the right language - any objections?
&g= t;
> > 3.1.2 Redirection Endpoint
> >
> > There = should be a clear normative specification for how to  match
> en= dpoints.
> > There are traces of this in various parts of the document when
> > matching is discussed. I recommend making a= concise definition in one
> > place (namely
> > here) an= d referencing this throughout. Since this comparison has
> > secur= ity implications it should be a priority for the specification to be air-> tight.
>
> This has been discussed by the WG and no cons= ensus was reached. We can
> reconsider if someone submits proposed te= xt.
>
> > 3.1.2.2 Registration Requirements
> >
= > > "(the client MAY use the state request parameter to achieve
&g= t; > per-request customization)". Doesn't this overload its use for CSRF= -
> protection?
>
> Yep. That's intentional.
>
&= gt; > 3.1.2.4 Invalid Endpoint
> >
> > "The authorizat= ion server SHOULD NOT redirect...". Why isn't this a
> > MUST NOT?=
>
> I'm ok with MUST NOT - any objections?
>
> > 3.1.2.5 Endpoint Content
> >
= > > This section basically seems to say "Serve with server-side code = not
> > with html or client-side code". If this is the case then I= suggest
> > reformulate to say precisely that using normative lan= guage.
> >
> > The use of the word "script" could perhaps= also be made less ambiguous
> > since in this case it could refer= to both server-side code aswell as
> > in-browser code.
>> This is only about the HTML response sent back to the user-agent. Th= is is
> about including something like 'Share on Twitter/Facebook' wi= dget on a page
> with an access token in the URI fragment (which has = caused tokens to leak to
> Twitter in some cases).
>
> &g= t; 3.2.1 Client Authentication
> >
> > The phrase "client= s issued client credentials" could be rephrased to
> > make less violence on English - perhaps "clients that have been issued
> = > with client credentials", unless that is not the intended meaning in> > which case I argue for something easier to understand ;-)
&g= t;
> Ok.
>
> > The second bullet: Using client credent= ials more often also exposes
> > them more which might be worth me= ntioning aswell.
>
> Proposed text?
>
> > 4. Obt= aining Authorization
> >
> > Perhaps not critical but the= term 'password credentials' occurs in the
> > first paragraph and= this doesn't seem compatible with resource owner
> > authenticati= on being out of scope. It could just be that it should
> > read 'r= esource owner credentials' but it could also signal an
> > underly= ing assumption about username and password being used for
> > reso= urce owner authentication. In either case I thing its best to
> > avoid the use of the word 'password' to avoid any confusio= n.
>
> Password is intentional. This is a special case for pass= words.
>
> > 4.1 Authorization Code
> >
> >= ; (C) - "using the redirection URI provided earlier" should perhaps read> > "using the redirection URI provided earlier or associated with t= he
> > client in client registration"
>
> Changed to:<= br>>
>              Assuming t= he resource owner grants access, the authorization server
> redirects= the
>              user-agent ba= ck to the client using the redirection URI provided earlier
> (in the=
>              request or during= client registration). The redirection URI includes an
> authorizatio= n
>              code and any local state provided by the client earlier.
>
> > 4.1.1= and 4.1.2 Authorization Request/Authorization Response
> >
>= ; > The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but=
> > there is no mention in 4.1.2 how to handle the case when the<= br>> > redirect_uri is not present. I believe the assumption is that = the
> > redirect_uri is either resent or part of client registrati= on but that needs to
> be made explicit in that case.
>
>= 3.1.2 describe how to handle this parameter.
>
> > This may= apply to other uses of the redirect_uri parameter eg in 4.2.1.
> >= ;
> > Furthermore in 4.2.2 "code" I suggest the following re-formu= latation
> > of the last sentence: "The client MUST NOT use an aut= horization code
> > for more than one request. If an authorization= code is re-used, the
> > authorization server should treat that as a replay attack and SHOULD
> > revoke all tokens associat= ed with the client." (i.e loose the "attempt"
> > bit which carrie= s no real meaning)
>
> Changed to server MUST not allow reuse b= ased on previous feedback. Not
> sure treating it as an attack is the= right language, but the normative language
> is the same either way = (about revoking tokens).
>
> > Also note that this is potent= ially a DOS attack should a single authz code
> leak.
>
>= Explain?
>
> > 4.1.2.1 Error Response
> >
> = > First paragraph, last sentence "and MUST NOT automatically redirect".<= br>> > In the light of how willing users normally are to click on lin= ks
> > presented to them I would strengthen this to "MUST prevent = the user
> > from following the redirect URI"
>
> Not = sure what you mean.
>
> > In the definition of the invalid_request parameter I don't understand
> > how unsupported = parameters can generate an error since endpoints
> > should ignore= unsupported parameters (in order to support extensibility).
>
>= ; Good catch. Dropped 'unsupported parameter' part.
>
> > 4.= 1.3 Access Token Request
> >
> > "require client authenti= cation for confidential clients or for any
> > client issued clien= t credentials (or with other authentication requirements)"
> >
= > > This text seems unnecessarily convoluted. Isn't enough to say tha= t if
> > you have issued credentials to a client you MUST require<= br>> > authentication from that client? This applies equally to the o= ther
> > sections where client authentication is an issue (eg 4.3.= 2).
>
> I felt it was important to call out confidential client= s explicitly, but I agree that
> if we require issuing credentials to such clients, this can be made simpler.
> What do oth= er think? The same end result, but different emphasis.
>
> >= Also cf my comment on 3.1.2 for the discussion of matching
> > re= direct_uri in the last bullet: ".. and that their values are
> > i= dentical". Is this really meant to mean identical?
>
> Here yes= . String comparison.
>
> > 4.2 Implicit Grant
> >> > The parenthesis "(it does not support the issuance of refresh t= okens)"
> > sounds like it should really be normative language, "r= efresh tokens
> > MUST NOT be issues for implicit grant" because a= faiu you could easily
> > extend "fragment-transport" to include a= refresh-token, so it isn't a
> > technically motivated constraint= , right?
>
> Instead I added this to 4.2.2:
>
>&nbs= p;           The authorization server MUST NOT issue a refresh token.
>
> > In (D) I would like to hav= e a normative reference to a document that
> > specifies browser b= ehavior for URL fragments since this is a critical
> > security de= pendency for this grant type.
>
> That's RFC2616. Seems odd to = reference it here.
>
> > 4.4 Client Credentials
> >=
> > I think the text should note that this model effectively impl= ies that
> > the client is able to impersonate all users which has= the potential
> > for worse security problems than if the client = has access to individual user
> passwords.
>
> Worse how?= You can't use this with resource owner password.
>
> > 6 Re= freshing an Access Token
> >
> > scope - The term "lesser= than" is intuitive but imprecise. I suggest
> > "MUST NOT include= any scope not originally granted by the resource
> owner".
>
> Ok.
>
> > 7.1 and 8.1 Access Token = Types
> >
> > The section 7.1 lists two definitions of ac= cess token types and
> > provides a couple of examples but doesn't= provide any constraints on
> > future development of access token= s except in 8.1 where it is implied
> > that not all access token = types would be associated with HTTP
> > authentication mechanisms.= Are there really no constraints on access
> > token types that sh= ould be captured?
>
> None suggested.
>
> > 10.6= Authorization Code Redirection URI Manipulation
> >
> > = Suggest replace the word 'familiar' with 'trusted' in the first
> >= ; sentence of the second paragraph. The notion of trust opens up several> > boat loads of worm but it is the correct term here I think.
&= gt;
> Ok.
>
> > In the third paragraph "the same as" wrt redirection URIs occur and
> > this needs to be defi= ned (cf comments on 3.1.2 above).
>
> Changed to identical.
= >
> > Finally "The authorization server MUST require public cli= ents and
> > SHOULD require confidential clients to register their= redirection
> > URI". I am missing a discussion of why the two ty= pes of client differ wrt this
> attack vector.
>
> Public= clients rely on the registration to provide a minimal level of client
&= gt; identification while confidential clients are later authenticated which= can
> mitigate redirection URI manipulation.
>
> > 10= .10 Credentials Guessing Attack
> >
> > I found myself wa= nting implementation advice for how to generate good
> > tokens at= this point. This has been raised on the list too. The same
> > go= es for how to generate good CSRF cookies where the "(eg a hash of
> > the session cookie..." feels like it is implementation adv= ice yearning
> > to come out of the closet.
>
> Need s= omeone to suggest text.
>
> 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


=
--835683298-1501530307-1325920933=:19255--