> If the server issues clients with password credentials it MUST support HTTP > Basic (this is the flip side of 'the client MAY use HTTP Basic') and should > only support the client_secret parameter if it has clients incapable of using > HTTP Basic.
Very well. Without changing the meaning, I think the community would be well served by appending paragraph 2 of Section 2.3 as follows: ---- Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g. password, public/private key pair). If clients are issued passwords, the authorization server MUST support the HTTP Basic authentication scheme as defined in [RFC2617] and described by Section 2.3.1. ---- This helps to communicate that authorization servers are only required to support HTTP Basic if they issue client passwords. Andre On Tue, Sep 20, 2011 at 3:20 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > If the server issues clients with password credentials it MUST support HTTP > Basic (this is the flip side of 'the client MAY use HTTP Basic') and should > only support the client_secret parameter if it has clients incapable of using > HTTP Basic. > > This language has been tweaked to reach a delicate balance. I'm not inclined > to touch it. > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of André DeMarre >> Sent: Wednesday, September 14, 2011 5:25 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 >> >> I agree that stating "Clients in possession of a client password MAY use the >> HTTP Basic authentication scheme" [Section 2.3.1 paragraph 1] implies that >> authorization servers MUST support HTTP basic authentication, but such is >> never asserted. Instead, it says "The authorization server MAY accept any >> form of client authentication meeting its security requirements." [Section >> 2.3 >> paragraph 1] This is somewhat contradictory. >> >> I can understand that requiring a specific method of client authentication is >> desirable for maximum interoperability, but this would be problematic for >> authorization server implementations that wish to enforce stronger security >> than HTTP Basic. Such implementations would be forced to deviate from the >> specification. In particular, implementations which choose MAC access >> tokens instead of Bearer tokens may wish to add a layer of security to >> defend against improperly configured TLS connections, or to protect clients >> who connect to the wrong server. >> [http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/] >> Such implementations will also find HTTP Basic undesirable for client >> authentication. To require a form of client authentication that isn't >> universally >> sufficient could become a source of criticism and deter adoption of OAuth >> 2.0. >> >> I think the best solution is to clarify section 2.3.1 as follows: >> --- >> Clients in possession of client credentials MAY use any form of >> authentication >> scheme supported by the authorization server. >> --- >> And then follow with the existing example that demonstrates HTTP Basic. >> >> Regards, >> Andre DeMarre >> >> On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail <g...@apigee.com> wrote: >> > I would like to add my support to the comments below on section 2.3, >> > specifically 2.3.1. >> > >> > It is clear to me from reading section 2.3 that clients MAY use HTTP >> > basic, or they MAY include client_id and client_secret in the request >> > body -- however, the latter is not recommended. >> > >> > It is not clear what the authorization server MUST support. IMHO, that >> > leads us to a situation in which there is no universally-agreed set of >> > authentication technology that all programmers can assume is going to >> > work, which means that interoperability will be difficult as some >> > authorization servers will support Basic, others will support the >> > request body, and others will do neither in favor of something else. >> > >> > I would prefer that we make both HTTP basic AND the request body >> > mechanisms in this section both required on the server side, thus >> > giving the client the option of choosing one or the other. That would >> > mean re-writing the beginning of section 2.3.1 as shown below. >> > >> > If I have missed other discussion on this topic I apologize. If there >> > is already consensus to make the "message body" authentication >> > optional rather than required for the authorization SERVER then I >> > would still recommend that we make HTTP Basic a MUST in order to allow >> > easier interop. >> > >> > Proposed change to 2.3.1: >> > >> > ---- >> > >> > The authorization server MUST support the HTTP Basic authentication >> > scheme as defined in [RFC2617] as a way to identify clients. The >> > client identifier is used as the username, and the client password is >> > used as the password. >> > >> > For example (extra line breaks are for display purposes only): >> > >> > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW >> > >> > Alternatively, the authorization server MUST also allow the client to >> > include the client credentials in the request body using the following >> > parameters: >> > >> > client_id >> > REQUIRED. The client identifier issued to the client during >> > the registration process described by Section 2.2. >> > client_secret >> > REQUIRED. The client secret. The client MAY omit the >> > parameter if the client secret is an empty string. >> > >> > Clients in possession of a client password MAY use either mechanism in >> > order to authenticate with the authorization server. However, >> > including the client credentials in the request body using the two >> > parameters is NOT RECOMMENDED, and should be limited to clients unable >> > to directly utilize the HTTP Basic authentication scheme (or other >> > password-based HTTP authentication schemes). >> > >> > (Rest of section remains as-is with the paragraph beginning "For >> > example...") >> > >> > Gregory Brail | Technology | Apigee | +1-650-937-9302 >> > >> > On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell >> > <stephen.farr...@cs.tcd.ie> wrote: >> >> >> >> FYI, probably best for the WG to see/process these secdir comments as >> >> appropriate. I've not read 'em in detail myself yet, so as Leif says, >> >> feel free to react as appropriate. >> >> >> >> S. >> >> >> >> PS: Thanks Leif for reviewing this. >> >> >> >> -------- Original Message -------- >> >> Subject: secdir review of draft-ietf-oauth-v2 >> >> Date: Mon, 12 Sep 2011 20:31:06 +0200 >> >> From: Leif Johansson <le...@sunet.se> >> >> To: draft-ietf-oauth...@tools.ietf.org, sec...@ietf.org, >> >> i...@ietf.org >> >> >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA1 >> >> >> >> >> >> Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 >> >> >> >> Do not be alarmed. I have reviewed this document as part of the >> >> security directorate's ongoing effort to review all IETF documents >> >> being processed by the IESG. These comments were written primarily >> >> for the benefit of the security area directors. Document editors and >> >> WG chairs should treat these comments just like any other last call >> >> comments. >> >> >> >> This review is rather lengthy. This should not be interpreted as >> >> anything beyond a desire to do a thorough review. >> >> >> >> It may well be that I have stumbled on things already covered on the >> >> list. If so I apologize and ask that you silently ignore such bits. >> >> Also I have included things that are not directly security related >> >> but that I found problematic for other reasons. >> >> >> >> The notes are presented in the order I wrote them down. >> >> >> >> ** 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_ POST example in the cases where both are supported would help >> >> or make the method explicit in the text before the example. >> >> >> >> The P-word >> >> >> >> The term 'password' is sprinkled throughout the document, sometimes >> >> as in "client password" or "resource owner password credentials" and >> >> I suspect that sometimes it is password as in 'an example of a >> >> credential type' and in other cases it is password as in 'plain old >> >> password'. This needs to be cleared up throughout (I've included some >> >> examples below). >> >> >> >> Normative Language >> >> >> >> I've often found myself wanting more normative language often to >> >> replace existing but less precise text. I've called out some >> >> important cases below. >> >> >> >> Unknown parameters >> >> >> >> The sentence "The client SHOULD ignore 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 inconsistency. >> >> >> >> ** Specifics >> >> >> >> 1.1 Roles >> >> >> >> Forward references to the sections where the roles are defined would >> >> improve readability. >> >> >> >> As an illustration of an alternative model for the authorization >> >> server maybe an informative reference to UMA would be illustrative >> here. >> >> >> >> 1.2 Protocol Flow >> >> >> >> (A) talks about 'an intermediary such as an authorization server.' it >> >> isn't clear it me if this refers to a separate authorization server >> >> or if it is the same authorization server that is referenced in (B). >> >> >> >> 1.3.3 Resource Owner Password Credentials >> >> >> >> When I first read this I thought - why not talk about Resource Owner >> >> Credentials - in fact there is a parenthesis there "(e.g a username >> >> and password)" that seems to indicate that other credentials could be >> >> supported. >> >> >> >> This needs to be cleared up. Either its username and password and >> >> nothing else or there is a way to support things like Negotiate or >> >> X.509-based credentials in which case it should really be Resource >> >> Owner Credentials with no reference to passwords other than as as an >> >> example of one possible credential type. >> >> >> >> 1.4 Access Token >> >> >> >> first paragraph: "The string is usually opaque". This should be >> >> reformulated as normative language. In fact I would have liked >> >> guidance on generating those tokens (which has been brought up on the >> >> list) possibly as part of an implementation-guide. >> >> >> >> 1.5 Refresh Token >> >> >> >> Why is the refresh token not simply treated as an access token for >> >> the access token resource in the 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. >> >> >> >> Also in the first paragraph: "(access tokens may have a shorter >> >> lifetime and fewer permissions". Why not try to write normative >> >> language here - there are security implications of allowing a refresh >> >> token to get more permissions (say) than the original access token. >> >> >> >> 2.1 Client types >> >> >> >> 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... >> >> >> >> This section also lacks normative language which isn't good. There >> >> should be language defining the behavior of public and confidential >> >> client aswell as the three profiles. >> >> >> >> For instance under native application we have "It is assumed that any >> >> client authentication credentials included in the application can be >> >> extracted". 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. >> >> >> >> 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 SHOULD >> >> support both and clients SHOULD only do Basic. >> >> >> >> This section also seems to have been the product of a partial >> >> s/password/credential/g operation. Either OAUTH is only meant to use >> >> Basic and passwords or we want to cover all/most HTTP authentication >> >> methods and credentials and then section 2.3.2 (which feels like an >> >> afterthought) 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. >> >> >> >> 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 authentication method with a mapping to >> client_id. >> >> If a client supports username+passwords it SHOULD do Basic and if it >> >> supports other HTTP authentication methods it MUST NOT use >> >> client_password for anything and MUST follow normal HTTP >> >> authentication method negotiation. >> >> >> >> Finally, everywhere there is negotiation there must imho be some >> >> mention/discussion/protection of downgrade attacks. >> >> >> >> 3.1 Authorization Endpoints >> >> >> >> 6th paragraph: "The authorization 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? >> >> >> >> 3.1.1 Response Type >> >> >> >> The response_type parameter is REQURED but its absence SHOULD result >> >> in an error. Why not MUST? >> >> >> >> 3.1.2 Redirection Endpoint >> >> >> >> There should be a clear normative specification for how to match >> >> endpoints. 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) and referencing this throughout. Since >> >> this comparison has security implications it should be a priority for >> >> the specification to be air-tight. >> >> >> >> 3.1.2.2 Registration Requirements >> >> >> >> "(the client MAY use the state request parameter to achieve >> >> per-request customization)". Doesn't this overload its use for CSRF- >> protection? >> >> >> >> 3.1.2.4 Invalid Endpoint >> >> >> >> "The authorization server SHOULD NOT redirect...". Why isn't this a >> >> MUST NOT? >> >> >> >> 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 language. >> >> >> >> 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. >> >> >> >> 3.2.1 Client Authentication >> >> >> >> The phrase "clients 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 ;-) >> >> >> >> The second bullet: Using client credentials more often also exposes >> >> them more which might be worth mentioning aswell. >> >> >> >> 4. Obtaining Authorization >> >> >> >> Perhaps not critical but the term 'password credentials' occurs in >> >> the first paragraph and this doesn't seem compatible with resource >> >> owner authentication being out of scope. It could just be that it >> >> should read 'resource owner credentials' but it could also signal an >> >> underlying assumption about username and password being used for >> >> resource owner authentication. In either case I thing its best to >> >> avoid the use of the word 'password' to avoid any confusion. >> >> >> >> 4.1 Authorization Code >> >> >> >> (C) - "using the redirection URI provided earlier" should perhaps >> >> read "using the redirection URI provided earlier or associated with >> >> the client in client registration" >> >> >> >> >> >> 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 >> >> redirect_uri is not present. I believe the assumption is that the >> >> redirect_uri is either resent or part of client registration but that >> >> needs to be made explicit in that case. >> >> >> >> 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-formulatation >> >> of the last sentence: "The client MUST NOT use an authorization 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 associated with the client." (i.e loose the "attempt" >> >> bit which carries no real meaning) >> >> >> >> Also note that this is potentially a DOS attack should a single authz >> >> code leak. >> >> >> >> 4.1.2.1 Error Response >> >> >> >> First paragraph, last sentence "and MUST NOT automatically redirect". >> >> In the light of how willing users normally are to click on links >> >> presented to them I would strengthen this to "MUST prevent the user >> >> from following the redirect URI" >> >> >> >> 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). >> >> >> >> 4.1.3 Access Token Request >> >> >> >> "require client authentication for confidential clients or for any >> >> client issued client credentials (or with other authentication >> >> requirements)" >> >> >> >> This text seems unnecessarily convoluted. Isn't enough to say that if >> >> you have issued credentials to a client you MUST require >> >> authentication from that client? This applies equally to the other >> >> sections where client authentication is an issue (eg 4.3.2). >> >> >> >> Also cf my comment on 3.1.2 for the discussion of matching >> >> redirect_uri in the last bullet: ".. and that their values are >> >> identical". Is this really meant to mean identical? >> >> >> >> 4.2 Implicit Grant >> >> >> >> The parenthesis "(it does not support the issuance of refresh tokens)" >> >> sounds like it should really be normative language, "refresh tokens >> >> MUST NOT be issues for implicit grant" because afaiu you could easily >> >> extend "fragment-transport" to include a refresh-token, so it isn't a >> >> technically motivated constraint, right? >> >> >> >> In (D) I would like to have a normative reference to a document that >> >> specifies browser behavior for URL fragments since this is a critical >> >> security dependency for this grant type. >> >> >> >> 4.4 Client Credentials >> >> >> >> I think the text should note that this model effectively implies 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. >> >> >> >> 6 Refreshing 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". >> >> >> >> 7.1 and 8.1 Access Token Types >> >> >> >> The section 7.1 lists two definitions of access token types and >> >> provides a couple of examples but doesn't provide any constraints on >> >> future development of access tokens 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 should be captured? >> >> >> >> 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. >> >> >> >> In the third paragraph "the same as" wrt redirection URIs occur and >> >> this needs to be defined (cf comments on 3.1.2 above). >> >> >> >> Finally "The authorization server MUST require public clients and >> >> SHOULD require confidential clients to register their redirection >> >> URI". I am missing a discussion of why the two types of client differ >> >> wrt this attack vector. >> >> >> >> 10.10 Credentials Guessing 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 generate good CSRF cookies where the "(eg a hash of >> >> the session cookie..." feels like it is implementation advice >> >> yearning to come out of the closet. >> >> >> >> >> >> Thats it. >> >> >> >> Cheers Leif >> >> -----BEGIN PGP SIGNATURE----- >> >> Version: GnuPG v1.4.11 (GNU/Linux) >> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> >> >> >> iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ont >> E >> >> a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS >> >> =ox42 >> >> -----END PGP SIGNATURE----- >> >> >> >> _______________________________________________ >> >> 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 >> > >> _______________________________________________ >> 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
