Re: [OAUTH-WG] treatment of client_id for authentication and identification
the client_id parameter had been added to the token endpoint in -16. As far as I remember, the reason was to properly separate client identification and authentication in order to support further client authentication methods. quote from http://www.ietf.org/mail-archive/web/oauth/current/msg06346.html: The goal is a cleaner protocol design. The protocol design separates client identification as part of the flow (URI parameter) and originator authentication. While the client_id parameter is required, the authentication can be omitted (unauthenticated access) or performed using other authentication mechanisms. And such mechanisms not neccessarily use client_id's. Moreover, the spec just says, The authorization server MUST ensure the two identifiers belong to the same client. So the client_id's (request parameter and header) may differ. You removed the parameter in -17, can you please explain why? regards, Torsten. Am 27.07.2011 18:45, schrieb Eran Hammer-Lahav: There is not clean way of adding it. First where? In each flow of the token endpoint or just in 3.2? Then how is it defined? Optional? Required for public clients? How does it work alongside authentication? If you use client_password or Basic then it becomes authentication but otherwise identification? What about duplication between Basic and the parameter? It also means adding a new section discussing client authentication vs identification which is currently implicit. I strongly believe that it is better to have a simple model as the one already defined in –20 and let other use case find their way around it instead of producing a confusing document that is trying to hard to solve every possible combination. As I said before, we can tweak the definition of client_secret to make it more esthetically pleasing (the server doesn't mind having an empty parameter included, just people), but that's as far am I'm (as wg member) willing to support, especially at this point. EHL From: Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net Date: Wed, 27 Jul 2011 15:21:16 -0700 To: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com Cc: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com, oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I personally think that would be more confusing than just adding the client_id parameter to the token endpoint request (independent of client authentication credentials). Am 27.07.2011 18:17, schrieb Brian Campbell: I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahave...@hueniverse.com mailto:e...@hueniverse.com wrote: If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: SSL/TLS Performance Data
We had a discussion at the OAuth working group meeting about the worries people have with using TLS. Here is a relevant mail from a discussion around TCP crypt. Begin forwarded message: From: Eric Rescorla e...@rtfm.com Date: July 28, 2011 10:53:00 AM EDT To: tsv-a...@ietf.org Subject: SSL/TLS Performance Data Re: Mark's comments about SSL/TLS performance versus tcpcrypt performance, it's worth reading: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html Relevant point: In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. -Ekr ___ 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 would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. 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
+1 Am 28.07.2011 15:10, schrieb Brian Campbell: I would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahave...@hueniverse.com wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. 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
Perfect. I'll make this change after the last call before sending this to IETF LC. EHL From: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Date: Thu, 28 Jul 2011 12:59:19 -0700 To: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com Cc: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification +1 Am 28.07.2011 15:10, schrieb Brian Campbell: I would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahave...@hueniverse.commailto:e...@hueniverse.com wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments
My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt: 1. Mentioning that this is an HTTP authentication mechanism in the title and/or abstract would be useful to the wider IETF ( beyond) audience. Title: The BEARER HTTP authentication mechanism for use with OAuth 2 Abstract: This specification describes how to use bearer tokens in HTTP requests to access OAuth 2 protected resources. [Personally, I wouldn't bother mentioning OAuth at all here, but others seem to want this context restriction.] 2. The ABNF for credentials does not comply with RFC 2617 HTTP Authentication. And even though RFC 2617 is broken is this aspect, the BEARER spec doesn't comply with the errata (still broken) or the more likely fixes proposed for HTTPbis [draft-ietf-httpbis-p7-auth]. I expect HTTPbis to allow a base64-like-blob consistently in Authorization and WWW-Authenticate headers (to accommodate BASIC and NTLM). Multiple WWW-Authenticate headers can have their values combined, separated by commas. They can also have quoted-string parameters. To be able to parse this, requires disallowing commas and double-quotes from the base64-like-blob (and hence from access-token) at a minimum; only allowing equals at the end also helps. The current approach in the bearer spec disallows all but 94 chars/bytes. I suggest reducing this to 69. Something in between (eg 91 chars, dropping comma, quote, and slash) might work. None of these options are materially easier than the others for a token issuer; and less symbols just means less risk of escaping problems elsewhere (eg allowing in an access token will wreck someone's XML somewhere, for no benefit). Suggestion: access-token = 1*( ALPHA / DIGIT / - / . / _ / ~ / + / / ) *= access-token includes the 66 unreserved URI characters plus a few others. It can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace [RFC4648]. 2b. If 2 is not accepted (and assuming HTTPbis will allow any content after the scheme name in a Authorization header) can we please not misuse the quoted-char label when no quoting is going on. The following is a better equivalent: access-token = 1*(%x21-7E) ; ASCII, except controls, space, or delete 3. Drop '\' from the allowed chars in a scope value, to avoid clashing with the HTTP quoted-string escaping mechanism (and don't use the quoted-char label when no quoting is going on). scope-v = 1*(%x21 / %x23-5B / %x5D-7E); excludes space and and \ 4. Section 3.3 Summary of Recommendations sensibly says clients MUST ensure that bearer tokens are not leaked to *unintended parties* and correctly notes that this is the primary security consideration that underlies all the others. So it is a glaring hole that OAuth2 fails to tell the client who the intended parties are when issuing a bearer token. -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
