Re: [OAUTH-WG] draft 16 notes on security considerations
Am 28.05.2011 20:25, schrieb Doug Tangren: I just re-read draft 16 on this memorial day weekend :) 1. I had a comment on the suggested use of the authorization code flow for native clients [1]. Section 10.9 on auth code transmission [2] suggests users of the auth code flow should implement tls on it's redirect uri. This makes sense for web servers which may register something like "https://foo.com/i/got/authed"; but may not be possible on native clients. It makes sense for all flows where the redirect_uri referes to a server resource. This holds true for web servers acting as OAuth client as well as any server-based resource used by other clients to obtain the authorization code. This should be clarified. It's a common practice for android clients, for instance, to open a browser window to authorize a user via `Intent` and then register their redirect_uri to be a custom scheme registered with their android `activity`, something like "myapp://i/got/authed". As pointed out by e.g. Marius in some postings, there are other techniques as well. Some of them are based on server resources the native app relies on. 2. With regards to resource owner creds flow security consideration mentioned [3], it really feels like this is dodging the whole idea of oauth asking for authorization on the site owning the resources. The section clearly states our preference to use other grant types. "The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible." Apart from that, I would not limit OAuth 2.0 to "just" delegated authorization via end-user authorization. In my opinion, OAuth 2.0 is a generic token issuance framework. Such tokens can be issued based on delegation flows but also based on direct authentication on the tokens endpoint. Other examples of reasonable credentials are assertions of all kind. We at Deutsche Telekom also added a custom grant type to directly authenticate users based on their SIM card. What I like the most, OAuth 2.0 combines the user involvement of OAuth 1.0 with architectural properties of Kerberos (trusted third-party authentication, scalability). Moreover, it is based on and integrated with HTTP(S) and allows to use different token formats (and even designs). Is this mainly meant for `official` apps developed by the site owning the resource? We use it for our own apps. Here, the decision to use web-based flows or username/password is typically met by product managers. Otherwise, it feels like its no different than ye old basic http auth and gimme your login and password and trust me not to store them. It clearly has the security advantages that refresh tokens instead of passwords are stored in order to provide a convenient login experience. The scope of such a token can (and must) be much less powerful than a password. regards, Torsten. [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9 [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.9 [3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12 -Doug Tangren http://lessis.me ___ 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] Referencing client_secret when making requests
We can add it as an example. Instead of 'Commonly', 'For example, using'. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of David Recordon > Sent: Saturday, May 28, 2011 9:41 AM > To: OAuth WG > Cc: paul Tarjan > Subject: [OAUTH-WG] Referencing client_secret when making requests > > In sections 4.1.3, 4.3.2, 4.4.2 and 6 there's a list of parameters included > within > the request and then the sentence, "The client includes its authentication > credentials as described in Section 3." > Reading through the spec yesterday afternoon with Paul, we first thought > that client_secret was removed from these requests between drafts 10 and > 16. This is because the list of parameters is quite obvious but this sentence > referencing section 3 sort of just blends in. > > We'd propose changing this sentence to read, "The client includes its > authentication credentials as described in Section 3. Commonly the > client_secret parameter." > > Goal being that client_secret is exposed within each section describing how > to make a request in a way that holds true for most usage but doesn't make > it more confusing for clients working with SAML (or other client > authentication credentials). > > --David > ___ > 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] Question on action item to make RedirectURI optional
This applies to 4.1.1 and 4.2.1 only. It must be required in 4.1.3 is must match the location actually used by the server to deliver the code to (regardless of whether the redirection uri was registered or included explicitly with the request). EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, May 27, 2011 2:08 PM To: oauth@ietf.org Subject: [OAUTH-WG] Question on action item to make RedirectURI optional The minutes from the special meeting included: TODO: Eran to add extensibility language for this based on requirements. -"RedirectURI" should be optional TODO: Eran to send mail to the list proposing language changes to either change this from REQUIRED to OPTIONAL and add clarifying language, or leave as required and add a pre-defined value for "we're not actually using this". Is this proposed change just limited to section 4.5? It seems to make sense to have redirect_uri be optional in section 4.1.3 as well (access token request using grant_type authorization code). Since this request is made directly from the client to the authorization server, I don't see why this would be required. For at least some implementations of the 3-legged flow, it would make sense to not have this be a requirement. Comments? Thanks, -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Question on action item to make RedirectURI optional
why must the redirect_uri be validated if it is pre-registered and not included in the authorization request? regards, Torsten. Am 29.05.2011 18:20, schrieb Eran Hammer-Lahav: This applies to 4.1.1 and 4.2.1 only. It must be required in 4.1.3 is must match the location actually used by the server to deliver the code to (regardless of whether the redirection uri was registered or included explicitly with the request). EHL *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Mike Jones *Sent:* Friday, May 27, 2011 2:08 PM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Question on action item to make RedirectURI optional The minutes from the special meeting included: TODO: Eran to add extensibility language for this based on requirements. -"RedirectURI" should be optional TODO: Eran to send mail to the list proposing language changes to either change this from REQUIRED to OPTIONAL and add clarifying language, or leave as required and add a pre-defined value for "we're not actually using this". Is this proposed change just limited to section 4.5? It seems to make sense to have redirect_uri be optional in section 4.1.3 as well (access token request using grant_type authorization code). Since this request is made directly from the client to the authorization server, I don't see why this would be required. For at least some implementations of the 3-legged flow, it would make sense to not have this be a requirement. Comments? 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] Question on action item to make RedirectURI optional
-Doug Tangren http://lessis.me On Sun, May 29, 2011 at 12:41 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > why must the redirect_uri be validated if it is pre-registered and not > included in the authorization request? > I think the preregistered redirect_uri may only require the core components of where the user will be redirected to after authorization The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path. If a redirection URI was registered, the authorization server MUST compare any redirection URI received at the authorization endpoint with the registered URI. - http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.1.1 What you pre-register determines how you would match the provided requests' redirect_uris. It's explicitly required for an explicit location to redirect to on a request by request basis. The exact match in 4.1.3 is required to have a binding between the first and second request in the auth code flow. I think the idea behind a pre-registered redirect_uri was to limit where credentials will be sent to after authorization. In oauth1 someone could supply a redirection "callback" to a completely different for every request. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Question on action item to make RedirectURI optional
we need to distinguish (1) the registration of a redirect uri template for the purpose of validating the actual redirect uri of an authorization transaction and the (2) registration of the redirect uri to be used in all authorization requests of a client. In the later case, there is no need for the pass a redirect uri with every authz request. Is OAuth supposed to support (2)? regards, Torsten. Doug Tangren schrieb: -Doug Tangren http://lessis.me On Sun, May 29, 2011 at 12:41 PM, Torsten Lodderstedt wrote: why must the redirect_uri be validated if it is pre-registered and not included in the authorization request? I think the preregistered redirect_uri may only require the core components of where the user will be redirected to after authorization The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path. If a redirection URI was registered, the authorization server MUST compare any redirection URI received at the authorization endpoint with the registered URI. - http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.1.1 What you pre-register determines how you would match the provided requests' redirect_uris. It's explicitly required for an explicit location to redirect to on a request by request basis. The exact match in 4.1.3 is required to have a binding between the first and second request in the auth code flow. I think the idea behind a pre-registered redirect_uri was to limit where credentials will be sent to after authorization. In oauth1 someone could supply a redirection "callback" to a completely different for every request. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
I am also concerned by the fragility of using time-since-credentials-issued, and also the added complexity of specifying this construction. I think it would be preferable to always require a timestamp as part of the authorization header, and maybe even include in the spec a maximum time difference between client and server (e.g. 900 seconds) that can be tolerated. This makes generating the nonce easier also, since the value need to longer be unique over all time. We have such rules in place for an HMAC-based authentication system we use. Once in a while a client has a local clock so far out of sync that there is an issue, but it's rare. -Peter On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward wrote: > Resending to the list from my subscribed account... > > Begin forwarded message: > >> From: Skylar Woodward >> Date: May 23, 2011 6:14:00 PM PDT >> To: Skylar Woodward >> Cc: Eran Hammer-Lahav , OAuth WG >> Subject: Re: [OAUTH-WG] issues with token age element - MAC token >> >> So after discussing this today and reflecting on it a bit, I would suggest >> that nonce simply be the "unique value" (as it is so named) without further >> requirements. It might be suggested that this be composed of an >> random+timestamp (not age) value, but that seems more of a MAY or >> "recommended" practice. If the expectation is that very few if any providers >> would actually check the timestamp (or moreover, the nonce itself), why add >> terminology in the draft that requires it? Developers are doing extra >> housekeeping (and perhaps for a perceived benefit) but with no payoff or >> added security. >> >> I'm sending this feedback based on having implemented the v3-5 changes last >> night (for both client credentials and requests w/ access tokens). After the >> changes, the nonce creation is now the most complicated part of the >> normalized request string and yet these changes offer the least benefit. >> What's most important is that nonces are unique on each request for an ID. >> >> There are issues with age as well: >> >> - As Bill mentioned, if the client stores the issue time based on receipt, >> then the internal clock changes (presumably w/o knowledge of the software >> storing the dates) then time will also fail. Assuming that a user with a bad >> clock (of by hours or more) will never fix it and actually encourages bad >> user behavior (don't fix your clock or Twitterbot will stop working!). >> Though we say that timezones won't bring about the situation of changed >> clock, I'd be to differ. Many users aren't savvy enough to change time zone, >> but just adjust the time to local time anyway. Users who are more likely to >> get it right already have auto clock sync enabled (via web, mobile, etc.) >> >> - What if the token wasn't originally issued programmatically? In this case, >> the issue time has to be obtained from the server and stored on the client >> then you have the same problem as with a timestamp - the client clock is not >> sync'd to the server clock and there is no adjustment. You want this to >> apply to uses outside of just OAuth, but now requiring the client to be able >> to determine an issue time based on when it receives an HTTP request >> necessarily limits the types of token flows for which this can be used. >> >> - It's one more detail to store. Hardly an issue for a developer, but it is >> inelegant. It's like having a double ID. Yet it's not an ID, it is actually >> more of a recording of "my personal clock offset value" but obfuscated >> several times over (one for each token) as issue_date. >> >> - This implementation assumes software programs use the computer internal >> clock exclusively for timestamp. A robust program that is dependent on >> accurate timestamps would ping the origin server (or similar trusted time >> authority) to ask it the current time. Then it could store a "my device >> clock offset" value for the lifetime of the program execution. All requests >> needing timestamp would be adjusted accordingly. For age, if the clock is >> changed since the stored issue_date, the problem can't be corrected in this >> manner. Thus, a significant advantage for timestamp. >> >> All in all, this seems like a misguided but well-intentioned attempt to get >> around end-user issues of mis-set clocks. It feels like a hack and it >> certainly isn't a foolproof solution. The more I think about the >> implications of the age parameter, the less I like it. Timestamp has been >> used for many years in the industry and with reasonable success in relevant >> applications. If we change to a new way of trying to sync on time I think we >> run a greater risk of stumbling upon unforeseen issues, such as those >> outlined above. >> >> I recommend the requirement of an age (or timestamp for that matter) be >> dropped from the nonce construction. For providers that deem it valuable, >> timestamp can be an optional value (either as part of the nonce or t
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Any kind of clock sync requirement for user-agents (basically, home desktops) it completely impractical. The added complexity pales in comparison to the difficulty of trying to use timestamps and any kind of clock sync. No window will be big enough as experience shows some users have closes that are off by more than an hour and a half. The issue here is who is this being optimized for. Server-to-server communication should simply use TLS for privacy and MITM protection on top of MAC instead of using nonces to prevent replay. The whole point of this kind of replay protection is when TLS is not available. I think a better approach is to simply make checking the nonce optional when TLS is used. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Peter Wolanin > Sent: Sunday, May 29, 2011 6:53 PM > To: Skylar Woodward > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > I am also concerned by the fragility of using time-since-credentials-issued, > and also the added complexity of specifying this construction. > > I think it would be preferable to always require a timestamp as part of the > authorization header, and maybe even include in the spec a maximum time > difference between client and server (e.g. 900 seconds) that can be > tolerated. This makes generating the nonce easier also, since the value need > to longer be unique over all time. > > We have such rules in place for an HMAC-based authentication system we > use. Once in a while a client has a local clock so far out of sync that > there is an > issue, but it's rare. > > -Peter > > On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward > wrote: > > Resending to the list from my subscribed account... > > > > Begin forwarded message: > > > >> From: Skylar Woodward > >> Date: May 23, 2011 6:14:00 PM PDT > >> To: Skylar Woodward > >> Cc: Eran Hammer-Lahav , OAuth WG > >> > >> Subject: Re: [OAUTH-WG] issues with token age element - MAC token > >> > >> So after discussing this today and reflecting on it a bit, I would suggest > >> that > nonce simply be the "unique value" (as it is so named) without further > requirements. It might be suggested that this be composed of an > random+timestamp (not age) value, but that seems more of a MAY or > "recommended" practice. If the expectation is that very few if any providers > would actually check the timestamp (or moreover, the nonce itself), why add > terminology in the draft that requires it? Developers are doing extra > housekeeping (and perhaps for a perceived benefit) but with no payoff or > added security. > >> > >> I'm sending this feedback based on having implemented the v3-5 changes > last night (for both client credentials and requests w/ access tokens). After > the changes, the nonce creation is now the most complicated part of the > normalized request string and yet these changes offer the least benefit. > What's most important is that nonces are unique on each request for an ID. > >> > >> There are issues with age as well: > >> > >> - As Bill mentioned, if the client stores the issue time based on > >> receipt, then the internal clock changes (presumably w/o knowledge of > >> the software storing the dates) then time will also fail. Assuming > >> that a user with a bad clock (of by hours or more) will never fix it > >> and actually encourages bad user behavior (don't fix your clock or > >> Twitterbot will stop working!). Though we say that timezones won't > >> bring about the situation of changed clock, I'd be to differ. Many > >> users aren't savvy enough to change time zone, but just adjust the > >> time to local time anyway. Users who are more likely to get it right > >> already have auto clock sync enabled (via web, mobile, etc.) > >> > >> - What if the token wasn't originally issued programmatically? In this > >> case, > the issue time has to be obtained from the server and stored on the client > then you have the same problem as with a timestamp - the client clock is not > sync'd to the server clock and there is no adjustment. You want this to apply > to uses outside of just OAuth, but now requiring the client to be able to > determine an issue time based on when it receives an HTTP request > necessarily limits the types of token flows for which this can be used. > >> > >> - It's one more detail to store. Hardly an issue for a developer, but it is > inelegant. It's like having a double ID. Yet it's not an ID, it is actually > more of a > recording of "my personal clock offset value" but obfuscated several times > over (one for each token) as issue_date. > >> > >> - This implementation assumes software programs use the computer > internal clock exclusively for timestamp. A robust program that is dependent > on accurate timestamps would ping the origin server (or similar trusted time > authority) to ask it the current time. Then it could store a "my device clock > offset" value for
