Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2
Simply added to the first paragraph: The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients which were issued a client password. EHL -Original Message- From: André DeMarre [mailto:andredema...@gmail.com] Sent: Tuesday, September 20, 2011 7:12 PM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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-ide a/] 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
Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2
-Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, September 20, 2011 3:13 PM 3.1.1 Response Type The response_type parameter is REQURED but its absence SHOULD result in an error. Why not MUST? Changes to MUST. 3.1.2.4 Invalid Endpoint The authorization server SHOULD NOT redirect Why isn't this a MUST NOT? I'm ok with MUST NOT - any objections? This one is actually tricky. I don't like the current text (mine) because untrusted is a useless qualifier here. The point is that redirecting to unregistered endpoints can lead to the abuse of the endpoint as an open redirector. Because we actually support unregistered callbacks, we can't say MUST NOT. I am removing the 'untrusted' part but leaving the SHOULD NOT as is. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2
I have not seen any follow up to the open issues and will be closing 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 know of listing them (and their status/response). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, September 20, 2011 3:13 PM To: Leif Johansson; OAuth WG Subject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2 (+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. EHL -Original Message- From: Leif Johansson [mailto:le...@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_ 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. What sections? That's the only place these roles are defined. As an illustration of an alternative model for the authorization server maybe an informative reference to UMA would be illustrative here. A reference to UMA would be confusing in this document. 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). Changed to: (A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary. 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. Changed to: (i.e. username and password) This is explicitly just for username and password. Other types require an extension. 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. There is not requirement for the string to be opaque, but the general architecture assumes it is. Otherwise, please suggest language. 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. Simpler architecture 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 language here - there are security implications of allowing a refresh token to get more permissions (say) than the original access token. This was discussed before and we
[OAUTH-WG] FW: draft-ietf-oauth-v2: Doubt about chapter 4.2
Sending to the right place. EHL From: DIEGO GONZALEZ MARTINEZ [mailto:die...@tid.es] Sent: Friday, October 07, 2011 1:35 AM To: draft-ietf-oauth...@tools.ietf.org Subject: draft-ietf-oauth-v2: Doubt about chapter 4.2 Hello, My name is Diego González, I work in Telefónica RD and I'm following OAuth 2.0 works as we're using OAuth in Telefónica's APIs exposure programs (e.g.: BlueVia). I as well participate in OMA activities for using OAuth to access OMA standard APIs. I'm Reading through OAuth 2.0 draft and I have a doubt. In chapter 4.2.1 for Implicit Grant I can see the following example: GET /authorize?response_type=tokenclient_id=s6BhdRkqt3state=xyz redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com Then in chapter 4.2.2 I see the following example: HTTP/1.1 302 Found Location: http://example.com/rd#access_token=2YotnFZFEjr1zCsicMWpAA state=xyztoken_type=exampleexpires_in=3600 The first I thought is that this is just a misalignment within examples and second example should look like https://client.example.com/cb. Is it? But then I got the following doubt. Would it make sense for every Client to be redirected to a known web hosted by the resource provider? I mean a set of clients trying to gain access to a Resource, and being always redirected to the same web-hosted resource offered by resource provider, not to the web-client hosted resource. E.g.: redirect every client using Implicit Grant to https://server.com/accessTokenScriptisHereforEveryOne, no matter what the redirect_uri was. Do you think this make sense? Or there are some security problems I am not taking into account. Kind regards, Diego Diego González Martínez Telefónica Investigación y Desarrollo Iniciativa NeoSDP e-mail: die...@tid.esmailto:die...@tid.es Phone: +34 983 36 75 97 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Using OAuth error_code to glean information from the server
'Client credentials' needs to be removed from invalid_grant. It is not appropriate. Use invalid_client all the way to a fully authenticate client. ANY failure to authenticate the client should result in invalid_client. Use unauthorized_client for an authenticate client which is not permitted to use this grant type. There are no other issues with an invalid grant related to client credentials. I'll drop it from the e.g. list. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, December 12, 2011 4:52 PM To: oauth@ietf.org Subject: [OAUTH-WG] Using OAuth error_code to glean information from the server I recently received an inquiry regarding invalid_client vs. invalid_grant. It seems that there is a potential information disclosure in the specification with respect to how these error codes are used: invalid_client Client authentication failed (e.g. unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the Authorization request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the WWW-Authenticate response header field matching the authentication scheme used by the client. invalid_grant The provided authorization grant (e.g. authorization code, resource owner credentials, client credentials) is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client. If one uses invalid_client when the client is unknown and invalid_grant when the client credentials are invalid, then an attacker could deduce whether or not a particular client exists. First, do people agree that this is a potential information leak and that the leak is meaningful? If so, what mitigation might be suggested? For instance, might a server choose to use a single error code for both (and potentially other) cases? Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Mandatory to Implement Interoperability
I can work with Berry's text. Another alternative is to: * Require the server to implement at least one of Bearer and MAC, or provide the client with a method for discovering or requesting a specific token type (which is beyond the scope). This way, until there is a discovery method, each server must support at least one of these two (which is not an unreasonable requirement given that these two cover all the use cases the community has come up with in 5 years). Clients that want to ensure interoperability then, must understand both, but the requirement isn't on the client. In practice, this will keep every existing implementation already in compliance, and will offer clients a guaranteed path to interop is the client so chooses. The advantage of this approach is that it can be expressed with one sentence and it should not offend those objecting to MTI MAC tokens. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Friday, December 09, 2011 4:36 AM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Mandatory to Implement Interoperability Hannes, I don't see any proposed text here, I see re-chartering suggestions. The latter is not going to happen if the current main documents are wedged. Please focus on the former now. You know that I disagree with you and a number of WG participants about this, so no need for me to repeat myself, other than to say that I've always said pick an MTI, *or* say (convincingly) what that's not needed and you've not addressed the latter. Barry's text did do that. The fact that a) the room in Taipei seemed to agree with MTI, b) the list seemed to agree with Barry's suggested text, and c) this new suggested programme also gets a bunch of +1's all seems to me to imply that people are not sufficiently focused on getting this finished but would still prefer to get what they think of as perfection. S. PS: I would also quibble that the lessons from keyprov are highly relevant here, but let's not:-) On 12/08/2011 09:15 PM, Alexey Melnikov wrote: On 08/12/2011 14:18, Hannes Tschofenig wrote: Hi all, Hi Hannes, Some random thoughts about your message below: I read through this rather long mail thread again and see whether we are reaching any conclusion on this discussion. In turns out that there are actually two types of discussions that relate to each other, namely the TLS version support and the token type. Let me go back in time a little bit when I was still chairing another working group (years ago), namely the KEYPROV working group. There we ran into a similar issue, which looked fairly simple at the beginning. We worked on Portable Symmetric Key Container (PSKC), later published as RFC 6030. We were at the stage where we thought we had to decide on a mandatory-to-implement cryptographic algorithm and, similar to the OAuth case, PSKC is one building block in a larger protocol suite. As you can imagine, everyone had their own deployment environment in mind and did not like the suggestion others made about what as mandatory to implement. Russ (now IETF chair and at that time security area director) told the group not to worry - we don't need to pick an algorithm. He suggested to just provide a recommendation of what is best in a specific deployment environment (at the time of writing). In fact, he proposed to publish a separate document instead to discussing it in that document. I was surprised because I was couldn't see how one would accomplish interoperability. Russ told me that this is in practice not a problem because implementations often implement a range of cryptographic algorithms anyway. Then, as part of the algorithm negotiation procedure (or some discovery) they will figure out what both end points support. He further argued that algorithm preferences will change (as algorithms get old) and we don't want to update our specifications all the time. (This was a bit motivated by the MD5 clean-up that happened at that time.) [Please forgive me if I do not recall the exact words he said many years ago.] I believe we are having a similar discussion here as well, both with the token type but also with the TLS version. We look at individual specifications because we are used to add security consideration sections to each and every document. Unfortunately, the most useful statements about security (for these multi-party protocols where the functionality is spread over multiple documents) can really only be made at a higher level. Our approach for describing security threats and for recommending countermeasures isn't suitable to all the documents we produce. Let me list a few desirable results of our standardization work: 1) Everyone wants interoperability. We can do interop testing of building blocks to see whether a client and a
Re: [OAUTH-WG] Mandatory-to-implement token type
Bearer tokens are practically identical to OAuth 1.0 PLAINTEXT. Get your facts right. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin Sent: Sunday, December 04, 2011 1:37 AM To: Mike Jones; Barry Leiba; Stephen Farrell Cc: oauth WG Subject: Re: [OAUTH-WG] Mandatory-to-implement token type I agree we have no plans to implement MAC if we wanted that we would have been happy with OAUTH 1.0a but that was not deployable -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Saturday, December 03, 2011 6:26 PM To: Barry Leiba; Stephen Farrell Cc: oauth WG Subject: Re: [OAUTH-WG] Mandatory-to-implement token type I strongly object to a mandatory-to-implement clause for the MAC scheme. They are unnecessary and market forces have shown that implementers do not want or need this kind of an authentication scheme. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Barry Leiba Sent: Saturday, December 03, 2011 1:38 PM To: Stephen Farrell Cc: oauth WG Subject: Re: [OAUTH-WG] Mandatory-to-implement token type Stephen says: On 12/02/2011 03:20 AM, Barry Leiba wrote: Maybe what would work best is some text that suggests what I say above: that toolkits intended for use in implementing OAuth services in general... implement [X and/or Y], and that code written for a specific environment implement what makes sense for that environment. It seems to me that to require any particular implementation in the latter case is arbitrary and counter-productive, and doesn't help anything interoperate. Whereas general-purpose toolkits that implement everything DO help interop. That'd work just fine for me. OK, so here's what I suggest... I propose adding a new section 7.2, thus: --- 7.2 Access Token Implementation Considerations Access token types have to be mutually understood among the authorization server, the resource server, and the client -- the access token issues the token, the resource server validates it, and the client is required to understand the type, as noted in section 7.1, above. Because of that, interoperability of program code developed separately depends upon the token types that are supported in the code. Toolkits that are intended for general use (for building other clients and/or servers), therefore, SHOULD implement as many token types as practical, to ensure that programs developed with those toolkits are able to use the token types they need. In particular, all general-use toolkits MUST implement bearer tokens [...ref...] and MAC tokens [...ref...]. Purpose-built code, built without such toolkits, has somewhat more flexibility, as its developers know the specific environment they're developing for. There's clearly little point to including code to support a particular token type when it's known in advance that the type in question will never be used in the intended deployment. Developers of purpose-built code are encouraged to consider future extensions and to plan ahead for changes in circumstances, and might still want to include support for multiple token types. That said, the choice of token-type support for such purpose-built code is left to the developers and their specific requirements. --- I think that expresses a reasonable compromise that might actually be followed and might actually do some good. Comments? Can we go with this and close this issue? (And, sorry, I've been a Bad Chair, and haven't put this in the tracker.) Barry ___ 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
Re: [OAUTH-WG] TR: [oauth] #27: Incorporate bearer scope character restrictions into the base spec
It has to be. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of MARCON, JEROME (JEROME) Sent: Friday, December 02, 2011 5:47 AM To: oauth@ietf.org Subject: [OAUTH-WG] TR: [oauth] #27: Incorporate bearer scope character restrictions into the base spec Hello everyone, Does someone know if ticket#27 (Incorporate bearer scope character restrictions into the base spec) is still planned to be resolved ? Many thanks, Jerome Marcon -Message d'origine- De : oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] De la part de oauth issue tracker Envoyé : jeudi 20 octobre 2011 06:31 À : barryle...@computer.org Cc : oauth@ietf.org Objet : [OAUTH-WG] [oauth] #27: Incorporate bearer scope character restrictions into the base spec #27: Incorporate bearer scope character restrictions into the base spec This is part of the resolution of issue #26, as discussed on the mailing list: Can you please open an issue for the core spec to incorporate the scope character restrictions from the bearer spec into the core spec? These restrictions are: scope = scope = scope-val *( SP scope-val ) scope-val = 1*scope-val-char scope-val-char = %x21 / %x23-5B / %x5D-7E -- + Reporter: barryleiba@.| Owner: Type: task| Status: new Priority: minor | Milestone: Deliver OAuth 2.0 spec Component: v2 |Version: Severity: Active WG Document | Keywords: + Ticket URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/27 oauth http://tools.ietf.org/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
Re: [OAUTH-WG] 2 Leg with OAuth 2.0
This functionality can be implemented in two main ways: 1. Using the client credentials flow to get an access token, then using the protocol as usual 2. Just using the Bearer (over SSL) or MAC token schemes without the rest of OAuth EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Hawkins Sent: Tuesday, November 29, 2011 11:49 AM To: oauth@ietf.org Subject: [OAUTH-WG] 2 Leg with OAuth 2.0 I'm having trouble finding information on how to do 2leg authentication with OAuth 2.0. Does it even support it? Thanks Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 2 Leg with OAuth 2.0
Both MAC and Bearer work in this setup, just think of them as HMAC-SHA-1 and PLAINTEXT in OAuth 1.0. In Bearer, your token is the client secret and in MAC, the client secret is the key. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Hawkins Sent: Tuesday, November 29, 2011 12:28 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] 2 Leg with OAuth 2.0 Maybe I'm making this harder then it should be. Here is the situation: Site A and B both trust each other. Site A needs to update user information at site B. With OAuth 1.0 Site A would use it's consumer key and secret to sign the update call to Site B (no access token involved). Only one message is sent. The closest I can come to the above with OAuth 2.0 is to use the MAC token scheme and sign the request with the consumer secret. Is that valid? I kind of get the idea that the protocol doesn't care. It feels like the bearer scheme just doesn't work for what I'm trying to do. Thanks Brian On Tue, Nov 29, 2011 at 1:06 PM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: This functionality can be implemented in two main ways: 1. Using the client credentials flow to get an access token, then using the protocol as usual 2. Just using the Bearer (over SSL) or MAC token schemes without the rest of OAuth EHL From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On Behalf Of Brian Hawkins Sent: Tuesday, November 29, 2011 11:49 AM To: oauth@ietf.orgmailto:oauth@ietf.org Subject: [OAUTH-WG] 2 Leg with OAuth 2.0 I'm having trouble finding information on how to do 2leg authentication with OAuth 2.0. Does it even support it? Thanks Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] MAC: body-hash
That like trying to eat the cake and have it too. We dropped the body-hash parameter because it doesn't work. There are too many complications in getting an interop solution across platforms and body types. There are ASCII, UTF8, binary, etc. bodies and they will all produce different hash value based on at what level the client hashes them. In addition, the HTTP layer can do many things to the data including encoding. On top of that, you have HTTP headers that change the meaning of the payload. We've tried it and could not come up with any reasonable solution. As someone who have and wants to implement this, I understand the need for it, but at this point within the limitations of HTTP, this belongs as a vendor specific extension until more real-world experience is gained. EHL -Original Message- From: Peter Wolanin [mailto:peter.wola...@acquia.com] Sent: Thursday, November 24, 2011 5:03 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC: body-hash I'd lobby for something more than just prose, since for me, including the body or body hash in the HMAC is a pretty essential piece of security for any real implementation. I understand that you think it should not be 100% required by all servers, and hence should not be a specified field, but then I think it should be something like a standard extension. For example, retain some of the existing text describing the bodyhash as using the same algorithm as the HMAC and show an example like: ext=bodyhash:k9kbtCIy0CkI3/FEfpS/oIDjk6k= Are there any other specific things you see as common examples of ext values? Is there a suggested system for indicating or separating multiple ext values? It seems to me without a standardized way to include the body hash in the ext field, you immediately invite more diversity in implementations. It would also seem by putting it in the ext field, any client could include the hash even if the server doesn't require it? Best, Peter On Thu, Nov 24, 2011 at 12:21 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: In prose, sure. But I'd rather not go further than that. EHL -Original Message- From: Peter Wolanin [mailto:peter.wola...@acquia.com] Sent: Wednesday, November 23, 2011 11:53 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC: body-hash As long as a specific service can make an ext containing the body hash required, I think this is fine. Can the spec include body hash as an example of an ext? Thanks, Peter On Sat, Nov 19, 2011 at 10:39 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: I want to reaffirm our previous consensus to drop the body-hash parameter and leave the ext parameter. Body-hash as currently specified is going to cause significant interop issues due to character (and other) encoding issues. Providers who desire to MAC the body can define their own ext use case. Let me know if you have an objection to this change. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. peter.wola...@acquia.com : 781-313-8322 Get a free, hosted Drupal 7 site: http://www.drupalgardens.com; -- Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. peter.wola...@acquia.com : 781-313-8322 Get a free, hosted Drupal 7 site: http://www.drupalgardens.com; ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] MAC Cookies
MAC tokens are a solution, not a use case :-) As for reaching out, I'll leave it to the chairs to decide how to want to proceed. EHL -Original Message- From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Wednesday, November 23, 2011 11:36 PM To: Peter Wolanin Cc: Eran Hammer-Lahav; Ben Adida; OAuth WG; Adam Barth (a...@adambarth.com) Subject: Re: [OAUTH-WG] MAC Cookies Eran, I see value (at least for servers) in having browser and HTTP clients work with common tokens (e.g. MAC) - even though the mechanism for exchange may vary. I had an email exchange with Harry Halpin. He suggests cross posting to the w3c public-identity list. They are discussing web cryptography and MAC tokens may be an important use case. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-11-23, at 4:57 PM, Peter Wolanin wrote: No objection from me, but it's too bad the browser vendors aren't interested. -Peter On Sat, Nov 19, 2011 at 10:33 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: I would like to drop the cookies support defined in the MAC document due to lack of interest from the browser vendors. At this point it is most likely going to be an unimplemented proposal. If there is interest in the future, it can be proposed in a separate document. This will allow us to bring this work to a quick conclusion. Any objections? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. peter.wola...@acquia.com : 781-313-8322 Get a free, hosted Drupal 7 site: http://www.drupalgardens.com; ___ 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-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14
-Original Message-
From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org] On
Behalf Of Mark Nottingham
Sent: Wednesday, November 23, 2011 10:22 PM
To: IETF Apps Discuss; draft-ietf-oauth-v2-bearer@ietf.org
Cc: The IESG
Subject: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14
I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments you may
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.
Document: draft-ietf-oauth-v2-bearer-14
Title: OAuth 2.0 Bearer Tokens
Reviewer: Mark Nottingham
Review Date: 24/11/2011
Summary: This draft is almost ready for publication as a Proposed Standard, but
has a few issues that should be fixed.
Major Issues
* Section 2.3 URI Query Parameter
This section effectively reserves a URI query parameter for the draft's use.
This should not be done lightly, since this would be a precedent for the IETF
encroaching upon a server's URIs (done previously in RFC5785, but in a much
more limited fashion, as a tactic to prevent further, uncontrolled
encroachment).
Given that the draft already discourages the use of this mechanism, I'd
recommend dropping it altogether. If the Working Group wishes it to remain,
this issues should be vetted both through the APPS area and the W3C liaison.
(The same criticism could be leveled at Section 2.2 Form-Encoded Body
Parameter, but that at least isn't surfaced in an identifier)
* Section 3 The WWW-Authenticate Response Header Field
The draft references the quoted-string ABNF from HTTP, but changes its
processing in a later paragraph:
In all these cases, no character quoting will occur, as senders are
prohibited from using the %5C ('\') character.
This is at best surprising (as many readers will reasonably surmise that using
the quoted-string ABNF implies that the same code can be used). Please either
use quoted-string as defined (i.e., with escaping).
Minor Issues
* Section 1: Introduction
The introduction explains oauth, but it doesn't fully explain the relationship
of this specification to OAuth 2.0. E.g., can it be used independently from the
rest of OAuth? Likewise, the overview (section 1.3) seems more specific to the
OAuth specification than this document. As I read it, this mechanism could be
used for ANY bearer token, not just one generated through OAuth flows.
If it is indeed more general, I'd recommend minimising the discussion of OAuth,
perhaps even removing it from the document title.
* Section 3 The WWW-Authenticate Response Header Field
The difference between a realm and a scope is not explained. Are the
functionally equivalent, just a single value vs. a list?
Do you really intend to disallow *all* extension parameters on the challenge?
Also, the scope, error, error_description and error_uri parameters all specify
only a quoted-string serialisation. HTTPbis strongly suggests that new schemes
allow both forms, because implementation experience has shown that
implementations will likely support both, no matter how defined; this improves
interoperability (see p7 2.3.1).
Finally, the error_description parameter can carry only ASCII characters. While
I understand a tradeoff has been made here (and, in my judgement, an
appropriate one), it's appropriate to highlight this in review.
* General
The draft currently doesn't mention whether Bearer is suitable for use as a
proxy authentication scheme. I suspect it *may*; it would be worth discussing
this with some proxy implementers to gauge their interest (e.g., Squid).
Nits
* Section 2.1 Authorization Request Header Field
simplicity reasons -- simplicity
If additional parameters are desired in the future, a different scheme could
be defined. -- If additional parameters are needed in the future, a
different scheme would need to be defined.
* Section 3 The WWW-Authenticate Response Header Field
The requirement that a resource server MUST include the HTTP WWW-Authenticate
response header field is odd; really this is at the discretion of the server.
Is it really necessary to use a conformance requirement here?
URI-reference -- URI-Reference
* Section 3.1 Error Codes
405 belongs in the list of typically appropriate status codes as well.
Kind regards,
--
Mark Nottingham http://www.mnot.net/
___
apps-discuss mailing list
apps-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] MAC Cookies
I would like to drop the cookies support defined in the MAC document due to lack of interest from the browser vendors. At this point it is most likely going to be an unimplemented proposal. If there is interest in the future, it can be proposed in a separate document. This will allow us to bring this work to a quick conclusion. Any objections? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] MAC: body-hash
I want to reaffirm our previous consensus to drop the body-hash parameter and leave the ext parameter. Body-hash as currently specified is going to cause significant interop issues due to character (and other) encoding issues. Providers who desire to MAC the body can define their own ext use case. Let me know if you have an objection to this change. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] MAC: body-hash
The charset is restricted so no issues. From: William Mills [mailto:wmi...@yahoo-inc.com] Sent: Saturday, November 19, 2011 7:46 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] MAC: body-hash I haven't read the MAC spec recently enough, did you already deal with the character set issue (if there was one) comparable to the ones in the Bearer spec? I am +1 on the -body_hash +ext change. From: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com To: OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Sent: Saturday, November 19, 2011 7:39 AM Subject: [OAUTH-WG] MAC: body-hash I want to reaffirm our previous consensus to drop the body-hash parameter and leave the ext parameter. Body-hash as currently specified is going to cause significant interop issues due to character (and other) encoding issues. Providers who desire to MAC the body can define their own ext use case. Let me know if you have an objection to this change. EHL ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] MAC: Age in nonce
We had a long discussion about what to use for the numerical component of the nonce string. I would like to suggest we use: nonce REQUIRED. A unique string generated by the client to allow the server to verify that a request has never been made before and helps prevent replay attacks when requests are made over an insecure channel. The nonce value MUST be unique across all requests with the same MAC key identifier. The nonce value MUST consist of an age, a colon character (%x25), and a unique string (typically random). The age portion MUST be a monotonically increasing, but not necessarily unique, positive integer value. The change in the age value between requests MUST reflect the number of seconds elapsed. For example, the age can be a client timestamp expressed as seconds since 01-01-1970 or since the credentials were issued to the client. The value MUST NOT include leading zeros (e.g. 000273156). For example: 273156:di3hvdf8 To avoid the need to retain an infinite number of nonce values for future checks, the server MAY choose to restrict the time period after which a request with an old age is rejected. If such a restriction is enforced, the server SHOULD allow for a sufficiently large window to accommodate network delays. The server SHOULD use the first age value received from the client to establish a method for comparing the server time with that of the client. In addition, the server SHOULD accommodate small negative changes in age values caused by differences between the multiple clocks of a distributed client configuration utilizing more than one device. This text keeps the age as a seconds count but uses the first request to establish a clock sync on the server side instead of mandating one way to calculate it. Feedback? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
-Original Message- From: Mark Nottingham [mailto:m...@mnot.net] Sent: Tuesday, May 31, 2011 4:57 PM The normalized request string contains the request-URI and values extracted from the Host header. Be aware that intermediaries can and do change these; e.g., they may change an absolute URI to a relative URI in the request-line, without affecting the semantics of the request. See [1] for details (it covers other problematic conditions too). It would be more robust to calculate an effective request URI, as in [2]. [2] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 Using the effective request URI has proved to be a significant point of friction in OAuth 1.0. I would rather note that intermediaries can change the request URI and that the server must reverse those changes based on what the values should have been if they were received from the client directly. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] MAC Token Comments
Thanks. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Friday, August 12, 2011 11:44 AM To: oauth@ietf.org Cc: Anganes, Amanda L Subject: [OAUTH-WG] MAC Token Comments 2: MAC Key: The server MUST NOT reissue a previously issued MAC key and MAC key identifier combination. Ok. 3: I would still like to see a binding for post body and url parameters. This could be as simple as defining a set of parameter names for everything used in the auth header, but I'm still given the impression that this has been deemed outside the scope of the MAC token. Our use case is to pass around signed URLs between servers with all query parameters protected by the signature, which we use 2-legged OAuth 1.0 for today. We can try to get language for this together if there's enough draw for it, but I haven't been hearing that from other folks yet so we might just try to draft an extension to the extension, instead. I can see the value in this for signed redirections and callbacks. The problem, of course, is that once you mess with the request URI, it must be normalized which has been a significant source of friction in OAuth 1.0. If you have suggestions on how to add this functionality without introducing significant pain, we should discuss it. 5: This section's wording should be brought more in line with the descriptions of the OAuth protocol in both core and bearer, which in turn should actually be a bit closer together themselves. Seems like we need a succinct elevator pitch for what is OAuth2 to drop into all of these locations (and other extension specs) -- anybody want to take a crack at distilling one from these three sources? I just dropped the whole thing and kept a one line reference to OAuth 2.0. No need to explain it. 7.9: Grammar tweak: Those designing additional methods should evaluate the compatibility of the normalized request string with their own security requirements. Adding 'own' is superfluous. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Mandatory-to-implement token type
1. Should we specify some token type as mandatory to implement? Why or why not (*briefly*)? On the server - no. It makes no sense because the server dictates the token type so if it decides to never issue the mandated type, what's the point in implementing? On the client, maybe. If the server knows that a client will always understand a set of token types, it can choose to use that and ensure interop (or not). In practice, mandating will add no real interop value. Almost every client will hard-code the token types it needs to understand and providers are not likely to support more than one or to change it. We can mandate a type for 'generic clients' so that libraries support both, but it won't actually make any difference. Bottom line, this is a red herring. OAuth doesn't really provide this level of interop and was never designed for that. In the future, when we have more interop web APIs (photos, social, etc.) and we have real world experience with discovery, this will be important. But that's a few years away (at least). 2. If we do specify one, which token type should it be? This is a no win situation. Most providers will ignore a requirement to support MAC, or will support it but will not see much usage because most developers when given the choice will go with Bearer. Mandating Bearer will be ignored by providers who want better security and will most likely render MAC pointless. If we mandate Bearer, I see no point in even publishing MAC as it will turn into a purely theoretical exercise. Given the history of this group, no change is the only likely consensus. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Single transaction token
No, but you can define a new parameter for use instead or alongside the existing parameter. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Declan Newman Sent: Tuesday, November 08, 2011 1:58 AM To: oauth@ietf.org Cc: Will Simpson; Geoffrey Bilder Subject: [OAUTH-WG] Single transaction token Hello, We're currently implementing OAuth 2 provider for a client, whom needs to have the facility to authenticate/authorise a client to update in a single transaction. Is there a way to specify the validity of a token on a per-transaction basis, as opposed to a timeframe? Any help much appreciated. Regards, Dec Declan Newman, Development Team Leader, Semantico, Floor 1, 21-23 Dyke Road, Brighton BN1 3FE mailto:declan.new...@semantico.com tel:+44-1273-358247 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
I have not seen any responses to these items so I assume the group is in agreement with the comments made. I will push out a revised ID addressing these items in a few days. EHL From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Stephen Farrell [stephen.farr...@cs.tcd.ie] Sent: Thursday, October 13, 2011 10:13 AM To: oauth@ietf.org Subject: [OAUTH-WG] AD review of -22 Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
Do you want to see no change or adjust it to client must implement both, server decides which to use. EHL From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of John Bradley [ve7...@ve7jtb.com] Sent: Wednesday, November 02, 2011 1:06 PM To: Torsten Lodderstedt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of -22 +1 On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote: Hi Stephen, I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. regards, Torsten. Am 13.10.2011 19:13, schrieb Stephen Farrell: Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
The problem is centered on the definition of a client. If it is a service specific implementation which is merely using OAuth for access, there isn't any interop requirements other than making sure the client and server are compatible. But if the client is a general purpose OAuth library or generic client (e.g. CURL), then the MTI becomes critical for any real interop. I don't have a strong prefernece here, but we should clearly define the client characteristics in this discussion since an OAuth client isn't usually similar to an HTTP client in its interop reality. I am not sure how to craft this language into spec form, but we might want to list such a MTI requirement in terms of a 'client designed to work across multiuple providers such as a general purpose library'. EHL From: Stephen Farrell [stephen.farr...@cs.tcd.ie] Sent: Wednesday, November 02, 2011 1:45 PM To: John Bradley Cc: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of -22 So perhaps this is the interesting point of difference. On 11/02/2011 08:37 PM, John Bradley wrote: It is up to the server to decide what formats it will support. With IETF protocols, its IETF consensus that decides this in almost all cases that affect interop and it is therefore not up to the specific server deployment admin what the server code will support. I think this case affects interop. and should be treated as for any other IETF protocol. Am I wrong? S ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Rechartering
That's a whole different issue as this is about talking to a single server retuning two tokens with different scopes. EHL From: Dick Hardt [dick.ha...@gmail.com] Sent: Saturday, October 29, 2011 12:07 AM To: Eran Hammer-Lahav Cc: Dan Taflin; OAuth WG Subject: Re: [OAUTH-WG] Rechartering What if the access tokens come from different authoritative servers? On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote: Why not just ask for one access token with all the scopes you need, then refresh it by asking for the different subsets you want. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dan Taflin Sent: Tuesday, October 25, 2011 3:37 PM To: OAuth WG Subject: Re: [OAUTH-WG] Rechartering I would like to second Torsten's pitch for the ability to return multiple access tokens with a single authorization process. The use case for my company is to segment operations into two main categories: protected and confidential. (A possible third category, public, would not require any authorization at all). Protected operations would be user-specific operations that don't involve the passing of any sensitive information, such as image search results tagged with information about whether each image is available for download by that user. Confidential operations would involve passing user data, like user registration or e-commerce. We would like to protect each category of operations with distinct tokens: a general-use token for protected operations, and a secure token for confidential operations. We could use the scope parameter to specify either protected or confidential. Currently the oauth spec allows a Refresh token to request a new token with reduced scope from the one originally issued, but there is no way to obtain a new token with a completely different scope without doing the full oauth dance a second time. Dan -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Thursday, October 20, 2011 3:57 PM To: Hannes Tschofenig Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering Hi all, my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps. A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose. OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover client instance aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes. We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers. As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment. If the additional data enlarges the request payload to much, we could consider to adopt the request by reference proposal. Let's now assume, OAuth is successful in the world of standard protocols and we will see
Re: [OAUTH-WG] Rechartering
Why not just ask for one access token with all the scopes you need, then refresh it by asking for the different subsets you want. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dan Taflin Sent: Tuesday, October 25, 2011 3:37 PM To: OAuth WG Subject: Re: [OAUTH-WG] Rechartering I would like to second Torsten's pitch for the ability to return multiple access tokens with a single authorization process. The use case for my company is to segment operations into two main categories: protected and confidential. (A possible third category, public, would not require any authorization at all). Protected operations would be user-specific operations that don't involve the passing of any sensitive information, such as image search results tagged with information about whether each image is available for download by that user. Confidential operations would involve passing user data, like user registration or e-commerce. We would like to protect each category of operations with distinct tokens: a general-use token for protected operations, and a secure token for confidential operations. We could use the scope parameter to specify either protected or confidential. Currently the oauth spec allows a Refresh token to request a new token with reduced scope from the one originally issued, but there is no way to obtain a new token with a completely different scope without doing the full oauth dance a second time. Dan -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Thursday, October 20, 2011 3:57 PM To: Hannes Tschofenig Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering Hi all, my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps. A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose. OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover client instance aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes. We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers. As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment. If the additional data enlarges the request payload to much, we could consider to adopt the request by reference proposal. Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But
Re: [OAUTH-WG] Rechartering
Who is we had already decided? This was not discussed on this list. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, October 20, 2011 10:19 AM To: Richer, Justin P. Cc: OAuth WG; Barry Leiba Subject: Re: [OAUTH-WG] Rechartering Certainly not everyone needs to pay attention to everything. We are, however, trying to determine whether there is a critical mass of interested persons for a given item in terms of reviews, document authors, implementers, and deployers. I do not see a problem at all with working on JWT within the OAuth working group. I thought that we had already decided in the past that the JSON signature encryption work would go into JOES (earlier WOES) and the home for JWT is the OAuth working group. The area directors may have a different opinion but for the moment this is my working assumption. Ciao Hannes On Oct 20, 2011, at 9:30 AM, Richer, Justin P. wrote: I think it will be true that the whole working group won't be focusing on all documents at the same time, much in the same way that different subsets of our current WG have focused on things like the security document or SAML bindings. In this fashion, I believe we'll be able to pull expertise from different sectors to produce a family of documents that live in an ecosystem around OAuth. For many of these documents, even though they're not directly OAuth pieces (like JWT), but where else should they live? This may not be The Way That IETF Does It (I'm honestly not sure), but in my opinion, as long as each document has a dedicated editor and at least some interaction/support with the group we can handle many of these smaller items. -- Justin From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of Barry Leiba [barryle...@computer.org] Sent: Thursday, October 20, 2011 12:05 PM To: OAuth WG Subject: Re: [OAUTH-WG] Rechartering do we have the band width to work on all these items, as some are big and some are fairly small and contained. May have to have some prioritized list of where people think these fit. Yes, exactly. And one of the things we'd like to hear from all of you is what your priorities are... how you would prioritize the list. Barry, chair-like object ___ 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
Re: [OAUTH-WG] Rechartering
This is not how the IETF, or for that matter, any standards body operates. Working groups must be focused with a clearly defined purpose. For example, JWT is a large enough effort and clear enough to form a working group today - just go ahead and propose it. JWT has OAuth binding but it is not part of OAuth. JWT to OAuth is what WebDAV is to HTTP. It is not enough to have critical mass for each document if there isn't a significant overlap in audience across each. Trying to do too much at the same times creates list noise and really forces those with day jobs not dedicated to standards to leave the WG. Bundling efforts makes sense when they are small enough and can be finished in a short period of time. Some of these documents can also live on the list but not become official WG documents. Take a look at HTTPbis - they have a clear charter and set of documents but the list is discussing about a dozen of other individual submissions, some from the editors and chair of the WG, without any problem or heavy handed process. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Richer, Justin P. Sent: Thursday, October 20, 2011 9:31 AM To: Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] Rechartering I think it will be true that the whole working group won't be focusing on all documents at the same time, much in the same way that different subsets of our current WG have focused on things like the security document or SAML bindings. In this fashion, I believe we'll be able to pull expertise from different sectors to produce a family of documents that live in an ecosystem around OAuth. For many of these documents, even though they're not directly OAuth pieces (like JWT), but where else should they live? This may not be The Way That IETF Does It (I'm honestly not sure), but in my opinion, as long as each document has a dedicated editor and at least some interaction/support with the group we can handle many of these smaller items. -- Justin From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of Barry Leiba [barryle...@computer.org] Sent: Thursday, October 20, 2011 12:05 PM To: OAuth WG Subject: Re: [OAUTH-WG] Rechartering do we have the band width to work on all these items, as some are big and some are fairly small and contained. May have to have some prioritized list of where people think these fit. Yes, exactly. And one of the things we'd like to hear from all of you is what your priorities are... how you would prioritize the list. Barry, chair-like object ___ 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
Re: [OAUTH-WG] Rechartering
What possible rational is there for SWD to belong in the OAuth working group and in the security area? EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Thursday, October 20, 2011 12:12 PM To: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] Rechartering Thanks, Hannes. Here's my prioritized list of new work: 1. JSON Web Token (JWT) 2. Simple Web Discovery (SWD) 3. JSON Web Token (JWT) Bearer Token Profile 4. Token Revocation My prioritized list of existing work items to complete after the core and bearer specs are: A. Assertions Specification B. SAML Bearer Token Profile I am ambivalent about whether the working group takes on most of the other work items. Responding to Eran's comments on SWD versus host-meta, these specs have significantly different goals and use substantially different mechanisms with different privacy characteristics. Also, if you compare the relative complexity of the example at http://tools.ietf.org/html/draft-hammer-hostmeta- 17#appendix-A versus the example at http://tools.ietf.org/html/draft-jones- simple-web-discovery-01#section-1, you can see why SWD was chosen for use in OpenID Connect to discover OAuth authorization and resource server endpoints. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, October 19, 2011 10:09 PM To: OAuth WG Subject: [OAUTH-WG] Rechartering Hi all, in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion. We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter. Potential future OAuth charter items (in random order): 1) Dynamic Client Registration Protocol Available document: http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ 2) Token Revocation Available document: http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ 3) UMA Available document: http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ 4) Client Instance Extension Available document: http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt 5) XML Encoding Available document: http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt 6) JSON Web Token Available document: http://tools.ietf.org/html/draft-jones-json-web-token-05 7) JSON Web Token (JWT) Bearer Profile Available document: http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 8) User Experience Extension Available document: http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 9) Request by Reference Available document: http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 10) Simple Web Discovery Available document: http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 We have the following questions: a) Are you interested in any of the above-listed items? (as a reviewer, co- author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item. b) Are there other items you would like to see the group working on? Note: In case your document is expired please re-submit it. Ciao Hannes Barry ___ 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
Re: [OAUTH-WG] Rechartering
We also use HTTP, but we don't discuss it here. OAuth discovery, automation, cross-vendor interop, and dynamic client registration are all part of one big topic. Before we can discuss any particular drafts or proposals, we must first understand the problem space, collect use cases and requirements, and figure out what we are trying to solve. Then we can decide if this is big enough for a new working group or not and charter the work. Once the WG starts working on it, it can decide based on the requirements which technologies to use and SWD can be one option. However, even if an OAuth-related effort decides to use SWD, it is still not the place to work on it. SWD is clearly an Application area work and should be discussed there. EHL -Original Message- From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Thursday, October 20, 2011 12:46 PM To: Eran Hammer-Lahav; Hannes Tschofenig; OAuth WG Subject: RE: [OAUTH-WG] Rechartering Because it's intended for (and used for) discovery of OAuth endpoints... -Original Message- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, October 20, 2011 12:42 PM To: Mike Jones; Hannes Tschofenig; OAuth WG Subject: RE: [OAUTH-WG] Rechartering What possible rational is there for SWD to belong in the OAuth working group and in the security area? EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Thursday, October 20, 2011 12:12 PM To: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] Rechartering Thanks, Hannes. Here's my prioritized list of new work: 1. JSON Web Token (JWT) 2. Simple Web Discovery (SWD) 3. JSON Web Token (JWT) Bearer Token Profile 4. Token Revocation My prioritized list of existing work items to complete after the core and bearer specs are: A. Assertions Specification B. SAML Bearer Token Profile I am ambivalent about whether the working group takes on most of the other work items. Responding to Eran's comments on SWD versus host-meta, these specs have significantly different goals and use substantially different mechanisms with different privacy characteristics. Also, if you compare the relative complexity of the example at http://tools.ietf.org/html/draft-hammer-hostmeta- 17#appendix-A versus the example at http://tools.ietf.org/html/draft-jones- simple-web-discovery-01#section-1, you can see why SWD was chosen for use in OpenID Connect to discover OAuth authorization and resource server endpoints. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, October 19, 2011 10:09 PM To: OAuth WG Subject: [OAUTH-WG] Rechartering Hi all, in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion. We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter. Potential future OAuth charter items (in random order): 1) Dynamic Client Registration Protocol Available document: http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ 2) Token Revocation Available document: http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ 3) UMA Available document: http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ 4) Client Instance Extension Available document: http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt 5) XML Encoding Available document: http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt 6) JSON Web Token Available document: http://tools.ietf.org/html/draft-jones-json-web-token-05 7) JSON Web Token (JWT) Bearer Profile Available document: http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 8) User Experience Extension Available document: http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 9) Request by Reference Available document: http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 10) Simple Web Discovery Available document: http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 We have the following questions: a) Are you interested in any of the above-listed items? (as a reviewer, co- author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item. b) Are there other items you would like to see the group working on? Note: In case your document is expired please re-submit it. Ciao Hannes Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions
I don't think defining them as URI's is helpful here. But the set must be inclusive of URI characters. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Marius Scurtescu Sent: Wednesday, October 19, 2011 10:31 AM To: Mike Jones Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions On Wed, Oct 19, 2011 at 10:26 AM, Mike Jones michael.jo...@microsoft.com wrote: Yes, it covers all the characters legal in URIs. Per earlier discussion on the list, scopes are not restricted to being URIs, as existing practice includes scope elements that are not URIs such as email profile, and openid. All those simple words are URIs. They are relative URIs (just the path), but URIs nonetheless. Marius -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Marius Scurtescu Sent: Wednesday, October 19, 2011 10:24 AM To: Julian Reschke Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions Marius On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke julian.resc...@gmx.de wrote: On 2011-10-18 17:38, Eran Hammer-Lahav wrote: Space is allowed inside a quoted string and is already not allowed inside each scope string. EHL ... a) yes. b) well: The value of the scope parameter is expressed as a list of space- delimited, case sensitive strings. The strings are defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. That certainly implies that you can't have a space inside a token, but it could be clearer. Optimally, state the character repertoire precisely: scopetokenchar = %x21 / %x23-5B / %x5D-7E ; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII ? Is this covering all characters allowed in a URI? Why not define scopes as a list of URIs? Best regards, Julian ___ 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
Re: [OAUTH-WG] Rechartering
No-brainer, low-hanging-fruit: 2) Token Revocation 8) User Experience Extension Don't see the point, but simple enough not to care if plenty of others want to see it included: 4) Client Instance Extension 5) XML Encoding 9) Request by Reference Now for the objectionable... 1) Dynamic Client Registration Protocol This is premature standardization and must be deferred until we have enough real world experience and real world requirements. Since we don't have enough interoperable web protocols (e.g. sharing photos), there is little need for dynamic client registration at this point. Doing this wrong would be extremely costly. We have tried this multiple times with OAuth 1.0 and failed because there was no one at the table shipping real-world products that needed this functionality. 3) UMA This is big enough, and complex enough, for its own working group and list (which I thought it already had elsewhere). Does not belong here. It is a layer above OAuth, not part of it. 6) JSON Web Token 7) JSON Web Token (JWT) Bearer Profile This is big enough for its own working group and list. It also overlaps with the new JSON signature working group recently created. 10) Simple Web Discovery First, this clearly does not belong here. This is a classic Application area item, and should really be raised in the application area general WG. I'd also point out that the IESG has recently approved the publication of host-meta as a proposed standard and the latest version includes a JSON flavor which makes this work redundant. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, October 19, 2011 10:09 PM To: OAuth WG Subject: [OAUTH-WG] Rechartering Hi all, in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion. We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter. Potential future OAuth charter items (in random order): 1) Dynamic Client Registration Protocol Available document: http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ 2) Token Revocation Available document: http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ 3) UMA Available document: http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ 4) Client Instance Extension Available document: http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt 5) XML Encoding Available document: http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt 6) JSON Web Token Available document: http://tools.ietf.org/html/draft-jones-json-web-token-05 7) JSON Web Token (JWT) Bearer Profile Available document: http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 8) User Experience Extension Available document: http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 9) Request by Reference Available document: http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 10) Simple Web Discovery Available document: http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 We have the following questions: a) Are you interested in any of the above-listed items? (as a reviewer, co- author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item. b) Are there other items you would like to see the group working on? Note: In case your document is expired please re-submit it. Ciao Hannes Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions
Space is allowed inside a quoted string and is already not allowed inside each scope string. EHL -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Tuesday, October 18, 2011 6:50 AM To: Eran Hammer-Lahav Cc: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions On 2011-10-17 20:53, Eran Hammer-Lahav wrote: All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding and \ so no escaping is needed, ever. You also need to have one character reserved as delimiter for multiple scopes inside quoted-string, so is SP out? Best regards, Julian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-v2-22
Sending to the right place. On Oct 18, 2011, at 20:36, qijun83 qiju...@gmail.commailto:qiju...@gmail.com wrote: Dear Sir, It's really very pleasure for me to write to you for asking some questions about oauth-v2-22 as follows. In section 2.3 (Client Authentication), it is recommended to use the HTTP Basic authentication scheme like Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW, which is included of user_id and password as defined in [RFC2617http://tools.ietf.org/html/rfc2617], instead of using the parameters of client_id and client_secret in HTTP request body. I want to know, (1). whether user_id equals to client_id, and password equals to client_secret. (2). and whether it is allowed to use both of the HTTP Basic authentication scheme and the client credentials in the request body at the same time. Looking forward to hearing from you. Yours, sincerely Qijun Zhang ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions
I agree. EHL -Original Message- From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Monday, October 17, 2011 6:07 AM To: Richer, Justin P. Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions The scopes cross all of the profiles. I expect that restricting the character sets for bearer tokens, MAC, and other future variants should be dealt with in those profiles. Without restricting scope in core, we leave the possibility of coming up with different rules in different profiles e.g. MAC vs Bearer. It is probably best to have one rule in core that works across all the profiles. John B. On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: I think the limit makes sense, but then are tokens limited by the same rules? They need to live in all the same places (query parameters, headers, forms) that scopes do and would be subject to the same kinds of encoding woes that scopes will. Or am I missing something obvious as to why this isn't a problem for tokens (both bearer tokens and the public part of MAC tokens) but is a problem for scope strings? -- Justin From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of John Bradley [ve7...@ve7jtb.com] Sent: Sunday, October 16, 2011 8:11 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions Restricting it now in the core spec is going to save a lot of headaches later. John B. On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: It's an open question for the list. EHL -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Sunday, October 16, 2011 11:00 AM To: Mike Jones Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG; Eran Hammer-Lahav Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions On 2011-10-16 18:44, Mike Jones wrote: As Eran wrote on 9/30, The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs. ... I see. Thanks. Is this going to be clarified in -23? Best regards, Julian ___ 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
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions
All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding and \ so no escaping is needed, ever. EHL -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Monday, October 17, 2011 8:25 AM To: Eran Hammer-Lahav Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions It is good that we have an agreement among a few people that more text needs to be provided in the core specification on the issue of the scope element. Now, there is still the question of what the text should say. The questions from my earlier mails are therefore still applicable and need an answer. Ciao Hannes On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote: I agree. EHL -Original Message- From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Monday, October 17, 2011 6:07 AM To: Richer, Justin P. Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions The scopes cross all of the profiles. I expect that restricting the character sets for bearer tokens, MAC, and other future variants should be dealt with in those profiles. Without restricting scope in core, we leave the possibility of coming up with different rules in different profiles e.g. MAC vs Bearer. It is probably best to have one rule in core that works across all the profiles. John B. On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: I think the limit makes sense, but then are tokens limited by the same rules? They need to live in all the same places (query parameters, headers, forms) that scopes do and would be subject to the same kinds of encoding woes that scopes will. Or am I missing something obvious as to why this isn't a problem for tokens (both bearer tokens and the public part of MAC tokens) but is a problem for scope strings? -- Justin From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of John Bradley [ve7...@ve7jtb.com] Sent: Sunday, October 16, 2011 8:11 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions Restricting it now in the core spec is going to save a lot of headaches later. John B. On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: It's an open question for the list. EHL -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Sunday, October 16, 2011 11:00 AM To: Mike Jones Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG; Eran Hammer-Lahav Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions On 2011-10-16 18:44, Mike Jones wrote: As Eran wrote on 9/30, The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs. ... I see. Thanks. Is this going to be clarified in -23? Best regards, Julian ___ 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
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions
It's an open question for the list. EHL -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Sunday, October 16, 2011 11:00 AM To: Mike Jones Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG; Eran Hammer-Lahav Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions On 2011-10-16 18:44, Mike Jones wrote: As Eran wrote on 9/30, The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs. ... I see. Thanks. Is this going to be clarified in -23? Best regards, Julian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions
This is not sufficient. For scope, if you are going to restrict the allowed characters, you must either specify how to encode all other values to fit the field, or we must move this restriction to the v2 specification so that no encoding is required. For the token, you need to also define allowed token values so that they will fit in the header without encode, or specify an encoding scheme. The MAC token restricts token values (called MAC identifier) to %x20-21 / %x23-5B / %x5D-7E (any printable ASCII character except for and \). EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, October 14, 2011 8:43 AM To: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions Thanks for the useful discussion and the write-up, Hannes. For context, Hannes and I discussed how to resolve the remaining Bearer spec issues in a manner that meets the needs of implementations and will not generate objections during the IESG or IETF Last Call reviews. A few additional comments... 1. Error Description - Nothing to add to Hannes' write-up. 2. Scope - I was planning to allow a broader set of ASCII characters than the token set, as these characters are inadequate for the use of URIs/URLs as scope elements. In particular, scope elements need to permit the full sets of reserved http://tools.ietf.org/html/rfc3986#section-2.2 and unreserved http://tools.ietf.org/html/rfc3986#section-2.3 characters in RFC 3986http://tools.ietf.org/html/rfc3986. The draft I am working on will say that scope is a space separated set of elements, where the elements consist of one or more characters from the union of the reserved and unreserved sets. 3. Authorization Request Header Field - We agreed on the call that we're not doing implementers any favors by allowing both the b64token and #auth-param syntaxes, and that it is better to specify one or the other. Since existing practice corresponds to the b4token syntax, the choice is clear which to specify. Thus, it was a mistake to introduce the #auth-param choice in draft 9. It will be removed in draft 10, which is shortly forthcoming. -- Mike -Original Message- From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Friday, October 14, 2011 5:25 AM To: OAuth WG Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions Hi all, I had a discussion with Mike and Julian to hear what to discuss the open issues with the OAuth Bearer Token draft. Below is a short writeup of my impressions. 1. Error Description The error description field provides information to the software developer and is not meant to be shown to the end user. As such, there is no desire to provide internationalization support for this field. Hence, it has a similar characteristic as the HTTP 'Reason-Phrase. http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#reason.phrase says The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A client SHOULD ignore the content of the Reason Phrase. Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) We can use something similar for the error description field and even simplify it further by omitting HTAB and obs-text: error-desc = error_description = *( SP / VCHAR ) 2. Scope The scope field is yet another item that will not be shown to the user and it serves the purpose of an identifier for authorization comparison. So, we don't need to have any internationalization support here either. The suggestion is to re-use the 'token ABNF syntax from the HTTP spec: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.3 3. Authorization Request Header Field Finally, there is the authorization request header field where we have to decide how we want to deal with extensions. The current specification says: credentials = Bearer 1*SP ( b64token / #auth-param ) This means that we can have either a base64 opaque blob or a parameter like syntax (but not both). An example of the b64token is Authorization: Bearer vF9dft4qmT and an example of the auth-param usage is Authorization: Bearer t=vF9dft4qmT With an opaque blob extensibility is limited and for this reason, I guess, Mike had provided the additional option of auth-parameter. If we want to allow extensibility then we have to go for the auth-param approach. If we only use the auth-param (without the b64token) then there may be an issue with already existing
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions
Relying on b64token is not enough because you are only restricting the header syntax, not the other methods. Also, you are not restricting the server from issuing other values, in which case the client will need to figure out how to use the header with those values. My point is that you need to explicitly define the allowed range for tokens. Saying they must comply with the b64token rule is enough, just not enough to leave it implied via the header definition. EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Friday, October 14, 2011 9:51 AM To: Eran Hammer-Lahav; Hannes Tschofenig; OAuth WG Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions I am fine with this scope character set restriction also being added to the core spec. As to your second comment, you'll find that the b64token definitionhttp://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.1 already provides a character set restriction (as you suggest is needed). -- Mike From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Sent: Friday, October 14, 2011 8:55 AM To: Mike Jones; Hannes Tschofenig; OAuth WG Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions This is not sufficient. For scope, if you are going to restrict the allowed characters, you must either specify how to encode all other values to fit the field, or we must move this restriction to the v2 specification so that no encoding is required. For the token, you need to also define allowed token values so that they will fit in the header without encode, or specify an encoding scheme. The MAC token restricts token values (called MAC identifier) to %x20-21 / %x23-5B / %x5D-7E (any printable ASCII character except for and \). EHL From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, October 14, 2011 8:43 AM To: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions Thanks for the useful discussion and the write-up, Hannes. For context, Hannes and I discussed how to resolve the remaining Bearer spec issues in a manner that meets the needs of implementations and will not generate objections during the IESG or IETF Last Call reviews. A few additional comments... 1. Error Description - Nothing to add to Hannes' write-up. 2. Scope - I was planning to allow a broader set of ASCII characters than the token set, as these characters are inadequate for the use of URIs/URLs as scope elements. In particular, scope elements need to permit the full sets of reserved http://tools.ietf.org/html/rfc3986#section-2.2 and unreserved http://tools.ietf.org/html/rfc3986#section-2.3 characters in RFC 3986http://tools.ietf.org/html/rfc3986. The draft I am working on will say that scope is a space separated set of elements, where the elements consist of one or more characters from the union of the reserved and unreserved sets. 3. Authorization Request Header Field - We agreed on the call that we're not doing implementers any favors by allowing both the b64token and #auth-param syntaxes, and that it is better to specify one or the other. Since existing practice corresponds to the b4token syntax, the choice is clear which to specify. Thus, it was a mistake to introduce the #auth-param choice in draft 9. It will be removed in draft 10, which is shortly forthcoming. -- Mike -Original Message- From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Friday, October 14, 2011 5:25 AM To: OAuth WG Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues Proposed Resolutions Hi all, I had a discussion with Mike and Julian to hear what to discuss the open issues with the OAuth Bearer Token draft. Below is a short writeup of my impressions. 1. Error Description The error description field provides information to the software developer and is not meant to be shown to the end user. As such, there is no desire to provide internationalization support for this field. Hence, it has a similar characteristic as the HTTP 'Reason-Phrase. http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#reason.phrase says The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A client SHOULD ignore the content of the Reason Phrase. Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) We can use
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments
Not that I will ever use this, but this is really broken way to create a protocol. Now is the time to make hard choices and pick one format. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, October 12, 2011 11:39 AM To: Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments One possible syntax is: Bearer access_token=xyz_-123,more_info=pdq Ultimately though, the format of the bearer token is outside of the scope of the spec, and up to the participants to determine, including whether to use b64token syntax or params syntax. -- Mike -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Wednesday, October 12, 2011 11:35 AM To: Mike Jones Cc: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments On 2011-10-12 20:26, Mike Jones wrote: Because b64token is existing practice ... include-disclaimer-about-maturity-of-internet-drafts/ Anyway, how do you then send credentials that include the bearer token plus additional parameters? Example, please. Best regards, Julian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Possible alternative resolution to issue 26
I agree with this analysis and its conclusions. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Manger, James H Sent: Sunday, October 02, 2011 5:51 AM To: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 The best solution is to drop the scope field from the WWW-Authenticate: Bearer ... response header. scope is relevant to an OAuth2-core flow, not to presenting a bearer token. scope could make sense in a WWW-Authenticate: OAuth2 ... response header as long as other necessary details such as an authorization URI were also provided. Dropping scope and error_description (as the error should be described in the response body) would eliminate these encoding problems. If the group really wants to keep scope, I don't think RFC 5987 is a good solution. RFC 5987 might have been ok for adding internationalization support to long-standing ASCII-only fields in a world of multiple character sets - but none of that applies here. Having to change the field name from scope to scope* when you have a non-ASCII value is the biggest flaw. The simplest solution is to explicitly restrict scope values to some subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly disappointing, but I can live with it. My preferred escaping solution would be a JSON string, UTF-8 encoded: json.org, RFC 4627; value in double-quotes; slash is the escape char; supports Unicode; eg scope=coll\u00E8gues. This is backward-compatible with HTTP's quoted-string syntax. It is forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is well-supported (and required for other OAuth2 exchanges). [I might suggest json-string to the httpbis group as a global replacement for quoted-string (or at least as a recommendation for new fields).] -- James Manger From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, 30 September 2011 4:53 AM To: oauth@ietf.orgmailto:oauth@ietf.org Subject: [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII characters in scope strings than had previously been in evidence. If we decide to define a standard representation for doing so, using RFC 5987http://tools.ietf.org/html/rfc5987 (Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the clear choice. I'd be interested in knowing how many working group members are in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying UTF-8 encoding of the error_description value, requesting the use of RFC 5987 encoding instead. I'd also be interested in knowing how many working group members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description parameter. (As editor, I would make the observation that if we choose RFC 5987 encoding for either of these parameters, it would be logical to do so for the other one as well.) In the interest of finishing the specification in a way that meets everyone's needs, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Possible alternative resolution to issue 26
Two observations: - I doubt anyone is going to implement RFC 5987 in most OAuth 2.0 libraries, mostly because it offers little value and, - No one really needs scope values other than limited ASCII or URIs There should not be any interoperability issues with the error_description value as long as it is valid for HTTP transport because it is for debugging only. If a provider returns some other character set than plain ASCII in there, it is safe to assume the developer will figure it out. The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs. Crossing the boundaries of v2 into the bearer spec is the first place where this flexibility has been tested. Scope are machine-readable strings and URIs already provide a way to include internationalization. OAuth parameters are all in English and it is reasonable to expect most providers to craft their scope values within those undeclared boundaries. I am not expressing a strong opinion because I don't think this is a real issue. Internationalization matters when it comes to end-user interaction, not developers. But the most consistent choice based on the past 2 years of use cases and examples is to simply limit the scope character-set in v2 and avoid all this. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, September 30, 2011 8:20 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 Thus far, I've received no responses preferring 1 or 2 or preferring A or B. Could people please weigh in so that the working group has data to base a decision on to close this issue? Thanks, -- Mike From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Thursday, September 29, 2011 11:53 AM To: oauth@ietf.orgmailto:oauth@ietf.org Subject: [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII characters in scope strings than had previously been in evidence. If we decide to define a standard representation for doing so, using RFC 5987http://tools.ietf.org/html/rfc5987 (Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the clear choice. I'd be interested in knowing how many working group members are in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying UTF-8 encoding of the error_description value, requesting the use of RFC 5987 encoding instead. I'd also be interested in knowing how many working group members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description parameter. (As editor, I would make the observation that if we choose RFC 5987 encoding for either of these parameters, it would be logical to do so for the other one as well.) In the interest of finishing the specification in a way that meets everyone's needs, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Authorization code use in draft-ietf-oauth-v2-21
On Sep 9, 2011, at 15:31, André DeMarre andredema...@gmail.com wrote: Greetings Everyone, I hope the draft isn't too far along for these comments. (draft-ietf-oauth-v2-21) 1. AUTHORIZATION CODE RESTRICTIONS The specification (particularly Section 4.1) does not say if the authorization server may or may not allow an authorization code to be used more than once in exchange for an access token. (Section 4.1.3) With this ambiguity, some authorization server implementations might allow authorization codes to be reused by the client (whether intentionally or not). I don't see any benefit in allowing this and think it should be forbidden for several reasons. Allowing this enables a scenario where an authorization code may be reused when the client should use the refresh token instead. The refresh token has more desirable security properties. The usefulness of authorization codes should be restricted wherever possible because they are revealed to resource owners and can be sent over unsecure connections when the client does not require TLS on its redirection URI. These properties combined with the possibility that the authorization code flow may be used by public clients might open more severe attack vectors. I think it should be clearly stated that the authorization server MUST NOT issue more than one access token per authorization code grant. An authorization code should be discarded after its first use and new access tokens should only be issued when exchanged for refresh tokens. Tweaked the code description slightly: REQUIRED. The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD attempt to revoke all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI. 2. AUTHORIZATION CODE VS. TOKEN? Much less important, and please forgive me if this has already been discussed, but why isn't the authorization code called an authorization token? It is similar to the refresh token in that it can be presented in exchange for an access token at the token endpoint. I see it as another type of token and wonder if the language used should perhaps reflect that as well. It's bad enough the refresh token uses 'token'. Adding another 'token' will be too confusing. 3. GRAMMAR CORRECTION IN SECTION 10.12 In Section 10.12 paragraph three it says (e.g. a hash of the session cookie used to authentication the user-agent). This should say authenticate instead of authentication. Thanks, EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Typo in Sec 5.1
Thanks. Fixed in a few other places too. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Paul Madsen Sent: Monday, September 12, 2011 1:30 PM To: oauth@ietf.org Subject: [OAUTH-WG] Typo in Sec 5.1 scope OPTIONAL. The scope of the access request as described by Section 3.3http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-3.3. presumably this should be 'access token' paul ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Typos and language in -21
Thanks. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Niv Steingarten Sent: Monday, September 12, 2011 2:01 PM To: OAuth WG Subject: [OAUTH-WG] Typos and language in -21 In section 10.12 (CSRF): 5th paragraph: A CSRF attack against the against the authorization server's authorization endpoint One against the is redundant. 4th paragraph: The binding value enables the client to validate the validity of the request by matching the binding value to the user-agent's authenticated state. The phrase validate the validity of the request sounds a bit awkward in my opinion. I'd personally go with either establish the validity of the request or simply validate the request. -- Niv ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Section 4.3. Resource Owner Password Credentials: Invalid Credentials Error Handling
'invalid_grant'. Added (e.g.) to the error code to make it more explicit.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Colm Divilly
Sent: Tuesday, September 13, 2011 9:08 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Section 4.3. Resource Owner Password Credentials:
Invalid Credentials Error Handling
Apologies if this has been covered before, a cursory search of the archives
and issue tracker didn't turn up anything.
What is the expected error response when performing a Resource Owner
Password Credentials flow, if the resource owner provides incorrect
credentials?
From reading the spec it looks like the expectation is that a response like
the
following should be generated:
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
error:invalid_request
}
Which is not terribly helpful for a user-agent trying to determine that it is
the
user supplied credentials at fault (and therefore be able to re-prompt the
user for credentials). Perhaps something like the following would be more
useful:
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
error:invalid_resource_owner_credentials
}
A bit verbose perhaps, any alternative suggestions?
Regards,
Colm Divilly
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 v21 Nits and Typos
Thanks. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Anganes, Amanda L Sent: Monday, September 19, 2011 8:23 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth 2.0 v21 Nits and Typos Lots of minor grammar and wording catches here. I apologize if any of these were already brought up and addressed. 1.2.3, second paragraph: When issuing an implicit grant, the authorization server does not authenticate the client and in some cases, the client identity can be verified... should be When issuing an implicit grant, the authorization server does not authenticate the client. In some cases, the client identity can be verified... 1.5, first paragraph. Last sentence should be changed to Issuing a refresh token is optional. If an authorization server issues a refresh token, it is included when issuing an access token. 2.1, definition of public client: last sentence ends with via any other mean which should be via any other means. 2.1, definition of native applications: On the other hand, dynamically issued credentials such as access tokens or refresh tokens, can receive an acceptable level of protection should be On the other hand, dynamically issued credentials such as access tokens or refresh tokens can receive an acceptable level of protection (final comma is unnecessary). 3.1, second paragraph. Add a comma after beyond the scope of this specification, so it reads The means through which the client obtains the location of the authorization endpoint are beyond the scope of this specification, but the location is typically provided in the service documentation. 3.2.1, first sentence. Unnecessary comma between requirements and MUST; should read Confidential clients, clients issued client credentials, or clients assigned other authentication requirements MUST authenticate... 4.1, section (E): last sentence is missing a subject. If valid, responds back with an... should read If valid, the authorization server responds back with an... 4.1.2 and 4.1.2.1, also 4.2.2 and 4.2.2.1, state description: last sentence is missing a MUST. Should read REQUIRED if the state parameter was present in the client authorization request. The state parameter MUST be set to the exact value received from the client. 4.1.3, redirect_uri description: Change REQUIRED, if the redirect_uri parameter was included in the authorization request described in Section 4.1.1, and their values MUST be identical to REQUIRED, if the redirect_uri parameter was included in the authorization request as described in Section 4.1.1. If included, the two values MUST be identical. 4.1.3, final paragraph (The authorization server MUST: ...). Is any additional normative language required for lists such as this in order to specify that the AS must do ALL of the items in the list? Similar MUST lists appear elsewhere throughout the rest of the document. The entire list is required. Also, final bullet should be reworded; suggest ensure that the redirect_uri parameter is present if the redirect_uri parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical. 4.2, first paragraph: clarify that implicit grants can be used only for access tokens by including the word only here: The implicit grant type is used to obtain access tokens only... That might not be accurate with extensions. 4.3.2, paragraph after term parameter descriptions: If the client type is confidential or was issued client credentials should be reworded to If the client type is confidential or the client was issued client credentials. 9, bullets following second paragraph: Change this to a definition list format instead of a bulleted list. This is not definitions. 9, final bullet following when choosing between an external or embedded user-agent...: Last sentence starts Embedded user-agent educate... but should be Embedded user-agents educate... 10.2, second paragraph: last sentence is a fragment. Reword to For example, the authorization server should engage the resource owner to assist in identify the client and its origin. 10.5, second paragraph, first sentence: extraneous comma between authorization server and is. Should be ...verify that the resource owner who granted authorization at the authorization server is the same resource owner... 10.6, last paragraph, first sentence: extraneous comma between authorization code and is the same. Should be ... the authorization server MUST ensure that the redirection URI used to obtain the authorization code is the same as the redirection URI provided ... Last sentence should be reworded; suggest The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. If a redirection URI is provided in the authorization request, the authorization server
Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2
(+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. EHL -Original Message- From: Leif Johansson [mailto:le...@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_ 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. What sections? That's the only place these roles are defined. As an illustration of an alternative model for the authorization server maybe an informative reference to UMA would be illustrative here. A reference to UMA would be confusing in this document. 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). Changed to: (A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary. 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. Changed to: (i.e. username and password) This is explicitly just for username and password. Other types require an extension. 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. There is not requirement for the string to be opaque, but the general architecture assumes it is. Otherwise, please suggest language. 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. Simpler architecture 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 language here - there are security implications of allowing a refresh token to get more permissions (say) than the original access token. This was discussed before and we could not reach consensus. 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... These are the best terms we could come up with. Not intuitive but well defined. 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
Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2
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
Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2
This will go into the IETF LC feedback loop. EHL -Original Message- From: André DeMarre [mailto:andredema...@gmail.com] Sent: Tuesday, September 20, 2011 7:12 PM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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-ide a/] 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
Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt
Just a general note: you don't need every spec to become a working group item. If you get an area director to sponsor your draft, you can push it through sooner as an individual submission. Sometimes you don't even need sponsorship. I'm not saying this out of any objection to the WG taking on this work, just that I don't see a reason to wait. If you feel this simple document is ready and has consensus, you should find a sponsor and move to IETF LC. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Marius Scurtescu Sent: Monday, September 19, 2011 11:48 AM To: Chuck Mortimore Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt +1 On Fri, Sep 16, 2011 at 1:06 PM, Chuck Mortimore cmortim...@salesforce.commailto:cmortim...@salesforce.com wrote: If it's not already implicit by our implementation, I'm voicing our support for this becoming a working group item. - cmort On Sep 16, 2011, at 12:31 PM, Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net wrote: Hi all, I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec. We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom. regards, Torsten. Original-Nachricht Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Datum: Fri, 16 Sep 2011 12:20:14 -0700 Von: internet-dra...@ietf.orgmailto:internet-dra...@ietf.org An: tors...@lodderstedt.netmailto:tors...@lodderstedt.net CC: sdro...@gmx.demailto:sdro...@gmx.de, tors...@lodderstedt.netmailto:tors...@lodderstedt.net, mscurte...@google.commailto:mscurte...@google.com A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. Filename:draft-lodderstedt-oauth-revocation Revision:03 Title: Token Revocation Creation date: 2011-09-16 WG ID: Individual Submission Number of pages: 6 Abstract: This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Is this malicious piece of software external a native application either past of a native client or external to the browser? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 6:51 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal browser and perform an authorization flow with the resource owner for one particular scope. Using the same browser instance and based on the cookies obtained in the first run, it could silently perform additional authorization flows for other scopes. 4) internal browser (non-interactive authentication methods) - There are authentication methods available w/o the need for user-interaction, for examples SIM card authentication or certificate-based authentication. The attacker could utilize an internal, invisible browser instance in combination with such an authentication method in order to perform
Re: [OAUTH-WG] Nit: Language in section 1.1
I have no objection, but much clearer? :-) EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, September 14, 2011 6:04 AM To: Greg Brail Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Nit: Language in section 1.1 +1, this wording is much clearer to me, too -- justin On Tue, 2011-09-13 at 19:25 -0400, Greg Brail wrote: This part of section 1.1 is confusing to me and I stumble whenever I read it – I see that Brian Eaton suggested looking at it a while back but I don’t think it got changed: “OAuth includes four roles working together to grant and provide access to protected resources - access restricted resources requiring authentication:” I would suggest something simpler, such as: “OAuth includes four roles that work together to grant and provide access to protected resources that require authentication.” Gregory Brail | Technology | Apigee | +1-650-937-9302 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I suggest we address this particular scenario in the thread model document. EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 7:26 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) It is a native app and it is external wrt the browser. regards, Torsten. On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote: Is this malicious piece of software external a native application either past of a native client or external to the browser? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 6:51 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead
Re: [OAUTH-WG] Authorization code use in draft-ietf-oauth-v2-21
Sending to the right address. EHL On Sep 9, 2011, at 15:31, André DeMarre andredema...@gmail.com wrote: Greetings Everyone, I hope the draft isn't too far along for these comments. (draft-ietf-oauth-v2-21) 1. AUTHORIZATION CODE RESTRICTIONS The specification (particularly Section 4.1) does not say if the authorization server may or may not allow an authorization code to be used more than once in exchange for an access token. (Section 4.1.3) With this ambiguity, some authorization server implementations might allow authorization codes to be reused by the client (whether intentionally or not). I don't see any benefit in allowing this and think it should be forbidden for several reasons. Allowing this enables a scenario where an authorization code may be reused when the client should use the refresh token instead. The refresh token has more desirable security properties. The usefulness of authorization codes should be restricted wherever possible because they are revealed to resource owners and can be sent over unsecure connections when the client does not require TLS on its redirection URI. These properties combined with the possibility that the authorization code flow may be used by public clients might open more severe attack vectors. I think it should be clearly stated that the authorization server MUST NOT issue more than one access token per authorization code grant. An authorization code should be discarded after its first use and new access tokens should only be issued when exchanged for refresh tokens. 2. AUTHORIZATION CODE VS. TOKEN? Much less important, and please forgive me if this has already been discussed, but why isn't the authorization code called an authorization token? It is similar to the refresh token in that it can be presented in exchange for an access token at the token endpoint. I see it as another type of token and wonder if the language used should perhaps reflect that as well. 3. GRAMMAR CORRECTION IN SECTION 10.12 In Section 10.12 paragraph three it says (e.g. a hash of the session cookie used to authentication the user-agent). This should say authenticate instead of authentication. Regards, Andre DeMarre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] problem statement
Michael, I suggest you go back and read the entire thread again: http://www.ietf.org/mail-archive/web/oauth/current/maillist.html I don't think you have been listening to the 11 (!) people who all completely disagree with you and dismiss your suggestions (on technical grounds). The one person who supported your plea didn't actually make any technical contribution. If anyone wants to make accusations about behaving like adults, that should be the 11 people who tried to explain why you are simply wrong and were completely ignored by you. Any perceived hostility is easily justified by having to explain the same thing over and over again to someone who refuses to list and insists on labeling this work as lacking and insecure. We take real security pretty seriously here. You asked a question as someone very new to thinking about this problem space and was answered by experts. The fact that you refuse to accept their answers is while being , at this point, your problem. You were given multiple opportunities to present an alternative text and technical justification to support it, but refused to do so. You might not like my tone, but I consider making a statement like this: In fact, you guys have convinced me that OAuth gives inferior protection at considerable expense for all concerned. an irresponsible and serious offense - the kind of baseless FUD that can cause real damage to important work. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] problem statement
Melinda, We clearly have different views on what it means to [deal] with this like an adult. I would like to address what I *think* were your two main points: the lack of civility in addressing the feedback provided by Mr. Thomas, and the alleged IETF process violation by me as editor. I have not seen any actual technical argument coming from you in support of this change other than 'why not'. While the 11 people who replied to this thread did dismiss the claim and the need to address it, the conversation was pretty calm and polite. I suggest you go back and read the entire thread: http://www.ietf.org/mail-archive/web/oauth/current/maillist.html Any hints of hostility you find can be justly explained by the frustration of trying to talk to someone who refuses to listen and insists on making a change that everyone else objects to. Given that this is a technical working group, I can safely state that this objection was unanimous based on technical arguments. Process-wise, we are operating under clear and explicit directions from the chairs to only consider changes to the document based on *proposed text* and consensus. As editor, it is completely within my authority to dismiss proposals and changes not matching the criteria set by the chairs, and it is my stated responsibility to reject changes where there clearly is no consensus. While the chairs can change their instructions, someone still has to provide text, which is the only way you can reach consensus. And for the record, in this case, there is clear cut IETF consensus not to make any changes (1 in support, 11 against, and 1 'why not'). That's a close as the IETF gets to unanimity. I agree that the editor is not empowered to make such final declarations, but everyone is free to make that observation, including the editor. I have never refused to make a change in face of clear guidance from the chairs, nor have I ever suggested I have the authority to make such final calls. I find that suggestion disrespectful to my unparalleled contribution to this work over 4 years. Your entire argument is basically 'why not, it's only a few lines in the introduction'. I find this both counter-productive and harmful. The suggested change boils down to explaining to the reader that installing untrusted clients on a user device can have wide repercussions to the security properties of this protocol. But such a claim is both obvious (to everyone but one) and incomplete. It is the incompleteness part that most people objected to, and the fact that any attempt at a comprehensive text would mean significant and open-ended delay. The number of potential ways for malicious code to find its way onto a user device are practically unlimited, and every single one of them will lead to the same security degradation described in this thread. There are certain things we have to take for granted when writing a specification like this. One of them is the reader's understanding that there are many factors outside the scope of the protocol, and malware is one of the most obvious factors. I am completely serious when I say that earthquakes (as suggested jokingly by others) present equal thread to the security model of this protocol because the user hand might shake when trying to deny client access and hitting the approve button instead. So following your login, why not discuss the potential impact of a physical disruption to the user interaction with the authorization endpoint? I am dead serious as I consider the two threats to be of equal relevance to this document. There are many examples of over-specification causing more harm than good and this is clearly one of those cases. 'Why not' is never an acceptable argument for making changes, especially at this stage and for a security protocol. I would also note that every example you tried to give for why accommodating this is the right thing based on past protocols was proved to be misleading or misguided. I would also note that the proposed changes (guessing based on the information provided in lieu of actual text) will not result in *any* actionable result by anyone, if only because there is nothing to do about it other than educate users not to install untrusted software of any kind on any device. Trying to portray the answer below as a more adult response is interesting. If you note, no one actually suggested we change the security thread model document, only that it provides a comprehensive description of the protocol. I am pretty sure most WG participants will still object to this change made in that document for the same reasons. As editor, I consider this matter closed and will not make any changes based on the information presented. You are free ask the chairs to open an issue block the progress of the draft until this is resolved to your satisfaction. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
You can revoke access tokens but only if they are Stateful (which usually means a DB lookup for every API call which doesn’t scale as well). EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phillip Hunt Sent: Wednesday, September 07, 2011 4:24 PM To: William Mills Cc: Quizlet Dev Team; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill From: Dave Rochwerger da...@quizlet.commailto:da...@quizlet.com To: oauth@ietf.orgmailto:oauth@ietf.org Cc: Quizlet Dev Team devt...@quizlet.commailto:devt...@quizlet.com Sent: Wednesday, September 7, 2011 2:15 PM Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the authorization code flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). Our architecture: * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). Questions: 1. Given the above scenario, what use are refresh tokens? - Access tokens can not leak because every request (to resource and authz server) containing an access token is done over SSL. We control both the authz and resource servers, so tokens in logs (and other suggested reasons in the archives) are not an issue. - Long-lived refresh tokens and short-lived access tokens are supposed to provide security due to possible access token leakage... but in our 100% SSL scenario, if access tokens are able to leak, then so would the client id, secret and refresh token. - Having a long-lived refresh token that can be exchanged for another access token adds a level of complexity (a second HTTPS request every so often) and seems to provide no benefit for our case. 2. What is the point of the client secret (in our scenario)? - We originally were treating the clients as confidential, but after re-reading the native-application section, it seems we really should treat them as public (phone apps can be decompiled and the secret discovered). - The spec says that the authz server should authenticate confidential clients, but public clients are allowed to just send their public client id (and no secret). - The only verification
Re: [OAUTH-WG] problem statement
I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. EHL On Sep 6, 2011, at 11:10, Igor Faynberg igor.faynb...@alcatel-lucent.com wrote: Mike, You've got the problem statement right: allowing the user to authorize resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth. I do not think though that it is related to OAuth per se. To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks. From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment. There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView. If I am wrong, I would appreciate a detailed description of what happened. Igor On 9/6/2011 1:40 PM, Michael Thomas wrote: Hi all, Barry suggested that I might subscribe and explain what I sent him. My basic problem is that in neither the protocol nor the threats drafts, I can't seem to find what problem is actually trying to be solved with oauth, and what assumptions you're making about various elements. Here's what I did. I've written an app, and I wanted re-integrate the ability to send tweets after they deprecated Basic. So the app has a webView (android, iphone...) which it obviously completely controls. With oauth, the webview UA will ultimately redirect off to Twitter's site to collect the user's credentials and grant my app's backend an access token (sorry if I get terminology screwed up, i'm just coming up to speed). What occurs to me is that webview affords exactly zero protection from my client (ie, the app) from getting the user's twitter credentials. All I have to do is set up a keypress handler on that webview and in a few minutes of hacking I have a key logger. etc. So what I can't tell is whether this is a problem or not, because I don't know what problem you're trying to solve. If the object of oauth isn't to keep user/server credentials out of the hands of a third party, then what is it trying to solve? Is there an expectation that the UA is trusted by the user/server? What happens when that's not the case? Regardless of whether I'm misunderstanding, it would sure be nice to have both the problem and your assumptions laid out, hopefully with some prominence so you don't get these sort of dumb questions. Mike ___ 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
Re: [OAUTH-WG] problem statement
Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. If there was a solution to this we would not need an antivirus. EHL On Sep 6, 2011, at 11:23, Michael Thomas m...@mtcc.com wrote: Eran Hammer-Lahav wrote: I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. How, exactly, is the user supposed to protect themselves against rogue apps? It sounds like the solution is to tell them to never use oauth in an app at all. Is oauth only intended to be used on standalone trustable web browsers? I don't recall seeing that anywhere. Mike EHL On Sep 6, 2011, at 11:10, Igor Faynberg igor.faynb...@alcatel-lucent.com wrote: Mike, You've got the problem statement right: allowing the user to authorize resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth. I do not think though that it is related to OAuth per se. To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks. From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment. There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView. If I am wrong, I would appreciate a detailed description of what happened. Igor On 9/6/2011 1:40 PM, Michael Thomas wrote: Hi all, Barry suggested that I might subscribe and explain what I sent him. My basic problem is that in neither the protocol nor the threats drafts, I can't seem to find what problem is actually trying to be solved with oauth, and what assumptions you're making about various elements. Here's what I did. I've written an app, and I wanted re-integrate the ability to send tweets after they deprecated Basic. So the app has a webView (android, iphone...) which it obviously completely controls. With oauth, the webview UA will ultimately redirect off to Twitter's site to collect the user's credentials and grant my app's backend an access token (sorry if I get terminology screwed up, i'm just coming up to speed). What occurs to me is that webview affords exactly zero protection from my client (ie, the app) from getting the user's twitter credentials. All I have to do is set up a keypress handler on that webview and in a few minutes of hacking I have a key logger. etc. So what I can't tell is whether this is a problem or not, because I don't know what problem you're trying to solve. If the object of oauth isn't to keep user/server credentials out of the hands of a third party, then what is it trying to solve? Is there an expectation that the UA is trusted by the user/server? What happens when that's not the case? Regardless of whether I'm misunderstanding, it would sure be nice to have both the problem and your assumptions laid out, hopefully with some prominence so you don't get these sort of dumb questions. Mike ___ 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
Re: [OAUTH-WG] problem statement
I'm dismissive of this being an OAuth problem. EHL On Sep 6, 2011, at 11:35, Michael Thomas m...@mtcc.com wrote: Eran Hammer-Lahav wrote: Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. If there was a solution to this we would not need an antivirus. How exactly does an end user know what is crap or not? Or are you just dismissive of apps in general? I don't think that apple and google are going to close up shop because it breaks oauth's trust model. Mike EHL On Sep 6, 2011, at 11:23, Michael Thomas m...@mtcc.com wrote: Eran Hammer-Lahav wrote: I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. How, exactly, is the user supposed to protect themselves against rogue apps? It sounds like the solution is to tell them to never use oauth in an app at all. Is oauth only intended to be used on standalone trustable web browsers? I don't recall seeing that anywhere. Mike EHL On Sep 6, 2011, at 11:10, Igor Faynberg igor.faynb...@alcatel-lucent.com wrote: Mike, You've got the problem statement right: allowing the user to authorize resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth. I do not think though that it is related to OAuth per se. To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks. From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment. There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView. If I am wrong, I would appreciate a detailed description of what happened. Igor On 9/6/2011 1:40 PM, Michael Thomas wrote: Hi all, Barry suggested that I might subscribe and explain what I sent him. My basic problem is that in neither the protocol nor the threats drafts, I can't seem to find what problem is actually trying to be solved with oauth, and what assumptions you're making about various elements. Here's what I did. I've written an app, and I wanted re-integrate the ability to send tweets after they deprecated Basic. So the app has a webView (android, iphone...) which it obviously completely controls. With oauth, the webview UA will ultimately redirect off to Twitter's site to collect the user's credentials and grant my app's backend an access token (sorry if I get terminology screwed up, i'm just coming up to speed). What occurs to me is that webview affords exactly zero protection from my client (ie, the app) from getting the user's twitter credentials. All I have to do is set up a keypress handler on that webview and in a few minutes of hacking I have a key logger. etc. So what I can't tell is whether this is a problem or not, because I don't know what problem you're trying to solve. If the object of oauth isn't to keep user/server credentials out of the hands of a third party, then what is it trying to solve? Is there an expectation that the UA is trusted by the user/server? What happens when that's not the case? Regardless of whether I'm misunderstanding, it would sure be nice to have both the problem and your assumptions laid out, hopefully with some prominence so you don't get these sort of dumb questions. Mike ___ 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
Re: [OAUTH-WG] problem statement
Framing this as an OAuth issue is wrong. In your scenario: 1. Install bad app 2. Do protocol X 3. Bad things happen X can be anything. For example, the app can add a root cert to your os and break TLS protection. EHL On Sep 6, 2011, at 11:50, Michael Thomas m...@mtcc.com wrote: William Mills wrote: OAuth doesn't solve this problem, and can't. Generally the question is whether the app appears to come from a reputable source, and nowadays whether it's signed (in windows land) or otherwize certified by the provider. If you manage to solve this problem in a real way I'd be interested in investing in your company. Then what I don't see anywhere is that oauth is not applicable to embedded web objects, and that end users should *never* trust oauth in a, say, phone app. As far as I can tell, the server deploying oauth can't tell that it's being misused, so this is all on the shoulders of the end user. It sure looks like oauth is easily subverted in the real world. Mike *From:* Michael Thomas m...@mtcc.com *To:* Eran Hammer-Lahav e...@hueniverse.com *Cc:* oauth@ietf.org oauth@ietf.org *Sent:* Tuesday, September 6, 2011 11:34 AM *Subject:* Re: [OAUTH-WG] problem statement Eran Hammer-Lahav wrote: Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. If there was a solution to this we would not need an antivirus. How exactly does an end user know what is crap or not? Or are you just dismissive of apps in general? I don't think that apple and google are going to close up shop because it breaks oauth's trust model. Mike EHL On Sep 6, 2011, at 11:23, Michael Thomas m...@mtcc.com mailto:m...@mtcc.com wrote: Eran Hammer-Lahav wrote: I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. How, exactly, is the user supposed to protect themselves against rogue apps? It sounds like the solution is to tell them to never use oauth in an app at all. Is oauth only intended to be used on standalone trustable web browsers? I don't recall seeing that anywhere. Mike EHL On Sep 6, 2011, at 11:10, Igor Faynberg igor.faynb...@alcatel-lucent.com mailto:igor.faynb...@alcatel-lucent.com wrote: Mike, You've got the problem statement right: allowing the user to authorize resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth. I do not think though that it is related to OAuth per se. To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks. From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment. There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView. If I am wrong, I would appreciate a detailed description of what happened. Igor On 9/6/2011 1:40 PM, Michael Thomas wrote: Hi all, Barry suggested that I might subscribe and explain what I sent him. My basic problem is that in neither the protocol nor the threats drafts, I can't seem to find what problem is actually trying to be solved with oauth, and what assumptions you're making about various elements. Here's what I did. I've written an app, and I wanted re-integrate the ability to send tweets after they deprecated Basic. So the app has a webView (android, iphone...) which it obviously completely controls. With oauth, the webview UA will ultimately redirect off to Twitter's site to collect the user's credentials and grant my app's backend an access token (sorry if I get terminology screwed up, i'm just coming up to speed). What occurs to me is that webview affords exactly zero protection from my client (ie, the app) from getting the user's twitter credentials. All I have to do is set up a keypress handler on that webview and in a few minutes of hacking I have a key logger. etc. So what I can't tell is whether this is a problem or not, because I don't know what problem you're trying to solve. If the object of oauth isn't to keep user/server credentials out of the hands of a third party, then what is it trying to solve? Is there an expectation that the UA is trusted by the user/server? What happens when that's not the case? Regardless of whether I'm misunderstanding, it would sure be nice to have both the problem and your assumptions laid out, hopefully with some prominence so you don't get
Re: [OAUTH-WG] problem statement
You are one making the argument that no one should be installing apps. There is no known way to stop users from installing malware and viruses other than not letting them install anything off a whitelist. The problem you are describing has nothing to do with OAuth, its a fundamental problem with running untrusted code on your devices. Once you do that, yes, OAuth can be exploited but that's true for every authentication scheme when one side is compromised. My point, which you seems to miss, is that the same argument can be made against any other protocol. TLS offers your certain protections but they are all gone if you install a bad native app – following your logic people should not use TLS in apps either. I do not consider this an issue. EHL From: Michael Thomas m...@mtcc.commailto:m...@mtcc.com Date: Tue, 6 Sep 2011 11:58:11 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: igor.faynb...@alcatel-lucent.commailto:igor.faynb...@alcatel-lucent.com igor.faynb...@alcatel-lucent.commailto:igor.faynb...@alcatel-lucent.com, oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement Eran Hammer-Lahav wrote: I'm dismissive of this being an OAuth problem. Which brings us back to my original problem: what is the problem it's trying to solve? What are the assumptions it makes? What is its applicability? None of those are addressed very well if at all in the drafts. I'm sure that I'm not the only one who would be very surprised to hear that using oauth on a phone app is a bad idea. Put it this way: your favorite example of a photo printing service needing access to flickr. It's ok if you do that from a browser, but not if the photo printer makes an app. How many users, exactly, are going to know that they shouldn't do the second one? I think that's an oauth problem because oauth makes it *seem* like you're protected from the third party, whereas if the app itself asked for your login credentials there would be far less confusion. So in that sense, oauth is making things worse, not better. Mike EHL On Sep 6, 2011, at 11:35, Michael Thomas m...@mtcc.commailto:m...@mtcc.com wrote: Eran Hammer-Lahav wrote: Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. If there was a solution to this we would not need an antivirus. How exactly does an end user know what is crap or not? Or are you just dismissive of apps in general? I don't think that apple and google are going to close up shop because it breaks oauth's trust model. Mike EHL On Sep 6, 2011, at 11:23, Michael Thomas m...@mtcc.commailto:m...@mtcc.com wrote: Eran Hammer-Lahav wrote: I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. How, exactly, is the user supposed to protect themselves against rogue apps? It sounds like the solution is to tell them to never use oauth in an app at all. Is oauth only intended to be used on standalone trustable web browsers? I don't recall seeing that anywhere. Mike EHL On Sep 6, 2011, at 11:10, Igor Faynberg igor.faynb...@alcatel-lucent.commailto:igor.faynb...@alcatel-lucent.com wrote: Mike, You've got the problem statement right: allowing the user to authorize resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth. I do not think though that it is related to OAuth per se. To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks. From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment. There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView. If I am wrong, I would appreciate a detailed description of what happened. Igor On 9/6/2011 1:40 PM, Michael Thomas wrote: Hi all, Barry suggested that I might subscribe and explain what I sent him. My basic problem is that in neither the protocol nor the threats drafts, I can't seem to find what problem is actually trying to be solved with oauth, and what assumptions you're making about various elements. Here's what I did. I've written an app, and I wanted re-integrate the ability to send tweets after they deprecated Basic. So the app has a webView (android, iphone...) which it obviously completely controls. With oauth, the webview UA will ultimately redirect off to Twitter's site to collect the user's credentials and grant my app's backend an access token (sorry if I get terminology screwed up, i'm just coming up to speed
Re: [OAUTH-WG] problem statement
I understood his request and disagree that any action needs to be taken. It is unreasonable to expect every protocol to discuss the security considerations of a user installing malware. EHL From: Melinda Shore melinda.sh...@gmail.commailto:melinda.sh...@gmail.com Date: Tue, 6 Sep 2011 12:18:18 -0700 To: oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement On 09/06/2011 11:11 AM, Jill Burrows wrote: I repeat, it is not an OAuth problem. If I'm reading Mike correctly (and if I'm not it won't be the first time I've misunderstood him), he's not really asking for OAUTH to solve this particular problem but to clarify the documents and beef up discussions of what is and is not in scope. He read the document and couldn't figure out whether or not this particular problem is the business of the working group. Melinda ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] problem statement
It is a problem. For a few months now we have been going through this over and over again. The longer we work on this draft the more of this two-sentence changes people suggest. They don't make the document any better, create a false sense of comprehensiveness, and just further delay being done. So yeah, unless you can prove that there is an actual problem, we are done. EHL On Sep 6, 2011, at 15:22, Melinda Shore melinda.sh...@gmail.com wrote: On 09/06/2011 12:59 PM, John Kemp wrote: The point is that you have a point. He does, and that's in some large part why I don't fully understand the temperature of the responses. I do not think it's a particularly big deal to stick a couple of sentences in the security considerations underscoring the fact that OAUTH can't do anything about a compromised host or a malicious application. I've learned to live with the fact that sometimes people implementing or deploying security technologies don't fully understand them and it's my impression that there's some number of people out there who think that OAUTH and other third-party protocols provide sufficient protection against password snagging. Melinda ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] problem statement
Wg consensus is clearly to do nothing here. EHL On Sep 6, 2011, at 17:05, Michael Thomas m...@mtcc.com wrote: On 09/06/2011 03:27 PM, Eran Hammer-Lahav wrote: So yeah, unless you can prove that there is an actual problem, we are done. I will point out that the chairs make that determination based on working group consensus, not the document editor. Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] problem statement
The chairs have the final say, not a monopoly on making observations. The editor role *is* to distill wg discussion onto proposed changes. So saying I have no intention on making changes is clearly within my authority and the chair have the right to override that call. EHL On Sep 6, 2011, at 17:13, Melinda Shore melinda.sh...@gmail.com wrote: On 09/06/2011 04:09 PM, Eran Hammer-Lahav wrote: Wg consensus is clearly to do nothing here. ?? No, it clearly is not, unless you're laboring under the misconception that consensus means voting. At any rate the job of calling consensus *explicitly* belongs to working group chairs, not editors. Melinda ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] problem statement
What do you think such a warning would accomplish? There are no ways to mitigate malware (bad client or otherwise), and using passwords make it even easier. End users are not going to read the specification and service providers have absolutely no alternatives. As for the example, the issue you described with accepting every CA is completely irrelavent because changing the root certificates will be done in secrecy by the installed malware. I have not seen any argument showing how such a warming makes any difference in deploying OAuth (or not). Can you propose text and show how it mau affect implementation? EHL On Sep 6, 2011, at 17:50, Melinda Shore melinda.sh...@gmail.com wrote: On 09/06/2011 04:23 PM, Peter Saint-Andre wrote: I just looked at the most recent specifications for TLS (RFC 5246) and secure shell (RFC 4253), which I think we'd all agree are two quite successful security technologies. Neither of those specs says anything about not protecting humans users from malicious clients that perform keylogging to capture security-critical data the user might enter. I think there's an argument to be made that the user interface is sufficiently different that those might not be a great model. But it's also the case that there have been security problems with both that may or may not have been avoided in part by putting in warnings not to trust every crappy, random CA certificate that wafts by, or not to respond Sure - thanks! to every ssh host key you're offered. Melinda ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] problem statement
You clearly feel strongly about this. The only way forward if you want to pursue this is to suggest text and show how providing it will lead to more secure implementations. Otherwise this is just going in circles. EHL On Sep 6, 2011, at 18:13, Michael Thomas m...@mtcc.com wrote: On 09/06/2011 06:08 PM, Peter Saint-Andre wrote: Put me in the may not have been avoided camp. We can't legislate common sense (which, sadly, is all too uncommon). Can somebody show me in the archives where this has been discussed before? Specifically about oauth clients that also have control of the web UA? In any case, you site this as common sense. It's not. You are close to the problem. Nobody else is. Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] problem statement
*I* am not going to do anything to move this forward which means nothing will happen unless someone propose text. Even the chairs can't instruct the editor to produce new prose. All the chairs are going to do is give you the same answer. If you want the wg to consider anything at this point you must provide text. In fact, they already issued this clear instructions. Now, the overwhelming resistance to such a change would make *me* reconsider spending my time on this of I was in your position, but proposing text is the only advise the chairs can offer you at this point. If you think you can offer text that will win wg consensus you should. Arguing with me as a participant is, unfortunately, part of the deal. EHL On Sep 6, 2011, at 18:27, Michael Thomas m...@mtcc.com wrote: On 09/06/2011 06:24 PM, Eran Hammer-Lahav wrote: You clearly feel strongly about this. The only way forward if you want to pursue this is to suggest text and show how providing it will lead to more secure implementations. Otherwise this is just going in circles. Didn't you just get done announcing how you weren't going to do anything under any circumstances unless you were forced to by the chairs? I think I'll wait for them to chime in before I waste my time. Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
Perfect. Thanks Phil. EHL On Sep 6, 2011, at 20:42, Phil Hunt phil.h...@oracle.com wrote: Eran, Just took a look at the text. This new version looks much improved. I think this is a good compromise. Thanks, Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-09-04, at 4:25 PM, Eran Hammer-Lahav wrote: The corresponding 'state' parameter definition: RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in section 10.12. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Sunday, September 04, 2011 4:20 PM To: William J. Mills; Anthony Nadalin; Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is my proposed text for -21 (based on Bill's text as a starting point): 10.12. Cross-Site Request Forgery Cross-site request forgery (CSRF) is an exploit in which an attacker causes the user-agent of a victim end-user to follow a malicious URI (e.g. provided to the user-agent as a misleading link, image, or redirection) to a trusting server (usually established via the presence of a valid session cookie). A CSRF attack against the client's redirection URI allows an attacker to inject their own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g. save the victim's bank account information to a protected resource controlled by the attacker). The client MUST implement CSRF protection for its redirection URI. This is typically accomplished by requiring any request sent to the redirection URI endpoint to include a value that binds the request to the user-agent's authenticated state (e.g. a hash of the session cookie used to authentication the user-agent). The client SHOULD utilize the state request parameter to deliver this value to the authorization server when making an authorization request. Once authorization has been obtained from the end-user, the authorization server redirects the end-user's user-agent back to the client with the required binding value contained in the state parameter. The binding value enables the client to validate the validity of the request by matching the binding value to the user- agent's authenticated state. The binding value used for CSRF protection MUST contain a non-guessable value, and the user-agent's authenticated state (e.g. session cookie, HTML5 local storage) MUST be kept in a location accessible only to the client and the user- agent (i.e., protected by same-origin policy). A CSRF attack against the against the authorization server's authorization endpoint can result in an attacker obtaining end-user authorization for a malicious client without involving or alerting the end-user. The authorization server MUST implement CSRF protection for its authorization endpoint, and ensure that a malicious client cannot obtain authorization without the awareness and explicit consent of the resource owner. EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, August 25, 2011 12:11 PM To: Anthony Nadalin; Eran Hammer-Lahav; Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I had proposed text, and I'll reprise it here with a modification to make the authorizaton server related explicit. 10.12. Cross-Site Request Forgery Cross-site request forgery (CSRF) is an attack whereby malicious URLs are sent to the user-agent of an end user (generally as hidden links or images) and transmitted from the user-agent the server trusts or has authenticated. The most commonly exploited mechanism for this is credentials held in cookies automatically presented by a web browser. CSRF attacks against the client's redirection URI allow an attacker to inject their own authorization code or access token, which can result in the client using an access token associated with the attacker's account rather than the victim's. CSRF attacks are also possible against an authorization endpoint resulting in delivering a user credential to an attacker. Client applications MUST implement CSRF protection for the redirection URI. CSRF protection for a request is data included in the request that ties that request to the user's authenticated state, i.e. a cryptographic signature of the user credential and the redirection URI path. Upon receipt of a request the client application computes the CSRF data based on the presented credential and compares
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Sorry for the late response. -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Sunday, August 21, 2011 10:59 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, This is still just a CSRF attack. I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit. I don't see any reason to include this new text based on this threat analysis. However, this doesn't mean this discussion wasn't useful. We did identify the need to explicitly discuss CSRF attacks on the authorization endpoint. We need to explicitly separate the two target of CSRF attacks (client, server) because while the solution is the same, the implementation is very different (due to the use of redirections in one). I agree, we should explicitely document these two variants of CSRF (client, authz server). But I suspect it's not only CSRF we are talking about in this thread - at least not textbook CSRF. Let me explain my thoughts: As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal
Re: [OAUTH-WG] redirect uri validation
That's not complete. A valid redirection URI is not enough to verify client identity at the time it is presented, but it is enough in many cases to prevent leaking credentials later on. How about a slight change: A valid redirection URI is not sufficient to verify the client's identity when asking for end-user authorization, but can be used to prevent delivering credentials to a counterfeit client after obtaining end-user authorization. EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Monday, August 15, 2011 1:36 PM To: Eran Hammer-Lahav Cc: e...@sled.com; oauth@ietf.org Subject: Re: [OAUTH-WG] redirect uri validation Hi Eran, Am 15.08.2011 08:57, schrieb Eran Hammer-Lahav: Added to 1.4.2: When issuing an implicit grant, the authorization server does not authenticate the client and [[in some cases]], the client identity [[can]] be verified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent. Hope this is sufficient. What do you want to express? Clients can sometimes be verified via redirection URI? My intention was to point out that an invalid redirect URI is a counter- evidence for a client's identity but a valid redirect URI is _not_ an evidence for its identity. I would suggest to add the text below to section 10.1., last paragraph after the sentence For example, by requiring the registration of the client redirection URI or enlisting the resource owner to confirm identity. proposed text: Please note: while an invalid redirection URI indicates a counterfeit client, a valid redirection URI is not sufficient to confirm a client's identity. regards, Torsten. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Sunday, August 14, 2011 11:09 PM To: Torsten Lodderstedt Cc: tors...@lodderstedt-online.de; oauth@ietf.org Subject: Re: [OAUTH-WG] redirect uri validation Where would you suggest I add this? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Monday, July 25, 2011 10:42 AM To: Eran Hammer-Lahav Cc: tors...@lodderstedt-online.de; oauth@ietf.org Subject: Re: [OAUTH-WG] redirect uri validation Hi Eran, OAuth 1.0 was highly criticized for failing to address client identity in public clients. I believe OAuth 2.0 offers a much better story, within the boundariesof what’s possible today. Agreed. I think we must honestly discuss the value of client authentication/identification itself. I personally think it is over-emphazised right now. The strength of OAuth 2.0 is that it allows solutions where neither client nor resource server have access or do store end-user credentials. Client authentication is nice but not the main feature. Do you have any specific suggestions not already mentioned on the list? I would suggest to mention that while an invalid redirect_uri indicates a counterfeit clients a valid redirect does not prove the calling client's identity. regards, Torsten. 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
New tweak: The security ramifications of allowing unauthenticated access by public clients to the token endpoint, as well as the issuance of refresh tokens to public clients MUST be taken into consideration. EHL -Original Message- From: Richer, Justin P. [mailto:jric...@mitre.org] Sent: Friday, August 19, 2011 4:56 AM To: Eran Hammer-Lahav; Lu, Hui-Lan (Huilan); Brian Campbell Cc: oauth Subject: RE: [OAUTH-WG] treatment of client_id for authentication and identification I find the original text clearer, myself. -- Justin From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav [e...@hueniverse.com] Sent: Thursday, August 18, 2011 5:16 PM To: Lu, Hui-Lan (Huilan); Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification -Original Message- From: Lu, Hui-Lan (Huilan) [mailto:huilan...@alcatel-lucent.com] Sent: Thursday, August 18, 2011 1:45 PM To: Eran Hammer-Lahav; Brian Campbell Cc: oauth Subject: RE: [OAUTH-WG] treatment of client_id for authentication and identification Eran Hammer-Lahav wrote: Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. unless its value is an empty string. Do people read this new text to mean OPTIONAL if not empty? Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. 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
Re: [OAUTH-WG] Auth Code Swap Attack
This is my proposed text for -21 (based on Bill's text as a starting point): 10.12. Cross-Site Request Forgery Cross-site request forgery (CSRF) is an exploit in which an attacker causes the user-agent of a victim end-user to follow a malicious URI (e.g. provided to the user-agent as a misleading link, image, or redirection) to a trusting server (usually established via the presence of a valid session cookie). A CSRF attack against the client's redirection URI allows an attacker to inject their own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g. save the victim's bank account information to a protected resource controlled by the attacker). The client MUST implement CSRF protection for its redirection URI. This is typically accomplished by requiring any request sent to the redirection URI endpoint to include a value that binds the request to the user-agent's authenticated state (e.g. a hash of the session cookie used to authentication the user-agent). The client SHOULD utilize the state request parameter to deliver this value to the authorization server when making an authorization request. Once authorization has been obtained from the end-user, the authorization server redirects the end-user's user-agent back to the client with the required binding value contained in the state parameter. The binding value enables the client to validate the validity of the request by matching the binding value to the user- agent's authenticated state. The binding value used for CSRF protection MUST contain a non-guessable value, and the user-agent's authenticated state (e.g. session cookie, HTML5 local storage) MUST be kept in a location accessible only to the client and the user- agent (i.e., protected by same-origin policy). A CSRF attack against the against the authorization server's authorization endpoint can result in an attacker obtaining end-user authorization for a malicious client without involving or alerting the end-user. The authorization server MUST implement CSRF protection for its authorization endpoint, and ensure that a malicious client cannot obtain authorization without the awareness and explicit consent of the resource owner. EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, August 25, 2011 12:11 PM To: Anthony Nadalin; Eran Hammer-Lahav; Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I had proposed text, and I'll reprise it here with a modification to make the authorizaton server related explicit. 10.12. Cross-Site Request Forgery Cross-site request forgery (CSRF) is an attack whereby malicious URLs are sent to the user-agent of an end user (generally as hidden links or images) and transmitted from the user-agent the server trusts or has authenticated. The most commonly exploited mechanism for this is credentials held in cookies automatically presented by a web browser. CSRF attacks against the client's redirection URI allow an attacker to inject their own authorization code or access token, which can result in the client using an access token associated with the attacker's account rather than the victim's. CSRF attacks are also possible against an authorization endpoint resulting in delivering a user credential to an attacker. Client applications MUST implement CSRF protection for the redirection URI. CSRF protection for a request is data included in the request that ties that request to the user's authenticated state, i.e. a cryptographic signature of the user credential and the redirection URI path. Upon receipt of a request the client application computes the CSRF data based on the presented credential and compares that to the CSRF protection data presented in the request. CSRF protection data MUST contain a non-guessable value, and the client MUST keep it in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy). The state redirection URI parameter is provided as one method of carrying CSRF protection data, and is RECOMMENDED to provide the greatest compatibility with systems implementing strong redirection URI validation. Authorization servers MUST implement CSRF protection for authorization requests, use of the state parameter is RECOMMENDED as the way to transmit the CSRF protection data. The CSRF protection data MUST contain a non-guessable value, and MUST be presented as part of the authorization request data (e.g. not as a cookie). Authorization servers MAY use proof of previous authorization by a user for a client in lieu of explicit CSRF protection. For example, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the state
Re: [OAUTH-WG] Security area review
Where is this feedback? -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Monday, August 29, 2011 1:16 AM To: Eran Hammer-Lahav Cc: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] Security area review Hi Eran, I gave presentations to the security area directorate, and have asked for review comments. Some of the folks (such as Tom Yu, and Shawn Emery) showed up in the meetings and the side meetings and provided comments. As Barry said, there will be more review comments flying in after the document left the working group. Ciao Hannes PS: I had also given presentations at the SAAG meeting to solicit more feedback. On Aug 6, 2011, at 10:29 AM, Eran Hammer-Lahav wrote: Did the chairs issue a last call request to anyone in the security area? I thought the whole point of moving this working group from apps to security was to increase the review and participation of that area. So far I have seen absolutely nothing to indicate any such contribution. I would like to know what actual actions are being taken to turn this promise into reality. 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
[OAUTH-WG] Request for open issues resolution
#19 - no text proposed, consider current text sufficient. Close. #20 - reference to DOM variable removed. Close. #21 - resolved by new text, no comments received. Close. #24 - pending comments. Close if agreed to by Torsten. #25 - no comments received to proposed text which has been applied. Close. I will post -21 shortly and will follow with -22 if needed later this week. I am only posting -21 to help facilitate the discussion moving forward, not to imply consensus on items still open (issue #24 and new CSRF text). EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Draft -21 next steps
I'd like to ask the chairs to declare a 2 weeks review period limited to changes made since -20 after which we will either declare -21 as the final WG draft or publish a quick -22 with all changes agreed prior on the list and no additional WG review period. Of course, the chairs can change all these rules as they see fit. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
Everyone yourself included indicated that the combination of MUST prevent CSRF and SHOULD use 'state' is the way to go. Yes, we still need to agree on text but the normative language part is settled. If you still insist on making 'state' required, I will defer to the chairs to decide how to move forward. EHL From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com Date: Thu, 25 Aug 2011 08:11:01 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto:oauth@ietf.org Subject: RE: [OAUTH-WG] Auth Code Swap Attack I have not seen any updated text, so I don’t believe we have consensus. Also we have a flawed protocol and we are not providing a fix, suggest that MUST be on the state also unless someone has a better fix From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, August 24, 2011 7:54 AM To: Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I believe we have full consensus on this approach. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]mailto:[mailto:tors...@lodderstedt.net] Sent: Tuesday, August 23, 2011 11:06 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack making CSRF prevention a MUST and recommending the state parameter as implementation pattern is ok with me. regards, Torsten. Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: I light to the recent discussion, do you still feel that changing ‘state’ from optional to required is the best approach? EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Sunday, August 21, 2011 11:04 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack My intention is to require clients to implement CSRF prevention. I thought making the state parameter mandatory would be the straightforward way. regards, Torsten. Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of ‘state’ from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section’s language and clarity which we should address either way. To clarify – I am not proposing we close this issue just yet. EHL From:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn’t very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn’t sufficient. We use “cannot be generated, modified, or guessed to produce valid values” elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable. In addition, this is not what “state” was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. ‘csrf’). By forcing clients to use “state” for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify
Re: [OAUTH-WG] Auth Code Swap Attack
We already have one recommended implementation with 'state'. It is clearly described in the security section which is the right place to define it. I will further emphasize it in the 'state' parameter definition as previously proposed. BTW, as stated repeatedly before, making the parameter required does not provide *ANY* CSRF protection. It just forces it to be included. To guarantee CSRF protection, you need a LOT more normative language in how to bind the state value with some form of session information on the user-agent – which is clearly outside the scope of this working group. Requiring CSRF protection accomplishes that, and if a developer doesn't know how to do that, unfortunately, we will not be able to help within the scope of this document – which doesn't exclude it from being discussed in details in the thread model document as advised by the chairs. CSRF is a serious attack vector, but our correct course is to highlight it, suggest a path, and leave it to developers to implement proper security like the other handful of possible attacks listed. EHL From: Phil Hunt phil.h...@oracle.commailto:phil.h...@oracle.com Date: Thu, 25 Aug 2011 09:25:30 -0700 To: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com Cc: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net, OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Auth Code Swap Attack I agree. I think at least one implementation must be included in the spec. However, I'd like to see it left that more methods could be implemented in the future. I can live with SHOULD given the definition in 2119. Or phrased MUST implement at least the following method... for stronger language. Tony is correct, I think it is a serious issue given the dependence on grants being passed by URLs through redirects. Phil @independentid www.independentid.comhttp://www.independentid.com phil.h...@oracle.commailto:phil.h...@oracle.com On 2011-08-25, at 8:11 AM, Anthony Nadalin wrote: I have not seen any updated text, so I don’t believe we have consensus. Also we have a flawed protocol and we are not providing a fix, suggest that MUST be on the state also unless someone has a better fix From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, August 24, 2011 7:54 AM To: Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I believe we have full consensus on this approach. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]mailto:[mailto:tors...@lodderstedt.net] Sent: Tuesday, August 23, 2011 11:06 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack making CSRF prevention a MUST and recommending the state parameter as implementation pattern is ok with me. regards, Torsten. Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: I light to the recent discussion, do you still feel that changing ‘state’ from optional to required is the best approach? EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Sunday, August 21, 2011 11:04 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack My intention is to require clients to implement CSRF prevention. I thought making the state parameter mandatory would be the straightforward way. regards, Torsten. Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of ‘state’ from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section’s language and clarity which we should address either way. To clarify – I am not proposing we close this issue just yet. EHL From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn’t very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn’t
Re: [OAUTH-WG] Auth Code Swap Attack
I believe we have full consensus on this approach. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Tuesday, August 23, 2011 11:06 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack making CSRF prevention a MUST and recommending the state parameter as implementation pattern is ok with me. regards, Torsten. Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: I light to the recent discussion, do you still feel that changing 'state' from optional to required is the best approach? EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Sunday, August 21, 2011 11:04 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack My intention is to require clients to implement CSRF prevention. I thought making the state parameter mandatory would be the straightforward way. regards, Torsten. Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of 'state' from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section's language and clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn't sufficient. We use cannot be generated, modified, or guessed to produce valid values elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable. In addition, this is not what state was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. 'csrf'). By forcing clients to use state for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful. As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below. From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com Date: Fri, 12 Aug 2011 12:06:36 -0700 To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto:oauth@ietf.org Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring state should change from: state OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the request
Re: [OAUTH-WG] Auth Code Swap Attack
Sounds like a good compromise. I will play with the text Bill proposed and follow up with new text on the list. EHL From: Phil Hunt phil.h...@oracle.commailto:phil.h...@oracle.com Date: Mon, 22 Aug 2011 08:57:54 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: record...@gmail.commailto:record...@gmail.com record...@gmail.commailto:record...@gmail.com, OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Auth Code Swap Attack Eran, to summarize, 1. The server cannot tell if the client did its job - so the server can't require the client to implement state 2. There are many ways to enforce CSRF There is an important network effect here (and in general with OAuth) - that client decisions affect the security of the resource server and vice-versa. One could argue, that many implementers will want a solution for #1 above -- some form of mutual state validation. This may not be of interest to today's implementers, but I know this is critical for government and financial services where fraud (and phishing) become a much larger issue. I am beginning to believe we can't fix this now. This will likely have to be an optional RFC for higher strength anti-CSRF which specifies a standard methodology that can be verified by the server (so it can enforce that it was done). My belief is that a standard methodology would make things easier for developers since they would have clear instructions on how to do it. Hopefully this would address folks like Facebook who are concerned developers have a hard time getting this right. Because of this, I re-checked RFC2119 regarding making state RECOMMENDED. Whereas REQUIRED is equivalent to MUST, RECOMMENDED is equivalent to SHOULD and could be used as a parameter qualifier. Though I agree, traditionally this isn't done. However, my feeling is that the developer needs to be alerted to the importance of state. Deciding not to use it means they should have some other technique to counter CSRF. This is what SHOULD is meant for. Changing to RECOMMENDED makes the calls consistent with the security consideration requirement that anti-CSRF is a MUST. Phil @independentid www.independentid.com phil.h...@oracle.commailto:phil.h...@oracle.com On 2011-08-21, at 10:53 PM, Eran Hammer-Lahav wrote: -Original Message- From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Sunday, August 21, 2011 10:39 PM To: David Recordon Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I think the complication here is that CSRF issues are multi-site issues where the attacker cross connecting his client with a victims resource, or a victims client with the attackers resource. So while an individual site (e.g. Facebook) may presume little or no risk - there is a network effect here. A CSRF attacker could be using facebook to attack another site. See Yaron's original text about Plaxo/Live at the start of this thread. It's still just a CSRF attack. Would it be reasonable to assess whether a resource site could make it mandatory based on a pre-registered client? IOW, would Facebook want to make state mandatory for Confidential clients, but not public clients? That's irrelevant. The authorization server has absolutely no way of verifying if the client is implementing a CSRF protection properly. Making 'state' required does not accomplish such an enforcement. A client can pass the proposed text requirement with state=ni. Would it be acceptable to change status from OPTIONAL to RECOMMENDED? Parameters are either required or optional. We can makes it optional and recommended for a particular purpose which is consistent with the existing text. It should be mandatory to implement CSRF protection. We agree on that and should add it to the text. We also agree that 'state' is a great way of implementing it and should recommend it. We already do that in the security consideration section and can enhance that when defining the 'state' parameter. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
I light to the recent discussion, do you still feel that changing 'state' from optional to required is the best approach? EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Sunday, August 21, 2011 11:04 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack My intention is to require clients to implement CSRF prevention. I thought making the state parameter mandatory would be the straightforward way. regards, Torsten. Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of 'state' from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section's language and clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn't sufficient. We use cannot be generated, modified, or guessed to produce valid values elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable. In addition, this is not what state was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. 'csrf'). By forcing clients to use state for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful. As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below. From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com Date: Fri, 12 Aug 2011 12:06:36 -0700 To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto:oauth@ietf.org Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring state should change from: state OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. value SHOULD enable) accomplishes nothing
Re: [OAUTH-WG] Auth Code Swap Attack
-Original Message- From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Sunday, August 21, 2011 10:39 PM To: David Recordon Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I think the complication here is that CSRF issues are multi-site issues where the attacker cross connecting his client with a victims resource, or a victims client with the attackers resource. So while an individual site (e.g. Facebook) may presume little or no risk - there is a network effect here. A CSRF attacker could be using facebook to attack another site. See Yaron's original text about Plaxo/Live at the start of this thread. It's still just a CSRF attack. Would it be reasonable to assess whether a resource site could make it mandatory based on a pre-registered client? IOW, would Facebook want to make state mandatory for Confidential clients, but not public clients? That's irrelevant. The authorization server has absolutely no way of verifying if the client is implementing a CSRF protection properly. Making 'state' required does not accomplish such an enforcement. A client can pass the proposed text requirement with state=ni. Would it be acceptable to change status from OPTIONAL to RECOMMENDED? Parameters are either required or optional. We can makes it optional and recommended for a particular purpose which is consistent with the existing text. It should be mandatory to implement CSRF protection. We agree on that and should add it to the text. We also agree that 'state' is a great way of implementing it and should recommend it. We already do that in the security consideration section and can enhance that when defining the 'state' parameter. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of 'state' from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section's language and clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn't sufficient. We use cannot be generated, modified, or guessed to produce valid values elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable. In addition, this is not what state was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. 'csrf'). By forcing clients to use state for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful. As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below. From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com Date: Fri, 12 Aug 2011 12:06:36 -0700 To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto:oauth@ietf.org Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring state should change from: state OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. value SHOULD enable) accomplishes nothing. Also, what does MUST be kept confidential mean? Confidential from what? Why specify an encoded value? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
I think using phishing here is misleading. This is not a classic phishing attack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not authorization code phishing? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) 10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
There was no argument made. You described a CSRF attack scenario which carries the exact same risk and uses the exact same solution as the CSRF attack already present in the specification. Then jumped from there to a new normative requirement. I have not seen any argument to justify the new MUST requirement - if I have missed it, please point me in the right direction. Also, -20 has no such inconsistencies. It is OPTIONAL in one place and RECOMMENDED in the other. However, -20 does not *require* CSRF protection which put it at odds with how we address every other attack vector, so we are in full agreement that CSRF prevention is a MUST. My text fixes that in a manner consistent with how you and the other security consideration section drafters approached many of the other sections (by requiring a solution but not limiting developers to a particular one). There are two open issues: - the quality of the prose (I agree that Bill's text is a good new starting point), and - whether we should dictate to developers the parameter name (and location) of the CSRF artifact. If we decide that we should mandate such a parameter, we then need to decide if 'state' is the right place and if it is, find a new way to describe it because using it for CSRF is a relative new use case for the parameter (which still have all the previous use cases). EHL From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Wednesday, August 17, 2011 11:41 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I felt the argument provided was persuasive and that the current spec leaves implementers open to attack. I get concerned when the core spec says OPTIONAL for state and then Security Considerations says REQUIRED. The inconsistency seemed to be a flaw in draft 20. As to your comment about a tie vote, all that shows is a lack of consensus. Clearly we need to keep working on some more proposals. I think it is reasonable to determine whether MUST is appropriate in all cases. I agree with what you said earlier, we should have more specific language other then of sufficient complexity to describe the value of the state parameter. I saw a proposal by William Mills that I would like to see more discussion on. Phil @independentid www.independentid.comhttp://www.independentid.com phil.h...@oracle.commailto:phil.h...@oracle.com On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav wrote: I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of 'state' from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section's language and clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn't sufficient. We use cannot be generated, modified, or guessed to produce valid values elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable. In addition, this is not what state was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. 'csrf'). By forcing clients to use state for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
But it's not really a counterfeit client but a real client with modified redirection uri. It is a counterfeit redirection endpoint. *I* understand exactly what you mean, but I fear new readers will get completely confused by the title. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, August 18, 2011 12:12 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) The security document designates it as Authorization code leakage through counterfeit client http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7 Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 08:06 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) I think using phishing here is misleading. This is not a classic phishing attack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]mailto:[mailto:t.lodderst...@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not authorization code phishing? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) 10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Thanks. You have a typo in #1 (the authorization endpoint belongs to the authorization server, not client). This is a textbook CSRF attack on the authorization endpoint. The right solution is for the authorization server to set or maintain a session cookie (or other same-origin-protected state in the browser) in #1 as well as some hidden CSRF token in the Accept form and not allow CORS calls to that endpoint. I don't see how the measures proposed in the new section are relevant here. EHL -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 5:49 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Here are two very simple examples. They are very naive ones, but get the point across and I would not be suprised if they could be found in the wild: Say a client has its authorization endpoint at (1) http://www.domain.com/auth.php A client requests access to protected resources by redirecting the user-agent to: (2) http://www.domain.com/auth.php?response_type=codeclient_id=1234; redirect_uri=SOMEURIscope=SOMESCOPE One possible design choice for the developer, if a bad one, is to have the 'Allow' button point to: (3) http://www.domain.com/auth.php?[..previous query params..]allow=1 In this case, a malicious client who knows the structure of this auth flow, can simply skip (2) and redirect the user-agent to (3) in order to gain access to the protected resources. Another possible design choice for the developer (again, a very bad one) would be to issue some kind of session cookie after (2) in order to keep a state. Then, the 'Allow' button could possibly point to: (4) http://www.domain.com/allow.php without any parameters (since the state is maintained by a cookie). Here, an attacker could launch a request to (2) just to issue the state cookie, and immediately redirect the user-agent to (4) in order to gain access to the protected resources. These are two very naive scenarios which can be averted using a nonce for example (+ better design choices, for that matter). In non-user-agent based clients, a client might also be able to actually scrape the contents of the authorization HTML page, and simulate the click programmatically. In this case a nonce would be useless, but a CAPTCHA or a PIN code/password would solve the problem. -- Niv On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav e...@hueniverse.com wrote: I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. I'm keeping this proposed text out until we resolve this questions. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Hey Torsten, -Original Message- From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, August 18, 2011 12:52 AM To: Eran Hammer-Lahav; Torsten Lodderstedt; oauth@ietf.org Subject: AW: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically presses the right buttons. This obviously only works if the client can predict the form structure and expected input values. That's not an attack but a description of capabilities. The attack example provided by Niv is a *classic* CSRF attack on the authorization endpoint. Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment? I don't understand the attack and how the proposed solution address it. I'm really happy for everyone else who got it, but I need more information to process it. The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. True. But it was central in the list discussion and was promoted as strong defense to whatever this attack is. I think that CAPCHA is an impractical recommendation in general for the authorization endpoint. Can you point to any real world example of a large provider forcing CAPCHA on every login? That's what this amounts to. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions. The text hints at a very dangerous attack vector of scripts doing 'really bad things'. But it doesn't show why this attack requires any kind of automation at all. If I am targeting just a small number of people, I can automate this by sending a message to a human who will break the CAPCHA and quickly return the link to approve access. The other measures either have the same properties, are just there to annoy the attacker, or provide some kind of after the fact notice (when it is clearly too late to prevent damage). I'm keeping this proposed text out until we resolve this questions. See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? no one (except you) is an interesting statement... :-) This is not a process issue. New text has been proposed with the support of a few working group members. The working group has been largely silent about it (and the review you referenced above was done off list). I have read the new text and did not understand it, therefore, could not edit the text as I have done with every other proposed language. No new draft will be published until we resolve all open issues, which is exactly what I have stated above. To make it clearer: I am keeping this proposed text out of *my* working draft for -21 until the working group discusses the text further and addresses the issues I have raised about the text as a working group member (technical issues) and as an editor (clarity issues). As for IETF process, all it takes is one objection to block text from being *automatically* added to the specification. I have not implied anywhere that I have made any decision (or have the authority to) with regard to this text, only that I'm holding it back until the issues are resolved. And IETF process does not require full agreement to solve issues which is the role of the chairs to resolve. In this case, we're nowhere near needing help from the chairs - just the assistance of the text authors to do their job and explain it. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland
Chairs - please open an issue for this: Clarifying reference to refresh tokens in section 1.4.3 of -20. -Original Message- From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, August 18, 2011 1:01 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: AW: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland 1.4.3. Resource Owner Password Credentials: Comment on (when combined with a refresh token): This is the first time that refresh tokens are mentioned in the spec. And yet there is no explanation of what they are. I suspect they should anyway be introduced in section 1.4.1 (as previously noted) and then their use here will make sense. If that isn't possible then it would be good to have a forward reference to section 1.5 below so the reader has some idea of what's going on. I removed '(when combined with a refresh token)'. This is actually not true as there is no assumption that access tokens are always short-lived or that refresh tokens will always be issued to native applications using this grant type. -1 against removing this text (w/o an suitable replacement) and w/o group consent. Since you felt it necessary to make this a process issue, I've asked the chairs to open a ticket. The -20 text clearly points out that this combination ... eliminates the need for the client to store the resource owner credentials for future use. The resource owner grant type alone does not justify this statement. It's true that the spec does not explicitly defines the lifetime assumption for access and refresh tokens (which is pity in my opinion). So at least add something like if the token lifetime is reasonable long enough. How about: This grant type can eliminates the need for the client to store the resource owner credentials for future use, by exchanging the credentials with a long-lived access token or refresh token. As for Yaron's original comment, I think this text is sufficient and no forward reference is needed to 1.5 (which is a few lines lower in the same page). Also, with the new organization proposed by Justin, the access token term isn't full defined yet either and it reads just fine. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) (thanks for the typo correction) Yes, the example I provided is a very lightweight one which does take the form of CSRF, but it is only the simplest example of a family of automated authorization flow attacks. Indeed, a nonce (or hidden token, both serve the same purpose in this case) would be enough here. Great. So we need to add explicit text about preventing CSRF attacks at the authorization endpoint. If the client is not user-agent based, a full-fledged forgery of the whole process is possible, one in which CORS and sandboxes have no meaning. In a native client, unless some kind of human test is performed, the whole flow could be spoofed. Can you provide another example with the same level of detail as you provided below? A CAPTCHA and/or password entry are not bullet-proof, but they provide a steep obstacle for the attacker. CAPTCHA and password entry are two completely difference measures and are rarely interchangeable. CAPTCHA does nothing more than increase the likelihood that the entity on the other side is a human. Any attack prevented by CAPTCHA must be one in which automation and speed are crucial. I still don't understand what it *solves*. Another option would be, for example, to email the resource owner an OTP, with the following message The application [...] requests access to [...]. Please use the number to allow it access etc... (similar to Google's and Facebook's two-step sign-in). Two-factor authentication is good, but completely impractical for most web authorization scenario. You need to remember that the authorization page is used for both the initial grant, but also for delegated login (by far a more frequent use). An access token can be issued almost automatically if the client has been previously authorized. The first attack described in my previous message takes the form of CSRF, while the above one may be bypassed by an attacker with the help of some sort of clickjacking or similar. Eventually this threat description is for a family of attacks which mimic the behavior of the resource owner in order to gain access to protected resources, and some possible countermeasures. I don't understand this family of attacks. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. EHL [1] http://www.ibras.dk/montypython/episode34.htm ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. and launch it using the same HTTP framework/WebKit, simulating the Allow button. This is still just a CSRF attack. In order to automate the approval action, they attacker has to get the user-agent (embedded or not) to make a cross site request which will include some session state (cookies or otherwise). If the authorization page is CSRF protected, they attacker will not be able to construct such a link. The nature of the client does not matter. In either case, the client has to gain access somehow to the authorization server state stored in the browser. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
We know how to fix CSRF attacks on form submission which this is. The UI questions about more about legitimate client interaction and how informed a user should be. EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, August 18, 2011 12:27 PM To: Niv Steingarten; Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) This is, in my opinion, another style of CSRF. I the attacker present your browser (user agent) with a link, and your browser presents a credential automatically to the token endpoint, which automatically issues a token to be given back to me? That's a classic CSRF, how to fix it is interesting. I'm of the opinion that the user *should* be pesented with some UI at that point so they can make an informed choice about issuing a credential. Not everyone agrees with me though (mostly business folks that want to avoid user interaction because it's too scary and somehow informing the user what they are doign is a bad thing). -bill From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Thursday, August 18, 2011 12:11 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request and launch it using the same HTTP framework/WebKit, simulating the Allow button. [1] http://www.ibras.dk/montypython/episode34.htm +1 for more Monty Python references. -- Niv ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. You only said that about the first request. But since both requests (the one requesting the auth endpoint and the one simulating the allow) are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. That's not exactly right. This entire attack is based on: 1. The presence of some session cookie or other user-agent state to bypass active authentication, and 2. The ability of the malicious client to make CSS calls using #1. Everything else is a red herring because the ability to automate this attack and make it more powerful is completely beside the point. If you deploy an effective CSRF protection, everything else is a non-issue. This is why the client type does not matter when it comes to not using CORS. The authorization server MUST NOT allow CSS calls on the authorization endpoint because that's the actual attack you described - using local state (session cookie) to make a CSS call. If the client makes direct calls to the authorization endpoint, it cannot impersonate the resource owner. and launch it using the same HTTP framework/WebKit, simulating the Allow button. This is still just a CSRF attack. I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit. I don't see any reason to include this new text based on this threat analysis. However, this doesn't mean
Re: [OAUTH-WG] treatment of client_id for authentication and identification
-Original Message- From: Lu, Hui-Lan (Huilan) [mailto:huilan...@alcatel-lucent.com] Sent: Thursday, August 18, 2011 1:45 PM To: Eran Hammer-Lahav; Brian Campbell Cc: oauth Subject: RE: [OAUTH-WG] treatment of client_id for authentication and identification Eran Hammer-Lahav wrote: Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. unless its value is an empty string. Do people read this new text to mean OPTIONAL if not empty? Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Text? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
To reiterate Berry's earlier point, we are not going to cover everything in the v2 spec. We need to agree on new language for the CSRF section, and add the potential attacks on both endpoints. But beyond that, it will probably be best to add it to the threat model document - but I will leave that up to the editors of that document. EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, August 18, 2011 9:21 PM To: Niv Steingarten Cc: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) While I agree in principal, I think there are real world use cases that make this more complicated. If, for example, a user has previously approved access to a particular endpoint then we might be willing to re-issue credentials without user interaction. I don't know how we capture this in the right way in the spec. From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com To: William J. Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com Cc: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com; oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Thursday, August 18, 2011 6:06 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com wrote: I proposed text that I think is more complete in a previous message... From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Thursday, August 18, 2011 4:33 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource
[OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
Noticed this follow up question after I sent this: 10.6. Authorization Code Leakage: Comment on The authorization server SHOULD require the client to register their redirection URI: Why is this a should? Because comparing the redirect_uri value used between the two calls (authorization and token) along with client authentication is sufficient to avoid the attack described for confidential clients. For public clients it is a MUST. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URI and if provided in the request, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
